Сцепление модулей программы

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

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

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

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

Вид сцепления	Степень сцепления модуля
По кодам	9 (сильное сцепление)
По внешним ссылкам	7
По управлению	5
По общей области	4
По образцу	3
По данным	1
Независимое	0 (слабое сцепление)

Таблица 2.1

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

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

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

Модули сцеплены по общей области, если они разделяют одну и ту же глобальную структуру данных. Модули ПЛ/1, ссылающиеся на структуру, объявленную как EXTERNAL, сцеплены друг с другом по общей области. Модули Фортрана, ссылающиеся на данные в блоке COMMON, группы модулей, ссылающиеся на абсолютные адреса памяти (включая регистры), также служат примерами сцепления по общей области.

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

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

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

Независимое сцепление возможно в том случае, если модули не вызывают друг друга или не обрабатывают одну и ту же информацию.

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

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

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

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

Кроме внутренней (по виду) связности и внешней (по виду сцепления) связности степень независимости модуля определяется также еще целым рядом дополнительных факторов, к которым следует отнести:

• размер модуля;

• предсказуемость модулей;

• структура принятия решений;

• минимальность объемы данных, необходимых для взаимодействия;

• наличие внутренних процедур.

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

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

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

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

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