Уикипедия

Софтуерна архитектура

Софтуерната архитектура (на английски: software architecture) е съвкупност от важни решения за организацията на програмните системи. Тя се определя от високо ниво структури от софтуерни системи, дисциплината от създаването на такива структури и документация на тези структури. Тези структури са необходими за аргументиране на софтуерните системи. Всяка структура съставлява софтуерни елементи, връзки между тях и свойствата на двете – елементи и връзки. Архитектурата на софтуера е метафора, аналогично е на архитектура на сграда.[1]

Чрез софтуерната архитектура се вземат структурни решения, които са скъпи за промяна след реализация. Софтуерната архитектура включва специфични структурни варианти от възможности в дизайна на софтуера. Например системите, които контролират космически совалки, трябва да са много бързи и много надеждни. Следователно необходимо е да се избере подходящ компютърен език. В допълнение, за да задоволи нуждите за надеждност, би могло да се избере на-добрият вариант, да има множество излишни и независими произведени копия на програмата и да се задействат тези копия, докато тече многократна проверка на резултатите.

Документирането на софтуерната архитектура улеснява комуникацията между заинтересованите страни, позволява ранни решения за проектиране на високо равнище и повторно използване на проектните компоненти.[2]

Характеристика и обхват редактиране

Архитектурата спомага за ползваемостта.[3] Тя дава възможност на потребителя да поема инициативи, например да прекрати дълго изпълняващи се операции или да се откаже от последната команда.

Системата трябва да може да придвижва реакцията на потребителя.

Системата трябва да дава възможност на потребителя да бъде ефективен в работата си чрез прилагане на тактики.

Нуждата от софтуерната архитектура е предизвикана от необходимостта за солидна основа при големите и сложни системи. Тя е гаранцията за дълъг живот на системата.

Ако не са предвидени различните сценарии и начини на използване на системата, общите проблеми и начините на справяне с тях, целите в дългосрочен план, то тогава софтуерният продукт е в риск, а това струва време и пари. Разбиране на системата от всяко заинтересовано лице, нейното структуриране на елементите е друга необходимост.

Софтуерната архитектура играе ролята на инструмент за комуникация, обосновка при вземане на решения[4], средство за анализ и развитие на системата.

Основно твърдение:

  • Софтуерните архитектури са важни за успешното разработване на софтуерни системи.
  • Има достатъчно и добре обобщени знания за софтуерните архитектури.
  • Софтуерните системи се изграждат за да удовлетворят бизнес целите на организациите.
  • Архитектурата е мост между тези (често абстрактни) бизнес цели и крайната (конкретна) система.
  • Софтуерните архитектури могат да бъдат проектирани, анализирани, документирани и реализирани с определени техники, така че да бъдат постигнати целите на бизнеса.

Обосновка и предимства редактиране

Софтуерната архитектура е един вид „интелектуално разбираема“ абстракция на сложна система.[5] Тази абстракция осигурява редица предимства:

  • Дава основа за анализ на поведението на софтуерната система преди тя е да е била построена. Способността да се провери, че една бъдеща софтуерна система отговаря на нуждите на своите заинтересовани страни без тя да е построена още, представлява значително намаляване на разходите и рисковете. Редица технически устройства са разработени за да извършват такъв анализи, например АТАМ.
  • Тя осигурява основа за повторно използване на елементи и решения. Пълна софтуерна архитектура или част от него, може повторно да се използва в няколко системи, чиито участници изискват подобни характеристики и функционалности. Това спестява разходи за проектиране и намалява риска от проектантски грешки.
  • Тя подкрепя ранните дизайнерски решения, които влияят на разработката, разгръщането и живота на поддръжката. Вземането на ранни решения предотвратява преразходи в бюджета.
  • Улеснява комуникацията на заинтересованите страни, допринася за една по-добра система отговаряща на нуждите им.
  • Софтуерната архитектура спомага управлението на риска. Тя помага за намаляване на шансовете за провал. Дава възможност за намаляване на разходите в сложни IT проекти.

