Лекція 5. Основи проектування програмних систем.

Випадково зв'язний модуль схожий на логічно зв'язний модуль. Його елементи-дії не зв'язані ні потоком даних, ні потоком управління. Але в логічно зв'язному модулі дії, принаймні, відносяться до однієї категорії; у випадково зв'язному модулі навіть цього немає. Отже, випадково зв'язні модулі мають всі недоліки логічно зв'язних модулів і навіть підсилюють їх. Застосування таких модулів вселяє жах, оскільки один параметр використовується для різних цілей.

Щоб клієнт міг скористатися модулем "Різні функції", цей модуль (подібно до всіх випадково зв'язних модулів) повинен бути «білим ящиком», чия реалізація повністю видима. Такі модулі роблять системи менш зрозумілими і важче супроводжуваними, чим системи без модульності взагалі!

На щастя, зв'язність по збігу зустрічається рідко. Серед її причин можна назвати: o бездумний переклад існуючої монолітної коди в модулі;

oнеобгрунтовані зміни модулів з поганою (зазвичай тимчасовою) зв'язністю, що приводять до додавання прапорців.

8.8.Визначення зв'язності модуля

Приведемо алгоритм визначення рівня зв'язності модуля.

1.Якщо модуль — одинична проблемно-орієнтована функція, то рівень зв'язності — функціональний; кінець алгоритму. Інакше перейти до пункту 2.

2.Якщо дії усередині модуля зв'язані, то перейти до пункту 3. Якщо дії усередині модуля ніяк не зв'язані, то перейти до пункту 6.

3.Якщо дії усередині модуля зв'язані даними, то перейти до пункту 4. Якщо дії усередині модуля зв'язані потоком управління, перейти до пункту 5.

4.Якщо порядок дій усередині модуля важливий, то рівень зв'язності — інформаційний. Інакше рівень зв'язності — комунікативний. Кінець алгоритму.

5.Якщо порядок дій усередині модуля важливий, то рівень зв'язності — процедурний. Інакше рівень зв'язності — тимчасовою. Кінець алгоритму.

6.Якщо дії усередині модуля належать до однієї категорії, то рівень зв'язності — логічний. Якщо дії усередині модуля не належать до однієї категорії, то рівень зв'язності — по збігу.

Кінець алгоритму.

Можливі складніші випадки, коли з модулем асоціюються декілька рівнів зв'язності. У цих випадках слід застосовувати одне з двох правив:

1.правило паралельного ланцюга. Якщо всі дії модуля мають декілька рівнів зв'язності, то модулю привласнюють найсильніший рівень зв'язності;

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

Наприклад, модуль може містити деякі дії, які зв'язані процедурно, а також інші дії, зв'язкові із збігу. В цьому випадку застосовують правило послідовного ланцюга і в цілому модуль вважають зв'язним по збігу.

9. Зчеплення модулів

Зчеплення (Coupling) — міра взаємозалежності модулів поданим. Зчеплення — зовнішня характеристика модуля, яку бажано зменшувати.

Кількісне зчеплення вимірюється ступенем зчеплення (СЦ). Виділяють 6 типів зчеплення.

1.Зчеплення по даним (Сц=1). Модуль А викликає модуль В.

Всі вхідні і вихідні параметри модуля, що викликається, — прості елементи даних (мал. 5.13).

Мал. 5.13. Зчеплення поданим

2.Зчеплення за зразком (Сц=3). Як параметри використовуються структури даних (мал. 5.14). 53

Лекція 5. Основи проектування програмних систем.

Мал. 5.14. Зчеплення за зразком

3. Зчеплення по управлінню (Сц=4). Модуль А явно управляє функціонуванням модуля В (за допомогою прапорів або перемикачів), посилаючи йому керівники дані (мал. 5.15).

Мал. 5.15. Зчеплення по управлінню

4.Зчеплення по зовнішніх посиланнях (Сц=5). Модулі А і В посилаються на один і той же глобальний елемент даних.

5.Зчеплення по загальній області (Сц=7). Модулі розділяють одну і ту ж глобальну структуру

даних (мал. 5.16).

6. Зчеплення за змістом (Сц=9). Один модуль прямо посилається на зміст іншого модуля (не через його точку входу). Наприклад, коди їх команд перемежаються один з одним (мал. 5.16).

Мал. 5.16. Зчеплення по загальній області і змісту

На мал. 5.16 бачимо, що модулі В і D зчеплені за змістом, а модулі З, Е і N зчеплені по загальній області.

10.Складність програмної системи

Упростому випадку складність системи визначається як сума мерів складності її модулів. Складність модуля може обчислюватися різними способами.

Наприклад, М. Холстед (1977) запропонував міру довжини модуля N [33]:

N ≈ n1log2 (n1) + n2log2(n2)

де n1 — число різних операторів, п2 — число різних операндів.

Як другу метрику М. Холстед розглядав об'єм V модуля (кількість символів для запису всіх операторів і операндів тексту програми):

V = N x log2 (n1 + n2).

Разом з тим відомо, що будь-яка складна система складається з елементів і системи зв'язків між елементами і що ігнорувати внутрісистемні зв'язки безрозсудно.

Том Маккейб (1976) при оцінці складності ПС запропонував виходити з топології внутрішніх зв'язків [49]. Для цієї мети він розробив метрику цикломатической складності:

V(G)= E-N + 2 54

Лекція 5. Основи проектування програмних систем.

де Е — кількість дуг, a.N — кількість вершин в графові ПС, що управляє. Це був крок в потрібному напрямі. Подальше уточнення оцінок складності зажадало, щоб кожен модуль міг представлятися як локальна структура, що складається з елементів і зв'язків між ними.

Таким чином, при комплексній оцінці складності ПС необхідно розглядати міру складності модулів, міру складності зовнішніх зв'язків (між модулями) і міру складності внутрішніх зв'язків (усередині модулів) [28] [56]. Традиційно із зовнішніми зв'язками зіставляють характеристику «зчеплення», а з внутрішніми зв'язками — характеристику «зв'язність».

Питання комплексної оцінки складності обговоримо в наступному розділі.

11. Характеристики ієрархічної структури програмної системи

Ієрархічна структура програмної системи — основний результат попереднього проектування. Вона визначає склад модулів ПС і відносини, що управляють, між модулями. У цій структурі модуль більш високого рівня управляє модулем нижнього рівня (підлеглим).

Ієрархічна структура не відображає процедурні особливості програмної системи, тобто послідовність операцій, їх повторення, галуження і так далі Розглянемо основні характеристики ієрархічної структури, представленої на мал. 4.17.

Мал. 4.17. Ієрархічна структура програмної системи

Первинними характеристиками є кількість вершин (модулів) і кількість ребер (зв'язків між модулями). До них додаються дві глобальні характеристики — висота і ширина:

висота — кількість рівнів управління; ширина — максимальне з кількостей модулів, розміщених на рівнях управління. У нашому прикладі висота = 4, ширина = 6.

Локальними характеристиками модулів структури є:

Коефіцієнт об'єднання по входу Fan_in(i) — це кількість модулів, які прямо управляють i-м модулем.

У прикладі для модуля n: Fan_in(n)=4.

Коефіцієнт розгалуження по виходу Fan_out(i) — це кількість модулів, якими прямо управляє i-й модуль.

У прикладі для модуля m: Fan_out(m)=3.

Як оцінити якість структури?

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

Як визначити незв'язність?

Пригадаємо, що повний граф (complete graph) з п вершинами має кількість ребер ес=n(n-1) /2

а дерево (tree) з такою ж кількістю вершин — істотна менша кількість ребер et=n-l.

Тоді формулу незв'язності можна побудувати, порівнюючи кількість ребер повного графа, реального графа і дерева.

Для проектної структури з п вершинами і е ребрами незв'язність визначається по виразу

55

Лекція 5. Основи проектування програмних систем.

Значення незв'язності лежить в діапазоні від 0 до 1. Якщо Nev = 0, то проектна структура є деревом, якщо Nev = 1, то проектна структура — повний граф.

Ясно, що незв'язність дає грубу оцінку структури. Для збільшення точності оцінки слід застосувати характеристики зв'язності і зчеплення.

Хороша структура повинна мати низьке зчеплення і високу зв'язність.

Структуру також можна оцінювати за допомогою коефіцієнтів Fan_in(i) і Fan_out(i). Велике значення Fan_in(i) — ознака високого зчеплення, оскільки є мірою залежності модуля. Велике значення Fan_out(i) говорить про високу складність зухвалого модуля. Причиною є те, що для координації підлеглих модулів потрібна складна логіка управління.

Основний недолік коефіцієнтів Fan_in(i) і Fan_out(i) полягає в ігноруванні ваги зв'язків. Тут розглядаються потоки, що тільки управляють (виклики модулів). В той же час інформаційні потоки, що навантажують ребра структури, можуть істотно змінюватися, тому потрібна міра, яка враховує не тільки кількість ребер, але і кількість інформації, що проходить через них.

С. Генрі и Д. Кафура (1981) ввели інформаційні коефіцієнти ifan_in(i) і ifan_out(j) [35]. Вони враховують кількість елементів і структур даних, з яких i-й модуль бере інформацію і які оновлюються j-м модулем відповідно.

Інформаційні коефіцієнти підсумовуються із структурними коефіцієнтами sfan_in(i) і sfan_out( j), які враховують тільки виклики модулів.

В результаті формуються повні значення коефіцієнтів:

Fan_in (i) = sfan_in (i) + ifan_in (i) Fan_out (j) = sfan_out (j) + ifan_out (j).

На основі повних коефіцієнтів модулів обчислюється метрика загальної складності структури:

де length(i) — оцінка розміру i-го модуля (у вигляді LOCабо FP-оценки).

56