OberonCore

Да, конечно, традиционная структура документа - как иерархически нумерованных докэлементов - не просто так и она будет актуальна. Схематически её можно поддержать, скажем, вьюшкой по такому принципу, как говорилось здесь: viewtopic.php?p=64343#p64343. Разбираться должно помочь... да и в реализации те же силуэты, только положенные набок...

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

Возможно, это даст что-то: http://www.rsdn.ru/forum/philosophy/483 ... ?tree=tree (ну и некоторые связанные посты там же).

Возможно, упрощению послужит поддержка каталога [макро]операторов, формируемого сочинителем. С параметризацией по именам (как у Лаптева). Собственно, в граф-записи аналогичным механизмом является Область - но чисто текстовый, вероятно, для начала будет проще реализовать (возни с компоновкой меньше).

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

Да, вот ещё.
Что это за переходы и почему они нужны?

"Что это за переходы и почему они нужны?"

Для попадания в следующую по порядку ветку в следующем проходе цикла-силуэта

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

Кстати, она актуальна и при эскизном описании процессов - достаточно посмотреть на эту задачу: viewtopic.php?p=66824#p66824. И тут видно, что надо решать вопрос с индексацией элементов схемы в аспекте, обсуждавшемся здесь: viewtopic.php?p=72208#p72208.
... и тогда уж реализовать и то, что называю "графит-примечаниями" и что Сергей определял здесь: viewtopic.php?p=57545#p57545.
Т.е. каждой структурной скобке (заменяющей ключевые слова-указатели маршрутов) соответствует комментарий - как и каждому оператору. При "своей" скобке он и отображается. Интендация текста заменяется вложенностью скобок; текст располагается одномерно - в колонку строк. Это формат вьюшки исхтекста совместно с комментариями (в отличие от вида только исхтекста как "схемы со снятой графикой", где и скобки двумерны, и каждой оси порядка - своя колонка).
Такие "атомарно-релятивные" комменты - прежде всего для утверждений о конструкциях, ограниченных скобками. Ну и для просто записей, включая ссылки на разные места в документах среды и во внешних. Для начала (дабы не усложнять реализацию) внутри среды ссылки - на те самые индексы, вовне - как уже говорил, на закладки в каком-то кроссплатформенном формате.

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

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

Структурные скобки можно изображать как графикой, так и псевдографикой (ASCII-символами для таблиц и чем-то для обозначения стрелки). Второе - для облегчённой реализации среды.

Вот такую вьюшку хотелось бы видеть...

Таблица-силуэт с горизонтальной раскладной действий для языка ДАЛВЯЗ 2

(пока не реализовано, выкладываю как материал для обсуждения)

Логика работы остается той же:
- во главе угла ЛСП (логическая структура процедуры), набор действий
которой (подробнее см. тему "AB_VJAZ и DAL_VJAZ") опирается на постулат
структурного программирования:

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

1) простое действие (присваивание, вызов процедуры);
2) ветвление (сложное условие);
3) цикл.

При горизонтальной раскладке действий действия выполняются
слева направо, ветка ДА условия уходит вправо, а ветка НЕТ - вверх.
Т.е. условие горизонтальной раскладки - это повернутое на 90 градусов
против часовой стрелки условие вертикальной раскладки, для которого
ДА - вниз, НЕТ - вправо. Для условия цикла ветка ДА означает окончание
цикла.

Базовые элементы ЛСП для горизонтальной раскладки выглядят
следующим образом:

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

Если веток много, используем таблицу-силуэт.
При этом для блоков Начало, Цикл-Силуэт, Условие Цикла-Силуэта и Конец
будем использовать вертикальную раскладку.

Параллельные действия для горизонтальной раскладки

1) Алгоритм запуска параллельных действий, который может быть
преобразован в исходный код

2) Нестрогое описание параллельных действий с помощью таблицы-силуэта

Интересно. Видимо, нестрогое описание параллелизма нужно оценить с позиций - можно ли по нему выявить проблемы, представленные здесь?.. Строгое, впрочем, тоже...

