Что такое диаграмма последовательности?
A Диаграмма последовательности — это поведенческий диаграмма UML который детализирует, как программные операции выполняются во времени. Как основной стандарт спецификации унифицированного языка моделирования (UML), он моделирует точный хронологический порядок обмена сообщениями между объектами, процессами или микросервисами. Отображая жизненные линии вертикально, а последовательные взаимодействия — горизонтально, этот конкретный тип диаграммы UML позволяет программистам и архитекторам систем ясно визуализировать сложные последовательности вызовов API, сетевые обмены данными и границы транзакций базы данных до написания кода для производства.
С помощью VPasCode, вам не нужно тратить часы на выравнивание параллельных стрелок, растягивание линий сообщений или перемещение рамок, чтобы освободить место для нового шага. Наш движок компоновки динамически вычисляет всю сетку временной шкалы по мере ввода вами текстовых декларативных скриптов.
Руководство по основному синтаксису: элементы и конструкции
Чтобы создать действенный, соответствующий стандартам диаграмму последовательности UML в PlantUML, необходимо освоить объявления компонентов, стили стрелок сообщений, жизненные линии и логические структуры управления.
1. Объявление участников UML и форм
По умолчанию компоненты на этой диаграмме UML наследуют стандартную форму квадратной рамки. Однако вы можете изменить визуальный образ своих сущностей, чтобы читатели сразу понимали архитектурный контекст границ вашей системы, используя специфические ключевые слова UML:
актер Клиент
граница "API Gateway" как Шлюз
контроль Контроллер
база данных "PostgreSQL" как БД
2. Стрелки сообщений и синхронизация
Стиль ваших линий стрелок и их головок определяет точный протокол обмена сообщениями в ваших инфраструктурных каналах в соответствии со стандартами диаграмм UML:
- Синхронный запрос (блокирующий): Обозначается сплошной линией и сплошной стрелкой. Отправитель ожидает ответа:
A -> B - Асинхронное сообщение (неблокирующее): Обозначается сплошной линией и тонкой открытой стрелкой. Отправитель передает данные и немедленно продолжает работу:
A ->> B - Ответ / возвращаемое значение: Обозначается пунктирной линией и открытой стрелкой:
B --> A
3. Управление жизненными линиями (активация и деактивация)
Чтобы избежать появления ваших компонентов в виде плоских полос, вы должны явно показывать, когда процесс активно использует потоки CPU или емкость памяти. Используйте маркерыактивировать и деактивировать маркеры, или используйте сокращенную синтаксическую конструкцию в строке (++ / --):
Шлюз -> Контроллер ++ : "processPayment()"
Контроллер --> Шлюз -- : "return receipt"
4. Логические блоки: альтернативы, циклы и параллели
Сложная бизнес-логика (например, ветвление if/else, повторные попытки доступа к базе данных или параллельные потоки выполнения) должна быть обернута в структурированные границы глобальных рамок, известные как комбинированные фрагменты в спецификации диаграмм UML:
- Условная логика (alt / else): Моделирует условные ветвления.
Plantuml Edit Plantuml in VPasCode
alt успешное условие A -> B : "Продолжить запрос" иначе состояние ошибки A -> B : "Выдать код ошибки" конец
- Циклы повторений (loop): Моделирует итерации, повторные попытки или блоки обработки очереди до тех пор, пока условие не будет выполнено.
Plantuml Edit Plantuml in VPasCode
loop пока очередь не пуста Рабочий -> Очередь : "Получить следующую задачу" конец
- Параллельные выполнения (par): Модели разделяют операции, выполняемые одновременно в независимых потоках.
Plantuml Edit Plantuml in VPasCode
par Запустить параллельные процессы A -> LogService : "Записать аналитику трассировки" иначе A -> БД : "Зафиксировать данные профиля клиента" конец
Рекомендации по созданию чистых последовательностей
- Группировать сообщения с помощью разделителей: Используйте двойные знаки равенства (“
== Ваш этап ==) для разделения огромной последовательности аутентификации до оформления заказа на отдельные логические этапы. - Использовать автонумерацию: Разместите директиву
autonumberнепосредственно под@startuml. Это заставляет рабочую среду добавлять номера шагов на каждый элемент, что значительно упрощает проверку кода. - Держите ответы в чистоте: Избегайте написания длинных описательных предложений на стрелках возврата (
-->). Вместо этого просто укажите, какой объект сырых данных или код HTTP возвращается обратно (например,"201 Создан токен").
Примеры диаграмм последовательности PlantUML из реальной жизни
Пример 1: Цикл аутентификации микросервиса (блоки Alt и жизненные линии)
Этот шаблон обрабатывает стандартную последовательность безопасности, при которой клиент проходит аутентификацию через шлюз, демонстрируя явные жизненные линии и альтернативную структуру условных результатов внутри стандартного формата диаграммы UML.
@startuml
autonumber
актер Пользователь
граница "Веб-приложение" как App
контроль "Сервис аутентификации" как Auth
Пользователь -> App ++ : "Отправить учетные данные"
App -> Auth ++ : "POST /v1/auth"
alt #LightGreen Успешный вход
Auth --> App : "200 OK (JWT-токен)"
App --> Пользователь : "Отобразить панель управления"
иначе #LightPink Неверные учетные данные
Auth --> App : "401 Не авторизован"
App --> Пользователь : "Показать всплывающее уведомление об ошибке"
конец
deactivate Auth
deactivate App
@enduml
Разбор синтаксиса: The автонумерация тег автоматически управляет номерами с 1 по 5. The альт и иначе блоки дополняются пользовательскими флагами цвета в шестнадцатеричном формате (например, #LightGreen) для немедленного визуального выделения путей успешного и неуспешного выполнения. The ++ токены обеспечивают, чтобы линии жизни оставались активными во время блока сетевого вызова.
Пример 2: Расширенная обработка заказов (циклы, параллели и разделители)
Этот архитектурный чертеж предприятия моделирует надежную систему оформления заказов, которая распределяет задачи между параллельными исполнителями, выполняет запись в базу данных и полагается на цикл синхронизации с внешней системой.
@startuml
автонумерация
область "API оформления заказов" как API
база данных "БД заказов" как DB
контроль "Очередь рабочих" как Queue
область "Stripe" как Stripe
== Этап 1: Проверка журнала транзакций ==
API -> DB ++ : "Записать ожидающий заказ"
DB --> API -- : "Подтверждённый ID заказа"
== Этап 2: Оплата и асинхронное выполнение ==
API -> Stripe ++ : "Списать счёт клиента"
Stripe --> API -- : "Оплата авторизована"
пар Параллельные фоновые операции
API -> Queue ++ : "Опубликовать событие 'Order_Placed'"
деактивировать Queue
иначе
API -> DB ++ : "Обновить статус на 'Оплачен'"
деактивировать DB
конец
цикл Повторение до 3 раз при сбое сети
API -> API : "Пинг вебхук синхронизации уведомлений"
конец
API --> Клиент : "Вернуть HTTP 200 (Успех)"
@enduml
Разбор синтаксиса: The == разделители делят макет на отдельные операционные этапы. The пар блок чисто отклоняется от пути стрелки сообщения в два отдельных горизонтальных пути, иллюстрируя, что публикация событий и обновление статуса базы данных происходят одновременно без блокировки друг друга. Самопоходящая стрелка (API -> API) идеально отображает цикл внутренней локальной функции экземпляра.