DRAKON.SU

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

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

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

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

1)последовательно, слева-направо(сверху-вниз).
2)определено алгоритмически
3)одновременно

Получается, что вот такой - {(А,В,С);(1,2,3)} базис надо визуализировать, а не IDEFnn.

- пп. В) и 2) оба можно читать как "определено алгоритмически".

Уважаемый Рэйлвэй Каген!

К сожалению, я не сумел понять Ваш краткий ответ. Вполне возможно, что я что-то пропустил
и не уяснил какую-то важную вещь.
У меня к Вам большая просьба. Если можно, разъясните мне Ваши замечания более подробно.
__________________________________________________________________

Вы пишете: "а почему шиной сделан только запуск параллельных процессов?"
В моем рисунке вообще нет шин. Есть горизонтальные линии с жирными точками.
Вы их назвали шинами? Если да, то у меня возражений нет.
Мне кажется, что необходима Ваша фигура, обозначающая слияние.
А зеркальная фигура для расщепления, по-моему, НЕ НУЖНА. Во всяком случае, я совершенно не понимаю, зачем она нужна.
Или я не прав?
Для удобства повторяю свой рисунок.

Владимир Даниелович, Вы правильно поняли мой вопрос и дали необходимые разъяснения.
Фигура для расщепления, которая, по-Вашему, НЕ НУЖНА - это расширенная икона "Адрес" в наших примитивах.

Попробую рассмотреть Ваш вариант подробно, используя дополненный список Ильченко Эдуарда:

функции расширенной иконы "Адрес":
A) Выполнить один из многих.
B) Выполнить несколько из многих.
С) Выполнить все.

функции расширенной иконы "Ветка":
А')Дождаться любого из.
B')Дождаться нескольких из.
С')Дождаться всех.

порядок выполнения для расширенных икон "Адрес" и "Ветка":
1)последовательно, слева-направо(сверху-вниз).
2)определено алгоритмически
3)одновременно

1. совершенно справедливо, что "А)Выполнить один из многих." и "В)Выполнить несколько из многих." не нужны, т.к.

случай А) можно свободно изобразить средствами классического Дракона,

случай В) можно сводить к А) или С) средствами классического Дракона, не допуская излишнего иерархического "закапывания".

2. линия с жирными точками не позволяет различить случаи (С;1),(С;2) и (С;3). Однако при ближайшем рассмотрении можно предположить, что:

случай (С;1) можно свободно изобразить средствами классического Дракона,

случай (С;2) можно сводить к группам запуска на основе (С;3) средствами классического Дракона. - (требует доказательства)

Поэтому, для соединений с расширенным "Адресом", может остаться только случай (С;3).
Тогда в примитиве можно использовать ОДИН ВИД линии для обозначения "(С;3). При этом получается, что в схеме НЕ БУДЕТ dummy-маршрутов, т.е. тех, которые появляются у нас в примитиве между шин и не содержат никаких икон.

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

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

Но так или иначе, напрашивается очередной вариант:Покритикуйте, пожалуйста.

При наличии ГОСТа в части определения "Параллельные действия", все эти предложения являются изобретением велосипеда.

Вот откорректированные иконы узлов, МШ-примитив с исправленными именами и силуэт. Дал шампурам и узлам индексы (узел содержит индекс законченного мультишампур-блока, каковой в этой МШ-схеме один); полный индекс шампура образуется составлением индексов частей узла (м.б. через какой-нибудь разделитель - это уже детали синтаксиса). Потоки индексируются по "своим" узлам расщепления; можно нумеровать потоки независимо как элементы схемы (слева направо и сверху вниз); для чего-нибудь такой способ может оказаться удобным. Показано разделение текстовой части икон на обязательную и необязательную. Ну и естественно, базовый смысл узла в иконе реальной схемы не пишется но подразумевается самим присутствием его иконы и подлежит обязательной алгоритмизации.
Прошу покритиковать, не забывая, что это неалгоритмическая схема (как и любая импер-модель, допускающая в процессе исполнения неединственность рабочей точки); предложения по сведению к таких моделей к алгоритмическим пока по-прежнему в P.P.S. этого сообщения.
Да, и опять: не стоит ли ввести икону приёма сообщения от другого процесса в пару к И20? Её употребление визуально проявит момент, когда нужно это сообщение в текущем процессе (а так мы лишь подразумеваем это по употреблению величин, переданных по И20 вне данного визуала).
P.S. Также в МШ-алфавите для показа разделения независимого шампура по веткам МШ-силуэта необходимы специальные иконы БП; вводятся по образцу исходных у Рэйлвей Каген. Ещё предлагаю вариант иконы расщепления, графика которого учитывает "расшифровку" смысла узла как ДРАКОН-переключателя для случая "выполнить один из". В МШ-примитиве занизил границу МШ-блока, исправлено (блок заканчивается, естественно, выходом из последнего узла сбора). Наконец дорисовал МШ-силуэт; решил аж в двух вариантах, чтобы показать себе и другим, как можно делать подстановки в МШ-схемы. Cказать, что для такой схемы силуэтное построение искусственно, возможно, слишком мягко будет Но понять логику, наверное, можно... не забывая, что независимые БП могут совершаться и параллельно (источники индекса для них берутся по обычной схемной логике "куда приходит сигнал"); показано также другое построение индекса узла. В общем на этих примерах, можно считать, дано рабочее определение МШ-алфавита; дело за стандартом языка и технологией...
Реализовал отделение в дракон-МШ-модели МШ-схем от дракон-схем для варианта 2 как вариант 3 (кстати, исправил ошибку в логике визуала Напиться: не было алгоритмизовано, что делать, если Напиток='Никакой'); подредактировал и остальные варианты. Наверное, допустимо и так и этак; лишь бы укладываться в формат диосцены. Также обозначил своё понимание использования оператора "чёрный ящик" от Рэйлвей Каген: им сочинитель временно обозначает часть мультишампура, содержание которой пока не знает (на разных МШ-схемах для примера поставил по-разному). Кстати, комментарий "Можно повторить всё сначала" - намёк на рекурсию в МШ-схемах (в данном случае - взаимную); но её допустимость здесь надо ещё проверить...

И, к сожалению, этим конструкциям опять же нехватает текстовой части.

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

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

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

В порядке творческого бреда : )
В общем, на текущий момент, я удовлетворён параллелизмом : )))
Пора двигаться дальше.

P.S. Серый прямоугольник навеян вот этим (см. рисунок).

В целом +1.

С каких это пор ГОСТ стал эталоном эргономики?

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

Для тех, кто захочет побаловаться с узлами расщепления/сбора ниже шаблон для Diagram Designer (лёгкая модернизация вот этого шаблона).

Как раз с эргономикой в ГОСТе с независимыми параллельными действиями все нормально:
1. точно выбрана терминология,
2. описан алгоритм синхронизации независимых параллельных действий,
3. выразительная, оригинальная и краткая графика,
4. ГОСТ является основой для UML и Дракона,
5. стандарт общепринятый - международный,
6. устоявшийся - выдержал переиздания.

Уважаемый Геннадий Николаевич!
Может хватит прикалываться и делать вид, что не понимаете, о чём речь?
1. Раз уж нужна Вам для чего-то документация в ЕСПД, так и следуйте условным обозначениям и правилам оформления, изложенным в соответствующих ISO/ГОСТ, именно при оформлении соответствующей документации.
2. Возможность перехода от непредусмотренного ГОСТом визуального синтаксиса к символам ГОСТ, была показана на элементарных примерах. Если остаются вопросы - ничего страшного, ещё порисуем. ВключАт этот синтаксис в язык или ещё куда - никому неизвестно.
3. Было бы прекрасно, если бы визуальное программирование выполнялось сразу в виде построения, удовлетворяющего ЕСПД. Но язык Дракон несколько шире программирования. Модификация или исследования языка на предмет расширения его возможностей вовсе не ограничиваются простым включением в синтаксис языка условных обозначений из какой-либо предметной области и совсем уж не обязаны следовать за модификациями прикладных программ..

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

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

Приложения иконы, реализованные в какой бы то ни было среде, не отменяют наличия основного текста этой иконы.
Однако от того, что мы изображаем вершину линией, становится ли она по сути линией (ребром графа)? Хотелось бы узнать суть предложения.

Уже есть некое ПО с похожим названием Micon 1.1.3U