Контроль архітектури програмних засобів.

Для контролю архітектури ПЗ використовується суміжний контроль і ручна імітація.

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

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

 

 

Розробка програмного модуля. Властивості та характеристики модуля: інформаційна закритість модуля, зв’язність та зчеплення.

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

Основні властивості модулей:

- Назва модуля, по якій можна до нього звернутися;

- Визначеність модуля (для модуля повинні бути визначені вхідні та вихідні дані і алгоритм рішення задачі)

- структурна замкненість (наявність однієї точки входу і однієї точки виходу);

- функціональна незалежність (виконання однієї визначеної функції. Ця функція може бути подана набором елементарних складових функцій, але кожна з них не є самостійною з урахуванням загального призначення програми).

- Зміни в одному модулі не повинні впливати на інший.

- Модуль повинен передавати керування тому, який його викликає.

 

2.

Для оцінки програмного модуля застосовуються наступні характеристики:

 

Інформаційна закритість

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

Інформаційна закритість означає наступне:

1. Всі модулі незалежні, обмінюються лише інформацією, яка необхідна для роботи;

2. Доступ до операцій і структур даних модуля обмежений.

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

Ідеальний модуль відіграє роль „чорного ящика”, вміст якого невидимий клієнтам. Він простий у використанні – кількість „ручок і органів управління” ним невелика. Його легко розвивати і коректувати в процесі супроводу ПЗ. Для забезпечення таких можливостей система внутрішніх і зовнішніх зв’язків модуля повинна відповідати особливим вимогам.

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

Зв’язність модуля – це міра залежності його частин, внутрішня характеристика модуля. Чим вища зв’язність модуля, тим кращий результат проектування, тобто тим „чорніший” його ящик, тим менше „ручок управління” на ньому знаходиться і тим простіші ці „ручки”.

Для вимірювання зв’язності використовують поняття сили зв’язності. Існує 7 типів зв’язності:

1. Функціональна зв’язність (10). Частини модуля разом реалізують одну функцію. Функціонально зв’язаний модуль містить елементи, які беруть участь у виконанні однієї і тільки однієї проблемної задачі. Коли клієнт викликає модуль, виконується тільки одна робота, без залучення зовнішніх обробників. Деякі з функціонально зв’язних модулів дуже прості, інші складні. Не дивлячись на складність модуля і на те, що його обов’язки виконують декілька функцій, якщо його дії можна представити як єдину проблемну функцію (з точки зору клієнта), тоді вважають, що модуль функціонально зв’язний. Програми, побудовані з функціонально зв’язних модулів, легше супроводжувати. Помилково вважати, що будь-який модуль можна розглядати як однофункціональний – існує багато різновидностей модулів, які виконують для клієнтів перелік різних робіт, і цей перелік не можна розглядати як єдину проблемну функцію. Критерій при визначенні рівня зв’язності цих нефункціональних модулів – як зв’язані один з одним різні дії, які вони виконують.

2. Інформаційна (послідовна) зв’язність (9). Вихідні дані однієї частини використовуються як вхідні дані в іншій частині модуля. Тобто при такій зв’язності елементи-обробники модуля утворюють конвеєр для обробки даних. Супроводжувати модулі з інформаційною зв’язністю легко, але можливості повторного використання модулів невисока.

3. Комунікативна зв’язність (7). Частини модуля зв’язані за даним (працюють з однією і тою ж структурою даних). З точки зору клієнта проблема використання комунікативно зв’язного модуля полягає в надлишковості отримуваних результатів. Майже завжди розбиття комунікативно зв’язного модуля на окремі функціонально зв’язні модулі покращує супроводжуваність системи.

4. Процедурна зв’язність (5). Частини модуля зв’язані порядком виконуваних ними дій, які реалізують деякий сценарій поведінки. При досягненні процедурної зв’язності попадають в пограничну ділянку між доброю (для модулів з більш високими рівнями зв’язності) і поганою супроводжуваністю (для модулів з більш низькими рівнями зв’язності). Процедурно зв’язний модуль складається з елементів, які реалізують незалежні дії, для яких задано порядок роботи, тобто порядок передачі управління. Залежності за даними між елементами немає.

5. Часова зв’язність (3). Частини модуля не зв’язані, але необхідні в один і той же період роботи системи. Недолік: сильний взаємний зв’язок з іншими модулями та велика чутливість до внесення змін. При часовій зв’язності елементи-обробники модуля прив’язані до конкретного періоду часу. Класичним прикладом модуля такого типу зв’язності є модуль ініціалізації.

6. Логічна зв’язність (1). Частини модуля об’єднані за принципом функціональної подібності. Наприклад, модуль складається з різних підпрограм обробки помилок. При використанні такого модуля клієнт вибирає тільки одну з підпрограм. Недоліками таких модулів є складність спряження та велика ймовірність внесення помилок при зміні спряження заради однієї з функцій.

7. Зв’язність за співпадінням (0). В модулі відсутні явно виражені внутрішні зв’язки.

Зв’язність за співпадінням, логічна та часова зв’язності – результат неправильного планування архітектури, а процедурна зв’язність – результат поганого планування архітектури ПЗ.

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

- Правило паралельності. Якщо всі дії модуля мають декілька рівнів зв’язності, то модулю присвоюють самий сильний рівень.

- Правило послідовності. Якщо дії в модулі мають різні рівні зв’язності, то модулю присвоюють самий слабкий рівень.

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

Зчеплення модулів – це міра взаємозалежності модулів за даними, це зовнішня характеристика модуля, яку бажано зменшувати. Три чинники роблять вплив на зчеплення модулів:

- Кількість елементів даних, які передаються між ними.

- Кількість управляючих даних, які передаються між модулями.

- Кількість глобальних елементів даних, які спільно використовуються модулями.

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

Кількісно зчеплення вимірюється мірою зчеплення і виділяють 6 типів.

1. Зчеплення за даними (1). Модуль А викликає модуль В. Усі вхідні й вихідні параметри викликаного модуля – прості елементи даних.

2. Зчеплення за зразком (3). В якості параметрів використовуються структури даних.

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

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

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

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