DRAKON.SU

Текущее время: Пятница, 29 Март, 2024 07:57

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 111 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.
Автор Сообщение
СообщениеДобавлено: Воскресенье, 30 Ноябрь, 2008 12:11 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Alexey_Donskoy писал(а):
А я говорю про случаи, когда по ошибке (да почему по ошибке, вообще разные ситуации бывают) требуется выход на другой логический уровень (в другую схему - надсистему). Если решать структурно, то придётся два принципиально разных алгоритмических пути пропускать через одно общее, узкое горлышко - стандартный выход из процедуры. А затем ставить кривой case/switch для анализа кода возврата... А если таковой выход происходит с n-го уровня рекурсии? Накладные расходы возрастают неимоверно! Когнитивные расходы возрастают также...

Многократный транзитный выход из процедуры(с n-ого уровня рекурсии), как оказывается, прибили ещё в Эльбрусе. За счёт прекращения выполнения по ситуации вместо многократного возврата. Вроде как подарок для ФЯ, но они его не заметили :)
В основном, за счёт того, что указатель ситуации имел аппаратно распознаваемый тип, отмотка по стеку вызовов существенно сократилась. Вызов обработчика осуществлялся моментально благодаря хранению указателя ситуации совместно с её типом(очень похоже на действия при вызове через WITH..)
Alexey_Donskoy писал(а):
Однако распространение исключения вверх по иерархии так уже не изобразить, мой первоначальный вопрос в силе...

Распространение исключения(ситуации) это не алгоритм, если рассматривать ситуацию как объект/экземпляр определённого типа. Но это распространение происходит по некоторому маршруту, однозначно определяемому порядком вложения областей. Как отобразить - сразу так и не скажу. Недостаток в том, что отношения(не взаимодействия!) декларативных сущностей на сегодняшний день непредставимы ни в Драконе, ни в Флоксе.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 30 Ноябрь, 2008 23:52 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Э-э... Про транзитный выход из процедур... А кто будет динамическую память освобождать (локальные переменные и проч.)?

То есть стекпойнтер-то изменить не вопрос и одной командой, но этого мало... Только прозрачно для пользователя надо...

И с чего это распространение ситуации - не алгоритм? В томже смысле, что fuzzy logic - не логика? :D

Тогда и обработка прерывания - декларативна... Хотя, в какой-то мере так и есть - надо ж таблицу векторов прерывания описать ;)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 01 Декабрь, 2008 09:56 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Alexey_Donskoy писал(а):
При транзитном выходе ... память освобождать..
Не, я не прикалываюсь. Раз уж эльбрусовская команда написала при сие чудо в своих книжках, оснований не доверять как бы нет..

Alexey_Donskoy писал(а):
И с чего это распространение ситуации - не алгоритм?
Просто с того, что вроде появляется шанс визуально разделить эти сущности(распространение ситуации и выполнение алгоритма), а также управление ими.

Alexey_Donskoy писал(а):
..надо ж таблицу векторов прерывания описать
Именно так, каждый вектор прерывания - метод ситуации соответствующего типа/класса. Добавим само описание типа/класса, и всё будет в шоколаде :)

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 01 Декабрь, 2008 10:05 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Рэйлвэй Каген писал(а):
динамические связи маршрута выполнения алгоритма можно отобразить на статические связи по данным. Если эргономично объединить визуальное представление статических связей по данным и Дракон-схему, то получится инструмент с качественно новыми характеристиками.
Так, так, и ещё подробнее! Предложите визуальное представление!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 01 Декабрь, 2008 10:12 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
уже.. -> здесь

