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

Унифицированный язык моделирования (UML) состоит из интегрированных диаграмм, используемых ИТ-разработчиками для визуального представления объектов, состояний и процессов в программном обеспечении или системе. Язык моделирования может служить чертежом проекта и гарантировать структурированную информационную архитектуру, а также может помочь разработчикам представить описание системы в понятном для внешних специалистов виде. UML в основном используется при разработке объектно-ориентированного программного обеспечения. Усовершенствования, внесенные в стандарт в версии 2.0, также делают его пригодным для представления бизнес-процессов.

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

С конца 1980-х по 1990-е годы было разработано и введено в использование множество методов и языков для представления ООП. В результате появилось множество методов, которые были во многом несхожи. Для их унификации три разработчика Джеймс Румбо, Грейди Бух и Ивар Якобсон решили объединить несколько существующих языков в один общий, стандартизированный.

Эти трое уже создали свои собственные методы разработки объектно-ориентированного программного обеспечения:

• Метод Буча
• Метод объектного моделирования (OMT)
• Метод объектно-ориентированной разработки программного обеспечения (OOSE).

UML должен определить семантику для представления этих методов в качестве языка моделирования. Под названием «UML Partners» разработчики начали работать над завершением UML в команде в 1996 году. Затем они передали его Object Management Group (OMG), которая представила унифицированный язык моделирования версии 1.1 в качестве стандарта в 1997 году.

Не удовлетворившись этим, разработчики создали рабочую группу для улучшения языка в течение нескольких версий. Существующая критика включала неточную, неоправданно сложную семантику, отсутствие адаптивности и довольно слабую стандартизацию. По этой причине была проведена серьезная ревизия. Результатом стал UML 2.0, который установил новый стандарт в 2005 году. Версия 2.4.1 легла в основу стандартизации ISO 19505-1 (Инфраструктура) и 19505-2 (Надстройка) 2012 года. Версия UML 2.5.1 появилась в декабре 2017 года.

Некоторые называют «унифицированный язык моделирования» лингва-франка среди языков моделирования, и это действительно то, чем он стремился стать. Как упоминалось выше, UML визуализирует состояния объектов и взаимодействие между ними в рамках системы. Его широкое распространение, возможно, связано с большим влиянием членов группы управления объектами (OMG) (включая IBM, Microsoft и HP). Этому также способствует структурированная семантика. Диаграммы UML отображают следующие компоненты системы:

• Отдельные объекты (базовые компоненты)
• Классы (комбинация элементов с одинаковыми свойствами)
• Отношения между объектами (иерархия и поведение/коммуникация между объектами)
• Действия (сложная комбинация действий/поведенческие строительные блоки)
• Взаимодействие между объектами и интерфейсы

UML 2.0 определяет единицы языка, которые работают на разных уровнях. Вы используете их для выражения структуры и поведения системы. Метамоделирование включает все элементы UML, включая те, которые описывают сам UML. В нем используются четыре иерархически расположенных уровня (от M0 до M3).

Уровень метамоделирования M3 определяет метаданные языка моделирования и их взаимосвязи с помощью метаобъекта (MOF). Он определяет мета-модель, а также позволяет передавать метаданные. Формат XMI, определенный членами группы управления объектами, является практическим инструментом для обмена объектно-ориентированными данными на уровне метаданных между инструментами разработки. Язык объектных ограничений (OCL), декларативный язык программирования, дополняет UML и регулирует граничные условия моделирования. Однако как текстовый язык он является лишь вспомогательным и не может быть использован для моделирования.

На рисунке показано, что метамоделирование UML 2.0, уровень M0 — это базовый уровень. Он представляет конкретные, реальные объекты и отдельные записи данных — например, объект или компонент. Уровень M1 включает в себя все модели, которые описывают и структурируют данные уровня M0. Это UML-диаграммы, такие как диаграмма деятельности или диаграмма пакетов (объясняется ниже). Чтобы определить структуру этих моделей, мета-модели M2 определяют спецификации и семантику элементов модели.

Если вы хотите создать понятную диаграмму UML, вам необходимо знать мета-модель UML и ее правила. Самый высокий уровень, M3, является мета-моделью мета-модели. Упомянутое мета-объектное средство работает на абстрактном уровне, определяющем мета-модели. Этот уровень определяет сам себя, поскольку в противном случае возникли бы другие, вышестоящие метауровни.

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

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

• Core (описывает элементы инфраструктуры UML 2.0, такие как пакет, пространство имен, атрибут и т.д.).
• Ассоциативные классы
• Интерфейсы
• Силовые типы (классы, экземпляры которых являются подклассами в рамках данного класса)

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

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

Профиль: Профиль настраивает UML 2.0 для конкретных нужд. Абстрактные термины, такие как деятельность или объект, должны быть определены для некоторых проектов, чтобы улучшить понимание. Вы можете использовать профиль для настройки семантики и понятий, которые заданы нечетко.

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

Действие: Когда речь идет об изображении поведения, действия занимают центральное место. Они представляют собой один шаг в рамках деятельности — деятельность, в свою очередь, является поведением, которое состоит из набора действий. Вот несколько примеров действий:

• Заполнить заказ
• Показать страницу ошибки
• Обработать заказ

Поведение: Языковая единица «поведение» или «описание поведения» означает моделирование динамических аспектов в системе. Она содержит три спецификации:

• Действие: Действия взаимодействуют через потоки данных и управления. В результате образуется сложная система поведений — действий.
• Взаимодействие: Эта мета-модель описывает, как потоки сообщений обмениваются между объектами, когда сообщение отправляется и какому объекту, и на какие другие элементы оно влияет.
• Машины состояний: На диаграмме состояний эта метамодель показывает состояния (ситуации с неизменными свойствами) и псевдосостояния (состояния без присвоения значений) вместе с их переходами. Объекты в состоянии могут быть назначены на действия или деятельность.

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

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

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

Язык моделирования определяет 14 типов диаграмм, которые делятся на две категории. Основные категории «структура» и «поведение» представляют основные концепции, представленные диаграммами UML. В группе поведенческих диаграмм UML определяет подкатегорию «диаграммы взаимодействия». Четвертая подкатегория существует с момента разработки UML 2.0 и определяет дизайн диаграмм моделей.

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

Диаграммы UML этой категории представляют всю систему или подструктуру. Последняя помогает, например, детально прояснить структуру. В языке категории «структура» в UML 2.0 выделено семь типов UML-диаграмм:

• Диаграмма классов: Если объекты имеют общее поведение или одинаковую структуру, их можно классифицировать или отнести к классу. Таким образом, класс является упрощающим, обобщающим элементом (абстракцией) для визуального представления. Классы и объекты связаны друг с другом с помощью интерфейсов. Все эти компоненты и их связи друг с другом могут быть представлены на диаграмме классов. Класс представляет свою диаграмму с помощью прямоугольника. Название класса выделено жирным шрифтом, как показано ниже.

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

• Диаграмма составной структуры: Объекты принадлежат к классам, которые, в свою очередь, также могут быть классифицированы. Эти так называемые мета-классы в UML называются классификаторами. Диаграмма составной структуры представляет отдельные части и соединительные элементы классификатора. Части всегда являются частью целого, даже если они не обязательно нужны для завершения классификатора. Соединители — это связи между частями. Функции или сервисы, требующие компонентов вне классификатора, передают части через интерфейс.
• Диаграмма пакета: Пакет объединяет такие элементы, как интерфейсы или классы, в пространстве имен (см. примечание под диаграммой). Пакеты также могут объединяться с другими пакетами (объединение пакетов), импортировать их (импорт пакетов) или содержать другие пакеты (подпакеты). Диаграммы структуры пакетов связывают содержимое иерархически, как в древовидной диаграмме. Диаграмма пакетов используется, например, в мета-модели UML 2, и является модульной в программных системах. Строго говоря, пакет состоит из головной части и области содержимого.

• Диаграмма развертывания: Диаграмма развертывания моделирует физическое распределение артефактов по узлам. Узлы — это либо аппаратное обеспечение (узлы устройств), которое может предоставлять память, либо программное обеспечение (узлы среды выполнения), которое предоставляет среду для выполнения процессов. Они представлены в виде трехмерных кубоидов. Они содержат имя файла. Чтобы отличить их от класса, кубоиды имеют стереотипы, такие как <<артефакт>>. Диаграмма подходит для отображения зависимостей между узлами и артефактами, так называемых отношений распределения.

  </artifact>

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

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

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

Диаграмма вариантов использования представляет UML с помощью прямоугольника с надписью «вариант использования». Отправителем является действующее лицо (оно изображается в виде палочной фигуры, даже если это система — см. ниже). Актор связан с вариантом использования (эллипс с меткой) в рамках системы (прямоугольник с меткой <<system>> и названием системы).

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

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

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

  UML 2.0 отображает синхронные сообщения (стрелка с заполненной головкой) и асинхронные сообщения (стрелка с открытой головкой). Синхронные сообщения — это сообщения, которые блокируют канал до получения ответа от целевого объекта. Они определяют поведенческие характеристики в виде синхронных операций. Асинхронные сообщения управляют вызывающим объектом-источником. К ним относятся как асинхронные операции, так и сигналы (пакеты данных, передаваемые между действиями).

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

• Временная диаграмма: Временная диаграмма позволяет детально показать поведение систем в аспекте временной последовательности. Системы реального времени, например, должны завершать определенные процессы в течение определенного периода времени. Чтобы лучше представить временную плоскость, UML 2.0 моделирует временные диаграммы как двумерные диаграммы, с осью x и осью y. В этой подкатегории диаграммы последовательности состояния объектов находятся на оси y, а временные последовательности, назначенные им, проходят вдоль оси y.

• Диаграмма обзора взаимодействия: Диаграмма обзора взаимодействия, недавно добавленная в UML 2.0, помогает отобразить очень сложную систему в грубых очертаниях, когда обычная диаграмма взаимодействия была бы слишком запутанной. Для детального отображения подходит диаграмма последовательности. Диаграмма UML похожа на диаграмму деятельности с узлами. Она представляет потоки управления между взаимодействиями. Она отличается от диаграммы деятельности тем, что вся диаграмма взаимодействия может быть вложена в узлы, обозначающие деятельность. Эти вложения могут быть показаны непосредственно в диаграмме (inline) или ссылаться на модель (ключевое слово: ref), что подробно показано в другом месте.

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