DRAKON.SU

Текущее время: Четверг, 28 Март, 2024 21:36

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




Начать новую тему Ответить на тему  [ Сообщений: 31 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: Среда, 10 Апрель, 2013 12:13 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Благодаря подсказке Геннадия Тышова, я прочитал на github сообщение Кирилла Пименова. https://github.com/kirushik/libtougarin/

Проект Кирилла меня заинтересовал и я послал ему письмо:

Цитата:
9 апреля 2013 г. 9:49
Здравствуйте, Кирилл Пименов!

Вы писали на github (два года назад):

            Цитата:
            Дальнейшие планы

            * Разработать визуальный редактор диаграмм языка ДРАКОН с открытым под GNU/GPL исходным кодом. В разработке планируется использовать язык C++ и набор инструментов Qt.

            * Разработать принципы сборки блок-схем ДРАКОНа в исполняемые программы. (Скорее всего, будет реализована сборка в llvm-байткод.)

У меня вопрос. В каком состоянии Ваша разработка сейчас?

Приглашаю Вас принять участие в обсуждении ДРАКОНа на официальном форуме:
viewforum.php?f=77

С уважением,
Владимир Паронджанов


Кирилл прислал очень интересный и содержательный ответ.
С разрешения Кирилла публикую ответ в следующем сообщении.


Последний раз редактировалось Владимир Паронджанов Среда, 10 Апрель, 2013 15:05, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 10 Апрель, 2013 12:21 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Ответ Кирилла Пименова

Цитата:
Владимир, здравствуйте.

Мне на самом деле лестно получить Ваше письмо, особенно если учесть что два года назад я осознал, что полностью реализовать задуманное в одиночку я не потяну, и поэтому отложил проект в “долгий ящик”.

КАРТИНКИ ГРЯДУЩЕГО

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

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

Итак, мне бы хотелось видеть ДРАКОН в качестве некоей lingua franca для прототипирования алгоритмов и реализаций протоколов.

ЧТО ЭТО ПОДРАЗУМЕВАЕТ?

ДРАКОНу нужно какое–то ещё выражение, кроме графического, такое, которое легко интегрируется в имеющиеся промышленные toolchains и инструментарий разработки.

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

Требование 1. ОТКРЫТЫЙ ФОРМАТ

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

Требование 2. ТЕКСТОВЫЙ ФОРМАТ

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

Требование 3. ЧЕЛОВЕКОЧИТАЕМЫЙ ФОРМАТ

В–третьих, этот формат должен быть человекочитаемым — то есть допускать его генерацию и редактирование “руками”, а не средствами программы–транслятора из графического представления.

Требование 4. ВЗАИМООДНОЗНАЧНОЕ СООТВЕТСТВИЕ

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

Требование 5. СТАНДАРТНЫЙ ФОРМАТ

В–пятых, этот формат разумно делать на основе имеющихся стандартных текстовых форматов. Это обеспечит простоту интеграции нашего формата с другими программными компонентами — благо всякого рода парсеры и объектные представления можно будет задействовать имеющиеся.

Комментарий 1. ТОЖДЕСТВЕННОЕ ПРЕДСТАВЛЕНИЕ

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

Никаких изменений и дополнений самой графической формы записи, естественно, не предполагается, и четвёртый пункт явно требует однозначное соответствие этого расширения языка оригинальному ДРАКОНу.

Если разработать такой стандарт и реализовать к нему “образцово–показательную” реализацию, ДРАКОНом практически сразу же можно будет автоматизировать многие программистские–задачи–для–непрограммистов.

Комментарий 2. ТРИ СЛОЯ

По сути, это позволит легко разделить реализацию ДРАКОНа на три слоя независимых компонент:

— визуальные редакторы графического представления ДРАКОНограмм, как общего назначения, так и специфические/встроенные;

— текстовый формат для унифицированного сохранения на диск, передачи по сети и сохранения в БД этих схем;

— и наконец прослойка трансляторов, выполняющая полезное действие на основе этих единообразных и стандартизированных текстовых записей.

ПРИМЕРЫ

Примерами последних могут служить:

— трансляторы ДРАКОНа в программы на других языках программирования,

— проблемно–специфичные исполнители ДРАКОНограмм (наподобие макросов VisualBasic в Microsoft Office),

— разного рода инструментарий для тестирования и проверки корректности визуально созданных диаграмм.

АДАПТАЦИЯ К НУЖДАМ ПОЛЬЗОВАТЕЛЕЙ

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

Естественно, я верю что это позволит резко увеличить пользовательскую базу и востребованность ДРАКОНа и связанной с ним софтовой экосистемы.

ИТОГ

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

Мне, естественно нужна сторонняя экспертиза для того, чтобы проверить соответствие моей имплементации пяти изначальным тезисам–постулатам.

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

НУЖНА ПОДДЕРЖКА СООБЩЕСТВА

Если я получу валидацию и поддержку сообщества, я готов:

— залатать обнаруженные дыры в спецификации

— и в кооперации с другими энтузиастами спроектировать и реализовать “образцово–показательную” реализацию для всех трёх слоёв.

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

ПРОТОТИП И ПОПЫТКА

Прототип такой записи для одной из схем Вашего авторства можно посмотреть здесь: https://github.com/kirushik/libtougarin ... ample.json

Брошенную на середине попытку формализованной записи каждого из узлов — здесь: https://github.com/kirushik/libtougarin ... 0%BE%D0%B2

ВОПРОС

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


Последний раз редактировалось Владимир Паронджанов Среда, 10 Апрель, 2013 14:52, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 10 Апрель, 2013 13:04 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 234
Откуда: Украина, Киев
Замечательный ответ дал Кирилл. Многое из этого уже не раз высказывалось.
Главное, что-бы была осознана необходимость куда-то двигать ДРАКОН. Поскольку, без этих необходимых усилий он будет по-прежнему бесполезен для серьёзного применения.
По-поводу предложенной Кириллом JSON нотации, её ещё надо прорабатывавать в сторону валидности получаемых JSON-документов. И не совсем понятен сам принцип, как Кирилл представляет себе построение JSON-представления ДРАКОН-схем. Там он вроде как пытался изобразить древовидную структуру? Какова предполагается глубина этой структуры?

И... пожалуй таки надо создавать открытую реализацию ДРАКОН-редактора.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 10 Апрель, 2013 13:38 
Аватара пользователя

Зарегистрирован: Пятница, 25 Сентябрь, 2009 13:10
Сообщения: 46
Откуда: Tel-Aviv
Ярослав Романченко писал(а):
И... пожалуй таки надо создавать открытую реализацию ДРАКОН-редактора.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 10 Апрель, 2013 13:47 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 234
Откуда: Украина, Киев
Роман М. писал(а):
Drakon-editor - чем не открытый.
Открытый-то открытый, но весьма отдалён от тех. задания. Над ним ещё работать и работать.
Техническим заданием на ДРАКОН-редактор является (если не ошибаюсь) вся 14-я глава книги Паронджанова "Как улучшить работу ума". Надо открывать и делать по написанному, всё остальное лишь породит бледные тени ДРАКОНа.
Роман М. писал(а):
Открытые реализации редакторов имеются.
Вы пишете во множественном числе. Вам известны ещё какие-то открытые реализации?
Роман М. писал(а):
Нужно чтобы была открытая техническая документация (спецификация).
Как Вы добьётесь открытой документации в данном конкретном тяжёлом случае?
Геннадий Тышов писал(а):
Ильченко Эдуард писал(а):
Попробую внести некоторый конструктив по вопросу формата DRT.
...
Надеюсь, уважаемый Геннадий Николаевич поправит ошибки и подскажет, что должно быть на месте знаков вопроса.
Владимир Паронджанов писал(а):
Это очень важное и обширное сообщение и важный конструктив.
Желательно услышать комментарии на предложение Эдуарда Владимировича.
Уважаемые Эдуард и Владимир,
я не знаю, что и для чего Вы это делаете, смогу ли я при этом помочь.
Есть такой старый анекдот:
Цитата:
Стоит пьяный мужчина перед витриной цветочного магазина и вслух размышляет: "Хочу ли я? Могу ли я? Говно ли я? а, вспомнил, магнолия!"
Как-раз тот случай.


Последний раз редактировалось Ярослав Романченко Среда, 10 Апрель, 2013 14:13, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 10 Апрель, 2013 15:34 

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

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


Согласен с Ярославом Романченко. Чтобы ответить на замечание Романа М., даю дополнительное разъяснение.

1. Спецификация языка ДРАКОН есть. Написанная строгим техническим языком.

2. Спецификация называется (примерно) так: "Графический (визуальный) синтаксис языка ДРАКОН". Спецификация состоит из 37 тезисов. Тезисы ссылаются на строгие рисунки, которые разъясняют содержание тезисов.

3. Такая глава есть в следующих пяти источниках (перечисленных в хронологическом порядке).

          1. Паронджанов В. Д. Графический синтаксис языка ДРАКОН //Программирование, 1995, №3. – С. 45–62.

          2. Паронджанов В. Д. Как улучшить работу ума. (Новые средства для образного представления знаний, развития интеллекта и взаимопонимания). — М.: Радио и связь, 1998, 1999. — 352 с. — Иллюстраций: 154.
                  — Глава 14. Визуальный дракон-редактор. — С. 217-227.
                  — Глава 15. Описание визуального синтаксиса языка ДРАКОН. — С. 228-236.

          3. Паронджанов В. Д. Как улучшить работу ума. Алгоритмы без программистов – это очень просто! — М.: Дело, 2001. – 360 с. — Иллюстраций: 154.
                  — Глава 14. Визуальный дракон-редактор. — С. 226-235.
                  — Глава 15. Описание визуального синтаксиса языка ДРАКОН. — С. 236-244.

          4. Паронджанов В. Д. Дружелюбные алгоритмы, понятные каждому (Как улучшить работу ума без лишних хлопот). — М.: ДМК-пресс, 2010. – 464 с. — Иллюстраций: 233.
                  — Глава 21. Визуальный конструктор алгоритмов (дракон-редактор). — С. 327-338.
                  — Глава 22. Визуальный синтаксис языка ДРАКОН. — С. 339-348.

          5. Паронджанов В. Д. Учись писать, читать и понимать алгоритмы. Алгоритмы для правильного мышления. Основы алгоритмизации. — М.: ДМК Пресс, 2012. – 520 с. — Иллюстраций: 272.
                  — Глава 32. Конструктор алгоритмов (помощник человека). — С. 395-415.
                  — Глава 33. Графический синтаксис языка ДРАКОН. — С. 416-424.

4. Содержание спецификации практически неизменно. Графический алфавит ДРАКОНа стабилен и неизменен. Единственное изменение — добавление иконы "соединитель".

5. Чем отличаются описание языка ДРАКОН во всех перечисленных источниках?
В рамках спецификации — практически ничем. Спецификация — это одна из глав каждой книги. И эта глава почти без изменений повторяется во всех источниках.

6. Чем отличаются остальные главы во всех книгах? Только степенью детализации и формализации материала. Детализация и формализация неуклонно возрастают в каждой следующей книге.

7. Последняя книга (изданная в 2012 году) отличается максимальной детализацией и формализацией. Книга позиционируется как Основы алгоритмизации и представляет собой УЧЕБНОЕ ПОСОБИЕ.

ДОБАВЛЕНИЕ 1

Я надеюсь, что с выходом этой книги:
Цитата:
Паронджанов В. Д. Учись писать, читать и понимать алгоритмы. Алгоритмы для правильного мышления. Основы алгоритмизации. – М.: ДМК Пресс, 2012. – 520 с. Иллюстраций: 272.
вопрос о спецификации на язык ДРАКОН следует считать закрытым. Именно эта книга содержит наиболее полную и точную информацию.

Мне неизвестны критические замечания на данную книгу, содержащие претензии относительно спецификации на язык ДРАКОН.

ДОБАВЛЕНИЕ 2

Описание синтаксиса языка ДРАКОН в электронном виде см. здесь:
http://drakon.su/_media/biblioteka/chas ... isanie.pdf


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 17 Апрель, 2013 09:48 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Только на это уже было сказано:
Ярослав Романченко в viewtopic.php?p=78811#p78811 писал(а):
...
В том-то и дело, что не очень подробно. А для того что-бы реализовать то о чём вы пишете нужно очень подробно и желательно в (Е)БНФ форме. Потом нужно строить сканер, парсер по этой (Е)БНФ форме, синтаксический анализатор...
...

Видимо, и при реализации работы с маршрутами в ГРАФИТ-ФЛОКС (метода ГР для языка ГРАФИТ - кажется, там такая терминология) тоже было как-то так?..


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 16 Май, 2013 15:17 

Зарегистрирован: Четверг, 11 Апрель, 2013 21:07
Сообщения: 6
Добрый день. Я тот самый Кирилл Пименов, и у меня наконец-то разгреблось время поучаствовать этом обсуждении.

Во-первых, огромное спасибо всем, кто указал на некооректности в моём JSON–формате трёхлетней давности. То представление было написано «наивно», «на салфетке» — с целью проверки принципиальной возможности формулировать JSON-текст в любом обычном блокноте. Пожалуй, вывод — всё-таки без хотя бы верификации/подсветки синтаксиса оперировать тяжело даже с JSON — то есть подобное представление годится для чтения/мелких правок, но не для полноценного авторинга схем. В общем-то, мне не видится это проблемой, но запомним на будущее.

Так или иначе, я поправил JSON–формат (https://github.com/kirushik/libtougarin/blob/master/sample.json) и на пробу просто тождественно оттранслировал его в YML (https://github.com/kirushik/libtougarin/blob/master/sample.yaml), который является также стандартным и широкораспространённым надмножеством JSON'а. Если этот вариант нам после рассмотрения покажется более приятным/перспективным, можно будет ещё более облегчить запись за счёт использования специфических YML-фич вроде обратных ссылок и именованных фрагментов.

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

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

И я вижу принципиально важным вопрос этой стыковки. Реализация автономного комплекта ПО ДРАКОН мне видится гораздо менее перспективным, нежели встраивание компоненты «визуальный ДРАКОН–редактор» в уже имеющиеся рабочие процессы (опять-таки, не только и не столько программистские, сколько офисные–автоматизационные). Было бы круто дать возможность бухгалтеру без знания языков 1С изменять внутреннюю логику складского учёта без внешних вмешательств. Секретарше босса — автоматизировать перенаправление корреспонденции в СЭД самой, а не силами “компьютерщиков”. Графическому дизайнеру — переложить рутинные задачи по хитрой оптимизации изображений для сайтов на плечи роботу. Естественно, никто из них не будет учить «настоящий» ЯП и отдельное ПО к нему для решения этих задач. Но возможности расширить/автоматизировать свои повседневные возможности они окажутся сташно рады.

Подведу итог вышесказанному: ДРАКОН — потенциально даст возможность непрограммистам использовать большую часть возможностей своего имеющегося ПО для автоматизации ежедневных задач. Чтобы этого добиться, необходимо таким образом направить разработку, чтобы 1) максимально упростить сторонним программистам интеграцию ДРАКОНа в свои продукты и 2) мягко направлять все такие продукты по пути «совсем непрограммистского» использования схем, то есть без использования привычных программистских абстракций типа «имён функций» или «типов данных».

