CC BY
54
УДК: 004.051 ББК: 32.973.2
Антипова Е. В.
ВЛИЯНИЕ СПОСОБА ПРЕОБРАЗОВАНИЯ АВТОМАТНЫХ ДИАГРАММ НА ПАРАМЕТРЫ СГЕНЕРИРОВАННОГО ПРОГРАММНОГО КОДА
Antipova E. V.
EFFECT OF STATE DIAGRAM TRANSFORMATION METHOD ON GENERATED CODE PARAMETERS
Ключевые слова: автоматные диаграммы, трансформация автоматных диаграмм, генерация программного кода из автоматных диаграмм, исследование параметров программного кода.
Keywords: state diagrams, state diagram transformation, state diagram code generation, research of code parameters.
Аннотация
В статье исследуются способы трансформации автоматных диаграмм и автоматической генерации программного кода для микроконтроллеров в рамках системы автоматизированного проектирования программно-аппаратных реализаций автоматных диаграмм для промышленных микроконтроллеров.
Abstract
The article studies state diagram transformation methods and automatic code generation for microcontrollers within the framework of computer aided design of softwarefirmware implementations of state diagrams for industrial microcontrollers.
Введение
Применение технологий визуального программирования уменьшает вероятность ошибок и сокращает сроки разработки. Основным недостатком большинства средств разработки программного обеспечения для микроконтроллеров, предоставляющих интерфейс для задания алгоритмов в виде диаграмм UML, является направленность на определенный класс микроконтроллеров. Недостатком других - слишком большая степень унификации, программы получаются обобщенные, неспециализированные под конкретный микроконтроллер. Часто для генерации программного кода используется один механизм генерации. Механизмы трансформации, как структурные, так и аппаратнозависимые, обычно отсутствуют. Большинство систем не поддерживает встроенное определение вспомогательных функций, что делает трассировку диаграммы состояний затруднительной.
Целью данной статьи является предоставить читателю результаты исследования влияния способа трансформации автоматных диаграмм на характеристики программного кода, полученного в результате генерации из автоматных диаграмм различными способами.
Применение различных способов генерации и трансформации дает возможность получить из автоматной модели наиболее эффективную программно-аппаратную реализацию для конкретного устройства.
1. Способы оптимизирующих преобразований автоматных диаграмм Диаграмма состояний обычно разрабатывается человеком и отображает алгоритм процесса управления, как его представляет разработчик. Считается, что преобразование диаграмм состояний нецелесообразно потому, что при трансформации меняется структура диаграмм состояний - количество и смысл состояний, их тип, переходы между состояниями. Однако, в некоторых случаях, например, если диаграмма состояний
содержит большое количество состояний или переходов, применение алгоритмов преобразования диаграммы оправдывается целью сделать диаграмму более наглядной и компактной.
Трансформация диаграмм состояний может касаться только структуры, либо затрагивать аппаратно-зависимые компоненты. В данной статье подробно рассмотрим механизмы структурной трансформации.
К структурным механизмам трансформации можно отнести минимизацию
1 2 3 4 5
автомата , выделение в различные структурные компоненты возвратных частей и
^ 6,7
других структурных элементов автоматной диаграммы , поиск и устранение изоморфизма8,9, объединение в композитное состояние групп состояний по определенным условиям (общий исходящий переход, общие входные или выходные действия и пр).
В данном исследовании будет использован пример автоматной диаграммы, реализующей работу электронных часов, отображающих дату и время с возможностью их настройки (см. рисунок 1).
Рисунок 1 - Автомат работы электронных часов 1.1. Трансформация «Сокрытие деталей реализации»
В исследованиях Волковой Е.Д. и Страбыкина А.Д.10 приводится несколько алгоритмов трансформации автоматных диаграмм. Среди них описан алгоритм сокрытия деталей реализации11. Алгоритм применим для состояний, имеющих большое количество переходов в самих себя. Процесс находится в состоянии ожидании запроса на выполнение определенной операции, при получении которого выполняются действия, указанные на
1 Брауэр В. Введение в теорию конечных автоматов: Пер. с нем. - М.: Радио и связь, 1987. - С. 243.
2 Гилл А. Введение в теорию конечных автоматов. - М. Наука, 1966. -С. 75.
3 Карпов Ю.Г. Теория автоматов. - СПб.: Питер, 2003. -С. 106.
4 Глушков В.М. Синтез цифровых автоматов. - М.: Физматгиз, 1962. -С. 135.
5 Кобринский Н.Е., Трахтенброт Б.А. Введение в теорию конечных автоматов. - М.: Физматгиз, 1962. -С. 210.
6 Волкова Е. Д. Анализ и трансформации исполняемых UML моделей / Е.Д. Волкова, А.Д. Страбыкин. // Труды Института системного программирования. - М.: ИСП РАН, 2006. - С. 171-192.
7 Волкова Е. Д. Методы композиции и декомпозиции исполняемых иМЬ моделей / Е.Д. Волкова, А.Д. Страбыкин. // Труды Института системного программирования. - М.: ИСП РАН, 2006.
8Брауэр В. Введение в теорию конечных автоматов: Пер. с нем. - М.: Радио и связь, 1987. - С. 85.
9 Мелихов А.Н. Ориентированные графы и конечные автоматы. - М.: Наука, 1971. - С. 187.
10Волкова Е. Д. Анализ и трансформации исполняемых иМЬ моделей / Е.Д. Волкова, А.Д. Страбыкин. // Труды Института системного программирования. - М.: ИСП РАН, 2006. - С. 171-192.
11Волкова Е. Д. Методы композиции и декомпозиции исполняемых иМЬ моделей / Е.Д. Волкова, А.Д. Страбыкин. // Труды Института системного программирования. - М.: ИСП РАН, 2006.
переходе, и система вновь возвращается в исходное состояние. Большое количество переходов в само себя означает особую семантическую роль внутренних спецификаций состояния. Если автоматная диаграмма имеет довольно большое количество таких состояний, детали описания работы каждого из них значительно усложняют диаграмму.
Рисунок 2 иллюстрирует результат применения трансформации.
/ГпсТйпеО
Рисунок 2 - Автомат работы электронных часов после применения трансформации
«Сокрытие деталей реализации»
В результате преобразования исходная автоматная диаграмма становится более удобной для восприятия. Выделенные композитные состояния вместо состояний с большим количеством переходов в само себя подчеркивают значимость внутренней функциональности.
1.2. Трансформация «Выделение возвратной части автоматной диаграммы в композитное состояние или автоматный метод»
Данные алгоритмы трансформации подробно описаны в работах
1,1
1 Волкова Е. Д. Анализ и трансформации исполняемых иМЬ моделей / Е.Д. Волкова, А.Д. Страбыкин. // Труды Института системного программирования. - М.: ИСП РАН, 2006. - С. 171-192.
Рассмотрим множество состояний МгЛ'и состояние .Vе N. Состояние 5 считается входным узлом, если существует состояние а &Ы и переход из состояния а в 5. Состояние Ь<£Ыявляется выходным узлом, если существует переход /е У ИЗ Л в Ь.
Множество состояний N, не содержащее конечное состояние исходного автомата, является возвратной частью автомата, если для множества состояний N существует ровно один входной узел и не более одного выходного. Возвратных частей может быть несколько.
Возвратную часть можно обособить двумя способами:
1) перенести в автоматный метод;
2) перенести в композитное состояние.
При переносе возвратной части в автоматный метод все состояния, принадлежащие множеству N и переходы между ними выносятся на отдельную диаграмму. Создается переход из начального состояния новой диаграммы (по сути, нового автомата) во входной узел возвратной части. Все переходы, ведущие из состояний, принадлежавших возвратной части, в выходной узел, заменяются в новой диаграмме переходами в конечное состояние. На исходной диаграмме (где уже отсутствуют состояния, принадлежащие возвратной части, и переходы между ними) все переходы, входящие во входной узел заменяются переходами в выходной узел, а к действиям на этих переходах добавляется вызов нового метода.
Выделенный метод является автоматным, т.е. описывает автомат по всем правилам, присущим основному автомату, вплоть до определения интервала дискретизации. Удобство применения автоматных методов заключается в том, что вызвать его можно в любом месте, где разрешен вызов обычных функций. В то же время, автоматный метод может описывать работу внешних устройств, сопряженных с основным - например, автоматный метод может управлять выводом информации на некоторое устройство, рабочая частота которого может отличаться от частоты основного устройства и интервала дискретизации самого автомата.
Перенос возвратной части автомата в композитное состояние происходит по следующему алгоритму:
1. На исходной диаграмме создается новое композитное состояние.
2. Все состояния, входящие в состав возвратной части автомата, и переходы между ними переносятся в новое композитное состояние.
3. Переходы, входящие во входной узел, заменяются переходом по умолчанию в новое композитное состояние.
4. Переходы, ведущие в выходной узел, заменяются сквозными переходами из вложенных состояний в выходной узел.
На рисунке 3 приведен результат применения трансформации «Выделение возвратной части автоматной диаграммы в композитное состояние» для исходного автомата (рисунок 1).
На рисунке 4 приведен результат применения трансформации «Выделение возвратной части автоматной диаграммы в автоматный метод» для исходного автомата (рисунок 1).
1 Волкова Е. Д. Методы композиции и декомпозиции исполняемых иМЬ моделей / Е.Д. Волкова, А.Д. Страбыкин. // Труды Института системного программирования. - М.: ИСП РАН, 2006
/ГпсТйпеО
Рисунок 3 - Результат применения трансформации «Выделение возвратной части автоматной диаграммы в композитное состояние» для автомата работы электронных часов
/1псПтеО
Рисунок 4 - Применение трансформации «Выделение возвратной части автоматной диаграммы в автоматный метод для автомата работы электронных часов
1.3. Трансформация «Выделение групп состояний с общими спецификациями в композитные состояния».
Для композиции групп состояний требуется определить непересекающиеся множества состояний, имеющих общие спецификации. К спецификациям в данном случае
относятся действия при входе в состояние, действия при выходе из состоянии и внутренняя деятельность состояния. При определении множеств состояний можно указать степень схожести спецификаций: количество вызовов соответствующих функций
(операций), которое взаимно отличает один список однотипных спецификаций от других.
Порядок следования спецификаций в соответствующем списке учитывается, фактические параметры функций при вызове - тоже.
На рисунке 5 представлен результат применения трансформации «Выделение групп состояний с общими спецификациями в композитные состояния» для автомата, представленного на рисунке 1.
Рисунок 5 - Результат применения трансформации «Выделение групп состояний по
общим спецификациям»
Механизм уместно применять в автоматах с большим количеством состояний, которые содержат схожие внутренние спецификации.
1.4. Комбинации трансформаций
К одной и той же автоматной диаграмме можно применить сразу несколько трансформаций. Результат зависит не только от механизма трансформации, но и от последовательности применения. К автомату, представленному на рисунке 1, применимы следующие последовательности трансформаций из описанных выше:
1. Трансформации «Сокрытие деталей реализации» и «Выделение возвратной части автоматной диаграммы в композитное состояние».
2. Трансформации «Сокрытие деталей реализации» и «Выделение возвратной части автоматной диаграммы в автоматный метод».
3. Трансформации «Выделение возвратной части автоматной диаграммы в
композитное состояние» и «Сокрытие деталей реализации».
4. Трансформации «Выделение возвратной части автоматной диаграммы в
автоматный метод» и «Сокрытие деталей реализации».
5. Трансформации «Выделение групп состояний с общими спецификациями в композитное состояние» и «Сокрытие деталей реализации».
Применение более двух механизмов трансформации над нашим примером оказалось невозможным.
2. Основные принципы отображения автоматных диаграмм в программный код
Существует множество механизмов генерации программного кода из автоматных диаграмм, и каждый из этих способов может иметь несколько вариаций. Рассмотрим самые характерные из них: switch-технология, отображение множества актуальных состояний во множество меток перехода, отображение множества переходов в упорядоченное или неупорядоченное множество переходов автомата и паттерн State.
2.1. Switch-технология
Классическая реализация конечного автомата основывается на конструкции switch-case. Оператор switch является дешифратором состояний. В зависимости от текущего состояния, полученного входного сигнала и сторожевых условий происходит выработка выходных сигналов, выполняются действия на переходе, вычисляется новое текущее состоянии и выполняются входные действия нового текущего состояния. При следующей итерации рабочего цикла микроконтроллера все повторяется для нового текущего состояния.
На базе switch-подхода разработана мощная технология для формализации генерации программного кода по автоматным диаграммам, которая получила название Switch-технология. В России switch-технология развивается в Санкт-Петербургском государственном институте точной механики и оптики с 1991 года1. В основе подхода лежит классический механизм реализации конечного. Основное внимание уделяется управляющим (автоматным) состояниям, которые перечисляются явно, в то время как вычислительные состояния2 описываются функциями выходных сигналов.
Структура программы и статические свойства проектируемой системы определяются на схеме связей, которая может совмещаться со схемой взаимодействия автоматов3. Схема связей также содержит условное обозначение и расшифровку входных и выходных сигналов.
Поведение системы задается графами переходов перечисленных в схеме связей автоматов (в формате диаграммам состояний4).
Недостатком метода является возможное дублирование участков кода при сложных сквозных переходах в композитных состояниях, а также трудности с сопровождением сгенерированного кода при отсутствии исходных диаграмм.
1 Туккель Н.И., Шалыто А.А. Программирование с явным выделением состояний // Мир ПК. - 2001. - № 9. -С. 132 -138
2 Шалыто А.А., Туккель Н.И. От тьюрингова программирования к автоматному // Мир ПК. - №2, 2002. -с.144 -149
3 Шалыто А.А., Туккель Н.И. SWITCH-технология — автоматный подход к созданию программного обеспечения «реактивных» систем. // Программирование. - №5, 2001. - с.45 - 62
4 Harel D. Statecharts: a Visual Formalism for complex systems // Science of Computer Programming. - Vol. 8, 1987. - pp. 231-274
2.2. Отображение множества актуальных состояний во множество меток перехода
1) При программировании на языках высокого уровня использования оператора goto стараются избегать. Оправдывается это тем, что отследить все переходы по исходному коду трудно, а невысокая квалификация программиста или недостаточный опыт низкоуровневого программирования могут породить большое количество ошибок и привести к непредсказуемому поведению программы. Однако оператор goto предоставляет настолько широкие возможности выполнения строго определенных участков кода в строго определенный момент времени, что грамотное его использование не породит никаких побочных эффектов работы программы. Более того, при использовании концепции конечных автоматов и визуальной отладке программы на уровне диаграмм состояний генерация исходного кода программы на основе переходов по меткам goto не вызовет никаких неудобств. В отличие от графических языков МЭК метки не присутствуют явно на диаграмме состояний, они используются только на уровне языка целевой среды и не влияют на структуру диаграмм.
К недостаткам метода можно отнести плохую читаемость сгенерированного кода и сложности при его сопровождении.
2.3. Отображение множества переходов автомата в таблицу переходов
Метод переходов по таблице имеет несколько разновидностей, но можно выделить основные классы, различающиеся принципом построения таблицы.
В первом случае таблица содержит столбцы Исходное_состояние, Условие_перехода, Действие_перехода, Целевое_состояние, которые описывают каждый переход автомата. Условие_перехода здесь представляет собой комбинацию сторожевого условия и события-инициатора перехода. В зависимости от конкретной реализации количество, тип и значение столбцов может изменяться.
При реализации автоматных диаграмм при помощи таблицы переходов диаграмма состояний транслируется в массив объектов вида <Исходное_состояние; Событие; Сторожевое_условие; Целевое_состояние; Выходные_действия>. При получении входного сигнала программа просматривает массив и ищет строку с соответствующим полем <Событие>, где исходное состояние равно текущему, и выполняется сторожевое условие. Затем выполняются необходимые действия, и определяется новое текущее состояние.
Данный метод хорош при автоматической генерации таблицы, при ручной разработке легко переносит добавление новых состояний и переходов, небольших усилий требует добавление новых условий переходов. При удалении состояний, переходов или условий перехода требуется просмотр всей таблицы. Размер таблицы зависит от количества переходов в автомате.
Второй класс содержит методы, опирающиеся на таблицу другого вида. Все состояния располагаются в определенном порядке, образуя столбцы таблицы и обозначая исходные состояния переходов. Все возможные условия перехода, а именно комбинации сторожевых условий и событий, помещаются в специальный список. Каждая строка таблицы переходов будет соответствовать условию перехода из данного списка. Каждая строка в каждой ячейке содержит поле Действие_перехода и Целевое_состояние. Если из текущего состояния нет перехода по данному условию, то ячейка остается пустой.
При использовании данного метода добавление и удаление новых условий перехода требует добавления и удаления строк соответственно, что довольно удобно. Добавление новых состояний потребует введения новых столбцов в таблице, что не всегда может быть удобно. Удаление состояний из таблицы потребует просмотра всей таблицы. Появление и удаление переходов не доставляет каких-либо неудобств. Если автомат не полностью определен, налицо избыточность такой таблицы. Зато такой способ очень нагляден.
В данном случае размер таблицы зависит от произведения количества состояний на количество различных условий переходов.
Третий способ задания таблицы - это квадратная матрица переходов, где номер столбца или строки обозначает определенное исходное или целевое состояние. Каждый элемент матрицы хранит условие перехода, действие перехода и признак сегмента сквозного перехода. В данном исследовании такой способ рассматриваться не будет
2.4. Паттерн проектирования State
Паттерн State подразумевает создание класса автомата, который содержит описание абстрактного класса State, от которого наследуются конкретные состояния. Абстрактный класс State имеет набор методов, реализующих переходы по всем возможным в системе входным сигналам. В классе State такие методы не содержат никаких действий. Каждый конкретный класс переопределяет методы, соответствующие обработке сигналов, которыми помечены все исходящие дуги из данного состояния на диаграмме.
В главном классе автомата содержатся экземпляры всех дочерних классов состояний и ссылка на класс State, которая и указывает на текущее состояние.
Применение паттерна State позволяет добавлять новые состояния и удалять «лишние» с минимальными затратами и правками кода.
К недостаткам метода относится:
1) большие затраты памяти для размещения всех экземпляров состояний;
2) сложности при добавлении в программу новых событий, что влечет за собой добавление нового метода в класс State, и соответственно, переопределение нового метода в дочерних классах;
3) низкая читаемость кода в тех случаях, если целевая архитектура не поддерживает объектно-ориентированный стиль программирования.
Генерация объектно-ориентированного паттерна проектирования в программу, написанную в функциональном стиле, неэффективна, неестественна и может повлечь огромное количество проблем при попытке сопровождать и модифицировать программный код при отсутствии исходных диаграмм и инструментов генерации.
3. Сравнение производительности программного кода
Скорость обработки программой входных сигналов - один из самых важных показателей эффективности программно-аппаратной реализации автоматной диаграммы. В данном исследовании измерялось суммарное количество тактов микроконтроллера при обработке тестовой последовательности входных сигналов.
В таблице 1 приведены сравнительные результаты эффективности применения трансформация для каждого из методов генерации (относительно исходной автоматной диаграммы без применения трансформаций). Жирным шрифтом выделены случаи, когда скорость работы программы, полученной из трансформированной диаграммы, превышала скорость работы программы, полученной из исходной диаграммы.
В таблице 1 и всех прочих приняты следующие обозначения:
1. Трансформация №1 - Сокрытие деталей реализации;
2. Трансформация №2 - Выделение возвратной части автоматной диаграммы в композитное состояние;
3. Трансформация №3 - Выделение возвратной части автоматной диаграммы в автоматный метод;
4. Трансформация №4 - Выделение в композитное состояние групп состояний с общими спецификациями;
5. Трансформация №5 - Комбинация трансформация «Сокрытие деталей
реализации» и «Выделение возвратной части автоматной диаграммы в композитное состояние»;
6. Трансформация №6 - Комбинация трансформаций «Сокрытие деталей
реализации» и «Выделение возвратной части автоматной диаграммы в автоматный метод»;
7. Трансформация №7 - Комбинация трансформаций «Выделение возвратной части автоматной диаграммы в композитное состояние» и «Сокрытие деталей реализации»;
8. Трансформация №8 - Комбинация трансформаций «Выделение возвратной части автоматной диаграммы в автоматный метод» и «Сокрытие деталей реализации»;
9. Трансформация №9 - Комбинация трансформация «Выделение в композитное состояние групп состояний с общими спецификациями»;
10. Механизм генерации №1 - Отображение множества актуальных состояний в аргумент оператора выбора;
11. Механизм генерации №2 - Отображение множества актуальных состояний в множество меток перехода;
12. Механизм генерации №3 - Отображение множества актуальных состояний в объекты класса State;
13. Механизм генерации №4 - Отображение множества переходов в общий список спецификаций автомата;
14. Механизм генерации №5 - Отображение множества переходов в сегментированное множество спецификаций автомата.
Из таблицы 1 видно, что комбинация трансформаций «Сокрытие деталей реализации» и «Выделение возвратной части автоматной диаграммы в композитное состояние» при отображении множества актуальных состояний в аргумент оператора выбора дает выигрыш почти в 2 раза (94,0% относительно программы, полученной из автоматной диаграммы без трансформации). Также данная комбинация эффективна для данной автоматной диаграммы при отображении множества актуальных состояний в множество меток перехода и при применении паттерна State. Но и другие комбинации способов трансформации и генерации дают довольно ощутимые приросты производительности.
Таблица 1 - Прирост скорости обработки тестового примера
\ Механизм трансформа \ ции Механизм генерации \ Трансформация №1 Трансформация №2 Трансформация №3 Трансформация №4 Трансформация №5 Трансформация №6 Трансформация №7 Трансформация №8 Трансформация №9
Механизм генерации №1 64,5% 14,7% -1,0% 1,6% 94,0% 35,7% 37,2% -1,3% 65,2%
Механизм генерации №2 65,1% 21,2% 40,9% 1,9% 98,1% 65,9% 37,9% 40,7% 67,6%
Механизм генерации №3 65,3% 14,5% -1,8% 1,7% 94,5% 67,7% 36,8% -2,1% 65,2%
Механизм генерации №4 50,0% 0,2% 87,1% -716,4% -54,1% -156,8% -8,1% 88,0% -529%
Механизм генерации №5 -253% -115,0% -4,8% -548,2% 90,4% -360,1% -119,5% -4,9% -453,0%
4. Сравнение объема памяти кода и данных программ, полученных из автоматной диаграммы после применения трансформаций
В таблице 2 приведены сведения о затратах памяти кода и данных программ, полученных перечисленными способами.
______Таблица 2. - Затраты памяти кода и данных (в байтах)______________________
Механизм трансформации Механизм генерации ^ч Без трансформации Трансформация №1 Трансформация №2 Трансформация №3 Трансформация №4 Трансформация №5 Трансформация №6 Трансформация №7 Трансформация №8 Трансформация №9
Механизм генерации 2820 2932 2832 3300 2818 2938 3234 2850 3332 2878
№1 5 5 5 29 5 5 29 5 29 5
Механизм генерации 3036 3196 3080 3082 3070 3216 3214 3106 3110 3130
№2 7 7 7 7 7 7 7 7 7 7
Механизм генерации 3026 3324 3070 3548 3056 3368 3716 3120 3610 3210
№3 61 109 69 101 69 117 141 77 109 93
Механизм генерации 4188 5762 4402 5188 4628 5954 6530 4626 5306 5420
№4 382 872 452 465 522 931 909 522 500 767
Механизм генерации 4312 6386 4602 5118 4900 6658 6962 4898 5276 5940
№5 370 902 446 465 522 970 945 522 503 788
Из таблицы 2 видно, что практически во всех случаях затраты памяти почти не отличаются от затрат памяти программы, полученной из автоматной диаграммы без применения трансформаций. Практически всегда памяти требуется больше, причем в случаях табличной реализации автомата (механизмы генерации №4 и №5) значительно.
Заключение
В таблицы не вошла такая метрика кода, как количество строк. Но даже без подобной оценки ясно, что отбрасывать такие мощные механизмы получения эффективных программно-аппаратных реализаций автоматных диаграмм, как применение различных механизмов трансформации и генерации, не стоит.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Брауэр В. Введение в теорию конечных автоматов: Пер. с нем. - М.: Радио и связь, 1987. - 392 с.: ил.
2. Гилл А. Введение в теорию конечных автоматов. - М. Наука, 1966. - 272 с.: ил.
3. Карпов Ю.Г. Теория автоматов. - СПб.: Питер, 2003. - 208 с.: ил.
4. Глушков В.М. Синтез цифровых автоматов. - М.: Физматгиз, 1962. - 476 с.: ил.
5. Кобринский Н.Е., Трахтенброт Б.А. Введение в теорию конечных автоматов. -М.: Физматгиз, 1962. - 404 с.: ил.
6. Волкова Е. Д. Анализ и трансформации исполняемых ЦМЪ моделей / Е.Д. Волкова, А.Д. Страбыкин. // Труды Института системного программирования. - М.: ИСП РАН, 2006. - С. 171-192.
7. Волкова Е. Д. Методы композиции и декомпозиции исполняемых ЦМЪ моделей / Е.Д. Волкова, А.Д. Страбыкин. // Труды Института системного программирования. - М.: ИСП РАН, 2006.
8. Мелихов А.Н. Ориентированные графы и конечные автоматы. - М.: Наука, 1971. - 416 с.: ил.
9. Беляев А. В., Суясов Д. И., Шалыто А. А. Компьютерная игра «Космонавт».
Проектирование и реализация // Компьютерные инструменты в образовании. - № 4, 2004. -с. 75-84..
10. Гуров В. С., Мазин М. А., Шалыто А. А. Автоматическое завершение ввода условий в диаграммах состояний // Информационно-управляющие системы. - №1, 2008. -с. 24-33.
11. Гуров В., Мазин М.А., Нарвский А.С., Шалыто А.А. UML. SWITCH-технология. EdipseZ/Информационно-управляющие системы-2004. №6- с. 12-17.
12. Гуров В., Нарвский А. Шалыто А.А. ICQ и автоматы // Технология клиент-сервер. - № 3, 2004. - с. 3-11.
13. Гуров В., Нарвский А., Шалыто А. Исполняемый UML из России // PC Week/RE. - № 26, 2005. - с. 18-19.
14. Канжелев С.Ю., Шалыто А. А. Автоматическая генерация автоматного кода // Информационно-управляющие системы. - №6, 2006. - с. 35-42.
15. Степанов О.Г. Методы реализации автоматных объектно-ориентированных программ : Дис. ... канд. тех. наук / Санкт-Петербургский государственный университет информационных технологий, механики и оптики. СПб., 2009.
16. Туккель Н.И., Шалыто А.А. Программирование с явным выделением состояний // Мир ПК. - 2001. - № 9. - С. 132 -138.
17. Шалыто А.А. Автоматное проектирование программ. Алгоритмизация и программирования задач логического управления // Известия академии наук. Теория и системы управления. - № 6, 2000. - с.63-81.
18. Шалыто А.А. Алгоритмизация и программирование задач логического управления. - СПБ: СПбГУ ИТМО,1998.
19. Шалыто А.А. Switch-технология. Алгоритмизация и программирование задач логического управления. - СПб.: Наука,1998. - 628 с.
20. Шалыто А.А. Автоматно-ориентированное программирование // Материалы IX Всероссийской конференции по проблемам науки и высшей школы "Фундаментальные исследования в технических университетах". - СПб.: изд-во Политехнического университета. 2005. - с. 44-52.
21. Шалыто А.А. Алгоритмизация и программирование для систем логического управления и "реактивных" систем // Автоматика и телемеханика. - №1, 2001. - с.3-39.
22. Шалыто А.А. Программная реализация управляющих автоматов //Судостроительная промышленность. Серия «Автоматика и телемеханика». - 1991. Вып.13, - с.41, 42. - Режим доступа : http://is.ifmo.ru/works/switch_prr/
23. Шалыто А.А. Технология автоматного программирования // Мир ПК. - №10, 2003. - с. 74-78.
24. Шалыто А.А., Туккель Н.И. SWITCH-технология — автоматный подход к созданию программного обеспечения «реактивных» систем. // Программирование. - №5, 2001. - с.45 - 62.
25. Шалыто А.А., Туккель Н.И. От тьюрингова программирования к автоматному // Мир ПК. - №2, 2002. - с.144 -149.
26. Harel D. Statecharts: a Visual Formalism for complex systems // Science of Computer Programming. - Vol. 8, 1987. - pp. 231-274.
27. Антипова Е.В. Формальная модель сквозных переходов UML // Информатика и вычислительная техника: сборник научных трудов / под ред. Н.Н. Войта. - Ульяновск : УлГТУ, 2011. - 656 с. 37 - 42
