DRAKON.SU

Предлагается некоторое исследование автора касательно возможности использования ДРАКОНА в современных распределенных системах.

СОДЕРЖАНИЕ
Алаверды Дракону 1
Оглавление 2
Предисловие 3
Введение 4
1. Может ли быть маршрутный язык ДРАКОНа декларативным? 5
2. Может ли другой язык быть лучше ДРАКОНа в понимании алгоритмов и программ? 9
3. Можно ли ДРАКОН совмещать с другими когнитивными языками? 17
4. Что у ДРАКОНа должно быть на выходе? 18
5. Какие сферы применения можно обозначить? 23
6. Какие нужны связи между языками? 24
7. Какие возможности расширения? 29
8. Есть ли другие формы представления данных? 30
Выводы 31
Список литературы 32

Дмитрий, очень интересная работа, свежий взгляд, глубокий реальный опыт, спасибо!

(Есть предложение эту статью в wiki, в раздел ДРАКОНа).

Вы обрисовали вариант развития отрасли отечественных CASE-средств на годы вперёд. Есть, над чем подумать, есть над чем работать.

Уважаемый Дмитрий!
Вот такие соображения:
1. Не трактовать ли взаимодействие "оператор-машина" как систему совместно протекающих алгопроцессов - допустим, как здесь?
2. Что подразумевается под "единообразным представлением всех данных" на с. 17?
3. Имеется ли в виду под комплементарными ДРАКОНу языками то, что сказано на этой странице? И когда на с. 7 Вы говорите, что задача получения кода (видимо, прогтекста) по блок-(дракон-?)схеме "не решаема, ибо для неё нужны ДАННЫЕ" - имеете ли Вы в виду, что нужно декларировать величины и типы алгоритма, скажем, как показано в этом примере - и, возможно, дать модель реализации программы (исполнителя кода)? И что имеется в виду на с.7 - "если не программа, а процесс, то нужен не код на процедурном языке, а что-то другое"? М.б. это опять подразумевается инструкция человеку-исполнителю процесса (см. вопрос 1)?
4. Следует ли в свете сказанного в этой классификации и в п. 2.2.1 этой работы, что схемы такие, как на Рис.17-19 - это не иные формы представления алгоритмов (импер-части знания о задаче), а взаимосвязанное представление исполнителей этих алгоритмов (актив-части)?
5. Если говорить об "электронном проекте" - не следует ли рассматривать его через призму "трёх схем информатизации задачи", допустим, так, как описано здесь и в связанных источниках? Что не отменяет языков диалога пользователя (да и взаимодействующих технических систем) с "электронно проектируемым" приложением - а также и визуализации кода самого приложения (текстово существующего, допустим, на языках Оберон-семейства), на каждом из уровней иерархии. Как Вы относитесь к тому, чтобы "электронный проект" имел вид единой системы документов, подобных описанному здесь и в связанных источниках?

Уважаемый Драконограф!

1. Для АЭС там целые труды по человеко-машинному взаимодействию. Я же эти проблемы не рассматривал, брал существующие графические схемы как данность.
2. По стр.17 "единообразие всех данных". Берем дерево Рис.9 и берем к нему текст на узлах - формулы. Если у Вас поменяется графическое представление, как в примере с Рис.11,12 с экспертной системой, Вам придется взять другой редактор и все переделать. А если поменяется текст, вы можете легко подправить в текстовом редакторе, либо использовать псевдо-язык, либо переконвертировать автоматически эту логику.
3. И да, и не только. Комплементарность - это дополнение, внесение новых свойств, не зависимых от предыдущих языков.
В описании ДРАКОНа я предложил убрать двусмысленность. Декларативность пусть останется как определение данных.
Языки же - пусть будут процедурными и непроцедурными(а не декларативными хотя бы в этой теме).
Данный алгоритм:
"остановись, подсвети по результату формулы и жди ввода оператора"
Объект, реализующий алгоритм, написан на непроцедурном языке (плюс оболочка с компилятором байт-кода).
Для объекта "Остановить ключом АЗ" это выглядит так:
A-0//1.1 dp an_hy016hla24 an_hy017hla24 -- это декларации переменных
A-0//1.1 check {expr {$an_hy016hla24 || $an_hy017hla24}} -- это ожидаемое действие
A-0//1.1 goto A-0//1.2 -- это переход дальше
Так вот, алгоритм системы выполняет "expr {$an_hy016hla24 || $an_hy017hla24}"
До тех пор, пока не изменится переменная процесса или пока Вы не скажете выполнено (т.н. override). Тогда, правда элемент фиксируется красной подсветкой. По следующему шагу - загрузится A-0//1.2
4. Я показал, что маршрутный алгоритм может превратиться в непроцедурные знания. Это означает, что в Вашей классификации граница между императивными и декларативными знаниями размыта.
5. Я писал, что электронный проекты, разработанные зарубежными компаниями, уже внедряются. Применительно к АСУТП есть САПР из 5 языков МЭК с единой БД.

