Bilet 32 vopros 1 1. Основные принципы структурного программирования.

Цель структурного программирования — разработка программы, которой присуща определенная структура, основанная на применении принципов структурного программирования. Перечислим эти принципы:

1. Каждый программный модуль (блок, функция, процедура) должен иметь только один вход

и один выход. Это позволяет максимально упростить стыковку модулей в программе.

2. В программах рекомендуется применять 4 типа конструкций: а) последовательность ( модулей, операторов) б) разветвление (условный оператор); в) цикл 1) с предусловием 2) с постусловием 3)выбор из нескольких альтернатив

3. Разработку программ рекомендуется вести сверху — вниз или по нисходящей стратегии. Суть нисходящей стратегии в том, что проектировщик должен приступить к работе, имея только концептуальный, абстрактный замысел о том, что система или программа будет делать. Затем этот замысел постепенно конкретизируется шаг за шагом, тем самым погружаясь в подробности окончательного программного продукта до тех пор, пока не будет достигнуто «дно», под которым понимаются программные модули, реализующие отдельные функции или процедуры преобразования данных.

Основные принципы структурной методологии:

1. Принцип абстракции.

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

2. Принцип формальности.

Он предполагает строгий методический подход к программированию, придает творческому процессу определенную строгость и дисциплину

3. Принцип модульности.

В соответствии с этим принципом программа разделяется на отдельные законченные фрагменты, модули, которые просты по управлению и допускают независимую отладку и тестирование. В результате отдельные ветви программы могут создаваться разными группами программистов.

4. Принцип иерархического упорядочения.

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

Bilet 33 vopros 1 1. Проектирование программ по структурам данных.

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

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

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

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

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

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

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