UML. Дополнительные отношения: отношение расширения, отношение включения, отношение агрегации, отношение композиции.

Дополнительные отношения:

1) отношение расширения;

2) отношение включения;

3) отношение агрегации;

4) отношение композиции.

Отношение расширения – это один из вариантов отношения зависимости. Отношение расширения – это взаимосвязь одной частной сущности с более общей сущностью.

“еxtend” (стрелка пунктиром)

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

“include” (стрелка пунктиром)

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

Целое

Часть

 

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

Целое

Часть

 

31 UML. Диаграмма вариантов использования. Актер, вариант использования, интерфейс, примечание.

UML (unified Meta language). Унифицированные метаязыки.

Общие сведения.

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

UML эффективно используется для моделирования сложным систем.

Программные продукты, работающие с UML: Rational Rose, Together, Visio.

Принципы построения сложной системы:

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

5) Многомодельность – никакая единственная модель не может с достаточной степенью адекватности (или приватности??) описывать различные аспекты сложной системы. Необходимо использовать некоторое число взаимосвязанных представлений, каждое из которых отражает некоторый аспект поведения или строения (структуры) системы.

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

Общая структура языка UML.

С общей точки зрения язык состоит из двух взаимодействующих частей:

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

4) Нотация языка UML (представляет собой графическую нотацию для визуализированного предст-я семант. языка).

Семантика определяется для двух видов объектных моделей – для структурных м и моделей поведения. Структурные (статические) модели описывают структуру сущностей, компонентов системы, включая их классы, интерфейсы, атрибуты и отношения.

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

UML выделяет 4 уровня модельных представлений:

5) Мето-метомодель;

6) Мето-модель;

7) Модель;

8) Объекты пользователя

 

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

Разработка диаграммы преследует следующие цели:

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

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

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

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

Элементы (блоки):

1. актер – любая сущность, взаимод с системой

2. варианты использования – набор действий, совершаемых системой (в повелительном наклонении)

3. интерфейс – спецификация параметров моделей, которые видимы извне

4. примечания (комментарии) – произвольный текст

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

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

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

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

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

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

 

 

Актеры

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

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

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

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

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

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

Интерфейс

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

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

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

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

Примечания

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

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

Если в примечании указывается ключевое слово «constraint», то оно является ограничением, налагаемым на соответствующий элемент модели.