DRAKON.SU

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

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

Относительно "приписывания части свойств целого" - в /Паронджанов, 2001, с. 191-192/ говорилось, что кроме императивных знаний есть и другие, не содержащиеся в дракон-схемах... там был и Рис. 100 с первоначальной классификацией визуализируемых знаний (уточнена, напр. здесь).

А о каком самостоятельном примененении Вы говорите?

Кстати, на HiAsm очень похожа эта нотация

Кто бы, язык Дракон обновил, можно и реализовать.
Или язык Дракон расширить конструкцией "Дерево подзадачи".

Ну, тело циклов и так сбоку справа выносится.

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

Нужен когнитолог для экспертной оценки принципа построения блок-схем по Дамке.

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

В очередной раз: "Братва, не стреляйте в друг друга//Вам нечего больше делить" )
Илья же уже говорил о возможности развернуть силуэт в этом сообщении именно в дерево. Точно так же можно развернуть ДМ-схему на языке, определённом здесь - тогда и получится форма дерева процедур - только тогда и ветвлениями дерева считать также развилки. Также и код по маршруту между вставками, конечно, показывать надо - это когда визуал дракон-модели в терминах определения степени содержательности в этом подразделе является не полностью концептуализированным. У Прохорова в пи-схемах (Фиг.12 из автореферата) тот же принцип - только дерево строится иначе и последовательный код (операторные цепочки), насколько я могу видеть, текстом отображаются. Однако эргономичнее будет этот код изначально свёртывать также, как и вставки - заменяя, допустим, на абстракцию шампур-блока в виде вершины ОС6 по определению из этого пункта - а по щелчку раскрывать содержание. Но это всё вряд ли нужно считать частью ДРАКОНа - а как отдельный язык (конструкции которого создаются на основании дракон-схемы или дракон-модели) почему бы и не реализовать...
Кстати, пи-схемы, как я вижу, реализуют и визуализацию исключений и синхронизации - судя по видимой части алфавита... А на Фиг.16 у Прохорова вижу возможное решение по "диаграмме размещения" - т.е. структурно-топологическое представление реализации - актив-знание, взаимосвязанное с импер-знанием. Пи-синт-язык, видимо, это те же синтдиаграммы, только древовидные - как давнее предложение dvuugl по организации описания типов. Кстати, и это имеет свои корни - см. хотя бы изображение этой текстово-визуальной среды разработки для Паскаля (статья 1984-го года):
Здесь в окне Expression display (среднее внизу) можно увидеть всё ту же диаграмму синтаксического разбора выражения - очевидно, построенную автоматически. Кстати, рядом и фрагмент ГСА, причём вертикали, насколько можно видеть, упорядочены вправо. Так что опять "всё уже украдено до нас" А все основные возможности, продемонстрированные на этом виде, нужно реализовать и в современной среде разработки - если полагать, что она не самостоятельна, а выдаёт продукт для промышленного компилятора/верификатора, то тем не менее полезны и демонстрация областей видимости, и показ значений величин (конечно, по умолчанию, если среда сама не исполняет описания, а перекладывает это на промышленные системы), и исходный текст (на "нейтральном языке" в смысле, разъясняемом в этом сообщении) для текущей единицы реализации (если языком является Оберон - то модуля).

Возможно, скажу банальность.
Есть поговорка: "на вкус и цвет товарища нет", можно продолжить "на вкус, цвет и графическое представление алгоритмов товарища нет".
Дело в том, что большую роль играет привычка. Если человек привык использовать в своей работе блок-схемы, то его трудно будет заставить использовать Дракон, UML или другие диаграммы. Кто-то привык использовать Дракон и уже не смыслит, как вообще можно представлять алгоритмы по-другому, кроме как на Драконе.

Есть две концепций программирования, которые мне нравятся, и которые, как я думаю, могут решить многие проблемы связанные с надежностью программ:
1) Доказательное программирование (Дейкстра, Грис, Бейбер и др)
2) Пошаговое уточнение (Вирт и с некоторой натяжкой Кнут, с его концепцией грамотного программирования).

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

Циклы с условием в конце практически никогда не используются. Если такой цикл возник, то в большинстве случаев это признак, что что-то не так спроектировано в структуре алгоритма. См. базовую схему "полный проход" - подготовительное действие до цикла, затем цикл с условием в начале. Практически всегда так, кроме совсем примитивных случаев, где в цикле повторяется одно действие 1 или более раз.

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

Пошаговое уточнение позволяют видеть и пи-подобные схемы - тогда не нужно всё вправо выносить... А объединение выходов - это же получается возврат к шампур-схемам?

Добавьте "разработка через тестирование". Можно считать это дополнением к 2 - сначала напиши, как пользовать будешь, потом пиши код.

И.с. Drakon дорабатывается для формирования блок-схем по Дамке. Схема получила название вида - "Задача". В схеме дополнительно используются иконы: "ПодЗадача", "If", "While", "Until", "For".
Схема "Задача", выбрана и видны точки ввода. Сейчас отработаны вопросы: графика икон, ввод и удаление икон.

Какое будет ваше мнение?

Неплохо... Что касается конструкции "Задача".

Но я бы очень настойчиво советовал не делать выносок для циклов и условий. Это уже жуткая путаница.

Ведь до условия можно просто вставить Вашу "задачу" - а сбоку от неё прорисовать условие как обычно в ДРАКОНе.

В принципе схема нравится, но можно сделать еще лучше:
1) Тело оператора IF не должно быть на одном уровне с телом оператора UNTIL. Тело оператора IF должо идти до тела оператора UNTIL
2) Лучше если каждый уровень вложенности будет на одной вертикали для всех операторов. А для этого ветки IF лучше разместить не горизонтально, а вертикально.
Или же как вариант можно расположить ветки IF по разные стороны от ромбика.

А что-то подобное, видимо, и сделал Прохоров...

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

Нужно реализовать цикл Дейкстры - и там тоже есть над чем подумать при такой организации...

Да, а откуда на примере ведёт вторая вертикаль в нижнем ряду? Не видно, чтобы верхний конец был куда-то присоединён...

Некоторые идеи Дамке реализованы в проекте Logichart для PROLOG'а. Дано определение грамматики.
Для императивных языков:
Внутреннее представление H-code здесь:

Считаю, что скрывать код от самого себя не надо. (Если допустим написал программу, через пол года уже забыл как программа работает, а надо немного оптимизировать, открываешь схему, а там 3 прямоугольника, ну и ладно где здесь может тормозить. Открываешь первый прямоугольник, там несколько присваиваний, открываешь второй, там цикл, ну и ладно цикл и цикл, а открываешь еще, а там еще 2 уровния вложенности и того O(N^3))
Надо чтобы вся структура программы была сразу видна.

Работа по дополнению и.с. Drakon иерархическими схемами "Дерево" продолжена.
С некоторыми результатами можно познакомиться здесь.
Какие мнения будут?