Содержание
Основы визуального программирования
Под визуальным программированием понимаем получение текста в системе команд предполагаемого исполнителя (целевой) на основании комплекта исходных чертежей - совокупности граф-схем, в т.ч. на различных языках, описывающей некий процесс в терминах формального исполнителя. При этом структурная часть процесса описывается строением граф-схем, а часть, касающаяся содержания элементов структуры - значениями атрибутов элементов граф-схем.
Возможны два уровня решения задачи:
непосредственное отображение в коды команд из дракон-системы;
получение промежуточного исходного текста, который кодируется внешней программой-транслятором.
Во втором случае мы можем принять различные языки исходного текста. Здесь также возможны два уровня:
язык высокого уровня;
язык Ассемблера для целевой системы команд.
Во втором случае каждому визуальному оператору соответствует одна команда исполнителя. В первом случае каждый визуальный оператор в итоге м.б. отображён более чем одной командой; правило отображения для каждого ЯВУ реализовано в трансляторе с этого языка.
В качестве формального языка текста граф-схем процессов (исходных чертежей программ) д.б. принят по крайней мере один промышленный прогязык реального времени, обладающий максимально высоким научно-техническим уровнем и имеющий реализацию в виде компилятора исходных текстов с этого языка.
В соответствии с мнением отечественных ИТ-специалистов, представленных на веб-конференции OberonCore.Ru, исходным м.б. выбран прогязык Активный Оберон.
Фактически к представлению модели как исходных чертежей добавляется представление её как исходного текста. Понятно, что между языком исходного текста и семейством языков исходных чертежей д.б. определено взаимно-однозначное соответствие.
Следует также обеспечить единство источника — из нескольких представлений только одно рассматривается как содержание модели, а все остальные получаются «переводом» на язык нужного представления в среде поддержки. И это можно реализовать по-разному, выбрав за базовый:
язык исходного текста;
языки описания визуальных моделей.
Точнее говорить о метаязыке, имея в виду классификацию отчуждённого знания на общее и частное и далее частных знаний — по видам.
Конечно, в любом случае машинный документ, содержащий полиязыковую модель, должен содержать при каждой схеме указание на тип её языка (напр. в виде префикса заголовка). Оно используется средой сочинения для выбора языкового модуля работы с этой схемой.
Имеет смысл выбрать базовым текстовое представление; тогда визуальные модели получаются трансляцией текста. Однако метаязык этого текста будет, очевидно, шире прогязыка дракон-программы; в него будет входить и язык[и] обобщённой формализации задачи, и язык схематизации содержания документа. Поэтому нужна техоперация трансляции с метаязыка на язык исходного текста; в результате её должен получаться отдельный документ в формате внешнего транслятора с этого языка.
Среди уровней прогязыков логично принять за базовый язык высокого уровня. Тогда низкоуровневое представление (на Ассемблере или в кодах) получается также трансляцией (в отдельный документ в формате использования — напр. программатора, загрузчика кода).
Понятно, что режимы трансляции и набор поддерживаемых языков зависят от конкретной реализации ИСП с функциями визуального программирования (которую мы называем РДП-системой).
Т.о. реализуется двусторонняя трансляция формальных моделей чертежи↔текст. И это можно реализовать разными способами:
оперативным — немедленно по редактировании одного представления обновляется другое;
отложенным — обновление выполняется в определённых случаях, напр. при сохранении документа и/или по команде сочинителя.
В первом случае специальной команды обновления, конечно, не требуется.
В принципе это то же, что режимы on-line и off-line взаимодействия систем или интерактивный и пакетный режимы доступа (исполнения заданий оператора).
Что это даёт для техпроцесса сочинения? Во-первых, сочинитель не связан каким-то одним представлением — может работать как с графикой, так и с текстом. Технология формализации получается естественной - правка схем отражается (автоматически) на тексте и наоборот. При поддержке нескольких языков по одним и тем же чертежам можно получить текст на каждом из них (удобно также транслировать разные дракон-программы на разные языки).
Имея возможность иерархической детализации согласно п/п 2.1.3.12, мы можем реализовать «сборочную визуализацию» и алгоритмических, и иных моделей. Для этого нужно только организовать и вести каталоги фрагментов моделей, оформленных как автономные сущности; логично считать их областями, не связанными ни с какой схемой.
В каталоге мы можем поставить каталогизированной области на некотором языке в соответствие икону на более высокоуровневом языке (напр. области-схеме на дракон-ассемблере - оператор ДО-2).
Исходя из того, что согласно п/п Смысл и текст икон п. 2.1.2 определён шаблон синтаксиса текста на любом языке), мы можем абстрагировать имена объектов в тексте и иконы, и детализирующей её области. Вместо имён в текстах появляются поля объектов — переменные-"иксы", формируемые условно; вхождению одного и того же имени в исходной схеме соответствует вхождение соответствующего условного имени по каталогу. При использовании в конкретной схеме сочинитель должен указать имя из числа употребляемых в этой схеме для каждого поля для обратной конкретизации.
При этих условиях можно, выбрав язык для детализации и подгрузив нужные каталоги, при выборе очередной иконы детализируемой схемы замещать её ранее построенной структурой, а не строить детализацию каждый раз заново. Понятно, насколько это удобнее сочинителю.
Естественно, соответствие устанавливается в абстрагированной форме — сначала текст детализируемой иконы приводится к шаблону, а затем проверяется совпадение (по местам вхождений и типам) с иконой из каталога (текст котрой также абстрагирован по определению).
Возможно, что одной иконе в каталоге соответствует более одной области; тогда сочинитель должен выбрать нужную.
Если используется нешампур-область, то можно допустить и «подгонку по месту» связей выбранной структуры путём операций с лианой.
Естественно, каталоги можно вести при любом варианте ТФЗ — хоть вручную — но наибольший эффект даст каталогизация областей в РДП-системе (среде). При этом автоматизируется и проверка соответствия, для чего РДП-редактором используется шаблон синтаксиса; сочинителю же нужно по большей части просто отвечать на вопрос о "визуальном автозаполнении" области очередной иконы из подходящей по определению области каталога.
Лист-каталог, по-видимому, д.б. одноязыковым; он сохраняется и открывается отдельно. Сочинитель может создавать столько каталогов, сколько ему нужно.
Визуальное ассемблирование по «областной» технологии можно провести следующим образом. Каждый оператор дракон-программы детализируется областью, причём:
конструкции записываются в лиоформе, как определено в п. 2.2.2 для ветвлений и в п. 2.2.3 для циклов; началом главной вертикали служит икона Заголовок, любой другой вертикали – икона Имя ветки;
икона Развилка представляется как команда ветвления (см. п. 2.2.2);
в иконе Имя ветки записывается метка (адрес памяти программ, с которого начинается озаглавленная ею вертикаль), в любой другой иконе – полный текст одной команды (в т.ч. в развилке – команды условного перехода УП, Адрес ветки – команды БП).
икона Конец трактуется как команда останова машины, а при использовании в конце вставки – как команда возврата из подпрограммы;
любая шампур-икона визуализируется как шампур-блок в минимальном базисе (веточные иконы представляют безусловные переходы, икона Вставка – команду вызова подпрограммы, икона Действие – любые другие команды); здесь сочинитель определяет выкладку вертикалей в памяти информашины, вводя БП по своему усмотрению.
Т.о. иконы рассматриваются как «контейнеры» для команд ассемблера.
Можно расширить базис, использовав для некоторых машинных команд подходящие по смыслу иконы. Прежде всего это касается ввода и вывода; также можно использовать икону Полка для визуализации команд пересылки (синтаксис очевиден, если иметь в виду смысл полки как присваивания).
Такую схему можно оттранслировать в текст на ассемблере по относительно простым правилам (которые д.б. определены в редакторе схем). Очевидно, что редактор должен контролировать, чтобы адреса БП указывали на существующие метки, а на каждую метку приходился хотя бы один БП (указывая сочинителю на нарушения). Также удобно снабжать каждую икону её начальным адресом (вычисляемым относительно головной иконы вертикали). Ну и разумеется следует автоматически контролировать правильность написания команд (как для любого поддерживаемого языка «костюма»); возможно, стоит предлагать автозаполнение.
В принципе для данного метода визуализации достаточно, чтобы редактор просто допускал рисование схемы-лиоформы (т.е. вставку икон БП в любых местах визуала) и мог формировать исходный текст из всех текстов икон схемы, «разбирая» их по вертикалям (точнее – по цепочкам между меткой и командой БП); этот текст можно будет передать в транслятор с Ассемблера. Правда, ручной контроль адресов БП достаточно сложен, но облегчается эргономичным представлением структуры маршрутов в виде дракон-схемы.
Можно ввести поддержку ассемблера в редактор; тогда нешампур-иконам, как обычно при гибридном программировании, сопоставляются маршрутные части команд. Однако в случае языка такого рода это не совсем удобно из-за иного, чем в ЯВУ, способа построения операторов; напр. мнемотекст (а равно и машинный код операции) команды УП фактически должен складываться из общей части, представленной как икона, и спецчасти, представленной знаком условия УП в тексте этой иконы – нагляднее будет записать команду полностью в тексте иконы.
В начало страницы | Оглавление | Главная | Версия для печати
Copyright © Жаринов В.Н.