Структурные диаграммы (Class, Object, Package)

Структурные диаграммы UML (Unified Modeling Language) описывают статическую сторону решения: из каких типов и экземпляров оно состоит и как они связаны. Для системного аналитика они закрывают вопрос «из чего состоит доменная и объектная структура решения?» — в отличие от поведенческих диаграмм, которые показывают динамику. В UML 2.5 семейство структурных диаграмм шире (Component, Composite Structure, Deployment, Profile и др.); здесь разбираются три базовые: Class, Object и Package. Детали модели данных и ER-слоя — в 03.03.01 ER-диаграммы (сущность-связь); динамика — в 06.01.02 Поведенческие диаграммы (State, Activity, Use Case) и 06.01.03 Диаграммы взаимодействия (Sequence, Communication). Формальная опора нотации — спецификация OMG UML 2.5; контекст стандартов для аналитика — в 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148).

1. Суть темы

Структурные диаграммы отвечают на вопрос «Из чего состоит система в данный момент (типы) или в конкретном сценарии (экземпляры)?». Они не заменяют ER-модель предметной области и не являются целью сами по себе: это спецификация структуры для согласования с командой, трассировки к требованиям и проверки непротиворечивости.

Уровни модели: что показывать кому

На одном проекте не смешивайте уровни без явной пометки — иначе заказчик увидит «классы для разработки», а команда потеряет доменный смысл.

Уровень реализации в артефактах требований появляется редко: его ведёт команда разработки в репозитории или reverse-engineering в EA. Аналитик подключается, когда нужно сопоставить доменную модель из SRS с фактической структурой сервисов — не чтобы заменить исходники, а чтобы зафиксировать расхождения перед приёмкой или рефакторингом. Концептуальная модель объясняет предметную область; спецификация для команды может стать основой для реализации — но генерация кода и схемы БД для аналитика следствие согласованной модели, а не главная цель артефакта. Для хранения данных параллельно смотрите 03.03.01 ER-диаграммы (сущность-связь), 03.03.02 Логическая и физическая модель данных и 10.01.03 Шаблон спецификации БД сервиса.

Граница статьи

Полный перечень структурных диаграмм UML 2.5 включает также Component, Composite Structure, Deployment, Profile. Они не входят в scope этой заметки; соседние материалы раздела 06.01 покрывают поведение и взаимодействие. Архитектурная декомпозиция системы — в 03.01.03 Декомпозиция системы на подсистемы и модули и 03.01.01 Понятие архитектуры ИС и её виды (бизнес-, системная, техническая).

Если нужна не OO-структура домена, а размещение на инфраструктуре или состав компонентов поставки, UML deployment/component diagram здесь не разбираются — для этих задач удобнее 06.03.05 C4-модель (уровни контейнеров и компонентов) и 06.03.03 Прикладной и технологический слои (ArchiMate для связки приложения и платформы).

2. Ключевые понятия

2.1 Диаграмма классов (Class Diagram)

Самая распространённая структурная диаграмма: типы объектов (классы), их структура и статические отношения.

Минимум для SRS и ревью с командой (первый проход): ассоциация, композиция, обобщение, кратность, роли, навигация, ключевые атрибуты и операции. Этого достаточно, чтобы согласовать домен и трассировать к требованиям.

Можно отложить до второго прохода или углублённого моделирования: агрегация (если композиция и ассоциация уже закрывают домен), квалифицированные ассоциации, ассоциативные классы (если связь M:N уже описана в ER), стереотипы <<boundary>> / <<control>>, формальные Profile.

Класс изображается прямоугольником из трёх секций:

• Имя — жирный шрифт; абстрактный класс — курсив или {abstract}.
• Атрибуты — видимость имя : тип [кратность] = начальное_значение {ограничения}.
• Операции — видимость имя (параметр : тип, ...) : возвращаемый_тип {свойства}.

Видимость: + public, - private, # protected, ~ package.

Пример класса Заказ:

+ идентификатор : Integer {readOnly}
- дата : Date
# статус : String
+ рассчитатьИтого() : Double
- проверитьНаличие() : Boolean

Отношения между классами

Кратность на концах ассоциации: 1, 0..1, *, 0..*, 1..*.

Роли подписывают смысл конца связи (размещает / оформлен). Навигация (navigability) — стрелка или явная однонаправленность: с какого класса «виден» связанный. Двунаправленная ассоциация без ролей и навигации — частый источник неоднозначности в SRS и API-моделях; фиксируйте направление чтения явно.

