Arkitektura e softuerit

 

Arkitektura e softuerit është grupi i strukturave të nevojshme për të arsyetuar rreth një sistemi softuerësh dhe disiplinës së krijimit të strukturave dhe sistemeve. Çdo strukturë përbëhet nga elemente softuerike, marrëdhënie midis tyre dhe vetitë e të dyjave, elementeve dhe marrëdhënieve.

Arkitektura e një sistemi softuerik është një metaforë, analoge me arkitekturën e një ndërtese. Ajo funksionon si një plan (ose projekt) për sistemin dhe për projektin e zhvillimit, projektin e zhvillimit, që më pas mund të përdoret nga menaxhimi i projektit për të nxjerrë detyrat që duhet të realizohen nga ekipet dhe individët e përfshirë.

Arkitektura e softuerit ka të bëjë me zgjedhje themelore strukturore që janë të kushtueshme për t'u ndryshuar pasi të jenë zbatuar. Zgjedhjet në arkitekturën e softuerit përfshijnë opsione specifike strukturore nga mundësitë në projektimin e softuerit . Ekzistojnë dy ligje themelore në arkitekturën e softuerit :

1. Çdo gjë është një kompromis.
2. "Pse" është më e rëndësishme sesa "si".

"Architectural Kata" është një punë në grup që mund të përdoret për të prodhuar një zgjidhje arkitekturore që përmbush nevojat.Çdo ekip nxjerr dhe prioritizon karakteristikat arkitekturore (ose kërkesat jo funksionale ) dhe më pas i modelon komponentët në përputhje me rrethanat. Ekipi mund të përdorë modelin C4, i cili është një metodë fleksibël për të modeluar arkitekturën sa duhet. Vini re se komunikimi sinkron midis komponentëve arkitekturorë i ngatërron ata dhe i detyron të ndajnë të njëjtat karakteristika arkitekturore.

Dokumentimi i arkitekturës së softuerit lehtëson komunikimin midis palëve të interesuara, kap vendimet e hershme në lidhje me dizajnin në nivel të lartë dhe mundëson ripërdorimin e komponentëve të dizajnit midis projekteve..

Projektimi i arkitekturës së softuerit zakonisht krahasohet me projektimin e aplikacioneve softuerike . Ndërsa projektimi i aplikacioneve fokusohet në projektimin e proceseve dhe të dhënave që mbështesin funksionalitetin e kërkuar (shërbimet që ofron sistemi), projektimi i arkitekturës së softuerit fokusohet në projektimin e infrastrukturës brenda së cilës mund të realizohet dhe ekzekutohet funksionaliteti i aplikacionit, në mënyrë që funksionaliteti të ofrohet në një formë që plotëson kërkesat jo-funksionale të sistemit.

Arkitekturën e softuerit mund ta kategorizojmë në dy lloje kryesore: arkitekturë monolite dhe arkitekturë e shpërndarë,secila me nënkategoritë e veta.

Arkitektura e softuerit tenton të bëhet më komplekse me kalimin e kohës. Arkitektët e softuerit duhet të përdorin " funksione përshtatjeje " për ta mbajtur arkitekturën të kontrolluar në mënyrë te vazhdueshme.

Aktivitetet e arkitekturës së softuerit

Fushat

Ekzistojnë mendime të ndryshme lidhur me fushën e arkitekturës së softuerit:

• Struktura makroskopike e sistemit : Kjo i referohet arkitekturës si një abstraksion në nivel më të lartë të një sistemi softuerik që përbëhet nga një koleksion komponentësh llogaritës së bashku me lidhës që përshkruajnë ndërveprimin midis këtyre komponentëve..
• Gjërat e rëndësishme – çfarëdo qoftë kjo : Kjo i referohet faktit që arkitektët e softuerit duhet të merren me ato vendime që kanë ndikim të madh mbi sistemin dhe palët e interesuara.
• Ajo që është thelbësore për të kuptuar një sistem në mjedisin e tij
• Gjërat që njerëzit i perceptojnë si të vështira për t'u ndryshuar :Meqenëse projektimi i arkitekturës ndodh në fillim të ciklit jetësor të një sistemi softuerik, arkitekti duhet të përqendrohet në vendime që "duhet" të jenë të sakta herën e parë. Duke ndjekur këtë logjikë, çështjet e projektimit arkitektonik mund të mos jenë më arkitekturore pasi tëkapërcehet pakthyeshmëria e tyre..
• Një grup vendimesh të projektimit arkitektonik : Arkitektura e softuerit nuk duhet të konsiderohet thjesht një grup modelesh ose strukturash, por duhet të përfshijë vendimet që çojnë në këto struktura të veçanta dhe arsyetimin pas tyre. Ky kuptim ka çuar në hulumtime të konsiderueshme mbimenaxhimin e njohurive të arkitekturës softuerike.

Nuk ka një kufi të qartë midis arkitekturës së softuerit dhe projektimit apo inxhinierisë së kërkesave. (shih fushat përkatëse më poshtë). Ata janë pjesë e një "zinxhiri qëllimshmërie" nga synimet në nivel të lartë deri te detajet në nivel të ulët.

Karakteristikat

Arkitektura e softuerit përmban elementët e mëposhtëm:

Shumë palë të interesuara: Sistemet softuerike duhet të plotësojnë nevojat e një shumëllojshmërie palësh të interesuara si menaxherët e biznesit, pronarët, përdoruesit dhe operatorët. Këto palë kanë shqetësimet e tyre specifike për sistemin. Balancimi i këtyre shqetësimeve dhe demonstrimi i adresimit të tyre është pjesë e projektimit të sistemit. Kjo nënkupton se arkitektura përfshin trajtimin e një larmie të gjerëshqetësimesh dhe palësh të interesuara dhe ka një natyrë multidisiplinare.

Ndarja e shqetësimeve : Mënyra e vendosur për të reduktuar kompleksitetin është ndarja e shqetësimeve që ndikojnë në projektim. Dokumentimi i arkitekturës tregon se të gjitha shqetësimet e palëve të interesuara trajtohen duke modeluar dhe përshkruar arkitekturën nga pikëpamje të veçanta që lidhen me shqetësimet e ndryshme të palëve të interesuara. Këto përshkrime të veçanta quhen pamje arkitekturore (shih për shembull modelin e pamjes arkitekturore 4+1 ).

E drejtuar nga cilësia: qasjet klasike projektimit të softuerit (p.sh. Jackson Structured Programming ) janë udhëhequr nga funksionaliteti i kërkuar dhe rrjedha e të dhënave përmes sistemit, por kuptimi aktual është se arkitektura e një sistemi softuerik lidhet më ngushtë me atributet e tij të cilësisë si toleranca ndaj gabimeve, përputhshmëria me prapavijën, zgjerueshmëria, besueshmëria, mirëmbajtja, disponueshmëria, siguria, përdorshmëria dhe të tjera të ngjashme . Shqetësimet e palëve të interesuara shpesh përkthehen në kërkesa për këto atribute cilësie, të cilat quhen ndryshe kërkesa jo-funksionale, kërkesa shtesë-funksionale, kërkesa të sjelljes ose kërkesa për atributet e cilësisë.

Stile të përsëritura: Ashtu si arkitektura e ndërtesave, disiplinës së arkitekturës së softuerit i janë zhvilluar mënyra standarde për të trajtuar shqetësime të përsëritura. Këto "mënyra standarde" quhen me emra të ndryshëm në nivele të ndryshme abstraksioni. Terma të zakonshëm për zgjidhje të përsëritura janë stili arkitekturor,taktikë,arkitektura e referencës dhe modeli arkitektonik .

Integriteti konceptual: një term i prezantuar nga Fred Brooks në librin e tij të vitit 1975 The Mythical Man-Month, që nënkupton idenë se arkitektura e një sistemi softuerik përfaqëson një vizion të përgjithshëm për atë që duhet të bëjë dhe si duhet ta bëjë. Ky vizion duhet të ndahet nga zbatimi i tij. Arkitekti merr rolin e "ruajtësit të vizionit", duke u siguruar që shtesat në sistem të jenë në përputhje me arkitekturën, duke ruajtur kështuintegritetin konceptual .

Kufizimet njohëse: Një vëzhgim i bërë për herë të parë në një artikull të vitit 1967 nga programuesi kompjuterik Melvin Conway, ku organizatat që projektojnë sisteme janë të kufizuara të prodhojnë projekte që janë kopje të strukturave të komunikimit të këtyre organizatave.. Fred Brooks e prezantoi këtë ide tek një audiencë më e gjerë kur citoi këtë artikull dhe këtë ide në The Mythical Man-Month, duke e quajtur atë Ligji i Conway .

Motivimi

Arkitektura e softuerit është një abstraksion "lehtësisht i kuptueshëm" i një sistemi kompleks. Ky abstraksion ofron një numër përfitimesh:

• Ofron bazë për analizimin e sjelljes së sistemeve softuerike para se të ndërtohet sistemi. Aftësia për të verifikuar që një sistem i ardhshëm softuerësh plotëson nevojat e palëve të interesuara pa qenë nevoja ta ndërtojmë atë përfaqëson një kursim të konsiderueshëm të kostos dhe reduktim të rrezikut. Janë zhvilluar një sërë teknikash për të kryer analiza të tilla, si ATAM ose duke krijuar një përfaqësim vizual të sistemit të softuerit.
• Ofron një bazë për ripërdorimin e elementeve dhe vendimeve. Një arkitekturë e plotë softuerike ose pjesë të saj, siç janë strategjitë dhe vendimet arkitekturore individuale, mund të ripërdoren nëpër sisteme të shumta, të cilët kërkojnë cilësi ose funksionalitete të ngjashme për palët e interesuara, duke kursyer kostot e projektimit dhe duke ulur rrezikun e gabimeve në projektim.
• Mbështet vendimet e hershme të projektimit që ndikojnë në zhvillimin, vendosjen dhe mirëmbajtjen e një sistemi. Marrja e vendimeve të sakta, të hershme, me ndikim të lartë që në fillim është thelbësore për të parandaluar tejkalimet e buxhetit dhe afateve .
• Lehtëson komunikimin me palët e interesuara, duke kontribuar në krijimin e një sistemi që i plotëson më mirë nevojat e tyre.Komunikimi rreth sistemeve të komplikuara nga këndvështrimi i palëve të interesuara i ndihmon ata të kuptojnë pasojat e kërkesave të tyre të dhe vendimet e projektimit të bazuara në to. Arkitektura mundëson komunikimin mbi vendimet e projektimit përpara se sistemi të zbatohet, kur ato janë ende relativisht të lehta për t'u përshtatur.
• Ndihmon në menaxhimin e rreziqeve. Arkitektura e softuerit ndihmon në reduktimin e rreziqeve dhe mundësinë e dështimit.
• Mundëson uljen e kostos . Arkitektura e softuerit është një mjet për të menaxhuar rrezikun dhe kostot në projekte komplekse të TI-së.

Krahasimi midis projektimit të softuerit dhe arkitekturës (civile) u bë për herë të parë në fund të viteve 1960, por termi "arkitekturë e softuerit" nuk u përdor gjerësisht deri në vitet 1990. Disiplina e shkencave kompjuterike është përballur me probleme që lidhen me kompleksitetin që nga krijimi i saj. Problemet e hershme të kompleksitetit u zgjidhën nga zhvilluesit duke zgjedhur strukturat e duhura të të dhënave, duke zhvilluar algoritme dhe duke aplikuar konceptin e ndarjes së shqetësimeve . Edhe pse termi "arkitekturë e softuerit" është relativisht i ri në industri, parimet themelore të kësaj fushe janë aplikuar herë pas here nga pionierët e inxhinierisë softuerike që nga mesi i viteve 1980. Përpjekjet e hershme për të kapur dhe shpjeguar arkitekturën softuerit të një sistemi ishin të pasakta dhe të pa organizuara, shpesh të karakterizuara nga një grup diagramesh kutish dhe vijash.

Arkitektura e softuerit si një koncept e ka origjinën e tij në hulumtimet e Edsger Dijkstra në 1968 dhe David Parnas në fillim të viteve 1970. Këta shkencëtarë theksuan se struktura e një sistemi softuerik ka rëndësi dhe se përcaktimi i strukturës së duhur është kritik. Gjatë viteve 1990 pati një përpjekje të përqendruar për të përcaktuar dhe kodifikuar aspekte themelore të disiplinës, me hulumtime qe u fokusuan në stile ( modele ) arkitekturore, gjuhët e përshkrimit të arkitekturës, dokumentim arkitekturor dhe metoda formale .

Institucionet kërkimore kanë luajtur një rol të rëndesishëm në zhvillimin e arkitekturës së softuerit si një disiplinë. Mary Shaw dhe David Garlan nga Carnegie Mellon shkruan një libër të titulluar Software Architecture: Perspectives on an Emerging Discipline në vitin 1996, i cili promovoi konceptet e arkitekturës së softuerit si komponentët, lidhësit dhe stilet. Përpjekjet e Institutit për Kërkime Softuerike të Universitetit të Kalifornisë në Irvine në kërkimet mbi arkitekturën e softuerit janë përqendruar kryesisht në stilet arkitekturore, gjuhët përshkruese të arkitekturës dhe arkitekturën dinamike.

IEEE 1471 -2000, "Praktika e Rekomanduar për Përshkrimin e Arkitekturës së Sistemeve të mbështetur nga Softueri", ishte standardi i parë formal në fushën e arkitekturës së softuerit. Ai u miratua në 2007 nga ISO si ISO/IEC 42010:2007 . Në nëntor 2011, IEEE 1471–2000 u zëvendësua nga ISO/IEC/IEEE 42010:2011, "Inxhinieria e sistemeve dhe softuerëve – Përshkrimi i arkitekturës" (publikuar në mënyrë të përbashkët nga IEEE dhe ISO).

Ndërsa në IEEE 1471, arkitektura e softuerit trajtonte arkitekturën e "sistemeve të mbështetur nga softueri", e cila definohej si "çdo sistem ku softueri kontribuon me ndikime thelbësore në projektimin, ndërtimin, vendosjen dhe evolucionin e sistemit si një tërësi", edicioni i 2011 shkon një hap më tej duke përfshirë definicionet e sistemit të ISO/IEC 15288 dhe ISO/IEC 12207 të cilat përfshijnë jo vetëm harduerin dhe softuerin, por gjithashtu "njerëzit, proceset, procedurat, objektet, materialet dhe entitetet që ndodhin natyrshëm". Kjo pasqyron marrëdhënien midis arkitekturës së softuerit, arkitekturës së ndërmarrjes dhe arkitekturës së zgjidhjeve .

Aktivitete Arkitekturore

Arkitekti i softuerit kryen shume aktivitete. Zakonisht, ai punon me menaxherët e projekteve, diskuton kërkesat arkitekturore të rëndësishme me palët e interesuara, projekton arkitekturën e softuerit, vlerëson një dizajn, komunikon me projektuesit dhe palët e interesuara, dokumenton dizajnin arkitekturor dhe më shumë.

Është përgjegjësi e arkitektit të softuerit të përputhë me karakteristikat arkitekturore (të njohura si kërkesat jo-funksionale ) me kërkesat e biznesit. Për shembull:

• Të kesh një kënaqësi të lartë të klientit kërkon disponueshmëri, tolerancë ndaj gabimeve, siguri, testueshmëri, rikuperueshmëri, elasticitet dhe performancë në sistem.
• Blerjet dhe bashkimet (M&A) kërkojnë zgjerueshmëri, shkallëzueshmëri, adaptueshmëri dhe ndërveprim.
• Kufizimet në buxhet dhe kohë kërkojnë realizueshmëri dhe thjeshtësi.
• Hedhja më e shpejtë +në treg kërkon mirëmbajtje, testueshmëri dhe shpërndarje të shpejtë.

Janë katër aktivitete kryesore në projektimin e arkitekturës së softuerit. Këto aktivitete kryesore të arkitekturës kryhen në mënyrë iteruese në faza të ndryshme të ciklit të zhvillimit të softuerit, si dhe gjatë evolucionit të një sistemi.

Vlerësimi i Arkitekturës është procesi i përcaktimit të shkallës në të cilën dizajni aktual ose një pjesë e tij plotëson kërkesat e nxjerra gjatë analizës. Të dhënat ose kërkesat për aktivitetin e analizës mund të vijnë nga çdo numër i palësh të interesuara dhe përfshijnë elementë të tillë si:

• çfarë do të bëjë sistemi kur të jetëperkthe n në funksion (kërkesat funksionale)
• Sa mirë do të performojë sistemi gjatë ekzekutimit për kërkesat jofunksionale si besueshmëria,operabiliteti, efikasiteti i performancës, siguria dhe përputhshmëria, të përcaktuara në standardin ISO/IEC 25010:2011 Kërkesat jofunksionale gjatë kohës së zhvillimit, si mirëmbajtshmëria dhe transferueshmëria, të përcaktuara në standardin ISO 25010:2011
• Kërkesat e biznesit dhe kontekstet mjedisore të një sistemi që mund të ndryshojnë me kalimin e kohës, si çështjet ligjore, sociale, financiare, konkurruese dhe teknologjike

Rezultatet e aktivitetit të analizës janë ato kërkesa që kanë një ndikim të matshëm në arkitekturën e një sistemi softuerik, të quajtura kërkesa të arkitekturorisht të rëndësishme .

Sinteza ose dizajni arkitekturor është procesi i krijimit të një arkitekture. Duke pasur parasysh kërkesat e arkitekturorisht të rëndësishme të përcaktuara nga analiza, gjendjen aktuale të projektimit dhe rezultatet e çdo aktiviteti vlerësimi, dizajni është krijuar dhe përmirësuar.

Vlerësimi i arkitekturës është procesi i përcaktimit se sa mirë dizajni aktual ose një pjesë e tij i plotëson kërkesat e nxjerra gjatë analizës. Një vlerësim mund të ndodhë kurdo që një arkitekt po merr një vendim projektimi, mund të ndodhë pasi të ketë përfunduar një pjesë e projektimit, mund të ndodhë pas përfundimit të projektit përfundimtar, ose mund të ndodhë pasi sistemi të jetë ndërtuar. Disa nga teknikat e disponueshme të vlerësimit të arkitekturës së softuerit përfshijnë metodën e analizës së ndërlikimeve të arkitekturës (ATAM) dhe TARA. Kornizat për krahasimin e teknikave diskutohen në korniza të tilla si Raporti SARA dhe Rishikimet e Arkitekturës: Praktika dhe Përvoja .

Evolucioni i arkitekturës është procesi i mirëmbajtjes dhe përshtatjes së një arkitekture ekzistuese të softuerit për të përmbushur ndryshimet në kërkesa dhe mjedis. Meqenëse arkitektura e softuerit ofron një strukturë themelore për një sistem softuerik, evolucioni dhe mirëmbajtja e saj do të ndikojnë domosdoshmërisht në strukturën e saj themelore. Prandaj, evolucioni i arkitekturës merret si me shtimin e funksionaliteteve të reja, ashtu edhe me mirëmbajtjen e funksionaliteteve ekzistuese dhe sjelljes së sistemit.

Arkitektura kërkon aktivitete mbështetëse kritike. Këto aktivitete mbështetëse zhvillohen gjatë procesit kryesor të arkitekturës së softuerit. Ato përfshijnë menaxhimin dhe komunikimin e njohurive, arsyetimin dhe marrjen e vendimeve në dizajn, si dhe dokumentimin.

Aktivitete mbështetëse të arkitekturës

Aktivitetet mbështetëse të arkitekturës së softuerit kryhen gjatë aktiviteteve kryesore të arkitekturës së softuerit. Këto aktivitete ndihmojnë arkitektin e softuerit për të kryer analiza, sintezë, vlerësim dhe evolucion. Për shembull, gjatë fazës së analizës, një arkitekt duhet të mbledhë njohuri, të marrë vendime dhe të dokumentojë.

