Используйте моделирование вариантов

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

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

Краткий обзор диаграммы вариантов использования

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

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

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

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

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

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

Актер

• Кто-то взаимодействует с вариантом использования (системной функцией).
• Названо существительным.
• Актер играет роль в бизнесе
• Подобно концепции пользователя, но пользователь может играть разные роли
• Например:
• проф. может быть инструктором, а также исследователем
• играет 2 роли с двумя системами
• Актер запускает прецедент(ы) использования.
• У Актера есть ответственность перед системой (входы), а у Актера есть ожидания от системы (выходы).

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

• Функция системы (процесс — автоматизированный или ручной)
• Названо глаголом + существительным (или именной фразой).
• т.е. сделать что-то
• Каждый субъект должен быть связан с вариантом использования, в то время как некоторые варианты использования могут быть не связаны с акторами.

Связь

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

Граница системы

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

6 шагов анализа вариантов использования

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

Шаг 1 — определите действующих лиц: определите, кто будет напрямую использовать систему. Это Актёры.

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

Шаг 2: Выберите одного из этих актеров.

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

Шаг 3 — Определите варианты использования: определите, что этот Актер хочет делать с системой. Каждая из этих вещей, которые актер хочет сделать с системой, становится вариантом использования.

• Вещи, которые акторы хотят сделать с системой, становятся целями.
• Цель — это конечный результат действий пользователя. Есть два типа целей. Первый тип – жесткая цель.
• Эта цель должна быть полностью удовлетворена и описывает минимальные требования целевой системы.
• Чтобы определить варианты использования, мы можем прочитать спецификацию требований с точки зрения актера и продолжить обсуждение с теми пользователями, которые будут действовать как актеры.
• Путем определения всего, что каждый актор сможет делать при взаимодействии с системой, определяется полная функциональность системы.

Шаг 4 — Определите сценарий нормального варианта использования. Для каждого из этих вариантов использования определите наиболее обычный курс, когда этот субъект использует систему. Что обычно происходит.

• Вариант использования имеет один базовый курс и несколько альтернативных курсов.
• Базовый курс — это самый простой курс, в котором запрос доставляется без каких-либо затруднений.
• Могут быть альтернативные курсы, описывающие варианты основного курса и возможные ошибки.
• Они задокументированы как расширения варианта использования.

Шаг 5 — Разработка описания варианта использования. Опишите этот базовый курс в описании варианта использования.

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

Шаг 6 — Разработайте альтернативные варианты использования: когда вы довольны базовым курсом, рассмотрите альтернативы и добавьте их в качестве расширенных вариантов использования.

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

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

• Есть две разновидности:  исключения  и  альтернативы .
• Исключения составляют условия отказа (что-то пошло не так).
• Альтернативы — это просто другой способ сделать все правильно.

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

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

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

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

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

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

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

• Как нарисовать диаграмму вариантов использования
• Учебное пособие по диаграмме прецедентов
• Описание варианта использования