DRAKON.SU

Они не могут бесконечно расти и вертикально. Есть ограничение на максимальный размер структур - они должны быть обозримы, поэтому структура по горизонтали не превышает размер экрана, а по вертикали 3 экрана, кроме того ограничение на размер файла. Действительно, такой подход просто обязывал проводить декомпозицию.
Любой экран ограничивает, но если обычная программа растет в основном вниз, то здесь она растет равномерно и в ширину и в высоту. Видимо дело привычки - я и сейчас в обычных программа все синтаксические конструкции отбываю табом, сдвигая вправо вложенные конструкции.

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

Нормально воспринималось, даже лучше обычной программы. Что касается другого применения - не знаю, но с учетом, что это использовалось и ПЭО, в своих целях, и после ликвидации технологии они дюже загрустили, то и у них с восприятием проблем не было.

Это видимо просто картинка, потому что в РТК оно так не рисовалось, по крайней мере в том варианте, что был у нас, там работа шла в режиме АЦД. Может быть поэтому и воспринималось лучше.

Ещё одна статья Вельбицкого на стр.46 http://miratech.ua/sites/default/files/documents/press_about_us/kibertonia_n01-2012.pdf
Картинка вызывает вопрос, а как же принцип: у структуры только один вход? (см. на вложенную спец. структуру)
PS.
Имеется ввиду, что есть вход извне во вложенную структуру

Тут, давеча посетовал на малое к-во материалов в сети по Р-схемам и недостаточное полное изложение тонкостей.
Вот некоторые "непонятки". Интересно бы знать авторский замысел.
1.Ограничен ли всё-таки набор доступных для комбинирования структур. Например взять цикл (типа while) только такой:

или можно такой (ЦД):


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

PS.
Вот, если хочется ЦД, а есть только while c одним условием, то, эмулируем параллельным соединением ?

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

Уважаемый PSV100, еще раз внимательно прочитал ваше 1-е сообщение и пришел к выводу, что структуры лучше записывать в виде таблиц, а не P-схем. Потому что при записи структур стрелки дуг не имеют смысла, так же, как и провежуточные вершины.

Они только отвлекают внимание читателя.

Ну почему же, как раз стрелки задают отношение следования: HEAD -> BODY -> и затем END OF FILE. Двойная дуга не имеет стрелки от природы, а то, что, например, после стрелки CONDITION ничего нет - значит всё, конец этого следования (кстати, на рисунках ошибка: в Р-схеме - CONDITION, в исходнике - DESCRIPTION). Следование ярче выражено в диаграмме ниже: subject -> article -> (auther, source). Специальная вершина требуется по ГОСТу при соединении спецдуги (структуры с ней) с другой структурой (не одиночной). Но мне кажется, что в любом случае при соединении структур "много-много" эту точку соединения выделять, хотя бы просто визуально, без тайного смысла.

Можно попробовать похозяйничать, убрать стрелки. Также, например, чуть ранее я смотрел на mind map в виде а-ля Р-схемы, но чтобы их так рисовать, необходимо отказаться от вертикальной линии справа, т.е. "разорвать" структуры. Имхо, подобные вольности неоднозначны, это на уровне того, чтобы разрешить пересечения в ДРАКОНе.

Здесь, действительно, проблема, прежде всего, в читателе (конечно, и Р-схемы не без греха). Если ему нужны таблицы или квадратики со стрелочками, и он к ним привык, то, даже если и убрать стрелки и спецвершины, ему сразу легче не станет. А какому-то программисту, который эти Р-схемы "щёлкает" как японец иероглифы, гораздо приятнее для своего замыленного глаза созерцать привычные стрелки. И ему достаточно 30 сек, чтобы слепить диаграмму, вместо долгой и нудной возни в каком-нибудь граф-редакторе, рисуя квадратики, или мучаясь в Экселе, красиво оформляя таблицы.

Кстати о японцах. Во время своей возни с Р-схемами я перебрал варианты разных нотаций, в том числе и японские Hichart-ы (или как они там правильно обзываются), они представлены здесь: Альтернативный ВИЗУАЛЬНЫЙ СТРУКТУРНЫЙ ПОДХОД К АЛГОРИТМАМ. Да, собственно, там вся тема посвящена подобным альтернативам, здесь ещё один вариант, а здесь один из самых полезных рисунков в той теме. Эти альтернативы, вроде как, ближе к блок-схемах, понятнее, хорошо выделяют структурную составляющую, но в отличие от Р-схем теряют маршрутную логику.

В ГОСТе 8631-94 также есть сравнение Р-схем со "всякими другими".

По поводу "таблиц". Недавно появился Blockly от гугла, вариация Scratch-а, он напомнил мне о диаграммах Насси-Шнейдермана (всё тоже, но вид с боку, т.е. в гламурных пазлах). Но счастья я там не нашёл.