История редактиране

Сравнението между софтуер, дизайн и архитектура за първи път е изготвено в края на 1960, но терминът софтуерна архитектура стана широко разпространен само в началото на 1990-те години. В областта на компютърните науки са се срещали проблеми, свързани със сложността. По-ранни проблеми свързани с нея са решени от разработчиците чрез избора на правилните структури от данни, разработване на алгоритми, както и чрез прилагане на концепцията за разделяне на отговорности. Въпреки че терминът „софтуерна архитектура“ е сравнително нов за индустрията, основните принципи на областта са били приложени от пионери в софтуерното инженерство от средата на 1980-те. Ранните опити за обяснение на софтуерна архитектура на система бяха неточни и неорганизирани, често характеризирани с набор от кутия-и-диаграми.

Софтуерна архитектура като концепция има своите корени в изследванията на Едсгер Дейкстра през 1968 г. и Дейвид Парнас в началото на 1970. Тези учени подчертават, че структурата на софтуерната система и правилното и получаване е от решаващо значение. През 1990-те години е имало съгласувани усилия да се определят и систематизират основните аспекти на дисциплината, чрез изследователска работа концентрирана върху архитектурни стилове (модели), описателни архитектурни езици, архитектурна документация, както и формални методи.

Изследователските институции са изиграли важна роля за по-нататъшното развитие на софтуерната архитектура като дисциплина. Mary Shaw и David Garlan от университета Carnegie Mellon са написали книга, озаглавена Софтуерна Архитектура: Перспективи на Emerging дисциплина през 1996 г., която насърчава софтуерни архитектурни концепции като компоненти, конектори и стилове. Университетът на Калифорния, Институт Irvine за Софтуерни изследователски усилия в изследванията на софтуерна архитектура, е насочен предимно в архитектурни стилове, описателни архитектурни езици, както и динамични архитектури.

IEEE 1471-2000, Препоръчителна практика за архитектурно описание на софтуер-интензивни системи, беше първият официален стандарт в областта на софтуерна архитектура. Той беше приет през 2007 г. от ISO като IEC 42010: 2007. През ноември 2011 г., IEEE 1471 – 2000 бе заменен от ISO / IEC / IEEE 42010:. 2011 Системи и софтуерно инженерство – Архитектурно описание (публикуван съвместно от IEEE и ISO).

Докато в IEEE 1471, софтуерната архитектура е била за архитектурата на „софтуер-интензивни системи“, дефинирани като „всяка система, където софтуер влияе съществено с проектирането, изграждането, внедряването и развитието на системата като цяло“, изданието, от 2011 отива една стъпка по-нататък чрез включване на ISO / IEC 15288 и ISO / IEC 12207 дефинициите на системата, които обхващат не само хардуер и софтуер, но също и „хора, процеси, процедури, съоръжения, материали и естествени образувания“. Това се отразява на отношенията между софтуерна архитектура, Enterprise Architecture и Solution Architecture.

Архитектурни дейности редактиране

Има много дейности, които един софтуерен архитект изпълнява. Софтуерният архитект обикновено работи с мениджъри на проекти, обсъжда архитектурно значими изисквания със заинтересованите страни, проектира софтуерна архитектура, оценява дизайн, комуникира с дизайнери и заинтересовани лица, документира архитектурния дизайн и други. Има четири основни дейности в проектирането на софтуерна архитектура. Тези основни архитектурни дейности се извършват итеративно и на различни етапи от първоначалната разработка на жизнен цикъл на софтуер, както и с течение на развитието на дадена система.

Архитектурният анализ е процес на разбиране на средата, в която ще работят планирана система или системи и определяне на изискванията за системата. Входът или изискванията към дейността по анализ могат да дойдат от произволен брой заинтересовани страни и включват елементи като:

  • колко добре системата ще изпълнява по време на работа нефункционални изисквания като надеждност, оперативност, ефективност производителност, сигурност, съвместимост, дефинрани в стандарт ISO / IEC 25010: 2011
  • време за развитие на нефункционалните изисквания, като например възможност за поддръжка и за прехвърляне, определени в стандарт ISO 25010: 2011
  • бизнес изисквания и екологични условия на една система, които могат да се променят с течение на времето, като например правни, социални, финансови, конкурентни и технологични опасения 

Резултатите от дейността на анализ са тези изисквания, които имат измеримо въздействие върху архитектурата на софтуерната система, наречени архитектурно значими изисквания.

Архитектурния синтез или дизайн е процес на създаване на архитектура. Предвид архитектурно съществените изисквания, определени от анализа, текущото състояние на проекта и резултатите от всички дейности за оценка, дизайнът е създаден и подобрен.

Oценяване на архитектура е процес на определяне на това колко добре настоящия дизайн или част от него отговаря на изискванията, получени по време на анализа. Оценката може да се случи, когато един архитект обмисля решение на дизайн, също така след като известна част от дизайна е завършена, може да се случи и след като окончателен проект е завършен или след като системата е изградена. Някои от наличните техники за оценка на софтуерната архитектура включва Architecture Tradeoff Analysis Method (ATAM) и TARA.

Еволюция на архитектура е процесът на поддържане и адаптиране на съществуваща софтуерна архитектура, за да отговаря на изискванията и промените в околната среда. Тъй като софтуерна архитектура осигурява фундаменталната структура на софтуерна система, нейната еволюция и поддръжка непременно ще се отрази върху основната структура. Eволюцията на архитектура се занимава с добавяне на нова функционалност, както и поддържане на съществуващата функционалност и система на поведение.

Архитектурата изисква критични поддържащи дейности. Тези подкрепящи дейности се осъществяват през целия процес на изграждане на архитектурния софтуер. Те включват управление на знания и комуникация, изграждане на дизайн, вземане на решения и документация.

Архитектурни помощни дейности редактиране

Софтуерните архитектурни помощни дейности се извършват по време на основните дейности на софтуерна архитектура. Тези дейности подпомагат софтуерния архитект за извършване на анализ, синтез, оценка и еволюция. Например, един архитект трябва да събере знания, да вземе решения и документи по време на фазата на анализ.

Управлението на знания и комуникация е активността на проучване и управление на знанието, което е от съществено значение за разработването на софтуерна архитектура. Софтуерните архитекти не работят в изолация. Те получават данни, функционални и не функционални изисквания и дизайн контексти, от различни заинтересовани страни. Знанието за софтуерна архитектура често е скрито и се задържа в главите на заинтересованите страни. Софтуерна архитектура за управление на знанието е за намиране, общуване и задържане на знания. Проблемите на софтуерната архитектура са сложни и взаимно свързани, пропуски в познанията при проектирането може да доведе до неправилен дизайн на софтуерна архитектура. Примери за дейности по управление на знания и комуникация включва претърсване за модели за дизайн, прототипи, разпитване на опитни предприемачи и архитекти, оценка на проекти на подобни системи, споделяне на знания с други дизайнери и заинтересовани страни, и документирането на опита.

Проектиране на дизайн и вземане на решения е дейността на оценяване на дизайнерски решения. Тази дейност е от основно значение за всички три основни софтуерни архитектурни дейности. Това включва събиране и асоцииране на контекстни решения, формулиране на проблеми за дизайн решения, намиране на варианти на решения и оценка на компромиси, преди вземане на решения. Този процес се извършва на различни нива на решение на детайлността, докато се оценява значими архитектурни изисквания и решения, софтуерна архитектура и софтуерен архитектурен анализ, синтез и оценка. Например, проектиране на дизайн включва разбиране на въздействието на изискване или дизайн на качествени характеристики, оценка на въпросите, които дизайнът може да причини, оценка на възможните варианти на решения, както и оценка на алтернативите, възникнали между решения.

