> -- Дмитрий_ВБ в download/file.php?id=1749 писал(а):
> ДАЯ[КОН] - дружелюбный алгоритмический язык, [который обеспечивает наглядность,] подмножество языка ДРАКОН   (Должен ли у каждого народа быть свой алгоритмический язык - ДКАКОН у китайцев, ДААКОН у американцев и ДГАКОН у греков ?)
Ну, каждый народ имеет свой алфавит, и потому аббревиатура на другом естественном языке в большинстве случаев будет будет несколько иначе записанаПо-русски же мы можем расшифровывать её и несколько иначе -ДРужелюбныйАлгоязык... - тем самым подчёркивая неспецифичность языка текста. Хотя "русский" здесь, по-моему, означает всего лишь принадлежность культуре, в которой создан техноязык...
А если серьёзно - то свой неформальный (для целей импер-эскизирования) стандарт техноязыка естественным образом формируется у носителей любого естественного языка - гибридизацией с этим языком - также, как и формальный стандарт формируется гибридизацией с искусственным языком. Это даже не вопрос - надо только учесть общие требования, предъявляемые к тексту при гибридизации - я сформулировал их, как сам понимаю,в этом подпунктеи конкретизировал для действийв конце этого подпункта.
Но этого мало - не следует забывать и об этом:
> -- Илья Ермаков в viewtopic.php?p=48527#p48527 писал(а):
> Алгоритмы - это только небольшая составляющая структуры программной системы.
Именно поэтому я занимаюсь вопросами, отражёнными, в частности,в этом сообщении- т.е. целостным визуальным представлением всего прогязыка. Ему должна соответствовать текстовая запись (которуюв этом сообщенииназываю метаязыком ТФРД). Посему о дальнейшем:
> -- Дмитрий_ВБ в download/file.php?id=1749 писал(а):
> Блок "вставка" исключен, т.к. в ДАЯ каждый блок может быть ссылкой, см. ниже описание формата текстового представления блок-схем в ДАЯ.
Вставка - это ссылка и метка (для возврата из процедуры, вызванной по ссылке) одновременно, и эргономичнее выделить этот случай особым типом вершины. С таким взглядом, видимо, связано и следующее допущение:
> -- Дмитрий_ВБ в download/file.php?id=1749 писал(а):
> Формат текстового представления БС в ДАЯ состоит из последовательно размещенных друг за другом описаний БС...
Процедуры должны организовываться в схему программы (процесса) - и д.б. язык текстового представления этих схем, с которыми связаны тексты процедур. Конечно, этот язык можно формировать отдельно (я определяю его как ПК-язык) - а потом из его вершин просто ссылаться на БС процедур (что отражается и в тексте процесса).

> -- Дмитрий_ВБ в download/file.php?id=1749 писал(а):
> Почему Г.Н.Тышов вкачестве формата сохранения дракон-схем в файлах выбрал не их структурированное текстовое представление, приведенное в качестве примера В.Д.Паронджановым, а непригодный для редактирования "вручную" drt-формат ? ...Рассмотрим 2 варианта изображения цикла в и.с.Дракон: ...Для случая выходов из цикла с использование переменной вопроса цикла перевод в текстовый формат представляется совершенно очевидным: ...Для случая выхода из цикла с обходом вопроса цикла не все так очевидно, потому что операторы выхода из цикла заданы неявно. ...
Посмотрите на результаты Рэйлвей Каген, в частности,в этом сообщении- записывая импер-структуру как список для стековой машины, он получил, что БП назад в примитивной записи представить проблематично. Кстати, в ПРОТОНе вводятся представления для вершин-соединителей - но они промежуточные, до получения окончательного результата - и здесь есть над чем подумать...

> -- Дмитрий_ВБ в download/file.php?id=1749 писал(а):
> Я глубоко не влезал в этот вопрос, но есть у меня подозрение, что по мере усложнения дракон-схемы с использованием досрочных выходовиз цикла найти однозначное соответствие между графическим и текстовым представлениями дракон-схемы становится все более трудной задачей.
Поэтому тот же Илья Ермаковв этом сообщениии говорит о том, чтобы не клепать циклы с досрочными выходами, а сочинять цикл Дейкстры - но для этого сочинителю надо выводить маршрутную логику, опираясь на смысл алгоритмизуемого процесса...

> -- Дмитрий_ВБ в download/file.php?id=1749 писал(а):
> Пример структурной блок-схемы   Продолжим рассмотрение ДС и соответствующей ей БС для случая выходов из цикла с использованием переменной вопроса цикла: ... Введем новый вид отображения примитива или ветки силуэта:логическая структура схемы. Здесь текстом действий будут обозначенияструктурных блоков процедуры, привязанные к этим действиям.   Настоящий текст действия можно просмотреть, наведя указатель нышина прямоугольник действия, аналогично режиму сжатия БС (см. выше).   Предполагается, что на экране будут отображаться 2 окна:слева логическая структура схемы, а справа, по выбору, Б-схема илиД-схема.   Изменения в логической структуре схемы будут сразу же отображатьсяна внешнем виде создаваемой блок-схемы.   Если нужно будет ввести новое действие, то надо в окне логическойструктуры схемы дважды щелкнуть мышью между двумя действиями.     Окно редакции блоков действия для логической структуры схемы будетвызываться по щелчку правой кнопки мыши на соответствующем действии.   Вот такие предложения.    Для совсем неподготовленных пользователей не подходит, но я с самого начала предупреждал, что у меня предложения в первую очередьдля программистов.
Пф-ф!Для непрограммиста, конечно, не всё понятно, но вижу здесь следующее:
* Б-схема есть "выкладка" Д-схемы в линию, только вместо линейных БП-обходов вертикалей, нарушающих линейный порядок (вводимых как показанов этом подпункте для ветвленийив этом подпункте для циклов) вводятся, я так понимаю, дополнительные переменные и новые развилки по ним? А зачем?
* вводится вершина типаЦикл, но неясно, чем она является - оператором или меткой?
* операции над вводимой переменнойВопрос цикла(кстати на схемах они ошибочно записаны как отношения, видимо, правильно как в тексте - присваивания) - в чём их смысл?
* вводится индексация порядка вертикалей, но по иному принципу, чем при обсуждении лиорасширенияпока в этом примере- как "многоуровневая нумерация элементов содержания", причём роль "нумеруемых заголовков" играют, видимо, какие-то иконы. Не совсем понял по схемам, какие - но сама идея очень интересна - хотелось бы разъяснений.
> -- Дмитрий_ВБ в download/file.php?id=1749 писал(а):
> При таком подходе номера действий приобретают справочный характер и нужны:1) для быстрого нахождения нужного действия при открытии для  редактирования окна текстового представления блок-схемы;2) для более удобного установления соответствия между действиями в окне логической структуры блок-схемы и в окне отображения блок-схемы.
А правильно ли, когда есть что-то справочное? Не получается ли избыточность, "зашумляющая" восприятие?

> -- Дмитрий_ВБ в download/file.php?id=1749 писал(а):
> При возникновении неразрешимых логических несоответствий в логической структуре схемы она будет сбрасываться и приводиться к линейному виду - действия без условий, с возможностью отката к последнему правильнову состоянию.
А почему возникают эти несоответствия? М.б. попробуем разобраться?

> -- Дмитрий_ВБ в download/file.php?id=1749 писал(а):
> Для совсем неподготовленных пользователей не подходит, но я с самого начала предупреждал, что у меня предложения в первую очередьдля программистов.
Визуальное представление (набор представлений) д.б. для всех участников процесса - чтобы согласовывать представления заказчика и разработчика. Тогда можно спецификацию последовательно преобразовывать в совокупность описаний программных модулей и инструкций по их применению - а не пытаться сначала программировать куски процесса автономно от пользователя, а потом документировать их для того же пользователя.
О работе по стандартам, пытающимся разделять разработку и документирование - Хейвуд и Кармайкл в книге, вложеннойв это сообщение, приводят любопытную статистику - посмотрите на с. 15 примечание. То же говорил фон Нейман (я это цитировал в Драконографике), общий смысл - мы не м.б. уверены, что любое описание программы будет менее точным и сложным, чем она сама - поэтому разумно требовать, чтобы из самой программы (шире - алгомодели работы любого косавта) человеку д.б. максимально ясно, "как она это делает" - а этому как раз удовлетворяет визуализация на гибридном прогязыке (включая дракон-инструкцию, "что оператору делать с программой").

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