Диаграммы классов UML для моделирования данных с помощью PlantUML

A диаграмма классов UML описывает структуру системы: вещи, которые она моделирует, их свойства и взаимосвязи. При моделировании данных она может захватывать концепции домена и ограничения до того, как вы приступите к созданию таблиц или кода приложения.

PlantUML делает диаграмму воспроизводимой: вы пишете текст, отображаете её, просматриваете изменения в системе контроля версий и обновляете её по мере развития модели. Она дополняет, а не заменяет схемы баз данных, миграции и подробные бизнес-правила.

1. Выберите уровень моделирования

Полезная диаграмма моделирования данных обычно фокусируется на одном уровне за раз:

• Концептуальный: бизнес-концепции и отношения с минимальным техническим описанием. Пример:Клиент размещает Заказ.

• Логический: атрибуты, идентификаторы, множественность и правила, не привязывая модель к конкретной базе данных.

• Физический: детали реализации, такие как типы столбцов SQL, индексы и ограничения, специфичные для базы данных.

В приведенном ниже примере это логическая модель домена. Типы, такие как UUID, Деньги, и DateTime являются иллюстративными; определите их конкретные представления при выборе технологии.

2. Основы PlantUML

Класс имеет имя и может перечислять атрибуты и операции:

@startuml
class Customer {
  -id: UUID
  +name: String
  +email: String
  +changeEmail(newEmail: String): void
}
@enduml

Маркеры видимости являются необязательными подсказками моделирования:

• + публичный

• - приватный

• # защищенный

• ~ видимость пакета

Для диаграммы домена или данных наиболее важны атрибуты. Включайте операции только тогда, когда они уточняют важное поведение; избегайте превращения диаграммы в полный перечень кода.

3. Связи и множественность

Наиболее полезные обозначения связей для моделирования данных:

Метки множественности располагаются рядом с концами ассоциации:

• 1 — ровно один

• 0..1 — необязательно, не более одного

• * или 0..* — ноль или более

• 1..* — один или более

• 2..5 — ограниченный диапазон

Например:

Клиент "1" -- "0..*" Заказ : размещает

Внимательно прочитайте метки на каждом конце: один клиент может разместить ноль или более заказов; каждый заказ связан ровно с одним клиентом. Метки описывают отношение, а не обязательно реализацию внешнего ключа в конкретной базе данных.

4. Пример с решением: интернет-магазин

Эта модель включает клиентов, заказы, позиции заказов, товары и записи об оплате. Она демонстрирует идентификаторы, типы, похожие на значения, перечисления, композицию и множественность.

@startuml ShopDomain
skinparam classAttributeIconSize 0
skinparam shadowing false

hide methods

class Клиент {
  +customerId: UUID
  +email: EmailAddress
  +displayName: String
}

class Заказ {
  +orderId: UUID
  +placedAt: DateTime
  +status: OrderStatus
  +total: Money
}

class ПозицияЗаказа {
  +lineNumber: Integer
  +quantity: PositiveInteger
  +unitPrice: Money
}

class Товар {
  +productId: UUID
  +sku: SKU
  +name: String
  +currentPrice: Money
}

class Оплата {
  +paymentId: UUID
  +amount: Money
  +status: PaymentStatus
  +paidAt: DateTime [0..1]
}

class Money <<объект-значение>> {
  +amount: Decimal
  +currency: CurrencyCode
}

enum OrderStatus {
  ЧЕРНОВИК
  РАЗМЕЩЕН
  ОПЛАЧЕН
  ВЫПОЛНЕН
  ОТМЕНЕН
}

enum PaymentStatus {
  ОЖИДАЕТСЯ
  УТВЕРЖДЕН
  ЗАХВАЧЕН
  ОШИБКА
  ВОЗВРАЩЕН
}

Клиент "1" -- "0..*" Заказ : размещает
Заказ "1" *-- "1..*" ПозицияЗаказа : содержит
ПозицияЗаказа "0..*" --> "1" Товар : ссылается на
Заказ "1" -- "0..*" Оплата : попытки оплаты
Заказ --> OrderStatus
Оплата --> PaymentStatus
ПозицияЗаказа --> Money : цена за единицу
Оплата --> Money : сумма

note right of ПозицияЗаказа
  количество должно быть больше нуля
  unitPrice — это цена, зафиксированная
  при размещении заказа
end note

note right of Товар
  Product.currentPrice может изменяться.
  Это не заменяет OrderLine.unitPrice.
end note
@enduml

Почему моделировать OrderLine явно? Связь между заказом и продуктом имеет собственные данные — количество и цена на момент покупки. Это делает её концепцией домена, а не просто простой ссылкой.

Почему композиция от Order к OrderLine? В примере предполагается, что строка заказа принадлежит одному заказу и не имеет самостоятельного смысла. Используйте композицию только в том случае, если в вашем домене действительно выполняется правило владения и жизненного цикла; нотация UML не обеспечивает его соблюдение в базе данных.

Почему различать текущие и исторические цены? Цена продукта может измениться после оформления заказа. Сохранение цены на момент покупки в строке заказа позволяет сохранить историческую сумму.

5. Моделирование решений, которые имеют значение

