Uml диаграмма сценариев использования

Это первая статья из цикла про методологию ICONIX, посвящена UML-диаграммам вариантов использования. В публикациях и книгах по ICONIX, use-case диаграммы обычно описываются очень бегло, а в книгах по UML — слишком подробно. Я постараюсь сделать это настолько подробно, чтобы можно было приступить к использованию диаграмм, но при этом не было скучно. Важно, что до тех пор, до знакомства с ICONIX я не считал use-case диаграммы хоть сколько-нибудь полезными, поэтому в статье я попробую сконцентрироваться на том, что они могут принести проекту.

Вне зависимости от методологии разработки, которую вы применяете, первым этапом разработки будет являться формулировка требований к продукту (Градди Буч описывает Rational Unified Process [1], а Розенберг — ICONIX [2]). Набор требований к продукту представляет собой техническое задание, при этом требования делятся на функциональные (то, что система позволяет сделать, желаемая функциональность) и нефункциональные (требования к оборудованию, операционной системе и т.п.). В языке UML для формализации функциональных требований применяются диаграммы использования.

Диаграмму вариантов использования есть смысл строить во время изучения технического задания, она состоит из графической диаграммы, описывающей действующие лица и прецеденты, а также спецификации, представляющего собой текстовое описание конкретных последовательностей действий (потока событий), которые выполняет пользователь при работе с системой. Спецификация затем станет основой для тестирования и документации, а на следующих этапах проектирования она дополняется и оформляется в виде диаграммы (в рамках ICONIX используется диаграмма последовательности, но в UML для этого имеются также диаграммы деятельности). Кроме того, use-case диаграмма достаточно проста, чтобы ее мог понять заказчик, следовательно вы можете использовать ее для согласования ТЗ (ведь диаграмма описывает функциональные требования к системе).

На диаграмме использования изображаются:

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

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

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

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

Рассмотрим разработку диаграмм вариантов использования на примере — пусть заказчик дал нам следующее техническое задание:

Цель — развитие у детей математических навыков.
Платформа: Linux, Windows, Android.
Функциональность:

для учеников:

выбор подготовленного учителем блока заданий;

выполнение заданий;

для учителя:

подготовка для учеников блоков заданий;

добавление в систему ученика;

просмотр отчетов.

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

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

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

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

Название прецедента: регистрация ученика

Действующее лицо: учитель

Цель: добавить ученика в систему, получив его пароль

Предусловия: учитель осуществил вход в систему

Главная последовательность:

учитель выбирает в главном меню пункт «добавить ученика«;

система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;

учитель вводит желаемый логин и пароль ученика, нажимает кнопку «далее»;

система добавляет ученика;

учителю открывается главное меню и в течении 5 секунд выводится уведомление о том, что ученик был добавлен успешно.

Альтернативная последовательность (возврат в главное меню без добавления ученика):

учитель выбирает в главном меню пункт «добавить ученика«;

система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;

учитель нажимает кнопку «назад»;

учителю открывается главное меню (при этом данные, введенные в формы окна добавления ученика не сохраняются).

Альтернативная последовательность (добавление ученика, уже имеющегося в системе):

учитель выбирает в главном меню пункт «добавить ученика«;

система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;

учитель вводит желаемый логин и пароль ученика, нажимает кнопку «далее»;

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

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

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

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

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

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

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

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

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

нефункциональные требования к системе (при этом используется стереотип <<requirement>>);
сценарии вариантов использования (связывая комментарий с соответствующим прецедентом);
детали реализации и другие выводы, к которым разработчики пришли в процессе обсуждения задачи (не все с этим согласны, т.к. use-case диаграмма показывается заказчику, которому не нужны детали).

Наиболее типичными ошибками при построении этого вида диаграмм являются:

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

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

Стоит отметить, что нет единого мнения по поводу использования в текстах сценария условных операторов или циклов. Ряд аналитиков считают, что наличие слов типа «если» в сценарии является ошибкой, которая исправляется добавлением альтернативной последовательности. Другие — допускают использование 1-2 ветвлений в сценарии, при этом отмечают, что такой подход улучшает читабельность сценариев.

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

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

Буч Градди Объектно-ориентированный анализ и проектирование с примерами приложений, 3-е изд. / Буч Градди, Максимчук Роберт А., Энгл Майкл У., Янг Бобби Дж., Коналлен Джим, Хьюстон Келли А.: Пер с англ. – М.: ООО “И.Д. Вильямс”, 2010. – 720 с.
Розенберг Д., Скотт К. Применение объектного моделирования с использованием UML и анализ прецедентов.: Пер. с англ. М.: ДМК Пресс, 2002
Бабич А. В. Введение в UML // Интернет университет информационных технологий. 2008. URL: http://www.intuit.ru/studies/courses/1007/229/info (дата обращения: 19.03.2016).
Леоненков, A.B. Объектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose: учеб. пособие Текст. / A.B. Леоненков. М.: Интернет-Ун-т информ. технологий: БИНОМ, Лаборатория знаний, 2006. — 320 с.

Источник

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

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

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

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

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

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

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

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

Актеры

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

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

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

Люди против нечеловеческих актеров

Время от времени на систему воздействуют различные события для выполнения определенных функций в той или иной ситуации. Например, при прохождении аудита система заранее отправляет письмо, чтобы уведомить людей; так отправка письма осуществляется системой автоматически? Этот вариант использования на самом деле запускается по времени, тогда действующим лицом является Таймер; например, этот вариант использования можно рассматривать как «автоматически отправлять письмо в 5:00 каждый день», тогда актор, который запускает это событие — отправку письма — не система, а на самом деле актор-таймер

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

A primary actor is an actor that uses the system to achieve a goal. Use cases document the interactions between the system and actors to achieve the goals of the primary actor. Secondary actors are the actors that the system needs to assist in order to achieve the goals of the primary actor.
- Actors may be primary or secondary. Primary actors initiate interactions with the system.
- Secondary actors are typically called upon by the system for help and a secondary actor never initiates the use case.
Note that: The symbol for an actor does not differentiate between a primary actor and a secondary actor; the difference must be inferred from the use case descriptions (also called use case narratives).

For Example:

A bank loan officer wants to review a customer’s loan application, and part of the process involves a real-time credit rating check.

ИЗМЕНИТЬ ЭТОТ ПРИМЕР ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ
- Используйте имя дела. Рассмотреть заявку на кредит
- Главный актер. Кредитный специалист
- Второстепенный актер. Система кредитного рейтинга
Как определить актеров?

Поскольку действующее лицо не обязательно является человеком, а может быть внешней системой, устройством или таймером, мы находим более конкретное действующее лицо, задавая следующие вопросы.
- Кто будет использовать систему после ее разработки?
- От кого или от каких других систем система должна будет получать данные?
- Для кого или для каких других систем система будет предоставлять данные?
- С какими другими системами будет связана система?
- Кто будет поддерживать и администрировать систему?
Эти вопросы помогают нам абстрагироваться от действующих лиц системы. Используя банкоматы в качестве примера, ответы на эти вопросы позволяют нам найти больше действующих лиц, т.е.
- Оператор несет ответственность за техническое обслуживание и управление системой банкоматов.
- Банкоматы также должны взаимодействовать с внутренними серверами для получения информации об учетных записях пользователей.
Вариант использования

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

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

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

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

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

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

Границы системы описывают систему, группируя варианты использования в прямоугольные границы, а границы системы в Visual Paradigm обеспечивают поведение ограничения вариантов использования.

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

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

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

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

Отношение

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

Вариант использования можно разбить на несколько вариантов использования, которые связаны отношениями <<включить>>, <<расширить>> или <<обобщить>> (описано далее в этом посте).

Связь канала связи

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

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

<<Включить>> Связь

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

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

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

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

<<Расширить>> отношения

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

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

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

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

Отношение обобщения

Обобщенное отношение похоже на обобщенное отношение объектно-ориентированного языка на диаграммах классов и может применяться к обобщению ролей (акторов) и вариантов использования.

Например, в системе бронирования есть два типа методов бронирования: «забронировать билет по телефону» и «забронировать билет через Интернет», а также базовый вариант использования «забронировать билет», поэтому вы можете использовать обобщение для формирования случая, и добавьте <<essential>> к родительскому варианту использования (бронирование), чтобы указать обобщенную связь.

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

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

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

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

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

Например, кейс «Снятие денег» в банкомате можно представить потоком событий следующим образом:

Обычный сценарий – вывод средств – основной ход событий:
1. Пользователь вставляет кредитную карту
2. Введите PIN-код
3. Введите сумму вывода
4. Снимает наличные
5. Выйдите из системы и получите кредитную карту
Но это описывает только обычный сценарий использования вывода средств. Как реальная система банкоматов, мы также должны учитывать различные другие сценарии, которые могут возникнуть, такие как:
- недействительные кредитные карты,
- неправильные пароли,
- недостаточный остаток денежных средств на счету пользователя и т. д.
Все эти возможные ситуации (как нормальные, так и нештатные) называются сценариями варианта использования, а сценарии также называются экземплярами варианта использования. Сценарии также называют экземплярами вариантов использования. Среди различных сценариев варианта использования наиболее распространенный сценарий описывается базовым процессом, тогда как другие сценарии описываются альтернативными процессами.

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

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

Снятие – альтернативные процессы событий.
1. Альтернативный сценарий I: Пользователь может отказаться на любом шаге основного процесса и перейти к шагу 5 основного процесса.
2. Альтернативный процесс II: на шаге 1 основного процесса пользователь вставляет недействительную кредитную карту, система отображает ошибку и закрывает кредитную карту, и вариант использования заканчивается.
3. Альтернативный процесс III: на шаге 2 основного процесса пользователь вводит неверный пароль, система отображает ошибку и предлагает пользователю повторно ввести пароль и вернуться к шагу 2 основного процесса; после трех неправильных вводов пароля кредитная карта конфискуется системой, и вариант использования заканчивается.
4. …
Комбинируя базовый сценарий и альтернативные сценарии, можно четко описать все различные ситуации, которые могут возникнуть в прецеденте. При описании потока событий варианта использования мы хотим максимально подробно описать все возможные сценарии, чтобы обеспечить полноту требований.

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

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

Модель вариантов использования состоит из диаграммы вариантов использования и подробного описания каждого варианта использования, спецификации варианта использования, которая предоставляется в виде шаблона в RUP.

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

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

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

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

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

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

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

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

Онлайн-версия

Бесплатная версия бесплатного инструмента для рисования Visual Paradigm Online (VP Online) поддерживает UML, ERD и организационные диаграммы. Вы можете быстро нарисовать диаграммы вариантов использования с помощью интуитивно понятного редактора чертежей UML. В этом бесплатном инструменте UML нет рекламы, нет ограниченного периода доступа и нет ограничений, таких как количество диаграмм, количество фигур и т. д. Рисуйте UML свободно. Рисуйте UML свободно. вам принадлежат диаграммы, которые вы создаете для личных и некоммерческих целей.

Настольная версия

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

использованная литература
- Что такое диаграмма вариантов использования?
- Типы актеров в модели вариантов использования
- Определите требования пользователя с помощью диаграмм вариантов использования
- Что такое спецификация варианта использования?
- История пользователя и вариант использования для гибкой разработки программного обеспечения
- Используйте подход, основанный на прецедентах, для гибкой разработки
UML-ресурсы
- Что такое УМЛ?
- Почему UML-моделирование?
- Обзор 14 типов диаграмм UML

Источник

Диаграмма прецедентов (вариантов использования или Use Case)

Используемые материалы:

Диаграмма прецедентов (простенько, но не полно)
Более полное описание
Конспект лекции (с видео) от WorldSkills

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

Диаграмма вариантов использования (use case diagram) — диаграмма, на которой изображаются отношения между акторами и вариантами использования (прецедентами).

Актор это калька с английского Actor что расшифровывается как действующее лицо (Act — действие, суффикс -or — человек, осуществляющий действие)

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

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

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

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

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

Базовыми элементами диаграммы вариантов использования являются вариант использования и актор.

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

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

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

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

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

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

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

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

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

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

Имя актора должно быть достаточно информативным с точки зрения семантики. Для этой цели подходят наименования должностей в компании (например, Продавец, Кассир, Менеджер, Президент).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разбор скринкаста семинара «Системный анализ и проектирование»

Текст задания:

Пользователь устанавливает приложение и регистрируется, указав ФИО и лицевой счёт, пароль. Так же пользователь может прикрепить данные банковской карты для быстрой оплаты, но не обязательно.

Работа возможна только для авторизованного пользователя.

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

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

В Visio создаёте новый документ и открываете Дополнительные фигуры -> Программы и базы данных -> Программное обеспечение -> Сценарии выполнения UML

Цвет моих диаграмм отличается от сделанных в Visio, т.к. я делаю в visual-paradigm онлайн

Порядок работы:

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

Рисуем прямоугольник подсистемы:
Определяем акторов

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

