DRAKON.SU

Паронджанову нужно конвертировать между редакторами?

Скорее не нужно, ведь он их не использует.

Тогда для чего или кого предлагается поднатужиться?

Паронджанов тут ни при чем. Вопрос о конвертировании важен для дела. Для стратегического успеха ДРАКОН-идеологии и поддерживающих ее инструментальных средств. Это важнейший вопрос. Наиважнейший. В данном случае Паронджанов — всего лишь один из многих сотен или даже тысяч пользователей.

Как писал Маяковский:

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

Кроме того, сейчас у меня мысли далеко в стороне. — Пишу книгу про дракон в медицине. Изучаю Гиппократа (почти 800 страниц), ищу там подходящие алгоритмы, чтобы изобразить их на Драконе и вставить в книгу.

Хочу доказать, что алгоритмы в медицине были всегда. Кстати сказать, алгоритмов у Гиппократа огромное количество.

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

Прощу прощения, в конце у меня получился почти оффтопик.

2. Формат хранения схем.

Правильно!

Общий формат должен быть в виде двух-табличной БД. Это позволит не связываться с кодогенерацией, а просто через общую БД встраивать любой дракон-редактор в любую современную среду программирования! И даже использовать его в режиме пошаговой отладки программ... Здесь об этом подробней: ()

В следующем посте расскажу об интерактивном силуэте: Сортировка веток по рекурсии вызова – тоже потребует непосредственной работы с такой базой данных.

--

По форматам данных ещё вот какие мысли: сделать файл составным

Это полезно для совместимости не только с любыми дракон-редакторами, но и со стандартными программами редактирования графики. Вообще, совместимость с любыми программами, где могут понадобиться блок-схема или какая-либо информация из неё.

В 'голову' файла записывать информацию для соответствующей программы. А в rar-архиве эмулировать расширенные потоки данных, из которых можно собрать любую информацию о схеме.

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

В посте я показал (сократив подробности)), как из реляционной базы можно программным способом строить силуэты. Теперь обсудим возможности динамичной компоновки веток. Чтобы программно осуществлять такую компоновку, необходима именно реляционная модель данных, потому что, как и в случае построения сетевых деревьев, при каждом таком построении требуется огромный объём обработки поисковых запросов, а для этого реляционные базы и предназначены!..

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



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

• Ветки, заканчивающиеся хотя бы одним входящим вызовом текущей (чем раньше, тем правее)
• Исходящие вызовы (чем правее, тем позже) – эти ветки вызываются из текущей

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

В следующем рисунке 'расшифрованы' ещё кое-какие интерфейсные возможности динамичного силуэта.

Я как раз это и предлагал. Тут есть два варианта:
1. В диалогах открытия и сохранения иметь два расширения: для текущего формата и для нового, общего.
2. Текущие диалоги оставить как есть, но добавить команды импорта/экспорта.

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

С другой стороны, в файле можно предусмотреть раздел, в котором будут дополнительные данные, которые какой-то редактор пожелал добавить. И там могут храниться цвета и положения на холсте.

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

Есть производный формат, JSON совместимый, в смысле читается JSON-reader'ми. Вот: https://github.com/cognitect/transit-format

У меня все укладываются : )

Могу ошибаться, но все же выскажу свою мысль:

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

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

Эдуард, мне кажется, Вы выбрали правильное направление движения!

XML-формат не так уж плох... Возможно, он кому-то и пригодится для нестандартной работы со схемой... Но перспективный дракон-редактор должен работать именно с таблицами базы данных. Это даже не обсуждается. Это основа.

То есть, при хранении данных в XML-файле, редактор каждый раз должен их оттуда транслировать в БД, и каждый раз, при сохранении, транслировать обратно.

Есть две принципиально разные задачи (Эдуард, я повторяю Вашу мысль).
1. Сравнение разных алгоритмов.
2. Сравнение разных дракон-схем, представляющих один и тот же алгоритм.

====

1. Мне кажется, что это существенно РАЗНЫЕ задачи. Для их решения нужны, по-видимому, разные методы.

2. Не следует решать обе задачи разом, одним методом, поскольку это трудно.

3. Надо выбрать одну задачу и попытаться ее решить (забыв на время про вторую задачу).

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

При двух-табличной записи программы в БД проблемы кодогенерации не существует, потому что в такой записи текст программы изначально соответствует иконкам схемы. Программа это и есть схема. А схема – это и есть программа (только без goto). Оператор goto в реляционной записи не нужен (даже если он предусмотрен в соответствующем ЯП.

Чистосердечное признание облегчает участь )


--

Насколько я понимаю, задача при импорте кода из "портянки" в БД заключается в удалении goto и автоматического формирования таблицы связей. Объясните мне, пожалуйста, как это делать? Алгоритмически объясните (или ссылкой)).

-

А при экспорте из БД в "портянку" -- наоборот, нужно добавлять goto. Здесь проблем не вижу. Хоть и подозреваю, что кодогенерация для разных "современных" ЯП — это непростая задача. Но в чём сложность? Сложность в том, что приходится скакать через барьеры, которые сами же себе расставили бумажной (портяночной) формой записи кода.

Выделите, пожалуйста, собственную ветку для НЕ обсуждения. Дайте примеры схем, примеры сгенерированного кода, примеры отношений в таблицах. Опишите плюсы и возможные минусы.

Потом поделитесь ссылкой ...

Согласен, часть данных о представлении содержится в самой модели.


Надо. Раздел данных отображения позволит уточнить как и что располагать, как рисовать и т.д. Вспомните, что алгоритма оптимального расположения икон схемы не существует. Создатель схемы может руками указать, что вот эта схема будет выше/ниже на шампуре, этот шампур стоит ближе к другому и т.п.
Этот раздел не обязателен. Скорее всего он может содержать и нестандартные элементы. Зато один формат на множество редакторов с сохранением всего необходимого.

О том и речь!

Я за то, чтобы было 3 раздела XML (3ий раздел могут поддерживать не все редакторы, если его нет, то расположение схемы производится автоматом):

1) маршрутная часть, со ссылками на текст икон
2) текст икон (в том числе и дополнительный и прочий). Атрибуты текста наверное можно и здесь, но лучше в третий раздел.
3) Позиции/ размеры икон / атрибуты текста.

Должна быть возможность расширять атрибуты текста / икон (просто будет добавляться новый атрибут, если он не поддерживается редактором, то пропускается).

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

Текст будет в другом разделе, а в маршрутах ссылки на него (можно даже ссылки на позиции начала и конца текста, в этом случае текст может быть "чистым" выходным ЯП, без служебных символов/комментариев и т.п.).

Это чего такое?