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

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

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

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

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

Разработчику нужна модель данных, но прежде всего команда обсуждает предметную область. В черновой диаграмме могут появиться классы «Заявка», «Клиника», «Груз», «ТребованиеТемпературы», «Транспорт» и «Назначение». Связи показывают, например, что заявка относится к клинике, груз имеет температурное требование, а назначение связывает груз с транспортом.

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

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

Диаграмма компонентов: когда важны программные части и зависимости

Если руководитель уточнит: «Где интеграции могут сорвать запуск?», фокус изменится. Тогда команда может рассмотреть диаграмму компонентов. Она показывает крупные части программного решения, предоставляемые и требуемые интерфейсы, зависимости между компонентами и внешними системами — например, сервис уведомлений или платформу партнёрского перевозчика.

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

Выбор не обязан быть единственным на весь проект. Но у каждой отдельной диаграммы должен оставаться свой главный вопрос.

Шаг 5. Сделайте два наброска — и отдайте их читателям

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

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

После этого черновики показывают будущим читателям по одному, без длинной вводной лекции. Вместо вопроса «Ну как, понятно?» команда задаёт три более полезных:

1. Какой вопрос, по-вашему, решает эта диаграмма?

2. Покажите, что произойдёт в случае, который для вас важен.

3. Что, как вы считаете, осталось за границей модели?

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

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

Практикум: три вопроса до первого значка

Запишите три вопроса о своей системе. Для каждого определите читателя, масштаб и диаграмму. Затем добавьте, почему ближайшая альтернатива хуже отвечает именно на этот вопрос.

Вопрос

Вероятный выбор

Почему не ближайшая альтернатива

Что делает сотрудник, когда заявка не проходит проверку?

Диаграмма деятельности

Диаграмма классов покажет данные заявки, но не порядок действий и ветвление

Какие цели клиника и диспетчер могут достигнуть с помощью сервиса?

Диаграмма вариантов использования

Диаграмма деятельности слишком подробно сосредоточится на ходе одного процесса

Какие сведения и связи нужны для выбора машины с нужным температурным режимом?

Диаграмма классов

Диаграмма вариантов использования покажет цель «назначить транспорт», но не структуру понятий

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

Короткий алгоритм перед рисованием

1. Сформулируйте вопрос. Что читатель должен понять или решить?

2. Назовите аудиторию. Кто будет читать модель и что ему уже известно?

3. Выберите масштаб. Весь контекст, один процесс, предметная структура или архитектура?

4. Обозначьте границы. Что включено, что исключено и какие допущения пока не проверены?

5. Подберите диаграмму. Нужны цели акторов, последовательность действий, структура понятий или программные зависимости?

6. Проверьте черновик на читателях. Попросите объяснить его смысл, пройти важный случай и назвать то, что осталось за рамками.

На встрече по «Тёплому маршруту» команда не стала рисовать все виды UML сразу. Диспетчерам предложили модель процесса, разработчикам — модель предметной структуры, а для обсуждения границ продукта оставили отдельный ракурс. И главное: найденное на схеме подозрение о причинах задержек команда решила проверить по данным, а не объявлять доказанным только потому, что так нарисовано.

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

Сценарии использования: акторы, границы системы и функциональные требования

На совещании в службе доставки лекарств спор начался с простого вопроса: «Кто нажимает кнопку?»

— Актор — «Тёплый маршрут», — сказал заказчик. — Сервис же обеспечивает доставку.

— Нет, актор — житель. Он выбирает лекарство и оставляет заявку, — возразил диспетчер.

— Я уже добавил базу данных, — сообщил разработчик. — Без неё система ничего не запомнит.

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

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

Сначала договоримся, что именно изображаем

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

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

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

Граница — не декоративный прямоугольник. Она отвечает на практический вопрос: за какое поведение отвечает проектируемая система, а какое только наблюдает или использует? Если этот ответ не дан, команда легко начинает приписывать программе физические действия («доставить лекарство») или, наоборот, превращать каждую внутреннюю деталь в участника взаимодействия.

Актор — это роль, а не табличка на двери

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

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

У акторов часто различают две практические роли:

• Первичный актор начинает взаимодействие ради собственной цели. В сценарии оформления заявки это житель: он хочет зарегистрировать запрос на доставку.

• Вспомогательный актор помогает системе выполнить сценарий или предоставляет ей услугу. Например, внешняя система аптечных остатков сообщает, есть ли нужный препарат.

Иногда первичным актором в другом варианте использования становится диспетчер: его цель — назначить курьера на заявку. Один и тот же участник может быть первичным в одном сценарии и вспомогательным в другом — классификация зависит от конкретного взаимодействия.

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

От кнопки к цели

Житель нажимает кнопку «Новая заявка». Но нажатие — не цель. Это лишь действие на экране, один из способов начать взаимодействие.

Полезный вариант использования обычно называют глаголом и объектом: «Оформить заявку на доставку», «Отменить заявку», «Назначить курьера на заявку». Название должно подсказывать, какой наблюдаемый результат получит актор.

Сравните:

Неудачное название

Что в нём не так

Более полезное название

«Обработать данные»

Неясно, кто действует и ради чего

«Оформить заявку на доставку»

«Работать с системой»

Описывает сам факт использования, а не цель

«Назначить курьера на заявку»

«Экран заявки»

Называет интерфейс, а не результат

«Просмотреть статус заявки»

«Проверить адрес»

Может быть внутренним шагом системы

«Указать адрес доставки» — если это цель пользователя

Вариант использования не обязан начинаться с клика. Житель может позвонить в службу, а оператор внесёт заявку от его имени; цель всё равно может оставаться «Оформить заявку», а актором в этом взаимодействии будет оператор. Если же система проектируется так, что человек регистрирует запрос самостоятельно, актором будет житель. Разные каналы взаимодействия могут потребовать разных сценариев — это зависит от того, что именно мы моделируем.

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

Диаграмма «Тёплого маршрута»

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

Актор вне границы

Вариант использования внутри границы

Роль в сценарии

Житель

Оформить заявку на доставку

Первичный актор; начинает взаимодействие ради регистрации заявки

Житель

Отменить заявку

Первичный актор; отзывает ранее созданную заявку, если правила это позволяют

Диспетчер

Назначить курьера на заявку

Первичный актор; выбирает исполнителя и фиксирует назначение

Внешняя система аптечных остатков

Оформить заявку на доставку

Вспомогательный актор; передаёт сведения о наличии препарата

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

Граница помогает исключить ложных акторов. База данных внутри программного сервиса не появляется снаружи прямоугольника. Рабочее место диспетчера — тоже часть решения, а не актор: актор здесь сам диспетчер. Экран «Оформление заявки» — элемент интерфейса, но не цель пользователя. Напротив, внешний сервис аптечных остатков может быть актором, потому что располагается за границей и участвует в обмене данными.

Диаграмма даёт обзор, сценарий раскрывает детали

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

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

Для нашего примера карточка сценария выглядит так.

Карточка UC-01: Оформить заявку на доставку

Цель: житель регистрирует заявку на доставку выбранного лекарства.

Первичный актор: житель.

Вспомогательный актор: внешняя система аптечных остатков.

Триггер: житель начинает оформление новой заявки.

Предусловие: житель вошёл в систему. Заявка ещё не создана.

Основной поток:

1. Житель начинает оформление заявки.

2. Система предлагает указать препарат, количество, адрес и предпочтительный интервал доставки.

3. Житель вводит нужные сведения и подтверждает адрес.

4. Система определяет, находится ли адрес в зоне обслуживания.

5. Система запрашивает у внешней системы аптечных остатков сведения о наличии препарата.

6. Система показывает жителю результат проверки и доступные условия доставки.

7. Житель подтверждает оформление.

8. Система сохраняет заявку со статусом «Новая», присваивает ей номер и показывает подтверждение.

Альтернативный поток A1: адрес вне зоны обслуживания. После шага 4 система сообщает, что доставить по указанному адресу нельзя. Житель может изменить адрес; тогда сценарий возвращается к проверке зоны обслуживания. Если он прекращает оформление, заявка не создаётся.