Обратите внимание: связи между акторами и прецедентами прямые и рисуются без всяких стрелок
- установка приложения — такой вариант использования есть в описании предметной области, но т.к. он не относится к подсистеме, то его рисуем за пределами подсистемы
- у обычного пользователя есть только один вариант использования: регистрация
  
  Но при регистрации возникают дополнительные действия (прецеденты): ввод ФИО, лицевого счёта и пароля, и не обязательный ввод данных карты.
  
  Для обязательных прецедентов используется отношение включения, для не обязательных — расширения
- оплата услуг авторизованным пользователем. Причём пользователь должен внести показания прибора учета. И может запросить отчет с возможным выбором периода
  
  После ввода показаний прибора учёта пользователь должен подтвердить оплату (обязательное действие, поэтому делаем включение). Если карта не была привязана в личном кабинете, то добавляем через включение действие ввод данных карты. Visio не полностью реализует стандарт UML — для альтернативных действий там есть специальные формы прецедентов. Но можно альтернативность прецедента акцентировать надписью на стрелке (тип ассоциации и так понятен по направлению стрелки)
  
  После подтверждения оплаты система генерирует квитанцию (делает это всегда, поэтому включение). Действия пользователя в этом случае не описаны, но т.к. сказано, что система не хранит квитанции, то напрашивается расширение для сохранения квитанции
- после всего вспомнили, что обычному пользователю для превращения в авторизованного нужно авторизоваться и, хотя этого нет в описании предметной области, добавляем этот прецедент:

Итоговый вариант диаграммы прецедентов:

Задание для самостоятельной работы:

Программа для фитнес-центра по распределению фитнес – расписания и контроля его соблюдения

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

Клиенты могут зарегистрироваться в системе, указав ФИО, телефон, пароль, дату рождения, фото профиля, пол.

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

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

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

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

Тренер также может посмотреть список своих текущих клиентов с указанием у каждого: проценты выполнения всего цикла тренировок (зависит от длительности цикла) и процента выполненных упражнений (т.к. некоторые упражнения могут быть пропущены). По каждому клиенту выводится средний показатель пульса во время выполнения упражнений.

Источник

What is a Use Case Diagram in UML?

A use case is a list of actions or event steps typically defining the interactions between a role of an actor and a system to achieve a goal. A use case is a useful technique for identifying, clarifying, and organizing system requirements. A use case is made up of a set of possible sequences of interactions between systems and users that defines the features to be implemented and the resolution of any errors that may be encountered.

While a use case itself might drill into a lot of detail (such as, flow of events and scenarios) about every possibility, a use-case diagram can help provide a higher-level view of the system, providing the simplified and graphical representation of what the system must actually do.

A use case (or set of use cases) has these characteristics:

Organizes functional requirements
Models the goals of system/actor (user) interactions
Describes one main flow of events (main scenarios) and possibly other exceptional flows (alternatives), also called paths or user scenarios

Try it!

Finding an online Use Case Diagram tool? Just click the Draw button below to create your Use Case Diagram online. Visual Paradigm Online is free^* and intuitive. You can also go through this Use Case Diagram tutorial to learn about Use Case Diagram before you get started.

Draw Now

Use Case Diagram Notations

Use cases define interactions between external actors and the system to attain particular goals. A use case diagram contains four main components

Actor

Actors are usually individuals involved with the system defined according to their roles. The actor can be a human or other external system.

Use Case

A use case describes how actors uses a system to accomplish a particular goal. Use cases are typically initiated by a user to fulfill goals describing the activities and variants involved in attaining the goal.

Relationship

The relationships between and among the actors and the use cases.

System Boundary

The system boundary defines the system of interest in relation to the world around it.

Benefits of Use Case Diagram

Use cases is a powerful technique for the elicitation and documentation of black-box functional requirements.
Because, use cases are easy to understand and provide an excellent way for communicating with customers and users as they are written in natural language.
Use cases can help manage the complexity of large projects by partitioning the problem into major user features (i.e., use cases) and by specifying applications from the users’ perspective.
A use case scenario, often represented by a sequence diagram, involves the collaboration of multiple objects and classes, use cases help identify the messages (operations and the information or data required — parameters) that glue the objects and classes together.
Use cases provide a good basis to link between the verification of the higher-level models (i.e. interaction between actors and a set of collaborative objects), and subsequently, for the validation of the functional requirements (i.e. blueprint of white-box test).
Use case driven approach provides an traceable links for project tracking in which the key development activities such as the use cases implemented, tested, and delivered fulfilling the goals and objectives from the user point of views.

