Модульное программирование
ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ ПРОГРАММ
Введение
Структурное проектирование
Нисходящее проектирование
Модульное программирование
Структурное программирование
2. Объектно-ориентированное проектирование
2.1. Основные понятия объектно-ориентированного проектирования
2.2. Пример объектно-ориентированного проектирования
Выводы
ЛИТЕРАТУРА
1. Марченко А.И., Марченко Л.А. Программирование в среде Turbo Pascal 7.0. – 8-е изд. – К.: ВЕК+, СПб.: КОРОНА принт, 2004. с. 232-238.
2. Ставровский А.Б. Первые шаги в программировании. Самоучитель. – М.: «Вильямс», 2003. с. 113-133.
3. Вирт Н. Алгоритмы и структуры данных. – М.: Мир, 1989.
4. Иванова Г.С. Технология программирования: Учебник для вузов. – М.: Изд-во МГТУ им. Н.Э.Баумана, 2002. -320 с.
Введение
Промышленный подход к разработке программных продуктов породил ряд современных технологий проектирования алгоритмов и программ, среди которых наибольшее распространение получили:
· структурное проектирование программных продуктов;
· информационное моделирование предметной области
и связанных с ней приложений;
· объектно-ориентированное проектирование программных продуктов и др.
Целью данного занятия является изучение основных принципов структурного и объектно-ориентированного проектирования программ
Структурное проектирование
В основе технологии структурного проектирования лежит последовательная декомпозиция, целенаправленное структурирование задачи на отдельные составляющие.
Методы структурного проектирования представляют собой комплекс технических и организационных принципов системного проектирования.
Типичными методами структурного проектирования являются:
· нисходящее проектирование, кодирование и тестирование программ;
· модульное программирование;
· структурное программирование и др.
В зависимости от объекта структурирования различают:
· функционально-ориентированные методы — последовательное разложение задачи или целостной проблемы на отдельные, достаточно простые составляющие, обладающие функциональной определенностью;
· методы структурирования данных.
Для функционально-ориентированных методов в первую очередь учитываются заданные функции обработки данных, в соответствии с которыми определяется состав и логика работы (алгоритмы) отдельных компонентов программного продукта. С изменением содержания функций обработки, их состава, соответствующего им информационного входа и выхода требуется перепроектирование программного продукта. Основной упор в структурном подходе делается на моделирование процессов обработки данных.
Для методов структурирования данных осуществляется анализ, структурирование и создание моделей данных, применительно к которым устанавливается необходимый состав функций и процедур обработки. Программные продукты тесно связаны со структурой обрабатываемых данных, изменение которой отражается на логике обработки (алгоритмах) и обязательно требует перепроектирования программного продукта.
Структурный подход использует:
· диаграммы потоков данных (информационно-технологические схемы) – показывают процессы и информационные потоки между ними с учетом событий, инициирующих процессы обработки;
· интегрированную структуру данных предметной области (инфологическая модель, ER-диаграммы);
· диаграммы декомпозиции – структура и декомпозиция целей, функций управления, приложений;
· структурные схемы – архитектура программного продукта в виде иерархии взаимосвязанных программных модулей с идентификацией связей между ними, детальная логика обработки данных программных модулей (блок-схемы).
.
Нисходящее проектирование
Спецификация задачи служит отправной точкой в создании программы. Нужно понять, какие действия должны быть совершены для решения задачи, описать их на естественном языке и на достаточно высоком уровне абстракции. В программировании уже давно используются специальные языки — языки формальных спецификаций. Однако их изучение требует определенной подготовки. Поэтому ограничимся неформальными спецификациями, но как можно более точными и полными.
Спецификация задачи является ее первичным проектом. От него мы движемся к программе, постепенно уточняя описание.
Постепенное уточнение проектов широко используется во многих отраслях инженерной деятельности и называется методом проектирования сверху вниз (пошаговой детализации или нисходящего проектирования).
В качестве примера рассмотрим проект одевания ребенка.
Первичная цель:
Одеть.
Конкретизация цели на первом шаге:
Одеть нижнюю половину.
Одеть верхнюю половину.
Нижнюю половину можно одеть в два этапа:
Надеть брюки.
Надеть носки и ботинки.
Верхнюю половину можно также одеть в два этапа:
Надеть рубашку.
Надеть куртку.
Окончательный проект выглядит так:
Надеть брюки.
Надеть носки.
Надеть ботинки.
Надеть рубашку.
Надеть куртку.
Метод нисходящего проектирования предполагает последовательное разложение общей функции обработки данных на простые функциональные элементы («сверху-вниз»). В результате строится иерархическая схема, отражающая состав и взаимоподчиненность отдельных функций, которая носит название функциональная структура алгоритма (ФСА) (рис. 1.1).
Последовательность действий по разработке ФСА приложения следующая:
1) определяются цели автоматизации предметной области и их иерархия (цель-подцель);
2) устанавливается состав приложений (задач обработки), обеспечивающих реализацию поставленных целей;
3) уточняется характер взаимосвязи приложений и их основные характеристики (информация для решения задач, время и периодичность решения, условия выполнения и др.);
4) определяются необходимые для решения задач функции обработки данных;
5) 
выполняется декомпозиция функций обработки до необходимой структурной сложности, реализуемой предполагаемым инструментарием.
Подобная структура приложения отражает наиболее важное – состав и взаимосвязь функций обработки информации для реализации приложений, хотя и не раскрывает логику выполнения каждой отдельной функции, условия или периодичность их вызовов.
Разложение должно носить строго функциональный характер, т.е. отдельный элемент ФСА описывает законченную содержательную функцию обработки информации, которая предполагает определенный способ реализации на программном уровне.
Функции ввода-вывода информации рекомендуется отделять от функций вычислительной или логической обработки данных.
По частоте использования функции обработки делятся на:
· однократно выполняемые;
· повторяющиеся.
Степень детализации функций может быть различной, но иерархическая схема должна давать представление о составе и структуре взаимосвязанных функций и общем алгоритме обработки данных. Широко используемые функции приобретают ранг стандартных (встроенных) функций при проектировании внутренней структуры программного продукта.
Уточнение действий при нисходящем проектировании — это, по сути, переход от описания того, что нужно сделать, к тому, как это сделать.
При уточнении действий в процессе проектирования программа разбивается на систему подпрограмм и программных единиц, а также конкретизируется представление данных.
В программировании также применяется метод последовательной модернизации. Сначала проектируется и реализуется упрощенный вариант решения задачи — прототип (однако и для него применяется нисходящее проектирование). Затем спецификации постепенно усложняются, а программа наращивается с соответствующим расширением возможностей, пока не будет получен окончательный вариант.
Модульное программирование
Модульное программирование является естественным следствием проектирования сверху вниз и заключается в том, что программа разбивается на части – модули, разрабатываемые по отдельности. В программировании под модулем понимается отдельная подпрограмма, а подпрограммы часто называются процедурами или процедурами-функциями. Поэтому модульное программирование еще называется процедурным.
Модуль должен обладать следующими свойствами:
· один вход и один выход – на входе программный модуль получает определенный набор исходных данных, выполняет содержательную обработку и возвращает один набор результатных данных, т.е. реализуется стандартный принцип IPO (Input - Process - Output - вход-процесс-выход);
· функциональная завершенность – модуль выполняет перечень регламентированных операций для реализации каждой отдельной функции в полном составе, достаточных для завершения начатой обработки;
· логическая независимость – результат работы программного модуля зависит только от исходных данных, но не зависит от работы других модулей;
· слабые информационные связи с другими программными модулями – обмен информацией между модулями должен быть по возможности минимизирован;
· обозримый по размеру и сложности программный код.
Установить разумные размеры модулей трудно, хотя стоит придерживаться правила: выделять модули, пока это целесообразно. Обычно размеры модуля ограничены несколькими десятками строк кода на языке высокого уровня. Считается, что малый модуль лучше большого, поскольку с увеличением размеров модулей их восприятие и отладка усложняются ускоренными темпами. Кроме того, большие модули часто оказываются взаимозависимыми, и изменения в одном из них влекут необходимость модификации других.
Модули содержат определение доступных для обработки данных, операции обработки данных, схемы взаимосвязи с другими модулями.
Каждый модуль состоит из спецификации и тела. Спецификации определяют правила использования модуля, а тело – способ реализации процесса обработки.
Принципы модульного программирования программных продуктов во многом сходны с принципами нисходящего проектирования: сначала определяются состав и подчиненность функций, а затем — набор программных модулей, реализующих эти функции.
Однотипные функции реализуются одними и теми же модулями. Функция верхнего уровня обеспечивается главным модулем; он управляет выполнением нижестоящих функций, которым соответствуют подчиненные модули.
При определении набора модулей, реализующих функции конкретного алгоритма, необходимо учитывать следующее:
· каждый модуль вызывается на выполнение вышестоящим модулем и, закончив работу, возвращает управление вызвавшему его модулю;
· принятие основных решений в алгоритме выносится на максимально «высокий» по иерархии уровень;
· для использования одной и той же функции в разных местах алгоритма создается один модуль, который вызывается на выполнение по мере необходимости.
В результате дальнейшей детализации алгоритма создается функционально-модульная схема (ФМС) алгоритма приложения, являющася основой для программирования (рис. 1.2).
Состав и вид программных модулей, их назначение и характер использования в программе в значительной степени определяются инструментальными средствами.
Алгоритмы большой сложности обычно представляются с помощью схем двух видов:
· обобщенной схемы алгоритма – раскрывает общий принцип функционирования алгоритма и основные логические связи между отдельными модулями на уровне обработки информации (ввод и редактирование данных, вычисления, печать результатов и т.п.);
· 
детальной схемы алгоритма – представляет содержание каждого элемента обобщенной схемы с использованием управляющих структур в блок-схемах алгоритма, псевдокода либо алгоритмических языков высокого уровня.
Наиболее часто детально проработанные алгоритмы изображаются в виде блок-схем согласно требованиям структурного программирования. При их разработке используются условные обозначения согласно:
· ГОСТ 19.003-80 ЕСПД (Единая система программной документации). Обозначения условные графические,
· ГОСТ 19.002-80 ЕСПД. Схемы алгоритмов и программ. Правила обозначения.