Arkkitehtuurityylit ohjelmarakenteen perustana

arvosana päiväys arvostelija Arkkitehtuurityylit ohjelmarakenteen perustana Teemu Tverin Helsinki 04.05.2007 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET THE UNIVERSITY OF HELSINKI Tiedekunta/Osasto Fakultet/Sektion - Faculty Matemaattis-luonnontieteellinen tdk Tekijä Författare - Author Teemu Johannes Tverin Työn nimi Arbetets titel - Title Arkkitehtuurityylit ohjelmarakenteen perustana Oppiaine Läroämne - Subject Tietojenkäsittelytiede Työn laji Arbetets art - Level Tutkielma Tiivistelmä Referat - Abstract Aika Datum Month and year 04.05.2007 Laitos Institution - Department Tietojenkäsittelytieteen laitos Sivumäärä Sidoantal Number of pages 20 sivua + 0 liitettä Tässä tutkielmassa esitellään ohjelmistojen arkkitehtuurityylejä, arkkitehtuurityylien merkitystä ohjelmiston rakenteen kannalta. Lisäksi esitellään arkkitehtuurityylien käyttöä erilaisten ohjelmistojen perusrakenteen pohjana. Lisäksi esitellään eri arkkitehtuurityylien sovelluksia. ACM Computer Classification System (CCS): A.1 [Introductory and survey], D.2.11 [Software Architectures] Avainsanat Nyckelord -Key words ohjelmistoarkkitehtuuri, arkkitehtuurityyli, ohjelmistosuunnittelu Säilytyspaikka Förvaringställe Where deposited Muita tietoja Övriga uppgifter Additional information

Sisältö 1 Johdanto...1 2 Arkkitehtuurityylien jaottelu... 4 3 Arkkitehtuurityyli ohjelmiston ryhmittelyn perustana... 6 3.1 Kerrosarkkitehtuuri... 6 3.2 Kerrosarkkitehtuurityylin sovelluksia...9 3.3 Tietovuoarkkitehtuuri...10 4 Palveluperustaiset- ja sovellusaluekohtaiset tyylit... 13 4.1 Asiakas-palvelin arkkitehtuurityyli...14 4.2 Malli-näkymä-ohjain -arkkitehtuuri...15 5 Yhteenveto...18 Lähteet... 20

1 1 Johdanto Nykyaikaisessa ohjelmiston tuottamisessa on tärkeää määritellä ja dokumentoida ohjelmiston rakenne huolellisesti jo suunnitteluvaiheessa. Ohjelmistojen koko on kasvanut sekä niiden monimutkaisuus lisääntynyt. Ohjelmiston arkkitehtuuri tarkoittaa ohjelmiston perusrakennetta. Se määrittelee ohjelmiston komponentit sekä niiden suhteet toisiinsa [KoMi05, s. 18]. Olennaista ohjelmiston arkkitehtuurissa on, että se ei pelkästään jaa ohjelmistoa osiin, vaan myös määrittelee ohjelmistoon muodostuvien alijärjestelmien välisiä suhteita. Arkkitehtuurin tehtävänä on ottaa kantaa keskeisiin ohjelmiston ratkaisuihin ja niissä käytettäviin ratkaisutapoihin [KoMi05, s. 19]. Ohjelmiston arkkitehtuurin dokumentointi on nykyaikaisessa ohjelmistotuotantoprojektissa ensiarvoisen tärkeää. Dokumentoimatonta arkkitehtuuria ei oikeastaan edes ole olemassa. Ohjelmiston arkkitehtuurin yksi perustehtävä on tarjota ohjelmiston sidosryhmille mahdollisuus muodostaa oma mielikuvansa tuotettavasta ohjelmistosta [Bass98, s. 28]. Arkkitehtuuri materialisoituu arkkitehtuurikuvauksena: jos arkkitehtuuria ei ole dokumentoitu kunnolla, joudutaan helposti tilanteeseen jossa projektin eri henkilöt tekevät kukin tahollaan olettamuksia tuotettavan ohjelmiston arkkitehtuurista [KoMi05, s. 20]. Jos nämä näkemykset poikkeavat toisistaan on projekti todennäköisesti ongelmissa. Arkkitehtuurityyli (architechtual style) on koko järjestelmää luonnehtiva korkeimman abstraktiotason suunnitteluratkaisu. Kirjallisuudessa arkkitehtuurityylistä käytetään myös termiä arkkitehtuurimalli (architectural pattern). Suunnittelumallit (design pattern) ovat arkkitehtuurityylien läheisiä sukulaisia, mutta niiden eroavaisuus on, että arkkitehtuurityyli on abstraktiotasoltaan suunnittelumallia korkeampi: kun suunnittelumalli voi esiintyä järjestelmässä monena ilmentymänä ratkaisten paikallisia suunnitteluongelmia, on arkkitehtuurityyli järjestelmää määräävä kokonaisrakenne [KoMi05, s. 125]. Arkkitehtuurityyli tarjoaa kokoelman valmiita alijärjestelmämalleja sekä määrittelee näiden vastuut ja keskinäiset suhteet [Busc96, s. 25]. Arkkitehtuurityylit ovat yleisiä,

