DRAKON.SU

Не понятно из чего, какого правила дракона, это следует.

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

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

Согласен:

Но далее
также согласен в отношении "двоякого токования", но немного по другим причинам.

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

Для начала привожу первообразную схему данной темы:

Пунктиром выделены параллельные маршруты - в обычном первобытном понимании:
(Д2-Д4) и (Д3-Д5).

Я не спроста несколько выше задал вопрос типа: что значит "расшивка параллельных маршрутов"?
1) Выделение параллельных маршрутов, то есть их выноска в две отдельные связные ветки?:
отдельно и связно (Д2-Д4) + отдельно и связно (Д3-Д5).
2) Разделение (разложение) параллельных ветвей на элементарные операторы
и выкусывание хвостов (в данном случае Д4, Д5) в отдельные ветки (как в силуэте PP.png).
Первая задача более общая - это попутное замечание.

Далее приводится еще более общая задача - взятая за основу:
с поперечным сечением в параллельном участке и с раздельным отображением 2-х фрагментов общей схемы.


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

Я привожу эту схему в доработке, в частности:
узел слияния параллельных ветвей (o) показан не одной поперечной линией, а двумя - как и узел распараллеливания (#).

Здесь используются такие аргументы:

1) Основная идея отображения параллелизма исторически была такая:
наглядное выделение параллельных участков схемы (с параллельными продольными ветвями)
между парными поперечными линиями на границах участков.

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

3) Целесообразно (логично):
-- либо использовать парные поперечные линии и на входе параллельного участка
(на разделении потоков "#") и на выходе (на слиянии потоков "o");
-- либо их не использовать и на входе и на выходе - и использовать одинарные поперечные линии.

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

Далее идут следующие аргументы:

5) Традиционно узел слияния параллельных ветвей (обозначен на схеме малым кругом "o")
выполняет функции конъюнкции - логической операции И, And (o = &), которая:
-- контролирует окончание работы всех параллельных ветвей;
-- срабатывает не выход (передает управление далее)
после окончания выполнения последней во времени параллельной ветви
(возможно одновременное окончание).
Это, условно, параллельная конъюнкция операторов параллельных ветвей.

6 ) Если есть параллельная конъюнкция, то теоретически может быть параллельная дизъюнкция:
o = V - логическая операция Или, Or, которая:
-- контролирует окончание работы первой во времени параллельной ветви;
-- и срабатывает на выход (предает управление далее)
после окончания выполнения этой первой во времени ветви.
Более позднее окончание работы других параллельных ветвей этой схемой не контролируется
(но это можно обеспечить другими средствами - при необходимости).

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

8 ) Если на схемах не указывается тип узла слияния параллельных ветвей,
по умолчанию предполагается параллельная конъюнкция (o = V).
Это массовое традиционное применение параллелизма
(обычно на интуитивном уровне понимания структурной логики его работы).

9) Если необходимо использовать параллельную дизъюнкцию,
то необходимо как-то различать эти два вида замыкания параллельных ветвей,
например надписями типа o = & и o = V (или просто надписями &, V).

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

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

И кроме того его, в принципе, можно с пользой применить для логических схем алгоритмов
(особых стрелочных структурных формул алгоритмов - с адресными связями стрелок) типа:
или

Тоже есть информация к размышлению.

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

Максим, Вы правы, такого правила нет.

Я имею в виду новое правило. См. ниже




На рисунке показано, что две параллельные ветки
(2-я и 3-я) имеют в иконах адрес одинаковое слово "амба".
Это означает конец параллельных процессов.

Слово амба ничего не значит. Оно бессмысленное.
Рисунок тоже бессмысленный. Я нарисовал его
только для того, чтобы проиллюстрировать
формальное правило.

Имхо, как-то поспешно правило родилось : )

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

Как-то так ...

Эдуард Владимирович, Ваши замечания справедливы. Тщательное продумывание деталей является безусловно правильным подходом.

Вместе с тем, моя позиция тоже является продуманной. Поясню.

1. Надо разделить сложные случаи (о которых пишете Вы) и простые случаи, о которых пишу я.

2. В жизни есть и то и другое (и сложные случаи, и простые).

3. Думаю, что простых случаев БОЛЬШЕ. Мое предложение относится к простым случаям. Моя цель — обеспечить ПРОСТЫМИ средствами большинство пользователей.


4. Я понимаю, что в сложных случаях мой способ может не сработать. И придется вводить усложнение.

5. Это означает, что я допускаю возможность двух разных решений:
— мое решение для простых случаев
— и иное решение для сложных случаев.

6. Я исхожу из того, что простых случаев будет большинство и забочусь в первую очередь о "простых" пользователях.

7. Начинать надо с простого, а не со сложного.

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

Для простых случаев нужно запретить использовать силуэт для параллельных процессов ...

Если нет решения по изображению параллельных процессов в сложных случаях в силуэте, то и для простого случая использование силуэта не требуется.

Пользователь всегда (подчеркну ВСЕГДА) из простого случая сделает сложный : ) А решения нет ...

Не могу согласиться. Это невозможно.
Силуэт с паралельными процессами нужен врачам. Обязательно.



Это не так. Для простого случая
использование силуэта требуется.
Обязательно требуется.

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

Со сложными случаями работает специалист по информатике.
Специалист может придумать и использовать сколь угодно
сложные случаи. А врач нет.

Согласен. Поправлюсь. Я имел в виду продолжение маршрутов параллельных процессов через петлю силуэта.

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

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

Вы правы. Я нечетко сформулировал новое правило.
По Вашему замечанию исправляю формулировку

Применительно к конкретному случаю это означает следующее:
Надо дождаться завершения обоих параллельных процессов:
— "Достань пальцами до нижней челюсти"
— "Разрежь защелку, фиксирующую шлем"
и только ПОСЛЕ этого можно выполнять действие "Клади на носилки и поехали".

Не могу согласиться.
Полная изоляция веток (т.е. запрет объединения веток) — фундаментальное правило ДРАКОНа.

"Соединить две ветки" — это ошибка типа "сиамские близнецы".

Если разрешить соединять ветки, наступит хаос. И преимущества ДРАКОНа исчезнут.

==============================

Напоминаю правило пересадки лиан из книги "Учись...".

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

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


От предлагаемого соединения веток тоже никто не умер. И, надеюсь, не умрёт : )

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


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

< от Владимир Паронджанов:лучше говорить о слиянии параллельных процессов :) ...

-

< от Ильченко Эдуард:Полезно иметь в виду, что параллельные потоки всегда сливаются через логический элемент (даже если эта логика явно не обозначена).


Красиво соединять ветки через петлю силуэта можно при помощи таблиц истинности:



В реляционной модели вообще не важно, в каком виде будет представлена информация (примитивом, силуэтом, или как-то ещё), и примитив всегда можно взаимно преобразовать в силуэт...
=> не нужны ограничения, типа
< от Ильченко Эдуард: