Тема 7. Розробка архітектури прогоамних систем
Розбиття системи на підсистеми.
Розділи, топологія та асинхронність об’єктів.
Розподіл підсистем за процесорами та задачами.
Управління сховищами даних, глобальними ресурсами і реалізація управління програмним забезпеченням.
Архітектури прикладних систем.
Архітектура системи управління банківською мережею.
Розробка об’єктів системи.
Спільний розгляд трьох моделей.
Алгоритм реалізації операції.
Оптимізація розробки.
Реалізація управління.
Уточнення успадкування та реалізація залежностей.
[2; 3; 7; 13]
Після того як прикладна задача досліджена та результати її дослідження зафіксовані у вигляді об’єктної, динамічної та функціональної моделей, можна розпочати конструювання системи. На етапі конструювання приймаються рішення про розбиття системи на підсистеми, розподіл підсистем за процесорами та іншим апаратним обладнанням і встановлюються основні принципи та концепції, які формують основу подальшої докладної розробки програмного забезпечення системи.
Зовнішня організація системи називається архітектурою системи. Вибір архітектури системи є ще однією задачею, яка вирішується на етапі її конструювання.
Конструювання системи завершується конструюванням її об’єктів. На цьому етапі розробляються повні визначення класів та залежностей, які використовуються на етапі реалізації системи. Крім того, визначаються та конструюються внутрішні об’єкти й оптимізуються структури даних і алгоритмів.
Під час аналізу вимог до системи основна увага приділялася з’ясуванню того, що повинно бути зроблено. На етапі розробки вирішувалося питання, як реалізувати рішення етапу аналізу.
Спочатку розробляється загальна структура (архітектура) системи. Архітектура системи визначається її розбиттям на підсистеми, задає контекст, у рамках якого приймаються проектні рішення на наступних етапах розробки. Прийнявши рішення про структуру системи в цілому, розробник системи виконує її розбиття на підсистеми, залучаючи розробників підсистем, що дає змогу розподілити подальшу роботу між ними.
Розробник системи має прийняти такі рішення:
визначити розбиття системи на підсистеми;
виявити асинхронний паралелізм у системі;
розподілити підсистеми за процесорами обчислювального комплексу та незалежними задачами;
організувати управління сховищами даних;
організувати управління глобальними ресурсами;
вибрати принципи реалізації управління програмним забезпеченням;
організувати управління примежовими ситуаціями.
7.1. Розбиття системи на підсистеми. Ієрархія підсистем
Перше, що необхідно зробити, починаючи етап розробки системи, виявити її розбиття на деяку кількість компонентів — підсистем. Підсистема не є ні об’єктом, ні функцією; підсистема — це набір (пакет) класів, залежностей, операцій, подій та обмежень, які взаємозв’язані та мають досить добре визначений та по можливості невеликий інтерфейс з іншими підсистемами. Підсистема звичайно визначається через служби, які вона забезпечує. Службою називається набір взаємозв’язаних функцій, які разом забезпечують якусь функціональність, наприклад виконання вводу-виводу, зарисовку картинок, виконання арифметичних дій. Підсистема визначає узгоджений спосіб розгляду однієї зі сторін прикладної задачі, для розв’язування якої розробляється система. Наприклад, система файлів — підсистема операційної системи; вона забезпечує набір взаємозв’язаних абстрактних операцій, які більшою мірою (але не повністю) незалежні від абстрактних операцій, які забезпечуються іншими підсистемами.
Кожна підсистема має добре визначений інтерфейс з останньою частиною системи (іншими підсистемами). Цей інтерфейс визначає форму всіх взаємодій з підсистемою та всі потоки даних через її межі, але не специфікує внутрішню структуру підсистеми та особливості її реалізації. Тому кожна підсистема може розроблятися незалежно від інших підсистем.
Підсистеми мають визначатися так, щоб більша частина взаємодій лишалась усередині підсистем для зменшення глобальних потоків даних та скорочення залежностей між підсистемами. Підсистем має бути не дуже багато (у межах десятка). Деякі підсистеми можуть бути в свою чергу підрозділені на підсистеми. Підсистеми найнижчого рівня називаються модулями.
Дві підсистеми можуть взаємодіяти одна з одною або як клієнт та постачальник (клієнт–сервер), або як рівноправні партнери (спів- програми). У першому випадку клієнт викликає сервер, який виконує деякий запит клієнта і повертає результат; клієнт має знати інтерфейс сервера, але сервер може не знати інтерфейсів клієнта, оскільки всі взаємодії ініціюються клієнтом. У разі співпрограмної взаємодії обидві підсистеми викликають одна одну. Звернення підсистеми до іншої підсистеми не обов’язково зв’язане з негайним одержанням відповіді. Співпрограмні взаємодії є більш складними, бо обидві підсистеми мають знати інтерфейси одна одної. Тому слід намагатися, щоб більша частина підсистем взаємодіяла як клієнт та сервер.
Розбиття системи на підсистеми може бути організоване або як послідовність горизонтальних рівнів, або як набір вертикальних розділів.
Рівні
Рівнева система може розглядатись як упорядкована множина віртуальних світів, кожен з яких побудовано на базі понять, які підтримуються його підсистемами: підсистеми одного рівня забезпечують реалізацію підсистем наступного рівня. Об’єкти кожного рівня можуть бути незалежними, хоч зрідка об’єкти різних рівнів можуть відповідати один одному. Кожна підсистема знає про підсистеми нижчих рівнів і нічого не знає про вищі рівні. Залежність клієнт–сервер існує між більш верхнім (клієнт) та більш нижчими рівнями (сервери). При цьому кожен рівень може мати свій власний набір класів та операцій. Кожен рівень реалізується через класи та операції нижчих рівнів. Рівневі архітектури бувають двох видів: відкриті та замкнені. У замкненій архітектурі кожний рівень будується на базі безпосередньо наступного за ним рівня. Це скорочує залежності між рівнями та спрощує внесення змін. У відкритій архітектурі кожний рівень будується на базі всіх наступних за ним рівнів. Це зменшує потребу у перевизначенні операцій на кожному рівні та забезпечує ефективніший і компактніший код. Проте відкрита архітектура не задовольняє принцип зберігання інформації, оскільки зміни в якійсь підсистемі можуть потребувати відповідних змін у підсистемах вищих рівнів.
Звичайно лише підсистеми найвищого та найнижчого рівнів можуть бути виведені з постановки задачі: найвищий рівень — це потрібна система, а найнижчий рівень — це доступні ресурси: апаратура, операційна система, яка має бібліотеки. Проміжні рівні вводяться розробником системи.
Система з рівневою архітектурою при перенесенні на іншу платформу потребує переписування лише одного (найнижчого) рівня. Приклад системи з рівневою архітектурою подано на рис. 71.
Рис. 71. Приклад системи з рівневою архітектурою