DRAKON.SU

Нормально, на моих схемах очень даже помогает...
Насчёт вынесения деталей - конечно, всё как по ЕСКД (Усов о том же говорил).

Но читаемость, действительно, не на уровне. И в таком примере как раз лучше видно, почему.
Мало того - там действие Встретить клиента идёт "против шампура"...

В целом согласен. Схема с "перекрёстками", координирующими прохождение "рабочих точек" поодиночке по работам-алгопроцессам (без деталей работ и координации) - самое то. Алгоритмы "перекрёстков" и работ здесь и будут теми самыми деталями...
Как уже говорил, математика указывает, что циклы на таких схемах (конечно, реальные, а не фиктивные - чисто для укладки на плоскости) недопустимы - исключение составляют GAN-схемы.
Иная логика - сети Петри, где позиции-состояния "повязаны друг с другом" через переходы-действия. Её нужно по-своему приводить к системе алгопроцессов...

Силуэт нужен был бы для укладки - но сеть работ в общем случае не обязательно сводимый (устремлённый) граф. И с устранением пересечений синтаксис может только запутывать...

Насчёт организации силуэта с горизонтальным следованием - эквивалентный поворот дракон-силуэт-кросса ("петли" с заголовками и веточными разъёмами) действительно предписывает замыкать кросс через верх и против часовой стрелки - против естественного движения по часовой, как при чтении текста. Это показано пунктиром для непримитивных заготовок здесь в Правиле 40.

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

И вот в силу сложности отличения я всё-таки за сохранение различных направлений следования для императивных и неимперативных по смыслу схем.

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

Ну, пока хватает и офисного редактора...

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

Но. Во-первых, этот текст не вполне строг и потому не отражает всей сути дела. Прежде всего - что такое "выполнить КАЖДЫЙ процесс"? В каком порядке ставить на выполнение? Переключатель ведь несёт алгосмысл - в порядке просмотра. А что это м.б. не так - нигде не указано.
Далее. Порядок непоследовательного исполнения д.б. связан с исполнителем, допускающим параллелизм. Значит, вместо "КАЖДЫЙ" надо расписать, кто, что и над чем будет выполнять. Кстати, ещё м.б. условия выдержки времён стартов цепочек работ - но Вы, полагаю, подразумевали простейший случай, когда старт сразу после завершения назначений?..
Затем. Что значат такие имена вариантов расщепления? Если это названия процессов - то д.б. глагольными. Если субъектов и предметов деятельности - то кофеварка, вода и чашка сами не готовят... Где субъекты, исполняющие работы над ними? Как раз у PSV100 они появились...

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

Ну и по узлам сбора/расщепления системно. Каждое слияние завершает предшествующие работы. Поэтому ссылаться на них в дальнейшем некорректно. У Вас такого и нет - во втором слиянии используются только ещё не сливавшиеся работы. Но. Кроме того, на новую цепочку работ нужно явно назначить субъекта (как у PSV100 - вопрос отдельный из-за иной интерпретации графа). Т.е. после слияния д.б. расщепление - хотя бы и "один к одному". Это уже при "алгорасшифровке" оно будет представлено тривиальным алгоритмом запуска... а пока у нас модель доалгоритмическая...
Эскизно можно ввести хотя бы имя новой цепочки работ - и именно его использовать в тексте следующего слияния.

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

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

И кстати - что это приходится говорить "первый", "второй"? Узлы должны иметь индексы...

Образ книги где-нибудь доступен ?

Спасибо за примеры. Я, в принципе, и говорил о том, что у ДРАКОНа с "большим текстом" и "гламурностью" всё на уровне "мэйнстрима". И с "параллельностью" приходилось баловаться по всяко-разному, к примеру, и по таким мотивам:



Это уже "расширенный" ДРАКОН. В Ветке "С" есть как раз "множественный выбор". Чёрточки а-ля UML - это очередная попытка в рамках борьбы с пересечениями, которых иногда не избежать, а разруливать ситуацию через силуэт не всегда приемлемо (громоздко, к тому же логика растягивается по веткам). Поэтому приходилось и "в лесу" бродить:



