Вот какая позиция сформировалась по вопросу, топиковому для этой ветки:
viewtopic.php?p=46926#p46926.
Илья недавно повторил тут:
Я думаю, что попытки как пропагандировать, так и критиковать ДРАКОН, некорректны без разделения на разные целевые ниши:
- информационного характера алгоритмы (с которыми сталкиваются те 90% программистов - и которые решаются хорошей декомпозицией, часто даже управляющая логика уходит на ООП-виртуализацию - т.е. вместо IF работает полиморфизм, и т.п.);
- системный анализ, алгоритмы в предметных областях (где ДРАКОН как раз и пошёл, как видим, сейчас "в гору");
- алгоритмы управляющего (reactive, реагирующего) характера - совершенно специфичного характера код.. Где, например, декомпозиция не всегда желательна, иногда расслоение принятия решения по уровням усложняет дело.
...
Кстати, кроме всякого управляющего и бортового ПО, есть фрагменты кода и в "обычном" ПО, имеющие такой <реагирующий - В.Ж.> характер.
- свою позицию:
1) Я думаю, что эффект от графового представления есть только тогда, когда оно делает явным что-то, что оказывается неявным в тексте. Граф управления для реактивных программ проясняет структуру поведения программы - все возможные маршруты, "грамматику событий". Для вычислительных программ в структуре поведения прояснять особо нечего. Зато там может быть полезным прояснять структуру зависимостей данных при вычислениях. Так что.... можно на эту тему поразмышлять.
2) Говорить "контроль за соблюдением структурности программы остается за исполнителем (программистом)" я думаю, некорретктно. Очень мутное высказывание.
3) Возможности выражения не-вложенно-блочных структур в программе в текстовом представлении, конечно, ограничены. И тут, опять же, сфера применения - оно бывает очень нужно в "поведенческих" алгоритмах (потому что сильно их проясняет), но совершенно не актуально в обычных.
К этому добавлю вот что:
А. Некоторые пути уменьшения сложности реагирующих алгоритмов представил PSV100 здесь:
http://forum.oberoncore.ru/viewtopic.php?p=83753#p83753 (надо ещё повертеть идеи).
Б. Надо представлять зависимости не только данных, но и процедур (имеется в виду по управлению; по данным тоже надо бывает, если есть нелокальная видимость величин). Насчёт этого вот:
... Нужно создавать в структурном редакторе собственные графические средства представления взаимосвязей (на верхних уровнях декомпозиции программы) и переходов (на нижнем уровне). Образцом такого средства не может быть Дракон. И вот почему:
1. Схема взаимосвязей в структурном редакторе вынужденно должна быть иерархической: проекты состоят из модулей (объединенных в подсистемы и слои), модули из процедур и функций, процедуры и функции состоят из блоков, которые могут быть вложенными, а блоки содержат ветви алгоритма. Соответственно, связи между высокоуровневыми объектами (от процедур и функций до проектов) не являются просто переходами в программном коде, и, соответственно, не описываются Драконом - он является лишь конкурирующим способом отображения блочной структуры кода и переходов. ...
- замечу, что ДРАКОН-то не может быть средством, но исчисление м.б. способом получения таких схем.
Пример здесь:
http://forum.oberoncore.ru/viewtopic.php?p=62870#p62870 (и такого типа схему можно получить даже "шампур-методом"). Это можно трактовать и как "двумерную схему зависимостей" процедур.
Т.е. решается проблема такого рода:
Работая с исходниками Блэкбокс (и другими), я обратил внимание, что требуется много усилий (если модуль большой, как Kernel, например) для того чтобы обрести ясность что делает та или иная процедура, и как она используется в самом модуле. Эти затруднения произростают из того, что модуль имеет линейную структуру (по форме). Те представления о структуре модуля, которые подразумевал программист на момент написания, оказываются безвозвратно потеряны. Просто просматривая длинную вереницу процедур, трудно понять какие из них являются ключевыми, а какие служат лишь для того, чтобы обеспечить реализацию этих ключевых процедур.
...
- но не на ДРАКОНе, а исчислением графов... и не
абстрактных, как в "шампур-методе", а
взвешенных (раскрашенных, нагруженных)...
И главное. Дмитрий_ВБ здесь:
http://forum.oberoncore.ru/viewtopic.php?p=83147#p83147 высказал вещи, которые так или иначе на ОберонКоре обсуждались в связи с инженерией ПО безотносительно к формам записи. Предварительные проработки показывают, что даже для развитой деятельности можно построить такое описание, в котором реагирующей будет ограниченная часть процессов - как по модельным типам, так и по экземплярам времени исполнения. Остальные процессы будут удовлетворять сказанному здесь:
... Процедура - обычно не более 10-20 строк. ...
Но. Для этого надо начинать с "логики верхнего уровня" в терминах Дмитрия. Замечу, что намеренно не говорю "программной" - ибо считаю эти соображения приложимыми к деятельности как таковой, безотносительно к подразумеваемому исполнителю. Об этом уже было здесь:
http://forum.oberoncore.ru/viewtopic.php?p=78317#p78317.
И тогда получим модель, удовлетворяющую требованиям Дмитрия (там на самом деле можно уточнить и дополнить, но для общего представления сказанного достаточно). А иначе будет нечто подобное обсуждавшемуся в этой теме:
http://forum.oberoncore.ru/viewtopic.php?p=73246#p73246 (где "верхний" и "нижний" уровни свалены в кучу ради идеи "запрограммировать силуэтно-циклически"
)...
Что же получается? Мы можем, в принципе, применить ДРАКОН для эскизного проектирования деятельности. А скорее для постановки задачи "предметником" в графической форме. Поскольку она м.б. ему привычнее, и он больше сможет "отслоить" из своих знаний о деятельности. Это уже предлагалось:
Как инструмент, позволяющий вытянуть хоть что-то путное из людей, не занимающихся программированием (как здесь говорят, "нормальных людей, а не программистов") блок-схемы - это, пожалуй, подходящий инструмент.
Но. Когда аналитик создаст на основании постановки проект деятельности в "архитектурных формах", оснований для применения ДРАКОНа станет уже меньше... А при реализации всё будет зависеть также и от языка исходного текста...
В общем, имеем ещё один парадокс... уже сродни
здесь (из Стругацких)... Заменим только "воспитанный человек" на "продуманная модель", ну а личное местоимение - на название языка...
Но не так буквально - определённая применимость всё же будет. При следующих, полагаю, ограничениях:
* только для реагирующих процессов И/ИЛИ
* когда декомпозиция на мелкие процедуры заменяется сложной логикой крупных процедур.
А тут уже начинает рулить сказанное когда-то:
вовсе не обязательно производить однозначное соответствие «икона — кусок кода». Можно же сделать соответствие «схема — конечный автомат».
- т.е. визуализируется не реализация "логики верхнего уровня" на
императивном языке, потоки управления коего представимы ДРАКОНом. А сама эта логика на
дескриптивном языке, в данном случае - структур "состояние-переход" (в графовой записи - автоматных диаграмм).
Это же предлагал и Алмазов (на вопрос, чем он считает нужным заменить ДРАКОН где-то на форуме)... ну а Шалыто с коллегами реализовали в своём UniMod, как можно понять из
этой работы (в выдержку не вошло)...
Короче, первый вопрос отсюда:
Я не сравниваю Дракон с яровизацией, а просто пытаюсь сказать, что нужно правильное место определить для технологии.
Ну и обнаучить ее, формализовать.
- как-то решается. А вот второй...
Вот так как-то...