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

В разработке программного обеспечения , диаграмма классов ^[1] в унифицированном языке моделирования (UML) — это тип диаграммы статической структуры, которая описывает структуру системы, показывая классы системы , их атрибуты, операции (или методы) и отношения между объектами.

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

На схеме классы представлены прямоугольниками, содержащими три отсека:

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

При проектировании системы несколько классов идентифицируются и группируются в диаграмму классов, которая помогает определить статические отношения между ними. При детальном моделировании классы концептуального проекта часто разбиваются на подклассы. ^[3]

Для дальнейшего описания поведения систем эти диаграммы классов могут быть дополнены диаграммой состояний или конечным автоматом UML . ^[4]

Члены

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

Видимость

Чтобы указать видимость члена класса (т. е. любого атрибута или метода), эти обозначения должны быть помещены перед именем члена: ^[5]

`+`	Общественный
`-`	Частный
`#`	Защищено
`~`	Упаковка

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

Производное свойство отображается с именем, которому предшествует косая черта '/'. ^[6]

Объем

UML определяет два типа области действия для членов: экземпляр и класс . Имя класса представляет собой подчеркнутое объединение имени экземпляра (если есть), двоеточие (':'), и фактическое имя класса. ^[1]

Члены экземпляра привязаны к конкретному экземпляру.
- Значения атрибутов могут различаться в зависимости от экземпляра.
- Вызов метода может повлиять на состояние экземпляра (т. е. изменить атрибуты экземпляра).
Члены класса обычно считаются «статическими» во многих языках программирования. Конец области видимости — это сам класс.
- Значения атрибутов одинаковы для всех экземпляров
- Вызов метода не влияет на состояние классификатора.

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

Отношения

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

Отношения на уровне экземпляра

Зависимость

Зависимость — это тип ассоциации, при котором между зависимыми и независимыми элементами модели существует семантическая связь. ^[7] Он существует между двумя элементами, если изменения в определении одного элемента (сервера или цели) могут вызвать изменения в другом (клиенте или источнике). Эта ассоциация однонаправленная. Зависимость отображается в виде пунктирной линии с открытой стрелкой, указывающей от клиента к поставщику.

Ассоциация

Пример диаграммы классов связи между двумя классами

Ассоциация представляет собой семейство структурных связей. Бинарная ассоциация изображается сплошной линией между двумя классами. Рефлексивная ассоциация — это бинарная ассоциация между классом и самим собой. Ассоциация между более чем двумя классами изображается в виде ромба, соединенного сплошной линией с каждым из связанных классов. Ассоциация между тремя классами является тройной ассоциацией. Ассоциация между большим количеством классов называется n-арной ассоциацией.

Ассоциации можно дать имя, а концы ассоциации можно украсить именами ролей, индикаторами агрегации, множественностью, видимостью, возможностью навигации и другими свойствами. Например, точечная запись позволяет с помощью маленькой точки на стороне одного класса обозначить, что конец ассоциации принадлежит другой стороне. ^[8]

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

Агрегация

Диаграмма классов, показывающая агрегацию между двумя классами. Здесь профессору «есть» преподавать.

Агрегация — это вариант отношения ассоциации «имеет»; агрегирование более специфично, чем ассоциация. Это ассоциация, которая представляет собой отношение части-целого или части-части. Как показано на изображении, у профессора есть класс, который он должен вести. Как тип ассоциации, агрегат может быть назван и иметь те же украшения, что и ассоциация. Однако агрегация не может включать более двух классов; это должна быть бинарная ассоциация. Более того, во время реализации едва ли существует разница между агрегациями и ассоциациями, и диаграмма может вообще пропустить отношения агрегации. ^[9]

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

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

Состав

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

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

Различия между составом и агрегацией

Композиционные отношения: 1. При попытке представить отношения «целое-часть» реального мира, например, двигатель является частью автомобиля.; 2. При уничтожении контейнера уничтожается и его содержимое, например, университет и его факультеты.

Отношения агрегации: 1. При представлении взаимосвязи программного обеспечения или базы данных, например, двигатель модели автомобиля ENG01 является частью модели автомобиля CM01, поскольку двигатель ENG01 также может быть частью другой модели автомобиля. ^[10]; 2. Когда контейнер уничтожается, его содержимое обычно не уничтожается, например, у профессора есть студенты; Когда профессор покидает университет, студенты не уходят вместе с профессором.

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

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

Обобщение/Наследование

Диаграмма классов, показывающая обобщение суперкласса *Человек* и двух подклассов *Студент* и *Профессор.*

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

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

   symbolic of realization           (subclass) _______▻ (superclass)

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

Суперкласс суперкласс ) в отношениях обобщения также известен как «родительский» , (базовый класс , базовый класс или базовый тип .

Подтип производный в отношениях специализации также известен как «дочерний» , подкласс , класс , производный тип , наследующий класс или наследующий тип .

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

А — это разновидность Б

Например, «дуб – это разновидность дерева», «автомобиль – это вид транспортного средства».

Обобщение можно отобразить только на диаграммах классов и диаграммах вариантов использования .

Реализация/Внедрение

В моделировании UML отношение реализации — это отношение между двумя элементами модели, в котором один элемент модели (клиент) реализует (реализует или выполняет) поведение, которое задает другой элемент модели (поставщик).

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

   symbolic of realization           (implementer) -------▻ (interface)

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

Зависимость

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

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

Это отношение ассоциации указывает на то, что (по крайней мере) один из двух связанных классов ссылается на другой. Эти отношения обычно описываются как «А имеет Б» (у матери-кошки есть котята, у котят есть мать-кошка).

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

0	Нет случаев (редко)
0..1	Нет экземпляров или один экземпляр
1	Ровно один экземпляр
1..1	Ровно один экземпляр
0..*	Ноль или более экземпляров
*	Ноль или более экземпляров
1..*	Один или несколько экземпляров

Стереотипы анализа

Сущности

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

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

См. также

Связанные диаграммы

Ссылки

^ Перейти обратно: ^а ^б «Классы». Единый язык моделирования 2.5.1 . Официальный номер документа OMG /05.12.2017. Организация по разработке стандартов группы управления объектами (OMG SDO). Декабрь 2017. с. 194.
^ Спаркс, Джеффри. «Моделирование баз данных в UML» . Проверено 8 сентября 2011 г.
^ Флэтт, Амели; Лангнер, Арне; Лепс, Олоф (2022 г.), «Фаза I: Сопоставление юридических концепций с техническими объектами» , Разработка профилей приложений Akoma Ntoso на основе моделей , Cham: Springer International Publishing, стр. 13–17, doi : 10.1007/978-3-031 -14132-4_3 , ISBN 978-3-031-14131-7 , получено 7 января 2023 г.
^ Скотт В. Эмблер (2009) Диаграммы классов UML 2 . Веб-документ 2003–2009 гг. По состоянию на 2 декабря 2009 г.
^ Справочная карта UML, версия 2.1.2 , Holub Associates, август 2007 г. , получено 12 марта 2011 г.
^ «Производное свойство UML — это свойство, значение которого создается или вычисляется на основе другой информации, например, с использованием других свойств» . www.uml-diagrams.org . Проверено 24 января 2019 г.
^ Фаулер (2003) UML Distilled: Краткое руководство по стандартному языку объектного моделирования
^ Селич, Бран (18 апреля 2013 г.). «Все в точку» (PDF) . www.omg.org . Группа управления объектами . Проверено 26 ноября 2023 г.
^ «Урок UML, часть 1: диаграммы классов» (PDF) . Архивировано из оригинала (PDF) 3 января 2007 г. Проверено 18 июля 2015 г.
^ Гудвин, Дэвид. «Моделирование и моделирование, стр. 26» (PDF) . Университет Уорика . Проверено 28 ноября 2015 г.

Внешние ссылки

«Классы». Единый язык моделирования 2.5.1 . Официальный номер документа OMG /05.12.2017. Организация по разработке стандартов группы управления объектами (OMG SDO). Декабрь 2017. с. 194.

Диаграммы классов UML 2

[OMG-1] Перейти обратно: ^а ^б «Классы». Единый язык моделирования 2.5.1 . Официальный номер документа OMG /05.12.2017. Организация по разработке стандартов группы управления объектами (OMG SDO). Декабрь 2017. с. 194.

[2] Спаркс, Джеффри. «Моделирование баз данных в UML» . Проверено 8 сентября 2011 г.

[3] Флэтт, Амели; Лангнер, Арне; Лепс, Олоф (2022 г.), «Фаза I: Сопоставление юридических концепций с техническими объектами» , Разработка профилей приложений Akoma Ntoso на основе моделей , Cham: Springer International Publishing, стр. 13–17, doi : 10.1007/978-3-031 -14132-4_3 , ISBN 978-3-031-14131-7 , получено 7 января 2023 г.

[SWA09-4] Скотт В. Эмблер (2009) Диаграммы классов UML 2 . Веб-документ 2003–2009 гг. По состоянию на 2 декабря 2009 г.

[HOL07-5] Справочная карта UML, версия 2.1.2 , Holub Associates, август 2007 г. , получено 12 марта 2011 г.

[6] «Производное свойство UML — это свойство, значение которого создается или вычисляется на основе другой информации, например, с использованием других свойств» . www.uml-diagrams.org . Проверено 24 января 2019 г.

[7] Фаулер (2003) UML Distilled: Краткое руководство по стандартному языку объектного моделирования

[8] Селич, Бран (18 апреля 2013 г.). «Все в точку» (PDF) . www.omg.org . Группа управления объектами . Проверено 26 ноября 2023 г.

[9] «Урок UML, часть 1: диаграммы классов» (PDF) . Архивировано из оригинала (PDF) 3 января 2007 г. Проверено 18 июля 2015 г.

[10] Гудвин, Дэвид. «Моделирование и моделирование, стр. 26» (PDF) . Университет Уорика . Проверено 28 ноября 2015 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]