1. Структурный подход к программированию

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

Впервые термин «структурное программирование» ввел Эдсгер Дейскстра. Он рассматривал программу как совокупность иерархических абстрактных уровней, которые позволяли четко структурировать программу, выполнять доказательства при ее корректировке, а значит, и повышать надежность функционирования программы, и сокращать сроки ее разработки.

Э. Дейкстра указывал: «Оператор GOTO нужно считать вредным». Его поддержали ученые Н. Вирт (Цюрих) и Хоар (Оксфорд).

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

1.1. Цели структурного программирования

Обеспечение дисциплины программирования («Структурное программирование - это дисциплина, которую программист навязывает сам себе», – утверждал Э. Дейкстра).
Повышение эффективности (например, разбиение на относительно независимые модули).
Повышение надежности (облегчение тестирования и отладки).
Уменьшение времени и стоимости (повышение производительности программистов).
Улучшение читабельности программы.

1.2. Основные принципы структурного подхода

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

Структурный подход включает в себя три основные составные части:

– нисходящее проектирование;

– структурное программирование;

– сквозной структурный контроль.

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

Делить программу на модули необходимо, учитывая следующие свойства (или требования) модулей:

1. Возможность обособления модуля в исходном и объектном кодах.

2. Наличие имени у модуля и возможность вызова по имени.

3. Модуль должен иметь один вход и один выход.

4. Модуль должен возвращать управление в ту точку, откуда был вызван.

5. Модуль должен иметь возможность вызывать другие модули.

6. Внутренний текст модуля должен быть структурирован (представлять комбинацию простых структур).

7. Модуль должен быть обозрим в исходном тексте (желательно чтобы он помещался на одной странице).

8. Модуль не использует историю своих вызовов для управления своим функционированием (сколько бы мы ни вызывали модуль, он делает одно и то же).

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

10. Модуль должен иметь минимальную возможность обмена информацией с другими модулями.

11. Модуль может использовать глобальные объекты, но не должен их менять (без необходимости).

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

П р и м е р (рис. 1.1). Если функции F1, F2, F3 реализованы отдельно, но основной модуль может обращаться к ним, тогда модуль хорошо организован.

Общая функция системы

Первый уровень