Сцепление (компьютерное программирование)

В программной инженерии связь — это степень взаимозависимости между программными модулями , мера того, насколько тесно связаны две процедуры или модули, ^[1] и сила взаимосвязей между модулями. ^[2] Связь не является двоичной, а многомерной. ^[3]

Сцепление обычно противопоставляется сплоченности . Низкая сцепленность часто коррелирует с высокой сплоченностью, и наоборот. Низкая сцепленность часто считается признаком хорошо структурированной компьютерной системы и хорошего дизайна, а в сочетании с высокой сплоченностью поддерживает общие цели высокой читаемости и поддерживаемости . ^{[ необходима цитата ]}

Метрики качества программного обеспечения , связанные и связанные, были изобретены Ларри Константином в конце 1960-х годов как часть структурированного дизайна , основанного на характеристиках «хороших» практик программирования, которые снижали затраты на обслуживание и модификацию. Структурированный дизайн, включая связанность и связь, были опубликованы в статье Стивенса, Майерса и Константина (1974) ^[4] и книге Йордона и Константина (1979), ^[5], и последние впоследствии стали стандартными терминами.

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

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

Сцепление контента (высокое)

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

Общая муфта

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

Внешняя муфта

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

Управляющая муфта

Сцепление управления — это когда один модуль управляет потоком другого, передавая ему информацию о том, что делать (например, передавая флаг «что делать»).

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

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

В этой ситуации изменение в поле, которое не нужно модулю, может привести к изменению способа, которым модуль читает запись. Чтобы проиллюстрировать концепцию связывания штампов, рассмотрим сценарий с участием UserProfile компонента . Этот компонент предназначен для возврата всей информации о профиле пользователя в ответ на запросы , даже если потребителям требуется только определенный атрибут . Эта практика иллюстрирует связывание штампов, которое может привести к значительным проблемам с пропускной способностью , особенно в масштабе. Когда какой-либо атрибут в UserProfileкомпоненте изменяется, всем потребителям, которые взаимодействуют с ним, может потребоваться пройти тестирование , даже если они не используют измененный атрибут. ^[6]

Связывание данных

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

Подкласс сцепления

Описывает отношения между потомком и его родителем. Потомок связан со своим родителем, но родитель не связан с потомком.

Временная связь

Это когда два действия объединяются в один модуль только потому, что они происходят одновременно.

В недавних работах были исследованы и использованы в качестве индикаторов различных принципов модуляризации, используемых на практике. ^[7]

Целью определения и измерения этого типа связи является предоставление оценки времени выполнения программной системы. Утверждалось, что статические метрики связи теряют точность при интенсивном использовании динамического связывания или наследования. ^[8] В попытке решить эту проблему были приняты во внимание меры динамической связи.

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

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

По мнению Грегора Хохпе, связь многомерна: ^[3]

• Зависимость от технологий
• Зависимость от местоположения
• Зависимость от топологии
• Формат данных и зависимость типа
• Семантическая зависимость
• Зависимость от разговора
• Зависимость от порядка
• Временная зависимость

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

1. Изменение в одном модуле обычно вызывает цепную реакцию изменений в других модулях.
2. Сборка модулей может потребовать больше усилий и/или времени из-за возросшей зависимости между модулями.
3. Конкретный модуль может быть сложнее повторно использовать и/или тестировать, поскольку необходимо включить зависимые модули.

Независимо от того, связаны ли они слабо или тесно, производительность системы часто снижается из-за создания, передачи, перевода (например, маршалинга) и интерпретации сообщений (которые могут быть ссылкой на строку, массив или структуру данных), что требует меньших накладных расходов, чем создание сложного сообщения, такого как сообщение SOAP . Более длинные сообщения требуют больше ресурсов ЦП и памяти для создания. Для оптимизации производительности во время выполнения длина сообщения должна быть минимизирована, а смысл сообщения должен быть максимальным.

Накладные расходы на передачу сообщений и производительность

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

Накладные расходы на перевод сообщений и производительность

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

Накладные расходы и производительность интерпретации сообщений

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

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

• У A есть атрибут, который ссылается на B (имеет тип) .
• А пользуется услугамиобъекта Б.
• У A есть метод, который ссылается на B (через возвращаемый тип или параметр).
• A является подклассом (или реализует)класс B.

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

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

Сцепление описывает степень и характер зависимости между компонентами программного обеспечения, фокусируясь на том, что они разделяют (например, данные, поток управления, технологию) и насколько тесно они связаны. Оно оценивает два ключевых измерения: прочность, которая измеряет, насколько сложно изменить зависимость, и область действия (или видимость), которая указывает, насколько широко зависимость проявляется через модули или границы. Традиционные типы сцепления обычно включают в себя сцепление содержимого, общее сцепление, сцепление управления, сцепление штампа, внешнее сцепление и сцепление данных. ^{[9] [10] [11]}

Connascence , представленный Мейлиром Пейдж-Джонсом, предоставляет систематическую структуру для анализа и измерения зависимостей сцепления. Он оценивает зависимости на основе трех измерений: сила, которая измеряет усилия, необходимые для рефакторинга или изменения зависимости; локальность, которая учитывает, насколько физически или логически близки зависимые компоненты в кодовой базе; и степень, которая измеряет, сколько компонентов затронуто зависимостью. Connascence можно разделить на статические (обнаруживаемые во время компиляции) и динамические (обнаруживаемые во время выполнения) формы. Статическая connascence относится к зависимостям времени компиляции, таким как сигнатуры методов, в то время как динамическая connascence относится к зависимостям времени выполнения, которые могут проявляться в таких формах, как connascence времени, значений или алгоритма. ^{[9] [10] [11]}

