Programų sistemų architektūra ir projektavimas

EUROPOS SĄJUNGA Europos socialinis fondas KURKIME ATEITĮ DRAUGE! Saulius Maskeliūnas Programų sistemų architektūra ir projektavimas Mokymo medžiaga Vilnius 2007

Mokymo medžiaga parengta vykdant projektą Programų sistemų magistrantūros įsteigimas, įgyvendinantį 2004-2006 metų bendrojo programavimo dokumento 2.5 priemonę Žmogiškųjų išteklių kokybės gerinimas mokslinių tyrimų ir inovacijų srityje, finansuojamą Europos Sąjungos struktūrinių fondų lėšomis ir Lietuvos Respublikos bendrojo finansavimo lėšomis. 2

1. ĮVADAS...7 1.1. PROJEKTAVIMO VIETA PROGRAMŲ SISTEMŲ GYVAVIMO CIKLE...7 I DALIS ARCHITEKTŪRINIO PROJEKTAVIMO PAGRINDAI...9 2. PROGRAMŲ SISTEMOS ARCHITEKTŪROS SĄVOKOS...10 2.1. PROGRAMŲ SISTEMOS ARCHITEKTŪRA...10 2.2. PROGRAMŲ SISTEMOS STRUKTŪROS IR VAIZDAI...11 2.2.1. Statinės struktūros...13 2.2.2. Dinaminės struktūros...17 2.3. IŠORIŠKAI MATOMOS SISTEMOS SAVYBĖS...22 2.4. IŠORINĖS SAVYBĖS IR SISTEMOS VIDINĖ STRUKTŪRA...23 2.5. PROGRAMŲ SISTEMOS ARCHITEKTŪROS SVARBA...26 2.6. ARCHITEKTŪRINIAI ELEMENTAI...26 2.7. SUINTERESUOTI ASMENYS...27 2.7.1. Žmonės, grupės ir organizacijos...28 2.7.2. Interesai...28 2.7.3. Suinteresuotų asmenų svarba...29 2.8. ARCHITEKTŪROS APRAŠAS...30 2.9. RYŠIAI TARP ESMINIŲ SĄVOKŲ...31 3. POŽIŪRIAI IR VAIZDAI...32 3.1. ARCHITEKTŪRINIAI VAIZDAI...33 3.2. POŽIŪRIAI...34 3.3. ESMINIŲ SĄVOKŲ TARPUSAVIO RYŠIAI...35 3.4. VAIZDŲ IR POŽIŪRIŲ NAUDA...36 3.5. POŽIŪRIŲ KATALOGAS...37 4. ARCHITEKTŪRINĖS PERSPEKTYVOS...39 4.1. PERSPEKTYVOS...40 4.2. PERSPEKTYVŲ PRITAIKYMAS VAIZDAMS...41 4.3. ESMINIŲ SĄVOKŲ TARPUSAVIO RYŠIAI...44 4.4. PERSPEKTYVŲ KATALOGAS...45 5. ARCHITEKTO VAIDMUO...46 5.1. ARCHITEKTŪROS KŪRIMO PROCESAS...46 5.1.1. Architektūros kūrimas nėra vien tik projektavimas...47 5.1.2. Riba tarp reikalavimų analizės ir architektūros kūrimo...48 5.1.3. Riba tarp architektūros kūrimo ir projektavimo...49 5.2. ARCHITEKTO ROLĖ...50 5.3. SĄVOKŲ TARPUSAVIO RYŠIAI...52 5.4. ARCHITEKTŲ PROFESINĖ SPECIALIZACIJA...53 5.4.1. Architektūriniai stiliai...53 5.4.2. Pavyzdiniai modeliai...54 5.4.3. Pavyzdinės architektūros...55 5.4.4. Apibendrinimas...56 5.4.5. Taikomoji architektūra...57 5.4.6. Dalykinė architektūra...58 5.4.7. Apibendrinimas...58 5.4.8. Organizacijos architektūra...60 5.4.9. Architektų profesinė specializacija...61 5.5. KITOS ROLĖS PROGRAMŲ SISTEMOS KŪRIMO PROJEKTE...62 5.5.1. Verslo analitikas...62 5.5.2. Projekto vadovas...62 5.5.3. Techninis vadovas...62 3

5.5.4. Technologijų specialistas...63 5.5.5. Architekto ryšys su kitomis rolėmis...64 5.6. ARCHITEKTUI REIKALINGI ĮGŪDŽIAI...64 5.7. ARCHITEKTO ATSAKOMYBĖS...64 II DALIS ARCHITEKTŪROS KŪRIMO PROCESAS...66 6. ĮVADAS...67 7. ARCHITEKTŪROS KŪRIMO PROCESAS...68 7.1. PAGRINDINIAI PRINCIPAI...68 7.2. PROCESO DARBO PRODUKTAI...69 7.3. PROCESO KONTEKSTAS...70 7.4. PAGALBINĖS VEIKLOS...71 7.5. ARCHITEKTŪROS KŪRIMO VEIKLOS...75 7.6. PROCESO SĖKMINGOS PABAIGOS SĄLYGOS...81 7.7. ARCHITEKTŪROS KŪRIMAS PROGRAMŲ SISTEMŲ GYVAVIMO CIKLO KONTEKSTE...83 7.7.1. Krioklio modelio metodai...83 7.7.2. Iteratyvūs metodai...84 7.7.3. Judrūs metodai...84 8. APIMTIS, INTERESAI, PRINCIPAI IR RIBOJIMAI...86 8.1. VERSLO TIKSLAI IR VAROMOSIOS JĖGOS...87 8.2. ARCHITEKTŪROS APIMTIS...88 8.2.1. Kas yra geras apimties apibrėžimas...88 8.2.2. Konteksto diagrama...89 8.3. ARCHITEKTŪRINIAI INTERESAI...90 8.3.1. Architektūriniai tikslai...91 8.3.2. Funkciniai reikalavimai...92 8.3.3. Architektūriniai reikalavimai...92 8.3.4. Kas yra geras interesas...93 8.4. ARCHITEKTŪRINIAI PRINCIPAI...94 8.4.1. Kas yra geras principas...95 8.4.2. Principų naudojimas pademonstruoti trasuojamumą...96 8.5. KITI ARCHITEKTŪRINIAI RIBOJIMAI...98 8.5.1. Standartai...98 8.5.2. Organizacijos strategijos...99 8.5.3. Organizacijos politikos...99 8.6. KLAUSIMŲ SĄRAŠAS PASITIKRINIMUI...100 9. SUINTERESUOTŲ ASMENŲ IDENTIFIKAVIMAS IR ĮTRAUKIMAS...101 9.1. SUINTERESUOTŲ ASMENŲ PARINKIMAS...101 9.2. SUINTERESUOTŲ ASMENŲ KLASIFIKACIJA...102 9.2.1. Užsakovai...104 9.2.2. Vertintojai...104 9.2.3. Instruktuojantis ir konsultuojantis personalas...104 9.2.4. Kūrėjai...105 9.2.5. Prižiūrėtojai...105 9.2.6. Tiekėjai...105 9.2.7. Palaikymo personalas...105 9.2.8. Sistemos administratoriai...105 9.2.9. Testuotojai...106 9.2.10. Vartotojai...106 9.3. TARPINIAI SUINTERESUOTI ASMENYS...106 9.4. SUINTERESUOTŲ ASMENŲ ATSAKOMYBĖS...106 4

9.5. KLAUSIMŲ SĄRAŠAS PASITIKRINIMUI...107 10. SCENARIJAI...108 10.1. SCENARIJŲ TIPAI...109 10.2. SCENARIJŲ NAUDOJIMO BŪDAI...109 10.3. SCENARIJŲ IDENTIFIKAVIMAS IR PRIORITETŲ JIEMS SUTEIKIMAS...110 10.4. SCENARIJŲ SUDARYMAS...111 10.4.1. Funkcinių scenarijų sudarymas...111 10.4.2. Sistemos kokybės scenarijų sudarymas...112 10.5. SCENARIJŲ PANAUDOJIMAS...114 10.5.1. Eskiziniai modeliai...114 10.5.2. Scenarijaus pažingsninis vykdymas...115 10.5.3. Imitaciniai modeliai...115 10.5.4. Prototipo kūrimas...116 10.5.5. Programų sistemos testavimas...116 10.5.6. Apibendrinimas...116 10.6. KLAUSIMŲ SĄRAŠAS PASITIKRINIMUI...117 11. ARCHITEKTŪRINIAI STILIAI IR KITI TIPINIAI SPRENDIMAI...118 11.1. TIPINIAI SPRENDIMAI...118 11.2. TIPINIŲ SPRENDIMŲ KLASIFIKACIJA...121 11.2.1. Architektūriniai stiliai...121 11.2.2. Tipiniai projektavimo sprendimai...121 11.2.3. Programavimo kalbų idiomos...122 11.2.4. Apibendrinimas...123 11.2.5. Tipiniai projektavimo sprendimai ir idiomos architektūroje...124 11.3. DAŽNIAUSIAI PASITAIKANTYS ARCHITEKTŪRINIAI STILIAI...124 11.3.1. Vamzdžių ir filtrų stilius...124 11.3.2. Kliento-serverio stilius...126 11.3.3. Daugelio lygmenų stilius...126 11.3.4. Lygiaverčių narių stilius...127 11.3.5. Sluoksnių stilius...127 11.3.6. Publikavimo/prenumeratos stilius...128 11.3.7. Modelio-vaizdo-kontrolerio stilius...129 11.3.8. Brokerio stilius...132 11.4. ARCHITEKTŪRINIŲ STILIŲ HIERARCHIJA...134 11.5. ARCHITEKTŪRINIAI STILIAI IR ARCHITEKTŪROS APRAŠAS...135 11.6. KLAUSIMŲ SĄRAŠAS PASITIKRINIMUI...136 12. ARCHITEKTŪRINIŲ MODELIŲ KŪRIMAS...137 12.1. KODĖL MODELIAI YRA SVARBŪS...138 12.2. MODELIŲ TIPAI...140 12.2.1. Kokybiniai modeliai...140 12.2.2. Kiekybiniai modeliai...141 12.2.3. Eskizai...142 12.3. MODELIAVIMO KALBOS...142 12.3.1. Architektūros aprašymo kalbos...142 12.3.2. UML kalba...142 12.3.3. Kitos modeliavimo kalbos...143 12.4. EFEKTYVIŲ MODELIŲ KŪRIMO PATARIMAI...143 12.4.1. Modeliuoti tikslingai...143 12.4.2. Modeliai turi būti kuriami suinteresuotiems asmenims...144 12.4.3. Abstrahuoti atsargiai...144 12.4.4. Naudoti prasminius pavadinimus...145 5

12.4.5. Apibrėžti terminus...145 12.4.6. Siekti paprastumo...145 12.4.7. Apibrėžti naudojamą notaciją...146 12.4.8. Tikrinti modelius...146 12.4.9. Atnaujinti modelius...146 12.5. KLAUSIMŲ SĄRAŠAS PASITIKRINIMUI...147 13. ARCHITEKTŪROS APRAŠO KŪRIMAS...148 13.1. EFEKTYVAUS ARCHITEKTŪROS APRAŠO SAVYBĖS...149 13.1.1. Korektiškumas...149 13.1.2. Pakankamumas...150 13.1.3. Glaustumas...151 13.1.4. Aiškumas...152 13.1.5. Vertingumas...152 13.1.6. Tikslumas...153 13.2. TERMINŲ ŽODYNAI...154 13.3. IEEE STANDARTAS...154 13.4. ARCHITEKTŪROS APRAŠO ŠABLONAS...155 13.4.1. Dokumento atributai...156 13.4.2. Turinys...156 13.4.3. Įvadas...156 13.4.4. Apimties apibrėžimas...156 13.4.5. Reikalavimų ir interesų apžvalga...157 13.4.6. Bendri architektūriniai principai...157 13.4.7. Architektūriniai stiliai...157 13.4.8. Vaizdai...158 13.4.9. Kokybinių savybių santrauka...159 13.4.10. Svarbūs scenarijai...159 13.4.11. Priedai...159 13.5. KLAUSIMŲ SĄRAŠAS PASITIKRINIMUI...160 TERMINŲ ŽODYNAS...161 LITERATŪRA...162 6

1. Įvadas Šių dienų programų sistemos yra vienos iš sudėtingiausių kada nors žmonių sukurtų kūrinių, turinčios milijonus kodo eilučių, šimtus duomenų bazių lentelių, dešimtis ar net šimtus komponentų, kurie dažnai yra vykdomi ne vieno, o daugelio kompiuterių. Visa tai sąlygoja visą eilę netrivialių problemų, kurias turi spręsti programų sistemos įgyvendintojai. Ir jei šių problemų sprendimui nėra priimami tinkami sprendimai, sistemos yra sukuriamos vėluojant, viršijant biudžetą arba yra žemos kokybės. Vis daugiau programų sistemų kūrimo projektų vykdytojų pripažįsta programų sistemos architekto rolės, o kartais netgi architektų grupės svarbą, kurie turi spręsti technologijų pasirinkimo klausimus bei padėti likusiai komandai priimti projektinius sprendimus. 1.1. Projektavimo vieta programų sistemų gyvavimo cikle Projektavimas, kaip vienas iš programų sistemų gyvavimo ciklo procesų, standartiniame procesų sąraše (pavyzdžiui, ISO/IEC standartas nr. 12207 Software Life Cycle Processes [ISO95]) įsiterpia tarp programų sistemos reikalavimų analizės ir programų sistemos konstravimo procesų (žr. Pav. 1-1). Pav. 1-1. Projektavimo proceso vieta programų sistemų gyvavimo cikle Standartas IEEE/EIA 12207 projektavimo procesui priskiria šias veiklas: 1. Architektūrinis projektavimas: aprašo programų sistemos viršutinio lygmens (angl. toplevel) struktūrą, identifikuoja sudėtines dalis (komponentus) bei jų jungimosi taškus. 2. Detalusis projektavimas: aprašo kiekvieną komponentą pakankamai detaliai, kad būtų galima jį sukonstruoti. 7

Detalusis projektavimas ir yra tai, kas paprastai vadinama vienu žodžiu projektavimas, ko rezultate turi būti sukurta projektinė dokumentacija, pakankama programuotojui pradėti programų sistemos konstravimą. Architektūrinis projektavimas gi baigiasi programų sistemos architektūros (tiksliau, jos dokumentacijos) sukūrimu, kuri aprašo programų sistemos struktūrą, esmines jos sudėtines dalis bei jų jungimo būdus, kokybines charakteristikas, ir nusako esmines tolesnio detalaus projektavimo kryptis. Tiek detalusis projektavimas, tiek architektūrinis projektavimas patys savaime yra plačios ir sudėtingos temos, todėl šioje knygoje detaliai yra aptariama tik viena iš jų, o būtent architektūrinis projektavimas. Skaitytojas šioje knygoje yra supažindinamas su pagrindinėmis architektūros sąvokomis ir architektūros kūrimo procesu. Knyga iš esmės šneka apie informacinių sistemų architektūros kūrimą, kur informacine sistema vadiname programų sistemą (galbūt kelias sistemas), įmonės verslo procesams teikiančią informacinį aprūpinimą. Rašant šią knygą daugiausia buvo remtasi [ROZA05] šaltinio informacija. 8

I DALIS Architektūrinio projektavimo pagrindai

