Лекція 8. Архітектура програмного забезпечення
План
Аналіз області розв’язків
Архітектура програмного забезпечення
Основні класи архітектур програмних засобів
Архітектурні функції
Контроль архітектури програмних засобів
Розробка і оцінка архітектури на основі сценаріїв
1. Аналіз області розв’язків
Припустимо, ми розібралися в предметній області, зрозуміли, що потрібно від майбутньої програмної системи, навіть зафіксували настільки повно, наскільки змогли, вимоги і побажання всіх зацікавлених осіб до всіх аспектів якості програми. Що робити далі?
На цьому етапі (а точніше, набагато раніше, зазвичай ще в ході аналізу предметної області) досліджуються можливі способи розв’язків тих задач, які поставлені у вимогах. Не завжди буває потрібно спеціальне вивчення цього питання — найчастіше наявний досвід розробників відразу підказує, як можна вирішувати поставлені задачі. Проте іноді, все ж таки, виникає потреба спочатку зрозуміти, як це можна зробити і, взагалі, чи можливо це зробити і при яких обмеженнях.
Таким чином, явно або неявно, проводиться аналіз області розв’язків. Метою цієї діяльності є розуміння, чи можна взагалі розв’язати завдання, що стоять перед системою, що розробляється, за яких умов і обмежень це можна зробити, як вони розв’язуються, якщо розв’язок є, а якщо немає — чи не можна придумати спосіб його знайти або отримати хоч би приблизне рішення, і т.п. Зазвичай завдання добре досліджене в рамках якої-небудь області людських знань, але іноді доводиться витратити деякі зусилля на знаходження власних розв’язків. Крім того, розв’язків зазвичай декілька і вони розрізняються за деякими характеристиками, здатним згодом зіграти важливу роль в процесі розвитку і експлуатації створеної на їх основі програми. Тому важливо зважити їх плюси і мінуси і визначити, які з них найбільш підходять в рамках даного проекту, або вирішити, що всі вони повинні використовуватися для забезпечення більшої гнучкості ПЗ.
Коли визначені принципові способи розв’язування всіх поставлених задач (мабуть, в якихось обмеженнях), основною проблемою стає спосіб організації програмної системи, який дозволив би реалізувати всі ці розв’язки і при цьому задовольнити вимогам, що стосуються не функціональних аспектів програми, що розробляється. Шуканий спосіб організації ПЗ у вигляді системи взаємодіючих компонентів називають архітектурою, а процес її створення — проектуванням архітектури ПЗ.
2. Архітектура програмного забезпечення
Під архітектурою ПЗ розуміють набір внутрішніх структур ПЗ, які видно з різних точок зору і складаються з компонентів, їх зв'язків і можливих взаємодій між компонентами, а також доступних ззовні властивостей цих компонентів.
Під компонентом в цьому розумінні мається на увазі довільний структурний елемент ПЗ, який можна виділити, визначивши інтерфейс взаємодії між цим компонентом і всім, що його оточує. Зазвичай при розробці ПЗ термін "компонент" (див. далі при обговоренні компонентних технологій) має дещо інший, вужчий сенс — це одиниця розгортання, найменша частина системи, яку можна включити або не включити в її склад. Такий компонент також має певний інтерфейс і задовольняє деякому набору правил, званому компонентною моделлю. Там, де можливі непорозуміння, буде вказано, в якому сенсі вживається цей термін. У цій лекції до обговорення UML ми використовуватимемо переважно широке розуміння цього терміну, а в далі — навпаки, вузьке.
У визначенні архітектури згадується набір структур, а не одна структура. Це означає, що в якості різних аспектів архітектури, різних поглядів на неї виділяються різні структури, відповідні різним аспектам взаємодії компонентів.
Приклади таких аспектів:
опис типів компонентів і типів статичних зв'язків між ними за допомогою діаграм класів;
опис композиції компонентів за допомогою структур об'єктів, що посилаються один на одного;
опис поведінки компонентів за допомогою моделювання їх як набору кінцевих автоматів, що взаємодіють, передають один одному деякі події.
Архітектура програмної системи схожа на набір карт деякої території. Карти мають різні масштаби, на них вказані різні елементи (адміністративно-політичне ділення, рельєф і тип місцевості — ліс, степ, пустеля, болота і ін., економічна діяльність і зв'язки), але вони об'єднуються тим, що всі представлені на них відомості співвідносяться з географічним положенням. Так само архітектура ПЗ є набір структур або подань, що мають різні рівні абстракції і що показують на різні аспекти (структуру класів ПЗ, структуру розгортання, тобто прив'язки компонентів ПЗ до фізичних машин, можливі сценарії взаємодій компонентів і ін.), об'єднуваних зіставленням всіх представлених даних із структурними елементами ПЗ. При цьому рівень абстракції даного подання є аналогом масштабу географічної карти.
Архітектура визначає більшість характеристик якості ПЗ в цілому. Архітектура служить також основним засобом спілкування між розробниками, а також між розробниками і рештою всіх осіб, зацікавленими в даному ПЗ.
Вибір архітектури задає спосіб реалізації вимог на високому рівні абстракції. Саме архітектура майже повністю визначає такі характеристики ПЗ як надійність, переносимість і зручність супроводу. Вона також значно впливає на зручність використання і ефективність ПЗ, які, проте, сильно залежать і від реалізації окремих компонентів. Значно менше вплив архітектури на функціональність — зазвичай задану функціональність можна реалізувати, використавши абсолютно різну архітектуру.
Тому вибір між тією або іншою архітектурою визначається більшою мірою саме нефункціональними вимогами і необхідними властивостями ПЗ з погляду зручності супроводу і переносимості. При цьому для побудови хорошої архітектури треба враховувати можливі суперечності між вимогами до різних характеристик і уміти вибирати компромісні рішення, що дають прийнятні значення за всіма показниками.
Так, для підвищення ефективності в загальному випадку вигідніше використовувати монолітну архітектуру, в якій виділено невелике число компонентів (гранично — єдиний компонент). Цим забезпечується економія як пам'яті, оскільки кожен компонент зазвичай має свої дані, а тут число компонентів мінімальне, так і часу роботи, оскільки можливість оптимізувати роботу алгоритмів обробки даних є також тільки в рамках одного компоненту.
З іншого боку, для підвищення зручності супроводу, навпаки, краще розбити систему на велике число окремих маленьких компонентів, з тим щоб кожний з них вирішував свою невелику, але чітко визначену частину загального завдання. При цьому, якщо виникають зміни у вимогах або проекті, їх зазвичай можна звести до зміни в постановці однієї, рідше двох або трьох таких підзадач і, відповідно, змінювати тільки компоненти, що відповідають за розв’язування цих підзадач.
З третього боку, для підвищення надійності краще використовувати або невеликий набір простих компонентів, або дублювання функцій, тобто зробити декілька компонентів відповідальними за розв’язування однієї підзадачі. Відмітимо, проте, що помилки в ПЗ найчастіше носять невипадковий характер. Вони повторювані, на відміну від апаратного забезпечення, де помилки пов'язані часто з випадковими змінами характеристик середовища і можуть бути подолані простим дублюванням компонентів без зміни їх внутрішньої реалізації. Тому при такому забезпеченні надійності треба в різних компонентах використовувати способи розв’язування однієї і тієї ж задачі, що достатньо сильно відрізняються.
Іншим прикладом суперечливих вимог служать характеристики зручності використання і захищеності. Чим сильніше захищена система, тим більше перевірок, процедур ідентифікації і ін. потрібно проходити користувачам. Відповідно, тим менш зручна для них робота з такою системою. При розробці реальних систем доводиться шукати деякий розумний компроміс, щоб зробити систему досить захищеною і здатною поставити відчутну перешкоду для несанкціонованого доступу до її даних і, в той же час, не відлякати користувачів складністю роботи з нею.
Основні завдання розробки архітектури ПЗ:
Виділення програмних підсистем і відображення на них зовнішніх функцій (заданих в зовнішньому описі) ПЗ;
визначення способів взаємодії між виділеними програмними підсистемами.
З урахуванням ухвалюваних на цьому етапі рішень проводиться подальша конкретизація і функціональних специфікацій.