Софтуерната архитектура () е съвкупност от важни решения за организацията на програмните системи. Тя се определя от високо ниво структури от софтуерни системи, дисциплината от създаването на такива структури и документация на тези структури. Тези структури са необходими за аргументиране на софтуерните системи. Всяка структура съставлява софтуерни елементи, връзки между тях и свойствата на двете – елементи и връзки. Архитектурата на софтуера е метафора, аналогично е на архитектура на сграда.Perry.D.E. (1992). Foundations for the of sofware architecture(PDF)
Чрез софтуерната архитектура се вземат структурни решения, които са скъпи за промяна след реализация. Софтуерната архитектура включва специфични структурни варианти от възможности в дизайна на софтуера. Например системите, които контролират космически совалки, трябва да са много бързи и много надеждни. Следователно необходимо е да се избере подходящ компютърен език. В допълнение, за да задоволи нуждите за надеждност, би могло да се избере на-добрият вариант, да има множество излишни и независими произведени копия на програмата и да се задействат тези копия, докато тече многократна проверка на резултатите.
Документирането на софтуерната архитектура улеснява комуникацията между заинтересованите страни, позволява ранни решения за проектиране на високо равнище и повторно използване на проектните компоненти.Bass, Len; Paul Clements:Pick Kazman(2012). Sofware Architecture in Practice, Thirth Edition. Boston Addison-Wesley. ISBN 978-0-321-81573-6.
Характеристика и обхват Архитектурата спомага за ползваемостта.How do you define Sofwarw Archiecture? Retived 2012-09-12 Тя дава възможност на потребителя да поема инициативи, например да прекрати дълго изпълняващи се операции или да се откаже от последната команда.
Системата трябва да може да придвижва реакцията на потребителя.
Системата трябва да дава възможност на потребителя да бъде ефективен в работата си чрез прилагане на тактики.
Нуждата от софтуерната архитектура е предизвикана от необходимостта за солидна основа при големите и сложни системи. Тя е гаранцията за дълъг живот на системата.
Ако не са предвидени различните сценарии и начини на използване на системата, общите проблеми и начините на справяне с тях, целите в дългосрочен план, то тогава софтуерният продукт е в риск, а това струва време и пари. Разбиране на системата от всяко заинтересовано лице, нейното структуриране на елементите е друга необходимост.
Софтуерната архитектура играе ролята на инструмент за комуникация, обосновка при вземане на решения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, средство за анализ и развитие на системата.
Основно твърдение: Софтуерните архитектури са важни за успешното разработване на софтуерни системи. Има достатъчно и добре обобщени знания за софтуерните архитектури. Софтуерните системи се изграждат за да удовлетворят бизнес целите на организациите. Архитектурата е мост между тези (често абстрактни) бизнес цели и крайната (конкретна) система. Софтуерните архитектури могат да бъдат проектирани, анализирани, документирани и реализирани с определени техники, така че да бъдат постигнати целите на бизнеса.
Обосновка и предимства Софтуерната архитектура е един вид „интелектуално разбираема“ абстракция на сложна система.Garlan & Show(1994). An Introduction to sofware architecture Тази абстракция осигурява редица предимства: Дава основа за анализ на поведението на софтуерната система преди тя е да е била построена. Способността да се провери, че една бъдеща софтуерна система отговаря на нуждите на своите заинтересовани страни без тя да е построена още, представлява значително намаляване на разходите и рисковете. Редица технически устройства са разработени за да извършват такъв анализи, например АТАМ. Тя осигурява основа за повторно използване на елементи и решения. Пълна софтуерна архитектура или част от него, може повторно да се използва в няколко системи, чиито участници изискват подобни характеристики и функционалности. Това спестява разходи за проектиране и намалява риска от проектантски грешки. Тя подкрепя ранните дизайнерски решения, които влияят на разработката, разгръщането и живота на поддръжката. Вземането на ранни решения предотвратява преразходи в бюджета. Улеснява комуникацията на заинтересованите страни, допринася за една по-добра система отговаряща на нуждите им. Софтуерната архитектура спомага управлението на риска. Тя помага за намаляване на шансовете за провал. Дава възможност за намаляване на разходите в сложни 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волюцията на архитектура се занимава с добавяне на нова функционалност, както и поддържане на съществуващата функционалност и система на поведение.
Архитектурата изисква критични поддържащи дейности. Тези подкрепящи дейности се осъществяват през целия процес на изграждане на архитектурния софтуер. Те включват управление на знания и комуникация, изграждане на дизайн, вземане на решения и документация.
Архитектурни помощни дейности Софтуерните архитектурни помощни дейности се извършват по време на основните дейности на софтуерна архитектура. Тези дейности подпомагат софтуерния архитект за извършване на анализ, синтез, оценка и еволюция. Например, един архитект трябва да събере знания, да вземе решения и документи по време на фазата на анализ.