УНИВЕРСИТЕТ ИТМО
Кафедра «Технологии программирования»

Преобразование графов переходов, представленных в формате MS Visio, в исходные коды программ для различных языков программирования (инструментальное средство MetaAuto)

© 2005 г. С.Ю.Канжелев, А.А. Шалыто

Санкт-Петербургский государственный университет информационных технологий, механики и оптики

Проектная документация
Исполняемая программа
Исходные тексты

Аннотация

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

Автоматное программирование основано на использовании конечных автоматов, описывающих поведение программ. Подход основан на задании графов переходов автоматов и их визуализации.

Основным достоинством автоматного программирования является возможность формального преобразования графов переходов в исходные коды программ. Возможна также и интерпретация графов переходов без построения кода программы или только при частичном его построении.

Настоящая работа посвящена разработке инструментального средства, названного MetaAuto, позволяющего по графам переходов, построенным с помощью редактора MS Visio, автоматически генерировать изоморфные им исходные коды программ на разных языках программирования, для каждого из которых предварительно должен быть создан шаблон.

Изложим последовательность действий для построения программы по графам переходов, например, на языке C#:
1. Выбрать из готовых или создать, как это указано в работе, шаблон для используемого языка программирования. Для языка C# этот шаблон находится в папке CSharpProject.
2. С помощью редактора MS Visio cтроятся графы переходов автоматов.
3. Запускается программа Visio2Xml.exe (находится в папке Utils), которой в качестве параметров пользователем должны быть переданы путь к файлу, содержащему графы переходов, полученные на шаге 2, и путь к генерируемому этой программой XML-файлу.
4. Запускается программа XSLTransform.exe (находится в той же папке), которой в качестве параметров пользователем указываются путь к полученному на третьем этапе XML-файлу, путь к XSLT-шаблону и путь к генерируемому файлу с исходным кодом.

Отметим, что действия, соответствующие шагам 2-4, могут быть автоматизированы с помощью утилиты nmake (находится в папке Utils) и создания makefile, который содержит связи между файлами с графом переходов, XML-файлом и генерируемым файлом с исходным кодом. Makefile будет обрабатываться утлитой nmake.

Указанные действия могут быть также интегрированы в процесс компиляции в среду разработки, например, MS Visual Studio (папки CSharpProject и CppProject).

Отметим, что для запуска программ необходимо иметь установленный редактор MS Visio и .NET Framework.

Переписка

From: Sergey Kanzhelev <SKanzhelev@*******.com>
To: «Anatoly Shalyto» <shalyto@mail.ifmo.ru>
Date: Wednesday, December 7, 2005, 3:20:51 PM
Subject: об MetaAuto

===8<==============Original message text===============
Анатолий Абрамович!

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

(Вчера я не смог прийти на семинар, хотя очень хотел. Все из-за поездки в Киев)

Константин!

Я много слышал о Вас и впечатлен Вашей работой (той, что на много страниц и с краисвыми автоматами). Рад, что Вы нашли время посмотреть мою работу. Спасибо за критику. Я постарался ответить на нее по пунктам.

> 1. Нет связи со средой компиляции и выполнения. Опять граф создается в
> Visio, но опять без программного (интерфейсного) доступа к реальными
> переменными. 100 процентов — будут ошибки просто при наборе входов/выходов
> или условий переходов. И даже если задавать соответствия переменных и
> обозначений графа, это не то что нужно.

Да действительно. Это очень правильное замечание. Связь со средой программирования необходимо. Сейчас срудно представить программирование без IntelliSense (авто заполнение). Но я реализовывал универсальный конвертер, универсального средства для осуществления обратной связи от среду разработки я не нашел. Соответственно необходимо, по-видимому, делать для каждого языка свой модуль обратной связи. Возможно, поддерживающий в том числе и отладку. Я думаю сейчас над этим. Но честно говоря еще не вижу способа сделать это красиво и универсально.

