DRAKON.SU

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

Так о чём я и говорю! Вложенность и показана явно на моих набросках... Если чуть изменить соответствующие иконы, то можно выделить и более аккуратно...

Графическое структурирование = вложенность, без сомнения...

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

Уважаемый Рэйлвэй Каген!
1. Использование BREAK показано на стр. 178, пример 3 книги "Как улучшить работу ума"
2. Ожидание можно выполнить с помощью цикла "Ждать" (см. там же, рис. 84, 85 и сопутствующий текст).

Если я ответил не по теме, поправьте меня.

Вот так, наверное..

То же, только покрупнее, в пдф-нике:
Всё-таки мы не должны повторять конструкции целевого языка, а должны рисовать то, что потом можно будет описать этими самыми конструкциями(try-finally-except).
В таком виде явно контролируется вложенность и сразу будут заметны злоупотребления типа "попрограммировать на ситуациях".

Я про другой BREAK - который для выхода из цикла до его завершения.
Речь о том, что бывает "ситуацию" явно никто не ждет по маршруту алгоритма. Сафонов (с.65) см.п.2. динамические ситуации. Поэтому делать циклом "Ждать" - нецелесообразно.

Ну, давайте рассуждать логически...

1) Ситуация имеет алгоритм обработки? Да. Значит, просто рисовать прямоугольник вставки и описывать алгоритм в другом месте неправильно (неэргономично).

2) Раз ситуацию никто не ждёт, значит, алгоритм её обработки должен иметь отдельное начало, висящее "в воздухе". Никуда от этой дополнительной точки входа не денешься.

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

4) Обработчик ситуации имеет алгоритмическую привязку в точках инициализации и удаления обработчика. Эти точки и определяют область действия обработчика ситуации (не самой ситуации! чтобы не было путаницы в терминах!).

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

Кроме того, целесообразно иметь видимую область действия обработчика (тот самый выделенный прямоугольник, привязанный к шапке). Любой выход из области действия означает удаление обработчика (end).

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

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

Дык, речь ведь о не только о том, как наверх... Речь о том, как описать на Драконе приём этого сообщения.

2 Alexey_Donskoy:
1. Зачем в другом месте? Пусть алгоритм обработчика рисуется/открывается прямо в области. Как в фотошопе - по слоям.. До RationalRose с его сонмищем закладок, надеюсь, не дойдёт..
2. Соответственно и "висяка" не будет
3. Ежели вызвали, как "вставку", тогда и вернёмся в правильное место - после вызова. Можно вызвать как "действие", тогда возвращаться придётся в наружную процедуру и т.д. до перехвата на более высоком уровне(по классической модели).
4. Конструктор ситуаций пока рано лепить. Он наверняка появится - средствами автоматической трансляции, но сейчас нарисовать бы корректно все связи.

Отрисовываться с использованием силуэта по try-finally-except слишком узко. Только статические сиуации попадают в эту категорию отображения.

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

Вот этого не понял... Что значит "статические"? И в каких ("динамических"?) случаях этого недостаточно?

Область действия? Есть.
Точки входа? Есть.
Алгоритм? Есть.
Точки выхода? Есть (то есть в силуэте нет, а в иконе "Исключение" сделать придётся )

В иконах "<Операторы>" не операторы на языке Delphi, а фрагменты алгоритма на ДРАКОНе.
Здесь был разговор о различного рода добавлениях, но думаю правильнее следовать авторскому ДРАКОНУ.

Почти убедили

Только что такая форма по существу ничем не отличается от текстовой и не использует графические преимущества Дракона... Например, очень было бы полезно хотя бы графически выделить область действия исключения (от try до end).

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

Ну и раскрашивание икон, кстати, тоже было бы очень полезной опцией!

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

значит, что "условия возникновения ситуации предусмотрены программистом"(Сафонов)
"Статическая ситуация - это константа, значением которой является метка перехода. Динамическая ситуация - это объект скрытого типа."(Пентковский).
Тут я ошибся, сказав, что try-except-finally подходит только для статики.
Нерассмотренным остается вопрос с прерыванием, поскольку это ситуация динамическая по характеру связи места возникновения с местом обработки. Как отобразить ситуацию прерывания от периферии? Отражающую правильный маршрут выполнения алгоритма, в отличие от стандартных прерываний, сигнализирующих об ошибке? try-except-finally не подходит идеологически.

p.s.:Учитывая приведённые выше определения ситуаций, разумно рассмотривать их как декларативные сущности. А раз так, то напрямую в Драконе они отображаться не должны. Тогда имеем право отрисовать обработчик как метод типа/класса(отдельно на том же листе, на отдельном листе, слое и т.п.), т.е. всё-таки не включая его в основной алгоритм. Точка входа - в выделенной области алгоритма. Возражения??

Согласен, я выразился некорректно. Прошу прощения.


Я, собственного говря, имел в виду то, что отсутствует удобная возможность отобразить на одной диаграмме несколько выполняемых параллельно алгоритмических веток - чего-то вроде "порождения разветвления потока управления" и "слияния потоков управления" типа тех, что есть в диаграмме деятельностей UML 2.0.

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

Заранее благодарен за ответ.

Уважаемый TAU!

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

Таким образом, возникает ситуация: С ТОЧКИ ЗРЕНИЯ МАТЕМАТИКИ --ХОРОШО. А С ТОЧКИ ЗРЕНИЯ НАГЛЯДНОСТИ -- ПЛОХО!

Выход из положения я вижу в следующем. Я изложу свою позицию на "родном" для меня примере технологии ГРАФИТ-ФЛОКС.
http://wiki.oberoncore.ru/index.php/%D0 ... 0%BE%D0%BD

В этой технологии два редактора:
процедурный графит-редактор;
декларативный флокс-редактор.

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

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

Эта ТРЕТЬЯ (математически строгая) картинка дает возможность наглядно увидеть глазами взаимодействие параллельных процессов между собой и с другими логическими сигналами.

Надо сказать, что это была не просто мечта. В нашем коллективе было полное единство взглядов относительно целесообразности создания редактора циклограмм. Меня даже попросили написать техническое задание на разработку такого редактора, что я и сделал.
Увы! В жизни удается реализовать не все, что было задумано. У программистов вклинилась какая-то свехсрочная работа. И редактор циклограмм был временно отложен. Сначала временно... а потом и навсегда. В общем, то, о чем я рассказал, НЕ БЫЛО РЕАЛИЗОВАНО НА ПРАКТИКЕ.

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

Впрочем, кто знает! Может быть, когда-нибудь найдется энтузиаст, который дополнит редактор Геннадия Тышова редактором циклограмм.

Постскриптум. На всякий случай подчеркну, что алгоритм и циклограмма -- это два разных чертежа, которые распечатываются на двух разных листах бумаги.
Алгоритм и циклограмма никогда не совмещаются на одном чертеже. Это РАЗНЫЕ картинки. Они не накладываются друг на друга.

Уважаемый Владимир Даниелович! Думаю, Вы догадываетесь, кто я такой
В конце концов, и попал я на этот форум по ссылке из Вашего письма.
Так вот: редактор циклограмм был нами создан. И достаточно давно.
К сожалению, с его практическим использованием на предприятии все обстоит тоже не столь радужно.
Но это - совершенно отдельная тема, собственно, слабо связанная с его целесообразностью.


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

А подробнее?

Геннадий, можно. Но не очень наглядно.

Первая картинка - визуальный конструктор "временных диаграмм", отражающих логико-временную схему алгоритма.

Вторая картинка - графический редактор циклограмм.