Диаграмма классов
 | Эта статья нуждается в дополнительных цитатах для проверки . ( февраль 2009 г. ) |
| Типы диаграмм UML |
|---|
| Структурные диаграммы UML |
| Поведенческие UML-диаграммы |
В разработке программного обеспечения ,диаграмма классов [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 представляет собой полый треугольник на конце линии (или дерева линий) суперкласса, который соединяет его с одним или несколькими подтипами.
символ реализации (подкласс) _______▻ (надкласс)
Отношение обобщения также известно как отношение наследования или отношение «является» .
Суперкласс суперкласс ) в отношениях обобщения также известен как «родительский» , (базовый класс , базовый класс или базовый тип .
Подтип производный в отношениях специализации также известен как «дочерний» , подкласс , класс , производный тип , наследующий класс или наследующий тип .
Обратите внимание, что эти отношения не имеют ничего общего с биологическими отношениями родитель-ребенок: использование этих терминов чрезвычайно распространено, но может вводить в заблуждение.
- А — это разновидность Б
- Например, «дуб – это разновидность дерева», «автомобиль – это вид транспортного средства».
Обобщение можно отобразить только на диаграммах классов и диаграммах вариантов использования .
Реализация/Внедрение [ править ]
В моделировании UML отношение реализации — это отношение между двумя элементами модели, в котором один элемент модели (клиент) реализует (реализует или выполняет) поведение, которое задает другой элемент модели (поставщик).
Графическое представление реализации в UML представляет собой полый треугольник на конце интерфейсной пунктирной линии (или дерева линий), которая соединяет ее с одним или несколькими реализаторами. На интерфейсном конце пунктирной линии, соединяющей его с пользователями, используется простая стрелка. В диаграммах компонентов используется графическое соглашение «шарик и гнездо» (разработчики демонстрируют шарик или леденец, тогда как пользователи показывают гнездо).Реализации могут быть показаны только на диаграммах классов или компонентов.Реализация — это связь между классами, интерфейсами, компонентами и пакетами, которая соединяет элемент клиента с элементом поставщика. Отношения реализации между классами/компонентами и интерфейсами показывают, что класс/компонент реализует операции, предлагаемые интерфейсом.
символ реализации (реализатор) -------▻ (интерфейс)
Общие отношения [ править ]
Зависимость [ править ]
Зависимость может быть более слабой формой связи, которая указывает на то, что один класс зависит от другого, поскольку он использует его в определенный момент времени.Один класс зависит от другого, если независимый класс является переменной параметра или локальной переменной метода зависимого класса. Иногда отношения между двумя классами очень слабы. Они не реализованы спеременные-члены вообще. Скорее, они могут быть реализованы как аргументы функции-члена.
Множественность [ править ]
Это отношение ассоциации указывает на то, что (по крайней мере) один из двух связанных классов ссылается на другой. Эти отношения обычно описываются как «А имеет Б» (у матери-кошки есть котята, у котят есть мать-кошка).
UML-представление ассоциации — это линия, соединяющая два связанных класса. На каждом конце строки есть необязательные обозначения. Например, мы можем указать с помощью стрелки, что заостренный конец виден из хвоста стрелки. Мы можем указать право собственности путем размещения мяча, роль, которую элементы этой цели играют, указав имя роли, а также множественность экземпляров этой сущности (диапазон количества объектов, которые участвуют в ассоциации с точки зрения другого конца).
| 0 | Нет случаев (редко) |
| 0..1 | Нет экземпляров или один экземпляр |
| 1 | Ровно один экземпляр |
| 1..1 | Ровно один экземпляр |
| 0..* | Ноль или более экземпляров |
| * | Ноль или более экземпляров |
| 1..* | Один или несколько экземпляров |
анализа Стереотипы
Сущности [ править ]
Классы сущностей моделируют долгоживущую информацию, обрабатываемую системой, а иногда и поведение, связанное с этой информацией. Их не следует идентифицировать как таблицы базы данных или другие хранилища данных.
Они рисуются в виде кругов с короткой линией, прикрепленной к нижней части круга. В качестве альтернативы их можно нарисовать как обычные классы со стереотипным обозначением «сущность» над именем класса.
См. также [ править ]
- Связанные диаграммы
Ссылки [ править ]
- ^ Jump up to: а б «Классы». Единый язык моделирования 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 г.
Внешние ссылки [ править ]
- Введение в диаграммы классов UML 2
- Рекомендации по диаграммам классов UML 2
- Диаграмма классов IBM Введение
- «Классы». Единый язык моделирования 2.5.1 . Официальный номер документа OMG /05.12.2017. Организация по разработке стандартов группы управления объектами (OMG SDO). Декабрь 2017. с. 194.
| Актеры |
|  | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Концепции |
| ||||||||||||
| Диаграммы |
| ||||||||||||
| Производные языки | |||||||||||||
| Другие темы | |||||||||||||