ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ ПРОГРАММ

Введение

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

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

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

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

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).

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

Алгоритмы большой сложности обычно представляются с помощью схем двух видов:

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

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

МИНОБРНАУКИ РОССИИ

Реферат

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

Введение

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

Машинно-ориентированное программирование появилось одновременно с созданием электронных вычислительных машин. Сначала это были программы в машинных кодах, затем появился язык программирования Assembler (Автокод), который немного «очеловечил» написание программы в машинном коде.

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

Структурное программирование. Здесь основная идея прекрасно выражена Н. Виртом в его книге "Алгоритмы + структуры данных = программы". Это был ответ на кризис в области программирования, начавшийся в середине 60-х годив, когда объем исходного программного кода перешел рубеж в 1000 строк. В 1971 году появился алгоритмический язык Pascal и немного позже, в 1972 году, язык С..

Модульное программирование. Здесь основная идея заключалась в том, чтобы "спрятать" данные и процедуры внутри независимых программных единиц - модулей. Эту идею впервые реализовал Н. Вирт в алгоритмическом языке Modula (1975-1979 годы), а затем "подхватили" и остальные, распространенные в то время языки программирования. Например, известные системы программирования Turbo Pascal и Turbo С.

Объектно-ориентированное программирование. С середины 80-х годов объем исходного программного кода перешел рубеж в 100 000 строк. Нужно было сделать не случайное объединение данных и алгоритмов их обработки в единое целое, а - смысловое. То есть необходимо было создать модульное программирование нового уровня, когда основной акцент делается на смысловую связь структур данных и алгоритмов их обработки

модуль программирование проектирование декомпозиция

1. Цель модульного программирования

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

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

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

2. Основные характеристики программного модуля

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

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

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

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

Сцепление модуля - это мера его зависимости по данным от других модулей. Характеризуется способом передачи данных. Чем слабее сцепление модуля с другими модулями, тем сильнее его независимость от других модулей. Для оценки степени сцепления Майерс предлагает упорядоченный набор из шести видов сцепления модулей. Худшим видом сцепления модулей является сцепление по содержимому . Таким является сцепление двух модулей, когда один из них имеет прямые ссылки на содержимое другого модуля (например, на константу, содержащуюся в другом модуле). Такое сцепление модулей недопустимо. Не рекомендуется использовать также сцепление по общей области - это такое сцепление модулей, когда несколько модулей используют одну и ту же область памяти. Единственным видом сцепления модулей, который рекомендуется для использования современной технологией программирования, является параметрическое сцепление (сцепление по данным по Майерсу) - это случай, когда данные передаются модулю либо при обращении к нему как значения его параметров, либо как результат его обращения к другому модулю для вычисления некоторой функции. Такой вид сцепления модулей реализуется на языках программирования при использовании обращений к процедурам (функциям).

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

o всегда следует использовать рутинный модуль, если это не приводит к плохим (не рекомендуемым) сцеплениям модулей;

o зависящие от предыстории модули следует использовать только в случае, когда это необходимо для обеспечения параметрического сцепления;

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

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

3. Проектирование модуля

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

Для получения максимальных преимуществ от использования модульного программирования каждая подпроблема или модуль должны иметь один вход и один выход. В этом случае можно легко отслеживать поток управления в программе.

3. 1 Функциональная декомпозиция

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

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

3.2 Минимизации количества передаваемых параметров

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

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

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

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

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

3.3 Минимизации количества необходимых вызовов

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

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

Заключение

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

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

Все ресурсы модуля делятся на две группы: внешние - предназначенные для использования другими программными единицами, и внутренние - рабочие ресурсы данного модуля.

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

Размещено на Allbest.ru

Подобные документы

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

реферат , добавлен 29.01.2016


Характеристика модульного программирования: процедуры и функции, модули и их структура, открытые массивы и строки, нетипизированные параметры. Способы передачи параметров в подпрограммы в Borland Pascal. Объектно-ориентированное программирование.

контрольная работа , добавлен 28.04.2009


Сущность программирования с использованием среды Delphi 7 и ее основные графические возможности. Структура автономно компилируемого программного модуля и его принципы. Основные приемы работы с графическими процедурами, построение дуги, круга и эллипса.

курсовая работа , добавлен 16.12.2011


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

презентация , добавлен 14.10.2013


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

презентация , добавлен 05.11.2016


Предмет исследования – современные методы разработки программ таких, как объектно-ориентированное программирование и визуальное проектирование, а также структурное и модульное программирование. C++ - универсальный язык программирования. Ключевые понятия.

курсовая работа , добавлен 10.01.2009