только вот реакции особо не последовало. Даже по рукам никто не треснул.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 01 Декабрь, 2008 10:30 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Ну как же? А здесь я кому отвечал?

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 01 Декабрь, 2008 11:20 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Вероятно в ответе я был не особо убедителен. Попробую уточнить:
1.символы вставка/действие призваны обозначить область возникновения ситуации, для которой обработчик соответственно возвращается_обязательно/не_факт_что _возвращается к выходу из области. В Драконе по "Вставке" возвращаемся всегда.. Поскольку области больше икон, есть надежда, что они не будут "замыливать алгоритм", как в случае с непосредственной отрисовкой try-except-finally,
2.Сам алгоритм конечной реакции на ситуацию, а именно - метод определённого типа может быть отрисован как примитив или силуэт. В Драконе это ничего не нарушает и не "завешивает в воздухе" начало алгоритма обработки ситуации.
3.Ситуацию с числом выходов обработчика можно трактовать однозначно: их будет столько же, сколько выходов из области или на один больше. Последнее будет означать, что обработчик может инициировать выход из процедуры(область должна быть обозначена как "Действие").
4.Точки инициализации и удаления обработчика ситуации определяют только область его существования как экземпляра определённого типа/класса. Чтобы не было путаницы в терминах, область действия обработчика ситуации эквивалентна выделенной прямоугольником действие/вставка области возникновения ситуации. Последнюю лучше обозвать "областью реакции на ситуацию", поскольку вручную выделяем именно контролируемую область.. Да, их может быть много в разных процедурах и функциях. Даже ссылающихся на одии и тот же тип. Зато появится возможность визуально их структурировать - хотя бы исключить лишние вложения; сразу же видеть куда вывалимся из процедуры и т.п..

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

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


Последний раз редактировалось Рэйлвэй Каген Понедельник, 01 Декабрь, 2008 11:42, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 01 Декабрь, 2008 11:41 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
1. Есть принципиальная разница между обработкой прерывания (внешнего прерывания!) и исключения.

Обработчки внешнего прерывания (ISR) проектируется как независимый процесс, и обменивается с другими процессами стандартными средствами вроде семафоров, очередей и т.п. Но главное в ISR то. что он НЕ изменяет ход алгоритма других процессов (иначе как через глобальные данные).

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

Поэтому валить их в одну кучу нельзя, и нельзя их изображать каким-то одним способом. Это просто разные задачи!

Поэтому мне категорически не нравится предложение рисовать исключение вставкой (т.е. в отдельном алгоритме). Это - супернеэргономично.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 01 Декабрь, 2008 12:09 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Средства обмена(аппаратные, программные), равно как и особенности реализации(как отдельный процесс) нельзя тащить в язык(Дракон) как таковые. Нужно иметь возможность их отобразить средствами языка. Мы же не китайской грамоте обучены. Зачем нам 20.000 икон?
Если так претит использование икон "действие"/"вставка" явно не по назначению, да ещё и наложенными поверх алгоритма, давайте применим другие рамки(с завитушками) :wink: Но таких рамок должно быть две. Какая-то из них будет соответстовать безусловному возврату из обработчика ситуации.
Исключения и прерывания - разные задачи? Да. Зато возникают как-то одинаково - по ходу выполнения основного алгоритма. Вне обозначенного дракон-схемой маршрута. Да ещё и контекст переключают. Так что сходств больше, чем различий.
Прерывание может и не вернуть управление в прерванную процедуру - например прерывание от аппаратного watchdog'а. А до чего можно додуматься, если не ставить "reti" в конце обработчика прерывания - вообще потёмки.. :wink:

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 01 Декабрь, 2008 13:14 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Как хотите, конечно, но разные сущности надо и отображать по-разному. Общего между исключениеми и прерываниями, на мой взгляд, меньше, чем различий... Причём общность тут только по форме (прерывают выполнение нити основного алгоритма), а различия - именно по сути, как я писал выше...

И исключение обрабатывается не отдельно от основного алгоритма, это просто ЯВУ даёт такую (опасную) иллюзию.
Та же финализация локальных переменных в процедуре... Она ж не девается никуда, run-time фактически по исключению передаёт управление на финализирующий код процедуры... Просто программист (так и хочется сказать "юзер" ;) ) того не видит, за что и полюбил исключения... И стал даже использовать Raise вместо Goto...

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 01 Декабрь, 2008 15:59 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Если рисовать обработчик ситуации отдельно, то возникает проблема с обозначением на Драконе выхода из вызывающей процедуры. Не просто возврат, а на два уровня вверх.
Срочно нужен третий :wink: , а то мы тут друг другу нахваливаем свои огороды..


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 01 Декабрь, 2008 16:26 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Рэйлвэй Каген писал(а):
Если рисовать обработчик ситуации отдельно, то возникает проблема с обозначением на Драконе выхода из вызывающей процедуры.
Так а я о чём говорю?
Р: обработчик надо рисовать отдельно.
А: нельзя обработчик рисовать отдельно!
Р: нельзя обработчик рисовать отдельно.
Итого: консенсус ;)

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

