UML: sequence-диаграммы
Главный инструмент системного аналитика на интеграционных проектах. Просят нарисовать обмен между системами - оплату, обмен с внешним реестром, синхронизацию каталога - и почти всегда добивают вопросом про ошибки и таймауты, потому что счастливый путь умеет рисовать любой.
Устроена она просто: участники стоят в ряд по горизонтали, время идёт сверху вниз, сообщения летают горизонтальными стрелками. Синхронность видна по виду стрелки, ветвления описывают прямоугольниками-фрагментами с пометками alt, opt и loop.
// Формулировки: «нарисуй оплату заказа», «как покажешь таймаут?», «что не видно на этой диаграмме?»
Оси, линии жизни, активации
По вертикали идёт время, но только порядок событий, без всякого масштаба. Расстояние между двумя стрелками ничего не говорит о секундах: сообщение, нарисованное на сантиметр ниже, может прийти через миллисекунду, а может через час. Это первая и самая частая ловушка чтения таких схем.
Линия жизни - пунктирная вертикаль под участником, показывающая, что он существует в этом сценарии. Утолщённый прямоугольник поверх неё - активация: отрезок, когда участник реально занят обработкой, а не просто присутствует. Вложенные активации показывают, что вызов пришёл, пока предыдущий ещё не закончился.
Вид стрелки несёт смысл. Синхронный вызов - сплошная линия с закрашенным треугольным наконечником: отправитель встал и ждёт. Возврат - пунктирная стрелка обратно. Асинхронное сообщение рисуют открытым наконечником, похожим на галочку: отправитель отдал сообщение и пошёл дальше, ответа не ждёт.
// Отсюда типичная ошибка: помечать асинхронным всё, что уходит наружу. Обычный вызов внешнего сервиса, после которого мы стоим и ждём ответа, - синхронный, и рисовать его надо соответственно, иначе разработка построит совсем другую механику.
- активация
- отрезок на линии жизни, когда участник занят обработкой. Отвечает на вопрос «он сейчас работает?», а не «он вообще есть?»
Чего на схеме не видно
Раз масштаба по вертикали нет, таймаут приходится подписывать явно - временной меткой, ограничением на фрагменте или просто подписью у стрелки. Без этого «ждём ответ» превращается в реализации в бесконечное ожидание, и первый же зависший внешний сервис утащит за собой твою систему.
Интеграционная схема без обратных стрелок описывает мир, в котором ничего не ломается. Разработке нужна вторая половина: какие коды ответа возможны, что делает вызывающая сторона при отказе, повторяет ли запрос и с какой паузой, сколько раз.
И отдельный пункт, который забывают чаще всего, - что делать после таймаута. Мы не получили ответ, но это не значит, что операция не выполнилась: платёж мог пройти, а ответ потеряться по дороге. Поэтому в контракте нужен метод проверки статуса по нашему собственному ключу операции, иначе любое решение после таймаута будет гаданием.
// Именно эти ветки потом становятся половиной тест-кейсов. Их отсутствие на схеме означает ровно одно: поведение при сбое доопределит разработчик, и узнаешь ты об этом в первый плохой день.
Уровень абстракции
Двенадцать участников и полсотни сообщений на одном листе почти всегда означают смешение уровней. Рядом с «отправить заявку в реестр» живут «прочитать из кэша» и «записать в лог» - шаги, между которыми пропасть по значимости.
Лечится расслоением. Верхнеуровневый обмен между системами - отдельная схема, на ней четыре-пять участников и десяток сообщений. Внутренняя механика каждой стороны - своя отдельная схема, если она вообще нужна.
// Проверка простая: покажи схему тому, кто не участвовал в её создании, и попроси пересказать. Если он не может проследить основной сценарий за минуту, схему надо разрезать. Одна диаграмма на всё не читается никем, включая автора через месяц.
Как отвечать: «Нарисовал обмен с платёжным шлюзом. Что добавишь обязательно?»
Обратные стрелки и ветку отказа. Успешный путь - это половина схемы, а разработке нужна вторая: какие коды ответа возможны, что делает наша сторона при отказе и что при таймауте. Явно подпишу таймаут, потому что по вертикали масштаба нет и из расстояния между стрелками не следует ничего. Дальше опишу политику повторов - сколько попыток и с какой паузой. И обязательно метод проверки статуса операции по нашему ключу: после таймаута мы не знаем, прошёл платёж или нет, ответ мог потеряться уже на обратном пути, и без такого метода любое решение будет гаданием, а цена ошибки - двойное списание.
Кандидат закрывает три типовые дыры интеграционной схемы разом и показывает, что думает про плохой день. Последний пункт про проверку статуса называют единицы, и он сразу выдаёт человека с боевым опытом.
На чём валятся
- −− Рисуют только счастливый путь, без ответов и веток отказа.
- −− Считают, что расстояние между сообщениями отражает длительность.
- −− Помечают асинхронным всё, что уходит наружу, хотя вызов с ожиданием ответа синхронный.
- −− Смешивают бизнес-шаги и техническую механику в одной схеме.
- −− Забывают подписать таймаут и оставляют ожидание неограниченным.
Проверьте себя
Пять вопросов из банка по этой подтеме. Всего их 12, остальные разбираются в тренажёре.
- Как на sequence выглядит синхронный вызов?A)Сплошная стрелка, закрашенный конецB)Пунктирная стрелка с открытым наконечникомC)Двойная линия между участникамиD)Стрелка с ромбом на конце
показать ответ и разбор
+A)Сплошная стрелка, закрашенный конец// разбор: Синхронный вызов рисуют сплошной линией с треугольным закрашенным наконечником: вызывающий ждёт ответа. Возврат показывают пунктирной стрелкой. Асинхронное сообщение отличается открытым наконечником — вызывающий продолжает работу, не дожидаясь ответа.
- Когда на схеме уместно асинхронное сообщение?A)Когда участников больше трёхB)Когда вызов идёт по HTTPC)Когда отправитель не ждёт ответаD)Когда сообщение уходит во внешнюю систему
показать ответ и разбор
+C)Когда отправитель не ждёт ответа// разбор: Асинхронность на диаграмме — не про технологию, а про ожидание: отправитель отдал сообщение и пошёл дальше. Событие в очередь, уведомление, запуск фоновой задачи. Ошибка изображать асинхронным всё, что уходит наружу: обычный REST-вызов с ожиданием ответа остаётся синхронным.
- Для чего на sequence используют фрагмент alt?A)Пометить необязательный участокB)Показать повторение шаговC)Выделить критическую секциюD)Взаимоисключающие ветки по условию
показать ответ и разбор
+D)Взаимоисключающие ветки по условию// разбор: alt — это ветвление: несколько секций с условиями, из которых выполняется одна. Для одиночной необязательной ветки есть opt, для повторения — loop. Аналитику фрагменты нужны, чтобы не плодить отдельную диаграмму на каждый исход сценария.
- Что обязательно показать на sequence, описывающей интеграцию двух систем?A)Ответы и поведение при ошибкеB)Версии протоколов у каждой стороныC)Размер сообщений в байтахD)Схему базы принимающей системы
показать ответ и разбор
+A)Ответы и поведение при ошибке// разбор: Интеграционная схема без обратных стрелок описывает мир, где ничего не ломается. Разработке нужны ответы, коды ошибок и ветка отказа: что делает вызывающая сторона при таймауте, повторяет ли запрос и с какой паузой. Именно эти ветки потом становятся половиной тест-кейсов.
- Почему таймаут приходится подписывать на sequence отдельно?A)Нотация запрещает временные ограниченияB)Вертикаль показывает порядок, а не длительностьC)Таймаут относится к НФТ и на схемах не отражаетсяD)Таймаут виден по длине стрелки
показать ответ и разбор
+B)Вертикаль показывает порядок, а не длительность// разбор: Ось времени на sequence не масштабируется: расстояние между сообщениями ничего не говорит о секундах. Поэтому ограничение фиксируют явно — временной меткой, ограничением на фрагменте или подписью у стрелки. Без этого «ждём ответ» превращается в бесконечное ожидание в реализации.
дальше
Теорию прочитали. Навык ставится повторением
В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.