Почему C++. Возникновение и эволюция языка C++. Сравнение языков С++ и С. Эффективность и структура. Процедурное программирование. Модульное программирование. Абстракция данных. Объектно-ориентированное программирование. Улучшенный С.

реферат , добавлен 03.06.2004


Обзор технологий и систем геоинформационных систем. Системное и функциональное проектирование программного модуля, его разработка с использованием сред программирования Visual C++ 6.0, Qt 3.3.3. Технико-экономическое обоснование данного процесса.

дипломная работа , добавлен 13.03.2011


Проектирование программного модуля в среде программирования Borland Delphi 7.0. Схемы алгоритмов решения задач по темам "Символьные переменные и строки", "Массивы", "Работа с файлами", "Создание анимации". Реализация программного модуля, код программы.

отчет по практике , добавлен 21.04.2012


Проектирование информационной системы. Анализ языков программирования и существующих решений для администрирования системы управления базами данных. Разработка модуля взаимодействия и структуры программы. Модули авторизации и соединения с базой данных.

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

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

В основе использования модульной архитектуры лежат три основных концепции:

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

Также имеются дополнительные определения программного модуля.

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

Функциональная спецификация модуля должна включать:

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

Модули также разделяют на три категории:

• - «Маленькие» (функциональные) модули. Они, обычно, реализуют одну или несколько функций. Во всех языках программирования высокого уровня имеется поддержка основного и простейшего модуля: процедуры и функции.
• - «Средние» (информационные) модули, реализующие, в обычном случае, сравнительно небольшое количество операций или функций над так называемым информационным объектом, который считается за пределами модуля неизвестным. Наиболее известные примеры информационных модулей это классы в таких языках программирования как С, С++, С#, Java и другие.
• - «Большие» (логические) модули, которые объединяют в себе некоторое количество как «маленьких» так и «средних» модулей. Примером "больших" модулей в языках программирования могут послужить пакеты или сборки в таких языках программирования, как Java.

Введение

1. Теоретическая часть

1.1.1 Процедуры и функции

1.1.2 Модули

1.1.3 Открытые массивы и строки

1.1.4 Нетипизированные параметры

1.2 Объектно-ориентированное программирование

Заключение

Список литературы

Введение

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

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

1. Построить таблицы по приведенным данным.

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

3. Результаты представить в виде консолидированной таблицы.

4. Сформировать и заполнить форму сводной ведомости.

5. Результаты представить в графическом виде.

Объектом изучения является модульное и объектно-ориентированное программирование.

1. Теоретическая часть

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

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

1.1.1 Процедуры и функции

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

Заголовок блока определяет форму вызова программы. В разделе описаний блока объявляют внутренние локальные ресурсы блока (переменные, типы, внутренние подпрограммы). Раздел операторов содержит инструкции подпрограммы в операторных скобках begin … end.

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

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

Из основной программы данные могут быть получены:

· Неявно – с использованием глобальных констант и переменных;

· Явно – через параметры.

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

В свою очередь локальные ресурсы, объявлены в разделе описания подпрограммы, из программного блока, в разделе описания которого она определена, не доступны. В том случае, если в подпрограмме объявляется ресурс, имя которого совпадает с именем глобального ресурса, соответствующий глобальный ресурс в подпрограмме становится не доступным, «перекрывается».

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

В BorlandPascal параметры в подпрограмму могут передаваться тремя способами:

· Как значения – в подпрограмму передаются копии значений параметров, и никакие изменения этих копий не возвращаются в вызывающую программу;

· Как переменные – в программу передаются адреса фактических параметров, соответственно все изменения этих параметров в подпрограмме на самом деле происходят с переменными, переданными в качестве фактических параметров; такие параметры при описании помечаются служебным словом var; в качестве фактических значений параметров – переменных нельзя использовать литералы;

· Как изменяемые переменные (именованные константы) – в подпрограмму, так же как и в предыдущем случае, передаются адреса фактических параметров, но при попытке изменить значение параметра компилятор выдает сообщение об ошибке; такие параметры при описании помечаются служебным словом const.

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

< переменная> :=< имя функции> (< фактические параметры> ).

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

Вызов процедуры и функции по-разному изображается на схеме алгоритма: вызов функции – в блоке «процесс» или блоке вывода, а для вызова процедуры используется специальный блок «предопределенный процесс». Схемы алгоритмов же самих подпрограмм в обоих случаях оформляются отдельно, причем вместо слова «начало» указывают имя подпрограммы, а вместо слова «конец» - указывают слово «возврат» или «return».

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

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

Все ресурсы модуля делятся на две группы: внешние – предназначенные для использования другими программными единицами, и внутренние – рабочие ресурсы данного модуля.