sovelluksesta riippumattomia, kuvauksia järjestelmän arkkitehtuurista. Yleisesti arkkitehtuurimallia käytetään tuotettavan järjestelmän hahmottelun työkaluna. 2 Arkkitehtuurityyli asettaa rajat ja säännöt tuotettavan ohjelmiston arkkitehtuurille ja sitä käyttäen voidaan suunnitella toteutettavan järjestelmän rakenteellinen ja toiminnallinen runko. Arkkitehtuurityyli ohjaa järjestelmän kehitystyötä, esimerkiksi jokaista järjestelmään kehitettävää ominaisuutta tai alijärjestelmien tarkkaa suunnittelua ja alijärjestelmien välistä toimintaa [Busc96, s. 26]. Erilaisten järjestelmien vaatimuksia ajatellen on kehitetty erilaisia arkkitehtuurityylejä. Järjestelmälle sopivin arkkitehtuurityyli riippuu sille asetetuista vaatimuksista sekä sovellusalueesta [Busc96, s. 27]. Tunnetuimmat arkkitehtuurityylit ovat kerrosarkkitehtuurit, tietovuoarkkitehtuurit, asiakas-palvelin-arkkitehtuurit sekä sovellusaluekohtaisten arkkitehtuurien ryhmä. Näistä arkkitehtuurityyleistä kerros- ja tietovuoarkkitehtuurit ovat arkkitehtuurityylejä, jotka sopivat ohjelmiston komponenttien ryhmittelyyn ja näin ohjelmiston jäsentämiseen. Erityisesti kerrosarkkitehtuuria voidaan käyttää monenlaisten järjestelmien kuvaamiseen [KoMi05, s. 25]. Asiakas-palvelin-arkkitehtuurityylissä perusajatuksena on kapselointi. Tässä arkkitehtuurityylissä kapseloidaan tietyn arkkitehtuuritason resurssin (palvelin) hallinta siten, että resurssin käyttäjän (asiakas) ei tarvitse huolehtia resurssin käyttöön liittyvistä teknisistä ongelmista. Kapselointi toimii myös toiseen suuntaan, palvelin ei tunne asiakkaan teknistä toteutusta [KoMi05, s. 136]. Sovellusaluekohtaisten arkkitehtuurityylien ryhmä sisältää sellaisia arkkitehtuurityylejä, joiden on huomattu toimivan tietyllä sovellusalueella erityisen hyvin [KoMi05, s. 142]. Suurinta osaa järjestelmistä ei kuitenkaan voida rakentaa ainoastaan yhden arkkitehtuurityylin varaan [Busc96, s. 27]. Monien järjestelmien täytyy tukea laajaa joukkoa vaatimuksia, jotka voidaan saavuttaa vain useampia arkkitehtuurityylejä käyttäen. Käytännössä tämä voi tarkoittaa sitä, että esimerkiksi

kerrosarkkitehtuurityylillä suunniteltuun järjestelmään integroidaan osia, jotka noudattavat suunnittelultaan asiakas-palvelin-arkkitehtuurityyliä. 3 Arkkitehtuurityyli, tai yhdistelmä eri arkkitehtuurityyleistä ei ole valmis ohjelmiston arkkitehtuuri [Busc96 s. 27]. Se on ainoastaan rakenteellinen kehys ohjelmistolle. Arkkitehtuurityylit ovat ohjelmistoarkkitehtuurin suunnittelun avaintyökalu, mutta sopivimman vaihtoehdon valinta on usein vaivalloista, eikä oikean, tilanteeseen parhaiten sopivan arkkitehtuurityylin löytäminen ja valitseminen aina ole kiistatonta tai varmaa [AvZd05, s. 1].

