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

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

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

• процедурный (или структурный - по названию подхода);

• объектный.

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

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

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

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

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

Первоначально к модулям (еще понимаемым как подпрограммы) предъ­являлись следующие требования:

• отдельная компиляция;

• одна точка входа;

• одна точка выхода;

• соответствие принципу вертикального управления;

• возможность вызова других модулей;

• небольшой размер (до 50-60 операторов языка);

• независимость от истории вызовов;

• выполнение одной функции.

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

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

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

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

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

• меньше вероятность появления новых ошибок при исправлении ста­рых или внесении изменений в программу, т. е. вероятность появления «волнового» эффекта;

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

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

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

Различают пять типов сцепления модулей:

• по данным;

• по образцу;

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

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

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

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

Например, функция Мах предполагает сцепление по данным через па­раметры скалярного типа:

Function Max(a, b: integer) : integer;

begin

If a>b then Max:=a else Max: =b;

end;

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

Так, функция MaxEl, описанная ниже, предполагает сцепление по образ­цу (параметр а - открытый массив).

Function MaxEl(a:array of integer):integer;

Var i:word;

begin

MaxEl:=a[0];

for i:=l to High(a) do

if a[i]>MaxEl then MaxEl: =a[i];

end;

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

Например, функция MinMax предполагает сцепление по управлению, так как значение параметра flag влияет на логику программы: если функция MinMax получает значение параметра flag, равное true, то возвращает макси­мальное значение из двух, а если false, то минимальное:

Function MinMax(a, b: integer; flag: boolean): integer;

begin

if(a>b) and (flag) then MinMax: =a

else MinMax: =b;

end;

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

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

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

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

Например, функция МахА, использующая глобальный массив А, сцеп­лена с основной программой по общей области:

Function MaxA:integer; Var i:word;

begin

MaxA: =a[Low(a)]; for i:= Low(a)+l to High(a) do if a[i]>MaxA then MaxA: =a[i];

end;

Следует иметь в виду, что «подпрограммы с памятью», действия кото­рых зависят от истории вызовов, используют сцепление по общей области, что делает их работу в общем случае непредсказуемой. Именно этот вариант используют статические переменные С и C++.

В случае сцепления по содержимому один модуль содержит обращения к внутренним компонентам другого (передает управление внутрь, читает и/или изменяет внутренние данные или сами коды), что полностью противо­речит блочно-иерархическому подходу. Отдельный модуль в этом случае уже не является блоком («черным ящиком»): его содержимое должно учитывать­ся в процессе разработки другого модуля. Современные универсальные язы­ки процедурного программирования, например Pascal, данного типа сцепле­ния в явном виде не поддерживают, но для языков низкого уровня, например Ассемблера, такой вид сцепления остается возможным.

В табл. 2.1 приведены характеристики различных типов сцепления по экспертным оценкам [21, 30]. Допустимыми считают первые три типа сцеп­ления, так как использование остальных приводит к резкому ухудшению тех­нологичности программ.

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

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

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

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

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

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

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

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

• временную;

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

• случайную.

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

Из тех же соображений следует избегать неструктурированного распре­деления функции между модулями - библиотеками ресурсов. Например, ес­ли при проектировании текстового редактора предполагается функция редактирования, то лучше организовать модуль - библиотеку функций редактиро­вания, чем поместить часть функций в один модуль, а часть в другой.

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

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

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

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

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

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

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

Обратите внимание, что в трех предпоследних случаях связь между не­сколькими подпрограммами в модуле обусловлена внешними причинами. А в последнем — вообще отсутствует. Это соответствующим образом проециру­ется на технологические характеристики модулей. В табл. 2.2 представлены характеристики различных видов связности по экспертным оценкам [21, 30].

Анализ табл. 2.2 показывает, что на практике целесообразно использо­вать функциональную, последовательную и информационную связности.

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

Библиотеки ресурсов. Различают библиотеки ресурсов двух типов: библиотеки Подпрограмм и библиотеки классов.

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

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

В качестве средства улучшения технологических характеристик библи­отек ресурсов в настоящее время широко используют разделение тела моду­ля на интерфейсную часть и область реализации (секции Interface и Imple­mentation - в Pascal, h и срр-файлы в C++ и в Java).

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

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