Прямое и обратное проектирование. Для диаграмм состояния возможно прямое проектирование (создание кода по модели), в особенности если контекстом диаграммы является класс

Для диаграмм состояния возможно прямое проектирование (создание кода по модели), в особенности если контекстом диаграммы является класс. Так, из показанной выше диаграммы инструментальное средство могло бы сгенерировать следующий код на языке Java для класса MessageParser:

class MessageParser { public boolean put (char c) { switch (state) { case Waiting: if (c == '<') { state = GettingToken; token = new StringBuffer (); body = new StringBuffer (); } break; case GettingToken: if (c == '>') state = GettingBody; else token.append(c); break; case GettingBody: if (c ==';') state = Waiting; else body.append(c); return true; } return false; } StringBuffer getToken() { return token; } StringBuffer getBody() { return body; } private final static int Waiting = 0; final static int GettingToken = 1; final static int GettingBody = 2; int state = Waiting; StringBuffer token, body; }

Генерация такого кода требует от инструмента некоторых "ухищрений", чтобы включить необходимые закрытые поля и константы с атрибутами final static.

Обратное проектирование (создание модели по коду) теоретически возможно, но практически не очень полезно. Выбор того, что составляет значимое состояние, - прерогатива проектировщика. Инструмент для обратного проектирования не обладает способностью к абстрагированию и потому не может автоматически породить осмысленные диаграммы состояний. Более интересный вариант - анимация модели, задача которой заключается в том, чтобы показать, как будет исполняться развернутая система. Скажем, в предыдущем примере инструментальная программа могла бы анимировать состояния диаграммы по мере их достижения в работающей системе. При этом можно также подвергнуть анимации и срабатывание переходов, показав получение событий и выполнение соответствующих действий. Под управлением отладчика допустимо контролировать скорость выполнения и устанавливать точки прерывания для остановки работы в представляющих интерес состояниях, чтобы просмотреть значения атрибутов отдельного объекта.

Советы

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

Хорошо структурированная диаграмма состояний обладает следующими свойствами:

• сосредоточена на описании какого-либо одного аспекта динамики системы;
• содержит только те элементы, которые существенны для понимания этого аспекта;
• описывает лишь детали, которые соответствуют своему уровню абстракции;
• сбалансированно использует стилистику машин Мили и Мура.

При изображении диаграммы состояний пользуйтесь следующими рекомендациями:

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