UML онлайн: последовательности, классы и состояния на одном примере
UML — язык моделирования, который позволяет показать систему с разных сторон: как участники обмениваются сообщениями, какие объекты существуют и как меняется их состояние. Начинайте не с выбора редактора UML онлайн, а с вопроса команды. «Кто вызывает оплату?» и «Какие поля хранит заказ?» требуют разных диаграмм.
Одна задача — несколько взглядов
Разберём оформление заказа. Покупатель отправляет запрос, API сохраняет черновик и возвращает номер. Оплата происходит отдельным шагом. На этом небольшом сценарии можно согласовать взаимодействие, структуру и жизненный цикл, не смешивая всё в одной картинке.
Sequence отвечает на вопрос «кто, кому и в каком порядке отправляет сообщение». Диаграмма классов UML — «какие сущности и связи есть в модели». State — «в какие состояния может перейти заказ». ER-схема полезна рядом, но не является UML-диаграммой: она показывает модель данных.
Диаграмма последовательности UML: кто кому отвечает
В sequence diagram участники располагаются по горизонтали, время читается сверху вниз. Сплошная стрелка обозначает сообщение, пунктирная — ответ в используемом примере. Названия стрелок описывают действие, а не техническую подробность, которая пока неизвестна.
В нашем примере API сначала сохраняет черновик, получает номер и только затем отвечает покупателю. Это важнее аккуратности прямоугольников: если поменять порядок, команда может решить, что успешный ответ отправляется до сохранения.
Открыть sequence-пример на доске.
Как добавить исключение, не перегружая sequence
Сначала согласуйте основной путь. Затем спросите: что увидит покупатель, если сохранение не удалось? Повторится ли запрос и может ли он создать второй заказ? Это отдельные ветви или отдельная диаграмма, а не мелкая сноска после успешного ответа.
Не рисуйте повторный запрос как гарантированно безопасный. Если идемпотентность ещё не предусмотрена, отметьте это вопросом к архитектуре. Диаграмма должна выявлять неизвестное, а не превращать предположение в обещание.
Диаграмма классов UML: из чего состоит заказ
В структурной модели Order связан с одной или несколькими OrderLine. Строка хранит количество и цену; заказ — идентификатор и статус. Кратность 1..* говорит, что в этом примере пустой заказ недопустим. Если продукт допускает пустую корзину, это другой объект или другая граница модели.
Композиция в примере означает принадлежность строк конкретному заказу. Не копируйте такой знак автоматически в любую связь: сначала выясните жизненный цикл объектов. Диаграмма классов — не обязательное точное отображение таблиц базы данных.
ER и схема таблиц базы данных: другой уровень
При переходе к хранению данных добавьте первичные и внешние ключи, обязательность полей и кардинальность отношений. Например, order_line.order_id связывает строку с заказом. Решите, где фиксируется цена на момент покупки: ссылка на текущую цену товара не всегда сохраняет историю.
ER-диаграмма не заменяет миграцию базы, индексы и проверку ограничений. Схема данных должна отражать реальные инварианты, а не только удобно нарисованные отношения. Не называйте ER одним из типов UML — её можно использовать рядом с UML как отдельную нотацию.
Для детального примера есть доска со схемой клиента и заказов.
Диаграмма состояний UML: допустимые переходы
В примере заказ начинается в Draft, после подтверждения оплаты становится Paid, после отправки — Shipped. До оплаты его можно отменить и перейти в Cancelled. Название перехода описывает событие, а не само состояние.
Проверяйте запрещённые переходы: можно ли отправить неоплаченный заказ? Что происходит при отмене уже оплаченного? На нашей небольшой схеме возврат средств не описан — его нужно проработать отдельно, а не считать невозможным только потому, что линии нет.
Как создать диаграмму в Эсборд
Подключите выбранный ИИ-ассистент через MCP-сервер Эсборд, передайте ссылку на доску и попросите конкретный тип диаграммы. Например: «Создай sequence для покупателя, API и базы. Сначала сохраняем черновик, затем возвращаем номер. Оплату вынеси за границы».
В этом сценарии ассистент пользователя формирует Mermaid-подобное описание, а движок выполняет раскладку. В Эсборд поддерживаются sequence, class, state, ER и Gantt; Gantt и ER не относятся к UML. Use case и activity здесь не обещаем как поддерживаемые типы.
Собственной языковой модели в продукте нет. Доступность ассистента, его подписку и сетевые разрешения проверяйте отдельно. После генерации сверьте каждую стрелку и условие с владельцем процесса: синтаксически правильная диаграмма может описывать неверную систему.
Когда UML избыточен
Если нужно лишь показать проверку заявки и два исхода, достаточно блок-схемы из фигур. UML полезен, когда выбранная нотация снимает конкретную неоднозначность: порядок сообщений, кратность отношения или допустимый переход.
Хорошая инженерная диаграмма заканчивается решением или списком открытых вопросов. Укажите границы, дату и ответственного за актуализацию. Не пытайтесь собрать всю архитектуру в одном полотне: связанные небольшие примеры проще проверять и поддерживать.