Вот, кстати, пример на то, что имел в виду: - в том смысле, что если сочинитель делает "последовательный алгоритм" по Закревскому из работ, которые м.б. переупорядочены, то у него всё равно никуда не девается необходимость координации. И в результате такой алгоритм превращается в "эвроритм". А АРМ, получается, используется в роли доски у диспетчера... тогда как могло бы "поддерживать принятие решений"...

Вы вроде как хотите описать принципы координации, если я верно понял. Чтобы переложить на среду (точнее, на записанный в ДАЛВЯЗ-проекте код) функции выбора работ к активации/откладыванию/снятию. Ну, понятно, в ограничениях теории расписаний, как популярно у Потопахина: viewtopic.php?p=78120#p78120.
Но штука в том, что если сочинитель и опишет все правила запуска хоть и в виде текста предлагаемых схем, ему это всё равно не поможет "развернуть в бизнес-процессы" сколь-нибудь развитые структуры "вопросов, находящихся на различных этапах решения, перемещаемых по мере прохождения этапов"... И вот хотелось бы от среды на этом коде:

* проявления "неявного поведения/зависимостей, которое в реальном коде образуется немыслимыми сочетаниями сценариев";
* учёта вещей вроде описанных тут: viewtopic.php?p=74833#p74833.

Конечно, это м.б. сделано по-разному. В частности, ограничиваясь тем, что реализуется в ДАЛВЯЗ, можно просто экспортировать код для внешнего анализа вроде такого: viewtopic.php?p=74705#p74705 и импортировать обратно.

Кстати, "рисунки из книги" тоже в тему... ибо взаимодействие м.б. организовано как раз через рандеву...

Не, Владислав, у меня все гораздо проще.

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

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

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

Т.к. ЛСП является логическим инвариантом, то для нее имеются 3 формы отображения (см. рис.):
- линейная вертикальная раскладка;
- линейная горизонтальная раскладка;
- вертиально-горизонтальная раскладка.


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

1) требование запрета пересечения линий схемы;
2) меры по пространственному структурированию схемы;
3) движение в сторону горизонтальной раскладки схемы
(пп. 2 и 3 - путем введения визуально-логической конструкции "силуэт")

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

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

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

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

В качестве примера приведу вопросы, поднятые мной в теме "Просто о силуэте", которые
остались без ответа:

"1) какая плотность представления информации на визуальной схеме является
оптимальной ?
под плотностью информации на схеме я имею в виду отношение площади
информационных блоков схемы к площади всего пространства схемы;
(в глаза явно бросается неравномерность распределения информации на схемах языка ДРАКОН,
много пустых мест, перемежающихся с заполненными участками - это не есть хорошо)

2) какая степень детализации алгоритма является оптимальной для визуальной схемы ?

3) должна ли визуальная схема по высоте обязательно целиком помещаться в окне просмотра ?"

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

3. Консервация в языке ДРАКОН представлений о программировании на уровне микроконтроллеров.
- не поддерживается модульность.
- не поддерживаются ссылки из схемы на структуры (типы) данных и объекты данных
- не поддерживаются ссылки на внешние файлы документации (например, htm-файлы)

4. Неявно заложенная в языке ДРАКОН и весьма спорная идея о том, что никак не украшенная
техническая схема, которой в сущности и является схема языка ДРАКОН, будет привлекательна не
только для технических специалистов, но и для гуманитариев (см. замечания VOT7)

5. Формы блоков схемы были выбраны волевым решением автора языка, и некоторые из них
не являются оптимальными, например из замечаний на формуме:
- "гробики" условий;
- блок комментария лучше смотрится в UML

Вроде это все основные замечания по визуальным вопросам.

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

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

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

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

На сайте videoecology.com в разделе
Книги и фильм
Видеоэкология
Текст - введение, заключение, содержание
читаем:
"Актуальность проблемы видеоэкологии еще и в том, что наука
до сих пор не разработала нормативные документы по формированию
визуальной среды, нет требований по допустимым отклонениям,
в частности по допустимым размерам гомогенных и агрессивных полей".
На мой взгляд мнение доктора биологических наук Василия Антоновича Филина - это достаточно
авторитетный источник.

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

