DRAKON.SU

Уважаемые участники!
Думаю, теперь стоит вплотную заняться моделированием объектов деятельности. Это направление (буду называть его датаматизацией - по аналогии с алгоритмизацией) периодически всплывало на конференции в разных темах, но всегда в связи с программированием. В то же время оно и более широко по назначению, и ранее вводится в процессе формализации знаний. Нижесказанное будет, наверное, очевидно для большинства, но фактически деклар-моделирование идёт параллельно с импер-моделированием и точно так же нужно не только для информашины, но и для человека. И нужен деклар-полиязык, построенный по принципам ДРАКОНа; считаю нужным основывать его на обобщённом опыте создания технологий ГРАФИТ-ФЛОКС и ДРОН. Эдуард Ильченко поднял важный вопрос об отражении параллелизма процессов, и хотя мнения о его разрешении сложились разные, развитие дискуссии уже вселяет некоторую надежду, что этот "Треугольник будет выпит//Будь он параллелепипед//Будь он круг, едрёна вошь" ) Думаю, отработка языка представления объектов будет не лишней и для этой цели - чтобы визуализировать те структуры/элементы данных, которые обеспечивают блокировку, например. Дабы не гнать сплошной текст, более конкретные соображения даю далее в отдельных сообщениях.

В своё время dvuugl предложил расширение интерпретации дракон-схем, которое более развёрнуто обсуждалось здесь. Есть такое мнение относительно этого. Если рассматривать представление содержания объектов средствами техноязыка как развитие языка синтдиаграмм (предполагаю, что мы с другими участниками понимаем его сущность одинаково), то синт-силуэт также читается от начала к концу для порождения представляющего текста (последовательности элементарных объектов), только содержит не неопределённые (как в синтдиаграмме), а конкретные условия ветвлений и циклов, что и нужно для информатизации такого представления (т.е. сведения к конечному, детерминированному и выполнимому до целесообразного результата).

Цикл ДЛЯ в таком понимании представляет итератор числа вхождений тела цикла подряд в содержание объекта. Икона Действие имеет смысл жёсткого поля, также вводится икона для гибкого поля (напрашивается Вставка, но она тоже нужна в своём обычном значении, см. ниже); остальные шампур-иконы не используются.

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

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

Разумеется, возможен и синт-примитив - топологически прямой аналог синтдиаграммы, только как бы повёрнутый на 90 градусов по часовой стрелке.
Идея обратного поворота уже высказывалась в этом сообщении, но применительно к импер-схемам; в той же теме можно увидеть критику её для этого случая, с которой соглашусь. В то же время для синт-схем такой поворот м.б. полезным; в частности, синт-силуэт тогда будет описывать текст, где ветки будут отвечать строкам на страницах (а иконы БП получат смысл знаков "начало/конец строки/текста", уточняемый их содержанием).
Такого рода диаграммы вводятся для формального описания отдельных значений; это пригодится, скажем, для контроля правильности значений в ходе исполнения. Структуру же данных следует представлять деревом, как это предлагал Я. Романченко; для создания языка, когнитивно эквивалентного ДРАКОНу, нужны дополнительные условия (см. следующее сообщение). В дерево данных могут входить и обращения к диаграммам.

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

Р.S. Поправил ссылки

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

Прежде всего, нужно определиться с типами схем языка и вершин. В алфавите блок-схем по ГОСТ мы имеем по сути наряду с императивным также декларативный подалфавит графоэлементов (также будем называть их иконами). По логике, он отражает классификацию объектов, перечисляемых в тексте иконы, по формам представления, а сами объекты привязываются к некоему процессу (процессам); эта логика воспроизведена мною в языке схем данных. Эти схемы выражают внешнюю т. зр. на данные (как они должны представляться для целей потребителя решения).
Предложение Романченко, видимо, требует назначения графики икон по базовым (предопределённым реализацией) типам, напр.: числовой, литерный, логический; также вводится икона исходного (в т.ч. базового) типа, через который раскрывается тот или иной производный (как икона Вставка в импер-языке или блок Гибкое поле в синтдиаграммах). Здесь уже отражается классификация объектов по внутренней структуре. Образуется система схем-деревьев, связанных отношениями "исходный-производный". Эти схемы выражают внутреннюю т. зр. на данные (как они представляются для целей исполнителя решения, оперирующего только с базовыми типами и конструкциями из них).

В обоих типах схем употребляется общее множество имён типов величин (объектов). Также используется общий язык атрибуции величин (таблицы Романченко); при этом некоторые атрибуты заполняются только программистами для подготовки законченной версии проекта к кодогенерации. На этом же языке описывается формат структур данных во внешней памяти (как я понимаю, этот принцип использовал Тышов в описании формата файлов типа *.drt).
Логичным дополнением к схемной графике также является описание символической формы сложных объектов (скажем, экранных и печатных форм документов) в виде иллюстраций. За правила их создания логично принять нормы стандартов документации, соответствующих предметной области (ЕСКД, УСОРД и т.п.).

С дракон-схемами схемы данного языка связаны через употребление описанных типов при описании объектов (величин) в командном тексте. Также в иконах Ввод и Вывод указываются формы отображения/регистрации, а в иконах Запоминание и Вспоминание - форматы массивов внешней памяти (типы файлов).

Дочитал Свердлова до теории трансляции и увидел идею помещения алгоритмов на синтдиаграммы в качестве вершин (там они называются семантическими процедурами и обозначаются как треугольники); по сути, это форма предложенного здесь. В общем это закономерно, т.к. синтдиаграммы всё-таки следует относить к средствам обобщённой (начальной) формализации, так же, как по-видимому, и языки визуальной схематизации (подобные ГРАФу; кстати, и у них есть текстовые предшественники, об одном см. в этом сообщении).

Попробую пояснить своё вИдение данного направления в сфере формализации на конкретном примере. Возьму пример из работы Грабина, рассмотренной в этом сообщении с позиции технологии производства.
А если "вернуться к нашим баранам" т.е. к деклар-знаниям, то видно, что метод Грабина предполагает ещё и планирование структуры изделия (продукта) так, чтобы оптимально разделить его на части, создаваемые независимо - именно тогда можно совместить ряд процессов в каждой фазе полного ЖЦ изделия.

У самого Грабина это планирование прослеживается гл. обр. за пределами приведённого отрывка - здесь лишь упоминается "...широкое применение типовых схем, унификация как отдельных узлов, так и групп механизмов по принципу подобия..." (с. 447), "...творческая база в виде перспективных типовых схем как изделия в целом, так и отдельных механизмов и "командных" деталей." (с. 449). Однако и этого достаточно.

При материальном производстве разработчик знает структуру изделия "в наглядных образах", и по мере накопления опыта формирует закономерности оптимального структурирования и технологизации; но ему в этом помогает и наглядный "язык техники" - чертёж. А структуры данных (или предметных областей) как объекты создания м.б. весьма сложны, и их формализация требует наглядного языка не менее, если не более настоятельно.

А если нет общего языка формализации деклар-знаний? Тогда имеем как раз один из ключевых факторов ситуации, которую Грабин преодолевал три четверти века назад в своей области - разобщённости конструктора и технолога. Тут один импер-язык, даже самый передовой, не поможет - не согласовав вИдение структуры объектов и отношений, состава и значений атрибутов, не спроектировать действия над ними оптимальным образом - а равно эксперт-заказчик, не понимая, что за структура объектов спроектирована для машинной части деятельности и как она воплощена в машине, не сможет оценить её и предложить изменения.

Конечно, эксперту нужно знать языки деклар-формализации и её основы - но тут мы опять сталкиваемся с необходимостью когнитивно-эргономичного представления деклар-знаний - если будем учить расписывать объекты и отношения предметной области на текстовом языке ООП или БД, умственные возможности человека будут расходоваться неэффективно. Недаром уже предлагается новый открытый формат файла описания для дракон-сред (ТФАП у Дмитрия_ВБ)...

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

Предлагаю проект набора атрибутов в табличной форме для некоторых типов.

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

На примерах здесь и здесь показан подход к визуальному представлению деклар-знания - т.е. сущностной структуры описываемой задачи, предметной области - в информатизованном виде. Видно, что он отличается от принятого при визуализации в распространённых "визуальных средах". Хотя такая организация выбрана интуитивно, можно указать её рациональные основания - см. в этом подпункте. По сути, обосновывается язык абстрактных типов (АТ).

Пример неоднородных отношений - определения неатомарных типов абстрактными АТ-схемами. Два таких определения даны ниже:


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

А можно ли в абстрактных схемах использовать ОС-узлы И, как в конкретных? Да, можно; для этого надо задавать варианты синтаксиса также, как в текстовой записи — на метаязыке. Мы можем использовать графит-РБНФ-знаки согласно п/п 1.3.1.4 в этом пункте; пример их употребления см. выше на абстрактной АТ-схеме проекта (описывающей структуру общей АТ-схемы). Также возможно накладывать на схему графит-ограничители с РБНФ-индексацией; пример см. в этом сообщении.

Основываясь на изложенном здесь об абстрактных типах, составлены АТ-схемы некоторых КП-программ из книги В.В. Потопахина, обсуждаемой в этой теме.
Результаты см. в этом примере.
Ещё одну КП-программу выберем для иллюстрации графит-АТ-моделирования прогтекстов с реальными процедурами и сложной компоновкой (рекурсией и импортом). Исхтекст и визуализация деклар-части приведены в этом примере.