DRAKON.SU

С точки зрения когнитивной эргономики один плюс - всё сосредоточено на одной схеме. Жа и тот плюс не очевиден.
То есть я хочу сказать, что:
- использование переключателя для такой цели (фактически - декларация методов объекта) не считаю удачнымю Потому что перепутываются конструкции алгоритмические со структурно-декларативными;
- сам элемент "Переключатель" имеет неэргономичную форму (много лишних РАЗРОЗНЕННЫХ деталей).

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

Лучше сделать более адекватный способ визуального представления.

Не могли бы Вы поподробнее объяснить про "более адекватный способ визуального представления"?

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

Но просто достаточно очевидно, что один имеющийся Дракон пихать во сферы только потому, что он есть - неверный подход.

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

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

Давно работающее уже есть. UML, BPWin, IDEFы, куча всякоразных под задачи «только для себя» и т. д. и т.п.


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


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


Жаль, что «годную эргономику» (похоже Вы знаете, что это такое) от Вас я не увижу.

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

Не согласен, причины несогласия изложил...

Если б знал, писал бы книги, как Паронджанов, и соответствующий продукт разрабатывал

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

В целом согласен с Алексеем.
Некоторые мысли:

1) Линии на твёрдых копиях м.б. неодинаковыми так, как и положено в ЕСКД - блоки основной толщины, связи - тонкие. Также играем цветом - но, как я думаю, прежде всего не графики, а содержания.
На видеограммах, безусловно, можно больше разнообразить форматирование...

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

3) Что делать с силуэтом - наверное, лучше Александр Сергеевич знает... вот только спрашивать его надо не здесь... и не так, как иногда делается... в стиле кавалера "Большого креста германского орла" (типа: "Вы же согласны, что тачка м.б. любого цвета при условии, что этот цвет - чёрный?")...

Ну, теперь к конкретике.
Ну, начинали-то Вы с этой задачи... не прибедняйтесь... имею в виду, что на Вильяма-то нашего Шекспира замахнулись... у которого акторы и каждый не одну играет роль... в т.ч. и совместно-параллельно...
И вот, как помните, я говорил, что непонятно. А теперь понял... именно потому, что вы перешли к последовательному исполнению. Что стало очевидно:

1) Данное расширение языка имеет ту же область оптимальной применимости, что и исходный технооязык - представление импер-составляющей для случая с единственной РТ. Именно потому изначальное приложение к "Задаче на перспективу" и вышло таким - для многих РТ оптимально не получается. Причины лучше изложил Алексей в той же теме.

2) В расширении Вы фактически подошли к дейкстралу со стороны "автоматчиков" (и Info21) - через эмуляцию вложением LOOP(CASE) - подобно ЦС у Дмитрия_ВБ. Луп у Вас - это "пустой" цикл ДЛЯ, кейс - вложенный силуэт специального вида. О том, что ЦД не есть лучшее средство для представления логики программы как системы, говорил Усов здесь... И это в любом случае представление для единственной РТ...

3) В качестве преимущества указывается генерация вроде как востребованных отчётов (текстовых выборок-вьюшек) по схеме. Тут замечу, что это для любой схемы обязательно - и хорошо, что Вы об этом подумали (конечно, если выработаны однозначные правила генерации - не вникал). Но. Нужно всегда помнить о "том неявном, что есть в тексте" - да и вообще в любом отдельно взятом представлении любого объёмного предмета. Так, взаимодействие исполнителей фактически д.б. представлено отдельной схемой "соединений по вводу-выводу" - так наглядней (можно делать по принципу ДМ-схем, можно своё выработать). Не зря в ЕСКД разные типы схем (и не зря Рэйлвей Каген предлагал "не впадать в программизм" )...

смотрите на него, как на развёртку вырожденного тора. И ненавистные разрывы исчезнут!

Да пожалуйста. Только любая развёртка по определению содержит разрыв
И визуально он никуда не пропадает, как ни смотри...

Схема-пример (отсюда)


та же схема в другой нотации

Ага, только это будет уже не ДРАКОН... а комплексная нотация...

Чтобы комплексность не была "с-ложной" - можно было бы ограничиться принципом операторных схем - только с вариантами, как сказано здесь (в п. 1): viewtopic.php?p=75098#p75098. В предположении, задаваемом подходом Усова, что переход между действиями определяется получением нужного результата труда - вьюшка будет вполне подходящей, думаю... в конкретных случаях...

Вот такая схема (описание здесь)

с учётом замечания

вот в таком исполнении: