Архітектура програмного забезпечення

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

Технологія розробки програмного забезпечення
Цикл розробки програмного забезпечення
Програміст за роботою
Діяльність і кроки
Допоміжні дисципліни
Практики
Інструменти
Стандарти та галузі знань

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

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

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

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

Огляд

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

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

Історія

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

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

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

Проєктування архітектури програмних систем

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

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

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

Загальносистемний підхід

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

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

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

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

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

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

Архітектура рекурсивна, і описується для кожного рівня абстракції. Крім того кожна фаза роботи системи має окрему архітектуру. Наприклад файл конфігурації є окремим елементом системи на етапі її запуску, але під час подальшої роботи дані що містились в ньому вже розподілені між іншими компонентами системи, і як окремий компонент він в цій фазі не присутній. Таким чином архітектура відрізняється від структури програмного забезпечення - остання стосується статичного коду, в той час як архітектура описується для системи що виконується. І хоча є переваги в тому аби архітектура системи відповідала структурі коду який її утворює, проте також є й перевага в тому аби різні компоненти архітектури використовували, наприклад, розподілювані бібліотеки[12].

Елементи архітектури поділяються на елементи обробки (англ. processing elements) які виконують перетворення даних, елементи даних (англ. data elements) які містять дані, і з'єднувальні елементи (англ. connecting elements), які з'єднують елементи обробки, не змінюючи даних які по них проходять[4]. Хоча їх часто називають компонентами (англ. components) та конекторами (англ. connectors)[5][9].

Компонент - це абстрактна одиниця коду програми та внутрішнього стану, яка дозволяє перетворення даних через свій інтерфейс. Архітектура не задає реалізацію компонента, а лише його інтерфейс і сервіси які він повинен надавати іншим компонентам[13].

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

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

Опис архітектури

Опис архітектури задіює принципи і практики моделювання та представлення архітектур, використовуючи такі механізми як: мови опису архітектури (англ. architecture description language), точки зору на архітектуру (англ. architecture viewpoint)[15] та архітектурні каркаси (англ. architecture framework).

Мови опису архітектури

Більшість робіт на тему архітектури опублікованих наприкінці 1990-х стосувалися мов опису архітектури (англ. architecture desctiption languages, ADL). Мова опису архітектури - це мова що дозволяє явний опис архітектури, включаючи щонайменше компоненти, їх інтерфейси, конектори та конфігурацію архітектури[16].

Приклади:

Точки зору на архітектуру
4+1 Architectural View Model.

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

Популярними моделями точок зору на архітектуру є 4+1 Architectural View Model, каталог точок зору та перспектив[19], та IBM views & viewpoint model[20].

Методології проєктування

Ранні дослідження архітектури зосереджувались на методології проєктування систем. Наприклад об'єктно-орієнтований дизайн намагається структурувати проблеми так що вони розв'язуються архітектурою на основі об'єктів. Однією з перших методологій яка підкреслила проєктування саме на рівні архітектури була Jackson System Development[21].

Приклади архітектурних моделей і стилів

Див. також

Примітки
  1. Е. М. Пройдаков, Л. А. Теплицький. Англо-Український тлумачний словник з обчислювальної техніки, Інтернету і програмування. — СофтПрес. — С. 552. — ISBN 966-530-070-9.
  2. fielding, с. 5.
  3. fielding, с. 1.
  4. perry_wolf.
  5. fielding, с. 8.
  6. Чернецки К., Айзенекер У. Порождающее программирование. Методы, инструменты, применение. — Издательский дом «Питер», 2005. — 730 с.
  7. Рамбо Дж., Джекобсон А, Буч Г. UML: специальный справочник. — Питер, 2002. — 656 с.
  8. fielding, с. 2.
  9. Software Architecture: Glossary. Software Engineering Institute. Процитовано 8 січня 2017.
  10. fielding, с. 27.
  11. fielding, с. 4.
  12. fielding, с. 6.
  13. fielding, с. 10.
  14. fielding, с. 11.
  15. О. Є. Коваленко. СТАНДАРТИЗАЦІЯ ФОРМАЛЬНОГО ОПИСУ СИСТЕМНОЇ АРХІТЕКТУРИ СИТУАЦІЙНИХ ЦЕНТРІВ. Процитовано 7 січня 2017.
  16. fielding, 21.
  17. Zelesnik, Gregory. The UniCon Language Reference Manual. Carnegie Mellon University. Процитовано 9 січня 2017.
  18. Unicon. Carnegie Mellon University. Процитовано 9 січня 2017.
  19. http://www.viewpoints-and-perspectives.info/
  20. An introduction to the IBM Views and Viewpoints Framework for IT systems. 8 січня 2008. Процитовано 9 січня 2017.
  21. fielding, 19.

Література


This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.