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

Почему не рекомендуется подробная детализация диаграмм прецедентов

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

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

Рубрика Программирование, компьютеры и кибернетика
Вид лабораторная работа
Язык русский
Дата добавления 10.03.2014
Размер файла 672,2 K
  • посмотреть текст работы
  • скачать работу можно здесь
  • полная информация о работе
  • весь список подобных работ

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Диаграммы прецедентов (вариантов использования)
Цель работы: построить диаграмму прецедентов (use case diagram)

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

Диаграмма вариантов использования (use case diagram)

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

Реализация варианта использования зависит от типа элемента модели, в котором он определен. Например, поскольку варианты использования класса определяются посредством операций этого класса, они реализуются соответствующими методами. С другой стороны, варианты использования подсистемы реализуются элементами, из которых состоит данная подсистема. Поскольку подсистема не имеет своего собственного поведения, все предлагаемые подсистемой сервисы должны представлять собой композицию сервисов, предлагаемых отдельными элементами этой подсистемы, т. е., в конечном итоге, классами. Эти элементы могут взаимодействовать друг с другом для совместного обеспечения требуемого поведения отдельного варианта использования. Такое совместное обеспечение требуемого поведения описывается специальным элементом языка UML — кооперация или сотрудничество, который будет рассмотрен в главе 9, посвященной построению диаграмм кооперации. Здесь лишь отметим, что кооперации используются как для уточнения спецификаций в виде вариантов использования нижних уровней диаграммы, так и для описания особенностей их последующей реализации.

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

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

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

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

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

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

Рис. 1. Графическое обозначение варианта использования

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

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

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

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

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

2. Актеры (актанты)

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

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

· только снабжать информацией систему;

· только получать информацию из системы;

· снабжать информацией и получать информацию из системы.

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

Кто заинтересован в определенном системном требовании?

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

Кто получит преимущества от использования системы?

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

Кто будет осуществлять поддержку и обслуживание системы?

Использует ли система внешние ресурсы?

Выступает ли какой-либо участник системы в нескольких ролях?

Выступают ли различные участники в одной роли?

Будет ли новая система взаимодействовать со старой?

В языке UML актант изображается в виде фигуры человечка.

Изображение актанта в языке UML

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

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

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

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

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

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

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

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

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

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

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

· Отношение ассоциации (association relationship)

· Отношение расширения (extend lelationship)

· Отношение обобщения (generalization lelationship)

· Отношение включения (include lelationship)

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

Отношение ассоциации

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

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

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

Примечание

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

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

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

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

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

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

Два символа, разделенные двумя точками. При этом первый из них является целым неотрицательным числом или 0, а второй — специальным символом «*». Здесь символ «*»обозначает произвольное конечное целое неотрицательное число, значение которого неизвестно на момент задания соответствующего отношения ассоциации.

Пример такой формы записи кратности ассоциации — «2.. *». Запись означает, что количество отдельных экземпляров данного компонента, которые могут выступать в качестве элементов данной ассоциации, равно некоторому заранее неизвестному числу из подмножества натуральных чисел: .

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

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

Если кратность отношения ассоциации не указана, то по умолчанию принимается ее значение, равное 1.

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

Отношение расширения

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

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

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

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

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

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

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

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

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

Рис. 4. Пример графического изображения отношения обобщения между вариантами использования

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

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

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

Рис. 5. Пример графического изображения отношения обобщения между актерами

Отношение включения

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

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

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

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

Рис. 6. Пример графического изображения отношения включения между вариантами использования

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 9. Один из вариантов последующего уточнения диаграммы вариантов использования для примера рассматриваемой системы продажи

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

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

Диаграмма прецедентов (она же диаграмма вариантов использования, англ. Use-Case Diagram) — первая диаграмма, которая моделируется средствами языка UML. Диаграмма прецедентов рассматривает корпоративные бизнес-процессы верхнего уровня с внешней точки зрения и позволяет понять, как выглядит деятельность компании «со стороны».

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

