Итак, на сайте появился еще один
новый автор! Как оказывается, в
Питере весьма популярно
использование конечных автоматов:)
Предлагаемая Вашему вниманию
статья Б.П. Кузнецова "Психология
автоматного программирования"
несколько отличается по характеру
от ранее опубликованных материалов
А.А. Шалыто и Н.И. Туккеля тем, что в
ней основной упор сделан именно на
основы. Поэтому, она представляет
интерес для тех, кто хочет изучить
принципы использования теории
конечных автоматов при решении
практических задач.
Следует отметить, что автоматное
управление действительно широко
используется при построении
специализированных цифровых
систем. Сам в свое время изучал
основы построения цифровых
устройств по книге Баранова С.И. "Синтез
микропрограммных автоматов". Но
вот как-то не задумывался о
последовательном формировании
последующих состояний из
начального. Обычно в голове
возникали одновременно несколько
разрозненных фрагментов, которые
потом и объединялись переходами. Да
и задачи, аналогичные
представленному примеру чаще
решались в лоб. Поэтому мне было
интересно прочитать о том, как
формируется граф конечного
автомата.
Вместе с тем хотелось бы
высказать и свое мнение по ряду
изложенных вопросов. Ведь кто-то
должен подбрасывать ложку дегтя,
чтобы сладко не было:)
Во-первых, не вижу особого смысла
использовать автоматы для
организации циклических программ.
Если уж отказываться от табличной
организации, то почему бы не
отказаться и от фиксации состояния
в переменной? Его можно прекрасно
фиксировать и местоположением в
коде, определяя соответствующую
метку. А вместо присваивания state = X,
где X - новое состояние,
использовать goto X. Вместо выхода из
цикла по флагу, я просто перехожу в
конечное состояние. Тогда вообще
никакой цикл не нужен, а замена
переключателя (switch) переходами
ускоряет выполнение программы. Я
пользуюсь таким методом при
разработке трансляторов
достаточно давно (с 1990 г.) и особых
проблем не испытываю. Предвижу
возражение: программа становится
неструктурированной. А зачем ее
структурировать, если основным
документом является таблица (граф)
переходов? Кроме того, разве
использование присваиваний вместо
переходов, хоть и внутри цикла while,
делает программу более
структурированной? Ведь чтение
написанного кода не совпадает с его
исполнением. Те же прыжки. Можете
сравнить авторский и мой варианты:
Было
Стало
static char state = ‘A’;
int cycle = 1;
while(cycle)
{
switch(state)
{
case ‘A’:
оператор YAB;
state = ‘B’;
break;
case ‘B’:
оператор ZB;
if(XBA)
{
оператор YBA;
cycle = 0;
state = ‘A’;
}
else if(XBC)
{
оператор YBC;
state = ‘C’;
}
else // if ( ! ( XBA || XBC ) == 1 )
{
оператор YBB;
// state = ‘B’;
}
break;
case ‘C’:
состояние C не_рассматриваем;
break;
case ‘D’:
состояние D не_рассматриваем;
break;
}
}
state_A:
оператор YAB;
goto state_B;
state_B:
оператор ZB;
if(XBA)
{
оператор YBA;
goto state_end;
}
if(XBC)
{
оператор YBC;
goto state_C;
}
// if ( ! ( XBA || XBC ) == 1 )
оператор YBB;
goto state_B;
state_C:
состояние C не_рассматриваем;
case ‘D’:
состояние D не_рассматриваем;
state_end: ...
Надеюсь, что в предлагаемом своем
варианте не наделал много ощибок.
Но думаю, что и в этом случае
основная суть достаточно понятна:)
Во-вторых, что операторы перехода,
что циклы и переключатели, что
таблицы - это все разные способы
реализации одной модели. Их столько,
что можно сбиться со счету и
сказать еще раз: Программирование
весьма разнолико! В конкретной
ситуации выбирается тот из них,
который больше подходит. Поэтому, я
не стал бы сбрасывать со счетов
табличный метод, сочетаемый с
предварительным получением
входного автоматного символа. Свои
достоинства есть и у образца State,
рассматриваемого в Design Patterns (Приемах
ОО проектирования от Эрика Гаммы и
товарищей:) Но следует
отметить, что сам процесс
разработки программы с
использованием конечных автоматов
представлен весьма наглядно. А раз
автор сам "напросился" в конце
статьи на заявки читателей, то хочу
попросить его провести сравнение
различных способов программной
реализации конечных автоматов:)
(:От такой наглости аж
сам вздрогнул:)
PS
Я надеюсь, что мои пространные
рассуждения в какой-то мере
компенсируют отсутствие
конкретных познавтельных
материалов. Получается так, что
статьи, публикуемые на сайте,
достаточно велики, чтобы их
воспроизводить в рассылке. А давать
только информацию о новых
материалах - суховато. Надеюсь
также, что мои комментарию несут
хоть какую-то познавательную
информацию. А авторам статей всегда
предоствляется ответное слово:)