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

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук
Цикл розробки
програмного забезпечення
Coding Shots Annual Plan high res-5.jpg
Програміст за роботою
Діяльність та кроки
Вимоги ·  Специфікація
Архітектура ·  Дизайн
Реалізація ·  Тестування
Розгортання ·  Підтримка
Методології
Гнучка ·  Чистого приміщення
DSDM ·  Iterative ·  RAD ·  RUP
Spiral ·  Водоспад ·  XP ·  Scrum
Lean ·  V-Model ·  FDD ·  TDD
Допоміжні дисципліни
Конфігураційне керування
Документування
Якість ПЗ
Управління проектами
Досвід користування
Інструменти
Компілятор ·  Зневаджувач
Профілювальник
GUI designer ·  IDE

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

Огляд[ред.ред. код]

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

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

Історія[ред.ред. код]

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

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

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

Проектування архітектури програмних систем[ред.ред. код]

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

Стандартизований підхід[ред.ред. код]

Тривалий час в Україні та СРСР розроблення програмних систем виконувалась на основі стандарту ГОСТ 34.601–90[2], що регламентує стадії й етапи процесу розробки ПС.

Об’єктний підхід[ред.ред. код]

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

Загальносистемний підхід[ред.ред. код]

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

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

  • Blackboard
  • Клієнт-серверна модель (Client-server)
  • Архітектури, побудовані навколо бази даних (Database-centric architecture)
  • Розподілені обчислення (Distributed computing)
  • Подієва архітектура (Event-driven architecture)
  • Front end and back end
  • Неявні виклики (Implicit invocations)
  • Монолітний застосунок (Monolithic application)
  • Peer-to-peer
  • Пайпи і фільтри (Pipes and filters)
  • Plugin
  • Representational State Transfer
  • Rule evaluation
  • Пошук-орієнтована архітектура
  • Сервіс-орієнтована архітектура
  • Shared nothing architecture
  • Software componentry
  • Space based architecture
  • Структурована
  • Багаторівнева

Посилання[ред.ред. код]

Примітки[ред.ред. код]

  1. Чернецки К., Айзенекер У. Порождающее программирование. Методы, инструменты, применение. — Издательский дом «Питер», 2005. — 730 с.
  2. ГОСТ 34.601-90 // ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания.
  3. Рамбо Дж., Джекобсон А, Буч Г. UML: специальный справочник. — Питер, 2002. — 656 с.
  4. [1] // Software Architecture styles and patterns - Wikipedia, the free encyclopedia

Джерела[ред.ред. код]