Software arkitektura

Wikipedia, Entziklopedia askea

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.[1] Software sistemen arkitektura metafora bat da, eraikinen arkitekturarekin[2] duen antzekotasunarengatik. Garatutako proiektuentzat eta sistemarentzat plano moduko bat da, eginbeharrak, diseinatutako moduan egin daitezen.[3]

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.[4]

Irismena[aldatu | aldatu iturburu kodea]

Software-arkitekturari buruzko iritziak bere irismenaren arabera doaz:[5]

  • Egituraren sistema makroskopikoa: Arkitektura, goi-mailako software abstrakzioa da, non hainbat atal konputazionalen sorta, konektore batzuen bitartez beraien artean loturik daude.[6]
  • Garrantzizko gauza: Honen esanahia, software arkitektoek kezkatu beharrekoa, eragin handiko erabakietan eta interes-taldeetan dela.[7]
  • Ingurune horretan ezinbestekoa dela ulertzea[8]
  • 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.[9] Zorroztasun honek, software arkitekturaren jakituriaren kudeaketaren ikerketara eraman gaitu.[10]

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

Ezaugarriak[aldatu | aldatu iturburu kodea]

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.[12] 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[13][14] 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[aldatu | aldatu iturburu kodea]

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.[15] 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.[16]

Historia[aldatu | aldatu iturburu kodea]

Software diseinuaren eta arkitekturaren arteko konparazio 1960.[17] hamarkadaren amaieran hasi zen erabiltzen, baina hitzaren gaur egungo zabalkuntza ez zen hasi 1990.[18] hamarkada arte. Konputazio zientziak arazoak izan zituen konplexutasunak erlazionatzen.[19] 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.[20]

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[aldatu | aldatu iturburu kodea]

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[aldatu | aldatu iturburu kodea]

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[aldatu | aldatu iturburu kodea]

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:

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[aldatu | aldatu iturburu kodea]

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:

Erreferentziak[aldatu | aldatu iturburu kodea]

  1. ↑ Clements, Paul; Felix Bachmann; Len Bass; David Garlan; James Ivers; Reed Little; Paulo Merson; Robert Nord et al.. (2010). Documenting Software Architectures: Views and Beyond, Second Edition. Boston ISBN 978-0-321-55268-6..
  2. ↑ Perry, D. E.; Wolf, A. L.. (1992). «Foundations for the study of software architecture» ACM SIGSOFT Software Engineering Notes 17 (4): 40.  doi:10.1145/141874.141884..
  3. ↑ (Ingelesez) Software Architecture. .
  4. ↑ Bass, Len; Paul Clements; Rick Kazman. (2012). Software Architecture in Practice, Third Edition. Boston: Addison-Wesley ISBN 978-0-321-81573-6..
  5. ↑ SEI. (2006). How do you define Software Architecture?. .
  6. ↑ Garlan & Shaw. (1994). An Introduction to Software Architecture. .
  7. ↑ Fowler, Martin. (2003). «Design – Who needs an architect?» IEEE Software 20 (5): 11–44.  doi:10.1109/MS.2003.1231144..
  8. ↑ ISO/IEC/IEEE 42010: Defining "architecture". Iso-architecture.org. Retrieved on 2013-07-21.
  9. ↑ Jansen, A.; Bosch, J.. (2005). «Software Architecture as a Set of Architectural Design Decisions» 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05). , 109 or.  doi:10.1109/WICSA.2005.61. ISBN 978-0-7695-2548-8..
  10. ↑ Ali Babar, Muhammad; Dingsoyr, Torgeir; Lago, Patricia; van Vliet, Hans. (2009). Software Architecture Knowledge Management. Dordrecht Heidelberg London New York: Springer ISBN 978-3-642-02373-6..
  11. ↑ George Fairbanks. (2010). Marshall & Brainerd.
  12. ↑ ISO/IEC/IEEE. (2011). ISO/IEC/IEEE 42010:2011 Systems and software engineering – Architecture description. .
  13. ↑ Muller, Gerrit. (August 20, 2007). A Reference Architecture Primer. .
  14. ↑ Angelov, Samuil; Grefen, Paul; Greefhorst, Danny. (2009). «A Classification of Software Reference Architectures: Analyzing Their Success and Effectiveness» Proc. Of WICSA/ECSA 2009: 141–150.  doi:10.1109/WICSA.2009.5290800. ISBN 978-1-4244-4984-2..
  15. ↑ Kruchten, H.. (Feb 6, 2002)..
  16. ↑ Poort, Eltjo; van Vliet, Hans. (September 2012). Journal of Systems and Software 85 (9): 1995–2013.  doi:10.1016/j.jss.2012.03.071..
  17. ↑ Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7–11 Oct. 1968. Brussels: NATO, Scientific Affairs Division.
  18. ↑ P. Kruchten; H. Obbink; J. Stafford. (2006). «The past, present and future of software architecture» IEEE Software 23 (2): 22.  doi:10.1109/MS.2006.59..
  19. ↑ University of Waterloo. (2006)..
  20. ↑ IEEE Transactions on Software Engineering. (2006). Introduction to the Special Issue on Software Architecture.  doi:10.1109/TSE.1995.10003..

Kanpo estekak[aldatu | aldatu iturburu kodea]

"https://eu.wikipedia.org/w/index.php?title=Software_arkitektura&oldid=9553784"(e)tik eskuratuta