Проектування різних видів архітектур програмних систем

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

Перший рівень – системні компоненти. Вони здійснюють взаємодію з периферійними пристроями комп’ютерів (принтери, клавіатура, сканери, маніпулятори і т.п.), використовуються при побудові операційних систем.

Другий рівень – загальносистемні компоненти. Вони забезпечують взаємодію з універсальними сервісними системами середовища роботи прикладної системи, такими як операційні системи, СКБД, системи баз знань, системи керування мережами і т.п.

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

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

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

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

Результат проектування – архітектура й інфраструктура, що містять у собі набір об’єктів, з яких можна формувати деякий конкретний вид архітектурної схеми для конкретного середовища виконання системи, а також набір елементів керування і контролю.

Проектування архітектури системи завершується створенням опису, в якому відображені зафіксовані проектні рішення, логічна і фізична структура системи, а також способи взаємодії об’єктів. Архітектурна схема може бути: розподілена, клієнт-серверна і багаторівнева.

Розподілена схема реалізує взаємодію компонентів системи, розташованих на різних комп’ютерах через стандартні протоколи виклику віддалених методів RPC (Remote Procedure Calls), RMI (Remote Method Invocation), що представлені в проміжних середовищах (COM/DCOM, CORBA) [15, 16]. Взаємодіючі компоненти можуть бути неоднорідними, створеними на різних мовах програмування (С, С++, Паскаль, Java, Basic, Smalltalk і ін.), що допускається в проміжному середовищі, наприклад, CORBA (рис. 4.7).

 

 

Рис. 4.7. Зв’язок між мовами L1, L2, …, Ln через інтерфейси CORBA

 

Для кожної пари мов взаємодіючих компонентів створюються інтерфейси (Li, L n) за кількістю пар мов програмування, що взаємодіють між собою. Інтерфейси між мовами Li, Ln містять у собі опис:

– зв'язків двох об’єктів у цих мовах, що здійснюються через stub (стаб, заглушку) і skeleton (каркас) у мові IDL;

– атрибутів викликів в stub і skeleton, що відображаються в операції, а операції – в методи.

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

Клієнтські і серверні «заглушки» виступають у ролі класів, об’єкти яких використовуються реалізаціями методів клієнта і сервера. Спільний кореневий об’єкт виконує метод об'єкта-сервера (функцію, сервіс, операцію) за умови, якщо інший об’єкт, який виступає в ролі клієнта для нього, посилає йому виклик для виконання цього методу.

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

Головне завдання схеми клієнт–сервер – забезпечення доступу до ресурсів (апаратури, ПЗ і даних) і їхнього розподілу. При реалізації архітектури клієнт- сервер компонент сервер керує ресурсами і доступом до них, а клієнт їх використовує. Ця архітектура заснована на концепції розподілених об’єктів, які інкапсулюють ресурс і надають послуги іншим об’єктам.

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

Як метод проектування архітектури об’єктно-орієнтованих програмних систем застосовується UML [17, 18]. Зв’язки між об’єктами сервера і клієнта задаються діаграмами взаємодії або послідовності. Схема процесу розроблення в UML з використанням stub і skeleton, семантику яких розглянуто вище, наведена на рис. 4.8.

Діаграми станів задають обмеження на операції об’єктів сервера, визначаючи способи виклику операцій і поведінку об’єктів. Сутність стилю проектування в рамках уніфікованого процесу RUP [19] полягає в описі усіх видів діяльності, виконуваних на моделях (аналізу, проектування, розробки і тестування) процесу ЖЦ.

Моделі охоплюють всі аспекти побудови структури і відображення поведінки об’єктів системи. До складу архітектури входять статичні і динамічні об’єкти, їхні зв’язки й інтерфейси між ними. У ній відображаються структура виділених підсистем, довідників, словників, а також результати всіх процесів.

 

 

Рис. 4.8. Процес розроблення інтерфейсних об’єктів з UML

 

Логічна структура проектованої системи – це композиція об’єктів і готових програмних продуктів, що виконують відповідні функції системи.

Композиція ґрунтується на таких положеннях:

1) кожна підсистема повинна відображати вимоги і спосіб їхньої реалізації (сценарій або прецедент);

2) змінювані функції виділяються в підсистемі так, щоб для них прогнозувалися зміни вимог і окремі об’єкти, зв’язані з актором;

3) зв’язок об’єктів здійснюється через інтерфейс;

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

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

– логічного об’єднання і збирання об’єктів;

– комунікативного об’єднання об’єктів через загальне джерело даних;

– процедурного об’єднання за допомогою операторів виклику;

– функціонального об’єднання об’єктів.

Якщо в заново створеній системі використана успадкована система, то вона знімає проблему дублювання і скорочує обсяг робіт при проектуванні архітектури системи. У складних програмних системах кількість об’єктів може нараховувати сотні, їх композиції не будуть мати виразного вигляду, навіть з урахуванням того, що об’єкти різних сценаріїв можуть збігатися, тому в такому випадку потрібен додатковий аналіз для їхнього ототожнення.

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

Для реалізації інтерфейсу між службою та системою кожного разу створюється новий об’єкт. Разом з тим перехід на нову платформу може вимагати побудови допоміжних інтерфейсних або керуючих об’єктів і коригування існуючих. Крім того, може виникнути необхідність у використанні готових підсистем, структура яких відрізняється від тих підсистем, що були визначені на основі аналізу вимог до системи. У цьому випадку вносяться відповідні зміни в модель вимог і в архітектуру системи.