Структурное программирование и проектирование программ

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

· определяются цели автоматизации предметной области и их иерархия (цель-подцель);

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

· уточняется характер взаимосвязи приложений и их основные характеристики (информация для решения задач, время и периодичность решения, условия выполнения);

· определяются необходимые для решения задач функции обработки данных;

· выполняется декомпозиция функций обработки до необходимой
структурной сложности.

Структурное программирование включает три составляющие: проектирование сверху вниз или нисходящее проектирование программ; модульное программирование и структурное кодирование.

Нисходящее проектирование программ

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

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

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

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

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

Модульное программирование

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

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

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

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

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

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

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

Структурное кодирование

Третьим составным элементом структурного программирования является структурное кодирование, которое представляет собой метод написания хорошо структурированных программных модулей, удобных для тестирования, модификации и использования. Метод предусматривает написание программных модулей произвольного размера и сложности на основе ограниченного множества базисных логических структур. Метод аналогичен принципу, положенному в основу проектирования схем, где любая логическая структура может быть создана из элементарных структур И, ИЛИ и НЕ. Структурное кодирование базируется на строго доказанной теореме о структурировании, которая утверждает, что любую правильную программу (с одним входом и одним выходом, без зацикливаний и недостижимых команд) можно написать с использованием следующих логических структур: последовательности двух или более операторов; выбора одного из двух операторов (IF THEN, ELSE); повторения (или управления
циклом) оператора, пока выполняется некоторое условие (DO WHILE).