Подробное описание элементов графической нотации и типов взаимосвязи см. в подпараграфе 5.5.1 «Представление прецедентов».

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

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

  • • Отсутствует потребность в доскональной детализации прецедентов. Диаграмма прецедентов показывает крупные функциональные блоки, а не описывает подробно всю функциональность системы.
  • • Действия, которые совершаются внутри прецедента, должны составлять неделимую цепочку. Эта цепочка будет детализироваться в последующих диаграммах.
  • • Прецедент не описывает, как именно будет выполняться что-то. Прецедент описывает, ЧТО ИМЕННО будет выполняться.
  • • Элементы диаграммы нужно но возможности располагать без пересечений, а их расположение должно делать интуитивно понятным взаимодействие функциональных блоков.
  • • Диаграмма прецедентов не должна учитывать конкретные варианты реализации ИС, связанные с программной или аппаратной стороной вопроса.

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

Пример диаграммы прецедентов

Рис. 5.17. Пример диаграммы прецедентов

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

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

Квадратной рамкой выделена область автоматизации.

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

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

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

Сегодня мы разберемся с тем, как использовать диаграмму вариантов использования UML (англ. «Unified Modeling Language») – стандартизированный язык моделирования при проектировании программ.

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

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

  • Что будет делать приложение?
  • Кто будет пользоваться этим приложением?

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

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

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

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

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

В этой системе можно выделить следующие группы пользователей:

  • Обучающиеся
  • Преподаватели
  • Классные руководители
  • Заместители директора

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

Каждая из групп пользователей может пользоваться нашей системой по-своему.

  • Смотреть расписание
  • Просматривать свои оценки
  • Размещать материалы для уроков
  • Выставлять оценки в электронный журнал

Классные руководители могут делать все то же самое, что и преподаватели плюс:

  • Составлять расписание родительских собраний

Заместители директора могут:

  • Составлять расписание
  • Публиковать посты с важной информацией

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

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

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

А почему мы описываем так мало возможностей?

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

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

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

Построение диаграммы

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

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

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

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

Так же изобразим актёров для оставшихся групп пользователей:

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

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

Этот эллипс представляет действие

В терминологии UML, этот эллипс называется вариантом использования (англ. «use-case»). В общем случае, вариант использования – набор действий, который может быть использован актёром для взаимодействия с системой.

Связи между элементами

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

Отношение ассоциации (англ. Отношение обобщения (англ. Отношение включения (англ. Отношение расширения (англ.

Отношение ассоциации

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

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

Мы соединили актеров с вариантом использования с помощью сплошной линии без стрелки. Такая линия называется отношением ассоциации.

Отношение ассоциации предназначено только для соединения актёров и вариантов использования. Нет никакого смысла соединять отношением ассоциации двух актёров или два варианта использования.

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

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

Почему отношение ассоциации называется так и не иначе?

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

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

Первая версия диаграммы

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

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

Заметим, что в нашей системе группы пользователей «Преподаватель» и «Классный руководитель» обладают схожими возможностями. Чтобы изобразить это на диаграмме, мы можем пойти одним из трёх путей:

  1. Дублировать варианты использования, чтобы связать их с каждым схожим актёром (очевидно, неудачный вариант).
  2. Соединить каждого актёра со всеми нужными вариантами использования. Это может породить множество пересечений линий, что не самым лучшим образом скажется на читаемости диаграммы.
  3. Показать с помощью одного из видов отношений, что актёры связаны между собой. Это будет означать, что один из них может пользоваться всеми вариантами использования, с которыми соединён другой актёр.

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

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

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

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

Покупка горного и скоростного велосипеда - ЧАСТНЫЙ случай покупки велосипедаФизическое лицо и юридическое лицо можно ОБОБЩИТЬ до обычного покупателя

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

Вернёмся к нашему основному примеру. Изобразим отношение обобщения от актёра «Кл. руководитель» к актёру «Преподаватель».

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

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

Изобразим это на диаграмме. Для этого создадим два варианта использования «Узнать среднюю оценку за некоторый период времени» и «Узнать среднюю оценку по предмету» и соединим их с вариантом использования «Узнать свои оценки» отношением обобщения.

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

Присоединим это к основной диаграмме:

Вторая версия диаграммы

Отношение включения

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

  1. Расписание занятий
  2. Расписание мероприятий
  3. Расписание каникул

Всё это составляется заместителем директора, поэтому покажем это на диаграмме. Для этого будем использовать отношение включения. Отношение включения обозначается пунктирной линией с V-образной стрелкой на конце, над стрелкой добавляется надпись “include”.

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

Когда мы используем отношение включения, мы подразумеваем, что составные варианты использования ОБЯЗАТЕЛЬНО входят в состав общего варианта использования.

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

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

Снова вернёмся к нашему основному примеру.

Составление расписания ВКЛЮЧАЕТ в себя составление расписания занятий, мероприятий, каникул(обязательно)

Как итог, наша диаграмма принимает следующий вид:

Третья версия диаграммы

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

Отношение расширения

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

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

Зачем над пунктирными линиями добавлять надписи “include” и “extend”?

В UML пунктирная линия с V-образной стрелкой, в общем случае, называется отношением зависимости. Для диаграммы вариантов использования выделяют различные виды зависимостей: отношение включения и отношение расширения. Чтобы их различать, над стрелками пунктирной линией пишут “include” и “extend” соответственно.

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

На диаграмме предполагается, что к заказу МОЖЕТ БЫТЬ добавлена картошка фри или соус (необязательно)

Два нижних варианта использования описывают возможные «расширения» для базового варианта использования. Исходя из этого примера, мы можем сделать важное замечание.

Можно сказать, что отношение расширения — это выборочное отношение включения. Если отношение включения обозначает, что элемент обязательно включается в состав другого элемента, то в случае отношения расширения это включение необязательно.

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

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

Расширяем функционал отправки сообщений с помощью функции прикрепления файлов к сообщению (Необязательно прикреплять файл к каждому сообщению)

Как итог, получим такую диаграмму:

Четвёртая версия диаграммы

Вот и всё. Я постарался рассказать вам про все моменты построения диаграммы вариантов использования при проектировании программных систем. В следующем вашем проекте обязательно попробуйте построить данную диаграмму на стадии проектирования. Ваши усилия обязательно окупятся!

Что делать, если я путаюсь в направлении стрелок?

При построении диаграмм UML часто возникает путаница, в какую сторону направлена та или иная стрелка. Это пройдёт после небольшой практики. Общая рекомендация к запоминанию правильного направления стрелок на диаграмме вариантов использования: стрелка обычно направлена от «зависимого» объекта к «независимому» (от специального к общему). Например:

Проектирование программы ЗАВИСИТ от составления функциональных требований, обдумывания функционала программы, выделения групп пользователей ,потому что ВКЛЮЧАЕТ в себя эти этапы

Программист на каждом следующем уровне должности ПЕРЕНИМАЕТ знания с предыдущих уровней, без которых не может развиваться дальше. Получается, что актёры ЗАВИСЯТ от предыдущих ступеней

Тем не менее, в любом правиле есть исключение. Этим исключением является отношение расширение:

Если DLC было куплено, то игра зависит от контента, который содержится в нём. Наше правило

  1. Диаграммы очень просто изменять. Не нужно пугаться того, что требования к программе могут измениться или что вы что-то забыли отобразить на диаграмме. Вы можете добавить элементы к диаграмме, когда вам угодно.
  2. Не нужно засорять диаграмму слишком мелкими действиями. Объедините все общие действия в одну группу под общим названием, чтобы было просто читать диаграмму.
  3. Старайтесь не допускать пересечений соединительных линий. Это может затруднить чтение диаграммы для вас и для ваших коллег.
  4. Не дублируйте варианты использования на диаграмме. Если приходится дублировать варианты использования, то элементы диаграммы надо постараться расставить по-другому.
  5. Пользуйтесь специальными компьютерными программами для построения диаграмм. Это существенно упростит весь процесс моделирования.
  • проектирование
  • моделирование
  • Диаграммы вариантов использования
  • для начинающих
  • uml-проектирование
  • uml
  • uml activity diagram
  • Проектирование и рефакторинг
  • UML Design

695_Poletajkin_A.N._Uchebno-metodicheskoe_posobie_Realizatsija_zhiznennogo_ch.1_

концептуальной модели исходной бизнес-системы к логической модели ИС, а затем и к физической модели соответствующей программного приложения. К базовым моделям UML относятся модель прецедентов (требований) и модель классов (объектную модель). 3.2. Модель вариантов использования Модель прецедентов (модель требований, модель вариантов использования ) – это диаграмма UML, на которой изображаются отношения между актерами и вариантами использования. Это исходное концептуальное представление или концептуальная модель системы в процессе ее проектирования и разработки. Создание диаграммы вариантов использования имеет следующие цели: определение общих границ и контекста моделируемой предметной области на начальных этапах проектирования ИС; формальное представление требований к функциональному поведению (функциональных требований) проектируемой ИС; разработка исходной концептуальной модели системы для ее последующей детализации в форме логических и физических моделей в нотации UML; модельное обеспечение командной разработки ИС при помощи специальных программных средств управления жизненным циклом ИС; подготовка исходной документации для взаимодействия разработчиков системы с ее заказчиками и пользователями. В общем случае, диаграмма вариантов использования представляет собой граф специального вида, который является графической нотацией для представления конкретных вариантов использования, актеров и отношений между этими элементами. Назначение данной диаграммы состоит в следующем: проектируемая система представляется в форме так называемых вариантов использования (прецедентов), с которыми взаимодействуют внешние сущности или актеры (в английской транскрипции – экторы). При этом актером или действующим лицом называется любой объект, субъект, система или устройство, взаимодействующие с моделируемой бизнес-системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая служит источником воздействия на моделируемую систему так, как определит разработчик. Вариант использования служит для описания сервисов, которые система предоставляет актеру в соответствии с его потребностями. При этом не оговаривается, каким образом будет реализовано взаимодействие актеров с системой и собственно выполнение вариантов использования. Рассматривая диаграмму вариантов использования в качестве модели бизнес-системы, можно ассоциировать ее с «черным ящиком» (см. рис. 2). Концептуальный характер этой диаграммы проявляется в том, что подробная детализация диаграммы или включение в нее элементов физического уровня представления на начальном этапе проектирования скорее имеет 21

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

а) глагольное существительное б) глагол в) актер

Рис. 3. Графическое обозначение варианта использования и актера Диаграмма вариантов использования содержит конечное множество вариантов использования, которые в целом должны определять все возможные аспекты ожидаемого поведения системы. Данной модели на всех этапах работы над проектом позволяет не только достичь требуемого уровня унификации обозначений для представления функциональности программы, но и является мощным средством последовательного уточнения требований на основе их итеративного обсуждения со всеми заинтересованными специалистами. Примерами вариантов использования могут быть следующие действия: занесение систему данных о клиенте, проверка состояния текущего счета клиента, оформление заказа на покупку товара, получение информации о кредитоспособности клиента, отображение графической формы на экране монитора, авторизация пользователя, и другие действия, процессы, задачи. Актер (actor) – согласованное множество ролей, которые играют внешние сущности по отношению к вариантам использования при взаимодействии с ними, представляет собой любую внешнюю по отношению к моделируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач. Каждый актер может рассматриваться как определенная роль относительно конкретного варианта использования. 22

Стандартным графическим обозначением актера на диаграммах является фигурка человечка, под которой записывается имя актера (рис. 3, в). Имя актера должно начинаться с заглавной буквы и следовать рекомендациям использования имен для типов и классов модели, должно быть достаточно информативным с точки зрения семантики. Это может быть наименование должности (например, продавец, кассир, менеджер, и т.д.). Не рекомендуется давать актерам имена собственные или названия моделей конкретных устройств, даже если это с очевидностью следует из контекста проекта, так как одно и то же лицо (устройство) может выступать в нескольких ролях и, соответственно, обращаться к различным сервисам проектируемой системы. При этом в каждый момент времени с системой взаимодействует вполне определенный актер, который играет или выступает в одной из таких ролей. Актеры используются для моделирования внешних по отношению к системе сущностей, которые взаимодействуют с системой. Это могут быть пользователи системы, технические устройства (например, датчики, терминалы обслуживания и т.д.), другие системы. В отдельных случаях в качестве актеров могут выступать подсистемы проектируемой системы, либо ее отдельные классы. 3.3. Отношения на диаграмме вариантов использования. Отношение ( relationship ) – семантическая связь между отдельными элементами модели. Между элементами модели прецедентов могут существовать различные отношения, которые описывают взаимодействие экземпляров одних актеров и вариантов использования с экземплярами других актеров и вариантов использования. Один актер может взаимодействовать с несколькими вариантами использования. Это значит, что этот актер обращается к нескольким сервисам данной системы. В свою очередь один прецедент может взаимодействовать с несколькими актерами, предоставляя свой сервис для всех них. В то же время два варианта использования, определенные в рамках одной моделируемой системы, могут взаимодействовать друг с другом, однако характер этого взаимодействия будет отличаться от взаимодействия с актерами. В обоих случаях способы взаимодействия элементов модели предполагают обмен сигналами или сообщениями, которые инициируют реализацию функционального поведения моделируемой системы. В языке UML имеется несколько стандартных видов отношений между элементами модели прецедентов: ассоциация, включение, расширение и обобщение. С помощью отношений включения, расширения и обобщения могут быть представлены общие свойства вариантов использования. Отношение же ассоциации – одно из фундаментальных понятий в языке UML и в той или иной степени используется при построении всех графических моделей систем в форме канонических диаграмм. На диаграмме прецедентов устанавливается только между актером и вариантом использования и служит для обозначения специфической роли актера при его взаимодействии с прецедентом. На диаграмме вариантов использования, так же как и на других диаграммах, ассоциация обозначается сплошной линией между актером и прецедентом, 23

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

а) отношение ассоциации б) отношение включения
в) отношение расширения г) отношение обобщения

