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

Мал. 5.9. Широкомовна модель

Мал. 5.10. Модель, керована перериваннями

У моделі, керованій перериваннями (мал. 5.10), всі переривання розбиті на групи — типи, які утворюють вектор переривань. Для кожного типу переривання є свій обробник. Кожен обробник реагує на свій тип переривання і запускає свій процес.

5. Декомпозиція підсистем на модулі

Відомо два типи моделей модульної декомпозиції:

•модель потоку даних;

•модель об'єктів.

Уоснові моделі потоку даних лежить розбиття по функціях.

Модель об'єктів заснована на слабо зчепленій суті, що має власні набори даних, стани і набори операцій.

Очевидно, що вибір типу декомпозиції повинен визначатися складністю розбиваної підсистеми.

6. Модульність

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

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

За визначенням Р. Майерса, модульність — властивість ПЗ, що забезпечує інтелектуальну можливість створення скільки завгодно складної програми. Проілюструємо цю точку зору.

Хай З(х) — функція складності вирішення проблеми х, Т(х) — функція витрат часу на вирішення проблеми х. Для двох проблем р1 і р2 із співвідношення З(р1)> З(р2) витікає, що

Співвідношення (5.2) — це обгрунтування модульності. Воно приводить до висновку «розділяй і володарюй» — складну проблему легко вирішити, розділивши її на керовані частини. Результат, виражений нерівністю (5.2), має важливе значення для модульності і ПО. Фактично, це аргумент на користь модульності.

47

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

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

Мал. 5.11. Витрати на модульність

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

зовні він простіший, ніж усередині; його простіше використовувати, чим побудувати.

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

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

Мал. 5.12. Інформаційна закритість модуля

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

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

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

Переваги інформаційної закритості:

•забезпечується можливість розробки модулів різними, незалежними колективами;

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

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

48