ВУЗ:
Составители:
Рубрика:
подход может рассматриваться как путь борьбы с дублированием в програм-
мировании. В связи с этим программные модули, создаваемые в рамках ар-
хитектурного подхода, обычно параметризуются для того, чтобы усилить
применимость таких модулей путем настройки их на параметры.
Спецификация программы
(головного модуля)
Текст головного модуля
Спецификация
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
- …
- следующая ›
- последняя »
