Здравствуйте, VladZharinov, Вы писали:
PSV>> Имхо, Паронджанову лучше начинать знакомство программистов с ДРАКОНом на примере таких инженерных схем, как эта: http://forum.oberoncore.ru/viewtopic.php?p=43805#p43805. Здесь ДРАКОН во всей своей красе. Затем показательные выступления лучше перенести на алгоритмы уровня рыбалки и поездки на автобусе — это стихия ДРАКОНа, и, как бонус, для тех, кому нужно, можно заявить о "гибридности" ДРАКОНа с языками С, Pascal PSV>>В любом случае, можно придумать как начертить свое нужное видение параллельности. VZ>Кстати, ветка, в которой появилась та инженерная схема, как можно видеть, в основном как раз посвящена была именно этому. Сам ВП в дальнейшем предложил решение, основанное на операторах синхронизации — см. эту ветку.
Спасибо за эту ветку, весьма кстати. Раньше параллельностью мы у себя особо не заморачивались, т.к. составление схем происходит эпизодически и тип схем — лишь некий псевдо-ДРАКОН (без всяких строгостей), то параллельность иногда выделяли объединяющими линиями, удобными в конкретном случае (в общем, как-то связывали квадратики, лишь бы было понятно). А в этой теме как раз всплыла проблемность адекватного указания параллельных процессов (или действий).
Короче говоря, кратко по порядку. Все рисунки взяты из этой темы.
Меня интересует, прежде всего, возможность демонстрации параллельных действий и их возможная синхронизация, поэтому для меня интересна представленная там задача про "последний этап строительства дома". Сначала Паронджанов предоставляет схему в таком виде:
Затем схема оптимизируется (якобы упрощается), Владимир Даниелович выбрасывает треугольники и предоставляет заявленный эргономичный вариант:
Сугубо моё личное имхо: стало ещё хуже. Треугольники как-то явно указывали на то, что выполняется слияние или синхронизация процессов, тем более, что в ДРАКОНе принято действия определять через иконы. Нарушается также ещё одно религиозное табу ДРАКОНа: имеем пересечение линий (от самого автора стандарта). Кроме того, например, не очень-то очевидно, что действия "Прокладка электропроводки" и "Прокладка водопровода" оба ждут завершения "Монтаж электрощита". Без треугольников как-то и непонятно, что "Отделочные работы" начнутся после завершения всех четырёх действий над ним. Одним словом, наглядность хромает, особенно для неподготовленного человека.
Я также глянул и эту тему про сравнение Дракона со всякими другими, но адекватного изображения параллельности там тоже не нашёл. Посмотрел на редактор Тышова. Как я понимаю, он реализовал визуализацию параллельности на основе гостов для блок-схем:
В результате можно рисовать так:
(два последних рисунка предоставлены Тышевым в исходной теме)
Несмотря на то, что схема справа на последнем рисунке оптимизирована и более компактна, схема слева, всё-таки, более наглядна. Но главное, я как-то не могу "въехать", как же здесь указать то, что "Монтаж электрощита" является "предком" одновременно для "Прокладка электропроводки" и "Прокладка водопровода".
Такая же "непонятка" и с Р-схемами. Я хотел нарисовать схему, но сразу же "приехал":
Как нарисовать дальше синхронизацию процессов — опять "не врубаюсь". К тому же здесь есть некий эффект того, что надписи под дугами воспринимаются как текст внутри какой-то таблицы, что-ли. И в целом, "стандартный" редактор рисует не очень наглядно:
Если убрать выделение надписей цветом — будет ещё хуже. Нужно схемы как-то расширять, но тогда компактность пропадает.
А в исходной теме самым лучшим вариантом для задачи про дом оказалась схема UML (диаграмма деятельности), предоставленная Эдуардом Ильченко:
Несмотря на то, что именно эта схема повлияла на идеи Паронджанова, ДРАКОН пока хромает в этом направлении (хотя, возможно, сейчас есть что-то стоящее, я не в курсе). Также вот такие черточки-разветвители/соединители, как и в сетях Петри, нужно прикручивать и в Р-схемах (в случае необходимости, кому нужно).
Одним словом, нет пока счастья.
PSV>>- В Р-схемах можно придумать, как задать силуэт ДРАКОНа, только шампура будут расположены горизонтально. Получим "мангал-метод" VZ>Есть такое — "синт-силуэт" — можно видеть здесь. Кстати, применение в такой схеме, наряду с "синт-переключателями", ОС-узлов (суть IDEF3-"перекрёстков"), может помочь адекватному представлению непрограмvно строгих описаний (скажем, текстовых НД) — говорил здесь.
К сожалению, это из разряда "много букв — не осилил", к тому же те картинки в мозг никак не грузятся. Здесь без поллитры не разобраться (говорю так, ибо стоящий рядом бокальчик с коньячком не помогает ). Не хватает времени со всем этим разобраться, могу сказать одно, что, если такие "синт-силуэты" ввести в "стандарт" ДРАКОНа, то ДРАКОН превратится в "графический С++". Это будет поводом для написания книг вида "ДРАКОН для профессионалов", "Эффективное программирование на ДРАКОНе" и т.п., и самое главное — "Как нельзя программировать на ДРАКОНе" .
PSV>> ... когда программа на Питоне "вписана" в графическую схему — для программистов ненаглядны: это что-то вроде зарисовки математических формул вместо их прямого написания, что, возможно, пригодно лишь для образовательных целей. VZ>А что будет нагляднее? Возможно, структурные скобки, как здесь?..
Подобные скобки рисуют текстовые редакторы/IDE (т.е. вертикальные линии для отступов, выводят и подсказки для них, когда парная граница блока не видна на экране), к этому можно добавить свёртку кода, хорошее форматирование и автовыравнивание текста и т.д. — всё это хорошие помощники. Кстати, я не в курсе, что это за PureBuilder такой. Если это какой-то очередной структурный построитель кода, когда код рисуется (именно рисуется) как блок-схемы, только вместо квадратиков "рисуются" ключевые "словесные иконы" как "if", "while" и т.п. — то это издевательство над программистом. Не нужно отбирать у него нормальный текстовый редактор.
Но речь идёт не о помощниках, а, в принципе, о восприятии текстовой информации в виде языка программирования. Вот рисунок Р-схемы (из этой статьи):
Я, как программист, мгновенно понимаю алгоритм на основе текста слева, и лишь понимание текста программы мне дает представление о том, как работают дуги в виде двойных линий, указывающих на цикл.
Не знаю, как объяснить словами. Могу сказать то, что рисовать блок-схемы для программиста — это тоже самое, что заставить математика рисовать эти схемы вместо записей формул при решении уравнений, доказательств теорем и т.д. Сейчас всё больше и больше появляется средств для декларативных указаний действий, обычно программист не будет реализовывать код так, как этот код сгенерирует транслятор "в лоб" из того же ДРАКОНа. К тому же, есть много факторов, которые косвенно влияют на "ощущение" алгоритмов, например, понимание структуры тех же классов, видение рядом аннотации типов и т.п. Есть и много технических проблем с визуальными средствами. По своему опыту скажу, что ни всякие RAD-средства для построения интерфейсов или для бумажных отчётов, ни ER-диаграммы баз данных, ни рисовалки UML- и всяких блок-схем и прочие визуальные рабства не спасают отцов русской демократии, особенно если нужно оперировать многими сотнями сущностей, постоянно их переделывая.
Но иногда, как и математикам, необходимо видеть "геометрические фигуры". Я предпочту созерцать именно инженерные схемы, или схемы "про рыбалку", где будет только поясняющий краткий текст. Если в блок-схеме будет "вписана" программа на конкретном ЯП, да ещё и с явными ключевыми словами "if", "for", "while" и пр. — это масло масляное, что годится м.б. для образовательных целей.
Вот только схем, которых поймёт любой человек с первого взгляда, и для работы с которыми нужно всего десять минут на освоение правил, да и создание схем удобное на уровне написания обычного текста, — пока таких не видно, увы...
Здравствуйте, PSV100, Вы писали:
... PSV>Спасибо за эту ветку, весьма кстати. Раньше параллельностью мы у себя особо не заморачивались, т.к. составление схем происходит эпизодически и тип схем — лишь некий псевдо-ДРАКОН (без всяких строгостей), то параллельность иногда выделяли объединяющими линиями, удобными в конкретном случае (в общем, как-то связывали квадратики, лишь бы было понятно). А в этой теме как раз всплыла проблемность адекватного указания параллельных процессов (или действий).
PSV>Короче говоря, кратко по порядку. Все рисунки взяты из этой темы.
PSV>Меня интересует, прежде всего, возможность демонстрации параллельных действий и их возможная синхронизация, ... PSV>... Треугольники как-то явно указывали на то, что выполняется слияние или синхронизация процессов, тем более, что в ДРАКОНе принято действия определять через иконы. Нарушается также ещё одно религиозное табу ДРАКОНа: имеем пересечение линий (от самого автора стандарта). Кроме того, например, не очень-то очевидно, что действия "Прокладка электропроводки" и "Прокладка водопровода" оба ждут завершения "Монтаж электрощита". Без треугольников как-то и непонятно, что "Отделочные работы" начнутся после завершения всех четырёх действий над ним. Одним словом, наглядность хромает, особенно для неподготовленного человека.
PSV>Я также глянул и эту тему про сравнение Дракона со всякими другими, но адекватного изображения параллельности там тоже не нашёл. Посмотрел на редактор Тышова. Как я понимаю, он реализовал визуализацию параллельности на основе гостов для блок-схем:
... PSV>Несмотря на то, что схема справа на последнем рисунке оптимизирована и более компактна, схема слева, всё-таки, более наглядна. Но главное, я как-то не могу "въехать", как же здесь указать то, что "Монтаж электрощита" является "предком" одновременно для "Прокладка электропроводки" и "Прокладка водопровода".
...
PSV>Если убрать выделение надписей цветом — будет ещё хуже. Нужно схемы как-то расширять, но тогда компактность пропадает.
PSV>А в исходной теме самым лучшим вариантом для задачи про дом оказалась схема UML (диаграмма деятельности), предоставленная Эдуардом Ильченко:
Да, конечно. Она и есть модификация сети Петри, кстати. PSV>Также вот такие черточки-разветвители/соединители, как и в сетях Петри, нужно прикручивать и в Р-схемах (в случае необходимости, кому нужно).
Тут ещё штука в том, что схемы деятельности, допускающей параллелизм — доалгоритмические. В терминах ВД можно сказать, что они развёртываются в общем случае более, чем одной "рабочей точкой" ("дракон-поездом"). Потому и м.б. нужна синхронизация. По определению мне кажется удачным "системы совместно протекающих [взаимодействующих] процессов" (СПВП)- как здесь в Гл. 4.
Так что и язык схем систем процессов отдельный — грубо говоря, это язык сетевых графиков. И такие схемы — ДД, СП и любые другие — в смысле структуры м.б. сложнее, чем графы устремлённые, как говорит Ермаков. Потому в общем случае пересечения на плоскости там не устранишь. Но никакой алгоритм там не описывается — алгоритмы представляются блоками работ.
А уже алгоритм каждого блока можно описать на техноязыке или как-то ещё — и это уже будет устремлённый граф. Так я это понимаю. И он развёртывается единственной "рабочей точкой" — представлением исполнителя данной конкретной работы (экземпляра)в текущем его состоянии.
И как раз разнесение на разные типы схем помогает компактности.
Порядок работ указывается связностью блоков работ через узлы расщепления/слияния "рабочих точек". ДД в этом смысле ничем не отличается.
Условия синхронизации, конечно, следует как-то фиксировать — это я и предлагал в МШ-языке. Да, это не будет компактно — но эти атрибуты м.б. скрытыми — как говорил и Усов.
В принципе можно устранять пересечения, вписывая СПВП-схему в силуэт — там в ветке тоже показывали, как. Но получается несколько громоздко — надо думать.
А вот другие базовые принципы — направленности линий прежде всего — из шампур-метода стоит взять. Тогда как раз нужны "линейчатые" формы управляющих вершин — как и принято для ОС-узлов.
PSV>Несмотря на то, что именно эта схема повлияла на идеи Паронджанова, ДРАКОН пока хромает в этом направлении (хотя, возможно, сейчас есть что-то стоящее, я не в курсе).
Пока о чём-либо, кроме обсуждавшегося выше Z-языка, мне не известно.
Кстати, есть ещё разновидность языка описания СПВП — кратко описана здесь в Гл. 8. Думаю, и это Вас не вполне удовлетворит.
Здравствуйте, PSV100, Вы писали:
... VZ>>Есть такое — "синт-силуэт" — можно видеть здесь. Кстати, применение в такой схеме, наряду с "синт-переключателями", ОС-узлов (суть IDEF3-"перекрёстков"), может помочь адекватному представлению непрограмvно строгих описаний (скажем, текстовых НД) — говорил здесь.
PSV>К сожалению, это из разряда "много букв — не осилил", к тому же те картинки в мозг никак не грузятся. Здесь без поллитры не разобраться (говорю так, ибо стоящий рядом бокальчик с коньячком не помогает ). Не хватает времени со всем этим разобраться, могу сказать одно, что, если такие "синт-силуэты" ввести в "стандарт" ДРАКОНа, то ДРАКОН превратится в "графический С++". Это будет поводом для написания книг вида "ДРАКОН для профессионалов", "Эффективное программирование на ДРАКОНе" и т.п., и самое главное — "Как нельзя программировать на ДРАКОНе" .
...
Вот при допущении пересечений такое возможно — говорил здесь.
Не-не, синт-силуэт — это не "для ДРАКОНа" — т.е. не для описания потоков управления. Это именно для столь же упорядоченной записи синтдиаграмм. Ну и также различных классификаций, словарей, вообще структурированного текста. Или отображения документа как структуры из оглавляемых частей — как говорил здесь. В редакторе группы В. Лаптева для этого же предполагается синт-дерево документа показывать — см. в этом посте.
Здравствуйте, PSV100, Вы писали:
... VZ>>А что будет нагляднее? Возможно, структурные скобки, как здесь?..
PSV>Подобные скобки рисуют текстовые редакторы/IDE (т.е. вертикальные линии для отступов, выводят и подсказки для них, когда парная граница блока не видна на экране), к этому можно добавить свёртку кода, хорошее форматирование и автовыравнивание текста и т.д. — всё это хорошие помощники. Кстати, я не в курсе, что это за PureBuilder такой. Если это какой-то очередной структурный построитель кода, когда код рисуется (именно рисуется) как блок-схемы, только вместо квадратиков "рисуются" ключевые "словесные иконы" как "if", "while" и т.п. — то это издевательство над программистом. Не нужно отбирать у него нормальный текстовый редактор.
Нет, это не то, что здесь показано (если я верно Вас поонял). А именно замена подмножества ключевых слов текстового языка, которое ВП называет "маршрутным", на [псевдо]графику скобочных линий. Графики вершин не вводится; следование представляется смежностью строк текста в колонке.
РВ-проект — это предложение по языку и редактору от С. Прохоренко. Материал проекта испльзуется и в практике — см. этот пост.
PSV>Но речь идёт не о помощниках, а, в принципе, о восприятии текстовой информации в виде языка программирования. Вот рисунок Р-схемы (из этой статьи):
PSV>
PSV>Я, как программист, мгновенно понимаю алгоритм на основе текста слева, и лишь понимание текста программы мне дает представление о том, как работают дуги в виде двойных линий, указывающих на цикл. Не знаю, как объяснить словами.
Да. конечно, Р-схемы не слишком наглядны...
PSV>Могу сказать то, что рисовать блок-схемы для программиста — это тоже самое, что заставить математика рисовать эти схемы вместо записей формул при решении уравнений, доказательств теорем и т.д.
Да, есть и такая ветка... Причём, как можно видеть, представление доказательств схемами — старая идея.
PSV>Сейчас всё больше и больше появляется средств для декларативных указаний действий, обычно программист не будет реализовывать код так, как этот код сгенерирует транслятор "в лоб" из того же ДРАКОНа. К тому же, есть много факторов, которые косвенно влияют на "ощущение" алгоритмов, например, понимание структуры тех же классов, видение рядом аннотации типов и т.п. Есть и много технических проблем с визуальными средствами. По своему опыту скажу, что ни всякие RAD-средства для построения интерфейсов или для бумажных отчётов, ни ER-диаграммы баз данных, ни рисовалки UML- и всяких блок-схем и прочие визуальные рабства не спасают отцов русской демократии, особенно если нужно оперировать многими сотнями сущностей, постоянно их переделывая.
Как я подозреваю, немаловажно здесь то, что ещё всё эти переделки в схемах напрямую ведь не связаны с собственно программой? Ибо для всех названных языков нет точного программно-текстового эквивалента?..
Да, а как же программист будет реализовывать?.. У него же всё равно получится исходный текст... что мешает именно этот текст записать на частично графовом языке... эквивалентном?..
Вот Дмитрий_ВБ строит схему по прогтексту — см. утилиту к его среде здесь... "Ракетный дизайнер кода" тоже это умеет, как показывает деморолик...
PSV>Но иногда, как и математикам, необходимо видеть "геометрические фигуры". Я предпочту созерцать именно инженерные схемы, или схемы "про рыбалку", где будет только поясняющий краткий текст. Если в блок-схеме будет "вписана" программа на конкретном ЯП, да ещё и с явными ключевыми словами "if", "for", "while" и пр. — это масло масляное, что годится м.б. для образовательных целей.
Да, нужно чётко выделить структурную часть текстового языка и именно заменить её представление на нетекстовое. И продумать свёртку полного представления до укрупнённого в той или иной степени. В РВ, кстати, для этого предлагается механизм, как в "файловом обозревателе" — свёртка/развёртка ветвей структуры управителями по типу линуксовых...
Здравствуйте, PSV100, Вы писали:
PSV>Здравствуйте, VladZharinov, Вы писали:
VZ>>[...]
PSV>Благодарю за оказанное внимание и предоставленные материалы. Необходимо выделить время, чтобы это всё переварить, поэтому пока без комментариев.
PSV>Спасибо.
Уж извиняюсь, но некоторые уточнения — сразу всё не сформулировалось...
1. При описании систем процессов, конечно, не только работы развёртываются в алгопроцессы, но и "чёрточки". Их смысл, ессно — управление ресурсами для работ (назначение/снятие исполнителей). Блинов, ака Рэйлвей Каген (автор своего языка описания СПВП, выполняющего ту же роль, что и МШ-язык), называет это "алгоритмической расшифровкой". Он же в упомянутом посте предложил её вариант.
Кстати, в рамках ГРАФКОНТ-методологии используется свой тип моделей систем процессов — т.н. логико-временные схемы. В реализации называются многовходовыми моделями — вид был в этом примере (для всё той же "инженерной схемы" Паронджанова).
"Расшифровка" базируется на механизмах взаимодействия. Любых известных — семафоры, сообщения etc. Так, Вирт предлагал свой вариант — можно видеть в выдержке отсюда. Механизмы в общем рассматривались в классических "Концепциях и принципах ЯП" — см. выдержки здесь.
2. Из сказанного о РВ-языке не совсем ясно — заменяют ли структурные скобки по С. Прохоренко "маршрутные" ключевые слова? Если при уточнении окажется, что нет — то тут я, конечно, соглашусь с Вами — должны заменять. Почему — можно видеть и из дальнейшего.
Кстати, такое "масло масленое" ти для учебных целей не имеет смысла. Но для любых, думаю, имеет в одном частном случае — когда предметом описания служит асмкод. Тогда м.б. удобно вписывать команду целиком (с мнемоникой) в вершину. Ибо мнемоника обычно лишь частично имеет "маршрутный" смысл. Пример можно найти в этом пункте.
3. В примере, который Вы уже могли видеть, есть ошибки. В дальнейшем они были описаны здесь (ответ Б5). И вот что м.б. интересно для данного топика. Часть их была включена сознательно — но другая (около половины) действительно допущена при сочинении. А выявлена более-менее быстро — в основном при первом-втором просмотре готового описания. И тут важную роль сыграло именно то, о чём Вы говорите — что: 1) не следует дублировать текст, и так представляемый графом; 2) надо иметь аналогично представленные неалгоритмические компоненты модели.
Скажем, текст в вершинах визуалов только "выраженьевый" — и ты уже сосредотачиваешься на правильности этих выражений — а структуру маршрутов проверяешь по виду схемы. Аналогично структура типов задана видом схем и их связями — и по ним смотришь, скажем, правильно ли "по-Обероновски" расширил запись.
По поводу редактора — важно, чтобы он поддерживал связность всех компонент и учёт их употребления.
Здесь на форуме VladZharinov представил незнакомый мне ранее язык Amber для описания бизнес-процессов (здесь, гл.8). Также есть ещё публикации:
— здесь материалы от авторов языка;
— здесь небольшой учебник;
— здесь кроме Amber есть пару слов и о NEML — близкий к нему язык (также в документе встречаются и др. технологии);
— здесь ещё один пример интеграции Amber c Promela для верификации моделей и пр.
Есть в инете и ещё материалы. Я выкладываю здесь идею, как можно по мотивам Amber и используя ряд принципов из ДРАКОНа описать попроще (надеюсь) выполнение действий, с учётом их возможного совместного протекания. Возможно, кто-то увидит для себя что-то полезное из тех, кому необходимо подрисовывать всякие процессики и нет приколачивания гвоздями к стандартам UML, IDEF... и пр. Кстати, здесь можно познать небольшое сравнение "ынтырпрайза".
Язык, на мой непрофессиональный взгляд, представляет собой переработанные диаграммы активностей UML (скорее всего, и ещё что-то повлияло, я не спец). Выглядит так:
Это простейшая схема с циклом. Здесь посерьёзнее:
Короче говоря, в Amber всякого хватает. Ключевой момент — это использование блоков разветвления и слияния процессов, на манер типовых перекрёстков как в IDEF3 и ряда других языков для workflow, или признаков переходов/соединения в YAWL. Но здесь есть вполне адекватное упрощение: вместо трёх типов — AND, OR, XOR — которые взрывают моск у обычных ни в чём неповинных людей, используется только два вида — AND и OR. Имхо, их должно хватать, XOR можно выразить косвенно, к тому же их и проще зарисовать.
В общем, в языке описания процессов предлагается следующее:
— "кружочки" — действия, операции и пр., т.е. аналог квадратиков из ДРАКОНа и блок-схем;
— "растянутые кружочки" — те же действия, но "растянуты" из-за надписи внутри, похожи на заголовки в ДРАКОНе;
— "полукружочки" или "разорванные кружочки" — могут указывать на действия участников процесса как логическая связь между ними, можно выразить цикл "ДЛЯ", реализовать аналог "выбора" и "варианта" — "переключатель" в ДРАКОНе;
— "кружочки с картинкой" и пр. символами + надпись — в качестве альтернативы для таких композитных икон вида:
Такие иконы наглядны, но требуют больше места, в т.ч. и вокруг себя. Хотя вполне тоже можно использовать сложные иконы;
— "линии" — дуги графа как в ДРАКОНе, с небольшим исключением (см. ниже). Как и в ДРАКОНе, в отличие от Amber, UML и пр., лучше не использовать надписи на линиях кроме вида "да/нет";
— "закрашенный квадратик" — соединитель "И": процесс продолжится, когда все запущенные входные действия будут завершены;
— "пустой квадратик" — соединитель "ИЛИ": процесс продолжится, когда хотя бы одно из входных действий будет завершено;
— "закрашенный ромбик" — разветвитель "И": все выходные действия выполняются;
— "пустой ромбик" — разветвитель "ИЛИ": запускается хотя бы одно из выходных действий;
— "усеченный ромб" с надписью — аналог "вопроса" из ДРАКОНа, это частный случай "пустого ромбика", когда условие вписано в сам разветвитель. Вполне возможно, что лучше не использовать этот "вопрос", чтобы схемы были в одном стиле. Если необходимо иметь рядом много вопросов, то можно использовать "переключатель", который располагается и горизонтально и можно вывернуть его и вертикально.
Для "кружочка" возможен только один выход на другое действие или как петля цикла, но необходим отдельный выход на каждый требуемый соединитель. В этом случае, фактически, не избежать пересечений линий, и лучше разрешить пересечение (на входах соединителей). Необходимы отдельные выходы и для разветвителей. Лучше также разрешить и наклонные линии для разветвителей/соединителей;
— из ДРАКОНа используются ветки (шампура) и силуэт. Например, здесь есть несколько сравнений диаграмм в различной нотации с аналогичными ДРАКОН-схемами, можно заметить, что попытка упорядочить/разделить элементы схемы даёт эффект.
Короче говоря, схематично язык выглядит так (сорри за ручную мазню, но так проще и быстрее):
Возможна горизонтальная направленность:
Можем использовать акторов/сущностей модели как-то так:
Кружочки, полукружочки, квадратики и ромбики — просты и хорошо различимы, ими можно вертеть в разные стороны. В каком-нибудь редакторе схем можно реализовать режим, когда "растянутые кружочки" сжимаются, т.е. убирается надпись, внутри можно оставить лишь идентификатор иконы, можно кратко подписать вершины, т.е. привести схему к компактному виду (как первый рисунок в этом эпосе). И как-то легче воспринимается рисунок, когда много кружочков чуть разбавлены квадратиками и ромбиками, чем когда имеем много маленьких квадратиков (как действия) и кружочки-переходы. Такие символы из Amber и ДРАКОНа можно использовать и для построения других диаграмм, как диаграмма последовательности и пр. http://files.rsdn.ru/91237/diagram_actor.PNG
Имхо, получился модифицированный ДРАКОН, не же ли развитие Amber. Пока нет чётких формальных правил для обеспечения полноценности, непротиворечивости, работоспособности и т.д. И неизвестно пока, будут ли практические разработки для реальной работы.
По поводу способа рисования схем. Я лично не нашёл удобного и практичного инструмента. Типовые графические редакторы годятся для использования сотрудниками всяких отделов маркетинга, которые только и занимаются рисованием креативных диаграмм (организовывают важные совещания, где долго решают, каким же цветом рисовать свои квадратики, а через полгода делают "прорыв": те же квадратики теперь рисуют новым гламурным цветом).
Здесь на форуме VladZharinov давал ссылку на "Ракетный дизайнер кода" (ролик). Да, это самый эффективный способ, особенно если это адекватный плагин для уже используемой IDE (редактора). Текстовый язык позволяет как-то всё увязать: основной программный код (в моём случае кружочки с линиями не превращаются в программу на Обероне и не "прошиваются" в контроллер, всё размазывается на кучу софта — базы данных, серверный и клиентский код и пр.), систему контроля версий, сборки, баг-трекинг, вики и т.д. К тому же "программирование" полезно, если задействована реальная технология, т.е. схемы не с потолка рисуют с произвольным текстом про рыбалку, а манипулируют объектами из какого-нибудь "флокса".
Но есть проблема с форматом этого языка. Структурные описания как XML, json, s-выражения и пр. проблематичны для ручной правки, особенно при многих уровнях вложения. Программный псевдо-язык или DSL на основе ключевых слов "если", "цикл", "конец" и т.д. (или англ. слова) трудновато воспринимается, особенно когда необходимо быстро сопоставить видимый текст на экране с рисуемым рядом куском схемы.
Есть мысли использовать текстовый DSL как линейный список команд для манипулирования объектами диаграммы, некий "ассемблер" для схем, что-то по мотивам:
— первая: "д" — действие, т.е. добавляем кружок для текущей позиции, до "\" — текст действия, после — комментарий (хинт) кружочка;
— вторая: "ври" — вставить разветвитель "И" в позицию "12.4".
Тогда можем работать глядя на схему, для ввода текста достаточно небольшого окошка консоли. Схема сохраняется как прямой список команд для её построения (т.е. не так как мы вводим в процессе работы). Здесь автокомплит и всякие сниппеты помогут.
К тому же подобный язык поможет реализовать что-то вроде вимператора для графического редактора, для тех же доступных ДРАКОН-редакторов, например. Кто не в курсе: вимператор — это плагин для FireFox, который реализует управление броузером как в виме (можно демки глянуть, есть его форк, популярен и эмакс для FireFox). Такое расширение даст и удобную быструю работу через клавиатуру, и быстрый выбор/выделение объектов в схеме и выполнение операций над ними через так называемый "following links", быстрый ввод команд через комстроку с автокомплитом и пр. плюшками и т.д. В общем, это отдельная тема.
Спасибо за полезную "нагрузку", пришлось перелопатить сайт OberonCore и прочие материалы и не один раз (к сожалению, это проблематично, ибо сейчас у меня совсем другая нагрузка, далёкая от "рисования"), но не зря.
По поводу PureBuilder. Такие структурные скобки, дающие некий эффект направленного графа в программном коде, вполне могут дать наглядность в языках, подобных используемому в этом проекте, или, действительно, близких к ассемблеру. Нечто похожее могут рисовать ряд редакторов/IDE, например так:
Здесь на рисунке слева видно, что область "if" выделяется зеленоватым цветом, "for" — коричневатым и т.д. На правом рисунке есть мнемонические индикаторы (на поле слева от области с текстом): синия стрелка — "break", красная — выход по "return". Вполне адекватные помощники. Но увидеть некий полный "граф" всей программы/модуля как-то проблематично, т.к. в большинстве случаев текст не вмещается на один экран. К тому же в языках с развитой декларативностью (где всё больше и больше появляются черты функциональных языков, как списочные выражения, использование лямбд и т.д.), подобный граф ("драконовский поезд") уже толком не нарисуешь. Также такие скобки теряют наглядность, когда концы блоков не видны на экране. И лишняя разноцветность линий, если она используется, тоже как-то напрягает. "Попугайство" полезно, например, на рисунке справа: внизу введено много скобок (для демонстрации), разные цвета облегчают поиск парной скобки (но здесь не очень удачная цветовая схема). Лично я подобные структурные выделения обычно не использую, стремлюсь к минимализму на экране перед собой. Мне достаточно не ядовитой адекватной раскраски кода, когда глаз цепляется за ключевые слова, помогают и отступы и прочее форматирование. Весьма полезно видеть рамки блока по требованию, например, на рисунке слева курсор установлен на нижнюю фигурную скобку цикла, редактор выделяет парную границу блока: нужный текст выделяет рамкой и слева (там где номера строк) рисует "структурную скобку", но в данном случае верхняя граница не видна, поэтому нет рамки и "обрублена" скобка, а внизу в строке статуса редактор пишет подсказку — "Matches line ....". Также границы блоков можно выделять и постоянно, например, через ненавязчивое подчёркивание (особенно полезно для случаев работы с XML-подобными тэгами).
Одним словом, при работе с текстом решающее значение имеют ключевые слова. Подобные структурные выделения могут быть лишь хорошими "помогалками", и то не всегда они удобны/уместны.
По поводу графических языков описания процессов. Меня действительно интересуют языки для "изображения" бизнес-процессов или материальных, не же ли техноязык, как таковой. Попытки "расширить" ДРАКОН для указания параллельных действий пока закончились не успешно, хороший готовый вариант пока не попался на глаза. Кстати, попробовал эксперименты с "рядовыми смертными" (небольшое количество). Декларации Z-языка:
некоторых (и вроде не глупых) вводят в ступор: им нужно время, чтобы "въехать", и то, большая часть так и не понимает самостоятельно правильную последовательность. Не легче им и с вариантом "на треугольниках".
Остальные варианты, найденные на OberonCore, также дали мало эффекта. Например, идеи использования многоадресных переходов позволили мне нарисовать Р-схему в таком виде:
При этом для "смертных" она оказалось понятнее оригинала. А сами Р-схемы, после небольшой возни с ними, уже утратили своё главное потенциальное достоинство — компактность. Всё-таки мало кайфа при их рисовании через текстовую псевдографику, они также громоздки. А были надежды на то, что подобные схемы можно прикрутить к какому-нибудь org-mode и составить "конкуренцию" для РДП-документов и подобных графит-моделей, (кстати, org-mode в эмакс реальная мощная конкуренция, и, главное, практичная. Эта тема форума начиналась с примеров из статьи об этом проекте, есть попытки реализовать часть функционала и для других редакторов попроще, что-то было для Sublime, JEdit). К тому же, гламурность у Р-подобных схем страдает, "большому начальству" нужны цветные квадратики с градиентами и тенями, с распечаткой а-ля матричный принтер лучше к нему не подходить.
Идеи из предложенного МШ-языка по поводу блоков расщепления и соединения интересны, но, действительно, очень громоздко. К тому же далеко не всегда необходимо "на месте" раскрывать сущность как именно происходит совместное протекание процессов, в большинстве случаев достаточно просто показать, что они параллельны, все подробности лучше раскрывать отдельно. И по причине громоздкости не очень наглядны и "синт-силуэты", когда большие квадраты с текстом соседствуют с мелкими квадратиками и повязаны они линиями. Как-то лучше, если всё разделить. Вот в этой теме есть хороший "вынос" справочной информации. Если говорить о редакторе/IDE для схем, то было бы не плохо иметь механизм для быстрого показа "раскрывающей" диаграммы, что-то вроде code bubbles, как в этом прототипе (хотя большую часть функционала из этого Light Table можно реализовать и сейчас в эмаксе/виме/JEdit и пр., в этом проекте также интересны идеи и для отладки, которые можно прикрутить и для техноязыка как ДРАКОН).
Типовые блоки разветвления и соединения, как в IDEF3 (и представленные ОС-узлы тоже), как-то не очень доступны "рядовым", когда они имеют аж три типа: AND, OR и XOR. Понравилась идея в YAWL, когда и действие/состояние, и переход/соединение задаётся одной вершиной графа. Но в YAWL эти признаки соединения/разветвления уж слишком замудренно рисуются. Кстати, YAWL и Р-схемы показали, что в большой диаграмме с множеством элементов ощутимо снижается наглядность, если надписи разных сущностей располагать покомпактнее. Здесь я соглашусь с ВП, лучше иметь квадратики с текстом, тогда их можно расположить поближе друг к другу.
А вот знакомство с Amber оказалось полезным. Идея в этом языке иметь узлы разделения/соединения только двух типов: AND и OR — вполне себя оправдывает, при этом поверхностная проверка показала, что рядовые смертные эти блоки вроде как "проглатывают" более-менее нормально. В общем, Amber навёл на мысли как зарисовывать процессы. Об этом я написал в соседнем топике
Пожалуйста. На самом деле по математике-то схем почти ничего не было сказано. Вообще-то главное в этом смысле — что есть различные математические структуризации систем процессов и соответственно классы формализмов их описания. Имея в виду, что схема м.б. описана и текстом (как и операции над ней) — потому и говорим просто об "описании".
Навскидку есть два класса:
GAN — структуры с возможностью циклов;
сетевые графики — ациклические.
О разнице между ними писал здесь, а подробнее — здесь в п. А).
В GAN преобразования (в частности, упрощения) структуры возможны, но достаточно громоздки.
По типам узлов — на самом деле И/ИЛИ — это ведь "выполнить от одного до всех". Так что можно как раз два других свести к нему...
Здравствуйте, VladZharinov, Вы писали:
PSV>Спасибо за "матподготовку".
VZ>Пожалуйста. На самом деле по математике-то схем почти ничего не было сказано. Вообще-то главное [...]
Да я не про математику, а про материальную подготовку, "матчасть", так сказать...
И по поводу матчасти. Появилось практическое опробование последних идей по поводу описательного языка алго/процессов, поэтому я поднял эту темку форума и поделюсь небольшими результатами.
Под впечатлением от Amber была попытка рисования схем по мотивам, указанным мною в соседнем посте
— от концепции "акторов" (последний рисунок в том посте) мало толку. В UML между "плавательными дорожками" граф действий может бегать туда-сюда и куда угодно (что не очень-то наглядно), но если пытаться придерживаться наглядности ДРАКОНа, то мы очень ограничены в области для взаимодействия акторов. Кроме того, если уже есть один способ для группировки элементов схемы — ветки силуэта — то лучше и иметь только одну сущность, путаница не нужна. Одним словом, если а-ля "драконить", лучше от акторов отказаться;
— Наличие разных "ромбиков" — маленьких и ромба с текстом (вопрос) — вводит неоднозначность в стиль языка. Необходимо отказаться от усеченного ромба с текстом, но в большинстве случаев (для развилок "да/нет") тогда требуется больше места по вертикали;
— Разные "квадратики", т.е. попытка как-то обозначить принцип синхронизации действий, лишний раз заставляют задуматься в тех случаях, когда логика соединения не такая однозначно простая как "ждём всех" или "хотя бы одного". Имхо, лучше, когда в схемах есть возможность просто обозначить сам факт слияния/разделения без никаких намёков о самой алгоритмике (т.е. просто показать последовательность действий во времени) и есть возможность кратко показать суть соединения/запуска, при этом оба способа должны быть идентичными;
— "Ромбики" и "квадратики" выглядят как-то "не к месту" в таких "тяжёлых" случаях, как этот:
Рисунок не очень-то нагляден, здесь суть в том, что если использовать наклонные линии, то они должны быть под 45 гр., тогда они более приятны глазу при входе/выходе в/из ромбик/квадратик, а это требует больше места по вертикали. В таких случаях чёрточки UML приятнее, да и нет разделения на разные элементы соединения/слияния:
По поводу этого "леса" линий. Имхо, это основная головная боль, если алгоритмическую нотацию ДРАКОНа и блок-схем для одного исполнителя пытаться раздуть до описания процессов с душком параллельности. Разводить этот лес по веткам силуэта не всегда удобно/наглядно/необходимо. Иногда схему рисуют для того, чтобы компактно и доступно показать запутанную ситуацию, разброс по силуэту только ухудшает понимание. С разделением процессов как-то проще, здесь и двойные линии по ГОСТу "перевариваются", а вот как чуть сложное соединение — сразу беда. Гораздо хуже вместо наклонных линий использовать свалку из ломаных горизонтальных и вертикальных маршрутов, шин и ещё хуже — развилок, когда из вертикальной линии идём направо и налево. Были попытки заменить "лес" подсмотренными на Драконографике соединителями вида:
Здесь пунктирные линии для соединения лучше не рисовать, тот же лес получим. В реальной схеме подобная конструкция выглядит громоздко, и не "по-драконовски" как-то. Кстати, эти соединители-переходы могут оказаться полезными, вместо плясок по силуэту иногда проще нарушить правила ДРАКОНа при описании реальных материальных процессов (не при составлении алгоритмов для расчётов, скажем).
Если говорить о средствах "распараллеливания" ДРАКОНа, то лучшим найденным вариантом, имхо, является предложенный Вами "мульти-шампур", несмотря на главный недостаток — огромные "квадратики". Идеи на основе соединительных и разделительных линий (жирных, двойных и пр.) применимы только в простых ограниченных случаях, ненаглядны и различные "мультиадреса".
А попытка использовать Amber-мотивы себя не оправдала. "Ромбики" с "квадратиками" выкинули и в очередной раз поигрались с чёрточкой из UML внутри ДРАКОНа:
Здесь есть и "мульти-шампура", и "множественный выбор" (в ветке "С"). Недостаток этих чёрточек. Во-первых, нужны какие-то формальные ограничивающие правила для составителя по поводу использования наклонных линий при соединении/разделении. Если использовать строгие драконовские маршруты, которые часто в таких случаях окажутся "шибко ломаными" — будет ещё хуже. Во-вторых, в сложных случаях соединения "леса" не избежать, и этот лес также требует приличного места по вертикали, к тому же иногда чёрточки из "леса" лучше убрать: будет даже проще, если линии работают "без посредников", т.е. от квадратика к квадратику.
Одним словом, замены для своего "наколенного дракона" пока не нашлось. А ДРАКОН у нас "скатился" к такому виду:
Это, конечно, не направленный граф, а так, "протокол о намерениях", это антидракон высшего порядка. Иногда и адреса/заголовки шампуров не рисуются, если есть только последовательный переход с ветки на ветку. Все ромбики и прочие фигурки выкинуты, только одни квадратики. Так банально проще рисовать и есть возможность для любого произвола. Для сравнения, если рисовать с ромбиками и пр.:
У любого, кто знаком с блок-схемами, появится ощущение ошибки природы. Сплошные квадратики эту ошибку скрывают. Такой беспредел позволяет показать и сложный "лес" соединений, и, в целом, составить схему по-компактнее и более содержательно, да и меньше "попугайства", что ли. Понимание сути основывается на содержательном тексте внутри квадратиков, исходящие/входящие линии — лишь подсказка. К примеру, если из квадратика исходят несколько линий, значит далее выполняется разделение процессов, а в самом квадратике может быть указана логика этого разделения (аналог блока расщепления из МШ-языка) или просто некое действие (т.е. не раскрываются алгоритм/условия и пр. параллельности). Иногда участок схемы выделяется квадратиком с примечанием (аналог "областей" из Драконографики) и раскрывается отдельной, более подробной схемой (в т.ч. так может разъясняться и параллельность).
Вот такой "протокол". Благо, рисовать приходится редко, а вменяемая "документация с картинками" нужна ещё реже. Иногда приходится рисовать полноценную ДРАКОН-схему в каком-нибудь Visio, и слава Богу, что лично меня сия миссия пока миновала, ДРАКОН-схемы хоть и эргономичны (с оговорками), но процесс драконоклепания крайне неэргономичен.
И ещё один момент. В рамках творческого эксперимента были опробованы Р-схемы на реальных "подопытных", включая "большое начальство" у заказчика. Схемки рисовались во время совещания на доске, были и пару моментов с параллельностью. В качестве примера я тоже попробую "напоить себя":
Как видно, это попытка реализовать "мангал" — шампура по горизонтали ("синт-силуэт"). Идентификаторы действий как именованные вершины выделяются в схеме и указывают на то, что на эти действия существуют связи, в т.ч. могут быть и переходы. Переходы (в квадратных скобках), имхо, можно разрешить и в рамках ветки, т.е. если переход где-то внутри ветки — значит это переход на действие внутри шампура (хотя, ещё надо подумать). Циклические переходы между ветками можно выделять двойными скобками, и пр. и т.д., сейчас это не важно. Представленная схема, конечно, не имеет полноценного графа, это опять "упрощение", формально необходимо рисовать как-то так:
Вердикт подопытных таков. Прежде всего, непривычно на фоне остальных типовых диаграмм, с которыми они имели дело (их мучали и UML-ем, и всякими картинками от "бизнес-описателей"). Из-за непривычности вроде кажется, что страдает наглядность, но понимание схем вопросов не вызывает, и ключевой момент здесь, имхо, это наличие предиката (условия прохождения по дуге), эта штучка всем понравилась, в некоторых моментах это хороший способ разжевать сущность происходящего сразу по месту без необходимости плясать глазами по маршруту в обратном направлении.
Имхо, подобные схемы как-то по духу близки к используемому "упрощённому протоколу". По поводу наглядности. Рисование вручную прощает огрехи, но, в целом, Р-схемы требуют более качественной отрисовки в том смысле, что нужно эргономично привязывать надписи/подписи к нужной дуге, чтобы не было свалки, особенно, если стремиться к компактности. Если повозиться с Р-схемами, то довольно быстро к ним привыкаешь, включая и "сложные случаи" — дуга с двойной линией (хотя для описания процессов можно и без неё обойтись). Непривычно в схемах выглядит произвольный текст. Программный код, матформулы или "инженерные" идентификаторы как в ГРАФИТ-ФЛОКСЕ смотрятся там как родные, имхо, такая "привычность" просто навязана всем со школьной скамьи через рисунки на геометрии и т.п. Но и к этому быстро привыкаешь. При необходимости (если реально нужно "бизнес-рисователям") текст можно оформить как-то так:
Если грамотно рисовать, скажем, оформить содержательный текст как внутреннюю табличку с тонкими линиями из точек, то можно добиться и наглядности, и компактности, экономя место и уменьшая эффект попугайства, в отличие от ряда граф-языков, как, например, в EPC-нотации (здесь есть примеры, когда к квадратику-функции прилепляют кучу "картинок" на пол-экрана: исполнители, документы, БД и т.д.). К тому же, через одну и ту же нотацию Р-схем можно задать не только алгоритмические диаграммы, но и декларативные, структурные и пр. И важен технический момент — для Р-схем есть адекватное отображение и в текстовом виде.
Короче говоря, последняя морока с Р-схемами пока не разрешила их выкинуть на свалку. Скорее, наоборот — конкуренция для ДРАКОНа с мульти-шампурами возрастает. Тем более, на oberoncore опять замечена адекватная критика ДРАКОНа, например, в этой теме. Если говорить о реальном программировании, то в Р-схемах, имхо, как-то проще задать неудобные для ДРАКОНа вещи, как использование исключений, та же параллельность, или у Р-схем больше шансов иметь предикаты для верификации кода (навеяно этой темой).
Одним словом, сейчас наблюдается попытка перехода от "Бейсика" (ДРАКОНа) к "Хаскелю" (Р-схемам). Надеюсь, что, в конце концов, жизнь заставит выбрать что-то одно (а может и другое ).
Я приветствую Ваши поиски истины. По моему мнению, было бы хорошо, если бы Вы продублировали это Ваше сообщение (или даже всю эту тему) на форуме oberoncore. Вы ведь там зарегистрированы.
Думается, что там Вы получите намного больше откликов (если, конечно, Вы заинтересованы в откликах).
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>Я приветствую Ваши поиски истины. По моему мнению, было бы хорошо, если бы Вы продублировали это Ваше сообщение (или даже всю эту тему) на форуме oberoncore. Вы ведь там зарегистрированы.
ВП>Думается, что там Вы получите намного больше откликов (если, конечно, Вы заинтересованы в откликах).
Здравствуйте, Maxim S. Shatskih, Вы писали:
PSV>> | | | | | | | | +----+ +----+ PSV>> | Database +<----->+ Shared +<---->+ Executive +<-=-->+ Operator +<---->|cYEL| . . .|cYEL| PSV>> | c707 | | Memory | | c707 | | Server | | | | |
MSS>А где локи для защиты доступа к shared memory?
Да Бог его знает, я в сущность схемы и не всматривался. Эта диаграмма, как и UML-схема последовательностей там же, просто случайно попали под горячую руку, необходимы были готовые примеры и я их вытащил отсюда — статья про org-mode эмакса, эта ссылка есть и в исходном сообщении.
Сам ВП в дальнейшем предложил решение, основанное на операторах синхронизации — см. эту ветку.
