Поток управления

Когда сообщение получено основной программой и вызван тейкер события, управление не обязательно возвращается немедленно к главному циклу. Действие, вызываемое как результат вызова тейкера события, может самостоятельно вызывать другие тейкеры событий, которые могут, в свою очередь, вызывать еще другие. В конечном счете управление будет передано действию, которое не порождает никаких событий. В этой точке управление возвратится от действия к тейкеру события, который его вызвал, и затем к предыдущему действию, которое вызвало тейкер события. Эта схема будет продолжать поддерживать иерархию вызовов до тех пор, пока управление в конечном счете не возвратится к основному циклу.1

Таймеры

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

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

• Операция, получающая сообщение, возвращает управление почти немедленно независимо от того, доступно получение сообщения или нет.

9.9 Расширение и использование архитектуры Варьирование

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

КМС и Переход. Некоторое повышение эффективности может быть получено путем объединения классов Перехода и КМС. Мы Сохранили их раздельными в этом представлении только для простоты объяснения.

Определитель и связанные с ним пассивные классы. Определитель «объекта» и пассивные прикладные классы «объекта» могут быть объединены. Если это выполнено, некоторые аксессоры инкапсулированных данных не обязательно должны быть общедоступными.

Конструкторы. В определенных случаях данные здесь правила ведут к определению как операции Установить, так и отдельного аксессора создания. Если обе операции имеют одни и те же входные параметры (что вероятно), то операции одинаковы и должны быть выполнен одним и тем же модулем. Если Ваш язык реализации позволяет, мы бы предложили, чтобы этот модуль назывался не только именем Установить, но и естественным для ООА именем аксессор, чтобы сохранить однородность интерфейсов на диаграммах класса.

Рабочие продукты

Традиционные подходы к проектированию предполагают, что проектировщик будет создавать отдельную графическую модель для каждой программы и класса в законченной системе. Однако при использовании трансформационного подхода, как в рекурсивном проектировании, проектирование является столь однообразным, что создание, например, законченных схем структуры класса было бы длинной канцелярской работой.

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

Как только это сделано, создают:

• диаграмму класса для каждого класса в прикладном домене;

• сегменты действия схем структуры класса.

Оставшаяся часть проектирования может быть выражена в шаблонах кода: фрагментах, содержащих метки-заполнители, где должны быть подставлены соответствующие имена (рис.9.9.1).

// Шаблон интерфейса для активного класса с

// использованием C++

//

// Скобки "<...>" обозначают имя, которое должно быть

// подставлено шаблонным процессором. В роли шаблонного

// процессора может выступать программист, редактор,

// специализированная программа, связанная с CASE-средством,

// или препроцессор.

// Атрибутная грамматика может быть использована для

// точного определения правил такой подстановки.

//

// <active class name> и <active class type> являются

// именем и типом активного класса, который определяется.

//

// Индексные переменные используются для обозначения

// i-ro элемента следующим образом:

// attri - объявленный i-й атрибут исходного объекта

// attri type - тип i-ro атрибута, получаемый из

// описания домена

// eventi - номер события, обрабатываемого классом для

// Затребовать событие и Затребовать и Создать

// dataseti - данные события для i-ro события

// dataseti attrj - j-й атрибут для i-й dataset

//

// Объявление класса

class <active class name>: public active instance {

// Объявление компонент экземпляра

private:

<attr1 type> <attr1>;

<attr2 type> <attr2>;

<attr3 type> <attr3>;

<attr4 type> <attr4>;

public:

// Сначала операции класса

// <active class type> Установить(<аttr1 type>,<attr2 type> ... )

// записывается как:

<active class name> (<attr1 type>, <attr2 type> ... );

void Load_FSM();

// Теперь оспоренные на классах тейкеры событий

void Take_and_Create_<event1>(<dataset1 attr1

type>,<dataset1 attr2 type>, ... ); void Take_and_Create_<event2>(<dataset2 attr1

type>,<dataset2 attr2 type>, ... );

// Теперь экземплярные операции, впервую очередь тейкеры

// событий

void Take_<event1>(<dataset1 attrl type>,<dataset1 attr2 type>, ... );

void Take_<event2>(<dataset2 attrl type>,<dataset2 attr2

type>, ... );

// А сейчас аксессоры чтения, обычно именуемые Read_«attri»

<attr1 type> Read_<attr1>();

<attr2 type> Read_<attr2>();

<attr3 type> Read_<attr3>();

}

Рис.9.9.1. C++ шаблон для интерфейса активного класса.

Такая стратегия открывает возможность автоматического создания кода, специально предназначенного для архитектуры, выбранной для конкретного проекта. Мы видели эту стратегию, показываемую с различными степенями автоматизации в нескольких пользовательских проектах и находим ее очень обещающей. Учтите данное замечание:

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