4 2 Arkkitehtuurityylien jaottelu Buschmann et al. esittelevät teoksessaan Pattern-Oriented Software Architecture: A System of Patterns arkkitehtuurityylien jaottelun kategorioihin. Perusajatus jaottelulle on, että tiettyyn kategoriaan sisältyvät arkkitehtuurityylit auttavat ratkaisemaan samantapaisia ongelmia. [Busc96, s. 26]. Kategoriat ovat: jäsennysarkkitehtuurit (from mud to structure), hajautetut arkkitehtuurit (distributed systems), vuorovaikutusarkkitehtuurit (interactive systems), muokattavuutta tukevat arkkitehtuurit (adaptable systems). Jäsennysarkkitehtuurien ryhmään kuuluvat sellaiset arkkitehtuurit, joita käytetään ohjelmiston rakenteen puuroutumisen estämiseen. Näitä arkkitehtuurityylejä ovat esimerkiksi kerrosarkkitehtuurityyli sekä tietovuoarkkitehtuurityyli. Jäsennysarkkitehtuurit jakavat ohjelmiston pääasiallisen tehtävän suorituksen yhteistyötä tekeville järjestelmän osille. Jäsennysarkkitehtuureita käsitellään tutkielman luvussa 2. Hajautettujen arkkitehtuureiden ryhmään kuuluu arkkitehtuurityylejä, jotka sopivat hajautettujen järjestelmien pohjaksi. Esimerkiksi asiakas-palvelin-arkkitehtuurityylin voidaan ajatella kuuluvan hajautettuihin arkkitehtuureihin. Vuorovaikutusarkkitehtuurit ovat arkkitehtuureita, joiden pääasiallinen sovelluskohde ovat sellaiset järjestelmät, jotka sisältävät ihmisen ja tietokoneen välistä interaktiota. Eräs vuorovaikutusarkkitehtuuri on malli-näkymä-ohjain -arkkitehtuuri, jota käsitellään myöhemmin tässä tutkielmassa.

5 Muokattavuutta tukeviin arkkitehtuureihin kuuluvat sellaiset arkkitehtuurityylit, jotka tukevat vahvasti järjestelmän muokattavuutta sekä järjestelmien kykyä sopeutua kehittyvään teknologiaan ja muuttuviin toiminnallisiin vaatimuksiin.

6 3 Arkkitehtuurityyli ohjelmiston ryhmittelyn perustana Nykyaikaisen laajan ohjelmiston rakenne, saattaa ilman suunnittelua ohjaavaa aputyökalua, puuroutua komponenttien ja alijärjestelmien vaikeaselkoiseksi massaksi. Arkkitehtuurityyli, joka auttaa ohjelmiston rakennuspalasten ryhmittelyssä ja järjestämisessä, on keino välttää tämä ongelma [Busc96, s. 29]. On yleistä, että arkkitehtuurityyliä käytetään apuna juuri tämän ongelman esiintymisriskin pienentämiseen. Tällöin ryhmittelyyn perustuvan arkkitehtuurityylin mukaisessa järjestelmässä järjestelmän komponentit muodostavat joukkoja, joissa komponentit ovat samassa suhteessa keskenään ohjelmiston arkkitehtuurin kannalta. Tärkeimmät arkkitehtuurityylit, joita käytetään ohjelmiston ryhmittelyn perustana ovat kerrosarkkitehtuurit ja tietovuoarkkitehtuurit [KoMi05, s. 125]. Kerrosarkkitehtuuri voidaan ajatella tapana nähdä järjestelmä organisoituna käyttösuhteiden mukaan jaoteltuihin osiin, jotka koostuvat samassa asemassa käyttösuhteiden kannalta olevista komponenteista [KoMi05, s. 126]. Siksi tällainen arkkitehtuurityyli voidaan ymmärtää sekä järjestelmän hahmotus- että ryhmittelytekniikkana. 3.1 Kerrosarkkitehtuuri Kerrosarkkitehtuurin perusajatus on, että järjestelmä koostuu joukosta eri käsitetasoja. Nämä käsitetasot ovat itsenäisiä. Samalla käsitetasolla sijaitsevat järjestelmän palvelut muodostavat kerrosarkkitehtuurityylissä kerroksen [Busc96, s. 31]. Kuten kuvassa 1, kerrosarkkitehtuurin kerrokset on järjestetty nousevaan järjestykseen sopivaa abstrahointiperiaatetta käyttäen ja palvelukutsut kulkevat ainoastaan ylemmältä kerrokselta välittömästi seuraavalle alemmalle kerrokselle. Yleisin käytetty periaate on skaala laite-ihminen [KoMi05, s. 126]. Laitetta läheisimmät tasot tarjoavat yleisesti lähellä laitteistoa ja käyttöjärjestelmää olevia

palveluita ja ovat näin matalammalla tasolla kuin ihmistä lähellä olevat tasot, jotka yleisesti tarjoavat esimerkiksi käyttöliittymäpalveluja [KoMi05, s. 126]. 7 Kuva 1: Puhtaan kerrosarkkitehtuurityylin periaate. Kerrosarkkitehtuurin etu on sen rakenne, joka mahdollistaa ohjelmiston eri osien määrittelyn osissa eri käsitetasoilla. Jokaisella kerroksella on omat määritellyt rajapintansa ulospäin, joten ne eivät aseta rajoituksia muiden kerrosten toteuttamiselle tai käytölle [GrSh94, s. 11]. Rakenteen ansiosta on myös mahdollista muuttaa tai jopa toteuttaa uudelleen jokin yksittäinen kerros ilman, että muihin kerroksiin tarvitsee koskea. Pahimmillaan muuttamisen vaikutukset ulottuvat vain muutamaan lähimpään kerrokseen [GrSh94, s. 11]. Kerrosten abstraktiotasoja voi kuitenkin olla vaikea tunnistaa, sillä usein kerrokset ovat luonteeltaan niin teknisiä, että eri abstraktiotasojen nimeäminen ja erottaminen toisistaan käsitteellisesti on hankalaa [KoMi05, s. 126]. Siksi saatetaan tarvita toinen tapa löytää järjestelmän kerrostusperiaate. Tällöin kerrostusperiaatteen ratkaisee se, että ylempi kerros kutsuu itseään alemman kerroksen tarjoamia palveluita ja tarjoaa palveluitaan itseään ylemmälle kerrokselle. Abstraktiotasoltaan korkeammat palvelut toteutetaan käyttäen abstraktiotasoltaan matalampia palveluita [KoMi05, s. 126].

