DRAKON.SU

Alexey_Donskoy: "Перегружать силуэт тоже не стоит.. Всю программу в один силуэт не затолкать"
Madzi: "третье измерение.."
Ели развернуть 3-е измерение (точнее уровени 3-го измерения) на 0-вую плоскость, получим многоэтажный силуэт. Тогда вставки (~ процедуры и проч.) можно описывать на дополнительных этажах не перегружая основной, 0-вой этаж. Развёрнутая "матрёшка" вставок (процедур), дерево силуэтов, в самом низу которого "простейшие", элементарные процедуры.Причём строгой иерархии нет, возможно обращение с любого уровня к любому уровню.
Напоминает FORTH. Похоже таким одним многоэтажным плоским силуэтом его можно весь наглядно отобразить, а при наличии соответствующего ДРАКОН-редактора и собрать. Ну и в такой форме развивать. На форум фортёрам что-ли скинуть?

Вся программная система не обязана быть объединена в один силуэт. Иначе так можно и ОС туда же запихать

На рисунке вроде бы и не дерево вовсе...
А каков должен быть вид графа на самом деле, как Вы думаете?

Ссылка на уровень с деревом стыкуется из рук вон плохо.
Третье (и далее) измерения - это, конечно, хорошо, но не совсем соответствует реальности... и эргономике... имхо...

Есть предложение - рассматривать 3-е измерение тоже в плоскости.. только декларативной. Вроде как в физической модели БД, только трактовать вьюшки - как результат действия. Т.е. программа в декларативе - упорядоченный список вьюшек. Так и с Драконом состыковаться можно. Найти бы ещё время, чтобы устаканить и отрисовать сей Горыныч

p.s.: т.е. представить вопрос несколько шире, чем в стандартной диаграмме классов.
p.s.2: да и модули вроде как тоже отрисуются.

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

По-моему, в такой конструкции могут появиться межэтажные веточные циклы. С наглядностью будет трудно - придётся "понимать" вместо "воспринимать".

Об чём и речь!
Придумать эргономичный способ отображения такого сложного графа не так-то просто!
Но - надо!

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

Согласен, но и в пределах одного этажа их можно использовать или не использовать, а можно наворотить так что не разберёшься. В "суперсилуэте" просто открывается и такая возможность.

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

Вернулся к теме, замены наименования иконы "Вставка".
Замена на термин "Процедура", нашло понимание, но не поддержку.
Есть предложение заменить наименование иконы "Вставка", на термин "Схема".

Схема.., которая определена в другом месте (в подпрограмме, процедуре, функции, макроопределении, модуле, запросе..). За бортом остаются синтаксически-зависимые особенности реализации. Наверное будут и более мягкие формулировки.
Идею поддерживаю.

Проговорить её ещё как-то надо. По маршруту..
..выполнить действие
..выбрать вариант
..выполнить схему (???)
..использовать схему (+1)
..

Вопрос, требующий ответа Да/Нет, может формулироваться очень просто. Но чтобы ответить на него могут потребоваться очень много и непростых действий. В этом, в частности, феномен "детского вопроса".
Посему может быть есть смысл ввести в ДРАКОН икону "развилка-вставка"? Она будет показывать что процедура поиска ответа описана в отдельной схеме. Добавление минимально- только вертикальные полоски, традиционно отличающие вставку от просто действия. Пример:

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

Единственным исключением может быть рекурсивный вызов функции. Вот его-то неплохо рисовать во "вставке", несмотря на то, что функция определена тут же. Учитывая, что рекурсия может получиться скрытой, обнаружение таких случаев неплохо было бы автоматизировать. С целью привлечь внимание разработчика к тому, что он нагенерил
На крайняк можно сплошняком "зажирнить" отчёркнутые границы.

Здесь можно, и вероятно нужно, использовать принцип декомпозиции, т.е. разделять и властвовать. Перед иконой "Вопрос" или "Выбор" поместить икону "Вставка" в режиме функции для получения состояния и далее в иконе "Вопрос" или "Выбор" выполнить анализ полученного состояния.

В моем понимании, при вызове функции не имеет значение способ реализации, т.е. рекурсивная или нет. Рекурсивную функцию можно реализовать в схеме "Силуэт", в одной из веток должна быть развилка с переходом на ветку с рекурсивным вызовом или на ветку с выходом из рекурсии.

А если есть несколько вариантов условий при которых возможно несколько вариантов событий? Может ввести новую икону "нейрон"?

Не понял вас. Для нескольких вариантов можно использовать блок "Переключатель" с иконой "Выбор" или можно выполнить разбор с использование нескольких икон "Вопрос".
Язык ДРАКОН вполне функционально полный, в литературе Паронджанова стабилизировался (устоялся) и лучше использовать в авторском варианте.

Кейс по кейсам? Рисунок в студию, пожалуйста.
Йес! +5!

Геннадий Николаевич, что касается рекурсии, то я имел в виду не силуэт(там все вопросы решены явно), а примитив(здесь) и нетривиальные случаи скрытой рекурсии, которые явно никак не отобразить, но технически возможно принудительно пометить иконы на разных листах, через которые идёт рекурсия(думаю будет чертовски полезно).

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

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

No, -5.
Избыточная декомпозиция. Не следует доводить стриптиз до скелета а декомпозицию программы до нулей и единиц. Вместо одной иконы две. Два раза отвечаем на один и тот же вопрос. Сначала на него отвечает вставка-функция. Потом на него же отвечает вопрос к этой вставке-функции. Можно ещё добавить вопрос к каждому выходу (Да/Нет) вопроса, вопрошающему вставку-функцию. А потом вопросы к этим вопросам. И т.д. в "дурную бесконечность". Не всё декомпозиция, нужна и композиция. C++ (и проч. об. ориент.) пришёл именно к укрупнению, к "композиции" через класс.
Ни один язык не устоялся в авторском варианте- разве что кроме автора никому не нужный. И ДРАКОНу развития не избежать. Он далеко уйдёт от "авторского варианта", который именно только вариант. Вы сами создаёте реализацию уже отличающуюся: не было у Паронджанова ни универсального сборщика, ни квадратиков-примечаний(в которых программный код) в каждой иконе. Посыл трудов Паронджанова вызовет множество ДРАКОНОов, а не один.