OberonCore

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

dal_vjaz 0.3 :

Генерирование структур процедур для ЯПВУ семейств C/C++ и Pascal

shema.opo - файл описания ПО (бывшая shema.prg)
shema.ris - значки и сокращения
shema.str - сгенерированная структура процедуры
shema.old - старая shema.opo, запоминаемая при старте программы
shema.otk, shema.otr - файлы для отката

Редактирование действия - щелчком левой кнопки мыши на блоке действия.

dal_vjaz.cfg :

;________________________" " или "значение"
;
__шаг_индексов:__________"10"____; при нормализации
__количество_пиктограмм: "12"____; до 30 рисунков p_XX.bmp, см. picts.txt
;
; задание ключевых слов и символов для описания процедуры:
;
__строка_док_IF:_________"* если"
__строка_док_EI:_________"* иначе если"
__строка_док_EB:_________"* иначе"
__строка_док_END:________"* конец"
__строка_док_CB:_________"* цикл"
__строка_док_CE:_________"* конец цикла"
__строка_док_HD_1:_______" "
__строка_док_HD_2:_______"* ветка"
__строка_док_HD_3:_______" "
__строка_док_AD_1:_______"* к ветке"
__строка_док_AD_2:_______" "
__строка_док_A:__________"*"
__строка_док_RET:________"КОНЕЦ"
__строка_док_UNDEF_AD:___"НЕТ АДРЕСА"
__строка_док_EXIT_AD:____"ВЫХОД"
;
; задание ключевых слов и символов для текста процедуры:
;
__строка_прг_IF:_________"IF THEN"
__строка_прг_EI:_________"ELSIF THEN"
__строка_прг_EB:_________"ELSE"
__строка_прг_END:________"END;"
__строка_прг_CB:_________"CB"
__строка_прг_CE:_________"CE"
__строка_прг_HD_1:_______"END; "
__строка_прг_HD_2:_______"IF (USL_VJAZ ="
__строка_прг_HD_3:_______") THEN"
__строка_прг_AD_1:_______"USL_VJAZ :="
__строка_прг_AD_2:_______";"
__строка_прг_A:__________"(**)"
__строка_прг_RET:________"END;"
__строка_прг_UNDEF_AD:___"0"
__строка_прг_EXIT_AD:____"0"
;
__открывающий_коммент:___"(*."
__закрывающий_коммент:___" *)"
;


Разработка и документирование алгоритмов в программе dal_vjaz:

1) Производится обработка файлов описания ПО, а не файлов исходного текста
программы.
2) На первом этапе вводится предварительный вариант описания структуры
процедуры, из которого будет сгенерирована структура процедуры для ЯПВУ.
3) На первом этапе допускается свободное изменение меток действий в
описании процедуры (т.е. при вводе нового действия меняются и метки
действий, следующих за этим действием).
4) После формирования предварительной структуры процедуры производим
нормализацию меток действий с заданным шагом в описании процедуры и
генерируем структуру процедуры для ЯПВУ.
5) С этого момента текст процедуры на ЯПВУ становится главным, поэтому
отключаем режим изменения меток действий при вводе нового действия.
6) Если изменение меток действий отключено, то индекс нового действия будет
равен первому свободному дополнительному индексу (дополнительные индексы
начинаются с 901). Это позволит легко отличать только что введенные
действия от действий, введенных раньше.
7) После внесения нужных исправлений в описание процедуры соответствующие
им исправления вносятся и в текст процедуры путем сравнения в многооконном
редакторе текста и описания процедуры.
8 ) Проводим нормализацию индексов действий для описания и текста процедуры.
Нормализация индексов действий для описания процедуры производится
автоматически. А так как число действий для описания и для текста процедуры
совпадает, то и нормализацию индексов действий для текста процедуры не
составит особого труда.
9) Если при внесении изменений в программу производится существенное
изменение структуры процедуры, то имеет смысл новую структуру процедуры
сгенерировать заново, а затем перенести в нее действия из старого варианта
процедуры.

А теперь разберем вышеперечисленные шаги разработки и документирования
текста процедуры более подробно на примере процедуры (метода)
Tform_ls::b_sozdatx_shemuClick из файла u_ls.cpp исходного текста
программы dal_vjaz.



новая версия dal_vjaz на b3 и d4:

при обнаружении ошибок, когда будет время, внесу исправления в текущую версию 0.3 .
теперь полная версия будет: <дата выпуска> <текущая версия>.

