Разработка модульной структуры программы

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

Рис. 2.10. Пример иерархического дерева модулей

При этом модульная структура программы должна, помимо картинки, включать спецификацию программного модуля.

Спецификация программного модуля должна содержать:

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

- функциональную спецификацию (описание семантики функций, выполняемых модулем по каждому из его входов).

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

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

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

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

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