Поэтому предложение А об изображении исключений Драконовскими силуэтами-переключателями вполне адекватно, но не на 100% эргономично...

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 01 Декабрь, 2008 21:49 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Alexey_Donskoy писал(а):
Тышов делает редактор "на общественных началах" и ему тоже все эти исследовательские феньки... некогда, одним словом...

Разрешите включиться в Ваш разговор со своим мнением.
Дракон-схема отображает алгоритм, т.е. определяет цели и последовательность их выполнения, а вовсе не средства их реализации. Набор графических средств ограничен, и область смыслового применения расширяется за счет их объединения. Например для отображения алгоритмов реального времени, многие иконы имеют присоединение иконы "Синхронизатор по таймеры". Там где не хватает проблемно ориентированных икон, следует использовать иконы с присоединенными комментариями, в которых раскрываются дополнительные функции иконы, границы их действия. Использование комментариев расширит смысловое значение икон и увеличит графическую наглядность алгоритма при сохранении простоты.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 01 Декабрь, 2008 22:04 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
TAU писал(а):
Первая картинка - визуальный конструктор "временных диаграмм", отражающих логико-временную схему алгоритма.
Вторая картинка - графический редактор циклограмм.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 01 Декабрь, 2008 22:13 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Геннадий Тышов писал(а):
Разрешите включиться...
Конечно. У нас же не соревнования в личном зачёте. И Вы сразу сказали нужные слова:"область смыслового применения расширяется за счет объединения икон" Решение может быть где-то рядом.

2Alexey_Donskoy:
1.не всякий консенсус должен быть выпит.
Лучше вовремя вспомнить, зачем все эти телодвижения..
Видимо для борьбы со сложностью(необозримостью)вводятся структурность действий и структурность данных - использование каждой сущности для одной конкретной цели, без их экономии и переиспользования под другое назначение и без запутывания маршрутных(для действий) и информационных/декларативных(для данных) связей.
а получилось, что
    Ваш вариант - не совсем эргономичен,
    мой вариант - не совсем адекватен :)
2.механизмы свёртывания-развёртывания или преобразования масштаба представления Дракон-схемы - это действительно фенька. Качественно ничего нового не добавляющая в инструмент. Весьма полезная в процессе проектирования, но всё-таки не жизненно необходимая. Её реализация позволила бы просто взглянуть на проектируемую систему под другим углом зрения. Видимо поэтому и долгострой.
3.насчёт предложения. Пока сложился определённый взгляд на то, чего не хватает для того, чтобы визуально(максимально облегчая когнитивное восприятие) проектировать системы с асинхронным и распределённым взаимодействием(внутренним или внешним, или их совокупностью). Но нет жизнеспособного варианта реализации. Пристраивать костыль к Дракону - не хотелось бы. Да и к Дракону ли - пока непонятно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 02 Декабрь, 2008 08:22 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Ага, и поэтому я давно предлагаю сообща нвбросать спеки для того, что могло бы стать таким удобным инструментом!

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

Давайте рисовать и обсуждать картинки, которые, по Вашему мнению, наиболее подходят для отображения всего вышеперечисленного!

P.S. Только есть такое смутное подозрение, что в результате опять получится UML ;)

P.P.S. Динамическое свёртывание-развёртывание, и фильтр отображения по слоям - это не фенька на самом деле, а существенно новое качество инструмента. Динамика vs. статика. Интерактивность vs. лапидарность бумаги ;)
Надо мне анализировать основной алгоритм, я отключаю вспомогательный слой и вижу область исключения примерно как на Вашем рисунке. Надо детально разобраться в обработке ситуации - включаю слой и вижу всё тут же, на этом же алгоритме.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 02 Декабрь, 2008 13:48 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 341
Геннадий Тышов писал(а):
TAU писал(а):
Первая картинка - визуальный конструктор "временных диаграмм", отражающих логико-временную схему алгоритма.
Вторая картинка - графический редактор циклограмм.

Все это представляет отраслевой интерес

Ну, не только... Смотря как понимать понятие "отрасль" 8)

Геннадий Тышов писал(а):
Включать в язык ДРАКОН

А при чем тут Дракон? :wink:

Геннадий Тышов писал(а):
при этом, средствами Дракона все это можно отобразить.

Ну, во-первых, не все, а во-вторых, не наглядно, Геннадий, я ж Вам уже писал об этом.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 03 Декабрь, 2008 18:55 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Рэйлвэй Каген писал(а):
...возникает проблема с обозначением на Драконе выхода из вызывающей процедуры. Не просто возврат, а на два уровня вверх...


