На очереди у нас — диаграмма состояний (или UML State Machine, если по-модному). В целом про UML у нас было тут, про юз кейсы — тут, классы — тут, а диаграмма активностей была здесь.
Как и раньше:
Голубой цвет — то, что не продиктовано UML, а взято как полезный совет/правило из иных теорий и практик.
Курсив — примеры.
Как и раньше:
Голубой цвет — то, что не продиктовано UML, а взято как полезный совет/правило из иных теорий и практик.
Курсив — примеры.
UML State Machine Diagram (Диаграмма состояний) — это диаграмма из разряда поведенческих, которая показывает то, какие состояния может иметь объект моделирования (то, состояния чего мы рисуем) и как они меняются в течение жизни этого самого объекта.
Что такое вообще “состояние”? Состояние — это некая ситуация, в которой объект обладает какими-то неизменными параметрами. Звучит сложно, но, например, наше состояние в течение дня может быть таким: уставший, воодушевленный, голодный, сонный и т. п., причем мы можем находиться в нескольких из них одновременно. Например, состояние “уставший” — это когда у нас параметр “энергия” = низкий. При этом есть какие-то триггеры (события, действия), которые могут повлиять на этот самый параметр, который характеризует состояние (то бишь изменить его) и, соответственно, привести к смене состояния — например, это действие “поспать” (но не только оно). Собственно, чтобы показать целостную картину того, какими мы можем быть в течение дня (какие у нас могут быть состояния) и какие триггеры к каким переходам между состояниями могут привести, мы и можем попользовать такую диаграмму.
Аналитики используют эту диаграмму, чтобы показать жизненный цикл какого-нибудь класса данных из логической модели данных. Или же, чтобы показать/изучить состояния какой-нибудь сущности из модели бизнес-домена при изучении предметной области. Полезно это в том случае, когда жизнь у целевого объекта — сложная, т. е. если класс данных или бизнес-сущность сменяет ряд явно выраженных состояний в процессе своей жизни или в какой-то отрезок времени. Например, мы делаем систему электронного документооборота, и один из ключевых классов данных в этой системе — документ. У объектов этого класса в подобной системе весьма сложная жизнь – отсканированы, отправлены на ревью, одобрены, архивированы и т. п. — это их статусы по мере продвижения по системе, или состояния.
Элементы:
Ключевой элемент один — Cостояние (State). Изображается так же, как и действие на диаграмме активностей, — прямоугольником с закругленными концами.
Ключевой элемент один — Cостояние (State). Изображается так же, как и действие на диаграмме активностей, — прямоугольником с закругленными концами.
Initial State (Начальное состояние; вроде бы, корректно зовется Pseudostate, но это уже такие глубины философии UML, в которые спускаться одиноко и страшно) — точка, которая показывает начало жизни объекта или того куска его жизни, который мы моделируем. Как и начальная точка на диаграмме активностей, изображается в виде закрашенного кружка. Т. е. она и связь, идущая из нее, просто показывают, с чего начинается жизнь объекта (какое состояние у нас является начальным). Например, мы показываем смену состояний человека в контексте еды в течение дня, а значит точка будет сигнализировать некое принятое нами начало дня, т. е. в примере далее мы постулируем, что человек просыпается голодным:
Final State (Конечное состояние) — точка, которая показывает конец жизни объекта или того куска его жизни, который моделируем. Изображается, как и на диаграмме активностей, в виде закрашенного кружка внутри другого кружка. В нашем примере с ее помощью мы покажем, что лечь спать человек может в любом из имеющихся состояний:
Связь нас интересует ровно одна — Behavioral transition (Поведенческий переход). Это связь, которая соединяет состояния и обозначает возможный переход между ними.
На ней может быть указан ряд параметров, но нас интересуют следующие:
- Trigger (Триггер). Это надпись без обрамлений, которая обозначает, что (какое действие или событие) приводит к переходу между состояниями.
- Guard (Условие) — аналогично такому же параметру на диаграмме активностей, это то условие, при котором указанный триггер приведет к переходу. Если условие не выполняется, то триггер не приведет к переходу. Собственно, оформляется так же, как и на диаграмме активностей для связи Control Flow — в квадратных скобках.
В предыдущих заметках мы рассматривали пример с системой видеохостинга и строили диаграмму его вариантов использования и логическую модель данных. Не буду дублировать тут описание условия, просто напомню, что у такого класса данных, как Коммент, есть статус (и мы отразили это в модели данных). Модераторы могут выносить решение по комментарию и тем самым присваивать ему статус, что фактически равно смене состояния и является сигналом к тому, что возможные переходы между статусами лучше бы изучить/показать на диаграмме состояний.
Продвинутые аспекты:
Composite State (Сложное состояние) — это состояние, у которого есть подсостояния. Можно показать их смену внутри такого элемента на той же диаграмме, а можно на отдельной (сопроводив “очочками” сложное состояние на текущей диаграмме):
Фактически это все. UML позволяет добавить на диаграмму еще ряд элементов, но учитывая, что аналитику эта диаграмма не то, чтобы часто нужна (при этом, когда уместна — весьма-таки полезна), мы в них вдаваться не будем, ибо ненужные усложнения.
Типовые ошибки:
Их немного, т. к. диаграмма довольно проста в плане рисования.
Бесполезное применение
Рекомендую не плодить "логические по смыслу" состояния для ваших сущностей данных или бизнес-сущностей — это тупо лишняя работа. То есть если вы вводите в требования какие-то состояния, это требованиями же должно быть обусловлено. Т. е. на примере Коммента (изначальном, а не доработанном для сложных состояний) мы не просто говорим, мол, «чисто концептуально Коммент может быть создан, потом отредактирован или просмотрен, потом удален, а значит давайте колбасить такие его состояния». Нет, никакой пользы это решению и пониманию/реализации требований к нему не несет — девелоперам не нужно ничего в связи с этим кодить в системе. Вводя состояния, вы вводите необходимость системе их отслеживать, что означает, что скорее всего нужен новый атрибут у сущности Коммент с названием Статус, который будет менять свое значение согласно правилам перехода между состояниями, и системе для чего-то необходимо это осуществлять и отслеживать.
Путаница между действиями и состояниями и непонимание целей диаграммы
Мимолетный взгляд на эту диаграмму может вызвать сходу реакцию в духе "Так это та же самая диаграмма активностей — нафига это вообще нужно?" У меня как раз было такое, когда я впервые пытался постичь дао этой диаграммы. Вероятно, это только я такой альтернативно одаренный, но потребовалось время и раскопки, чтобы понять, что между процессом и "жизнью" какого-то объекта есть разница. Мы не показываем тут процесс в понимании его сценария (шаги, ветвления, участники и пр.). Мы показываем, каким может быть объект в течение его жизни или какого-то периода времени. Не процесс "Поесть" для человека (из каких шагов состоит "поесть", кто в них участвует и что на них может пойти не так), а какими могут быть состояния человека в течение дня относительно насыщения и какими могут быть всевозможные переходы между ними, включая начало дня и его конец. Если все еще сложно уразуметь ценность этой диаграммы, то, во-первых, со сложными сущностями данных надо вначале столкнуться на практике, чтобы это щелкнуло, а во-вторых давайте вспомним пример выше: документ в системе документооборота. Представьте, что у него может быть 20+ статусов, пока он движется по системе, которые системе надо отслеживать. Для чего? Как минимум, например, чтобы показать соответствующую иконку статуса для пользователя, а как максимум — чтобы позволять/не позволять совершать над ним какие-то операции в зависимости от текущего статуса. Подобная диаграмма даст повод не упустить море полезных требований, ведь она наводит на вопросы для всех этих 20+ состояний: А можно ли из статуса А перевести документ в статус Б? А обратно? А что именно переводит из статуса А в Б? А при каком условии это можно сделать? В каких статусах может "родиться" документ? А "умереть"? А что такое вообще завершение его жизни и нужно ли оно — удаление, архивация и пр.? Все это критичные для требований вопросы, которые могут и не прийти на ум, если вы не взглянете на картину целиком и именно с такого угла.
