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

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

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

Связь и когезия

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

История

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

Типы муфт

Концептуальная модель сцепления

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

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

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

Связывание контента (высокое)

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

Общая муфта

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

Внешняя связь

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

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

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

Штамповая связь (связь со структурой данных)

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

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

Соединение данных

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

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

Соединение подклассов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Затраты на интерпретацию сообщений и производительность

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

Решения

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

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

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

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

Связь против сплоченности

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

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

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

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

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

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

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

Для экологической связи:

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

${\displaystyle \mathrm {Coupling} (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}$

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

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

Рекомендации

1. ISO/IEC/IEEE 24765:2010 Системная и программная инженерия. Словарь.
2. ISO/IEC TR 19759:2005, Программная инженерия. Руководство по своду знаний по программной инженерии (SWEBOK).
3. Стивенс, Уэйн П .; Майерс, Гленфорд Дж .; Константин, Ларри Лерой (июнь 1974 г.). «Структурированный дизайн». IBM Systems Journal . 13 (2): 115–139. дои : 10.1147/sj.132.0115.
4. Юрдон, Эдвард ; Константин, Ларри Лерой (1979) [1975]. Структурное проектирование: основы дисциплины проектирования компьютерных программ и систем . Юрдон Пресс. Бибкод : 1979sdfd.book.....Y. ISBN 978-0-13-854471-3.
5. Бек, Фабиан; Диль, Стефан (сентябрь 2011 г.). «О соответствии модульности и связи кодов». В материалах 19-го симпозиума ACM SIGSOFT и 13-й Европейской конференции по основам программной инженерии (SIGSOFT/FSE '11) . Сегед, Венгрия. п. 354. дои : 10.1145/2025113.2025162. ISBN 9781450304436. S2CID  2413103.{{cite book}}: CS1 maint: отсутствует местоположение издателя ( ссылка )
6. Аришольм, Эрик; Бриан, Лайонел К .; Фойен, Аудун (август 2004 г.). «Измерение динамической связи для объектно-ориентированного программного обеспечения». Транзакции IEEE по разработке программного обеспечения . ИИЭЭ . 30 (8): 491–506. дои :10.1109/TSE.2004.41. HDL : 10852/9090 . S2CID  3074827.
7. Прессман, Роджер С. (1982). Программная инженерия - подход практикующего специалиста (4-е изд.). МакГроу-Хилл. ISBN 0-07-052182-4.

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

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