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