Рис. 4. Пример графического представления отношений на диаграмме вариантом использования В контексте модели прецедентов ассоциация между актером и вариантом использования может указывать на то, что актер инициирует соответствующий прецедент. Такого актера называют главным. В других случаях подобная ассоциация может указывать на актера, которому предоставляется справочная информация о результатах функционирования моделируемой системы. Такого актера называют второстепенным. Включение (include) в языке UML – это разновидность отношения зависимости между базовым вариантом использования и его специальным случаем. При этом отношением зависимости (dependency) является такое отношение между двумя элементами модели, при котором изменение одного элемента (независимого) неизбежно приводит к изменению другого элемента (зависимого). Отношение включения устанавливается только между двумя вариантами использования и указывает на то, что заданное поведение для одного варианта использования включается в качестве обязательного составного фрагмента в последовательность поведения другого варианта использования. Данное отношение является направленным бинарным отношением в том смысле, что пара экземпляров вариантов использования всегда упорядочена в этом отношении. Так, например, отношение включения, направленное от варианта использования «Предоставление кредита в банке» к варианту использования «Проверка платежеспособности клиента», указывает на то, что каждый экземпляр первого (базового) прецедента всегда включает в себя функциональное поведение или выполнение второго (включаемого) прецедента, то есть поведение второго прецедента является частью поведения первого прецедента на данной диаграмме. Графически данное отношение обозначается как отношение зависимости в форме пунктирной линии со стрелкой, направленной от базового прецедента к включаемому, при этом данная линия помечается стереотипом <>, как показано на рис. 4, б. Семантика этого отношения определяется следующим образом. Процесс выполнения базового варианта использования включает в себя как собственное 24

подмножество последовательность действий, которая определена для включаемого варианта использования. Причем выполнение включаемой последовательности действий происходит всегда при инициировании базового прецедента. Один вариант использования может входить в несколько других прецедентов, а также включать в себя другие прецеденты. Включаемый вариант использования является независимым от базового прецедента в том смысле, что он предоставляет последнему инкапсулированное поведение, детали реализации которого скрыты от последнего и могут быть легко перераспределены между несколькими включаемыми прецедентами. Более того, базовый вариант использования зависит только от результатов выполнения включаемого в него варианта использования, но не от структуры включаемых в него прецедентов. Расширение (extend) определяет взаимосвязь базового прецедента с другим прецедентом, функциональное поведение которого задействуется базовым не всегда, а только при выполнении дополнительных условий. В языке UML отношение расширения устанавливается только между вариантами использования, и является зависимостью, направленной к базовому прецеденту и соединенной с ним в так называемой точке расширения. Отношение расширения между вариантами использования обозначается как отношение зависимости в форме пунктирной линии со стрелкой, направленной от прецедента, который является расширением для базового прецедента, и помеченная стереотипом <>, как показано на рис. 4, в. В изображенном фрагменте имеет место отношение расширения между базовым прецедентом «Предоставление кредита в банке» и прецедентом «Предоставление налоговых льгот». Это означает, что свойства поведения первого прецедента в некоторых случаях могут быть дополнены функциональностью второго прецедента, для чего должно быть выполнено определенное логическое условие данного отношения расширения. Отношение расширения позволяет моделировать поведение системы таким образом, что один из вариантов использования должен присоединять к своему поведению последовательность действий, определенную для зависимого (расширяющего) прецедента. При этом, в отличие от отношения включения, данное отношение всегда предполагает проверку условия и ссылку на точку расширения в базовом прецеденте. Точка расширения определяет место в базовом прецеденте, в которое должно быть помещено расширение при выполнении соответствующего логического условия. Один вариант использования может быть расширением для нескольких базовых прецедентов, а также иметь в качестве собственных расширений другие прецеденты. Любой базовый вариант использования не зависит от своих расширений. Семантика отношения расширения определяется следующим образом. Если базовый прецедент выполняет некоторую последовательность действий, которая определяет его поведение, и при этом имеется точка расширения на экземпляр другого прецедента, которая является первой из всех точек расширения у базового прецедента, то проверяется логическое условие данного 25

