Кейс

Кейс (Case) в контексте CPA — описание последовательности определенных действий, при выполнении которых, автор кейса получил профит. Часто кейсом является связка источник-креатив-ПП-оффер.

В программном обеспечении и системной инженерии фраза "прецедент" представляет собой полисемию с двумя значениями:

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

• Потенциальный сценарий, в котором система получает внешний запрос (например, ввод данных пользователем) и отвечает на него.

В этой статье рассматривается последний смысл.

Вариант использования-это список действий или шагов события, обычно определяющих взаимодействие между ролью (известной в Унифицированном языке моделирования (UML) как субъект) и системой для достижения цели. Действующим лицом может быть человек или другая внешняя система. В системной инженерии примеры использования используются на более высоком уровне, чем в программной инженерии, часто представляя миссии или цели заинтересованных сторон. Подробные требования затем могут быть отражены на языке моделирования систем (SysML) или в виде договорных заявлений.

История

В 1987 году Ивар Якобсон представил первую статью о случаях использования на конференции OOPSLA'87. Он описал, как этот метод использовался в Ericsson для определения и определения требований к системе с использованием текстовых, структурных и визуальных методов моделирования для управления объектно-ориентированным анализом и проектированием. Первоначально он использовал термины сценарии использования и прецедент – последний является прямым переводом его шведского термина användningsfall – но обнаружил, что ни один из этих терминов не звучит естественно на английском языке, и в конечном итоге он остановился на прецеденте.

В 1992 году он стал соавтором книги "Объектно-ориентированная разработка программного обеспечения-подход, основанный на прецедентах" , которая заложила основу метода разработки систем OOSE и помогла популяризировать варианты использования для учета функциональных требований, особенно при разработке программного обеспечения. В 1994 году он опубликовал книгу о вариантах использования и объектно-ориентированных методах, применяемых к бизнес-моделям и реинжинирингу бизнес-процессов.

В то же время Грейди Буч и Джеймс Рамбо работали над объединением своих методов объектно-ориентированного анализа и проектирования, метода Буча и Метода объектного моделирования (OMT) соответственно. В 1995 году к ним присоединился Ивар Якобсон, и вместе они создали Унифицированный язык моделирования (UML), который включает моделирование вариантов использования. UML был стандартизирован Группой управления объектами (OMG) в 1997 году. Джейкобсон, Буч и Румбо также работали над усовершенствованием процесса разработки программного обеспечения для объектов. Полученный в результате Унифицированный процесс был опубликован в 1999 году и пропагандировал подход, основанный на прецедентах.

С тех пор, многие авторы внесли свой вклад в развитие техники, в частности: Ларри Константина созданное в 1995 году, в контексте использования-по центру конструкции, так называемые "существенные случаи использования", которые направлены для описания пользовательского намерения, а не последовательность действий или сценариев, которые могут ограничить или исказить дизайн пользовательского интерфейса; Алистер Кокберн , опубликованной в 2000 целенаправленное использование судебной практики на основе текста описательной и табличной спецификации; Курта Биттнера и Ян Спенс созданное в 2002 передовых методов для анализа функциональных требований с использованием делам; Дин Леффингуэлл и Дон Видриг предложили применять варианты использования для управления изменениями и деятельности по взаимодействию с заинтересованными сторонами; Гуннар Овергаард предложил в 2004 году распространить принципы шаблонов проектирования на варианты использования.

В 2011 году Джейкобсон опубликовал вместе с Яном Спенсом и Куртом Биттнером электронную книгу "Вариант использования 2.0", чтобы адаптировать метод к гибкому контексту, обогатив его дополнительными "фрагментами" вариантов использования и продвигая его использование на протяжении всего жизненного цикла разработки после представления обновленного подхода на ежегодной конференции IIBA.

Общий принцип

Варианты использования-это метод для сбора, моделирования и определения требований системы. Вариант использования соответствует набору поведений, которые система может выполнять во взаимодействии со своими участниками и которые дают наблюдаемый результат, способствующий достижению ее целей. Участники представляют роль, которую играют пользователи - люди или другие системы во взаимодействии.

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

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

Вариации

Существуют различные варианты использования и вариации в технике:

• Варианты использования системы определяют требования к разрабатываемой системе. В их подробном описании указываются не только взаимодействия с субъектами, но и сущности, участвующие в обработке. Они являются отправной точкой для дальнейшего анализа моделей и проектной деятельности.
• Бизнес-примеры использования сосредоточены на бизнес - организации, а не на программной системе. Они используются для определения бизнес-моделей и требований к бизнес-процессам в контексте инициатив по реинжинирингу бизнес-процессов.
• Основные варианты использования, также называемые абстрактными вариантами использования, описывают потенциальные намерения участников и то, как система решает эти проблемы, без определения какой-либо последовательности или описания сценария. Эта практика была разработана с целью поддержки ориентированного на пользователя проектирования и предотвращения предвзятого отношения к пользовательскому интерфейсу на ранней стадии спецификаций системы.
• Вариант использования 2.0 адаптирует методику в контексте методов гибкой разработки. Этот метод обогащает практику сбора требований поддержкой повествований пользовательских историй. Он также предоставляет "фрагменты" вариантов использования для облегчения постепенного выявления требований и обеспечения постепенной реализации.

Масштаб

Область применения может быть определена в зависимости от предмета и целей:

   Субъект определяет систему, подсистему или компонент, которые будут обеспечивать взаимодействие.
   Цели могут быть структурированы иерархически с учетом организационного уровня, заинтересованного в достижении цели (например, компания, отдел, пользователь), и декомпозиции цели пользователя на подцели. Декомпозиция цели выполняется с точки зрения пользователей и независимо от системы, что отличается от традиционной функциональной декомпозиции.  

Использование

Случаи использования, как известно, применяются в следующих контекстах:

1. Объектно-ориентированная программная инженерия (OOSE), как движущий элемент;
2. Унифицированный язык моделирования (UML), как инструмент моделирования поведения;
3. Единый процесс разработки программного обеспечения (UP) и его предшественник, IBM Rational Unified Process (RUP);
4. предварительная документация спецификации требований к программному обеспечению (SRS) в качестве альтернативной структуры для функциональных требований;
5. вывод проекта из требований с использованием подхода "объект-контроль-граница";
6. и гибкая разработка.

Шаблоны

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

Стиль Кокберна

Шаблон, определенный Алистером Кокберном в его книге "Написание эффективных вариантов использования", был одним из наиболее широко используемых стилей написания вариантов использования.[требуется цитирование] Области проектирования Кокберн предлагает аннотировать каждый вариант использования символом, чтобы показать "Область разработки", которая может быть черным ящиком (внутренняя деталь скрыта) или белым ящиком (внутренняя деталь показана). Доступно пять символов

Масштаб	Икона
Организация (черный ящик)	Заполненный Дом
Организация (белый ящик)	Незаполненный Дом	Scope-icons-unfilled-house
Система (черный ящик)	Заполненная Коробка	Scope-icons-filled-box
Система (белый ящик)	Незаполненная Коробка	Scope-icons-unfilled-box
Компонент	Шуруп или болт	Scope-icons-screw-bolt

Другие авторы иногда называют варианты использования на уровне организации "Бизнес-варианты использования"[21].

Уровни целей

Иерархия уровней целей

Кокберн предлагает аннотировать каждый вариант использования символом, чтобы показать "Уровень цели"; предпочтительный уровень-"Цель пользователя" (или, в просторечии, "уровень моря

См.также

Клоака