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

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

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

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

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

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

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

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

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

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

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

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

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

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