Итак, что обнаружилось в старых (и нечитанных - с позиции Усова, очевидно, правильно  ) постах по этому топику - может, будет интересно.
Насчёт нелинейных маршрутов - для циклов обозначено, что нужно бы представлять явно: viewtopic.php?p=14738#p14738. Итак, идею представить цикл как "виток спирали", кою заложил в свой вариант языка структурных скобок (показано на этом примере), Донской уже предлагал.
Читаю тему дальше - и вижу, что там реализована и мысль Прохоренко отсюда: viewtopic.php?p=14784#p14784. Ну вот, очередной велосипед изобретён... 
И вот давайте попробуем сделать так же в графовой записи... хорошо ли получится?..
Теперь от циклов перейдём к ветвлениям (множественным): ... Могу только сказать, чего не хватает:
- описания структур данных;
- описания неалгоритмичексих знаний;
- по мелочам... например, очень бы хотелось видеть автоматизацию анализа всех возможных ситуаций выбора. Это косвенно (через эргономику) влияет на сложность модели. Вот, например, табличное представление алгоритма (те же таблицы решений, таблицы состояний и т.п.) реализуют если не анализ, то хотя бы визуальное представление всех возможностей выбора, которые описать наскоком через if then else (а хоть бы и через case!) не получается и не рекомендуется во избежание ошибок. Некоторые компиляторы (особенно функциональных языков), напротив, обеспечивают автоматическую проверку полноты определения вариантов, но текстовое представление для человека здесь не оптимально (текстовый язык из вполне понятной экономии не содержит требования обязательного указания всего массива вариантов, т.е. пропущенных мест просто не видно, в отличие от таблицы). В Драконе имеем то же, что и в тексте - пропущенных вариантов не видно.
... - опять есть вопрос к графовой записи, как видим.
Замечу, что решения есть. Как первоначальное - всегда подставлять в кейс вариант "любое другое" (сочетание значений величин из списка фигурирующих во всех условиях ветвления). Указано ещё в Драконографике для схемно-техноязыковой формы записи здесь. Редактор может делать автоматом (с пустым телом варианта), подставляя и список величин/значений. Дабы сочинитель не забывал, чего наваял... Как детализирующее в графовой форме - "кейс по кейсам" с полным перебором вариантов, о чём писал здесь: viewtopic.php?p=64668#p64668. Тоже можно реализовать составление в редакторе - автоматом и/или по команде (тоже недоопределённые варианты с пустыми телами).
Разумеется, оба решения не зависят от формы записи. Но надо смотреть - а как лучше с таким "полно-переборным" описанием работать - в тексте? таблице? на графе?..
...
Имеем проблему: текст программы не похож на алгоритм. Между тем, алгоритм с блок-схемы типа ДРАКОН один в один списывается в ассемблер. Ассемблер более точно записывает алгоритм.
С этим не могу согласиться никак. Возьмем тот же пример - конструкцию if then else. По своей алгоритмической сути она имеет две равновесные ветки. Заметим, что переходов здесь никаких нет, есть только выбор пути. Сравним:
- что бы кто не говорил по этому поводу, табличное представление наиболее точно и беспристрастно отображает суть данной конструкции;
- графическое представление (ромбик со стрелками) также отображает точно, но имеет особенности (облегченное восприятие человеком и, вместе с тем, неоднозначность синтаксиса - да/нет и влево/вправо);
- Дракон чуть пытается улучшить графическое представление путём невнятной и противоречивой рекомендации располагать да/нет "в порядке предпочтения";
- текстовые ЯВУ типа Паскаля, оставаясь точными по сути, вносят искажение по форме, чем затрудняют восприятие человеком (как любая плоская картографическая проекция искажает глобус). Ну, и синтаксис усложняется соответственно;
- ассемблер делает две гадкие вещи, обе в порядке внесения дополнительной, лишней, не нужной для алгоритмической сути, сложности: а)добавляет понятие перехода (условного и безусловного), б)вносит жёсткую, аппаратно обусловленную асимметрию (во всех известных мне процессорах инструкция условного перехода сами знаете как выглядит и нсколько она похожа на алгоритмический ромбик со стрелочками).
... - да, проблему имеем... И решение было - уж года два с лишним тому. В частности, как результат обдумывания, как в графах лучше записать вывод "теоремы о переписываемости"... И тогда же было очевидно, что переход - следствие ассемблера внешне, а глубинно - модели памяти... и вот здесь та самая "мерность" играет... если видеть её отдельно и от формы записи, и от структурности...
И тут тоже можно сущность перехода использовать... если подумать... ну, об этом Вы теперь в курсе...
Да и сама мысль Прохоренко от формы записи не зависит. А за ней стоит то, что переходы безусловные, на метку (как средства реализации нелинейных конструкций в линейной записи) бывают таких типов:
* структурные - с общей точки ветвления на общую точку слияния маршрутов в направлении по следованию для выбора и против для цикла;
* полуструктурные - сохраняют структурное направление, но их начало (для циклов) или конец (для досрочных выходов из процедуры - тоже начинаемых по сути через ветвления, явные или скрытые) не совпадают с общей точкой;
* неструктурные - произвольно направлены, не связаны с ветвлением. Первые представлены ключевыми словами структурных конструкций. Отсюда и необходимость читать даже структурный линейный текст алгоритма "скачками". Заметим, что exit в loop также можно считать структурным БП.
Вторые - break/continue, return.
Ну, третьи - goto. Сюда же относятся и допвходы в процедуру, когда они не понимаются как вызовы (т.е. без переключения контекста и пролога). Ну и такие же выходы.
А с учётом наличия восстановления контекста (и эпилога) при выходе из процедуры мысль Сергея о разнице с выходом из нелинейных конструкций, возможно, следует уточнить...
Ну и в целом те сжатые рекомендации, которые были здесь: viewtopic.php?p=14729#p14729 - видимо, по-прежнему актуальны.
В итоге, наверное, эти тезисы:...Вот правильные тезисы:
- любая модель должна быть формализована, и формальный язык всегда вносит определенные ограничения (соответственно, добавляет сложность);
- во главу угла я ставлю эргономические вопросы (частным случаем которых являются вопросы экономические). С этой точки зрения всегда возможен оптимальный выбор инструмента;
- в подавляющем большинстве случаев ассемблер менее эргономичен, чем все другие инструменты (хотя бывает и по-другому, но редко и в специфических задачах);
- к сожалению, эргономичность всех нынешних инструментов оставляет желать лучшего. И я желаю улучшить их на порядок! (с этой точки зрения разница между ЯВУ и ассемблером далеко не так велика).
... можно применять при определении, какие языки нужны в редакторе...
|