classDiagram
    class Клиент {
        +имя
        +email
        +сделатьЗаказ()
    }
    class Заказ {
        +номер
        +дата
        +рассчитатьИтого()
    }
    class СтрокаЗаказа {
        +количество
        +цена
    }
    class Товар {
        +наименование
        +базоваяЦена
    }

    Клиент "1" -- "0..*" Заказ : размещает
    Заказ "1" *-- "1..*" СтрокаЗаказа : содержит
    СтрокаЗаказа "1..*" -- "1" Товар : ссылается на

В Mermaid типы атрибутов опускены — каноническая запись в текстовых спецификациях: имя : тип (см. пример класса Заказ выше).

Абстракция, интерфейс, стереотипы

• Абстрактный класс — не инстанцируется, может содержать абстрактные операции.
• Интерфейс на class diagram — прямоугольник со стереотипом <<interface>>. Нотация «lollipop» (кружок) чаще встречается на component-диаграммах; здесь придерживайтесь прямоугольника, чтобы не смешивать нотации.
• Стереотипы в работе SA: <<entity>>, <<service>>, <<DTO>> — уточняют роль класса в спецификации. Пары <<boundary>> / <<control>> — наследие robustness/analysis model (Jacobson); в большинстве современных команд не используются — не включайте их в «рекомендуемый набор» без явного запроса методологии. Достаточно согласованного словаря в 10.01.14 Шаблон глоссария и словаря данных.

Продвинутые конструкции

• Ассоциативный класс — связь с собственными атрибутами. Пример: Работник — Проект через класс Участие с атрибутом часыРаботы. В ER-нотации тот же паттерн — ассоциативная сущность для связи M:N; см. 03.03.01 ER-диаграммы (сущность-связь). На проекте выберите одну нотацию для SRS или явно трассируйте класс к ER-сущности.
• Квалифицированная ассоциация — доступ к связанным объектам по ключу (квалификатор на конце линии), например Склад[артикул] → Товар.
• Ограничения в {}: {readOnly}, {ordered}, {unique}.

2.2 Диаграмма объектов (Object Diagram)

Снимок экземпляров в конкретный момент: объекты, значения атрибутов (слоты) и линки (экземпляры ассоциаций). Кратности на object diagram не ставят — это уже конкретные связи.

Обозначение объекта: прямоугольник с подчёркнутым именем имяОбъекта : ИмяКласса или : ИмяКласса для анонимного. Слоты перечисляются внутри прямоугольника; линки — сплошные линии без кратностей.

Пример эталонного сценария для V&V (текстовая запись — предпочтительный формат в SRS):

клиентИван : Клиент          ← подчёркнуто
  имя = "Иван Петров"
  email = "ivan.petrov@example.com"
 
заказ1024 : Заказ            ← подчёркнуто
  идентификатор = 1024
  дата = 2025-03-15
  статус = "Оплачен"
 
строка1 : СтрокаЗаказа       ← подчёркнуто
  количество = 2
  цена = 1500.00
 
товарРучка : Товар           ← подчёркнуто
  наименование = "Ручка гелевая"
 
линки:
  клиентИван ──размещает──► заказ1024
  заказ1024 ──содержит──► строка1
  строка1 ──ссылается на──► товарРучка

Рисуйте object diagram в 07.04 Инструменты моделирования (Sparx EA, Lucidchart, draw.io) — Mermaid и упрощённые редакторы не воспроизводят подчёркивание имён и нотацию : Класс; не используйте pseudo-object diagram из wiki-редакторов как образец нотации.

2.3 Диаграмма пакетов (Package Diagram)

Группирует классы, интерфейсы и другие пакеты; показывает зависимости между группами и иерархию имён. Пакет — «папка» (прямоугольник с ярлычком).

Зависимость между пакетами (пунктирная стрелка) уточняется стереотипами:

• <<use>> — клиент использует элементы поставщика.
• <<import>> — публичный импорт имён.
• <<access>> — приватный доступ без экспорта имён.

Вложенность — пакет внутри пакета без отдельной линии.

graph TD
    subgraph Представление["Представление (View)"]
        UI["Web-интерфейс"]
    end
    subgraph БизнесЛогика["Бизнес-логика (Service)"]
        Сервисы["Сервисы заказов"]
        Домен["Доменная модель"]
    end
    subgraph Данные["Данные (Data)"]
        Репозиторий["Репозитории"]
        Сущности["Сущности хранения"]
    end

    UI -.->|<<use>>| Сервисы
    Сервисы -.->|<<use>>| Репозиторий
    Домен -.->|<<import>>| Сущности

Рисунок выше — схема зависимостей в Mermaid, а не буквальная UML package notation (символ «папки»). Смысл use / import / access соответствует спецификации; детали рисования — в 07.04 Инструменты моделирования (Sparx EA, Lucidchart, draw.io).

Типовые паттерны группировки — слои (View / Service / Data), функциональные модули (Заказы, Клиенты) или общее ядро (Shared Kernel). Глубокая архитектурная и DDD-разметка — в 03.01.01 Понятие архитектуры ИС и её виды (бизнес-, системная, техническая) и 03.06.02 Основы Domain-Driven Design; здесь достаточно показать границы пакетов на уровне модели.

3. Как применяется в работе аналитика

Когда какую диаграмму строить

Object diagram для аналитика — не ежедневный инструмент. Имеет смысл, когда: (1) нужно проверить, что кратности class diagram допускают реалистичный сценарий; (2) в спецификации требуется конкретный эталонный пример для V&V; (3) мультипликация или композиция неочевидны для заказчика — один снимок снимает споры быстрее абстракции.

Трассировка к требованиям

Связывайте классы и ключевые операции с user story, use case или FR — через 02.03.04 Трассировка требований (концепция) и 10.01.15 Шаблон матрицы трассировки. Минимум: у каждого значимого класса есть хотя бы одно функциональное требование или прецедент из 03.02.01 Диаграмма прецедентов (Use Case Diagram) / 04.02 Пользовательские истории (User Stories) и Job Stories.

Связка статики и динамики

• Операция на class diagram (Заказ.оплатить()) → сценарий на sequence diagram.
• Атрибут со state-dependent поведением (статус) → state machine diagram.

Куда идти за динамикой: трек 03.02 (SA) vs 06.01 (расширенный UML)

Обе ветки описывают одну и ту же семантику UML; дублировать диаграмму в двух местах не нужно — выберите трек по аудитории артефакта. В этой статье (раздел 06.01) отсылки к 06.01.0x — справочные; для ежедневной работы над требованиями чаще достаточно материалов раздела 03.02.

• Пакет «Доменная модель» → граница контекста на 03.01.02 Моделирование контекста системы (Context Diagram).

Когда диаграмма не нужна

Не стройте class/package diagram «для галочки»:

• небольшая фича в 05.02 Scrum и Kanban (аналитик в Agile)-итерации, где достаточно ER + 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf) + текста в story;
• команда уже ведёт модель в коде, а ваша задача — уточнить контракт API, а не OO-дизайн;
• дублирование 03.03.01 ER-диаграммы (сущность-связь) без добавления операций или ролей классов.

Критерий: диаграмма должна снимать неоднозначность, которую текст или ER не закрывают.

Ревью модели

Перед передачей в разработку проверьте согласованность с требованиями: нет «божественных» классов, лишних двунаправленных связей, композиции там, где в домене часть переживает целое. Формальное рецензирование — 08.04 Рецензирование и инспекции (техники Фейгана); проверка модели как артефакта требований (полнота, непротиворечивость, трассировка) — 08.03 Тестирование требований (статическое тестирование).

4. Типовые ошибки и ограничения

Ограничения нотации: Mermaid и многие онлайн-редакторы упрощают UML; для формального соответствия UML 2.5 опирайтесь на спецификацию OMG и профильные инструменты (07.04 Инструменты моделирования (Sparx EA, Lucidchart, draw.io)). Class diagram не описывает потоки управления — дополняйте поведенческими диаграммами из раздела 06.01 или 03.02 по таблице выше.

Связи с другими разделами базы

• 08.03 Тестирование требований (статическое тестирование) — проверка модели как артефакта требований
• 10.01.03 Шаблон спецификации БД сервиса — переход от классов-сущностей к схеме хранения
• 06.03.05 C4-модель — компоненты и контейнеры вместо UML Component/Deployment
• 06.03.03 Прикладной и технологический слои — размещение и технологический стек (ArchiMate)

Источники и дополнительные материалы

Книги и стандарты

• OMG Unified Modeling Language (OMG UML), Version 2.5.1 — официальная спецификация: https://www.omg.org/spec/UML/2.5.1
• Гради Буч, Джеймс Рамбо, Ивар Якобсон. «Язык UML. Руководство пользователя» — классическое руководство от создателей. 2-е издание, ДМК Пресс.
• Мартин Фаулер. «UML. Основы» — краткий справочник по основным диаграммам. 3-е издание, Символ-Плюс.
• Крэг Ларман. «Применение UML и шаблонов проектирования» — объектный анализ и диаграмма классов. 3-е издание, Вильямс.

Статьи и справочники

• Visual Paradigm — Class Diagram: https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-class-diagram/
• Visual Paradigm — Object Diagram: https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-object-diagram/
• Visual Paradigm — Package Diagram: https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-package-diagram/
• UML-Diagrams.org — Class Diagrams — нейтральный справочник по нотации: https://uml-diagrams.org/class-diagrams.html

Инструменты

• Практика работы с EA, Lucidchart, draw.io — 07.04 Инструменты моделирования (Sparx EA, Lucidchart, draw.io)