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

Actor Актер (actor) — согласованное множество ролей, которые играют внешние сущности по отношению к вариантам использования при взаимодействии с ними. Актер представляет собой любую внешнюю по отношению к моделируемой системе

• Главная
• Информатика
• Диаграмма вариантов использования

Слайды и текст этой презентации

Слайд 1Диаграмма вариантов использования
Диаграмма вариантов использования (use case

diagram) — диаграмма, на которой изображаются отношения

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

Диаграмма вариантов использования — это исходное концептуальное представление или концептуальная модель системы в процессе ее проектирования и разработки. Создание диаграммы вариантов использования имеет следующие цели:

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

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

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

Слайд 2Actor
Актер (actor) — согласованное множество ролей, которые

играют внешние сущности по отношению к вариантам

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

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

Слайд 3Вариант использования
Вариант использования (use case) — внешняя

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

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

Дизайнер мужской одежды: обучение, производство и выбор шрифта для футболок

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

Слайд 4Отношения
Отношение (relationship) — семантическая связь между отдельными

элементами модели.
Между элементами диаграммы вариантов использования

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

ассоциации (association relationship)
включения (include relationship)
расширения (extend relationship)
обобщения (generalization relationship)

Слайд 5Ассоциация
Отношение ассоциации – одно из фундаментальных понятий

в языке UML и в той или

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

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

Слайд 6Включение
Включение (include) в языке UML — это

разновидность отношения зависимости между базовым вариантом использования

и его специальным случаем. При этом отношением зависимости является такое отношение между двумя элементами модели, при котором изменение одного элемента (независимого) приводит к изменению другого элемента (зависимого).
Отношение включения устанавливается только между двумя вариантами использования и указывает на то, что заданное поведение для одного варианта использования включается в качестве составного фрагмента в последовательность поведения другого варианта использования. Так, например, отношение включения, направленное от варианта использования «Предоставление кредита в банке» к варианту использования «Проверка платежеспособности клиента», указывает на то, что каждый экземпляр первого варианта использования всегда включает в себя функциональное поведение или выполнение второго варианта использования. В этом смысле поведение второго варианта использования является частью поведения первого варианта использования на данной диаграмме. Графически данное отношение обозначается как отношение зависимости в форме пунктирной линии со стрелкой, направленной от базового варианта использования к включаемому варианту использования. При этом данная линия помечается стереотипом >:

Слайд 7Расширение
Отношение расширения (extend) определяет взаимосвязь базового варианта

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

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

Слайд 8Обобщение
Два и более актера могут иметь общие

свойства, т. е. взаимодействовать с одним и

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

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

Слайд 9Дополнительные обозначения языка UML для бизнес-моделирования
Бизнес-актер (business

actor) – индивидуум, группа, организация, компания или

система, которые взаимодействуют с моделируемой бизнес-системой, но не входят в нее, т.е. не являются частью системы. Общее свойство бизнес-актеров состоит в том, что они являются инициаторами или клиентами бизнес-процессов моделируемой системы.
Сотрудник (business worker) – индивидуум, который действует внутри моделируемой бизнес-системы, взаимодействует с другими сотрудниками и является участником бизнес-процесса моделируемой системы. Общее свойство сотрудников заключается в том то, что они являются субъектами и входят в состав моделируемой системы.
Бизнес-вариант использования (business use case) — вариант использования, определяющий последовательность действий моделируемой системы, направленных на выполнение отдельного бизнес-процесса.

Слайд 10Пример бизнес-модели
Диаграмма вариантов использования для системы продажи

товаров по каталогу в общих обозначениях языка

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

Слайд 11Требования
Требование (requirement) — желательное свойство, характеристика или

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

своей эксплуатации.
Применительно к программным системам предложена следующая классификация требований, которая получила название модели FURPS+, что соответствует первым буквам соответствующих категорий требований на английском языке:
функциональные требования (Functionality)
требования удобства использования (Usability)
требования надежности (Reliability)
требования производительности (Performance)
требования возможности сопровождения (Supportability)
При этом символом «+» обозначены дополнительные условия, к которым относятся:
проектные ограничения
требования управления системой
требования к графическому интерфейсу пользователя
физические требования
юридические требования

Слайд 12Сценарии
Центральное место среди указанных требований занимают функциональные,

которые специфицируют особенности реализации отдельных бизнес-процессов моделируемой

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

Источник: thepresentation.ru

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

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

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

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

Актер – это Кто в системе, другими словами, он конечный пользователь.

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

Вариант использования определяет поток событий в системе. Это больше касается того, что выполняется системой для выполнения последовательности действий.

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

Вариант использования обеспечивает следующие преимущества:

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

Это простое средство определения функциональных требований с акцентом на добавленную стоимость для пользователя.

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

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

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

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