Документацията е дейността на запис на дизайна, генериран по време на процеса на архитектурата на софтуера. Една дизайн система е описана с помощта на няколко мнения, които често включват статичен изглед, показващ структурата на системата под формата на код, динамичен изглед, който показва действията на системата по време на изпълнение, както и изглед на разполагане, който показва как една система се поставя на хардуер за изпълнение. 4 + 1 изглед на Kruchten предлага описание на често използвани изгледи за документиране на софтуерна архитектура. Примери за дейности, свързани с документация са написването на спецификация, запис на модел на система за проектиране, документиране на обосновка на дизайн, разработване на гледна точка, документиране на възгледи.

Софтуерни архитектурни теми редактиране

Описание на софтуерна архитектура редактиране

Описанието на софтуерната архитектура включва принципи и практики на моделиране, посредством механизми като: архитектурни езици, архитектурни гледни точки, както и архитектурни рамки.

Архитектурни езици редактиране

Архитектурен език (ADL) е всяко средство за изразяване, използвано за описание на софтуерна архитектура (ISO / IEC / IEEE 42010). Много ADL със специално предназначение са били разработени от 1990 г. насам, в това число AADL (SAE стандарт), Write (разработена от Carnegie Mellon), Acme (разработена от Carnegie Mellon), xADL (разработена от UCI), Дарвин (разработена от Imperial College London), DAOP-ADL (разработена от Университета на Малага), SBC-ADL (разработена от Националната Сун Ятсен университет), и ByADL (Университета на Акуила, Италия).

Архитектурни гледни точки редактиране

 
Обща илюстрация на 4+1 Архитектурен планов модел

Софтуерните архитектурни изображения са често организирани в планове, които са аналог на различни типове планове, направени за изграждане на сградна архитектура. Всеки план разглежда набор от системни дялове, съгласно конвенциите на своята гледна точка, където гледна точка е спецификация описваща нотации, моделиране и анализиращи техники използвани в плана, чиято архитектурната цел е изразяване на архитектурния проблем от перспективата на заинтересованите страни и тяхната работа (ISO / IEC / IEEE 42010). Гледната точка специфизира не само работната рамка, но също представянето, видовете използвани модели, видовете конвенции и съответните правила за запазване на плана в съгласие с другите планове.

Архитектурна рамки редактиране

Архитектурната рамка съдържа „конвенции, принципи и практики за описанието на архитектури, установени в рамките на определена област на приложение и/или дадени заинтересовани лица“ (ISO/ IEC/ IEEE 42010). Рамка обикновено се осъществяват по отношение на една или повече гледни точки или софтуерни архитектурни езици.

Архитектурни стилове и модели редактиране

Един архитектурен модел е главен (общ, генерален), многократно употребявано решение на често срещащ проблем в софтуерна архитектура в рамките на определен контекст. Архитектурни модели са често документирани като софтуерни дизайн модели.

Следвайки традиционната строителна архитектура, „софтуерния архитектурен стил“ е специфичен метод на строителство, характеризиран със свойства, които го правят забележителен „(архитектурен стил)“. Един архитектурен стил определя: семейство от системи от гледна точка на един модел на структурна организация; речник от компоненти и конектори, с ограничения за това как те могат да бъдат комбинирани. [6] Aрхитектурните стилове са за многократна употреба „пакети“ от дизайнерски решения и е ограничения да се прилагат за архитектура за да се предизвика избраните желани качества. [7]

Има много признати архитектурни модели и стилове, сред тях:

  • Черна дъска (Blackboard)
  • Клиент-сървър (Client-server)
  • Компонентно базирани
  • Дата-ориентирана
  • Възникнали от събитие (мълчаливо извикване)
  • Многослойна архитектура
  • Монолитно приложение
  • Партньор към партньор (P2P)
  • Тръби и филтри
  • Приставки (Plug-ins)
  • Представителни трансфер състояние (REST)
  • Правило базирани (Rule-based)
  • Обслужвано базирани
  • Микро обслужвана архитектура
  • Несподелено архитектура
  • Пространствено базирана архитектура

