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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Опишите методологию IDEF0

Метод SADT (IDEF0) представляет собой совокупность правил и процедур, предназначен­ных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.

1. Принципы построения SADT-модели.

Основные элементы этого метода основываются на следующих концепциях:

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

- строгость и точность. Правила SADT включают: ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков), связность диаграмм (но­мера блоков), уникальность меток и наименований (отсутствие повторяющихся имен), синтакси­ческие правила для графики (блоков и дуг), разделение входов и управлений (пра­вило определения роли данных);

- отделение организации от функции, т.е. исключение влияния административ­ной структуры организации на функциональную модель.

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