I DALIS ARCHITEKTŪRINIO PROJEKTAVIMO PAGRINDAI 2. Programų sistemos architektūros sąvokos Viena iš problemų, su kuria susiduriama kai kalbama apie programų sistemų architektūrą, yra nusistovėjusios terminijos stoka pasaulinėje literatūroje, jau nekalbant apie literatūrą lietuvių kalba, kur ši terminija iš viso dar nėra sukurta. Pavyzdžiui, netgi vien tik programų sistemų kontekste, terminas architektūra yra vartojamas kalbant tiek apie mikroprocesorių vidinę struktūrą, tiek apie kompiuterių vidinę struktūrą, tiek apie kompiuterinių tinklų organizavimą (tinklo architektūra), tiek apie programų sistemų struktūrą, bei daugelį kitų dalykų. Šiame skyriuje yra pamėginta apibrėžti ir apžvelgti kai kuriuos esminius terminus, kurie bus vartojami šios knygos tolimesniuose skyriuose, tokius kaip programų sistemos architektūra, architektūrinis elementas, suinteresuotas asmuo (angl. stakeholder) ir kitus. 2.1. Programų sistemos architektūra Kai bandome suprasti kaip veikia programų sistema, mes aiškinamės iš kokių dalių ji yra sudaryta, ką tos dalys daro, kaip jos dirba kartu ir kaip jos komunikuoja su išoriniu pasauliu kitaip sakant, mes bandome išsiaiškinti programų sistemos architektūrą. Paskutiniu metu plačiausiai priimtas ir cituojamas yra Len Bass, Paul Clements ir Rick Kazman knygoje Software Architecture in Practice pateiktas programų sistemos architektūros apibrėžimas [BASS03]: 1. Programų sistemos architektūra yra tos sistemos struktūra arba struktūros, kurios susideda iš architektūrinių elementų, iš išorės matomų tų elementų savybių, bei ryšių tarp tų elementų. Aptarkime kai kurias išvadas, sekančias iš šio apibrėžimo. Pirmiausia architektūra nusako architektūrinius elementus. Architektūra apima informaciją apie tai, kaip elementai susiję tarpusavyje. Tai reiškia, kad informacija, nesusijusi su šių elementų tarpusavio bendravimu, yra praleidžiama. Taigi, architektūra yra programų sistemos abstrakcija, praleidžianti tą informaciją apie elementus, kuri nesusijusi su tuo, kaip elementai yra naudojami, yra susiję ar bendrauja tarpusavyje. Praktiškai visose modernioje programų sistemose elementai bendrauja tarpusavyje per interfeisus. Pastarieji suteikia priėjimą prie elemento viešos dalies, tuo tarpu kai privačioji lieka uždara priėjimui iš išorės. Architektūrai įdomi yra tik viešoji elementų dalis; privačioji dalis, kuri yra susijusi su vidine elemento realizacija, nėra architektūrinė informacija. 10

I DALIS ARCHITEKTŪRINIO PROJEKTAVIMO PAGRINDAI Antra, apibrėžimas aiškiai sako, kad programų sistemos gali turėti (ir turi) daugiau nei vieną struktūrą, bei jokia struktūra pavieniui negali būti vadinama architektūra. Vienos struktūros nusako statinius sistemos aspektus (pvz., kaip sistemos konstravimo metu moduliai, komponentai yra susiję tarpusavyje), kitos dinaminius (pvz., kokie procesai vyksta sistemos vykdymo metu, kokia informacija jie keičiasi, kada vykdoma sinchronizacija tarp procesų ir t.t.). Kadangi struktūros neša savyje architektūrinę informaciją, jos yra programų sistemos architektūros dalis. Kita vertus, tai, kad architektūra susideda iš daugelio struktūrų, reiškia, kad yra daugiau nei vienas architektūrinių elementų tipas (pvz., moduliai, komponentai, procesai), daugiau nei vienas ryšių tarp elementų tipas (pvz., ryšiai susideda-iš, naudoja, sinchronizuojasi-su, ir t.t.), ir netgi daugiau nei vienas kontekstas (pvz., sistemos konstravimas, sistemos vykdymas). Apibrėžimas sąmoningai nepasako kokie gali būti architektūrinių elementų bei ryšių tarp jų tipai. Tai priklauso nuo konkrečios programų sistemos, jos projektavimo metodikos (pvz., objektinės ar struktūrinės), parinkto architektūrinio stiliaus, ir kitų dalykų. Trečia, iš apibrėžimo išplaukia, kad kiekviena programų sistemų turi architektūrą, nes kiekviena programų sistema susideda iš kokių nors elementų ir ryšių tarp jų. Trivialiausiu (ir daugiau teoriniu) atveju sistema pati yra vienintelis elementas. Tačiau nors ir kiekviena sistema turi architektūrą, konkrečios sistemos atveju ji gali būti niekam nežinoma. Galbūt visi sistemą projektavę žmonės yra seniai išsiskirstę, projektinė dokumentacija prarasta, pasenusi arba niekada nesukurta, išeities tekstai prarasti arba niekada negauti, ir viskas, kas turima, tai vykdomas binarinis kodas. Visa tai atskleidžia skirtumą tarp architektūros ir tos architektūros aprašymo (dokumentacijos). Kadangi programų sistemos architektūra egzistuoja nepriklausomai nuo jos aprašymo ar specifikavimo, tampa svarbu gebėti ją dokumentuoti, o jei reikia, ir rekonstruoti. Galiausiai apibrėžimas nieko nesako apie tai, kokia architektūra yra gera arba bloga. Tai iškelia klausimą, kaip architektūra gali būti projektuojama, bei kaip vertinama. 2.2. Programų sistemos struktūros ir vaizdai Kiekviena atskirai paimta programų sistema paprastai yra per daug sudėtinga kad būtų įmanoma suvokti ją visą iškarto. Todėl konkrečiu momentu paprasčiau yra sutelkti dėmesį ties viena programų sistemos struktūra arba mažu jų skaičiumi. Kad prasmingai kalbėtume apie architektūrą, mes turime išreikštinai pasakyti, kokią struktūrą ar struktūras mes šiuo metu aptarinėjame iš kokio požiūrio taško mes šiuo metu žiūrime į architektūrą. Žiūrėdami iš skirtingų požiūrio taškų (arba požiūrių, angl. viewpoint), mes matome skirtingus vaizdus (angl. view). 11

I DALIS ARCHITEKTŪRINIO PROJEKTAVIMO PAGRINDAI 2. Programų sistemos struktūra yra architektūrinių elementų ir ryšių tarp jų aibė. 3. Programų sistemos vaizdas yra vieno ar kelių architektūros struktūrinių aspektų, parodančių, kaip architektūroje yra atsižvelgiama į vieną ar kelis suinteresuotų asmenų interesus, pavaizdavimas. Kitaip sakant, vaizdas yra architektūrinių elementų ir ryšių tarp jų pavaizdavimas (dažniausiai grafinis), o struktūra yra patys architektūriniai elementai su ryšiais. Pavyzdžiui, sistemos modulinė struktūra yra tos sistemos modulių aibė ir ryšiai tarp modulių. Modulinis vaizdas yra modulinės struktūros pavaizdavimas, pateiktas sistemos architektūros dokumentacijoje. Kadangi šnekėti apie programų sistemos struktūras yra patogiau parodant jų vaizdus, tai dažniausiai šios dvi sąvokos vartojamos kaip sinonimai. Detaliau apie vaizdus šnekėsime 3.1 skyriuje. Žemiau parodytas struktūros ir vaizdo metamodelis (Pav. 2-1). Kaip matome, struktūros yra sudarytos iš struktūrinių elementų, kurie yra dviejų rūšių ryšiai ir architektūriniai elementai. Vienas architektūrinis elementas gali dalyvauti keliuose ryšiuose su kitais architektūriniais elementais, vienas ryšys gali jungti du arba daugiau architektūrinių elementų. Struktūros elementui gali būti nurodytas ribojimas, susiaurinantis šio elemento pasirodymo struktūroje laisvę. Ribojimo pavyzdys: dekompozicijos struktūroje (žr. žemiau) dekompozicijos ryšiai negali sudaryti ciklų. Kiekvienas struktūros elementas turi vieną arba daugiau galimų pavaizdavimų. [HILL99] Ribojimas * * Struktūros 1 1..* elementas Pavaizdavimas Ryšys * 1..* Architektūrinis elementas Pav. 2-1. Programų sistemos struktūros ir vaizdo metamodelis Programų sistemų struktūros gali būti suskirstytos į dvi kategorijas statines ir dinamines. 4. Programų sistemos statinės struktūros nusako sistemos vidinius projektavimo meto elementus ir ryšius tarp jų. Vidiniais projektavimo laiko programiniais elementais gali būti moduliai, paketai, objektinės klasės, duomenų bazės procedūros ir bet kokie kiti programiniai kodo vienetai. Vidiniais duomenų elementais gali būti klasės, reliacinių duomenų bazių lentelės/esybės, bei duomenų failai. Vidiniais 12