• Menaxhimi dhe komunikimi i njohurive është veprimi i eksplorimit dhe menaxhimit të njohurive që janë thelbësore për projektimin e një arkitekture softuerike. Një arkitekt softuerik nuk punon në izolim. Ata marrin hyrje, si kërkesa funksionale dhe jo-funksionale, dhe kontekste dizajni nga një gamë e gjerë palësh të interesuara dhe ofrojnë rezultate për këto palë. Njohuritë për arkitekturën e softuerit shpesh janë të pashprehura dhe mbahen në mendjet e palëve të interesuara. Aktiviteti i menaxhimit të njohurive për arkitekturën e softuerit konsiston në gjetjen, komunikimin dhe ruajtjen e këtyre njohurive.
• Meqenëse çështjet e dizajnit të arkitekturës së softuerit janë komplekse dhe të ndërlidhura, një mungesë njohurish në arsyetimin e dizajnit mund të çojë në një projektim të pasaktë të arkitekturës së softuerit.
• Shembuj të aktiviteteve të menaxhimit dhe komunikimit të njohurive përfshijnë kërkimin për modele dizajni, prototipizimin, pyetjen e zhvilluesve dhe arkitektëve me përvojë, vlerësimin e dizajneve të sistemeve të ngjashme, ndarjen e njohurive me dizajnues të tjerë dhe palë të interesuara, dhe dokumentimin e eksperiencës në një faqe wiki.
• Arsyetimi i dizajnit dhe marrja e vendimeve është aktiviteti i vlerësimit të vendimeve të dizajnit. Ky aktivitet është thelbësor për të tre aktivitetet kryesore të arkitekturës së softuerit. Ai përfshin mbledhjen dhe shoqërimin e konteksteve të vendimeve, formulimin e problemeve të vendimeve të dizajnit, gjetjen e opsioneve të zgjidhjes dhe vlerësimin e kompromiseve para se të merret një vendim. Ky proces ndodh në nivele të ndryshme të hollësisë së vendimeve gjatë vlerësimit të kërkesave të rëndësishme arkitekturore dhe vendimeve për arkitekturën e softuerit, si dhe gjatë analizës, sintezës dhe vlerësimit të arkitekturës së softuerit. Shembuj të aktiviteteve të arsyetimit përfshijnë kuptimin e ndikimeve të një kërkese ose një dizajni në atributet e cilësisë, pyetjen e problemeve që mund të shkaktojë një dizajn, vlerësimin e opsioneve të mundshme të zgjidhjes dhe vlerësimin e kompromiseve midis zgjidhjeve.
• Dokumentimi është akti i regjistrimit të dizajnit të krijuar gjatë procesit të arkitekturës së softuerit. Dizajni i sistemit përshkruhet duke përdorur disa pamje që shpesh përfshijnë një pamje statike që tregon strukturën e kodit të sistemit, një pamje dinamike që tregon veprimet e sistemit gjatë ekzekutimit, dhe një pamje të vendosjes që tregon se si një sistem vendoset në hardware për ekzekutim. Pamja 4+1 e Kruchten sugjeron një përshkrim të pamjeve të përdorura shpesh për dokumentimin e arkitekturës së softuerit
• Dokumentimi i Arkitekturave të Softuerit: Pamje dhe Përtej ka përshkrime të llojeve të shenjave që mund të përdoren brenda përshkrimit të pamjes
• Shembuj të aktiviteteve të dokumentimit janë shkrimi i një specifikimi, regjistrimi i një modeli të dizajnit të sistemit, dokumentimi i një arsyeje për dizajnin, zhvillimi i një pikëpamje, dhe dokumentimi i pamjeve.

Temat e arkitekturës së softuerit

Përshkrimi i arkitekturës së softuerit

Përshkrimi i arkitekturës së softuerit përfshin parimet dhe praktikat e modelimit dhe përfaqësimit të arkitekturave, duke përdorur mekanizma si gjuhët e përshkrimit të arkitekturës, pikëpamjet earkitekturës dhe kornizat e arkitekturës.

Gjuhët e Përshkrimit të Arkitekturës