Следующим этапом может стать интеграция окна Visio в среду разработки. Но судя по всему уже для недавно вышедшей MS Visual Studio 2005 это будет не очень актуально. По той информации, что я слышал о DSL (это фича Visual Studio 2005), в новой студии логичнее будет использовать уже встроенные средства.

> В UniMod уже лучше, но для других сред (как например сименсовские) так не
> получается.

В чем особенность сименсовских сред? Они могут предоставить информацию о переменных, функциях…?

> Все-таки есть ощущение, что универсально не получится никогда.

Универсальное с точностью до написания модуля обратной связи. Другой вопрос, стоит ли овчинка выделки. Не проще ли сразу затачиваться под конкретный язык и среду разработки.

> Насчет ошибок редактирования. Необходимо отслеживать ошибки автоматически
> (как в UniMod) или сделать специальную утилиту. У меня в конверторе для
> S7-200 это делается при создании кода с указанием места ошибки на рисунке
> Visio.

Об этом я не подумал. Спасибо.

> 2. По-моему, не очень удачное решение с разделением графа и схемы связей.
> Зачем дублирование описаний входов/выходов?

Элементы были оставлены для поддержки Visio2Switch. Я предполагал сделать еще и схему связей. У меня есть черновики, но еще сырые чтобы выкладывать. Согласен с замечанием.

> Кстати, глобальная проблема — какая все-таки аннотация более практична -
> универсальная или удобная практически?

Удобна практически, на мой взгляд, универсальная аннотация. Недавно прочел книжку Джеффа Раскина «Интерфейс». Она не про это, а про обычный пользовательский интерфейс. Но там затрагивается похожий вопрос. Автор утверждает, что неразумно делать специальные лазейки для специфичных задач. Они, конечно, облегчают жизни в этом конкретном случае, зато катастрофически усложняют в обычных ситуациях. Например, при переходе на другой язык можно начать постоянно делать ошибки просто из-за того, что привык к другой, заточенной под тебя, нотации.

> 3. И тут же дальше по теме — насколько технологично следование
> рекомендациям по применению конвертора? Спрашиваю как проектировщик-
> практик (а как я понял, автор -студент). Я разрабатывал свои методики и
> конверторы для ПРИМЕНЕНИЯ и как можно простого и зная кто будет ими
> пользоваться. Так вот — даже эта простота не всегда сразу «доходит». Это
> конечно субъективный взгляд, но очень практичный.

Я конвертер применил практически только один раз при изготовлении самого конвертера. Методика не отработана, но я постарался предусмотреть различные варианты использования. У меня есть человек, который хочет попробовать применить мой конвертер. Как только получу конкретные отзывы — постараюсь сообщить.

> 4. Аналогичный вопрос по рекомендациям по собственно реализации логики на
> основе графов. Хорошо бы проанализировать уже имеющиеся методики.

Хороший вопрос. Он всегда возникает при начале работы с инструментом, языком программирования, методикой. Вспомните, когда Вы писали свою первую функцию на C++, Вы, вероятно, как и я не знали, как лучше написать цикл, как вернуть или передать значение — по ссылке, по значению, в конце концов как назвать функцию и куда поместить файл в дереве каталогов. Аналогично, при составлении первой диаграммы на UML.

И если по С++ и по UML написано много литературы «для чайников», то по SWICTH такой литературы нет. Все учатся на своих ошибках.

Однако кроме UniMod, и, вероятно, Вашего конвертера, нет пока ни одной устоявшейся методики. Я думаю, «рекомендации по реализации логики на основе графов» могут быть написаныв только когда есть готовая методика исполнения этих графов. Потому на мой взгляд разумнее не анализировать все, а описывать имеющиеся две.

> Я уже писал и говорил Вам о проблемах конверторов и почему не хотел бы
> выставлять свой.
> В итоге может быть критика (или просто игнорирование применения) и это
> повредит ДЕЛУ SWITCH-технологии.

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

Конвертер, применяемый даже так — наколенно, показал мне преимущество SWITCH, которое до этого я толком не осознавал — возможность формального перевода в код.

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

-
С уважением,
Сергей Канжелев.

===8<===========End of original message text===========