Зв'язність (програмування)

Зв'язність (англ. coupling) чи залежність (англ. dependency) це міра в якій модуль (компонент) програми залежить від кожного іншого модуля (використовує якусь інформацію про нього).

Зв'язність зазвичай протиставляється пов'язаності. Метрики програмного забезпечення зв'язність та пов'язаність, винайдені Ларрі Констянтином, першим розробником Structured Design,[1] який також був першим їхнім прихильником (див. також SSADM). Слабка зв'язність часто є ознакою добре структурованої комп'ютерної системи, та гарної архітектури, і в поєднанні з високою пов'язаністю дозволяє досягнути гарної прочитності та підтримуваності коду.

Види зв'язності

Концептуальна модель зв'язності

Зв'язність може бути «слабкою» (чи «низькою») або «сильною» («високою»). Розглянемо деякі види зв'язності в порядку від найвищих, до найнижчих:

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

Зв'язність за вмістом (сильна): З'являється, коли один модуль модифікує або залежить від внутрішнього вмісту іншого модуля (наприклад, використовує його змінні).; Тому зміна способу, яким другий модуль обробляє дані, вимагатиме зміни залежного модуля.
Зв'язність за спільністю даних: Коли два модулі мають спільні глобальні дані (глобальні змінні).; Зміна спільного ресурсу передбачає зміну всіх модулів що його використовують.
Зовнішня зв'язність: З'являється коли два модулі поділяють нав'язаний ззовні формат даних, протокол комунікації чи інтерфейс пристрою. Зазвичай це пов'язане з взаємодією з зовнішніми інструментами чи апаратурою.
Зв'язність контролю: З'являється коли один модуль контролює хід роботи іншого, передаючи йому інформацію про те що робити.
Залежність-штамп (Залежність від структурованих даних): коли модулі мають спільну складну структуру даних, і використовують лише її частини, можливо різні (наприклад функції передається запис, хоча вона потребує лише його частину).
Зв'язність даних: Зв'язність даних виникає коли модулі діляться спільними даними через, наприклад, параметри. Кожне дане є елементарним, і єдиним яке ділиться (наприклад передача числа функції що обчислює квадратний корінь).
Зв'язність через повідомлення (слабка): Найслабший тип зв'язності. Досягається за допомогою децентралізації стану (в об'єктах). Взаємодія компонентів проводиться через параметри та обмін повідомленнями.
Відсутня: Модулі взагалі не взаємодіють між собою.

Об'єктно-орієнтоване програмування

Зв'язність підкласу: Описує взаємозв'язок між предком та нащадком. Нащадок прив'язаний до предка, а предок ні.
Тимчасова зв'язність: Коли дві дії упаковані в один модуль лиш тому, що вони можуть відбуваються одночасно.

У недавній праці інші концепції зв'язності були вивчені та використані як ознаки різних принципів модульності, що використовуються на практиці.[2]

Недоліки

Сильно зв'язні системи як правило демонструють наступні характеристики розробки, які часто розглядаються як недоліки:

Зміна одного модуля зазвичай викликає хвилю змін в інших модулях
Збирання модулів до купи та стиковка вимагатиме більше зусиль та часу, через збільшення міжмодульних залежностей
Конкретний модуль важче буде повторно використати та/або тестувати, тому що потрібно включити залежні модулі.

Проблеми продуктивності

Незалежно від сили зв'язності, продуктивність системи зменшується через створення повідомлень та параметрів, їх передавання, трансляцію та інтерпретацію. Дивіться подійно-орієнтоване програмування.

Витрати на створення повідомлень: Створення будь-якого повідомлення вимагає додаткових витрат як процесора так і пам'яті. Створення цілочисельного повідомлення (яке може бути посиланням на рядок, масив чи іншу структуру даних) вимагає менших витрат ніж створення складного повідомлення такого як наприклад в SOAP. Для оптимізації потрібно зменшувати довжину повідомлення, та збільшувати міру вмісту яка в нього вкладається.

Витрати на передачу повідомлень: Так як для отримання змісту, повідомлення потрібно передати повністю, потрібно це оптимізувати. Коротші повідомлення передаються і приймаються швидше.

Витрати на трансляцію повідомлень: Протоколи повідомлень, і вони самі часто містять надлишкову інформацію (наприклад опис пакету і його структури). Тому отримувач часто потребує перетворення повідомлення в простішу форму, видаленням додаткових символів та інформації про структуру та/або приведенням типу значень до потрібного. Для оптимізації процесів трансляції повідомлення знову ж таки має мати якомога меншу довжину, за якомога більшого вмісту.

Витрати на інтерпретацію повідомлень: всі повідомлення мають інтерпретуватись приймачем. Прості повідомлення, такі як цілі, можуть не вимагати додаткової обробки. Тим не менш, складні повідомлення, наприклад в SOAP, потребують парсера та перетворення рядків для відтворення змісту.

Способи вирішення проблем

Одним з підходів до зменшення зв'язності є функціональне проектування, яке намагається обмежити відповідальності модулів в функціональності.

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

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

Зв'язність та пов'язаність

Зв'язність та пов'язаність — два терміни які дуже часто вживаються разом. Вони описують якості які повинні мати модулі. Зв'язність характеризує взаємозв'язки між модулями, а пов'язаність описує зв'язок функцій всередині модуля. Низька пов'язаність спричинює ситуацію коли модуль виконує різні непов'язані завдання, і починає створювати проблеми коли модуль стає великим.

Зв'язність модулів

У книзі «Software Engineering»[3] зв'язність описує варіант метрики пов'язаної з цим терміном.

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

d_i: кількість вхідних параметрів даних
c_i: кількість вхідних контрольних параметрів
d_o: кількість вихідних параметрів даних
c_o: кількість вихідних контрольних параметрів

Для глобальної зв'язності:

g_d: кількість глобальних змінних які використовуються як дані
g_c: кількість глобальних змінних які використовуються для контролю

Для зв'язності середовищ:

w: кількість викликаних модулів (fan-out)
r: кількість модулів що викликають модуль який розглядається (fan-in)

$\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}}\approx 0.67$

Якщо модуль має 5 вхідних та вихідних параметрів, таке ж число контрольних параметрів, і використовує 10 глобальних змінних, викликає 3 модулі, і викликається чотирма,

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

Див. також

Примітки

W. Stevens, G. Myers, L. Constantine, «Structured Design», IBM Systems Journal, 13 (2), 115-139, 1974.
F. Beck, S. Diehl. On the Congruence of Modularity and Code Coupling. In Proceedings of the 19th ACM SIGSOFT Symposium and the 13th European Conference on Foundations of Software Engineering (SIGSOFT/FSE '11), Szeged, Hungary, September 2011. DOI:10.1145/2025113.2025162
Pressman, Roger S. Ph.D (1982). Software Engineering — A Practitioner's Approach — Fourth Edition. ISBN 0-07-052182-4

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.

[1] W. Stevens, G. Myers, L. Constantine, «Structured Design», IBM Systems Journal, 13 (2), 115-139, 1974.

[2] F. Beck, S. Diehl. On the Congruence of Modularity and Code Coupling. In Proceedings of the 19th ACM SIGSOFT Symposium and the 13th European Conference on Foundations of Software Engineering (SIGSOFT/FSE '11), Szeged, Hungary, September 2011. DOI:10.1145/2025113.2025162

[Pressman-3] Pressman, Roger S. Ph.D (1982). Software Engineering — A Practitioner's Approach — Fourth Edition. ISBN 0-07-052182-4