ДАЯ[КОН] - дружелюбный алгоритмический язык, [который обеспечивает наглядность,] подмножество языка ДРАКОН
(Должен ли у каждого народа быть свой алгоритмический язык - ДКАКОН у китайцев, ДААКОН у американцев и ДГАКОН у греков ?)
Ну, каждый народ имеет свой алфавит, и потому аббревиатура на другом естественном языке в большинстве случаев будет будет несколько иначе записана
По-русски же мы можем расшифровывать её и несколько иначе -
ДРужелюбный
Алгоязык... - тем самым подчёркивая неспецифичность языка текста. Хотя "русский" здесь, по-моему, означает всего лишь принадлежность культуре, в которой создан техноязык...
А если серьёзно - то свой неформальный (для целей импер-эскизирования) стандарт техноязыка естественным образом формируется у носителей любого естественного языка - гибридизацией с этим языком - также, как и формальный стандарт формируется гибридизацией с искусственным языком. Это даже не вопрос - надо только учесть общие требования, предъявляемые к тексту при гибридизации - я сформулировал их, как сам понимаю,
в этом подпункте и конкретизировал для действий
в конце этого подпункта.
Но этого мало - не следует забывать и об этом:
Алгоритмы - это только небольшая составляющая структуры программной системы.
Именно поэтому я занимаюсь вопросами, отражёнными, в частности,
в этом сообщении - т.е. целостным визуальным представлением всего прогязыка. Ему должна соответствовать текстовая запись (которую
в этом сообщении называю метаязыком ТФРД). Посему о дальнейшем:
Блок "вставка" исключен, т.к. в ДАЯ каждый блок может быть ссылкой, см. ниже описание формата текстового представления блок-схем в ДАЯ.
Вставка - это ссылка и метка (для возврата из процедуры, вызванной по ссылке) одновременно, и эргономичнее выделить этот случай особым типом вершины. С таким взглядом, видимо, связано и следующее допущение:
Формат текстового представления БС в ДАЯ состоит из последовательно размещенных друг за другом описаний БС...
Процедуры должны организовываться в схему программы (процесса) - и д.б. язык текстового представления этих схем, с которыми связаны тексты процедур. Конечно, этот язык можно формировать отдельно (я определяю его как ПК-язык) - а потом из его вершин просто ссылаться на БС процедур (что отражается и в тексте процесса).
Почему Г.Н.Тышов в
качестве формата сохранения дракон-схем в файлах выбрал не их структурированное текстовое представление, приведенное в качестве примера В.Д.Паронджановым, а непригодный для редактирования "вручную" drt-формат ? ...
Рассмотрим 2 варианта изображения цикла в и.с.Дракон: ...
Для случая выходов из цикла с использование переменной вопроса цикла перевод в текстовый формат представляется совершенно очевидным: ...
Для случая выхода из цикла с обходом вопроса цикла не все так очевидно, потому что операторы выхода из цикла заданы неявно. ...
Посмотрите на результаты Рэйлвей Каген, в частности,
в этом сообщении - записывая импер-структуру как список для стековой машины, он получил, что БП назад в примитивной записи представить проблематично. Кстати, в ПРОТОНе вводятся представления для вершин-соединителей - но они промежуточные, до получения окончательного результата - и здесь есть над чем подумать...
Я глубоко не влезал в этот вопрос, но есть у меня подозрение, что по мере усложнения дракон-схемы с использованием досрочных выходов
из цикла найти однозначное соответствие между графическим и текстовым представлениями дракон-схемы становится все более трудной задачей.
Поэтому тот же Илья Ермаков
в этом сообщении и говорит о том, чтобы не клепать циклы с досрочными выходами, а сочинять цикл Дейкстры - но для этого сочинителю надо выводить маршрутную логику, опираясь на смысл алгоритмизуемого процесса...
Пример структурной блок-схемы
Продолжим рассмотрение ДС и соответствующей ей БС для случая выходов из цикла с использованием переменной вопроса цикла: ...
Введем новый вид отображения примитива или ветки силуэта:
логическая структура схемы. Здесь текстом действий будут обозначения
структурных блоков процедуры, привязанные к этим действиям.
Настоящий текст действия можно просмотреть, наведя указатель ныши
на прямоугольник действия, аналогично режиму сжатия БС (см. выше).
Предполагается, что на экране будут отображаться 2 окна:
слева логическая структура схемы, а справа, по выбору, Б-схема или
Д-схема.
Изменения в логической структуре схемы будут сразу же отображаться
на внешнем виде создаваемой блок-схемы.
Если нужно будет ввести новое действие, то надо в окне логической
структуры схемы дважды щелкнуть мышью между двумя действиями.
Окно редакции блоков действия для логической структуры схемы будет
вызываться по щелчку правой кнопки мыши на соответствующем действии.
Вот такие предложения.
Для совсем неподготовленных пользователей не подходит, но я с
самого начала предупреждал, что у меня предложения в первую очередь
для программистов.
Пф-ф!
Для непрограммиста, конечно, не всё понятно
, но вижу здесь следующее:
* Б-схема есть "выкладка" Д-схемы в линию, только вместо линейных БП-обходов вертикалей, нарушающих линейный порядок (вводимых как показанов этом подпункте для ветвлений и в этом подпункте для циклов) вводятся, я так понимаю, дополнительные переменные и новые развилки по ним? А зачем?
* вводится вершина типа Цикл, но неясно, чем она является - оператором или меткой?
* операции над вводимой переменной Вопрос цикла (кстати на схемах они ошибочно записаны как отношения, видимо, правильно как в тексте - присваивания) - в чём их смысл?
* вводится индексация порядка вертикалей, но по иному принципу, чем при обсуждении лиорасширения пока в этом примере - как "многоуровневая нумерация элементов содержания", причём роль "нумеруемых заголовков" играют, видимо, какие-то иконы. Не совсем понял по схемам, какие - но сама идея очень интересна - хотелось бы разъяснений.
При таком подходе номера действий приобретают справочный характер и нужны:
1) для быстрого нахождения нужного действия при открытии для редактирования окна текстового представления блок-схемы;
2) для более удобного установления соответствия между действиями в окне логической структуры блок-схемы и в окне отображения блок-схемы.
А правильно ли, когда есть что-то справочное? Не получается ли избыточность, "зашумляющая" восприятие?
При возникновении неразрешимых логических несоответствий в логической структуре схемы она будет сбрасываться и приводиться к линейному виду - действия без условий, с возможностью отката к последнему правильнову состоянию.
А почему возникают эти несоответствия? М.б. попробуем разобраться?
Для совсем неподготовленных пользователей не подходит, но я с самого начала предупреждал, что у меня предложения в первую очередь
для программистов.
Визуальное представление (набор представлений) д.б. для всех участников процесса - чтобы согласовывать представления заказчика и разработчика. Тогда можно спецификацию последовательно преобразовывать в совокупность описаний программных модулей и инструкций по их применению - а не пытаться сначала программировать куски процесса автономно от пользователя, а потом документировать их для того же пользователя.
О работе по стандартам, пытающимся разделять разработку и документирование - Хейвуд и Кармайкл в книге, вложенной
в это сообщение, приводят любопытную статистику - посмотрите на с. 15 примечание. То же говорил фон Нейман (я это цитировал в Драконографике), общий смысл - мы не м.б. уверены, что любое описание программы будет менее точным и сложным, чем она сама - поэтому разумно требовать, чтобы из самой программы (шире - алгомодели работы любого косавта) человеку д.б. максимально ясно, "как она это делает" - а этому как раз удовлетворяет визуализация на гибридном прогязыке (включая дракон-инструкцию, "что оператору делать с программой").
Естественно, не всё сразу - но общая концепция должна с самого начала позволять непротиворечивое расширение представления новыми компонентами (здесь - языками ТФРД, записывающими разные типы схем). Концепция логической структуры, похоже, позволяет это - т.е. по этому принципу можно закодировать текстом любой силуэт, очевидно, необязательно алгоритмический - именно поэтому она интересна. Не возникнут ли какие-то частные проблемы с текстованием неалгоритмических структур по этому принципу - надо смотреть...