Для чего используют диаграмму состояний UML в SILA Union? Элементы и примеры использования
Проекты цифровой трансформации современных организаций характеризуются высокой степенью сложности, многоуровневой архитектурой и вовлеченностью различных профессиональных групп — от бизнес-пользователей до системных архитекторов и разработчиков. В таких условиях особую значимость приобретает задача формализации требований к поведению информационных систем и управляемых ими бизнес-сущностей.
Традиционные текстовые описания, используемые в технических заданиях и регламентах, нередко страдают неоднозначностью, неполнотой и недостаточной проработкой исключительных ситуаций. Это приводит к расхождениям в интерпретации требований, ошибкам при реализации и снижению качества конечных цифровых решений. Особенно остро данная проблема проявляется при описании динамического поведения объектов, жизненный цикл которых включает множество состояний и условий перехода между ними.
Для преодоления указанных ограничений необходимы инструменты, обеспечивающие строгость, формализуемость и визуальную наглядность описания поведения систем. Одним из таких инструментов является диаграмма состояний языка Unified Modeling Language (UML), позволяющая перейти от нарративных описаний к формальной спецификации поведения объектов.
Подробнее о диаграммах UML и их различных типах (случаев использования, классов, последовательности, активностей и др.) с пошаговыми инструкциями создания в системе SILA Union, мы рассказали в отдельной статье.
В этом материале мы детально разберем, что такое диаграмма состояний UML, из каких базовых объектов она строится (автоматы, состояния, переходы), и главное — приведем пример диаграммы состояний непосредственно в среде SILA Union и покажем основные ситуации применения на практике.
Диаграмма состояний – еще один тип поведенческих UML-диаграмм в SILA Union
Статических представлений обычно недостаточно для моделирования физических систем, кроме самых простых. Возьмем, к примеру, любое устройство: оно может быть либо исправно, либо неисправно. Использовать его можно только в исправном состоянии. Однако понятие состояния системы сложно связать с ее структурой, описанной в диаграммах классов. Для этого нужно мыслить в других, динамических категориях.
Поведение системы на логическом уровне в UML может моделироваться с использованием различных видов диаграмм. В отличие от диаграмм классов, описывающих статическую структуру системы, диаграмма состояний ориентирована на динамику и предназначена для моделирования изменения состояния одного объекта во времени под воздействием внешних событий.
Диаграмма состояний описывает возможные последовательности состояний и переходов, которые объект проходит в течение своего жизненного цикла. Такие системы, поведение которых определяется реакцией на события, в теории систем и программной инженерии принято называть реактивными.
Хотя диаграммы состояний чаще всего применяются для описания поведения экземпляров классов, они могут использоваться и для моделирования поведения других элементов системы, включая подсистемы, варианты использования или бизнес-сущности. В формальном смысле диаграмма состояний представляет собой ориентированный граф, соответствующий модели конечного автомата, где вершины соответствуют состояниям, а дуги – переходам между ними.
Далее мы рассмотрим, из каких графических элементов проектируется диаграмма UML в SILA Union.
Автоматы
Автомат в UML – это формальный способ описания поведения объекта через последовательность его состояний. Он показывает все этапы жизни объекта: от создания до уничтожения. Основу автомата составляют состояния и переходы между ними. Состояние – это устойчивая ситуация, в которой объект может находиться длительное время, а переход – это мгновенное изменение, переводящее объект из одного состояния в другое.
При описании конечных автоматов в литературе традиционно приводятся такие примеры, как системы круиз-контроля или торговые автоматы. В качестве альтернативы может быть рассмотрена модель контроллера секретной панели управления в готическом замке. Предполагается, что сокровища надежно скрыты, а для доступа к сейфу необходимо выполнить строгую последовательность действий: сначала требуется вынуть определенную свечу из канделябра, что активирует механизм появления замка только при условии, что дверь помещения закрыта. После появления замка необходимо вставить в него ключ и повернуть, чтобы открыть сейф. В целях повышения безопасности сейф может быть открыт исключительно после извлечения свечи. Нарушение данного порядка действий, например, попытка открыть сейф без выполнения начальных условий, активирует защитный механизм, выпускающий монстра, который нейтрализует злоумышленника.
Состояние
Понятие состояния является фундаментальным в системном анализе и языке UML. Состояние моделирует отдельную ситуацию, в течение которой выполняется некоторое условие. Оно описывается через набор значений атрибутов объекта, причем изменение этих значений отражает изменение состояния объекта. Важно отметить, что состояние характеризуется инвариантным условием, которое включает только те атрибуты, которые значимы для поведения объекта. Это условие может описывать как статическую ситуацию (например, ожидание события), так и динамический процесс (например, выполнение действий).
Графически состояние изображается в виде прямоугольника со скругленными углами. Существует два основных варианта его представления:
- Простая форма, где указывается только имя состояния (см. рис.1)
- Расширенная форма, где добавляется секция с внутренними действиями или переходами (см. рис.2)
Рисунок 1. Простая форма состояния, представленная в SILA Union
Рисунок 2. Расширенная форма состояния, представленная в SILA Union
Имя состояния – это текстовое строка, раскрывающая его смысл. Его принято записывать с заглавной буквы.
Список внутренних действий – эта та секция, которая содержит перечень действий, выполняемых, пока объект находится в данном состоянии. Каждое действие записывается в формате: ‘<метка-действия’/’выражение-действия>’
Метка действия указывает условие для выполнения действия. Выражение действия может использовать атрибуты и связи объекта.
Стандартные метки действий:
- entry – действие выполняется в момент входа в состояние (входное действие);
- exit – действие выполняется в момент выхода из состояния (выходное действие);
- do – деятельность, выполняемая все время нахождения в состоянии, пока не завершится вычисление;
- include – обращение к подавтомату; выражение действия содержит его имя.
Прочие метки идентифицируют события, запускающие внутренние переходы. Эти переходы семантически аналогичны переходам в само состояние, но без выхода и повторного входа, поэтому действия «entry» и «exit» не выполняются.
Рисунок 3. Состояние с внутренними действиями «Ввод пароля»
Начальное и конечное состояния
Начальное состояние – это псевдосостояние, не содержащее внутренних действий. В этом состоянии объект находится по умолчанию в начальный момент времени. Оно указывает точку на диаграмме, с которой начинается процесс изменения состояний.
Рисунок 4. Графическое изображение начального состояния в SILA Union
Конечное состояние – это также псевдосостояние без внутренних действий. В этом состоянии объект оказывается после завершения работы автомата и своего жизненного цикла. Оно указывает точку на диаграмме, в которой процесс изменения состояний завершается.
Рисунок 5. Графическое изображение конечного состояния в SILA Union
Переход
Переход – это отношение между двумя последовательными состояниями, указывающее на смену одного состояния другим. До срабатывания перехода объект находится в исходном состоянии (источнике), после срабатывания – в целевом состоянии.
Переход осуществляется при наступлении события, которое может быть окончанием выполнения деятельности, получением сообщения, приемом сигнала.
Срабатывание перехода также может зависеть от сторожевого условия – логического выражения, которое должно быть истинным.
Рисунок 6. Переход, изображенный в SILA Union
Событие – это спецификация факта, произошедшего в пространстве и времени, которое инициирует переход. События упорядочены во времени и необратимы. В UML события выступают в роли стимулов-триггеров. Имя события идентифицирует переход и записывается со строчной буквы.
Переходы могут быть триггерными и нетриггерными. Первый содержит явно указанное событие-триггер в своей сигнатуре, а второй не имеет строки текста с событием и срабатывает по завершению внутренней деятельности в состоянии-источнике. Условия его срабатывания должны быть ясны из контекста диаграммы.
Сторожевое условие – это логическое выражение, которое записывается в прямых скобках после события-триггера и может принимать значения «истина» или «ложь». Оно уточняет семантику срабатывания перехода. Если связанное с условием событие-триггер наступило и стороженевое условие истинно, переход срабатывает, и объект переходит в целевое состояние. Если условие ложно, переход не срабатывает, и объект остается в исходном состоянии (при отсутствии других подходящих переходов).
Если из одного состояния выходит несколько переходов с одинаковым событием-триггером, их сторожевые условия не должны одновременно быть истинными. Все условия вычисляются каждый раз при наступлении общего для них события.
Практическое применение диаграммы состояний UML
Диаграмма состояний, по своей сути, является визуальной реализацией концепции конечного автомата. Она моделирует жизненный цикл одного объекта (или системы), описывая последовательность его состояний, в которых он находится в ответ на события, и реакцию на эти события.
Они представляют собой широко известную технологию для описания поведения систем. Данная методология, существующая в различных формах с 1960-х годов, активно использовалась на ранних этапах развития объектно-ориентированного программирования для визуализации поведения систем. В объектно-ориентированных подходах диаграммы состояний применяются для моделирования поведения отдельного класса, демонстрируя изменения состояния объекта в течение его жизненного цикла.
Для демонстрации практической ценности данного инструментария рассмотрим модель жизненного цикла центральной для коммерческих подразделений сущности – лида.
На рисунке 7 изображен пример диаграммы состояний в цифровой среде SILA Union.
Рисунок 7. Пример диаграммы UML «Изменение статуса лида» в SILA Union
Здесь показано, как меняется статус лида на протяжении его «жизни» в системе. Данная модель, представленная в графическом виде, недвусмысленно определяет все разрешенные последовательности смены статусов, условия этих изменений и сопутствующие операции. Она исключает возможность интерпретационной произвольности, например, прямого перехода из «Новый» в «Преобразован в клиента», что является нарушением внутреннего регламента.
Диаграммы состояний на практике: где и зачем они работают
Формальные модели оживают, когда встречаются с реальными задачами. Диаграммы состояний — это конкретный инструмент для проектирования динамических состояний процесса, предотвращения хаоса в данных и обеспечения единого понимания для всех участников команды. Рассмотрим ключевые сферы их применения.
1. Диаграммы состояний применяются в проектировании информационных систем управления для моделирования жизненных циклов ключевых объектов системы: заказов, заявок, документов, инцидентов, лидов, договоров, счетов и других бизнес-сущностей. В формализации бизнес-правил и регламентов, где каждый переход между состояниями фактически отражает бизнес-правило, а сторожевые условия – ограничения, накладываемые регламентами.
2. В проектах цифровизации диаграммы состояний применяются для описания управляемого поведения объектов в CRM (Customer Relationship Management – Система управления взаимоотношениями с клиентами), ERP (Enterprise Resource Planning – Система планирования и управления ресурсами предприятия), BPM (Business Process Management – Управление бизнес-процессами)- и low-code-платформах, они служат основой для настройки автоматических переходов статусов, контроля целостности данных и реализации событийно-ориентированной логики.
3. Четко определенный жизненный цикл сущности предотвращает появление «зависших» или противоречивых состояний, что особенно важно при интеграции нескольких систем и распределенной архитектуре.
4. Диаграммы состояний используются различными участниками проекта, каждый из которых решает с их помощью собственные задачи. Бизнес-аналитики применяют диаграммы состояний для формализации требований, выявления исключительных ситуаций и согласования правил изменения статусов с бизнес-пользователями. Системные и корпоративные архитекторы используют их для описания поведенческой логики сущностей в архитектуре предприятия и согласования взаимодействия между подсистемами. Разработчики опираются на диаграммы состояний при реализации логики обработки событий, валидации переходов и разработки конечных автоматов в коде. Тестировщики и специалисты по качеству применяют диаграммы для построения сценариев тестирования, включая негативные и граничные случаи. А владельцы продуктов и процессов используют диаграммы состояний как инструмент контроля соблюдения бизнес-регламентов и оценки зрелости цифровых процессов.
5. В коммерческих системах диаграммы состояний применяются для описания жизненного цикла лида или сделки: от создания до закрытия. Они фиксируют допустимые последовательности изменения статусов (например, «Новый», «В работе», «Квалифицирован», «Закрыт успешно», «Закрыт неуспешно») и исключают произвольные переходы, нарушающие внутренние регламенты продаж.
6. Для заявок и инцидентов диаграммы состояний описывают переходы между состояниями «Зарегистрирован», «В обработке», «Ожидание клиента», «Решён», «Закрыт». Это позволяет строго регламентировать работу линий поддержки, автоматизировать эскалации и обеспечить соблюдение SLA.
7. В системах электронного документооборота диаграммы состояний используются для моделирования жизненного цикла документов: от создания и согласования до подписания, архивирования или аннулирования. Они обеспечивают контроль последовательности действий и юридическую корректность процессов.
8. В ERP- и MES-системах (Manufacturing Execution System – Система управления производственным исполнением) диаграммы состояний применяются для описания статусов заказов, производственных заданий и поставок. Это позволяет синхронизировать работу различных подразделений и обеспечить прозрачность исполнения заказов.
9. Для счетов, платежей и финансовых операций диаграммы состояний позволяют формализовать допустимые состояния (например, «Выставлен», «Оплачен», «Просрочен», «Аннулирован») и предотвратить некорректные операции.
В совокупности с процессными моделями и архитектурными представлениями диаграммы состояний формируют фундамент для построения предсказуемых, устойчивых и согласованных цифровых решений.
Визуальная модель служит формальной спецификацией, минимизирующей риски недопонимания между бизнес-аналитиками, архитекторами и разработчиками.
Заключение
Систематическое использование диаграмм состояний в единой цифровой среде SILA Union позволяет:
- Устранить семантические разрывы: Создать единый источник истины для жизненных циклов ключевых сущностей (например, «Договор», «Проект», «ИТ-Сервис»), понятный как бизнесу, так и ИТ-специалистам.
- Повысить качество и полноту требований: Четко определить все возможные состояния, события и правила переходов, что минимизирует двусмысленности и исключает неучтенные сценарии на ранних этапах проектирования.
- Обеспечить предсказуемость и устойчивость решений: Построить архитектуру, в которой поведение систем логически вытекает из формализованных бизнес-правил, что упрощает модификацию и снижает риски при внесении изменений.
В контексте SILA Union диаграмма состояний связывает стратегические цели бизнеса с архитектурой процессов и реализующими их ИТ-компонентами, делая корпоративную архитектуру работоспособным и устойчивым инструментом управления. Следовательно, освоение и рутинное применение этой нотации внутри платформы является не рекомендацией, а необходимым условием для построения прозрачных, эффективных и технологически подконтрольных цифровых активов компании.
Автор статьи: Ожогина Алина, бизнес-аналитик SILA Union