отношения. Если это условие выполняется, исходная последовательность действий расширяется посредством включения действий расширяющего варианта использования. Следует заметить, что условие отношения расширения проверяется лишь один раз – при первой ссылке на точку расширения, и если оно выполняется, то все зависимые прецеденты вставляются в базовый прецедент. Обобщение представляет собой реализацию принципа наследования в ООП. Помимо вариантов использования, может также связывать два и более актера, которые могут иметь общие свойства, т.е. взаимодействовать с одним и тем же множеством вариантов использования одинаковым образом. Такая общность свойств и поведения представляется в виде отношения обобщения с другим, возможно, абстрактным прецедентом/актером, который моделирует соответствующую общность действий/ролей. Графически отношение обобщения обозначается сплошной линией со стрелкой в форме треугольника без заливки, которая указывает на родительский прецедент или действующее лицо (рис. 4, г). Эта линия со стрелкой имеет специальное название – стрелка-обобщение, – которая используется также и в других канонических диаграммах UML. В данном примере отношение обобщения указывает на то, что вариант использования «Предоставление кредита корпоративным клиентам» есть специальный случай варианта использования «Предоставление кредита клиентам банка». Другими словами, первый прецедент является специализацией второго прецедента. При этом вариант использования «Предоставление кредита клиентам банка» называют предком или родителем по отношению к варианту использования «Предоставление кредита корпоративным клиентам», а последний прецедент называют потомком по отношению к первому прецеденту. Следует отметить, что потомок наследует все свойства поведения своего родителя, а также может обладать дополнительными особенностями поведения. Отношение обобщения между элементами модели прецедентов применяется в том случае, когда необходимо отметить, что дочерние элементы обладают всеми особенностями поведения родительских. Дочерние актеры/прецеденты участвуют во всех отношениях родительских актеров/прецедентов. По аналогии с принципом наследования ООП, дочерние актеры/прецеденты могут наделяться новыми свойствами поведения, которые отсутствуют у их предков, а также уточнять или модифицировать наследуемые от них свойства поведения. 3.4. Модель классов Диаграмма классов (class diagram) – диаграмма языка UML, на которой представлена совокупность декларативных или статических элементов модели, таких как классы с атрибутами и операциями, а также связывающие их отношения. Предназначена для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Когда говорят о данной диаграмме, имеют в виду статическую структурную модель проектируемой системы, т.е. графическое 26

