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

Предисловие

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

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

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

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

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

Использование ООП может существенно упросить жизнь программисту. Это достигается за счёт сокрытия особенностей внутренней реализации классов. Программисту остаётся лишь пользоваться её удобствами. Кажется, что ООП – панацея от всех проблем. Однако на практике, если не иметь чёткого представления о том, какие классы нужно реализовать и как ими потом пользоваться, в результате может получиться очень запутанная система, которая начнёт порождать спагетти-коду (от англ. “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, следует перейти к их последовательному рассмотрению.

Типы отношений на диаграмме классов

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

• Отношение
  зависимости
  (dependency
  relationship).

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

• Отношение
  обобщения
  (generalization
  relationship).

• Отношение
  реализации
  (realization
  relationship).

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

Для
отношения
ассоциации
используется
понятие
арности
— количество
классов,
участвующих
в
данном
отношении.
Бинарная
ассоциация
(в
отношении
участвуют
два
класса)
является
частным
случаем
N-арной
ассоциации.

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

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

Отношение
обобщения
является отношением между более общим
классом
(классом-родителем)
и более частным классом
(классом-потомком).
При этом предполагается, что класс-потомок
обладает всеми свойствами и поведением
класса-потомка,
а также может иметь свои собственные
свойства и поведение, которые отсутствуют
у класса-родителя
см. рис. 4.7 (классы
Голкипер, Защитник, Играющий тренер
наследуют свойства и поведение
родительского
класса
Футболист, класс
Играющий тренер наследует свойства и
поведения класса
Тренер). Наследуются потомками
не все свойства класса-родителя
(атрибуты и методы), а только с областью
видимости общей и закрытой (public,
protect).

Рис. 4.7. Пример отношения обобщения между классами.

Выявление классов (одна из основных задач проектирования системы- определить классы и отношения между ними)

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

Вторым
способом
является
анализ
диаграмм
последовательностей.
Но
этих
диаграмма
следует
найти
схожие
объекты,
т.е.
те
объекты,
которые
обладают
одинаковыми
данными
и
поведением.
Пример.
На
диаграммах
последовательности
участвуют
два
объекта
Счет
Мистера
Иванова
и
Cчет
Миссис
Петровой.
Оба
счета
обладают
такими
свойствами
как
баланс
и
пароль,
оба
счета
можно
пополнять,
проверять
пароль
и
т.д.
Тогда
следует
создать
класс
Счёт.

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

• классы,
  необходимые
  для
  описания
  основных
  сущностей
  (стереотип
  <<Entity>>);

Классы—сущности
присутствуют
на
каждой
диаграмме
классов.
Они
описывают
основные
понятия
системы.

• классы,
  необходимые
  для
  управления
  системой
  и
  её
  элементами
  (стереотип
  <<Control>>);

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

• классы,
  необходимые
  для
  связи
  с
  внешним
  миром
  (стереотип
  <<Boundary>>).

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Введение и содержание

Диаграмма классов занимает центральное место в проектировании объектно-ориентированной системы. Нотация классов используется на разных этапах проектирования и строится с различной степенью детализации. Язык UML применяется не только для проектирования, но и с целью документирования, а также эскизирования проекта. Я (в отличии от Гради Буча) не являюсь сторонником разработки проекта с использованием всех видов UML диаграмм, а также детального проектирования. Чаще всего я применяю UML для эскизирования, а также для проектирования по процессу ICONIX [Rosenberg]. В статье описана часть нотации классов UML, применение которой достаточно в большинстве случаев. Тут не будет информации о кратности ассоциаций и атрибутов, особенностях изображения параллельных операций, шаблонах (параметризованных классах) и ограничениях. При необходимости всю эту информации можно посмотреть в других книгах [Buch, Leonenkov]. Мы же ограничимся базовой частью нотации и больше внимания уделим применению диаграммы классов.

1. Элементы диаграммы классов
   1. Символ класса
   2. Отношения классов
2. Использование диаграммы классов
   1. Диаграмма классов как словарь системы, концептуальная модель
   2. Диаграмма классов уровня проектирования
   3. Диаграмма классов для эскизирования, документирования
   4. Диаграмма классов для моделирования БД
3. Заключение и литература по теме

1 Элементы диаграммы классов

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

1.1 Символ класса

Символ класса на диаграмме может выглядеть различным образом в зависимости от детализации диаграммы:

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

Формат спецификации атрибута:
видимость имя : тип [кратность] = значение_по_умолчанию

Формат спецификации операции:
видимость имя(аргумент: тип) = тип_возвращаемого_значения

В зависимости от параметра видимости элемент может быть:

• приватным (private, доступен только внутри класса) — задается символом «минус» (-), может отображаться в виде квадрата;
• защищенным (protected, доступен внутри класса, а также внутри классов-наследников) — задается символом «решетка» (#), может отображаться в виде ромба;
• открытым (public, доступен всем) — задается символом «плюс» (+), может отображаться в виде круга.

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

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

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

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

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

Отношение композиции обозначается закрашенным ромбом, который рисуется со стороны включающего класса — так, класс MovingItem включает в себя класс Position, т.к. перемещающийся объект всегда имеет позицию. Отношение агрегации изображается незакрашенным ромбом — игрок (Player) агрегирует состояние (IPlayerState).

Если вы знакомы с паттернами State, Strategy или Delegation — секцию можно пропустить.
На приведенной выше диаграмме используется шаблон проектирования Состояние (State), являющийся разновидностью шаблона Делегирование (Delegation) и близкой к паттерну Стратегия (Strategy). Суть делегирования заключается в том, что для упрощения логики работы класса, часть его работы может быть передана (делегирована) вспомогательному классу. В свою очередь, паттерн State может быть добавлен, например, на этапе рефакторинга если в нескольких функциях класса встречается разлапистая проверка состояния объекта для выполнения тех или иных действий. В нашем случае персонаж может взаимодействовать с ежом, предположим, что если персонаж движется сидя и контактирует с ежом — у него должно уменьшится здоровье, а если стоя — увеличится счет (points). Кроме ежа могла быть еда, противники, патроны и т.д. Для демонстрации такого паттерна создан абстрактный класс IPlayerState и два наследника StayState и SeatState. В классе Player, при нажатии кнопки Ctrl состояние могло бы меняться на SeatState, а при отпускании — на StayState. Таким образом, при выполнении state->process_hedgehog(this) наш игрок каким-то образом, определенным объектом state, проконтактирует с ежиком.

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

Наиболее общий вид отношений между классами — ассоциация, обозначается сплошной линией (иногда со стрелкой). Вообще, и композиция, и агрегация, и обобщение (наследование) — являются частными случаями ассоциации. В нашей диаграмме с помощью ассоциации показано, что класс IPlayerState изменяет stats (health и points) объекта Player. Ассоциация может иметь название связи, поясняющую суть отношения. В качестве названия связей композиции и агрегации часто используется имя соответствующей переменной. Кроме того, ассоциация может иметь кратность, она задается на концах линии:

• 1 — одна связь (на нашей диаграмме показано, что один игрок включает в себя один экземпляр класса IPlayerState);
• * любое число связей (если бы на диаграмме был класс игрового поля, то с помощью звездочки можно было бы показать, что оно может содержать произвольное число игровых элементов);
• [от..до] — может задаваться диапазоном. Так диапазон [0..*] эквивалентен звездочке, но если мы захотим показать, что должно присутствовать более одного объекта — можем записать [1..*]

Последний вид отношений, который мы рассмотрим — зависимость, изображается штриховой (прерывистой) линией. Если есть стрелка — то направлена от зависимого к независимому классу, если стрелки нет — то классы зависят друг от друга. Под зависимостью понимается зависимость от интерфейса, т.е. если интерфейс независимого класса изменится — то придется вносить изменения в зависимый класс. В нашей диаграмме SeatState и StayState зависят от класса Player, т.к. обращаются к его методам для изменения характеристик игрока. Для изображения отношения дружбы между классами используется отношение зависимости с подписью friend.

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

2 Использование диаграммы классов

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

Стоит отметить, что у Гради Буча советы по использованию UML даны в книге «Руководство пользователя» [Buch_Rambo], но в его «Объектно-ориементированном анализе» [Buch] можно найти хорошие примеры и критерии качества проекта. Леоненков [Leonenkov] и вовсе избегает этой темы, оставляя лишь ссылки на литературу, конкретные рекомендации я нашел у Лармана [Larman] и Розенберга [Rosenberg], часть материала основана на моем личном опыте. Фаулер рассматривает UML как средство эскизирования, поэтому у него свой (сильно отличающийся от Буча и Розенберга) взгляд на диаграмму классов [Fauler].

2.1 Диаграмма классов как словарь системы, концептуальная модель

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

Гради Буч для построения словаря системы предлагает выполнять в следующем порядке [BuchRambo]:

1. анализируя прецеденты, определить какие элементы пользователи и разработчики применяют для описания задачи или ее решения;
2. выявить для каждой абстракции соответствующее ей множество обязанностей (ответственности). Проследите правильность распределения обязанностей (в том числе, соблюдение принципа единой обязанности [solid_refactoring]);
3. разработайте процедуры и операции для выполнения классами своих обязанностей.

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

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

Ларман предлагает строить концептуальную модель системы [Larman] — это примерно то, что мы описали как словарь системы, но помимо терминов предметной области в ней фиксируются некоторые отношения, понятные заказчику. Например, заказчик понимает (и фиксирует в техническом задании), что <покупку> оформляет <продавец> — следовательно, между продавцом и покупкой существует отношение ассоциации "оформляет". Я рекомендую строить концептуальную модель, дорабатывая словарь системы, хотя Ларман рекомендует сначала добавлять ассоциации, а затем — атрибуты.

2.2 Диаграмма классов уровня проектирования

В любом объектно-ориентированном процессе проектирования диаграмма классов является результатом, т.к. является моделью, наиболее близкой к реализации (коду). Существуют инструменты, способные преобразовать диаграмму классов в код — такой процесс называется кодогенерацией и поддерживается множеством IDE и средств проектирования. Например, кодогенерацию выполняет Visual Paradigm (доступно в виде плагинов для множества IDE), новые версии Microsoft Visual Studio, такие средств UML-моделирования как StarUML, ArgoUML и др. Чтобы построить по диаграмме хороший код, она должна быть достаточно подробной. Именно о такой диаграмме идет речь в этом разделе.

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

1. перенести классы с диаграммы последовательности;
2. добавить атрибуты концептуальной модели;
3. добавить имена методов по анализу диаграмм взаимодействия (например, диаграмм последовательностей [uml_sequence_diag]);
4. добавить типы атрибутов и методов;
5. добавить ассоциации (на основании атрибутов — отношения композиции и агрегации);
6. добавить стрелки (направление ассоциаций)
7. добавить ассоциации, определяющие другие виды отношений (в первую очередь, наследование).

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

Например, при анализе задания на игру «Сапер» мы выделили классы <Флажок> и <Мина>, но будут ли эти классы в окончательном проекте или останутся только в воображении? — решение можно принять только проанализировав диаграммы взаимодействия. Ведь возможен и такой код:

enum class CellType { 
  EmptyOpened, EmptyClose, EmptyCloseFlagged, 
  MineOpened, MineClose,  MineCloseFlagged 
};

class PlayingGround {
// ...
  CellType **m_ground;
}

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

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

2.3 Диаграмма классов для эскизирования, документирования

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

Сторонником применения UML для эскизирования является Фаулер [Fauler], который считает, что целостный процесс проектирования с использованием UML слишком сложен. Эскизирование применяется очень часто (не только при объяснении проекта на маркерной доске):

• в любой книге, посвященной паттернам проектирования, вы найдете массу UML диаграмм, выполненных в этом стиле;
• при моделировании прецедента выбираются классы, за счет которых этот прецедент реализуется. Моделирование прецедента выполняется при рефакторинге;
• в документацию для разработчиков нет смысла вставлять диаграмму классов уровня проектирования — гораздо полезнее описать наиболее важные (ключевые) моменты системы. Для этого строятся эскизные диаграммы классов и диаграммы взаимодействия. Также существуют специальные инструменты построения документацию по готовому коду — такие как JavaDoc или Doxygen [doxygen_codegeneration], в частности они строят диаграмму классов, но чтобы документация была понятной, в исходный код программы требуется вносить комментарии специального вида.

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

2.4 Диаграмма классов для моделирования БД

Частным случаем диаграммы классов является диаграмма «сущность-связь» (E-R диаграмма), используемая для моделирования логической схемы базы данных. В отличии от классических E-R диаграмм, диаграмма классов позволяет моделировать поведение (триггеры и хранимые процедуры).

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

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

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

Для моделирования схемы БД с помощью диаграммы классов нужно [Buch_Rambo]:

1. идентифицировать классы, данные которых должны храниться между запусками приложения (или обращениями пользователя) и нанести эти классы на отдельную диаграмму;
2. детально специфицировать атрибуты классов, ассоциации и кратности. В E-R модели кратности имеют огромное значение — так например, при наличии кратности «многие-ко-многим» придется создавать вспомогательную таблицу. Используйте специфические стереотипы классов и пометки атрибутов (для задания первичных и вторичных ключей, например) [uml_datamodeling];
3. решить проблемы использования полученной диаграммы в качестве физической модели базы данных — циклические ассоциации, n-арные ассоциации и т.д. При необходимости создать промежуточные абстракции;
4. раскрыть операции, важные для доступа к данным и поддержания целостности;

Заключение и список литературы

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

• диаграмма шаблона проектирования Publish-Subscriber [pattern_mvc];
• множество диаграмм, демонстрирующих шаги рефакторинга для приведения проекта в соответствие принципам SOLID [solid_refactoring];
• диаграммы классов для паттерна адаптер и сетевого чата [pattern_adapter].
• [Buch] Буч Градди Объектно-ориентированный анализ и проектирование с примерами приложений, 3-е изд. / Буч Градди, Максимчук Роберт А., Энгл Майкл У., Янг Бобби Дж., Коналлен Джим, Хьюстон Келли А.: Пер с англ. — М.: ООО «И.Д. Вильямс», 2010. — 720 с.
• [Leonenkov] Леоненков, А.В. Самоучитель UML 2 / А.В. Леоненков. – СПб.: БХВ — Петербург, 2007. – 576с.
• [Larman] Ларман, К. Применение UML и шаблонов проектирования: Уч. Пос / К. Ларман. — М.: Издательский дом «Вильямс», 2001. — 496 с.
• [Rosenberg]Розенберг Д., Скотт К. Применение объектного моделирования с использованием UML и анализ прецедентов.: Пер. с англ. М.: ДМК Пресс, 2002
• [Badd] Бадд Т. Объектно-ориентированное программирование в действии: Пер с англ. — СПб: «Питер», 1997. — 464 с. 2002
• [Buch_Rambo] Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя: Пер. с англ. — М.: ДМК, 2000. — 432 с.
• [Fauler] Фаулер, М. UML. Основы / М. Фаулер, К. Скотт; пер. с англ. – СПб.: Символ – Плюс, 2002. – 192 с.
• [solid_refactoring] SOLID принципы. Рефакторинг — URL: https://pro-prof.com/archives/1914
• [uml_sequence_diag]Основы UML. Диаграммы последовательности — URL: https://pro-prof.com/archives/2769
• [uml_datamodeling] UML data modeling — URL: http://www.agiledata.org/essays/umlDataModelingProfile.html
• [doxygen_codegeneration] Использование doxygen — URL: https://pro-prof.com/archives/887
• [pattern_mvc] Паттерны MVC и Publish-Subscriber — URL: https://pro-prof.com/archives/2400
• [pattern_adapter] Работа с сетью в Qt. Сокеты. Паттерн Adapter — URL: https://pro-prof.com/archives/1372