Диаграммы UML

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

Чем UML не является

1. не является языком программирования, хотя генерация кода не возбраняется
2. не навязывает спецификации, которая говорила бы о том, как программы должны рисовать UML-схемы
3. не диктует модель процесса разработки приложения

Частые способы применения

1. рисование картинок/схем для обмена информацией (общением) с другими людьми
2. спецификация систем - возможность как-то стандартизировать знания о работе компании (полезно для быстрого понимания)
3. моделирование объектов - описание объектов участвующих в спецификации системы (например модель Клиент имеет поля Имя, адрес и т.д.)

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

Типы элементов нотации

1. фигура (shape) - прямоугольники и эллипсы, внутри фигур могут помещаться другие элементы нотации: тексты, линии, значки и даже другие фигуры. Единственное требование: должно быть однозначно понятно, что элемент нотации находится внутри фигуры, в частности, его изображение не должно пересекать границу фигуры.
2. линия (line) - могут быть прямые, ломаные, плавные кривые, сплошные и пунктирные. Всегда присоединяются своими концами к фигурам или значкам, они не могут быть нарисованы сами по себе. К линиям могут быть пририсованы дополнительные элементы: стрелки на концах, тексты и т.д. Единственное требование: должно быть ясно, что дополнительный элемент относится именно к данной линии. Линии могут пересекаться, и это ничего не значит, но рекомендуется избегать таких случаев, поскольку это затрудняет восприятие.
3. значок (icon) - не имеют внутренности, в которую можно что-то поместить.
4. текст (text) - различаются прямые, курсивные и подчеркнутые тексты
5. рамка (frame) - используется исключительно как контейнер для других фигур, линий, значков и текстов

Нотация UML довольно свободная: рисовать можно как угодно, лишь бы не возникало недоразумений. Например рассмотрим пример "Четыре способа представления ребер" из книги Фаулер М. UML. Основы (3-е издание, 2005):

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

Виды

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

Авторы UML считают, что диаграммы определены не очень строго. Часто вполне допустимо присутствие элементов диаграммы одного типа в другой диаграмме.

Стоит добавить, что иерархия UML диаграмм и полное описание каждого типа хорошо продемонстрированы в википедии.

Взаимосвязи

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

Пример взаимосвязи			Описание
наличие обязательных деталей	Ассоциация	Компьютер	Если у сложного устройства есть в наличии обязательные детали (материнская плата, процессор, озу) значит это компьютер
сложное устройство	Наследование	Компьютер	Любое сложное устройство (ноутбук, планшет, умные часы и т.д.) является представителем компьютера
компьютер	Реализация/Имплементация	Стандарты сборки	Чтобы правильно собрать компьютер, нужно следовать неким стандартам сборки (размеры, виды разъемов, версии протоколов взаимодействия и т.д.)
компьютер	Зависимость	Электричество	Работа компьютера зависит от электричества, но электричество не зависит от компьютера
дополнительные детали	Агрегация	Компьютер	В компьютере могут быть дополнительные детали (точпад, веб-камера и т.д), но их может и не быть
обязательные детали	Композиция	Компьютер	Без обязательных деталей компьюетр не может быть собран (материнская плата, процессор, озу)

Рассмотрим примеры с детальным пояснением.

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

На рис. 3.7 показаны зависимости, которые можно обнаружить в многоуровневом приложении. Класс Benefits Window (Окно льгот) – это пользовательский интерфейс, или класс представления, зависящий от класса Employee (Сотрудник). Класс Employee – это объект предметной области, который представляет основное поведение системы, в данном случае бизнес- правила. Это означает, что если класс Employee изменяет свой интерфейс, то, возможно, и класс Benefits Window также должен измениться.

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

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

Кратность

• 1 Заказ может представить только один клиент.
• 0..1 (Корпоративный клиент может иметь, а может и не иметь единственного торгового представителя.)
• * Клиент не обязан размещать заказ, и количество заказов не ограничено. Он может разместить ноль или более заказов.

Атрибут

Примеры:

isPrepaid: Boolean[1]

+ userName: String [1] = "Без имени" {readOnly}

Обязательно только имя.

• слева от имени отображается метка видимости, которая может быть + (public) или - (private). Если не указано, значит +
• справа от знака "равно" = показано значение по умолчанию (значение для вновь создаваемых объектов, если атрибут не определен в процессе создания)
• Элемент {строка свойств} позволяет указывать дополнительные свойства атрибута. В примере он равен {readOnly}, то есть клиенты не могут изменять атрибут. Если он пропущен, то, как правило, атрибут можно модифицировать

Параметризованный класс:

Шарово-гнездовая нотация

Рассмотрим php-пример нотации называемой "леденец на палочке":

class Order {      private List $Lineltems;      public function __construct() {          $this->LineItems = new ArrayListO;      }  }

• ArrayList это реализация классов/интерфейсов List и Collection
• Order требует чтобы LineItems был экземпляром класса/интерфейса List

Еще пример, но уже с диаграммой компонентов:

В этом примере компонент Till (Касса) может взаимодействовать с компонентом Sales Server (Сервер продаж) с помощью интерфейса sales message (Сообщение о продажах). Поскольку сеть ненадежна, то компонент Message Queue (Очередь сообщений) установлен так, чтобы касса (Till) могла общаться с сервером продаж (Sales Server), когда сеть работает. А когда сеть отключена, чтобы можно было разговаривать с очередью сообщений. Тогда очередь сообщений сможет поговорить с сервером, когда сеть снова станет доступной. В результате очередь сообщений предоставляет интерфейс для разговора с кассой (Till), и требует такой же интерфейс для разговора с сервером. Сервер разделен на два основных компонента: Transaction Processor (Процессор транзакций) реализует интерфейс сообщений, а Accounting Driver (Драйвер счетов) общается с Accounting System (Система ведения счетов) .

Диаграмма последовательности

Пример демонстрирующий, как вызов функции calculatePrice порождает цепочку действий.

Обратите внимание на следующие нюансы:

• возвращающие стрелки не отображены, но подразумеваются (кроме последней стрелки пунктиром)
• объект Order сделав вызов getDiscountedValue породил обратный вызов к себе getBaseValue от объекта Customer

Диаграмма деятельности

Обратите внимание выше, как завершается слияние у решения.

Вложенная деятельность

Часто, можно встретить такие обозначения:

Деятельность разделов (взаимодействие разделов)

Иногда полезно разбить диаграмму деятельности на разделы (partitions):

Еще пример:

Временный сигнал:

Как видите, до моего отлета остается два часа (Two hours before flight), и мне пора собирать багаж. Если я упакую его раньше времени, то все равно не смогу уехать, пока не прибудет такси. Если такси приходит (Taxi Arrives) до того, как я успею собрать багаж (Pack Bags), то оно должно ждать меня, пока я не закончу.

Диаграммы компонентов

Пример вложенности:

Временные диаграммы

Акцентирует внимание на временных ограничениях.

Пример из жизни основанный на использовании насоса (Pump) и нагревательного элемента (Hotplate) в кофеварке (coffee pot).

Представим себе правило, которое гласит, что между включением насоса и включением нагревательного элемента должно пройти по крайней мере 10 секунд. Когда емкость с водой становится пустой (waterEmpty), насос выключается, а нагревательный элемент не может оставаться включенным более 15 минут.

Временная диаграмма, на которой состояния представлены в виде линий:

Временная диаграмма, на которой состояния представлены в виде областей:

Источники: 1 - 2 - 3 - 4 - 5 - 6- 7 - 8