Владислав Жаринов писал(а):
Дело в том, что в той теме обсуждалась как раз проблема физического преедставления графа маршрутов независимо от логики. Вернее, возникающая, когда логика (в данном случае - правило упорядочения "чем главнее - тем левее") препятствует физически уложить граф на плоскости без пересечений даже тогда, когда это физически возможно.
...
Предлагавшиеся варианты, в сущности, относящиеся к двум базовым путям разрешения пересечений:
* вводить соединители в одну из пары персекающихся линий;
* вводить в саму схему логику, исключающую необходимость в пересечении.
В сущности, силуэтная укладка "только для устранения пересечений" - тоже разновидность второго пути.
Тогда как А. Донской в той теме, похоже, хотел сказать, что не надо мешать физику с логикой. А наоборот, нужно их отграничивать в синтаксисе схем. Если так - то я с ним согласен.
Да в том и дело, что здесь физика существенно влияет на логику. Если в этом случае ещё можно выкрутиться через рокировки, уже игнорируя правила упорядочения: всё главное - слева (силуэт здесь, имхо, это разрыв логики "на ровном месте"), то в
следующем - уже "здравствуй силуэт" (или, скорее, новые ветки силуэта), прощай компактность, а может и декомпозицию элементов схем придётся встречать (т.е. разносить по разным схемам). При этом, очень вероятно, что с такой проблемой столкнулись не сразу, и затем на арену выходит уж слишком нудная, требующая море возни, переделка-"рефакторинг" диаграммы. После таких моментов блок-схемы хочется выкинуть куда подальше. Откровенно говоря, подмеченные Вами моменты
здесь и
здесь имеют своё место, и лично я бы в рамках встроенки, очень вероятно, искал бы способы программить через специализированные текстовые языки (DSL), причём с функциональным уклоном. Всё-таки, у ДРАКОНа крайне узкое применение в программировании. В остальных сферах, как описание алгопроцессов, скажем, в
медицине, ситуация не лучше. Если вдруг эта тема получит своё развитие, то, проблемы тоже начнутся, как минимум, с "совместной параллельностью", когда дело дойдёт до бригады врачей.
Кстати, интересно бы познать мнение А. Донского, использует ли он ДРАКОН сейчас, рискнул бы "Р-порисовать", хотя бы как диаграммы состояний...
В Р-схемах, имхо, как раз есть возможность разделить "физику от логики" через структурные переходы и спец-вершины (
этот пост). Да и, в целом, как-то Р-схемы лучше адаптированы к реальному программированию (имхо, конечно).
Владислав Жаринов писал(а):
PSV100 писал(а):
...
В Р-схемах структуры задаются последовательно, параллельно и вложено, но не хватает некоего их объединения (последовательных структур при общем маршруте), т.е. был бы не плох такой вариант:
...
Наверное... но синтаксис всё равно не позволяет легко читать схему...
Вообще-то, думаю, что подобное объединение не ввели специально. Р-схемы предполагают чётко выделять структуры: что за чем следует, что инвариантно/параллельно, что куда входит, при этом выделяется и основной шампур. Нет никаких слияний маршрутов, и отдельно показывается каждый переход, тем самым предоставляя возможность быстро оценить какие есть варианты передвижения. Структурность у Р-схем более строгая, чем в ДРАКОНе, например, двойную дугу цикла невозможно разорвать по веткам силуэта, что допустимо с циклом "ДЛЯ" в ДРАКОНе. И, имхо, очень полезный эффект "слепки" структур, как здесь:
Вложение:
r_remont.PNG [ 26.14 КБ | Просмотров: 15397 ]
Т.е. как бы нет эффекта явного сплошного маршрута, единого графа (что имеем в ДРАКОНе, да и в блок-схемах), в вершинах-соединений последовательных структур (прежде всего, "много-много", "много-один") мы можем подразумевать скрытую "ЕСКД-шину с множеством потенциальных пересечений", логику соединений раскрываем через предикаты.
Ну, и последний аргумент в пользу Р-схем. В следующем
посте alexus в рамках борьбы с пересечениями предлагал использовать 3D-проекции. Вельбицкий в своей
статье утверждает о готовности Р-схем к 3D:
Вложение:
r_3D.PNG [ 12.99 КБ | Просмотров: 15397 ]
Речь, конечно, об иерархической декомпозиции...
И я вновь "покурил" над eEPC-нотацией для попыток дополнить "предикатами" ДРАКОН. Всё-таки, квадратики-события не соответствуют логике предикатов в Р-схемах. Требуется выделять отдельную икону для результатов/охран, показывать через рёбра взаимосвязь между ними, может возникнуть потребность обращаться к результатам прошлых функций, т.е. не только последней, и это нужно как-то маршрутно показывать. И традиционно неясно как компактно/удобно ликвидировать пересечения, т.е. как же ввести "скрытую ЕСКД-шину", ведь "Р-структур" таких нет. К тому же уже без "перекрёстков" не обойтись, а тогда ромбик-"вопрос" и иконы "выбора" уже лишние. А эти перекрёстки - такая уж непонятная штука для обычных людей, особенно когда в них рисуют неизвестные "палочки" вида "v ^ x". Даже узлы в Amber, без палочек и прочих надписей, с логикой только двух видов "и" и "или", тоже требуют постоянного вникания.
Одним словом, как Р-схемы развернуть вертикально и впихнуть их в квадратики - пока не знаю...
Кстати, наткнулся на парочку материалов насчёт eEPC-нотации:
-
здесь очень кратко основная суть;
-
здесь коротко в целом о методологии и какие имеются типы диаграмм;
-
здесь краткое сравнение с IDEF, заметно, насколько они "одинаково полезны";
-
здесь есть пару слов, но я обращаю внимание на эту
картинку - пример таблицы-расшифровки выполняемых операций, что пригодится в свете "критики" в
этом посте. Подобные таблицы связать бы с
табличной Р-программой, или расширить её, да подключить бы ещё и
таблицы решений, и
оценка варианта исполнения не помешает, которую можно задать и как Р-граф, и как таблицу, к тому же нужно учесть, что Р-схемы ну уж очень похожи на таблицы и могут не только задавать алгоритмику - в общем, можно полноценную "таблографику" сваять, рядом с "драконографикой"
-
здесь небольшой урок, и там в комментариях пользователь starodubcev выложил свой труд
Соглашение по моделированию, видимо, под "впечатлением" от "описалок" в SAP R/3.
Материалы выше указаны в контексте
этой темы, м.б., что-то пригодится. Но, я наткнулся на
эту тему (правда, там по сути лишь пару слов, остальное - сплошной антропоцентризм
) и
эту, и более-менее прояснился Ваш вывод, указанный
здесь. Соглашусь, и я сам говорил тоже, что реальная потребность в зарисовке бизнес-процессов возникает редко при правильном "системном подходе". И, действительно, имеющееся массовое "бизнес-описательство", фактически, бесполезное занятие, коим часто страдают описатели в кабинетах, "где висят плакаты с миссией предприятия". Но потребность в реальном адекватном отражении дела, всё-таки, возникает иногда, кроме материальных процессов требуется и структурные части декларировать, какие-то отношения показать, те же межцеховые связи, и т.п., да и алгоритмы всяких расчётов разобрать по полкам тоже иногда нужно (причём, скорее всего, самая полезная составляющая в нагрузках для графики), не исключена и необходимость в формальностях (если уж начальство хочет, аудиторы требуют, сертификация намечается и т.д.).
Но адекватная графика пока что-то не светится в конце туннеля. Кстати, эта eEPC-нотация снова показала, что сверх-обилие разных квадратиков - излишнее попугайство. А для программистской натуры, всё-таки, как-то ближе "безликие чертежи" - что-то вроде адекватного прогязыка, где нет изобилия ключевых слов и уродских идентификаторов с символами-закарлючками а-ля "указатели" и "ссылки" (а если дела с закарлючками как в упомянутом языке Rust - то просто ужас) - так меньше лишнего информационного шума.
Надеюсь, что возня с Р-схемами родит какие-то идеи...