Прямое и обратное проектирование

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

class MessageParser { public boolean put (char c) { switch (state) ( case Waiting :

if (c == ‘<') { state = GettingToken;

token = new StringBufferf) ;

body = new StringBufferf) ;

} 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;

}

StringBuffergetBody() (

' 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 не забывайте, что все диаграммы -это лишь проекции динамических аспектов одной и той же системы. Одна диа­грамма состояний может описать семантику одного реактивного объекта, но ни­когда - семантику всей системы, за исключением самых тривиальных случаев.

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

• сосредоточена на описании какого-либо одного аспекта динамики системы;

• содержит только те элементы, которые существенны для понимания этого аспекта;

• описывает лишь детали, которые соответствуют своему уровню абстракции;

• сбалансирование использует стилистику машин Мили и Мура.

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

• дайте ей имя, соответствующее назначению;

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

• располагайте элементы так, чтобы число пересечений было минимальным