представление таких структурных взаимосвязей логической модели системы, которые не зависят от времени. Класс (class) – абстрактное описание множества однородных объектов, имеющих одинаковые атрибуты, операции и отношения с объектами других классов. Графически класс в нотации UML изображается в виде прямоугольника, который дополнительно может быть разделен горизонтальными линиями на разделы или секции (рис. 5). В этих секциях указываются имя класса, атрибуты и операции класса. На начальных этапах разработки диаграммы отдельные классы могут обозначаться простым прямоугольником, в котором должно быть указано его имя (рис. 5, а). По мере проработки отдельных компонентов диаграммы описания классов дополняются атрибутами (рис. 5, б) и операциями (рис. 5, в). Четвертая секция (рис. 5, г) не обязательна и служит для размещения дополнительной информации справочного характера, например, об исключениях или ограничениях класса, сведения о разработчике или языке реализации класса. Предполагается, что окончательный вариант диаграммы содержит наиболее полные описания классов, которые состоят из трех или четырех секций. Рис. 5. Варианты графического изображения класса на диаграмме Имя класса должно быть уникальным в пределах пакета, который может содержать одну или несколько диаграмм классов. Имя указывается в самой верхней секции прямоугольника, поэтому она называется секцией имени класса. В дополнение к общему правилу именования элементов языка UML, имя класса записывается по центру секции полужирным шрифтом и должно начинаться с заглавной буквы. Рекомендуется в качестве имен классов использовать имена существительные, записанные по практическим соображениям без пробелов. Необходимо помнить, что имена классов образуют словарь предметной области при проектировании системы. В секции имени класса могут также находиться стереотипы или ссылки на стандартные шаблоны, от которых образован данный класс и, соответственно, от которых он наследует свои свойства: атрибуты и операции. 27

В этой секции может также приводиться информация о разработчике класса и статус состояния разработки. Атрибут (attribute) – содержательная характеристика класса, описывающая множество значений, которые могут принимать отдельные объекты этого класса. Атрибут класса служит для представления отдельного свойства или признака, который является общим для всех объектов данного класса. Атрибуты класса записываются в секции атрибутов (рис. 5, б). Операция (operation) – это сервис, предоставляемый каждым экземпляром или объектом класса по требованию своих клиентов, в качестве которых могут выступать другие объекты, в том числе и экземпляры данного класса. Операции класса записываются в секции операций (рис. 5, в). Совокупность операций характеризует функциональный аспект поведения всех объектов данного класса, который описывается другими каноническими диаграммами UML. Имя операции представляет собой строку текста, которая используется в качестве идентификатора соответствующей операции и должна быть уникальной в пределах данного класса. Имя операции должно начинаться со строчной буквы, и, как правило, записываться без пробелов. Идентификация классов анализа заключается в предварительном определении набора классов системы (так называемых, классов анализа) на основе описания предметной области и спецификации требований к системе. Прежде всего, выделяются основные абстракции предметной области. Способы идентификации основных абстракций аналогичны способам идентификации сущностей в модели «сущность-связь» – поиск абстракций, описывающих физические или материальные объекты, процессы и события, роли людей, организации и другие понятия предметной области. Единственным формальным способом идентификации сущностей является анализ текстовых описаний предметной области, выделение из описаний имен существительных и выбор их в качестве «кандидатов» на роль абстракций. Каждая сущность должна иметь наименование, выраженное существительным в единственном числе. Далее абстракции идентифицируются по трем типам, которые используются для уточнения семантики отдельных классов при построении различных диаграмм: 1. Управляющий класс (control class) – класс, отвечающий за координацию действий других классов на диаграмме. На каждой диаграмме классов должен быть хотя бы один управляющий класс, который контролирует последовательность выполнения действий данного варианта использования. Данный класс является активным и инициирует рассылку множества сообщений другим классам модели. Управляющий класс изображается в форме прямоугольника класса со стереотипом <> в секции имени. Примеры управляющих классов: менеджер транзакций, журнал операций, координатор ресурсов, обработчик событий, обработчик ошибок, и т.п. 2. Класс-сущность (entity class) – пассивный класс, информация о котором должна храниться постоянно и не уничтожаться с выключением системы или завершением работы программы. Как правило, этот класс 28

