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

Челябинский юридический колледж

Кафедра информатики и вычислительной техники

 

 

 

 

 

 

КУРСОВАЯ РАБОТА

по дисциплине «технические разработки программных продуктов»

 

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

 

 

 

 

Студент гр. ПО 1-3-09

программное обеспечение ВТ и АС    ___________________    Р.С. Терентьев

                                                                «__» ________________2012

Преподаватель                                       ___________________    А.А. Гришаев

             «__» _________________2012

Рецензент                                               ____________________  А.А. Гришаев                            «__» _________________2012

 

 

 

 

 

 

2012

Оглавление

Введение …………………………………….....…………………………...3

1. Теоретические  аспекты модульного программирования  ………………..….6

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

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

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

1.3.1 Функциональная декомпозиция ……………………………………….....22

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

1.3.3 Минимизации количества необходимых вызовов  …………..…….25

1.4 Методы разработки структуры модульной программы ...………….....….27

1.5 Контроль структуры модульной программы  ...…………………..…34

2. Практическая  часть. Код программы "Блокиратор рабочего стола" …….35

Заключение ……………………………………………………………….38

Список исползуемых источников …...………………………..………....39

 

Введение

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

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

Процедурное программирование. Основная идея этого стиля – алгоритмизация процесса решения задачи и выбор наилучшего алгоритма (по расходу памяти или по быстродействию). Реализация этой идеи началась с 1957 года с появлением алгоритмических языков Fortran и затем Algol-60, когда все большее и большие число специалистов занялось решением достаточно сложных инженерных и научных задач. И нужен был стиль программирования максимально близкий к человеческому (математическому) стилю. При этом знание тонкостей архитектуры ЭВМ не требовалось. Программа на алгоритмическом языке (при наличии соответствующих трансляторов) должна была в идеале работать на ЭВМ любой архитектуры. Но это были программы прикладные. Разработку же системных программ (самих трансляторов, систем ввода-вывода) по-прежнему надо было делать на Ассемблере.

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

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

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

Объектно-ориентированное программирование. С середины 80-х годов объем исходного программного кода перешел рубеж в 100 000 строк. Нужно было сделать не случайное объединение данных и алгоритмов их обработки в единое целое, а - смысловое. То есть необходимо было создать модульное программирование нового уровня, когда основной акцент делается на смысловую связь структур данных и алгоритмов их обработки. Сейчас практически все основные языки программирования (их более 100, в том числе такие распространенные, как Object Pascal, C++, Smalltalk) базируются на этой идее, а предком их является язык Simula, созданный еще в 1960 году.

Обобщенные технологии разработки приложений. Идеология объектно-ориентированного программирования породила CASE-технологии разработки и сборки программ на основе уже известных программных моделей, содержащих интерфейсы и прототипы (шаблоны — template) данных: COM (Component Object Model), STL (Standard Template Library), ATL (Active Template Library). Все эти новшества поддерживают визуальные среды разработки, например, такие известные, как Visual C++, Borland C++ Builder, Borland Delphi.

Теперь  подробно рассмотрим технологию модульного программирования.

 

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

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

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

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

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

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

- упрощение разработки и реализации программ

- улучшение «читаемости» программ

- упрощение настройки и модификации программ

- упрощение работы с данными, имеющими сложную структуру

- избежание чрезмерной детализации алгоритмов

- более выгодное размещение программ в памяти ЭВМ

Модуль  может получать и возвращать данные через общие области памяти или  параметры.

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

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

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

Практика  показала, что чем выше степень  независимости модулей, тем:

- легче разобраться в отдельном модуле и всей программе и, соответственно, тестировать, отлаживать и модифицировать ее

- меньше вероятность появления новых ошибок при исправлении старых или внесении изменений в программу

- проще организовать разработку ПО группой программистов и легче его сопровождать.

Не всякий программный модуль способствует упрощению  программы. Для оценки приемлемости выделенного модуля используются некоторые  критерии.

Хольт предложил следующие общие критерии:

- хороший модуль снаружи проще, чем внутри

- хороший модуль проще использовать, чем построить.

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

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

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

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

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

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

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

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

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

Степень независимости модулей (как подпрограмм, так и библиотек) оценивают сцеплением и связностью.

Сцепление, или связанность, модулей – мера их взаимозависимости.

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

Типы  сцепления модулей:

- по данным: модули взаимодействуют через передачу параметров; каждый параметр – элементарный информационный объект. Это наиболее предпочтительный тип связанности модулей.