DRAKON.SU

Xочу внести предложение по стандартизации языка ДРАКОН как w3c standard.

По сути структура Дракон-диаграмм - это граф. А именно - направленный граф с содержимым по узлам и ребрам.

Такого рода графы хорошо описываются при помощи RDF - Resource Definition Framework. Вот более-менее разумное введение https://www.w3.org/TR/2014/NOTE-rdf11-primer-20140225/

В RDF представление сводится к набору троек (subject, predicate, object), причём s, p или o может быть либо указатель на нечто называемое resource (URI), либо символьная константа (Literal). URI - это почти как URL, Literal - строка, число и т.д. Представление такими тройками даёт большие преимущества по сравнению с обычным представлением из двух множеств узлов и ребер.

Основной инструмент при работе с RDF - SPARQL, https://en.wikipedia.org/wiki/SPARQL

Существует большая система стандартов по semantic web technologies где RDF - базовый (с участием XML и URI/IRI). Все это двигается организацией W3C с участием всего ИТ бомонда.

Суть моего преложения: нужно написать W3C standard описывающий Дракон-диаграммы.
RDF и связанные с ним вещи (SPARQL, SHACL, OWL) - это всё данные. А вот алгоритмы оказываются не у дел.
Если определить скажем ADF - Algorithm Definition Framework (Дракон) на основе RDF-представления - вот вам и стандарт и мировое признание (пока в узких кругах).

Самый простой алгоритм определённый через ADF (не рабочий пример для иллюстрации, используется Turtle):

Вы внесли важное и ценное предложение. Кроме практической пользы, оно имеет научно-практическую составляющую.

Было бы очень хорошо, если бы вы написали статью на эту тему и опубликовали ее в подходящем журнале, например, в журнале "Программная инженерия".

В этом журнале уже опубликована статья Степана Митькина
https://drakonhub.com/files/pe_drakon_a ... n_2019.pdf

Категорически поддерживаю предложение о стандартизации языка ДРАКОН.
W3C, ГОСТ или ISO — это уже другой вопрос. Нужен стандарт.

Для чего нужен стандарт?
1. Чтобы люди понимали ДРАКОН-схемы друг друга вне зависимости от используемого инструмента.
2. Чтобы можно было переносить ДРАКОН-схемы из одного инструмента в другой.
3. Чтобы создавать и проверять на совместимость новые ДРАКОН-редакторы.

В книгах В.Д. Паронджанова представлен набор икон языка ДРАКОН и способы преобразования схем ("исчисление икон").
Но этого недостаточно.
Требуется строгое логическое описание допустимых сочетаний икон и линий.

Пример. Следует ли данная схема правилам языка ДРАКОН?
Я не знаю.

Вопрос подобный "Яйцо или курица" -
Что должно появиться раньше - спецификация Дракона или стандарт Дракона?

Это важный вопрос.
К сожалению, сейчас я занят.
Отвечу чуть позже

Рассмотрим верхнюю часть схемы Степана Митькина.

Она строго определена согласно правилам языка ДРАКОН.
Понятия "Макроикона" и "Валентная точка", а также действия с ними строго определены.

Вот последовательность действий, позволяющая построить верхнюю часть из примера Степана Митькина.
Черный кружок — это валентная точка.

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

--
Если идея с RDF-представлением понравилась то можно сделать важный практический шаг.
Нужно выбрать namespace URI и префикс для будущего определения стандарта языка Дракон и зарегистрировать это на http://prefix.cc
В моём примере используется префикс adf и namespace URI http://drakon.su/AlgorthmDefinitionFramework#
Это означает что полная ссылка на узел adf:Algorithm будет http://drakon.su/AlgorthmDefinitionFramework#Algorithm
Предполагается что adf:Algorithm будет базовым классом всех алгоритмов.

В RDF представлениях и SPARQL префиксы используются также как в XML, для сокращения идентификаторов. Пользователь может выбрать любой префикс но интерпретация многих namespace URI определена в системах обработки. Например http://www.w3.org/2000/01/rdf-schema# используется для описания семантики правил вывода (inference) see also https://www.w3.org/TR/rdf-mt/
При этом префикс rdfs становится практически стандартным.

http://prefix.cc не связан с w3c но полезный когда начинается практическая работа. Там пока можно без проблем зарегистрировать любой префикс. Например я зарегистрировал drk. adf уже определен но сайт регистрирует все варианты, потом можно голосовать.


