Комментарии
Диаграмма последовательности для решения интеграционных кейсов
Project Manager Skills: UML
Сибирикс

Project Manager Skills: UML

Диаграмма последовательности для решения интеграционных кейсов
При разработке протоколов интеграции бывает очень и очень много вводных. Например: две 1С, CRM, где и физический и юридические лица, одни с дисконтными картами, другие без е-мейлов… Экспортируй оттуда, импортируй сюда… впору кинуть документы в воздух, подышать и присесть собирать их обратно. Чтобы голова не лопнула и было понятно и клиенту, и вам, и программисту — рисуйте диаграммы последовательности UML.

Что такое диаграмма последовательности UML

UML — это специальный язык для описания разных бизнес-процессов, структур и прочих вещей, для которых необходимо последовательное описание. В запутанных ситуациях с большим количеством сущностей может сильно помочь. UML включает несколько видов диаграмм, рассмотрим диаграмму последовательности.

Возьмем упрощенный сценарий «Заказ в ресторане».
uml диаграмма
Есть главные лица сценария: клиент, официант, повар и кассир. В UML их называют «акторы» — какие-то действующие лица или объекты, с которыми происходят операции.

Далее таймлайн — линия жизни объектов, она расположена вертикально сверху вниз.

Сообщения между акторами бывают нескольких типов. Основные, на которые нужно обратить внимание — это синхронные (сообщение инициирует обработку и отправитель ждет ее завершения) и асинхронные (сообщение инициирует обработку, но отправитель не дожидается ее завершения). В данном случае у нас асинхронные взаимоотношения.

Читаем диаграмму:

  • гость заказывает еду у официанта,
  • официант его слушает и далее идет на кухню, чтобы передать заказ повару,
  • повар начинает готовить,
  • параллельно с этим официант приходит к клиенту и наливает ему винишко,
  • пока клиент пьет винишко, повар приносит еду на стойку официанту,
  • официант забирает заказ и относит его гостю. Больше клиент с официантом дел не имеет (официант выпадает из системы),
  • гость оплачивает свой заказ у кассира и уходит.

В McDonald's или Michelin 5 звезд диаграмма будет другая, поскольку процессы обслуживания там устроены иначе. Все зависит от конкретной ситуации, где применяется диаграмма.

Диаграмма последовательности 2.0

В классической UML второй версии диаграмма стала еще более подробной, разбитой на более мелкие элементы и связи. Подходит для детальной проработки структур и систем.

Есть разные типы объектов, которые могут между собой взаимодействовать:
Актор
Участник процесса.
Менеджер заказа
Это какой-то интерфейс. Причем не обязательно экранный интерфейс, он может быть физическим: картридер в банкомате или форма регистрации на сайте.
Менеджер заказа
Или менеджер паролей, или любой другой программный модуль, к которому идет обращение от программной подсистемы. Например, менеджер паролей отвечает за то, чтобы делать авторизацию/регистрацию.
Заказ
Это объект, который создается, либо с которым происходят какие-то операции. Например, счет или пользователь в базе данных.
Синхронный вызов (связь)
Напомним, что пользователь отправил сообщение в систему, и пока ему она не ответит, он ничего не может делать.
Асинхронный вызов (связь)
А тут пользователь отправил сообщение в систему, и может продолжать с ней взаимодействовать, не дожидаясь ответа.
Запрос данных
Объект сам у себя запрашивает данные.
Пример диаграммы
uml диаграмма
Читаем диаграмму:

Это форма авторизации. Она передает данные в менеджер паролей: логин и пароль. Менеджер паролей проверяет, есть ли такой пользователь в системе. Если нет, то выводит в форме авторизации ошибку. Еще форма авторизации ожидает ответ, пока менеджер пароля проверяет данные, и сообщает форме авторизации, какое сообщение необходимо вывести пользователю.

Как это использовать на практике

Рассмотрим кейс и закрепим материал небольшим видео (если читать было некогда или не хотелось, а тут и посмотреть можно).

Все совпадения случайны, ситуация надуманная и высосанная из пальца.

Ситуация:

