DRAKON.SU

Все выше перечисленные программы ГЕНЕРИРУЮТ КОД В АВТОМАТЕ!!!!

Назвать доработки развитием - не могу !
Попытка механизма была, но как всегда "начальная стадия"
Это мое предложение

Может пора все таки, что то менять в ИС Дракон?

Мораль сей басни такова:
Кому то открытка и дифирамбы,
А кому то 93 миллиона рублей только за тех поддержку
Где хоть один тендер на ИС Дракон? - это и есть главный показатель его функциональности.
Где бурные обсуждения работы в ИС Дракон? - это второй показатель востребованности ПО
наверное на форуме эксплуатанта ИС Дракон - ОДК Климова, но форума по этой теме у них нет!
Даже на форуме ОВЕН, есть довольно бурное обсуждение (больше критика) - Вот это показатель заинтересованной Аудитории, а там только программисты.
Есть и другие обсуждения на программистских форумах.

Но Владимир Данилович не считает "программирование" - широкой областью, это очень узко направленная область.
По этому все программисты и ушли с форума Дракон... (люди которые пишут исключающее ИЛИ раз 15 в день! и прочие комбинации)

Можно и дальше делать -УНИВЕРСАЛ, И ДУМАТЬ КАК ПРАВИЛЬНО СОСТАВИТЬ ТРИ ИКОНЫ (а Вы попробуйте 200 икон под конкретную задачу, а не абстрактно).
Только аудитория теряется быстро, а снова получить аудиторию обратно практически не возможно!!!!

Все кто до сих пор участвует в форуме - это люди связанные именно с практическим программированием ЭВМ, а так же подавляющее большинство пользователей ИС Дракон "практикующие"(воспользуюсь врачебным термином) программисты

Алексей, дайте ссылку

https://owen.ru/forum/showthread.php?t= ... 0%EA%EE%ED

https://owen.ru/forum/showthread.php?t=27487
Ссылка на 1 страницу (из трех)


Кстати давно на форуме не было нашего глубоко уважаемого коллеги Ситникова Владимира, а вот на форуме Овен он активен сейчас!

LCOM обратите внимание причем МАТЛАБ и Дракон
Это последняя запись по теме ИС Дракон!
Это явно не я писал!!!

Все получается очень просто.
Графит не мог жить без Флокса, а Флокс без Графита!
Здесь мы обсуждаем Флокс (Дракон)
Давайте обсудим Графит (Пространство имен)

//Сразу забегая вперед у Геннадия Николаевича в ИС Дракон ЕСТЬ область объявления переменных. В данном случае предлагаю разобраться что, и почему с ней не так.
//может это поможет Автору в усовершенствовании ИС Дракон

Владимир Данилович - не могли бы Вы обнародовать ту страничку из той книги (по Графит Флоксу), где начинается описание возможных используемых данных, построение имен переменных?
... и еще там есть интересная фраза "объектное программирование" (и это в 80 годах прошлого века)
Там есть и пункты к которым многие IDE приходят только сейчас!

А Мы постараемся понять как это могло работать, и интерпретируем в Реалии современного мира
Хочу заметить, что данная область является общей для всех известных мне языков программирования. Большинство типов данных структур и таблиц абсолютно одинаковые для всех языков (могут быть различны только названия типов)
Наработка по графическому определению переменных есть (или была) у Геннадия Николаевича.

В нашем редакторе это вполне допустимо: внутри вопроса пишем комментарий - и он отображается на схеме. А под комментарием пишем код. Он не отображается на схеме, но выполняется внутри генерируемой конструкции if(). Также можно просто вызвать стороннюю диаграмму по имени, которая вернет True/False.
У нас есть механизм, по которому работает икона Вставка: двойной клик по ней открывает привязанную диаграмму, которую можно править. Для иконы Вопрос я такого вызова не делал, но это не сложно организовать.

