Технология разработки программного обеспечения. Зубкова Т.М. - 19 стр.

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