Альтернативный поток A2: препарата нет в наличии. После шага 5 система сообщает об отсутствии препарата. Житель может выбрать доступную замену, если такая возможность предусмотрена, или завершить оформление без отправки заявки. Правило о заменах нужно согласовать с заказчиком: его нельзя незаметно додумывать за пользователя.

Альтернативный поток A3: житель передумал до отправки. До шага 7 житель прекращает оформление. Система удаляет черновик или сохраняет его по установленному правилу; новая заявка не создаётся. Команда должна выбрать одно поведение, а не оставлять его на усмотрение разработчика.

Результат: либо создана заявка со статусом «Новая», либо заявка не создана. Если сценарий завершился отказом, житель получает понятное объяснение причины.

Это уже не просто рассказ о «доставке». В сценарии появились условия, точки проверки и ожидаемые результаты. Теперь заказчик может ответить на конкретные вопросы: должна ли система разрешать замену препарата? Сохраняется ли черновик? Каковы правила зоны обслуживания? Чем точнее такие решения зафиксированы, тем меньше места остаётся для несовместимых трактовок.

Отмена уже созданной заявки — отдельная цель и поэтому отдельный вариант использования. Для неё тоже нужны правила: может ли житель отменить заявку после назначения курьера? Нужно ли указывать причину? Как меняется статус? Например, предусловием может быть статус «Новая», а результатом — статус «Отменена». Если разрешена отмена и после назначения, это следует описать отдельно и согласовать с операционными правилами.

Связь вариантов использования с функциональными требованиями

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

Идентификатор

Функциональное требование

Проверка

FR-01

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

Житель вводит данные, система принимает их

FR-02

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

Для адреса за пределами зоны заявка не появляется в очереди

FR-03

Если препарат отсутствует, система должна показать результат проверки и не отправлять заявку без подтверждения жителя

При отсутствии препарата создаётся либо не создаётся заявка согласно выбранному правилу

FR-04

После подтверждения система должна присвоить заявке номер и установить статус «Новая»

Житель получает номер, диспетчер видит заявку в очереди

FR-05

Житель должен иметь возможность отменить заявку, если её статус допускает отмену

Статус меняется на «Отменена» при выполнении условий

FR-06

Диспетчер должен иметь возможность назначить курьера на заявку

После назначения в системе сохранены заявка и выбранный курьер

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

Когда include и extend добавляют путаницу

В UML есть отношения include и extend, и пользоваться ими стоит только тогда, когда их смысл действительно нужен.

include означает, что один вариант использования обязательно включает поведение другого. Это удобно для повторно используемого обязательного фрагмента. Например, если несколько сценариев всегда выполняют одну и ту же самостоятельную проверку полномочий, её можно описать отдельно и включать в эти сценарии. Но include — не синоним слова «после этого».

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

В «Тёплом маршруте» отсутствие лекарства — обычная ветвь сценария оформления заявки. Само по себе оно не становится вариантом использования extend: житель не приходит в систему с самостоятельной целью «расширить оформление случаем отсутствия». Если команда без ясной причины соединит сценарии include и extend, диаграмма станет похожа на карту метро: линий много, но куда ехать — непонятно.

Проверка перед публикацией модели

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

1. Названа ли система и ясна ли её граница? Понятно ли, что входит в программный сервис, а что находится снаружи?

2. Каждый ли актор внешняя роль? Не оказались ли внутри диаграммы база данных, экран, внутренний модуль или функция?

3. У каждого ли варианта использования есть актор и осмысленная цель? Можно ли сказать, какой результат получит роль?

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

5. Описаны ли значимые альтернативы? Что будет при неверном адресе, отсутствии препарата или отмене?

6. Проверяемы ли связанные требования? Можно ли определить, выполнено ли требование, не угадывая намерения автора?

Небольшое упражнение: выберите любой знакомый сервис и выпишите три роли, которые с ним взаимодействуют. Для каждой сформулируйте по одной цели в виде «глагол + объект». Затем проведите воображаемую границу вокруг именно того продукта, который моделируете, и перечеркните внутренние компоненты, ошибочно попавшие в список акторов. Если цель нельзя проверить по наблюдаемому результату, переформулируйте её.

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

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