Идентификаторы: Одинаково выделяйте идентификаторы, например customerId или orderId. UML не определяет единого универсального обозначения для первичных ключей, поэтому выберите соглашение и документируйте его. Стереотип или примечание могут сделать это явным:

class Customer {
  +customerId: UUID <<PK>>
  +email: EmailAddress
}

Необязательные значения: Используйте [0..1] для необязательного атрибута, когда это очевидно для ваших читателей, или укажите правило. Например, платеж может не иметь paidAt отметки времени до успешного завершения.

Объекты значений: Тип, такой как Money или EmailAddress может представлять концепцию с собственной проверкой или семантикой. Определите, должен ли он отображаться как отдельный класс, тип атрибута или структура базы данных, исходя из аудитории и уровня детализации.

Перечисления и контролируемые значения: Используйте перечисление, когда разрешенный набор небольшой и относительно стабильный. Если значения требуют независимых описаний, жизненного цикла или администрирования, моделируйте их как класс вместо этого.

Нормализация и реализация: Диаграмма классов передает концепции и правила; она не решает каждую деталь связей. Например, является ли Деньги двумя столбцами, отдельной таблицей или типом, специфичным для базы данных, — это решение реализации.

Держите диаграммы читаемыми: Разделите крупную область на направленные диаграммы — например, заказы, инвентарь и идентификация — и используйте пакеты для группировки связанных классов. Показывайте только атрибуты, релевантные вопросу, на который должна отвечать диаграмма.

6. Создание модели на основе требований

1. Извлечение кандидатских концепций из языка домена: существительные часто указывают на классы; глаголы часто указывают на отношения или поведение.

2. Уточнение правил с помощью конкретных вопросов: Может ли заказ существовать без клиента? Может ли он иметь нулевое количество строк? Может ли платеж быть повторен?

3. Выбор уровня моделирования и оставьте технические решения базы данных за пределами концептуальной диаграммы.

4. Добавление атрибутов и идентификаторов только тогда, когда они помогают объяснить модель.

5. Установка многозначности на основе бизнес-правил, проверяя оба конца каждой связи.

6. Проверка граничных случаев: удаление, исторические записи, необязательные поля, повторные попытки и изменение значений.

7. Отобразить и проверить диаграмму с экспертами по предметной области и разработчиками. Рассматривайте её как модель для проверки, а не просто как изображение для утверждения.

7. Используйте VPasCode и Visual Paradigm

VPasCode это браузерный редактор текста в диаграмму с поддержкой PlantUML и живой предварительный просмотр. В описании функций также указано создание и изменение кода диаграммы с помощью ИИ, а также помощь в синтаксисе. Практичный рабочий процесс следующий:

1. Откройте VPasCode и выберите или введите PlantUML.

2. Вставьте приведённый выше пример и проверьте отображённую диаграмму.

3. Повторно используйте исходный код PlantUML; храните текст как версионный артефакт.

4. Используйте помощника ИИ, если он доступен в вашей рабочей среде, для создания первого черновика или его доработки.

5. Самостоятельно проверьте каждый сгенерированный класс, связь, множественность и бизнес-правило.

Инструменты диаграмм с поддержкой ИИ от Visual Paradigm могут генерировать редактируемые диаграммы на основе описаний на естественном языке. Опубликованный рабочий процесс описывает создание диаграммы классов на основе запроса, а затем уточнение её элементов и связей. Рассматривайте вывод ИИ как черновик: он может неправильно определить владение, пропустить ограничения или включить необоснованные классы. Правильность модели всё ещё зависит от проверки её соответствия требованиям.

Например, обратитесь к помощнику ИИ с запросом:

Создайте логическую диаграмму классов UML для интернет-магазина. Клиенты размещают заказы. Каждый заказ содержит одну или несколько строк заказа. Каждая строка заказа ссылается на один продукт и хранит количество и цену за единицу на момент покупки. Заказы могут иметь несколько попыток оплаты. Включите идентификаторы, множественность и перечисления статусов заказа и оплаты. Выводите только PlantUML.

Затем проверьте результат по требованиям перед его принятием. Для лучшего результата явно укажите предположения — например, могут ли заказы быть черновиками без строк, и могут ли оплаты быть возвращены.

Visual Paradigm описывает VPasCode как редактор, совместимый с PlantUML с живым отображением и генерация или модификация с помощью ИИ. Инструменты и доступность могут различаться в зависимости от версии продукта или рабочей среды.

8. Компактный чек-лист для проверки

Перед тем как поделиться или реализовать диаграмму классов, проверьте:

• Каждый ли класс представляет собой значимое концептуальное понятие домена?

• Ясны ли идентификаторы и важные атрибуты?

• Правильно ли указаны метки отношений и множественности на обоихконцах?

• Отражает ли композиция реальную зависимость жизненного цикла?

• Сохраняются ли исторические факты там, где текущие значения могут изменяться?

• Видны ли необязательные значения и бизнес-ограничения?

• Достаточно ли диаграмма сфокусирована на своей аудитории?

• Был ли проверен сгенерированный контент по отношению к реальным требованиям?

Лучший рабочий процесс диаграмм как кода — это ИИ для начального черновика, PlantUML для точной редактирования и истории версий, а также человеческая проверка на корректность домена.

Эта статья также доступна на Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Việt Nam, 简体中文 and 繁體中文