Применение каких отношений считается ошибкой при построении диаграммы классов

Предисловие

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

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

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

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

Э.С. Таненбаум

Использование ООП может существенно упросить жизнь программисту. Это достигается за счёт сокрытия особенностей внутренней реализации классов. Программисту остаётся лишь пользоваться её удобствами. Кажется, что ООП – панацея от всех проблем. Однако на практике, если не иметь чёткого представления о том, какие классы нужно реализовать и как ими потом пользоваться, в результате может получиться очень запутанная система, которая начнёт порождать спагетти-коду (от англ. “spaghetti code”), который будет лишь мешаться, когда вы захотите добавить что-то новое в систему.

Чтобы избежать большинства проблем, возникающих при использовании ООП, нужно:

1. Иметь некоторый опыт создания программ и использования классов.

2. Строить структурные диаграммы классов.

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

Содержание

1. Назначение диаграммы классов

2. Постановка задачи и её анализ

3. Класс

   1. Статический класс

   2. Абстрактный класс

4. Поля класса

   1. Уровень видимости

   2. Идентификатор

   3. Тип поля

   4. Кратность

5. Методы класса

6. Классы, отвечающие за графику

7. Виды отношений

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

   2. Отношение зависимости

   3. Отношение наследования

   4. Отношение агрегации

   5. Отношение композиции

Назначение диаграммы классов

Диаграмма классов (от англ. «class diagram») предназначена для представления внутренней структуры программы в виде классов и связей между ними. 

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

Взаимосвязь диаграммы классов с другими диаграммами

Диаграмма классов UML тесно связана с другими диаграммами, поскольку в них используются экземпляры классов (объекты), описанные на диаграмме классов. Например, на диаграмме кооперации (англ. «cooperation diagram») показывается структурные связи при взаимодействии объектов, а на диаграмме последовательности (англ. «sequence diagram») изображается последовательность обмена сообщений между объектами.

Постановка задачи и её анализ

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

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

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

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

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

Зачем плодить множество диаграмм, когда можно сделать одну большую?

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

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

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

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

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

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

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

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

Для удобства работы с нашим приложением нужно добавить возможность определения и использования именованных констант. Например, использование распространённых математических констант, таких как π = 3,141592.. или e = 2,71828.. будет очень удобным для пользователей.

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

Соглашение об именовании объектов и классов

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

• Класс для хранения математического выражения. Назовём его MathExpression.

• Класс для разбиения строкового представления выражения на список токенов — MathParser.

• Класс для построения постфиксной формы выражения из списка токенов — MathFormConverter.

• Класс для работы с именованными константами — MathConstantManager.

• Класс для проверки корректности пользовательского математического выражения — MathChecker.

• Класс для подсчёта таблицы значений математического выражения — MathCalculator.

Почему все имена классов имеют префикс Math?*

Класс

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

1. Имя класса

2. Список полей класса

3. Список методов класса

Выбор терминологии

Оранжевым цветом мы будем выделять обязательные части элементов.

Обычно в качестве имени класса выбирается существительное в единственном числе. Разумеется, это имя должно быть уникальным в пределах диаграммы. Если имя класса состоит из нескольких слов, мы ,по практическим соображениям, будем записывать их слитно в верблюжьем стиле (от англ. «CamelCase»).

Рекомендация по именованию классов

Настало время изобразить наши классы на диаграмме. Пока что давайте изобразим только имена этих классов.

Пока что эта диаграмма не даёт никакого понимания того, как будет устроена наша система, однако к концу статьи диаграмма значительно преобразится.

Статический класс

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

Формально, такие модификаторы называется стереотипами. Стереотип – именованный набор свойств. В данном случае, стереотип «utility» означает, что объекты указанного класса не создаются.

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

В нашей системе классы MathParser, MathFormConverter, MathConstantManager являются статическими, потому что они представляют собой «сборник» полезных функций, которые мы объединили в класс. Давайте изобразим это на нашей диаграмме.

Абстрактный класс

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

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

Поля класса

Вернёмся к нашему примеру с классом Customer. Обратите внимание на центральную секцию.

Давайте рассмотрим первую строчку. Что вообще означает запись «- balance: Integer»? Сейчас будем разбираться.

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

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

Уровень видимости

Уровень видимости (от англ. «visibility») — свойство поля, которое показывает, из какой части программы можно обратиться к данному полю.

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

• «+» — открытое поле. Аналог public в языках программирования. Означает, что к полю можно обратиться из любой части программы.

• «-» — закрытое поле. Аналог private в языках программирования. Означает, что получить доступ к полю можно только внутри класса.

• «#» — защищённое поле. Аналог protected в языках программирования. Означает, что получить доступ к полю можно внутри класса и внутри производных классов.

Может показаться, что как-то неудобно для каждого поля указывать его уровень видимости. Почему бы не группировать поля по уровню видимости? Например, именно такой подход используется в языке программирования C++. Давайте попробуем напрямую использовать ключевые слова public, private и protected.

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

А что будет, если не указывать уровень видимости вовсе?*

Идентификатор

Идентификатор (от англ. «identificator») — название поля. Является обязательным элементом для описания переменной на диаграмме классов, поскольку однозначно её определяет (все идентификаторы на диаграммах уникальны).

Тип поля

Тип поля (англ. «type of field») показывает, какой тип имеет данное поле в нашей программе. На ранней стадии проектирования можно и не уточнять, какой тип имеет то или иное поле.

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

Кратность

Кратность (от англ. «multiplicity») – интервал, определяющий диапазон количества элементов в массиве. Если для поля указана кратность, то его следует считать массивом. Количество элементов в таком массиве и будет определяться указанным интервалом.

Для кратности указывают одно или два значения:

• [m..n] — интервал от m до n включительно (m <= n). Такая запись будет означать, что в коллекции может храниться от m до n значений включительно.

• [n] – интервал, который можно рассматривать, как сокращённую запись [0..n].

Может случиться так, что мы захотим показать, что в массиве может храниться неограниченное количество элементов. В таком случае верхняя граница n заменяется символом *.

Примеры интервалов:

• [1] — ровно один объект. То же самое, что и интервал [1..1]

• [0..1] — ноль или один объект.

• [0..*] — ноль или неограниченное количество объектов. Часто такой интервал обозначают просто как [*].

• [1..*] — один или неограниченное количество объектов.

Наиболее часто используют кратность [0..*] или [1..*]. Можно заметить, что динамические структуры данных вообще очень удобны в использовании. В нашей статье мы откажемся от использования кратности, а будем использовать такие коллекции: связный список (List) и ассоциативный массив (Map).

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

Чтобы отличать статические элементы класса от обычных, статические поля и методы будут подчёркиваться.

Назначение каждого поля построенных классов

Методы класса

Снова разберём наш пример с классом Customer. На этот раз обратим внимание на третью секцию — секцию методов.

Описание методов очень похоже на описание полей класса. На рисунке ниже представлен общий вид описания метода класса.

Аргументы методов в общем случае описываются следующим образом:

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

Классы, отвечающие за графику

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

Виды отношений

Давайте начнём рассматривать различные отношения между классами на диаграмме. Нами будут рассмотрены следующие соединительные линии:

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

• Отношение зависимости

• Отношение обобщения, также известное как отношение наследования.

• Отношение агрегации

• Отношение композиции

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

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

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

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

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

Обратите внимание на кратность ассоциации, которая расположена под стрелкой. С кратностью мы уже встречались ранее. Здесь у нее несколько иное значение. Кратность ассоциации обозначает количество объектов, которые участвуют во взаимодействии. Как показано на рисунке выше, во взаимодействии могут участвовать от m до n пользователей и от q до r владельцев.

Если кратность ассоциации не указана, будет подразумеваться кратность [0..*]. В случае со статическими классами кратность не указывается (можно считать, что там указана кратность [1].

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

Давайте добавим отношения ассоциации на наши диаграммы.

Отношение зависимости

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

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

Стрелка отношения зависимости направлена от зависимого класса к независимому.

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

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

Отношение наследования

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

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

Если вы работали с какой-нибудь библиотекой для создания графического интерфейса (OpenGL в чистом виде не в счёт!), вы могли заметить, что все классы графических элементов обычно выстраиваются в цепочку наследования.  Например, взгляните на цепочку наследования классов фреймворка Qt5, представленную на рисунке ниже.

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

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

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

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

Отношение агрегации

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

В переводе с английского, слово aggregation означает соединение частей. Это значение очень точно отражает суть данного отношения – показать, из каких частей состоит класс.

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

class A
{
	class B
	{
	};
…
}; 

На самом деле, это отношение означает, что объект одного класса включает в себя в качестве составной части объект другого класса.

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

На нашей диаграмме есть много мест, где нам может пригодиться отношение агрегации:

• Объект класса MainWindow содержит в себе по одному объекту классов PaintingArea, ConstantBoxList, FunctionBoxList.

• Неограниченное количество объектов класса Graph могут содержаться в объекте класса PaintingArea.

• Класс-контейнер ConstantBoxList может содержать в себе неограниченное количество объектов класса ConstantBox.

• Класс-контейнер FunctionBoxList может содержать в себе неограниченное количество объектов класса FunctionBox.

Отношение композиции

Отношение композиции является частным случаем отношения агрегации. Однако у него есть одно отличие – классы-части, которые он соединяет с классом-целым, не могут существовать обособленно.

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

Давайте в качестве примера рассмотрим окно интерпретатора Python.

Понятное дело, что ни полоса прокрутки (ScrollBar), ни заголовок окна (Title), ни поле ввода команд (TextInput) не могут существовать отдельно от окна программы (Window). Это можно изобразить на диаграмме классов следующим образом.

В нашей диаграмме объекты классов FunctionBox и ConstantBox не могут существовать отдельно от их контейнеров. Кроме того, объекты класса Graph тоже не могут существовать обособленно от координатной плоскости.

Вот и всё! Мы рассмотрели достаточно элементов диаграммы классов, чтобы начать делать собственные диаграммы классов.

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

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

• Отношение ассоциации (association relationship)
• Отношение обобщения (generalization relationship)
• Отношение агрегации (aggregation relationship)
• Отношение композиции (composition relationship)

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

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

Ассоциация (association) — семантическое отношение между двумя и более классами, которое специфицирует характер связи между соответствующими экземплярами этих классов.

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

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

Наиболее простой случай данного отношения — бинарная ассоциация (binary association), которая служит для представления произвольного отношения между двумя классами. Она связывает в точности два различных класса и может быть ненаправленным (симметричным) или направленным отношением. Частный случай бинарной ассоциации — рефлексивная ассоциация, которая связывает класс с самим собой. Ненаправленная бинарная ассоциация изображается линией без стрелки. Для нее на диаграмме может быть указан порядок чтения классов с использованием значка в форме треугольника рядом с именем данной ассоциации.

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

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

В качестве простого примера направленной бинарной ассоциации можно рассмотреть отношение между двумя классами — классом Клиент и классом Счет (рис. 6.2). Они связаны между собой бинарной ассоциацией с именем Имеет, для которой определен порядок следования классов. Это означает, что конкретный объект класса Клиент всегда должен указываться первым при рассмотрении взаимосвязи с объектом класса Счет. Другими словами, эти объекты классов образуют кортеж элементов, например, <клиент, счет_1, счет_2,…, счет_n>.

Частный случай отношения ассоциации — так называемая исключающая ассоциация (Xor—association). Семантика данной ассоциации указывает на то, что из нескольких потенциально возможных вариантов данной ассоциации в каждый момент времени может использоваться только один. На диаграмме классов исключающая ассоциация изображается пунктирной линией, соединяющей две и более ассоциации (рис. 6.3), рядом с которой записывается ограничение в форме строки текста в фигурных скобках: {xor}.

Тернарная ассоциация связывает отношением три класса. Ассоциация более высокой арности называется n-арной ассоциацией.

n-арная ассоциация (n-ary association) — ассоциация между тремя и большим числом классов.

Каждый экземпляр такой ассоциации представляет собой упорядоченный набор (кортеж), содержащий n экземпляров из соответствующих классов. Такая ассоциация связывает отношением более чем три класса, при этом класс может участвовать в ассоциации более чем один раз. Каждый экземпляр n-арной ассоциации представляет собой n-арный кортеж, состоящий из объектов соответствующих классов. В этом контексте бинарная ассоциация является частным случаем n-арной ассоциации, когда значение n=2, но имеет собственное обозначение. Бинарная ассоциация — это специальный случай n-арной ассоциации.

Графически n-арная ассоциация обозначается ромбом, от которого ведут линии к символам классов данной ассоциации. Сам же ромб соединяется с символами классов сплошными линиями. Обычно линии проводятся от вершин ромба или от середины его сторон. Имя n-арной ассоциации записывается рядом с ромбом соответствующей ассоциации. Однако порядок классов в n-арной ассоциации, в отличие от порядка множеств в отношении, на диаграмме не фиксируется.

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

Класс может быть присоединен к линии ассоциации пунктирной линией. Это означает, что данный класс обеспечивает поддержку свойств соответствующей n-арной ассоциации, а сама n-арная ассоциация имеет атрибуты, операции и/или ассоциации. Другими словами, такая ассоциация является классом с соответствующим обозначением в виде прямоугольника и самостоятельным элементом языка UML — ассоциативным классом (Association Class).

Класс ассоциация (association class) — модельный элемент, который одновременно является ассоциацией и классом. Ассоциация класс может рассматриваться как ассоциация, которая обладает свойствами класса, или как класс, имеющий также свойства ассоциации.

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

Конец ассоциации (association end) — концевая точка ассоциации, которая связывает ассоциацию с классификатором.

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

Роль (role) — имеющее имя специфическое поведение некоторой сущности, рассматриваемой в определенном контексте. Роль может быть статической или динамической.

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

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

Так, для примера (рис. 6.4) кратность » 1 » для класса Компания означает, что каждый сотрудник может работать только в одной компании. Кратность » 1..* » для класса Сотрудник означает, что в каждой компании могут работать несколько сотрудников, общее число которых заранее неизвестно и ничем не ограничено. Вместо кратности » 1..* » нельзя записать только символ » * «, поскольку последний означает кратность » 0..* «. Для данного примера это означало бы, что отдельные компании могут совсем не иметь сотрудников в своем штате. Такая кратность приемлема в ситуациях, когда в компании вообще не выполняется никаких проектов.

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

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

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

• Диаграмма классов
• Диаграмма компонентов
• Схема развертывания
• Диаграмма объекта
• Схема пакета
• Схема составной структуры
• Диаграмма профиля

Что такое диаграмма классов?

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

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

UML — это нотация, возникшая в результате объединения OMT с

1. Техника объектного моделирования OMT  [ James Rumbaugh  1991] – лучше всего подходит для анализа и информационных систем с интенсивным использованием данных.
2. Booch [ Gradi Booch  1994] — отлично подходил для дизайна и реализации. Грэди Буч много работал с  языком Ада  и был главным игроком в разработке объектно-ориентированных методов для этого языка. Хотя метод Буча был сильным, нотация была принята хуже (в его моделях преобладало множество форм облаков — не очень аккуратно).
3. OOSE (Object-Oriented Software Engineering [ Ivar Jacobson  1992]) — включает модель, известную как варианты использования. Сценарии использования — это мощная техника для понимания поведения всей системы (область, в которой объектно-ориентированный подход традиционно был слабым).

В 1994 году Джим Рамбо, создатель OMT, ошеломил мир программного обеспечения, когда он покинул General Electric и присоединился к Грэди Бучу в Rational Corp. Целью партнерства было объединить их идеи в единый унифицированный метод (рабочее название метод действительно был «унифицированным методом»).

Назначение диаграммы классов

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

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

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

Ищете бесплатный инструмент для построения диаграмм классов?

Visual Paradigm Online (VP Online) Free Edition — это бесплатное онлайн-программное обеспечение для рисования, которое поддерживает диаграммы классов, другие диаграммы UML, инструменты ERD и инструменты организационных диаграмм. Он имеет простой, но мощный редактор, который позволяет быстро и легко создавать диаграммы классов. В этом бесплатном редакторе UML нет рекламы, нет сроков доступа и нет ограничений, например, на количество диаграмм, количество фигур и т. д. Вы являетесь владельцем диаграмм, которые создаете для личных и некоммерческих целей.

Ищете более формальное моделирование UML на рабочем столе?

Visual Paradigm Community Edition был запущен в 2004 году для предоставления  бесплатного программного обеспечения UML  исключительно для некоммерческих целей, поддержки пользователей, которые делали свои первые шаги в моделировании UML и которым требуется бесплатное и кросс-платформенное программное обеспечение для моделирования UML для личного использования, например как применение UML в студенческих проектах.

Бесплатный инструмент моделирования UML для всех видов некоммерческих целей. Поддержка 13 диаграмм UML 2.x

Нас приняли более 1 миллиона установок по всему миру, и эта цифра продолжает расти. Многие люди используют платные версии Visual Paradigm для ежедневного рисования профессиональных диаграмм UML и ERD для проектирования и анализа систем и баз данных.

Причина 2

Доверие ИТ-специалистов и крупных организаций

Многие крупные организации, ИТ-компании, консультанты, университеты, неправительственные организации и правительственные учреждения по всему миру приняли Visual Paradigm (платные версии). На рисунке ниже показаны некоторые из наших платных клиентов.

Причина 3

Высокое качество – награда

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

Причина 4

Самая широко используемая платформа для моделирования в академических кругах.

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

Причина 5

Сотни примеров UML и ERD,  готовых для импорта в Visual Paradigm для мгновенного эксперимента или для начала работы с собственной моделью UML. Все бесплатно.

Причина 6

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

Простое обновление для огромного набора дополнительных функций (например, BPMN и поддержки совместной работы) и для коммерческого использования, начиная с  6 долларов США в месяц .

Причина 7

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

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

Причина 8

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

Visual Paradigm может работать на разных платформах, таких как Windows, Linux и Mac. Его интуитивно понятный интерфейс и мощные функции моделирования делают моделирование быстрым и легким!

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

• между классами и объектами на диаграмме классов;
• между пакетами;
• между вариантами использования;
• другие.

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

Табл. Стандартные стереотипы зависимостей на диаграмме классов

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

Рассмотрим отношение реализации. Между интерфейсами и другими классификаторами, в частности, классами, на
диаграмме классов применяются два отношения:

• классификатор (в частности, класс) использует интерфейс ‒ это показывается с помощью
  зависимости со стереотипом «call»;
• классификатор (в частности, класс) реализует интерфейс ‒ это показывается с помощью отношения
  реализации.

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

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

Используя нотацию «чупа-чупс», появившуюся в UML 2, эту же модель можно изобразить лаконично,
симметрично и просто, как показано ниже.

ИЗМЕНЕНИЯ В ТЕХНИЧЕСКОМ ЗАДАНИИ

Каждая структурная единица предприятия (подразделение, должность) должна иметь свое название.

ИЗМЕНЕНИЯ В ТЕХНИЧЕСКОМ ЗАДАНИИ

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

ИЗМЕНЕНИЯ В ТЕХНИЧЕСКОМ ЗАДАНИИ

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

видимость ИМЯ : тип

ИЗМЕНЕНИЯ В ТЕХНИЧЕСКОМ ЗАДАНИИ

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

ИЗМЕНЕНИЯ В ТЕХНИЧЕСКОМ ЗАДАНИИ

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

ИЗМЕНЕНИЯ В ТЕХНИЧЕСКОМ ЗАДАНИИ

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

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

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

Класс
— один из самых «богатых» элементов
моделирования UML.
Описание класса может включать множество
различных элементов, и чтобы они не
путались, в языке предусмотрено
группирование элементов описания класса
по разделам.
Стандартных
разделов три:

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

• раздел
  атрибутов — содержит список описаний
  атрибутов класса;

• раздел
  операций — содержит список описаний
  операций класса.

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

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

Раздел
имени класса в общем случае имеет
следующий синтаксис.

«стереотип»
ИМЯ {свойства} кратность.

В
табл. 2 перечислены стандартные стереотипы
классов.

Таблица
2. Стандартные
стереотипы классов

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

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

Кратность
класса задается по общим правилам.
Наиболее распространенный случай
неограниченной кратности (т. е. класс
может иметь произвольное значение
экземпляров) подразумевается по умолчанию
и никак не отражается на диаграмме
классов. Другой распространенный случай
— нулевая кратность — обычно представляется
с помощью стандартного стереотипа
«utility»
(см.
табл. 2).

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

Если
мы предполагаем, что проектируемая
информационная система отдела кадров
будет использоваться на одном предприятии,
то целесообразно определить служебный
класс Company
со
стереотипом utility
для
хранения глобальных атрибутов и операций
информационной системы отдела кадров.
Раздел имени такого класса показан на
рисунке 3.3.

Рисунок
3.3. Раздел имени службы

Атрибут
— это именованное место (или, как говорят,
слот),
в котором может храниться значение.

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

видимость
ИМЯ кратность : тип = начальное значение
{свойства}

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

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

Подчеркивание
описания атрибута соответствует
описателю static
в языке С++. Кратность,
если она присутствует, определяет данный
атрибут как массив (определенной или
неопределенной длины).

Тип
атрибута — это либо примитивный
(встроенный) тип, либо тип определенный
пользователем.

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

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

У
атрибутов имеется еще одно стандартное
свойство: изменяемость.
В табл. 3 перечислены возможные значения
этого свойства.

Таблица
3.
Значения
свойства изменяемости атрибута

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

Таблица
4.
Примеры
описаний атрибутов

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

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

Описания
операций класса перечисляются в разделе
операций и имеют следующий синтаксис:

видимость
ИМЯ (параметры) : тип {свойства}

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

направление
ПАРАМЕТР : тип = значение

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

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

Таблица
5.
Ключевые
слова для описания направления передачи
параметров

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

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

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

Во-первых,
это concurrency
—
свойство, определяющее семантику
одновременного (параллельного) вызова
данной операции. В приложениях, где
имеется только один поток управления,
никаких параллельных вызовов быть не
может. Действительно, если операция
вызвана, то выполнение программы
приостанавливается в точке вызова до
тех пор, пока не завершится выполнение
вызванной операции. В однопоточных
приложениях в каждый момент времени
управление находится в одной определенной
точке программы и выполняется ровно
одна определенная операция. Рекурсивный
вызов (т. е. вызов операции из нее самой)
не считается параллельным, поскольку
при рекурсивном вызове выполнение
операции, как обычно, приостанавливается
и, таким образом, всегда выполняется
только один экземпляр рекурсивной
операции. Не так обстоит дело в приложениях,
где имеется несколько потоков управления.
В таком случае операция может быть
вызвана из одного потока и в то время,
пока ее выполнение еще не завершилось,
вызвана из другого потока. Значение
свойства concurrency
определяет,
что будет происходить в этом случае.
Возможные варианты и их описания даны
в табл. 6.

Таблица
6.
Значения
свойства concurrency

Во-вторых,
операция имеет свойство isQuery,
значение которого указывает, обладает
ли операция побочным
эффектом.
Если значение данного свойства true,
то выполнение операции не меняет
состояния системы — операция только
вычисляет значения, возвращаемые в
точку вызова.⁶
В противном случае, т. е. при значение
false,
операция меняет состояние системы:
присваивает новые значения атрибутам,
создает или уничтожает объекты и т. п.
По умолчанию операция имеет свойство
{isQuery=false}.
Поэтому, если нужно указать, что данная
операция — это функция без побочных
эффектов, то достаточно написать
{isQuery}.
Рассмотрим примеры описания возможных
операций класса Person
информационной системы отдела кадров
(табл. 7).

Таблица
7.
Примеры
описания операций

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

• между
  классами и объектами на диаграмме
  классов;

• между
  пакетами;

• между
  вариантами использования;

• между
  объектами на диаграмме взаимодействия;

• между
  состояниями автомата;

• между
  подсистемами и моделями.

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

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

Таблица
8.
Стандартные
стереотипы зависимостей на диаграмме
классов

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

Рассмотрим
пример. В информационной системе отдела
кадров мы выделили классы Position,
Department
и Person.
Резонно предположить, что все эти классы
имеют атрибут, содержащий собственное
имя объекта, выделяющее его в ряду
однородных. Для простоты положим, что
такой атрибут имеет тип String.⁷
В
таком случае можно определить суперкласс,
ответственный за хранение данного
атрибута и работу с ним, а прочие классы
связать с суперклассом отношением
обобщения. Однако более пристальный
анализ предметной области наводит на
мысль, что работа с собственным именем
для выделенных классов производится
не совсем одинаково. Действительно,
назначение и изменение собственных
имен подразделениям и должностям
находится в пределах ответственности
информационной системы отдела кадров,
но назначение (изменение) собственного
имени сотрудника явно выходит за эти
пределы.⁸
Исходя из этих соображений, мы приходим
к структуре обобщений, представленной
на рисунке 3.4. Обратите внимание, что
суперкласс Unit
мы
определили как абстрактный, т. е. не
могущий иметь непосредственных
экземпляров, поскольку не предполагаем
иметь в системе объекты данного класса.
Класс Unit
в
данном нужен только для того, чтобы
свести описания одного атрибута и двух
операций в одно место и не повторять их
дважды.

Рисунок
3.4 – Отношение обобщения

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

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

Тогда
данную ситуацию можно описать с помощью
диаграммы, приведенной на рисунке 3.5.
Классы Male
и Female
являются экземплярами метакласса
Gender.
Классы Owner
и Employe
являются экземплярами метакласса
Status.
Это видно из имен подмножеств обобщений,
указанных возле пунктирных линий,
выделяющих подмножества. Классификация
по полу является завершенной и дизъюнктной.
Классификация по отношению собственности,
напртив, не является ни завершенной, ни
дизъюнктной.

Рисунок
3.5. Подмножества обобщений и метаклассы

Иногда
бывает важно указать, что некоторый
объект является экземпляром конкретного
класса. Это делается с помощью стереотипа
instanceOf
(Рисунок
3.6). Далее, обычно конструктор объектов
класса определяется в классе. Но иногда
конструктор помещают в другой класс,
который в таком случае называют фабрикой.
На рисунке 3.6 объект (единственный)
класса Company
является
фабрикой объектов классов Department
и
Person,
а
объект класса Department
является
фабрикой объектов класса Position

Рисунок
3.6. Инстанциирование и спецификация
экземпляра

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

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

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

• имя
  ассоциации (возможно, вместе с направлением
  чтения);

• кратность
  полюса ассоциации;

• вид
  агрегации полюса ассоциации;

• роль
  полюса ассоциации;

• направление
  навигации полюса ассоциации;

• упорядоченность
  объектов на полюсе ассоциации;

• изменяемость
  множества объектов на полюсе ассоциации;

• квалификатор
  полюса ассоциации;

• класс
  ассоциации;

• видимость
  полюса ассоциации;

• многополюсные
  ассоциации.

Начнем
по порядку. Имя
ассоциации
указывается в виде строки текста над
(или под, или рядом с) линией ассоциации.
Имя не несет дополнительной семантической
нагрузки, а просто позволяет различать
ассоциации в модели. Обычно имя не
указывают, за исключением многополюсных
ассоциаций или случая, когда одна и та
же группа классов связана несколькими
различными ассоциациями. Например, в
информационной системе отдела кадров,
если сотрудник занимает должность, то
соответствующие объектов классов Person
и Position
должны быть связаны. Дополнительно
можно указать направление чтения имени
ассоциации. Фрагмент графической модели,
приведенный на рисунке 3.7, фактически
можно прочитать вслух:

Рисунок
3.7. Имя ассоциации

Кратность
полюса ассоциации
указывает, сколько объектов данного
класса (со стороны данного полюса)
участвуют в связи. Кратность может быть
задана как конкретное число, и тогда в
каждой связи со стороны данного полюса
участвуют ровно столько объектов,
сколько указано. Более распространен
случай, когда кратность указывается
как диапазон возможных значений, и тогда
число объектов, участвующих в связи
должно находится в пределах указанного
диапазона. При указании кратности можно
использовать символ *, который обозначает
неопределенное число. Например, если в
информационной системе отдела кадров
не предусматривается дробление ставок
и совмещение должностей, то (работающему)
сотруднику соответствует одна должность,
а должности соответствует один сотрудник
или ни одного (должность вакантна). На
рисунке 3.8 приведен соответствующий
фрагмент диаграммы UML.

Рисунок
3.8. Кратность полюсов ассоциации

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

Рисунок
3.9. Использование неопределенной
кратности

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

Агрегация
от класса A
к классу B
означает, что объекты (один или несколько)
класса A
входят в состав объекта класса B.

Это
отмечается с помощью специального
графического дополнения: на полюсе
ассоциации, присоединенному к «целому»,
т. е., в данном случае, к классу B,
изображается ромб. Например, на рисунке
3.10 указано, что подразделение является
частью компании.

Рисунок
3.10. Агрегация

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

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

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

Рисунок
3.11. Сравнение композиции (вверху) и
агрегации (внизу)

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

Рисунок
3.12. Структура связей классов информационной
системы отдела кадров

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

видимость ИМЯ :
тип

Имя
является обязательным, оно называется
именем
роли
и фактически является собственным
именем полюса ассоциации, позволяющим
различать полюса. Если рассматривается
одна ассоциация, соединяющая два
различных класса, то в именах ролей нет
нужды: полюса ассоциации легко можно
различить по именам классов, к которым
они присоединены. Однако, если это не
так, т. е. если два класса соединены
несколькими ассоциациями, или же если
ассоциация соединяет класс с самим
собой, то указание роли полюса ассоциации
является необходимым. Такая ситуация
отнюдь не является надуманной, как может
показаться. Вернемся к рисунку 3.12, где
мы, забегая вперед, начали разбор примера
на эту тему. На этом рисунке изображена
ассоциация класса Position
с самим собой. Эта ассоциация призвана
отразить наличие иерархии подчиненности
должностей в организации. Однако из
рисунка 3.12 видно только, что объекты
класса Person
образуют некоторую иерархию (каждый
объект связан с некоторым количеством
нижележащих в иерархии объектов и не
более чем с одним вышележащим объектом),
но не более того. Используя спецификацию
интерфейсов и, заодно, (опять несколько
забегая вперед) отношения реализации
и интерфейсы можно описать субординацию
в информационной системе отдела кадров
достаточно лаконично, но точно. Например,
на рисунке 3.13 указано, что в иерархии
субординации каждая должность может
играть две роли. С одной стороны, должность
может рассматриваться как начальственная
(chief),
и в этом случае она предоставляет
интерфейс IChief⁹
имеющий операцию petition
(начальнику можно подать служебную
записку). С другой стороны, должность
может рассматриваться как подчиненная
(subordinate),
и в этом случае она предоставляет
интерфейс ISubordinate,
имеющий операцию report
(от подчиненного можно потребовать
отчет). У начальника может быть произвольное
количество подчиненных, в том числе и
0, у подчиненного может быть не более
одного начальника.

Рисунок
3.13. Роли полюсов ассоциации

Имя
в виду ту же самую цель, можно поступить
и по-другому: непосредственно включить
в описание класса составляющие,
ответственные за обеспечение нужной
функциональности ( Рисунок 3.14). Однако
такое решение «не в духе» UML:
во-первых, оно слишком привязано к
реализации, разработчику не оставлено
никакой свободы для творческих поисков
эффективного решения; во-вторых оно
менее наглядно — неудачный выбор имен
атрибутов способен замаскировать
семантику отношения для читателя модели,
потеряны информативные имена ролей и
ассоциации; в- третьих, оно менее надежно
— в модели на рисунке 3.13 подчиненный
синтаксически не может потребовать
отчета от начальника, а в модели на
рисунке 3.14 — может, и нужно предусматривать
дополнительные средства для обработки
этой ошибки.

Рисунок
3.14. Атрибуты, обеспечивающие реализацию
ролей

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

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

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

Рисунок
3.15. Направление навигации

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

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

Рисунок
3.16. Ограничение видимости полюса
ассоциации

Обратите
внимание, что, согласно семантическим
правилам UML,
ограничение видимости полюса pwd
распространяется на объекты класса
Workgroup,
но не на объекты класса User
— непосредственно связанные объекты
всегда видят друг друга. Объект класса
User
может использовать интерфейс pwd,
предоставляемый классом Password
— стрелка навигации разрешает ему это,
но объект класса Workgroup
не может использовать интерфейс pwd
— значение видимости private
(знак -) запрещает ему это.

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

Упорядоченность
объектов на полюсе ассоциации.
Ели кратность полюса лежит в диапазоне
0..1, то проблемы упорядоченности не
возникает — на данном полюсе связи,
возможно, имеется один объект, но не
более того. При иных кратностях объектов
может быть несколько, т. е. полюс связи
присоединен к множеству объектов. По
умолчанию множество объектов,
присоединенных к данному полюсу связи,
считается неупорядоченным (как и любое
множество, если не оговорено противное).
Если необходимо указать, что это множество
упорядочено (см. пример ниже и рисунок
3.17), то нужно наложить соответствующее
ограничение на полюс ассоциации. В
качестве ограничения используется одно
из двух ключевых слов:

• ordered
  (или sorted)
  если множество упорядочено;

• unordered,
  если
  не упорядочено.

Обычно
считается, что множество объектов на
полюсе связи может изменяться произвольным
образом (в пределах специфицированной
кратности). Например, в один момент
работы информационной системы отдела
кадров в данном подразделении может
быть одних 10 должностей, а в другой —
20 других. Совершенно аналогично, значение
атрибута обычно может произвольным
образом меняться в процессе жизни
объекта (в пределах указанного типа
атрибута). Однако иногда необходимо
определенным образом ограничить
изменяемость атрибута. Аналогично
иногда нужно ограничить изменяемость
состава
множества объектов присоединенных к
полюсу связи (экземпляру ассоциации).
Для этого применяется тот же самый набор
стандартных значений. В информационной
системе отдела кадров мы не нашли
походящего примера, и для иллюстрации
двух последних понятий используем
пример из вычислительной геометрии.
Допустим, что у нас есть класс Point,
экземплярами которого являются точки
(на плоскости). Многоугольник (Polygon)
можно определить, как упорядоченное
множество точек (вершин многоугольника),
причем резонно предположить, что состав
вершин данного многоугольника, после
того, как он определен, не может меняться.
Модель данной ситуации приведена на
рисунке 3.179.

Рисунок
3.17. Упорядоченность и изменяемость
множества объектов на полюсе связи

Рассмотрим
ситуацию, когда два класса связаны
ассоциацией «один ко многим» (именно
этот случай имеет место в данном примере).
Такая ассоциация доставляет для каждого
экземпляра класса, находящегося на
полюсе «один» множество (иногда
большое) объектов класса, находящегося
на полюсе «много». Например, по
экземпляру многоугольника можно получить
множество его вершин. Однако часто
возникают ситуации, когда нужно получить
не все множество ассоциированных
объектов, а некоторое небольшое
подмножество, чаще всего один конкретный
объект. Чтобы выделить из множества
один конкретный элемент, нужно располагать
информацией, однозначно идентифицирующей
этот элемент. Такую информацию принято
называть ключом. Например, номер вершины
в многоугольнике можно считать ключом
и тогда задача ставится так: по
многоугольнику и номеру вершины получить
вершину. Всегда можно применить следующее
тривиальное решение: хранить ключ в
самом объекте в качестве атрибута и,
получив множество объектов, перебирать
их все последовательно до тех пор, пока
не найдется тот, который имеет искомое
значение ключа. Такой прием называется
линейным
поиском.
Для многоугольников, у которых не очень
много вершин, данный способ может быть
вполне приемлемым. Но в других случаях,
когда к полюсу «много» присоединено
действительно много
объектов, линейный поиск слишком
неэффективен. Известно множество
программных решений, позволяющих
эффективно выделить (найти в множестве)
объект по ключу: сортированные массивы,
таблицы расстановки (хэш-таблицы),
деревья сортировки, внешние индексы и
др. Эти приемы обобщены в UML
понятием квалификатора.

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

Квалификатор
изображается в виде небольшого
прямоугольника на полюсе ассоциации,
примыкающего к прямоугольнику класса.
Внутри этого прямоугольника (или рядом
с ним) указывается имена и, возможно,
типы атрибутов квалификатора. Описание
квалифицирующего атрибута ассоциации
имеет такой же синтаксис, что и описание
обычного атрибута класса, только оно
не может содержать начального значения.
Квалификатор может присутствовать
только на том полюсе ассоциации, который
имеет кратность «много», поэтому,
если на полюсе ассоциации с квалификатором
задана кратность, то она указывает не
допустимую мощность множества объектов,
присоединенных к полюсу связи, а
допустимую мощность того подмножества,
которое определяется при задании
значений атрибутов квалификатора.
Например, на рисунке 3.18 приведен фрагмент
модели для примера с многоугольниками,
в котором использован квалификатор (в
данном случае с именем number).
Обратите внимание, что на полюсе
ассоциации с квалификатором, присоединенном
к классу Point,
указана кратность 0..1
(а не *, как на Рисунок 3.17). Действительно,
само наличие квалификатора указывает
на кратность много, а кратность 0.. 1
указывает сколько вершин с конкретным
номером связано с данным многоугольником:
1, если задан допустимый номер вершины,
или 0 в противном случае.

Рисунок
3.18. Квалификатор

Ассоциация
имеет экземпляры (связи), стало быть,
является классификатором и может
обладать соответствующими свойствами
и составляющими классификатора. В
распространенных случаях, рассмотренных
выше, ассоциации не обладали никакими
собственными составляющими. Грубо
говоря, ассоциация между классами A
и B
— это просто множество пар (a,b),
где а
— объект класса A,
а b
— объект класса B.
Подчеркнем еще раз, что это именно
множество: двух одинаковых пар (a,b)
быть не может. Однако возможны и более
сложные ситуации, когда ассоциация
имеет собственные атрибуты (и даже
операции), значения которых хранятся в
экземплярах ассоциации — связях. В
таком случае применяется специальный
элемент моделирования — класс ассоциации.

Класс
ассоциации
— это сущность, которая имеет как
свойства класса, так и свойства ассоциации.

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

Вернемся
к информационной системе отдела кадров
и рассмотрим следующий пример. Допустим,
что имеет место более сложное отношение
между должностями и сотрудниками, нежели
те, что приведены на рисунке 3.10 и 3.11. А
именно, допускается не только совмещение
должностей (один сотрудник может работать
на нескольких должностях), но и дробление
ставок (одну должность могут занимать
несколько сотрудников — полставки,
четверть ставки и т. п.). Использую уже
разобранную нотацию ассоциации, мы
можем констатировать, что между классами
Person
и
Position
имеет
место ассоциация «многие ко многим».
Однако этого недостаточно: необходимо
указать, какую долю данной должности
занимает данный сотрудник. Эту информацию
нельзя отнести ни к должности, ни к
сотруднику — это атрибут класса
ассоциации между ними (Рисунок 3.19).

Рисунок
3.19.
Класс
ассоциации

Может
показаться, что понятие класса ассоциации
в UML
является надуманным и излишним.
Действительно, можно применить стандартный
прием нормализации, который часто
используется при проектировании схем
баз данных: систематическим образом
избавиться от отношений «многие ко
многим» путем введения дополнительной
сущности и двух отношений «один ко
многим». Применительно к данному
примеру такой прием дает решение,
приведенное на рисунке 3.20.

Рисунок
3.20. Элиминация отношения «многие ко
многим” с помощью введения дополнительной
сущности

На
первый взгляд, модели на рисунке 3.19 и
3.20 выглядят семантически эквивалентными,
однако это не так — здесь есть тонкое
различие. В случае использования класса
ассоциации Job,
который по определению является
множеством пар должность-сотрудник, не
может быть двух одинаковых пар. То есть
не может быть так, чтобы Новиков занимал
полставки доцента и еще (отдельно)
четверть той же ставки. В случае же
промежуточного класса Job
это, вообще говоря, вполне возможно, что
не совсем естественно. Опытные
проектировщики баз данных нам могут
возразить, что это вполне поправимо:
нужно ввести в классах Position
и Person
атрибуты, которые будут уникальными
ключами, идентифицирующими объекты
этих классов, а в классе Job
ввести пару атрибутов, значениями
которых будут ключи классов Position
и Person
и потребовать, чтобы эта пара атрибутов
была уникальным составным ключом класса
Job.

Чаще
всего используются бинарные ассоциации,
отражающие связи между объектами двух
классов. В UML
определены также многополюсные
ассоциации, отражающие
связи между большим числом объектов. С
формальной точки зрения многополюсные
ассоциации излишни, поскольку их можно
выразить через комбинацию бинарных
ассоциаций введением дополнительных
сущностей. Действительно, упорядоченную
тройку объектов (a,
b,
с)
— элемент трехполюсной ассоциации —
можно представить как упорядоченную
пару (a,
d),
где d
— новый объект, представляющий
упорядоченную пару (b,
с).
Однако на практике (в некоторых случаях)
многополюсные ассоциации бывают
буквально незаменимы. Рассмотрим
следующий пример из информационной
системы отдела кадров. Допустим, что в
организации применяется современная
организационная форма управления и
помимо иерархии подразделений и
должностей существует структура
выполняемых проектов, «пронизывающих»
организацию.¹⁰
Один и тот же сотрудник может участвовать
во многих проектах, выполняя различные
обязанности (т. е. занимая различные
должности), в каждом проекте (частично)
заняты многие сотрудники и размер оплаты
труда зависит от того, сколько конкретно
времени проработал данный сотрудник в
данной должности в данном проекте. Такую
замысловатую (но весьма жизненную!)
ситуацию очень легко отобразить,
используя многополюсные ассоциации и
классы ассоциации (Рисунок 3.21). Чтобы
полностью оценить полезность многополюсных
ассоциаций и классов ассоциаций, мы
советуем читателям проделать весьма
поучительное упражнение: попытаться
построить модель, семантически
эквивалентную модели на рисунке 3.21, но
не использующую многополюсных ассоциаций
и классов ассоциаций (подсказка: придется
ввести дополнительные сущности и
отношения).

Рисунок
3.21. Многополюсная ассоциация

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

Рисунок
3.22. Метамодель ассоциации

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

Интерфейс
— это именованный набор абстрактных
операций.

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

Между
интерфейсами и другими классификаторами,
в частности классами, на диаграмме
классов применяются два отношения:

• классификатор
  (в частности, класс) использует интерфейс
  — это показывается с помощью зависимости
  со стереотипом «call»;

• классификатор
  (в частности, класс) реализует интерфейс
  — это показывается с помощью отношения
  реализации.

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

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

Роль
— это интерфейс, который предоставляет
классификатор в данной ассоциации.

Продолжая
пример информационной системы отдела
кадров, начатый на рисунке 3.13, дополним
его иллюстрацией использования
зависимости со стереотипом «call».
Допустим, что класс Department
для реализации операций связанных с
движением кадров, использует операции
класса Position,
позволяющие занимать и освобождать
должность — другие операции класса
Position
классу Department
не нужны. Для этого, как показано на
рисунке 3.23 можно определить соответствующий
интерфейс IPosition
и связать его отношениями с данными
классами.

Рисунок
3.23. Отношения реализации и использования
интерфейсов

Используя
нотацию «чупа-чупс», появившуюся в UML
2.0, эту же модель можно изобразить
лаконично, симметрично и просто, как
показано на рисунке 3.24.

Рисунок
3.24. Использование нотации «чупа-чупс»

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

Здесь
уместно дать точные ответы на два важных
вопроса.

• Для
  каких элементов модели можно указать
  тип?

• Что
  можно использовать в качестве указания
  типа?

В
UML
типизированы могут быть:

• атрибуты
  классов, в том числе классов ассоциаций;

• параметры
  операций, в том числе тип возвращаемого
  значения;

• роли
  полюсов ассоциаций;

• квалификаторы
  полюсов ассоциаций;

• параметры
  шаблонов.

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

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

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

• Примитивные
  типы, которые считаются предопределенными
  в UML
  — таковых, как минимум, три: строка,
  целое число и значение даты/времени.
  Инструменты вправе расширять этот
  набор и использовать подходящие
  названия.

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

• Типы
  данных, которые определены в модели. В
  стандарте UML
  предусмотрен только один конструктор
  типов данных: перечислимый тип, который
  определяется с помощью стереотипа
  «enumeration».

В
частности, тип Boolean
определен в UML
как перечислимый тип со значениями true
и false.
Приведем пример: допустим, в нашем
приложении нужно использовать не обычную
двузначную логику, а трехзначную. Тогда
соответствующий можно определить так,
как показано на рисунке 3.25.

Рисунок
3.25. Перечислимый тип данных «Трехзначная
логика»

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

Возникает
вопрос: чем же типы данных отличаются
от прочих классификаторов UML?

Тип
данных
(в
UML)
— это классификатор, экземпляры которого
не обладают индивидуальностью (identity).

Это
довольно тонкое понятие, которое мы
попробуем объяснить на примере. Рассмотрим
какой-нибудь встроенный тип данных в
обычном языке программирования, например,
тип integer
в языке Паскаль. Значения этого типа
(экземпляры классификатора) изображаются
обычным образом, например, 3. Что будет,
если число «три» используется в
нескольких местах программы? Отличатся
ли чем-нибудь экземпляры изображения
3? Очевидно, нет. Экземпляры типа integer
не обладают индивидуальностью, мы вправе
считать, что написанные в разных местах
изображения числа 3 суть одно и то же
число, а компилятор вправе использовать
для хранения представления числа «три»
одну и ту же ячейку, сколько бы изображений
числа 3 ни присутствовало в программе.
Далее, программисту не нужно предусматривать
никаких инициализирующих действий, для
того, чтобы воспользоваться числом 3 —
не нужно определять никаких объектов,
не нужно вызывать никаких конструкторов.
Можно считать, что все значения типа
данных уже определены и всегда существуют,
независимо от программы. Более того, с
числом «три» ничего не может
случиться — чтобы ни происходило в
программе, число «три» останется
числом «три» и никогда не станет
числом » пять».

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

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

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

• Операции
  типа данных всегда обладают свойством
  isQuery.

• Операции
  типов данных считаются не повторно
  входимыми и обладают свойством sequential
  .

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

ИМЯ
: тип

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

• явное
  связывание
  — зависимость со стереотипом «bind»,
  в которой указаны значения аргументов;

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

имя_шаблона
< аргументы >

Рассмотрим
пример (Рисунок 3.26). Здесь определен
шаблон Array,
имеющий два параметра: n
типа Integer
и T,
тип которого не указан. Этот шаблон
применяется для создания массивов
определенной длины, содержащих элементы
определенного типа. В данном случае с
помощью явного связывания определен
класс Triangle
как массив из трех элементов типа Point.
С помощью неявного связывания определен
аналогичный по смыслу класс с именем
Array<3,Point>.

Рисунок
3.26. Связывание шаблона: неявное (вверху),
явное (внизу)

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

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

• Описывать
  структуру удобнее параллельно с
  описанием поведения. Каждая итерация
  должна быть небольшим уточнением как
  структуры, так и поведения.

• Не
  обязательно включать в модель все
  классы сразу. На первых итерациях
  достаточно идентифицировать очень
  небольшую (10%) долю всех классов системы.

• Не
  обязательно определять все свойства
  класса сразу. Начните с имени — операции
  и атрибуты постепенно выявятся в
  процессе моделирования поведения.

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

• Не
  обязательно определять все отношения
  между классами сразу. Пусть класс на
  диаграмме «висит в воздухе» —
  ничего с ним не случится.

Сущности на диаграмме классов

Свойства классификаторов

1. Имя

2. Экземпляры

3. Абстрактный

• не может иметь прямых экземпляров
• имя выделяется курсивом

4. Видимость

• может ли составляющая одного классификатора использоваться в другом
• открытый        + public        — виден везде
• защищенный  # protected  — виден в контейнере
• закрытый        — private       — виден в своем элементе
• пакетный        ∼package    — виден в своем пакете

5. Область действия

• определяет, как проявляет себя составляющая классификатора в экземплярах: используется общее значение или у каждого экземпляра свое
• экземпляр (instance) — по умолчанию
• классификатор (classifier) — подчеркивается

6. Кратность

• Все допустимые значения мощности Нижняя граница … ВЕРХНЯЯ ГРАНИЦА
• кратность 0 нет экземпляров служба (utility)
• кратность 1 ровно один одиночка (singleton)
• кратность 8 фиксированное число (e. g. концентратор)
• кратность * произвольное число по умолчанию

7. Могут участвовать в отношении обобщения

Класс — один из самых богатых элементов моделирования UML.

Секции:

• Секция имени
  • «стереотип» ИМЯ {свойства} кратность
• Секция атрибутов
  • список описаний атрибутов
• Секция операций
  • список описаний
  операций
  + доп. секции = примечания

Атрибут — именованное место, в котором может храниться какое-то значение.

видимость ИМЯ [кратность] : тип = начальное значение {свойства}

• Видимость: + — # ∼
• ИМЯ: атрибут экземпляра, ИМЯ: атрибут класса
• Кратность: определяет атрибут как массив
• Тип: примитивный / определенный пользователем
• Начальное значение: при создании экземпляра атрибут получает указанное значение
• Свойства: ограничения и именованные значения, e.g. изменяемость (changeability)

Примеры описания атрибутов

Операции и методы

Операция — спецификация действия с объектом.

Метод — выполняемый алгоритм.

• Видимость: + — # ∼
• ИМЯ: операция экземпляра, ИМЯ: операция класса, ИМЯ: абстрактная операция
• Параметры:
  направление ПАРАМЕТР : тип = значение

Свойства операций

1. Параллелизм — когда имеется несколько потоков управления

2. Побочные эффекты

• True — не меняет состояния системы
• False (по умолчанию) — операция меняет состояние системы:
  присваивает новые значения атрибутам, создает или уничтожает объекты и т. п.

Примеры описания операций

Параметры

Интерфейсы и типы данных

Идентификация классов

1. Словарь предметной области: существительные в ТЗ

2. Реализация вариантов использования

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

Отношения на диаграмме классов

Отношения зависимости

Стандартные стереотипы зависимости между классами и объектами

Отношение реализации

Классификатор использует интерфейс — зависимость со стереотипом «call» (требуемый интерфейс).

Классификатор реализует интерфейс — реализация (обеспеченный интерфейс).

Пример реализации и использования интерфейсов

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

Применение обобщений:

• Множественное наследование 
  • Класс является подклассом нескольких суперклассов
• Несколько иерархий обобщения
  • Не требуется, чтобы у базовых классов был общий
  суперкласс
• Ограничение: частичная упорядоченность
  • Отсутствие циклов в цепочках обобщений

Пример:

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

Отношение ассоциации
Ассоциация в UML — это классификатор, экземпляры которого называются связями (link)

• Минимум:
  Объекты ассоциированных классов могут взаимодействовать во время выполнения

Имя ассоциации

Между классами должно быть отношение ассоциации (1) и может быть имя (2), поясняющее ее назначение. Дополнительно можно указать направление чтения имени ассоциации (3).

Кратность полюса ассоциации

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

* — неопределенное число

Агрегация и композиция
Агрегация — это ассоциация между классом А (часть) и классом В (целое)

• Не изменяет направления навигации и не накладывает ограничений на время жизни

Композиция — более сильные ограничения:

• Часть А может входить только в одно целое В
• Время жизни частей совпадает с временем жизни целого

Примеры агрегации и композиции

Структура элементов системы

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

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

Ассоциация класса Position самим с собой (1). На полюсах ассоциации указаны роли (2). Значок, показывающий направление чтения (3) позволяет прочесть данную ассоциацию как “Chief subordinates Subordinate”. Эта ассоциация призвана отразить наличие иерархии подчиненности должностей в организации.

Уточнение предыдущей схемы:

Направление навигации

Для отображения факта возможности или не возможности навигации для данного полюса ассоциации применяется следующая нотация: если навигация для некоторого полюса возможна, то этот полюс отмечают стрелкой на конце линии ассоциации (1), если же навигация не возможна, то на конце линии ассоциации рисуют косой крестик (2).

Многополюсные ассоциации

Класс ассоциации

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

Ограничения на полюсах ассоциации
Упорядоченность объектов (ordering) / уникальность (uniqueness) — наличие / отсутствие одинаковых объектов

Упорядоченность и изменяемость

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

Основное назначение квалификатора ‒ снизить кратность противоположного полюса ассоциации, поэтому в основном он используется в ассоциациях с кратностями полюсов «один ко многим» или «многие ко многим» и стоит у полюса противоположному полюсу с кратностью «много».

Основная диаграмма классов

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

Список типов диаграмм UML

Итак, каковы же различные типы диаграмм UML? Существуют две основные категории: структурные диаграммы и поведенческие диаграммы. Щелкните по ссылкам, чтобы узнать больше о конкретном типе диаграммы.

• Структурные диаграммы
  • Диаграмма классов
  • Диаграмма компонентов
  • Диаграмма развертывания
  • Диаграмма объектов
  • Диаграмма пакета
  • Диаграмма профиля
  • Диаграмма композитной структуры
• Поведенческие диаграммы
  • Диаграмма вариантов использования
  • Диаграмма деятельности
  • Диаграмма машины состояний
  • Диаграмма последовательности
  • Диаграмма связи
  • Диаграмма обзора взаимодействия
  • Временная диаграмма

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

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

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

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

Ниже приведено изображение диаграммы классов. Перейдите по ссылке ниже для просмотра примеров диаграмм классов или начните работу с нашими Шаблоны диаграмм.

Получить больше примеров диаграмм классов UML >>

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

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

Получить больше шаблонов диаграмм компонентов >>

Диаграмма развертывания

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

Получить больше шаблонов диаграмм развертывания >>

Диаграмма объектов

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

Получить больше шаблонов диаграмм объектов >>

Диаграмма пакета

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

Диаграмма профиля

Диаграмма профиля – это новый тип диаграмм, введенный в UML 2. Это тип диаграммы, который очень редко используется в каких-либо спецификациях. Для получения дополнительных шаблонов диаграмм профилей посетите наше сообщество диаграмм

Диаграмма композитной структуры

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

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

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

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

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

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

Получить больше шаблонов диаграмм деятельности >>

Диаграмма машины состояний

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

Получить больше примеров диаграмм состояния >>

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

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

Диаграмма связи

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

Диаграмма обзора взаимодействия

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

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

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