Восходящая разработка по

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

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

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

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

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

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

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

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

№51 Последовательность проектирования и реализации (Иерархический , Операционный , Комбинированный)

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

• Иерархический – разработка идет строго по уровням. Недостатки: большое количество сложных заглушек, основная масса модулей разрабатывается и реализуется в конце работы над проектом;

• Операционный - последовательность разработки модулей совпадает с порядком их выполнения при запуске программы. Недостатки: модули вывода результатов должны разрабатываться первыми, чтобы не проектировать сложную заглушку, при тестировании;

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

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

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

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

• сложные модули должны разрабатываться прежде простых.

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

№52 Модульное программирование. Модули и их свойства. Сцепление модулей. Связность модулей.

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

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

Результатом объектной декомпозиции является совокупность объектов, представляющих собой поля и методы, работающие с этими полями.

Таким образом, при любом способе декомпозиции получают набор процедур , которые в процессе реализации организуют в модули.