Владимир Паронджанов писал(а):
Надо разграничить две проблемы:
ИМХО, такое разграничение не имеет ни теоретического, ни практического смысла.
Цитата:
Я хочу — с помощью участников форума — доказать (или опровергнуть) тезис о том, что слепыш языка ДРАКОН почти полностью решают проблему управления и декомпозиции
Задача декомпозиции осложняется тем, что она имеет принципиально иерархические свойства, которые ДРАКОН-подобная нотация не поддерживает должным образом.
Цитата:
превращая сложную проблему императивного программирования в относително простую проблему проектирование и кодирование линейных участков программы.
Нормальный проектировщик, импользуя императивное программирование, оперирует ЗАДАЧАМИ (подзадачами и т.д.).
В так называемых линейных участках схемы большого проекта подзадачи, как правило, сами по себе комплексные и подразумевают дальнейшее раскрытие (уточнение, детализацию). Главное, чтобы грамотное проектирование позволило эти подзадачи локализовать, минимизировав их связи с остальной схемой (сведя до одного входа и одного выхода в случае линейного блока).
Проектировщику приходится решать и такой нетривиальный вопрос: до какой степени детализировать тот или иной участок на схеме текущего рассматриваемого уровня.
Крайней степенью "когнитивного упрощения" соотношения между "управлением" и "линейными участками" мне представляется принцип "свернуть всё, что можно". То есть данная схема решает ОДНУ задачу, а все локальные подзадачи свёрнуты в "комплексные" блоки, составляющие линейные участки.
Другой крайностью будет принцип "развернуть всё", изобразив ВСЮ программу на одной схеме. Очевидно, для сколько-нибудь существенных проектов подобный подход неприемлем. К примеру, подзадачу "отсортировать массив" нормальный проектировщик изобразит в виде одного блока в линейной части (если только данная схема не является самой процедурой сортировки или чем-то подобным, специфическим)...
Но эти рассуждения тривиальны (надеюсь).
А вот
теперь прошу ВНИМАНИЯ!Основные задачи, которые решает проектировщик, вовсе не относятся к поставленным Вами проблемам управления и кодирования линейных участков!К примеру, у меня в системах реального времени наиболее сложной проблемой является синхронизация (в общем смысле - по событиям, по данным и т.п.). Посмотрим на один только из используемых здесь способов программирования: флаги. Тут требуется инструмент, который бы показал:
- где инициализируется флаг;
- где он взводится и сбрасывается;
- где используется.
Для решения этих вопросов ДРАКОНа менее чем недостаточно. Потому что само по себе визуальное представление алгоритма не помогает ни ответить на эти вопросы, ни показать соответствующие области, и т.п.
Я не говорю (пока), что для этого нужен специальный ЯЗЫК. Но специфический инструмент визуализации и редактирования НАД используемым языком - необходим.
В связи с этими соображениями поставленные Вами вопросы не представляются актуальными.
А с теоретической точки зрения напомню про тему "Что же такое алгоритм?", где показывается, что само понятие алгоритма основательно подвисает в воздухе в зависимости от конкретных особенностей исполнителя.
С практической же точки зрения объём алгоритмического слоя в проекте, как неоднократно указывали здесь, редко превышает 10%
Обратите, пожалуйста, внимание. Я пишу всё это не для того, чтобы просто возразить и указать на какие-то недостатки.
Я хочу, чтобы усилия и Ваши, и других участников форума были направлены на более актуальные задачи (в том числе теоретические)!
Вход
FAQ
Поиск
