Диаграмма классов
![](http://upload.wikimedia.org/wikipedia/commons/thumb/1/11/Class_diagram_relations.png/540px-Class_diagram_relations.png)
Диаграмма классов (англ. class diagram) — структурная диаграмма языка моделирования UML, демонстрирующая общую структуру иерархии классов системы, их коопераций, атрибутов (полей), методов, интерфейсов и взаимосвязей (отношений) между ними. Широко применяется не только для документирования и визуализации, но также для конструирования посредством прямого или обратного проектирования[1].
Введение
[править | править код]Целью создания диаграммы классов является графическое представление статической структуры декларативных элементов системы (классов, типов и т. п.) Она содержит в себе также некоторые элементы поведения (например — операции), однако их динамика должна быть отражена на диаграммах других видов (диаграммах коммуникации, диаграммах состояний). Для удобства восприятия диаграмму классов можно также дополнить представлением пакетов, включая вложенные[2].
При представлении сущностей реального мира разработчику требуется отразить их текущее состояние, их поведение и их взаимные отношения. На каждом этапе осуществляется абстрагирование от маловажных деталей и концепций, которые не относятся к реальности (производительность, инкапсуляция, видимость и т. п.). Классы можно рассматривать с позиции различных уровней. Как правило, их выделяют три основных: аналитический уровень, уровень проектирования и уровень реализации[3]:
- на уровне анализа класс содержит в себе только набросок общих контуров системы и работает как логическая концепция предметной области или программного продукта.
- на уровне проектирования класс отражает основные проектные решения касательно распределения информации и планируемой функциональности, объединяя в себе сведения о состоянии и операциях.
- на уровне реализации класс дорабатывается до такого вида, в каком он максимально удобен для воплощения в выбранной среде разработки; при этом не воспрещается опустить в нём те общие свойства, которые не применяются на выбранном языке программирования.
Элементы диаграммы
[править | править код]![](http://upload.wikimedia.org/wikipedia/commons/thumb/4/41/BankAccount1.svg/289px-BankAccount1.svg.png)
Класс является ключевым элементом в объектно-ориентированном моделировании. На диаграмме классы представлены в рамках, содержащих три компонента:
- В верхней части написано имя класса. Имя класса выравнивается по центру и пишется полужирным шрифтом. Имена классов начинаются с заглавной буквы. Если класс абстрактный — то его имя пишется полужирным курсивом.
- Посередине располагаются поля (атрибуты) класса. Они выровнены по левому краю и начинаются с маленькой буквы.
- Нижняя часть содержит методы класса. Они также выровнены по левому краю и пишутся с маленькой буквы.
Язык UML предоставляет механизмы для представления членов класса, например атрибутов и методов, а также дополнительной информации о них.
Видимость
[править | править код]Для задания видимости членов класса (то есть — любым атрибутам или методам), эти обозначения должны быть размещены перед именем участника:[4]
+ |
Публичный (Public) |
- |
Приватный (Private) |
# |
Защищённый (Protected) |
/ |
Производный (Derived) (может быть совмещён с другими) |
~ |
Пакет (Package) |
Области действия
[править | править код]UML определяет два типа областей действия для членов: экземпляр и классификатор, последние имеют подчёркнутые имена.[5]
- Члены классификаторы. Во многих языках называются static. Область действия — сам класс.
- Значения полей одинаковы для всех экземпляров в данной единице трансляции
- Вызов метода не меняет состояние объекта
- Члены экземпляры. Область действия — объект.
- Значения полей могут отличаться в разных объектах
- Методы могут изменять поля
Чтобы показать принадлежность к классификатору, имя подчёркивается, в противном случае область действия полагается областью действия по умолчанию.
Взаимосвязи
[править | править код]![](http://upload.wikimedia.org/wikipedia/commons/thumb/7/77/Uml_classes_ru.svg/351px-Uml_classes_ru.svg.png)
Взаимосвязь — это особый тип логических отношений между сущностями, показанных на диаграммах классов и объектов. В UML представлены следующие виды отношений:
Взаимосвязи объектов классов
[править | править код]Зависимость
[править | править код]Зависимость[англ.] обозначает такое отношение между классами, что изменение спецификации класса-поставщика может повлиять на работу зависимого класса, но не наоборот.
Ассоциация
[править | править код]Ассоциация показывает, что объекты одной сущности (класса) связаны с объектами другой сущности таким образом, что можно перемещаться от объектов одного класса к другому. Является общим случаем композиции и агрегации.
Например, класс Человек и класс Школа имеют ассоциацию, так как человек может учиться в школе. Ассоциации можно присвоить имя «учится в».
Двойные ассоциации представляются линией без стрелочек на концах, соединяющей два классовых блока. Ассоциации более высокой степени имеют более двух концов и представляются линиями, один конец которых идёт к классовому блоку, а другой к общему ромбику. В представлении однонаправленной ассоциации добавляется стрелка, указывающая на направление ассоциации.
Ассоциация может быть именованной, и на концах представляющей её линии могут быть подписаны роли, принадлежности, индикаторы, мультипликаторы, видимости или другие свойства.
Агрегация
[править | править код]![](http://upload.wikimedia.org/wikipedia/commons/thumb/2/2a/KP-UML-Aggregation-20060420.svg/372px-KP-UML-Aggregation-20060420.svg.png)
Агрегация — это разновидность ассоциации при отношении между целым и его частями. Как тип ассоциации агрегация может быть именованной. Одно отношение агрегации не может включать более двух классов (контейнер и содержимое).
Агрегация встречается, когда один класс является коллекцией или контейнером других. Причём по умолчанию, агрегацией называют агрегацию по ссылке, то есть когда время существования содержащихся классов не зависит от времени существования содержащего их класса. Если контейнер будет уничтожен, то его содержимое — нет.
Графически агрегация представляется пустым ромбом на блоке класса, и линией, идущей от этого ромба к содержащемуся классу.
Композиция
[править | править код]Композиция — более строгий вариант агрегации. Известна также как агрегация по значению.
Композиция имеет жёсткую зависимость времени существования экземпляров класса контейнера и экземпляров содержащихся классов. Если контейнер будет уничтожен, то всё его содержимое будет также уничтожено.
Графически представляется, как и агрегация, но с закрашенным ромбиком.
Различия между композицией и агрегацией
[править | править код]Приведём наглядный пример. Комната является частью квартиры, следовательно здесь подходит композиция, потому что комната без квартиры существовать не может. А, например, мебель не является неотъемлемой частью квартиры, но в то же время, квартира содержит мебель, поэтому следует использовать агрегацию.
Взаимосвязи классов
[править | править код]Обобщение (наследование)
[править | править код]![](http://upload.wikimedia.org/wikipedia/commons/thumb/6/66/KP-UML-Generalization-20060325.svg/300px-KP-UML-Generalization-20060325.svg.png)
Обобщение (Generalization) показывает, что один из двух связанных классов (подтип) является частной формой другого (надтипа), который называется обобщением первого. На практике это означает, что любой экземпляр подтипа является также экземпляром надтипа. Например: животные — супертип млекопитающих, которые, в свою очередь, — супертип приматов, и так далее. Эта взаимосвязь легче всего описывается фразой «А — это Б» (приматы — это млекопитающие, млекопитающие — это животные).//
Графически обобщение представляется линией с пустым треугольником у супертипа.
Обобщение также известно как наследование или «is a» взаимосвязь (или отношение «является»).
Реализация
[править | править код]Реализация — отношение между двумя элементами модели, в котором один элемент (клиент) реализует поведение, заданное другим (поставщиком). Реализация — отношение целое-часть. Графически реализация представляется так же, как и наследование, но с пунктирной линией.
Поставщик, как правило, является абстрактным классом или классом-интерфейсом.
Общая взаимосвязь
[править | править код]Зависимость
[править | править код]Зависимость (dependency) — это слабая форма отношения использования, при которой изменение в спецификации одного влечёт за собой изменение другого, причём обратное не обязательно. Возникает, когда объект выступает, например, в форме параметра или локальной переменной.
Графически представляется штриховой стрелкой, идущей от зависимого элемента к тому, от которого он зависит.
Существует несколько именованных вариантов.
Зависимость может быть между экземплярами, классами или экземпляром и классом.
Уточнения отношений
[править | править код]Уточнение имеет отношение к уровню детализации. Один пакет уточняет другой, если в нём содержатся те же самые элементы, но в более подробном представлении. Например, при написании книги вы наверняка начнете с формулировки предложения, в котором кратко будет представлено содержание каждой главы. Предположим, что резюме к каждой главе в качестве отдельного элемента входит в пакет «Предложение». Допустим также, что «Завершённая книга» — это пакет, элементами которого являются законченные главы. В этом контексте пакет «Завершённая книга» является уточнением пакета «Предложение».
Мощность отношений (Кратность)
[править | править код]Мощность отношения (мультипликатор) означает число связей между каждым экземпляром класса (объектом) в начале линии с экземпляром класса в её конце. Различают следующие типичные случаи:
нотация | объяснение | пример |
0..1 | Ноль или один экземпляр | Кошка имеет хозяина. |
1 | Обязательно один экземпляр | у кошки одна мать |
0..* или * | Ноль или более экземпляров | у кошки могут быть, а может и не быть котят |
1..* | Один или более экземпляров | у кошки есть хотя бы одно место, где она спит |
См. также
[править | править код]- Entity-Relationship модель
- Объектно-ориентированное проектирование
- Объектно-ориентированное программирование
- Теория множеств (множество, элемент множества)
- Теория категорий
Примечания
[править | править код]- ↑ Буч, Рамбо, Якобсон, 2006, Диаграмма классов, с. 120.
- ↑ Буч, Якобсон, Рамбо, 2006, class diagram (диаграмма классов), с. 226.
- ↑ Буч, Якобсон, Рамбо, 2006, Классы, с. 68.
- ↑ UML Reference Card, Version 2.1.2, Holub Associates, August 2007, Архивировано 2 марта 2010, Дата обращения: 12 марта 2011 Источник . Дата обращения: 6 марта 2017. Архивировано 2 марта 2010 года.
- ↑ OMG Unified Modeling Language (OMG UML) Superstructure Архивная копия от 13 марта 2016 на Wayback Machine, Version 2.3: May 2010. Retrieved 23 September 2010.
Источники
[править | править код]- Г. Буч, Д. Рамбо, И. Якобсон. Язык UML. Руководство пользователя = The Unified Modeling Language Usere Guide. — 2-е. — М. : ДМК Пресс, 2006. — 496 с. — ISBN 5-94074-334-X.
- Г. Буч, А. Якобсон, Д. Рамбо,. UML. Классика CS = The Unified Modeling Language Reference Manual. — 2-е. — СПб. : «Питер», 2006. — 736 с. — ISBN 5-469-00599-2.