Кстати, изучал и Ваши попытки "параллельного ДРАКОНа", например, здесь: "Сравнение Дракона со всякими другими". Но для ДРАКОНа пока лучшим решением я вижу "мульти-шампур" от Владислава Жаринова (здесь, например), но недостатки тоже есть, поэтому борьба не закончена.

Можно в двух словах подробнее, почему именно: в принципе из-за того, что текст не внутри икон, или идеологические огрехи, скажем, исполнители в подписях плохо выделяются, и т.п.



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



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



Да, Ваши идеи вполне здравы, себе взял на заметку. Спасибо.



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

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

- попытка "вписать" таблички. Стиль "визуальных эффектов" обдумывается, пока лишь прощупывается идея;

- номер действия и исполнитель указываются по мотивам ГОСТа для блок-схем;

- и, главное, есть попытка реализовать схему а-ля "программные исходники": под дугой объединяются несколько действий как логический участок, следующая структура в Р-схеме возникает, как правило, из-за новой развилки или "выбора", цикла или чего-то параллельного. На этом примере: первая структура - бармен последовательно выполняет действия с 51А по 51Д, вторая - цикл, третья - "параллельные действия", при этом во время "работы" клиента действие 72А выполняет официант, а затем последовательно 73А и 73Б - дежурный, конкретики расщепления/соединения процессов нет, в четвертой структуре - развилка типа да/нет.

Опять же, при отсутствии грамотного черчения красоты нет.

Диаграмма "таблицы в Р-схеме":

Ага, спасибо.

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

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

И вот здесь третье - возможность той самой "жизни без графики вершин". При обычной семантике можем эту графику снять - что будет, обсуждалось здесь: viewtopic.php?p=73919#p73919. Дуги либо оставляем все, либо дуги естественного перехода заменяем смежностью записей вершин (тогда границы записей д.б. очевидны - у Вас это таблицы).
При двойственной же семантике с читаемостью хуже - придётся заменять рёбра таблицами, оставляя графику вершин (назначение которых не всегда очевидно).

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

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

"- Заметьте - не я это предложил!" ((С) Л. Зорин. Покровские ворота)... в смысле, чтоб действия следовали по шампуру, как бы он ни был направлен...

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

Да, конечно... как же без эскизов...

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

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

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

Соглашусь, и с такими эффектами я и пытаюсь бороться. Вроде как, потенциал есть. Вот картинка из книги Вельбицкого и др. "Технологический комплекс производства программ ...", с.60:



Вроде, переварить подписи более-менее можно. Ранее я показывал очередную тренировку:



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



Одним словом, пока рано "сдаваться", но силы утихают, что-то .



Может быть, есть какая-нибудь ссылочка по поводу теории потоков работ на базе сетей Петри в рамках "реляционных отношений" (и не только) ?



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



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



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



Как раз я и подразумевал близость Р-схем к декларативным табличным данным, они и внешне "похожи" и связать их между собой "доктор прописал как".


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


Да, конечно, причины таких решений очевидны, и я завидую Вашей изобретательности

Я тут оценил, сколько "стрелочек" нужно, если использовать "мульти-шампура":



фигуры 3 и 4 - для веточных циклов вместо "чёрточки" внизу, последние три - для "мульти-шампуров". К этому можно добавить "соединители":



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


Спасибо за конструктивность.

А какая польза от хранения программы в реляционной БД и получении её через SQL запрос?

У представленных P-схем из книги Вельбицкого есть эргономический изъян по сравнению с Драконом. Поскольку у них нагружены дуги, то количество места в узлах мало. И автор в качестве меток использует сокращения: ДРВК, ДКК, ДРК (попробуйте сходу расшифровать, что это такое!). Сокращения нужно считывать из отдельной таблицы; из-за чего приходится бегать глазами туда-сюда, что замедляет чтение.

Такого рода сокращения были во всей компьютерной литературе советских времён, когда ещё что-то своё придумывалось.

