|
|
@@ -0,0 +1,116 @@
|
|
|
+# Диаграмма прецедентов (вариантов использования или Use Case)
|
|
|
+
|
|
|
+Используемые материалы:
|
|
|
+
|
|
|
+* [Диаграмма прецедентов (простенько, но не полно)](https://planerka.info/item/diagramma-precedentov-variantov-ispolzovaniya-uml/)
|
|
|
+* [Более полное описание](https://intuit.ru/studies/courses/32/32/lecture/1004)
|
|
|
+
|
|
|
+## Диаграмма вариантов использования, общие понятия
|
|
|
+
|
|
|
+**Диаграмма вариантов использования** (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>>.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+В нашем случае, при оплате в магазине доступны оба расширения, а при оплате на сайте только оплата картой (на самом деле второй вариант сложнее: нужно выделить отдельный прецедент "онлайн оплата" с расширениями "оплата картой", "оплата при получении" и т.п.)
|
|
|
+
|
|
|
+Два и более актора могут иметь общие свойства, т.е. взаимодействовать с одним и тем же множеством вариантов использования одинаковым образом. Такая общность свойств и поведения представляется в виде **отношения обобщения** с другим, возможно, абстрактным актором, который моделирует соответствующую общность ролей.
|
|
|
+
|
|
|
+Графически *отношение обобщения* обозначается сплошной линией со стрелкой в форме незакрашенного треугольника, которая указывает на родительский вариант использования.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Рассматривая наш магазин при автосервисе, мы можем применить обобщение для закупок запчастей при тех.обслуживании автомобиля. Понятно, что делает это не клиент, а внутренняя служба, которая потом просто выставляет счёт со списком запчастей (и это еще один прецедент к варианту оплаты).
|
|
|
+
|
|
|
+**Границы проектируемой системы**. В начале лекции про них упоминалось - прямоугольник, который ограничивает проектируемкю модель (т.е. наши варианты использования). Еще раз обращаю внимание, акторы не входят в модель и рисуются на пределами системы.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+НИ В КОЕМ СЛУЧАЕ НЕ ИСПОЛЬЗУЙТЕ ЭТУ ДИАГРАММУ КАК ПРИМЕР ДЛЯ ПОДРАЖАНИЯ. Это первый "сырой" вариант, как минимум автосервис нужно выносить в отдельную подсистему и *прецедент* "покупка запчастей" инициируется менеджером автосервиса, а не сам по себе.
|
|
|
+
|
|
|
+Мы рассмотрели только базовые элементы для диаграммы вариантов использования, на самом деле их больше. Но для нашего уровня обучения этого достаточно.
|
|
|
+
|
Евгений Колесников