Восходящее и нисходящее проектирование пс.
Многоуровневый иерархический подход позволяет проектировать сложные КП по принципу сверху вниз с позиции назначения и наилучшего решения основной целевой задачи всей системы. Это обеспечивает концептуальное единство программ и возможность рационального распределения ресурсов проектирования по мере декомпозиции компонент. Хотя разделение на иерархические уровни требует некоторых затрат, в целом ресурсы используются более эффективно, чем при отсутствии четкой иерархии, за счет экономного построения и упрощения компонент на каждом уровне.
Иногда основному проектированию сверху вниз сопутствует разработка компонент снизу вверх. Разработка начинается с модулей нижнего уровня, далее переходят к разработке модулей следующего уровня иерархии и т.п. Достоинством этого принципа является то, что при переходе к разработке модулей более высокого уровня иерархии модули нижних уровней можно считать готовыми и подключать их к модулям верхнего уровня на стадии отладки. Однако при таком подходе отсутствие целостного взгляда на КП с позиций верхнего уровня, определяющего цели построения комплекса, не позволяет в ряде случаев принимать верные решения, что приводит к повторной разработке или значительной корректировке модулей. Влияние повторной разработки сказывается тем тяжелее, чем выше уровень иерархии, на котором обнаружена ошибка. Разработка КП полностью по принципу снизу вверх возможна лишь для сравнительно небольших групп программ, ограниченных несколькими модулями, когда разработчики способны в любое время оценивать структуру и функции отдельных модулей на всех уровнях иерархии. Поэтому при разработке сложных КП, содержащих сотни модулей, наиболее рациональным принципом является проектирование сверху вниз.
Базовые управляющие структуры.
В 1968 году Э. Дейкстра в противовес необоснованно частому использованию программистами оператора безусловного перехода goto выдвинул принципы структурного программирования:
1) Каждый программный модуль (блок, функция, процедура) должен иметь только один вход и только один выход.
2) В программах разрешается применять только следующие 4 типа управляющих конструкций:
3) Программы разрабатываются по нисходящей стратегии.
Общие правила структурного построения пс.
Комплексы программ создаются на основе модульно-иерархической структуры, состоящей из программных и информационных модулей. На начальных этапах разработки КП формируются его структура и общие правила взаимодействия компонент, которые состоят в следующем[8,24,26]:
- должна быть унифицирована структура КП и правил оформления описания каждого программного и информационного модуля;
- каждый модуль характеризуется функционнальной законченностью, автономностью независимостью в оформлении от модулей, которые его используют и которые он вызывает;
- применяются стандартные правила организации связей по управлению и информации с другими модулями;
- комплексы программ разрабатываются в виде совокупности небольших по количеству операторов (до 100) программных модулей, связанных иерархическим образом, что дает возможность полностью и отностиельно просто уяснить функцию и правила работы отдельных частей и КП в целом;
- должен отсутствовать эффект последействия очередного исполнения программы на последующие исполнения;
- регламентировано использование локальных переменных и регистров ЭВМ, на которой реализуется КП.
Ниже эти правила детализируются правилами связи программных модулей по управлению, информации и организации типовой структуры программного модуля.
Правила связи программных модулей по управлению:
Передача управления вызываемому модулю всегда осуществляется через его начало, т.е. через первый оператор или команду.
По окончании исполнения вызываемого модуля управление передается в ввызывающий модуль на оператор, следующий непосредственно за оператором вызова.
Модули низших уровней или одного уровня иерархии могут вызываться для исполнения только модулями высших уровней, т.е. модули низших уровней не могут вызывать модули высших уровней, а модули одного уровня - вызывать друг друга.
Для исполнения модуля с некоторой внутренней точки вызов осуществляется стандартным образом ( через первый оператор ), а точка начала задается в виде параметра. При этом в начале вызываемого модуля должен стоять переключатель, который обеспечивает передачу управления к внутренним точкам входов по параметру, указанному при обращении.
В любом модуле должна быть предусмотрена возможность подключения контрольных и отладочных средств; операторы реализующие эти средства, обычно сосредотачиваются в конце модуля.
Правила связи программных модулей по информации:
Информация зон глобальных переменных доступна для использования любым модулям, входящим в КП или группу программ в соответствии с областью действия зоны глобальных переменных, т.е. глобальные переменные могут быть доступны не для всего КП, а лишь для указанной в описании группы модулей.
Локальные переменные доступны лишь в пределах того модуля, в котором они определены либо объявлены.
Для взаимодействия вызываемых и вызывающих модулей создаются зоны обменных переменных, информация из которых доступна лишь модулям, непосредственно связанным по управлению.
Запрешается использовать для обмена информацией между модулями регистры и ячейки памяти, используемые как регистры, т.е. после окончания работы вызываемого модуля считается, что регистры не содержат информации, являющейся результатом его работы.
Информация, находящаяся в регистрах вызывающего модуля при вызове, должна быть сохранена на период выполнения вызываемого модуля и восстановлена при возврате управления в вызывающий модуль. Сохранение регистров может осуществлять как вызывающий, так и вызываемый модуль, однако принятое соглашение должно соблюдаться при всех вызовах модулей.
Языки программирования.
Фортран, Алгол, ПЛ/1, Паскаль, Ада, Модула, Си и т.п.
Достоинства и недостатки.
Абстрактная машина фон-Неймана была и остается основной моделью вычислений в программировании [159]. В последние годы все более заметной становится точка зрения (см. напр.[114]), согласно которой процедурное программирование имеет в своих основаниях особенности, которые часто выступают как принципиальные ограничения, и потому предлагается брать за основу либо уже существующие, но отличные от машины фон-Неймана модели вычислений, либо искать новые и на их основе строить теорию и практику конструирования вычислений[90]. При этом выбор парадигмы программирования во многом определяется не соответствующей только моделью вычислений, но и зависит от точки зрения на природу программирования ([16], [18], [67], [89], [150]). Так например согласно весьма распространенной инженерной точке зрения, программа - это вид промышленного изделия и требует для своего изготовления специальной технологии (по аналогии с проектированием узлов и механизмов). Как отмечается в [18], характерной особенностью инженерного подхода является его эмпиричность, наиболее ярко проявляющаяся в вопросе правильности: заключение о правильности программы при данном подходе выносится при ее испытании (отладке) - предлагается вначале создать программу, а затем экспериментально продемонстрировать ее соответствие решаемой задаче. Заметим, что хотя процесс отладки является одним из самых трудоемких и дорогих зтапов конструирования программ (не гарантирующим при этом от отсутствия ошибок), он остается наиболее распространенным способом подтверждения правильности программ.
Наряду с традиционным инженерным подходом имеются другие точки зрения на природу и методологию программирования, например, идея конструирования программ, правильных по построению. Одним из подходов, в котором эта идея реализуется наиболее последовательно, является доказательное программирование. Согласно исходным положениям этого подхода процесс построения программ обязятельно должен включать в себя (в явной или неявной форме) доказательство ее правильности (в том смысле как доказательство понимается в математике). Таким образом, деятельность программиста при доказательном программировании приобретает не только инженерный, но и прикладной математический характер.
На пути доказательного программирования встает ряд проблем [90], касающихся автоматизации перехода от формальной постановки (спецификации) задачи к алгоритму (программе). Главной трудностью здесь является различие в природе этих конструкций: обычно спецификация - это описание того, что решать, и поэтому она имеет декларативный, а не алгоритмический характер. Здесь возможны по крайней мере два способа преодоления данного препятствия:
а) придерживаясь традиционной процедурной модели вычислений, найти доказательные методы перехода от спецификаций к программам;
б) отказаться от фоннеймановской модели вычислений и найти такую, в рамках которой спецификации могли бы выполняться непосредственно (дескриптивную модель).
Заметим, что если в случае а) систематический метод допускает полную автоматизацию - синтез программ, то этот метод вместе с машиной фон-Неймана может рассматриваться как новая модель вычислений. С другой стороны, и для новых моделей может возникнуть задача правильного перехода от спецификаций к программам при условии, что язык спецификаций шире, чем язык программ. В результате смысл дескриптивных моделей (и синтеза программ) сводится к тому, что отпадает необходимость "ручного" извлечения алгоритма (программы) из спецификации задачи, и, следовательно, проблема правильности программы сводится к проблеме адекватности формальной формулировки задачи и ее содержательной постановки, к проблеме, относящейся уже к методологии и философии науки [90].