Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Лекции / Горбунов / УП_ОПТ1 / Р2_История.doc
Скачиваний:
26
Добавлен:
16.04.2013
Размер:
866.82 Кб
Скачать
      1. Нисходящее и восходящее проектирование.

«Лучше изобличить собственные ошибки, чем чужие».

Демокрит, ок 470-370 гг.до н.э.

Есть два пути построения проектной иерархии представления сложных объектов: нисходящий и восходящий. Нисходящий уже продемонстрирован при определении уровней иерархии. Он использует принципы последовательной детализации при создании теста программ:

  • Начинается с наиболее общей блок-схемы.

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

  • Каждый прямоугольник может быть раскрыт как управляющая структура (if, if/else, switch, while, do/while, for).

Восходящий процесс построения проектных иерархий значительно сложнее, он начинается с определения типовых моделей терминальных элементов. Затем последовательно создаются структурные модели (т.е. идет процесс обратный их раскрытию). Если при нисходящем проектировании мы знаем интерфейс элемента (внешние требования), но не знаем реализации, то при восходящем мы имеем реализацию, но не знаем до конца интерфейса. Поэтому в реальности оба подхода могут использоваться в «смеси», особенно при необходимости уточняющих итераций и т.п. проектных процедурах.

Напомним, что при программировании текст программ в общем случае описывает не только абстракцию самих объектов, их элементов и связей между ними, а самое главное – модель процессов с ними! Поэтому если при проектировании учитывается прежде всего аспект функциональных зависимостей, то данный подход к выделению структуры называют функциональным. Напомним, что реальное моделирование (а не программа как инструкция) отражает реальные процессы в виде операций над знаковой системой в которой построена модель. В программе эти операции только описываются.

      1. Динамика нарастания детализации.

«Ни искусство, ни мудрость не могут быть достигнуты, если им не учиться».

Демокрит, ок 470-370 гг.до н.э.

Данный пример процедурной иерархии и её раскрытия показывает, каким образом исходное описание на некотором псевдопрограммном языке (даже в вербальном виде – на естественном языке) может постепенно детализироваться до уровня операторов языка С или С++. Ясно, что каждый профессиональный программист должен владеть данных технологическим приемом.

Заметим, что для задач с явно выраженной «древесной» структурой организации и обработки данных технология структурного программирования будет очень эффективной. Особенно важно, чтобы некоторые «ветви» вычислений были бы изоморфны по выполняемым операциям (т.е. вычислялись бы одной функцией при различных исходных данных). Проблемы начинаются из-за более сложных структур данных в программных приложениях и «недревесных» функциональных зависимостях между их данными. В широком классе приложений зависимости между данными имеют так называемую «сетевую» структуру, что требует общности части данных. Это порождает проблему перекрестных ссылок в базах данных и требует иной парадигмы в технологиях создания сложных программных систем. Поэтому структурные методы организации программного обеспечения оказались очень чувствительными к логической сложности решаемых задач. Это привело к локализации технологии структурного программирования.

Потребности общества невозможно ограничить. Если требуется перейдти от исследования и создания больших систем к сверхбольшим (называемых программными комплексами), то рано или поздно это будет сделано. «Проклятие сложности» и размерности систем будет преодолено (или существенно отодвинуто). При этом очень важно понять, каким образом «выкрутились» разработчики програмных комплексов в нашем случае. Дело в том, что созданное для этого парадигма объектно-ориентированного программирования (ООП) и связанное с ним объектно-ориентированное проектрование программ (ООПП) бурно развиваются в последние 15 лет. Но какое при этом произошло кардинальное изменение критериев качества, требований к технологиям создания и самой философией проектирования систем! Но в основном эти вопросы будут рассматриваться в Части 2 настоящего пособия. Сначала нам надо разобраться с некоторыми проблемами системного анализа проблемных ситуаций и фундаментальным, но более частным вопросом: «Что же такое данные и как их организовать в програмной системе?»

27

Соседние файлы в папке УП_ОПТ1