Имя : Описательное имя, которое иллюстрирует цель варианта использования.

Описание : Описывает, что использует прецедент в нескольких предложениях.

Актер : Перечислите любых актеров, которые участвуют в сценарии использования.

Предварительное условие : условия, которые должны быть выполнены до начала использования.

Поток событий : описание взаимодействия между системой и актером.

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

Руководство для шаблона использования

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

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

• Идентификатор варианта использования – присвойте каждому варианту использования уникальный числовой идентификатор в иерархической форме: XY Связанные варианты использования можно сгруппировать в иерархии. Функциональные требования можно проследить до обозначенного варианта использования.
• Имя варианта использования – укажите краткое, ориентированное на результаты имя для варианта использования. Они отражают задачи, которые пользователь должен выполнять с помощью системы. Включите глагол действия и существительное. Некоторые примеры –

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

Идентификатор варианта использования – присвойте каждому варианту использования уникальный числовой идентификатор в иерархической форме: XY Связанные варианты использования можно сгруппировать в иерархии. Функциональные требования можно проследить до обозначенного варианта использования.

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

Просмотр информации о номере детали.

Вручную пометьте источник гипертекста и установите ссылку на цель.

Сделайте заказ на компакт-диск с обновленной версией программного обеспечения.

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

Здесь мы упоминаем об именах людей, которые являются заинтересованными сторонами документа Usecase.

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

Создано – укажите имя человека, который первоначально задокументировал этот вариант использования.

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

Последнее обновление – укажите имя человека, который выполнил самое последнее обновление, в описании варианта использования.

Дата последнего обновления – введите дату последнего использования варианта использования.

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

Ниже приведены определения ключевых концепций варианта использования.

Актер

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

Описание

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

Предпосылками

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

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

Условия размещения

Опишите состояние системы в конце исполнения варианта использования. Пронумеруйте каждый пост.

• Документ содержит только допустимые теги SGML.
• Цена товара в базе данных была обновлена ​​с новым значением.

приоритет

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

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

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

Нормальный ход событий

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

Альтернативные курсы

Документируйте другие, законные сценарии использования, которые могут иметь место в этом сценарии использования отдельно в этом разделе. Укажите альтернативный курс и опишите любые различия в последовательности шагов. Пронумеруйте каждый альтернативный курс, используя идентификатор прецедента, а затем «AC», чтобы указать «Альтернативный курс». Пример: XYAC.1.

Исключения

Опишите любые ожидаемые ошибки, которые могут возникнуть во время выполнения сценария использования, и определите, как система должна реагировать на эти условия. Кроме того, опишите, как система должна реагировать в случае сбоя при выполнении варианта использования по какой-то непредвиденной причине. Пронумеруйте каждое исключение, используя ID прецедента в качестве префикса, затем «EX» для обозначения «Exception». Пример: XYEX.1.

Включает в себя

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

Специальные требования

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

Предположения

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

Примечания и проблемы

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

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

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

Источник: coderlessons.com

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

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

Происхождение варианта использования

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

• В 1986 году Ивар Якобсон впервые сформулировал методы текстового и визуального моделирования для определения вариантов использования.
• В 1992 году его соавторская книга « Объектно-ориентированная разработка программного обеспечения — подход, основанный на прецедентах» помогла популяризировать метод определения функциональных требований, особенно при разработке программного обеспечения.

Диаграмма вариантов использования

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

• Укажите контекст системы
• Зафиксируйте требования системы
• Проверка системной архитектуры
• Управляйте внедрением и создавайте тестовые примеры
• Разработано аналитиками совместно с экспертами в предметной области

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

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

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

Вариант использования (или набор вариантов использования) имеет следующие характеристики:

1. Организует функциональные требования
2. Моделирует цели взаимодействия системы/актора (пользователя)
3. Описывает один основной поток событий (основные сценарии) и, возможно, другие исключительные потоки (альтернативы), также называемые путями или пользовательскими сценариями.

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

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

Актер

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

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

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

Отношение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Использование шаблона заявки — пример заявки на снятие денег в банкомате

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

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

Если вы хотите рисовать случайные диаграммы случаев, Visual Paradigm Online будет вашим лучшим выбором. Поскольку это абсолютно бесплатно навсегда, без ограничений, без установки и настройки.

Вы также можете использовать Visual Paradigm Community Edition , это также бесплатно для создания вариантов использования для различных платформ.

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

Если вы хотите выполнить и разработать моделирование вариантов использования, вам рекомендуется использовать платную версию Visual Paradigm , которая позволяет разработать правильную и полную спецификацию вариантов использования, как указано выше.

Сделай сам прямо сейчас с Visual Paradigm Online

Попробуйте сейчас и получайте удовольствие от всех этих готовых к редактированию примеров и шаблонов, перечисленных ниже:

Источник: www.cybermedian.com