Не как обязательно для автора - он делает интересные вещи - просто в качестве развития:
> -- Дмитрий_ВБ писал(а):
> Краткий перечень наиболее важных ошибок:'Нет ЕС для ИЕ' - нет ЕСЛИ для ИНАЧЕ ЕСЛИ;'Нет ЕС для ИН' - нет ЕСЛИ для ИНАЧЕ;'Нет ЕС для К' - нет ЕСЛИ для конца блока ЕСЛИ;...Ну, сокращения, наверное, неэргономичны...

А вообще перечисленные ошибки объединяет ситуация - они возникают как следствие нарушения принципов: вложения составных операторов как одноимённых атомов; добавления/удаления логически целостных частей. Если вкладываем сразу "Развилку" (т.е. ЕСЛИ-ТО-ВСЁ) и прибавляем/вычитаем из неё только ветвями (т.е. <ТО|ИНАЧЕ>-ВСЁ) - такие ошибки не возникают в принципе. И редактор эргономичный для сочинителя должен в итоге это поддерживать.

> -- Дмитрий_ВБ писал(а):
> ...Выяснилось, что для таблицы-силуэта удобно объединять нескольковеток в одну строку при помощи блока ЕСЛИ, например:(*i*)  if (wetka = 1) then begin (*i*)  k := 1; n := 1;     //_>.1 (*i*)  wetka := 2;(*i*)  end else if (wetka = 2) then begin (*i*)  // вход в основной режим (*i*)  wetka := 61;(*i*)  end;Такой прием позволяет легко управлять шириной таблицы-силуэта так,чтобы по ширине она помещалась в экран.Не подгоняем ли логику работы под физику отображения?.. Иля я не так понял?..

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

> -- Дмитрий_ВБ писал(а):
> ...При наведении мышки на блок схемы всплывает окошко, в верхней строке которого в скобках указана строка файла исходного кода, соответствующаяначалу блока, а ниже следует содержание блока. Если в блоке естьгиперссылки (см. dalvjaz.cfg), то во всплывающем окне они будутдоступны, надо только БЫСТРО передвинуть указатель мыши на всплывающееокно, чтобы оно до этого не закрылось. Возврат из внутренней гиперссылки по кнопке "<".Насколько БЫСТРО?..Оно ведь тоже эргономика...
А вообще реализация связности и атрибутов-примечаний - рулез.


> -- Дмитрий_ВБ писал(а):
> ...Предлагается следующая технология работы с таблицей-силуэтом.Предметник на бумаге или его секретарша в графическом редакторе Paintрисует алгоритм, используя предоставленные разработчиком шаблоны -файлы со схемами ранее сгенерированных алгоритмов. Кстати тут уместнодать полезный совет - перед тем, как вводить текст блоков в схему,его нужно сначала набрать в обычном текстовом редакторе, а уже потомпереносить внутрь блоков. Этот же текстовый файл с содержанием блоковсхемы будет затем использован программистом для ввода комментариев кпроцедуре.После получения схемы процедуры программист, пользуясь регулярностью исходного кода таблицы-силуэта, быстренько лепит шаблон процедуры и заполняет его в соответствии с полученным рисунком. Затем на основе полученной процедуры генерится схема и сравнивается с первоисточником.Если расхождений нет, то можно считать, что задача в первом приближениизапрограммирована - теперь нужно отлаживаться.Я считаю, что при внесении достаточно значительных изменений в алгоритмпроще и менее чревато ошибками быстренько повторить весь процесс заново, имея перед глазами схему предыдущего варианта алгоритма.Ну или, если уж лень рисовать, пусть программист внесет нужные изменения в процедуру, сгенерит схему и отнесет заказчику для обсуждения и согласования.Вот как-то так получается.А в итоге (опять же для эргономики взаимодействия в триаде) должно получаться как-то иначе - предметник рисует схемы процессов (размечая их качественными соображениями - варианты иллюстрированы, скажем,этим описанием) прямо в том же редакторе. Чтобы избежать кросс-обработки внешнего рисунка... Ессно, для этого функции рисования д.б. удобны обычному пользователю офисных программ (может, они уже сейчас в ДАЛВЯЗ вполне удобны не знаю - но в любом случае нужна "прозрачная инструкция" предметнику по рисованию).

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

Такой процесс будет чреват ещё меньшими ошибками (во многом из-за меньших трудозатрат и участников - той же секретарши с Пайнтом).

Вот как-то так...