Илья!

Спасибо, если что-то интересное найдете, используйте и ссылайтесь. Можно и в wiki, я сам не разработчик языка, а предлагаю лишь взгляд со стороны.

2. А чем должен отличаться другой редактор, что нельзя переделать в прежнем? Легко работать с текстом - "литератору" по складу ума; "живописцу" (эйдетику) легче работать с графикой. Техноязык и разработан как комплементарная чистому инфор-тексту (напр., программному) форма - где маршрутная часть из текста переведена в граф-схемы. В том и другом случае за описанием стоит одна и та же модель структуры (ряд соотносимых моделей) - допустим, абстрактное синтаксическое дерево - поэтому такая замена и возможна. Думаю, так.

3. В чём двусмысленность ДРАКОНа (м.б. и шампур-метода вообще)?
Непроцедурный, как я это понимаю - значит, неисполнимый на "информатической машине" - модельной (напр., тьюринговой) и реальной. Посему и ПРОЛОГ-описание (часто называемое "программой") в конечном итоге исполнимо на этой "машине" как программа, получаемая применением к этому описанию алгоритма трансляции (напр., разбора дерева вывода) Или нет?

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

5. Да наверное, таких САПР уже не одна... если посмотреть "СТА" даже, возникает такое представление Главное - чтоб был когнитивно-эргономичный подход - при фиксации частных языков разработки (напр. стандартами МЭК) он применяется только к собственно проектному документу (в частности, чтобы "техноименам" показанного у Вас вида давались "эргоимена", несколько более человекочитаемые ).

Да, в исходном посте у меня под №4 стоял другой вопрос - по блочному представлению как неимперативному и недекларативному (а в ЮМЛ-семействе приблизительно соответствующему языкам "реализации" - только у Поликарповой и Шалыто решение, IMHO, целесообразнее) - интересно Ваше мнение...

Уважаевый Драконограф!

2. В экспертной системе вы начали с ДРАКОН-схемы, а закончите fuzzy logic (http://www.apmath.spbu.ru/ru/staff/pota ... fuzzy.html).
3. Двусмысленность не ДРАКОНа, а определения декларативности
И про ПРОЛОГ Ваш пример хороший - не разберешь, программа это или данные
4. Вы не можете сказать, является ли алгоритм, скажем закалки кинжала в теле раба, данными или программой.
5. Да, много. И много еще осталось.

Схемы Рис.17-19? Это - экземпляры объектов. Объектно ориентированного ДРАКОНа. Или супа из текстового языка, ДРАКОНа и логических схем FBD.

2. Это точно как один из альтернативных "разбору деревьев логического вывода" методов алгоритмизации недетерминированно поставленных задач.

3. Именно поэтому я оставляю "декларативному" только смысл "представимый через абстрактные типы [данных]". Декларации же в смысле непроцедурной информатизации (как ПРОЛОГ) отношу к обобщённому информатически формальному знанию о задаче. В соответствии с иерархией моделирования/формализации по Фридланду, уточнённой на этой странице. Т.е. это допрограммная (хотя уже и информатическая) модель.

4. Это тоже к вышесказанному - это программа для исполнителя, который в своём множестве предписаний (у Паронджанова - репертуаре) имеет названные "именами действий", присутствующими в текстах визуала, и в своём множестве объектов деятельности ("багаже") - названные именами объектов в том же тексте. Это уже разбирал применительно к "детской книге" - см. в этом сообщении (прежде всего к §§2,6). Чтобы отличить это даже в "родном" техноязыке (для исполнителя-человека) - я и предлагаю разный формат имён действий и объектов. И получается то, что описано, в частности, в этом подпункте. Есть замечания к такому поодходу?

Уважаемый Драконограф!

4. Есть ли возражения? Есть. В Вашем примере:
"Текст иконы записывается либо как императивное предложение, либо как присваивание;"
"Получить Деталь М080 из Заготовки 021 согласно операционной карте А135 на рабочем месте 9" - это неформальное предложение
либо
"ДетМ080 := КартаА135(Загот021; РМ9)" - а это уже программа.
Та же программа на выходе.

Я же предлагаю (стр.20)
ДЕЙСТВИЕ "X = [КартаА135 Загот021 РМ9]" "Получить Деталь М080 ..."
Это - строка псевдо-языка. Он сгенерился из ДРАКОНа. После обработки интерпретатором можно получить хоть С, хоть Oberon, хоть данные на XML.

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

P.S. Да, тут по ООП вообще глубокие обсуждения возникают - взять хотя бы эту тему. Да и Свердлов кое-что в связи с Оберонами добавляет в этой книге.
Вообще визуализация объектной парадигмы, по сути, интересно проведена в IDEF1X-методологии (в принципе относящейся к типу "сущность-связь" в роду обобщённо-информатических, а традиционно предназначенной для описания схем БД). Вкратце о её языке здесь; указанный там стандарт доступен здесь. Можно отметить, что создатели обошлись из понятийного аппарата ООП наследованием; полиморфизм передан через роли наследуемых атрибутов (кстати, именно точечные записи имён - главный повод отказаться от принятого Паронджановым их формата); инкапсуляция - сокрытием невнешнеключевых атрибутов. По вопросу уточнения понятий ООП высказывался интересно Илья - см. в этом сообщении и рядом в теме.

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

Первое - "о содержании". И то, и другое - это программа, только разной формальности сообразно природе исполнителя-адресата. Оператор, закодированный "именем действия" А135 - это в том и в другом случае один набор разных описаний деятельности. Для человека - комплект ЕСТД-документов по данной операции, для машины - допустим, программа УЧПУ. И то, и другое м.б. визуализировано (на своих диалектах графит-языка). Если описываем операцию только для человека (ручная работа) - программы нет. Если только для машины - только программа (но это в специфических случаях для ограниченной части решения задачи - напр., работа самонаводящегося управляемого снаряда после старта - а до старта, как мы понимаем, человек очень даже участвует в решении и такой задачи ). Типичный же случай - автоматизированный - работа СЧМ (пример - тот же контроль датчиков).
Понятно, что таких комплектов в расчёте на разные свойства системы-исполнителя можно подготовить не один. А по форме любого такого комплекта - см. выше.

Спасибо, добавил статью в Вики:
http://oberoncore.ru/wiki/drakon/start# ... 1%80%D0%B0
в категорию "Рецензии".

Ещё к вопросу о связи классификаций в другом аспекте. Что можно понимать под "размытостью"? То, что в реальной схеме, которую можно отнести к одному частному роду (скажем, к императивному - в визуале) тем не менее присутствует знание и другого рода (имена величин). Но это - не размытость, а проявление целостности реальных вещей - любое подразделение которых будет несколько искусственным (об этом хорошо говорил alexus в различных темах конференции).
Можно ли получить описание "чистого рода"? Да, можно. Конкретно если взять визуал - то исключив неимперативный текст. Получим схему "деятельности вообще", где имена действий абстрагированы от их объектов (предметов и результатов труда). Развитие этого - литеральная запись, вводимая Паронджановым. Если пойти дальше - можно вообще убрать разметку вершин - получим абстрактную импер-шампур-схему. Но относительно целей практической визуализации это будет не разумной абстракцией, а идеалистическим отрывом от сути.

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

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

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

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

И как пример - сказанное в "Алаверды..." о кадрах интерфейса оператора в не-драконовском представлении никак не отрицает такой возможности - просто это не тот тип знаний о задаче, который нужно представлять на техноязыке. Это как раз деклар-знания (при всей их "алгоритмичности") - которые передаются из машинной части оператору как значения сообщений - передающие же процессы (как и процессы, формирующие эти кадры) как раз описываются на импер-языке (техноязыке/псевдокоде). То же относится и к работе оператора - она представляется как совместно исполняемая с машинной. При визуализации их связь "по пульту" можно представить операторами взаимодействия типа Д25, 25Д, Д3/25, Д14/25, 3/25Д, 14/25Д, Д26, Д15/26, 21Д, 15/26Д, Д31, Д32, 32Д по определению Д2М-языка здесь. Естественно, алгоритм работы оператора и машины будет разным. Кто кого сопровождает и отслеживает - показывается языковыми средствами выражения взаимодействия процессов.
Текстовая реализация зависит от связанного инфор-языка - если язык без таких операторов, как Оберон, то представляются через процедуры, описанные Виртом (см., выдержку в этом сообщении), если язык типа Promela (описание см. в этом сообщении) - то там такие операторы в основном есть.
Кроме того вид этих кадров - это часть спецификации ("внешней схемы" задачи) - частью "нейтральной схемы" (инструкции оператору + машинные программы) будет порождающий код (написанный, допустим, как показано у Коутса и Влейминка - или через вызовы уже написанных библиотек аналогичного назначения).

И спецификация, и программа подчиняются введённой иерархии представления задач - являясь координатами ортогонального ей измерения "по горизонтали". Естественно, "электронный проект" должен содержать описание и того, и другого - в целостности и взаимосвязи.

В связи с этим и сказанное о стандарте МЭК61499, увы, наводит на мысль о приблизительности его трактовки систем. Всё то же самое ЯВС-метод предлагает формализовать более естественно - за счёт целостного взгляда авторов прежде всего. Между прочим, если посмотреть /Поликарпова, Шалыто, п. 2.2.1/, то они определяют параметры актив-схемы (называя её "структурой") в общем так же, как Вы на с.24. По такому же принципу я определял графит-актив-схемы (см. ту же задачу контроля датчиков).
И "неоптимальная, мягко говоря, система организации и управления как производством, так и разработкой ПО", вообще-то во многом порождается именно подходом, когда "новые технологии не ВМЕСТО старых, а ВМЕСТЕ со старыми" - когда эти старые "избыточно сложны", то новые обычно могут только наворотить новые уровни этой сложности (Илья говорил об этом в своём докладе о программной инженерии).

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

Уважаемый Драконограф!

1. Мое понимание изложено. И аргументация представлена.
2. И вы, и сообщество может не принимать во внимание. И тем более не принимать это как руководство к действию. Я никого не заставляю, лишь даю взгляд со стороны.
3. В это время другие системы уже реализованы на языках блок-схем (всех пяти из 61131) и будут внедряться повсеместно. Можете не бороться, если хотите остаться при своих подходах.

В добавление.

ООП. В части ООП я ожидаю, что сообщество разделяет подходы Вирта (Programming in Oberon). Я писал свои предложения полностью в рамках этих подходов. Не нужно слишком мудрствовать.
"Дракон-схема - это не структура данных". Дракон-схема - это структура данных. И использую эту структуру данных из блок-схем программно (например, печатаю из нее инструкции в виде HTML). Даже если Вы с этим не согласны.

Уважаемый Дмитрий Викторович Дагаев!

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

Чувствуется. что Вы прекрасно разбираетесь и в программировании,
и в электрических и логических схемах аппаратуры, и в многосложном
хозяйстве АЭС, связанном не только с реакторным и турбинным
отделением, но и с системой насосов, трубопроводов и различных
подсистем АЭС.

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

Ваше исследование -- ценнейший подарок для меня. Я очень
рад, что Вы сделали такой щедрый подарок.

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

Изумительные иллюстрации, представленные на страницах
Вашего исследования, делают его понятным и еще более ценным.

От всей души благодарю Вас за Ваш грандиозный труд.

Я разумеется, не во всем согласен с Вами.
Но сейчас я не хочу говорить о раличии во мнениях.

Сейчас я хочу задать совсем другие вопросы.

Какие у Вас планы?

Собираетесь ли Вы опубликовать Ваше ценнейшее исследование
в виде статьи в журнале? Или в виде доклада на конференции?

Может быть, Вы планируете превратить статью в книгу
и опубликовать ее?

Может быть, Вы хотите развить эту тему и превратить
ее в диссертационную работу?

В любом случае желаю Вам огромных успехов.
Я от всей души поддерживаю Вашу работу.

С огромным уважением
Владимир Паронджанов

Уважаемый Дмитрий Викторович!

Я поместил ссылку на Ваш материал в Википедии в статье
ДРАКОН (алгоритмический язык) в секции Ссылки.

Если я что-то неточно написал, поправьте, как считаете нужным.
URL http://ru.wikipedia.org/wiki/%D0%94%D0% ... 1%8B%D0%BA)

Уважаемый Владимир Даниелович!

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

Алаверды, как правильно отметил Илья Ермаков, - документ в стиле рецензии. Там действительно есть набросок концепции. Но в силу формата документа это сделано "галопом по Европам". Более того, мне недавно удалось приобрести Вашего "Мудреца". И я проникся стилем Гнома, попытаюсь улучшать свое изложение.

В работе есть проект документа "Как запустить Дракона". Если в Алаверды речь шла об анализе Дракона, "как поставить на землю", то предполагается проект: "как запустить в небо". Те же самые системы, что в Алаверды, но проекте реализации. Предложения прояснить принимаются.

Для меня главным является опубликовать концепции. С надеждой раскрутить что-то реальное. Просто один из прожектов. Я еще до конца не решил, буду ли заниматься публикациями, скорее всего, заброшу так же на форум. Буду ли этим заниматься дальше, тоже не знаю. Хорошо, если кто-то почитает, может подхватит знамя.

Дмитрий, подумайте, пожалуйста, над тем, не подготовить ли Вам публикацию на очередную конференцию "Объектные системы", мне кажется, это был бы очень интересный материал для неё:
viewtopic.php?f=86&t=2693

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

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

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

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

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

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

Естественно, полноценный редактор должен поддерживать разные подходы. Практически для данного случая это означает реализацию FBD-языка в качестве как императивного, так и активностного.