OberonCore

Б-схема - это представление БС почти в том же виде, как в программе ab_vjaz, введена
для показа, с одной стороны, разницы во внешнем виде, а с другой - логической
тождественности Б и Д схем.

Цикл - конечно оператор. У меня в конце показан сгенерированный код процедуры,
там циклу соответствует оператор repeat

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

* вводится индексация порядка вертикалей
- это я сделал в пояснительных целях, в рабочем варианте этого не планируется

* А правильно ли, когда есть что-то справочное? Не получается ли избыточность, "зашумляющая" восприятие?
- можно ввести флажок, отключающий вывод меток

* А почему возникают эти неразрешимые логические несоответствия? М.б. попробуем разобраться?
- ну, мало ли, чего пользователь там введет, иногда проще сбросить, ну, или если ясно,
где ошибка, то подсветить ее


Выложенный материал - это предложения, и если пойдет активное обсуждение с ценными
замечаниями, то можно изменить там очень многое.
Не хотелось бы отказываться от идеи ТФАП, но конкретные детали формата могут
обсуждаться и улучшаться.

Интересно, удобен ли для редактирования блок-схемы предложенный мной интерфейс
(хотя, подозреваю, это можно будет проверить уже после его реализации на практике) ?

Единственное, чего я не буду делать (в одиночку уж точно!) - это писать полноценный
графический редактор для полной версии язка ДРАКОН.

Не вижу, почему бы и нет - полагаю, надо уважать любую веру, уважающую человеческое в человеке - а к православию (как и ко многим другим) в этом смысле нет вопросов (понятно, что широкое употребление этого слова в смысле "пиктограмма" пришло от "белых англосаксонских протестантов", в традиции которых икона не занимает особого места как предмет культа). Вот только "блок" в техноязыке уже имеет значение подграфа шампур-схемы - так что нужно искать другой термин, не менее красивый и выразительный. Очевидное сложносокращение толкования иконы "виоп" (ВИзуальный ОПератор) м.б. не совсем точно, имея в виду, что граф-схеы м.б. не только императивными - и корректно ли тогда будет говорить об их вершинах как об операторах? Можно предложить "грана" (ГРАфическая вершиНА) - вроде звучно и склоняется аналогично (грана-граны-гране-грану-граной-о гране) - но близко к слову "грань", которое вполне может встретиться в какой-то формализуемой области знаний, да и склонение могло быть более удачным (с полным различием форм, а тут ряд падежей у разных чисел совпадают: граны-гран-гранам-граны-гранами-о гранах). В общем, есть над чем подумать...

Т.е. вершина Цикл - просто для представления такой конструкции текстового языка, когда запись условия цикла текстуально отделена от записи переходов, вытекающих из результата проверки этого условия? И вот эта критика:вызвана теми же соображениями? Кстати, какой специальный оператор имеется в виду?


Т.е. подразумевается тот же приём, что был использован при выводе преобразования "ЦД-силуэт" в п. Доказательство этого примера - введение переменной, по которой организуется выбор маршрута (там - целого типа, здесь - булева)? Тогда операторы действительно д.б. присваиваниями...


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


А, ясно, я-то подумал, что Вы обнаружили, что при построении Б-схем возникают невязки вроде того, что в упомянутом сообщении Рэйлвей Каген...


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

Макетная реализация предложений, изложенных в файле dajakon1.

Вот выдалось свободное время и решил обобщить все мои наработки на форуме.
Можно сказать, отчет о проделанной работе:



Макеты с исх. кодом на C++ Builder 3 и Delphi 4 см. ниже в моем сообщении от
Воскресенье, 03 Апрель, 2011 20:15

а это главное окно макета:

Вопрос - может ли распространяемая И21 сборка (ну и из книги
Потопахина, соответственно) генерировать нормальный exe-файл, в который
можно было бы статически включать все нуждные библиотеки и затем пускать
на любой Win-машине ?

Спасибо, Александр, за ответ. Я повнимательнее посмотрел и нашел в документации
по КП описание того, как делать exe-файл. Обязательно попробую, когда буду
по-настоящему знакомиться с КП.

А макет я пока все же решил перетащить на Delphy, у них с BCB графика такая же,
так проще. В дальнейшем, если проект будет развиваться, буду поддерживать
соответствие между его вариантами на BCB3 и D4.

А если будут желающие перетащить его на КП, то пожалуйста. Код будет открытым
и буду стараться подробно все документировать.

Перетащил макет в Delphi 4.

Теперь обозначения для вариантов проекта будут:

b3_dalXX - вариант для Borland C++ Builder 3.0
d4_dalXX - вариант для Delphi 4

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

b3_dal02.rar, скачиваний 9
d4_dal02.rar, скачиваний 15

Новые версии см. в посте от 16.05.11
-----------------------------------------------------


Предлагаемые форматы файлов для программы dal_vjaz
и обсуждение вопроса обработки возникающих в процедуре ошибок для визуальной схемы,
добавление от 2 мая 2011:

Спасибо Евгению Темиргалееву, темы действительно поделены по моей просьбе.

Единственное замечание, что все просмотры достались старой теме "дракон-си",
а и число просмотров надо бы тоже было поделить корректно - старая тема занимает
1 страницу, а ее продолжение - 2 страницы, а значит и число просмотров должно
было быть поделено соответственно.

Но это уже мелочи - если у народа нет интереса к программе, то как счетчики ни
накручивай, пользоваться ей все-равно никто не будет. Так что все правильно.

Начиная сегодняшнего дня, в связи с тем что обсуждение моих предложений ведется, мягко говоря, крайне вяло,
все обновления и предложения будут выкладываться в сообщении от 3 апреля без дополнителльных уведомлений.

Уважаемый Дмитрий_ВБ!
Большая просьба.
Каждое обновление и предложение выкладывайте в отдельном новом сообщении.
Спасибо.

Было бы очень хорошо, если бы Вы подробно объясняли, какое именно УЛУЧШЕНИЕ
дает каждое обновление и предложение.

Ответ на пост Владимира Даниеловича по поводу улучшений,
которые дают мои предложения:

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

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

3) Формат файлов данных должен быть доступен для редактирования - в обсуждении
принял участие только Драконограф

4) Возможность ввода визуальной схемы несколькими способами (в теме "Замечания
Алексея Донского") - ответил только Драконограф. Алексей на просьбу сказать, что он
думает по пунктам 2 и 4 от обсуждения уклонился.

5) Предложение от 2 мая, помещенное в посте от 3 апреля в файле files.txt -
уточнение внутренних форматов файлов программы и предложения по отображению
обработки ошибок в визуальной схеме.

Обязательно. Ещё лучше почитать Раскина про масштабирование.

Как-то чересчур остро воспринимаете!
По п.2 ничего не скажу, надо изучить и пробовать, а банально некогда.
По п.4 скажу - обязательно!
В конце концов, рассматривая скульптуру в музее, мы можем заглянуть с разных сторон. И здесь тоже нецелесообразно одним представлением ограничиваться.

Спасибо за ответ, Алексей.
Возможно, я немного погорячился с фразой, что Вы уклонились от ответа - извиняюсь.

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

Донесите эту мысль до Паронджанова!
Ваше мнение будет более весомо, потому что Вы хоть что-то делаете, а я только рассуждаю...

Тут ведь вопрос еще и в том, что Владимир Даниелович - теоретик, а реализацией
занялся Геннадий Николаевич.
Что я могу сказать ? Мне не нравится содержимое файла ReadWrite1wire.c, выложенного
Геннадием Николаевичем в теме "тестирование ИС Дракон", потому что нужно было бы
генерировать структурированный код с минимальным использованием goto (это сейчас
является общепринятым стандартом в программировании), а если goto и использовать - то
только для обработки ошибок, потому что ошибки - это по своей сути вещь хаотическая и
разрушающая любую структуру (см. пример структуры процедуры генерации ветки силуэта
в файле files.txt, сообщение этой темы от 3 апреля).
Хотя и при обработке ошибок без goto можно обойтись - вместо него ставим возврат из
процедуры, а ошибку обрабатываем уже в процедуре верхнего уровня.

Свое видение визуальной среды я изложил в файлах dalvjaz.pdf и files.txt.
Появится свободное время - займусь дальнейшим развитием программы dal_vjaz.

Хотя код программы открыт и энтузиасты, если такие найдутся, могли бы пока подумать
над выводом полной формы отображения визуальной схемы, с надписями, а не сокращениями
внутри блоков .
Если энтузиасты все-таки отыщутся, то в окне "About" можно было бы написать:

ДРУЖЕЛЮБНЫЙ АЛГОРИТМИЧЕСКИЙ ВИЗУАЛЬНЫЙ ЯЗЫК
(подмножество языка ДРАКОН)
Бесплатное ПО с открытым кодом (freeware) (с) сообщество forum.oberoncore.ru

Покольку я интенсивно использую ИС Дракон при разработке и сопровждении микропроцессорных устройств, и очень полюбил этот инструмент, то хочу высказать несколько своих, чисто практических замечаний.
Поначалу пробовал печатать дракон -схемы на бумаге. Использовал принтер А4, ножницы и клей. Получались вполне симпатичные плакаты из 6 - 8 листов A4. Но потратив 10 минут на изготовление этого плаката, и посмотрев на него пару минут, продолжаешь работу, и еще через 5 минут плакат уже не соответствует реальности... В общем, сейчас обхожусь без твёрдых копий.
Это неверно. В форуме неоднократно приводились примеры достижения этой цели.
На основе своего опыта утверждаю: - производительность труда существенно повышается.
Да и сам труд меняется. Это даже трудно передать словами - это иное качество труда.
В окне "ИС Дракон" я вижу алгоритм работы программы гораздо лучше, чем в любом тексте, сформированном по всем "общепринятым стандартам в программировании".

И меня совершенно не смущает, что потом, где то, в автоматически сгенерированном коде, щедро используются goto. Точно так же, как меня не беспокоят переходы в сгенерированном компилятором машинном коде. Зато мне очень нравится, что сгенерированный текст программы очень ПРОСТОЙ. Я использую прото-ОС, и в совокупности простой текст и простая ОС дают минимум побочных эффектов, и максимум надёжности.

Кстати, этот текст великолепно оптимизируется компилятором, и я ни разу не заметил никаких проблем при использовании максимальной степени оптимизации. В результате, память моих микропроцессоров используется более эффективно.

В целом применение Дракона приблизило меня к моей давней цели: довести в своих устройствах надёжность программы до надёжности "железа".

Ефанов Сергей.

Спасибо, Сергей, что Вы поделились своим опытом использования ИС Дракон. Ничего не
имею против того, что ИС Дракон реально помогает Вам в вашей работе.

Вопрос в другом. Недавно Владимир Даниелович поставил вопрос о том, что надо начать
преподавать язык ДРАКОН студентам в ВУЗах с использованием ИС Дракон для обучения
студентов программированию.
В связи с этим возник вопрос о существующих на текущий момент недостатках ИС Дракон,
которые должны быть преодолены, чтобы язык ДРАКОН мог получить более широкое
распространение.
Тема достаточна спорная и неудивительно, что Вы несогласны с некоторыми моими
замечаниями. Эти вопросы нуждаются в дальнейшем обсуждении.

Главное, я думаю, - визуализировать прогязык, применяемый в обучении, целиком (а не только импер-часть, для чего и предназначен ДРАКОН) - и уже эту визуализацию применять в обучении. При этом и в импер-части фактически нужно провести точную и целостную гибридизацию ДРАКОНа с импер-синтаксисом прогязыка - а не приближённую "на общий/средний случай" . И в связи с выбором языка для этого встают некоторые вопросы.
Вот именно И нужно отметить в свете этой цитаты:
- есть разница между исхтекстом и машкодом. Если язык исхтекста допускает явные БП - то их присутствие вопрос лишь стиля сочинителя. Если не допускает - нужно обходиться без них.
У Сергея, видимо, первый случай - на это же рассчитана и Ты-среда. Для второго - нужно вводить альтернативу силуэтной разметке нелинейного тела алгоритма - без явных БП, но также обладающую свойствами "универсальной программы". Пока вижу в этой роли цикл Дейкстры - но м.б. кто-то из владеющих теорией ещё что-то предложит (а то ЦД тут многим не нравится )?
Это примерно как описано здесь для исключений? Тоже вопрос дискуссионный - см. здесь и здесь. Вероятно, тоже нужно определение исключения, учитывающее общую теорию и её реализацию в конкретном языке,
Конечно, она будет повышаться, если с графовой формой структуры человеку работать удобнее, чем с представленной ключевыми словами языка текстовой формы. Но дальше уже возникает вопрос о представлении задачи для разных участников создания решения (и сопровождения/развития его, между прочим) - см. хотя бы сказанное в этом посте и связанных с ним.
Среду поддержки такого языка нужно ещё писать... но сначала с поставленными вопросами бы определиться...

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

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

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

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