Знаймо

Додати знання

приховати рекламу

Цей текст може містити помилки.

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



План:


Введення

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


1. Огляд

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

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


2. Історія

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

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

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


3. Теми по програмній архітектурі

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

Мови опису архітектури (ADLS) використовуються для опису архітектури програмного забезпечення. Різними організаціями було розроблено декілька різних ADLS, в тому числі AADL (стандарт SAE), Wright (розроблений в університеті Carnegie Mellon), Acme (розроблений в університеті Carnegie Mellon), xADL (розроблений в UCI), Darwin (розроблений в Imperial College в Лондоні ), DAOP-ADL (розроблений в Університеті Малаги), а також ByADL (Університет L'Aquila, Італія). Спільними елементами для всіх цих мов є поняття компонента, коннектора і конфігурації.


3.2. Види (views)

Архітектура ПЗ зазвичай містить кілька видів, які аналогічні різним типам креслень в будівництві будинків. В онтології, встановленої ANSI / IEEE 1471-2000, види є екземплярами точки зору, де точка зору існує для опису архітектури з точки зору заданої множини зацікавлених осіб.

Приклади видів:

 * Функціональний / логічний вигляд * Вид код / ​​модуль * Вид розробки (development) / структурний * Вид паралельності виконання / процес / потік * Фізичний вигляд / вид розгортання * Вид з точки зору дій користувача * Вид з точки зору даних 

Хоча було розроблено кілька мов для опису архітектури програмного забезпечення, але в даний момент немає згоди з приводу того, який набір видів повинен бути прийнятий в якості еталону. В якості стандарту "для моделювання програмних систем (і не тільки)" був створений мова UML.


3.3. Базові фреймворки для архітектури ПЗ (software architecture frameworks)

Існують наступні фреймворки, що відносяться до галузі архітектури ПЗ:

  • 4 +1
  • RM-ODP (Reference Model of Open Distributed Processing)
  • Service-Oriented Modeling Framework (SOMF)

Такі приклади архітектур як фреймворк Захмана (Zachman Framework), DODAF і TOGAF відносяться до галузі архітектури підприємства (enterprise architectures).

3.4. Відмінність архітектури ПЗ від детального проектування ПЗ

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

Архітектура ПЗ, яку також можна уявити собі у вигляді розробки стратегії - це діяльність, пов'язана з визначенням глобальних обмежень, що накладаються на проектування системи, такі як вибір парадигми програмування, архітектурних стилів, стандарти розробки ПЗ, засновані на використанні компонентів, принципи проектування та обмеження, накладаються державним законодавством. Детальне проектування, тобто розробка тактики - це діяльність, пов'язана з визначенням локальних обмежень проекту, такі як шаблони проектування, архітектурні моделі, ідіоми програмування і рефакторинга. Згідно "гіпотезі напруги / околиці" (Intension / Locality Hyphotysis), відмінність між архітектурним і детальним проектуванням визначається критерієм околиці (Locality Criteria), згідно з яким твердження, що дизайн ПО не є локальним (а є архітектурним) істинно тоді і тільки тоді, коли програма, яка відповідає цьому критерію може бути розширена в програму, яка не задовольняє йому. Наприклад, стиль програми, клієнт-сервер є архітектурним стилем (стратегічним дизайном), тому що програма, яка побудована на цьому принципі, може бути розширена в програму, яка не є клієнт-сервером, наприклад, шляхом додавання peer-to-peer вузлів.

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


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
  • Структурована
  • Трьох-рівнева

Примітки


Цей текст може містити помилки.

Схожі роботи | скачати

Схожі роботи:
Тестування програмного забезпечення
Впровадження програмного забезпечення
Проектування програмного забезпечення
Якість програмного забезпечення
Установка програмного забезпечення
Портування програмного забезпечення
Розробка програмного забезпечення
Інженерія програмного забезпечення
Супровід програмного забезпечення
© Усі права захищені
написати до нас
Рейтинг@Mail.ru