. Решил задать вопрос в новой теме, ибо в том разделе уже накидали много сообщений, и тема фактически уже неактивна.
Мне (и коллегам) иногда приходится рисовать схемки для обсуждения алгоритмов, причём часто со специалистами в прикладной области (которые не программисты), иногда и они сами рисуют алгоритмы. Раньше рисунки напоминали типовые советские блок-схемы. Были попытки применять псевдо-программный язык — не прижилось, не нравится ни кому — ни программистам, ни остальным. Не помню сколько лет назад я встретил информацию о ДРАКОНе, рисунки в его стили оказались реально приятнее классических блок-схем, хотя синтаксис и правила соблюдаются не идеально (пару слов по этому поводу здесь
). Действительно, ДРАКОН облегчает восприятие алгоритмов, но он тоже "не безгрешен", здесь есть пример. В соответствующей теме про ДРАКОН всплыла интересная забытая Р-технология, как реальная альтернатива блок-схемам и ДРАКОНу тоже (здесь
, здесь, здесь, здесь). Что лучше/удобнее/нагляднее: блок-схемы/ДРАКОН/Р-технология — пока сказать сложно без практического опыта. Но эта Р-технология опять заставила задуматься над самим процессом создания схем.
Основная проблема визуальной алгоритмизации — много возни для рисования схем. Иногда реально возникает желание иметь какой-то транслятор, ибо задалбывает сначала всё разрисовать, а потом ещё и запрограммировать (правда, всё-равно программируется лишь "по мотивам" схем). Сейчас всем проще рисовать вручную на бумаге, "рефакторинг" реально напрягает. Доступные графические редакторы неудобны в работе. Были попытки попробовать рисовать в псевдо-графике, например, по таким мотивам:
Это пример отсюда, так можно рисовать и для ДРАКОНа. Но в псевдо-графике схемы не так наглядны и более громоздки, чем "рисованные". К тому же нужно осваивать эмакс (вариант не для всех) или писать плагины для других редакторов (псевдо-графику тоже нужно удобно вводить).
Были мысли сделать текстовое описание для схем, что-то вроде:
Но подобное описание является, фактически, своим языком программирования, от чего, собственно, и избавляются в нашей задаче. Хотя для "плоских" схем, вида диаграммы последовательности, текстовое описание можно "переварить":
title Example Sequence Diagram
activate Client
Client -> Server: Session Initiation
note right: Client requests new session
activate Server
Client <-- Server: Authorization Request
note left: Server requires authentication
Client -> Server: Authorization Response
note right: Client provides authentication details
Server --> Client: Session Token
note left: Session established
deactivate Server
Client -> Client: Saves token
deactivate Client
результат:
Но такое текстовое описание всё-таки уступает в наглядности рисунку схемы, и, в любом случае, это ещё одно "программирование", хоть DSL и не сложный.
Вот в "древней" Р-технологии схемы специально заточены для возможности работы в текстовом представлении. Вот пример:
Сейчас есть мысли попробовать такие схемы на практике, но прежде, чем ломать голову над тем, как приспособить текстовый редактор для них, всё-таки хотелось бы познать, какие есть варианты для несложного создания схем. Поэтому вопросик такой. Может кто-то из своей практики поделится успешным опытом удобного и быстрого создания каких-то визуальных схем? Интересуют любые способы: как графический редактор с мышкой (может и тачскрин), так и текстовое "программирование". Тип схем не важен: блок-схемы, всякие диаграммы и пр., возможно что-то есть реально удобное среди инструментария для инженерных систем (в этой сфере у меня опыта нет).
Не понял. В этой "паре слов" я не обнаружил опровергающих примеров.
PSV>Действительно, ДРАКОН облегчает восприятие алгоритмов,
Согласен.
PSV>но он тоже "не безгрешен", здесь есть пример.
Не согласен. Данный пример НЕ является опровергающим. Участники дискуссии пытались "нарушить" правила ДРАКОНа.
Вывод простой: ПРАВИЛА ДРАКОНа НЕ НАДО НАРУШАТЬ. Тогда не будет никаких проблем.
PSV>Основная проблема визуальной алгоритмизации — много возни для рисования схем.
Согласен. Но если пользоваться дракон-редакторами Геннадия Тышова или Степана Митькина, то ситуация меняется.
Возни будет гораздо меньше.
PSV>Сейчас всем проще рисовать вручную на бумаге,
Не согласен. Редакторы Тышова и Митькина изменяют ситуацию.
Кроме того, они могут доработать редакторы, если Вы их уговорите. Попробуйте.
Здравствуйте, PSV100, Вы писали:
PSV>Мне (и коллегам) иногда приходится рисовать схемки для обсуждения алгоритмов, причём часто со специалистами в прикладной области (которые не программисты), иногда и они сами рисуют алгоритмы.
PSV>В соответствующей теме про ДРАКОН всплыла интересная забытая Р-технология, как реальная альтернатива блок-схемам и ДРАКОНу тоже...
PSV>Что лучше/удобнее/нагляднее: блок-схемы/ДРАКОН/Р-технология — пока сказать сложно без практического опыта.
Для Вашего случая Р-технология Игоря Вельбицкого не подойдет. Хотите попробовать — пробуйте. По моему мнению, Вы зря потеряете время.
Для Вашего случая альтернативы Дракону нет.
К сожалению, Вы используете "самодельный", испорченный Дракон. К тому же Вы работаете вручную.
Чтобы поправить дело, могу рекомендовать Вам книгу
Паронджанов В. Д. Учись писать, читать и понимать алгоритмы. Алгоритмы для правильного мышления. Основы алгоритмизации. – М.: ДМК Пресс, 2012. – 520 с. — Иллюстаций 272.
. Решил задать вопрос в новой теме, ибо в том разделе уже накидали много сообщений, и тема фактически уже неактивна.
Некоторые мысли и по Вашему топику в той ветке, и здесь — без цитирования для быстроты.
1. По упрощению синтаксиса — такое уже сделал Дмитрий_ВБ для своих сред графпрограммирования УВК — в ДАЛВЯЗ-решении. Мне это кажется ограничением возможностей графов — но есть и свои резоны для конкретных условий (Вы их во многом повторили).
2. По связке с текстом — да, есть и такие разработки. Не для техноязыка, но как "техзадание" — наверное, этот редактор. Для ДАЛВЯЗ тоже проводятся эксперименты в этом направлении. Считаю совершенно правильным — схема должна отражать некий текстовый формат один в один.
Связывать можно и не графы, а те самые упрощённые представления. Но тут надо продумывать, как они будут выглядеть. Некоторые мысли здесь — там же в ветке видно, что народ думает и что-то уже реализует...
3. По опыту — есть такой. Примеры можно найти на этой странице и на связанной хотя бы. Именно чтобы не осваивать что-то помимо офисных пакетов и/или знакомых редакторов диаграмм...
. Решил задать вопрос в новой теме, ибо в том разделе уже накидали много сообщений, и тема фактически уже неактивна.
PSV>Мне (и коллегам) иногда приходится рисовать схемки для обсуждения алгоритмов, причём часто со специалистами в прикладной области (которые не программисты), иногда и они сами рисуют алгоритмы.
<skipped>
UML спасет отца русской демократии! UML — это общепризнанный мировой стандарт. Есть много разных редакторов для рисования UML-диаграмм.
Книг по UML тоже издано много. Не связывайтесь с доморощенными драконами и прочей ерундой. Только время потеряете.
PSV>>но он тоже "не безгрешен", здесь есть пример.
ВП>Не согласен. Данный пример НЕ является опровергающим. Участники дискуссии пытались "нарушить" правила ДРАКОНа. ВП>Вывод простой: ПРАВИЛА ДРАКОНа НЕ НАДО НАРУШАТЬ. Тогда не будет никаких проблем.
Без надежды на ответ. По ссылке показан пример, который при использовании Дракона становится более запутанным и менее наглядным.
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>Для Вашего случая Р-технология Игоря Вельбицкого не подойдет. Хотите попробовать — пробуйте. По моему мнению, Вы зря потеряете время.
Наш технологический процесс позволяет попробовать даже иероглифы . В любом случае, неудача — это тоже опыт. А вот конструктивная критика Р-технологии была бы полезной.
ВП> К сожалению, Вы используете "самодельный", испорченный Дракон. К тому же Вы работаете вручную.
"Самодеятельность" в Драконе вынужденная, это следствие упрощения работы вручную. К сожалению, доступные графические ДРАКОН-редакторы, как и многие универсальные "рисовалки" различных схем, неудобны в работе, особенно на фоне программистских редакторов/IDE. Дракон-редакторы тоже используются, в основном, чтобы нарисовать схемку "красивенько". К тому же, иногда использование программ для рисования затруднительно, например, схемки рисуются на бумаге по ходу дела во время коллективного обсуждения какой-то проблемы, или когда требуется от какого-нибудь специалиста изложить свои мысли, при этом "украсть" его драгоценное время можно не более получаса.
Вот сейчас и ищется вариант продуктивного создания схем алгоритмов.
Здравствуйте, VladZharinov, Вы писали:
VZ>1. По упрощению синтаксиса — такое уже сделал Дмитрий_ВБ для своих сред графпрограммирования УВК — в ДАЛВЯЗ-решении. Мне это кажется ограничением возможностей графов — но есть и свои резоны для конкретных условий (Вы их во многом повторили).
VZ>2. По связке с текстом — да, есть и такие разработки. Не для техноязыка, но как "техзадание" — наверное, этот редактор. Для ДАЛВЯЗ тоже проводятся эксперименты в этом направлении. Считаю совершенно правильным — схема должна отражать некий текстовый формат один в один.
VZ>Связывать можно и не графы, а те самые упрощённые представления. Но тут надо продумывать, как они будут выглядеть. Некоторые мысли здесь — там же в ветке видно, что народ думает и что-то уже реализует...
VZ>3. По опыту — есть такой. Примеры можно найти на этой странице и на связанной хотя бы. Именно чтобы не осваивать что-то помимо офисных пакетов и/или знакомых редакторов диаграмм...
Большое спасибо за мысли и ссылки, по возможности всё посмотрю. На первый быстрый взгляд пока не увидел что-то желанное для себя, например, что-то вроде org-mode для эмакс (органайзер, структурные документы, таблицы, псевдографика и пр.) — удобно и продуктивно, всё в текстовом виде (а это даёт возможность использовать всю мощь и эффективность текстового редактора, а также это — сравнение файлов, контроль версий и т.д.).
Пока вывод такой: "квадратики" и линии — тяжело рисовать. "Будем искать..."
Здравствуйте, Nikita123, Вы писали:
N>UML спасет отца русской демократии! UML — это общепризнанный мировой стандарт. Есть много разных редакторов для рисования UML-диаграмм. N>Книг по UML тоже издано много. Не связывайтесь с доморощенными драконами и прочей ерундой. Только время потеряете.
Пока Бог миловал "uml-ить", дальше образовательных целей я с ним не связывался и большого счастья я там не вижу.
В общем, можно и свои квадратики со стрелочками выдумать, сейчас не в этом суть. Тут больше банально техническая проблема — как легко, быстро, наглядно их создавать.
N>>Книг по UML тоже издано много. Не связывайтесь с доморощенными драконами и прочей ерундой. Только время потеряете.
PSV>Пока Бог миловал "uml-ить", дальше образовательных целей я с ним не связывался и большого счастья я там не вижу.
Но при этом в исходном сообщении приведены схемы, которые в UML давно стандартизированы, например.
PSV>В общем, можно и свои квадратики со стрелочками выдумать, сейчас не в этом суть. Тут больше банально техническая проблема — как легко, быстро, наглядно их создавать.
. Решил задать вопрос в новой теме, ибо в том разделе уже накидали много сообщений, и тема фактически уже неактивна. PSV>Основная проблема визуальной алгоритмизации — много возни для рисования схем. Иногда реально возникает желание иметь какой-то транслятор, ибо задалбывает сначала всё разрисовать, а потом ещё и запрограммировать (правда, всё-равно программируется лишь "по мотивам" схем). Сейчас всем проще рисовать вручную на бумаге, "рефакторинг" реально напрягает.
У нас учёные рисуют на iPad'ах в OmniGraffle. Не на формальном языке, а просто в виде стрелочек с квадратиками для упрощения понимания (или в процессе обсуждения).
Но формальные документы пишем чистым текстом, с алгоритмами на псевдоязыке.
Здравствуйте, PSV100, Вы писали:
PSV>Наш технологический процесс позволяет попробовать даже иероглифы . В любом случае, неудача — это тоже опыт. А вот конструктивная критика Р-технологии была бы полезной.
Я нашел критику Р-технологии в этом документе. В нем на странице 13 говорится:
Использование P-схем для графического описания УА РВ затрудняет тот факт [30], что она не предусматривает средств адаптации к специфике конкретной БЦВМ, а также отсутствие возможностей для описания параллельного функционирования программ в режиме реального времени.
Это весь конструктив. Кстати, при описании ДРАКОНа в этом документе снова использовалась схема с рыбалкой.
Отчет ЦРУ выпущен в мае 1990 года, рассекречен через 10 лет — в 2000 году.
См. стр. 7. Там написано следующее:
R-technology: A structured-design software engineering methodology developed in the early 1970s.
R-technology has been used by software developers in the USSR’s strategic missiles industries.
The Soviets claim that R-technology enables software professionals to electronically “draw” on a computer screen the algorithmic design of the software, which is then automatically mapped to a compiler that generates executable object code.
Вот и все. Как видите, совсем не много. Но, как говорится, с паршивой овцы хоть шерсти клок. Я имею в виду ЦРУ, а не Р-технологию.
К Игорю Вячеславовичу Вельбицкому я отношусь с глубочайшим уважением. Потому что он заложил основы. Он построил фундамент. И нельзя его упрекать, что на этом могучем фундаменте сегодня построено совсем не то здание, которое он хотел возвести.
По моему мнению, Вельбицкий — пионер, основоположник и первопроходец. Он создал первую в истории нашей страны визуальную технологию программирования. Но этим не ограничился.
Обладая неукротимой энергией и гигантской пробивной силой, он пошел дальше. Игорь Вячеславович попытался вывести Р-технологию на мировой уровень. Он мечтал завоевать весь мир. Не получилось.
В любом случае, это был научный подвиг. За это честь ему и хвала.
И низкий поклон.
Вместе с тем, надо честно признать, что Вельбицкий потерпел неудачу. Такой, увы, часто бывает судьба первопроходцев. Главное, что дело, которому он посвятил жизнь, не пропало. Оно продолжается. Пусть в другой форме. Но на том же краеугольном камне.
На краеугольном камне, который заложил Игорь Вячеславович Вельбицкий.
Здравствуйте, Privalov, Вы писали:
P>Кстати, при описании ДРАКОНа в этом документе снова использовалась схема с рыбалкой.
Дык возможно, это весь ассортимент, что был на тот момент (2008/09) доступен... автор ведь не из НПЦ АП...
Кстати, по этому же — не так давно обсуждалась по крайней мере одна ГРАФИТ-ФЛОКС-схема — начиная отсюда: http://forum.oberoncore.ru/viewtopic.php?p=43805#p43805 (ну и там практически до конца ветки). Там и подход к параллелизму обсуждался. Также была небольшая ветка по технологии в целом: http://forum.oberoncore.ru/viewtopic.php?f=62&t=1091.
по этому поводу можно прокомментировать так. Для упорядочения маршрутов в техноязыке взят как приоритетный принцип "по шампуру (крайний слева, строго по прямой) — самый главный (в смысле какого-то критерия, вводимого по смыслу задачи)". Для иллюстрации отличий от побочных можно использовать развёртку — скажем, приведённую в этом пункте.
В показанных случаях есть пересечения, которые можно устранить рокировкой (обменом выходов ветвлений — и соответственно начинаемых ими маршрутных участков). Но. При этом главный маршрут может оказаться не "по шампуру"... Заметим, что это можно установить только по конкретному содержанию схемы — а там обсуждаются т.н. литеральные схемы, в которых тексты вершин абстрагированы индексами. Но для сути вопроса это неважно.
И вот вопрос — а как сохранить "правило главного" и при этом избежать пересечений? Получается, что надо вводить дополнительные средства — конструкции перехода условного (переключатели) или безусловного ("петля" силуэта).
В ряде случаев, IMHO, есть и другой путь — изначально строить логику маршрутов иначе. Здесь могут помочь конструкции Дейкстры. И прежде всего его цикл — как иная форма, так сказать, "универсальной программы", чем силуэт. Можно видеть на примерах для обычной и автоматной программ. Разумеется, так же приложимо и к алгоритмам материальных процессов — хотя бы здесь.
Как сказал PSV100, в некотором смысле переход к ЦД можно понимать как "упрощение" графовой записи алгоритма. Да, тут условия выбора единиц структуры "вытаскиваются" в "шапку" схемы (принцип рассмотрен здесь). И перехды между единицами остаются тлько условные — веточные соединители не нужны. Но главная цель другая — выделять единицы структуры и условия их выбора по смыслу процесса.
Разумеется, и здесь возможна критика... Прежде всего — из условий не всегда понятен смысл веток. Для этого вводятся комментарии (на схемах отделены знаком тождества).
: это безымянные функции, которые имеют доступ к переменным, созданным на один уровень выше.
Технически, циклы можно строить точно так же, как функции, с помощью стека адресов возврата, убрав из набора команд процессора goto вверх по программе и оставив только переходы вперёд.
Так же выглядели циклы в Фортране, Паскале и ПЛ/1. И в Рексе и позднем Бейсике. Я вот думаю, когда же сдохнет последний приверженец Алгола, наконец.
Кстати, ДРАКОН представляет циклы как замыкания, т.е. как функции внутри функций.
Сообщаю Вам материал об Р-технологии, который отчасти можно рассматривать как критические замечания.
Чтобы отвлечься от моих личных оценок, буду приводить цитаты.
Передо мной журнал «Управляющие системы и машины» (УСиМ) за 1988 год, №4. В нем есть статья
Соболев В.Е. Вопросы интеграции метода МСПП и Р-технологии.
Поясню:
МСПП — метод многоуровневого структурного проектирования программ.
САА — система алгоритмических алгебр
Статья начинается так:
К числу прогрессивных методов разработки программ относятся метод многоуровневого структурного построения программ (МСПП) и Р-технология. По методу МСПП алгоритмы создаются в терминах операций модифицированной системы алгоритмических алгебр (САА) на формализованном языке, близком к естественному (в САА-схемах), а по Р-технологии — на Р-языке (в Р-схемах).
Даю выдержку из средины статьи:
САА-схемы ориентированы на подробное описание алгоритмов на языке, близком к естественному. Размер названий операторов и условий практически не ограничен. Предусмотрены средства повышения наглядности текста и комментарии, в которых могут быть записаны, например, детальные спецификации модуля и процедур.
Далее, Р-схемы отражают логику алгоритмов в удобной для зрительного восприятия форме. Их основные отличительные особенности — хорошая наглядность и компактность — отчетливо проявляются в сравнении с текстами на ЯП.
Однако попытка разместить на дугах содержательные тексты больших размеров (или вынести подробные комментарии) приводит, как правило, к потере этих качеств из-за роста «габаритов» рисунка и ухудшению его обозримости.
Кроме того, вероятно рассредоточение цельной информации по нескольким кадрам проектирования, если принять во внимание технологический аспект.
Что же касается функциональных описаний составных (элементарных) операторов и условий в области спецификаций (абстракций) чертежа, то они оторваны от мест расположения соответствующих алгоритмических элементов в Р-схеме.
Напротив, смысл операторов и условий САА-схемы воспринимается по ходу ее чтения.
Таким образом, чертежи как средство проектирования и описания модуля хорошо подходят в тех случаях, когда смысл шагов алгоритма понятно выражается краткими названиями или записями на ЯП.
Если же необходимо более детальное содержательное описание этих шагов, следует рассмотреть возможность применения САА-схем.
Допускается также сочетание текстовых и графических средств: на верхних уровнях проектирования алгоритма используется САА-схема, а для конкретизации ее элементарных операторов и условий — чертежи.
Про МСПП и САА можно, в частности, более подробно прочитать в книге:
Многоуровневое структурное проектирование программ. Теоретические основы, инструментарий / Е.Л. Ющенко, Г.Е. Цейтлин, В.П. Грицай, Т.К. Терзян. — М.: Финансы и статистика, 1989. — 208с.
Здравствуйте, Nikita123, Вы писали:
N>UML спасет отца русской демократии! UML — это общепризнанный мировой стандарт. Есть много разных редакторов для рисования UML-диаграмм. N>Книг по UML тоже издано много. Не связывайтесь с доморощенными драконами и прочей ерундой. Только время потеряете.
Там кроме квадратиков еще много чего есть.. Но чукча не читатель. Чукча писатель..
PSV>Но подобное описание является, фактически, своим языком программирования, от чего, собственно, и избавляются в нашей задаче. Хотя для "плоских" схем, вида диаграммы последовательности, текстовое описание можно "переварить": PSV>
PSV>title Example Sequence Diagram
PSV>activate Client
PSV>Client -> Server: Session Initiation
PSV>note right: Client requests new session
PSV>activate Server
PSV>Client <-- Server: Authorization Request
PSV>note left: Server requires authentication
PSV>Client -> Server: Authorization Response
PSV>note right: Client provides authentication details
PSV>Server --> Client: Session Token
PSV>note left: Session established
PSV>deactivate Server
PSV>Client -> Client: Saves token
PSV>deactivate Client
PSV>
У всех прошу прощения, не было возможности оперативно реагировать на сообщения в форуме. Попробую в одном посте дать ответы.
Здравствуйте, Privalov, Вы писали:
P>Я нашел критику Р-технологии в этом документе. В нем на странице 13 говорится: P>
P>Использование P-схем для графического описания УА РВ затрудняет тот факт [30], что она не предусматривает средств адаптации к специфике конкретной БЦВМ, а также отсутствие возможностей для описания параллельного функционирования программ в режиме реального времени.
P>Это весь конструктив. Кстати, при описании ДРАКОНа в этом документе снова использовалась схема с рыбалкой.
То, что в Р-схемах нет привязки к специфики какой-то ЭВМ — так это плюс. И авторы Р-технологии, если я не ошибаюсь, изначально закладывали возможность указания параллельных процессов: если дуги графа не имеют условия своего выполнения, значит действия в этих дугах выполняются одновременно, и я предполагаю, что в точке, где сходятся дуги, процессы будут ждать завершения друг друга. В любом случае, можно придумать как начертить свое нужное видение параллельности. Одним словом, конструктива в той статье действительно нет.
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>Уважаемый PSV100! ВП>Учитывая Ваш интерес к Р-технологии Вельбицкого, я не поленился ВП>и заглянул в архивы ЦРУ (CIA USA), разумеется, рассекреченные. ВП>[...] ВП>По моему мнению, Вельбицкий — пионер, основоположник и первопроходец. Он создал первую в истории нашей страны визуальную технологию программирования. Но этим не ограничился. ВП>Обладая неукротимой энергией и гигантской пробивной силой, он пошел дальше. Игорь Вячеславович попытался вывести Р-технологию на мировой уровень. Он мечтал завоевать весь мир. Не получилось. ВП>[...]
ВП>Сообщаю Вам материал об Р-технологии, который отчасти можно рассматривать как критические замечания. ВП>Чтобы отвлечься от моих личных оценок, буду приводить цитаты. ВП>Передо мной журнал «Управляющие системы и машины» (УСиМ) за 1988 год, №4. В нем есть статья ВП>[...]
Владимир Даниелович, спасибо за "шпионские" сведения и остальные материалы. С некоторыми предположениями я соглашусь (об этом ниже), но вызывает сомнение то, что Вельбицкий с Р-технологией пытался завоевать весь мир — как-то незаметны следы такой попытки.
Я немного пощупал Р-схемы, и, так как в этой теме опять есть небольшое обсуждение ДРАКОНа и к нему добавилась и Р-технология, то могу поделиться своими мыслями по этому поводу.
Во-первых, нужно сначала сказать о том, с каких позиций я рассматриваю графический язык алгоритмов. Прежде всего, это удобное средство представления для непрограммистов. В своей практике я столкнулся с тем, что ими графические схемы воспринимаются лучше, чем текстовый программный псевдо-язык. Что касается программистов, то разводить новый флейм по этому поводу никак не хочется. Имхо, здесь у каждого есть свое мнение.
Так вот, всплыли некоторые нюансы Р-схем:
— небольшое общение с "непрограммистами" пока показало, что блок-схемы для них как-то нагляднее, понятнее, проще. Р-схемы для них — это уже что-то "инженерное", они напоминают принципиальные электрические схемы. Т.е. "попса" — квадратики и стрелки — им милее. Короче говоря, попсовость и гламурность у Р-схем несколько занижена.
— В Р-схемах сделан упор на текстовое содержание над и под дугами (а также и в именованных вершинах), т.е. основной смысл схемы задаётся текстом. К тому же это похоже на школьные математические рисунки, когда над/под геометрическими фигурами или отрезками писались формулы. В результате Р-схемы лучше адаптированы для "вписания" в них математических формул или программного текста, т.е. указание присваивания переменных, операторов, вызов функций (со скобками в том числе) и пр. в таком же виде, как и в текстовом языке программирования. В блок-схемах и ДРАКОНе используется различие во внешнем виде икон, которые сами по себе несут определенную смысловую нагрузку. Поэтому блок-схемы гораздо приятнее, когда внутри икон указывается только краткий поясняющий текст. Здесь на форуме совершенно справедливо указали, что такие ДРАКОН-схемы, как здесь — алгоритм быстрой сортировки, когда программа на Питоне "вписана" в графическую схему — для программистов ненаглядны: это что-то вроде зарисовки математических формул вместо их прямого написания, что, возможно, пригодно лишь для образовательных целей. Имхо, Паронджанову лучше начинать знакомство программистов с ДРАКОНом на примере таких инженерных схем, как эта: http://forum.oberoncore.ru/viewtopic.php?p=43805#p43805 (ссылку здесь на форуме предоставил VladZharinov). Здесь ДРАКОН во всей своей красе. Затем показательные выступления лучше перенести на алгоритмы уровня рыбалки и поездки на автобусе — это стихия ДРАКОНа, и, как бонус, для тех, кому нужно, можно заявить о "гибридности" ДРАКОНа с языками С, Pascal и пр. (где самая вкусность: ДРАКОН-АДА ).
— Р-схемы несколько компактнее по сравнению с блок-схемами и ДРАКОНом, но не на много, особенно если рисовать комментарии сверху/снизу дуг. В текстовой псевдо-графике Р-схемы лучше, чем квадратики блок-схем, но тоже "не ахти". Также в Р-схемах несколько слабо выделяются переходы на именованные дуги, и есть некий визуальный шум из-за наличия явных знаков "стрелка" и кружочков/крестиков-вершин. Возможно, что-то можно доработать напильником, но вряд ли получатся кардинальные сдвиги.
— Имхо, Р-схемы несколько проще составляются, чем ДРАКОН-схемы. Они имеют меньше требований, допускают пересечение линий (что "проглатывается" лучше, чем в блок-схемах). В ДРАКОНе нужно больше напрягаться, чтобы нарисовать наглядную схему. Здесь на форуме уже говорилось об этом (например, здесь
— В Р-схемах можно придумать, как задать силуэт ДРАКОНа, только шампура будут расположены горизонтально. Получим "мангал-метод"
Р-схемы и ДРАКОН, как и многие графические языки, имеют общие недостатки, например:
— наглядность схем снижается, когда они довольно громоздкие;
— схемы плохие, когда указано много содержательного текста внутри иконы или над/под дугами графа;
— понимание схем затрудняется, когда схема не видна целиком, например, на мониторе при работе в графическом редакторе. К тому же, как-то неудобно или непривычно работать в режиме поэтапного или циклического создания схем: где-то тут нарисовал кусочек, затем там и т.д. Очень много зависимостей от инструментальных средств.
При этом я не затрагиваю тему отсутствия или неразвитости в графических технологиях таких средств, как сравнение схем, ведение истории версий, отладчик, профилировщик, анализатор кода (выявление неиспользованного кода и пр.), слабые базовые операции для модификации схем (отключение/комментирование участков схем, различные преобразования, да и копирование, вставки, автодополнение и т.д и т.п. — всё слабо развито или не так удобно по сравнению с текстовыми редакторами/IDE).
Что удобнее/лучше — ДРАКОН или Р-схемы — однозначно ответить нельзя. Для "рядовых смертных" доступнее "попса" — квадратики и стрелки, для программистов, инженеров и прочих "продвинутых" — Р-схемы вполне могут себя оправдать.
И пока ещё не нашлось удобного способа создания схем. Здесь на форуме затронули гугловский Blockly и Scratch, они напомнили о диаграммах Насси — Шнейдермана (или здесь), что-то общее у них есть, это ещё одна альтернатива блок-схемам. Попробую покурить бамбук с мыслями прикрутить к ним силуэтное программирование от ДРАКОНа. Если удастся добиться адекватного внешнего вида для схем, то есть шанс что-то придумать для ввода данных некий аналог таблиц в org-mode эмакса. Хотя очень сомневаюсь, что будет толк.
Здравствуйте, PSV100, Вы писали:
PSV>То, что в Р-схемах нет привязки к специфики какой-то ЭВМ — так это плюс. И авторы Р-технологии, если я не ошибаюсь, изначально закладывали возможность указания параллельных процессов: если дуги графа не имеют условия своего выполнения, значит действия в этих дугах выполняются одновременно, и я предполагаю, что в точке, где сходятся дуги, процессы будут ждать завершения друг друга.
Пожалуй, совпадает со сказанным здесь.
PSV> Имхо, Паронджанову лучше начинать знакомство программистов с ДРАКОНом на примере таких инженерных схем, как эта: http://forum.oberoncore.ru/viewtopic.php?p=43805#p43805. Здесь ДРАКОН во всей своей красе. Затем показательные выступления лучше перенести на алгоритмы уровня рыбалки и поездки на автобусе — это стихия ДРАКОНа, и, как бонус, для тех, кому нужно, можно заявить о "гибридности" ДРАКОНа с языками С, Pascal PSV>В любом случае, можно придумать как начертить свое нужное видение параллельности.
Кстати, ветка, в которой появилась та инженерная схема, как можно видеть, в основном как раз посвящена была именно этому. Сам ВП в дальнейшем предложил решение, основанное на операторах синхронизации — см. эту ветку.
PSV>- В Р-схемах можно придумать, как задать силуэт ДРАКОНа, только шампура будут расположены горизонтально. Получим "мангал-метод"
Есть такое — "синт-силуэт" — можно видеть здесь. Кстати, применение в такой схеме, наряду с "синт-переключателями", ОС-узлов (суть IDEF3-"перекрёстков"), может помочь адекватному представлению непрограмvно строгих описаний (скажем, текстовых НД) — говорил здесь.
PSV>- В Р-схемах сделан упор на текстовое содержание над и под дугами (а также и в именованных вершинах), т.е. основной смысл схемы задаётся текстом. К тому же это похоже на школьные математические рисунки, когда над/под геометрическими фигурами или отрезками писались формулы. В результате Р-схемы лучше адаптированы для "вписания" в них математических формул или программного текста, т.е. указание присваивания переменных, операторов, вызов функций (со скобками в том числе) и пр. в таком же виде, как и в текстовом языке программирования. В блок-схемах и ДРАКОНе используется различие во внешнем виде икон, которые сами по себе несут определенную смысловую нагрузку. Поэтому блок-схемы гораздо приятнее, когда внутри икон указывается только краткий поясняющий текст. Здесь на форуме совершенно справедливо указали, что такие ДРАКОН-схемы, как здесь — алгоритм быстрой сортировки, когда программа на Питоне "вписана" в графическую схему — для программистов ненаглядны: это что-то вроде зарисовки математических формул вместо их прямого написания, что, возможно, пригодно лишь для образовательных целей.
А что будет нагляднее? Возможно, структурные скобки, как здесь?.. PSV>- наглядность схем снижается, когда они довольно громоздкие; PSV>- схемы плохие, когда указано много содержательного текста внутри иконы или над/под дугами графа;
Да, тот же Усов (alexus) высказывался в том смысле, что для решения этих проблем можно двигаться по пути традиционных систем документации — вынося часть атрибутов графоэлементов в спецификации — см. его сообщение.
Здравствуйте, 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 эмакса, эта ссылка есть и в исходном сообщении.
. В любом случае, неудача — это тоже опыт. А вот конструктивная критика Р-технологии была бы полезной.
