Рэйлвэй Каген писал(а):
Для устойчивого появления когнитивной связи, эти части в тексте следуют друг за другом.
Напоминаю, что как раз здесь графика и отличается от текста. Здесь альтернативные пути нужно изобразить параллельно (развилка, переключатель). Кстати, в третий раз повторяю, что переключатель идеологически (семантически) наиболее близок к описанию обработчика ситуации!
Рэйлвэй Каген писал(а):
При возникновении ситуации во время выполнения любого действия из алгоритмического предложения(независимо от места возникновения) выполняется переход к альтернативным предложениям. При этом не надо сопровождать выполнение каждого действия алгоритмического предложения проверкой условия "Ошибка?".
Я вижу в этих рассуждениях принципиальную ошибку.
Во-первых, Вы упорно не хотите отделить
исключения (синтаксический сахар, позволяющий нарушить строгий алгоритм; причём польза этого сахара в свете написания надёжного софта более чем сомнительна) от возмущений внешней среды, на которые должна быть обеспечена немедленная реакция (механизмом
прерываний, по сути отдельных процессов). Прочувствуйте, насколько это
разные задачи!
Во-вторых, на самом же деле исключений не существует в природе как таковых; они существуют постольку, поскольку:
а) типовые архитектуры процессоров имеют программные прерывания по ситуациям (которые можно по пальцам пересчитать - ошибка FPU, недопустимая инструкция (такого на ЯВУ быть не должно никогда), переполнение стека туда/сюда (вот это бывает)... и вроде всё...);
б) вумные сишники придумали включить эту обработку в ЯВУ, назвав это исключениями;
в) ленивые, но вумные разработчики Unix (?) и Windows решили, что это удобный механизм, и стали генерировать программные прерывания при каждой ошибке системных функций.
Таким образом, исключения обусловлены исторически, вызвали к жизни их вредные программеры, которым лениво писать действительно надёжные программы, и ценность механизма исключений, вообще говоря, вовсе не очевидна!
В-третьих, физически (алгоритмически) исключения возникают отнюдь не в произвольные моменты (как прерывания от внешних устройств), а во вполне конкретных местах алгоритма. Поэтому
именно проверка ошибок на каждом таком месте (например, вызове системной функции) и есть адекватное алгоритмическое описание задачи!Рэйлвэй Каген писал(а):
Представим, что мы пользуемся GPS-приёмником для определения местоположения, а также не имеем часов и узнаём время с того же GPS-приёмника. Эта штука может выйти из строя, могут сесть батарейки, наконец мы можем забрести в ущелье, откуда просто не видны спутники и приёмник там молчит как партизан. Тогда ситуация "ошибка GPS" может произойти во время "доберись до места ловли", по всей ветке "обратная дорога" и при проверках "пора домой?"(наверное смотрим на часы).
Ошибка алгоритмизации, см. выше. В данном случае ситуация не является внешним прерыванием. Ситуация ичсерпывающим образом описывается алгоритмически без всяких исключений: пока не добрались до места выполнить (посмотреть на GPS; если есть сигнал то алгоритм1 иначе алгоритм2 конец). И притягивать за уши ненужную ситуацию, даже в иллюстративных целях, не есть правильно...
Рэйлвэй Каген писал(а):
По поводу выделения цветом
Паронджанов абсолютно прав - выделение области имеет более декларативный смысл, и потому должно отличаться от алгоритмически чётких линий. Как вариант я бы предложил цветной прямоугольник без рамки (Паронджанов здесь прав!), но с градиентной заливкой, с высветлением центра. Тогда вложенность будет выглядеть вполне замечательно.
Блин, как инерционно человеческое мышление! Привыкли линии рисовать, и в голову не приходит, что есть другие выразительные формы, что мониторы давно цветные, что принтеры цветные тоже перестали быть роскошью ну и т.д. Где свобода мысли и духа?!Рэйлвэй Каген писал(а):
спеки.. Вот сверху вниз - как раз UML и получится. Потому что эти спеки будут отражать стандартный(часто консервативный) набор идей и методов, основанный на опыте спекописателей.
Надо как-то обеспечить генерацию и тестирование новых идей и принципов(адекватных и не очень) на предмет облегчения визуального проектирования.
Второе аболютно верно, а первое неоднозначно... Ну вот, к примеру, я могу прочитать потоковую диаграмму, но никогда ею не пользовался на практике. Как могу судить я об её удобстве и вообще применимости?
Рэйлвэй Каген писал(а):
Как будет выглядеть маршрут выполнения программы(дракон-схема) в области данных(в декларативном представлении)? Получится множество вложенных друг в друга областей, каждая из которых соответствует использованию декларативных сущностей по маршруту выполнения программы, а порядок вложения определён очерёдностью выполнения команд и правилами их выполнения.
Тут хотелось бы подробнее, с примерами... А то можно понять такую идею совершенно по-разному
Рэйлвэй Каген писал(а):
p.s.: Кстати, вложения в текстовой форме(вложенные циклы, а особенно if'ы и т.д.) часто вызывают трудности с восприятием. Народ с удовольствием влепит лишний выход, чем ступеньку вложенности. Чем больше вложений, тем сильнее уезжает код на странице вправо. Поэтому структурность в этом случае часто приносится в жертву.
Про это уже давно говорили. Ещё Седов отмечал, что текст линеен, в чём его основной недостаток. Отступы на деле не добавляют нового измерения. Алгоритм же на полскости имеет два измерения, поэтому качественно неизмеримо выше
Вход
FAQ
Поиск
Да, задача верификации в нашей работе ставится в качестве одной из основных. 