Д Р А К О Н О Г Р А Ф И К А

Маршрутами ДРАКОНа | Основы реализации | Средства общего назначения

Пока таковых насчитываются единицы. Здесь даётся предварительный обзор дракон-сред и систем.

Первой следует считать дракон-деклар-систему ГРАФИТ-ФЛОКС. Она разработана для применения техноязыка при создании законченных косавтов на базе аппаратуры БЦВМ «Бисер» по полному циклу НИОКР.

Строго говоря, в этой системе реализовано семейство языков ДРАКОН (импер-язык, граф-базированный в терминах генклассификации формализуемых знаний) и ФЛОКС (табулобазированный деклар-язык объявления величин автоматизированных объектов управления (АОУ)¹ на базе «Бисера»), применяемое по технологии ГРАФИТ. Обзор содержится в в этой теме.

В начале 1990-х годов Л. Эйсымонтом был разработан автономный редактор дракон-схем (будем называть его ЛЭ-редактор)². На сегодня он не считается удобным, но м.б. освоен для общего представления и сравнения с другими изделиями. Редактор и документация доступны здесь.

Исторически первой дракон-средой широкого применения является разработка Г. Тышова (далее - Ты-среда). Среда постоянно совершенствуется разработчиком; пока при этом также изменяется формат файлов её документов без обратной совместимости, что осложняет разработку приложений, сопрягаемых с ней по данным. Обратная связь с разработчиком доступна в этой теме. В рамках первичного освоения и оценки был составлен проект пользовательской спецификации Ты-среды, доступный здесь; дальнейшее освоение было признано нецелесообразным до повышения качества изделия (краткую его оценку можно найти далее по тексту).

Программист П. Приклонский разработал внешний конвертор из Ты-документов, содержащих ДРАКОН-Си-описания, в исхтексты на прогязыке Си.

Потребность в совершенствовании Ты-среды привела ещё одного разработчика – В.А. Тарасенко – к рефакторингу её приложения. Им также создан проект внешнего конвертора Ты-моделей на несколько прогязыков и общее определение приципов конверсии. Результаты доступны в этой теме.

Одновременно Тарасенко сформулировал требования как к среде, так и к стандарту техноязыка; обсуждение их с участием автора этих строк привело к выработке уточнённых требований. Результаты доступны в этой теме. Фактически это наиболее целостные требования к практически пригодной ИСП визуализации знаний. Поскольку необходима их отработка на конкретных ситуациях, в этой теме рассматриваются некоторые примеры.

Также Я.Романченко был создан автономный дракон-конвертор ДРОН для языка Активный Оберон (диалект языка Оберон – преемника Паскаля Н. Вирта). Дистрибутив доступен на сайте программы (см. здесь).

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

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

Разработчик систем управления реального времени Д.В. Барановский ищет возможности применить техноязык и шампур-метод для сквозной формализации задач РВ вплоть до гибридного программирования. Изначально в этой теме он провёл сравнительный анализ языка и дракон-сред с другими методологиями, указал на некоторые проблемы реализации и предложил решения по смешанной текстово-графической ИСП (будем называть её ДВБ-системой)³. Как язык реализации был предложен не ДРАКОН, а визуальный язык блок-схем (ВЯЗБС) почти в минимальном базисе вершин, что не позволяет говорить о полноценном решении. Первоначальной реализацией была программа АБ_ВЯЗ (доступна в упомянутой теме).

В дальнейшем был разработан новый вариант ДВБ-системы — редактор-транслятор ДАЛВЯЗ на массовые прогязыки. Фактически в основе лежит авторская методология формализации — совмещение в ИСП программирования и ограниченной спецификации задачи (называемое у Барановского РДП — от «Разработка и Документирование Программ»). ДАЛВЯЗ используется в разработке программ для задач основной деятельности Барановского (изначально - местное микроконтроллерное управление некоторыми видами сортировочного ж/д оборудования в реальном времени).

Определение ВЯЗБС и ДВБ-система развиваются; результаты и обратная связь с разработчиком доступны в этой теме.

Можно оценить различные ИСП-ДРАКОН по критериям, введённым здесь. Подобные оценки были даны в пользовательских спецификациях автора для ДВБ-системы и для Ты-среды. Учитывая, что там уже сформулированы назначения этих изделий, здесь можно ограничиться краткими выводами.

В отношении Ты-среды можно сказать, что она «избыточно сложна» для пользователя, прежде всего в силу следующего:

• наличия разных видов текстовых примечаний, т.н. «приложений» к вершинам. При этом все виды примечаний, кроме «управленческого», имеют формальный смысл в Ты-среде, влияя на процесс и/или результат трансляции схемы в текст (причём каждый вид по-своему); о неэргономичности этого подробнее см. это веб-сообщение;

• «плоского» форматирования текста, единого в пределах документа, что не позволяет сделать его более удобочитаемым;

• попытки «языкового универсализма» как для поддерживаемых прогязыков — заявлены несколько языков, воплощающих различные парадигмы программирования, так и для языков визуализации — для всей модели деятельности разработчик ограничился только техноязыком, а всё остальное содержание модели представил на базе языка ГНОМ;

• частичного возложения реализации прогязыков на пользователя — Ты-среда генерирует только т.н. «шаблоны программного кода», автоматически определяя в исходном тексте лишь маршрутную часть импер-составляющей описания. Всё остальное (командную часть, деклар-составляющую и общую структуру программы) пользователь должен «прописывать» в текстовой части вершин или в «шаблоне» исхтекста после трансляции;

• реализации, по сути, варианта «препроцессинга» для описания сложных (содержащих более одной схемы) моделей. При этом некие правила «сборки» определяются не визуальными операторами декомпозиции, а текстами в ГНОМ-схемах;

• недостаточно продуманного интерфейса;

• отсутствия свободной компоновки схем на диосцене (размещение по площади Ты-листа предопределено в редакторе);

• отсутствия связи по данным с какими бы то ни было средствами разработки/документирования, которые могли бы восполнить нереализованное в Ты-среде; нет включения (внедрения, связывания) внешних документов и/или объектов содержания, не поддерживается системный «карман» (буфер обмена);

• невозможности автоматического обмена исхтекстами на языках, поддержка которых заявлена, с системами, обрабатывающими эти тексты; внешние конверторы Романченко, Тарасенко и Приклонского делают возможным [полу]автоматический экспорт (при определённых требованиях к сочинению в Ты-среде) на некоторые прогязыки.

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

Общий вывод – при всех достоинствах выбранного подхода к реализации необходимо дальнейшее совершенствование Ты-среды прежде всего в когнитивно-эргономическом отношении (удобства работы и когнитивного качества создаваемых описаний).

В то же время ДВБ-система имеет достаточно низкий «порог вхождения» в пользование в силу следующего:

• реализует ряд языков, но предлагает вполне естественный способ доопределения их — в файлах ресурсов. Кроме того, степень реализации достаточно высока, оставляя пользователю не так много работы;

• достаточно хорошо документирована;

• предлагает различные представления содержания алгоритмов и программ — текстовое и графическое. При этом второе реализовано в различных вариантах, в основном оригинальных;

• реализует новый тип представления маршрутов — т.н. логическую структуру программы (ЛСП). По сути, это табулобазированное описание, где графы таблицы соответствуют осям порядка маршрутов (в терминах структур графит-метода). Барановский предлагает заполнение ЛСП-формы как основной тип ввода структуры схемы, что можно рассматривать как реализацию идеи И. Ермакова о клавиатурном вводе граф-схем (см. это веб-сообщение).

• транслирует описания программ сразу в корректный исхтекст (при условии доопределения прогязыков);

Однако ей присущи и некоторые ограничения:

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

• требуют дальнейшего развития средства декомпозиции моделей;

• средства представления непрограммной части пока не позволяют оформлять в ней полноценные спецификации, описания задач и предметных областей;

• нет возможности включения (внедрения, связывания) внешних документов и/или объектов содержания (напр., из офисных пакетов).

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

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

Каковы же общие рекомендации по выбору средств на сегодняшний момент? Очевидно, всё зависит от целей сочинителя.

Если цель – создать целостную формальную модель, пригодную для программной реализации, то нужно пользоваться ДВБ-системой.

Если же цель – создать модель в первую очередь для человека, следует либо использовать результаты моделирования в этой среде как основу диосцен, дорабатываемую в редакторах документов или изображений, напр. из состава пакета OpenOffice.org, либо сразу визуализировать в таких редакторах (если не предполагается дракон-программирование).

Отметим также перспективные проекты и целесообразные направления развития ИСП-ДРАКОН.

Возможности представления алгоритмической части программ предполагается ввести в структурный редактор-компилятор, разрабатываемый по проекту PureBuilder В. Лаптевым с сотрудниками (далее РВ-систему); результаты доступны на этом форуме . Спецификацию РВ-системы независимо разрабатывает С. Прохоренко; результаты оформлены как этот веб-ресурс .

В г. Орле ведётся разработка дракон-редактора, воплощающего идеи И.А. Ермакова по совершенствованию шампур-метода. Некоторые сведения доступны в в этой теме.

Прототипные редакторы шампур-схем созданы Э. Ильченко (как расширение элеграф-редактора Draw из OpenOffice.org) и С. Митькиным (как автономное приложение). Редакторы были изначально предназначены для допрограммной визуализации алгоритмов деятельности (как т.н. «бизнес-процессов») и поддерживают только импер-часть описания. Митькин в настоящее время реализует гибридизацию с прогязыками (прежде всего с Си).

Возможности визуализации бизнес-процесов на драконоподобном импер-языке введены в популярную среду автоматизации 1С:, о чём подробнее в этой теме (при разработке языка использовались консультации В.Д. Паронджанова).

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

Тем самым реализация ТФЗ должна стать комплексной ИСП визуализации знаний; следуя Барановскому, удобно назвать её системой РДП – разработки и документирования процессов (и программ как предельно формализованной части этих процессов). ИСП без выхода на программирование (автоматическое) также будем называть РДП-средой.

В начало страницы | Оглавление | Версия для печати

Copyright © Жаринов В.Н.