DRAKON.SU

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

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

Уважаемый PSV100!

В Белоруссии (2011) сравнивают Р-схемы и Дракон (две похожие, но разные статьи):
http://elib.bsu.by/bitstream/123456789/ ... 351pdf.pdf
http://elib.bsu.by/bitstream/123456789/ ... nakh62.pdf

Название конференции
http://elib.bsu.by/handle/123456789/9836

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

Соавтор указанных статей Любовь Федоровна Дробушевич
в 1987 г. защитила кандидатскую диссертацию на тему "Использование P-технологии для оценки качества и надежности программ"

Имеет совместные работы с Вельбицким и Ковалевым

См. список ее работ: http://www.fpmi.bsu.by/?guid=13100

Видно, что часть материала - примеров - стыбзена вот отсюда: viewtopic.php?f=62&t=2921
Формулировки слегка изменены, но лексика и фразы просочились.

В библиографии, тем не менее, наша статья не указана.

Спасибо за материалы. Откровенно говоря, публикации - так себе..., без конструктива. Незаслуженно досталось ДРАКОНу, немалая часть дифирамб для Р-схем не чужды и ДРАКОНу тоже, да и картинки диаграмм некорректно оформлены (но это мелочь), и не все недостатки классических блок-схем, указанные авторами, можно приписать и к ДРАКОН-нотации (здесь авторы ошибаются). И с Р-схемами напортачили, в рамках примеров использования с "return". Р-технология, вроде как, не допускает использование действий, которые предопределяют продвижение по маршруту, т.е. нельзя указывать "if, for, while, break, return и пр.". Для произвольных переходов есть соответствующие граф-элементы, указанные в этом посте. Видимо, авторы публикаций ещё столкнулись и с ограниченными возможностями используемых редакторов для Р-схем, они не поддерживают переходы, как и специальные (в т.ч. и именованные) вершины. А переходы, всё-таки, могут быть востребованы из-за практической необходимости, они позволяют указать алгоритм, требуемой семантики для конкретного исполнителя (к примеру, эта тема показала, что алгоритм не может быть оторван от конкретного "действующего лица"), да и явное "goto" иногда может оказаться полезным (а в этой теме так и не достигли однозначно верного решения, здесь и goto бы пригодился, возможно).

Кстати, кроме "return" есть и алгоритмические ошибки. Вот рисунок из первой публикации:



Здесь, если напряжение не в норме, то отказ от пуска не будет выполнен, и состояние выполнения действий становится неопределенным (рантайм-ошибка, если "компилятор" допустит такую схему). Если не привязываться "к железу", то алгоритм лучше задать без "return", так для "Р-человека" будет доступнее:



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



В публикациях неудачно выбран и пример цикла с return:



Без return-а и двойной дуги даже понятнее:



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

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

По статьям лишний раз видна недостаточная наглядность схем с инверсией семантики вершин/дуг... всё время в Р-схемах вынужден прилагать усилия для связывания разметки с дугами...

Забавно, что в качестве стандарта для Р-схем при наличии специализированного ГОСТ Р указывается 8631... обзорный, зато международный... видимо, в Беларуси советские ГОСТы автоматически не "гармонизируются"...

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

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

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

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

В сущности, силуэтная укладка "только для устранения пересечений" - тоже разновидность второго пути.

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

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

Чертёж - вообще язык техники... просто, как верно отмечали, скажем, Ермаков и Усов, представление о "технике идеального" у самих предметников ещё не на должном уровне...

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

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


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



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

Ну, и последний аргумент в пользу Р-схем. В следующем посте alexus в рамках борьбы с пересечениями предлагал использовать 3D-проекции. Вельбицкий в своей статье утверждает о готовности Р-схем к 3D:



Речь, конечно, об иерархической декомпозиции...


И я вновь "покурил" над eEPC-нотацией для попыток дополнить "предикатами" ДРАКОН. Всё-таки, квадратики-события не соответствуют логике предикатов в Р-схемах. Требуется выделять отдельную икону для результатов/охран, показывать через рёбра взаимосвязь между ними, может возникнуть потребность обращаться к результатам прошлых функций, т.е. не только последней, и это нужно как-то маршрутно показывать. И традиционно неясно как компактно/удобно ликвидировать пересечения, т.е. как же ввести "скрытую ЕСКД-шину", ведь "Р-структур" таких нет. К тому же уже без "перекрёстков" не обойтись, а тогда ромбик-"вопрос" и иконы "выбора" уже лишние. А эти перекрёстки - такая уж непонятная штука для обычных людей, особенно когда в них рисуют неизвестные "палочки" вида "v ^ x". Даже узлы в Amber, без палочек и прочих надписей, с логикой только двух видов "и" и "или", тоже требуют постоянного вникания.

Одним словом, как Р-схемы развернуть вертикально и впихнуть их в квадратики - пока не знаю...

Кстати, наткнулся на парочку материалов насчёт eEPC-нотации:

- здесь очень кратко основная суть;

- здесь коротко в целом о методологии и какие имеются типы диаграмм;

- здесь краткое сравнение с IDEF, заметно, насколько они "одинаково полезны";

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

- здесь небольшой урок, и там в комментариях пользователь starodubcev выложил свой труд Соглашение по моделированию, видимо, под "впечатлением" от "описалок" в SAP R/3.

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

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

Надеюсь, что возня с Р-схемами родит какие-то идеи...

Даю ГОСТ на P-схемы, если кто еще не читал

Кроме ГОСТа, практически ничего не найти, а искал в сети, правда не очень настойчиво, тексты Вельбицкого чтобы получше прояснить задумку автора по интерпретации р-схем. Доступная книга от 1980г. не помогла. Наличие "много букафф" частенько загромождает смысл, а копать особо мотивации и времени нет.
IMHO - плоховато изложена эта технология в сети. (В отличии от Дракона)

Имхо, сам по себе язык диаграмм тут решительно ни при чём.
Просто имеем отсутствие адекватных инструментов.
Но откуда им взяться, если сама исходная задача поставлена некорректно? За каким лешим понадобилось алгоритм на плоскость натягивать? У алгоритма как графа нет свойства двумерности. Это привнесённая в процессе визуализации сложность. И, имхо, этой сложности слишком много уделяется внимания в ущерб смыслу.

Согласен.

Почти не использую - за отсутствием адекватного инструмента... А самому писать некогда... да и лень

Р-схемы ещё не оценил. То их представление, которое встречается здесь в примерах и описано в литературе, можно оправдать разве что бедностью эпохи АЦПУ (да и то, в те же самые времена вполне имелись те же синтаксические диаграммы Паскаля, так что сравнить в плане эргономики есть с чем). В общем, нет оправдания такому представлению. Дуги - это хорошо, а вот текст сверху/текст снизу - никуда не годится. Семантики не касаюсь - надо поработать, чтобы оценить, а я не работал с ними...

Хотелось бы...

А как выйти из этой схемы?

Полностью поддерживаю.

Да... по содержательному же могу сказать кратко, что к этому: из материалов данной конференции более всего относится сказанное здесь: viewtopic.php?p=66447#p66447.
Как это реализовывалось - теперь можно видеть в роликах: https://www.box.com/s/84130eef00353ba8bd9d.
Смысл в том, что всё отражаем относительно ПМ - рабочих мест и связей между ними. Представляемых, как всегда в управлении предприятием и было, на базе схем с "расщеплением рабочих точек". В частности, в КУБе взята наиболее распространённая форма схемы - сетевой график. И в такой форме описание деятельности и верифицируется... ибо из неё следуют и возможности связей между РМ и более крупными единицами оргструктуры... по поводу и производства, и снабжения, и сбыта, и финансов... что и нужно для управления... а алгоритмы возникают в техоперациях (реализация смысла каждой отдельно взятой вершины и связи).
А уж "бизнес-процесс" как конкретная реализация в виде алгоритма м.б. получен для конкретных целевых данных. Только не это требуется в жизни - а планирование и отслеживание выполнения плана...

Затрудняюсь ответить, я на своих тестовых данных даже войти не могу...
В качестве оправдания я обязан попробовать Вас вытащить оттуда:

Спасибо за мнение.


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


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



Но могли и так (отсюда):



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



Думаю, что эта картина недалека от истины. Т.е. схемы оформлялись на листах, где сначала были описательные данные, затем схема с десяток дуг и ниже остальные данные. При этом оформление было по ЕСКД, с рамками и штампами, плюс остальные табличные справки в чертеже, и пояснительный текст. В результате сама схема, в виде дуг, выделялась среди табличности, не смотря на свою с ней схожесть. Это подтверждает и пример из книги Вельбицкого (с.72):



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


Пока ещё туго, хотелось бы побольше сторонних мнений, идей, нужны сплетни и сенсации...

Тогда уж нижнюю дугу можно убрать, а третью сделать обратной, но обращает на себя внимание условие прохождения третей дуги в сравнении с условием прохождения второй дуги.
Кстати, обратите внимание, что это, по сути цикл Дейкстры )))
Вобщем я думаю, что специальная структура все же проще в конструировании большинства циклов, а базовая структура применяется для реализации цикла repeat ... until not Cond

Уважаемый PSV100!

Я очень рад, что Вы организовали дискуссию на тему: "Дракон и Р-схемы".
Дискуссия привлекла внимание специалистов. И вызвала многочисленные отклики.
Это очень хорошо.

Благодаря Вам я снова вспомнил про Р-технологию, о которой давно забыл.
За что Вам большое спасибо.

Вместе с тем цитированный отрывок содержит ошибочное утверждение.
Во избежание недоразумений повторю:
В чем здесь ошибка?

В том, что эта анимационная диаграмма НЕ ЗАМЕНЯЕТ Дракон, а дополняет его.
Я согласен, что это хорошая анимационная диаграмма.

Но она никогда не сможет заменить Дракона.

Сегодня в западной медицине для изображения медицинских алгоритмов используются блок-схемы. Приведу примеры:

1. Статья "Medical algorithms" в английской Википедии:
http://en.wikipedia.org/wiki/Medical_algorithm

2.Статья "Texas Medication Algorithm Project"
http://en.wikipedia.org/wiki/Texas_Medi ... hm_Project

3. Статья "International Psychopharmacology Algorithm Project"
http://en.wikipedia.org/wiki/Internatio ... hm_Project
http://www.ipap.org/

4. IPAP Schizophrenia Algorithm
(Алгоритм шизофрении)
http://www.ipap.org/pdf/schiz/IPAP_Schi ... 060327.pdf

5. IPAP Post-Traumatic Stress Disorder (PTSD) Algorithm
(Алгоритм нарушений при посттравматическом стрессе).
http://www.ipap.org/pdf/ptsd/en/IPAP_PTSDAlg_en.pdf

6. Generalized Anxiety Disorder (GAD) Algorithm
http://www.ipap.org/pdf/gad/en/IPAP_GADflowchart_en.pdf

Источник блок-схем, которые я привел:
http://www.ipap.org/welcome.php

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

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

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

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