Привет Хабр! Меня зовут Татьяна Ошуркова, я системный аналитик, разработчик и автор телеграм-канала IT Talks. В прошлом году у меня вышла статья Не UML-диаграммы на PlantUML. Обзор с примерами, где я рассмотрела различные диаграммы не в нотации UML, которые можно построить с использованием возможностей PlantUML. В этой статье я хочу разобрать построение и других диаграмм, которые использует системный аналитик в своей работе.

8 апреля проведу бесплатный вебинар: «Топ-5 ошибок в моделировании требований системным аналитиком», где подробно разберу, какие ошибки наиболее часто системный аналитик допускает при моделировании требований, а также расскажу, как их избежать. Запись на вебинар доступна по ссылке.

Модель C4

Модель C4 (Context, Containers, Components, Code) используется для визуализации архитектуры системы и помогает на разных уровнях абстракции представить как систему, так и её компоненты. Так как PlantUML не имеет встроенных возможностей для построения диаграмм модели C4, используется внешняя библиотека C4-PlantUML. Это библиотека, размещённая в GitHub, которая предоставляет инструменты для работы с диаграммами C4 в PlantUML. Библиотеки можно подключать с помощью команды !includeurl, указывая ссылку на соответствующий файл из репозитория C4-PlantUML. Построим диаграммы контекста и контейнеров для онлайн-магазина.

Диаграмма контекста

На диаграмме контекста отобразим внешнее взаимодействие системы с пользователями и другими системами.

@startuml
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Context.puml

' Внешние сущности
Person(customer, "Покупатель", "Покупает товары в интернет-магазине")
Person(admin, "Администратор", "Управляет товарами и заказами в системе")
System(system, "Интернет-магазин", "Система для покупки товаров онлайн")
System_Ext(paymentSystem, "Платежная система", "Обрабатывает платежи")
System_Ext(shippingSystem, "Система доставки", "Организует доставку товаров")
System_Ext(externalAuth, "Система авторизации", "Проводит авторизацию пользователей через OAuth2")

' Потоки данных
Rel(customer, system, "Покупает товары")
Rel(admin, system, "Управляет товарами и заказами")
Rel(system, paymentSystem, "Запрос на оплату")
Rel(system, shippingSystem, "Запрос на доставку")
Rel(system, externalAuth, "Запрос на авторизацию через OAuth2")
@enduml

• Person. Используется для отображения пользователей системы. В примере это Покупатель и Администратор.

• System и System_Ext. Используются для отображения основной системы и внешних систем. В примере это Интернет-магазин (основная система), Платежная система, Система доставки и Система авторизации.

• Rel. Указывает на потоки данных между пользователями и системой, а также между системой и внешними системами.

Диаграмма контейнеров

Далее построим диаграмму контейнеров для отображения структуры системы и её компонентов: как веб-приложения, API, мобильного приложения и базы данных.

@startuml
!define C4Container https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml
!includeurl C4Container

' Внешние сущности
Person(customer, "Покупатель", "Покупает товары в интернет-магазине")
Person(admin, "Администратор", "Управляет товарами и заказами")

' Контейнеры системы
System_Boundary(system, "Интернет-магазин") {
    Container(webApp, "Веб-приложение", "React", "Интерфейс для покупок")
    Container(api, "API", "Node.js", "Обрабатывает запросы от клиентов и администраторов")
    Container(mobileApp, "Мобильное приложение", "Flutter", "Мобильный интерфейс для покупок")
    ContainerDb(database, "База данных", "PostgreSQL", "Хранит информацию о товарах, заказах и пользователях")
    Container(paymentService, "Сервис оплаты", "Node.js", "Обрабатывает оплату через внешние платежные системы")
    Container(authService, "Сервис авторизации", "OAuth2", "Обрабатывает авторизацию и регистрацию пользователей")
}

' Потоки данных
Rel(customer, webApp, "Использует для покупок")
Rel(admin, api, "Управляет товарами и заказами")
Rel(webApp, api, "Обрабатывает запросы")
Rel(mobileApp, api, "Обрабатывает запросы")
Rel(api, database, "Запросы к базе данных")
Rel(api, paymentService, "Запросы на оплату")
Rel(api, authService, "Запросы на авторизацию")
@enduml

• System_Boundary. Определяет область системы. В данном примере система — это Интернет-магазин.