b3 от 15.05.2011, скачано 10
d4 от 15.05.2011, скачано 12

сейчас дата выпуска 5.06.2011:






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



построенная схема для процедуры - начальные, основные и завершающие действия:

Появились мысли в направлении развития программы dal_vjaz, связанные с генерацией кода процедуры.

Кстати, в сообщении от 16 мая выложены новые версии b3 и d4, исправлена работа со значками и добавлены новые
значки для обозначения дополнительных маршрутных операторов процедуры, подробнее см. в выкладываемом
в rar-архиве htm-файле:

Пример использования всплывающих подсказок (как и подсветки результатов поиска по контексту) в этом сообщении. Самая что ни на есть когнитивная эргономизация... и при визуализации пригодится...

ДАЛВЯЗ 2

ДРУЖЕЛЮБНЫЙ АЛГОРИТМИЧЕСКИЙ ВИЗУАЛЬНЫЙ ЯЗЫК, версия 2

визуальное алгоритмическое программирование
с генерацией и считыванием
структурированного программного кода
для языков семейств Pascal и C/C++

--------------------------------

сейчас пока версия 2 поддерживается только для Delphi 4

dalvjaz2.txt - пояснительный текст к рисункам

d4_dal20.rar - вторая версия с исходным кодом, рисунками и пояснительным текстом.

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

Ну между переключателем и внутренностью цикла-cилуэта есть разница: у переключателя его
линейная, а не лестничная форма задается полем рисунков и сокращений: (*рис . . ДN *)
а у цикла-силуэта следующими конструкциями языка программирования:
для заголовка ветки: if <условие входа в ветку> (например: "if (wetka = )")
для перехода к ветке: <присвоение перехода к ветке> (например: "wetka := ")
<условие входа в ветку> и <присвоение перехода к ветке> задаются в файле конфигурации

Т.к в ДАЛВЯЗ 2 есть логические аналоги основных обобщенных операторов языков
программирования, то и реализовать можно почти все конструкции, применяемые в
программировании.
Вопрос с точки зрения общепринятой практики заключается в "гибридной" форме
представления: основные маршрутные операторы реализуются почти как обычно (это
касается обобщенного цикла, внешний вид у него как у традиционного для блок-схем
цикла "повторять до", а вот реальное содержание может соответствовать любому из
типов циклов, в зависимости от контекста), а дополнительные маршрутные операторы
реализуются при помощи специальных значков внутри действий - эта логика
напрямую заимствована из программирования. Это сделано с целью избежать
ситуаций, вызывающих пересечение линий в визуальной схеме.
----------------------------------------------------------------------------------------------------
Можно сказать, что я сформулировал еще одну разновидность силуэта: цикл-силуэт
1-я, ВЯЗБС-силуэт, см. в теме "Система разработки и документирования ПО РВ", ab 2.ХХ
Что еще сделано ?
* сформулирован новый визуальный интерфейс (структурно-текстовый) ввода визуальной схемы,
* разработаны алгоритмы формирования из визуальной схемы структурного кода ПО и считывания
этого кода обратно в визуальную схему
* разработан макет, действующий притом (правда пока только для одного файла программного кода),
позволяющий создавать структурное ПО на основе визуальной схемы: Паскаль (простой и компонентный),
С/С++, Java. Нужно только правильно задать файл конфигурации.
Не могу гарантировать, что в макете нет ошибок - даже наоборот, неотлаженные ошибки там наверняка
есть - но программировать уже можно !
* логика визуального отображения скорректирована с целью сделать процесс создания визуальной
схемы как можно более быстрым и легким - введены понятия "основные и дополнительные маршрутные
операторы", "обобщенный цикл"
* сделан вклад в теорию документирования ПО - предложена технология документирования ПО при
помощи ссылок и сокращений.

Есть и другие новшества, но это уже не так существенно ...

Но одно я могу сказать точно - в одиночку ни мне, ни Геннадию Николаевичу Тышову (да есть подозрение,
что и объединенными усилиями тоже) совершенную (такую, какой в свое время предстала Delphi среди IDE)
среду визуального программирования не написать. Слишком много понадобится для этого усилий и
новых идей, время которых еще не пришло - это, скорее всего, дело будущего.
Поэтому среди всего сделанного я, хотя это может показаться и странным, пожалуй могу выше всего
оценить один из моих демонстрационных рисунков моего предыдущего сообщения:

