DRAKON.SU

Данная тема создана по предложению Владимира Arhat109

Пасибки. Надеюсь тема не умрет, так и не начавшись. Давайте начну задавать вопросы:

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

Мне советовали для данных использовать ERIL, но у меня пока тема заглохла, на неопределенный период, поэтому хорош он или нет, не скажу. Автор утверждает, что очень удобен. Ермакову тоже вроде как понравился. Попробуй.

Если есть ссылка, поделитесь пожалуйста. Я как-то ничего не нашел про ERIL как языка описания данных, кроме поста на этом форуме с удаленной ссылкой на описание.

Вот-тут:

viewtopic.php?p=86045#p86045

Спасибки. А мне вот на текст ERIL wikipedia вывалилось что-то про финский ..

P.S. Только в статье нет ничего вразумительного, кроме отсылок к .. ДРАКОН и Степану Митькину.

P.P.S.
adva, спасибо за ссылку, почитал форум и скачал zip с русским описанием. В целом, это очень похоже на ДРАКОН и, как самостоятельный язык (на отдельных листах), наверное интересно. Но меня сейчас интересует практическое встраивание описания данных в ДРАКОН-схемы по принципу Lego-scratches или Ardublock. В смысле на одном листе схемы.

Что-то подобное я уже пробовал рисовать "для себя" (с UML немного знаком), но уже писал - получается каша.

Кстати, в русскоязычном переводе указано что одиночная стрелка используется для а) указания ОДНОНАПРАВЛЕННОЙ связи и б) указания ОТНОШЕНИЯ наследования .. это так и должно быть или это разные стрелки? В частности там на одном рисунке использована закрашенная стрелка, а на другом нет. Или закраска стрелки и есть "различие"?

Поясню то, что меня интересует сейчас картинкой:

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

Вопрос относительно этой картинки формулируется так: как встроить в ДРАКОН описание и использование переменных, хотя бы простых?

Как понимаю, и эта тема "канет в небытие" .. никто помочь, подсказать не хочет?

Владимир Arhat109, здесь вы лидер, вся надежда на вас.

У меня знаний по Ардублок нет.

Если поскрести по сусекам могу дать только очень отдаленную аналогию.

Как сделано в технологии Графит-Флокс.
Графит — описание алгоритма, Флокс — описание данных.

Описание данных удалено из дракон-схем и записывается на отдельных листах в виде так называемых флокс-таблиц. Все флокс-таблицы хранятся в реляционной базе данных Флокс.

Связь между алгоритмами (дракон-схемами) и описанием данных (флокс-таблицами) осуществляется с помощью идентификаторов специального вида, которые называются "флокс-идентификаторы".
http://drakon.su/_media/biblioteka/grafit_a4.pdf
http://drakon.su/_media/biblioteka/grafitfloks.pdf
viewtopic.php?f=100&t=1091

https://webcache.googleusercontent.com/ ... clnk&gl=ru

Вот еще очень-очень отдаленная аналогия от Николая Сенюгина
http://intelograf.narod.ru/
viewtopic.php?f=62&t=4060

Подобные вопросы уже поднимались, и ответа я пока не видел. Если придумаете решение, думаю будет прекрасное дополнение к дракону

А-а-а .. еле нашел куда все пропало .. хоть бы рассылку сделали что-ли.

Спасибо за ссылки, кое-что уже почитал. Оказывается система "ГРАФИТ-ФЛОКС" это "2в 1" .. вот оно как! То есть, вместо того чтобы расширять ДРАКОН добавляя к нему DDL просто создали упрощенный язык ФЛОКС и отделили его от ГРАФИТ, собрав всё уже на уровне единой СУБД управления программами. Ну вот и у меня, при совмещении получается пока только некая "каша".

Мне кажется, что совмещение может оказаться тем не менее возможным, если расширить визуальные средства, например Цветом отображения и/или видом обрамления икон (тип линий). в ч/б (двухцветном) и "строгом" оформлении (только ГОСТ фигуры и сплошные линии) изобразительных средств явно недостаточно.

Пока беру таймаут на вдумчивое прочтение ссылок.

P.S. Особенных знаний по Ардублок - в целом и не требуется. Картинка "всё объясняет" как в этом плагине можно создавать и использовать переменные разных базовых типов.

Где и как определены в нем разные "иконы" - я уже разобрался, как они рисуются и проверяются при стыковках - уже тоже по большей части нашел. Это вполне поддается модификации так, чтобы оно могло рисовать в стиле ДРАКОН и иконами от ДРАКОН. Можно прикрутить доп. проверки, согласно ограничениям языка ДРАКОН, не особо переделывая плагин .. но вот как описывать переменные программ - пока решить не могу, поскольку их нет в ДРАКОН "вовсе".

Эта работа, может повлечь за собой интересное обратное преобразование: программа, созданная для Ардуино ИДЕ (а это обычный С/С++ код) может быть впоследствии преобразована в ДРАКОН-Ардублок "автоматически". Но, опять жеж .. как рисовать DDL? Выносить на отдельный лист в стиле ФЛОКС?

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

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

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

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

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

И вот тут, мне стала симпатична идея авторов Ардублока: единые стыковочные элементы фигур Имени соответствующие типу значений этого Имени. Это наглядный подход к вопросу смешивания типов в выражениях. Не стыкуется.

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

.. как-бы не вижу достаточного перечня изобразительных средств. Есть у кого, какие идеи?

Дополню более сильным утверждением вышесказанное: ИМХО, полностью визуальный язык программирования должен оставаться наглядным и сохранять как сущность алгоритмической части, так и декларативной при полном отсутствии текстовых "пометок". То бишь "Имя" (идентификатор) - может быть полностью визуальным (картинко).

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

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

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

Тут 2 момента:
1. Стыковочный узел "целого типа". Сразу видно, какие значения и имена каких переменных сюда можно присоединить. Не получится чисто механически присоединить к примеру строковую или булеву переменную.
2. Картинка серводвигателя как Имя класса управляемого объекта. Есть такие же к просто огромному количеству датчиков и устройств управления..

Да, можно добавить "подпись" (как идентификатор конкретного объекта), но и без него - все настолько очевидно, что мой сын разобрался с применением таких блоков самостоятельно и сейчас программирует в Ардублоке и вовсе без моей помощи. 10.5 лет, но такое, мне кажется, очень наглядным и в гораздо меньшем возрасте.
И, как ни странно, эта подпись по сути ничего не изменяет, ибо поключение к конкретному выводу микроконтроллера - указано тут же цифирькой. 1 движок - 1 вывод.

P.S. текст способен обеспечить чуть больше чем "всё", именно поэтому и существуют текстовые среды разработки программ. Но .. мы же обсуждаем визуальное восприятие и его достоинства в применении к программированию, не так ли?

Спасибо, Очень интересно, будем ждать скриншот.

Желательно показать не один скриншот, а несколько — для разных типов данных (блоков управления для разных типов серводвигателей и других устройств).

А также

О, увольте! В Ардублоке наверное с десяток разных библиотек интегрировано под Ардуино датчики и шилды, которые кем только не выпускаются! Тотже "серводвигатель" есть в нескольких ипостасях, пардон библиотеках. Выкладка всех картинок займет просто огромное место. Согласен на пару-тройку для демонстрации подхода.