В разработке программного обеспечения диаграмма классов в унифицированном языке моделирования (UML) — это тип статической структурной диаграммы, которая описывает структуру системы, показывая классы системы , их атрибуты, операции (или методы) и отношения между объектами.
Диаграмма классов является основным строительным блоком объектно-ориентированного моделирования. Он используется для общего концептуального моделирования структуры приложения, а также для детального моделирования, перевода моделей в программный код . Диаграммы классов также можно использовать для моделирования данных . [1] Классы на диаграмме классов представляют как основные элементы, взаимодействия в приложении, так и классы, которые необходимо запрограммировать.
На схеме классы представлены прямоугольниками, содержащими три отсека:
При проектировании системы несколько классов идентифицируются и группируются в диаграмму классов, которая помогает определить статические отношения между ними. При детальном моделировании классы концептуального проекта часто разбиваются на подклассы. [2]
Для дальнейшего описания поведения систем эти диаграммы классов могут быть дополнены диаграммой состояний или конечным автоматом UML . [3]
UML предоставляет механизмы для представления членов класса, таких как атрибуты и методы, а также дополнительную информацию о них, например, конструкторы.
Чтобы указать видимость члена класса (т. е. любого атрибута или метода), эти обозначения должны быть помещены перед именем члена: [4]
Производное свойство — это свойство, значение (или значения) которого создается или вычисляется на основе другой информации, например, с использованием значений других свойств.
Производное свойство отображается с именем, которому предшествует косая черта '/'. [5]
UML определяет два типа области действия для членов: экземпляр и класс , причем последний представлен подчеркнутыми именами . [6]
Чтобы указать область действия классификатора для члена, его имя должно быть подчеркнуто. В противном случае по умолчанию предполагается область экземпляра.
Отношения — это общий термин, охватывающий конкретные типы логических связей, встречающихся на диаграммах классов и объектов. UML определяет следующие отношения:
Зависимость — это тип ассоциации, при котором между зависимыми и независимыми элементами модели существует семантическая связь . [7] Он существует между двумя элементами, если изменения в определении одного элемента (сервера или цели) могут вызвать изменения в другом (клиенте или источнике). Эта ассоциация однонаправленная. Зависимость отображается в виде пунктирной линии с открытой стрелкой, указывающей от клиента к поставщику.
Ассоциация представляет собой семейство структурных связей . Бинарная ассоциация изображается сплошной линией между двумя классами. Рефлексивная ассоциация — это бинарная ассоциация между классом и самим собой. Ассоциация между более чем двумя классами изображается в виде ромба, соединенного сплошной линией с каждым из связанных классов. Ассоциация между тремя классами является тройной ассоциацией. Ассоциация между большим количеством классов называется n-арной ассоциацией.
Ассоциации можно дать имя, а концы ассоциации можно украсить именами ролей, индикаторами агрегации, множественностью, видимостью, возможностью навигации и другими свойствами. Например, точечная запись позволяет с помощью маленькой точки на стороне одного класса обозначить, что конец ассоциации принадлежит другой стороне. [8]
Существует три типа ассоциации: простая ассоциация, разделяемая агрегация, составная агрегация (композиция). По ассоциации можно перемещаться в одном или нескольких направлениях. Навигацию не обязательно указывать явно. Стрелка с открытой головкой на стороне класса свидетельствует о том, что к классу можно эффективно получить доступ во время выполнения с противоположной стороны. Однонаправленная навигация отображается небольшим крестиком на линии ассоциации на той стороне класса, к которой невозможно добраться. Например, класс полета связан с классом самолета двунаправленно.
Агрегация — это вариант отношения ассоциации «имеет»; агрегирование более специфично, чем ассоциация. Это ассоциация, которая представляет собой отношение части-целого или части-части. Как показано на изображении, профессору «есть» класс, который он должен вести. Как тип ассоциации, агрегат может иметь имя и иметь те же украшения, что и ассоциация. Однако агрегация не может включать более двух классов; это должна быть бинарная ассоциация. Более того, во время реализации едва ли существует разница между агрегациями и ассоциациями, и диаграмма может вообще пропускать отношения агрегации. [9]
Агрегация может происходить, когда класс является коллекцией или контейнером других классов, но содержащиеся в нем классы не имеют сильной зависимости жизненного цикла от контейнера. Содержимое контейнера все еще существует, когда контейнер уничтожается.
В UML он графически представлен в виде полого ромба на содержащем классе с единственной линией, соединяющей его с содержащимся классом. Агрегат семантически является расширенным объектом, который во многих операциях рассматривается как единое целое, хотя физически он состоит из нескольких меньших объектов.
Отношения составной агрегации (в просторечии называемые композицией) — это более сильная форма агрегации, при которой агрегат контролирует жизненный цикл элементов, которые он агрегирует. Графическое представление представляет собой закрашенный ромб на конце линии, содержащей класс, которая соединяет содержащийся класс(ы) с содержащим классом.
Таким образом, отношение агрегации часто представляет собой «каталогическое» включение, чтобы отличить его от «физического» вложения композиции. UML 2 не определяет никакой семантики агрегирования по сравнению с простой ассоциацией.
Это указывает на то, что один из двух связанных классов ( подкласс ) считается специализированной формой другого (супертип ) , а суперкласс считается обобщением подкласса. На практике это означает, что любой экземпляр подтипа также является экземпляром суперкласса. Примерное дерево обобщений этой формы встречается в биологической классификации : человек — подкласс обезьян , который является подклассом млекопитающих и так далее. Эту связь легче всего понять с помощью фразы «А есть Б» (человек — млекопитающее, млекопитающее — животное).
Графическое представление обобщения в UML представляет собой полый треугольник на конце линии (или дерева линий) суперкласса, который соединяет его с одним или несколькими подтипами.
символ реализации (подкласс) _______▻ (надкласс)
Отношение обобщения также известно как отношение наследования или отношение «является» .
Суперкласс (базовый класс) в отношениях обобщения также известен как «родительский» , суперкласс , базовый класс или базовый тип .
Подтип в отношениях специализации также известен как «дочерний» , подкласс , производный класс , производный тип , наследующий класс или наследующий тип .
Обратите внимание, что эти отношения не имеют ничего общего с биологическими отношениями родитель-ребенок: использование этих терминов чрезвычайно распространено, но может вводить в заблуждение.
Обобщение можно отобразить только на диаграммах классов и диаграммах вариантов использования .
В моделировании UML отношение реализации — это отношение между двумя элементами модели, в котором один элемент модели (клиент) реализует (реализует или выполняет) поведение, которое задает другой элемент модели (поставщик).
Графическое представление реализации в UML представляет собой полый треугольник на конце интерфейсной пунктирной линии (или дерева линий), которая соединяет ее с одним или несколькими реализаторами. На интерфейсном конце пунктирной линии, соединяющей его с пользователями, используется простая стрелка. В диаграммах компонентов используется графическое соглашение «шарик и гнездо» (разработчики демонстрируют шарик или леденец, тогда как пользователи показывают гнездо). Реализации могут быть показаны только на диаграммах классов или компонентов. Реализация — это связь между классами, интерфейсами, компонентами и пакетами, которая соединяет элемент клиента с элементом поставщика. Отношения реализации между классами/компонентами и интерфейсами показывают, что класс/компонент реализует операции, предлагаемые интерфейсом.
символ реализации (реализатор) -------▻ (интерфейс)
Зависимость может быть более слабой формой связи, которая указывает на то, что один класс зависит от другого, поскольку он использует его в определенный момент времени. Один класс зависит от другого, если независимый класс является переменной параметра или локальной переменной метода зависимого класса. Иногда отношения между двумя классами очень слабы. Они вообще не реализованы с переменными-членами. Скорее, они могут быть реализованы как аргументы функции-члена.
Это отношение ассоциации указывает на то, что (по крайней мере) один из двух связанных классов ссылается на другой. Эти отношения обычно описываются как «А имеет Б» (у матери-кошки есть котята, у котят есть мать-кошка).
UML-представление ассоциации — это линия, соединяющая два связанных класса. На каждом конце строки есть необязательные обозначения. Например, мы можем указать с помощью стрелки, что заостренный конец виден из хвоста стрелки. Мы можем указать право собственности путем размещения мяча, роль, которую элементы этой цели играют, указав имя роли, а также множественность экземпляров этой сущности (диапазон количества объектов, которые участвуют в ассоциации с точки зрения другого конца).
Классы сущностей моделируют долгоживущую информацию, обрабатываемую системой, а иногда и поведение, связанное с этой информацией. Их не следует идентифицировать как таблицы базы данных или другие хранилища данных.
Они рисуются в виде кругов с короткой линией, прикрепленной к нижней части круга. В качестве альтернативы их можно нарисовать как обычные классы со стереотипным обозначением «сущность» над именем класса.