В литературе того времени старались вводить стандартные сокращения. А при использовании P-схем для каждой схемы создается своя система сокращений. ДРВК - "два разных вещественных корня" - это метка, которая будет применима только при решении данной задачи.

Вот и я о том же... в смысле удобства обычного распределения семантики между вершинами и дугами...

Насчёт формализмов потоков работ - погуглите WF-сети...

Ага! Так вот как надо понимать то, что Усов и Прохоренко говорили об организации программ через БД...

Кстати, Амбер-схемы по логике мне напоминают GAN... возможно, являются их случаем или сводимы к ним...

Декларативность/императивность - это в смысле этой классификации... т.е. табличная и иные формы представления равно приложимы к этим категориям содержания...

Речь идёт о близости Р-схем к табличным данным, и при необходимости можно реляционно связать не только декларативную часть, но и алгоритмику. Если говорить о создании некой своей системы вида ГРАФИТ-ФЛОКС, то здесь как раз наработки из СУБД могут пригодиться. Скажем, есть потребность в отслеживании зависимостей (что или кто и где какой декларативный объект использует) для аналитики, контроля, к примеру, нельзя допускать модификации объектов при их использовании или помечать объекты как невалидные для недопущения неверных вычислений. Кроме того, нужна куча вспомогательного функционала, как автодополнение кода, рефакторинг и т.д. и т.п. Работа с табличными данными имеет свои плюсы (и минусы) по сравнению с использованием синтаксических деревьев (хотя без AST не обойтись).
Одним словом, то что Р-программу можно свернуть в таблицу, так это, имхо, хороший бонус. Вельбицкий в своей книге говорит о том, что такой табличный способ удобнее для ввода и редактирования программы по сравнению с рисованием графа, и отладка выполняется тоже по таблицам. Скорее всего, здесь играет весомую роль технические возможности тех времён. Но в любом случае, это также хороший вариант хранить схемы в виде текста. Кроме того, что Р-схемы кроме графики имеют тождественное отображение через псевдографику, такой табличный линейный текст хорошо подходит для diff-сравнивалок, контроля версий и т.д.

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

Кстати, в книге схемы рисуются не по ГОСТу, видимо, разборы полётов для ГОСТов были позже. По ГОСТу именовать вершину нужно внутри узла, в круглых скобках, так несколько приятнее, но, действительно, вписать можно одно-два коротких слова (может, так даже и лучше, основная нагрузка ведь на дугах). Откровенно говоря, я бы предпочёл имел дело со схемами в том виде, в котором ДРАКОН зарождался, в этой теме ВП давал пример. Специалист в прикладной области понимает, что такое, например, "ПЛ1НХ.ПЕРЕХ.МТ", и ничего лишнего, красота. Здесь и у Р-схем проблем не будет.

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

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


Ага, понятно.

Думаю, Вы несколько оптимистично говорите о SQL-потенциале Р-программы. Обратите внимание что метка может быть только у Р-структуры, а не у каждой дуги структуры. Структура имеет один вход и один выход , да и к тому же может иметь вложенные структуры.Надо явно описывать упорядочивание (по вертикали) Да и вообще особого потенциала упрощения задачи описания графов в реляционных таблицах Р-технология не имеет (IMHO, конечно)
PS.
Что меня очень настораживает, работа по Р-технологии (по книге Вельбицкого) начинается с описания логической структуры данных - ЛСД

Круглыми скобками обозначаются специальные вершины.

Внутри спецвершины (между левой и правой круглой скобкой) возможно написание текста.

Текст около начальной вершины структуры является именем структуры и называется меткой.

Текст в конце дуги определяет переход в требуемое место р-схемы и называется структуризатором дуги, например:


ЗЫ: Это выдержки из документации технологического комплекса РТК Микро

Вы правы, так, вроде, и в ГОСТе написано. Но эти имена и переходы как-то плохо смотрятся (когда есть текст при дугах), было бы хорошо, если бы в условном редакторе они бы включались и отключались.

Кстати, кто такой "РТК Микро" - где-то есть эта документация ?