132
Как следствие предыдущего пункта, требуется не только объектная, но и
автоматная декомпозиция, что еще больше усложняет структуру системы.
В графической нотации описания поведения смешиваются элементы из
различных языков: используются как составные состояния, так и вложенные
автоматы.
Модули системы не являются в достаточной степени самостоятельными и не
предназначены для повторного использования. Например, имена компонентов
объектов управления совпадают с краткими идентификаторами входных и
выходных переменных автомата. Это довольно странно, если допустить, что
класс объекта управления мог разрабатываться отдельно от управляющего
автомата и может быть повторно использован в другой системе. Кроме того, для
автоматов множество их клиентов ограничивается заранее заданными
поставщиками событий, что препятствует использованию разработанных
автоматов в другом контексте.
В инструменте UniMod используется довольно странная автоматная модель. С
одной стороны, все автоматы являются пассивными: совершают переходы только
при возникновении события. Кроме того, работа системы начинается с запуска
источников событий. Однако все автоматы снабжены завершающими
состояниями, и окончание работы системы происходит по инициативе автомата.
Такая модель находится где-то между пониманием автомата как главной
программы (унаследованного из процедурного программирования с явным
выделением состояний) и как сущности, предоставляющей набор сервисов. В
доказательство наличия пережитков процедурного подхода, в большинстве
проектов, созданных с помощью инструмента UniMod [75], существует
единственный главный автомат, в который вложены все остальные.
Каким же должно быть инструментальное средство автоматного программирования,
поддерживающее подход «автоматизированные объекты управления как классы»?
Для того чтобы средство было востребованным среди широкого круга
программистов, его использование должно требовать минимальных изменений в
процессе разработки по сравнению с программированием «без автоматов».
В соответствии с этим требованием, новый инструмент должен быть встроен в
некоторую популярную среду разработки, а лучше – в несколько сред для различных
объектно-ориентированных языков программирования. При создании нового класса
инструмент должен обеспечивать возможность указания, что этот класс является
автоматизированным. В этом случае при редактировании класса помимо обычного
текста (который понадобится в том случае, если запросы и команды объекта
управления полностью или частично реализуются в автоматизированном классе)
должны появляться схема связей и диаграмма переходов. При этом отметим, что
диаграмму переходов, как правило, удобнее редактировать в графической форме.
Необходимо очень аккуратно подойти к разработке пользовательского интерфейса
инструмента, для того чтобы трудности создания и модификации диаграмм не свели
на нет все преимущества автоматного подхода. Разумеется, в новом инструменте
следует сохранить такие достоинства инструментального средства UniMod, как
проверка правильности и отладка в терминах автоматов.
Разработка инструментального средства, удовлетворяющего перечисленным выше
требованиям, в настоящее время проводится в рамках международного проекта