I DALIS ARCHITEKTŪRINIO PROJEKTAVIMO PAGRINDAI aparatūriniais elementais gali būti kompiuteriai bei jų sudėtinės dalys, tokios kaip kieti diskai, procesoriai, bei tinklo įranga kaip kad kabeliai ar maršrutizatoriai. 5. Programų sistemos dinaminės struktūros nusako sistemos vykdymo meto elementus ir komunikaciją tarp jų. Programų sistemos dinaminės struktūros parodo kaip sistema veikia, t.y., kas vyksta jos darbo metu, kaip sistema reaguoja į išorinius (ar vidinius) stimulus. Komunikacija tarp vykdymo meto elementų gali būti tiek duomenų srautai tarp jų (elementas A siunčia pranešimą elementui B), tiek lygiagretus ar nuoseklus užduočių vykdymas (elementas X iškviečia elemento Y paprogramę), tiek elementų būsenų pasikeitimai. 2.2.1. Statinės struktūros Čia trumpai aptarsime dekompozicijos, panaudojimo, sluoksnių ir apibendrinimo statines struktūras. Detalesnį šių struktūrų aprašymą galima rasti [CLEM02]. 1. Dekompozicija. Šioje struktūroje architektūriniai elementai yra moduliai, susiję modulinės dekompozicijos ryšiais, parodančiais, kaip stambesni moduliai yra sudaryti iš smulkesnių. Iš dekompozicijos ryšių draudžiama sudaryti ciklus. Modulis gali priklausyti tik vienam tėviniam moduliui, kitaip sakant, dekompozicijos struktūra privalo būti griežtai medžio pavidalo. Dažniausiai programų sistemos projektavimas ir yra pradedamas šios struktūros kūrimu. Architektas visą sistemą (pats stambiausias modulis) skaido į smulkesnius posistemius (smulkesni moduliai) ir priskiria jiems funkcionalumą. Stambūs/sudėtingi moduliai yra toliau skaidomi į smulkesnius, kuriuos lengviau aprėpti/analizuoti. Moduliai dažnai turi jiems priskirtus interfeisus, realizacinį kodą, testus, ir panašiai. Tinkama dekompozicijos struktūra didžia dalimi nusako sistemos modifikuojamumo galimybę, užtikrindama, kad tikėtini sistemos pakeitimai bus vieno ar kelių mažų modulių viduje (t.y., tam, kad modifikuotume sistemą, nereikės dirbti su visos sistemos kodu, o tik su vienu/keliais moduliais). Ši struktūra yra labai dažnai naudojama kaip išeities taškas programų sistemos kūrimo projekto organizacijai (stambių modulių konstravimas yra pavedamas atskirai komandai), dokumentacijos struktūrizavimui (atskiri moduliai aprašomi skirtinguose skyriuose), integracijos ir testų planų parengimui. [CLEM02] 13

I DALIS ARCHITEKTŪRINIO PROJEKTAVIMO PAGRINDAI Žemiau yra pateikti du modulinės struktūros vaizdų pavyzdžiai UML kalba (Pav. 2-2 ir Pav. 2-3). Gaisrininkų iškvietimų apskaitos sistema Iškvietimų registravimas Duomenų analizė Vartotojų administravimas Ataskaitos OLAP Užklausos Pav. 2-2. Dekompozicijos struktūros vaizdas UML kalba Gaisrininkų iškvietimų apskaitos sistema Iškvietimų registravimas Duomenų analizė Vartotojų administravimas OLAP Užklausos Ataskaitos Pav. 2-3. Alternatyvus tos pačios dekompozicijos struktūros vaizdas UML kalba 2. Panaudojimas. Ši struktūra yra skirta informuoti apie modulių tarpusavio priklausomybę, tiksliau apie tai, kokie moduliai yra tarpusavyje susiję naudojimo (angl. use) ryšiais, kurie yra atskiras priklausomybės (angl. dependency) ryšio atvejis. Architektas gali naudoti šią struktūrą siekdamas apriboti galimas architektūros realizacijas, pasakydamas, kokie kiti moduliai privalo egzistuoti tam, kad tam tikra sistemos dalis galėtų dirbti korektiškai. Tinkamai naudojama ši struktūra įgalina pažingsninį (angl. incremental) programų sistemos dalių įgyvendinimą bei diegimą. Šios struktūros elementai yra moduliai, bet gali būti ir kiti smulkesni elementai kaip kad pavyzdžiui interfeisai. Elementai yra susiję panaudojimo ryšiu, kuris yra atskiras priklausomybės ryšio atvejis. Modulis M1 naudoja modulį M2 jei modulio M1 14

I DALIS ARCHITEKTŪRINIO PROJEKTAVIMO PAGRINDAI korektiškumas priklauso nuo modulio M2 korektiškos realizacijos egzistavimo. [CLEM02] Duomenų analizė <<use>> Duomenų bazė Duomenų analizė Ataskaitos OLAP Užklausos <<use>> <<use>> Duomenų bazė Pav. 2-4. Panaudojimo struktūros pavyzdys. Jei modulis turi panaudojimo priklausomybių ir turi dekompozicinę struktūrą, tai bent vienas jo sudėtinis modulis taip pat turi turėti panaudojimo priklausomybę 3. Sluoksnių. Kai panaudojimo ryšiai yra kontroliuojami specialiu būdu, yra gaunama sluoksnių sistema, kur sluoksnis yra tam tikru aspektu susijusio funkcionalumo aibė. Griežtai sluoksniuotoje struktūroje, sluoksnis n gali naudotis tik sluoksnio n-1 paslaugomis (žr. Pav. 2-5, kairėje). Sluoksnis A Sluoksnis A <<use>> Sluoksnis B <<use>> <<use>> Sluoksnis B <<use>> Sluoksnis C <<use>> Sluoksnis C Pav. 2-5. Griežtai sluoksniuotos (kairėje) ir negriežtai sluoksniuotos struktūrų vaizdai 15

I DALIS ARCHITEKTŪRINIO PROJEKTAVIMO PAGRINDAI Praktikoje dažnai šis reikalavimas nėra išlaikomas, ir yra gaunama negriežtai sluoksniuota struktūra, kurioje sluoksniui leidžiama naudotis visais žemiau jo esančiais sluoksniais (žr. Pav. 2-5, dešinėje). Sluoksnis paprastai būna sudarytas iš modulių, realizuojančių tam tikru aspektu susijusį funkcionalumą. Dažnai šie moduliai sluoksnių struktūroje yra parodomi išreikštinai (žr. Pav. 2-6). Vienam sluoksniui priklausantys moduliai gali būti susiję panaudojimo ryšiais, tai nepažeidžia griežto sluoksniavimo ribojimo. Sluoksnis A Modulis A1 <<use>> Modulis A2 Modulis A3 <<use>> Sluoksnis B <<use>> <<use>> Modulis B1 <<use>> Modulis B2 Pav. 2-6. Sluoksnių vidinės struktūros pavaizdavimas Sluoksniai dažnai būna projektuojami kaip virtualios mašinos, kurios žemiau esančių sluoksnių atžvilgiu pakelia abstrakcijos lygmenį aukštesni sluoksniai dirba su aukštesnio abstrakcijos lygmens instrukcijomis, pateikiamomis žemiau esančių virtualių mašinų. Tai sudaro prielaidas sluoksnių portabilumui. [CLEM02] 4. Apibendrinimo. Šios struktūros architektūriniai elementai yra objektinės klasės ir interfeisai, kurie yra susieti paveldėjimo ryšiais. Iš paveldėjimo ryšių yra draudžiama formuoti ciklus. Bendru atveju išskiriamos dvi paveldėjimo rūšys interfeiso paveldėjimas ir realizacijos paveldėjimas. Šnekant apie architektūrą svarbus yra tik interfeiso paveldėjimas. Pav. 2-7 yra parodytas apibendrinimo struktūros pavyzdys. Kairėje pusėje pavaizduotas klasių paveldėjimas (Figūra yra abstrakti klasė), dešinėje pusėje pavaizduotas interfeisų paveldėjimas (interfeisai I1 ir I2 paveldi iš interfeiso I) bei interfeisų realizacija (klasė A realizuoja interfeisą I1, klasė B realizuoja interfeisus I1 ir I2). 16

