4. Архітектурні функції
Для забезпечення взаємодії між підсистемами у ряді випадків не потрібно створювати які-небудь додаткові програмні компоненти (крім реалізації зовнішніх функцій) для цього може бути досить наперед фіксованих угод і стандартних можливостей базового програмного забезпечення (операційної системи). Так в комплексі автономно виконуваних програм для забезпечення взаємодії достатньо опису (специфікації) загального зовнішнього інформаційного середовища і можливостей операційної системи для запуску програм. У шаровій програмній системі можуть виявитися достатніми специфікації виділених програмних шарів і звичайний апарат звернення до процедур. У програмному конвеєрі взаємодія між програмами також може забезпечувати операційна система (як це має місце в операційній системі UNIX).
Проте у ряді випадків для забезпечення взаємодії між програмними підсистемами може потрібно створення додаткових програмних компонент. Так для управління роботою комплексу автономно виконуваних програм часто створюють спеціалізований командний інтерпретатор, зручніший (у даній наочній області) для підготовки необхідного зовнішнього інформаційного середовища і запуску необхідної програми, чим базовий командний інтерпретатор використовуваної операційної системи. У шарових програмних системах може бути створений особливий апарат звернення до процедур шару (наприклад, що забезпечує паралельне виконання цих процедур). У колективі паралельно виконуваних програм для управління портами повідомлень потрібна спеціальна програмна підсистема. Такі програмні компоненти реалізують не зовнішні функції ПЗ, а функції, виниклі в результаті розробки архітектури цього ПЗ. У зв'язку з цим такі функції ми називатимемо архітектурними.
5. Контроль архітектури програмних засобів
Для контролю архітектури ПЗ використовується суміжний контроль і ручна імітація.
Суміжний контроль архітектури ПЗ зверху це її контроль розробниками зовнішнього опису: розробниками специфікації якості і розробниками функціональної специфікації. Суміжний контроль архітектури ПЗ знизу це її контроль потенційними розробниками програмних підсистем, що входять до складу ПЗ відповідно до розробленої архітектури.
Ручна імітація архітектури ПЗ проводиться аналогічно ручній імітації функціональної специфікації, тільки метою цього контролю є перевірка взаємодії між програмними підсистемами. Так само як і у разі ручної імітації функціональної специфікації ПЗ повинні бути спочатку підготовлені тести. Потім група розробників повинна для кожного такого тесту імітувати роботу кожної програмної підсистеми, що входить до складу ПЗ. При цьому роботу кожної підсистеми імітує один який-небудь розробник (не автор архітектури), ретельно виконуючи всі взаємодії цієї підсистеми з іншими підсистемами (точніше, з розробниками, що їх імітують) відповідно до розробленої архітектури ПЗ. Тим самим забезпечується імітаційне функціонування ПЗ в цілому в рамках архітектури, що перевіряється.
Список стандартів, що регламентують опис архітектури, який є основною складовою проектної документації на ПЗ, виглядає так:
IEEE 1016-1998 Recommended Practice for Software Design Descriptions (рекомендовані методи опису проектних рішень для ПЗ).
IEEE 1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems (рекомендовані методи опису архітектури программных систем).
Основний зміст цього стандарту зводиться до визначення набору понять, пов'язаних з архітектурою програмної системи.
Це, перш за все, саме поняття архітектури як набору основоположних принципів організації системи, втілених в наборі її компонентів, зв'язках їх один з одним і між ними і оточенням системи, а також принципів проектування і розвитку системи.
Це визначення, на відміну від даного на початку цієї лекції, робить акцент не на наборі структур в основі архітектури, а на принципах її побудови.
Стандарт IEEE 1471 визначає також подання архітектури (architectural description) як узгоджений набір документів, що описує архітектуру з погляду певної групи зацікавлених осіб за допомогою набору моделей. Архітектура може мати декілька подань, що відображають інтереси різних груп зацікавлених осіб.
Стандарт рекомендує для кожного подання фіксувати відображені в ньому погляди і інтереси, ролі осіб, які зацікавлені в такому погляді на систему, причини, що обумовлюють необхідність такого розгляду системи, невідповідності між елементами одного подання або між різними поданнями, а також різну службову інформацію про джерела інформації, дати створення документів і ін.
Стандарт IEEE 1471 відзначає необхідність використання архітектури системи для розв’язування таких завдань, як наступні:
Аналіз альтернативних проектів системи.
Планування перепроектування системи, внесення змін в її організацію.
Спілкування з приводу системи між різними організаціями, що залучені до її розробки, експлуатації, супроводу, які хочуть придбати систему або продати її.
Вироблення критеріїв приймання системи при її здачі в експлуатацію.
Розробка документації за її використанням і супроводом, включаючи навчальні і маркетингові матеріали.
Проектування і розробка окремих елементів системи.
Супровід, експлуатація, управління конфігураціями і внесення змін і поправок.
Планування бюджету і використання інших ресурсів в проектах, пов'язаних з розробкою, супроводом або експлуатацією системи.
Проведення оглядів, аналіз і оцінка якості системи