Мои предложения уже во многом сформулированы в описании алгоритмического языка ДАЛВЯЗ 2
и вкратце сводятся к следующему:
- в качестве логической основы: постулат структурного программирования (просто и проверено
временем) плюс логика цикла-силуэта для обработки сложных логических переходов;
- в качестве визуальной основы: схема с запретом на пересечение линий и пространственной
структурой, задаваемой визуально-логической конструцией силуэт (таблица-силуэт)
- у пользователя должна быть возможность выбирать раскладку схемы (подробнее см. в моем
сообщении выше):
линейная горизонтальная, линейная вертикальная или вертикально-горизонтальная;
- в качестве формата данных: текстовый файл, содержащий исходный код (или псевдокод),
для которого будет отображаться схема; исходный код содержит не только процедуры, но и
описание данных проекта; исходный код разбивается на записи, котрые могут ссылаться
друг на друга, на исхдный код других модулей проекта и на внешние htm-файлы документации;
- должна быть предусмотрена возможность вставки в блоки схемы как поясняющих значков,
так и полноценных изображений;
- пользователь должен иметь простую возможность задания цветового оформления схемы
и выбора используемых в ней шрифтов путем редактирования файлов стилей схемы.

Вот как с моей точки зрения выглядят МИНИМАЛЬНЫЕ требования к универсальному средству
алгоритмизации.

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

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

Дракон одновременно и понятен им, и структурирует их "неформатированное математикой" мышление. Чёткие и понятные "это нельзя, а нужно вот так", исключающие разгул неупорядоченной фантазии гуманитария, начавшего рисовать

Аргумент "нужны красивости, достаточно ли гуманитариям строгих схем" - не согласен. Привычки "клипового" мышления нужно ограничивать, а не потакать им.

Аргумент "но и новичков, для которых главное - сделать побыстрее и чтобы сразу заработало." - тоже не согласен. Я такого рода аргумент всегда называю "Бейсик-аргументом". Именно из-за этого ошибочного мнения (потакания желанию новичка пару раз "тык-мыкнуть", не думая и не вникая, и чтобы был результат) создавались Бейсик-подобные языки и ошибочно они считаются "хорошими для начинающих", хотя, на самом деле, намертво тормозят развитие их ума в правильном направлении...

Даже если в основе такого "новоявленного Бейсика" будет лежать алгоритмическая логика КП
(а если брать текстовый формат - то и сам КП) ?
Ну а графические висюльки - когда ребенок взрослеет, он отказывается от погремушек.

Смотря что Вы вкладывали в "побыстрее бы заработало".
Последнее Ваше высказывание ясности не добавляет....
Что именно Вы считаете препятствием для новичком на пути к "побыстрее бы заработало"?

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

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

Понял Ваши мысли.

По поводу ДРАКОНа и его связи с развитием визуальных средств в целом, я придерживаюсь мнения о "локальном оптимуме". Т.е. усовершенствованиям он не поддаётся, он хорошо "отточен" в конкретном, локально хорошем соотношении - туда-сюда в нём и подвигать особо нечего...

А новые средства хотелось бы проектировать не только из требований когнитивной эргономики, но и исходя из общего понимания проектирования... На какую тему всегда сворачивает Алексей Донской: как мне зафиксировать всю последовательность поиска окончательного решения?

Схемы данных в ДАЛВЯЗ 2

В общем случае дерево описания программы в ДАЛВЯЗ 2 выглядит так:

программа такая-то
...
n. модуль такой-то
...
n.m. запись такая-то, это либо текстовая запись,
либо схема действий,
либо схема данных.

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

Рассмотрим простой пример из Википедии

JSON — Википедия.htm :
"JSON (англ. JavaScript Object Notation) — текстовый формат обмена данными,
основанный на JavaScript

По аналогии с приведенными примерами для JSON и XML видно, что
в псевдокоде условие задает имя поля структуры, а действие
задает значение для этого поля.

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

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