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

Что такое диаграмма компонентов

Диаграмма компонентов (component diagram) — это структурная диаграмма UML, которая показывает, из каких крупных программных блоков состоит система и как эти блоки связаны между собой через интерфейсы. Компонент здесь — не класс и не объект, а логически завершённая часть системы: сервис, модуль, библиотека, подсистема.

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

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

Component

Компонент изображают прямоугольником со стереотипом «component» (или значком компонента в правом верхнем углу). Внутри — имя компонента.

┌──────────────────┐
│ «component»      │
│   AuthService    │
└──────────────────┘

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

Interface

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

Предоставляемый интерфейс (provided) рисуют кружком на «палочке» (нотация lollipop). Он означает, что компонент реализует и отдаёт наружу этот контракт.

AuthService ──○ AuthAPI

Читается как «AuthService предоставляет интерфейс AuthAPI»: другие компоненты могут им пользоваться.

Требуемый интерфейс (required) рисуют полукругом (нотация socket). Он означает, что компонент не работает без этого контракта и ожидает, что кто-то его предоставит.

PaymentService ──◐ AuthAPI

Читается как «PaymentService требует интерфейс AuthAPI». Когда lollipop одного компонента вставляется в socket другого, получается сборочный соединитель (assembly connector) — наглядная стыковка «розетки и вилки», которая показывает, что один компонент предоставляет ровно то, что нужно другому.

Port

Порт — это именованная точка взаимодействия на границе компонента. Порт группирует один или несколько интерфейсов и показывает, через какую «дверь» компонент общается с внешним миром.

┌───────────────┐
│ Service       │
│             ◯ port: HTTP
│             ◯ port: gRPC
└───────────────┘

Разные порты одного компонента могут предоставлять разные интерфейсы. На практике это удобно, когда сервис доступен по нескольким протоколам одновременно — например, публичный REST-порт для внешних клиентов и внутренний gRPC-порт для соседних сервисов. Порт делает явным, что у компонента может быть несколько независимых каналов взаимодействия, каждый со своим контрактом.

Dependency

Зависимость показывает, что один компонент опирается на другой: без него не работает или использует его функциональность. Её рисуют пунктирной стрелкой, направленной от зависящего компонента к тому, от которого он зависит.

ClientApp ──→ AuthService

Стрелка направлена от того, кто зависит (depender), к тому, от кого зависят (dependee): здесь ClientApp зависит от AuthService, а не наоборот. На собесе за направлением стрелки следят особенно — перепутанное направление сразу выдаёт, что кандидат рисует «по памяти», не понимая семантики. Зависимости полезны, чтобы увидеть связность архитектуры: чем больше компонентов зависит от одного, тем критичнее он для системы и тем осторожнее нужно его менять.

UML Component vs C4

C4 (Context, Container, Component, Code) — более простая и популярная в 2026 году нотация для описания архитектуры. Её любят за лёгкость: минимум правил, читаемо для нетехнических стейкхолдеров, быстро рисуется. Грубо говоря, уровень «container» в C4 примерно соответствует «component» в UML — это разворачиваемая единица вроде сервиса или базы данных.

UML Component — более формальная и строгая нотация. Её выбирают там, где важна точность и есть требования к документации: enterprise-системы, регулируемые отрасли (банки, госсектор, медицина), интеграционные проекты со сложными контрактами между подсистемами. На собесе полезно уметь объяснить этот выбор: C4 — когда нужно быстро и понятно донести общую картину, UML Component — когда нужно строго зафиксировать интерфейсы и зависимости в проектной документации. Хороший ответ — не «какая нотация лучше», а «какая уместнее под конкретную задачу и аудиторию».

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

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

FAQ

Чем диаграмма компонентов отличается от диаграммы классов?

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

Чем provided-интерфейс отличается от required?

Provided (кружок-lollipop) — контракт, который компонент реализует и отдаёт наружу; им пользуются другие. Required (полукруг-socket) — контракт, который компоненту нужен от кого-то ещё, без него он не работает. Когда lollipop стыкуется с socket, получается сборочный соединитель — компонент предоставляет ровно то, что требует другой.

Зачем нужны порты, если есть интерфейсы?

Порт — это именованная точка взаимодействия на границе компонента, которая группирует интерфейсы. Он полезен, когда у компонента несколько независимых каналов связи: например, публичный REST-порт для внешних клиентов и внутренний gRPC-порт для соседних сервисов. Порт делает явным, через какую «дверь» и по какому контракту идёт общение.

Что выбрать на собесе — UML Component или C4?

Зависит от задачи. C4 проще и понятнее нетехническим стейкхолдерам, быстрее рисуется — хорош для общей картины. UML Component строже и формальнее — уместен в enterprise и регулируемых отраслях, где важно точно зафиксировать интерфейсы и зависимости. Сильный ответ показывает, что вы выбираете нотацию под аудиторию и задачу, а не считаете одну «правильной».

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

Статья основана на спецификации UML 2.5. Конкретные требования и любимые нотации зависят от компании и команды — уточняйте у интервьюера или рекрутера.

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