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

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

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

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

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

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

Студент гр. ПО 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 операторов), независимость от истории вызовов, выполнение одной функции

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- по образцу: один модуль посылает другому составной информационный объект (запись, структура). Это один из допустимых типов связанности модулей.

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

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

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

Связность модуля – мера прочности соединения функциональных и информационных объектов внутри него. Это степень взаимосвязи элементов и направленности модуля на решение определенной задачи. Чем выше связность модуля, тем меньше «ручек управления» на модуле и тем он проще. При проектировании модулей нужно стремиться к высокой связности, так как чем выше связность, тем лучше спроектирован модуль. Размещение сильно связанных элементов в одном модуле уменьшает межмодульные связи и, соответственно, взаимовлияние модулей. В то же время помещение сильно связанных элементов в разные модули не только усиливает межмодульные связи, но и усложняет понимание их взаимодействия. Объединение слабо связанных элементов также уменьшает технологичность модулей, так как такими элементами сложнее мысленно манипулировать.

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

- функциональная: все объекты модуля предназначены для выполнения одной функции; операции, объединяемые для выполнения одной функции, или данные, связанные с одной функцией. Модуль, элементы которого связаны функционально, имеет четко определенную цель, при его вызове выполняется одна задача, например, подпрограмма поиска минимального элемента массива. Такой модуль имеет максимальную связность, следствием которой являются его хорошие технологические качества: простота тестирования, модификации и сопровождения. Именно с этим связано одно из требований структурной декомпозиции «один модуль – одна функция».

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

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

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

- временная: объекты модуля привязаны к конкретному промежутку времени (например, модуль, осуществляющий инициализацию процесса). Элементы модуля связаны только тем, что они должны выполняться в определенное время.

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

- случайная (по совпадению): связь между элементами модуля мала или отсутствует. Такой модуль имеет самые низкие показатели технологичности.

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

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

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

Как разработать  хороший модуль, который действительно  будет способствовать упрощению  программы?

В литературе приводятся различные критерии оценки  приемлемости модуля. Были предложены следующие критерии:

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

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

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

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

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

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

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

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

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

• данным;

• образцу;

• управлению;

• внешним  ссылкам;

• общей  области данных;

• содержимому.

Худшим  видом сцепления модулей является сцепление по  содержимому. Таким является сцепление двух модулей, когда один из них имеет прямые ссылки на содержимое другого модуля (например, на константу, содержащуюся в другом модуле). Такое сцепление модулей недопустимо.

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

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

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

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

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

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

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

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

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

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

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

Связность модулей — мера прочности соединения  функциональных и информационных объектов внутри одного модуля.

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

Различают следующие виды связности (в порядке  убывания уровня):

• функциональную;

• последовательную;

• информационную (коммуникативную);

• процедурную;

• временную;

• логическую;

• случайную.

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

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

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