Полное руководство по диаграмме классов UML

Пример класса

У собаки есть состояния – цвет, имя, порода, а также поведение – виляние, лай, еда. Объект является экземпляром класса.

Обозначение класса UML

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

Имя класса:

• Имя класса появляется в первом разделе.

Атрибуты класса:

• Атрибуты показаны во втором разделе.
• Тип атрибута отображается после двоеточия.
• Атрибуты сопоставляются с переменными-членами (элементами данных) в коде.

Классовые операции (методы):

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

Классовые отношения

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

Тип отношений	Графическое представление
Наследование  (или обобщение): Представляет отношение «есть-а». Имя абстрактного класса показано курсивом. SubClass1 и SubClass2 являются специализациями Суперкласса. Сплошная линия с полой стрелкой, указывающая от дочернего к родительскому классу
Простая ассоциация : Структурная связь между двумя одноранговыми классами. Существует связь между классом 1 и классом 2. Сплошная линия, соединяющая два класса
Агрегация :Особый тип ассоциации. Он представляет собой «часть» отношений. Class2 является частью Class1. Многие экземпляры (обозначенные *) класса 2 могут быть связаны с классом 1. Объекты Class1 и Class2 имеют разное время жизни. Сплошная линия с незакрашенным ромбом на конце ассоциации, связанной с классом составных
Состав :Особый тип агрегации, при котором части разрушаются при разрушении целого. Объекты класса 2 живут и умирают вместе с классом 1. Класс 2 не может стоять сам по себе. Сплошная линия с закрашенным ромбом в ассоциации, связанной с классом составных
Зависимость : Существует между двумя классами, если изменения в определении одного могут вызвать изменения в другом (но не наоборот). Class1 зависит от Class2 Пунктирная линия с открытой стрелкой

Имена отношений

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

Отношения — Роли

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

Судоходность

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

Диаграмма выше предполагает, что,

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

Видимость атрибутов класса и операций

В объектно-ориентированном дизайне есть нотация видимости атрибутов и операций. UML определяет четыре типа видимости:  public ,  protected ,  private и  package .

Символы +, -, # и ~ перед именем атрибута и операции в классе обозначают видимость атрибута и операции.

• + обозначает общедоступные атрибуты или операции
• – обозначает частные атрибуты или операции
• # обозначает защищенные атрибуты или операции
• ~ обозначает атрибуты пакета или операции

Пример видимости класса

В приведенном выше примере:

• attribute1 и op1 MyClassName являются общедоступными
• attribute3 и op3 защищены.
• attribute2 и op2 являются частными.

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

Множественность

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

• Ровно один — 1
• Ноль или единица – 0..1
• Многие – 0..* или *
• Один или несколько – 1..*
• Точное число — например, 3..4 или 6
• Или сложное отношение — например, 0..1, 3..4, 6.* будет означать любое количество объектов, кроме 2 или 5.

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

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

Пример агрегации — компьютер и комплектующие

• Агрегация — это частный случай ассоциации, обозначающий иерархию «состоит из».
• Агрегат — это родительский класс, компоненты — это дочерние классы.

Пример наследования — таксономия ячеек

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

Диаграмма классов — пример инструмента диаграммы

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

В приведенном выше примере:

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

1. Форма — это абстрактный класс. Он показан курсивом.
2. Форма — это суперкласс. Круг, прямоугольник и многоугольник являются производными от формы. Другими словами, Круг — это Форма. Это отношение обобщения/наследования.
3. Существует связь между DialogBox и DataController.
4. Форма является частью окна. Это агрегационные отношения. Shape может существовать без Window.
5. Точка является частью Круга. Это композиционные отношения. Точка не может существовать без Окружности.
6. Окно зависит от события. Однако Event не зависит от Window.
7. Атрибутами Circle являются радиус и центр. Это класс сущности.
8. Имена методов Circle: area(),circ(), setCenter() и setRadius().
9. Радиус параметра в Circle является параметром in типа float.
10. Метод area() класса Circle возвращает значение типа double.
11. Атрибуты и имена методов Rectangle скрыты. У некоторых других классов на диаграмме также скрыты атрибуты и имена методов.

Работа со сложной системой — диаграмма нескольких или одного класса?

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

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

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

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

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

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

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