Cтыковка (компоненты редактора со свободным кодом) + (стандартизированный формат обмена на основе общеупотребимых стандартов) + (множество стыковочных интерфейсов, трансляторов и интерпретаторов этого формата) — это лучшее, что я могу придумать в этом направлении. Соответственно, выношу свои наработки под критику сообщества именно для валидации этого пути или формулирования какой-то ещё более обоснованной альтернативы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 18 Май, 2013 17:23 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
В общем, Вы считаете "нишей" для техноязыка (кроме программирования простых железяк "пошагово") представление сценариев использования разного софта? примерно как предлагается здесь:
__1__ в viewtopic.php?p=80078#p80078 писал(а):
...
[*] В описании ничего не сказано о возможности систематизации локальных файлов и об их запуске средствами самой программы. Программа обязана выполнять функцию органайзера не только задач, но и соответствующих файлов.[/list]
...
Тогда, да, нужна "предметная типизация" имён величин в схемах. Полагаю, её основы заложены ещё в ГОСТ на блок-схемы. Конечно, нужно развить - например, как в семействе языков здесь (имеются в виду схем и атрибутов). Редактор только бы такой... :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 18 Май, 2013 17:58 

Зарегистрирован: Четверг, 11 Апрель, 2013 21:07
Сообщения: 6
Владислав Жаринов писал(а):
В общем, Вы считаете "нишей" для техноязыка (кроме программирования простых железяк "пошагово") представление сценариев использования разного софта?