Някои от разглежданите архитектурни модели и архитектурни стилове са еднакви [8], някои от разглежданите стилове са специализации на модели. Това, което имат и двата типа са идиоми използвани от архитектите, те предоставят общ език [8] или речник [6], с който се описват класовете в системите.

Софтуерна архитектура и бързо развитие редактиране

Има опасения, че софтуерните архитектурни лидери използват твърде много Big Design Up Front, особено сред привържениците на бързо развиващия се софтуер. Редица методи са разработени, за да се балансира компромисите на първоначалните дизайн и гъвкавост, [9] включително бързия метод DSDM. Които нарежда фаза „Фондации“ по време, на които просто достатъчно архитектурни фондации са положени. IEEE Software посвещава специална статия [10], на взаимодействието между бързина и архитектура.

Софтуна архитектурна ерозия редактиране

Софтуерна архитектурна ерозия (или разпад) се отнася до разликата между планираната и реално установената архитектура на софтуерната система, реализирана при изпълнението ѝ. [11] Софтуерна архитектурна ерозия настъпва, когато решенията за изпълнение или не постигнат напълно планираната архитектура, или по друг начин нарушават ограничения или принципи на архитектурата. [12] Разликата между планираните и действителните архитектури е понякога въпрос на разбиране на представата за технически дълг.

Като например строго слоеста система, където всеки слой може само да използва услуги и ресурси, предоставяни от по-долния спрямо него слой. Всеки компонент на сорс кода, който не спазва това ограничение представлява архитектурно нарушение. Ако не се коригират, подобни нарушения могат да трансформират архитектурата в монолитен блок, с неблагоприятно въздействие върху разбираемостта и възможността за поддръжка.

Различни подходи са били предложени за преодоляване на ерозията. "Тези подходи, които включват инструменти, техники и процеси се класифицират в три общи категории за минимизиране, предотвратяване и ремонт на архитектурната ерозия. В рамките на тези общи категории, всеки подход е допълнително разбит отразяващ стратегии на високо равнище, приети за справяне с ерозията. Те са: процесо-ориентирано архитектурно съответствие, управление на архитектурната еволюция, изпълнение на архитектурния дизайн, архитектура за свързано изпълнение, самостоятелна адаптация и архитектурни възстановителни техники, състоящи се от възстановяване, откритие и спогодба" [13].

Има две основни техники за откриване на архитектурни нарушения: отражателни модели и домейн специфични езици. Отражателния модел (RM) технически сравнява на високо равнище, модела на предоставения от архитектурата на системата с изпълнението на изходния код. Примери за търговски инструменти RM-базирани включват Bauhaus Suite (разработена от Axivion), SAVE (разработен от Fraunhofer IESE) и Structure-101 (разработен от Headway Software). Втората основна техника домейн специфичните езици е с фокус върху специфициране и проверка на архитектурните ограничаващи условия, включително .QL(разработена от Semmle Limited) и DCL(от Федералния университет на Минас Жерайс).

Софтуерна архитектура за възстановяване редактиране

Възстановяване на софтуерната архитектура (или реконструкция, или обратен инженеринг) включва методи, техники и процеси, за разкриване на архитектурата на софтуерната система въз основа на наличната информация, включително нейното изпълнение и документация. Възстановяване на архитектурата е често необходимо да се вземат информирани решения в лицето на остарели или out-of-date документация и архитектурна ерозия: решения за изпълнение и поддръжка, отклоняващи се от предвидената архитектура. [14]

Подобни теми редактиране

Дизайн редактиране

