DRAKON.SU

2

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

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

А чего не 1 ??? Или -2
Что бы не диспутировать на уровне "кто громче", нельзя ли привести коды на "чистом winAPI" для упомянутого рисунка
Чтобы можно было взять, и проверить. Молча.

У меня не получалось, скажем так... меньше пяти. При определенных требованиях к "универсальности шаблона"...

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

фрагментМне кажется, что такая конструкция неудобна (что делать если будет 10 процессов? Одни изломанные линии останутся) и избыточна (ниже попробую объяснить).Поскольку у нас примитив : ), ничего страшного нет в том чтобы принять некоторые упрощения для визуального облегчения схемы.

Обозначения:
A – узел (точка) расщепления.
B, C – узлы (точки) сбора (слияния).
D — маркер узла расщепления (в силуэте разворачивается в «Адрес» и три «Имя ветки»).
E, F и маршрут от A до B – независимые (параллельные) процессы.
G, H – маркеры узлов сбора (в силуэте разворачиваются в «Адрес» и «Имя ветки»).Маркер узла расщепления говорит о том, что здесь находится точка распараллеливания процессов и называются эти процессы «кофеварка», «вода» и «чашка». Действует правило: в маркере имена процессов, идущие сверху-вниз, соответстуют визуальному изображению процессов слева-направо от узла расщепления. При разворачивании в силуэт каждый процесс получит своё «Имя ветки».

Маркер узла сбора говорит о том, что узел сбора пройден. Надпись в маркере содержит имя процесса, следующего за маркером. При разворачивании в силуэт каждый предшествующий процесс получит свой «Адрес».

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

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

Не могли бы Вы привести свой вариант решения означенной проблемы?

И не пытайтесь. Не получится без полного контекста задачи. Это одна из мутных сторон ГОСТовской нотации, про которую более опытные коллеги почему-то сразу не предупредили.
На практике(как-то довелось наблюдать) - к ведущему приходит программер и спрашивает: "скока здесь потоков программить". Даже имея на руках схему. Занавес.

Здесь случай другой. Здесь уменьшение количества сущностей : )

Да, конечно. Эти модельки были нарисованы только как иллюстрация "цепочек", поэтому я допустил "плюхи" с пустыми маршрутами.

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

Это мы так шлифуем предложение, чтобы каждый был виноват

Если я правильно понял, требуется чтобы поток, завладевший объектом, делал запись в LOG файл. Остальные потоки ждут освобождения объекта (о чём свидетельствует состояние мьютекса). Время событий неизвестно. Количество потоков неизвестно. Я бы предложил такую конструкцию:
Продолжаем расширять язык : )))

Здесь:
А — узел расщепления.
В — узел сбора.
С — маркер узла расщепления. Содержит имена процессов. Соответствие процессов именам: имена сверху-вниз, процессы слева-направо.
G – маркер узла сбора. Содержит имя следующего процесса

AB – главный маршрут. В программе всегда присутствует. Является супервизором других процессов, необязательно расположенных именно между этими узлами расщепления и сбора.

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

EB и FB – динамические маршруты. Динамические в том смысле, что время их запуска и их количество неизвестно до запуска основной программы.

Статические маршруты визуально выделяются сплошной линией и всегда находятся справа от главного маршрута.

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

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

Плохо. Даже очень. От визуальных многоточий избавляться надо. имхо.

Как бы обозначить динамически создаваемые маршруты?
И, вообще, нужны ли они?

Крутить в цикле запуск процесса столько раз, сколько нужно копий.

С копиями понятно.
А где описать сам процесс (динамический)? Можно с помощью отдельного примитива или силуэта, а можно как выше, прерывистыми линиями.

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

А что такого плохого в прерывистых линиях?

Здесь я как раз думал о том, что примитив чаще нужно преобразовывать в силуэт.

Часть алгоритма, следующая за маркером узла сбора, при преобразовании в ветку силуэта, должна будет получить «Имя ветки». Поскольку «произвольное имя» можно легко автоматически присвоить в «Имя ветки», то имеет смысл сразу правильно именовать часть алгоритма, следующего за узлом сбора.

Просто для сравнения.

А разве текст в узле не есть метка маршрута (на котором м.б. и не один процесс)? Поэтому Рэйлвей Каген и говорит о "произвольном имени"...

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

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

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

Замечания есть:
1) Количество мьютексов совпадает с количеством защищаемых ресурсов, а не количеством параллельных процессов. Один файл - один мьютекс. А не m1, m2, ... и т.д.. Как это делать, чтобы это было понятно любому, взлянувшему на схему (наша задача - улучшить работу ума !!!) - НЕ ЗНАЮ.
2) Одна финтифлюшка по имени "Ждать освобождения" - это совершенно неправильно. Защита - это синтаксическая конструкция (которой нет, и никто ее не планирует вроде) со своим префиксом (WaitForSingleObject/EnterCriticalSection), и суфиксом (ReleaseMutex/LeaveCriticalSection). И с запретом выхода из этой конструкции мимо суффикса. Не вижу суффикса...

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