UML Deployment диаграмма на собеседовании системного аналитика

Зачем спрашивают на собесе SA

Deployment diagram (диаграмма развёртывания) показывает физическую сторону системы: где именно выполняется софт, на каком железе и в каких средах, и как эти узлы связаны между собой. Это одна из структурных диаграмм UML, и системного аналитика по ней проверяют регулярно, потому что от размещения зависят нефункциональные требования — доступность, задержки, отказоустойчивость, а ещё требования регуляторов к тому, где физически лежат данные.

Типовые вопросы на собесе: «нарисуй deployment вашей системы», «чем deployment-диаграмма отличается от component-диаграммы», «где на этой схеме проходит граница отказоустойчивости». Главное, что проверяют, — понимаете ли вы разницу между логической структурой (какие есть компоненты) и физическим размещением (на чём и где они реально крутятся). Component-диаграмма отвечает на вопрос «из каких частей состоит софт», deployment — «где и на каком железе он исполняется и как части общаются по сети».

Элементы deployment-диаграммы

Базовых элементов три, и их стоит уметь назвать чётко.

• Узел (node) — вычислительный ресурс, на котором что-то исполняется: физический сервер, виртуальная машина, облачный инстанс, контейнер, среда выполнения.
• Артефакт (artifact) — физическая единица, которую разворачивают: файл, исполняемый модуль, библиотека, образ. Например, jar, war, Docker-образ, конфиг.
• Путь коммуникации (communication path) — канал связи между узлами: сеть, протокол, шина. Показывает, как узлы обмениваются данными.

[Сервер приложений (node)]
  - артефакт: webapp.jar
[Сервер БД (node)]
  - артефакт: postgres

Сервер приложений ──HTTPS── Сервер БД

Узлы (nodes)

Узел — это исполняющая среда. В UML различают два вида узлов через стереотипы:

• «device» — физическое устройство: сервер, роутер, телефон, любое железо.
• «executionEnvironment» — программная среда исполнения: операционная система, JVM, сервер приложений, контейнер Docker, СУБД.

Узлы можно вкладывать друг в друга — это отражает реальную вложенность инфраструктуры: на физическом сервере крутится JVM, внутри неё развёрнут артефакт приложения.

Сервер (device)
  └── JVM (executionEnvironment)
        └── webapp.jar (artifact)

Такая вложенность полезна на собесе: она показывает, что вы понимаете, чем железо отличается от рантайма, и не путаете «сервер» с «процессом на сервере».

Артефакты (artifacts)

Артефакт — конкретная развёртываемая единица, физическое проявление компонента. Если компонент на component-диаграмме — это логический блок, то артефакт — то, что реально кладут на узел: собранный jar, конфиг, дамп данных, образ.

«artifact» webapp.jar        -- собранное приложение
«artifact» config.yml        -- конфигурация окружения
«artifact» postgres-data     -- данные/том БД

Стереотипы у артефактов ставят по необходимости — например, «executable», «file», «script», — чтобы уточнить характер единицы. Связь «артефакт развёрнут на узле» показывают либо вложением артефакта в узел, либо зависимостью со стереотипом «deploy».

Связи (relationships)

На deployment-диаграмме два основных типа связей.

• Развёртывание (deployment). Узел размещает артефакт. Обычно рисуют артефакт внутри узла или сплошной связью/зависимостью со стереотипом «deploy».
• Коммуникация (communication path). Канал между узлами: сеть или протокол. Часто уточняют стереотипом протокола — «HTTPS», «TCP», «JDBC», «AMQP».

Сервер ──«HTTPS»── Браузер
Сервер ──«JDBC»── База данных
Сервер ──«AMQP»── RabbitMQ

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

Деплой в облако и Kubernetes

В современных схемах узлами становятся облачные ресурсы и кластеры, а вложенность отражает регионы, сети и сервисы.

[AWS Region us-east-1]
  ├── [VPC]
  │     ├── [ECS-кластер]
  │     │     ├── api-service (3 инстанса)
  │     │     └── worker-service (2 инстанса)
  │     └── [RDS Postgres]
  └── [S3 bucket]

[Cloudflare CDN] ──→ [ALB] ──→ [ECS]

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

Частые ошибки

• Путать deployment с component-диаграммой. Component показывает логическую структуру софта, deployment — физическое размещение артефактов на узлах. Смешивать их — типичный провал.
• Рисовать узлы без стереотипов. Не различать «device» (железо) и «executionEnvironment» (рантайм) — значит показать, что вы не отделяете сервер от процесса на нём.
• Не указывать протоколы связи. Линия между узлами без «HTTPS»/«JDBC»/«AMQP» бесполезна для интеграций: именно протокол определяет безопасность, задержки и совместимость.
• Забывать про нефункциональные требования. Число инстансов, регионы, репликация БД, путь через CDN и балансировщик — это ответы на вопросы про доступность и масштаб, а не декор. Схема без них выглядит наивно.

Связанные темы

• UML Use Case на собесе SA
• UML Sequence на собесе SA
• UML Class на собесе SA
• C4 model для SA
• Подготовка к собесу системного аналитика

FAQ

Чем deployment-диаграмма отличается от component-диаграммы?

Component-диаграмма описывает логическую структуру софта: из каких компонентов он состоит и через какие интерфейсы они связаны. Deployment-диаграмма описывает физическое размещение: на каких узлах (серверах, VM, контейнерах) развёрнуты артефакты и как узлы общаются по сети. Артефакт на deployment-диаграмме — это физическое проявление компонента.

Чем узел «device» отличается от «executionEnvironment»?

«device» — это физическое (или виртуальное) железо: сервер, роутер, устройство. «executionEnvironment» — программная среда исполнения внутри него: ОС, JVM, сервер приложений, контейнер, СУБД. Их обычно вкладывают друг в друга: артефакт живёт в рантайме, рантайм — на устройстве.

Когда deployment-диаграмма особенно важна?

Когда размещение влияет на требования: кросс-кластерные интеграции, мультирегион, отказоустойчивость и репликация, а также требования регуляторов к тому, в какой стране физически хранятся данные. В этих случаях без deployment-схемы не согласовать архитектуру.

Нужно ли указывать протоколы на связях между узлами?

Да. Стереотип протокола («HTTPS», «JDBC», «AMQP» и т. п.) — это существенная для системного аналитика деталь: от протокола зависят безопасность, задержки, надёжность и совместимость интегрируемых сторон. Связь без протокола почти бесполезна.

Это официальная информация?

Нет. Статья основана на спецификации UML 2.5 и практике оформления диаграмм развёртывания. Конкретные соглашения по нотации в компаниях отличаются.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.