Файл: Диаграммы вариантов использования 1 Диаграммы вариантов использования 1.docx

Оглавление

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

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

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



Рисунок 1 - пример Диаграммы вариантов использования

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

---

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

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

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

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



Рисунок 2 - пример Вариантов использования

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

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

Актер

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



Рисунок 3 - пример Актера

---

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



Рисунок 4 - пример Диаграммы вариантов использования

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

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

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

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



Рисунок 5 - пример отношения ассоциации

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

---

Рисунок 6 - пример отношения включения

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



Рисунок 7 - пример отношения расширения

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



Рисунок 8 - пример отношения обобщения

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

Диаграммы классов

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

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

---

Рисунок 9 - пример Диаграммы классов

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

• 
  имя класса
  
• 
  атрибуты (свойства) класса
  
• 
  операции (методы) класса
  

Рисунок 10 - пример класса

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

• 
  - — private (частный)
  
• 
  # — protected (защищенный)
  
• 
  + — public (общий)
  

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

Операция (метод) – это реализация метода класса. Класс может иметь любое число операций либо не иметь ни одной. Часто вызов операции объекта изменяет его атрибуты.
Графически операции представлены в нижнем блоке описания класса.

Типы связей в UML

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



Рисунок 11 - пример связи зависимости

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



Рисунок 12 - пример связи ассоциация

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

---