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

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

     1.6 Методы проектирования программных средств

       Наиболее распространенными и применимыми являются: метод вос-
ходящей разработки и метод нисходящей разработки ПС.
       Метод восходящей разработки заключается в следующем. Сначала
строится модульная структура программы в виде дерева. Затем поочередно
программируются модули программы, начиная с модулей самого нижнего
уровня (листья дерева модульной структуры программы), в таком порядке,
чтобы для каждого программируемого модуля были уже запрограммированы
все модули, к которым он может обращаться. После того, как все модули
программы запрограммированы, производится их поочередное тестирование
и отладка в принципе в таком же (восходящем) порядке, в каком велось их
программирование. Такой порядок разработки программы на первый взгляд
кажется вполне естественным: каждый модуль при программировании выра-
жается через уже запрограммированные непосредственно подчиненные мо-
дули, а при тестировании использует уже отлаженные модули. Однако, со-
временная технология не рекомендует такой порядок разработки программы.
Во-первых, для программирования какого-либо модуля совсем не требуется
наличия текстов используемых им модулей − для этого достаточно, чтобы
каждый используемый модуль был лишь специфицирован (в объеме, позво-
ляющем построить правильное обращение к нему), а для тестирования его
возможно (и даже, как мы покажем ниже, полезно) используемые модули за-
менять их имитаторами (заглушками, драйверами). Во-вторых, каждая про-
грамма в какой-то степени подчиняется некоторым внутренним для нее, но
глобальным для ее модулей соображениям (принципам реализации, предпо-
ложениям, структурам данных и т.п.), что определяет ее концептуальную це-
лостность и формируется в процессе ее разработки. При восходящей разра-
ботке эта глобальная информация для модулей нижних уровней еще не ясна
в полном объеме, поэтому очень часто приходится их перепрограммировать,
когда при программировании других модулей производится существенное
уточнение этой глобальной информации (например, изменяется глобальная
структура данных). В-третьих, при восходящем тестировании для каждого
18