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

С публикацией книги Ивара Якобсона (1991) « Объектно-ориентированная разработка программного обеспечения, подход , ориентированный на прецеденты» моделирование прецедентов фактически стало практическим методом анализа». Сегодня Джейкобсон продолжает продвигать этот подход к системному анализу и обновил его до варианта использования 2.0, который официально является одним из 14 типов диаграмм UML .

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

Вариант использования не является процедурой, процессом или функцией.

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

Элементами диаграммы вариантов использования являются действующие лица (внешние объекты) и сам вариант использования. В широком смысле вариант использования — это функциональная единица (требование) или услуга в системе.

Актер

Актер — это любая сущность, внешняя по отношению к системе дизайна, будь то человек или другая нечеловеческая сущность. Пользователь системы — типичный пример актора. К другим типам участников относятся программные системы, которые интегрируются с текущей системой (например, система баз данных), внешнее оборудование, такое как датчик, и т.д.

В спецификации UML есть две нотации :

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

Актер — это роль, а не реальный человек 

Актер представляет собой роль сущности, которая взаимодействует с текущей системой, а не экземпляра. Обозначение актора указывает, что объект является классом, а не экземпляром для чтения (т. е. реальным пользователем Джоном или Мэри). Причина, по которой актер является типом класса, заключается в том, что это не сам актер, а роль, которую он играет.

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

Первичные и второстепенные актеры

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

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

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

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

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

Варианты использования представляют собой функции (обычно требования), которые, как ожидается, будут реализованы системой. Детали варианта использования, за исключением его уникального имени, интуитивно не выражены на диаграмме; Эти детали приведены в описании варианта использования.

Варианты использования обычно инициируются ключевыми участниками. Система использует базу данных и других вспомогательных участников через набор вариантов использования.

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

Системная граница

Граница системы определяет интересующую систему по отношению к окружающему миру.

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

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

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

ИЗМЕНИТЬ ЭТОТ ПРИМЕР СХЕМЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ UML

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

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

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

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

Обобщение

Обобщение представляет собой отношение между

• роли или
• случаи применения.

ИЗМЕНИТЬ ЭТОТ ШАБЛОН СХЕМЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ UML

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

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

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

Включение   — это особый тип отношений между двумя вариантами использования. Если вариант использования A включает в себя другой вариант использования B, то реализация A требует реализации B для выполнения своей задачи. Однако B не зависит от самого себя. То есть B не нужно ничего знать об A. B также может быть включен в любой другой вариант использования.

ИЗМЕНИТЬ ЭТОТ ПРИМЕР ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

Расширение — это еще один особый вид отношений между двумя вариантами использования. Если вариант использования B расширяет другой вариант использования A, то реализация A может условно включать реализацию B для выполнения своей задачи. То есть в некоторых случаях А может выполнить свою задачу без Б. Однако в зависимости от описанных условий.

ИЗМЕНИТЬ ЭТОТ ПРИМЕР ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

Обозначения диаграмм вариантов использования

ОТРЕДАКТИРУЙТЕ ЭТОТ ПРИМЕР СХЕМЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ ОНЛАЙН

9 простых шагов для анализа вариантов использования

1. Определите, кто будет непосредственно пользоваться системой. Эти люди — актеры.
2. Выберите одного из этих актеров.
3. Определите, что этот актер хочет делать с системой. Каждая вещь, которую актор хочет сделать с системой, становится вариантом использования.
4. Повторите шаги 2–3 для всех других вариантов использования
   . Определите второстепенные роли и нечеловеческую поддержку ролей для определенных вами вариантов использования.
5. Нарисуйте первоначальную версию варианта использования, не усложняйте связи вариантов использования на этом этапе.
6. Обсудите и проанализируйте с пользователями, чтобы подтвердить цели каждого варианта использования (преимущества предлагаемой функциональности). После внесения изменений вы можете продолжить детализировать варианты использования на шагах 8–10.
7. Для каждого варианта использования определите наиболее распространенный процесс, которому действующее лицо будет следовать при использовании системы. Что обычно происходит.
8. Опишите этот базовый процесс в описании варианта использования.
9. Как только вы будете удовлетворены основным процессом, рассмотрите альтернативные сценарии и добавьте их в качестве расширенных вариантов использования.

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

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

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

Сценарии использования

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

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

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

Например – клиент оплачивает счет:

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

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

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

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

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

Вы также можете: Нарисовать пакеты для логической категоризации вариантов использования на связанные подсистемы.

ИЗМЕНИТЬ ЭТОТ ПРИМЕР ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

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

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

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

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

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

Основное действующее лицо — действующее лицо, которое инициирует вариант использования.
Второстепенное действующее лицо — действующее лицо, которое реагирует или отвечает на действия, выполняемые основным действующим лицом.
Заинтересованные стороны — действующие лица за кулисами, которые не взаимодействуют напрямую с вариантом использования, но заинтересованы в результате варианта использования.

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

Нормальный путь — ввод от действующего лица и ответ системы — представляет собой наиболее распространенный путь успеха для достижения целей действующего лица.

Альтернативные пути — входные данные от актора и ответов системы, представляющие другие менее распространенные пути для достижения цели актера.

Исключительные пути — входные данные от субъекта и ответ системы, представляющие неудачные пути, когда цель субъекта не может быть достигнута.

Описание варианта использования
Используйте имя случая:	Снимать наличные
Актер (ы):	Клиент (основной), Банковская система (дополнительный)
Краткое описание:	Позволяет любому клиенту банка снимать наличные со своего банковского счета.
Приоритет:	Должен иметь
Положение дел:	Средний уровень детализации
Предварительное условие:	У клиента банка есть карта для вставки в банкомат Банкомат работает правильно
Постсостояние(я):	Клиент банка получил наличные (и, возможно, квитанцию) Банк дебетовал банковский счет клиента и зафиксировал детали транзакции.
Основной путь:	Клиент вводит свою карту в банкомат. Банкомат проверяет, является ли карта действительной банковской картой. Банкомат запрашивает PIN-код. Клиент вводит свой PIN-код Банкомат проверяет банковскую карту по ПИН-коду В банкомате представлены варианты обслуживания, включая «Снятие» Клиент выбирает «Снять». Банкомат представляет варианты сумм Клиент выбирает сумму или вводит сумму Банкомат проверяет наличие достаточного количества наличных в своем бункере. Банкомат проверяет, что клиент находится ниже лимита на снятие средств. Банкомат проверяет наличие средств на банковском счете клиента. Банкомат списывает деньги со счета клиента Банкомат возвращает банковскую карту клиента Клиент берет свою банковскую карту Банкомат выдает наличные деньги клиенту Клиент забирает свои деньги
Альтернативные пути:	2а. Недействительная карта 2б. Карта вверх ногами 5а. Украденная карта 5б. PIN-код недействителен 10а. Недостаточно денег в бункере 10б. Неправильный номинал наличных в хоппере 11а. Вывод сверх лимитов вывода 12а. Недостаточно средств на банковском счете клиента 14а. Банковская карта застряла в автомате 15а. Клиент не берет свою банковскую карту 16а. Деньги застряли в автомате 17а. Клиент не может забрать наличные банкомат не может связаться с банковской системой b Клиент не отвечает на запрос банкомата.
Бизнес правила:	B1: Формат ПИН-кода B2: количество попыток ввода PIN-кода B3: Варианты обслуживания B4: Варианты суммы B5: лимит снятия B6: карту необходимо забрать перед выдачей наличных
Нефункциональные требования:	NF1: время завершения транзакции NF2: Безопасность ввода PIN-кода NF3: пора разрешить сбор карт и наличных NF4: языковая поддержка NF5: Слепая и частично слепая поддержка

Ссылки по теме

1. Что такое унифицированный язык моделирования?
2. Слайд примера использования / конспект лекций
3. Роль вариантов использования в моделировании требований и анализа
4. Список инструментов UML
5. Попробуйте Visual Paradigm БЕСПЛАТНО
6. Пример использования — Примечания для учебного курса
7. Как написать эффективные варианты использования?
8. Глава книги — PDF — Модель прецедентов: написание требований в контексте