8 Käytännössä tästä kerrosarkkitehtuurin perusideasta joudutaan usein poikkeamaan ja puhdas kerrosarkkitehtuuri on harvinaisuus [KoMi05, s. 126]. Poikkeamia puhtaasta kerrosarkkitehtuurista on kahdenlaisia: palvelukutsun kulkeminen alemmasta kerroksesta ylempään (hierarchy breach) sekä kerrosten ohittaminen palvelukutsun kulkiessa ylemmältä abstraktiotasolta alas (bridging) [KoMi, s. 126]. Kerrosten ohittamista ei pidetä yleisesti pahana poikkeamisena kerrosarkkitehtuurista, sillä kerrosten ohittamiselle on usein perusteita: kerrosten ohittaminen on usein järkevää tehokkuussyistä tai siksi, että haluttua palvelua ei ole saatavilla seuraavassa kerroksessa. Usein käytettynä kerrosten ohittaminen saattaa kuitenkin johtaa kerrosarkkitehtuurin idean heikentymiseen [KoMi05, s. 127]. Palvelukutsun kulkeminen alemmasta kerroksesta ylempään on sen sijaan vakava kerrosarkkitehtuurin ongelma, jos sen seurauksena on alemman kerroksen riippuvuus ylemmästä [KoMi05, s. 127]. Tällainen kutsuminen on kuitenkin välttämätöntä, jos alemman kerroksen on sovitettava palvelunsa ylemmän kerroksen mukaan, ja kutsuu tämän takia oman palvelunsa aikana koodia, joka on ylemmässä kerroksessa. Jotta alempi kerros ei tulisi riippuvaiseksi ylemmästä, on tällainen tilanne toteutettava takaisinkutsuperiaatetta (callback) käyttäen [KoMi05, s. 127]. Kerrosarkkitehtuurityyli on yleinen malli, jota voidaan soveltaa lähes kaikissa järjestelmissä, sekä pienessä, että suuressa mittakaavassa [KoMi05, s. 130]. Koska se jakaa järjestelmän korkealla tasolla osiin, on järjestelmän rakenne helpompaa ymmärtää, ja toisaalta jokainen kerros voidaan myös käsitellä omana kokonaisuutenaan. Kerrosarkkitehtuuri on myös riittävän ymmärrettävä, että sitä voidaan käyttää tukena keskusteltaessa järjestelmästä erilaisten ihmisten kanssa [KoMi05, s. 131].

9 3.2 Kerrosarkkitehtuurityylin sovelluksia Käyttöliittymä Sovelluslogiikka Sovellusaluelogiikka Tietokanta Kuva 2: Esimerkki kerrosarkkitehtuurin käytöstä [KoMi05, s. 128]. Koskimies ja Mikkonen esittelevät teoksessaan Ohjelmistoarkkitehtuurit esimerkin kerrosarkkitehtuurityylin soveltamisesta liiketoimintajärjestelmänä, jossa on neljä kerrosta. Esimerkin sovellusalue on vakuutusyhtiön tietojärjestelmä. Tällaisen järjestelmän mahdollinen kerrosarkkitehtuurimallia noudattava rakenne on esitetty kuvassa 2 [KoMi05, s. 128]. Alin kerros tarjoaa yleistä infrastruktuuritukea, esimerkiksi tietokannan ja sen toiminnot, sen yläpuolella sovellusalueen logiikan sekä käsitteet toteuttava kerros. Tämän jälkeen seuraa sovelluksen logiikan toteuttava kerros ja ylimpänä kerroksena on sovelluksen käyttöliittymän toteuttava kerros. Alin kerros on lähinnä laitteistoa, kun taas ylin lähinnä järjestelmän käyttäjää. Esimerkkijärjestelmässä sovellusaluelogiikkakerroksessa on kaikille vakuutuksille yhteiset ominaisuudet, kuten asiakas tai laskutus. Sovelluslogiikkakerros sisältää esimerkiksi liikennevakuutuslogiikan tai henkivakuutuslogiikan. Tällainen arkkitehtuurityyli mahdollistaa kahden alimman kerroksen uudelleenkäytön, jos ilmenee tarvetta tehdä esimerkiksi uusi vakuutussovellus. Toinen tunnettu sovellus kerrosarkkitehtuurityylin käytöstä ovat tietoliikenneprotokollat [Busc96 s. 31]. Näitä protokollia ovat esimerkiksi OSI-malli sekä TCP/IP. Tietoliikenneprotokolliin kerrosarkkitehtuurityyliä sovelletaan järjestämällä yleisen protokollan erikoistuneet aliprotokollat kerrosarkkitehtuurityylin mukaiseen kerrostusjärjestelmään ja kutsuu palveluitaan ainoastaan alemmalta

kerrokseltaan. [Busc96 s. 31]. Jokainen kerros on vastuussa ainoastaan omasta erikoistumisalueestaan [Busc96 s. 31]. Kuvassa 3 esitetään OSI-mallin rakenne. 10 Kuva 3: OSI-mallin rakenne [Busc96 s. 31]. Seitsenkerroksisen OSI-mallin kehitti The International Standardization Organization (ISO) poistaakseen yhteensopimattomuusongelmia verkossa [Busc96 s. 31]. Kukin OSI-mallin kerros tarkastelee tietoliikennettä eri abstraktiotasolla. OSI-malli on viitekehys, jossa kullekin kerrokselle voidaan sovittaa useita protokollia [Busc96 s. 31]. 3.3 Tietovuoarkkitehtuuri Tietovuoarkkitehtuuri on arkkitehtuurityyli, joka sopii erityisen hyvin sellaisen järjestelmän malliksi, jossa on luonteenomaista tietovirran jäsentäminen ja jalostaminen [KoMi05, s. 132]. Tietovuoarkkitehtuurityyli on eräänlainen sovellus hajota ja hallitse -ongelmanratkaisutekniikasta: monimutkainen tehtävä jaetaan pienempiin kokonaisuuksiin, jotka voidaan sitten ratkaista pienemmällä resurssitappiolla, kuin jos koko tehtävä ratkaistaisiin kokonaisuudessaan kerralla [AvZd05, s. 12]. Tämän arkkitehtuurityylin merkittävin etu on, että mutkikas tiedon prosessointi voidaan tehdä asteittain, jalostamalla tietoa askel kerrallaan. Näin monimutkaisetkin tietojenkäsittelytehtävät voidaan ymmärtää ja toteuttaa hallitusti [KoMi05, 135].

11 Kuva 3: Tietovuoarkkitehtuuri [KoMi05, s. 132]. Tietovuoarkkitehtuurin perusajatus kuvataan kuvassa 3. Tietovuoarkkitehtuuri koostuu prosessointiyksiköistä (filter) sekä niitä yhdistävistä, tietovirtaa kuljettavista väylistä (pipe). Prosessointiyksiköiden tehtävä on tiedon aktiivinen käsittely ja väylien tehtävä on passiivinen tiedon kuljetus prosessointiyksiköiden välillä [GrSh94, s. 6]. Prosessiyksiköiden tehtävä on yksinkertaisesti lukea omaa syötevirtaansa, käsitellä se ja tuottaa tulosteensa [KoMi05, s. 132]. Yleisin ja yksinkertaisin muoto tietovuoarkkitehtuurista on liukuhihna-arkkitehtuuri (pipeline architecture). Liukuhihna-arkkitehtuurissa tietovirta etenee haarautumatta yhtä prosessointiyksiköiden ketjua pitkin. Tiedonvälitys voidaan toteuttaa synkronisena kahdella tavalla: joko työntämällä tai vetämällä tietoa [KoMi05 s. 133]. Tietovuoarkkitehtuurityyli vaatii, että prosessointiyksiköt on toteutettu itsenäisinä, omaa syötettään lukevana ja omaa tulostettaan tuottavana yksikkönä, joka ei ole riippuvainen muista yksiköistä. Yksiköt eivät jaa tilatietoa keskenään, eikä niiden tarvitse tuntea toisiaan [GrSh94, s. 6]. Prosessoinnin täytyy myös tapahtua vain yhdessä vaiheessa: prosessointi ei saa riippua jonkin tulevan tietoalkion prosessoinnista [KoMi05, s. 132]. Tietoa voidaan toki puskuroida, mutta laajamittainen tiedon puskurointi aiheuttaa arkkitehtuurityylin

12 perusidean rikkoutumisen ja vaikeuttaa esimerkiksi syötteen rinnakkaista prosessointia [KoMi05, s. 133]. Kukin yksikkö voisi esimerkiksi lukea aina koko tietovirran ensin omaan puskuriinsa ja sen jälkeen prosessoida sen mielivaltaisessa järjestyksessä. Tällöin koko tietovirran käsite häviää, koska tieto välitetään yksiköiden välillä isona rakenteena [KoMi05, s. 133]. Tietovuoarkkitehtuuri ei sovi interaktiivisen järjestelmän suunnittelun perusmalliksi, eikä sitä ole sellaiseen käytettäväksi tarkoitettukaan. Tietovuoarkkitehtuurin perustuvassa järjestelmässä ei ole sellaista globaalia tilaa, jonka näyttäminen käyttäjälle vuorovaikutusta varten olisi mielekästä [KoMi05, s. 135]. Monissa järjestelmissä tietovuoarkkitehtuuria voidaan kuitenkin käyttää pienemmässä mittakaavassa. Sovelluskohde tietovuoarkkitehtuurista on prosessien tulosten siirtäminen seuraavan prosessin syötteeksi putkia käyttäen Unix-järjestelmissä [KoMi05, s. 132].

13 4 Palveluperustaiset- ja sovellusaluekohtaiset tyylit Palveluperustaiset arkkitehtuurityylit on rakennettu siten, että niissä katsotaan olevan kahdenlaisia rooleja: palvelun tarjoajat ja niiden käyttäjät. Palvelun tarjoaja voi myös toimia jonkin palvelun käyttäjänä, joten roolit eivät yleensä ole tiukat. Usein palvelun ajatus perustuu johonkin resurssiin, jonka palveluita sen ympärille rakennettu komponentti tarjoaa ympäristölleen [KoMi05 s. 136]. Palveluperustaisuus ja kerrostaminen voidaan yhdistää, jos palveluita halutaan ryhmitellä. Tällöin tiettyjen palveluiden tarjoaminen yhdistetään suoraan johonkin arkkitehtuurin kerrokseen. Tällainen toimintatapa määrittelee yleensä sääntöjä myös sille, kuinka palveluita on mahdollista käyttää [KoMi05 s. 136]. Joillekin sovellusalueille on huomattu toimivaksi tietynlainen toteutustapa, ja se on ajan kuluessa vakiintunut. Näitä toteutustapoja kutsutaan sovellusaluekohtaisiksi arkkitehtuurityyleiksi Toteutukseltaan sovellusaluekohtaista arkkitehtuurityyliä noudattava järjestelmä voidaan rakentaa esimerkiksi palveluiden tai jonkinlaisen kerrostamisen perustalle [KoMi05, s. 142]. Tässä tutkielmassa esitellään palveluperustaisista arkkitehtuurityyleistä Asiakaspalvelin-arkkitehtuurityyli. Sovellusaluekohtaisista arkkitehtuurityyleistä esitellään Malli-näkymä-ohjain -arkkitehtuurityyli.

14 4.1 Asiakas-palvelin arkkitehtuurityyli Asiakas-palvelin-arkkitehtuurityyli on yleisin tällä hetkellä käytettävistä arkkitehtuuriratkaisuista [KoMi05, s. 136]. Sen perusajatus on kapseloida tietyn arkkitehtuuritason resurssin hallinta siten, että resurssin hallitsija (palvelin) huolehtii resurssin teknisistä tehtävistä ja resurssin käyttäjät (asiakkaat) voivat pyytää resurssin palveluita välittämättä muista palvelun asiakkaista [KoMi05, s. 136]. Yleensä palvelin ei tiedä asiakkaidensa määrää tai identiteettejä, mutta asiakkaat tietävät palvelimen identiteetin [GrSh94, s. 14]. Kuva 4: Asiakas-palvelin-arkkitehtuuri. Kuvassa 4 on havainnollistettu asiakkaiden ja palvelimien mahdollisia suhteita keskenään sekä asiakkaiden riippumattomuutta toisista asiakkaista: ne voivat pyytää palvelimilta palveluita välittämättä toisista asiakkaista [KoMi05, 136]. Palvelimen harteille jää esimerkiksi asiakkaiden priorisointi sekä muut tekniset kysymykset. Usein toiminta asiakkaan ja palvelimen välillä tapahtuu istunnon (session) puitteissa [KoMi05, s. 136]. Istunnossa suoritetaan jokin asiakkaan tarvitsema palvelukokonaisuus, jonka palvelin toteuttaa. Yleensä palvelimet odottavat passiivisina asiakkaan yhteydenottoa. Kun asiakkaan yhteydenotto saapuu, ryhtyvät palvelimet toimeen ja toteuttavat asiakkaan palvelupyynnön. Palvelukokonaisuuden suoritettuaan

