DRAKON.SU :: Просмотр темы - "Ситуации" в Драконе

Большинство людей строит гараж поближе к квартире (про советскую действительность говорю, а то ещё не поймут

).
Уникумы (вроде меня) строят квартиру поближе к гаражу (реальный факт

).

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

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

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

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

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

А как оно было на самом деле?

Автор:	Рэйлвэй Каген [ Вторник, 16 Декабрь, 2008 18:43 ]
Заголовок сообщения:	"Ситуации" в Драконе
Попытался изобразить обработчик ситуации на Драконе. Вот что вышло: Вложение: cl.png [ 8.52 КБ \| Просмотров: 25921 ] Прошу покритиковать.

Автор:	Alexey_Donskoy [ Вторник, 16 Декабрь, 2008 18:51 ]
Заголовок сообщения:	Re: "Ситуации" в Драконе
На первый взгляд - бред какой-то... Во-первых, так и непонятно что это за "ситуация" такая. То ли это процедура (оформлена как процедура), то ли это не просто процедура, а процедура обработки прерывания... С прерываниями вроде бы всё ясно, они, как и процедуры, при выходе возвращают управление туда же, откуда были вызваны (в точку прерывания). Но, глядя на эту картинку, у меня возникает гнусное подозрение, что хотели Вы изобразить исключение (exception). С другой стороны, таки изображённая схема имеет один выход. И ещё что-то непонятное (действие под названием ВЫХОД). Отмазка в том, что редактор Тышова не позволяет сделать два выхода, не катит. Можно было в painbrush подрисовать Во-вторых, непонятно, зачем тут нужно "имя замыкания" и что это за "действия в контексте"... На мой взгляд, существенно то, что исключение не является внешней процедурой! Это по сути тот же самый код в том же самом контексте. Тот факт, что возникновение исключения может происходить где-то глубоко относительно места инициализации обработчика, в другом локальном контексте, ничего не меняет на самом деле! Потому что обработчик исключения обязан последовательно финализировать все вложенные контексты, поднимаясь на исходный уровень. В связи с чем мне решительно непонятно, что это за контекст такой передаётся в замыкании, а, главное, зачем? В-третьих, непонятно, что это за выход по имени вызывающей процедуры. Что, надо снова запустить вызывающую процедуру? Бред! Или Вы хотели показать, что надо, к примеру, регистр BP здесь передавать в качестве указателя на контекст (возникновения прерывания?)? Ну так это дело компилятора... В общем, пока непнятно...

Автор:	Рэйлвэй Каген [ Вторник, 16 Декабрь, 2008 21:35 ]
Заголовок сообщения:	Re: "Ситуации" в Драконе
Alexey_Donskoy писал(а): непонятно что это за "ситуация" такая.. 1. Ничего пока не изменилось. Ситуация - экземпляр определённого типа/класса. На картинке один из его методов - обработчик. Исключения могут быть представлены с помощью ситуаций. Поэтому можно посмотреть на эту ситуацию как на исключение. 2."замыкание" - действия, обычно определяемые в секции EXCEPT. Представим, что у нас нет этой секции и все действия из неё вынесены в локальную процедуру, которую и передаём методу "ситуация.обработчик". Например, это замыкание подставляет принятые по-умолчанию значения в локальные переменные при возникновении ситуации - чтобы не допускать распространения ошибочных данных. "обработчик 2"- действия,определённые для данного типа/класса "ситуация". Без привязки к секциям EXCEPT и локальному контексту защищаемых процедур. Например, отписать чего-нибудь в лог(большой и общий). Или демонтировать устройство при обнаружении его отключения. 3. "вызывающей" - действительно, крайне неудачно использованное мной слово(будем менять). Притягивает внимание к месту, где дёрнули RAISE. На самом деле имеется в виду процедура/функция, в которой выделена область ситуации, охватывающая часть алгоритма. В которой "как бы" определены TRY-EXCEPT-END. 4. второй выход - имеется в виду, что после завершения обработки ситуации необходимо завершить процедуру/функцию, в которой "как бы" определены TRY-EXCEPT-END. Ни [BP], ни [FS]:0 не трогаем - не знает Дракон этого.

Автор:	Alexey_Donskoy [ Вторник, 16 Декабрь, 2008 21:48 ]
Заголовок сообщения:	Re: "Ситуации" в Драконе
Один только вопрос - зачем? Зачем обработчик исключения рассматривать отдельно от всего алгоритма и контекста? Для чего нужна такая искусственная операция? Какой в этом смысл? Когнитивного смысла - нет, т.к. возмещать потерю контекста малыми затратами ещё никто не научился; обработчик должен быть там же, где и вся область видимости... "Технологического", что-ли, смысла - тоже не наблюдается... Одни издержки с передачей параметров...

Автор:	Рэйлвэй Каген [ Вторник, 16 Декабрь, 2008 22:00 ]
Заголовок сообщения:	Re: "Ситуации" в Драконе
Чтобы иметь возможность свернуть/развернуть--посмотреть. И ещё потому, что рисовать, как предлагали Вы(здесь) и Геннадий Тышов(здесь) нельзя. Последнее поясню: Эти варианты по правилам дракона предусматривают выполнение всего защищаемого блока. А на самом деле структурный переход на обработчик может произойти из любого места защищаемого алгоритма. И не факт, что хвост, оставшийся после перехода на обработчик, обязательно должен выполняться. Чтобы отрисовать такое, понадобилось оторвать обработчик от области, притянуть за уши замыкание и нарисовать транзитный выход. Надеюсь, что можно проще, но пока не вижу как..

DRAKON.SU https://forum.drakon.su/

"Ситуации" в Драконе https://forum.drakon.su/viewtopic.php?f=62&t=1282	Страница 1 из 3

Автор:	Valery Solovey [ Среда, 17 Декабрь, 2008 12:44 ]
Заголовок сообщения:	Re: "Ситуации" в Драконе
Мы чаще используем термин "абстракция", а не "иллюзия".

Автор:	Alexey_Donskoy [ Среда, 17 Декабрь, 2008 12:55 ]
Заголовок сообщения:	Re: "Ситуации" в Драконе
Абстракция не всегда бывает иллюзией

