архітектурні функції

Основні класи архітектур програмних засобів

Розрізняють такі основні класи архітектур програмних засобів [1]:

• цільна програма;
• комплекс автономно виконуваних програм;
• шарувата програмна система;
• колектив паралельно виконуваних програм.

Цілісна програма являє вироджений випадок архітектури ПС: до складу ПС входить тільки одна програма. Таку архітектуру вибирають зазвичай в тому випадку, коли ПС повинно виконувати одну яку-небудь яскраво виражену функцію і її реалізація не видається занадто складною. Природно, що така архітектура не потребує будь-якого опису (крім фіксації класу архітектури), так як відображення зовнішніх функцій на цю програму тривіально, а визначати спосіб взаємодії не потрібно (в силу відсутності будь-якого зовнішнього взаємодії програми, крім як взаємодії її з користувачем, а останнім описується в документації щодо застосування ПС).

Комплекс автономно виконуваних програм складається з набору програм, такого, що:

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

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

Шарувата програмна система складається з деякої впорядкованої сукупності програмних підсистем, званих шарами, такий, що:

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

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

Як приклад розглянемо використання такої архітектури для побудови операційної системи. Таку архітектуру застосував Дейкстра при побудові операційної системи THE [2]. Ця операційна система складається з чотирьох шарів (див. Рис. 1). На нульовому шарі проводиться обробка всіх переривань і виділення центрального процесора програмам (процесам) в пакетному режимі. Тільки цей рівень обізнаний про мультипрограмних аспектах системи. На першому шарі здійснюється управління сторінкової організацією пам'яті. Всім вищим верствам надається віртуальна безперервна (НЕ сторінкова) пам'ять. На другому шарі здійснюється зв'язок з консоллю (пультом управління) оператора. Тільки цей шар знає технічні характеристики консолі. На третьому шарі здійснюється буферизація вхідних і вихідних потоків даних і реалізуються так звані абстрактні канали введення і виведення, так що прикладні програми не знають технічних характеристик пристроїв введення-виведення.

Мал. 1. Архітектура операційної системи THE.

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

Найпростішим різновидом такої архітектури є конвеєр, кошти, для організації якого є в операційній системі UNIX [3]. Конвеєр являє собою послідовність програм, в якій стандартний висновок кожної програми, крім самої останньої, пов'язаний зі стандартним введенням наступної програми цієї послідовності (див. Рис. 2). Конвеєр обробляє деякий потік повідомлень. Кожне повідомлення цього потоку надходить на введення першій програмі, яка, обробивши його, передає перероблене повідомлення наступній програмі, а сама починає обробку чергового повідомлення потоку. Таким же чином діє кожна програма конвеєра: отримавши повідомлення від попередньої програми і обробивши його, вона передає перероблене повідомлення наступній програмі, а остання програма конвеєра виводить результат роботи всього конвеєра (результуюче повідомлення). Таким чином, в конвеєрі, що складається з n програм, може одночасно перебувати в обробці до n повідомлень. Звичайно, в силу того, що різні програми конвеєра можуть витратити на обробку чергових повідомлень різні відрізки часу, необхідно забезпечити якимось чином синхронізацію цих процесів (деякі процеси можуть знаходитися в стадії очікування або можливості передати перероблене повідомлення, або можливості отримати чергове повідомлення).

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

Приклад програмної системи з портами повідомлень наведено на Рис. 3. Порт U може розглядатися як порт вступних повідомлень для представленого на цьому малюнку колективу паралельно діючих програм, а порт W - як порт вивідних повідомлень для цього колективу програм.

Для забезпечення взаємодії між підсистемами в ряді випадків не потрібно створювати будь-які додаткові програмні компоненти (крім реалізації зовнішніх функцій) - для цього може бути достатньо заздалегідь фіксованих угод і стандартних можливостей базового програмного забезпечення (операційної системи). Так в комплексі автономно виконуваних програм для забезпечення взаємодії досить опису (специфікації) загальної зовнішньої інформаційного середовища і можливостей операційної системи для запуску програм. В шаруватої програмної системі може виявитися достатнім специфікації виділених програмних шарів і звичайний апарат звернення до процедур. У програмному конвеєрі взаємодія між програмами також може забезпечувати операційна система (як це має місце в операційній системі UNIX).

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