15 palvelin vastaa asiakkaalle ja asiakas päättää istunnon [KoMi05, s. 137]. Jos istuntoon liittyy transaktioita, niiden eheys ja peruutus on palvelimen harteilla [KoMi05, s. 137]. Usein kommunikointi asiakkaan ja palvelimen välillä on täsmällisesti säädeltyä. Palvelin myös toimii aina omassa säikeessään tai prosessissaan, mikä pitää sen toteutuksen erillään asiakkaista [KoMi05, s. 137]. Asiakas-palvelin-arkkitehtuurityyli ajatellaan usein hajautettuna järjestelmänä [KoMi05, s. 138]. Asiakas-palvelin-arkkitehtuurityyliä onkin käytetty yleisesti hajautettujen järjestelmien mallina [GrSh94, s. 14]. Toisaalta ideaa siitä, että tietty resurssi kapseloidaan palvelimelle, joka huolehtii resurssin toiminnoista, ei ole sidottu hajautukseen, vaan sitä voidaan käyttää missä tahansa ympäristössä eristämään jokin resurssi oman hallintayksikkönsä valvontaan [KoMi05, s. 138]. 4.2 Malli-näkymä-ohjain -arkkitehtuuri Malli-näkymä-ohjain -arkkitehtuuri (MVC, model-view-controller) erottaa käyttöliittymän varsinaisesta sovelluslogiikasta ja datasta. Tämä arkkitehtuurityyli soveltuu sellaisten interaktiivisten järjestelmien malliksi, jotka sisältävät monimuotoisia käyttöliittymänäkymiä [KoMi05, s. 142]. Arkkitehtuurin avulla pyritään saavuttamaan käyttöliittymän helppo muokattavuus, sekä järjestelmän helppo siirrettävyys toiselle alustalle. Lisäksi halutaan, että käyttöliittymä heijastaa aina sovellusdatan tilaa ja näyttää sen tarvittaessa erilaisissa näkymissä aina oikeassa muodossaan [KoMi05, s. 142].

16 Kuva 5: Malli-näkymä-ohjain -arkkitehtuuri. Kuten kuvassa 5, Malli-näkymä-ohjain -arkkitehtuurityyliä noudattava järjestelmä jaetaan kolmen tyyppisiin osiin: malleihin (model), näkymiin (view) ja ohjaimiin (controller) [Busc96 s. 125]. Mallit edustavat osia sovellusdatasta tai sovelluksen tilasta. Ne ovat vastuussa laskentaan liittyvän tiedon tai tilan säilytyksestä. Näkymät edustavat osaa näkyvästä käyttöliittymästä ja ovat vastuussa tiedon esittämisestä käyttäjälle. Ohjaimet käsittelevät käyttäjän syötteet sekä toimivat sovittimina näkymien ja mallien välissä pitäen huolta siitä, että ne vastaavat toisiaan [Busc96, s. 128]. Ohjaimet siis vastaavat käyttäjän ja mallin vuorovaikutuksen ohjaamisesta. Tyypillisesti vuorovaikutus käyttäjän ja järjestelmän välillä kulkee kuvan 5 tapaan seuraavasti: Käyttäjä antaa komennon, jonka ohjain havaitsee. Se pyytää mallia suorittamaan vastaavan sovelluspalvelun. Tämän seurauksena mallin tila muuttuu, josta se informoi kiinnostuneita näkymiä tai ohjaimia, jotka suorittavat tarvittavat operaatiot näytön näyttämiseksi sekä ohjainten päivittämiseksi [KoMi05, s. 143-144]. Ohjaimien toiminnan apuna käytetään usein Tarkkailija-suunnittelumallia (observer). Tässä suunnittelumallissa näkymät ja ohjaimet toteuttavat tarkkailijarajapinnan, jota käyttäen ne voivat rekisteröityä tarkkailemaan malleissa tapahtuvia muutoksia. Kun muutoksia tapahtuu, voivat näkymät ja ohjaimet käydä kysymässä mallilta sen muuttunutta dataa [KoMi05 s. 142].

17 Malli-näkymä-ohjain -arkkitehtuurityyliin liittyy myös eräitä ongelmia. Malli-näkymäohjain -arkkitehturityylin käyttö saattaa lisätä järjestelmän kompleksisuutta lisäten sen luokkia [KoMi05 s. 144]. Jotta järjestelmän monimutkaisuus ei kasvaisi liikaa, kannattaa ohjain- ja näkymäluokat antaa vain suuremmille käyttöliittymäkokonaisuuksille, kuten esimerkiksi dialogeille [KoMi05 s. 144]. Tarkkailija-suunnittelumallin soveltaminen malli-näkymä-ohjain -arkkitehtuurityylissä merkitsee usein suuria määriä päivityskutsuja, joka on ongelmallista erityisesti jos eri komponentit on hajautettu eri prosesseihin [KoMi05 s. 144]. Tarkkailijasuunnittelumallin soveltaminen saattaa altistaa tehottomuudelle: tarkkailijat joutuvat kysymään mallilta muuttunutta tietoa käyttäen yleisiä mallin operaatioita, mikä voi olla hidasta. Eri tarkkailijat joutuvat myös tekemään samantapaisia tai jopa samoja kyselyjä muutosten jälkeen [KoMi05 s. 144]. Toinen malli-näkymä-ohjain -arkkitehtuurityylin tyypillisistä ongelmista on näkymäja ohjainluokkien kiinteä liittyminen toisiinsa. Jos malli- ja ohjainluokat ovat kiinteästi toisiinsa liittyviä, on niitä vaikea käyttää uudelleen toisistaan irrallaan muissa yhteyksissä [KoMi05 s. 144]. Koska Malli-näkymä-ohjain -arkkitehtuurityyli mahdollistaa mallien uudelleenkäytön useissa tilanteissa, on se sopiva valinta graafisen käyttöliittymän toteutusmekanismiksi [KoMi05, s. 144]. Eräs malli-näkymä-ohjain -arkkitehtuurityylin sovellusalue ovat toiminnalliset web-sivut, joissa käyttäjälle näkyvä HTML-sivu on näkymä. HTMLsivun koodi joka ottaa vastaan tietoa käyttäjältä sekä käsittelee tiedon on ohjain. Esimerkiksi tietokannassa tai XML-tiedostoissa sijaitseva varsinainen tietosisältö on malli.

