DRAKON.SU

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

А вот нифига. Ещё доказать надо, что это именно повторение. Причём даже самому себе, в процессе восприятия. Поэтому неизбежны огромные затраты мысленных ресурсов:
- на многократное повторное обозрение, запоминание и сравнение;
- на построение в голове ВСЕЙ модели целиком и безуспешные попытки удержать там же все связи (входы/выходы интерфейса выделенных участков), необходимые для понимания.

Вы меня сильно удивляете. Неужели Вы считаете, что общеалгоритмические соображения настолько зависят от задачи?!

А это что? Табу? Ярлык инакомыслия?

Если на одной чаше весов лежит "структурность", а на другой - лишнее повторение, то отнюдь не очевидно, что именно перевесит.

Структурность, имхо, бывает разная:
- та, которая обусловлена неадекватностью представления алгоритма;
- та, которая способствует ясному пониманию и грамотному проектированию.

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

Упущено самое главное - в задаче НЕ НУЖЕН переключатель. Как и автоматность с флагами и т.п.

Моё мнение: табу --- уменьшать объём за счёт уменьшения понятности (общее утверждение).

За конкретный алгоритм и его изображение на Драконе --- тут, по-моему ситуация из разряда "на вкус и цвет товарища нет". Неопределённая.

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

Естественно.
Так только ж Вы не оценили как раз эту самую понятность.

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

Так что работать всегда на минимуме желательно.

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

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

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

Ну-с, продолжим
Показан кусочек алгоритма обработки некоего прерывания.



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

Все вопросы успешно решаются, если отменить ограничение на пересечения.
Если же не отменять, то уж я не знаю, что делать...

Купить 3-D очки...

Как создаются религии:

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

Я тоже думаю, что в ряде случаев нельзя без пересечений.

Тут противоречие: в большинстве алгоритмов запрет на пересечения стимулирует лучшую их структурированность, но есть ряд ситуаций, где нет (где наблюдается равноправие маршрутов, и их никак не упорядочить).

Возможно, разрешить знак "переход на адрес" в середине схемы, чтобы не тянуть линию вниз, с пересечениями?

Не, это происки тупоконечников, нельзя же так!

У нас что - топология графа принципиально изменяется, что ли? Да нифига.
А что нас не устравивает? Исключительно отображение графа на плоскость.

Блин, да формулируйте же задачу, наконец! Исходя из эргономики, как основного критерия.
Какое там решение получится - с пересечениями или с разрывом, я не знаю. Исследовать надо.
Но вижу, что никто не решает ту задачу, которую действительно нужно решать, потому что она назрела уже давно.

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

Мне тоже кажется, что важна топология графа, а не планарность сама по себе. Можно просто ввести эргономический критерий - минимизация пересечений. Ну и правило, что более 1-2-х, например, пересечений в одной ветке - это признак очень плохой схемы, которую надо переделывать.

Не возьмусь говорить о "рисовании" алгоритмов, но вот базы данных "рисую" очень давно. Там тоже есть проблема пересечений связей между отношениями (ER-диаграммы). За полвека никто из "базовиков" не предложил хорошего решения. Используют два варианта, каждый из которых имеет свои плюсы и минусы:
1. Оставляют пересечения, как есть;
2. Дублируют сущность, связь с которой вызывает пересечения, в другом месте, где таких пересечений нет. Дубль помечают примерно так: RELATION: CUSTOMERS : 3. Цифра "3" означает, что это третий дубль.

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

Помимо общего между "рисованием" баз данных и "рисованием" алгоритмов есть важное отличие: схема базы данных не является орграфом, она, как правило, является... системой. Если попытаться представить, что существуют алгоритмы и... (динамические) связи между ними, то получим более системную модель. Но и она не избавит от пересечений.

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

Подозреваю, что когнитивная эргономика от пересечений зависит не так уж сильно

Критерий, на мой взгляд, правильный, а вот количественные оценки, я бы убрал. Лучше показать приемы, позволяющие снизить количество пересечений, чем... вешать ярлыки. IMHO.

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

Вообще говоря, автоматизации легко поддаётся
По крайней мере, не сложнее разводки печатных плат

Ну, например, откуда автоматике знать смысл веток, при рокировке развилок?

А человеку откуда?

Вот, к примеру, ветка А изображает самый частый путь (9 из 10 прерываний, например), а ветка Б - основную работу, которая, однако, выполняется 1 из 10 раз. Ну и как расставлять приоритеты?