И чтобы уже "два раза не вставать", здесь можно скачать презентации различных систем для WorkFlow. На форуме чуть раньше была шутка про человечков с шариками, как диаграмма процессов, так она не далека от истины, некоторые "монстры" к этому приближаются

Вобщем, эту подборку, в дополнение к стандартным UML, BPMN, IDEF, eEPC, есть ещё Amber (здесь, гл.8, спасибо Владиславу Жаринову) пришлось недавно пересмотреть, и ничего функциональнее, чем Р-схемы, не нашлось. Лисп - он и в Африке Лисп . Может быть Вам, или кому-то, что-то поможет с идеями, для того же ДРАКОНа.

P.S. Небольшое уточнение. Всё-таки, на диаграмме "subject -> article -> (auther, source)" отражена именно иерархия, а в схеме "File" - показано следование. Было бы нагляднее, если бы, скажем, в секцию "Body" сначала входила бы какая-то группа "Prerecords", затем указанная спецдуга "Record" (что задаёт наличие много record-ов), и затем некий "Postrecords", ну или что-то в этом роде.

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

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

Собственно цикл имеет такую форму (цикл-паук)

При этом любая часть структуры может отсутствовать, что превращает ее в ту или иную языковую конструкцию.

Спасибо за ответ.
И новые вопросы

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

Пусть P1 истинно, выполняется F1.
Что далее?
Проверка дуг с P3 и P4?
Допустим P3, следовательно F3 и следующая итерация.
А, если не P3 и не P4, то что? Я так понимаю - всё равно следующая итерация, ведь P1 то было истинным, и, если бы веток P3 и P4 не было, то цикл бы продолжался. Или ошибаюсь?

А что можете сказать про параллельное соединение структур?
PS.
Вообще-то совершенно не улавливаю разницу между:

и

Если правая и левая вершина - это одно и то же.
И потому все дуги, любой направленности, по идее должны просматриваться в установленном порядка (сверху вниз)
На рисунке получается ЦД с 4 ветками.

В руководстве это описано как общая форма организации циклов.
Вполне возможно, что я её неверно назвал "пауком", потому что семантика ее не определена, но на ее основе существовала библиотечная структура такого вида:

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

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

Спасибо за разъяснения, но вопросы только прибывают.
Переход на одну из параллельных вершин - новая непонятка. Можно предположить, что за этим стоит, если вспомнить примеры кода из книги В. от 1980г , но это неправильно мысленно опираться на конкретную реализацию
PS.
Наверное дальше копать больше не буду. Если случайно попадутся материалы, то тогда можно опять интерес проявить.

БОЛЬШОЙ БРАТ СЛЕДИТ ЗА НАМИ?

Что-то я не понял. Кто знает, поясните, пожалуйста.

1. Есть такой англоязычный сайт
http://www.progtown.com/

Вопрос первый: что это за сайт?

2. Почему-то на этом сайте имеется копия (в переводе на английский) темы, которую PSV100 недавно открыл на РСДН (про ДРАКОН, блок-схемы, как их рисовать (и про Р-технологию).
http://www.progtown.com/topic857960-dra ... -draw.html

Вопрос второй: зачем сделан этот английский перевод?

3. Уточняю. Оказывается там переведена не одна тема, а весь раздел "Философия программировния" сайта РСДН.

Или, может быть все гораздо проще... и этот перевод на английский организован сайтом РСДН?

Может быть здесь ответ:
http://rsdn.ru/forum/life/4646534.aspx
http://rsdn.ru/forum/rsdn/4228014.aspx

Да, конечно, теперь все ясно.

У меня остался лишь один вопрос. Почему для дублирования сайта РСДН выбран именно этот сайт http://www.progtown.com/
Что в нем такого примечательного?

Упоминание о Вельбицком в 2012 году
http://mediaps.org/medias/medias_en2.shtml

В составе программного комитета коференции среди прочих упомянут Igor Velbitsky

В инете есть и другие упоминания об Igor Velbitsky (правда, старые)

Я пытался найти статью В. с этой конференции но безуспешно.

Ну, с учётом того, того, что программа до сих пор "вылл бы пласед ин Април", неудивительно... м.б. конференция не состоялась?..

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

На статьи ссылаются, да и Кипр же это, чегож не состояться:)

Дык Греция-то рядом... а где ссылаются, можно узнать?..
Там, кстати, ещё Вольфенгаген числится... тоже известный... в связи с ФП и ЛП...

Я, похоже, ошибся годом. Есть ссылки на статью с конференции 2010г.

Вельбицкий, И. В. Визуальная технология программирования нового поколения для широкого
применения на базе стандарта ISO/IEC 8631 / И. В. Вельбицкий // Междунар. конф. Кипр, 2010.