18 5 Yhteenveto Ohjelmiston perusrakennetta kutsutaan ohjelmiston arkkitehtuuriksi. Se määrittelee ohjelmiston komponentit ja niiden suhteet toisiinsa. Arkkitehtuurin täsmällinen määrittely ja kuvaaminen on tärkeä osa nykyaikaista ohjelmistontuotantoa ja ohjelmistotuotantoprosessia. Ilman määriteltyä ja kuvattua arkkitehtuuria on projektiryhmän vaikeaa muodostaa yhtenäistä kuvaa tuotettavan ohjelmiston rakenteesta. Arkkitehtuurityyli on koko järjestelmää luonnehtiva korkeimman abstraktiotason suunnitteluratkaisu. Arkkitehtuurityyliä apuna käyttäen voidaan suunnitella ohjelmiston rakenteellinen ja toiminnallinen runko. Se asettaa rajat ja säännöt tuotettavan ohjelmiston arkkitehtuurille. Arkkitehtuurityylejä on kehitetty erilaisten järjestelmien vaatimuksia ajatellen. Arkkitehtuurityyli, joka auttaa ohjelmiston rakennuspalasten ryhmittelyssä on keino välttää ohjelmiston rakenteen muotoutuminen liian monimutkaiseksi. On yleistä, että arkkitehtuurityyliä käytetään juuri tämän ongelman estämiseen. Tällöin ryhmittelyyn perustuvan arkkitehtuurityylin mukaisessa järjestelmässä järjestelmä on jaettu osajoukkoihin, joissa yhden joukon sisältämät järjestelmän komponentit ovat samassa suhteessa arkkitehtuurityylin kannalta. Palveluperustaiset arkkitehtuurityylit perustuvat roolijakoon. Rooleja on kaksi: palvelun tarjoajat ja niiden käyttäjät. Tällä hetkellä yksi käytetyimmistä arkkitehtuurityyleistä on palveluperustaisiin arkkitehtuurityyleihin kuuluva asiakaspalvelin-arkkitehtuuri. Sovellusaluekohtaisiin arkkitehtuurityyleihin kuuluu sellaisia arkkitehtuurityylejä, jotka ovat ajan kuluessa vakiintuneet tietyn sovellusalueen täsmäratkaisuiksi. Usein ohjelmistoa ei voida rakentaa ainoastaan yhtä arkkitehtuurityyliä käyttäen. On mahdollista käyttää monien eri arkkitehtuurityylien yhdistelmiä ohjelmiston arkkitehtuurin perustana.

19 Arkkitehtuurityylin oikea valinta ja käyttö selkeyttää ohjelmiston arkkitehtuurin muodostamista ja auttaa arkkitehtuurin hallinnassa. Väärin valittu arkkitehtuurityyli voi taas olla suurikin haitta ohjelmistoprojektille. Kuten perinteisessä rakennusarkkitehtuurissakin, voi väärin valittu arkkitehtuurityyli jopa estää oikeanlaisen lopputuotteen syntymisen. Goottilaisella tyylillä on vaikea tuottaa modernia tyyliä tavoittelevaa rakennusta, mutta se on omiaan Goottilaista tyyliä noudattavien rakennusten malliksi.

20 Lähteet AvZd05 Paris Avgeriou & Uwe Zdun, Architectural patterns revisited - a pattern language. EuroPloP, 2005. Bass98 Len Bass, Paul Clements & Rick Kazman, Software architecture in practice. Addison-Wesley, 1998. Busc96 Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad & Michael Stahl, Pattern-Oriented Software Architecture: A System of Patterns. John Wiley & Sons. Inc., 1996. GrSh94 David Garlan & Mary Shaw, An Introduction to Software Architecture. School of Computer Science, Carnegie Mellon University, Pittsburgh, 1994 KoMi05 Kai Koskimies & Tommi Mikkonen, Ohjelmistoarkkitehtuurit. Talentum, 2005.