Нисходящее и восходящее проектирование

Пример архитектуры программной системы из нескольких уровней:

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

Нисходящее проектирование:

Проектирование сверху вниз, от общего к частному. При нисходящем проектировании сначала разрабатывается модуль верхнего уровня.

Например для данной схемы опишем модуль А на “мета” языке:

MAIN: procedure

Задача АА;

do while (условие)

Задача АВ;

end;

Задача АС;

end MAIN;

Процесс детализации:

Фаза1: А(MAIN)

Фаза2: MAIN: procedure

Инициализация задачи АА;

(подготовка данных для АА)

call AA;

do while (условие)

Инициализация задачи АВ;

call AВ;

end;

Инициализация задачи АC;

call AC;

end MAIN;

Описание модулей:

AA: procedure … Алгоритм решения задачи АА; … end AA;

AB: procedure … call АB; … end AB;

AC: procedure … end AC;

Далее процесс продолжается, пока не будет всё достаточно детализировано. Процесс детализации заканчивается с исчезновением общих фраз (инициализация задачи АВ).

Восходящее проектирование:

Снизу вверх или от частного к общему. Сначала разрабатываются модули самого нижнего уровня.

Процесс детализации:

Фаза1:

Напишем алгоритмы с предельной степенью детализации:

AAА: procedure … end AAА;

AАB: procedure … … end AАB;

ACА: procedure … end ACА;

Фаза2: Переход к более

абстрактным представлениям

AA: procedure … end AA;

…

AC: procedure … end AC;

A: procedure … end А; {MAIN}

Фаза3:

Такой подход применяется в случаях когда разрабатываемая система имеет хорошо известную архитектуру (аналог имеющийся системы). Так же этот подход может быть применён в случае когда нижний уровень функций определён.

Например: Проектирование ОС где нижний уровень определяется аппаратурой.

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

На этапе реализации (3-м) восходящий подход является основным.

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

Такой традиционный подход к реализации не всегда удобен. Иногда на ранних этапах реализации нужно бывает убедиться в работоспособности всей системы (например показать интерфейс заказчику). Есть выход – использование модулей заглушек. Эти модули замещают ещё не реализованные модули системы, но позволяют убедиться в работоспособности системы в целом.

Заглушка – программный модуль, который не выполняет никаких действий по обработке данных. Он всего лишь возвращает некоторые фиксированные данные, т.е. имитирует работу модуля (т.е. возвращаемые им данные нужной структуры).

Заглушки позволяют вести реализацию сверху-вниз.

<– использование заглушек при нисходящей реализации.

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

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

Достоинство: уже на ранних этапах имеем уже рабочую систему.

Недостаток: трудно планировать процесс разработки.

Дата добавления: 2014-01-07