Автор:	Рэйлвэй Каген [ Среда, 27 Январь, 2010 21:37 ]
Заголовок сообщения:	Re: "Ситуации" в Драконе
Многие помнят попытку рисования областей на Дракон-схеме. Для удобства напомню картинку: Вложение: doc4.png [ 42.09 КБ \| Просмотров: 25180 ] Дальше можно поступить в духе YAWL - непосредственно пририсовывать к области её обработчик и присоединять к ней же результат обработки(выходной маршрут обработчика) следующим образом: 1)возврат на вх.границу - restart - стрелка, направленная ко входу в область 2)переход на вых.границу - exception, cancel, skip - стрелка, направленная к выходу из области 3)возврат в точку, из которой вышли - interrupt - графически простым маршрутом Но при этом всё равно остаются проблемы: 1.отсутствуют принципы структурирования областей, подобные структурированию маршрутов в силуэте. 2.из-за п.1 на определённом этапе проектирования станет просто неудобно рисовать кучу громадных прямоугольников. 3.как достучаться до внутренней границы вложенной области не пересекая границу внешней области, не запутывая излишне транслятор? Что будет, если поступить с областями, также как и с параллельными процессами - вытянуть их границы и взаимодействие с ними на петлю силуэта? У иконы "Адрес" может быть список, чего бы не добавить такую же штуку к иконе "Ветка". Но для этого нужно разместить список внутри иконы "Ветка"? Было найдено графическое решение, отдалённо напоминающее перчатку хоккейного вратаря. Только "ловушку", вторая перчатка - "блин" совсем не подошла . В результате "Ветка" осталась со своим уникальным именем, а в "ловушку" попал нужный нам список. При этом ничто не мешает применять "Ветку с ловушкой" в контексте параллельных процессов(пример с параллельными процессами и ловушкой можно найти здесь). Вложение: drakon_ext_sit.png [ 46.93 КБ \| Просмотров: 24952 ] Картинку в высоком разрешении можно скачать здесь. Размер 0,5МБ. Такое применение соответствует динамической ситуации. Чтобы использовать статическую(заранее определённую по ходу алгоритма) ситуацию, необходимо обозначить конструктор ситуаций и обеспечить возможность возбуждения ситуаций. Последнее возможно, если присоединить к "Ветке с ловушкой" одноимённый заголовок. Само возбуждение обозначается вставкой с именем ситуации. Конструктор можно найти на картинке. также были разговоры о вложенности областей: вложенность в данном случае определяется порядком выполнения веток, задаваемым алгоритмически на Дракон-схеме. Это соответствует модели распространения ситуации, описанной Сафоновым и Пентковским. Порядковый номер веток в списке(ловушке) ничего не определяет и ни на что не влияет. Важно лишь наличие имени ветки в списке. В качестве бесплатного приложения получаем возможность визуально отделить работу собственно алгоритма от обработки ошибок. Лицензия - свободная: http://creativecommons.org/licenses/by-sa/3.0/ р.s.:К чему всё это? Можно почитать Сафонова и Пентковского. Почти все ответы - у них 08-02-2010: в алгоритме исправлен выход из ветки с ловушкой. 15-02-2010: уточнён синтаксис передачи управления из ловушки

Автор:	Alexey_Donskoy [ Четверг, 28 Январь, 2010 08:49 ]
Заголовок сообщения:	Re: "Ситуации" в Драконе
Рэйлвэй Каген писал(а): Дальше можно поступить в духе YAWL - непосредственно пририсовывать к области её обработчик и присоединять к ней же результат обработки(выходной маршрут обработчика) следующим образом: 1)возврат на вх.границу - restart - стрелка, направленная ко входу в область 2)переход на вых.границу - exception, cancel, skip - стрелка, направленная к выходу из области 3)возврат в точку, из которой вышли - interrupt - графически простым маршрутом Мне такой подход кажется более правильным. Кроме п.3 - прерываний. Потому что в подавляющем большинстве случаев прерывание будет устанавливаться при старте и действовать всегда. Более того, если вдруг понадобиться установить (разрешить) прерывание только на протяжении одного действия, то всё равно это действие может прерываться другим прерыванием, которое, в свою очередь, может быть прервано рассматриваемым прерыванием... Ну, в общем, основной смысл здесь в том, что прерывание не имеет чётко очерченной области действия. А исключение - вроде бы имеет (хотя я никогда не исследовал, как ведёт себя механизм исключений в прерываниях ). По логике всё-таки должна быть обеспечена область действия исключения только в том месте алгоритма, где оно включается... Рэйлвэй Каген писал(а): В качестве бесплатного приложения получаем возможность визуально отделить работу собственно алгоритма от обработки ошибок. На мой взгляд, это большой минус, который вводит дополнительные неявные связи между элементами алгоритма и тем противоречит цели эргономичного визуального инструмента. Да и выделение защищаемых участков алгоритма в отдельные ветки выглядит очень искусственно. И мне также осталось непонятно, что делать со вложенными исключениями...

