Здравствуйте, Privalov, Вы писали:

P>Кстати, при описании ДРАКОНа в этом документе снова использовалась схема с рыбалкой.
Дык возможно, это весь ассортимент, что был на тот момент (2008/09) доступен... автор ведь не из НПЦ АП...
Кстати, по этому же — не так давно обсуждалась по крайней мере одна ГРАФИТ-ФЛОКС-схема — начиная отсюда: http://forum.oberoncore.ru/viewtopic.php?p=43805#p43805 (ну и там практически до конца ветки). Там и подход к параллелизму обсуждался. Также была небольшая ветка по технологии в целом: http://forum.oberoncore.ru/viewtopic.php?f=62&t=1091.

Ещё по вопросам укладки графа маршрутов. Замечание Mamut

Автор: Mamut
Дата: 29.06.12

по этому поводу можно прокомментировать так. Для упорядочения маршрутов в техноязыке взят как приоритетный принцип "по шампуру (крайний слева, строго по прямой) — самый главный (в смысле какого-то критерия, вводимого по смыслу задачи)". Для иллюстрации отличий от побочных можно использовать развёртку — скажем, приведённую в этом пункте.
В показанных случаях есть пересечения, которые можно устранить рокировкой (обменом выходов ветвлений — и соответственно начинаемых ими маршрутных участков). Но. При этом главный маршрут может оказаться не "по шампуру"... Заметим, что это можно установить только по конкретному содержанию схемы — а там обсуждаются т.н. литеральные схемы, в которых тексты вершин абстрагированы индексами. Но для сути вопроса это неважно.
И вот вопрос — а как сохранить "правило главного" и при этом избежать пересечений? Получается, что надо вводить дополнительные средства — конструкции перехода условного (переключатели) или безусловного ("петля" силуэта).
В ряде случаев, IMHO, есть и другой путь — изначально строить логику маршрутов иначе. Здесь могут помочь конструкции Дейкстры. И прежде всего его цикл — как иная форма, так сказать, "универсальной программы", чем силуэт. Можно видеть на примерах для обычной и автоматной программ. Разумеется, так же приложимо и к алгоритмам материальных процессов — хотя бы здесь.
Как сказал PSV100, в некотором смысле переход к ЦД можно понимать как "упрощение" графовой записи алгоритма. Да, тут условия выбора единиц структуры "вытаскиваются" в "шапку" схемы (принцип рассмотрен здесь). И перехды между единицами остаются тлько условные — веточные соединители не нужны. Но главная цель другая — выделять единицы структуры и условия их выбора по смыслу процесса.
Разумеется, и здесь возможна критика... Прежде всего — из условий не всегда понятен смысл веток. Для этого вводятся комментарии (на схемах отделены знаком тождества).