Все, что вам нужно знать о моделировании вариантов использования

Преимущества диаграммы вариантов использования

1. Сценарии использования — это мощная техника для выявления и документирования функциональных требований черного ящика.
2. Потому что варианты использования просты для понимания и обеспечивают отличный способ общения с клиентами и пользователями, поскольку они написаны на естественном языке.
3. Сценарии использования могут помочь справиться со сложностью крупных проектов, разбивая проблему на основные пользовательские функции (т. е. варианты использования) и определяя приложения с точки зрения пользователей.
4. Сценарий варианта использования, часто представленный диаграммой последовательности, включает в себя сотрудничество нескольких объектов и классов, варианты использования помогают идентифицировать сообщения (операции и требуемую информацию или данные — параметры), которые объединяют объекты и классы.
5. Сценарии использования обеспечивают хорошую основу для установления связи между проверкой моделей более высокого уровня (т. е. взаимодействие между участниками и набором совместно используемых объектов) и, впоследствии, для проверки функциональных требований (т. е. плана теста белого ящика).
6. Подход, основанный на вариантах использования, обеспечивает прослеживаемые связи для отслеживания проекта, в котором основные действия по разработке, такие как варианты использования, реализованы, протестированы и доставлены, выполняя цели и задачи с точки зрения пользователя.

Как нарисовать диаграмму вариантов использования?

Модель варианта использования можно разработать, выполнив следующие действия.

1. Определите Актеров (роли пользователей) системы.
2. Для каждой категории пользователей определите все роли, которые играют пользователи, относящиеся к системе.
3. Определите, какие пользователи требуют, чтобы система выполнялась для достижения этих целей.
4. Создавайте варианты использования для каждой цели.
5. Структурируйте варианты использования.
6. Расставьте приоритеты, просмотрите, оцените и подтвердите пользователей.

Обратите внимание, что: чтобы сделать подход к вариантам использования более «гибким», не детализируйте все варианты использования, а расставьте им приоритеты в бэклоге продукта, вы должны уточнить вариант использования на разных уровнях детализации в соответствии с этапом разработки с помощью «точно вовремя». и достаточно образом.

Вы также можете:

1. Нарисуйте пакеты для логического разделения вариантов использования на связанные подсистемы.

Структурирование вариантов использования

UML определяет три стереотипа связи между вариантами использования:

<<включить>> Пример использования

Время использовать отношение <<include>> наступает после того, как вы завершили первое описание всех ваших основных вариантов использования. Теперь вы можете просмотреть варианты использования и определить общие последовательности взаимодействия пользователя с системой.

<<расширить>> Вариант использования

Расширенный вариант использования фактически является альтернативой базовому варианту использования. Вариант использования «расширить» выполняет это, концептуально вставляя дополнительные последовательности действий в последовательность базового варианта использования.

Абстрактный и обобщенный вариант использования

Общий вариант использования является абстрактным. Его нельзя создать, так как он содержит неполную информацию. Название абстрактного варианта использования выделено курсивом.

Пример

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

После того, как базовые варианты использования были определены в первом варианте, возможно, мы могли бы дополнительно структурировать эти варианты использования с помощью <<extend>> и <<include>> вариантов использования во втором раунде, как показано на рисунке ниже:

Пример использования в бизнесе

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

Как определить актеров

Часто люди считают, что проще всего начать процесс выявления требований с определения действующих лиц. Следующие вопросы могут помочь вам определить действующих лиц вашей системы (Шнайдер и Винтерс, 1998 г.):

• Кто использует систему?
• Кто устанавливает систему?
• Кто запускает систему?
• Кто обслуживает систему?
• Кто отключает систему?
• Какие другие системы используют эту систему?
• Кто получает информацию из этой системы?
• Кто предоставляет информацию системе?
• Происходит ли что-нибудь автоматически в настоящее время?

Как определить варианты использования?

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

• Какие функции актор хочет получить от системы?
• Хранит ли система информацию? Какие действующие лица будут создавать, читать, обновлять или удалять эту информацию?
• Должна ли система уведомлять актора о шансах во внутреннем состоянии?
• Существуют ли какие-либо внешние события, о которых система должна знать? Какой актор информирует систему об этих событиях?

Советы по диаграмме вариантов использования

Теперь ознакомьтесь с приведенными ниже советами, чтобы узнать, как эффективно применять варианты использования в вашем программном проекте.

• Всегда структурируйте и организуйте диаграмму вариантов использования с точки зрения действующих лиц.
• Сценарии использования должны начинаться с простого и максимально возможного просмотра. Только после этого их можно уточнять и детализировать.
• Диаграммы вариантов использования основаны на функциональности и поэтому должны фокусироваться на том, «что», а не «как».

Уровни детализации вариантов использования

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

Аластер Кокберн в  « Написание эффективных вариантов использования  » дает нам простой способ визуализировать различные уровни уровня цели, думая с точки зрения моря:

Обратите внимание, что:

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

Надеюсь, теперь вы сможете ответить на вопрос «что такое диаграмма вариантов использования» и сможете применить вариант использования в своем проекте. Если вы хотите узнать больше о других типах диаграмм UML, ознакомьтесь с руководством по UML:  Обзор 14 типов диаграмм UML .

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

Спецификация варианта использования обычно создается на этапе анализа и проектирования итеративным образом.

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

Вариант использования против спецификации варианта использования

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

Вариант использования (задача — заказчик хочет выполнить) может быть:

• Интерактивный — вариант использования системы описывает взаимодействие актера с системой для достижения определенной бизнес-цели.
• Руководство — последовательность действий, выполняемых актером.
• Автоматизированный — последовательность шагов, выполняемых программой или сценарием.

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

Вариант использования имеет:

• Только одна цель
• Единая отправная точка
• Единая конечная точка
• Несколько путей для прохождения от начала до конца
• т.е. указать поведение для множества возможных условий
• Каждое условие может потребовать определенных действий.

Например — Клиент оплачивает счет:

Есть несколько путей достижения цели:

• Оплата по телефону
• По почте
• Лично
• чеком
• наличными и др.

Путь, не ведущий к цели:

• Кредитная карта отклонена

Гибкий подход к вариантам использования

Модель вариантов использования и ее отдельные варианты использования со временем развиваются уровень за уровнем. Не все варианты использования модели обязательно должны быть указаны с одинаковым уровнем детализации.

Точно вовремя и достаточно

Варианты использования могут быть написаны на разных уровнях данных и области действия, каждый из которых служит определенной цели:

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

Примечание. Некоторые варианты использования могут быть достаточно определены до уровня II. Вы останавливаетесь, когда достигается достаточное количество деталей, используя метод «точно вовремя» и «достаточно точно».

Подробная спецификация варианта использования

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