Эта статья была первоначально опубликована на Medium.
Диаграммы UML: Общий язык. Краткое описание диаграмм UML и диаграмма классов… | автор Джин Цейсс | Средний
Джин Зейнисс ・ 26 января 2021 года ・ 8 минут чтения.
В своей работе я часто использую UML-диаграммы. Полагаю, ежедневно. Как бы то ни было, я никогда не понимал тонкости компонентов диаграмм. Когда использовать полную стрелку, а когда пустую, линия должна быть сплошной или пунктирной и указывать, в каком направлении она должна указываться. Мне надоело жить в неведении. Итак, вот я и собираюсь начать серию статей о диаграммах UML…
UML (Унифицированный язык моделирования) – это распространенный язык моделирования программной инженерии, который используется для решения широкого спектра задач. Это “Общий язык” Вестероса для фанатов “Игры престолов”. Это поможет вам определить, визуализировать и документировать модели программных систем, включая их структуру и дизайн, перед кодированием (с акцентом на “до”). Как гласит старая пословица: “Плотник дважды отмеряет и один раз режет”.
Существует несколько типов диаграмм UML, и каждая из них служит своей цели. Две наиболее широкие категории, охватывающие все остальные типы, – это Структурные и Поведенческие диаграммы.
Структурный (или статическая) диаграмма визуализирует статическую структуру системы с помощью объектов, атрибутов, операций и взаимосвязей. У меня есть кошка, Лола. У нее есть кое-какие вещи, такие как миска для еды, точилка для когтей и какашка. Итак, статические аспекты Лолы охватывают существование ее вещей. Кстати, сама Лола будет описана как объект (с объектно-ориентированной точки зрения, верно?).
Структурными диаграммами являются: Диаграмма классов, Диаграмма объектов, Диаграмма компонентов, Диаграмма составной структуры, Диаграмма пакетов, Диаграмма развертывания и Диаграмма профиля.
Поведенческий (или динамические) диаграммы используются для визуализации динамических аспектов системы. Поведенческая категория включает в себя несколько общих типов поведения, в частности Диаграмму вариантов использования, Диаграмму действий и Диаграмму конечного автомата; и типы, которые представляют различные аспекты взаимодействия (также известные как “Диаграммы взаимодействия”) — Диаграмму последовательности, Диаграмму связи, Временную диаграмму и Диаграмму обзора взаимодействия. Другими словами, он показывает, как система взаимодействует с внешними объектами и пользователями, как она реагирует на ввод или события и в каких условиях она работает. Просто пример взаимодействия между мной и моей кошкой. Лола истерично мяукает. Это заставляет меня класть еду в ее миску. Она ест, сохраняя при этом “спасибо ей”.
Не все из 14 различных типов диаграмм UML регулярно используются при документировании систем и/или архитектур. Я собираюсь написать о наиболее полезных диаграммах, по моему скромному мнению, и начну серию с диаграмм классов…
Поскольку большинство создаваемого в настоящее время программного обеспечения по-прежнему основано на парадигме объектно-ориентированного программирования, использование диаграмм классов для документирования программного обеспечения оказывается разумным решением. Диаграмма классов описывает структуру системы, показывая ее классы, их атрибуты, методы и отношения между ними. Это словарь системы, общий язык между всеми членами команды.
Структурные особенности (атрибуты) определяют, какие объекты класса “знают”. Кошка знает свой цвет глаз, шерсть, диапазон веса и остро осознает свое превосходство.
Поведенческие особенности (операции, они же методы) определяют, что объекты класса “могут делать”. Кошка может мяукать, есть и какать (очень поверхностное представление о том, что может делать кошка).
Классы описываются в виде блоков на диаграмме классов. Каждое поле имеет заголовок, представляющий название класса. Под заголовком есть два раздела:
Средняя часть поля включает в себя атрибуты . Обозначение атрибута – attribute:type (необязательно)
Нижняя часть включает в себя операции . Обозначение операции – operation(params):возвращаемый тип
Следующие обозначения позволяют указать видимость члена класса (т.е. любого атрибута или операции): Мы круты? Это пример класса Cat. Давайте взглянем на то, что у нас здесь есть:
- ” Cat” – это имя класса (название).
- У Кошки есть некоторые общедоступные атрибуты, такие как “цвет глаз” типа enum со значением по умолчанию “Желтый” (скажем) и объект значения “пальто” типа Coat.
- Кошки могут мяукать и есть лакомства на публике, однако они предпочитают испражняться в уединении (операции).
Когда вы создаете диаграмму классов, опустите необязательные детали. Я имею в виду, постарайтесь сохранить диаграмму чистой, показывая только соответствующие детали. Диаграммы классов очень быстро загромождаются. Взгляните на среднюю часть окна, отображаемые атрибуты помечены как общедоступные. Это означает, что другие классы имеют доступ к этим параметрам. В качестве обозначения это избавляет меня от необходимости указывать очевидные геттеры и сеттеры, которые мы здесь ожидаем. Ферстехен? …
Связь – это общий термин, охватывающий типы логических связей, обнаруживаемых на диаграммах классов и объектов. Класс может быть вовлечен в одно или несколько отношений с другими классами или экземплярами…
Отношения на уровне классов охватывают ключевые факторы объектно-ориентированной парадигмы: реализацию интерфейса (реализацию) и наследование (обобщение).
Реализация (Реализация интерфейса)
В моделировании UML реализация представляет собой взаимосвязь между двумя элементами модели, в которой один элемент модели (клиент) реализует поведение, заданное другим элементом модели (поставщиком).
Теперь то же самое на человеческом языке. Кошка – это домашний вид семейства Кошачьих. Я мог бы сказать, что Кошка – это воплощение кошачьих. Или, на объектно-ориентированном языке, Cat – это конкретная реализация интерфейса Felidae.
Обратите внимание, что окно интерфейса имеет только одну часть под заголовком, которая включает операции, которые имеют различные реализации.
Класс “Cat” реализует интерфейс “Felidae”. Мы можем распознать его по соединительной линии между их ячейками. Пунктирная линия с полой стрелкой, указывающей назад на реализуемый интерфейс.
Обратите внимание, что в поле Cat мы не показываем никаких операций, которые являются частью “Felidae”. Cat реализует эти операции, нет необходимости дублировать их (держите диаграммы как можно более чистыми, помните?).
Обобщение (Наследование)
Обобщение представляет собой отношение “ЕСТЬ” между общим классом (Cat) и более конкретной реализацией этого класса (Cat Breed). Русская голубая – это порода кошек, в то время как каждая конкретная порода кошек приобретает все атрибуты и функции Кошки, но также может иметь свои собственные. Например, кошки породы шотландская вислоухая могут вставать на задние лапы . Отношение обобщения, обозначенное в UML сплошной линией с вложенной полой стрелкой, указывающей назад на общий (базовый) класс.
Еще пара пунктов, которые следует иметь в виду здесь, – это концепция абстрактных и конкретных классов.
Абстрактный класс – это класс, который мы никогда не будем создавать. В UML имя этого класса должно быть выделено курсивом.
Конкретный класс – это класс, который мы фактически создаем. Это класс по умолчанию, без каких-либо специальных украшений его названия.
… Следующее, на что мы хотим обратить внимание в нашей диаграмме классов, – это моделирование отношений.
Базовая связь (Ассоциация)
Это ассоциативное отношение обычно описывается как отношение “ИМЕЕТ”. Это указывает на то, что по крайней мере один из двух связанных классов ссылается друг на друга. Эта связь представлена просто сплошной линией (без стрелки), которая соединяет два класса.
Теперь, часто, важно понимать, сколько элементов на каждой стороне отношений может существовать, что мы называем “мощностью”. Мощность выражается в терминах: “один к одному”, “один ко многим” и “многие ко многим”. В UML это обозначается следующим образом: Взгляните на эту диаграмму: В текущем примере у кошки есть человек (выбранный, справа). У человека есть несколько кошек (как русской голубой (подражатель), так и шотландской вислоухой породы. Правдивая история). Это отношения “многие к одному”.
Взаимосвязь агрегирования
Агрегирование – это вариант отношения “ИМЕЕТ”, однако оно более специфично, чем ассоциация. Агрегация представляет собой одностороннюю ассоциацию, называемую отношением “ЧАСТЬ-ЦЕЛОЕ”. Я имею в виду, что один объект работает как владелец (целое) другого (часть целого), но принадлежащие классы не имеют сильной зависимости жизненного цикла от владельца.
Вернемся к нашей Кошке. У каждой кошки должен быть домик для какашек. Таким образом, подразумеваемая связь между “Кошкой” и “Какашкой” будет отношением типа “ИМЕЕТ”. Но обратное может быть неверным. Каждая какашка не нуждается в содержании какой-либо кошки. Теперь легко распознать, что Cat является объектом-владельцем, и это отношение агрегации. В UML соединительная линия имеет полый ромб, указывающий на класс владельца . Какашка тесно связана с Кошкой.
Композиционные Отношения
Композиция – это отношение “ЧАСТЬ”, особый тип агрегации, где части не так сильно выделяются сами по себе. Класс owner здесь является своего рода контейнером, а связанные сущности являются его содержимым. Все объекты взаимозависимы друг от друга, например “ящик для мусора и комковатый мусор являются частью какашки”. Дом не может существовать без коробки или подстилки, не так ли? Здесь у нас есть сплошная линия с заполненным ромб, указывающая на класс владельца .
Использует Связь (Зависимость)
Отношения использования немного мягче связаны между классами. Эта связь указывает на то, что один класс зависит от другого, потому что он использует его в какой-то момент времени.
Например, другие члены семьи могут общаться с Кошкой и Человеком (что не очень приветствуется Кошкой). Использует обозначение отношений в виде пунктирной линии с открытой стрелкой, указывающей на используемые классы . Это помогает нам понять, что изменения в Кошке или Человеке могут повлиять на других членов семьи, и поэтому мы должны быть осторожны. У нас все хорошо? … Мы закончили. Теперь давайте проверим завершенный общий вид базовой диаграммы классов. Это все.
Чтобы ознакомиться с некоторыми другими диаграммами UML, о которых я писал, перейдите в мой профиль.
Оригинал: “https://dev.to/behalf/uml-diagrams-class-diagram-overview-5d16”