Автоматное программирование: от таблицы к программе

Автоматизированное преобразование таблиц переходов

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

_1         char symbol;                    // Чтение потока символов неявное
           int cnt;
               . . .                       // Инициализация          _4 St1 _5
_1 St1 _2  'a'<=symbol && symbol <= 'z' _3 printf ("%c", symbol);
           cnt = 1;                                                  _4 St2 _5
_1     _2  //symbol <'a' && 'z'< symbol && symbol != '\n'
                                        _3
           //Так как нужно печатать только слова,
           //действий нет                                            _4 St1 _5
_1     _2  failure                      _3
           // symbol == '\n' не нужно читать                         _4 St3 _5
_1 St2 _2  'a'<=symbol && symbol <= 'z' _3 printf ("%c", symbol);
                                           cnt++;                    _4 St2 _5
_1     _2  //(symbol <'a'||'z'< symbol)&&*/ symbol!='\n'
                                        _3 printf (" - %i\n", Cnt);  _4 St1 _5
_1     _2  failure _3 printf (" - %i\n", Cnt);                       _4 St3 _5
_1 St3 _2  'a'<=symbol && symbol <= 'z' _3 printf ("%c", symbol);
                                           cnt = 1;                  _4 St2 _5
_1     _2  //symbol <'a' && 'z'< symbol && symbol != '\n'
                                        _3
           //Так как нужно печатать только слова,
           //действий нет                                            _4 St1 _5
_1     _2  failure _3
           // symbol == '\n' не нужно читать                         _4 exit_5
_1 exit_2  // условие истина, но без неявного чтения потока
                                        _3 return 0;                 _4     _5

Здесь <_i>, i = 1, . . . , 5 обозначают позиции таблицы. Эти сочетания символов, нигде в обычной программе не встречающиеся, легко могут распознаваться препроцессором. Размещаемые между ними последовательности символов разносятся по соответствующим полям нужной структуры, которая, в зависимости от выбранной стратегии, интерпретируется либо транслируется. С помощью этих сочетаний осуществляется разметка текста, которая дает возможность распознавать и осмысливать его фрагменты. Стоит обратить внимание на то, что за счет специального взаимного расположения символов в данном тексте представляемая им таблица автомата вполне обозрима. Если нет более подходящего представления, то данную структуру можно рекомендовать для ввода.

Однако непосредственная интерпретация универсального текстового размеченного представления довольно затруднительна. Предпочтительнее, чтобы единицами интерпретации были бы сами поля таблицы. Вообще, этому противоречит наличие в таблице полей, значения которых - фрагменты исполняемого кода на языке программирования (такая запись удобна для человека, так как для заполнения таблицы не приходится прибегать ни к каким дополнительным соглашениям). На самом деле противоречие возникает только для поля действий, поскольку последовательности символов между <_2> и <_3> имеют ясно выраженную семантику: это проверка условия. Если всегда рассматривать условия как проверку того, чему равен входной символ, то вполне понятны, легко задаются, распознаются и интерпретируются специальные обозначения: перечисления значений, их диапазоны и т.д. Трактовка этих обозначений не вызывает осложнений, а потому подобные приемы кодирования применяются довольно часто.

Если говорить о полях действий, то их представление для большинства языков программирования плохо разработано. Данное обстоятельство препятствует использованию автоматного программирования: кодирование действий усложняет обработку. Но если в языке можно задавать подпрограммы как данные, то описание структуры таблицы, которое будет согласовано с дальнейшей трансляцией или интерпретацией, возможно, в частности, в языках функционального программирования (семейство LISP и ML) и в языке Prolog. Но функциональное и сентенциальное программирование хорошо интерпретируют лишь частные случаи таблиц.

Пусть тип T_StructTableLine описывает структуру одной строки таблицы, а вся таблица представлена в виде массива Table таких структур. Пусть далее iSt - переменная, используемая для индексирования массива Table, некоторые из ее значений представляют состояния конечного автомата (но не все, а только те, к которым определен переход!). Наконец, пусть

int handler ( int );

-обработчик строки (ее интерпретатор или транслятор), <понимающий> структуру T_StructTableLine, специфицируемый как функция, при выполнении которой должно быть определено очередное значение iSt. Значение iSt, не указывающее ни на какую строку таблицы, служит сигналом для завершения обработки (при желании можно заняться кодированием того, как завершилась обработка с помощью задания различных таких значений).

Тогда схема программы, которая оперирует с таблицей с помощью функции handler, может быть задана следующим циклом:

iSt = 0;
do     {
    iSt = handler ( iSt );
       }
while ( OUTSIDE ( iSt ) );

Понятно, что выбор массива в качестве представления автомата непринципиален. Допустимо, а иногда и предпочтительнее, работать со списком строк. Также непринципиален способ вычисления предиката OUTSIDE, проверяющего условие окончания цикла, хотя он и зависит от выбранного представления автомата. Возможность не рассматривать явно имена состояний, напротив, принципиальна: тот факт, что строки таблицы сгруппированы вокруг (поименованных) состояний, ничего не значит ни для обработки, ни для интерпретации, поскольку у конечного автомата следующее состояние всегда определяется явно.

Логика функции handler, интерпретирующей таблицу, проста. Для правильной таблицы, не содержащей состояний, в которых возможны неопределенные переходы, она строится следующим образом:

1. Извлечь значение Table[iSt] ;
2. Активизировать вычисление условия обрабатываемой строки таблицы;
3. Если условие истинно, то
   • активизировать подпрограмму действий;
   • читать очередной символ;
   • завершить handler со значением, извлекаемым из поля следующего состояния;
4. Если условие ложно, то
   • iSt++ ;
   • Перейти к 1;

Осталось предусмотреть детали для заключительных состояний, но это сделать уже легко.

Таким образом, нужно научиться описывать структуру строки таблицы. На языке C++/С# эта задача может решаться довольно просто:

struct T_StructTableLine
{                            
    // поле для имени состояния избыточно
    int (*condition)();     // поле условия
    void (*action)();       // поле действия
    int ref;                
    // поле перехода: индекс строки таблицы,
    // которая будет обрабатываться следующей,
    // или признак завершения процесса
}

Сама таблица описывается следующим образом:

T_StructTableLine Table[]

или

T_StructTableLine Table [Размер таблицы]

если значения строк задаются вне этого описания.

Однако сразу же видно ограничивающее соглашение, которое пришлось принять в связи с особенностями языка реализации: все условия и все действия оформлены как функции, тогда как задача, по своей сути, этого не требует. Более того, отделенное от таблицы описание функций, предписываемое языком С++/C#, резко снижает выразительность представления:

int Cond_St1_1() - условие в Table[1]

и

void Act_St1_1() - действие в Table[1] (строка 1 состояния St1 );

int Cond_St1_2() - условие в Table[2]

и

void Act_St1_2() - действие в Table[2] (строка 2 состояния St1 );

и т. д.