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

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

Архітектура повинна будуватись щоб найкраще відповідати вимогам до системи що створюється, згідно принципу "".

Згідно Perry та Wolf архітектурою є набір елементів що мають певну форму (властивості і обмеження що накладаються на елементи), і їх (). Обґрунтування фіксує мотиви вибору певного архітектурного стилю, елементів і обмежень. Рой Філдінг вважає що обґрунтування необхідне на етапі створення архітектури, і корисне надалі але не є невід'ємним її елементом. Тому що архітектура має набір властивостей що дозволяють їй задовольняти вимоги, і незнання цих вимог може призвести до змін що порушують архітектуру, але до архітектури входять властивості а не вимоги. Наприклад можна не знати що в "архітектуру" стола закладену вимогу стійкості, і тому він повинен мати більше двох ніжок. Не знаючи про цю вимогу, ми можемо відпиляти забагато ніжок і стіл впаде. Але це тому що ми порушили архітектурне обмеження "мати три чи більше ніжок".

Терміном "Архітектура" також називають документування архітектури програмного забезпечення. Документування архітектури ПЗ спрощує процес комунікації між зацікавленими особами, дозволяє зафіксувати прийняті на ранніх етапах проєктування рішення про високорівневий дизайн системи і дозволяє використовувати компоненти цього дизайну і шаблони проєктування повторно в інших проєктах.

Огляд

Область комп'ютерних наук з моменту свого утворення зіткнулася з проблемами, пов'язаними зі складністю програмних систем. Раніше проблеми складності вирішувалися розробниками шляхом правильного вибору структур даних, розробки алгоритмів і розмежуванню повноважень. Хоча термін «архітектура програмного забезпечення» є відносно новим для індустрії розробки ПЗ, фундаментальні принципи цієї області невпорядковано застосовувалися піонерами розробки ПЗ починаючи з середини 1980-х. Перші спроби зрозуміти і пояснити програмну архітектуру системи були повні неточностей і страждали від нестачі організованості, часто це була просто діаграма з блоків, з'єднаних лініями. В 1990-ті роки спостерігається спроба визначити і систематизувати основні аспекти даної дисципліни. Початковий набір шаблонів проєктування, архітектурних стилів, найкращих практик та були розроблені протягом цього часу. Основною ідеєю дисципліни архітектури ПЗ є ідея зниження складності системи шляхом абстракції і розмежування повноважень. Досі немає згоди щодо чіткого визначення терміну «архітектура програмного забезпечення».

Будучи, наразі, дисципліною без чітких правил про «правильний» шлях створення системи, проєктування архітектури ПЗ є поєднанням науки і мистецтва. Аспект мистецтва полягає в тому, що будь-яка комерційна система передбачає наявність застосування або місії. Ключові цілі, які має система, описуються з допомогою як нефункціональні вимоги до системи, також відомі як атрибути якості, які визначають, як буде поводитись система. Атрибути якості системи включають в себе відмовостійкість, збереження зворотної сумісності, розширюваність, надійність, супроводжуваність, доступність, безпека, зручність використання, а також інші якості. З точки зору користувача програмної архітектури, програмна архітектура дає напрям руху і вирішення завдань, пов'язаних зі спеціальністю кожного такого користувача, наприклад, зацікавленої особи, розробника ПЗ, Служба технічної підтримки, спеціаліста по супроводу, спеціаліста по розгортанню ПЗ, тестера, а також кінцевих користувачів. У цьому сенсі архітектура програмного забезпечення насправді об'єднує різні точки зору на систему. Можливість об'єднати кілька різних точок зору на систему є аргументом на захист необхідності і доцільності створення архітектури ще до етапу розробки ПЗ.

Історія Початок архітектурі програмного забезпечення як концепції було покладено в науково-дослідницькій роботі Едсгера Дейкстри в 1968 році і на початку 1970-х. Ці вчені підкреслили, що структура системи ПЗ має важливе значення, і що побудова правильної структури - критично важливо. Популярність вивчення цієї області зросла з початку 1990-х років разом з науково-дослідницькою роботою по дослідженню архітектурних стилів (шаблонів), мов описания архітектури, документування архітектури і формальних методів.

У розвитку архітектури програмного забезпечення як дисципліни відіграють важливу роль науково-дослідницькі установи. Мері Шоу і Девід Герлан з університету Карнегі-Меллон написали книгу під назвою «Архітектура програмного забезпечення: перспективи нової дисципліни в 1996 році», в якій висунули концепції архітектури програмного забезпечення, такі як компоненти, з'єднувачі (connectors), стилі і так далі. У Каліфорнійському університеті в Ірвайні, інститут по дослідженню ПЗ насамперед досліджує архітектурні стилі, мови опису архітектури і динамічні архітектури.

Першим стандартом опису програмної архітектури є стандарт : ANSI / IEEE 1471—2000: Рекомендації по опису переважно програмних систем. Він був прийнятий в 2007 році, під назвою ISO ISO / IEC 42010:2007.

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

Об’єктний підхід

Проєктування системи може здійснюватися на основі об'єкто-орієнтованого моделювання ПрО методом UML, який дозволяє враховувати аспекти, властиві діючим особам (акторам) системи, створювати сценарії виконання системи тощо. Об’єктний стиль проєктування — це декомпозиція майбутньої системи на окремі підсистеми (пакети), визначення функціональних і нефункціональних вимог і об’єктної моделі предметної області. Носіями інтересів, можливостей і дій в системі (або пакеті) є діючі особи — актори. Пакет може складатися з об’єктної моделі, варіантів використання, що визначають сценарії поведінки системи, склад об’єктів і методів їхньої взаємодії. Поведінка об’єктів відображується діаграмами, що задають послідовність взаємодії об’єктів (діаграми послідовностей, взаємодії), правилами переходу від стану до стану (діаграми станів), а також діаграмами кооперації, в яких діючі особи зображуються графічно. Об’єкти і відповідні їм діаграми варіантів використання задають загальну архітектурну схему системи, у рамках якої здійснюється реалізація структури і специфіки поведінки компонентів. Загальна концепція об’єктного проєктування — це побудова всіх сценаріїв, екранних діаграм для керування ними і їх випробування в різних варіантах використання. На вибір варіантів використання впливають нефункціональні вимоги (наприклад, забезпечення конфіденційності, швидкодії й ін.). На основі моделі опису вимог і понять проводиться уточнення складу і змісту функцій системи, методів їхньої реалізації у вигляді сценаріїв і діаграм потоків даних, у яких відображається взаємодія об’єктів як обмін повідомленнями між елементами системи для передачі даних і одержання відповіді після виконання операцій. Моделі вимог визначають призначення і місце вимог у таких системах. Цьому сприяють розроблені національні, корпоративні і відомчі стандарти. Вони фіксують правила формування нефункціональних вимог, у яких відображаються відомості про взаємодію і захист даних у системі. При цьому поведінка об’єктів представляється діаграмами UML, вони можуть уточнюватися при перегляді моделей вимог і складу об’єктів системи. Перегляд починається з вимог і пошуку місць локалізації для внесення необхідних змін у модель. Зміни можуть стосуватися функціональних і нефункціональних вимог у зв’язку з уточненням замовником обмежень на структуру системи, використовувані ресурси й умови середовища її функціонування.

Загальносистемний підхід Один зі шляхів архітектурного проєктування — традиційний неформальний підхід до визначення архітектури системи, її компонентів, способів їхнього подання й об’єднання в систему, який можна назвати загальносистемним. Фактично архітектура, що створюється згідно з таким підходом, є чотирирівневою і містить у собі:

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

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

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

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