DRAKON.SU

Допустимы ли в Драконе такие схемы?

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

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

Ну, со второй как раз всё в порядке. Так может выглядеть, например, линейный поиск, когда перед проверкой условия надо что-то хитро посчитать.

Далее идут два исхода из цикла - "нашли" - "не нашли".

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

ДРАКОН - это не программирование в узком, это программирование в широком.
Т.е. он не только для программистов.

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

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

На плоскости можно явно выражать разные пути-исходы.

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

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

При сравнении структурного программирования и Дракона считаю нужным исходить из того, для чего вообще появилось структурное программирование. И лучше всего, как мне кажется, на этот вопрос отвечает следующая фраза:

http://it.kgsu.ru/Otladka/otl_0047.html

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


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

Не могли бы Вы привести пример доказательства правильности работы программы с использованием ДРАКОНа?

Для примера блок-схема вычисления факториала вместе с доказательством корректности из книги "The Craft of Programming" John C. Reynolds. Можно, конечно, перерисовать ее в виде Дракон-схемы, но изменения будут не очень большими.

Спасибо!

В принципе для не совсем структурных программ тоже можно привести доказательство корректности. Например, блок-схема из книги "Доказательство правильности программ" Р. Андерсон.