Переходя к обсуждению инструментального средства для поддержки объектно-ориентированного программирования с явным выделением состояний, отметим, что если для генерации программ по автоматам кроме средств, рассмотренных в разделе 2.3.3, известны также и многие другие, то рассматриваемое здесь решение задачи об автоматизации построения объектно-ориентированных программных систем со сложным поведением в целом единственное в своем роде. Это объясняется тем, что по сравнению с другими средствами визуального конструирования объектно-ориентированных программ (IBM Rational Rose, Borland Together, Telelogic Rhapsody) их проектирование в инструментальном средстве UniMod осуществляется так же, как выполняется автоматизация объектов управления в промышленности. Кроме того, по сравнению с аналогами оно является открытым и бесплатным Авторы проекта UniMod предложили, во-первых, метод и язык моделирования для описания систем со сложным поведением (язык является подмножеством UML), а во-вторых, реализовали инструментальное средство, которое позволяет описывать системы на этом языке, проверять их корректность, интерпретировать или компилировать их и даже отлаживать.
Процесс разработки системы со сложным поведением с помощью этого инструментального средства состоит в следующем. На основе анализа предметной области производится объектная декомпозиция системы, определяются сущности и отношения между ними. В отличие от традиционных для объектно-ориентированного программирова2. ния подходов, из числа сущностей выделяются источники событий, объекты управления и автоматы. Источники событий активны — они по собственной инициативе воздействуют на автомат. Объекты управления пассивны и выполняют действия по команде от автомата. Они также формируют значения входных переменных для автомата. Автомат активируется источниками событий и на основании значений входных переменных и текущего состояния воздействует на объекты управления и переходит в новое состояние. С использованием нотации 3. диаграммы классов строится схема связей автомата, которая задает его интерфейс. На этой схеме слева отображаются источники событий, в центре — автоматы, а справа — объекты управления. Источники событий с помощью UML-ассоциаций связываются с автоматами, которым они поставляют события. Автоматы связываются с объектами, которыми они управляют.
Каждый объект управления содержит два типа компонентов, реализующих 4. входные (xj) и выходные переменные (zk).
Для каждого автомата с помощью нотации диаграммы состояний строится 5. граф переходов, в котором дуги могут быть помечены событием (ei), булевой формулой из входных переменных и выходным воздействием на переходе. В вершинах могут быть указаны выходные воздействия в состояниях и имена вложенных автоматов. Каждый автомат имеет одно начальное и произвольное число завершающих состояний. Состояния на графе переходов могут быть простыми и составными (суперсо6. стояния). Если в состояние вложено другое состояние, то оно является составным. В противном случае состояние простое. Основной особенностью состав ных состояний является то, что дуга, исходящая из такого состояния, заменяет однотипные дуги из каждого вложенного состояния. Компоненты объекта управления, соответствующие входным и выходным переменным, реализуются вручную на целевом языке программирования.
Как может убедиться читатель, подход к разработке, предлагаемый авторами инструментального средства UniMod, отличается от того, который был описан в параграфе 3.1. В частности, в основе этого подхода лежит концепция «автоматы и объекты управления как классы». Скорее всего, такое решение было принято по той причине, что во время создания проекта UniMod концепции «автоматизированные объекты управления как классы» еще не существовало. На рис. 3.19 приведена схема связей автомата, а на рис. 3.20 — его граф переходов, построенные с помощью инструмента UniMod.Поскольку модель системы в рассматриваемом средстве предназначена для компиляции в исполняемый код или интерпретации, ей необходима точная операционная семантика. Перечислим наиболее важные ее аспекты. При запуске модели инициализируются все источники событий. После этого yyони начинают воздействовать на связанные с ними автоматы. Каждый автомат начинает свою работу из начального состояния, а заканчивает yyв одном из завершающих. При получении события автомат выбирает все исходящие из текущего состояyyния переходы, помеченные символом этого события. Автомат перебирает выбранные переходы и вычисляет булевы формулы, запиyyсанные на них, до тех пор, пока не найдет формулу со значением «истина».
Если переход с такой формулой найден, автомат выполняет выходное воздейyyствие, записанное на дуге, и переходит в новое состояние. В нем автомат выполняет выходное воздействие, указанное для этого состояния, а также запускает вложенные автоматы. Если переход не найден, то автомат продолжает поиск перехода у состояния, yyв которое вложено текущее состояние. При переходе в завершающее состояние автомат останавливает все источники yyсобытий. После этого работа системы прекращается. Инструмент UniMod создан на основе среды разработки Eclipse Он позволяет создавать и редактировать схемы связей и графы переходов управляющих автоматов, которые создаются на основе диаграмм классов и состояний языка UML. Инструмент выполняет валидацию автоматов: проверяет достижимость состояний, полноту и непротиворечивость условий переходов. Кроме того, он поддерживает отладку программ в терминах автоматов, когда при пошаговом выполнении на диаграмме состояний подсвечивается текущее состояние, переход, выходная переменная и т. п. И наконец, инструмент совместно с известными или вновь разработанными верификаторами позволяет производить проверку корректности построенных с его помощью программ на основе метода Model Checking Инструментальное средство UniMod может осуществлять как компиляцию диаграмм в код на различных языках программирования (Java, C++), так и непосредственную интерпретацию с промежуточным преобразованием диаграмм в описание на языке XML. В настоящее время ведутся работы по совершенствованию этого инструментального средства Рассматриваемое инструментальное средство весьма эффективно при разработке небольших программных систем «с нуля», что подтверждается экспериментально Читатель, знакомый с материалом параграфов 3.1 и 3.2, мог заметить ряд недостатков модели сложного поведения и подхода к разработке, которые используются в инструментальном средстве UniMod.Концепция «автоматы и объекты управления как классы» нарушает стройность yyобъектно-ориентированной структуры системы и приводит к появлению в ней нового типа сущностей — автоматов. Это ограничивает модульность (поскольку автоматы в действительности не являются самостоятельными сущностями) и усложняет выделение уровней абстракции. Как следствие предыдущего пункта, требуется не только объектная, но и автоyyматная декомпозиция, что еще больше усложняет структуру системы.
В графической нотации описания поведения смешиваются элементы из различyyных языков: используются как составные состояния, так и вложенные автоматы. Модули системы не являются в достаточной степени самостоятельными и не yyпредназначены для повторного использования. Например, имена компонентов объектов управления совпадают с краткими идентификаторами входных и выходных переменных автомата. Это довольно странно, если допустить, что класс объекта управления мог разрабатываться отдельно от управляющего автомата и может быть повторно использован в другой системе. Кроме того, для автоматов множество их клиентов ограничивается заранее заданными поставщиками событий, что препятствует использованию разработанных автоматов в другом контексте. В инструменте UniMod используется довольно странная автоматная модель. yyС одной стороны, все автоматы являются пассивными: совершают переходы только при возникновении события. Кроме того, работа системы начинается с запуска источников событий. Однако все автоматы снабжены завершающими состояниями, и окончание работы системы происходит по инициативе автомата. Такая модель находится где-то между пониманием автомата как главной программы (унаследованного из процедурного программирования с явным выделением состояний) и как сущности, предоставляющей набор сервисов. В доказательство наличия пережитков процедурного подхода в большинстве проектов, созданных с помощью инструмента UniMod существует единственный главный автомат, в который вложены все остальные. Каким же должно быть инструментальное средство автоматного программирования, поддерживающее подход «автоматизированные объекты управления как классы»? Для того чтобы средство было востребованным среди широкого круга программистов, его использование должно требовать минимальных изменений в процессе разработки по сравнению с программированием «без автоматов». В соответствии с этим требованием новый инструмент должен быть встроен в некоторую популярную среду разработки, а лучше — в несколько сред для различных объектно-ориентированных языков программирования. При создании нового класса инструмент должен обеспечивать возможность указания, что этот класс является автоматизированным. В этом случае при редактировании класса помимо обычного текста (который понадобится в том случае, если запросы и команды объекта управления полностью или частично реализуются в автоматизированном классе) должны появляться схема связей и диаграмма переходов. При этом отметим, что диаграмму переходов, как правило, удобнее редактировать в графической форме. Необходимо очень аккуратно подойти к разработке пользовательского интерфейса инструмента, для того чтобы трудности создания и модификации диаграмм не свели на нет все преимущества автоматного подхода. Разумеется, в новом инструменте следует сохранить такие достоинства инструментального средства UniMod, как проверка правильности и отладка в терминах автоматов. Разработка инструментального средства, удовлетворяющего перечисленным выше требованиям, в настоящее время проводится в рамках международного проекта EiffelState (http://code.google.com/p/eiffel-state/), выполняемого на кафедре «Программная инженерия» Высшей политехнической школы в Цюрихе и кафедре «Технология программирования» Санкт-Петербургского государственного университета информационных технологий, механики и оптики. Предложенный в настоящей главе подход обладает при указанных выше достоинствах и одним недостатком: обеспечить верификацию программ, построенных с помощью него, существенно сложнее, чем для программ, в которых логика централизована, как в случае использования инструментального средства UniMod. Этот подход с точки зрения верификации занимает промежуточное положение между программами, построенными традиционными путем, и автоматными UniMod-программами.