Может быть, это можно сделать так (см. вложение).

1. :arrow: В иконе "полка" на верхнем этаже пишем ключевое слово Выход. На нижнем этаже пишем
имя вызывающей процедуры. (При этом управление передается на два или больше уровней наверх). Транслятор передает управление немедленно.
На дракон-схеме добавляются икона АДРЕС "Завершение" и икона ИМЯ ВЕТКИ "Завершение".
Благодаря этому соблюдается правило:
Дракон-схема имеет только один выход.

2. :arrow: Уважаемый Рэйлвэй Каген! Здесь
viewtopic.php?p=21618#p21618
Вы нарисовали большой черный прямоугольник (точнее, икону вставка). Я плохо понял
Вашу мысль, но, по-моему, прямоугольник из черных линий это нехорошо. Если надо выделить зрительную зону, это можно сделать нежным желтым (а на распечатке -- серым примерно 10% или 15% серости), причем БЕЗ КОНТУРА.

Поправьте меня, если я в чем-то ошибся.


Вложения:
Комментарий к файлу: Возврат управления в вызывающую программу и выделение зрительной зоны желтым цветом
_наверх.png
_наверх.png [ 103.66 КБ | Просмотров: 14941 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 03 Декабрь, 2008 19:53 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Владимир Паронджанов писал(а):
Может быть, это можно сделать так (см. вложение).

1. :arrow: ...
2. :arrow: ...

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

1. Икону "Адрес", после которой необходимо вернутся в конкретную процедуру, пометить идентификатором, допустим ВозвратА . К иконе "Конец" присоединить правый комментарий примерно такого содержания "Из ВозвратА управление вернуть до процедуры А".

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 03 Декабрь, 2008 21:24 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Владимир Даниелович, спасибо.

Дело в том, что связь, обозначенная красным(см.вложение), часто не существует. Если "леска порвалась" произойдёт при выполнении "подсекай", то ситуация останется необработанной. По крайней мере до тех пор, пока не выполнится ветка "рыбацкая работа" и мы вновь не попадём на ветку "ожидание клёва". Это неправильно.
Ошибка "порвалась леска" может возникнуть при выполнении любого оператора "забрось удочку", "подсекай", после проверки "пора домой?"-"Да" при пропущенном на схеме действии "смотай удочку".
Вложение:
fish1.png
fish1.png [ 67.12 КБ | Просмотров: 14929 ]

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

По поводу выделения цветом:
Представим, что мы пользуемся GPS-приёмником для определения местоположения, а также не имеем часов и узнаём время с того же GPS-приёмника. Эта штука может выйти из строя, могут сесть батарейки, наконец мы можем забрести в ущелье, откуда просто не видны спутники и приёмник там молчит как партизан. Тогда ситуация "ошибка GPS" может произойти во время "доберись до места ловли", по всей ветке "обратная дорога" и при проверках "пора домой?"(наверное смотрим на часы).
Возможны такие решения:
1. безусловная проверка "GPS работает?" в обозначенных местах алгоритма. Достаточно сильно "замылит" алгоритм - куча одинаковых проверок в разных местах алгоритма. Да ещё и каждый раз со своими накладными(вычислительными) расходами.
2. выделение области возможного возникновения ситуации "СИТ: Ошибка GPS". Можно мельчить и сделать несколько областей для каждого подозрительного места или тупо заключить в область весь алгоритм. В любом случае области "СИТ: Ошибка GPS" и "СИТ: порвалась леска" оказываются вложенными. Различаться будет только порядок вложения. Решение с цветом весьма запутает картину. Поэтому я использовал бы рамки. Двойные - показывающие обязательный возврат в алгоритм(пытался провести аналогию со вставкой) и одинарная рамка - показывающая, что возможен выход из алгоритма(тут с аналогией не особо, но альтернативы не нашлось). Рамки много больше икон и размер их будет изменяться в зависимости от выделяемой области. И(NB) у рамок нет проблем с вложенностью.

По поводу полки для обозначения выхода - это надо обдумать. Может что-то получится.


Последний раз редактировалось Рэйлвэй Каген Среда, 03 Декабрь, 2008 22:29, всего редактировалось 3 раз(а).

Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 111 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 6


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2024, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB