DRAKON.SU

Согласен - и это не вопрос. Решается на уровне среды - д.б. команда "Развернуть всё <дерево>". А скрывать имеет смысл в ходе сочинения (если оно осуществляется через дерево) - чтобы сократить те участки, над которыми в данный момент не работаешь.

Уже говорилось, что ДРАКОН и не должен иметь самостоятельное применение, если ставится задача комплексного описания решения какой-либо проблемы - см. замечание Ильи в этом сообщении или /Паронджанов, 2001, с 183, п. Описание данных/ - там, правда, лишь общие соображения, а каково было конкретное решение - мы знаем по ФЛОКСу. Если нужно показать только алгоритм - то непонятны претензии - мы же не знаем, какие алгоритмы разрабатываются создателем техноязыка сейчас...

Возникает и вопрос: а в чём рисовать схемы такого вида, как в книгах Паронджанова? Для этого нужен специализированный редактор, поддерживающий по крайней мере и шампур-метод, и КогниСтиль... я такого не знаю на сегодня.
На возможное возражение, что можно отрисовать что-то в шампур-редакторе, а потом что-то "нафотошопить" на пэлобразе этой отрисовки в пикселграф-редакторе есть очевидное соображение - структура знания формируется целостно, и разрывать процесс оформления - значит, нагружать сочинителя "избыточной сложностью" - ему д.б. представлена возможность пользоваться всеми языками и методами визуализации в одной среде. Т.е. налицо отрыв от сути процесса сочинения - о чём говорил Валерий Лаптев : "...сначала напиши, как пользовать будешь, потом пиши код.".

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

При этом, как указывается, допустим, в /Акимов О.Е., 2003, с. 318/, для восприятия структуры её необходимо представить последовательностью (можно сказать, "сериализовать"), что производится средствами логики; естественной же формой здесь служит текст. В то же время:
Акимов О.Е. в download/file.php?id=1946 на с. 321 писал(а):
В процессе познания вещи часть знания приходится на понятия об этой вещи (функциональные элементы), а часть - на представления о ней (структурные элементы).
Этому и соответствует "графитное" представление хорошо формализуемой части предмета описания.

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

Как видим, многое нужно ещё от специализированного редактора, чтобы работать полностью в нём...

"Хвостов" не должно быть - какую бы форму не выбирали. Каждый маршрут должен приводить к своей вершине Конец (Останов). Пи-дерево в этом смысле понятнее.
А почему у вершин Вопрос стало по три выхода?

1. "Хвост" - терминология бытовая, не адекватная. В терминах теории графов - лист.
О формах листов, что можно говорить? Это, или икона без ветки на месте листа, или ветка(и) пустого блока (в этом случае помечены знаком ? критические точки ввода), или пустая ветка блока "Если".

2. Имеем дело с деревом. Если дошли до листа, то возвращаемся на уровень выше к узлу. Останова не происходит.

3. "Пи-дерево" - что такое не знаю. "В этом смысле" - в каком смысле? По принципу "бритва Оккама" новые сущности не привлекаем, руководствуемся описанием Дамке. http://forum.oberoncore.ru/viewtopic.php?p=52854#p52854

4. В данном контексте икона именуется "Если", имеет вход, имеет выход - если не является конечной на шампуре, имеет 2-е ветки Да, Нет - соответствующие then и else. Одна из веток может заканчиваться переходом (Goto, Break, Continue) - лианой или быть пустой. Возможно, надо предусмотреть переход - выход (Exit) в виде иконы "Конец".

Дополнено сообщение о прототипах в части визуализации императивных языков. Вообще, тему визуализации атрибутных грамматик японцы топчут с начала 80-х. В рамках исследовательских программ даже был создан учебно-методический комплекс HCode2 с использованием автоматического генератора HiTS.

По сабжу:
никакой альтернативщины в этом подходе нет. Просто, в отличие от реляционной грамматики(Дракон) используется атрибутная грамматика(HiTS, HCode2, HiCHART, LogiCHART). Противопоставлять их бессмысленно. Совместное использование этих грамматик возможно, но не всегда. Не всякая конфигурация, записанная с помощью атрибутной грамматики может быть транслирована в конфигурацию на основе реляционной грамматики. Для обратной трансляции, если не ошибаюсь, ограничений нет.

Противопоставление с Драконом не предполагалось, больше имелось ввиду - взаимное дополнение. Схема "Дерево" и схемы Дракона предназначены для представления алгоритма и можно сравнивать их по различным критериям.

Для расширения функциональных возможностей дорабатывается и.с. Drakon.
В основу разработки взята практика Дамке и В.Д. Паронджанова.
Нет привязки к конкретному языку программирования и предусматривает внимание на алгоритме в проблемной области.
В ваших ссылках использованы конкретные языки программирования с изменением формы записи.

К вопросу о трансляции. Среда Drakon предлагает хранение программных текстов в полях алгоритма и формирование шаблона текста программного кода модуля с реализацией модели конечного автомата.

- это сказано в отношении представлений графовой модели алгоритма с помощью различных визуальных грамматик. Рассматривать мои слова в контесте трансляции в программный код модели конечного автомата не стоит. Это совсем другая тема.

В любом случае, есть результат общего применения, а не разговоры на тему Дракона многие годы.

Уважаемый, я Вам что-то должен??? Вы уж скажите прямо, а то какими-то намёками сыпете. Я чесслово ниче непонял из Вашего последнего сообщения.

Рэйлвэй Каген

В "A Description of Hichart Program Diagrams for C" видим дерево, но нет следования по структурному программированию с входом сверху и выходом внизу.

Нет, это я оправдываюсь. Извините.

И какой вывод из этого? ("нет следования по..")

Продолжать заниматься самостоятельно делом, которое можешь делать.

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

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

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

Вот этот самый выход (без "да/нет") - он для чего? А куда может вести переход?

Просьба давать именно свои ответы - т.е. как у Вас реализовано.

Драконограф

О диссертации Прохорова есть в сообщении http://forum.oberoncore.ru/viewtopic.php?p=52888#p52888. В автореферате поиском не нашел упоминания о ПИ-дереве или просто дереве.

С нотацией ознакомится можно по книге Дамке, конкретная реализация будет в тестовом выпуске и.с. Drakon.

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

Да, полагаю, будет самостоятельный раздел в справке.

Спасибо.
Кстати, для контроля определений - под "развёрткой" маршрутного графа я понимаю то, что справа на этом рисунке:

Здесь развёрнут циклический алгоритм, причём показаны состояния вычисления в узлах. Конечно, это конкретизация при известных исходных данных, потому и маршрут один - для общего случая мы рассматриваем для каждого условия его альтернативы и в результате строится уже "дерево возможностей", где листами всегда будут вершины-терминаторы языка (Конец, а для Д2М-определения техноязыка - также и Останов).

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

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

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

P.S. Кстати, "по Дамке" нет необходимости в пересадках лиан именно за счёт дублирования кода, имеющего место при "развёртывании".

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

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

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