Не совсем так. Я скорее считаю, что любое решение программистской задачи имеет некоторую позицию на оси «общее–частное решение».
Под “общими решениями” я подразумеваю максимально абстрактные инструменты, имеющие своей миссией решение информатизационных задач в максимально общем виде. Это то, чем на самом деле любят заниматься лучшие из программистов, поэтому с этой стороны шкалы продуктов довольно–таки много. Наиболее экстремальными представителями лагеря будут, например, компиляторы Тьюринг–полных языков программирования или программные интерфейсы операционных систем общего назначения.
Полной противоположностью к ним являются “частные решения”, когда решается максимально локальная информатизационная задача, и перед разработчиком софта не ставится ни малейшей цели сделать “универсально”, “масштабируемо” или там, на английский манер “future proof”... Возможных «экологических ниш» в этой половине шкалы на самом деле гораздо, на порядки, больше. Но все многочисленные ниши тут пока абсолютно свободны, а несчастные пользователи выполняют работу компьютеров и вручную борются с рутиной. И очень редко когда какая–нибудь корпоративная ИС (документооборота, планирования ресурсов предприятия, управления клиенской базой...) имеет «человеческое лицо» и решает задачу в частности, зато отлично и эргономично. Хотя в принципе некоторая небольшая тенденция по «очеловечиванию» IT последнее время наблюдается — взять хотя бы технику Apple или сравнить понимаемость программ на FORTRAN и Ruby.

