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

Софья Вечерняя

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

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

Софья Вечерняя

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

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

— Значит, как только заявка принята, жителю приходит сообщение, — сказала Марина, представитель заказчика.

— Нет, — ответил Илья, разработчик. — Эта стрелка обозначает внутреннее событие. Уведомление отправляется позже, если доступен шлюз сообщений.

Зоя, диспетчер, наклонилась к экрану:

— А я решила, что маршрут обновится сам. Если мост размыло, кто скажет курьеру ехать в объезд?

Архитектор Лев увеличил схему. Стрелка, о которой спорили, действительно соединяла заявку с уведомлением, но рядом с ней стояли ещё две подписи, а начало линии терялось среди других связей.

Никто не ошибался намеренно. Просто каждый читал в схеме то, чего ждал от системы. Заказчик видел обещание, разработчик — техническое событие, диспетчер — порядок действий. Перед командой лежала одна диаграмма, но в действительности — несколько разных объяснений.

— Мы пытались показать всё сразу, — признался Илья.

На стене это «всё сразу» выглядело внушительно. И почти ничего не объясняло.

Четыре слова, которые не стоит путать

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

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

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

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

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

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

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

У моделей есть ещё одна важная особенность: они избирательны. Умолчание может быть полезным — если оно осознанное. И опасным — если участники не заметили, что трактуют пробел по-разному.

Один сервис — три полезных взгляда

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

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

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

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

Разработчику важно понять взаимодействие во времени. Что происходит после того, как медработник отправил заявку? В каком порядке система проверяет данные, обращается к другим участникам и сообщает результат? Здесь полезна диаграмма последовательности: она показывает участников взаимодействия и сообщения между ними.

Например, команда может разобрать базовый сценарий так:

Шаг

Кто действует

Что происходит

1

Фельдшер

Передаёт заявку через интерфейс сервиса

2

Сервис заявок

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

3

Диспетчер

Просматривает заявку и принимает решение об организации доставки

4

Сервис и диспетчер

Фиксируют назначение курьера

5

Курьер

Сообщает о передаче лекарства или о том, что доставку выполнить не удалось

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

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

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

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

Паспорт модели: пять вопросов до рисования

Чтобы диаграмма не превратилась в собрание пожеланий, команда завела простой инструмент — паспорт модели. Его заполняют перед тем, как выбирать символы.

Поле паспорта

Что нужно решить

Цель

На какой конкретный вопрос должна ответить модель?

Аудитория

Кто будет её читать и какие решения принимать?

Границы

Что включено в систему, а что остаётся снаружи?

Допущения

Что мы пока считаем верным, хотя ещё не подтвердили?

Уровень детализации

Насколько глубоко описываем структуру или поведение?

Для первой модели «Тёплого маршрута» паспорт мог бы выглядеть так:

• Цель: согласовать, кто участвует в базовой доставке и где заканчивается ответственность сервиса.

• Аудитория: заказчик, руководитель диспетчерской и команда разработки.

• Границы: от передачи заявки медработником до фиксации результата доставки.

• Допущения: диспетчер участвует в организации доставки; курьер сообщает результат, а сервис его фиксирует.

• Уровень детализации: основные участники, действия и исходы, без технического устройства модулей.

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

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

Первая модель — и её честные пробелы

Команда выбрала вопрос: «Кто участвует в базовом сценарии, и за какой результат отвечает “Тёплый маршрут”?» Для начала составили компактную модель границ сервиса.

Участник

Действие в рамках базового сценария

Результат

Фельдшер

Передаёт заявку на доставку

Запрос поступает в сервис

Диспетчер

Проверяет заявку и организует доставку

Назначение фиксируется

Курьер

Выполняет поручение и сообщает результат

Передача лекарства или неудача доставки отмечена

Житель

Получает лекарство

Факт получения подтверждается согласованным способом

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

В ней намеренно не решены несколько важных вопросов:

• как проверяется рецепт и какие сведения обязательны в заявке;

• кто подтверждает наличие лекарства и как это подтверждение связано с аптекой;

• как выбирается маршрут и что происходит при перекрытой дороге;

• какие статусы видят житель, диспетчер и курьер;

• как сервис работает при потере мобильной связи;

• какие персональные данные собираются и как долго хранятся;

• как система должна быть развёрнута и какие отказы обязана выдерживать.

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

Проверка перед тем, как показать диаграмму

Перед тем как вынести модель на встречу, спросите себя:

1. Какой вопрос она решает? Если ответ звучит как «показывает всю систему», сузьте задачу.

2. Для кого она создана? Заказчику, разработчику и диспетчеру могут понадобиться разные виды.

3. Что включено в границы? Назовите важные внешние системы, роли и процессы, которые остались снаружи.

