Вот какая позиция сформировалась по вопросу, топиковому для этой ветки:viewtopic.php?p=46926#p46926.

Илья недавно повторил тут:> -- Илья Ермаков в viewtopic.php?p=83715#p83715 писал(а):
> Я думаю, что попытки как пропагандировать, так и критиковать ДРАКОН, некорректны без разделения на разные целевые ниши:...Кстати, кроме всякого управляющего и бортового ПО, есть фрагменты кода и в "обычном" ПО, имеющие такой <реагирующий - В.Ж.> характер.- свою позицию:> -- Илья Ермаков в viewtopic.php?p=68824#p68824 писал(а):
> 1) Я думаю, что эффект от графового представления есть только тогда, когда оно делает явным что-то, что оказывается неявным в тексте. Граф управления для реактивных программ проясняет структуру поведения программы - все возможные маршруты, "грамматику событий". Для вычислительных программ в структуре поведения прояснять особо нечего. Зато там может быть полезным прояснять структуру зависимостей данных при вычислениях. Так что.... можно на эту тему поразмышлять.2) Говорить "контроль за соблюдением структурности программы остается за исполнителем (программистом)" я думаю, некорретктно. Очень мутное высказывание.3) Возможности выражения не-вложенно-блочных структур в программе в текстовом представлении, конечно, ограничены. И тут, опять же, сфера применения - оно бывает очень нужно в "поведенческих" алгоритмах (потому что сильно их проясняет), но совершенно не актуально в обычных.
К этому добавлю вот что:

А. Некоторые пути уменьшения сложности реагирующих алгоритмов представил PSV100 здесь:http://forum.oberoncore.ru/viewtopic.php?p=83753#p83753(надо ещё повертеть идеи).

Б. Надо представлять зависимости не только данных, но и процедур (имеется в виду по управлению; по данным тоже надо бывает, если есть нелокальная видимость величин). Насчёт этого вот:> -- Сергей Прохоренко в viewtopic.php?p=72318#p72318 писал(а):
> ... Нужно создавать в структурном редакторе собственные графические средства представления взаимосвязей (на верхних уровнях декомпозиции программы) и переходов (на нижнем уровне). Образцом такого средства не может быть Дракон. И вот почему:1. Схема взаимосвязей в структурном редакторе вынужденно должна быть иерархической: проекты состоят из модулей (объединенных в подсистемы и слои), модули из процедур и функций, процедуры и функции состоят из блоков, которые могут быть вложенными, а блоки содержат ветви алгоритма. Соответственно, связи между высокоуровневыми объектами (от процедур и функций до проектов) не являются просто переходами в программном коде, и, соответственно, не описываются Драконом - он является лишь конкурирующим способом отображения блочной структуры кода и переходов. ...- замечу, что ДРАКОН-то не может быть средством, но исчисление м.б. способом получения таких схем.
Пример здесь:http://forum.oberoncore.ru/viewtopic.php?p=62870#p62870(и такого типа схему можно получить даже "шампур-методом"). Это можно трактовать и как "двумерную схему зависимостей" процедур.
Т.е. решается проблема такого рода:> -- igor в viewtopic.php?p=28837#p28837 писал(а):
> Работая с исходниками Блэкбокс (и другими), я обратил внимание, что требуется много усилий (если модуль большой, как Kernel, например) для того чтобы обрести ясность что делает та или иная процедура, и как она используется в самом модуле. Эти затруднения произростают из того, что модуль имеет линейную структуру (по форме). Те представления о структуре модуля, которые подразумевал программист на момент написания, оказываются безвозвратно потеряны. Просто просматривая длинную вереницу процедур, трудно понять какие из них являются ключевыми, а какие служат лишь для того, чтобы обеспечить реализацию этих ключевых процедур....- но не на ДРАКОНе, а исчислением графов... и неабстрактных, как в "шампур-методе", авзвешенных(раскрашенных, нагруженных)...

И главное. Дмитрий_ВБ здесь:http://forum.oberoncore.ru/viewtopic.php?p=83147#p83147высказал вещи, которые так или иначе на ОберонКоре обсуждались в связи с инженерией ПО безотносительно к формам записи. Предварительные проработки показывают, что даже для развитой деятельности можно построить такое описание, в котором реагирующей будет ограниченная часть процессов - как по модельным типам, так и по экземплярам времени исполнения. Остальные процессы будут удовлетворять сказанному здесь:> -- Илья Ермаков в viewtopic.php?p=73509#p73509 писал(а):
> ... Процедура - обычно не более 10-20 строк. ...
Но. Для этого надо начинать с "логики верхнего уровня" в терминах Дмитрия. Замечу, что намеренно не говорю "программной" - ибо считаю эти соображения приложимыми к деятельности как таковой, безотносительно к подразумеваемому исполнителю. Об этом уже было здесь:http://forum.oberoncore.ru/viewtopic.php?p=78317#p78317.
И тогда получим модель, удовлетворяющую требованиям Дмитрия (там на самом деле можно уточнить и дополнить, но для общего представления сказанного достаточно). А иначе будет нечто подобное обсуждавшемуся в этой теме:http://forum.oberoncore.ru/viewtopic.php?p=73246#p73246(где "верхний" и "нижний" уровни свалены в кучу ради идеи "запрограммировать силуэтно-циклически")...

Что же получается? Мы можем, в принципе, применить ДРАКОН для эскизного проектирования деятельности. А скорее для постановки задачи "предметником" в графической форме. Поскольку она м.б. ему привычнее, и он больше сможет "отслоить" из своих знаний о деятельности. Это уже предлагалось:> -- Peter Almazov в viewtopic.php?p=28834#p28834 писал(а):
> Как инструмент, позволяющий вытянуть хоть что-то путное из людей, не занимающихся программированием (как здесь говорят, "нормальных людей, а не программистов") блок-схемы - это, пожалуй, подходящий инструмент.
Но. Когда аналитик создаст на основании постановки проект деятельности в "архитектурных формах", оснований для применения ДРАКОНа станет уже меньше... А при реализации всё будет зависеть также и от языка исходного текста...
В общем, имеем ещё один парадокс... уже сродниздесь (из Стругацких)... Заменим только "воспитанный человек" на "продуманная модель", ну а личное местоимение - на название языка...Но не так буквально - определённая применимость всё же будет. При следующих, полагаю, ограничениях:
* только для реагирующих процессов И/ИЛИ
* когда декомпозиция на мелкие процедуры заменяется сложной логикой крупных процедур.

А тут уже начинает рулить сказанное когда-то:> -- Димыч в viewtopic.php?p=28832#p28832 писал(а):
> вовсе не обязательно производить однозначное соответствие «икона — кусок кода». Можно же сделать соответствие «схема — конечный автомат».- т.е. визуализируется не реализация "логики верхнего уровня" наимперативномязыке, потоки управления коего представимы ДРАКОНом. А сама эта логика надескриптивномязыке, в данном случае - структур "состояние-переход" (в графовой записи - автоматных диаграмм).
Это же предлагал и Алмазов (на вопрос, чем он считает нужным заменить ДРАКОН где-то на форуме)... ну а Шалыто с коллегами реализовали в своём UniMod, как можно понять изэтой работы(в выдержку не вошло)...

Короче, первый вопрос отсюда:> -- Info21 в viewtopic.php?p=36006#p36006 писал(а):
> Я не сравниваю Дракон с яровизацией, а просто пытаюсь сказать, что нужно правильное место определить для технологии. Ну и обнаучить ее, формализовать.- как-то решается. А вот второй...

Вот так как-то...