В общем, я считаю что адекватное средство для решения максимально частных задач силами самих «утопающих» — это то, что сейчас необходимо миру. И поэтому я рад увидеть в ДРАКОНЕ потенциал стать подобным средством.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 18 Май, 2013 19:10 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Здравствуйте, Кирилл!

Я очень рад, что Вы вышли на большую арену и принимаете участие в дискуссии.
kirushik писал(а):
Я ... считаю, что любое решение программистской задачи имеет некоторую позицию на оси «общее–частное решение».

Под “общими решениями” я подразумеваю максимально абстрактные инструменты, имеющие своей миссией решение информатизационных задач в максимально общем виде.

Это то, чем на самом деле любят заниматься лучшие из программистов, поэтому с этой стороны шкалы продуктов довольно–таки много.


Вы пишите интересные вещи. Я ни в коем случае не возражаю Вам. И даже не комментирую Ваши слова.

Я хочу лишь дополнить сказанное Вами и пояснить свою позицию.

Я предполагаю, что первое массовое применение ДРАКОНа произойдет в медицине (а не в программировании).

Язык ДРАКОН будут использовать в качестве средства представления медицинских алгоритмов.

Если Вас интересует эта тема, посмотреть можно здесь:
viewtopic.php?f=62&t=4049
а также в Википедии в статье ДРАКОН