ВОЗМОЖНО, ЧТО ВИЗУАЛЬНАЯ СРЕДА ПРОГРАММИРОВАНИЯ БУДУЩЕГО БУДЕТ ВЫГЛЯДЕТЬ
КАК-НИБУДЬ ВОТ ТАК:



ну и, наконец, надо просто радоваться, если сам процесс программирования приносит чувство радости
от красиво сделанной работы (хотя ох и нечасто это бывает!)

ПРОГРАММА DAL_VJAZ КАК КОНЦЕПТУАЛЬНЫЙ МАКЕТ

Название вовсе не означает, что макет — это нечто застывшее.
По мере появления интересных мыслей и свободного времени мой макет будет
развиваться.

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

Предполагаемые языки программирования: пока D4.
На BCB3 есть предпоследний вариант и, если будет время, дотяну его до
текущей версии.
Но если не применять крутых наворотов С++ типа шаблонов, то
перетаскивание алгоритмов из D4 в BCB3 и обратно — вещь достаточно
тривиальная. Как, впрочем, и с переходами между BCB и Qt и т.п.

Основные вопросы и мои ответы на них:

1. Логика языка ДРАКОН, если брать не только написание графического
редактора, но и полноценную генерацию и считывание структурного
исходного кода, слишком сложна, чтобы быть реализованной небольшой
группой программистов средней квалификации (см. фразу Владимира
Даниеловича: «два института 10 лет ...».

Поэтому я считаю, что нужен упрощенный по сравнению с языком ДРАКОН
популярный визуальный язык. Я назвал его ДАЛВЯЗ.

2. Генерация и считывание исходного кода, основанные на полном
синтаксическом и семантическом анализе ЯПВУ, слишком сложны для
любительской программы, разрабатываемой в свободное от работы время.

Поэтому для генерации и считывания исходного кода в программе
DAL_VJAZ используются служебные комментарии, зависящие от ЯПВУ, с
которым в данный момент времени работает программа, и задаваемые в
файле конфигурации.

3. Основными строительными блоками программы являются действие
(присвоение или вызов процедуры), цикл и сложное условие. Это постулат
структурного программирования.

В ДАЛВЯЗ действие (присвоение или вызов процедуры или группа
каких-нибудь операторов языка программирования), обобщенный цикл и
сложное условие являются основными маршрутными операторами, полноценно
отображаемыми на визуальной схеме в виде блоков действий, связанных между
собой линиями логических переходов.

Дополнительные маршрутные операторы:
- выход из цикла по условию;
- продолжение цикла по условию;
- переход к обработке ошибки по условию;
- выход из процедуры по условию;
- переход goto по условию
отображаются в виде специальных значков внутри блоков действий.

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

4. Раз уж я определил программную реализацию силуэта как цикл (см.
dalvjaz.pdf), то следующим шагом стало введение понятия «цикл-силуэт».
Это позволяет:

1) преодолеть логическое раздвоение визуальных схем в языке ДРАКОН на
примитив и силуэт;

2) создавать при желании логику процедуры, включающую в себя несколько
циклов-силуэтов, в том числе и вложенные циклы-силуэты.

5. Документирование.
Для документирования программы предполагается использовать логику
документирования, предлагаемую языком ДАЛВЯЗ:
- служебные комментарии;
- пиктограммы действий;
- сокращения.
Это не исключает использования простых (неформатированный текст +
графика) htm-файлов описания программы и т.п.

6. Взаимодействие.
Если найдутся желающие внести свой вклад в развитие программы, то
предполагается следующий порядок:
1) для замечаний общего характера пишите в тему «обсуждение программы
DAL_VJAZ» (если такой темы еще нет, то создайте ее);
2) Если появится желание написать свой вариант изменений в код программы,
заводите свою тему и выкладывайте результат там, или в теме «обсуждение
программы DAL_VJAZ» (если такой темы еще нет, то создайте ее).
Требования к документации кода см. в п. 5.

7. Цели.
У Владимира Даниеловича цель — программирование без программистов.

Я как программист с этим решительно не согласен.

У меня цель другая: путем развития программы DAL_VJAZ получить
инструмент для:
- написания более надежных программ;
- усиления контроля программиста над своей программой;
- повышения качества документирования программы.

