Нисходящая и восходящая разработка ПО

При проектировании, реализации и тестировании компонентов струк­турной иерархии, полученной при декомпозиции, применяют два подхода:

• восходящий;

• нисходящий.

В литературе встречается еще один подход, получивший название «рас­ширение ядра». Он предполагает, что в первую очередь проектируют и раз­рабатывают некоторую основу - ядро программного обеспечения, например, структуры данных и процедуры, связанные с ними. В дальнейшем ядро на­ращивают, комбинируя восходящий и нисходящий методы. На практике дан­ный подход в зависимости от уровня ядра практически сводится либо к нис­ходящему, либо к восходящему подходам.

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

Для тестирования и отладки компонентов проектируют и реализуют специальные тестирующие программы.

Подход имеет следующие недостатки:

• увеличение вероятности несогласованности компонентов вследствие неполноты спецификаций;

• наличие издержек на проектирование и реализацию тестирующих программ, которые нельзя преобразовать в компоненты;

• позднее проектирование интерфейса, а соответственно невозможность продемонстрировать его заказчику для уточнения спецификаций и т. д.

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

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

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

Иерархический метод предполагает выполнение разработки строго по уровням. Исключения допускаются при наличии зависимости по данным, т. е. если обнаруживается, что некоторый модуль использует результаты дру­гого, то его рекомендуется программировать после этого модуля. Основной проблемой данного метода является большое количество достаточно слож­ных заглушек. Кроме того, при использовании данного метода основная мас­са модулей разрабатывается и реализуется в конце работы над проектом, что затрудняет распределение человеческих ресурсов,

Операционный метод связывает последовательность разработки моду­лей с порядком их выполнения при запуске программы. Применение метода усложняется тем, что порядок выполнения модулей может зависеть от дан­ных. Кроме того, модули вывода результатов, несмотря на то, что они вызы­ваются последними, должны разрабатываться одними из первых, чтобы не проектировать сложную заглушку, обеспечивающую вывод результатов при тестировании. С точки зрения распределения человеческих ресурсов слож­ным является начало работ, пока не закончены все модули, находящиеся на так называемом критическом пути.

Комбинированный метод учитывает следующие факторы, влияющие на последовательность разработки:

• достижимость модуля - наличие всех модулей в цепочке вызова дан­ного модуля;

• зависимость по данным- модули, формирующие некоторые данные, должны создаваться раньше обрабатывающих;

• обеспечение возможности выдачи результатов - модули вывода результатов должны создаваться раньше обрабатывающих;

• готовность вспомогательных модулей - вспомогательные модули, на­пример, модули закрытия файлов, завершения программы, должны созда­ваться раньше обрабатывающих;

• наличие необходимых ресурсов.

Кроме того, при прочих равных условиях сложные модули должны раз­рабатываться прежде простых, так как при их проектировании могут вы­явиться неточности в спецификациях, а чем раньше это произойдет, тем луч­ше.

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

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

Нисходящий подход обеспечивает:

• максимально полное определение спецификаций проектируемого компонента и согласованность компонентов между собой;

• раннее определение интерфейса пользователя, демонстрация которого заказчику позволяет уточнить требования к создаваемому программному обеспечению;

• возможность нисходящего тестирования и комплексной отладки.

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