. Решил задать вопрос в новой теме, ибо в том разделе уже накидали много сообщений, и тема фактически уже неактивна.
Мне (и коллегам) иногда приходится рисовать схемки для обсуждения алгоритмов, причём часто со специалистами в прикладной области (которые не программисты), иногда и они сами рисуют алгоритмы. Раньше рисунки напоминали типовые советские блок-схемы. Были попытки применять псевдо-программный язык — не прижилось, не нравится ни кому — ни программистам, ни остальным. Не помню сколько лет назад я встретил информацию о ДРАКОНе, рисунки в его стили оказались реально приятнее классических блок-схем, хотя синтаксис и правила соблюдаются не идеально (пару слов по этому поводу здесь
). Действительно, ДРАКОН облегчает восприятие алгоритмов, но он тоже "не безгрешен", здесь есть пример. В соответствующей теме про ДРАКОН всплыла интересная забытая Р-технология, как реальная альтернатива блок-схемам и ДРАКОНу тоже (здесь
, здесь, здесь, здесь). Что лучше/удобнее/нагляднее: блок-схемы/ДРАКОН/Р-технология — пока сказать сложно без практического опыта. Но эта Р-технология опять заставила задуматься над самим процессом создания схем.
Основная проблема визуальной алгоритмизации — много возни для рисования схем. Иногда реально возникает желание иметь какой-то транслятор, ибо задалбывает сначала всё разрисовать, а потом ещё и запрограммировать (правда, всё-равно программируется лишь "по мотивам" схем). Сейчас всем проще рисовать вручную на бумаге, "рефакторинг" реально напрягает. Доступные графические редакторы неудобны в работе. Были попытки попробовать рисовать в псевдо-графике, например, по таким мотивам:
Это пример отсюда, так можно рисовать и для ДРАКОНа. Но в псевдо-графике схемы не так наглядны и более громоздки, чем "рисованные". К тому же нужно осваивать эмакс (вариант не для всех) или писать плагины для других редакторов (псевдо-графику тоже нужно удобно вводить).
Были мысли сделать текстовое описание для схем, что-то вроде:
Но подобное описание является, фактически, своим языком программирования, от чего, собственно, и избавляются в нашей задаче. Хотя для "плоских" схем, вида диаграммы последовательности, текстовое описание можно "переварить":
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) высказывался в том смысле, что для решения этих проблем можно двигаться по пути традиционных систем документации — вынося часть атрибутов графоэлементов в спецификации — см. его сообщение.
. В любом случае, неудача — это тоже опыт. А вот конструктивная критика Р-технологии была бы полезной.
