ВУЗ:
Составители:
Рубрика:
подход может рассматриваться как путь борьбы с дублированием в програм-
мировании. В связи с этим программные модули, создаваемые в рамках ар-
хитектурного подхода, обычно параметризуются для того, чтобы усилить
применимость таких модулей путем настройки их на параметры.
Спецификация программы
(головного модуля)
Текст головного модуля
Спецификация
1-ой подзадачи
Спецификация
3-ей подзадачи
Текст
головного модуля
1-ой подзадачи
Текст
головного модуля
3-ей подзадачи
Текст
головного модуля
2-ой подзадачи
Спецификация
2-ой подзадачи
Спецификация
2.1-ой подзадачи
Спецификация
2.2-ой подзадачи
Рисунок 1.6 - Второй шаг формирования модульной структуры про-
граммы при конструктивном подходе.
В классическом методе нисходящей разработки рекомендуется снача-
ла все модули разрабатываемой программы запрограммировать, а уж затем
начинать нисходящее их тестирование, что опять-таки находится в полном
соответствии с водопадным подходом. Однако такой порядок разработки не
представляется достаточно обоснованным: тестирование и отладка модулей
может привести к изменению спецификации подчиненных модулей и даже к
изменению самой модульной структуры программы, так что в этом случае
22
подход может рассматриваться как путь борьбы с дублированием в програм- мировании. В связи с этим программные модули, создаваемые в рамках ар- хитектурного подхода, обычно параметризуются для того, чтобы усилить применимость таких модулей путем настройки их на параметры. Спецификация программы (головного модуля) Текст головного модуля Спецификация Спецификация 1-ой подзадачи 3-ей подзадачи Текст Текст головного модуля головного модуля 1-ой подзадачи 3-ей подзадачи Спецификация 2-ой подзадачи Текст головного модуля 2-ой подзадачи Спецификация Спецификация 2.1-ой подзадачи 2.2-ой подзадачи Рисунок 1.6 - Второй шаг формирования модульной структуры про- граммы при конструктивном подходе. В классическом методе нисходящей разработки рекомендуется снача- ла все модули разрабатываемой программы запрограммировать, а уж затем начинать нисходящее их тестирование, что опять-таки находится в полном соответствии с водопадным подходом. Однако такой порядок разработки не представляется достаточно обоснованным: тестирование и отладка модулей может привести к изменению спецификации подчиненных модулей и даже к изменению самой модульной структуры программы, так что в этом случае 22
Страницы
- « первая
- ‹ предыдущая
- …
- 20
- 21
- 22
- 23
- 24
- …
- следующая ›
- последняя »