• Container. Определяет контейнеры системы, такие как веб-приложение (React), мобильное приложение (Flutter), API, база данных (PostgreSQL), сервисы оплаты и авторизации.

• Rel. Показывает, как контейнеры взаимодействуют между собой (например, как веб-приложение или мобильное приложение взаимодействует с API, а API — с базой данных или сервисами).

Диаграмма потоков данных (DFD)

Диаграмма потоков данных (DFD, Data Flow Diagram) является представлением потока данных в системе. Она показывает, откуда поступают данные, как они обрабатываются, куда передаются и где хранятся.

В PlantUML нет встроенного синтаксиса для DFD, поэтому такие диаграммы можно создать с использованием, например, элементов диаграммы компонентов или состояний. Рассмотрим построение DFD с использованием элементов диаграммы компонентов, поскольку она наиболее близка к классическому DFD.

Построим DFD для системы обработки заказов для онлайн-покупок, начиная с контекстного уровня и переходя к логическому для более детальной проработки. Необходимо смоделировать, как данные перемещаются в системе и как взаимодействуют все её компоненты.

Уровень контекста

На контекстном уровне мы отображаем систему как единое целое и показываем основные взаимодействия с внешними сущностями. Это помогает понять общую картину и определить границы системы.

@startuml

actor "Пользователь" as Customer
rectangle "Система обработки заказов" as OPS #lightblue
database "База данных заказов" as OrdersDB
rectangle "Платежная система" as Payment #lightyellow

Customer --> OPS : Отправляет заказ
OPS --> OrdersDB : Сохраняет заказ
OPS --> Payment : Отправляет запрос на оплату
Payment --> OPS : Подтверждает оплату
OPS --> Customer : Отправляет подтверждение
@enduml

Уровень логики

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

@startuml
' Внешние сущности
actor "Пользователь" as Customer
database "База данных заказов" as OrdersDB
rectangle "Платежная система" as Payment #lightyellow

' Основной процесс (разбивается на подпроцессы)
rectangle "Система обработки заказов" as OPS #lightblue
rectangle "Валидация заказа" as Validation #lightgreen
rectangle "Проверка наличия товара" as Inventory #orange
rectangle "Обработка платежа" as PaymentProc #pink
rectangle "Подтверждение заказа" as Confirmation #lightblue

' Потоки данных
Customer --> OPS : Отправляет заказ
OPS --> Validation : Проводит валидацию заказа
Validation --> Inventory : Проверяет наличие товара
Validation --> PaymentProc : Отправляет запрос на оплату
PaymentProc --> Payment : Обрабатывает платеж
Payment --> PaymentProc : Подтверждение платежа
Inventory --> OrdersDB : Обновляет складские запасы
PaymentProc --> OrdersDB : Обновляет статус платежа
OrdersDB --> Confirmation : Извлекает данные заказа
Confirmation --> Customer : Отправляет подтверждение заказа
@enduml

Диаграмма Ганта

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

@startgantt

[Анализ требований] lasts 10 days
[Проектирование системы] lasts 10 days
[Разработка] lasts 15 days
[Тестирование] lasts 7 days
[Внедрение] lasts 7 days

[Анализ требований] -> [Проектирование системы]
[Проектирование системы] -> [Разработка]
[Разработка] -> [Тестирование]
[Тестирование] -> [Внедрение]

Project starts 2025-04-01
[Анализ требований] starts 2025-04-01
[Проектирование системы] starts 2025-04-11
[Разработка] starts 2025-04-21
[Тестирование] starts 2025-05-06
[Внедрение] starts 2025-05-13

@endgantt

Подведем итоги

Мы рассмотрели несколько важных типов диаграмм, которые можно создавать в PlantUML, даже если они не относятся к классическим UML-нотациям:

1. Диаграмма потоков данных (DFD). Используется для моделирования потоков информации в системе. Поскольку в PlantUML нет встроенной поддержки DFD, мы построили ее, используя элементы других диаграмм.

2. Модель C4. Применяются для визуализации архитектуры программных систем. Мы подробно разобрали уровни контекста и контейнеров, рассмотрев использование библиотеки C4-PlantUML.

3. Диаграмма Ганта. Полезный инструмент для управления проектами и планирования сроков выполнения задач. В PlantUML есть встроенные инструменты для построения, а также к диаграмме можно применять дополнительное редактирование внешнего вида, что не было рассмотрено в статье.

На PlantUML можно построить даже Судоку :) Пишите в комментариях, если пробовали его решить.