соответствует отдельной сущности логической модели данных системы. В этом случае его атрибуты являются потенциальными полями таблицы, а операции – присоединенными или хранимыми процедурами. Этот класс пассивный и лишь принимает сообщения от других классов модели, реагируя на них посредством своих операций. Источники выявления классов-сущностей: ключевые абстракции, созданные в процессе архитектурного анализа, глоссарий проекта, описание потоков событий вариантов использования. Класс-сущность может быть изображен также стандартным образом в форме прямоугольника класса со стереотипом <> с секции имени класса. 3. Граничный класс (boundary class) – класс, который располагается на границе системы с внешней средой и непосредственно взаимодействует с актерами, но, тем не менее, является составной частью системы. Как правило, для каждой пары «действующее лицо – вариант использования» определяется один граничный класс. Типы граничных классов: пользовательский интерфейс, выражающий обмен информацией с пользователем без деталей интерфейса: кнопок, списков, окон, и т.п. системный интерфейс с надсистемой или другой системой (используемые протоколы обмена без деталей их реализации); аппаратный интерфейс для связи с внешними техническими устройствами (аппаратные средства, протоколы, драйверы). Граничный класс может быть изображен также стандартным образом в форме прямоугольника класса со стереотипом > в секции имени. 3.5. Отношения между классами Классы вступают друг с другом в отношения. На диаграмме классов выделяют такие виды отношений: ассоциация, наследование, агрегирование и использование. При изображении конкретной связи ей можно сопоставить текстовую метку, документирующую имя этой связи и/или ее роль. Имя отношения должно быть уникально в своем контексте. Также связь может иметь по ее концам обозначения кратности (множественности) отношений между классами, некоторые из которых показаны ни рис. 6.

* неопределенное множество

1..* один или много
0..1 ноль или 1
1..8 от 1 до 8
12 точно 12
определенное множество

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

Рис. 6. Обозначения множественности и значки отношений между классами Значок ассоциации соединяет два класса и означает наличие семантической связи между ними. Ассоциации часто отмечаются 29

существительными (например, Выбор), описывающими природу связи. Одна пара классов может иметь одну или несколько ассоциативных связей. Наследование представляет отношение типа «общее/частное», выглядит как значок ассоциации со стрелкой, которая указывает от подкласса к суперклассу. При этом подкласс наследует структуру и поведение своего суперкласса. Класс может иметь один (одиночное наследование), или несколько (множественное наследование) суперклассов. Агрегирование обозначает отношение «целое/часть» и получается из значка ассоциации добавлением закрашенного кружка на конце, обозначающем агрегат. Экземпляры класса на другом конце стрелки будут в определенном смысле частями экземпляров класса-агрегата. Разрешается рефлексивная и циклическая агрегация. Агрегация не требует обязательного физического включения части в целое. Композиция – это разновидность агрегирования с четко выраженным отношением владения, причем время жизни частей и целого совпадают. Части с нефиксированной кратностью могут быть созданы уже после создания самого композита, живут и уничтожаются вместе с ним. Также части могут быть удалены явным образом еще до уничтожения композита. Кроме того, в композитном агрегировании целое отвечает за диспозицию своих частей, то есть композит должен управлять их созданием и уничтожением. Использование обозначает отношение типа «клиент/сервер» и изображается как ассоциация с пустым кружком на конце, соответствующем клиенту. Эта связь выражает зависимость клиента от сервера и означает, что клиент нуждается в услугах сервера, то есть операции класса-клиента вызывают операции класса-сервера или имеют сигнатуру, в которой возвращаемое значение и/или аргументы принадлежат классу сервера. Фактически отношение использования показывает, что один элемент использует другой. Общие рекомендации по построению диаграмм классов: использовать зависимость, только в случае, если моделируемое отношение не является структурным; использовать обобщение, только если имеет место отношение типа «является»; располагать элементы так, чтобы свести к минимуму число пересекающиеся линий отношений; пространственно организовывать элементы так, чтобы семантически близкие сущности располагались рядом; — чтобы привлечь внимание к важным особенностям диаграммы, использовать примечания (комментарии) и выделение цветом; 3.6. Рациональный унифицированный процесс Процесс построения отдельных типов диаграмм UML имеет свои особенности, которые тесно связаны с семантикой элементов этих диаграмм. Сам процесс ООП в контексте языка UML получил специальное название – рациональный унифицированный процесс (Rational Unified Process, RUP). 30

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *