OberonCore

Алгоритмический язык ДАЛВЯЗ 2. Силуэтное программирование





Введение

Наконец-то в 2016, без малого через четыре года после того, как я
выложил на форуме http://forum.oberoncore.ru описание алгоритмического
языка ДАЛВЯЗ 2 (файл dalvjaz2_description.pdf), я смог сформулировать,
какой смысл применительно к языку ДАЛВЯЗ 2 имеет термин "силуэтное
программирование".

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

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

Почему неудобно и как удобно ?
Рассуждения на эту тему и составляют основное содержание этого материала,
в котором я объединил в одно целое уже имевшиеся у меня разные варианты
описания языка ДАЛВЯЗ 2, задуманного мной как сильно упрощенное и удобное
для практического программирования на языках семейств Pascal и С/С++
подобие алгоритмического языка ДРАКОН.


Содержание

ЧАСТЬ 1. ТЕОРИЯ
1.1. Почему неудобны стандартные блок-схемы
1.2. Что такое силуэт
1.3. Алгоритмический язык ДАЛВЯЗ 2
1.4. Формирование в ДАЛВЯЗ 2 блок-схемы на основе исходного
кода процедуры
1.5. Программирование на ДАЛВЯЗ 2 с циклом сложного условия
1.6. Конкретный пример схемы
1.7. Панель инструментов для работы со схемой
1.8. Редактирование схемы в ДАЛВЯЗ 2
1.9. Работа с русифицированной программной логикой верхнего
уровня в ДАЛВЯЗ 2

ЧАСТЬ 2. ПРАКТИКА
2.1. Файл конфигурации программы dal2.cfg
2.2. Файл стилей отображения схемы styles.cfg
2.3. Возможные варианты служебных комментариев
2.4. Шаблоны редактирования процедуры
2.5. Редактирование структурных блок-схем произвольного вида
2.6. Использование пиктограмм и рисунков при создании схем
2.7. Всплывающие окна для элементов схемы
2.8. Создание схемы для псевдокода
2.9. Описание логики программы на над-процедурном уровне
2.10. Создание текущей версии процедуры вывод_схемы, начало
2.11. Создание схемы с точки зрения программиста
2.12. Создание текущей версии процедуры вывод_схемы, окончание
Заключение
ЛИТЕРАТУРА И ССЫЛКИ В СЕТИ ИНТЕРНЕТ



<readme.txt>

Программа dal_vjaz_2, v.0.87.4


Очередная версия программы dal_vjaz_2 v.0.87.4 является приложением
к выкладываемому вместе с ней материалу "Алгоритмический язык ДАЛВЯЗ 2.
Силуэтное программирование", в котором приведено достаточно подробное
описание работы с этой программой. Но некоторые вопросы остались за
рамками вышеуказанного материала, а потому поясняются ниже.

Программа dal_vjaz_2 0.87.4 является свободно распространяемым ПО c
открытым кодом и выкладывается "как есть", с возможностью дальнейшего
развития и совершенствования всеми желающими.

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


файлы конфигурации: dal2.cfg, styles.cfg
файл, задающий размеры основной формы: formsize.dat
пробные файлы: proc2.txt, proc3.txt, proc_bb.txt


Описание подключения dll, сгенерированной в среде КП, приведено
в теме "КП + Delphi".
Описание концепции логики верхнего уровня, использованной для
разработки dll в среде КП, приведено в теме "программная логика
верхнего уровня".
Что касается проекта pasdll (информация для тех, кто захочет вносить
изменения в проект dal2874), то его надо перетранслировать каждый раз
после внесения изменений в определения форм проекта dal2874.

Для считывания текста процедуры со служебными комментариями нужно нажать
кнопку "Счит.", после чего откроется форма с окном ввода текста
процедуры, в которое по Shift + Ins нужно вставить этот текст, после
чего нажать кнопку "Сохранить".

Если при чтении служебных комментариев возникнут ошибки, то на экране
вместо схемы процедуры появится сообщение об ошибке и текст процедуры с
предполагаемым местом ошибки, обозначенным строкой "?>".
Нужно учитывать, что строкой "?>" часто обозначается не само место
ошибки, а место, где программа столкнулась с проблемой при считывании
служебных комментариев процедуры. Например, при возникновении сообщения
"нет ЕСЛИ для КОНЕЦ" с пометкой в тексте процедуры "?> КОНЕЦ" только
сам программист сможет разобраться, забыл ли он про ЕСЛИ, или добавил
лишний КОНЕЦ. ну и так далее.
После исправления ошибки в тексте процедуры нужно считать этот текст
снова.

Для сохранения текста отредактированной процедуры нужно нажать кнопку
"Сохр.", после чего текст отредактированной процедуры будет скопирован в
клипборд Windows, откуда этот текст по Shift + Ins можно вставить в
любой текстовый файл.
Кроме того, текст отредактированной процедуры записывается в файл
proc.txt в рабочем каталоге программы, а предыдущая версия файла
proc.txt сохраняется под именем proc.__o .

Для сохранения схемы в jpg-файле нужно нажать кнопку "JPG", после чего
схема будет сохранена в подкаталоге \rk рабочего каталога программы с
именем shema.jpg.
Если схема очень большая (больше схемы "Морозко"), то на экране может
появиться сообщение "недостаточно памяти для выполнения операции".

При работе с минимизированной схемой, когда идет массированная вставка
новых элементов, то мышь снует туда-сюда между панелью редактирования
схемы и самой схемой. В этом случае механизм подавления всплывающих окон
путем нажатия и удержания клавиши Shift является неудобным. Тогда для
отключения всплывающих окон следует сбросить флажок "вспл. окна".

Если кажется, что для минимизированной схемы перетаскивание мышью с
нажатой правой кнопкой слишком медленное, то нужно уменьшить параметр
"диапазон прокрутки", например до 150.

</readme.txt>

А в заключение 2 примера

Фрагмент схемы процедуры "вывод_схемы" для русифицированного КП:


Пример для КП
Из текста процедуры

получаем следующую схему:

Получается, что ДРАКОН скрывает (инкапсулирует) реализацию веточного цикла в схеме "силуэт", а ДАЛВЯЗ 2 всё это демострирует программисту, загромождая схему...
В чём тогда преимущества для программиста?
Мною в 2008 году (8 лет назад) был предоставлен транслятор ДРАКОН-схем в исходный код на языке Активный Оберон. http://sage.com.ua/ru.shtml?e6l0 Транслятор автоматически генерировал в том числе и код веточного цикла. Эта операция и должна делаться автоматически!
Всё что делается автоматически облегчает труд программиста и исключает ошибки человека (человеческий фактор), предоставляя программисту лишь приятное занятие по наполнению основной алгоритмической части схемы.
Сгенерированный код веточного цикла:

Здравствуйте, Ярослав.

Главное отличие ДАЛВЯЗ 2 от языка ДРАКОН состоит именно в том, что ДРАКОН - это
инструмент для людей, которые профессионально программированием не занимались, а
ДАЛВЯЗ 2 задумывался как инструмент для программистов. А у программиста должен быть
полный контроль над исходным кодом своей программы.
Если рассматривать вопрос функционирования силуэта, то цикл сложного условия, заставляющий
его работать в качестве силуэта, в процедуре всего один, а к тому же в ДАЛВЯЗ 2 этого цикла
может и не быть вовсе - тогда процедура будет состоять только из сложного условия, как во втором
примере моего предыдущего поста.

Возможно при чтении от Вас ускользнул один момент:

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

Можете ли Вы или разработчики других редакторов для языка ДРАКОН уверенно
заявить: "Да, с точки зрения эргономики мой редактор конечно дает программисту
гораздо лучшие условия ввода текста процедуры, чем обычный текстовый редактор" ?

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

Ради интереса почитал Ваши pdf-файлы, обратил внимание на Ваш пример с процедурой. Возникли вопросы:
1) Сама процедура-пример очень длинная, более 200 строк. При этом там в ветках условных операторов явно какая-то сложная логика.
2) В процедуре есть какие-то "волшебные числа" типа 10, 20 и т.п.
Если разбить её на осмысленные процедуры поменьше на 20-60 строк, дать им осмысленные имена, дать названия константам, то насколько будет велик выигрыш визуальных схем? Или есть какие-то непреодолимые причины, не позволяющие разбить процедуру (связанные, например, с оптимизацией и т.п.)?

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

Ответ участнику форума ScrollLock:

Тут важно понимать контекст.
Редактор ДАЛВЯЗ 2 и мои более ранние проекты, выложенные в разделе
«Визуальное программирование», создавались, когда энтузиасты языка «Дракон»
еще не удалились с форума oberoncore.ru на свой теперешний сайт.
Они активно использовали, да и сейчас продолжают использовать ДРАКОН-
редактор Геннадия Тышова.
Если говорить об эффективности визуального программирования в его
исполнении, то опыт показал, что для встраиваемых систем она присутствует.
Некоторые электронщики начали использовать ИС ДРАКОН Г. Тышова для
программирования микроконтроллеров и выразили ему благодарность за то, что
эффективность их труда после этого повысилась.
Логика визуального программирования, предложенная В. Паронджановым и
реализованная Г. Тышовым, предполагает сначала ввод визуальной схемы, а затем
генерацию на ее основе исходного, а затем и исполняемого кода. Сначала
генерировался код только для языков с goto, поэтому он получался не слишком
удобочитаемым. В последних версиях ИС ДРАКОН Г. Тышов реализовал
возможность визуального автоматного программирования, а заодно и генерацию
кода для языков без goto, но подробно в эти возможности я не вникал.
В любом случае, насколько я понимаю, сгенерированный в ИС ДРАКОН
исходный код, отредактированный в обычном текстовом редакторе, как правило,
если после этого изменилась логическая структура программы, а не несколько букв
в отдельных операторах, не может быть просто так считан обратно в среду ИС
ДРАКОН (Это, пожалуй, главный недостаток ДРАКОНа – нельзя наследовать уже
разработанное традиционным способом ПО).
При этом простыня схемы может быть достаточно большой, вплоть до
формата А1, а иногда этих простынь может быть и несколько, но для написанной на
языке С программы микроконтроллера этого обычно вполне достаточно.
Основная идея В. Паронджанова заключается в том, чтобы программист мог,
просматривая простыню схемы (в начале работ с языком ДРАКОН такие простыни
распечатывали на широкоформатном принтере, а сейчас просмотр на экране
монитора, аналогично просмотру больших чертежей в САПР КД типа AutoCAD),
охватить почти сразу всю логику программы (чего при дроблении исходников ПО на
малые процедуры сделать не получится), что дает ему возможность выявлять
ошибки логики программы путем визуального просмотра, что, пожалуй,
действительно легче, чем выявление ошибок путем инспекции исходного
текста ПО.
Кроме того, приближение программы по форме к чертежу должно, по мысли
В.Паронджанова, повышать дисциплину программирования и делать код
удобочитаемым для всех программистов, работающих над проектом, что повышает
возможности сопровождения ПО.
Язык ДРАКОН разрабатывался, насколько помню, в середине 1980-х, и тогда
подобные мысли В.Паронджанова, казалось, имели полное право на существование.
Но с тех пор объем исходного кода ПО начал лавинообразно расти и не
прекращает этого делать и сейчас. Поэтому ИС ДРАКОН Г. Тышова и занимает ту
нишу, которую она может охватить – программирование контроллеров
промавтоматизации.
Кроме того, была информация об использовании несколькими оборонными
предприятиями САПР ПО на основе языка ДРАКОН, но насколько она актуальна
сейчас, не знаю.

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

Результат всего этого я оцениваю скорее как неудачный, хотя при этом опыт
для меня был местами достаточно любопытный.
Я хотел получить визуальное программирование по-русски, и я его получил.

Та большая процедура, о которой Вы спрашивали – это процедура логики
верхнего уровня на русифицированном КП для вывода на экран визуальной схемы.
Волшебные цифры – это состояния автомата, т.к. ДАЛВЯЗ 2 фактически
реализует визуальное автоматное программирование, только не на операторах case,
а путем использования цикла сложного условия.

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

Выложенный в pdf-файлах материал можно конечно рассматривать как
рассуждения программистского деда, сожалеющего о прошлых временах.
Когда я после института пришел на свою первую работу, там были ЭВМ СМ-4
и промышленные контроллеры с системой команд PDP-11. Потом потихоньку стали
появляться PC XT и PC AT, а потом все закрутилось …
Современные среды программирования раскрашивают код ПО, показывают,
если поставить точку или стрелочку, весь список идентификаторов для текущего
контекста и делают многое другое.
Но кто знает, что будет через 10 лет ?
Сейчас Илон Маск показал обезъяну с вживленными электродами, которая
путем мысленного управления играет с компьютером в теннис.
А что будут творить через 10 лет программисты со шлемами мысленного
управления виртуальной реальностью [на головах] ? При позитивном развитии
событий, конечно, если не случится какой-нибудь мировой катастрофы.
В общем поживем – увидим.

Ну и остается задача создания полностью русифицированной
отечественной среды программирования с полностью русифицированным языком
программирования. Пусть это будет русифицированный КП – желаю сообществу
oberoncore удачи в этом нужном деле.

А какая будет область применения, учебная? Если речь о промышленном применении, то это вызывает скепсис: сейчас в ИТ незнание английского языка очень близко к профнепригодности, т.к. документация и API обычно приходят на английском языке. У меня родной язык - русский, но обнаружил, что читать код на русифицированном КП тяжелее, чем на английской версии. Английские ключевые слова воспринимаются примерно как знаки математических операций. И думаю, что если детей учить на русифицированных языках, им потом придётся переучиваться.

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


Не только это. Со старых времён произошли сильные изменения:
1) Системы автоматического генерирования документации по коду вроде Doxygen. Рисует даже иерархию классов. Но, увы, он - для C-подобных языков. Вы, кстати, их видели?
2) Массированное Goto остались разве что в Ассемблере и древних программах на Фортране-77 и GW-BASIC. И сейчас везде языки со структурными отступами, после которых уже не пытаешься развернуть конструкцию в GOTO (а блок-схема делает во многом это).