Это не имеет никакого отношения к программированию.

В сообщении viewtopic.php?p=73910#p73910 врач vasili111 писал(а):
Я сам по профессии врач и могу сказать что ДРАКОН прекрасно подходит для описания алгоритма постановки диагноза или алгоритма лечения.

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


Кирилл, пожалуйста сообщите, как Вас по отчеству.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 19 Май, 2013 06:35 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Да, блок-схемы подобного рода делали (для обучения в частности)... кстати, был пример и автоматного подхода один по крайней мере (ещё в 1980-е)...
Надо сказать, что на "непрограммистских" предметках как раз отчётливо выявляется правильность подхода В.Д. к отображению модели, отражённая в его иллюстрациях - "однослойная" симультанность в противовес "многослойной" сукцессивности. Ибо тут те не программирование по техзаданию в редакторе... :) Представьте себе, как тот же медик будет воспринимать схему экстренной помощи, разметка которой вся важна для дела, но разорвана по "слоям" (если они не м.б. отображены одновременно)... а главное - как он будет вспоминать её содержание, когда надо исполнять?.. :wink: :|


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 20 Май, 2013 18:05 

Зарегистрирован: Четверг, 11 Апрель, 2013 21:07
Сообщения: 6
Владимир Паронджанов писал(а):
Кирилл, пожалуйста сообщите, как Вас по отчеству.

Андреевич, но мне 26 лет и я бы предпочёл оставаться пока без отчества :-).

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 20 Май, 2013 19:34 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 585
kirushik писал(а):
То есть расцвет ДРАКОНа мне видится именно в развитии среды максимального абстрагирования от программитстских деталей.

Согласен.

kirushik писал(а):
...рабочие процессы (опять-таки, не только и не столько программистские, сколько офисные–автоматизационные).
...
Но все многочисленные ниши тут пока абсолютно свободны, а несчастные пользователи выполняют работу компьютеров и вручную борются с рутиной.

Именно так! Компьютеры, они для людей, а не для программистов.

kirushik писал(а):
И очень редко когда какая–нибудь корпоративная ИС имеет «человеческое лицо»

Плакал.

kirushik писал(а):
1) максимально упростить сторонним программистам интеграцию ДРАКОНа в свои продукты.


Как это сделать?
Можете ли объяснить на простом примере?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 21 Май, 2013 00:52 

Зарегистрирован: Четверг, 11 Апрель, 2013 21:07
Сообщения: 6
Степан Митькин писал(а):
Как это сделать?
Можете ли объяснить на простом примере?


Ну самый простой и наглядный пример — это готовая джаваскрипт–библиотека с открытыми исходниками, которая при подключении к коду веб–страницы превратит отведённый ей блок ХТМЛ–разметки в интерактивный ДРАКОН–редактор прямо в браузере. А программистское взаимодействие с ней сведётся к получению текстового представления из этого обособленного модуля по нажатию кнопки «Готово», сохранение этого текста и скармливание транслятору, который уже превратит этот текст в какую–то сущность прикладной полезности, набор IVR–инструкций для АТС Астериск например.

Ремарка. Я взял веб в качестве примера именно из–за присущей его нынешней ипостаси развитой модульности “из коробки”. Сам я с клиентским веб–программированием не особо в ладах, и предпочту написать подобные модули для окружений Qt и/или Android, просто в силу своих компетенций.

Если же вопрос касался скорее человеческого плана проблемы («Как сделать, чтобы программистам приходила в голову идея встроить в свои изделия ДРАКОН?»), то это естественно является отдельной задачей «Популяризация единой совместимой экосистемы ДРАКОН–реализаций», равноценной по сложности собственно написанию всего потребного кода. В качестве базовых идей в голову приходят «Создание удобной игрушки–развлекушки для программистов, включающей в себя ДРАКОН–редактор» и «Технические заметки на Хабрахабре про особенности реализации и внедрения ДРАКОНа в наши продукты». Опять–таки, продвижение — не самая сильная сторона моих профессиональных компетенций, но по счастью мне есть кому задать подобную “пятничную задачу”, непосредственно в его области специализации. Но к этому моменту необходимо уже иметь “овеществлённый” предмет для разговора естественно.

Ещё раз подчеркну — на данном этапе полезнее всего для развития моих принципов будет развёрнутая (ну или хотя бы краткая) рецензия на содержимое файлов https://github.com/kirushik/libtougarin/blob/master/sample.json и https://github.com/kirushik/libtougarin/blob/master/sample.yaml. Это может сэкономить мне неделю–другую размышлений и предохранить сообщество от технологических несогласий (а то и форков) где–нибудь в туманном грядущем.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 21 Май, 2013 10:40 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 585
Провёл инспекцию документа по адресу
https://github.com/kirushik/libtougarin/blob/master/sample.json


Вот результат:

line 11
"skewers" - (означает шампуры) Неподходящий здесь термин.
Должно быть "branches" (ветки).

line 22
Содержимое иконы хранится в уже разобранном виде. Почему это плохо?
1. Получается, что каждый тип икон имеет разный набор полей.
Это неудобно для хранения диаграмм в базе данных.
2. Синтаксический разбор (parsing) перемешан с хранением схемы.
Это хороший повод для появления макаронного кода в будущем.


line 36
"default_answer", "alternative_answer" - больно напыщенно, по-учёному.
Я бы чего-нибудь попроще выбрал: yes_answer, no_answer.