1. У Гармошки достаточно уникальный вид. С полкой перепутать сложно, как мне кажется.
2. Если иконы Вопрос рисовать с промежутками, то теряется смысл внутренней коммутации выходов. Придется использовать некие транзитные переменные, от чего я хотел уйти.
3. Гармошка достаточно компактная, но при этом не теряется её образ - некая структура, похожая на группу вопросов, только соединенных в батарею.
4. Представьте, что у вас есть узел, способный коммутировать 10 лиан. Гармошка справится. А ворох линий с традиционными Вопросами или Выбором/Вариантами будет перегружать схему.

Такую гармошку, я рассматривал в плане замены, супер громоздкой иконы Выбор.


Мой вариант решения:
После разрастания схемы необходимо, сделать так:
1)Выделить иконы входящие по смыслу в группу
2)нажать ПКМ и выбрать из контекста "создать капсулу"
3)в появившемся диалоговом окне определить тип капсулы - Вопрос или Действие, Дать Имя.

вместо набора икон формируется одна икона с заданным именем. В дереве проекта, под именем схемы, формируется дочерний узел с именем капсулы.
в дальнейшем можно пройти в капсулу и отредактировать ее внутреннюю схему. Также можно копировать капсулу в другие места программы.
Основная особенность капсулы- капсула не нуждается в объявлении переменных и экземпляров, и использует переменные "Материнской" Схемы
Данный механизм сродни Действию в ООП, но все же он отличается, и продиктован не подражанием ООП, а удобством дальнейшей работой со схемой

Икона, объединяющая внутри себя другие иконы, должна иметь вид - отличительный от стандартного вопроса и действия (немного отличительный вид для достаточного понимания, что это капсула а не вопрос или действие)

Для интересующихся данным вопросом могу рассказать более подробно, а возможно и с рисунками

Так Вставка, по крайней мере в нашем редактора, так и работает: по сути Действие-капсула, описанное внешней схемой.
А в развитие вашего предложения, для поддержки дизайна Вставки, рисуем Вопрос с двойными гранями - будет Вопрос-капсула.

Да, конечно, обязательно надо рассказать.
И обязательно с рисунками.

И пояснить, чем капсула отличается от иконы Вставка.

У Владимира Даниловича нет четкого описание свойств Вставки
В тех случаях когда ее используют (которые я видел здесь и на видео)
Вставка это отдельный экземпляр процедуры со своим пространством имен, и нуждающийся в передачи данных из схемы в Вставку и Обратно

Капсула использует пространство имен, самой схемы в которой находится, ей не нужно задавать отдельные переменные, соответственно она их и изменяет при исполнении.

Использование процедур в Драконе вызывает большое количество ошибок и лишних икон

Например попробуйте использовать процедуру Таймер или Тригер фронта. Если в программе только два маршрута , то все еще пока логично, но как только становится маршрутов больше- возникают следующие условия использования Вставки:
1)необходимо чтобы процедура вызывалась каждый цикл программы, тогда мы перемещаем икону " Вставка" вызова процедуры в начало программы или конец, что делает схему не читаемой- ведь хорошо когда икона находится на своем месте по графическому смыслу
2)В каждом маршруте должна появится управляющая икона, которая должна взводить управляющую переменную, если проглядеть эту икону и не поставить в нужное место, программа начинает работать неправильно - А теперь если у нас 20 маршрутов, то и Управляющих икон должно быть 20 (икон паразитов которые занимают место)
3) работа с выходными значениями требует появления таких икон как Вопрос и Выбор

Я использую Вставку при сборке конечной программы, там где требуется определить только порядок их выполнения -- т.к ветвление схемы для них не предусматривается. А вот ветвление схемы между ними - да, при условии что Икона Вопрос замыкается на вставке и в ставка не зависимо от результата вопроса выполняется всегда, в вопросе может обрабатываться какая то вспомогательная переменная
Исключение составляет выполнение Массива Вставок в цикле Для


Мне лично не нравится дизайн иконы Вставка по Параджанову. Эта икона имеет малоинформативный дизайн и не удобство размещения в ней информации, я чаще в место нее использовал полку. Сейчас я вижу дизайн этой Иконы как чертежное обозначение микросхемы. В принципе от начального отличается мало но более разветвленная, имеет формализированные поля ввода-вывода, согласно объявленным переменным

Опять же я повторю самое главное отличие Дракона и Других языков:
Дракон - это поток управления,
Другие языки -поток данных.
Таким образом нужно использовать сильную сторону Дракона - объективность управления

Перегонка данных из схемы в схему (во внимание принимается ВСТАВКА) - это слабая сторона Дракона, у него нет обозначений потока данных и возможности их контролировать при отладке

кроме того изначально Дракон задумывался как объектный язык. О чем повествует книга Руководство Графит Флокс, которая находится у Владимира Даниловича, выполненная кажется еще на печатной машинке.

Но в силу отсутствия технической возможности Владимир Данилович не может представить выдержки из этой книги

Этот момент вполне можно регулировать при сборке в генераторе. Например, схема, не имеющая Заголовка в структуре диаграммы, может вставляться напрямую, а имеющая - как процедура. Или использовать некий заменитель Заголовка, пунктирный, например.

Дмитрий, ведь заголовок не самое важное в процедуре - вторая важная часть любой процедуры это тянущие все в низ контрольные переменные, которые в схеме надо приладить так чтобы во время отладки, определить правильность работы процедуры и их нужно вытягивать на поверхность иконы процедуры .

А капсула это продолжение схемы, там даже нумерация пересылок должна использоваться общая с схемой

Почему я выделяю две капсулы Действие и Вопрос:

иногда капсула должна иметь два выхода как в случае с Чуком и Геком - четыре вопроса в одном - и контролировать это дело проще

На самом деле из начально я предложил бы всем договориться о Формализации, свойствах и функциях Икон: и тогда мы сможем все разговаривать на одном языке!

Данное соглашение позволит читать схемы друг друга и мыслить в одном направлении, а так же создателем редакторов усовершенствовать их

Просто сбой какой то я писал в одну тему а сообщение прилетело в другую

Это не сбой, а наведение порядка на форуме.

Алексей Муравицкий, обсуждение ваших предложений должно происходить только в этой теме.

Ваши предложения и замечания очень важны. Они должны быть сконцентрированы в одной теме (а не распыляться обрывками по разным темам).

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

про нумерацию ссылок я не понял: мы на диаграмму ДРАКОНа обычно глядим, как на граф, а не на нумерованные адресуемые ячейки.

заголовок я привел в пример к тому, то нужен простой принцип реализации кода Вставки/Капсулы: или вызов функции (как сейчас у нас в редакторе), или вставка свёрнутой диаграммы (т.е. просто сжатой визуально, но фактически являющейся частью рабочей диаграммы, "капсулы" по-вашему). Для программирования принципов реализации можно применить мой способ: задавать разные виды Заголовков (Обычный/Пунктирный), или вовсе убрать Заголовок при создании Капсулы, и заменить его на Комментарий, например. При таком создании капсулы адресное пространство останется тем же, что и в рабочей диаграмме.

Резюмируя, считаю: на мой взгляд,
икона Вставка может рассматриваться как:
1) вызов функции, если она содержит название другой диаграммы,
2) включение в схему свернутой части диаграммы, с которой можно работать как с отдельной диаграммой, но оставаясь в области видимости переменных диаграммы верхнего уровня.
Во втором случае она может называться Капсулой.

Придавать Капсуле вид иконы "Вопрос" считаю возможным. Мы данный механизм используем, вписывая в Вопрос название внешней диаграммы-функции, возвращающей Истина/Ложь, т.е. в конфигурации т.н. Вопрос/Вставка. Думаю, что так же можно вписывать диаграмму-капсулу, если она, например, имеет соответствующие ветви для вывода лиан. Может быть здесь пригодились бы иконки Адрес, только теперь уже не с названиями веток силуэта, а с ответами "ДА" и "НЕТ"?

Думаю, что Гармошку тоже можно реализовать как Капсулу, но с числом выходов больше одного. Если её строить с использованием того же подхода, что и Вопрос/Капсулу, то текст на иконках "Адрес" будет, соответственно, определять текст шестигранников в составе Гармошки.