I DALIS ARCHITEKTŪRINIO PROJEKTAVIMO PAGRINDAI Figūra I I1 I2 Kvadratas Linija Apskritimas Taškas A B Pav. 2-7. Apibendrinimo struktūros pavyzdys Apibendrinimo struktūra leidžia projektuoti pakartotiną panaudojamumą (išreikštinai nurodant interfeisus, kuriuos realizuoja klasės) bei įgalina pažingsninį funkcionalumo pridėjimą (pradedame projektuoti nuo tėvinės abstrakčios klasės arba interfeiso, o vėliau palaipsniui pridedame vaikines klases). Ši struktūra naudinga, kai programų sistema privalo pasižymėti plečiamumo savybe. [CLEM02] 2.2.2. Dinaminės struktūros Dinaminės struktūros parodo sistemos struktūrinius elementus ir ryšius tarp jų sistemos vykdymo metu. Kaip architektūriniai elementai šiose struktūrose naudojami procesai, gijos, EJB 1 komponentai, Java Servlet komponentai, DLL bibliotekos, objektai, ir t.t. Ryšiai tarp šių struktūrų elementų nusako vienokį arba kitokį komunikavimo mechanizmą. Komunikavimas dažnai vienokiu ar kitokiu būdu išsireiškia į metodų iškvietimus. Architektas turėtų skirti: Lokalius ir nutolusius metodų kvietimus Sinchroninius ir asinchroninius kvietimus Toliau aptarsime kliento-serverio, procesų ir dislokavimo struktūras 1. Kliento-serverio. Šioje struktūroje architektūriniai elementai dažniausiai yra komponentai, kurie bendrauja naudodamiesi kitų komponentų teikiamomis paslaugomis. Ši struktūra riboja komunikavimą tuo, kad komunikavimą inicijuoti gali tik klientai, serveriai atsako į klientų užklausas. Šioje struktūroje serveriai per vieną ar kelis interfeisus teikia paslaugas, o klientai naudoja šias paslaugas. Ryšys tarp kliento ir serverio yra užklausos-atsakymo jungtis. Virš jungties paprastai būna išvardintos serverio teikiamos paslaugos. Kai virš jungties yra nurodyta daugiau nei viena paslauga, 1 Enterprise JavaBeans 17

I DALIS ARCHITEKTŪRINIO PROJEKTAVIMO PAGRINDAI papildomai gali būti pateiktas protokolas, dokumentuojantis paslaugų iškvietimo eiliškumą. Serveriai savo ruožtu gali veikti kaip klientai naudodamiesi kitų serverių paslaugomis, tuo pačiu formuodami paslaugų iškvietimų hierarchija (žr. Pav. 2-8). Pav. 2-8. Kliento-serverio struktūros pavyzdys Kliento-serverio struktūra leidžia atskirti klientus nuo jų naudojamų paslaugų. Tai leidžia išskirti bendro naudojimo paslaugas ir tuo pačiu palengvina programų sistemos supratimą. Funkcionalumo išskaidymas į klientus ir serverius leidžia juos nepriklausomai vienas nuo kito priskirti sistemos lygmenims (angl. tier) ir tuo pačiu analizuoti sistemos našumą, skaliuojamumą (angl. scalability), saugumą ir patikimumą. 2. Lygiagrečių procesų. Lygiagrečiai vykstantys ir komunikuojantys procesai yra įprasti daugumoje didelių programų sistemų ir būtini išskirstytose programų sistemose. Šios struktūros architektūriniai elementai yra procesai arba gijos sujungti komunikavimo, sinchronizavimo, išsišakojimo ir kitais lygiagrečių skaičiavimų primityvais. Lygiagrečių procesų struktūra naudinga analizuojant ir projektuojant programų sistemos našumą (angl. performance), patikimumą bei pasiekiamumą (angl. availability). UML kalba neturi diagramų, kuriose tiesiogiai būtų galima modeliuoti procesus ir ryšius tarp jų, bet turi aktyvios klasės ir aktyvaus komponento 2 sąvokas, kurioms galima suteikti proceso arba gijos stereotipus. Paprastas bendravimas tarp procesų (pvz., nutolusių procedūrų iškvietimai) gali būti pavaizduotas kaip asociacijos tarp 2 Aktyvus objektas/komponentas vykdymo metu turi savo nuosavą procesą arba giją. 18

I DALIS ARCHITEKTŪRINIO PROJEKTAVIMO PAGRINDAI komponentų. Sudėtingesnės komunikavimo formos (bendro naudojimo atmintis, semaforai, ir t.t.) gali būti modeliuojamos naudojant papildomus stereotipus. Pav. 2-9 parodyta internetinės sistemos, paremtos Java Servlet API, lygiagrečių procesų struktūra. Klientai jungiasi prie internetinės sistemos naudodamiesi naršyklėmis. Kiekvienam naujam klientui Java Servlet konteineris sukuria naują giją, kuri vykdo Java Servlet komponento kodą. Kiekvienam Java Servlet komponentui reikalingas prisijungimas prie duomenų bazės, kurį jis gauna iš prisijungimų saugyklos. Prisijungimų saugykla yra bendro naudojimo resursas (t.y., sistemos veikimo metu yra tik vienas šio komponento egzempliorius), dėl kurio potencialiai varžosi kelios gijos. Siekiant uždrausti kelioms gijoms vienu metu kreiptis į duomenų saugyklą, operacija duokprisijungimą() yra pažymima žyme {guarded} 3. Ši žymė reiškia, kad jei vienu metu bus keli lygiagretūs kreipiniai į šią operaciją, tai jie bus sustatyti į vieną eilę ir apdoroti po vieną. Java programavimo kalboje tokios žymės analogas yra raktinis žodis synchronized. Pav. 2-9. Procesų, gijų ir sinchronizavimo modeliavimas UML komponentais ir stereotipais UML komponentų ir stereotipų naudojimas tampa nepatogus, kai reikia modeliuoti sudėtingesnes lygiagrečių procesų konstrukcijas procesų išsišakojimą arba susijungimą. Šiuo atveju patogesnės gali būti UML būsenų ir veiklos diagramos, kurios turi išsišakojimo bei susijungimo primityvus. Pav. 2-10 parodyta veiklos diagrama, kurioje veiksmai Skaičiavimai A ir Skaičiavimai B vyksta lygiagrečiai (t.y., skirtinguose procesuose arba gijose). Prieš pradedant vykdyti veiksmą Rezultatų spausdinimas yra laukiama, kol abu šie veiksmai baigs vykdymą. Tokie patys 3 Angliškai guarded apsaugotas. 19

I DALIS ARCHITEKTŪRINIO PROJEKTAVIMO PAGRINDAI išsišakojimo ir susijungimo primityvai yra prieinami ir būsenų diagramose. [BOOC05, ROZA05] Inicializacija Skaičiavimai A Skaičiavimai B Rezultatų spausdinimas Pav. 2-10. UML veiklos diagrama, demonstruojantį procesų išsišakojimą ir susijungimą 3. Dislokavimo. Ši struktūra parodo kaip programinė įranga yra priskiriama (dislokuojama) aparatūrinei įrangai. Architektūriniai elementai yra programinė įranga (dažniausiai procesai arba gijos iš lygiagrečių procesų struktūros) ir aparatūrinė įranga (kompiuteriai ir kompiuteriniai tinklai). Dislokavimo struktūra tinka analizuoti programų sistemos našumą, pasiekiamumą ir saugumą. Ji taip pat naudojama aparatūrinės įrangos pirkimo kaštų įvertinimui. Ši struktūra ypač svarbi išskirstytose ir daug lygiagrečių procesų turinčiose sistemose. Pav. 2-11 parodyta aukščiau pristatytos internetinės sistemos dislokavimo struktūra. Yra išskiriami aparatūriniai įrenginiai, (pažymėti stereotipu «device»), vykdymo aplinkos (pažymėtos stereotipu «execution environment») ir artefaktai (dažniausiai programų sistemos išeities tekstų transliavimo produktai; pažymėti stereotipu «artifact»). Siekiant nurodyti, iš kokių programinių elementų yra surinkti artefaktai, yra naudojami priklausomybės ryšiai su stereotipu «manifest». Artefaktai siejami su įrenginiais arba vykdymo aplinkomis dislokavimo ryšiais (priklausomybės ryšys su stereotipu «deploy»). Jei vykdymo aplinkai būtinas vienoks ar kitoks konfigūraciją apibrėžiantis failas, yra galimybė nurodyti dislokavimo specifikaciją (artefaktas su stereotipu «deployment spec»). 20

I DALIS ARCHITEKTŪRINIO PROJEKTAVIMO PAGRINDAI <<device>> Kliento kompiuteris Internetas <<device>> Dalykinis serveris Lokalus tinklas <<device>> DB serveris <<artifact>> firefox.exe <<execution environment>> Java Servlet konteineris <<artifact>> Oracle DBVS <<manifest>> <<manifest>> <<process>> Naršyklė <<deploy>> <<process>> DBVS <<deployment spec>> war.xml <<artifact>> war.jar <<manifest>> <<thread>> Java Servlet <<manifest>> <<component>> DB prisijungimų saugykla Pav. 2-11. Internetinės sistemos dislokavimo struktūra Programų sistemos našumas yra derinamas keičiant programinės įrangos priskyrimus aparatūrinei įrangai. Geresnis našumas pasiekiamas tokiais priskyrimais, kurie eliminuoja šimtaprocentinį pavienių procesorių apkrovimą paskirstydami sistemos apkrovimą daugiau mažiau vienodai visiems procesoriams. Komunikavimo tarp skirtingų aparatūrinių mazgų apimtis bei dažnumas yra vienos svarbiausių būsimą sistemos našumą įtakojančių charakteristikų, tuo pačiu ir architekto dėmesio objektas. Programų sistemos pasiekiamumas tiesiogiai priklauso nuo sistemos elgsenos sutrikus procesorių ar komunikavimo kanalų darbui. Bandant apsisaugoti nuo tokių gedimų, dažnai programinių elementų kopijos yra dislokuojamos ant kelių identiškų aparatūrinės įrangos mazgų. Sutrikus vienam mazgui, darbas perduodamas kitam. Tai yra pagrindinė programinės įrangos fermų bei klasterių kūrimo idėja. Bandant įvertinti/pagerinti programų sistemos saugumą, yra analizuojami komunikavimo kanalai, ypatingą dėmesį kreipiant kanalams, per kuriuos duomenys ateina iš sistemos išorės. Labai dažnai tokiose vietose yra įterpiami papildomi užkardų 4 aparatūriniai mazgai, statomi maršrutizatoriai, kuriamos demilitarizuotos zonos. [CLEM02, BOOC05] Nors kalbant apie programų sistemų struktūrą dažniausiai kalbama apie jos funkcionalumą, yra daug svarbių nefunkcinių savybių, tokių kaip fizinis sistemos išskirstymas, komunikacija tarp 4 Angliškai firewall 21

I DALIS ARCHITEKTŪRINIO PROJEKTAVIMO PAGRINDAI lygiagrečiai vykstančių procesų, našumas, saugumas, ir dar daug kitų, į kurias turi būti atsižvelgta projektuojant programų sistemos architektūrą. Kiekviena iš aptartų struktūrų (o jos aptartos tikrai ne visos) yra naudinga vienokių ar kitokių sistemos savybių analizei bei projektavimui kiekviena iš jų pateikia sistemos vaizdą iš skirtingo požiūrio taško. Tačiau tuo pačiu šios struktūros nėra nepriklausomos. Jų elementai yra glaudžiai tarpusavyje susiję (kaip pavyzdį matėme internetinės sistemos lygiagrečių procesų ir dislokavimo struktūras). Individualūs projektai kartais pasirenka vieną struktūrą kaip pagrindinę, ir kitas struktūras kuria atsispirdami nuo pirmosios įvestų architektūrinių elementų. Dažnai (bet ne visada) tokia dominuojančia struktūra tampa modulių dekompozicijos struktūra. Viena pagrindinių priežasčių yra tai, kad ši struktūra didžia dalimi diktuoja paties programų sistemos kūrimo projekto organizaciją (dažnai už atskirų aukščiausio lygmens modulių realizavimą yra atsakingos atskiros komandos). Ne visoms programų sistemoms prireikia visų struktūrų. Paprastai, kuo didesnė kuriama programų sistema, tuo įvairesnių struktūrų prisireikia. Mažoms sistemoms dažnai pakanka kelių struktūrų. Jei sistemoje yra tik vienas procesas, tai lygiagrečių procesų struktūra bus nereikalinga. Jei sistemą planuojama diegti viename serveryje, dislokavimo struktūra tampa triviali ir neprasminga. Individualios struktūros atsineša su savimi galimybę manipuliuoti viena ar keliomis nefunkcinėmis sistemos savybėmis (kaip matysime toliau, būtent nefunkcinės sistemos savybės ir yra pagrindinis architekto dėmesio objektas). Jos įgalina pritaikyti interesų atskyrimo principą (angl. separation of concerns), tuo supaprastinant architektūros kūrimą ir jos aiškinimą suinteresuotiems asmenims (angl. stakeholders). [BASS03] 2.3. Išoriškai matomos sistemos savybės Galima išskirti dvi išoriškai matomų savybių grupes: išoriškai matoma elgsena (ką sistema daro) ir kokybinės savybės (kaip sistema tai daro). Išoriškai matoma elgsena pasako, ką sistema daro žiūrint iš išorinio stebėtojo taško. 6. Programų sistemos išoriškai matoma elgsena nusako funkcinę sąveiką tarp sistemos ir jos aplinkos. Ši išorinė sąveika įtraukia informacijos srautus į sistemą ir iš sistemos, sistemos atsaką į išorinius stimulus, ir paskelbtą kontraktą arba API per kurį sistema bendrauja su išoriniu pasauliu. Trumpai sakant, išoriškai matoma elgsena yra tai, kas buvo numatyta sistemos funkciniuose reikalavimuose (ką sistema turi daryti). 22

I DALIS ARCHITEKTŪRINIO PROJEKTAVIMO PAGRINDAI Kokybinės savybės pasako, kaip programų sistema tenkina nefunkcinius reikalavimus. 7. Programų sistemos kokybinė savybė yra išoriškai matoma tos sistemos nefunkcinė savybė kaip kad našumas, saugumas, pasiekiamumas, ir t.t. Yra visa aibė programų sistemos kokybinių savybių, kurios yra įdomios architektui: kaip sistema elgiasi esant didelei apkrovai? Koks yra didžiausias pralaidumas konkrečiai nurodytai aparatūrinei įrangai? Kaip informacija sistemoje apsaugota nuo neautorizuoto jos panaudojimo? Kaip dažnai sistemoje linkę pasireikšti trikiai? Ar paprasta yra ją valdyti, prižiūrėti ir plėsti? Kaip lengvai ji gali būti naudojama neįgalių žmonių? Kurios iš šių savybių yra svarbios priklauso nuo konkrečios programų sistemos bei nuo suinteresuotų asmenų interesų ir prioritetų. 2.4. Išorinės savybės ir sistemos vidinė struktūra Paanalizuokime šias sąvokas detaliau paprasto pavyzdžio kontekste. PAVYZDYS: Avialinijų rezervavimo sistema gali vykdyti įvairias transakcijas, tokias kaip bilietų rezervavimas, rezervacijos modifikavimas, nutraukimas, ir panašiai. Tokios sistemos išoriškai matoma elgsena yra jos atsakas į transakcijas, kurias inicijuoja sistemos vartotojai. Šios sistemos kokybinės savybės įtraukia vidutinį atsako laiką vartotojo inicijuotai transakcijai esant nurodytam sistemos apkrovimui, maksimalų transakcijų skaičių, kurį sistema gali palaikyti, sistemos pasiekiamumą, ir laiką, reikalingą gedimų pašalinimui. Yra nemažai būdų, kaip būtų galima projektuoti sistemą, tenkinančią išvardintus reikalavimus. Mes aptarsime du iš jų. Architektas galėtų projektuoti avialinijų rezervavimo sistemą taikydamas jai kliento-serverio, dar kitaip vadinamo storo kliento (angl. fat-client) arba dviejų lygmenų (angl. two-tier) architektūrinį stilių (apie architektūrinius stilius bus kalbama vėliau). Šiuo atveju sistemos vartotojai per Internetą komunikuoja su centriniu serveriu (žr. Pav. 2-12). Šios kliento-serverio architektūros statinė struktūra susideda iš kliento programinės įrangos (kuri toliau detalizuota iki vartotojo interfeiso ir verslo logikos programinių įrangų), serverio ir jungčių tarp jų. Dinaminė struktūra yra pagrįsta 23

I DALIS ARCHITEKTŪRINIO PROJEKTAVIMO PAGRINDAI užklausų/atsakymų modeliu: klientai siunčia užklausas serveriui, serverio atsakymai yra grąžinami klientams. Klientai Vartotojo interfeisas Verslo logika Vartotojo interfeisas Verslo logika Internetas Vartotojo interfeisas Verslo logika DB serveris Pav. 2-12. Avialinijų rezervavimo sistemos kliento-serverio architektūra Alternatyviai architektas galėtų taikyti trijų lygmenų (angl. three-tier), kitaip dar žinomą kaip plono kliento (angl. thin-client), architektūrinį stilių, kai kliento pusėje yra tik vartotojo interfeiso programinė įranga, o verslo logika yra atliekama serverio pusėje dalykiniame serveryje (angl. application server). Šios architektūros statinė struktūra susideda iš klientų programinės įrangos, dalykinio serverio, duomenų bazės serverio ir jungčių tarp jų. Dinaminė struktūra yra pagrįsta trijų lygmenų užklausų/atsakymų modeliu: klientai siunčia užklausas dalykiniam serveriui, dalykinis serveris, jei reikia, siunčia užklausas DB serveriui, atsakymai yra grąžinami klientui. Architektas galėtų pasirinkti dviejų lygmenų architektūrinį stilių kaip tinkamą šiai sistemai dėl jo santykinio paprastumo, dėl to, kad galbūt šio stiliaus programų sistemą programuotojai galėtų sukurti greičiau ir mažesniais kaštais nei alternatyvius variantus, arba dėl eilės kitų priežasčių. Kaip alternatyvą, trijų lygmenų variantą architektas galėtų pasirinkti dėl to, kad jis pasižymi geresniu skaliuojamumu didėjant sistemos apkrovimui, dėl to kad užtenka paprastės klientų aparatūrinės įrangos, dėl to kad šis variantas pasižymi geresniu saugumu, ir dėl kitų priežasčių. Bet kuriuo atveju architekto sprendimas didžia dalimi priklauso nuo geriausio atitikmens tarp programų sistemos savybių, kuriomis ji pasižymės pritaikius vienokį ar kitokį architektūrinį stilių, ir programų sistemos reikalavimų. 24

I DALIS ARCHITEKTŪRINIO PROJEKTAVIMO PAGRINDAI Pav. 2-13. Avialinijų rezervavimo sistemos plono kliento architektūra Šiame pavyzdyje mes aptarėme du variantus, kaip būtų galima projektuoti avialinijų rezervavimo sistemą. Šie variantai yra vadinami potencialiomis architektūromis (angl. candidate architecture). 8. Programų sistemos potenciali architektūra yra jos statinių ir dinaminių struktūrų rinkinys, turintis potencialą pasižymėti reikalaujama sistemos išoriškai matoma elgsena ir kokybinėmis savybėmis. Nors potencialios architektūros turi skirtingas statines ir dinamines struktūras, visos jos privalo tenkinti programų sistemos reikalavimus (tiek funkcinius, tiek nefunkcinius). Tačiau, nors jos ir visos tenkins šiuos reikalavimus, visos jos pasižymės kokiomis nors specifinėmis kokybinėmis charakteristikomis (pavyzdžiui, vieną iš jų gali būti lengviau prižiūrėti bet brangiau sukurti nei kitą). Bet kuriuo atveju, kiekvienos potencialios architektūros statinės ir dinaminės struktūros turi būti detaliai analizuojamos, kad nustatyti kokiu laipsniu potenciali architektūra tenkina sistemai keliamus funkcinius ir ypač nefunkcinius reikalavimus. Pavyzdžiui, kliento-serverio modelis potencialiai galėtų geriau tenkinti funkcinius reikalavimus, nes jo klientai yra funkciškai turtingesni. Kita vertus, trijų lygmenų modelis galėtų duoti geresnį duomenų pralaidumą ir atsako laiką, nes jis pasižymi silpna sankiba (angl. loose coupling). Vienas iš architekto uždavinių ir yra kiekvienai potencialiai architektūrai sudaryti sistemos statines bei dinamines struktūras, suprasti, kokiu mastu kiekviena jų pasižymi reikiamomis elgsenos ir kokybinėmis savybėmis, ir pasirinkti geriausią. Aišku, ką reiškia geriausia gali būti ne visada akivaizdu. Prie šio klausimo grįšime, kai kalbėsime apie architektūros kūrimo procesą. Ryšius tarp programų sistemos išoriškai matomų savybių ir jos vidinės struktūros bei organizacijos galime nusakyti tokiu būdu [ROZA05]: Programų sistemos išoriškai matoma elgsena (ką sistema daro) yra sąlygota jos vidinių elementų bendra funkcine elgsena. 25

I DALIS ARCHITEKTŪRINIO PROJEKTAVIMO PAGRINDAI Programų sistemos kokybinės savybės (kaip sistema tai daro), tokios kaip našumas, skaliuojamumas, pasiekiamumas yra sąlygotos jos vidinių elementų kokybinių savybių. Paprastai sistemos kokybinė savybė yra tiek gera, kiek gera ši savybė yra silpniausiame sistemos vidiniame elemente (t.y., grandinė yra tiek stipri, kiek stipri yra silpniausia jos grandis). 2.5. Programų sistemos architektūros svarba Kiekviena programų sistema, didelė ar maža, yra sudaryta iš dalių, sujungtų tarpusavyje ryšiais. Šių dalių gali būti mažai, gal tik viena, o gali būti dešimtys ir šimtai; šie ryšiai gali būti trivialūs, gali būti sudėtingi, arba kažkur per vidurį. Toliau, kiekviena sistema yra sudaryta iš dalių kurios bendrauja tarpusavyje ir su išoriniu pasauliu determinuotu (nuspėjamu) būdu. Vėlgi, šis bendravimas gali būti paprastas ir lengvai suprantamas, o gali būti ir toks sudėtingas, kad joks pavienis žmogus negalės suprasti visų jo aspektų. Tačiau šis bendravimas vis tiek yra ir, bent jau teoriškai, yra nusakomas. Kitais žodžiais, kiekviena programų sistema turi architektūrą, panašiai kaip kad architektūrą turi kiekvienas pastatas, tiltas ar laivas. Šią sampratą išsakysime formaliai kaip principą. PRINCIPAS: Kiekviena programų sistema turi architektūrą, nesvarbu, ar ji yra dokumentuota ir kam nors žinoma. Architektūra yra fundamentali programų sistemos savybė egzistuojanti nepriklausomai nuo to, ar architektūra buvo dokumentuota ir ar ji yra kam nors žinoma. Iš to seka, kad kiekviena programų sistema turi tik vieną architektūrą nors, kaip pamatysime, ji gali būti pavaizduota keliais būdais. 2.6. Architektūriniai elementai Šioje knygoje architektūriniais elementais mes vadinsime dalis iš kurių gali būti sukurta sistema. 9. Architektūriniai elementai (arba tiesiog elementai) yra fundamentalios dalys, iš kurių gali būti konstruojama sistema. Architektūrinio elemento prigimtis labai priklauso nuo sistemos tipo bei nuo konteksto, kuriame nagrinėjame sistemos elementus. Programų bibliotekos, posistemės, dislokuojami programinės įrangos vienetai (pavyzdžiui, EJB ir ActiveX komponentai), pakartotinai panaudojami programiniai 26

