Идея изложена здорово.Аналогия с выражениями - да, это и имел в виду под "рассказом". Само собой, формальным.Отсюда штуку вижу в том, чтобы проверять по стандарту синтаксиса. В общем, форм основных дать его две, наверное: РБНФ и синтдиаграммы. Эргономично, надо думать, второе. Тут такие вопросы возможны:

1. Синтаксис есть и в сообщениях о языках (о КомПас тоже, ессно). Но в некоторых случаях между отдельными правилами подразумевается какая-то связка (выбор обычно), не формализованная определением синтаксиса (т.е. через вхождения по РБНФ). Тогда это следует из текста сообщения. М.б. из-за того, что эти связки надо восстанавливать, и возникает ступор иной раз?..
Вот перечисляем нетерминалы по ИЛИ (текстовому, схематическому - неважно), а почему так или этак, объяснения нет или оно нечёткое.
Да и для терминалов по ИЛИ тоже эргономично было бы объяснить, по каким основаниям выбирается каждый из них...Важны также зависимости выбора в разных правилах, не подчинённых через вхождения. Скажем, от того, обозначен ли идентификатор как VAR, IN или OUT, кое-что ведь зависит... результат процедуры-функции м.б. не любого типа...

2. Бывает также недоопределение синтаксиса, тоже восполняемое разве что неформально. Так, синтаксис КомПаса проверил по "Искусству..." Потопахина (Приложение 4) - и обнаружил используемый, но не определяемый нетерминал StatementSequence... насчёт IdentDef надо догадываться (он только охарактеризован), что это вроде как ident, но в какой-то ситуации употребления... MethAttributes тоже вроде как не раскрывается...

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

Это об эргономике определения. Ваши описания - это, можно сказать, "синтаксические таблицы". Интересно и д.б. наглядно. Тут тоже главное каждое понятие объяснить и связать с другими, наверное...

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

А. Порядок проверки можно связать с предметом так, как наэтой схеме процесса. Как раз сказанное о наглядности синтаксиса выше будет уместно реализовать...
Тут видно, что тогда маршрутную часть схемы процесса (данная у Вас в нотации шампур-блок-схем) м.б. удобнее:
* организовать "полуторамерно" (подобно тексту программы), дабы лучше связывалось с предметной частью;
* записать в нотации структурных скобок, учитывая замечания Алмазовао циклахио минимализме выразительных средств.Оно так на схеме и сделано...

Б. Различные понятия, которые у Вас даются "вокруг" фрагментов проверки, можно организовать в словарь вроде представленных здесь:viewtopic.php?p=78188#p78188. Кстати, то, что словами - может, и правильно для школьников?..

В. Всю проверку можно представить как процедуру (систему процедур) по схеме из А. Тогда словарь можно даже считать "предметной переменной", передаваемой в эту процедуру...

И вообще можно попробовать изложить ООД как квазипрограмму на КомПас-подобном псевдокоде...В качестве предмета для проверки заодно...

Для иллюстрации кое-чего из сказанного:Вложение:Рисунки A3LS ГрафитСеть Описание ДАЛВЯЗ2 (текущий).pdf[231.91 КБ]
Скачиваний: 614
- здесь как раз пример определения понятий и их использования. Ну и некоторые возможности таких схем были вэтом документе.

Может, чего и сгодится...