UML: поведение

Activity и дорожки

Activity - это блок-схема процесса: действия, стрелки между ними, ромбы условий, точки распараллеливания. Пока дорожек нет, перед тобой описание алгоритма: понятно, что происходит, и непонятно, кто это делает.

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

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

// Разница с sequence-диаграммой в вопросе, на который они отвечают. Activity отвечает «что за чем происходит и кто отвечает». Sequence - «кто кому какое сообщение шлёт и в каком порядке». Обмен между сервисами рисуют вторым, а не первым.

Машина состояний против набора флагов

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

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

Машина состояний убирает проблему на корню: она перечисляет только законные состояния и только разрешённые переходы между ними, поэтому невозможное просто нечем выразить. Целый класс дефектов исчезает ещё на схеме, до первой строчки кода.

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

завершающий переход

переход без указанного события. Срабатывает автоматически, как только закончится деятельность внутри состояния, а не по внешнему сигналу

Use case диаграмма: обзор, а не детали

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

Ценность в охвате, а не в глубине. За минуту видно, все ли роли учтены, не забыта ли внешняя система-потребитель и нет ли цели, которую никто не заказывал. Это дешёвая проверка полноты перед тем, как углубляться в детали.

// Попытка впихнуть в неё логику превращает диаграмму в паутину из связей «включает» и «расширяет», которую не читает никто. Признак болезни простой: если на схеме больше десятка овалов и появились стрелки между ними, ты рисуешь не use case, а плохую activity.

Как отвечать: «Когда возьмёшь машину состояний, а когда обойдёшься флагами?»

Смотрю, бывают ли недопустимые сочетания. Если у объекта два-три независимых признака и любая их комбинация осмысленна, флаги проще и честнее, городить схему незачем. Но как только появляются сочетания, которых быть не должно - оплачен и одновременно отменён, отгружен без оплаты, - я перехожу к явной машине состояний. Причина арифметическая: три флага дают восемь комбинаций, из них законны обычно четыре, и каждую из четырёх незаконных придётся ловить проверкой в коде, а одну кто-нибудь забудет. Машина состояний перечисляет только законные состояния и переходы, поэтому невозможное не выражается вообще. Заодно на такой схеме сразу видны тупики и недостижимые состояния - те самые дефекты, которые иначе всплывают в проде через полгода.

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

На чём валятся

• −− Моделируют жизненный цикл набором флагов и получают в базе состояния, которых не бывает.
• −− Ставят fork без join: следующий шаг выполняется дважды или стартует раньше времени.
• −− Рисуют обмен между сервисами на activity, хотя для этого есть sequence.
• −− Читают переход без триггера как «в любой момент» и закладывают гонку.
• −− Пихают логику в use case диаграмму вместо текстового сценария и получают нечитаемую паутину.