How to Draw a Use Case Diagram?

A Use Case model can be developed by following the steps below.

Identify the Actors (role of users) of the system.
For each category of users, identify all roles played by the users relevant to the system.
Identify what are the users required the system to be performed to achieve these goals.
Create use cases for every goal.
Structure the use cases.
Prioritize, review, estimate and validate the users.

Note that: to make use case approach more «Agile», do not detail all use cases, but prioritize them in your product backlog, you should refine the use case in different level of details according to the development phase with just-in-time and just-enough manner.

You can also:

Draw packages for logical categorization of use cases into related subsystems.

Structuring Use Cases

UML defines three stereotypes of association between Use Cases:

<<include>> Use Case

The time to use the <<include>> relationship is after you have completed the first cut description of all your main Use Cases. You can now look at the Use Cases and identify common sequences of user-system interaction.

<<extend>> Use Case

An extending use case is, effectively, an alternate course of the base use case. The <<extend>> use case accomplishes this by conceptually inserting additional action sequences into the base use-case sequence.

Abstract and generalized Use Case

The general use case is abstract. It can not be instantiated, as it contains incomplete information. The title of an abstract use case is shown in italics.

Example

This example depicts a model of several business use cases (goals) which represents the interactions between a restaurant (the business system) and its primary actors.

After the base use cases have been identified in the first cut, perhaps we could further structuring those use case with <<extend>> and <<include>> use cases in the second round touch up as shown in the Figure below:

Business Use Case

A business use case is described in technology-free terminology which treats the business process as a black box and describes the business process that is used by its business actors, while an ordinary use case is normally described at the system functionality level and specifies the function or the service that the system provides for the user. In other words, business use case represents how the work to be done manually in the currently situation and it is not necessarily done by the system or intend to be automated in the scope of target system.

Use Case Diagram Examples

The figure below shows an ATM use case diagram example, which is quite a classic example to use in teaching use case diagram.

The Document Management System (DMS) use case diagram example below shows the actors and use cases of the system. In particular, there are include and extend relationships among use cases.

The Order System use case diagram example below shows the actors and use cases involved in the system:

Want to draw a Use Case Diagram?

You’ve learned what a Use Case Diagram is and how to draw a Use Case Diagram step-by-step. It’s time to get your hands dirty by drawing a Use Case Diagram of your own. Draw UML diagrams free^* with Visual Paradigm Online. It’s easy-to-use, intuitive.

Draw Now

* The Free edition supports free usage of Visual Paradigm Online for non-commercial use only.

Источник

Диаграммы использования были предложены Иваром
Якобсоном в их нынешней графической форме еще в 1986 году. Диаграммы использования являются, безусловно,
самым стабильным элементом UML — они не менялись уже двадцать лет с лишним, фактически, приняли законченную
форму задолго до появления языка. Одновременно эти диаграммы имеют самую простую нотацию: всего два основных
типа сущностей (действующие лица и варианты использования) и три типа отношений (зависимости, ассоциации,
обобщения)!

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

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

Роль (role) в UML — это интерфейс (interface)^∇, поддерживаемый данным классификатором
(classifier) в данной ассоциации (assocation).

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

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

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

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

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

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

менеджер персонала, который работает с конкретными людьми;
менеджер штатного расписания, который работает с абстрактными должностями и подразделениями.

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

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

На следующем фрагменте диаграммы использования мы начинаем формировать представление использования
информационной системы отдела кадров. Менеджер персонала имеет имя Personnel Manager, а менеджер штатного расписания — Staff Manager, в
соответствии с используемой дисциплиной имен.

Рис. Действующие лица ИС ОК

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

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

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

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

Каждая конкретная последовательность действий называется сценарием (scenario).

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

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

В нашем примере простой анализ текста технического задания (приведенного в разделе
2.1.1) выявляет семь вариантов использования:

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

Опираясь на знание предметной области, которое не отражено в техническом задании (характерный случай),
заметим, что термин «вакансия» является сокращением оборота «вакантная должность», то есть должность в
некотором особом состоянии. Само же слово «должность» многозначно. Это может быть и обозначение
конкретного рабочего места — позиции в штатном расписании, и обозначение совокупности таких позиций,
имеющих общие признаки: функциональные обязанности, зарплата и т. п. Например: «в организации
различаются должности: программист, аналитик, руководитель проекта» или «в отделе разработки
предусмотрены следующие должности: 9 программистов, 3 аналитика и 2 руководителя проектов». Кадровые
работники легко различают эти случаи по контексту. Примем рабочую гипотезу о том, что автор технического
задания использовал слово должность в первом смысле и получим набор вариантов использования,
представленный на следующем рисунке.