Идет интеграция сайта с 1С — разрабатывается протокол интеграции. По ходу обсуждения выясняется:

  • 1С-ки будет две: Тверская и Московская;
  • Основная интеграция — с Тверской;
  • Вся товарная база хранится в Тверской 1С;
  • Помимо товаров, нужна выгрузка контрагентов;
  • Контрагент привязывается при регистрации к Москве или к Твери;
  • Контрагенты хранятся частично в Московской, частично — в Тверской базе;
  • Не у всех текущих контрагентов заполнены поля емейл и телефон;
  • Создание новых контрагентов требует премодерации;
  • Кроме того, заказы необходимо передавать в CRM.

Клиент ожидает, что ему предложат решение, как будет работать схема с CRM, сайтом и 1С-ками.

Решение: составляем диаграммы последовательности. Одна и та же структура будет описана в двух вариантах UML-диаграмм.

Диаграмма 1: Регистрация юридического лица (Москва)

uml диаграмма
Читаем диаграмму:

Юридическое лицо заходит на сайт и заполняет форму регистрации, указывая город Москва. Сайт передает данные на е-мейл модератору для премодерации. Модератор вручную заполняет данные контрагента в московскую 1С, создавая нового пользователя. Сайт получает сообщение, что регистрация завершена и отправляет письмо пользователю.

Диаграмма 2: Регистрация физического лица (Тверь)

uml диаграмма
Читаем диаграмму:

Физическое лицо заходит на сайт и заполняет форму регистрации, указывая город Тверь. Сайт передает данные в тверскую 1С, создавая нового пользователя. Сайт получает сообщение, что регистрация завершена и отправляет письмо пользователю.

Диаграмма 3: Оформление заказа (Тверь)

uml диаграмма
Читаем диаграмму:

Зарегистрированный клиент создает заказ на сайте, выбирая город Тверь. В тверской 1С создается заказ (и менеджер в ручную дублирует заказ в 1С). После создания заказа в 1С у заказа меняется статус, который передается сайту и показывается клиенту.

Диаграмма 4: Оформление заказа (Москва)

uml диаграмма
Читаем диаграмму:

Зарегистрированный клиент создает заказ на сайте, выбирая город Москва. В московской 1С создается заказ (и менеджер в ручную дублирует заказ в 1С). После создания заказа в 1С у заказа меняется статус, который передается сайту и показывается клиенту.

Обзор программ для построения UML-диаграмм

Раньше нужно было интернет до конца досмотреть, чтобы найти хотя бы одну. Сейчас онлайн сервисов для построения UML-диаграмм уйма. Делимся миниобзором на те, которыми пользуемся сами.
Бесплатно.

Интегрирован с Google Drive, G Suite, Dropbox, Confluence, Jira от Atlassian, Trello и другими сервисами. Можно работать как онлайн, так и в настольном приложении для MacOS, Windows и Linux. Схемы в этой статье мы сделали в этой программе.
uml диаграмма
Платно: от 312,50 или 937,50 руб в месяц.

Очень много инструментов, и пользоваться ими сможет и человек без специальных знаний и навыков, т.к. функции и интерфейс будут знакомы из пакета MS Office. Работает как приложение и в браузере, а данные хранит в OneDrive.
Бесплатно 15 дней. Далее от $ 99 в год. Если не купить, то данные, нарисованные за 15 дней, не сохранятся.

Аналог Microsoft Visio. Принцип работы и интерфейсы у обеих программ похожи. Здесь миллиард видов диаграмм, но пользоваться ими интуитивно понятно.
uml диаграмма
Бесплатно.

Выбираете диаграмму из шаблонов и наполняете ее своими данными. В результате получается код диаграммы. На любителя :)
uml диаграмма
Бывают диаграммы с альтернативными сценариями, диагональными линиями (процесс идет и занимает какое-то время, например, обработка заказа занимает 30 секунд) и диаграммы с циклами (сколько раз повторяется сценарий). Но это все формализм и сложности. Чем здесь UML может быть плох, так это тем, что можно нарисовать такие детализации, которые кодом потом никогда не реализовать.

Описывайте только один конкретный кейс и одну конкретную ситуацию (как правило, позитивный и самый длинный сценарий), иначе можете запутаться. Один кейс — одна диаграмма.

Что действительно полезно, так это синхронные и асинхронные вызовы, объекты и сообщения между ними.