Структура модуля выглядит следующим образом:

Unit < имя модуля>

Interface

<интерфейсная секция>

[ Begin

<секция инициализации>]

End .

Имя модуля должно совпадать с именем файла, в котором он содержится. Результат компиляции модуля помещается в файл с тем же именем и расширением.tpu.

Примечание. Среда языка BorlandPascal предусматривает три режима компиляции программы, использующей модули:

· Compile – компилируется только основная программа, все модули должны быть предварительно откомпилированы в файлы <имя модуля> .tpu и размещены либо в текущем каталоге, либо в одном из каталогов, указанных как источники файлов.tpu в настройках среды;

· Make – модули, для которых не обнаружены файлы.tpu, компилируются из соответствующих файлов.pas, которые должны находиться в текущем каталоге или в каталогах, указанных в настройках среды в качестве источников исходных файлов модулей;

· Build – все ранее откомпилированные модули.tpu игнорируются и все модули компилируются из своих исходных файлов заново.

В процессе отладки модулей целесообразно использовать режим Build, а при отладке программы – режим Compile

Интерфейсная секция содержит объявление ресурсов (в том числе заголовки подпрограмм), к которым возможны обращения извне.

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

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

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

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

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

Классическая проблема программирования

В западной литературе существует термин «big ball of mud» для описания архитектуры программы. Давайте переведём его дословно. Графически «большой шар грязи» можно представить в виде точек на окружности, символизирующих функциональные элементы, и прямых – связей между ними:

Похоже на ваши глаза перед сдачей проекта, не так ли?

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

Программирование не уникальная дисциплина: здесь можно и нужно применять опыт из других областей. Возьмём, к примеру, компьютер. Их производители не задумываются над многообразием задач, которые решает пользователь, и уж тем более не выделяют под каждую маленький процессор и память. Компьютер – это просто набор независимых сложных объектов, объединённых в одном корпусе при помощи разъёмов и проводов. Объекты не уникальны, не оптимизированы конкретно под вас, и тем не менее блестяще справляются со своей задачей.

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

В этом случае полезнее обратиться к модулям. Модуль – логически завершённый фрагмент кода, имеющий конкретное функциональное назначение. Для взаимодействия модулей используются способы, не позволяющие изменять параметры и функциональность. Плюсы модульного программирования очевидны:

• Ускорение разработки.
• Повышение надёжности.
• Упрощение тестирования.
• Взаимозаменяемость.

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

Но не всё так просто.

Проблемы модульного программирования

Сама по себе идея использования модулей не сильно упрощает код, важно минимизировать количество прямых связей между ними. Здесь мы подходим к понятию «инверсия управления» (IoC). Упрощённо – это принцип программирования, при котором отдельные компоненты кода максимально изолированы друг от друга. То есть детали одного модуля не должны влиять на реализацию другого. Достигается это при помощи интерфейсов или других видов представления, не обеспечивающих прямого доступа к модульному коду.

В повседневной жизни таких примеров множество. Чтобы купить билет на самолёт или узнать время вылета, вам не надо звонить пилоту. Чтобы выпить молока, не надо ехать в деревню или на завод и стоять над душой у коровы. Для этого всегда есть посредники.

В модульном программировании существует три основные реализации:

• Внедрение зависимостей. Способ, при котором каждый элемент имеет свой интерфейс, взаимодействие модулей происходит через интерфейсы.
• Фабричный метод. Основывается на существовании некого объекта, предназначенного для создания других объектов. Иначе говоря, введение в программу прототипа, объединяющего общие черты для большинства объектов. Прямого взаимодействия между модулями нет, все параметры наследуются от «завода».
• Сервисный метод. Создаётся один общий интерфейс, являющийся буфером для взаимодействия объектов. Похожую функцию в реальной жизни выполняют колл-центры, магазины, площадки для объявлений и т.д.

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

Для решения этой проблемы необходимо разработать архитектуру кода. Как правило, она схожа с файловой структурой любого приложения:

Таким образом, поддержка принципов модульного программирования, инверсии управления и четкой архитектуры приложения поможет убить сразу трёх зайцев:

1. Обеспечить чёткое функциональное разделение кода. При возникновении ошибок можно быстро определить источник, а исправления не приведут к появлению новых сбоев.
2. Минимизировать количество связей. Это позволит упростить разработку, отдав на откуп нескольким разработчикам разные модули. Или вы сможете самостоятельно разрабатывать каждый блок без оглядки на другие, что тоже экономит время и силы.
3. Создать иерархию с чёткой вертикалью наследования. Это повышает надёжность кода, так как тестирование провести проще, а результаты информативнее.

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