Хочу отметить что реальной смысловой нагрузки ни префикс ни namespace URI не несут. Namespace URI хоть и выглядит как интернет-ссылка но не обязан существовать. Но по этой ссылке можно разместить что-то полезное как например сделано для URL на префиксе foaf.

Так что выбор префикса и namespace URI - дело ответственное. Если дойдёт до дела то это будет часть стандарта. Регистрация в prefix.cc конечно ничего не гарантирует но способствует успеху.

Отвечаем:
Данная схема не следует правилам языка Дракон.

В иконах Вопрос нет текстов вопроса.
Следовательно нельзя писать маркеры "Да" и "Нет".

В.Д. Паронджанов в своей иллюстрации не пишет маркеры "Да" и "Нет".
Но, при этом, дает С.Б. Митькину ошибочный ответ.
Почему В.Д. Паронджанов дает ошибочный ответ?
Он забывает о тесной связи в языке Дракон текстов икон и графики Дракон-схем.

Проблема тут в том, что есть два способа нарисовать финальную диаграмму.
Оба варианта обозначают один и тот же алгоритм.


Описания операций с валентными точками недостаточно.
Нужно ещё указать, какой из способов правильный, а какой — неправильный.
В этом и состоит назначение стандарта ДРАКОНа.

RDF-представление или другое логическое описание ДРАКОН-схем трудно написать, а ещё труднее прочитать.

Предлагаю лучшую альтернативу — прецедентное право

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

Степан, вы правы.
Я считаю правильной схему, которую вы пометили птичкой
и неправильной ту, что вы обозначили красным крестиком.

Правило. Продолжать вниз следует ту вертикальную линию (из нескольких кандидатов), которая расположена левее.

Всё же, речь о технологическом формальном языке, эталонные примеры необходимы, но в дополнение к формальному базису.
У В.Д. Паронджанова, вроде бы, базис имеется, может быть есть потребность в расширении, уточнениях, изменениях. Напр., насчёт ситуации выше:



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

Кстати, Степан, по поводу последнего рисунка выше. Существует ли какой-то фундаментальный принцип при трансляции (автоматической, т.е. без ручного "интеллектуального" преобразования алгоритма, с учётом конкретики каждого случая) подобных схем в императивный язык без goto? Например, в JavaScript, в контексте которого у Вас, вроде бы, немалый багаж практики.

В целом, JavaScript имеет возможность применять метки для циклов и использовать break/continue, и, видимо, в ряде случаев переход можно эмулировать. Однако, например, при слиянии маршрута внутри "вариантов" при "выборе" эмулировать goto вовнутрь case-секций операторов вида switch затруднительно (в общем случае замена оператора аля switch на серию if-ов может оказаться неэквивалентной в плане технической реализации, напр., switch-выбор может быть основан на таблицах переходов и пр.):

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

Тогда получается вход ВНУТРЬ тела условного оператора (а в противном случае - выход из тела наружу).
Хотя условный оператор - не оператор цикла, и с точки зрения структурного программирования здесь меньше претензий, но тем не менее.

На сопутствующем языке вряд ли такое получится, скорее всего в виде дублирования кода будет сделано. А визуальные структуры всё же отличаются от текстовых

Спасибо.
Вы изобразили совершенно правильный пример.

Он полностью соответствует правилу:
Правило. Продолжать вниз следует ту вертикальную линию (из нескольких кандидатов), которая расположена левее.

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

Циклы защищены от второго (и более) входов, при потребности досрочные выходы осуществляются в привязке к условиям без потребности дублирования проверок в дальнейшем:

Варианты развилок могут сливаться без дублирования, без потребности в дополнительном кодировании состояния:

К исходному примеру ранее:

Вариант алгоритма по мотивам "классической структурщины":

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

Вариант с goto:

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

Обратная же сторона медали возможностей "двумерного структурного" программирования -- отход от "классических" формальных методов верификации (и в целом принципов построения моделей). Либо необходимо преобразовывать алгоритмические модели к "классике", либо применять рассуждения на основе иных методик (понятие систем переходов, автоматные методологии и пр.).

Необходимо ответить на вопрос Степана Митькина о нижней части его схемы.

Ответ будет дан позже с учетом дискуссии в теме:
viewtopic.php?f=147&t=6144

Чтобы решить какая диаграмма правильная можно использовать такой критерий:
- сожмите обе картинки в JPEG с максимальной потерей качества
- посмотрите на размеры полученных файлов
- та картинка которая лучше сжалась та и правильнее

По крайней мере простой критерий...