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

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

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

История [ править ]

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

Типы сцепления [ править ]

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

Процедурное программирование [ править ]

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

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

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

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

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

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

Динамическая связь [ править ]

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

Семантическая связь [ править ]

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

Логическая связь [ править ]

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

Недостатки жесткой связи [ править ]

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

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

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

Независимо от того, слабо или тесно связаны, производительность системы часто снижается из-за создания сообщений и параметров, их передачи, трансляции (например, маршалинга) и интерпретации сообщений (которые могут быть ссылкой на строку, массив или структуру данных), что требует меньших накладных расходов, чем создание сложное сообщение, такое как сообщение 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 : количество модулей, вызывающих рассматриваемый модуль (входящий вход)

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

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

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

[ISO_24765-1] ISO/IEC/IEEE 24765:2010 Системная и программная инженерия. Словарь.

[ISOIECTR19759_2005-2] ISO/IEC TR 19759:2005, Программная инженерия. Руководство по своду знаний по программной инженерии (SWEBOK).

[Stevens_1974-3] Стивенс, Уэйн П .; Майерс, Гленфорд Дж .; Константин, Ларри Лерой (июнь 1974 г.). «Структурированный дизайн». Системный журнал IBM . 13 (2): 115–139. дои : 10.1147/sj.132.0115 .

[Yourdon_1979-4] Юрдон, Эдвард ; Константин, Ларри Лерой (1979) [1975]. Структурное проектирование: основы дисциплины проектирования компьютерных программ и систем . Юрдон Пресс. Бибкод : 1979sdfd.book.....Y . ISBN 978-0-13-854471-3 .

[Beck_2011-5] Бек, Фабиан; Диль, Стефан (сентябрь 2011 г.). «О соответствии модульности и связи кодов». В материалах 19-го симпозиума ACM SIGSOFT и 13-й Европейской конференции по основам программной инженерии (SIGSOFT/FSE '11) . Сегед, Венгрия. п. 354. дои : 10.1145/2025113.2025162 . ISBN 9781450304436 . S2CID 2413103 . {{cite book}}: CS1 maint: отсутствует местоположение издателя ( ссылка )

[Arisholm_2004-6] Арисхольм, Эрик; Бриан, Лайонел К .; Фойен, Аудун (август 2004 г.). «Измерение динамической связи для объектно-ориентированного программного обеспечения». Транзакции IEEE по разработке программного обеспечения . 30 (8). IEEE : 491–506. дои : 10.1109/TSE.2004.41 . HDL : 10852/9090 . S2CID 3074827 .

[Pressman_1982-7] Прессман, Роджер С. (1982). Программная инженерия - подход практикующего специалиста (4-е изд.). МакГроу-Хилл. ISBN 0-07-052182-4 .

[1]

[2]

[3]

[4]

[5]

[6]

[7]