8. Планы.
Кроме того, что перечислено в файле dalvjaz.txt желательно было бы
сделать графическое редактирование визуальной схемы, а не только ее ввод
из окна логической структуры процедуры (ЛСП).

Я это вижу так:

Для действий, EI, EB — безусловный ввод (при ошибке вставка будет сразу
отклонена).
Для пар IF/E, CB/CE — условный ввод, а затем подтверждение ввода, что-то
вроде нажатия F10 из окна ЛСВ.
Удаление группы действий — тоже условное: помечаем все удаляемые (или
копируемые в буфер) действия, а затем F10. Аналогично и для вставки
ранее помещенной в буфер группы действий.


СВОБОДНОЕ ВРЕМЯ:
До Нового Года свободного времени нет, а дальше будет видно ...

"Цикл-силуэт" - это как-то связано с циклом Дейкстры в роли силуэта? В базовой форме - типа показанного на схеме отсюда? Или ограниченная, выводимая из автоматной модели ("зацикливание кейса"), как в /Поликарпова, Шалыто, 2010, Разд. 2?

Ну, в общем-то и правда человек, добросовестно самообразовавшийся в программировании, может уже считаться программистом... так что противопоставление вроде как отпадает...
Насчёт остального - качественное документирование у Вас предполагается как средство для цели улучшения взаимодействия "предметник-аналитик-программист" (в т.ч. и при совмещений кем-то каких-то ролей)?

Понятие цикл-силуэт подразумевает, прежде всего, один из возможных
вариантов программной реализации силуэта.
Кроме того, я посчитал, что не имеет смыла эту реализацию прятать,
как это я сначала сделал, см. dalvjaz.pdf
Ну и в результате см. рис 2 и 3 в моем сообщении от 13 ноября.

А документация - она пригодится и предметнику, и самому программисту
через полгода после написания программы, и другим программистам, если
в проект вовлечена группа программистов.

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

Да, вот ещё что. ЛСП-представление - в общем-то табличное представление [нелинейной ]маршрутной структуры. И оно неким образом, IMHO, реализует идею Ильи о клавиатурном вводе схем этим навеяно и такое требование. У Вас выбрана некая схема организации таблицы вида "графа-ряд цепочек вершин" с выносом ветвлений с главной оси на общую "побочную"... вроде так...

Возможно, следует перейти к принципу "графа ЛСП-таблицы - ось порядка[ маршрутов]" (в терминах отсюда)?..
Тогда при простейшей организации таблицы на ЛСП-строке будут коды вершин, одинаково удалённые от заголовка схемы (в "рёберной" метрике); в зависимости от числа вершин на разных маршах часть ячеек будут пустыми (допустим, мы "сгоняем" все вершины вверх, тогда пустые будут после них).

Или как-нибудь так : Тока представление областей видимости (как в левом нижнем окне интерфейса) я бы заменил опять же графами - типа как тут: http://grafit-basis.narod.ru/L3/part_vi ... Pril3-n121.
А граф программы тут, между прочим, по сложности языка что-то среднее между техноязыком и ВЯЗБС... кстати, и графит-изломы и "точки ввода" на схеме есть... как у Геннадия Николаевича... и упорядочение вертикалей "побочные-вправо" просматривается...

Кстати, система-то Паскалевская начала 1980-х (или конца 1970-х)... снова подтверждается, что не только формальность, но и эргономичность "Виртовского корня"...

Здравствуйте, народ.
Не писал с прошлого года, поэтому поздравляю всех с наступившей весной.

8 марта у меня нарисовался вот такой рисунок



который повиг меня быстренько внести в мою программку большую часть
заявленных в ноябре прошлого года планируемых изменений (см. файл
dalvjaz2.txt). Добавлено почти все по файлу конфигурации (только
по-прежнему осталась работа только с одним файлом сокращений) плюс еще
кое-что.

d4dal207.rar - скачиваний 55, новую версию см. ниже в этой теме в сообщении от 4.12.2012



Рабочая панель программы при этом почти не изменилась.



Элементы рабочей панели слева направо:
1) кнопка возврата после перехода по ссылке на другую запись
2) "ЧФ" - чтение файла
3) "ЗФ" - запись файла
4) "Н" - нормализация индексов элементов схемы
5) "Р" - редактирование текстовой записи
6) группа кнопок навигации по записям модуля
7) список - выбор записи модуля из списка
8 ) "схема" - флажок просмотра программных записей как визуальных схем
(сейчас при запуске программы флажок сброшен, так что первая запись
первого модуля появляется в окне в текстовом режиме)
9) толщина линий - 1 или 2
10) цвет линий - черный или зеленый
11) "BMP" кнопка создания bmp-файла shema.bmp и файла текстового
описания схемы shema.txt
12) закладки выбора модуля - щелчком по закладке модуля (можно
загрузить в программу до 10 модулей, а всего в программе задать до 99
модулей и загружать любые из них, меняя для модуля режим загрузки:
"КОД" - кодогенерация (тут все как было: для сохранения новой версии
файла нужно нажать кнопку "ЗФ" или подтвердить сохранение при выходе из
программы);
"---" - модуль не загружается;
"ДОК" - документирование: т.к. я не могу поручиться, что моя программа
полностью отлажена, то я и ввел этот режим с целью заботы о сохранности
файлов исходного кода.
Окна редактирования текстовой записи и элемента схемы открываются как
"ДОК" только для чтения, можно менять лишь значок пиктограммы и
сокращение для элемента схемы. После их изменения и нажатия "F2"
программа:
1) сохраняет файл исходного кода с расширением ".__b" и открывает для
записи новую версию файла исходного кода.
2) переписывает все строки ".__b" в новую версию файла, а когда доходит
до строки, с которой начинается отредактированный элемент записи
(кстати, при наведении мыши на элемент схемы в режиме "ДОК" во
всплывающем окне в скобках отображается номер строки файла исходного
кода, с которой начинается этот элемент), дописывает в конец этой
строки новый определитель рисунка и сокращения, после чего все
остальные строки переписываются из ".__b" в новую версию файла без
изменений.
3) закрывает новую версию файла.
Тупо, зато надежно.
После этого при переходе к окну среды программирования там появится
вопрос: "Файл ХХХ изменился. Загрузить новую версию?".
Программа по таймеру постоянно проверяет времена создания файлов
исходного кода и файла сокращений и при их изменении автоматически
считывает новые версии этих файлов, получаемые при нажатии на кнопку
"сохранить файл" в среде программирования или в текстовом редакторе.
При считывании новой версии файла исходного кода он сохраняется с
расширением ".__r". Перед считыванием новых версий для модулей в режиме
"КОД" их текущие версии сохраняются в "__каталог_чт" (см. dalvjaz.cfg).
Кроме того, при каждом запуске программы все считываемые программой
модули сохраняются с расширением ".__o".
Модуль делится на записи, а схема на элементы при помощи служебных
комментариев программы dalvjaz2, которые легко могут быть введены прямо
в среде программирования (подробнее см. dalvjaz.cfg). А если все модули
были загружены как "ДОК" и не планируется вводить для элементов схемы
пиктограммы и сокращения, то dalvjaz2 будет работать в режиме вьюера.


СИЛУЭТНОЕ ПРОГРАММИРОВАНИЕ В ДАЛВЯЗ 2

Следствием вышеуказанных изменений явилось то, что теперь можно
использовать программу dalvjaz2 как программу для разработки и
документирования ее же самой.
Каталог для работы с dalvjaz2: ...\dalvjaz2\work - нужно только
скопировать туда dalvjaz2.exe и исправить пути для каталогов в
...\dalvjaz2\work\dalvjaz.cfg.
Загружаются 5 модулей:
u_dalvj.pas ДОК
u_files.pas ДОК
u_ls.pas ДОК
u_red.pas ДОК
u_test.txt КОД
Я решил превратить процедуру создания визуальной схемы
procedure Tform_ls.b_sozdatx_shemuClick(Sender: TObject) (я раньше уже
разбирал логику работы этой процедуры и приводил скриншоты ее
визуальной схемы в старом варианте) в цикл-силуэт и воссоздал ее заново
в модуле u_test.txt, вводя элементы схемы с клавиатуры из окна ЛСП,
фрагменты исходного кода вставлял из старой версии процедуры, а также
присваивал элементам схемы сокращения и пиктограммы (если требуется
текст комментария, состоящий больше, чем из одной строки, можно
вставить ссылку на запись модуля, содержащую текстовый комментарий,
или на htm-файл, в котором можно и рисунком непонятные моменты
пояснить). После запоминания созданной процедуры по "ЗФ" я скопировал
сгенерированный текст процедуры в файл u_ls.pas, а старый вариант
процедуры сохранил для сравнения в файле u_test.txt.



В новой версии я изменил стиль вывода схемы.
Линии теперь по умолчанию двойной толщины и зеленого цвета.
Значки теперь выглядят вот так:



После вставки нового варианта процедуры в программу (вроде работает) я
вывел схему этой процедуры на экран и нажал кнопку "BMP", после чего
программа сгенерировала bmp-файл визуальной схемы процедуры и txt-файл
описания элементов процедуры по их пиктограммам и сокращениям.



2: начало цикла-силуэта
3: ветка начальной инициализации
4: загрузить ЛСП для возможного сообщения об ошибке
5: запоминаем 1-ю выделенную строку списка ЛСП
6: устанавливаем параметры главной вертикали схемы
7: инициализация массива открытых вертикалей схемы
8: начальная инициализация переменных
9: удаляем вертикали для схемы
10: переход к обработке ошибки при ошибке
12: сброс стека ЛСП
13: инициализация цикла сканирования ЛСП
15: начало цикла сканирования ЛСП
16: задание текущей строки ЛСП
17: запомнить блочный элемент схемы
18: получить текущий элемент схемы из ЛСП
19: получить вершину стека ЛСП
20: проверка ошибок ЛСП
21: переход к обработке ошибки при ошибке
24: окончание цикла сканирования ЛСП
25: начало IF/EI/цикла
26: оператор IF, обработка для IF
27: оператор EI, обработка для EI
28: начало цикла, обработка для начала цикла
29: переход к обработке ошибки при ошибке
30: заносим текущий элемент в стек ЛСП
31: оператор EB, начало альтернативного блока условия
32: оператор EB, начало альтернативного блока условия
33: переход к обработке ошибки при ошибке
34: оператор E, конец блока условия, обработка для E
35: оператор E, конец блока условия, обработка для E
36: переход к обработке ошибки при ошибке
37: цикл ПОВТОРЯТЬ ДО ...
38: переход к обработке ошибки при ошибке
39: конец цикла
40: переход к обработке ошибки при ошибке
41: конец цикла, обработка для конца цикла
42: конец цикла, обработка для конца цикла
43: переход к обработке ошибки при ошибке
44: переход к обработке ошибки при ошибке
45: извлечь элемент из стека ЛСП
46: обработка для действия
47: переход к обработке ошибки при ошибке
48: переход к следующему шагу цикла сканирования ЛСП
51: заключительные действия
52: получить вершину стека ЛСП
53: переход к обработке ошибки при ошибке
54: обработка после сканирования ЛСП
55: ошибок при создании схемы не было
56: схема считана
57: пересчет координат схемы
58: вывод на экран
59: загрузка ЛСП
60: восстановить выделенную линию списка ЛСП
61: сохранить схему в массиве памяти модуля схемы
63: обработка ошибок и выход
64: обработка ошибки
66: конец цикла-силуэта

Вот такой опыт силуэтного программирования.

Недавно прочитал заметку Геннадия Николаевича, что профессор Шалыто не
понимает, зачем нужно было придумывать силуэтное программирование, т.к.
все это слишком сложно и громоздко.
За Владимира Даниеловича я отвечать не буду, а от себя, для случая
ДАЛВЯЗ 2, могу ответить:
1) цикл-силуэт компактифицирует визуальную схему алгоритма, позволяя
размещать достаточно сложный алгоритм на одном экране (можно сравнить
нынешний и предыдущий варианты визуализации b_sozdatx_shemuClick);
2) в ДАЛВЯЗ 2 для создания на основе процедуры визуальной схемы даже
в текстовом редакторе требуются не такие уж и большие усилия - нужно
только скопировать требуемое число раз основной служебный комментарий
задания элемента визуальной схемы (*i*) (или /*i*/ для семейства
C/C++), а затем в некоторых местах его подкорректировать - для циклов,
выхода и окончания процедуры;
3) сложное условие в ДАЛВЯЗ 2 выполняет те же функции, что и switch-
переключатель, но при этом предоставляет более богатые возможности
выбора, так что в этом смысле силуэтное программирование в ДАЛВЯЗ 2
можно рассматривать как расширенный вариант switch-программирования.

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

Важное достижение...
Ну, от себя я решил там и ответить... не знаю, будут ли читать... Подразумевая дейкстрал, что в общем похоже на ЦС.
Обычно это следствие того, что на схеме многое не фиксируется как содержание вершин/рёбер. В этом примере то же. Можно многое ввести в схему - как обычно и делаю; описал на примере здесь (при разборе разветвителей).

Конечно, с автоматным программированием не все так просто ...
Владимир Даниелович пишет популярные книги для начинающих,
а учебники по switch-технологии ориентированы на студентов
IT-факультетов ВУЗов.
К тому же


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

Да и у моей программы, хотя она изначально задумана как инструмент для
программистов, "порог вхождения", как отмечал Владислав Жаринов,
является низким.
Ну не любят программисты рисовать блок-схемы и всяческие другие схемы.
Поэтому я попытался:
1) как можно более упростить процесс создания визуальной схемы и сделать
его как можно более привычным для программистов - ввод с клавиатуры;
2) дать возможность программистам создавать визуальные схемы из уже
существующих процедур;
3) загружать в мою программу уже существующие проекты из нескольких
модулей на языках семейств Pascal и С/С++.
Для этого один или несколько модулей проекта разбиваются на текстовые
записи заголовками вида:
(* t. имя записи *) - для семейства Pascal
/* t. имя записи */ - для семейства C/C++
после чего модуль может быть считан моей программой. А как превратить
текстовую запись в программную - я описал в своем сообщении в ноябре
прошлого года.

Ну и зачем все эти мучения ?

Основная мысль Владимира Даниеловича:

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

Это тоже путь к повышению надежности программы.
Другой, чем в автоматном программировании, но тоже проверенный временем
и подтвержденный практикой.

И тут еще один интересный момент:
Цикл-силуэт в моей программе является визуальным аналогом автомата, даже
ветки пронумерованы (хотя к ним можно добавлять и текстовые комментарии).
Поэтому представляет интерес вопрос синтеза автоматного и силуэтного
программирования (в том виде, как оно реализовано в ДАЛВЯЗ 2). Может, если
будет свободное время, подумаю над этим вопросом.
Правда в ближайшее время свободного времени пока не предвидится ...

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

Кстати, о цикле-силуэте. Из упомянутых описаний нетрудно увидеть его структуру. Тот же дейкстрал для языков без ЦД - только в качестве объемлющего цикла вместо LOOP взят REPEAT-UNTIL 'true'.

Не, ну вы, блин, даете!

По поводу "весовых категорий".

В. Д. Паронджанов - давний сотрудник НПЦ АП имени академика Пилюгина.
Знаете, чем занимается НПЦ АП?
Системами управления для ракетно-космической техники.

Технология ГРАФИТ/ФЛОКС создана изначально именно для этих - крайне ответственных - применений -
с целью достижения необходимых уровней надежности и качества ПО. Непосредственно -
при создании системы управления "Бурана".

Успешно использовалась в проектах "Морской Старт", РБ "Фрегат", и других.

Все это - широко известные вещи, и на данном форуме перемывались неоднократно.
Стыдно, молодой человек.

TAU пишет:


Я подозреваю, Андрей, что по возрасту я постарше Вас буду.

А если Вы невнимательно прочитали (хотя сами же и процитировали),
то повторяю:

Так что весовые категории у силуэтного (В ЕГО НЕСЕКРЕТНОМ ВАРИАНТЕ) и
автоматного программирования пока что разные.

Кто знает, что к нынешнему моменту ВПК понапридумывал:
может, у них уже и летающие тарелки, и терминаторы, и связь с параллельными
мирами, и много чего еще ...

Я к этим секретам не допущен, ну и слава Богу ! - спокойнее спать буду.
Мы обсуждаем технологии программирования на основе открытых источников.

Кстати, уже достаточно давно Илья Ермаков подчеркивал, что силуэт - это
визуальное отображение автомата.
А автомат, и автоматное программирование, построенне на его основе - это,
можно сказать, доработанная машина Тьюринга, которая и была первой ЭВМ.
Так что ничего обидного в своих словах для Владимира Даниеловича я не вижу.

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

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

Вряд ли. Хотя всякое может быть.


Нет никаких существенно отличающихся "несекретного" и "секретного" вариантов.
Придуманы были силуэты именно для космических БВК.

Кстати, главная идея Паронджанова - эргономизация блок-схем алгоритмов.
Или вторая ) А главная - внедрение основ алгоритмизации в другие сферы жизни, не связанные с программированием.

"Автоматное программирование" - пример, как можно раздуть и вытягивать деньги из бюджета
под известные давно вещи.