Диаграмма классов как и любые другие диаграммы и схемы - это про визуализацию.
Что есть класс? Кажется, класс очень близок по семантике к классификации. Когда мы что-то классифицируем - мы это что-то типизируем, то есть облекаем в какую-то форму, и нам становится понятным, что за объект перед нами.
У класса есть:
- имя - кто я как класс;
- какие-то атрибуты или характеристики - чем я отличаюсь;
- операции (действия) - что я как класс умею (могу) делать.
Объект, который попадает в класс - это экземпляр класса. Не все экземпляры одинаковы, но все экземпляры обладают параметрами основного класса. Иначе говоря, у экземпляра класса могут быть какие-то отличительные характеристики.
Классы в Системе состоят в отношениях.
Какие бывают отношения между классами?
- Наследование (или обобщение)
Используем для описание между классами: "родитель" - "дочка". Например: "Кухонная бытовая техника" - родительский класс, а "Микроволновые печи" & "Духовые шкафы" - это дочерние.
По сути, и микроволновки и шкафы - это бытовая техника, которая помогает нам с делами на кухне.
Здесь подклассы наследуют все функции родителя, а родитель включает в себя все атрибуты, методы и подклассы.
- Ассоциация
Наверное, наиболее популярная форма отношений между классами, которая показывает наличие связи.
Для того, чтобы указать количество объектов класса вступающих в связь, мы используем определенную маркировку связи, а именно:- 1..1 : Один к одному
- 1..* : Один ко многим
- 0..* : Ноль или больше
- 0..1 : Нет или только один
- m..n : Не менее m - не более n (m<=n)
Через ассоциацию между классами "Кухня" и "Бытовая техника" мы показываем, что на 1 кухне может находиться множество (*) различных бытовых приборов.
- Зависимость
Более строгий тип отношений, который показывает, что изменение в одном элементе связки влечет за собой изменения в другой. Пусть и относительно, но мы можем описать отношение "Зависмость" как витальную необходимость одного класса в другом.
Например, "Микроволновка" не будет работать без "Электричества"
Строим связь от зависимого класса к основному.
- Агрегация
Отношения данного типа агрегируют части в целое. При этом часть целого может существовать и как самостоятельный класс.
Например, "Кухня" у нас агрегирует в себе "Стол" и "Стул", но при этом последние - вполне себе самостоятельные классы, которые существуют в отрыве от агрегирующего их класса.
- Композиция (состав)
Здесь мы показываем более жесткую связь целого и части, когда целое зависит от части, его составляющей, и наоборот. Как только целая часть перестает существовать, составляющие её компоненты - тоже.
Как, например, если мы представим себе кухню, как отдельно стоящее здание, то без стен и потолка кухня не существует.
Прежде чем рисовать диаграмму
Есть такая штука, как боязнь белого листа - неважно, этот лист аналоговый или цифровой.
Одна из моих друзей - прекрасный аналитик и налоговый консультант, говаривала: "Чтобы проучить страх белого листа, начинай со слов: "Короче, бл@ " "
Не призываю делать это буквально, но, мантра, произнесенная про себя, - тоже работает.
Итак, для начала нам нужно определить предметную область - что мы проектируем, отрезать всё лишнее. Определить участников, чем мы оперируем, и что храним.
Далее определить состав классов, какие из них будут основными, какие нет, придумать имена для классов.
Далее, когда мы убедимся, что верхнеуровнево мы объявили все классы, мы их наполняем атрибутами, методами.
Далее мы навешиваем взаимосвязи или отношения классов друг к другу.
Диаграмма должна быть читабельна и проста, не стоит перегружать её длинными комментариями и ремарками. Если мы начинаем сопровождать нашу диаграмму лонгридами в комментах - это значит, что мы что-то сделали не так. Диаграмма должна читаться сама по себе. Потому имена классов, атрибутов, методов должны быть семантически понятными.
Пример: сервис заказа билетов в кино
Читаем диаграмму, и акцентируем наше с вами внимание на том, что мы посчитали важным и сумели показать с помощью диаграммы классов.
Сверху - вниз:
-
Наш центральный персонаж триллера под названием "Закажи билет в кино" - это Customer.
Customer находится в отношениях с Personal Data Access, для него это витальная связь. Если не будет создана запись про разрешение использовать персональные данные, то сам Customer не случится.
Эта связь у нас композиционная. При этом Customer единожды дает право на использование данных: 1:1.
Бизнесово это значит, что если клиент (пользователь сервиса) отзовет данное разрешение на использование перс данных, то данный пользователь перестанет существовать. -
Профиль Customer связан с Cards таким образом, что мы понимаем, что один клиент может не иметь карту, или может иметь более чем одну карту. При этом класс Cards является составной частью класса Customer, однако, в отличие от композиции, описанной выше, если вдруг будет удалена запись о карте клиента, сама сущность клиента не перестанет существовать.
То есть, здесь через агрегацию мы показываем, что сущность карты связана с сущностью клиента. -
Customer связан с сущностью заказа (Booking). Связан через ассоциацию, таким образом, что мы понимаем, что один клиент может не создавать заказов или создавать их бесконечное множество.
Далее центральную роль в развитии сюжета на себя перехватывает Заказ и связанные с ним сущности. -
Через ассоциацию мы связываем заказ с платежом (Payment) - один к одному.
В свою очередь платеж генерирует счет, так же 1:1. Счет в свою очередь включает в себя единицу товара - и здесь мы видим, что у нас снова объявлена композиционная связь.
То есть, если удалить товар, то вместе с ним удалится и счет.
Является ли данная связь оправданной и почему?
Как мы должны поступать, применительно к бизнесу кинопроката, когда фильм снят с показа?
Это не означает, что проект неверный, но точно означает, что на схеме нет ответа на вопрос, почему мы проектируем именно так. -
Инвойс генерирует билет, при этом с одного счета может быть сгенерирован n количество билетов, и далее производится формирование сообщения, которые мы отправляем клиенту в какое-то канал (не является частью настоящей схемы), и показываем, что сообщение включает в себя атрибуты билета. То есть, по факту, сообщение клиенту - это электронная форма билета.
-
Кроме платежа мы видим так же возврат. Класс возврата у нас витально связан со счетом, только при наличии оплаченного счета может возникнуть возврат. Если удалить счет, то связанный с ним возврат, не имея основного документа, так же должен быть удален.
Мы оставляем за кадром достаточность и всестороннюю корректность диаграммы. Цель - научиться читать диаграммы, использовать инструменты и уметь аргументировать те или иные решения, объявленные в диаграмме.
Comments are closed