DRAKON.SU

Крупные софтверные компании по определению делают не ПО, а деньги. Поэтому они никогда не заинтересуются разработкой чего-то совсем нового. Тем более, не западного, а советского.
Свободное ПО вокруг Дракона только появляется - время еще недостаточно прошло с момента оповещения общества.

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

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

1) В моих 80% случаях нужен больше вьюер чем редактор. Обычно разрабатываем систему с графическим интерфейсом и сдаем Заказчику. В этой части делается меньше, чем по схеме "редактор-код программы на языке высокого уровня".

2) Целый зоопарк из форматов файлов Дракон-схемы говорит о том, что кто-то в будущем выпустит еще формат, который всех устроит. Я полагаю, что для этого нужно:
- формальное и точное описание,
- API для доступа из ЯВУ,
- процедуры конвертации (из XML и обратно, во всяком случае, из .drt и обратно?)

3) Даже если появится формат и вьюер, то возникнут вопросы от домохозяек (на которых и рассчитан Дракон):
- а можно Дракон-схему посмотреть в браузере? а в Word'е?
- а если это инструкция или бизнес-процесс, можно ли текст из него в pdf для отчета?
Нет сейчас такого ПО

4) Если Вы хотите делать прикладную систему, что будете делать? Вы выберете графические средства, напишете ограниченный вариант вьюера, сделаете к нему анимацию на скриптовом языке, который выберете исходя из близости от мизинца на правой руке? Так и будет. Но если кто-то решил-таки сделать ПО, которое может быть использовано другими, есть задуматься о направлении в каком развиваться.

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

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

1) Да, мы знаем, как это сделать. Для тривиального случая пример, как уже говорилось, здесь: http://grafit-basis.narod.ru/L3/part_vi ... Pril3-n111. Но. Есть вопрос для случаев противоречивости и неполноты системы переходов. В своё время С. Прохоренко при обсуждении своего проекта высказывал кое-какие мысли. На качественном уровне. А нужна и математика, и информатика - т.е. количественно-пространственный анализ и алгопроцесс построения.

2) В принципе силуэт можно рассматривать как иную форму автоматной спецификации. Можно так понимать сказанное В.Д. в "Как улучшить...". Тут, помимо сказанного в 1), встаёт языковой вопрос реализации. Если на строго структурном ЯВУ - то нужно для программы переходить к дейкстралу. Это тоже вроде как не вопрос. Но средство поддержки намеченной Вами технологии должно позволять это (т.е. хорошо, если автоматически реализует правило преобразования здесь в п/п 5.5.2.4).
А если на языке с явными БП (включая асмы) - то можно сразу и силуэтный эскиз кодировать. Коли у нас определена трансляция любого типа вершин (а в некоторых случаях - подграфов, как то обсуждалось здесь и дальше) в структуры с goto (jmp).

3) Насчёт сетей Петри. Сами по себе они не представляются конкурентами техноязыку (и решениям по формализации отдельных алгопроцессов). Ибо дают модели систем взаимодействующих процессов. В.Д. предложил вариант моделирования. Но тут опять качественная и математическая проработки д.б. Дискуссии "от языка" в этой теме пока дали мало. Дискуссии "от содержания" в этой теме тоже...

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

Какой общий смысл? Реализация ("пакет") гарантоспособная (для всего остального можно и так сделать... и делается) связана с определением языка и технологии. А всё это, в свою очередь - с ясным пониманием предметки, начиная с качественного, через математическое к информатическому. Это уже говорилось в связи с "переопределением голов ДРАКОНа": http://drakonografika.narod.ru/L2/runaway.html#n1421. Однако в дальнейшем выяснилось, что я не первый - в несколько иной плосксти тот же вопрос раньше ставил Евгений Эдуардович: viewtopic.php?p=13999#p13999. А ещё 25-30 лет назад точно об этом говорил Кауфман: Так что мало будет предложить языковые решения - нужно дать технологию говорения... и для всего смысла языка, а не его части (скажем, не для одних только "слепышей", если говорить о граф-базированных языках)...

Он же напоминает ещё одну важную для затронутой Вами темы вещь. Что всё, что не реализовано прямо в языке, но нужно "по жизни", должен реализовать сочинитель. Это касается и результата формализации задачи - некие представления о сущностях и их отношениях либо есть в программе, либо должны вестись её пользователем. И процесса формализации - если язык исполнения (тот же прогязык) не представляет средства выразить что-то - значит, в процессе проектирования сочинителю нужны и иные языковые средства (язык спецификации). В их роли, как мы знаем, часто выступают комментарии. Но и их можно использовать по-разному - уже говорил здесь: viewtopic.php?p=69057#p69057. Что Мейер предлагал, чуть подробнее здесь.
А кроме того, целостных спецификаций для гарантоспособного изделия это не отменяет... И у них д.б. свой язык...

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

Это всё к тому, что лучшее бережение - развитие. Систематическое. Пока это идёт не очень. Если есть результаты по затронутым вопросам, будет интересно увидеть.

По поводу "несостоявшегося боя" с Шалыто. Ни в коем случае! Я за "Сбережение народа". Запретить внутривидовую конкуренцию(внутрироссийскую) при условии наличия межвидовой.

Сеть Петри - это математика, как и конечные автоматы, но шире. Есть такая партия.
http://en.wikipedia.org/wiki/File:Petri_net_types.svg

И Дракон с его циклами и параллельными процессами уже под сеть Петри подпадает.

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

Что существенно (и принципиально) - нет процесса без исполнителя. Имеем в виду одну платформу реализации деятельности - получим один алгоритм (систему). Другую платформу - другую систему. И это ещё во время сочинения. А во время исполнения системы уже влияет и физика исполнителя и среды.
О неисключаемости исполнителя - более того, о нём как отправной точке - говорил Александр Сергеевич, если помните. Хотя бы тут: viewtopic.php?p=66850#p66850. А вот конкретный пример: http://habrahabr.ru/blogs/algorithm/139199/. В этой ветке у нас обсуждались различные связанные вещи. Но для данной темы важна именно суть. В частности, анализ исполнения модели, по которой запрограммированы соответсвующие компоненты СУ ЛА.
По схеме она, типа, имеет вид алгоритма... Однако видно, что это система взаимодействующих процессов (в т.ч. из поясняющего текста). Ну и как следствие, далее восстанавливается ход этих процессов.
Вот и подумаем - а почему это "... в нашем случае получился вариант D"? И был ли обнаружен этот случай "до опыта"? Можно ли было его обнаружить - если да, то почему, если нет - то тоже почему? Если был обнаружен - то почему стал неожиданностью для пользователей системы?
И главное - а можно ли вообще проводить такой анализ только по импер-моделям (неважно, в какой записи - текстовой ли, "графитной")?.. Не привлекая спецификации исполнителя и окружения (насколько разработчики понимают их физику и логику при текущем уровне своих знаний)?..

Это к тому, что не просто не одним техноязыком делается формализация. Но и не одним классом моделей, в который попадает техноязык. Потому и у Шалыто в МФЗ есть "спецификации структуры" - фактически модели исполнителей. Несколько ограниченные - но это можно доопределить.