DRAKON.SU

Всем доброго времени суток!

При пересадке лианы маршруты можно расположить разными эквивалентными вариантами.

На Рис. 1 исходный алгоритм. На Рис. 2 один вариант расположения маршрутов. На Рис. 3 — другой вариант.

На нижнем изображении те же схемы, но однотонные. Чтобы внимание не отвлекалось.

Вопрос: какой из вариантов более эргономичен, симультантен или как там правильно по научному?
Очень хотелось бы услышать ваше мнение.



P.S. Схемы реально получаются большими
Вот эти три схемки занимают формат А3, при том, что ширина икон 2 см, высота 0.5 см, высота текста 6 единиц (название не помню), самого текста нет, примечаний и других излишеств тоже нет.

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

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

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

Не могли бы Вы представить правильный вариант?

А если через переключатель?

По смыслу ведь три условия подряд - это и есть переключатель в чистом виде.

Тогда рис.2. приобретёт нормальный вид, действия по вариантам выбора будут на одном уровне, и всё будет не в пример понятнее!

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

Вот подумалось, если лиана в точку вставки пересаживается из внешнего контура, то вариант Рис. 2, а если из внутреннего контура, то вариант Рис. 3.

Конечно, можно. Но здесь я пытаюсь рассмотреть не алгоритм, а возможные формы его представления.
Вот сидит проектировщик, мыслит, вставляет иконы, пишет. Ему нужно сделать пересадку лианы. Он указывает одну точку, вторую - и редактор делает переключение маршрута. И как-то должен это отобразить.

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

Всё там правильно; а изображаться по правилам В.Д. должно, как во втором варианте (смыкаемся всегда влево).

Ну так он с самого начала намыслил неправильно.
У него был стопудовый переключатель, а он его в линию развернул.
Смотреть надо в корень!

Спасибо. Как-то это правило мимо меня проскочило : )

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

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

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

Собственно, вопрос был не об алгоритме, а о его визуальном восприятии.

Да, точно!
Вот и ответ насчёт визуального восприятия. Я воспринял как кривой переключатель

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

p.s.: Если уж раскрашивать шампуры, то самый правый на рис.3 д.б. весь одного цвета. Когда за счёт объединения частей разных шапуров образуется новый шампур, логично перекрасить его. Цветовой разнобойчик правого шампура на рис.3 как-то не способствует восприятию смысла. Если попробовать рокирнуть верхнюю развилку(уже писали выше), то сохранять раскраску от старых шампуров(до пересадки) будет вообще нелогично.

Здесь цвет использовался только для того, чтобы было видно куда переместились иконы после пересадки лианы. И только.
Внизу я специально дал схему без раскраски.

Как указывать место, в которое будет производиться внедрение иконы?

Точки на схеме - это артефакты конструктора. В окончательном варианте их, конечно, не должно быть.
Но даже при их отсутствии схемы всё равно получатся большими.

В книжке по UML прочитал, что схемы умещающиеся на формат меньше А2 - баловство одно : )

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

О, а у Вас свой редактор есть?
И, если есть, какие изменения в синтаксисе Дракона применяли, кстати?

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