За пределами изолированных классов: архитектура структуры системы с помощью отношений UML и PlantUML

PlantUML Edit PlantUML in VPasCode

@startuml
skinparam style strictuml
skinparam classFontSize 14
skinparam defaultFontSize 12

title 1. Ассоциации: Пир-соединения в NexusMart

class Customer
class Password
class Reviewer
class Review

' Одностороннее навигирование (Customer -> Password)
Customer "1" --> "1" Password : аутентифицируется с

' Двусторонняя ассоциация с ролями, множественностью и меткой
Reviewer "1" - "0..*" Review : пишет

note on link
  Направление чтения UML: слева направо
  "1 Рецензент пишет 0..* отзыв(ов)"
end note

@enduml

2. Агрегации и композиции (иерархия «целое-часть»)

Когда отношения выражают асимметричную семантику «целое-часть», UML различает общую агрегацию (независимые жизненные циклы) и композицию (строгая принадлежность жизненного цикла).

Приложение NexusMart

Общая агрегация: Каталог содержит Продукт экземпляры. Удаление каталога не приводит к удалению продуктов; они сохраняются в основной базе данных.
Композиция: Заказ строго владеет Элемент заказа экземпляры. Уничтожение заказа приводит к каскадному удалению всех его строк.

Реализация PlantUML

PlantUML Edit PlantUML in VPasCode

@startuml
skinparam style strictuml

title 2. Агрегации против композиций: Семантика жизненного цикла

class Catalog
class Product
class Order
class OrderItem

' Общая агрегация: открытый ромб, независимый жизненный цикл
Catalog "1" o-- "*" Product : содержит

' Композиция: закрашенный ромб, строгая привязка жизненного цикла
Order "1" *-- "1..*" OrderItem : включает

note right of Order
  Композиция подразумевает каскадное удаление.
  Элемент заказа не может существовать без родительского заказа.
end note

@enduml

3. Обобщение (наследование)

Обобщение устанавливает таксономическую связь «является» (is-a). Подклассы наследуют структуру и поведение от суперкласса, специализируя его за счёт добавления атрибутов, переопределения операций или ограничения состояний. Повертипы могут дополнительно разделять подклассы на основе классификации во время выполнения.

Приложение NexusMart

Оплата выступает в качестве абстрактного суперкласса.
Оплата по кредитной карте, PayPalPayment, и CryptoPayment специализируйте его с помощью атрибутов, специфичных для шлюза, и логики проверки.

Реализация PlantUML

PlantUML

Редактирование PlantUML в VPasCode

PlantUML Edit PlantUML in VPasCode

@startuml
skinparam style strictuml

title 3. Обобщение: Иерархия наследования платежей

абстрактный класс Payment {
  +amount: Decimal
  +currency: String
  +process(): Boolean
}

class CreditCardPayment {
  +cardNumber: String
  +expiryDate: Date
  +cvv: String
  +validateCard(): Boolean
}

class PayPalPayment {
  +payerEmail: String
  +transactionId: String
  +verifyPayPalAccount(): Boolean
}

class CryptoPayment {
  +walletAddress: String
  +blockchainNetwork: String
  +confirmOnChain(): Boolean
}

Payment <|-- CreditCardPayment
Payment <|-- PayPalPayment
Payment <|-- CryptoPayment

@enduml

Редактирование PlantUML в VPasCode

4. Зависимости (динамика клиента-поставщика)

Зависимость — это направленная «использующая» связь, при которой изменение поставщика может потребовать изменения клиента. UML использует стереотипы для уточнения характера зависимости, превращая неясную пунктирную стрелку в точный архитектурный контракт.

Справочник стереотипов зависимости

Стереотип	Цель / Описание
`«use»`	Клиент требует от поставщика выполнения внутренних функций.
`«create»`	Операции клиента создают экземпляры класса поставщика.
`«instantiate»`	Явный путь инстанцирования на протяжении жизненного цикла выполнения.
`«derive»`	Целевое значение вычисляется на основе исходного элемента.
`«realize»`	Клиент реализует поведенческие спецификации, определённые поставщиком.
`«refine»`	Клиент представляет собой более низкоуровневую, более детальную формулировку поставщика.
`«trace»`	Отслеживает историческое или концептуальное развитие на разных уровнях абстракции.
`«permit»`	Поставщик предоставляет клиенту специальные права доступа к своим приватным компонентам.
`«заменить»`	Клиент выполняет контракт выполнения, ожидаемый от поставщика во время выполнения.

Приложение NexusMart

Сервис заказов использует Клиент инвентаризации для проверки наличия товара.
Заказ создает Счет после подтверждения.
Панель аналитики извлекает метрики из Заказ.

Реализация PlantUML

PlantUML Edit PlantUML in VPasCode

@startuml
skinparam style strictuml

title 4. Зависимости: контракты клиента и поставщика

class OrderService
class InventoryClient
class Order
class Invoice
class AnalyticsDashboard

OrderService .--> InventoryClient : «использует»
Order .--> Invoice : «создает»
AnalyticsDashboard .--> Order : «извлекает»

note bottom of OrderService
  Зависимости — это временные структурные связи.
  Они не подразумевают владение или привязку жизненного цикла.
end note

@enduml

5. Классы ассоциаций

Когда связь «многие ко многим» имеет собственные атрибуты или поведение, присоединение этих свойств к одному из классов-конечных точек нарушает принципы нормализации. Класс ассоциации объединяет связь и класс, фиксируя метаданные, которые строго относятся к самой связи.

Приложение NexusMart

Клиент и Продукт имеют связь «многие ко многим».
Запись о покупке выступает в качестве класса ассоциации, хранящего дату покупки, цена за единицу, и количество, которые логически относятся к связи транзакции, а не к клиенту или продукту независимо.

Реализация PlantUML

PlantUML Edit PlantUML in VPasCode

@startuml
skinparam style strictuml

title 5. Класс ассоциации: Нормализация связей «многие ко многим»

class Customer
class Product

' Основная ассоциация «многие ко многим»
Customer "*" - "*" Product

' Класс ассоциации, фиксирующий метаданные, специфичные для связи
class PurchaseRecord {
  +purchaseDate: DateTime
  +unitPrice: Decimal
  +quantity: Integer
  +calculateSubtotal(): Decimal
}

' Штриховая линия, связывающая класс ассоциации с отношением
(Customer, Product) .. PurchaseRecord

note right of PurchaseRecord
  Классы ассоциаций решают сложность M:N
  путем повышения связи до первого класса сущности.
end note

@enduml

6. Рекомендации, советы и постепенное уточнение

Структурное моделирование — это не одноразовая задача. Кендэлл Скотт подчеркивает поэтапное уточнение, визуальную дисциплину и контроль компоновки, чтобы сохранить диаграммы актуальными на протяжении всего жизненного цикла разработки.

Наилучшие практики моделирования

Группировка по контексту домена: Группируйте классы вокруг ограниченных контекстов (например, Заказы, Каталог, Платежи) для снижения когнитивной нагрузки и предотвращения «спагетти-макетов».
Устраните необработанные связи M:N: Преобразуйте неограниченные * к * связи в классы ассоциаций на ранних этапах анализа. Это готовит модель к реляционному отображению и проектированию на основе домена.
Постепенное уточнение по этапам:
- Домен (требования): Имена классов + широкие ассоциации. Нет атрибутов/операций.
- Анализ: Добавьте множественности, роли, ключевые атрибуты. Отложите методы.
- Проектирование: Полные сигнатуры, модификаторы видимости (+, -, #), реализационные стереотипы и контракты зависимостей.
Управление компоновкой PlantUML: Используйте направляющие указания (-left->, -down->, -right->, -up->) для принудительного чистого маршрутизирования и предотвращения пересечений линий в плотных графах.

Пример компоновки PlantUML и постепенного уточнения деталей

PlantUML

Редактирование PlantUML в VPasCode

PlantUML Edit PlantUML in VPasCode

@startuml
skinparam style strictuml
skinparam linetype ortho

title 6. Управление компоновкой и постепенное уточнение деталей (этап проектирования)

package "Контекст заказов" {
  class Order {
    -orderId: UUID
    -status: OrderStatus
    +submit(): void
    +cancel(): void
  }
  class OrderItem {
    -quantity: int
    -price: Decimal
    +getLineTotal(): Decimal
  }
}

package "Контекст оплаты" {
  abstract class Payment {
    +process(): boolean
  }
  class CreditCardPayment {
    -cardToken: String
    +validate(): boolean
  }
}

' Принудительная направленная компоновка для удобочитаемости
Order "1" *-- "1..*" OrderItem : содержит >
Order -right-> Payment : оплачивается через >
Payment <|-- CreditCardPayment

note as N1
  Модель этапа проектирования включает:
  - Модификаторы видимости (+, -)
  - Сигнатуры операций
  - Ортогональная маршрутизация линий
  - Контекстное упаковка
end note

@enduml