GetAnalyst_ShipEasyGA_Структурирование_адреса_через_DaData_drawio.png
💥 Пример 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
Для системы #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