Një gjuhë përshkrimi i arkitekturës (ADL) është çdo mjet shprehjeje që përdoret për të përshkruar një arkitekturë softuerike ( ISO/IEC/IEEE 42010 ). Shumë ADL-ve të përdorimit të veçantë janë zhvilluar që nga vitet 1990, përfshirë AADL (standard SAE), Wright (zhvilluar nga Carnegie Mellon), Acme (zhvilluar nga Carnegie Mellon), xADL (zhvilluar nga UCI), Darwin (zhvilluar nga Imperial College London ), DAOP-ADL (zhvilluar nga Universiteti i Málaga), SBC-ADL (zhvilluar nga Universiteti Nacional Sun Yat-Sen ), dhe ByADL (Universiteti i L'Aquila, Itali).

Pikëpamjet e arkitekturës

Modeli me pamje arkitektonike 4+1 .

Përshkrimet e arkitekturës së softuerit zakonisht organizohen nëpërmjet pikave të shikimit , të cilat janë analoge me llojet e ndryshme të planeve të ndërtimit në arkitekturën e ndërtesave. Çdo pikë shikimi adreson një grup shqetësimesh të sistemit, duke ndjekur konventat e pikës së pikëpamjes së saj, ku një pikëpamje është një specifikim që përshkruan shënimet, modelimin dhe teknikat e analizës për të përdorur në një pikë shikimi që shpreh arkitekturën në fjalë nga perspektiva i një grupi të caktuar të palëve të interesuara dhe shqetësimet e tyre ( ISO/IEC/IEEE 42010 ). Pika e shikimitspecifikon jo vetëm shqetësimet që janë përfshirë (dmth., që do të adresohen), por edhe paraqitjen, llojet e modeleve të përdorura, konventat e përdorura dhe çdo rregull të konsistencës (përputhjes) për të mbajtur një pikëpamje të konsoliduar me pikëpamjet e tjera.

Kornizat e arkitekturës

Një kornizë arkitekture kap "konventat, principet dhe praktikat për përshkrimin e arkitekturave të vendosura brenda një domeni të caktuar aplikimi dhe/ose një komuniteti të palëve të interesuara"( ISO/IEC/IEEE 42010 ). Një kornizë zakonisht zbatohet nëpërmjet një ose më shumë pikëpamjeve ose ADL-ve.

Stilet dhe modelet arkitekturore

Një model arkitekture është një zgjidhje e përgjithshme, e ripërdorshme për një problem të zakonshëm në arkitekturën e softuerit brenda një konteksti të caktuar. Modelet arkitekturore shpesh dokumentohen si modele të dizajnit të softuerit.

Duke ndjekur arkitekturën tradicionale të ndërtimit, një "stil arkitektonik softuerik" është një metodë e veçantë ndërtimi, e karakterizuar nga tiparet që e bëjnë të dallueshëm" ( stili arkitektonik ). Një stil arkitektonik përcakton: një familje sistemesh në terma të një modeli të organizatës strukturore; një fjalor komponentësh dhe lidhësish, me kufizime se si mund të kombinohen ata. Stilet arkitekturore janë "paketa" të ripërdorshme vendimesh dizajni dhe kufizimesh që zbatohen në një arkitekturë për të nxitur cilësitë e dëshiruara të zgjedhura. Ka shumë modele dhe stile arkitekturore të njohura, disa prej të cilave janë:

• Blackboard
• Model Broker
• Klient-server (2-tier, 3-tier, <i id="mwAYU">n</i> -tier, kompjuterizimi në re paraqet këtë stil)
• Baza e komponentëve
• Baza e të dhënave
• Ngjarje të drejtuara (ose thirrje të implicit )
• Modeli interpreter
• Arkitektura e shtresuar (ose shumë-shtresore)
• Master-slave
• Arkitektura e Mikroshërbimeve
• Modeli-pikë-dëshirë(MVC)
• Aplikacioni Monolitik
• Peer-to-peer (P2P)
• Tubat dhe filtrat
• Plug-ins
• Arkitektura reaktive
• Transferimi i shtetit të përfaqësimit (REST)
• Bazuar në rregulla
• Orientuar në shërbim
• Arkitektura pa ndarje
• Arkitektura hapësinore
• Arkitektura pa server

Disa i trajtojnë modelet arkitekturore dhe stilet arkitekturore si të njëjta, disa i trajtojnë stilet si specializime të modeleve. Ajo që kanë të përbashkët është se si modelet, ashtu edhe stilet janë idiomë për arkitektët që t’i përdorin, ato "sigurojnë një gjuhë të përbashkët" ose "fjalor" me të cilin përshkruajnë klasat e sistemeve.

Arkitektura e softuerit dhe zhvillimi i shkathët

Ka gjithashtu shqetësime që arkitektura e softuerit çon në një dizajn shumë të madh në fillim, veçanërisht ndërmjet mbështetësve të zhvillimit të softuerit të shkathët . Janë zhvilluar disa metoda për të balancuar kompromise midis dizajnit në fillim dhe shkathtësisë, duke përfshirë metodën agile DSDM e cila kërkon një fazë "Themelimesh" gjatë së cilës vendosen "mjaftueshëm" themele arkitekturore. IEEE Software i kushtoi një numër të veçantë ndërveprimit midis shkathtesise dhe arkitekturës.

Erozioni i arkitekturës së softuerit

Erozioni i arkitekturës së softuerit i referohet një hendeku gradual midis arkitekturës së synuar dhe asaj të zbatuar të një sistemi softuerik me kalimin e kohës. Fenomeni i erozionit të arkitekturës së softuerit u soll për herë të parë në dritë në vitin 1992 nga Perry dhe Wolf, së bashku me definimin e tyre të arkitekturës së softuerit.

Erozioni i arkitekturës së softuerit mund të ndodhë në çdo fazë të ciklit të jetës së zhvillimit të softuerit dhe ka ndikime të ndryshme në shpejtësinë e zhvillimit dhe kostot e mirëmbajtjes. Erozioni i arkitekturës së softuerit ndodh për shkak të arsyeve të ndryshme, si shkelje arkitekturore, akumulimi i borxhit teknik dhe avullimi i njohurive . Një rast i famshëm i erozionit të arkitekturës është dështimi i shfletuesit të internetit Mozilla. Mozilla është një aplikacion i krijuar nga Netscape me një bazë të koduar komplekse që u bë më e vështirë për t'u mbajtur për shkak të ndryshimeve të vazhdueshme. Për shkak të dizajnit fillestar të dobët dhe erozionit të rritur të arkitekturës, Netscape kaloi dy vjet duke renovar shfletuesin e internetit Mozilla, duke treguar se sa e rëndësishme është menaxhimi i erozionit të arkitekturës për të shmangur përpjekjet e shtrenjta për riparime, humbjen e kohës dhe kostos.

Erozioni i arkitekturës mund të urojë performancën e softuerit, të rrisë ndjeshëm kostot evolutive dhe të degradojë cilësinë e softuerit. Janë propozuar qasje dhe mjete të ndryshme për të zbuluar erozionin e arkitekturës. Këto qasje klasifikohen kryesisht në katër kategori: të bazuara në konsistencë, të bazuara në evolucion, të bazuara në defekte dhe qasje të bazuara në vendimmarrje. Përveç kësaj, masat që përdoren për të adresuar erozionin e arkitekturës përmbajnë dy lloje kryesore: masa parandaluese dhe masa rregulluese..

Rimëkëmbja e arkitekturës së softuerit

Stilet arkitekturore janë "paketa" të ripërdorshme vendimesh dizajni dhe kufizimesh që zbatohen në një arkitekturë për të nxitur cilësitë e dëshiruara të zgjedhura.

Rikuperimi i arkitekturës së softuerit (ose rindërtimi, ose inxhinieria e kundërt )përfshin metodat, teknikat dhe proceset për të zbuluar arkitekturën e një sistemi softuerik nga informacionet e disponueshme, duke përfshirë implementimin dhe dokumentimin e tij. Rikuperimi i arkitekturës është shpesh i nevojshëm për të marrë vendime të informuara përballë dokumentacionit të vjetruar ose të pasaktë dhe erozionit të arkitekturës : vendimet e zbatimit dhe mirëmbajtjes që ndryshojnë nga arkitektura e parashikuar. Ekzistojnë praktika për të rikuperuar arkitekturën e softuerit si analizë statike e programit . Kjo është një pjesë e temave të mbuluara nga praktika e inteligjencës softuerike .

Fushat e lidhura

Dizajni

 ● ArchiMate ● Modeli arkitektonik (shkenca e kompjuterëve)

● Anti-pattern

● Dizajni i drejtuar nga atributet

● Modeli C4

● Arkitektura e kompjuterëve

● Arkitektura e Menaxhimit të të Dhënave të Distribuara

● Arkitektura e Bazës së të Dhënave Relacionale të Distribuara

● Arkitektura e sistemeve

● Dizajni i sistemeve

● Metoda e Analizës së Arkitekturës së Softuerit

● Sistemi i nisur nga koha

Arkitektura është dizajn, por jo i gjithë dizajni është arkitektonik. arkitektonik. Në praktikë, arkitekti është ai që tërheq vijën midis arkitekturës së softuerit (dizajni arkitektonik) dhe dizajnit të detajuar (dizajni jo arkitektonik). Nuk ka rregulla ose udhëzime që përshtaten për të gjitha rastet, megjithëse ka pasur përpjekje për të formalizuar dallimin. Sipas Hipotezës së intensionit/lokalitetit, dallimi ndërmjet dizajnit arkitekturor dhe atij të detajuar përcaktohet nga Kriteri i Lokalitetit, sipas të cilit një deklaratë rreth dizajnit të softuerit është jo-lokal (arkitektonik) nëse dhe vetëm nëse një program që plotëson se mund të zgjerohet në një program që nuk është. Për shembull, stili klient-server është arkitektonik (strategjik) sepse një program që është ndërtuar mbi këtë princip mund të zgjerohet në një program që nuk është klient-server - për shembull, duke shtuar nyje peer-to-peer .

Inxhinieria e kërkesave

Inxhinieria e kërkesave dhe arkitektura e softuerit mund të shihen si qasje plotësuese: ndërsa arkitektura e softuerit synon ' hapësirën e zgjidhjes ' ose 'si', inxhinieria e kërkesave adreson ' hapësirën e problemit ' ose 'çfarë'. Inxhinieria e kërkesave përfshin nxjerrjen, negociatën, specifikimin, validimin, dokumentimin dhe menaxhimin e kërkesave . Të dyja, inxhinieria e kërkesave dhe arkitektura e softuerit përqendrohen në shqetësimet, nevojat dhe dëshirat e palëve të interesuara .

Ka një mbivendosje të konsiderueshme midis inxhinierisë së kërkesave dhe arkitekturës së softuerit, siç tregohet, për shembull, nga një studim mbi pesë metoda industriale të arkitekturës së softuerit që përfundon se &quot;inputet (qëllimet, kufizimet, etj.) zakonisht janë të pasqaruara, dhe zbulohet ose kuptohen më mirë pasi arkitektura fillon të shfaqet&quot; dhe se ndërsa &quot;shumica e shqetësimeve arkitekturore shprehen si kërkesa për sistemin, ato gjithashtu mund të përfshijnë vendime të detyrueshme të projektimit" . Me pak fjalë, sjellja e kërkuar ndikon në arkitekturën e zgjidhjeve, e cila nga ana tjetër mund të sjellë kërkesa të reja. Qasjet si modeli Twin Peaks synojnë të shfrytëzojnë lidhjen sinergjike midis kërkesave dhe arkitekturës.

Llojet e tjera të "arkitekturës"

Arkitektura kompjuterike

Arkitektura kompjuterike synon strukturën e brendshme të një sistemi kompjuterik, për sa i përket komponentëve të harduerit bashkëpunues si CPU - ose procesori - autobusi dhe memoria .

Arkitektura pa server

Arkitektura pa server është një paradigmë kompjuterike cloud që shpesh keqkuptohet si pa server. Ajo në thelb i kalon përgjegjësitë e menaxhimit të serverit nga zhvilluesit tek ofruesit e shërbimeve në re. Kjo u mundëson bizneseve të ekzekutojnë kodin e tyre të pasëm në infrastrukturën e re, duke eliminuar nevojën për menaxhimin e serverëve fizikë. Qasja e drejtuar nga ngjarjet e arkitekturës pa server mbështetet në funksione të vogla, specifike për detyra që ekzekutohen sipas kërkesës. Këto funksione njihen si Funksion si Shërbim (FaaS), dhe ato ofrojnë efikasitet në kosto përmes një modeli tarifimi sipas përdorimit dhe shkallëzimit dinamik të burimeve bazuar në kërkesën e aplikacionit. </link>

Arkitektura e sistemeve

Termi arkitekturë e sistemeve është përdorur fillimisht për arkitekturën e sistemeve që përbëhen nga hardueri dhe softueri . Shqetësimi kryesor që trajtohet nga arkitektura e sistemeve është integrimi i softuerit dhe harduerit në një pajisje të plotë dhe që funksionon siç duhet. Në një kuptim tjetër të zakonshëm – shumë më të gjerë – termi i referohet arkitekturës së çdo sistemi kompleks që mund të jetë teknik,, socioteknike ose social.

Arkitektura e ndërmarrjes

Qëllimi i arkitekturës së ndërmarrjes është të "përkthejë vizionin dhe strategjinë e biznesit në ndërmarrje efektive". Kornizat e arkitekturës së ndërmarrjeve, të tilla si TOGAF dhe Korniza Zachman, zakonisht dallojnë midis shtresave të ndryshme të arkitekturës së ndërmarrjeve. Edhe pse terminologjia ndryshon nga korniza në kornizë, shumë përfshijnë të paktën një dallim midis një shtrese biznesi, një shtrese aplikimi (ose informacioni ) dhe një shtrese teknologjike . Arkitektura e ndërmarrjeve trajton ndër të tjera përputhjen midis këtyre shtresave, zakonisht në një qasje nga lart-poshtë.

Shihni gjithashtu

● ArchiMate

● Modeli arkitektonik (shkenca e kompjuterëve)

● Anti-pattern

● Dizajni i drejtuar nga atributet

● Modeli C4

● Arkitektura e kompjuterëve

● Arkitektura e Menaxhimit të të Dhënave të Distribuara

● Arkitektura e Bazës së të Dhënave Relacionale të Distribuara

● Arkitektura e sistemeve

● Dizajni i sistemeve

● Metoda e Analizës së Arkitekturës së Softuerit

● Sistemi i nisur nga koha

Referencat

1. Clements, Paul; Felix Bachmann; Len Bass; David Garlan; James Ivers; Reed Little; Paulo Merson; Robert Nord; Judith Stafford (2010). Documenting Software Architectures: Views and Beyond, Second Edition (në english). Boston: Addison-Wesley. ISBN 978-0-321-55268-6.{{cite book}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
2. "Software Architecture". www.sei.cmu.edu (në english). Marrë më 2018-07-23.{{cite web}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
3. Perry, D. E.; Wolf, A. L. (1992). "Foundations for the study of software architecture" (PDF). ACM SIGSOFT Software Engineering Notes (në english). 17 (4): 40. CiteSeerX 10.1.1.40.5174. doi:10.1145/141874.141884. S2CID 628695.{{cite journal}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
4. Head First Software Architecture (në english). O'Reilly Media. 2024. ISBN 978-1098134358.{{cite book}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
5. Fundamentals of Software Architecture: An Engineering Approach (në english). O'Reilly Media. 2020. ISBN 978-1492043454.{{cite book}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
6. Fundamentals of Software Architecture An Engineering Approach (në english). O'Reilly Media. 2020. ISBN 9781492043423.{{cite book}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
7. Bass, Len; Paul Clements; Rick Kazman (2012). Software Architecture in Practice, Third Edition (në english). Boston: Addison-Wesley. ISBN 978-0-321-81573-6.{{cite book}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
8. SEI (2006). "How do you define Software Architecture?" (në english). Marrë më 2012-09-12.{{cite web}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
9. Garlan & Shaw (1994). "An Introduction to Software Architecture" (PDF) (në english). Marrë më 2012-09-13.{{cite web}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
10. Fowler, Martin (2003). "Design – Who needs an architect?". IEEE Software (në english). 20 (5): 11–44. doi:10.1109/MS.2003.1231144. S2CID 356506.{{cite journal}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
11. ISO/IEC/IEEE 42010: Defining "architecture". Iso-architecture.org. Marrë më 2013-07-21.
12. Jansen, A.; Bosch, J. (2005). "Software Architecture as a Set of Architectural Design Decisions". 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05) (në english). fq. 109. CiteSeerX 10.1.1.60.8680. doi:10.1109/WICSA.2005.61. ISBN 978-0-7695-2548-8. S2CID 13492610.{{cite book}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
13. Ali Babar, Muhammad; Dingsoyr, Torgeir; Lago, Patricia; van Vliet, Hans (2009). Software Architecture Knowledge Management (në english). Dordrecht Heidelberg London New York: Springer. ISBN 978-3-642-02373-6.{{cite book}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
14. George Fairbanks (2010). Just Enough Software Architecture (në english). Marshall & Brainerd.{{cite book}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
15. ISO/IEC/IEEE (2011). "ISO/IEC/IEEE 42010:2011 Systems and software engineering – Architecture description" (në english). Marrë më 2012-09-12.{{cite web}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
16. Muller, Gerrit (gusht 20, 2007). "A Reference Architecture Primer" (PDF). Gaudi site (në english). Arkivuar (PDF) nga origjinali më 2011-12-19. Marrë më nëntor 13, 2015.{{cite web}}: Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja) Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
17. Angelov, S.; Grefen, P.; Greefhorst, D. (2009). "A classification of software reference architectures: Analyzing their success and effectiveness". 2009 Joint Working IEEE/IFIP Conference on Software Architecture & European Conference on Software Architecture (në english). IEEE. fq. 141–150. doi:10.1109/WICSA.2009.5290800. ISBN 978-1-4244-4984-2. Marrë më 15 dhjetor 2023.{{cite book}}: Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja) Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
18. Brooks, Frederick P. Jr. (1975). The Mythical Man-Month – Essays on Software Engineering (në english). Addison-Wesley. ISBN 978-0-201-00650-6.{{cite book}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
19. Conway, Melvin. "Conway's Law". Mel Conway's Home Page (në english). Arkivuar nga origjinali më 2019-09-29. Marrë më 2019-09-29.{{cite web}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
20. Obbink, H.; Kruchten, P.; Kozaczynski, W.; Postema, H.; Ran, A.; Dominick, L.; Kazman, R.; Hilliard, R.; Tracz, W.; Kahane, E. (shk 6, 2002). "Software Architecture Review and Assessment (SARA) Report" (PDF) (në english). Marrë më nëntor 1, 2015.{{cite web}}: Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja) Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
21. Poort, Eltjo; van Vliet, Hans (shtator 2012). "RCDA: Architecting as a risk- and cost management discipline". Journal of Systems and Software (në english). 85 (9): 1995–2013. doi:10.1016/j.jss.2012.03.071.{{cite journal}}: Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja) Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
22. P. Naur; B. Randell, red. (1969). "Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7–11 Oct. 1968" (PDF) (në english). Brussels: NATO, Scientific Affairs Division. Arkivuar (PDF) nga origjinali më 2003-06-07. Marrë më 2012-11-16.{{cite web}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
23. P. Kruchten; H. Obbink; J. Stafford (2006). "The past, present and future of software architecture". IEEE Software (në english). 23 (2): 22. doi:10.1109/MS.2006.59. S2CID 2082927.{{cite journal}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
24. University of Waterloo (2006). "A Very Brief History of Computer Science" (në english). Marrë më 2006-09-23.{{cite web}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
25. "Introduction to the Special Issue on Software Architecture". IEEE.org (në english). 2006. doi:10.1109/TSE.1995.10003.{{cite journal}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
26. Garlan & Shaw (1994). "An Introduction to Software Architecture" (PDF) (në english). Marrë më 2006-09-25.{{cite web}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
27. Kruchten, P. (2008). "What do software architects really do?". Journal of Systems and Software (në english). 81 (12): 2413–2416. doi:10.1016/j.jss.2008.08.025.{{cite journal}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
28. Christine Hofmeister; Philippe Kruchten; Robert L. Nord; Henk Obbink; Alexander Ran; Pierre America (2007). "A general model of software architecture design derived from five industrial approaches". Journal of Systems and Software (në english). 80 (1): 106–126. doi:10.1016/j.jss.2006.05.024.{{cite journal}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
29. ISO/IEC (2011). "ISO/IEC 25010:2011 Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models" (në english). Marrë më 2012-10-08.{{cite web}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
30. Osterwalder and Pigneur (2004). "An Ontology for e-Business Models" (PDF). Value Creation from E-Business Models (në english). fq. 65–97. CiteSeerX 10.1.1.9.6922. doi:10.1016/B978-075066140-9/50006-0. ISBN 9780750661409. S2CID 14177438. Arkivuar nga origjinali (PDF) më 2018-11-17.{{cite book}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
31. Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013). "Characterizing Architecturally Significant Requirements". IEEE Software (në english). 30 (2): 38–45. doi:10.1109/MS.2012.174. hdl:10344/3061. S2CID 17399565.{{cite journal}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
32. Woods, E. (2012). "Industrial architectural assessment using TARA". Journal of Systems and Software (në english). 85 (9): 2034–2047. doi:10.1016/j.jss.2012.04.055. S2CID 179244.{{cite journal}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
33. Maranzano, J. F.; Rozsypal, S. A.; Zimmerman, G. H.; Warnken, G. W.; Wirth, P. E.; Weiss, D. M. (2005). "Architecture Reviews: Practice and Experience". IEEE Software (në english). 22 (2): 34. doi:10.1109/MS.2005.28. S2CID 11697335.{{cite journal}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
34. Babar, M.A.; Dingsøyr, T.; Lago, P.; Vliet, H. van (2009). Software Architecture Knowledge Management:Theory and Practice (eds.), First Edition (në english). Springer. ISBN 978-3-642-02373-6.{{cite book}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
35. Tang, A.; Han, J.; Vasa, R. (2009). "Software Architecture Design Reasoning: A Case for Improved Methodology Support". IEEE Software (në english). 26 (2): 43. doi:10.1109/MS.2009.46. hdl:1959.3/51601. S2CID 12230032.{{cite journal}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
36. Kruchten, Philippe (1995). "Architectural Blueprints – The '4+1' View Model of Software Architecture" (PDF). IEEE Software (në english). 12 (6): 42–50. arXiv:2006.04975. doi:10.1109/52.469759. S2CID 219558624.{{cite journal}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
37. Shaw, Mary; Garlan, David (1996). Software architecture: perspectives on an emerging discipline. Prentice Hall. ISBN 978-0-13-182957-2.
38. UCI Software Architecture Research – UCI Software Architecture Research: Architectural Styles. Isr.uci.edu. Marrë më 2013-07-21
39. Chapter 3: Architectural Patterns and Styles. Msdn.microsoft.com. Marrë më 2013-07-21
40. Boehm, Barry; Turner, Richard (2004). Balancing Agility and Discipline (në english). Addison-Wesley. ISBN 978-0-321-18612-6.{{cite book}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
41. Li, Ruiyin; Liang, Peng; Soliman, Mohamed; Avgeriou, Paris (2022). "Understanding software architecture erosion: A systematic mapping study". Journal of Software: Evolution and Process (në english). 34 (3): e2423. arXiv:2112.10934. doi:10.1002/smr.2423.{{cite journal}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
42. Li, Ruiyin; Liang, Peng; Soliman, Mohamed; Avgeriou, Paris (2021). "Understanding architecture erosion: The practitioners' perceptive". The 29th IEEE/ACM International Conference on Program Comprehension (ICPC) (në english). fq. 311–322. doi:10.1109/icpc52881.2021.00037.{{cite book}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
43. van Gurp, J. and Bosch, J.: 2002, Design erosion: Problems and causes, Journal of Systems and Software 61(2), 105–119.
44. Lungu, M. "Software architecture recovery", University of Lugano, 2008. http://www.slideshare.net/mircea.lungu/software-architecture-recovery-in-five-questions-presentation
45. Amnon H. Eden; Rick Kazman (2003). "Architecture Design Implementation" (PDF) (në english). Arkivuar nga origjinali (PDF) më 2007-09-28.{{cite web}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
46. C. Shekaran; D. Garlan; M. Jackson; N.R. Mead; C. Potts; H.B. Reubenstein (1994). "The role of software architecture in requirements engineering". Proceedings of IEEE International Conference on Requirements Engineering (në english). fq. 239–245. doi:10.1109/ICRE.1994.292379. ISBN 978-0-8186-5480-0. S2CID 3129363.{{cite book}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
47. Remco C. de Boer, Hans van Vliet (2009). "On the similarity between requirements and architecture". Journal of Systems and Software (në english). 82 (3): 544–550. CiteSeerX 10.1.1.415.6023. doi:10.1016/j.jss.2008.11.185.{{cite journal}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
48. Bashar Nuseibeh (2001). "Weaving together requirements and architectures" (PDF). Computer (në english). 34 (3): 115–119. doi:10.1109/2.910904. Arkivuar (PDF) nga origjinali më 2012-09-07.{{cite journal}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
49. Company, DashDevs | FinTech Software Development. "How to Use Serverless Architecture | DashDevs". How to Use Serverless Architecture | DashDevs. Marrë më 2023-08-28.

Lexim të mëtejshëm

• Richards, Mark (2020). Fundamentals of Software Architecture: An Engineering Approach (në english). O'Reilly Media. ISBN 9781492043454.{{cite book}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
• Len, Bass (2012). Software Architecture in Practice (në english) (bot. 3rd). Addison-Wesley Professional. ISBN 9780321815736.{{cite book}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja) - This book covers the fundamental concepts of the discipline. The theme is centered on achieving quality attributes of a system.
• Clements, Paul (2010). Documenting Software Architectures: Views and Beyond (në english) (bot. 2nd). Addison-Wesley Professional. ISBN 9780321552686.{{cite book}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja) - This book describes what software architecture is and shows how to document it in multiple views, using UML and other notations. It also explains how to complement the architecture views with behavior, software interface, and rationale documentation. Accompanying the book is a wiki that contains an example of software architecture documentation.
• Bell, Michael (2008). Bell, Michael (red.). Service-Oriented Modeling: Service Analysis, Design, and Architecture (në english). Wiley. doi:10.1002/9781119198864. ISBN 9780470255704.{{cite book}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
• Shan, Tony; Hua, Winnie (tetor 2006). "Solution Architecting Mechanism". 2006 10th IEEE International Enterprise Distributed Object Computing Conference (EDOC'06) (në english). fq. 23–32. doi:10.1109/EDOC.2006.54. ISBN 978-0-7695-2558-7.{{cite book}}: Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja) Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
• Garzás, Javier; Piattini, Mario (2005). "An ontology for micro-architectural design knowledge". IEEE Software (në english). 22 (2): 28–33. doi:10.1109/MS.2005.26.{{cite journal}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
• Fowler, Martin (shtator 2003). "Who Needs an Architect?" (PDF). IEEE Software (në english). 20 (5). doi:10.1109/MS.2003.1231144.{{cite journal}}: Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja) Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
• Kazman, Rick (maj 2003). "Architecture, Design, Implementation" (PDF). Software Engineering Institute (në english). Arkivuar (PDF) nga origjinali më 2015-09-21.{{cite journal}}: Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja) Mirëmbajtja CS1: Gjuhë e panjohur (lidhja) - On the distinction between architectural design and detailed design.
• Kruchten, Philippe (1995). "Architectural Blueprints – The '4+1' View Model of Software Architecture" (PDF). IEEE Software (në english). 12 (6): 42–50. arXiv:2006.04975. doi:10.1109/52.469759. Arkivuar (PDF) nga origjinali më 2006-06-13.{{cite journal}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)
• Pautasso, Cesare (2020). Software Architecture: visual lecture notes (në english). LeanPub. fq. 689.{{cite book}}: Mirëmbajtja CS1: Gjuhë e panjohur (lidhja)

Lidhje të jashtme

• Shpjegim mbi IBM Developerworks
• Koleksioni i përkufizimeve të arkitekturës së softuerit në Institutin e Inxhinierisë së Softuerit (SEI), Universiteti Carnegie Mellon (CMU)
• Shoqata Ndërkombëtare e Arkitektëve të IT (IASA Global), e njohur më parë si Shoqata Ndërkombëtare për Arkitektët e Softuerit (IASA)
• SoftwareArchitecturePortal.org – uebsajti i Grupit të Punës IFIP 2.10 mbi Arkitekturën e Softuerit
• SoftwareArchitectures.com – një burim i pavarur informacioni mbi disiplinën
• Arkitektura e Softuerit, kapitulli 1 i disertacionit REST të Roy Fielding
• Kur arkitektura e mirë shkon keq
• Zhvillimi i drejtuar nga arkitektura spirale - SDLC i bazuar në modelin Spiral synon të zvogëlojë rreziqet e arkitekturës joefektive
• Studime të rastit të arkitekturës së softuerit të jetës reale