Инициализация механизма конечного автомата полностью заключена в создании соответствующего экземпляра КМС и перехода .Это выполняется прикладными классами . Для этого существует три операции:
1.КМС.создать
2.КМС.добавить переход
3.переход.соответсвовать

Инициализация начинается ,когда прикладной класс вызывает КМС.создать .В свою очередь это принимает текстовую строку для КМС и возвращает ссылку для вновь созданного КМС.
После того как прикладной класс вызвал КМС.создать он вызывает переход.создать один раз для каждой ячейки своей таблицы переходов в состояние.Переход.создать создаёт переход и вызывает КМС.добавить переход для компоновки перехода в структуру данных КМС.Затем переход.создать возвращает управление прикладному классу .

Создание активного прикладного класса .
Объект ,который имеет отдельный конечный автомат для каждого конечного экземпляра используется для создания активного класса . Активный класс включает в себя : имя класса, компоненты экземпляра, аксессоры, тейкеры событий, инициализаторы, конструкторы для предварительно существующих экземпляров.
1. Имя класса – такоеже как у объекта, его породившего
2. Компоненты экземпляра – для каждого атрибута расматриваемого объекта определяется компонента экземпляра каждого класса.
Тип данных каждой компоненты определяется из описания домена атрибута:

Пример:

2.рецепт(Р)
• название рецепта
. время приготовления
. темпиратура приготовления
. скорость нагревания
. темпиратура консервации

строим на базе объекта класс.
Class Рецепт{
Миныты время_приготовления;
Градусы темпиратура_приготавления;
Public:

}

Определение методов класса .
Void принять событие<ev1>(активный класс экземпляра);
Void акссесор1(активный класс экземпляра);

Тип возвращяемого_объекта_класса акссесор2(активный класс экземпляр);
Активный класс установить();
Void загрузить_КМС();
Void принять_создать событие <ev k>;

Аксессоры – определяются общедоступные операции для всех аксессоров, которые определены для расматриваемого объекта и используются в действиях модели состояний некоторого другого объекта. Они идентифицируются из таблицы процессов в состояние.
Тейкеры событий – определяются общедоступные операции соответствующие каждаму генератору событий, который показан таблицей процесов в состояния как предназначеный для расматриваемого объекта. Такие общедоступные операции известны как тейкеры событий. Расмотрим два возможных случая:
1. событие порождаемое генератором событий не вызывает создания нового экземпляра события. Тогда соответствующий тейкер определяется как операция принять_событие.<метка события>.Событие, порождённое генератором событий вызывает создание нового экземпляра объекта.В этом случае соответствующий тэйкер события определяется как операция с именем принять и создать событие <метка события >.Для каждого элемента данных события определяются входные параметры ,переносимые этим событием.Выходные данные не определяются так как события в ООА представляют собой асинхронное взаимодействие , которое поэтому не производит синхронный вывод.
2. Цель тэйкера событий — принять событие и определить какое действие должно быть выполнено и выполнить это действие ,получая экземпляр в новом состоянии .

Инициализатор.
Каждый активный класс должен определить операцию загрузить КМС .Эта операция будет вызываться основным модулем во время инициализации программы
Конструктор для предварительно существующих экземпляров .
Считается ,что в большинстве моделей ООА экземпляры определённых объектов просто существуют и не применяется никаких средств их создания .
Если рассматриваемый объект имеет такую структуру ,то для создания предварительно существующего экземпляра и возвращения его дескриптора обеспечивает операция класса установить .Этот конструктор будет вызываться основным модулем во время инициализации.

Действия.
Часть схемы структуры класса ,имеющей дело с действие создаётся регулярным способом из ДПДД. Сначала создают необщедоступную операцию <объект >.действие<k>,где k-это номер состояния с которым связано действие. Эта операция вызывается только из тэйкеров событий того же класса и поэтому необщедоступна. Операция действие <k> получает все данные события ,которые используются в качестве входных данных тэйкера события. Затем вызываются модули ,соответствующие аксессорам,преобразованиях, проверках и генераторов событий показанных на ДПДД. Цель модуля действия <k>-вызвать эти отдельные модули в определенном порядке.

Основная программа.
На основную программу в рассматриваемой архитектуре возложено 3 задачи:
1.Вызов различных операций инициализации классов
2.Создание внешних событий , которые инициализируют или продолжают канал управления
3.Создание событий типа таймера

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

Структура основной программы .
// Программа управления микроволновой печью
// Инициализируем все предварительно существующие экземпляры

my_элемент:=силовой элемент::установить;
my_лампочка:=лампочка::установить();
my_печь:=печь::установить();

//Собственно работа печи
do_forever
message_here:=get_message(message_buffer);
if message_here then
msg_type:=Unpack_message(message_bufer);

case of msg_type
нажата кнопка:
my_печь.принять_событие_v1();
end_case
дверь открыта:
my_печь.принять_событие_v3();
end_case

дверь закрыта:
my_печь.принять_событие_v4();
end_case

end_if
Таймер:подать сигнал
end_forever

//конец программы печи
Основной модуль должен выполнять операцию Загрузить_КМС всех активных классов. Это может быть выполнено до или после определения основных экземпляров.

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

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