Мартыненко Б.К. Синтаксически управляемая обработка данных. Изд. 2-е, дополн
Подождите немного. Документ загружается.
261
Рис. П.21. Вид контекстной справки о внешнем дисбалансе.
Наконец, после закрытия окна с сообщением о внешнем дисбалансе
появляется предупреждение о деффектности построенных управляющих
таблиц (рис.П.22).
Рис.П.22. Окно с предупреждением о деффектности таблиц.
Разумеется, управляющая таблица прямого просмотра может использоваться
для процессирования (и ее имеет смысл оптимизировать) только тогда, когда
функция
Balance не обнаруживает вышеупомянутого дефекта.
Функция Backward pass реализует построение управляющей таблицы
обратного просмотра. Это необходимо, если предполагается челночная
обработка (в управляющей грамматике имеются семантики обратного
просмотра).
Во время выполнения этой команды на экране находится окно статуса с ин-
дикацией степени завершенности процесса. По ходу построения этой таблицы
проверяется семантическая однозначность входного языка относительно се-
мантик обратного просмотра. Если эта проверка проходит удачно, о чем Поль-
262
зователь извещается сигналом Success в окне статуса, на выходе образуется
файл с текущим именем и расширением .bp, содержащим двоичный код
управляющей таблицы обратного просмотра. В противном случае в окне
сообщений выдается диагностика обнаруженной ошибки.
Функция Minimize выполняет оптимизацию управляющей таблицы
простого или челночного процессора в зависимости от того, построена ли
только таблица прямого просмотра
170
или построена также и управляющая
таблица обратного просмотра
171
. В первом случае появляется диалоговое окно
с предупреждением о том, что управляющая таблица обратного просмотра не
существует, и запросом, требуется ли оптимизировать один только прямой
просмотр.
Наиболее тяжелым этапом оптимизации является построение отношений
эквивалентности на множествах состояний и магазинных символов. Поэтому
предусмотрены возможности прерывания этого процесса и его продолжения в
другое время. Для прерывания следует нажать клавишу Scroll Lock.
В этом
случае выдается файл с текущим именем и расширением .fpr, который
содержит частично построенные отношения. Он используется при
возобновлении процесса оптимизации
172
.
После того, как процесс оптимизации благополучно завершается, о чем
пользователь извещается сигналом Success в окне статуса, в текущем каталоге
(или другом каталоге, выбранном для управляющих таблиц) появляются файлы
с текущим именем и расширениями .mfp
и .fcl, содержащие оптимизированную
управляющую таблицу и классы эквивалентности входных символов,
состояний и магазинных символов прямого просмотра, а если
оптимизировались управляющие таблицы челночного процессора, то
появляются также и одноименные файлы с расширениями .mbp
и .bcl,
содержащие оптимизированную управляющую таблицу и классы
эквивалентности входных символов и состояний обратного просмотра.
Генератор диагностических сообщений автоматически готовит коллекцию
диагностик, которые используются во время процессирования, когда на входе
процессора обнаруживаются бесконтекстные синтаксические ошибки
173
. Он
запускается при помощи команды
Diagnost/Generate, когда управляющие
граф-схема и таблица прямого просмотра уже построены, т.е. существуют фай-
лы с расширениями .grh, .fp, и, может быть, .mfp
и .fcl. При этом, если опти-
мизированных таблиц прямого просмотра не существует, в диалоговом окне
будет запрашиваться, требуется ли генерировать диагностики для неоптимизи-
170
В этом случае существует файл с текущим именем и расширением .fp.
171
В этом случае существует также файл с текущим именем и расширением .bp.
172
Которое следует начинать после запуска подсистемы сразу с команды Minimize.
173
Контекстные синтаксические ошибки диагностируются другим, но тоже встроенным в процессор, механизмом.
263
рованного процессора. Если же файлы с расширениями .mfp и .fcl существуют,
диагностики будут безоговорочно строиться для оптимизированного
процессора. Во время генерации диагностик на экране находится окно статуса
с индикацией степени завершенности этой задачи.
Результатом работы такого генератора являются два файла с текущим
именем и расширениями .dgn и .pos. Первый из них содержит коллекцию
диагностик, а другой — список синтаксических позиций в правилах
управляющей грамматики. Этот второй файл необходим при редактировании
диагностических сообщений "на фоне" управляющей грамматики.
Редактор диагностических сообщений может быть полезен в том случае,
когда желательно использовать нестандартные описания ошибочных ситуаций
или несколько вариантов сообщений объединить в одной обобщающей
формулировке. Он может быть запущен командой
Diagnost/Edit после того,
как диагностики в стандартной форме сгенерированы. По этой команде
открывается окно редактора диагностик, вид которого показан на рис. П.23.
Рис. П.23. Вид окна редактора диагностических сообщений.
Оно состоит из двух частей: верхней, в которой можно просматривать
правила управляющей грамматики, и нижней, в которой экспонируются
варианты диагностических сообщений. Один класс эквивалентных состояний
может включать несколько состояний, а одному состоянию может
соответствовать несколько синтаксических позиций (вершин управляющей
граф-схемы). Вариант сообщения относится к одной позиции одного состояния
одного класса эквивалентности состояний. Результатом редактирования будет
новая версия файла с расширением .dgn.
Генератор тестов (прототестов) обеспечивает автоматическую генерацию
(прото-) теста заданного уровня для тех нетерминалов грамматики,
загруженной в окно редактора, которые отмечены пользователем (рис. П.24).
264
Рис. П.24. Вид диалогового окна генератора тестов
с отмеченными нетерминалами.
Уровень теста задается в диалоговом окне (рис. П.25), открывающемся по
команде
Options / Tests, которую следует выполнять перед запуском генератора.
Рис. П.25. Вид диалогового окна задания режима генерации теста.
Генератор листингов производит выдачу документов по проекту одной
трансляции, спецификация которой находится в окне редактора. Состав
документов, включаемых в листинг, устанавливается пользователем в
диалоговом окне, открывающемся по команде
Options / Listing (рис.П.26). В
этом же окне задается размер страницы (в строчках) и направление вывода
листинга: в файл (и тогда его можно просматривать по команде
Listing/View)
или непосредственно на принтер.
265
Рис. П.26. Окно настройки содержания листинга.
Общий порядок использования компонент. Как уже отмечалось,
подсистема проектирования обеспечивает удобную среду для подготовки
синтаксической части спецификации трансляции, ее редактирования и
построения управляющих граф-схем, управляющих таблиц, их оптимизации,
построения и редактирования диагностических сообщений периода
процессирования, генерации тестов, а также получения отчетных документов
по всем этим составляющим проекта трансляции.
Стандартный порядок работы в среде проектирования представлен рис.П.27.
На схеме двойными прямоугольниками показаны функциональные блоки,
двойными стрелками отмечен порядок их использования, одинарными
закругленными прямоугольниками обозначены информационные файлы, а
одинарными стрелками — потоки данных. Функциональные блоки
маркированы именами соответствующих пунктов главного и дополнительных
меню подсистемы проектирования, из которых они включаются в работу
174
.
Как показывает схема, процесс проектирования трансляции состоит из ряда
этапов, выполняемых в определенной последовательности.
Этап 1: подготовка спецификации трансляции. Прежде всего в окне
редактора должна быть подготовлена спецификация трансляции. По крайней
мере, должна быть написана управляющая грамматика.
Этап 2: построение управляющей граф-схемы. С помощью
функционального блока GRAPH/ Create строится управляющая граф-схема.
Если функция GRAPH/ Create обнаруживает ошибку в управляющей
грамматике, то после ее исправления (в окне редактора) попытка построить
управляющую граф-схему должна быть повторена.
Этап 3: проверка приведенности управляющей грамматики. После того, как
управляющая граф-схема построена, открывается возможность проверить ее
приведенность посредством технологической компоненты GRAPH/Check.
Если грамматика оказывается неприведенной, то об этом сообщается
пользователю, который должен в этом случае исправить управляющую
грамматику и повторить предыдущий этап проектирования. Эту проверку
следует проводить, если предполагается строить управляющие таблицы
процессора.
174
К схеме прилагается краткая расшифровка обозначений.
266
GRAPH / Create − генератор управляющих граф-схем
GRAPH / Check − проверка приведенности грамматики
TAB / Forward pass − генератор управляющих таблиц прямого просмотра
TAB / Balance − проверка внешней балансировки
TAB / Backward pass − генератор управляющих таблиц обратного просмотра
TAB / Minimize − оптимизатор управляющих таблиц
DIAGNOST / Generate − генератор
диагностических сообщений об ошибках
DIAGNOST /Edit − редактор диагностических сообщений об ошибках
TESTS / Generate − генератор (прото-) тестов
TESTS / Edit − редактор тестов
LISTING / Create − генератор отчетов по проектам трансляции
LISTING / View − просмотр отчетов на экране компьютера
Рис. П.27. Общая схема использования подсистемы проектирования
технологического комплекса SYNTAX.
Этап 4: построение управляющей таблицы прямого просмотра. После того,
как управляющая граф-схема получена, она используется функциональной
компонентой TAB/Forward pass для построения управляющей таблицы
прямого просмотра. Функция TAB/Forward pass анализирует управляющую
граф-схему, и если она не удовлетворяет всем необходимым условиям, выдает
диагностическое сообщение о характере нарушений. В таком случае нужно
внести требующиеся изменения в управляющую грамматику и снова повторить
этапы 2–4.
Этап 5: проверка условия внешней балансировки. Когда управляющая таб-
лица построена, следует проверить, удовлетворяет ли она условию внешней
балансировки. Для этого необходимо воспользоваться функциональной компо-
267
нентой TAB/Balance
175
. Если получено сообщение о нарушении этого
условия, нужно изменить управляющую грамматику и повторить все
предыдущие этапы снова. Пример такого рода сообщения показан на рис.П.19.
Этап 6: построение управляющей таблицы обратного просмотра. Если в
управляющей грамматике используются семантики обратного просмотра или
предполагается наблюдать синтаксическую структуру входных цепочек,
необходимо воспользоваться функцией TAB/Backward pass для построения
управляющей таблицы обратного просмотра. На этом этапе может быть
обнаружена семантическая неоднозначность относительно семантик обратного
просмотра, и тогда требуется внести необходимые изменения в грамматику и
повторить все предыдущие этапы с самого начала, т.е. с построения
управляющей граф-схемы.
Этап 7: оптимизация управляющих таблиц. После того, как управляющие
таблицы построены, их следует оптимизировать посредством функциональной
компоненты TAB/Minimize. Впрочем, от оптимизации можно и отказаться.
Например, в том случае, когда хочется иметь более точную диагностику
ошибок периода процессирования или предполагается наблюдать
синтаксическую структуру входных цепочек.
Если построена только управляющая таблица прямого просмотра, то
система запрашивает, действительно ли требуется минимизировать только
прямой просмотр, и в случае положительного ответа пользователя
производится оптимизация таблицы прямого просмотра. Если же построена и
управляющая таблица обратного просмотра, то производится совместная
оптимизация управляющих таблиц обоих просмотров. Практика показывает,
что оптимизация, как правило, дает значительную экономию памяти.
Заметим, что все формальные ошибки проектирования к моменту
выполнения этапа 7 уже устранены. Поэтому на этом и всех последующих
этапах никаких ошибок проектирования не диагностируется.
Этап 8: генерация диагностик периода процессирования. Диагностические
сообщения генерируются посредством функциональной компоненты
DIAGNOST/Generate. Причем к ней можно обратиться сразу после построения
управляющих таблиц прямого просмотра или после их оптимизации.
В первом случае сгенерируются диагностики, рассчитанные на использова-
ние при процессировании под управлением неоптимизированных таблиц.
Во втором —
они годятся лишь при процессировании под управлением
оптимизированных таблиц. Рекомендуется строить диагностики в двух
вариантах, чтобы во время отладки можно было оперативно переключаться с
одних таблиц на другие.
Например, если захочется посмотреть на синтаксическую структуру входной
цепочки, придется использовать прямой и обратный просмотр с
неоптимизированными управляющими таблицами.
175
Если грамматика явнорегулярна, такая проверка излишня.
268
Этап 9: редактирование диагностик периода процессирования. Если
желательно отредактировать автоматически сгенерированные сообщения об
ошибках, то следует воспользоваться технологической функцией
DIAGNOST/Edit. Это может потребоваться, если, например, при генерации
диагностик использовался шаблон вида “В ... после ... ожидается ...” ,
требующий подгонки окончаний диагностических терминов для согласования
их с установленным шаблоном.
Этап 10: генерация оптимального прототеста возможна сразу после
построения управляющей граф-схемы при помощи функции TESTS/Generate
176
.
Этап 11: редактирование прототеста. Для построения исполнимого теста,
исходя из полученного прототеста, можно воспользоваться технологической
функцией TESTS / Edit
177
.
Этап 12: генерация отчета по проекту трансляции. В любой момент можно
получить отчет по готовой части проекта трансляции, если воспользоваться
функцией LISTING/ Create. Его можно просмотреть на экране компьютера при
помощи функции LISTING/View, если листинг был направлен в файл. По
выбору пользователя он может быть также выдан на печать.
3. ПОДСИСТЕМА ПРОЦЕССИРОВАНИЯ
Подсистема процессирования включает средства для подготовки и
редактирования спецификации микролексики, описания операционной среды,
генерации микролексических классов для штатного транслитератора и
компиляции операционной среды, а также для компоновки действующих
SYNTAX-приложений из составляющих их компонент. К ним относятся
транслитераторы, параметризуемые микролексическими классами, и
управляющие процессоры (конечные или сплайновые, простые или челночные,
анализирующие или порождающие), параметризуемые управляющими
таблицами, диагностическими сообщениями и операционными средами.
Подсистема процессирования обеспечивает также благоприятную обстановку
для наблюдения за работой готовых средств СУОД в процессе их
тестирования, предоставляя возможность протоколирования и потактового
исполнения на любых уровнях процессирования. Подсистема запускается
командой
Process [Name.grm], где Name.grm — имя файла некоторой TSL-
спецификации
. По этой команде появляется заставка, вид которой показан на
рис.П.28.
176
Однако надо иметь в виду, что при этом контекстные условия не учитываются, даже если в спецификации
трансляции используются резольверные символы. Учет контекста при генерации тестов — дело дальнейших
исследований.
177
Пока эта функция не реализована.
269
Рис. П.28. Вид заставки подсистемы процессирования.
После сброса заставки клавишей Esc, открывается панель этой подсистемы,
включающая три основных элемента управления: полосу меню, собственно
поверхность панели и строку статуса (рис. П.29).
Рис. П.29. Вид панели подсистемы процессирования.
Если в команде Process был указан параметр, то в эту панель вставляется окно
редактора, содержащего указанную спецификацию (рис. П.30).
Рис. П.30. Вид панели подсистемы процессирования
c TSL-спецификацией калькулятора.
270
Если TSL-спецификация не была загружена при запуске подсистемы
процессирования, т.е. в команде
Process не был задан параметр, то это
необходимо сделать при помощи команды
General / Load processor, так как в
любом случае работа над конкретной TSL-спецификацией возможна лишь
после ее загрузки в окно редактора подсистемы. Одновременно с этим
подсистеме процессирования открывается доступ к соответствующей
управляющей граф-схеме.
Система меню и режимы работы. Здесь мы приведем полный перечень
всех команд среды подсистемы процессирования со спецификацией их
назначения.
Подсистема процессирования может находиться в одном из двух
функциональных режимов:
1)
режиме подготовки процессоров к работе,
2)
режиме отладки.
Режимы работы отличаются друг от друга перечнем допустимых команд. Но
некоторые команды, например команды из разделов меню About (
≅), Edit,
Options Edit и Options Window, доступны для использования в обоих режимах.
В режиме подготовки доступны команды из разделов General и Preparation,
позволяющие провести полный цикл подготовки к работе процессора или
комплекса процессоров, составляющих данное SYNTAX-приложение.
Перечень операций этого цикла описан далее.
В режиме отладки открывается доступ к командам из разделов Data, Run и
Debug основного меню, которые инициируют запуск подготовленного
SYNTAX-приложения и предоставляют средства отладки, имеющиеся в
интегрированной среде подсистемы процессирования.
Раздел About (Ё) — чисто информационный. Он содержит команду About,
выбор которой влечет появление диалогового окна с информацией о версии
подсистемы процессирования (см. рис.П.31).
Рис. П.31. Информация о версии подсистемы процессирования.
Раздел General. Команды раздела General (рис. П.32) предназначены для
загрузки спецификации трансляции, ее сохранения после редактирования, а