DRAKON.SU https://forum.drakon.su/ |
|
"Ситуации" в Драконе https://forum.drakon.su/viewtopic.php?f=62&t=1282 |
Страница 1 из 3 |
Автор: | Рэйлвэй Каген [ Вторник, 16 Декабрь, 2008 18:43 ] |
Заголовок сообщения: | "Ситуации" в Драконе |
Попытался изобразить обработчик ситуации на Драконе. Вот что вышло: Вложение: cl.png [ 8.52 КБ | Просмотров: 23609 ] |
Автор: | 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: "Ситуации" в Драконе |
Чтобы иметь возможность свернуть/развернуть--посмотреть. И ещё потому, что рисовать, как предлагали Вы(здесь) и Геннадий Тышов(здесь) нельзя. Последнее поясню: Эти варианты по правилам дракона предусматривают выполнение всего защищаемого блока. А на самом деле структурный переход на обработчик может произойти из любого места защищаемого алгоритма. И не факт, что хвост, оставшийся после перехода на обработчик, обязательно должен выполняться. Чтобы отрисовать такое, понадобилось оторвать обработчик от области, притянуть за уши замыкание и нарисовать транзитный выход. Надеюсь, что можно проще, но пока не вижу как.. |
Автор: | Alexey_Donskoy [ Вторник, 16 Декабрь, 2008 22:55 ] |
Заголовок сообщения: | Re: "Ситуации" в Драконе |
Коан расскажу... (c) я писал(а): Большинство людей строит гараж поближе к квартире (про советскую действительность говорю, а то ещё не поймут ). Уникумы (вроде меня) строят квартиру поближе к гаражу (реальный факт ). Любознательный товарищ поинтересуется у мастера дзен, почему так случилось? В отмет мастер дзен спросит: "Так ли это?" Когда любознательный товарищ начинает проверять слова мастера дзен, он долго трудится, читает гору книг и, наконец, понимает, что гараж стоял на правильном месте, и по фэн-шую так было сделать правильнее всего. И снизойдёт тогда на любознательного товарища просветление! Много позже любознательный товарищ поймёт, что китайский фэн-шуй на россиянина действует совсем не так, нежели на китайца... И усомнится любознательный товарищ в происходящем, а заодно и в компетентности мастера дзен... Прожив большую жизнь, любознательный товарищ вдруг поймёт ту простую истину, которую сразу увидел мастер дзен - всё призошло просто случайно! И незачем городить иллюзию на иллюзии, пытаясь объяснить эту случайность. И тогда любознательный товарищ обнаружит, что окружающие смотрят на него с почтением и называют мастером дзен Но на пороге своей жизни мастер дзен вдруг обнаруживает, что всё не так просто, и что в этом Мире случайностей не бывает... И с грустью вспомнит, что ещё в далёком детстве поп, обжора и пьяница, не отличавшийся ни умом, ни красноречием, говорил ему об этом же - заученными библейскими словами. А как оно было на самом деле? Рэйлвэй Каген писал(а): Эти варианты по правилам дракона предусматривают выполнение всего защищаемого блока... Не подскажете ли, как оно было на самом деле? Поймите же, что обсуждение выразительных возможностей конкретного Дракона может быть интересным лишь постольку, поскольку указывает направление дальнейшего пути совершенствования! Поэтому ещё раз спрошу - зачем Вам такие упражнения? Нарисуйте лучше новый язык, используя полученный опыт и решая конкретные проблемы! |
Автор: | Рэйлвэй Каген [ Вторник, 16 Декабрь, 2008 23:39 ] |
Заголовок сообщения: | Re: "Ситуации" в Драконе |
Alexey_Donskoy писал(а): ..зачем Вам такие упражнения? Чтобы в дзен не впадать.
|
Автор: | Alexey_Donskoy [ Вторник, 16 Декабрь, 2008 23:47 ] |
Заголовок сообщения: | Re: "Ситуации" в Драконе |
Ну и напрасно! Потому что всё, что мы тут пытаемся изобразить, на самом деле является иллюзией... А дзен - это выход на прямое знание. Первый шаг к этому - интуиция. Интуицию могут разбудить только эргономичные инструменты. Хотите оставаться в рамках Дракона (Паскаля, Хаскеля, Форта) - оставайтесь, но далеко не уедете |
Автор: | Valery Solovey [ Среда, 17 Декабрь, 2008 12:44 ] |
Заголовок сообщения: | Re: "Ситуации" в Драконе |
Мы чаще используем термин "абстракция", а не "иллюзия". |
Автор: | Alexey_Donskoy [ Среда, 17 Декабрь, 2008 12:55 ] |
Заголовок сообщения: | Re: "Ситуации" в Драконе |
Абстракция не всегда бывает иллюзией |
Автор: | Valery Solovey [ Среда, 17 Декабрь, 2008 14:58 ] |
Заголовок сообщения: | Re: "Ситуации" в Драконе |
Просто недавно я поменял точку зрения на эти понятия. Если какие-то объекты не конкретны - то они иллюзорны. Абстракция очень часто бывает полезной. Самое главное - не забывать, что это абстракция. |
Автор: | Alexey_Donskoy [ Среда, 17 Декабрь, 2008 15:33 ] |
Заголовок сообщения: | Re: "Ситуации" в Драконе |
Дык, опять же, не всякая иллюзия может подняться до абстракции Иллюзия - это то, что при внешне правдоподобном виде не соответствует сути и потому заводит в тупик... Абстракция - это [минимально необходимое] для решения задачи описание сути. Поэтому абстракция ВСЕГДА бывает полезной... Если, конечно, это не иллюзия А спутать их достаточно просто, так как суть при решении новой, творческой задачи ещё не открыта... |
Автор: | Рэйлвэй Каген [ Среда, 27 Январь, 2010 21:37 ] |
Заголовок сообщения: | Re: "Ситуации" в Драконе |
Многие помнят попытку рисования областей на Дракон-схеме. Для удобства напомню картинку: Вложение: Дальше можно поступить в духе YAWL - непосредственно пририсовывать к области её обработчик и присоединять к ней же результат обработки(выходной маршрут обработчика) следующим образом: 1)возврат на вх.границу - restart - стрелка, направленная ко входу в область 2)переход на вых.границу - exception, cancel, skip - стрелка, направленная к выходу из области 3)возврат в точку, из которой вышли - interrupt - графически простым маршрутом Но при этом всё равно остаются проблемы: 1.отсутствуют принципы структурирования областей, подобные структурированию маршрутов в силуэте. 2.из-за п.1 на определённом этапе проектирования станет просто неудобно рисовать кучу громадных прямоугольников. 3.как достучаться до внутренней границы вложенной области не пересекая границу внешней области, не запутывая излишне транслятор? Что будет, если поступить с областями, также как и с параллельными процессами - вытянуть их границы и взаимодействие с ними на петлю силуэта? У иконы "Адрес" может быть список, чего бы не добавить такую же штуку к иконе "Ветка". Но для этого нужно разместить список внутри иконы "Ветка"? Было найдено графическое решение, отдалённо напоминающее перчатку хоккейного вратаря. Только "ловушку", вторая перчатка - "блин" совсем не подошла . В результате "Ветка" осталась со своим уникальным именем, а в "ловушку" попал нужный нам список. При этом ничто не мешает применять "Ветку с ловушкой" в контексте параллельных процессов(пример с параллельными процессами и ловушкой можно найти здесь). Вложение: Картинку в высоком разрешении можно скачать здесь. Размер 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 писал(а): И мне также осталось непонятно, что делать со вложенными исключениями... В каком смысле?
|
Автор: | Alexey_Donskoy [ Четверг, 28 Январь, 2010 10:36 ] |
Заголовок сообщения: | 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 ВсёЧтоНужноСделатьЕслиФайлаНет; |
Автор: | Рэйлвэй Каген [ Четверг, 28 Январь, 2010 12:33 ] |
Заголовок сообщения: | Re: "Ситуации" в Драконе |
Вложение: ATTN: схема содержит ошибку! См. обсуждение наследующей странице.. |
Автор: | Рэйлвэй Каген [ Четверг, 28 Январь, 2010 12:41 ] |
Заголовок сообщения: | Re: "Ситуации" в Драконе |
На вопросы смогу ответить позже, т.к. буду вне сети до 31.01.2010 |
Страница 1 из 3 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |