Мы продолжаем серию публикаций об артефактах, которые клиенты получают на самой первом этапе разработки — дискавери фазы. Мы уже объяснили, что такое MindMap, Пользовательские истории, BPMN-диаграмма, Customer Journey Map и как мы используем эти инструменты в разработке.
Сегодня говорим о Request response diagram — этот артефакт необязательный, мы его используем, если в проекте предусмотрены интеграции (например, с Google-переводчиком, сервисом доставки и логистики, онлайн-оплатой и т. д.).
Что такое и как выглядит Request response diagram
Request response diagram или диаграмма последовательности — разновидность диаграмм взаимодействия. Обычно она содержит объекты, которые взаимодействуют в рамках сценария, сообщения, которыми они обмениваются, и возвращаемые результаты, связанные с сообщениями.
Диаграммы последовательностей используются для более детального описания логики сценариев использования.
Request response diagram отражает:
- обмен сообщениями между объектами (в том числе в рамках обмена сообщениями со сторонними Системами);
- ограничения, накладываемые на взаимодействие объектов;
- события, инициирующие взаимодействия объектов.
В отличие от BPMN-диаграммы, которая показывает алгоритм работы системы, Request response diagram обращают внимание разработчиков на сообщениях, которыми объекты обмениваются друг с другом.
Сейчас все станет понятно
Разберем на простом примере, как работает Request response diagram, чтобы наглядно представить, как работает этот артефакт.
Это диаграмма отображает обслуживание в ресторане:
Фред (клиент) заказывает еду Бобу (официанту), Боб передает заказ Хэнку (повару). Пока повар готовит еду, официант наливает вино клиенту. Хэнк отдает заказ Бобу, Боб сервирует блюда. Фред ест и потом рассчитывается за ужин через кассира Ренне.
Если развернуть этот пример в таблицу «шаг за шагом», станет видно, как читается диаграмма последовательности — сверху вниз, по времени:
| Шаг | Кто → кому | Сообщение (запрос) | Ответ |
|---|---|---|---|
| 1 | Фред → Боб | заказ еды | заказ принят |
| 2 | Боб → Хэнк | передаёт заказ на кухню | заказ принят в работу |
| 3 | Боб → Фред | наливает вино (пока готовится блюдо) | — |
| 4 | Хэнк → Боб | готовое блюдо | блюдо передано |
| 5 | Боб → Фред | сервирует блюда | — |
| 6 | Фред → Ренне | оплата ужина | чек / подтверждение оплаты |
Обратите внимание на шаг 3: официант наливает вино, не дожидаясь, пока повар закончит блюдо. Это асинхронное сообщение — оно не блокирует остальной сценарий. Именно такие детали (что можно делать параллельно, а что — только по очереди) и помогает увидеть диаграмма.
Это простая схема, в веб и мобильной разработке на таких диаграммах отображаются более сложные процессы и интеграции. Но такой инструмент дает понимание логики процесса, так как мы видим как должны работать объекты на протяжении всего временного цикла.
Request response diagram — довольно сложная нотация, которая имеет свой язык. Чтобы правильно прочитать ее, необходимо знать значение каждого символа. Останавливаться на расшифровке мы сейчас не будем, так как клиентам студии обычно не приходится разбираться с диаграммой, этот артефакт скорее оптимизирует работу в команде разработчиков.
Чтобы диаграмму было проще читать, вот значение основных элементов нотации:
| Элемент | Как выглядит | Что обозначает |
|---|---|---|
| Объект (участник) | прямоугольник вверху | Сторона взаимодействия: приложение, backend, внешний сервис, база данных |
| Линия жизни | вертикальная пунктирная линия | Время существования объекта в сценарии; читается сверху вниз |
| Синхронное сообщение | сплошная стрелка с закрашенным наконечником | Запрос, который ждёт ответа (например, вызов API) |
| Ответ (return) | пунктирная стрелка обратно | Результат на запрос: данные или статус |
| Асинхронное сообщение | стрелка с открытым наконечником | Сообщение, которое не блокирует сценарий и не ждёт ответа |
| Фрагмент alt / loop | рамка с условием в углу | Ветвление (alt) или повтор действий (loop) |
| Активация | узкий прямоугольник на линии жизни | Период, когда объект обрабатывает запрос |
Как это выглядит в веб- и мобильной разработке
В реальных проектах объектами диаграммы обычно выступают клиент (мобильное или веб-приложение), собственный backend-API и внешние сервисы. Тогда «запрос» — это HTTP-вызов (чаще всего GET или POST), а «ответ» — HTTP-ответ с кодом статуса: 200 (успех), 404 (не найдено), 500 (ошибка сервера).
Именно поэтому диаграмму называют request–response: она наглядно показывает пары «запрос → ответ» между приложением и API, порядок вызовов, а также где обращения идут по очереди, а где — параллельно. Для интеграций с оплатой, доставкой или авторизацией это критично: ошибка в порядке запросов или неучтённый ответ об ошибке всплывёт уже в проде.
Услуги мобильной разработки
Как и для чего мы используем Request response diagram в разработке
Request response diagram чаще всего применяются на этапе дискавери фазы, когда у сервиса есть интеграция.
Есть интеграция — есть необходимость прописать логику с этой интеграцией.
Эта логика заключается не только в том, чтобы показать запросы и ответы самой системы, но и в экономии средств клиента, в случае если интеграция платная.
Бизнес или системные аналитики в компании с проджект-менеджером разрабатывают бизнес-модель, которая позволит сделать продуктивную и экономичную интеграцию.
На примере интеграции с google-переводчиком (на схеме ниже) видно, что эта диаграмма показывает, как сохранить все переведенные ранее тексты в систему, чтобы пользоваться ими в будущем. Тем самым не придется каждый раз обращаться к платному переводчику и тратить деньги клиента.
После дискавери фазы, имея на руках проработанную интеграцию, разработчик понимает, каким образом она должна работать. В этом случае он может дать оценку по времени и соответственно стоимости разработки.
Приступая к работе, разработчик тратит гораздо меньше времени, чтобы реализовать интеграцию. Клиент получает результат интеграции с системой
в более короткий срок.
Поэтому мы всегда рекомендуем делать диаграмму на этапе дискавери (но только тогда, когда это действительно нужно проекту). Однако решение всегда остается за заказчиком.
Частые вопросы о Request response diagram
Что такое запрос и ответ на диаграмме?
Запрос (request) — сообщение-вызов от одного объекта к другому, например обращение приложения к backend-API. Ответ (response) — возвращаемый результат. В веб- и мобильной разработке запрос обычно соответствует HTTP-вызову (GET, POST), а ответ — HTTP-ответу со статусом (200, 404, 500).
Чем Request response diagram отличается от BPMN?
BPMN показывает алгоритм и шаги бизнес-процесса, а диаграмма последовательности — сообщения, которыми объекты обмениваются во времени, и их порядок. BPMN отвечает «что происходит», request response diagram — «кто кому и в каком порядке шлёт запросы и ответы».
Обязательно ли делать этот артефакт?
Нет. Мы делаем диаграмму, когда в проекте есть интеграции — с оплатой, доставкой, переводчиком, внешним API. Если интеграций нет, она обычно не нужна.
На каком этапе создаётся диаграмма?
Чаще всего на дискавери-фазе, до старта разработки. Её готовят бизнес- или системные аналитики вместе с проджект-менеджером, чтобы заранее описать логику интеграций.
Чем она полезна заказчику?
Проработанная диаграмма даёт точную оценку сроков и стоимости, ускоряет реализацию и помогает экономить — например, кэшировать ответы платного сервиса, чтобы не обращаться к нему повторно.
Обсудим ваш проект?
Соберём команду под вашу задачу и оценим проект за 2 дня — бесплатно.
