Существуют несколько подходов, но наиболее распространены иерархический и операционный подходы

Планирование порядка разработки модулей.

Планирование.

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

Внешние спецификации должны содержать следующие сведения:

- имя модуля;

- функция, выполняемая модулем;

- список параметров – число и порядок передачи модулю параметров;

- входные параметры – точное описание всех входных параметров (формат, размер, единицы измерений, диапазоны значений);

- выходные параметры – точное описание данных, которые возвращает модуль, здесь же указывается функциональная связь между входными и выходными параметрами, а также выходные данные, которые получаются при неверных входных данных;

- внешние эффекты – дается описание всех внешних событий, происходящих при работе модуля;

- использование внешних областей памяти и глобальных объекто в.

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

Конец этапа проектирования характеризуется следующими условиями:

- известно необходимое число модулей и их спецификации;

- связи между модулями отображены схемой иерархии;

- вся работа проверена пользователями на точность и полноту.

Планирование включает в себя две задачи: планирование порядка разработки модуля и планирование тестов. На этом этапе выбирается последовательность программирования и тестирования модулей.

Иерархический подход.

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

Используя иерархический подход, не нужно забывать о двух вещах:

- необходимость использовать в модуле данные, подготовленные или измененные другим модулем, то есть зависимость по данным, может затруднить программирование и тестирование при иерархическом подходе;

- слепое следование поуровневому подходу приводит к реализации основной массы модулей в конце проекта.

Операционный подход.

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

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

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

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

Кроме этого, при определении порядка разработки модулей следует учитывать следующие рекомендации:

- обеспечить готовность вспомогательных модулей в первую очередь;

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

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

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

Пример планирования для схемы на рисунке 1.

Последовательность разрабатываемых модулей.

1. «Обработать запрос» – головной модуль.

2. «Вывести ответ» – необходим при тестировании.

3. «Подготовить ответ», «Анализ», «Получение информации» – как наиболее сложные.

4. «Ввести запрос», «Признать», «Проверить» – как наиболее простые.

Дата добавления: 2014-01-06