C4, UML и согласованность модели

TL;DR

C4 и UML не конкурируют. C4 даёт компактную архитектурную карту для выбранной аудитории, а UML формально описывает отдельные аспекты системы. Один и тот же элемент можно проследить между моделями, но не следует ожидать взаимно однозначного соответствия обозначений.

Разные задачи

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

Уровень C4	Вопрос	Подходящие UML-представления
Контекст системы	кто достигает цели и с чем система взаимодействует?	диаграмма вариантов использования
Контейнеры	из каких приложений и хранилищ состоит система?	диаграмма компонентов, пакетов, развёртывания
Компоненты	как распределена ответственность внутри приложения?	диаграмма компонентов, внутренней структуры, техническая диаграмма классов
Код	какими классами и интерфейсами реализована часть?	техническая диаграмма классов
Динамика	как части взаимодействуют в выбранном сценарии?	диаграмма последовательности, диаграмма коммуникации
Развёртывание	где работают экземпляры системы?	диаграмма развёртывания

Ни название, ни прямоугольник не устанавливают соответствие. Контейнер C4 может быть реализован несколькими UML-компонентами, пакетами и классами; UML-компонент, напротив, может не быть достаточно крупным для архитектурной карты.

Согласованность сквозного примера

Для сервиса записи на консультации одна линия трассировки выглядит так:

Требование: студент не может записаться на занятый интервал
→ вариант использования: записаться на консультацию
→ сценарий: выбор интервала, проверка, подтверждение или отказ
→ динамика C4: взаимодействие веб-приложения, службы записи и хранилища
→ техническая модель: проверка доступности в службе записи
→ развёртывание: серверное приложение и база данных в рабочей среде

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

Что проверять

Проверку полезно выполнять при изменении модели, а не только в конце проекта.

Проверка	Вопрос
Граница	все ли люди и внешние системы остаются снаружи проектируемой системы?
Ответственность	у каждого контейнера и компонента есть одна понятная роль?
Поведение	можно ли сопоставить важные взаимодействия со сценарием или вариантом использования?
Данные	не противоречит ли использование хранилища архитектуре данных и правилам предметной области?
Размещение	соответствует ли каждый экземпляр существующему контейнеру?
Решения	есть ли для существенной технологии, границы или компромисса ADR?
Имена	одинаково ли названы ключевые элементы во всех материалах?

Подробнее о причинах расхождений и порядке проверки — в согласованности и трассируемости модели.

Минимальный комплект для учебного проекта

Не нужно создавать все возможные диаграммы. Обычно достаточно:

1. Контекста системы с людьми, проектируемой системой и внешними зависимостями.
2. Контейнеров с приложениями, хранилищами и важными протоколами.
3. Одной диаграммы компонентов только для действительно сложного контейнера.
4. Динамики для сложного или рискованного сценария.
5. Диаграммы развёртывания, когда физическое окружение существенно.
6. Ссылок на требования, сценарии, UML-модели и ADR, которые обосновывают выбор.

Итоговая проверка блока C4

Перед публикацией проверьте:

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

Вернуться к обзору C4.