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

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

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

История

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

Типы сцепления

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

Процедурное программирование

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

Сцепление контента (высокое): Говорят, что сцепление контента происходит, когда один модуль использует код другого модуля, например, ветви. Это нарушает сокрытие информации — базовую концепцию проектирования программного обеспечения.
Общая муфта: Говорят, что общая связь возникает, когда несколько модулей имеют доступ к одним и тем же глобальным данным. Но это может привести к неконтролируемому распространению ошибок и непредвиденным побочным эффектам при внесении изменений.
Внешняя муфта: Внешняя связь происходит, когда два модуля совместно используют внешне навязанный формат данных, протокол связи или интерфейс устройства. Это в основном относится к связи с внешними инструментами и устройствами.
Управляющая муфта: Сцепление управления — это когда один модуль управляет потоком другого, передавая ему информацию о том, что делать (например, передавая флаг «что делать»).
Сцепление штампов (сцепление структурированных данных): Связывание штампов происходит, когда модули совместно используют составную структуру данных и используют только ее части, возможно, разные части (например, передавая всю запись функции, которой требуется только одно ее поле).; В этой ситуации изменение в поле, которое не нужно модулю, может привести к изменению способа, которым модуль читает запись. Чтобы проиллюстрировать концепцию связывания штампов, рассмотрим сценарий с участием UserProfile компонента . Этот компонент предназначен для возврата всей информации о профиле пользователя в ответ на запросы , даже если потребителям требуется только определенный атрибут . Эта практика иллюстрирует связывание штампов, которое может привести к значительным проблемам с пропускной способностью , особенно в масштабе. Когда какой-либо атрибут в UserProfileкомпоненте изменяется, всем потребителям, которые взаимодействуют с ним, может потребоваться пройти тестирование , даже если они не используют измененный атрибут. ^[6]
Связывание данных: Сцепление данных происходит, когда модули обмениваются данными через, например, параметры. Каждый элемент данных является элементарной частью, и это единственные общие данные (например, передача целого числа в функцию, которая вычисляет квадратный корень).

Объектно-ориентированное программирование

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

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

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

Динамическая связь

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

Семантическая связь

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

Логическая связь

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

Размеры муфты

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

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

Недостатки жесткой связи

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

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

Проблемы с производительностью

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

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

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

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

Решения

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

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

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

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

Сцепление против сплоченности

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

Модульная муфта

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

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

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

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

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

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

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

$\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 (высокая связанность)

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

$C=1-{\frac {1}{1+0+1+0+0+0+1+0}}=1-{\frac {1}{3}}=0,67$

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

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

Смотрите также

Ссылки

^ ISO/IEC/IEEE 24765:2010 Системная и программная инженерия — Словарь
^ ISO/IEC TR 19759:2005, Программная инженерия — Руководство по своду знаний по программной инженерии (SWEBOK)
^ ab Hohpe, Gregor. Шаблоны интеграции предприятия: проектирование, построение и развертывание решений для обмена сообщениями . Addison-Wesley Professional. ISBN 978-0321200686.
^ Стивенс, Уэйн П .; Майерс, Гленфорд Дж .; Константин, Ларри Лерой (июнь 1974 г.). «Структурное проектирование». IBM Systems Journal . 13 (2): 115–139. doi :10.1147/sj.132.0115.
^ Yourdon, Edward ; Constantine, Larry LeRoy (1979) [1975]. Структурное проектирование: основы дисциплины проектирования компьютерных программ и систем . Yourdon Press. Bibcode :1979sdfd.book.....Y. ISBN 978-0-13-854471-3.
^ Ричардс, Марк. Основы архитектуры программного обеспечения: инженерный подход . O'Reilly Media. ISBN 978-1492043454.
^ Бек, Фабиан; Диль, Стефан (сентябрь 2011 г.). «О согласованности модульности и связности кода». В трудах 19-го симпозиума ACM SIGSOFT и 13-й Европейской конференции по основам программной инженерии (SIGSOFT/FSE '11) . Сегед, Венгрия. стр. 354. doi :10.1145/2025113.2025162. ISBN 9781450304436. S2CID 2413103.{{cite book}}: CS1 maint: отсутствует местоположение издателя ( ссылка )
^ Аришольм, Эрик; Бриан, Лайонел К.; Фойен, Аудун (август 2004 г.). «Динамическое измерение связи для объектно-ориентированного программного обеспечения». Труды IEEE по программной инженерии . 30 (8). IEEE : 491–506. doi : 10.1109/TSE.2004.41. hdl : 10852/9090 . S2CID 3074827.
^ Прессман, Роджер С. (1982). Программная инженерия — подход практиков (4-е изд.). McGraw-Hill. ISBN 0-07-052182-4.

Дальнейшее чтение

Майерс, Гленфорд Дж. (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