4. Какие допущения сделаны? Отделите подтверждённые факты от временных договорённостей.

5. Какой уровень детализации выбран? Не смешивайте обзор услуги с внутренним устройством метода или расписанием сообщений.

6. Что модель намеренно не объясняет? Запишите это, чтобы читатель не заполнял пробел собственной догадкой.

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

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

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

Прежде чем рисовать: цель модели, аудитория, масштаб и выбор диаграммы

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

— Мы не понимаем, что именно там происходит, — сказала диспетчер Ирина. — Клиника думает, что мы забыли про заявку. Мы думаем, что ждём машину. А иногда выясняется, что не хватает данных. Статус один, причины разные.

На рабочей встрече разработчик предложил диаграмму классов. Руководитель продукта — диаграмму вариантов использования. Архитектор добавил диаграмму компонентов. Кто-то вспомнил о диаграмме деятельности. За минуту на доске возник целый каталог UML, а исходная жалоба всё ещё ждала ответа.

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

Одна система — разные вопросы

Команда работает над «Тёплым маршрутом» — сервисом доставки термочувствительных лекарств в клиники. На встрече присутствуют три человека с разными задачами:

• диспетчеру нужно понять, где и почему задерживается заявка;

• разработчику важно разобраться, какие данные и связи нужны для назначения транспорта;

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

Это не три формулировки одного вопроса. Это три разных вопроса, а значит, и три разных ракурса.

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

Вместо немедленного рисования ведущая встречи задаёт первый вопрос:

— Какое решение должен помочь принять наш рисунок?

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

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

Шаг 1. Сформулируйте вопрос, на который можно ответить

Фраза «нам нужна схема процесса» пока ничего не говорит о цели. «Нам нужна UML-диаграмма» — тоже. Попробуйте записать вопрос так, чтобы читатель мог проверить: дала ли модель ответ.

Например:

• «На каком этапе заявка чаще всего переходит в ожидание назначения?»

• «Какие данные нужны, чтобы подобрать машине подходящий температурный режим?»

• «Какие внешние системы и участники входят в проект, а какие остаются за его границами?»

Полезно отличать вопрос о том, что происходит, от вопроса о том, из чего система состоит. Первый тянет нас к процессу и поведению, второй — к структуре. Вопрос о том, кто взаимодействует с системой и ради каких целей, ведёт к границам и функциям.

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

Контрольная остановка. Допишите фразу: «После просмотра модели читатель сможет…» Если окончание звучит как «понять систему вообще», вопрос пока слишком широк.

Шаг 2. Назовите будущего читателя

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

Аудитория — это не только должность. Важно выяснить:

• что читатель уже знает;

• какое решение он должен принять;

• какими словами он пользуется в своей работе;

• будет ли он обсуждать модель с другими или использовать её как справочник;

• какие детали ему нужны, а какие станут помехой.

Если диспетчеру показать десяток технических классов, он потратит внимание на расшифровку модели вместо обсуждения задержек. Если разработчику показать только «клиника отправляет заявку, система назначает машину», останется неясно, какие именно данные влияют на назначение.

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

Контрольная остановка. Назовите одного главного читателя. Если приходится отвечать «всех понемногу», подумайте, не нужны ли вам несколько видов модели.

Шаг 3. Выберите масштаб и явно обозначьте границы

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

Для «Тёплого маршрута» границы можно задать так:

• контекст системы: клиника, диспетчер, перевозчик и сервис уведомлений взаимодействуют с «Тёплым маршрутом»;

• сценарий или процесс: от поступления заявки до назначения перевозчика и подтверждения доставки;

• модель предметной области: заявки, грузы, требования к температуре, транспорт и назначения;

• архитектура: программные компоненты и их взаимодействия с внешними сервисами.

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

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

Здесь же полезно записать допущения и неизвестное. В случае «Тёплого маршрута» команда отмечает:

• в текущем процессе статус «Ожидает назначения» используется и при нехватке данных, и при отсутствии подходящего автомобиля;

• подбор машины может выполнять система или диспетчер вручную;

• частоту каждой причины задержки ещё нужно проверить по журналу заявок.

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

Шаг 4. Подберите диаграмму под задачу

Участники встречи возвращаются к исходным вопросам и выбирают не «любимый вид UML», а подходящий способ разговора.

Вопрос

Главная аудитория

Масштаб

Подходящая диаграмма

Где заявка задерживается и что происходит при отсутствии машины?

Диспетчеры и аналитики

Один процесс обработки

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

Какие функции входят в сервис и кто ими пользуется?

Руководитель, заказчик, команда

Граница системы и цели участников

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

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

Разработчики

Предметная область или структура данных

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

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

Архитектор, технический руководитель

Архитектурная структура

Диаграмма компонентов

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

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

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

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