Project Manager Skills: UML

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

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

Возьмем упрощенный сценарий «Заказ в ресторане».

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

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

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

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

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

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

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

Есть разные типы объектов, которые могут между собой взаимодействовать:

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

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

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

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

Ситуация:

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

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

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

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

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

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

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

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

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

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

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

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

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

Бесплатно.

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

Платно: от 312,50 или 937,50 руб в месяц.

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

Бесплатно 15 дней. Далее от $ 99 в год. Если не купить, то данные, нарисованные за 15 дней, не сохранятся.

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

Бесплатно.

Выбираете диаграмму из шаблонов и наполняете ее своими данными. В результате получается код диаграммы. На любителя :)

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

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

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