Лекція 6. Побудова архітектури та структури ПЗ.
Лекція 6.ПОБУДОВА АРХІТЕКТУРИ ПЗ
Поняття архітектури і завдання її опису. Основні класи архітектури програмних засобів. Взаємодія між підсистемами і архітектурні функції. Контроль архітектури програмних засобів.
1.Поняття архітектури програмного засобу.
Архітектура ПЗ - це його будова як воно видно (або повинно бути видно) из-вне його, тобто представлення ПЗ як системи, що складається з деякої сукупності взаємодіючих підсистем. Як такі підсистеми виступають зазвичай окремі програми. Розробка архітектури є першим етапом боротьби з складністю ПЗ, на якому реалізується принцип виділення щодо незалежних компонент.
Основні завдання розробки архітектури ПЗ:
•виділення програмних підсистем і відображення на них зовнішніх функцій (заданих в зовнішньому описі) ПЗ;
•визначення способів взаємодії між виділеними програмними підсистемами.
Зурахуванням ухвалюваних на цьому етапі рішень проводиться подальша конкретизація і функціональних специфікацій.
•Основні класи архітектури програмних засобів.
Розрізняють наступні основні класи архітектури програмних засобів [6.1]:
•цілісна програма;
•комплекс автономно виконуваних програм;
•шарувата програмна система;
•колектив паралельно виконуваних програм.
Цілісна програма представляє вироджений випадок архітектури ПЗ: до складу ПЗ входить тільки одна програма. Таку архітектуру вибирають зазвичай у тому випадку, коли ПЗ повинне виконувати одну яку-небудь яскраво виражену функцію і її реалізація не представляється дуже складною. Природно, що така архітектура не вимагає якого-небудь опису (окрім фіксації класу архітектури), оскільки відображення зовнішніх функцій на цю програму тривіально, а визначати спосіб взаємодії не потрібно (через відсутність якої-небудь зовнішньої взаємодії програми, окрім як взаємодії її з користувачем, а останнє описується в документації по застосуванню ПЗ).
Комплекс автономно виконуваних програм складається з набору програм, такого, що:
•будь-яка з цих програм може бути активізована (запущена) користувачем;
•при виконанні активізованої програми інші програми цього набору не можуть бути активізовані до тих пір, поки не закінчить виконання активізована програма;
•всі програми цього набору застосуються до одного і того ж інформаційного середовища.
Таким чином, програми цього набору по управлінню ніяк не взаємодіють - взаємодія між ними здійснюється тільки через загальне інформаційне середовище.
Шарувата програмна система складається з деякої впорядкованої сукупності програмних підсистем, званих шарами, такий, що:
•на кожному шарі нічого не відомо про властивості (і навіть існуванні) подальших (вищих) шарів;
•кожен шар може взаємодіяти по управлінню (звертатися до компонентів) з безпосередньо попереднім (нижчим) шаром через заздалегідь певний інтерфейс, нічого не знаючи про внутрішню будову всіх попередніх шарів;
•кожен шар має в своєму розпорядженні певні ресурси, які він або приховує від інших шарів, або надає безпосередньо подальшому шару (через вказаний інтерфейс) деякі їх абстракції.
Таким чином, в шаруватій програмній системі кожен шар
може реалізувати деяку абстракцію даних. Зв'язки між шарами обмежені передачею значень параметрів звернення кожного шару до суміжного знизу шарую і видачею результатів цього звернення від нижнього шару верхньому. Неприпустимо використання глобальних даних декількома шарами.
60
Лекція 6. Побудова архітектури та структури ПЗ.
Як приклад розглянемо використання такої архітектури для побудови операційної системи. Таку архітектуру застосував Дейкстра при побудові операційної системи THE [6.2]. Ця операційна система складається з чотирьох шарів (див. мал. 6.1). На нульовому шарі проводиться обробка всіх переривань і виділення центрального процесора програмам (процесам) в пакетному режимі. Тільки цей рівень обізнаний про мультипрограмні аспекти системи. На першому шарі здійснюється управління сторінковою організацією пам'яті. Всім вищестоящим шарам надається віртуальна безперервна (не сторінкова) пам'ять. На другому шарі здійснюється зв'язок з консоллю (пультом управління) оператора. Тільки цей шар знає технічні характеристики консолі. На третьому шарі здійснюється буферизація вхідних і вихідних потоків даних і реалізуються так звані абстрактні канали введення і виводу, так що прикладні програми не знають технічних характеристик пристроїв введення і виводу.
Прикладні програми
3: Управління вхідними і вихідними потоками даних
2: Забезпечення зв'язку з консоллю оператора
1: Управління пам'яттю
0: Диспетчеризація і синхронізація процесів
Комп'ютер
Мал. 6.1. Архітектура операційної системи THE.
Колективом програм, що паралельно діють, є набір програм, здатних взаємодіяти між собою, знаходячись одночасно у стадії виконання. Це означає, що такі програми, по-перше, викликані в оперативну пам'ять, активізовані і можуть поперемінно розділяти за часом один або декілька центральних процесорів, а по-друге, здійснювати між собою динамічні (в процесі виконання) взаємодії, на базі яких проводитися їх синхронізація. Звичайна взаємодія між такими процесами проводиться шляхом передачі один одному деяких повідомлень.
Простим різновидом такої архітектури є конвеєр, засоби для організації якого є в операційній системі UNIX [6.3]. Конвеєром є послідовність програм, в якій стандартне виведення кожної програми, окрім найостаннішої, пов'язане із стандартним введенням наступної програми цієї послідовності (див. мал. 6.2). Конвеєр обробляє деякий потік повідомлень. Кожне повідомлення цього потоку поступає на введення першій програмі, яка обробивши його передає перероблене повідомлення наступної програми, а сама починає обробку чергового повідомлення потоку. Таким же чином діє кожна програма конвеєра: отримавши повідомлення від попередньої програми і обробивши його, вона передає перероблене повідомлення наступної програми, а остання програма конвеєра виводить результат роботи всього конвеєра (результуюче повідомлення). Таким чином, в конвеєрі, що складається з n програм, може одночасно знаходитися в обробці до n повідомлень. Звичайно, внаслідок того, що різні програми конвеєра можуть витратити на обробку чергових повідомлень різні відрізки часу, необхідно забезпечити яким-небудь чином синхронізацію цих процесів (деякі процеси можуть знаходитися у стадії очікування або можливості передати перероблене повідомлення, або можливості отримати чергове повідомлення).
Мал. 6.2. Конвеєр програм, що діють паралельно .
У більш загальному випадку колектив програм, що паралельно діють, може бути організований в систему з портами повідомлень.
Порт повідомлень є програмною підсистемою, обслуговуючою деяку чергу повідомлень: вона може приймати на зберігання від програми яке-небудь повідомлення, ставлячи його в чергу, і може видавати чергове повідомлення іншої програми на її вимогу. Повідомлення, передане якою-небудь програмою деякому порту, вже не належатиме цій програмі (і використовувати її ресурси), але воно
61
Лекція 6. Побудова архітектури та структури ПЗ.
не належатиме і ніякий іншій програмі, поки по черзі не буде передано якій-небудь програмі по її запиту. Таким чином, програма, передавальна повідомлення не знаходитиметься у стадії очікування поки програма, що приймає це повідомлення, не буде готова його обробляти (якщо тільки не буде переповнений приймаючий порт).
Приклад програмної системи з портами повідомлень приведений на мал. 6.3. Порт U може розглядатися як порт ввідних повідомлень для представленого на цьому малюнку колективу програм, що паралельно діють, а порт W - як порт вивідних повідомлень для цього колективу програм.
Рис. 6.3. Приклад програмної системи з портами повідомлень.
Програмні системи з портами повідомлень можуть бути як у жорсткій конфігурації, так і у гнучкій конфігурації. У системах з портами жорсткої конфігурації з кожною програмою можуть бути жорстко зв'язані один або декілька вхідних портів. Для передачі повідомлення така програма повинна явно вказати адресу передачі: ім'я програми і ім'я її вхідного порту. В цьому випадку при зміні конфігурації системи доведеться коректувати використовувані програми: змінювати адреси передач повідомлень. У системах з портами гнучкої конфігурації з кожною програмою пов'язані як вхідні, так і вихідні віртуальні порти. Перед запуском такої системи повинна проводитися її попередня настройка за допомогою спеціальної програмної компоненти, що здійснює поєднання кожного вихідного віртуального порту з яким-небудь вхідним віртуальним портом на підставі інформації, що задається користувачем. Тим самим при зміні конфігурації системи в цьому випадку не вимагається якого-небудь коректування використовуваних програм - необхідні зміни повинні бути відбиті в інформації для настройки. Проте в цьому випадку потрібно мати спеціальну програмну компоненту, таку, що здійснює настройку системи.
•Архітектурні функції.
Для забезпечення взаємодії між підсистемами у ряді випадків не потрібно створювати які-небудь додаткові програмні компоненти (крім реалізації зовнішніх функцій) - для цього може бути досить заздалегідь фіксованих угод і стандартних можливостей базового програмного забезпечення (операційної системи). Так в комплексі автономно виконуваних програм для забезпечення взаємодії достатньо опису (специфікації) загального зовнішнього інформаційного середовища і можливостей операційної системи для запуску програм. У шаруватій програмній системі може виявитися достатнім специфікації виділених програмних шарів і звичайний апарат звернення до процедур. У програмному конвеєрі взаємодія між програмами також може забезпечувати операційна система (як це має місце в операційній системі UNIX).
Проте у ряді випадків для забезпечення взаємодії між програмними підсистемами може потрібно створення додаткових програмних компонент. Так для управління роботою комплексу автономно виконуваних програм часто створюють спеціалізований командний інтерпретатор, зручніший в даній наочній області для підготовки необхідного зовнішнього інформаційного середовища і запуску необхідної програми, чим базовий командний інтерпретатор використовуваної операційної системи. У шаруватих програмних системах може бути створений особливий апарат звернення до процедур шаруючи (наприклад, що забезпечує паралельне виконання цих процедур). У колективі програм, що паралельно діють, для управління портами повідомлень потрібна спеціальна програмна підсистема. Такі програмні компоненти ніяких зовнішніх функцій не виконують - вони реалізують функції,
62
Лекція 6. Побудова архітектури та структури ПЗ.
виниклі в результаті розробки архітектури програмного засобу. У зв'язку з цим такі функції ми називатимемо архітектурними.
•Контроль архітектури програмних засобів.
Для контролю архітектури ПЗ використовується суміжний контроль иручная імітація.
Суміжний контроль архітектури ПЗ зверху - це її контроль розробниками зовнішнього опису: розробниками специфікації якості і розробниками функціональної специфікації. Суміжний контроль архітектури ПЗ знизу - це її контроль потенційними розробниками програмних підсистем, що входять до складу ПЗ відповідно до розробленої архітектури.
Ручна імітація архітектури ПЗ проводиться аналогічно ручній імітації функціональної специфікації, тільки метою цього контролю є перевірка взаємодії між програмними підсистемами. Так само як і у разі ручної імітації функціональної специфікації ПЗ повинні бути спочатку підготовлені тести. Потім група розробників винна для кожного такого тесту імітувати роботу кожної програмної підсистеми, що входить до складу ПЗ. При цьому роботу кожної підсистеми імітує один який-небудь розробник (не автор архітектури), ретельно виконуючи всі взаємодії цієї підсистеми з іншими підсистемами (точніше, з розробниками, що їх імітують) відповідно до розробленої архітектури ПЗ. Тим самим забезпечується імітаційне функціонування ПЗ в цілому в рамках архітектури, що перевіряється.
63