Автор:	Рэйлвэй Каген [ Четверг, 28 Январь, 2010 10:25 ]
Заголовок сообщения:	Re: "Ситуации" в Драконе
Alexey_Donskoy писал(а): Мне такой подход кажется более правильным. К сожалению, при ближайшем рассмотрении, он оказался нежизнеспособным. В основном, из-за того, что он порождает набор взаимно противоречивых правил, существенно усложняющих сам язык(выводящий его из устойчивого минимального набора правил и компромиссов) и транслятор(из силуэта в набор примитивов или сразу в промежуточное представление для компилятора). Может быть я и ошибаюсь, но как-то не очень привлекает перспектива детальной проработки изначально "хромого" варианта. Поэтому и стал искать решение при других "граничных условиях". Alexey_Donskoy писал(а): прерывание не имеет чётко очерченной области действия. Позвольте не согласиться с таким утверждением. Если я при старте контроллера сразу разрешаю прерывания, то даже в этом случае область четко определена - все ветки. Рисуем чёрную "ловушку" с пустым списком, т.е. "не исключать ничего". Если надо где-то запретить обработку прерываний - заполняем список исключаемых веток. Если имеем ясные намерения разрешать прерывания в конкретных ветках - используем белую "ловушку" со списком. Да, чёрная "ловушка" - прямо клякса какая-то получилась. Наверное лучше перекрасить . По поводу большого минуса - ничто не запрещает размещать ветку обработчика рядом с веткой или группой веток, внесённных в список "ловушки". Равно как и отодвинуть обработчик в сторону тоже ничто не запрещает. Эргономика схемы будет определяться, в том числе, набором когнитивных правил, использованных разработчиком схемы для упорядочивания веток. Инструмент уже есть, новых ограничений на упорядочивание веток я не вводил. Поэтому считаю, что минусов в этом плане не добавилось. Alexey_Donskoy писал(а): выделение защищаемых участков алгоритма в отдельные ветки выглядит очень искусственно. Такое выделение позволяет исключить рисование громадных вложенных прямоугольников и связанные с этим проблемы при обработке схемы. Так же было и параллельными процессами - на определённом этапе увеличения сложности взаимодействия Вы уже не сможете с помощью ГОСТовской нотации отобразить без пересечений логику взаимодействия процессов. Точно также в классическом Драконе "расшиты" и пересечения обычных маршрутов.. Alexey_Donskoy писал(а): И мне также осталось непонятно, что делать со вложенными исключениями... В каком смысле?

Страница 1 из 3	Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/

Автор:	Alexey_Donskoy [ Вторник, 16 Декабрь, 2008 23:47 ]
Заголовок сообщения:	Re: "Ситуации" в Драконе
Ну и напрасно! Потому что всё, что мы тут пытаемся изобразить, на самом деле является иллюзией... А дзен - это выход на прямое знание. Первый шаг к этому - интуиция. Интуицию могут разбудить только эргономичные инструменты. Хотите оставаться в рамках Дракона (Паскаля, Хаскеля, Форта) - оставайтесь, но далеко не уедете

Автор:	Рэйлвэй Каген [ Четверг, 28 Январь, 2010 10:52 ]
Заголовок сообщения:	Re: "Ситуации" в Драконе
С выделением областей большими прямоугольниками и присоединёнными к ним обработчиками изображение вообще превратится в бессмыслицу. А если у каких-то областей, не непосредственно вложенных друг в друга, обработчик одинаковый? Попробуйте представить. В предложенном варианте таких проблем не возникает в принципе. Можно, конечно, и до маразма довести - нашинковать ветки по одному действию и вперёд.. Но ведь и голова у разработчика маленько думать должна.

Автор:	Alexey_Donskoy [ Четверг, 28 Январь, 2010 11:41 ]
Заголовок сообщения:	Re: "Ситуации" в Драконе
Ну давайте конкретный пример, что ли, разберём (абстрактный такой, не будем заморачиваться на конкретную Дельфу или другой ЯВУ с конкретной файловой системой): Код: error:=true; try OpenFile(f); try try ЧитаемФайлИРаботаем; finally CloseFile(f); end; error:=false; //успешное завершение except ShowMessage('Ошибка работы с файлом'); end; except ShowMessage('Ошибка открытия файла'); end; if error then ВсёЧтоНужноСделатьЕслиФайлаНет; Как такая фигня будет выглядеть в предлагаемой нотации?!