Software arkitektura

**Softwarearen arkitektura** Softwarearen Sistemaren funtsezko egitura eta hauek sortzeko erabiltzen diren diziplinen multzoa da. Software elementuak, hauen arteko erlazioak eta  bi hauen ezaugarriak, egitura bakoitzaren menpekoak dira. Software sistemen arkitektura metafora bat da, eraikinen arkitekturarekin duen antzekotasunarengatik. Garatutako proiektuentzat eta sistemarentzat plano moduko bat da, eginbeharrak, diseinatutako moduan egin daitezen.

Proiektuetan, behin eginik, aldatzeak kostu handia edukiko luketen erabakiak hartzean datza software arkitektura. Erabaki hauek, softwarearen diseinuaren hainbat egitura aukera barne ditzake. Adibidez, transbordadore espazial batean jaurtiketa kontrolatzeko sistemek, azkartasuna eta fidagarritasuna bermatu beharko dute. Beraz, denbora errealeko konputazio lengoaia egokia aukeratu beharko litzateke. Gainera, fidagarritasuna bermatu dezan, hartutako erabakiak hainbat kopia erredundante eta berain artean independenteki eginak izatea egin dezakegu. Gero, kopia hauek, hardware ezberdinetan exekutatzen jarri beraien emaitzak modu gurutzatuan kontrolatuz. 

Software arkitektura dokumentatuz, interes-taldeen arteko komunikazioa errazteaz gain, goi-mailako egiturari buruzko hasierako erabakiak jasotzen dira. Gainera, hainbat proiekturen artean, diseinu atazen berrerabilera ere ahalbidetzen dute.

## Irismena 
Software-arkitekturari buruzko iritziak bere irismenaren arabera doaz:

* **Egituraren sistema makroskopikoa**: Arkitektura, goi-mailako software abstrakzioa da, non hainbat atal konputazionalen sorta, konektore batzuen bitartez beraien artean loturik daude.
* **Garrantzizko gauza**: Honen esanahia, software arkitektoek kezkatu beharrekoa, eragin handiko erabakietan eta interes-taldeetan dela.
* **Ingurune horretan ezinbestekoa dela ulertzea**
* **Aldatzeko zailtzat deritzona**: Arkitekturaren diseinua softwarearen bizi-zikloaren hasieran egiten denez, arkitektoak, hasiera batean egin beharreko erabakietan arduratu beharko litzateke. Pentsaera hau jarraituz, arkitektura diseinuan zehar eduki daitezken arazoak gainditzen joanez gero, arkitekturatik kanpokoak bilakatu daitezke.
* **Arkitekturaren diseinuari buruzko erabaki sorta**: Software arkitektura ez litzateke soilik egitura eta modeloen sorta bat bezala uste beharko. Hauek erabiltzeko erabakiak eta erabaki hauek hartzeko arrazoiak ere kontuan hartu beharko litzateke. Zorroztasun honek, software arkitekturaren jakituriaren kudeaketaren ikerketara eraman gaitu.

Diseinua eta beharren ingeniaritzaren eta software arkitekturaren artean ez dago hainbesteko ezberdintasunik. Guztiak, “intentzioaren-katearen” barnekoak dira, goi-mailako intentzioetatik behe-mailako xehetasunetara doana.

## Ezaugarriak 
Software arkitekturak honako hauek erakusten ditu:

**Hainbateko interes-taldeak:** Software sistemek hainbat interes-talde ase behar dituzten, adibidez, negozio zuzendaria, jabeak, erabiltzaileak eta operatzaileak. Interes-talde hauek guztiek beraien ardurak dituzte sistemarekiko. Ardura hauek orekatzea eta kontuan harturik daudela frogatzea sistemaren diseinuan zati bat da. Honegatik, arkitekturak, ardura eta interes-talde askorekin tratatu beharko du.

**Arduren bereiztea**: Konplexutasuna murrizteko, ardurak banatzen dira. Arkitekturaren dokumentazioak erakutsiko du interes-talde guztien ardurak kontuan harturik daudela, honetarako, arkitektura hainbat ikuspuntutatik modelatuta eta deskribatuta egongo da. Deskripzio ezberdin hauei egiturazko ikuspuntu deritzo (adibidetzat, 4+1 egiturazko ikuspuntu).

**Kalitateak gidatua**: Software diseinu klasikoko irismenak, funtzionalitate betebeharrek eta sistemaren datuen fluxuak gidatua izango da. Baina esan beharra da gaur egungo zorroztasuna, software arkitektura bere kalitate atributuei erlazionatuta dagoela. Interes-taldeen ardurak askotan betebehar bilakatzen dira honako kalitate atributu hauetan, non honela deritze: funtzionalitate betebeharrak, funtzionalitate estrako betebeharrak, portaera betebeharrak edo kalitate atributuen betebeharrak.

**Errepikatzen diren estiloak**: Eraikinen arkitekturan bezala, software arkitektura diziplinak, errepikatzen diren estiloak sortzeko modu estandarrak eraiki ditu. Modu estandar hauek izen askorekin eta abstrakzio maila ezberdinekin deritzo. Normalean erabiltzen diren terminoak hauek dira: Arkitektura estiloa, taktika, arkitektura erreferentzia eta diseinu arkitektonikoa.

**Integritate kontzeptuala**: Termino hau Fred Brooksek sortu zuen “The Mythical Man-Month”-en, software sistemen arkitekturak, guztiak zer egin behar zuen eta nola egin behar zen adierazten zuen ikuspuntua adierazten zuena. Ikuspuntu hau, inplementaziotik banatu beharko litzateke. Arkitektoak “ikuspuntuaren zaindari” rola hartzen du, egiten diren gehiketa guztiak arkitekturaren lerroan doazela finkatuz.

**Muga kognitiboa**: Behaketa hau 1967. urtean egin zen lehen aldiz, Melvin Conway programatzailearen eskutik. Beraien sistema diseinua komunikazio estrukturen kopiak egitera mugatuta dauden organizazioak. Kontzeptu hau, publiko handiago bati ezagutzera eman zuen Freed Brooksek, artikulua eta ideiak bere “The Mythical Man-Month”-en adierazi zituenean “Conway´s Law” izenarekin.

## Motibazioa 
Software arkitektura, sistema konplexu baten abstrakzio “intelektualki ulergarria” da. Abstrakzio honek hainbat abantaila ditu:

* Software sistemen portaeraren oinarrizko analisia ematen digu sistema eraiki aurretik. Interes-taldeen beharrak egiaztatzeko eta asetzeko gaitasuna du oraindik kostu handiko aldaketarik egin aurretik. Analisi hau emateko hainbat teknika sortu dira, adibidez ATAM edo software sistemen eredu ikusgarriak eginez.

* Berrerabilgarriak diren hainbat elementu eta erabaki sortzen ditu. Software arkitektura osoa edo honen zati batzuk berriz erabili daitezke hainbat sistemetan non interes-taldeen beharrak antzekoak diren. Honekin, kostuetan eta diseinu arriskuetan laguntzen du.

* Diseinuaren hasierako erabakietan laguntzen du, eragin handiko erabaki hauetan garrantzitsua izaten baita estruktura eta aurrekontuen zanpatzea.

* Interes-taldeekin komunikazioan laguntzen du, hauen beharra hobeto ase daitezen. Interes-taldeen ikuspuntutik sistema konplexuei buruz komunikatzean, beharren ondorioak hobeto ulertzen laguntzen die.

* Arriskuen kudeaketan laguntzen du, porrot egiteko aukera murriztuz.

* Kostuak kudeatuz, hauek murriztea lortzen da proiektuetan.

## Historia 
Software diseinuaren eta arkitekturaren arteko konparazio 1960. hamarkadaren amaieran hasi zen erabiltzen, baina hitzaren gaur egungo zabalkuntza ez zen hasi 1990. hamarkada arte. Konputazio zientziak arazoak izan zituen konplexutasunak erlazionatzen. Konplexutasunaren arazo gehienak garatzaileek konpondu zituzten datu-egitura egokiak aukeratuz, algoritmoak sortuz eta arduren bereiztea kontzeptua aplikatuz. “Software arkitektura” terminoa industriarako nahiko berria izan arren, funtsezko oinarriak esporadikoki aplikatuak izan dira software ingeniaritzan 1980. hamarkadaren erdialdetik aurrera. Hasieran software arkitekturari buruz eginiko azalpenak zehaztugabeak eta ordenarik gabekoak ziren, gehienetan, kutxa eta lerrorekin diagrametan bereiziz.

Software arkitektura kontzeptua, Edsger Dijkstrak 1968 urtean eta David Parnasek 1970. hamarkadan sortu zuten. Zientzialari hauek, softwarearen egiturak garrantzia duela eta egitura egokia kritikoa dela nabarmendu zuten. 1990. hamarkadan, diziplinen alderdi funtsezkoak definitzeko eta kodetzeko nahia zegoen, honetarako, arkitektura estiloen ikerketetan kontzentratuz (diseinuak, arkitektura deskribatzeko lengoaiak, arkitektura dokumentazioan eta metodo formaletan).

Ikerketa instituzioek paper nabaria izan zuten software arkitektura diziplinatzat hedatzen. “Carnegie Mellon”-eko Mary Shawk eta David Garlanek liburu bat idatzi zuten “Software Architecture: Perspectives on an Emerging Discipline” izenarekin 1996. urtean. Liburu honek, software arkitektura kontzeptu askorekin sustatu zuten, adibidez, osagaiekin, konektoreekin eta estiloekin. “University of California, Invine’s” intituko softwarearen ikerkuntzan lan egiten duen zatiak, arkitekturaren estiloan, arkitekturaren lengoaien deskripzioan eta arkitekturen dinamiketan sustapenak egin zituen.

Software arkitekturaren lehenengo estandarra IEEE 1471-2000 “Recommended Practice for Architecture Description of Software-Intensive Systems” izan zen. 2007. urtean ISO-k (ISO/IEC 42010:2007) hartua izan zen. 2011. urteko azaroan, IEEE 1471-2000 , ISO/IEC/IEEE 42010:2011-taz ordeztua izan zen.

IEEE 1471 estandarrean arkitektura “software-trinkoko sistematzat” hartzen zen, “softwareak garrantzizko atalen bat betetzen zuen edozein sistema” bezala deritzola. Bestalde, 2011. urteko edizioak, ISO/IEC 15288 eta ISO/IEC 12207 definizioak gehitzen zituzten sistemara, non softwarea eta hardwarea kontuan hartzeaz gain, pertsonak, prozesuak, prozedurak, erraztasunak, material eta entitateak kontuan hartzen ziren. Honek, software-arkitekturaren, enpresen arkitekturaren eta soluzioen arkitekturaren arteko erlazioa islatzen zuen.

## Arkitektura jarduerak 
Hainbat jarduera ezberdin daude software arkitekturak egin ditzazkenak. Software arkitekto batek, normalean proiektu zuzendari batekin egiten du lan, arkitekturaren betebehar garrantzitsuei buruz hitz egiten interes-taldeekin, softwarearen arkitektura diseinatzen, diseinua ebaluatzen, diseinatzaileekin hitz egiten, arkitektura diseinuak dokumentatzen eta gehiago. Lau jarduera garrantzitsu daude software arkitekturarekin diseinuan. Jarduera hauek, softwarearen sorkuntzaren bizi-zikoaren hasieran, iteratiboki eta fase ezberdinetan egiten dira.

**Arkitekturaren analisia**, sistemaren ingurunearen ulermenean zentratzen da. Egongo diren betebeharrak hainbat interes-taldeetatik etor daitezke eta honako hauek eduki ditzake:

* Sistemak erabileran dagoenean zer egingo duen (behar funtzionalak)

* Sistemak zer moduz moldatuko zen exekuzio ez funtzional beharrekin, adibidez, fidagarritasuna, mantenua, errendimenduaren eraginkortasuna, segurtasuna edo ISO/IEC 25010:2011 estandarraren bateragarritasuna.