Рис. Варианты использования ИС ОК

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

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

Комментарий содержит текст, который вводит пользователь — создатель модели. Это может быть текст в
произвольном формате: на естественном языке, на языке программирования, на формальном логическом языке,
например, OCL и т. д. Более того, если возможности инструмента это позволяют, в примечаниях можно
хранить гиперссылки, вложенные файлы и другие артефакты, внешние по отношению к модели.

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

Комментарии могут иметь стереотипы. В UML определены два стандартных стереотипа для комментариев:

«requirement» — описывает общее требование к системе;
«responsibility» — описывает ответственность сущности (классификатора).

Комментарии первого стереотипа часто присутствуют на диаграммах использования, а комментарии второго
стереотипа — на диаграммах классов.

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

Рис. Нефункциональное требование к ИС ОК

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

ассоциация между действующим лицом и вариантом использования;
обобщение между действующими лицами;
обобщение между вариантами использования;
зависимости между вариантами использования;

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

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

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

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

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

Такое обобщение является весьма мощным средством моделирования.

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

ИЗМЕНЕНИЯ В ТЕХНИЧЕСКОМ ЗАДАНИИ

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

Это изменение в требованиях можно отразить в модели системы так, как показано ниже.

Рис. Иерархия категорий пользователей ИС ОК

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

ИЗМЕНЕНИЯ В ТЕХНИЧЕСКОМ ЗАДАНИИ

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

Данное требование следует оформить в виде дополнительного варианта использования ‒ Browse. Если мы проектируем систему отдела кадров для обычной организации, а не
для государственной секретной службы, то разумно предположить, что просматривать данные могут все
категории пользователей. В этом случае можно установить ассоциации между новым вариантом использования и
всеми действующими лицами, а можно поступить так, как показано следующем рисунке, т.е. ввести
обобщенного абстрактного пользователя User 1,
который будет связан ассоциацией с вариантом использования Browse 2. При этом все специализации 3 и
4 обобщенного пользователя автоматически будут связаны ассоциацией с
вариантом использования Browse.

Рис. Абстрактное действующее лицо

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

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

ИЗМЕНЕНИЯ В ТЕХНИЧЕСКОМ ЗАДАНИИ

Система должна поддерживать два способа увольнения сотрудника: по инициативе администрации и по собственному желанию.

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

Рис. Обобщение вариантов использования

Обобщенный абстрактный (имя написано курсивом) вариант использования Fire Person имеет две специализации, которые соответствуют увольнению работника по собственному
желанию Self Fire и по инициативе администрации Adm Fire.

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

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

«include» — показывает, что в каждый сценарий
зависимого варианта использования в определенном месте вставляется в качестве подпоследовательности
действий в сценарий независимого варианта использования.
«extend» — показывает, что в некоторый сценарий
независимого варианта использования может быть в определенном месте вставлен в
качестве подпоследовательности действий сценарий зависимого варианта использования. Другой вариант
интерпретации: в определенном месте сценария независимого варианта использования вызывается для
выполнения сценарий зависимого варианта использования. При этом последовательность действий в
вызываемом сценарии определяется местом, откуда он был вызван, т.е. из какого варианта использования
и конкретно из какого места какого сценария этого варианта использования.

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

ИЗМЕНЕНИЯ В ТЕХНИЧЕСКОМ ЗАДАНИИ

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

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

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

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

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

Рис. Комбинация отношений обобщения и зависимости

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

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

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

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

Внутренняя часть, выделяемая границами, имеет в UML конкретное название ‒ субъект.

Субъект (subject) — это классификатор, который реализует поведение, декларируемое
вариантами использования.

Если границы системы используются на диаграмме, то можно указать имя (и стереотип!), которые будут
относиться к субъекту^∇.

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

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

В приведенных примерах действующими лицами являются категории пользователей. Это не случайно, в
большинстве случаев действующими лицами в моделях UML действительно являются категории пользователей. Но
оборот «в большинстве случаев» еще не означает «всегда». В самом деле, в определениях действующего лица
(параграф 2.2.1) и варианта использования (параграф
2.2.2) ничто не указывает на ограничения в применении этих понятий. Выше мы отметили, что
варианты использования описывают внутренность системы, а действующие лица ‒ ее окружение. Так вот,
в качестве системы может выступать любая сущность, для которой можно определить функциональные
или не функциональные требования. Это может быть и подсистема главной системы, отдельный
компонент и просто класс. Если мы рассматриваем модель использования некоторой подсистемы, то другие
подсистемы (взаимодействующие с рассматриваемой) будут действующими лицами для рассматриваемой
подсистемы. Если мы рассматриваем модель использования некоторого класса, то другие классы
(взаимодействующие с рассматриваемым) будут действующими лицами для рассматриваемого класса.

Рассмотрим пример, связанный с взаимодействием нашей информационной системы отдела кадров с внешним
программным окружением.

ИЗМЕНЕНИЯ В ТЕХНИЧЕСКОМ ЗАДАНИИ

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

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

На следующей диаграмме действующее лицо ИС ОК ‒ это наша информационная
система отдела кадров, действующее лицо ERP ‒ некоторая другая
информационная система, а Adapter ‒ модуль с единственным вариантом
использования. Обратите внимание, что на этой диаграмме все сущности ‒ программные системы, никаких
пользователей здесь нет!

Рис. Программные системы в качестве действующих лиц

Источник

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

Важность использования диаграммы прецедентов
Объекты диаграммы прецедентов
Рекомендации по диаграммам прецедентов
Отношения в диаграммах вариантов использования
Как создавать диаграммы вариантов использования ( с примером )
- идентификация актеров
- Определение вариантов использования
- Когда использовать “Включить”
- Как использовать обобщение
- Когда использовать «Расширить»
Шаблоны диаграмм вариантов использования для распространенных сценариев

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

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

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

Объекты диаграммы прецедентов

Использовать диаграммы корпуса состоят из 4 объектов.

Актер
Случай использования
Система
Пакет

Объекты более подробно описаны ниже.

Актер

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

Случай использования

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

Система

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

Пакет

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

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

Существует пять типов отношений на диаграмме прецедентов. Они

Ассоциация между актером и случаем использования
Обобщение актера
Расширить отношения между двумя случаями использования
Включить взаимосвязь между двумя случаями использования
Обобщение случая использования

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

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

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

Выявление актеров

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

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

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

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

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

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

Ищите общие функциональные возможности для использования Включать

Ищите общие функциональные возможности, которые могут быть повторно использованы в системе. Если вы найдете два или более случаев использования, которые имеют общую функциональность, вы можете извлечь общие функции и добавить его в отдельный случай использования. Затем вы можете подключить его через include relationship, чтобы показать, что он всегда вызывается, когда выполняется исходный сценарий использования. ( см. диаграмму для примера ).

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

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

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

Необязательные функции или дополнительные функции

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

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

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

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

Шаблон варианта прецедентов для системы банкомата

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

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

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

Больше руководств по диаграммам

Учебное пособие по диаграммам последовательностей: полное руководство с примерами
Учебное пособие по моделированию бизнес-процессов (руководство по BPM с объяснением функций)
Окончательное руководство по блок-схеме (полное руководство по блок-схеме с примерами)

Источник

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

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

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

Актеры

Люди против нечеловеческих актеров

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

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

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

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

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

Отношение

Связь канала связи

<<Включить>> Связь

<<Расширить>> отношения

Отношение обобщения

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

Вариант использования — поток событий

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

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

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

UML-ресурсы

Диаграмма прецедентов (вариантов использования или Use Case)

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

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

Разбор скринкаста семинара «Системный анализ и проектирование»

Задание для самостоятельной работы:

What is a Use Case Diagram in UML?

Try it!

Use Case Diagram Notations

Actor

Use Case

Relationship

System Boundary

Benefits of Use Case Diagram

How to Draw a Use Case Diagram?

Structuring Use Cases

<<include>> Use Case

<<extend>> Use Case

Abstract and generalized Use Case

Business Use Case

Use Case Diagram Examples

Want to draw a Use Case Diagram?

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

Объекты диаграммы прецедентов

Актер

Случай использования

Система

Пакет

Рекомендации по диаграммам прецедентов

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

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

Выявление актеров

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

Ищите общие функциональные возможности для использования Включать

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

Необязательные функции или дополнительные функции

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

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

Больше руководств по диаграммам