DRAKON.SU

Текущее время: Пятница, 29 Март, 2024 04:53

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 79 ]  На страницу 1, 2, 3, 4  След.
Автор Сообщение
СообщениеДобавлено: Четверг, 13 Июнь, 2019 05:58 

Зарегистрирован: Понедельник, 10 Июнь, 2019 00:35
Сообщения: 10
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):

Код:
# Turtle -- https://en.wikipedia.org/wiki/Turtle_(syntax)
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix adf: <http://drakon.su/AlgorithmDefinitionFramework#>.

# defined elsewhere ...
# adf:Algorithm rdfs:Class owl:Thing .
# adf:AlgorithmStep rdfs:Class owl:Thing .
# adf:AlgorithmEntry rdfs:subClassOf adf:AlgorithmStep .
# adf:AlgorithmExit rdfs:subClassOf adf:AlgorithmStep .
# adf:entry rdf:type rdfs:Property .
# adf:exit rdf:type rdfs:Property .
# adf:next rdf:type rdfs:Property .
# SHACL constraint: adf:Algorithm must have exactly one Entry and Exit

adf:NOP rdf:type adf:Algorithm .
adf:NOP rdf:label "No Operation algorithm" .
adf:NOP-start adf:entry adf:NOP .
adf:NOP-end adf:exit adf:NOP .
adf:NOP-start adf:next adf:NOP-end .


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 13 Июнь, 2019 08:19 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
asmirnov69 писал(а):
Xочу внести предложение по стандартизации Дракона как w3c standard.
.................................................
Вы внесли важное и ценное предложение. Кроме практической пользы, оно имеет научно-практическую составляющую.

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

В этом журнале уже опубликована статья Степана Митькина
Цитата:
Митькин С.Б. Автоматное программирование на языке ДРАКОН // Программная инженерия. Том 10, № 1, 2019

https://drakonhub.com/files/pe_drakon_a ... n_2019.pdf


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 13 Июнь, 2019 10:51 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 585
asmirnov69 писал(а):
Xочу внести предложение по стандартизации языка ДРАКОН как w3c standard.

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

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

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