Каждый сорт сцепления может демонстрировать несколько типов согласованности, определенный тип или, в редких случаях, ни одного, в зависимости от того, как реализована зависимость. Распространенные типы согласованности включают согласованность имени, типа, положения и значения. Некоторые типы сцепления естественным образом соответствуют определенным типам согласованности; например, связывание данных часто включает согласованность имени или типа. Однако не каждая комбинация сопряжения и согласованности имеет практический смысл. Зависимости, полагающиеся на порядок параметров в сигнатуре метода, демонстрируют согласованность положения, которая является хрупкой и сложной для рефакторинга, поскольку переупорядочивание параметров нарушает интерфейс. Напротив, согласованность имени, которая опирается на имена полей или параметров, как правило, более устойчива к изменениям. Сами типы согласованности демонстрируют естественную иерархию силы, при этом согласованность имени обычно считается слабее, чем согласованность значения. ^{[9] [10] [11]}

Зависимости, охватывающие границы модулей или распределенные системы, обычно имеют более высокие затраты на координацию, что увеличивает сложность рефакторинга и распространения изменений через удаленные границы. Современные практики, такие как внедрение зависимостей и программирование на основе интерфейсов, часто используются для снижения прочности связи и улучшения поддерживаемости зависимостей. ^{[9] [10] [11]}

В то время как сцепление определяет, что является общим для компонентов, connascence оценивает, как ведут себя эти зависимости, как распространяются изменения и насколько сложно их рефакторить. Сила, локальность и степень взаимосвязаны; зависимости с высокой силой, широким охватом и охватывающие отдаленные границы значительно сложнее рефакторить и поддерживать. Вместе, coupling обеспечивает высокоуровневый обзор отношений зависимости, в то время как connascence предлагает гранулярную структуру для анализа силы зависимости, локальности, степени и устойчивости к изменениям, поддерживая проектирование поддерживаемых и надежных систем. ^{[9] [10] [11]}

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

Связность в программной инженерии ^[12] описывает версию метрик, связанных с этой концепцией.

Для сопряжения потоков данных и управления:

• d _i : количество параметров входных данных
• c _i : количество входных контрольных параметров
• d _o : количество параметров выходных данных
• c _o : количество выходных контрольных параметров

Для глобальной связи:

• g _d : количество глобальных переменных, используемых в качестве данных
• g _c : количество глобальных переменных, используемых в качестве контроля

Для связи с окружающей средой:

• w : количество вызванных модулей (разветвленных)
• r : количество модулей, вызывающих рассматриваемый модуль (fan-in)

${\displaystyle \mathrm {Связь} (C)=1-{\frac {1}{d_{i}+2\times c_{i}+d_{o}+2\times c_{o}+g_{d}+2\times g_{c}+w+r}}}$

Coupling(C)делает значение больше, чем более связан модуль. Это число варьируется от приблизительно 0,67 (низкая связанность) до 1,0 (высокая связанность)

Например, если модуль имеет только один входной и выходной параметр данных

${\displaystyle C=1-{\frac {1}{1+0+1+0+0+0+1+0}}=1-{\frac {1}{3}}=0.67}$

Если модуль имеет 5 входных и выходных параметров данных, равное количество параметров управления и имеет доступ к 10 элементам глобальных данных с коэффициентом объединения по входу 3 и коэффициентом объединения по выходу 4,

${\displaystyle C=1-{\frac {1}{5+2\times 5+5+2\times 5+10+0+3+4}}=0.98}$

• Сплоченность (информатика)
• Коннасценция (информатика)
• Сцепление (физика)
• Устранение мертвого кода
• Ад зависимости
• Эфферентная связь
• Инверсия управления
• Список терминов объектно-ориентированного программирования
• Слабое сцепление
• Марка (программное обеспечение)
• Статический анализ кода

• Майерс, Гленфорд Дж. (1974). Надежное программное обеспечение с помощью композитного проектирования . Нью-Йорк: Mason and Lipscomb Publishers.
• Оффутт, А. Джефферсон; Харролд, Мэри Джин ; Колте, Приядаршан (март 1993 г.). «Система показателей программного обеспечения для соединения модулей». Журнал систем и программного обеспечения . 20 (3): 295– 308. doi :10.1016/0164-1212(93)90072-6.
• Page-Jones, Meilir (1980). Практическое руководство по проектированию структурированных систем . Нью-Йорк: Yourdon Press. ISBN 978-8-12031482-5.
• Стандартный глоссарий терминологии программной инженерии . Нью-Йорк: IEEE . 1990. ISBN 0-7381-0391-8. 610.12_1990.
• "Учебная программа для сертифицированных специалистов по архитектуре программного обеспечения (CPSA) - Базовый уровень" (PDF) . 3.01. Международный совет по квалификации архитектуры программного обеспечения (ISAQB). 2015-05-15 [2009]. Архивировано из оригинала (PDF) 2017-03-29 . Получено 2019-06-23 .[1] Архивировано 22.02.2016 на Wayback Machine