Что такое сцепление программного модуля

Сцепление модулей

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

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

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

1. Сцепление по содержимому — модуль ссылается на данные (содержимое) другого модуля. Большинство языков программирования высокого уровня делает такое сцепление практически невозможным.

2. Сцепление по общей области — модули ссылаются на одну и ту же глобальную структуру данных.

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

3. Сцепление по управлению — один модуль управляет функционированием другого. При этом в вызываемый модуль передается значение управляющей переменной.

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

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

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

5. Сцепление по данным — передаваемые параметры — простые (неструктурированные) данные.

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

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

В литературе /1/ предлагается для оценки приемлемости программного модуля использовать следующие характеристики:

— сцепление с другими модулями;

— рутинность модуля (независимость от предыстории обращений к нему).

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

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

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

Вывод: Подытожим обсуждение модульного программирования перечислением принципов Хольта:

1.Сложность взаимодействия модуля с другими модулями должна быть меньше сложности его внутренней структуры.

2.Хороший модуль снаружи проще, чем изнутри.

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

Сцепление модулей

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

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

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

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

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

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

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

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

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

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

Function MaxA: integer;

For i:=Low(a) +1 to High(a) do

If a(i)>MaxA then MaxA:=a(i);

3. Сцепление по управлению – один модуль управляет функционированием другого. При этом в вызываемый модуль передается значение управляющей переменной.

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

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

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

Else MinMax:=b;

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

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

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

For i:=2 to High(a) do

If a(i)>MaxEl then MaxEl:=a(i);

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

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

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

If a>) then Max:=a

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

Таблица 2. Характеристики сцепления модулей

Читайте также Цилиндр сцепления бмв e39

устойчивость к ошибкам других модулей

Возможность повторного использования

По общей области

*-зависит от количества параметров интерфейса.

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

сцепление с другими модулями;

рутинность модуля (независимость от предыстории обращений к нему).

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

Вывод: Подытожим обсуждение модульного программирования перечислением принципов Хольта:

1.Сложность взаимодействия модуля с другими модулями должна быть меньше сложности его внутренней структуры.

2.Хороший модуль снаружи проще, чем изнутри.

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

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

Практика показала, что структурный подход в сочетании с модульным программированием позволяет получать достаточно надежные программы, размер которых не превышает 100 000 операторов [10]. Узким местом модульного программирования является то, что ошибка в интерфейсе при вызове подпрограммы выявляется только при выполнении программы (из-за раздельной компиляции модулей обнаружить эти ошибки раньше невозможно). При увеличении размера программы обычно возрастает сложность межмодульных интерфейсов, и с некоторого момента предусмотреть взаимовлияние отдельных частей программы становится практически невозможно. Для разработки программного обеспечения большого объема было предложено использовать объектный подход.

Модули. сцепление и связность модулей

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

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

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

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

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

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

К модулям предъявляются следующие требования:

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

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

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

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

1) источника входных данных;

3) от предистории.

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

1) функциональная сложность – обусловлено тем, что один модуль выполняет слишком много функций;

2) распределенная сложность – это сложность идентификации общей функции распределенной между несколькими модулями за счет чего утрачивается возможность уменьшения сложности всей программы при модульном программировании;

3) сложность связи – определяется сложностью взаимодействия модулей, при использовании общих данных.

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

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

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

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

Читайте также Шланг сцепления волга 402

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

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

Изготовление вездехода часть №2 Модуль сцепления

Понятия связности модулей и сцепления модулей.

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

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

Связность модуля (Cohesion, прочность) – мера зависимости его частей (в порядке увеличения степени связности):

— Связность по совпадению (по совмещению): нет внутренних связей между частями

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

— Временная связность: разные части не связаны, но нужны в один и тот же период работы (например, модуль инициализации программы)

— Процедурная (последовательная) связность: части должны выполняться в определенном порядке в одном сценарии (при этом может не быть связи по данным)

— Коммуникативная связность: части модуля используют одни и те же данные или устройства ввода-вывода

— Информационная связность: выходные данные одной части используются как входные для другой

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

Сцепление модулей (Coupling)– мера взаимозависимости различных модулей (в порядке увеличения степени сцепления):

— Сцепление по данным: передаются простые параметры

— Сцепление по образцу: передается сложная структура данных

— Сцепление по управлению: модуль A управляет функционированием модуля B (флаги, переключатели)

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

— Сцепление по общей области: модули разделяют одну и ту же общую область памяти (но типизируют ее по своему)

— Сцепление по содержанию: один модуль прямо ссылается на часть другого модуля не через точку входа

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

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

Цели структурного программирования:

— Разрабатывать программы минимальной сложности

— Заставить проектировщика мыслить ясно

— Обеспечить восприятие программы со стороны

Требования:

— Отсутствие микроэффективности в ущерб ясности программы

— Правильное оформление (сдвиги, комментарии)

— Разбиение на модули (не более одной страницы текста на подпрограмму)

— Каждый модуль имеет ровно один вход и один выход

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

Структурное тестирование программного обеспечения

Связь процессов тестирования и процессов проектирования.

Тестирование – процесс выполнения программы с целью обнаружения ошибок.

Доказательство правильности – попытка найти ошибки в программе без относительных входных данных.

Контроль (верификация) – поиск ошибок в ПО, при выполнении его в тестовой (моделируемой) среде.

Испытание – поиск ошибок в ПО, при выполнении его в заданной реальной среде.

Отладка – установление точной причины обнаруженной ошибки и ее устранение.

Виды тестирования:

1.Тестирование модуля (автономное, тестирование минимальной единицы программы) — тестирование программного модуля в изолированной от других модулей среде.

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

3.Системное (комплексное)– контроль или испытание системы на соответствие исходным целям.

4.Тестирование приемлемости – проверка соответствия программы требованиям пользователя.

Последовательность подготовки тестов совпадает с последовательностью проектирования. Выполнение же тестирования происходит обратно выполнению проектирования.

Тестирование включает в себя следующие виды деятельности:

1. постановка задачи на тестирование (определение целей). Определяется, кто будет выявлять ошибки, какие виды тестирования и кто будет выполнять.

2. проектирование тестов (составление перечня тестируемых процедур);

3. описание (кодирование) тестов (ручное или автоматическое написание тестов);

4. тестирование тестов (тестируемая программа является тестом для тестов);

5. выполнение тестов;

6. изучение результатов тестирования.

Дата добавления: 2018-06-01 ; просмотров: 533 ; Мы поможем в написании вашей работы!

Связанность модуля.Сцепление модуля

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

Существует 7 типов связности:

Связность по совпадению

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

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

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

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

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

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

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

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

Мера связности	Сцепление	Модифицируемость	Понятность	Сопровождаемость
Функциональная	хорошее	хорошая	хорошая	хорошая
Последовательная	хорошее	хорошая	близкая к хорошей	хорошая
Информационная	среднее	средняя	средняя	средняя
Процедурная	приемлемое	приемлемая	приемлемая	плохая
Временная	плохое	плохая	средняя	плохая
Логическая	плохое	плохая	плохая	плохая
Случайная	плохое	плохая	плохая	плохая

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

Связанность (coupling) модуля является мерой взаимозависимости модулей. При создании систем необходимо стремиться к максимальной независимости модулей, т.е. связанность модулей должна быть минимальной.

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

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

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

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

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

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

С понятием связанность тесно связано понятие связность.

Сцепление

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

— Уменьшение количества соединений между двумя модулями приводит к уменьшению вероятности появления «волнового эффекта» (ошибка в одном модуле влияет на работу других модулей);

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

— При сопровождении модуля отсутствие необходимости беспокоиться о внутренних деталях других модулей;

— Упрощение системы для понимания, насколько это возможно.

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

— Удаления необязательных связей;

— Уменьшения количества необходимых связей;

— Упрощением необходимых связей.

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

1. Создавайте минимальные по количеству параметров межмодульные связи;

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

3. Создавайте локализованные связи (например, значения списка параметров вычисляйте непосредственно перед вызовом модуля);

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

5. Создавайте гибкие связи для облегчения модификаций.

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

Два модуля А и В являются нормально сцепленными, если

— В возвращает управление А;

— Вся информация, передаваемая между А и В, представляется значениями параметров при вызове.

Существует три типа нормального сцепления: сцепление по данным, сцепление по образцу, сцепление по управлению. На практике наиболее часто используемым типом сцепления является сцепление по данным (data coupling). Два модуля сцеплены по данным, если они взаимодействуют через передачу параметров и при этом каждый параметр является элементарным информационным объектом.

Два модуля сцеплены по образцу (stamp coupling), если один посылает другому составной информационный объект, т.е. объект, имеющий внутреннюю структуру. Примером составного объекта может быть объект Данные о клиенте, включающий в себе поля: Название организации, Почтовый адрес, Номер счета и т.п.

Два модуля сцеплены по управлению (control coupling), если один посылает другому информационный объект — флаг, предназначенный для управления его внутренней логикой. Существует два типа флагов — описательный и управляющий. Описательный флаг обычно описывает ситуацию, которая произошла, и именуются с использованием существительных и прилагательных: Конец файла, Введенная кредитная карта. Управляющий флаг используется для декларирования определенных действий в вызываемом модуле и именуется с использованием глаголов: Читать следующую запись, Установить в начало. В общем случае управляющие флаги усиливают сцепление и, следовательно, ухудшают качество проекта.

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

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

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

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

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

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

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

В таблице 2.2. приведены конкретные характеристики каждого типа сцепления.

Таблица 2.2. Характеристики различных типов сцепления

Тип сцепления	Устойчивость к волновому эффекту	Модифици руемость	Понятность	Используемость в других системах
data coupling	*	хорошая	хорошая	хорошая
stamp coupling	*	средняя	средняя	средняя
control coupling	средняя	плохая	плохая	плохая
common coupling	плохая	средняя	плохая	плохая
content coupling	плохая	плохая	плохая	плохая