💥 Пример UML-Sequence для проекта #ShipEasyGA 💥

Для системы #ShipEasyGA, интеграционный сценарий работы со структурированием адреса охватывает взаимодействие между:
◽️ Frontend: iOS / Android / Web,
◽️ Backend ShipEasyGA
◽️ БД
◽️ DaData


Применение UML-Sequence диаграммы для него позволяет наглядно показать:

🔹 Как и когда пользователь инициирует запрос на Frontend

🔹 Последовательность обработки запроса между фронтендом, бэкендом ShipEasyGA, БД и сервисом DaData

🔹 Наличие сложной логики: обработку и очистку результата от DaData от лишней информации, поиск ближайших пунктов курьерской службы.

🔹 Можно показывать как прямые, так и альтернативные сценарии, но я предпочитаю показывать только прямой сценарий, чтобы не перегружать схему и оставлять легкой для понимания.

🖼 Диаграмма UML-Sequence для #ShipEasyGA прикреплена к посту.


❗️ P.S. Стоит обратить внимание, что я описала этот сценарий структурирования адреса отдельно от основного процесса заполнения данных об Отправлении и Получении посылки. И UML Sequence рисую отдельно.

Так сделано, по нескольким причинам:

1. Я делаю эту задачу в готовой системе, когда пользователи вводят данные без структурирования адресов и они проверяются вручную. Это отдельная доработка, новый сценарий.

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

3. UML-диаграмма на эту интеграцию будет отдельная, т.к. в основном процессе оформления заказа курьера и так будет много шагов. Это может привести к нечитаемости и усложнению диаграммы.

✅ Диаграмма - дополнение к тексту сценария, чтобы лучше понять процесс.

✅ Лучше делать её проще, понятнее и читаемее. Убирать с неё лишние детали.

✅ Никто не любит много читать. Мы не должны создать дополнительную сложность в изучении постановки задачи 🙂

#ИнтеграцииGA