UML без догадок: Как проектировать системы и объяснять их с помощью диаграмм

Поэтому при описании сценария важно держаться цели пользователя, а не пересказывать устройство программы. Актор показывает, кто взаимодействует с системой; граница отделяет её ответственность от внешней; вариант использования формулирует, какого результата добивается внешняя роль. Вместе они помогают выявить функциональные требования и договориться, что именно система должна делать, не смешивая это с тем, как она будет устроена внутри.

Но одного перечня целей недостаточно, когда нужно понять ход взаимодействия: какие действия следуют друг за другом, где возможны разные условия, что происходит параллельно и кто за что отвечает. Для этого сценарии раскрывают на следующем уровне — с помощью диаграмм деятельности.

Диаграммы деятельности: процессы, условия, параллельность и ответственность

В 9:06 Марина отправила заявку на доставку назначенного ей лекарства. Через двадцать минут диспетчер сказал, что заказ проверен. На складе тем временем ждали подтверждения, можно ли собирать покупку, а курьер не видел её в списке доставок. В 11:10 Марина позвонила сама. Никто не пытался переложить на коллег ответственность: каждый честно считал, что свою часть выполнил. Просто слово «проверить» означало для каждого разное.

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

Сначала восстановим историю

Команда не начинает с красивых символов. Она разговаривает с участниками процесса — отдельно, а затем вместе. Марина вспоминает, что указала адрес и пожелала получить заказ утром. Диспетчер говорит: «Я проверил заявку». На вопрос, что именно он проверял, уточняет: адрес, контактный телефон и удобное время. Сотрудник склада тоже говорит: «Мы проверили заказ», имея в виду наличие лекарства и возможность собрать остальные позиции. Курьер понимает под проверкой сверку уже собранного пакета перед выездом.

Это не спор о словах. Это три разных действия, которые команда поначалу сжала в одно. А пока шаги не названы точно, трудно понять, где заявка ждёт, кто должен принять решение и что вообще означает статус «проверено».

При реконструкции полезно разделить три слоя:

1. Наблюдаемые факты. Что участники действительно сделали в случае Марины и в каком порядке?

2. Правила. Что должно происходить согласно действующей политике?

3. Предложения. Что изменить, чтобы следующий заказ не повторил этот путь?

Если смешать эти слои, диаграмма незаметно превратится из описания процесса в изображение желаемого будущего. Это не всегда плохо, но команда должна понимать, какую именно модель строит: as-is — процесс как он есть, или to-be — процесс, каким его хотят сделать.

Для разговора об исполнителях мы выберем дорожки ответственности, или swimlanes. В нашем случае это четыре дорожки: Житель, Диспетчер, Склад, Курьер. Они группируют действия по тому, кто за них отвечает. Это не организационная схема: дорожка не утверждает, что у сотрудника есть определённая должность, что он подчиняется конкретному руководителю или что вся работа происходит в одной системе. Она отвечает на более узкий и полезный вопрос: кто выполняет этот шаг?

От заявки к действиям

Диаграмма деятельности читается как маршрут через работу. Начальный узел показывает, где начинается моделируемая деятельность; обычно его изображают закрашенным кружком. За ним располагаются действия — конкретные единицы работы, часто обозначаемые скруглёнными прямоугольниками. Потоки управления, то есть направленные линии между узлами, показывают, какой шаг может выполняться следующим.

Начальный узел — не то же самое, что действие «Оформить заявку». Первый задаёт старт процесса, второе описывает работу участника. В нашем случае стартом может быть поступление заявки, а первым действием в дорожке жителя — «Отправить заявку».

Когда заявка обработана, процесс завершается конечным узлом деятельности, который обычно изображают как кружок с заполненным центром внутри внешнего круга. Он означает завершение всей деятельности. Например, доставка вручена и зарегистрирована либо заявка отменена и об этом сообщено жителю.

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

Для первого разбора запишем путь заявки Марины без попытки уместить каждую мелочь:

Этап

Дорожка

Назначение

Заявка поступила

Начало процесса

Зафиксировать старт обработки

Отправить заявку

Житель

Передать сведения и пожелания по доставке

Проверить полноту данных

Диспетчер

Убедиться, что есть нужные контакты, адрес и другая обязательная информация

Уточнить недостающие сведения, если они нужны

Диспетчер и житель

Получить данные, без которых нельзя продолжить

Проверить наличие и подготовить заказ

Склад

Установить, что можно собрать и что отсутствует

Подготовить черновой маршрут

Диспетчер

Проверить адрес, временное окно и возможную последовательность доставок

Передать маршрут и заказ на доставку

Диспетчер и курьер

Зафиксировать передачу работы исполнителю

Доставить заказ и отметить результат

Курьер

Завершить доставку или зарегистрировать её неудачу

Таблица пока не раскрывает все развилки. Но уже видны два важных вопроса: что происходит, если данных не хватает, и как диспетчер узнаёт, что на складе обнаружено отсутствие лекарства? Если ответ звучит как «как-нибудь сообщают», перед нами не готовое правило, а пробел, который нужно исследовать.

«Проверить» — не решение

Действие выполняет работу: например, «Проверить полноту заявки». Решение определяет, какой путь будет выбран после работы. Само решение на диаграмме обычно изображают ромбом. Условия — например, [данные полны] и [данных не хватает] — подписывают на исходящих из него потоках.

Это различие практично. Если написать в ромбе «Данные полны?», мы видим вопрос, на который процесс должен ответить. Если поместить туда «Проверить полноту», действие и решение смешаются: непонятно, где именно заканчивается проверка и по какому правилу выбирается дальнейший путь.

Для заявки Марины после проверки полноты возможны два исхода:

• [данные полны] — обработка продолжается;

• [не хватает данных] — диспетчер запрашивает уточнение у жителя.

После уточнения заявка возвращается на проверку. Получается цикл, а не тупиковая ветвь. На практике здесь стоит уточнить и ещё одну деталь: кто следит за ответом и что случится, если его долго нет? Диаграмма не обязана решать этот вопрос сама, но делает его заметным.

Условия на выходах из ромба должны быть сформулированы так, чтобы их можно было проверить. Хорошо, если они покрывают все ожидаемые случаи и не противоречат друг другу. Если возможны «есть в наличии», «нет в наличии» и «данные о наличии пока недостоверны», не стоит прятать третий вариант за расплывчатым словом «иначе». Неопределённый поток — это не упрощение, а будущий спор.

После альтернативных путей часто нужен ромб слияния. Слияние сводит обратно несколько альтернатив, например путь с полными данными и путь с уточнёнными данными. Оно не ждёт, пока «закончатся обе ветви»: в конкретном проходе заявки обычно была выбрана только одна.