Переход от данных к конечному автомату

* * *

Только что решенная задача, разумеется, является модельной. На практике подобные задачи приходится решать в основном в частных случаях (например, игнорируются пересечения слов, вместо подсчета числа вхождений может потребоваться другая обработка). Дополнительные условия существенно влияют на выбор подхода, но применение метода динамически порождаемого автомата — это хорошее решение с точки зрения эффективности, наглядности и автономности.

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

Анализ предложенной двухэтапной схемы (построение автомата и его применение), показывает, что естественный метод реализации первого этапа — алгоритм, который на концептуальном уровне следует отнести либо к стилю сентенциального программирования, либо к рекурсивному варианту структурного. В качестве языка его реализации примерно одинаково адекватны LISP, Рефал и Prolog. В то же время адекватный стиль реализации второго этапа — автоматное программирование. Таким образом, разделение стилей требует в идеале применения двуязычной системы программирования. К сожалению, сугубо технические трудности сопряжения двух языков (упомянем только одну из них: согласование представлений данных) часто приводят к тому, что разработчики предпочитают моделирование стиля. И это порою прагматически обоснованное решение, особенно если систему не придется развивать дальше. Но если это потребуется, лучше один раз преодолеть технические трудности^{1И занести соответствующие приемы в свою базу технологических решений для использования в других подобных ситуациях.}, зато в дальнейшем работать концептуально продуманно. Хорошим примером здесь является система Autocad, языком для преобразования планов в которой служит расширение языка LISP.

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

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

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

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

Конечно, приведенная трактовка объектов не всегда адекватна. Более того, в задачах, которые неестественно решать данным методом, она оказывается вредной, противоречащей, например, взгляду на объекты как на активные единицы программы. И это обстоятельство отмечает границы сочетаемости объектно-ориентированного стиля и метода таблиц переходов.

Применительно к конкретной задаче о длинах слов объектно-ориентированное задание автомата возможно, но для решения вопроса об автоматизации перевода табличного представления в программное само по себе оно ничего не дает. В схеме с функцией handler двойственность программ и данных по-прежнему затрудняет построение и интерпретацию.

Убийственно для представления "живых" таблиц переходов объектами то, что, хотя число объектов и их связи могут изменяться динамически, новые действия в них уже не вставишь, поскольку весь конечный набор допустимых действий определяется статически при описании типов объектов в программе.

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