Пример. Следует ли данная схема правилам языка ДРАКОН?
Я не знаю.
Вложение:
eto-drakon.png
eto-drakon.png [ 29.93 КБ | Просмотров: 9389 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 13 Июнь, 2019 11:05 

Зарегистрирован: Среда, 07 Январь, 2015 14:53
Сообщения: 1356
Вопрос подобный "Яйцо или курица" -
Что должно появиться раньше - спецификация Дракона или стандарт Дракона?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 13 Июнь, 2019 16:41 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Степан Митькин писал(а):
В книгах В.Д. Паронджанова представлен набор икон языка ДРАКОН и способы преобразования схем ("исчисление икон").
Но этого недостаточно.
Требуется строгое логическое описание допустимых сочетаний икон и линий.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 13 Июнь, 2019 22:42 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Степан Митькин писал(а):
Пример.
Следует ли данная схема правилам языка ДРАКОН?
Я не знаю.
Изображение
Рассмотрим верхнюю часть схемы Степана Митькина.

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

Вот последовательность действий, позволяющая построить верхнюю часть из примера Степана Митькина.
Черный кружок — это валентная точка.
Вложение:
Для Митькина  Вставь кубик.png
Для Митькина Вставь кубик.png [ 113.53 КБ | Просмотров: 9354 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 14 Июнь, 2019 05:43 

Зарегистрирован: Понедельник, 10 Июнь, 2019 00:35
Сообщения: 10
Владимир Паронджанов писал(а):
Вы внесли важное и ценное предложение. Кроме практической пользы, оно имеет научно-практическую составляющую.

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


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

--
Если идея с 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 конечно ничего не гарантирует но способствует успеху.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 14 Июнь, 2019 07:49 

Зарегистрирован: Среда, 07 Январь, 2015 14:53
Сообщения: 1356
Степан Митькин писал(а):
Пример. Следует ли данная схема правилам языка ДРАКОН?
Я не знаю.
Изображение

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 14 Июнь, 2019 14:02 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 585
Владимир Паронджанов писал(а):
Вот последовательность действий, позволяющая построить верхнюю часть из примера Степана Митькина.
Черный кружок — это валентная точка.

Проблема тут в том, что есть два способа нарисовать финальную диаграмму.
Оба варианта обозначают один и тот же алгоритм.
Вложение:
tvetydig.png
tvetydig.png [ 28.09 КБ | Просмотров: 9324 ]


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 14 Июнь, 2019 14:19 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 585
RDF-представление или другое логическое описание ДРАКОН-схем трудно написать, а ещё труднее прочитать.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 14 Июнь, 2019 16:39 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Владимир Паронджанов писал(а):
Вот последовательность действий, позволяющая построить верхнюю часть из примера Степана Митькина.
Черный кружок — это валентная точка.

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

Описания операций с валентными точками недостаточно.
Нужно ещё указать, какой из способов правильный, а какой — неправильный.
Степан, вы правы.
Я считаю правильной схему, которую вы пометили птичкой
и неправильной ту, что вы обозначили красным крестиком.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 14 Июнь, 2019 16:50 

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

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

Изображение

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 14 Июнь, 2019 16:53 

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 14 Июнь, 2019 17:18 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Владимир Паронджанов писал(а):
Я считаю правильной схему, которую вы пометили птичкой и неправильной ту, что вы обозначили красным крестиком.
Правило. Продолжать вниз следует ту вертикальную линию (из нескольких кандидатов), которая расположена левее.
Тогда получается вход ВНУТРЬ тела условного оператора (а в противном случае - выход из тела наружу).
Хотя условный оператор - не оператор цикла, и с точки зрения структурного программирования здесь меньше претензий, но тем не менее.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 14 Июнь, 2019 17:31 

Зарегистрирован: Суббота, 16 Февраль, 2008 07:58
Сообщения: 239
Откуда: Россия, Стерлитамак
Alexey_Donskoy писал(а):
Тогда получается вход ВНУТРЬ тела условного оператора (а в противном случае - выход из тела наружу).
Хотя условный оператор - не оператор цикла, и с точки зрения структурного программирования здесь меньше претензий, но тем не менее.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 14 Июнь, 2019 19:37 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
PSV100 писал(а):
при слиянии маршрута внутри "вариантов" при "выборе" эмулировать goto вовнутрь case-секций операторов вида switch затруднительно

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 14 Июнь, 2019 19:41 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Alexey_Donskoy писал(а):
Тогда получается вход ВНУТРЬ тела условного оператора (а в противном случае - выход из тела наружу).
Хотя условный оператор - не оператор цикла, и с точки зрения структурного программирования здесь меньше претензий, но тем не менее.

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

Циклы защищены от второго (и более) входов, при потребности досрочные выходы осуществляются в привязке к условиям без потребности дублирования проверок в дальнейшем:
Вложение:
poisk.png
poisk.png [ 32.18 КБ | Просмотров: 9304 ]

Варианты развилок могут сливаться без дублирования, без потребности в дополнительном кодировании состояния:
Вложение:
napr.png
napr.png [ 39.04 КБ | Просмотров: 9304 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 14 Июнь, 2019 19:50 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
К исходному примеру ранее:
Вложение:
s1.png
s1.png [ 10.36 КБ | Просмотров: 9303 ]

Вариант алгоритма по мотивам "классической структурщины":
Код:
var flag: boolean;
...
if not C1 then
    A1;
    flag := true;
elsif not C2 then   
    A2;
    flag := true;
else
    flag := false;
end;

if flag then
    A3;
end;
A4;
...

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

Вариант с goto:
Код:
...
if not C1 then
    A1;
elsif not C2 then   
    A2;
else
    goto SKIP;
end;

A3;

SKIP:
  A4;
...

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 14 Июнь, 2019 21:45 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Необходимо ответить на вопрос Степана Митькина о нижней части его схемы.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 15 Июнь, 2019 03:55 

Зарегистрирован: Понедельник, 10 Июнь, 2019 00:35
Сообщения: 10
Степан Митькин писал(а):
Изображение


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

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 79 ]  На страницу 1, 2, 3, 4  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2024, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB