Arkitektura e softuerit

Arkitektura e softuerit trajton natyrshëm pasiguri, dhe madhësia e komponenteve arkitekturore mund të ketë një ndikim të rëndësishëm në rezultatet e një sistemi, si në mënyrë pozitive, ashtu edhe negative. Neal Ford dhe Mark Richards propozojnë një qasje përsëritese për të adresuar sfidën e identifikimit dhe përcaktimit të masës së duhur të komponenteve. Kjo metodë përqendrohet në rafinimin e vazhdueshëm ndërsa ekipet zhvillojnë një kuptim më të thelluar dhe të nuancuar të sjelljes dhe kërkesave të sistemit.ërsëritëse për të adresuar sfidën e identifikimit dhe madhësisë së duhur të komponentëve. Kjo metodë thekson përsosjen e vazhdueshme ndërsa ekipet zhvillojnë një kuptim më të hollësishëm të sjelljes dhe kërkesave të sistemit. 

Qasja zakonisht përfshin një cikël me disa faza: 

 Një strategji ndarjeje e nivelit të lartë vendoset, e cila shpesh kategorizohet si teknike ose e bazuar në domen. Përcaktohen udhëzime për njësinë më të vogël kuptimplote të lëvizshme, të referuara si "kuanta". Ndërsa këto vendime themelore merren herët, ato mund të rishikohen më vonë gjatë ciklit nëse është e nevojshme.
 Komponentët fillestarë identifikohen bazuar në strategjinë e përcaktuar.
 Kërkesat u caktohen komponentëve të identifikuar.
 Rolet dhe përgjegjësitë e secilit komponent analizohen për të siguruar qartësi dhe për të minimizuar mbivendosjen.
 Karakteristikat arkitekturore, të tilla si shkallëzueshmëria, toleranca ndaj defekteve dhe mirëmbajtja, vlerësohen.
 Komponentët mund të ristrukturohen bazuar në reagimet nga ekipet e zhvillimit.

Ky cikël shërben si një kornizë e përgjithshme dhe mund të përshtatet në fusha të ndryshme.

 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.

 Stili i arkitekturës së softuerit vs Modeli i arkitekturës së softuerit 
Modeli i Arkitekturës së Softuerit i referohet një zgjidhjeje të ripërdorshme dhe të provuar për një problem që përsëritet në nivel sistemi, duke trajtuar çështje që lidhen me strukturën e përgjithshme, mënyrën se si ndërveprojnë komponentët dhe tiparet cilësore të sistemit. Modelet e arkitekturës së softuerit funksionojnë në një nivel më të lartë abstraksioni sesa modelet e dizajnit të softuerit, duke zgjidhur sfida më të gjera në nivel sistemi. Edhe pse këto modele zakonisht ndikojnë në çështje të përmasave sistemore, dallimi midis modeleve arkitekturore dhe stileve arkitekturore nganjëherë mund të jetë i paqartë. Një shembull i tillë është Circuit Breaker (ndërprerës qarku).

Stili i Arkitekturës së Softuerit i referohet një organizimi strukturor të nivelit të lartë që përcakton organizimin e përgjithshëm të sistemit, duke specifikuar se si organizohen komponentët, si bashkëveprojnë dhe kufizimet në këto bashkëveprime. Stilet e arkitekturës zakonisht përfshijnë një fjalor të llojeve të komponentëve dhe lidhësve, si dhe modele semantike për interpretimin e karakteristikave të sistemit. Këto stile përfaqësojnë nivelin më të përgjithshëm të organizimit të sistemit. Shembujt përfshijnë Arkitekturën e Shtresuar, Mikroshërbimet dhe Arkitekturën e Drejtuar nga Ngjarjet .   
 Anti-modelet 
