DRAKON.SU

В примитиве иконы «Адрес» и «Ветка» не используются. Используются иконы «Узел расщепления» и «Узел сбора». Ведь никого не смущает, что иконы «Действие» и «Формальные параметры» практически одинаковы.

А я считаю, что именно в примитиве параллелизм имеет все шансы закрепиться. Сравните:

Примитив
Силуэт
Примитив чуть посложнее
А теперь представьте, на что будет похож силуэт этой схемы. На длинную телетайпную ленту, на которой потеряется весь смысл схемы.

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

Ниже варианты икон "Узел расщепления" и "Узел сбора".Реализуемые возможности:

A) Выполнить один из многих. Дождаться любого из.
B) Выполнить несколько из многих. Дождаться нескольких из.
С) Выполнить все. Дождаться всех.

С помощью этих икон можно реализовать "Развилку", "Переключатель", "Параллельные процессы" и может быть что-нибудь ещё.

Разные узлы расщепления можно комбинировать с разными узлами сбора.

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


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

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

Да, я не заметил, что в этом блоке - самостоятельное действие, не относящееся к процессу разщепления. Так, конечно, нельзя.

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

Также он очень подходит для "Переключателя". Только в "Переключателе" блоки входа в каждую ветку (условия) должны оставаться на одном уровне. Хотя, если уж на то пошло, то наиболее эргономичную конструкцию переключателя тут кто-то уже предлагал:

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

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

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

"Должна" - это не аргумент! С чего бы? Для какой цели?

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

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

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

Это не маршрут, это параллельные данные на шине

Есть предложение назвать вариант "макроикона <последовательная проверка условий>". А у переключателя другой смысл - эксклюзивный выбор. Поэтому я и не понимаю, зачем выносить макроикону конкретную реализацию взамен использования прямого смысла?

Странно, почему? До сих пор наши позиции почти по всем вопросам совпадали!
Неужто психофизиология восприятия у кого-то поменялась?

Алексей, я в предыдущий пост добавил.., гляньте..плз.

К чему приводит рост (раздувание и закладывание фич "на все случаи", которые всё равно не угадаешь), хорошо известно.

Есть компактный, миимальный аппарат - зачем его выводить из точки оптимума?

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

Какие данные?! Линия-то маршрутная! Об чём и речь идёт - всё свалено в одну кучу самым неэргономичным образом.
То есть, конечно, можно бы и не придираться к "мелочам"... Но хочется нотацию недвусмысленную, прозрачно понятную любому начинающему, и при этом максимально эргономичную!

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

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

видимо, в основе правил Дракона неортогональный базис и непротиворечивая группа компромиссов, но в целом система устойчивая и не допускает "размножения" компромиссов. Если мы что-то меняем в одном из понятий базиса, то новое сочетание правил и компромисов уже не в состоянии обеспечить устойчивость системы, для этого приходится вводить новые, при этом набор неизбежно "распухает" и могут появляться взаимные противоречия - ошибки. Для данной функциональности у Дракона минимальные базис и группа компромиссов.
Не факт, что новый минимум при расширенной функциональности займёт столько же места в голове. Что там было про chunk-limit?

Это легко разрешается в контексте параллельного исполнения.

Вначале был Дракон-1. Потом его стало не хватать, появился Дракон-2. Теперь настало время как-то внятно отображать параллелизм. Возможно это будет Дракон-3, который вберёт в себя что из предыдущих версий, как в своё время Дракон-1 взял кое-что из пресловутого ГОСТа (который до сих пор поставляет определения <см. редактор Тышова Г.Н.>). Может быть общее описание процессов будет изображаться на Драконе-3, а конкретные алгоритмы на Драконах-1,2.

Кому нужен минимальный аппарат всегда может пользоваться Драконом-1.

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

Ну да, а в Киеве - дядька!

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

2 Эдуард Ильченко: Как-то устали уже от разных версий одного и того же. Давно пора сделать единственную, вылизанную до полного удобства, нотацию, которая закроет 99% задач. И на оставшийся процент использовать другие инструменты.

Согласен. Может это и будет Дракон-3? Но суть не в названии.
А вот процесс вылизывания труден и тернист : )))

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

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

Здравый смысл + опыт.

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

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

Эта сумма не всегда срабатывает верно при бифуркациях.
Из нотации видно, что она предусматривает последовательное исполнение. Сказать 2 слова - "последовательный исполнитель" - гораздо эргономичнее, чем составлять список того, что нельзя делать в этой нотации.

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