Читаем Технологии программирования полностью

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

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

7.2.2. Понятие заглушки модуля

При структурном программировании программа в основном реализуется (собирается и тестируется) сверху вниз. Сначала из 20–30 модулей пишется ядро. Чтобы начать тестировать, недостающие модули нижних уровней заменяются заглушками. По окончании тестирования ядра, заглушки заменяются новыми готовыми модулями, но если программа еще не закончена, то для успешной ее линковки понадобятся все новые заглушки недостающих модулей. Теперь можно приступать к тестированию собранной части и т. д.

Заглушка — это макет модуля. Самая простая заглушка — это подпрограмма или функция без действий. Более сложная заглушка может выводить сообщение о том, что отработал такой-то модуль. Еще более сложные заглушки могут выводить входную информацию в какой-нибудь файл отладки. Наконец, еще более сложные заглушки выдают на выход тестовую информацию, необходимую для проверки уже реализованных модулей.

Написание заглушек — "лишняя" работа, но требуется искусство проектировщика, чтобы максимальное количество заглушек были простыми, а тестирование уже собранной части программы было бы полным.

7.2.3. Средства изменения топологии иерархии программы

В процессе нисходящего проектирования рациональной иерархии модулей программы необходимо получить оптимальную подчиненность.

Схеме иерархии можно придать любой топологический рисунок. Так, схеме иерархии, изображенной на рис. 7.2, а, можно придать вид, изображенный на рис. 7.2, б.

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

Рис. 7.2. Схема иерархии одной и той же программы: а — с вертикальными вызовами; б — с горизонтальными вызовами

Фрагменты с горизонтальными вызовами на одном уровне могут быть преобразованы в вертикальные вызовы модулей разных уровней посредством введения дополнительных переменных. Эти переменные не могут быть получены путем декомпозиции функционального описания на подфункции. Эти дополнительные переменные обычно имеют тип целый или логический и называются флагами (семафорами, ключами) событий. Их смысл обычно характеризуется фразой: "В зависимости от предыстории действий, выполнить такие-то действия".

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

7.2.4. Критерии оценки качества схемы иерархии

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

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

Каждый новый вариант сравнивается с предшествующим вариантом по описанным здесь критериям. Генерация вариантов прекращается при невозможности дальнейших улучшений.

Фонд критериев оптимальности схем иерархии является необходимым подспорьем при оптимизации схем иерархии и состоит из 13 критериев.

Первый — полнота выполнения специфицированных функций.

Второй — возможность быстрого и дешевого пополнения новыми, ранее не специфицированными функциями.

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

Четвертый критерий оценки качества структуры — максимальная независимость по данным отдельных частей программы.