line 37
"text": "Да" - хранение излишней информации.
И так ясно, что "Да".
Если наклеечки "Да" и "Нет" переставлены, для хранения этого факта достаточно логической переменной. Иными словами, данные не нормализованы.

line 78
"clause" - это разобранное представление поля "text"?
1. Дублируем информацию.
2. Смешиваем синтаксический разбор с рисованием квадратиков.


Общие замечания:

1. Нет информации о координатах.
Мы же работаем с графикой! Да, координаты можно вывести автоматически.
Но это редко будет красиво.

2. Древовидная структура документа. Почему это плохо?
- Мы имеем граф, а представляем его в виде дерева.
Документ имеет дополнительную сложность (степерь вложения элементов).
Но эта сложность не нужна. Она не соответствует природе предмета, который мы отображаем (граф).
- Плоскую структуру гораздо легче хранить в базе данных.
- Прочитать и записать её Элементарно.
- Если поменять связи между иконами, не нужно переписывать всё дерево.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 22 Май, 2013 01:24 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 73
Откуда: Россия, Санкт-Петербург
Возможно использовать такую структуру:
Код:
{
    "info": {
        "title": "Проверка летающей тарелки",
        "date": "2013-05-22",
        "author": "Madzi",
        "description": "Пример ДРАКОН схемы в формате json"
    },
    "schema": [
        {
            "id": 1,
            "title": "Проверка двигателей летающей тарелки",
            "blocks": [
                {
                    "id": 1,
                    "type": "include",
                    "text": "Проверка двигателей"
                },
                {
                    "id": 2,
                    "type": "timer_start",
                    "text": "T = 0"
                },
                {
                    "id": 3,
                    "type": "question",
                    "text": "Левый двигатель в норме",
                    "answers": {
                        "yes": {
                            "id": 4,
                            "type": "include",
                            "text": "Включить плазменный реактор"
                        },
                        "no": {
                            "id": 5,
                            "type": "question",
                            "answers": {
                                "yes": {
                                    "type": "connect",
                                    "block": 4
                                },
                                "no": {
                                    "id": 6,
                                    "type": "question",
                                    "answers": {
                                        "yes": {
                                            "id": 7,
                                            "type": "include",
                                            "text": "Включить фотонный двигатель"
                                        },
                                        "no": [
                                            {
                                                "id": 8,
                                                "type": "wait",
                                                "text": "4 с"
                                            },
                                            {
                                                "type": "connect",
                                                "block": 3
                                            }
                                        ]
                                    }
                                }
                            }
                        }
                    }
                },
                {
                    "id": 9,
                    "type": "wait",
                    "text": "4 с"
                },
                {
                    "id": 10,
                    "type": "question",
                    "text": "Тарелка взорвалась",
                    "answers": {
                        "yes": {
                            "id": 11,
                            "type": "connect",
                            "branch": 2
                        },
                        "no": {
                            "id": 12,
                            "type": "connect",
                            "branch": 3
                        }
                    }
                }
            ]
        },
        {
            "id": 2,
            "title": "Ремонт летающей тарелки",
            "blocks": [
                {
                    "id": 1,
                    "type": "deck",
                    "title": "Установить признак",
                    "text": "Авария тарелки"
                },
                {
                    "id": 2,
                    "type": "include",
                    "text": "Вызов главного демона"
                },
                {
                    "id": 3,
                    "type": "include",
                    "text": "Волшебный ремонт тарелки"
                },
                {
                    "id": 4,
                    "type": "pause",
                    "text": "2 мин 48 c"
                },
                {
                    "id": 5,
                    "type": "deck",
                    "title": "Снять признак",
                    "text": "Авария тарелки"
                },
                {
                    "id": 6,
                    "type": "connect",
                    "branch": 3
                }
            ]
        },
        {
            "id": 3,
            "title": "Пробный полёт летающей тарелки",
            "blocks": [
                {
                    "id": 1,
                    "type": "timer_start",
                    "text": "A = 0"
                },
                {
                    "id": 2,
                    "type": "include",
                    "text": "Включить телепортацию",
                    "left": {
                        "type": "sync",
                        "text": "A = 3 мин"
                    }
                },
                {
                    "id": 3,
                    "type": "include",
                    "text": "Отключить гравитацию",
                    "left": {
                        "type": "sync",
                        "text": "A = 5 мин"
                    }
                },
                {
                    "id": 4,
                    "type": "include",
                    "text": "Выход из астрального тела",
                    "left": {
                        "type": "sync",
                        "text": "A = 8 мин"
                    }
                },
                {
                    "id": 5,
                    "type": "parallel",
                    "text": "Шабаш злых духов",
                    "title": "Останов"
                },
                {
                    "id": 6,
                    "type": "parallel",
                    "text": "Шабаш злых духов",
                    "title": "Пуск"
                },
                {
                    "id": 7,
                    "type": "include",
                    "text": "Пробный полёт тарелки"
                },
                {
                    "id": 8,
                    "type": "include",
                    "text": "Анализ полёта"
                },
                {
                    "id": 9,
                    "type": "end"
                }
            ]
        }
    ]
}


