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

от наиболее обшей и абстрактной концептуальной модели исходной системы к

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

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

20.10.2014

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

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

20.10.2014

или актеров, взаимодействующих с системой с помощью так называемых вариантов

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

20.10.2014

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

интерфейсов, и отношений между этими элементами.

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

20.10.2014

или рядом с ним содержится его краткое название или имя

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

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

20.10.2014

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

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

20.10.2014

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

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

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

20.10.2014

или отдельные классы.
Каждый актер определяет некоторое согласованное множество ролей,

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

20.10.2014

без указания их внутренней структуры.
В языке UML интерфейс является

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

20.10.2014

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

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

20.10.2014

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

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

20.10.2014

с актерами за пределами системы.
В языке UML имеется несколько стандартных

видов отношений между актерами и вариантами использования:
Отношение ассоциации (association relationship)
Отношение расширения (extend relationship)
Отношение обобщения (generalization relationship)
Отношение включения (include relationship)

20.10.2014

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

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

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

20.10.2014

более общим вариантом, свойства которого определяются на основе способа совместного

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

20.10.2014

вариант использования А может быть обобщен до варианта использования В.

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

20.10.2014

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

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

20.10.2014

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

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

20.10.2014

на покупку товара" может быть уточнен на основе введения в

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

20.10.2014

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

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

20.10.2014

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

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

20.10.2014