I DALIS ARCHITEKTŪRINIO PROJEKTAVIMO PAGRINDAI produktai (pvz., duomenų bazių sistemos) arba net ir programos gali būti programų sistemos architektūriniais elementais. Architektūrinis elementas turi pasižymėti sekančiomis savybėmis: Aiškiai apibrėžtomis atsakomybėmis Aiškiai apibrėžta riba (angl. boundary) Aiškiai apibrėžtais interfeisais, kurie nusako paslaugas, kurias elementas teikia kitiems architektūriniams elementams Architektūriniai elementai dažnai neformaliai yra vadinami komponentais arba moduliais, tačiau šie terminai jau yra plačiai vartojami ir turi specifinę prasmę. Vartodami terminą komponentas mes esame linkę kalbėti apie programinio lygmens komponentų modelį (pavyzdžiui JavaEE 5 arba.net), kita vertus, terminas modulis yra siejamas su programavimo kalbos konstrukcija (pavyzdžiui, Pascal programavimo kalba turi tokį raktinį žodį). Nors tiek komponentai, tiek moduliai gali būti architektūriniais elementais vienoje sistemoje, jie gali jais nebūti kitose. Dėl šių priežasčių, norėdami išvengti painiavos ir sekdami kitų autorių pavyzdžiu ([ROZA05], [BASS03]) mes toliau šioje knygoje vartosime terminą elementas. 2.7. Suinteresuoti asmenys Tradiciškai programų sistemų kūrimą labiausiai įtakojo faktas, kad būsimoji programų sistema privalo tenkinti vartotojų reikalavimus. Nors yra įvairių termino vartotojas apibrėžimų, visi programų sistemų kūrimo metodai yra grindžiami šiuo principu. Tačiau žmonės, kurie yra įtakojami programų sistemos, yra ne tik tie, kurie ją naudoja. Programų sistemos yra ne tik naudojamos: jos yra kuriamos ir testuojamos, su jomis dirba operatoriai, gali reikėti taisyti sistemų gedimus, jos yra paprastai plečiamos, ir aišku už jas kažkas turi sumokėti. Kiekviena šių veiklų įtraukia tam tikrą grupę žmonių, kurie paprastai nėra vadinami vartotojais. Šios žmonių grupės turi savo reikalavimus, interesus ir poreikius, kuriuos turi tenkinti programų sistema. Mes šiuos žmones vadinsime suinteresuotais asmenimis. Suinteresuotų asmenų vaidmens supratimas yra fundamentalus tam, kad suprastume architekto vaidmenį programų sistemos kūrimo projekte. Toliau yra pateiktas formalus suinteresuoto asmens apibrėžimas [IEEE00]. 5 Java Enterprise Edition, seniau buvo žinomas kaip J2EE 27

I DALIS ARCHITEKTŪRINIO PROJEKTAVIMO PAGRINDAI 10. Programų sistemos architektūros kontekste suinteresuotas asmuo yra žmogus, asmenų grupė arba organizacija, turintys tiesiogiai ar netiesiogiai programų sistemos kūrimą įtakojančių interesų. Žemiau yra aptariamos raktinės šio apibrėžimo sąvokos. 2.7.1. Žmonės, grupės ir organizacijos Kaip matysime šioje knygoje, programų sistemos architektūra rūpi ne vien tik programų sistemos kūrėjams ir jos vartotojams. Architektūros realizacija įtakoja žymiai platesnį žmonių ratą, kaip kad ir tuos asmenis, kurie turės programų sistemą diegti, prižiūrėti, apmokyti jos vartotojus, ar galų gale už ją sumokėti. Programų sistemos architektūros kūrimo metu suinteresuoti asmenys turi galimybę ją įtakoti. Deja, kaip rodo praktika, dalis suinteresuotų asmenų dažnai nerodo iniciatyvos ir noro dalyvauti architektūros aptarimuose, o savo interesus išreiškia tik kai pamato jau sukurtą programų sistemą. Todėl viena iš architekto rolių ir yra suinteresuotų asmenų įtraukimas į diskusijas apie architektūrą, jų motyvavimas, ir įsitikinimas, kad šie asmenys supranta savo dalyvavimo svarbą. Suinteresuotas asmuo dažnai būna žmonių grupė. Tai gali sukelti problemų, nes gali būti neįmanoma išsiaiškinti visų grupės narių interesus per architektūros sukūrimui skirtą laiką. Tokiu atveju tenka pasirinkti reprezentatyvų atstovą, kuris šnekėtų grupės vardu. 2.7.2. Interesai Kaip rodo praktika, suinteresuoti asmenys programų sistemos kūrimo pradinėje stadijoje dažnai patys nežino tikslių reikalavimų. 11. Programų sistemos architektūros kontekste interesas yra reikalavimas, tikslas, intencija, siekis, kurį suinteresuotas asmuo turi programų sistemos atžvilgiu. Daugelis interesų gali būti bendri tarp suinteresuotų asmenų, bet dalis gali būti individualūs arba netgi prieštaraujantys. Išspręsti šiuos prieštaravimus, tenkinant visų suinteresuotų asmenų poreikius, gali būti sunkus uždavinys. PAVYZDYS: Kai kurios svarbios programų sistemos kūrimo projekto charakteristikos yra dažnai rodomos trikampio pavidalu, kurio kampuose yra kaštai, kokybė, ir sistemos sukūrimo laikas. Idealiu atveju norėtume, kad programų sistema pasižymėtų aukšta kokybe, nuline kaina ir nuliniu sukūrimo laiku, tačiau tai, žinoma, 28

I DALIS ARCHITEKTŪRINIO PROJEKTAVIMO PAGRINDAI neįmanoma. Kokybės trikampis (Pav. 2-14) rodo, kad reikia daryti kompromisus tarp šių trijų charakteristikų, ir geriausia ką mes galime pasiekti tai yra dvi charakteristikos iš trijų. Pavyzdžiui, aukštos kokybės sistema yra kuriama ilgiau ir su didesniais kaštais. Aišku, dažnai įmanoma sutrumpinti sistemos sukūrimo laiką, tačiau, darant prielaidą, kad kaštai išliks tokie patys, tai gaunasi sistemos kokybės sąskaita. Viena ar kelios šių charakteristikų gali būti svarbios skirtingiems suinteresuotiems asmenims, ir architekto užduotis yra suprasti, kurios charakteristikos yra kam svarbios, ir pasiekti patenkinamą kompromisą. Pav. 2-14. Programų sistemos kokybės trikampis 2.7.3. Suinteresuotų asmenų svarba Suinteresuoti asmenys tiesiogiai ar netiesiogiai įtakoja visą programų sistemos architektūrą. Be suinteresuotų asmenų nebūtų prasmės kurti architektūrą, nes niekam nereikėtų galutinės programų sistemos. PRINCIPAS: Architektūros yra kuriamos tam, kad patenkinti suinteresuotų asmenų poreikius. 29

I DALIS ARCHITEKTŪRINIO PROJEKTAVIMO PAGRINDAI Jei sistema netenkina suinteresuotų asmenų poreikių, projekto negalima laikyti sėkmingu, nesvarbu, kad sistema buvo kuriama atsižvelgiant į geriausias architektūrines praktikas. Kitaip sakant, architektūros turi būti įvertintos atsižvelgiant į suinteresuotų asmenų poreikius, kaip kad ir į architektūrinius ir programų sistemų inžinerijos principus. PRINCIPAS: Gera architektūra yra ta, kuri tenkina suinteresuotų asmenų poreikius ir pasiekia jų keliamus tikslus. 2.8. Architektūros aprašas Programų sistemos architektūra gali būti labai sudėtinga. Vienas iš architekto uždavinių yra aprašyti šį sudėtingumą žmonėms, kurie turi jį suprasti. Architektas tai daro su architektūriniu aprašu. 12. Architektūros aprašas yra darbo produktų aibė, dokumentuojanti architektūrą suinteresuotiems asmenims suprantamu būdu ir demonstruojanti, kad architektūra tenkina jų interesus. Produktai šiame kontekste susideda iš architektūrinių modelių, sistemos apimties apibrėžimų, ribojimų ir principų. Architektūrinis aprašas turi nusakyti tiek architektūros esmę, tiek jos detales kitaip sakant, jis turi pateikti tiek bendrą vaizdą, nusakantį visą sistemą, tiek ir detales, reikalingas patikrinti architektūrą ir sukurti pačią sistemą. Nors kiekviena programų sistema turi architektūra, tačiau ne kiekviena turi architektūrinį aprašą. Net jei architektūra yra dokumentuota, ji gali būti dokumentuota tik dalinai, arba ta dokumentacija gali būti pasenusi ir nebeatitinkanti realybės. Griežtai kalbant, mūsų apibrėžimas nusako gerą architektūrinį aprašą. Architektūrinis aprašas, kurio suinteresuoti asmenys nesupranta arba kuris neparodo, kad jų interesai yra patenkinti, yra nieko vertas. PRINCIPAS: Nors kiekviena programų sistema turi architektūrą, ne kiekviena sistema turi architektūrinį aprašą, kurį suinteresuoti asmenys supranta ir kuris parodo, kad jų interesai bus patenkinti. Šiuo metu yra gausybė technikų, modelių, architektūros aprašymo kalbų (angl. architecture description language), ir kitų būdų kaip dokumentuoti architektūras. Pasirinkti tinkamą konkrečiai 30