Перспективы | Вопросы развития
Содержание
Развивается ли стандарт языка?
Техноязык — единственное средство визуализации?
Да, конечно. С одной стороны, можно расширить сферу его приложения. Это вытекает из того, что метод в сущности определён для абстрактных граф-схем с особыми топологическими свойствами – будем называть этот тип маршрутным.
Маршрутная схема – граф, обладающий следующими свойствами:
а) этот граф ориентированный с циклами;
б) среди всех вершин этого графа имеется одна или несколько начальных, из которых только и могут начинаться любые маршруты на графе;
в) имеется также одна конечная вершина, к которой только и могут вести все маршруты на графе (включая циклические, если их развернуть, полагая число циклов конечным);
Интерпретацию смысла (как говорят, «надстройку») этой структуры задаёт текст икон. Так, для дракон-схемы надстройкой является некое вычисление – получение объектов-результатов из исходных объектов (те и другие указаны деклар-текстом вершин и в случае физического процесса м.б. вещественно-энергетическими, а в случае информатического – данными) посредством операций, заданных командным текстом икон.
Однако мы можем выбрать вершины из другого алфавита. Так, автор этих строк применил шампур-метод к синтаксическим диаграммам.
С другой стороны, сам метод задан как «жёсткое» исчисление, требующее точно определённого состояния после каждой операции и единственного пути её совершения. Это упрощает корректный вывод дракон-схем из заготовок, но усложняет сам процесс вывода.
Можно смягчить правила вывода, если ввести дополнительную разметку маршрутных схем, из которой можно извлекать условия допустимости тех или иных операций из многообразия возможных для текущей конфигурации схемы. Такую возможность ввёл И.А. Ермаков, о чём сообщил здесь.
И с третьей стороны, можно обогатить сам метод как исчисление. Очевидная цель – придать схемам свойство «выкладываемости» в лиоформу, о чём говорилось в этом пункте. Общая идея её достижения – употреблять безусловные переходы внутри шампура дракон-схем (в нелинейных конструкциях). Возможны два пути реализации этого:
ввести правила вставки БП как самостоятельных слов языка в схему;
ввести в словарь макроиконы нелинейностей с готовыми БП.
Первый путь оказывается более общим, обеспечивая выкладку фрагментами любых размеров; во втором случае можно выкладывать только целые вертикали.
На практике разумно сочетать оба пути. Подробнее лиоформирование дракон-схем рассмотрено в п/п 2.2.2.2 для ветвлений и п.п 2.2.3.1 для циклов; в п.п 2.2.1.1 описаны его элементы для линейных конструкций.
Словарь техноязыка расширен автором для этой цели макроиконами с буквенным индексом ЛД (лио-ДРАКОН), как показано в этом пункте.
В графике ЛД-макроикон безусловный переход показывается по-иному оформленной линией, чем естественный; тем самым подчёркивается произвольность расположения связанных БП подграфов.
Развивается ли стандарт языка?
И на этот вопрос ответ положительный. Едва ли не главная причина этому – необходимость более глубокой проработки реализации гибридного техноязыка (для полноценных исходных чертежей).
В настоящее время ДРАКОН-сообществом исследуется и маршрутный подъязык ДРАКОНа в связи с его реализацией в дракон-средах. Уже имеются некоторые вопросы, требующие проработки стандарта техноязыка (см. напр. отдельные темы форума Визуальный язык ДРАКОН конференции OberonCore), а именно:
о значении иконы Вставка;
о визуализации произвольных ветвлений;
об употреблении цикла ДЛЯ в гнёздах циклов;
о расширении маршрутных возможностей силуэта (произвольного);
о визуализации параллельных процессов (в т.ч. транзактных представлений деятельности).
Также исследуются вопросы декларативного описания, создания деклар-языка (семейства языков), совместимого с ДРАКОНом.
По поводу прагматичности техноязыков ДРАКОН-2 среди специалистов существуют разные мнения; можно обратиться в интернет (скажем, в тот же веб-форум). Так, высказываются претензии к иконам реального времени, что они не отражают полностью механизмы взаимодействия процессов, такие как семафоры. По мнению автора, одно дело – стандарт техноязыка, который должен давать «кирпичики» алгоритмов и правила их «кладки», и другое – что из этих «кирпичиков» можно построить; это задача технологии. Пожалуй, всё же не стоит требовать, чтобы такие вещи, как механизмы взаимодействия процессов, выражались одной иконой; другое дело, что множество икон д.б. инвариантом для представления любых алгоритмов, и этих в том числе.
Следовало бы предпринять усилия по определению инвариантности алфавита техноязыка, если результаты, предложенные его создателями, считаются недостаточными. На основе же актуального стандарта техноязыка можно и нужно определять типовые конструкции (как сейчас говорят, «паттерны») для неких функций, основываясь и на конкретном командном подъязыке.
В любом случае нужны повседневные усилия в теории и практике визуализации; это декларировано, напр. в рассылке «Усилители интеллекта».
Шампур-метод устанавливает не только эргономические, но и некоторые логические правила построения икон. В публикациях создателя техноязыка этот вопрос не освещается; в традиционных языках схем устанавливаются общие правила на случай расширения алфавита (прежде всего правила построения УГО по ЕСКД). При расширении алфавита техноязыка возникают некоторые вопросы.
Визуальный оператор (икона) в ряде случаев образован несколькими элементами-полями – замкнутыми контурами с текстовым заполнением. Логически этим представлен оператор сложного содержания.
Каков общий принцип организации полей? У Паронджанова мы видим, что это комбинация ненаправленного по форме поля (прямоугольника) и направленного. Тогда другой вопрос: визуализации чего служат эти комбинации? Соответствующие правила выявлены и установлены с определёнными коррективами в этом пункте.
Вообще-то этой теме вроде не место при изложении шампур-метода – ведь он относится к схемам, взятым без текста икон (см. /1, с. 272-273/). Однако там же указано, что реальный визуал получается интерпретацией шампур-схемы с привлечением некоторого языка текста. Можем ли мы указать общие требования к синтаксису этого языка?
Из классификации частных отчуждённых знаний в этом пункте следует, что в тексте существуют командные объекты (немаршрутная часть оператора) и декларативные – объекты приложения оператора. Независимо от языка текста иконы мы всегда можем выделить деклар-объекты – они представлены именами величин; остальная часть текста может трактоваться целиком как командная (своего рода «имя действия») и структурироваться в зависимости от стандарта командного подъязыка.
Соответственно определяется и раздельное форматирование этих видов имён (логично, чтобы его параметры настраивались сочинителем). Разные форматы употреблены в текстах икон дракон-азбуки; это символическое представление указанной структуры и его можно поддерживать как вручную (если реализация в ИСП никак не учитывает структуру), так и автоматически (если интерпретация структуры заложена в ИСП визуализации).
Говоря наглядно, для вышеприведённой записи в офисном редакторе имена объектов будут оформлены иначе потому, что сочинитель применил к выделенным фрагментам текста иные настройки стиля текста автофигуры, представляющей икону или её часть (поле). Если же мы пользуемся гипотетическим редактором визуалов, то сочинитель уже при вводе действия скомандовал включить в нужные места текста поля объектов, затем заполнил эти поля именами, а уж система применила к полям текущие настройки стиля. При этом текст и в предметной форме структурирован на имя действия и имена объектов этого действия.
А можно ли применить этот подход ко всем иконам? Да, более того – текст большинства икон изначально шаблонный, что мы показали через РБНФ-определения в дракон-алфавите. И конечно, языком схем не обязательно д.б. ДРАКОН (и вообще импер-язык) – любые информатизованные тексты (имеющие формальный синтаксис в конечных алфавите и словаре) можно представить «по шаблону».
Техноязык — единственное средство визуализации?
В общем случае состав средств представления данных (в т.ч. отчуждаемых знаний) определяется принятой структуризацией представляемого содержания. Уже Паронджанов указывал (прежде всего в /1, Гл. 12, п. Классификация знаний/), что содержание программ (мы можем сказать более общо — командных моделей) не сводится только к императивному. В то же время он, выделив также декларативное содержание, не классифицировал формы его представления. А в /1, Гл. 12, п/п Описание данных/ предложил определять величины визуала в вершине Полка или таблично за пределами дракон-схемы. Т.е. визуализация деклар-знания в авторской ДРАКОН-методологии не предполагается.
Автор этих строк придерживается иной т. зр. - что и отразил прежде всего в уточнении классификации в п/п 1.4.2.1. Полная классификация частного формализуемого знания проведена здесь; из неё следует необходимость трёх родов (семейств) взаимосвязанных частных языков — императивного, декларативного и активного. Каково содержание неимперативных языков — можно показать, если обсудить реальный язык высокого уровня — что и сделано далее на примере прогязыка Оберон.
В начало страницы | Оглавление | Версия для печати
Copyright © Жаринов В.Н.