* Garatze-denbora , behar ez funtzionalekin, adibidez, mantenua eta transferentzia, ISO 25010:2011 estandarrean zehaztu bezala.

* Negozio beharren eta ingurunearen testuingurua aldatzen joan daiteke legez, sozialki, ekonomikoki, lehiakortasunez eta teknologikoki.

**Sintesi arkitekturala** edo diseinua, arkitekturaren prozesuen sorkuntza da. Analisiaren bidez zehaztuta eta diseinuaren momentuan testuingurua kontuan harturik, diseinua sortu eta hobetzen da.

**Arkitekturaren ebaluazioa**, momentuan diseinuak beharrak ongi asetzen dituen begiratzean eta hobetu ahal daitekeen begiratzean datza. Ebaluazio bat, arkitekto batek diseinu erabaki bat egin behar denean egiten da. Hau, diseinuaren zati bat amaituta dagoelarik ere gerta daiteke.

**Arkitekturaren eboluzioa**, sorturik dagoen software arkitektura baten mantenuan eta moldaketan zentratzen da. Software arkitekturak funtsezko egitura sortzen doan bezala, honen eboluzioak eta mantenuak funtsezko egitura bere eragina izango du.

### Arkitekturan laguntzen duten jarduerak 
Laguntzen duten jarduerak hauek software arkitekturaren analisian, sintesian, ebaluazioan eta eboluzioan laguntzen dute. Adibidez, arkitekto batek, jakituria lortu behar du, erabakiak hartu eta analisi garaian dokumentatu.

**Jakituriaren kudeaketa eta komunikazioa**, ezinbestekoa da software arkitekturaren diseinuan. Software arkitekto batek ez du isolatuta egingo lanik. Ekarpenak, behar funtzional eta ez funtzionalak, diseinua testuinguruak jasotzen ditu hainbat interes-taldeen aldetik eta honek soluzioak emango ditu. Adibide bezala, jakituriaren kudeaketan eta komunikazioan egin ditzakegun jarduerak honako hauek izan daitezke: diseinu ereduen bilaketa, prototipoen sorkuntza, esperientzia gehiagoko garatzaileei eta arkitektoei galdetzea, berdintsuak izan daitezken sistemen diseinuen ebaluazioa, beste garatzaileekin eta interes-taldeekin informazio trukea eta wikietan esperientzia dokumentatzea.

**Erabakiak hartzea eta diseinuen arrazoitzea**. Jarduera hau ezinbestekoa da software arkitekturako funtsezko hiru jarduerentzat. Hau honi deritzo: erabakien testuinguruak erlazionatu, diseinuen erabakien arazoak formulatzea, soluzioen aukerak aurkitzea eta ordainen ebaluazioa egitea erabakiak hartu aurretik. Prozesu hauek hainbat maila ezberdinetan eman daitezke bere ebaluabidearen arabera. Adibideak hauek izan lirateke: Kalitate atributuen beharrek duten eraginak ulertzea, software arkitekturaren analisia, sintesia eta ebaluazioa, diseinuak izan ditzaken arazoak pentsatzea, soluzio posibleak neurtzea eta soluzioen arteko trukea ebaluatzea.

**Dokumentatzea**, softwarea arkitekturaren prozesuek sortzen dituzten diseinuen gordekinak sortzean datza. Sistemen diseinua, hainbat ikuspuntu kontuan harturik egiten dira. Honen adibideak honako hauek izango dira: Zehaztapenak idaztea, modeloen gordekinak lortzea, diseinuen logika dokumentatzea, ikuspuntuak sortzea eta ikuspuntu horiek dokumentatzea.

## Topikoak 
**Software arkitekturaren deskripzioa**

Arkitekturaren modelatzearen eta errepresentazioaren printzipioak eta praktikak dira. Arkitektura deskribatzeko lengoaiak, arkitektura ikuspuntuak eta arkitektura-frameworkak moduko mekanismoak erabiltzen dira honetarako.

**Arkitektura deskribatzeko lengoaiak**

Lengoai hauek (ADL: Architecture description language), software arkitektura (ISO/IEC/IEEE 42010) deskribatzeko erabiltzen diren adierazpenak dira. Hainbat ADL sortu dira 1990. hamarkadatik aurrera: AADL (SAE estandarra), Wright (Carnegie Mellonek garatua), Acme (Carmegie Mellonek garatua), xADL (UCIk garatua), Darwin (Imperial College Londonek garatua), DAOP-ADL (Malagako unibertsitateak garatua), SBC-ADL (National Sun Yat-Sen Unibersityk garatua) eta ByADL (University of L’Aquila, Italia).

**Arkitektura ikuspuntuak**

Software arkitekturaren deskripzioak normalean ikuspuntuekin organizatuta egoten dira. Hauek, arkitektura konbentzionalaren proiektuen (blueprints) analogoak dira. Ikuspuntu bakoitzak sistemaren beharren bat asetzen du.

**Arkitektura lan inguruneak (framework)**

Arkitekturako lan ingurune batek, arau, printzipio eta praktiken deskripzio arkitekturak erabakitzen ditu. Lan ingurune hauek, normalean, ikuspuntu edo ADL baten edo gehiagoren gainean eginik egoten dira.

**Arkitekturaren estiloak eta ereduak**

Arkitekturan, arazo komun baten soluzio berrerabilgarriei ereduak deritzo. Eredu hauek, normalean, diseinu eredu moduan egongo dira dokumentaturik.

Arkitekturaren hainbat eredu eta estilo daude ezagunak direnak, adibidez:

* Blackboard | Arbela
* Client-server | Bezero-zerbitzari
* Component-based | Piezetan oinarriturik
* Data-centric | Datuetan zentraturik
* Event-driven | Gertaerek eraginda
* Layered | Geruzatan banatua
* Microservices arkitekture | Zerbitzu txikien arkitektura
* Monolithic application | Aplikazio monolitikoa
* Peer-to-peer (P2P) | Parekotik parekora
* Pipes and filters  | Hodiak eta iragazkiak
* Plug-ins | Entxufeak
* Reactive architecture | Arkitektura erreaktiboa
* Representational state transfer (REST) | Egoeraren transferentzia adierazgarria
* Rule-based | Arauetan oinarriturikoa
* Service-orientated | Zerbitzuetara orientatuta
* Shared nothing | Ezer ez trukatuz
* Space-based architecture | Espazioan oinarrituriko arkitektura

**Software arkitektura eta garapen bizkorra**

Hainbat metodo sortu dira garapenaren diseinuaren eta bizkortasunaren arteko ordainak orekan egon daitezen.

**Software arkitekturaren erosioa**

Software-arkitekturaren erosioa edo erorketa, software arkitekturan, momentuan arkitekturaren eta planifikaturiko arkitekturaren arteko tarteari deritzo. Software arkitekturaren erosioa, inplementazio erabakiak ez dutenean guztiz hasierako plana betetzen gertatzen da.

**Software arkitektura berreskuratzea**

Software arkitekturaren berreskuratzea, berregitea edo alderantzizko ingeniaritza deritzona. Hainbat metodo teknika eta prozesuek, software sistema bat, eskura duen informaziotik urruntzen du.

## Erlazionatutako eremuak 
**Diseinua**

Arkitektura diseinua da baino diseinu guztiak ez dira arkitektura. Praktikan, arkitektura da lerroak marrazten dituena software arkitekturaren eta xehetasunen diseinutik. Ez dago gida araurik kasu guztiak ongi bat etorriko duten dioenik, baina ahalegin asko egon dira ezberdintasun hau formalizatzeko.  

**Beharren ingeniaritza**

Software arkitektura eta beharren ingeniaritza osagarriak direla esan daiteke beraien artean. Software arkitekturak “nola” pentsatzen duen bitartean, beharren ingeniaritzak “zer” planteatzen du.

**Beste arkitektura mota batzuk:**

* Konputazio arkitektura
* Sistemen arkitektura
* Enpresen arkitektura

## Erreferentziak 
## Kanpo estekak