Полностью от дерева уйти не удаётся из-за "странных" связей назад в ветках имеющих связь вперёд.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 22 Май, 2013 09:24 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 585
Почему ДРАКОН такой понятный?

Есть ли объективное объяснение у этого интуитивного ощущения? Есть!
Дело в том, что в основе ДРАКОНа лежит плоский прямоугольный граф.

В чём особенность плоского прямоугольного графа?
1. Нет пересечений рёбер.
2. Каждый узел может иметь максимум четырёх соседей: сверху, снизу, справа и слева.
3. Соседи слева и справа лежат на одной горизонтальной прямой.
4. Соседи сверху и снизу лежат на одной вертикальной прямой.

Глазу легко распознавать этот паттерн. Мозгу легко в нём ориентироваться.
Недаром прямоугольная (как в Манхеттене) планировка городов так удобна для навигации.

Вот посмотрите. Это каноническая ДРАКОН-схема про ремонт летающей тарелки:
Вложение:
Комментарий к файлу: Каноническая схема ремонта летающей тарелки.
ufo_repair.png
ufo_repair.png [ 159.85 КБ | Просмотров: 19968 ]

А вот соответствующий ей прямоугольный граф:
Вложение:
Комментарий к файлу: Плоский прямоугольный граф в основе канонической схемы.
ufo_repair_graph.png
ufo_repair_graph.png [ 140.37 КБ | Просмотров: 19968 ]


Узлы соединяются прямыми отрезками.
Узлы располагаются:
1. В центрах икон.
2. В изломах линий.
3. В перекрёстках линий.

Поэтому имеет смысл рассмотреть следующую схему данных
Код:
nodes: {
    {
        "id": 1,
        "type": "branch_header",
        "text": "Проверка двигателей\nлетающей тарелки",
        "x": 50,
        "y": 150,
        "width": 60,
        "height": 30,
        "up_neighbour_id": 2,
        "down_neighbour_id": 3,
        "left_neighbour_id": "",
        "right_neighbour_id": ""
    },
    {
        "id": 2,
        "type": "joint",
        "x": 50,
        "y": 100,
        "up_neighbour_id": 7,
        "down_neighbour_id": 1,
        "left_neighbour_id": 5,
        "right_neighbour_id": 10
    },
}

Если потребуется, можно ещё хранить список рёбер. (Если у них есть какие-то признаки.)

Итог:
1. Храним схему в виде набора узлов. (Не в виде дерева!)
2. Каждый узел имеет айдишник.
3. Каждый узел имеет координаты и размер, а также другие параметры, если нужно.

Этот формат показал свою практичность.
Он используется внутри в DRAKON Editor'e.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 22 Май, 2013 10:39 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Вообще, конечно, Вы смешиваете в один уровень сам граф и его визуальное представление...
Плоское прямоугольное изображение графа (конечно, того, который так представим).

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

Спасибо за интересную мысль.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 22 Май, 2013 10:59 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 73
Откуда: Россия, Санкт-Петербург
На самом деле, представляя схему ДРАКОНА как набор узлов, вы убиваете изначальную идею автора.

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

Силуэт - это набор прямых.

Когда алгоритм ветвиться, то к изначальной прямой добавляются рукава. И этот рукав удобно хранить в виде прямой, внутри той иконы из которой рукав растёт.

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


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

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


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

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


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

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