Как построить UML-диаграмму классов, выделив сущности предметной области. В чем разница между композицией и агрегацией, а также как показать ссылку на объект другого класса. Смотрим на примере интернет-магазина.
От доменного моделирования к коду: как составить UML-диаграмму классов
Когда аналитик начинает знакомиться с UML, многие концепции этого языка моделирования могут показаться сложными при отсутствии практики разработки на каком-либо языке программирования, поддерживающем объектно-ориентированную парадигму (ООП). Будучи основанным на понятиях ООП, UML позволяет спроектировать информационную систему через описание взаимодействующих объектов, каждый из которых является экземпляром какого-то класса. Класс в ООП – это абстракция, программная конструкция, которая позволяет создавать объекты по типовой структуре с общими свойствами и поведением. Например, товар в интернет-магазине имеет следующий набор характеристик, которые называют атрибуты или поля:
- название (строка);
- категория (строка);
- поставщик (ссылка на поставщика);
- стоимость (число).
Выделим класс Товар как абстракцию понятия доменной области. А жакет категории женская одежда от поставщика СуперШмот стоимостью 3 рубля будет конкретным представителем этого класса, т.е. его объектом. Другим объектом будут брюки категории женская одежда от того же поставщика СуперШмот стоимостью 5 рублей. Если эти объекты можно объединить в один комплект, например, брючный костюм категории женская одежда от поставщика СуперШмот стоимостью 7 рублей, между ними будет ассоциативная связь, о которой мы поговорим позже.
А пока отметим, что манипулировать объектами в ООП можно только после определения классов, к которым они принадлежат. Таким образом, класс представляет собой конструктор (шаблон), определяющий свойства и методы, которыми обладают все его объекты. Когда конкретный объект находится в памяти, занимая определенную именованную область памяти программы, и к нему можно обратиться по имени переменной, его называют экземпляром класса. Класс описывает поля и методы, которые будут доступны у его объекта. Объекты используются для моделирования конкретных сущностей реального мира. Можно сказать, что класс – это структура данных, т.е. комплексный тип данных, на который можно ссылаться, подобно тому, как атрибут поставщик в сущности Товар является ссылкой на сущность Поставщик.
Рассмотрим, как реализуются эти понятия ООП, написав на Python несколько классов, соответствующих исследуемому домену (интернет-магазин). Для этого сделаем сопоставление сущностей предметной области с классами в таблице.
| Сущность домена | Свойства | Класс | Поле | Тип данных |
| Товар | название (строка) | Product | name | str |
| категория (строка) | category | str | ||
| поставщик (ссылка на поставщика) | provider | Provider | ||
| составные части (ссылки на другие товары) | elements | массив [Product] | ||
| стоимость (вещественное число) | price | float | ||
| Заказ | номер (целое число) | number | int | |
| отметка времени (дата) | timestamp | date | ||
| клиент (ссылка на клиента) | customer | Customer | ||
| список заказанных товаров (ссылка на товар) и их количество (целое число) | products | массив [Product, int;] | ||
| сумма (вещественное число) | sum | float | ||
| Поставщик | название компании (строка) | Provider | company | str |
| ИНН (строка) | inn | str | ||
| адрес электронной почты (строка) | str | |||
| телефон (строка) | phone | str | ||
| физический адрес (строка) | address | str | ||
| Покупатель | имя (строка) | Customer | name | str |
| адрес электронной почты (строка) | str | |||
| телефон (строка) | phone | str |
DDD, ООП и UML для аналитика
Код курса
BUML
Ближайшая дата курса
9 декабря, 2024
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.
Визуализируем представленную таблицу виде UML-диаграммы классов, расставив кратности связей между классами:
- один покупатель может сделать множество заказов, но в одном заказе лишь один покупатель;
- в один заказ может входить множество товаров, и один товар может быть в составе многих заказов;
- один поставщик может поставить множество товаров, но у каждого товара лишь один поставщик.
Эта диаграмма создана с помощью следующего скрипта PlantUML:
@startuml
class Provider {
+ company: str
+ inn: str
+ email: str
+ phone: str
+ address: str
}
class Customer {
+ name: str
+ email: str
+ phone: str
+ address: str
}
class Order{
+ number: int
+ timestamp: date
+ products: [Product, int]
+ customer: Customer
+ sum: float
+ add_product()
}
class Product {
+ name: str
+ category: str
+ elements: [Product]
+provider: Provider
+price: float
+ add_element()
}
Product "*" --> "1" Provider
Product "1" *--> "*" Product
Customer "1"<- "*" Order
Order "*" o-> "*" Product
@enduml DDD, ООП и UML для аналитика
Код курса
BUML
Ближайшая дата курса
9 декабря, 2024
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.
Ассоциативные связи на диаграмме классов: агрегация vs композиция
В отличие от проектирования реляционной модели данных, понятие нормализации в UML не применимо и нет необходимости «развязать» связь много-ко-многим через отдельный класс, т.к. это реализуется в коде. Как именно это делается, разберем в следующей статье, когда перейдем к коду. А пока рассмотрим связи на этой UML-диаграмме классов. В этом примере все связи между классами являются ассоциативными и представленной в виде направленной ассоциации, когда один класс (первичный), использует другой класс (вторичный), в качестве своего поля или метода. В отличие от простой ассоциации, направленная имеет стрелку, указывающую направление связи между классами. Например, связь ассоциации от класса Order к классу Customer показывает, что каждый заказ соответствует конкретному покупателю, поскольку сделан от его имени.
Ассоциация в UML бывает не только простая или направленная, но и с маркировкой силы этой связи. В зависимости от степени силы ассоциативной связи, ассоциация может быть следующих видов:
- агрегация – связь между классами, когда объект одного класса содержит другой объект в качестве своей части. Причем, объект-часть может принадлежать только одному объекту-целому, и объект-целое продолжает существовать, даже если объект-часть удален. Агрегация в UML обозначается незакрашенным ромбом, где ромб указывает на объект-целое, а линия указывает на объект-часть. Например, каждый заказа содержит набор товаров, т.е. объект класса Product является частью объекта класса Order.
- композиция — связь между классами, когда объект одного класса является частью объекта другого класса и не может существовать отдельно от него. Когда объект-целое удаляется, все его объекты-части также удаляются. Композиция в UML обозначается закрашенным ромбом, где ромб указывает на объект-целое, а линия указывает на объект-часть.
В случае композиции объект-целое полностью контролирует жизненный цикл объектов-частей, которые являются его составными компонентами и могут иметь доступ к его методам и свойствам. В отличие от агрегации, при композиционной связи объект-часть может быть создан только в контексте объекта-целого и не может использоваться в другом контексте. Когда объект-целое удаляется, все его объекты-части также удаляются. Если в нашем магазине при удалении брючного костюма должны удалиться все его составные части, т.е. жакет и брюки, это как раз соответствует самой сильной ассоциативной связи, т.е. композиции.
Как показывает мой опыт преподавания курсов по UML, эта тема обычно бывает сложной, причем как для непрограммирующих аналитиков, так и для тех, кто имеет опыт разработки на любом ООП-шном языке. Причем, особенно часто тонкая грань между ассоциацией, агрегацией и композицией вызывает недоумение у коллег с опытом разработки, т.к. в коде все эти понятия реализуются абсолютно одинаково, через ссылку на объект другого класса, что я и покажу в следующей статье.
DDD, ООП и UML для аналитика
Код курса
BUML
Ближайшая дата курса
9 декабря, 2024
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.
Проверить свои знания UML вы можете прямо на нашем сайте, выполнив бесплатный интерактивный тест.
А научиться самостоятельно разрабатывать эти и другие UML-диаграммы вам поможет мой специализированный курс «UML для бизнес-аналитиков». Только практика на реальных примерах. После 8-часового интенсива вы сможете дополнять моделировать программные системы, чтобы наглядно объяснить разработчикам, из чего они должна состоять и что делать.
