Коллеги,

что такое Software Requirement Patterns?
В контексте - http://www.amazon.com/gp/product/0735623988/ref=pe_pe_5400_5954140_pe_snp_988

типовые варианты использования

это если книжек
http://www.isbnonline.com/Use-Cases-Patterns-and-Blueprints/book/9780131451346/
и
http://www.isbnonline.com/Patterns-for-Effective-Use-Cases/book/9780201721843/
не хватило, то можно почитать

Коллеги, а на русском языке про Патеррны Вариантов Использования нет никакой литературы?

Спасибо.

А вот в этой книжке нет?
“Применение UML 2.0 и шаблонов проектирования” 3-е издание, Крэг Ларман

Я искал, но ничего не нашел. Вообще тема паттренов ВИ слабо развита, неговоря уже про Россию. Лучшее собрание - это книга Овергаарда. Есть немного у Коберна и разные статьи в интернете, но все это на английском.

bas, спасибо. Такую книжку не читал.

Сейчас пробежался по ней и, насколько я понял, в ней указываются патерны проектирования, а не прецедентов использования. Хотя могу ошибаться...

Хотелось бы все-таки про патерны вариантов использования почитать

Виталий, спасибо

Как я и подозревал... Придется углубить свои познания английского.

Хотелось бы все-таки про патерны вариантов использования почитать

Если речь идёт о шаблонах вариантов использования, то читайте Устав... тьфу, чёрт, Коберна - там всё написано.

http://www.ozon.ru/context/detail/id/1061643/

Если речь идёт о шаблонах вариантов использования, то читайте Устав... тьфу, чёрт, Коберна - там всё написано.
http://www.ozon.ru/context/detail/id/1061643/

greesha,
думаю надо разделять понятие Use Case Pattern и Scenario Template.
bustor говорит о первом, Коберн в приведенной книге пишет про вторые.
1. Шаблон ВИ (шаблон сценария) - это то как оформлять сценарий.
2. Паттерн ВИ - это решение конкретной задачи (проблемы) определнным способом. Имеются ввиду, что не нужно "изобретать велосипед" - посмотри как сделали другие и используй это. Т.е по сути паттерн - это reuse sample.
Например, всем известный CRUD pattern, говорит о том, что в одном ВИ но разными независимыми потоками описываем все операции по созданию и редактированию объекта. Его удобно использовать, когда не очень сложная логика создания и редактирования.
Паттерн Multiple actors - позволяет описывать один ВИ для пользователей с различными ролями, те не нужно дублировать ВИ для каждой роли, если человек выполнеяет действия немного по разному в зависиости от роли и тп...

Паттерн Multiple actors - позволяет описывать один ВИ для пользователей с различными ролями, те не нужно дублировать ВИ для каждой роли, если человек выполнеяет действия немного по разному в зависиости от роли и тп...

Виталий, вот тут(http://www.uml2.ru/forum/index.php?topic=932.msg10125#msg10125) кажется как раз есть потребность в использовании данного паттерна. Может ты там расскажешь о его прелестях?

Книгу не читал - буду восполнять.

Это не мешает мне использовать паттерны "CRUD", "действия - структура данных - ограничение полномочий", "подсистема - расширяющий модуль".

А "отображать сообщения, как в Thunderbird", "сделать настройку прокси, как в Firefox", "сделать настройку регулярных задач, как регулярных встреч в Outlook", "сделать отчёты, как в Rational SoDA" я бы всё-же не стал называть паттернами: банальное списывание заведомо работающих (хотя и не обязательно лучших) решений. И то, такое описание - лишь чуть лучше, чем "TBD".

что такое Software Requirement Patterns?
В контексте - http://www.amazon.com/gp/product/0735623988/ref=pe_pe_5400_5954140_pe_snp_988

типовые варианты использования

Денис, ты уверен, что в книге Software Requirement Patterns сказано именно про паттерны ВИ? А не вообще про патерны и других видов Требований?!

Ни у кого кстати нет этой книги в электронном или печатном варианте (если в Мск)

Также меня заинтересовала книга Requirements Patterns and Antipatterns: Best (and Worst) Practices for Defining Your Requirements (Paperback). Кто что про нее может сказать?

Ни у кого кстати нет этой книги в электронном или печатном варианте (если в Мск)

Книжка есть у меня в электронном виде. Читал по-диагонали , она не про паттерны ВИ. Она про типовые решения в требованиях вообще, например как описывать бизнес-правила, ограничения, интерфейсы и тп.
Книга хорошая, IMHO. Если есть время советую по ней пробежаться.
Краткая аннотация книги