Архитектурата е дизайн, но не всички видове дизайн са архитектура. На практика, архитектът е този, който поставя линията между софтуерна архитектура (архитектурен проект) и работен проект (не-архитектурен дизайн). Няма правила или насоки, които отговарят на всички случаи, макар че е имало опити да се основат такива. Според Намерението/Локална хипотеза, разграничението между архитектурен и работен проект се определя от Локалните критерии, според които изявление за софтуерен дизайн е не-локално (архитектурно), е тогава и само тогава когато една програма, която го удовлетворява може да се разширява в друга програма, която не го прави. Например, стила на клиент-сървъра е архитектурен (стратегически), защото една програма, която е изградена на този принцип може да се разширява в друга програма, която не е клиент-сървър. Например, чрез добавяне на „peer to peer“ възли.

Други типове архитектура редактиране

Компютърна архитектура
Системна архитектура
Архитектура на предприятието

Някои от разглежданите архитектурни модели и архитектурни стилове са еднакви, някои от разглежданите стилове са специализации на модели. Това, което имат и моделите и стиловете, са идиоми използвани от архитектите, те предоставят общ език или речник с който се описват класовете в системите.

Източници редактиране

  1. ↑ Perry.D.E. (1992). Foundations for the of sofware architecture(PDF)
  2. ↑ Bass, Len; Paul Clements:Pick Kazman(2012). Sofware Architecture in Practice, Thirth Edition. Boston Addison-Wesley. ISBN 978-0-321-81573-6.
  3. ↑ How do you define Sofwarw Archiecture? Retived 2012-09-12
  4. ↑ Lansen, A: Bosh, J (2005). „Sofware architecture as a Set of Architectural Design Desisions“.5th Working IEEE/IP Conferece on Sofware Architecture(WISCA'05)p.109 doi:1001109/WISCA 2005.61 ISBN 0-7695-2548-2
  5. ↑ Garlan & Show(1994). An Introduction to sofware architecture
  6. ↑ а б Shaw, Mary; Garlan, David (1996). Software architecture: perspectives on an emerging discipline. Prentice Hall. ISBN 978-0-13-182957-2.
  7. ↑ UCI Software Architecture Research – UCI Software Architecture Research: Architectural Styles. Isr.uci.edu. Посетен на 21 юли 2013.
  8. ↑ а б Chapter 3: Architectural Patterns and Styles. Msdn.microsoft.com. Посетен на 21 юли 2013.
  9. ↑ Boehm, Barry; Turner, Richard (2004). Balancing Agility and Discipline. Addison-Wesley.ISBN 0-321-18612-5.
  10. ↑ „IEEE Software Special Issue on Agility and Architecture“. Април 2010. Посетен на 14 септември 2012.
  11. ↑ Terra, R., M.T. Valente, K. Czarnecki, and R.S. Bigonha, Recommending Refactorings to Reverse Software Architecture Erosion, 16th European Conference on Software Maintenance and Reengineering, 2012.
  12. ↑ Perry, D. E.; Wolf, A. L. (1992). "Foundations for the study of software architecture" (PDF). ACM SIGSOFT Software Engineering Notes 17 (4)
  13. ↑ de Silva, L. and D. Balasubramaniam, „Controlling software architecture erosion: A survey“, Journal of Systems and Software 01/2012; 85:132 – 151.
  14. ↑ Lungu, M. Software architecture recovery, University of Lugano, 2008.

Външни препратки редактиране

    Тази страница частично или изцяло представлява превод на страницата Software architecture в Уикипедия на английски. Оригиналният текст, както и този превод, са защитени от Лиценза „Криейтив Комънс – Признание – Споделяне на споделеното“, а за съдържание, създадено преди юни 2009 година – от Лиценза за свободна документация на ГНУ. Прегледайте историята на редакциите на оригиналната страница, както и на преводната страница, за да видите списъка на съавторите. ​

ВАЖНО: Този шаблон се отнася единствено до авторските права върху съдържанието на статията. Добавянето му не отменя изискването да се посочват конкретни източници на твърденията, които да бъдат благонадеждни.​

Взето от „https://bg.wikipedia.org/w/index.php?title=Софтуерна_архитектура&oldid=11990300“.