Anti-modelet arkitekturore që vijojnë mund të lindin si pasojë e vendimeve të arkitektëve. Këto anti-modele zakonisht zhvillohen sipas një sekuence progresive, ku adresimi i një problemi mund të shkaktojë shfaqjen e një problemi tjetër. 

 Një arkitekt mund të vonojë ose të shmangë marrjen e vendimeve arkitekturore për shkak të frikës së zgjedhjes së gabuar. Për ta adresuar këtë, shpesh është i nevojshëm bashkëpunimi i vazhdueshëm dhe i ngushtë me ekipin e zhvillimit, me zgjedhjet arkitekturore që përshtaten bazuar në reagimet e tyre. Përveç kësaj, vendimet zakonisht merren në "momentin e fundit përgjegjës", duke siguruar që të ketë informacion të mjaftueshëm për të justifikuar dhe vërtetuar vendimin, duke shmangur vonesat e panevojshme që mund të çojnë në paralizë të analizës dhe të pengojnë përparimin e ekipit. 
 Një tjetër anti-model mund të lindë kur vendimet arkitekturore harrohen, nuk dokumentohen ose nuk kuptohen, duke çuar në diskutime të përsëritura pa zgjidhje. Kjo ndodh shpesh kur email-i përdoret për të komunikuar vendimet arkitekturore. Për t'iu përgjigjur këtyre sfidave, arkitektët zakonisht ofrojnë justifikime si teknike ashtu edhe biznesi (shpesh të lidhura me koston, kënaqësinë e përdoruesit dhe kohën për të dalë në treg) në një regjistër të vetëm të vendimit arkitekturor (zakonisht një Regjistrim Vendimi Arkitekturor). Ky regjistër mund të mbahet në një depo të qasshme, siç është një wiki. Komunikimi përmes email-it përqendrohet në natyrën dhe kontekstin e ndryshimit dhe drejtohet vetëm tek palët e interesuara përkatëse, me një lidhje me regjistrin e qendrës. Kjo siguron që gjithmonë të ketë një burim të vetëm të përditësuar së vërtetës. Përveç kësaj, nëse një vendim arkitekturor nuk ofron vlerë të prekshme biznesi, ose nëse vlera e biznesit nuk është në përputhje me palët e interesuara të biznesit, mund të duhet të rishqyrtohet.
 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ë.

 Historia 
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 të dhënave te duhura, 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ë së softuerit që nga mesi i viteve 1980. Përpjekjet e hershme për të kapur dhe shpjeguar arkitekturën e një sistemi ishin të paqarta dhe të ç’organizuara, shpesh karakterizuar nga një grup diagramesh kutish dhe vijash. 

Koncepti i arkitekturës së softuerit ka origjinën e tij në hulumtimet e Edsger Dijkstra-s në vitin 1968 dhe David Parnas-it 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 që u fokusuan në stile arkitekturore (modele), gjuhë përshkrimi të arkitekturës, dokumentim arkitekturor dhe metoda formale. 

Institucionet kërkimore kanë luajtur një rol të rëndësishë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ë vitin 2007 nga ISO si ISO/IEC 42010:2007. Në nëntor të vitit 2011, IEEE 1471–2000 u zëvendësua nga ISO/IEC/IEEE 42010:2011, "Inxhinieri e sistemeve dhe softuerit – Përshkrimi i arkitekturës" (botuar 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ë dizajnin, ndërtimin, vendosjen dhe evoluimin e sistemit si një tërësi", edicioni i vitit 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 mes 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 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 gjatë kohës së zhvillimit, si mirëmbajtshmëria dhe transferueshmëria, të përcaktuara në standardin ISO 25010:2011
 koha e zhvillimit të kërkesave jofunksionale si mirëmbajtja dhe transferueshmëria e përcaktuar 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 
parapamje|264x264px| 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 shikimit specifikon 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ë projektimit 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
 Broker pattern
 Klient-server (2-tier, 3-tier, n-tier, kompjuterizimi në re paraqet këtë stil)
 Baza e komponentëve
 Data-centric
 Ngjarje të drejtuara (ose thirrje implicite)
 Modeli  interpreter
 Arkitektura e shtresuar (ose shumë-shtresore)
 Master-slave
 Arkitektura e Mikroshërbimeve
 Modeli-pamje-kontrollues 
 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 
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 

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 "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.

 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ë.

== Referime ==

 Leximi i mëtejshëm 


  - This book covers the fundamental concepts of the discipline. The theme is centered on achieving quality attributes of a system.
  - 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.




  - On the distinction between architectural design and detailed design.



 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

Kategoria:Arkitekturë softueri