Cтраница 4
На рис. 3.5 показаны все основные этапы планирования и реализации при разработке программы. На стадии планирования устанавливается порядок разработки и тестирования модулей. Этот порядок может не следовать строго ни уровням схемы иерархии, ни порядку исполнения - это обычно комбинация иерархического и операционного подходов. [46]
Случается, что на этапе реализации, когда начинается подробное программирование, модули в этой схеме могут объединяться или разделяться на модули меньшего размера. Пусть, например, при программировании обнаружилось, что необходимо поместить на нижний уровень модули ЧИТАТЬ СТАРЫЙ ГЛАВНЫЙ и ПИСАТЬ НОВЫЙ ГЛАВНЫЙ, поскольку они могут активизироваться только модулями более высокого уровня. На самом деле эти модули будут реализованы, конечно, только один раз, поскольку одна из задач схемы иерархии - показать подчиненность модулей; именно эта подчиненность и отражена с помощью повторного изображения модулей. [47]
Такое отступление не является нарушением принципа сверху вниз. Нисходящая разработка означает, что модули верхнего уровня пишутся и объединяются ранее подчиненных им модулей. Из рис. 3.1 видно, что модуль ВВЕСТИ пишется ранее подчиненных ему модулей. Если одна ветвь схемы иерархии целиком разрабатывается ранее модулей высшего уровня ( из других ветвей), то мы повышаем качество тестирования и, скорее всего, сокращаем затраты на программирование. [48]
![]() |
Блок-схема начисления удержаний. [49] |
Уровни абстракции определяют уровни модулей в программе. На этапе проектирования строится схема иерархии, изображающая эти уровни. По внешнему виду она напоминает организационную схему. Их логическое сходство усиливается тем, чю схема иерархии отражает функции и взаимодействие модулей. Каждый прямоугольник в ней изображает функцию или модуль. [50]
Каждый шаг этого процесса включает в себя разложение функции модуля на подфункции. В конечном итоге эти подфункции превращаются в шаги нужной программы. Этот процесс подобен нисходящему проектированию программы, при котором схема иерархии используется как средство разложения программы на составляющие ее модули. Схема иерархии показывает, конечно, функции и их подчинение, но она не проявляет внутреннюю логику каждого модуля. Пошаговая детализация применяется для декомпозиции функции каждого модуля в соответствии с внутренней логикой, необходимой для выполнения модулем этой функции. [51]
Каждый шаг этого процесса включает в себя разложение функции модуля на подфункции. В конечном итоге эти подфункции превращаются в шаги нужной программы. Этот процесс подобен нисходящему проектированию программы, при котором схема иерархии используется как средство разложения программы на составляющие ее модули. Схема иерархии показывает, конечно, функции и их подчинение, но она не проявляет внутреннюю логику каждого модуля. Пошаговая детализация применяется для декомпозиции функции каждого модуля в соответствии с внутренней логикой, необходимой для выполнения модулем этой функции. [52]
![]() |
Блок-схема начисления удержаний. [53] |
В ней отражены правила начисления удержаний и последовательность их расчета. С другой стороны, схема иерархии, приведенная на рис. 2.4, описывает лишь функции и их взаимосвязь в программе. Проявлена группировка функций, отсутствующая на блок-схеме. Каждое удержание выделено в самостоятельный модуль, и все они являются детализацией более общего ведущего модуля ВЫЧИСЛИТЬ УДЕРЖАНИЯ. Блок-схема пока-зывает процедуру, схема иерархии - функцию. [54]
В этой главе вводится одно из новых средств проектирования программ - схема иерархии. Разложение программы на составляющие ее модули требует умения переходить от общего к частному. Сначала определяются модули в соответствии с их функциями. При этом нужно руководствоваться принципом один модуль - одна функция. Затем модули объединяются в схему иерархии, основанную на понятии уровня абстракции. [55]
На рис. 8.1 представлена схема иерархии некоторых модулей в программе, обслуживающей расчеты с покупателями. Каждый прямоугольник в схеме представляет некоторый модуль этой программы. Каждый из этих модулей - внешняя процедура, которая может содержать любое количество внутренних процедур. Модули разрабатывались нисходящим методом, причем каждая ветвь этой схемы почти наверняка была полностью завершена до начала детального проектирования, программирования и тестирования следующих ветвей. Предположим, что самая левая ветвь на схеме иерархии завершена и, двигаясь вниз по схеме, мы оказались на стадии программирования модуля ( заштрихован на рис. 8.1), который составляет регистр счетов. [56]
Зависимость по данным может существовать и между модулями разных уровней. Например, ПОДГОТОВИТЬ может зависеть от, данных, вводимых модулем ПРОЧЕСТЬ. Если используется поуровневый метод, то модуль ПОДГОТОВИТЬ нельзя тестировать полностью - он пишется раньше модуля ПРО-ЧЕСТЬ. Такая организация может, однако, оказаться нелогичной или получится схема иерархии с неоправданно большим количеством модулей на одном уровне. [57]
Модуль может вызывать другой модуль уровнем ниже; он не может вызывать модуль своего уровня или выше. Однако он может вызывать сам себя - это случай рекурсивного программирования. Подобные связи упрощают межмодульный обмен данными. Однако иногда возникает потребность активизировать модуль, расположенный несколькими уровнями ниже. Это разрешено, но в таком случае модуль должен быть указан в схеме несколько раз на соответствующих уровнях. Такие модули следует специально отмечать на схеме иерархии. [58]