OberonCore https://forum.oberoncore.ru/ |
|
Программы AB_VJAZ и DAL_VJAZ https://forum.oberoncore.ru/viewtopic.php?f=121&t=3383 |
Страница 2 из 6 |
Автор: | Дмитрий_ВБ [ Понедельник, 13 Сентябрь, 2010 10:23 ] |
Заголовок сообщения: | Re: О предложениях по ДАЯКОН |
Драконограф писал(а): * Б-схема есть "выкладка" Д-схемы в линию, только вместо линейных БП-обходов вертикалей, нарушающих линейный порядок (вводимых как показанов этом подпункте для ветвлений и в этом подпункте для циклов) вводятся, я так понимаю, дополнительные переменные и новые развилки по ним? А зачем? * вводится вершина типа Цикл, но неясно, чем она является - оператором или меткой? * операции над вводимой переменной Вопрос цикла (кстати на схемах они ошибочно записаны как отношения, видимо, правильно как в тексте - присваивания) - в чём их смысл? Б-схема - это представление БС почти в том же виде, как в программе ab_vjaz, введена для показа, с одной стороны, разницы во внешнем виде, а с другой - логической тождественности Б и Д схем. Цикл - конечно оператор. У меня в конце показан сгенерированный код процедуры, там циклу соответствует оператор repeat Переменная Вопрос цикла - это флаг выхода из цикла, общий для нескольких условий выхода, поэтому без нее в показанной логике обойтись нельзя. * вводится индексация порядка вертикалей - это я сделал в пояснительных целях, в рабочем варианте этого не планируется * А правильно ли, когда есть что-то справочное? Не получается ли избыточность, "зашумляющая" восприятие? - можно ввести флажок, отключающий вывод меток * А почему возникают эти неразрешимые логические несоответствия? М.б. попробуем разобраться? - ну, мало ли, чего пользователь там введет, иногда проще сбросить, ну, или если ясно, где ошибка, то подсветить ее Выложенный материал - это предложения, и если пойдет активное обсуждение с ценными замечаниями, то можно изменить там очень многое. Не хотелось бы отказываться от идеи ТФАП, но конкретные детали формата могут обсуждаться и улучшаться. Интересно, удобен ли для редактирования блок-схемы предложенный мной интерфейс (хотя, подозреваю, это можно будет проверить уже после его реализации на практике) ? Единственное, чего я не буду делать (в одиночку уж точно!) - это писать полноценный графический редактор для полной версии язка ДРАКОН. |
Автор: | Владислав Жаринов [ Вторник, 14 Сентябрь, 2010 04:23 ] |
Заголовок сообщения: | Об "иконоборчестве" в техноязыке :) |
Дмитрий_ВБ в download/file.php?id=1749 писал(а): Из уважения к чувствам православных верующих слово "икона" не входит в состав описательных терминов языка ДАЯ. Не вижу, почему бы и нет - полагаю, надо уважать любую веру, уважающую человеческое в человеке - а к православию (как и ко многим другим) в этом смысле нет вопросов (понятно, что широкое употребление этого слова в смысле "пиктограмма" пришло от "белых англосаксонских протестантов", в традиции которых икона не занимает особого места как предмет культа). Вот только "блок" в техноязыке уже имеет значение подграфа шампур-схемы - так что нужно искать другой термин, не менее красивый и выразительный. Очевидное сложносокращение толкования иконы "виоп" (ВИзуальный ОПератор) м.б. не совсем точно, имея в виду, что граф-схеы м.б. не только императивными - и корректно ли тогда будет говорить об их вершинах как об операторах? Можно предложить "грана" (ГРАфическая вершиНА) - вроде звучно и склоняется аналогично (грана-граны-гране-грану-граной-о гране) - но близко к слову "грань", которое вполне может встретиться в какой-то формализуемой области знаний, да и склонение могло быть более удачным (с полным различием форм, а тут ряд падежей у разных чисел совпадают: граны-гран-гранам-граны-гранами-о гранах). В общем, есть над чем подумать... |
Автор: | Владислав Жаринов [ Вторник, 14 Сентябрь, 2010 05:09 ] |
Заголовок сообщения: | Re: О предложениях по ДАЯКОН |
Дмитрий_ВБ в viewtopic.php?p=51219#p51219 писал(а): Цикл - конечно оператор. У меня в конце показан сгенерированный код процедуры, там циклу соответствует оператор repeat Т.е. вершина Цикл - просто для представления такой конструкции текстового языка, когда запись условия цикла текстуально отделена от записи переходов, вытекающих из результата проверки этого условия? И вот эта критика: Дмитрий_ВБ в download/file.php?id=1749 писал(а): Кстати, в языке Паскаль оператор выхода из цикла отсутствует, хотя несомненно, что Н.Вирт знал о существовании такого оператора, когда создавал язык программирования Паскаль. вызвана теми же соображениями? Кстати, какой специальный оператор имеется в виду?Дмитрий_ВБ в viewtopic.php?p=51219#p51219 писал(а): Переменная Вопрос цикла - это флаг выхода из цикла, общий для нескольких условий выхода, поэтому без нее в показанной логике обойтись нельзя. Т.е. подразумевается тот же приём, что был использован при выводе преобразования "ЦД-силуэт" в п. Доказательство этого примера - введение переменной, по которой организуется выбор маршрута (там - целого типа, здесь - булева)? Тогда операторы действительно д.б. присваиваниями... Дмитрий_ВБ писал(а): Драконограф писал(а): * А правильно ли, когда есть что-то справочное? Не получается ли избыточность, "зашумляющая" восприятие? - можно ввести флажок, отключающий вывод меток Дык я как раз о том, что если можно просто отключить - надо ли оно? И кстати, для построения схем данные о номерах вершин разве не используются? Дмитрий_ВБ в viewtopic.php?p=51219#p51219 писал(а): - ну, мало ли, чего пользователь там введет, иногда проще сбросить, ну, или если ясно, где ошибка, то подсветить ее А, ясно, я-то подумал, что Вы обнаружили, что при построении Б-схем возникают невязки вроде того, что в упомянутом сообщении Рэйлвей Каген... Дмитрий_ВБ в viewtopic.php?p=51219#p51219 писал(а): Выложенный материал - это предложения, и если пойдет активное обсуждение с ценными замечаниями, то можно изменить там очень многое. Не хотелось бы отказываться от идеи ТФАП, но конкретные детали формата могут обсуждаться и улучшаться. Идея принципиально отличная, а изменять надо гл. обр. чтобы создать условия для последующего добавления в метаязык новых языков (для описания конкретных типов схем) и для задания единого принципа интеграции описаний на этих языках (чтобы можно было описать как логическую связь - напр. вхождение дракон-схемы в одну или более дракон-моделей, так и физическую - напр., что некоторая схема/подсхема вписана в контур вершины др. схемы, которая необязательно связана с первой логически). Ну и внутри схемы д.б. возможность определения разметки текстов вершин. Поскольку в ВЯЗБС уже определено представление и силуэта, и дерева (а это, видимо, базовый набор структур), то нужно, наверное, развивать эти представления. При понятном описании стандарта, очевидно, написание РДП-редактора кем-то ещё не вопрос. |
Автор: | Дмитрий_ВБ [ Вторник, 22 Март, 2011 18:16 ] |
Заголовок сообщения: | Re: дракон-си |
Макетная реализация предложений, изложенных в файле dajakon1. Вот выдалось свободное время и решил обобщить все мои наработки на форуме. Можно сказать, отчет о проделанной работе: Вложение: Макеты с исх. кодом на C++ Builder 3 и Delphi 4 см. ниже в моем сообщении от Воскресенье, 03 Апрель, 2011 20:15 а это главное окно макета: Вложение:
|
Автор: | Дмитрий_ВБ [ Среда, 30 Март, 2011 11:05 ] |
Заголовок сообщения: | Re: дракон-си |
Вопрос - может ли распространяемая И21 сборка (ну и из книги Потопахина, соответственно) генерировать нормальный exe-файл, в который можно было бы статически включать все нуждные библиотеки и затем пускать на любой Win-машине ? |
Автор: | Александр Ильин [ Среда, 30 Март, 2011 11:31 ] |
Заголовок сообщения: | Re: дракон-си |
Дмитрий_ВБ писал(а): Кстати, вопрос - может ли распространяемая И21 сборка (ну и из книги Да.
Потопахина, соответственно) генерировать нормальный exe-файл, в который можно было бы статически включать все нуждные библиотеки и затем пускать на любой Win-машине? |
Автор: | Дмитрий_ВБ [ Четверг, 31 Март, 2011 08:37 ] |
Заголовок сообщения: | Re: дракон-си |
Спасибо, Александр, за ответ. Я повнимательнее посмотрел и нашел в документации по КП описание того, как делать exe-файл. Обязательно попробую, когда буду по-настоящему знакомиться с КП. А макет я пока все же решил перетащить на Delphy, у них с BCB графика такая же, так проще. В дальнейшем, если проект будет развиваться, буду поддерживать соответствие между его вариантами на BCB3 и D4. А если будут желающие перетащить его на КП, то пожалуйста. Код будет открытым и буду стараться подробно все документировать. |
Автор: | Дмитрий_ВБ [ Воскресенье, 03 Апрель, 2011 20:15 ] |
Заголовок сообщения: | Re: дракон-си |
Перетащил макет в 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: Вложение:
|
Автор: | Дмитрий_ВБ [ Понедельник, 11 Апрель, 2011 13:03 ] |
Заголовок сообщения: | Re: Программы AB_VJAZ и DAL_VJAZ |
Спасибо Евгению Темиргалееву, темы действительно поделены по моей просьбе. Единственное замечание, что все просмотры достались старой теме "дракон-си", а и число просмотров надо бы тоже было поделить корректно - старая тема занимает 1 страницу, а ее продолжение - 2 страницы, а значит и число просмотров должно было быть поделено соответственно. Но это уже мелочи - если у народа нет интереса к программе, то как счетчики ни накручивай, пользоваться ей все-равно никто не будет. Так что все правильно. |
Автор: | Дмитрий_ВБ [ Понедельник, 02 Май, 2011 20:37 ] |
Заголовок сообщения: | Re: Программы AB_VJAZ и DAL_VJAZ |
Начиная сегодняшнего дня, в связи с тем что обсуждение моих предложений ведется, мягко говоря, крайне вяло, все обновления и предложения будут выкладываться в сообщении от 3 апреля без дополнителльных уведомлений. |
Автор: | Владимир Паронджанов [ Понедельник, 02 Май, 2011 21:15 ] |
Заголовок сообщения: | Re: Программы AB_VJAZ и DAL_VJAZ |
Дмитрий_ВБ писал(а): Начиная сегодняшнего дня, в связи с тем что обсуждение моих предложений ведется, мягко говоря, крайне вяло, Уважаемый Дмитрий_ВБ!все обновления и предложения будут выкладываться в сообщении от 3 апреля без дополнительных уведомлений. Большая просьба. Каждое обновление и предложение выкладывайте в отдельном новом сообщении. Спасибо. Было бы очень хорошо, если бы Вы подробно объясняли, какое именно УЛУЧШЕНИЕ дает каждое обновление и предложение. |
Автор: | Дмитрий_ВБ [ Вторник, 03 Май, 2011 08:50 ] |
Заголовок сообщения: | Re: Программы AB_VJAZ и DAL_VJAZ |
Ответ на пост Владимира Даниеловича по поводу улучшений, которые дают мои предложения: 1) Использование, наряду с обычным, и минимизированного представления визуальной схемы - это дает возможность более компактного представления визуальной схемы на экране. Предложение Владимира Даниеловича насчет обязательного использования принтера формата как минимум А3, как я понял, не вызвало большого энтузиазма у посетителей форума. Одно дело - технология работы в закрытом почтовом ящике и совсем другое - работа программистов на гражданке. То, что в закрытой конторе спущено сверху и обязательно к исполнению, на гражданке принимается (или не принимается) людьми добровольно. Весомым аргументом могло бы стать резкое повышение производительности труда программистов. Но, согласно отзывам участников форума, способ ввода визуальной схемы, реализованный в и.с.Дракон, этой цели не достигает. Поэтому: 2) Структурно-текстовый интерфейс ввода визуальной схемы - по поводу него только Драконограф сделал несколько замечаний на начальном этапе обсуждения, а после того, как была выложена программа dal_vjaz - вообще не одного комментария в этой теме, прямо связанного с этим вопросом не было. 3) Формат файлов данных должен быть доступен для редактирования - в обсуждении принял участие только Драконограф 4) Возможность ввода визуальной схемы несколькими способами (в теме "Замечания Алексея Донского") - ответил только Драконограф. Алексей на просьбу сказать, что он думает по пунктам 2 и 4 от обсуждения уклонился. 5) Предложение от 2 мая, помещенное в посте от 3 апреля в файле files.txt - уточнение внутренних форматов файлов программы и предложения по отображению обработки ошибок в визуальной схеме. |
Автор: | Alexey_Donskoy [ Вторник, 03 Май, 2011 09:38 ] |
Заголовок сообщения: | Re: Программы AB_VJAZ и DAL_VJAZ |
Дмитрий_ВБ писал(а): 1) Использование, наряду с обычным, и минимизированного представления визуальной Обязательно. Ещё лучше почитать Раскина про масштабирование.схемы - это дает возможность более компактного представления визуальной схемы на экране. Цитата: 4) Возможность ввода визуальной схемы несколькими способами (в теме "Замечания Как-то чересчур остро воспринимаете!Алексея Донского") - ответил только Драконограф. Алексей на просьбу сказать, что он думает по пунктам 2 и 4 от обсуждения уклонился. По п.2 ничего не скажу, надо изучить и пробовать, а банально некогда. По п.4 скажу - обязательно! В конце концов, рассматривая скульптуру в музее, мы можем заглянуть с разных сторон. И здесь тоже нецелесообразно одним представлением ограничиваться. |
Автор: | Дмитрий_ВБ [ Вторник, 03 Май, 2011 09:47 ] |
Заголовок сообщения: | Re: Программы AB_VJAZ и DAL_VJAZ |
Спасибо за ответ, Алексей. Возможно, я немного погорячился с фразой, что Вы уклонились от ответа - извиняюсь. В любом случае, нынешнее положение вещей нуждается в обсуждении и в новых идеях - я также как и Вы думаю, что консервирование нынешнего уровня и.с.Дракон при отсутствии конкурирующих графических редакторов для языка ДРАКОН до добра не доведет. |
Автор: | Alexey_Donskoy [ Вторник, 03 Май, 2011 10:15 ] |
Заголовок сообщения: | Re: Программы AB_VJAZ и DAL_VJAZ |
Дмитрий_ВБ писал(а): В любом случае, нынешнее положение вещей нуждается в обсуждении и в новых Донесите эту мысль до Паронджанова! идеях - я также как и Вы думаю, что консервирование нынешнего уровня и.с.Дракон при отсутствии конкурирующих графических редакторов для языка ДРАКОН до добра не доведет. Ваше мнение будет более весомо, потому что Вы хоть что-то делаете, а я только рассуждаю... |
Автор: | Дмитрий_ВБ [ Среда, 04 Май, 2011 11:19 ] |
Заголовок сообщения: | Re: Программы AB_VJAZ и DAL_VJAZ |
Тут ведь вопрос еще и в том, что Владимир Даниелович - теоретик, а реализацией занялся Геннадий Николаевич. Что я могу сказать ? Мне не нравится содержимое файла ReadWrite1wire.c, выложенного Геннадием Николаевичем в теме "тестирование ИС Дракон", потому что нужно было бы генерировать структурированный код с минимальным использованием goto (это сейчас является общепринятым стандартом в программировании), а если goto и использовать - то только для обработки ошибок, потому что ошибки - это по своей сути вещь хаотическая и разрушающая любую структуру (см. пример структуры процедуры генерации ветки силуэта в файле files.txt, сообщение этой темы от 3 апреля). Хотя и при обработке ошибок без goto можно обойтись - вместо него ставим возврат из процедуры, а ошибку обрабатываем уже в процедуре верхнего уровня. Свое видение визуальной среды я изложил в файлах dalvjaz.pdf и files.txt. Появится свободное время - займусь дальнейшим развитием программы dal_vjaz. Хотя код программы открыт и энтузиасты, если такие найдутся, могли бы пока подумать над выводом полной формы отображения визуальной схемы, с надписями, а не сокращениями внутри блоков . Если энтузиасты все-таки отыщутся, то в окне "About" можно было бы написать: ДРУЖЕЛЮБНЫЙ АЛГОРИТМИЧЕСКИЙ ВИЗУАЛЬНЫЙ ЯЗЫК (подмножество языка ДРАКОН) Бесплатное ПО с открытым кодом (freeware) (с) сообщество forum.oberoncore.ru |
Автор: | efanov [ Среда, 04 Май, 2011 22:52 ] |
Заголовок сообщения: | Re: Программы AB_VJAZ и DAL_VJAZ |
Покольку я интенсивно использую ИС Дракон при разработке и сопровждении микропроцессорных устройств, и очень полюбил этот инструмент, то хочу высказать несколько своих, чисто практических замечаний. Цитата: Предложение Владимира Даниеловича насчет обязательного использования принтера Поначалу пробовал печатать дракон -схемы на бумаге. Использовал принтер А4, ножницы и клей. Получались вполне симпатичные плакаты из 6 - 8 листов A4. Но потратив 10 минут на изготовление этого плаката, и посмотрев на него пару минут, продолжаешь работу, и еще через 5 минут плакат уже не соответствует реальности... В общем, сейчас обхожусь без твёрдых копий.формата как минимум А3, как я понял, не вызвало большого энтузиазма у посетителей форума. Одно дело - технология работы в закрытом почтовом ящике и совсем другое - работа программистов на гражданке. То, что в закрытой конторе спущено сверху и обязательно к исполнению, на гражданке принимается (или не принимается) людьми добровольно. Цитата: Весомым аргументом могло бы стать резкое повышение производительности труда Это неверно. В форуме неоднократно приводились примеры достижения этой цели.программистов. Но, согласно отзывам участников форума, способ ввода визуальной схемы, реализованный в и.с.Дракон, этой цели не достигает. На основе своего опыта утверждаю: - производительность труда существенно повышается. Да и сам труд меняется. Это даже трудно передать словами - это иное качество труда. Цитата: Что я могу сказать ? Мне не нравится содержимое файла ReadWrite1wire.c, выложенного В окне "ИС Дракон" я вижу алгоритм работы программы гораздо лучше, чем в любом тексте, сформированном по всем "общепринятым стандартам в программировании". Геннадием Николаевичем в теме "тестирование ИС Дракон", потому что нужно было бы генерировать структурированный код с минимальным использованием goto (это сейчас является общепринятым стандартом в программировании), И меня совершенно не смущает, что потом, где то, в автоматически сгенерированном коде, щедро используются goto. Точно так же, как меня не беспокоят переходы в сгенерированном компилятором машинном коде. Зато мне очень нравится, что сгенерированный текст программы очень ПРОСТОЙ. Я использую прото-ОС, и в совокупности простой текст и простая ОС дают минимум побочных эффектов, и максимум надёжности. Кстати, этот текст великолепно оптимизируется компилятором, и я ни разу не заметил никаких проблем при использовании максимальной степени оптимизации. В результате, память моих микропроцессоров используется более эффективно. В целом применение Дракона приблизило меня к моей давней цели: довести в своих устройствах надёжность программы до надёжности "железа". Ефанов Сергей. |
Автор: | Дмитрий_ВБ [ Среда, 04 Май, 2011 23:37 ] |
Заголовок сообщения: | Re: Программы AB_VJAZ и DAL_VJAZ |
Спасибо, Сергей, что Вы поделились своим опытом использования ИС Дракон. Ничего не имею против того, что ИС Дракон реально помогает Вам в вашей работе. Вопрос в другом. Недавно Владимир Даниелович поставил вопрос о том, что надо начать преподавать язык ДРАКОН студентам в ВУЗах с использованием ИС Дракон для обучения студентов программированию. В связи с этим возник вопрос о существующих на текущий момент недостатках ИС Дракон, которые должны быть преодолены, чтобы язык ДРАКОН мог получить более широкое распространение. Тема достаточна спорная и неудивительно, что Вы несогласны с некоторыми моими замечаниями. Эти вопросы нуждаются в дальнейшем обсуждении. |
Автор: | Владислав Жаринов [ Пятница, 06 Май, 2011 10:23 ] |
Заголовок сообщения: | Re: Программы AB_VJAZ и DAL_VJAZ |
Дмитрий_ВБ писал(а): ... Главное, я думаю, - визуализировать прогязык, применяемый в обучении, целиком (а не только импер-часть, для чего и предназначен ДРАКОН) - и уже эту визуализацию применять в обучении. При этом и в импер-части фактически нужно провести точную и целостную гибридизацию ДРАКОНа с импер-синтаксисом прогязыка - а не приближённую "на общий/средний случай" . И в связи с выбором языка для этого встают некоторые вопросы.Вопрос в другом. Недавно Владимир Даниелович поставил вопрос о том, что надо начать преподавать язык ДРАКОН студентам в ВУЗах с использованием ИС Дракон для обучения студентов программированию. ... Эти вопросы нуждаются в дальнейшем обсуждении. Дмитрий_ВБ писал(а): ...нужно было бы Вот именно И нужно отметить в свете этой цитаты:генерировать структурированный код с минимальным использованием goto (это сейчас является общепринятым стандартом в программировании), а если goto и использовать - то только для обработки ошибок, потому что ошибки - это по своей сути вещь хаотическая и разрушающая любую структуру... efanov писал(а): ...И меня совершенно не смущает, что потом, где то, в автоматически сгенерированном коде, щедро используются goto. Точно так же, как меня не беспокоят переходы в сгенерированном компилятором машинном коде. - есть разница между исхтекстом и машкодом. Если язык исхтекста допускает явные БП - то их присутствие вопрос лишь стиля сочинителя. Если не допускает - нужно обходиться без них. У Сергея, видимо, первый случай - на это же рассчитана и Ты-среда. Для второго - нужно вводить альтернативу силуэтной разметке нелинейного тела алгоритма - без явных БП, но также обладающую свойствами "универсальной программы". Пока вижу в этой роли цикл Дейкстры - но м.б. кто-то из владеющих теорией ещё что-то предложит (а то ЦД тут многим не нравится )? Дмитрий_ВБ писал(а): ... Это примерно как описано здесь для исключений? Тоже вопрос дискуссионный - см. здесь и здесь. Вероятно, тоже нужно определение исключения, учитывающее общую теорию и её реализацию в конкретном языке,Хотя и при обработке ошибок без goto можно обойтись - вместо него ставим возврат из процедуры, а ошибку обрабатываем уже в процедуре верхнего уровня. efanov писал(а): На основе своего опыта утверждаю: - производительность труда существенно повышается. Да и сам труд меняется. Это даже трудно передать словами - это иное качество труда. Конечно, она будет повышаться, если с графовой формой структуры человеку работать удобнее, чем с представленной ключевыми словами языка текстовой формы. Но дальше уже возникает вопрос о представлении задачи для разных участников создания решения (и сопровождения/развития его, между прочим) - см. хотя бы сказанное в этом посте и связанных с ним.Дмитрий_ВБ писал(а): Спасибо, Сергей, что Вы поделились своим опытом использования ИС Дракон. Ничего не имею против того, что ИС Дракон реально помогает Вам в вашей работе. Среду поддержки такого языка нужно ещё писать... но сначала с поставленными вопросами бы определиться... |
Автор: | Владислав Жаринов [ Суббота, 07 Май, 2011 11:03 ] |
Заголовок сообщения: | Re: Программы AB_VJAZ и DAL_VJAZ |
Дмитрий_ВБ писал(а): ... Выкладывавшиеся в дальнейшем кадры интерфейса показывали, что его эволюция идёт в целесобразном, на мой взгляд, направлении... поэтому глубже не вникал. Теперь посмотрел "отчёт" - вполне достойная спецификация инфопрога... так что подтверждается В частности, представление физических координат и логической разметки схемы, систематизация величин редактора и правил построения.2) Структурно-текстовый интерфейс ввода визуальной схемы - по поводу него только Драконограф сделал несколько замечаний на начальном этапе обсуждения, ... Только некоторые вопросы: Дмитрий_ВБ в download/file.php?id=2355 писал(а): ... С переходом к визуализации импер-части языка без явных БП возникнут вопросы представления, обсуждавшиеся, в частности, в этом сообщении (и связанных с ним).Рассматриваемый алгоритм построения визуальной схемы читатель сможет, если захочет, без особых затруднений перенести на любой другой из объектно-ориентированных или процедурных ЯПВУ. ...
Дмитрий_ВБ в download/file.php?id=2355 писал(а): ... Отказ от брейков - это хорошо... так сказать, шаг к согласованию с тем же КП А от континуев также?В программе dal_vjaz идея о запрете на пересечение линий визуальной схемы, а также идея о структурном текстовом представлении визуальной схемы реализованы с приложением сравнительно небольших усилий за счет отказа от досрочных выходов из циклов и запрета на непосредственное редактирование визуальной схемы пользователем. ... Т.е. правим только текстовую структуру схемы? Дмитрий_ВБ в download/file.php?id=2355 писал(а): ... Вообще-то это не точка пересечения... она логически м.б. разложена на цепочку "соединитель-разветвитель", как показано здесь... а в лиоформе (на "визуальном ассемблере") - на систему БП, как показано здесь. Видно, кстати, что и петлю силуэта можно расположить так, чтобы она и зрительно не пересекала шампура... и ветки упорядочить по вертикали... это тоже к вопросу о множественности изображений схемы.2) С целью улучшения читаемости визуальных схем алгоритмов В.Д. Паронджанов постулировал запрет на пересечение линий визуальной схемы (единственное исключение – точка пересечения обратной петли силуэта с главной вертикалью визуальной схемы), ... Дмитрий_ВБ в download/file.php?id=2355 писал(а): ... Вообще-то исхкодом элемента д.б. оператор языка схемы (для действия - м.б. ряд операторов, если в тексте вершины допускается операторный разделитель). Но это тесно связано с предопределением языка схемы как конкретного инфор-языка или его составляющей - и редактированием именно схемы.Наводя указатель мыши на элементы визуальной схемы пользователь может во всплывающем окне элемента прочитать информацию об исходном коде и (или) комментарии этого элемента. ... "Или" неплохо реализовать как графит-примечание... но это, вероятно, объёмный код. Дмитрий_ВБ в download/file.php?id=2355 писал(а): ... Прежде всего для этого нужна поддержка процедур (виоп Вставка) - чтоб было откуда ссылаться в импер-части. Ну и в перспективе - операторов структуризации программы конкретного языка (скажем, в КП - MODULE - визуализируемого как схема ПК-языка) - которые уже относятся к обобщённой части содержания программы.3) Нет реализации ссылки одной схемы на другую. ... Дмитрий_ВБ в download/file.php?id=2355 писал(а): ... Прежде всего - возможность сборочно-конкретизирующего представления описаний - скажем, через механизм Область. Есть ведь и языки без процедур... для которых и наличие вставки не поможет "параметризовать" описания...Возможно я и забыл перечислить что-нибудь, но эти четыре пункта можно считать необходимыми требованиями по дальнейшему развитию программы dal_vjaz. ... Ну и комплексное визуально-структурное документирование на базе лист-силуэтов (см. там же, а также в этом пункте). Кстати, ЛС - ещё одна форма изображения силуэта. Меня ведь средство визуализации интересует с позиции "предметника" - т.е. как построитель комплексного описания задачи/предметки. Вот когда среда позволит оформить в ней весь документ, подобный Вашему (и управлять совокупностью таких документов в плане шаблонов, каталогизации, сборки из фрагментов) - можно говорить о результате в этом смысле. |
Страница 2 из 6 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |