6 Ohjelmistoarkkitehtuurit

Esipuhe Tämä teos on tarkoitettu yliopistotason opetusmateriaaliksi kursseille, joilla käsitellään ohjelmistoarkkitehtuureja. Sen kohderyhmänä ovat erityisesti opiskelijat, jotka perehtyvät syvällisesti ohjelmistotuotantoon tai ohjelmistotekniikkaan. Teoksen toivotaan antavan myös teollisuudessa työskenteleville ohjelmistoammattilaisille yleiskuvan ohjelmistoarkkitehtuurien keskeisistä teemoista. Koska teoksesta on haluttu tehdä kattava, monet sen sisältämistä asiakokonaisuuksista voidaan käsitellä vain pintapuolisesti. Toisaalta monesta tällaisesta asiakokonaisuudesta on jo nyt kirjoitettu kokonaisia oppikirjoja. Tämän teoksen tavoitteena on antaa tiivistetty esitys myös tällaisista aiheista. Tämän teoksen aihepiiri liittyy läheisesti ohjelmistotuotantoon. Oletamme, että lukijalla on perustiedot paitsi ohjelmoinnista yleensä myös ohjelmistokehitysprosesseista. Monessa kohdin oletamme myös, että lukija hallitsee ainakin pintapuolisesti olioparadigman ja UML:n (Unified Modeling Language). Kuten monet muut ohjelmistotekniset tuotokset, tämäkin teos on syntynyt kiinteässä yhteistyössä useiden tahojen kanssa, joita kaikkia yhdessä ja erikseen haluamme kiittää. Jan Bosch on ystävällisesti antanut käyttöömme materiaalia, jota olemme hyödyntäneet kirjan tekstissä. Maarit Harsu ja Tommi Myllymäki ovat auttaneet tuoterunkoja koskevan luvun kirjoittamisessa. Kirjan eri osia ovat ansiokkaasti kommentoineet Ilkka Haikala, Juha Hautamäki, Mika Korhonen, Tero Laine, Mika Pussinen, Petri Selonen ja Tarja Systä. Haluamme myös kiittää materiaalin erilaisia esiversioita opiskelussaan käyttäneitä opiskelijoita Tampereen teknillisen yliopiston ohjelmistoarkkitehtuurikurssilla vuosina 2000 2004 ja kurssien toteuttamiseen osallistunutta henkilökuntaa, sekä teollisuudessa pidettyjen koulutustilaisuuksien osallistujia, joiden kommentit on myös pyritty ottamaan huomioon teosta kirjoitettaessa. Lisäksi kiitämme

6 Ohjelmistoarkkitehtuurit Ohjelmistotekniikan laitoksen henkilökuntaa ja Practise-tutkimusryhmää ymmärryksestä proffien kirjaprojektin aikana sekä teollisuusyhteistyökumppaneitamme kannustuksesta. Kirjan kirjoittamista on tukenut Nokia Säätiön apuraha. Tampereella, 25.01.05 Kai Koskimies ja Tommi Mikkonen sähköposti: kai.koskimies@tut.fi tommi.mikkonen@tut.fi

7 Sisällys Esipuhe... 5 Sisällys... 7 1 Johdanto...15 1.1 Arkkitehtuuri ohjelmistokehityksessä...15 1.2 Mikä on ohjelmistoarkkitehtuuri?...18 1.2.1 Ohjelmistoarkkitehtuurin määritelmä...18 1.2.2 Arkkitehtuurin tehtävät...19 1.2.3 Arkkitehtuurin dokumentointi...20 1.3 Arkkitehtuuripainotteinen ohjelmistokehitysprosessi...20 1.4 Arkkitehtuurin käyttö toteutusvälineenä...23 1.5 Arkkitehtuurin ja organisaation yhteys...24 1.6 Arkkitehtuurinäkymät...24 1.7 Arkkitehtuurin abstraktiotasoista...25 1.8 Johdatus teoksen muihin lukuihin...26 1.9 Yhteenveto...27 1.10 Harjoitustehtäviä...27 2 Ohjelmistoarkkitehtuurin kuvaus...29 2.1 Arkkitehtuurikuvauksen merkitys...29 2.2 Arkkitehtuurikuvaukseen liittyvät käsitteet...31 2.3 Arkkitehtuurikuvauksen abstraktiotaso...32 2.4 Näkökulmat arkkitehtuurien kuvauksessa...35 2.5 Arkkitehtuurikuvausten tyypit...37 2.6 Arkkitehtuuriviipaleiden kuvaus...39 2.7 Arkkitehtuuridokumentit...41

8 Ohjelmistoarkkitehtuurit 2.8 Malliperustainen arkkitehtuuri... 45 2.9 Yhteenveto... 47 2.10 Harjoitustehtäviä... 47 3 Komponentit ja rajapinnat...53 3.1 Komponentit... 53 3.1.1 Komponentin määritelmä... 53 3.1.2 Komponentit arkkitehtuurin yksikköinä... 55 3.1.3 Komponentit ohjelmistokehityksen yksikköinä... 57 3.2 Rajapinnat... 57 3.2.1 Rajapinnan käsite... 58 3.2.2 Tarjotut ja vaaditut rajapinnat... 59 3.2.3 Rajapintojen määrittely... 61 3.3 Komponenttien räätälöinti... 66 3.3.1 Komponentin tilan muuttaminen... 67 3.3.2 Vaadittujen rajapintojen toteuttaminen... 68 3.3.3 Periytymisen avulla toteutettu räätälöinti... 68 3.4 Yhteenveto... 71 3.5 Harjoitustehtäviä... 72 4 Komponenttien vuorovaikutustekniikat...75 4.1 Komponentit ja niiden vuorovaikutus... 75 4.2 Rajapinnat... 76 4.3 Roolirajapinnat... 77 4.4 Usean komponentin välinen vuorovaikutus... 79 4.5 Kutsun siirtäminen... 81 4.6 Edustajakomponenttien käyttö... 83 4.7 Takaisinkutsut... 85 4.8 Tapahtumiin perustuva vuorovaikutus... 87 4.9 Rajapintariippuvuuksien poistaminen... 89 4.10 Luontiriippuvuus ja sen purkaminen... 92 4.11 Yhteenveto... 95 4.12 Harjoitustehtäviä... 95 5 Suunnittelumallit...101 5.1 Johdatus suunnittelumalleihin... 101

9 5.1.1 Mikä on suunnittelumalli?...102 5.1.2 Suunnittelumallit ohjelmistotekniikassa...102 5.1.3 Suunnittelumallin sisältö...105 5.2 Suunnittelumallien kuvaaminen...105 5.3 Antisuunnittelumallit...107 5.4 Esimerkki: Rekursiokooste-suunnittelumalli...109 5.4.1 Ongelma: hierarkkisen oliokokoelman hallinta...109 5.4.2 Vaihe 1: kooste ja lehdet...110 5.4.3 Vaihe 2: koosteen ja lehtien samaistaminen...110 5.4.4 Vaihe 3: erityyppiset oliot...111 5.4.5 Vaihe 4: koosteen eriyttäminen...112 5.4.6 Suunnittelumallin esittäminen...113 5.5 Suunnittelumallien edut ja ongelmat...116 5.5.1 Suunnittelumallien tarjoamat edut...116 5.5.2 Suunnittelumalleihin liittyviä ongelmia...117 5.6 Suunnittelumallit ja UML...118 5.7 Yhteenveto...119 5.8 Harjoitustehtäviä...119 6 Arkkitehtuurityylit...125 6.1 Arkkitehtuurityyli ryhmittelyn perustana...125 6.1.1 Kerrosarkkitehtuurit...126 6.1.2 Tietovuoarkkitehtuuri...132 6.2 Palveluperustaiset arkkitehtuurityylit...136 6.2.1 Asiakas-palvelin-arkkitehtuurit...136 6.2.2 Viestinvälitysarkkitehtuurit...139 6.3 Sovellusaluekohtaiset arkkitehtuurityylit...142 6.3.1 Malli-näkymä-ohjain -arkkitehtuurit...142 6.3.2 Tietovarastoarkkitehtuurit...145 6.3.3 Tulkkipohjaiset arkkitehtuurit...146 6.4 Esimerkki: auton polttoaineenkulutuksen valvontaohjelmisto...148 6.5 Arkkitehtuurityylit ja UML...150 6.6 Yhteenveto...151 6.7 Harjoitustehtäviä...152

10 Ohjelmistoarkkitehtuurit 7 Tuoterunkoarkkitehtuurit...157 7.1 Arkkitehtuurin rooli ohjelmistokehityksessä... 157 7.2 Tuoterunkoarkkitehtuurit ja niiden hyödyt... 160 7.2.1 Tuoterungon edut... 160 7.2.2 Tuoterunko investointina... 161 7.3 Tuoterungon rakentaminen ja evoluutio... 163 7.4 Ohjelmistokehitysprosessi tuoterunkoa käytettäessä.. 164 7.4.1 Prosessin yleiskuvaus... 164 7.4.2 Alustakehitysprosessi... 165 7.4.3 Tuotekehitysprosessi... 167 7.5 Muunneltavuus tuoterungossa... 168 7.5.1 Muunneltavuus vaatimustasolla... 168 7.5.2 Muunneltavuus suunnittelussa ja toteutuksessa... 171 7.5.3 Muunneltavuus testauksessa... 172 7.6 Tuoterunko ja organisaatio... 173 7.7 Tuoterunkoarkkitehtuurin kerrosmalli... 175 7.7.1 Resurssialusta... 176 7.7.2 Arkkitehtuurialusta... 177 7.7.3 Sovellusalusta... 177 7.7.4 Sovelluskerros... 178 7.8 Esimerkki: auton valvonnan tuoterunko... 179 7.9 Tuoterunkojen ongelmia... 181 7.10 Yhteenveto... 183 7.11 Harjoitustehtäviä... 184 8 Ohjelmistokehykset...187 8.1 Johdatus ohjelmistokehyksiin... 187 8.1.1 Mikä on ohjelmistokehys?... 187 8.1.2 Erikoistamisrajapinta... 189 8.1.3 Kehykset ja suunnittelumallit... 190 8.1.4 Hollywood-periaate... 191 8.1.5 Erikoistamismekanismit... 191 8.1.6 Kehykset ohjelmistokehitysparadigmana... 194 8.2 Kehyslajit... 194 8.2.1 Abstraktit kehykset... 195

11 8.2.2 Muunneltavat kehykset...196 8.2.3 Plugin-kehykset...198 8.2.4 Koottavat kehykset...199 8.3 Kehysten strukturointi...202 8.3.1 Kerroksittaiset kehykset...202 8.3.2 Hierarkkiset kehykset...203 8.3.3 Komponenttikehysten käyttö...205 8.4 Kehysten suunnittelu...206 8.4.1 Kehysten suunnittelu ja oliosuunnittelu...206 8.4.2 Kehysten iteratiivinen rakentamisprosessi...208 8.4.3 Kehyksen kehitysprosessin vaiheet...209 8.4.4 Kerroksittaisen kehyksen suunnittelu...212 8.4.5 Erikoistamismallit...213 8.5 Kehysten riskejä...213 8.5.1 Tekninen vaativuus ja monimutkaisuus...215 8.5.2 Kehysten yhdistely...215 8.5.3 Monoliittisuus...216 8.5.4 Laadullinen varianssi...216 8.5.5 Dokumentointi...216 8.6 Yhteenveto...217 8.7 Harjoitustehtäviä...217 9 Arkkitehtuurien arviointi...221 9.1 Johdatus arkkitehtuurin arviointiin...221 9.1.1 Arvioinnin kohdentaminen...222 9.1.2 Arvioinnin perusteet...222 9.1.3 Arvioinnin sidosryhmiä...224 9.2 Arkkitehtuurin arviointi osana ohjelmistoprosessia...225 9.3 Arkkitehtuurin arviointimenetelmät...227 9.4 ATAM...229 9.4.1 Esittelyosio...229 9.4.2 Analyysiosio...230 9.4.3 Testausosio...232 9.4.4 Raportointiosio...233

12 Ohjelmistoarkkitehtuurit 9.5 Esimerkki: auton kunnonvalvontaohjelmiston arkkitehtuurin arviointi... 234 9.6 Arvioinnin ongelmia... 238 9.7 Yhteenveto... 239 9.8 Harjoitustehtäviä... 239 Kirjallisuusviitteet...241 Hakemisto...247

OSA I Perusteet

1 Johdanto Ohjelmistoarkkitehtuurit ovat muodostuneet selvästi omaksi ohjelmistotekniikan alueekseen verrattain myöhään, vasta 1990-luvun loppupuoliskolla. Sitä ennen ohjelmistoarkkitehtuureja pidettiin lähinnä vain korkeamman tason suunnitteluna. Nykyisin ohjelmistoarkkitehtuurien merkitys ohjelmistotekniikan alueena kasvaa jatkuvasti. Uusia arkkitehtuuriaiheisia oppikirjoja julkaistaan, niitä käsitteleviä uusia konferenssisarjoja perustetaan ja arkkitehtuuriin liittyvät kysymykset yleistyvät alan opetuksessa ja tutkimuksessa. 1.1 Arkkitehtuuri ohjelmistokehityksessä Ohjelmallisesti toteutettujen sovellusten ymmärtämisessä ja rakentamisessa on liikuttu primitiivisistä välineistä kohti suurempia kokonaisuuksia (kuva 1.1). Alussa sovellukset pyrittiin näkemään lähinnä muistipaikkoihin ja rekistereihin talletettujen lukujen ja merkkijonojen käsittelynä (esim. assembler-kielet). Sitten opittiin tunnistamaan näiden muodostamia rakenteita, joita toteuttamaan kehitettiin kieliin rakenteisia tietotyyppejä (esim. C, Pascal). Vastaavasti tunnistettiin Sovelluskäsitteet Luvut, merkkijonot ("nimi") Tietorakenteet ("osoite") Toiminnot ("talletus") Tietoabstraktiot ("tili") Palveluyksiköt ("tilin hallinta") Sovellusalue ("pankkiliiketoiminta") Toteutuskäsitteet Muistipaikat, rekisterit Rakenteiset tietotyypit Aliohjelmat Luokat Komponentit, agentit, rajapinnat Tuoterungot, kehykset, alustat Kuva 1.1: Ongelma-alueen ja toteutustekniikan käsitetason siirtyminen kohti suurempia kokonaisuuksia

16 Ohjelmistoarkkitehtuurit Johdanto 17 toimenpiteitä, joita näille rakenteille tuli suorittaa; nämä esitettiin kielissä aliohjelmina. Sitten opittiin näkemään sovelluksissa suurempia käsitteitä, joihin liittyy sekä tietoa että käyttäytymistä. Näitä toteuttamaan kehitettiin kieliin tietoabstraktio eri muodoissa. Tietoabstraktio kokoaa yhteen tietorakenteita ja niihin liittyviä operaatioita, ja antaa mahdollisuuden käsitellä tietoa vain näiden operaatioiden kautta. Eräs tietoabstraktion muoto on olioparadigman tuoma luokkakäsite, jossa abstraktiin tietotyyppiin on yhdistetty laajennettavuus (periytyminen). Tämän jälkeen havaittiin tarve muodostaa suurempia kokonaisuuksia loogisesti yhteen kuuluvista palveluista, jotka esitettiin tietyt rajapinnat toteuttavina komponentteina (tai agentteina, jos palvelut olivat proaktiivisia). Vähitellen yksittäisen sovelluksen käsite hämärtyi toteutuksen kannalta: eri sovellukset jakoivat yhteisiä komponentteja ja kirjastoja. Lisäksi opittiin ymmärtämään, että monilla myös eri sovellusalueille tarkoitetuilla ohjelmistoilla on olennaisesti sama perusarkkitehtuuri, ja kehitettiin ohjelmistoalustoja (platform), jotka toteuttavat tällaisen arkkitehtuurin tarvitseman yleisen infrastruktuurin. Edelleen ymmärrettiin, että eri sovellukset ovat usein läheistä sukua toisilleen sekä sovelluksen toteutusrakenteen että toiminnallisuuden kannalta. Tällä tavoin tunnistettiin tietyille sovellusalueille sovellustai tuoteperheitä (product/application family), joiden toteuttamisen tueksi kehitettiin lähinnä olioparadigman sisällä sovelluskehyksen käsite. Ohjelmistojen luominen tapahtuu näin yhä enemmän arkkitehtuuritason käsitteiden ja toteutusmekanismien pohjalta. Tähän suuntaukseen on vaikuttanut ennen muuta järjestelmien jatkuva monimutkaistuminen ja kasvaminen, uudelleenkäytön merkityksen kasvaminen ja yleinen arkkitehtuuritason ratkaisuja korostava teknologian kehitys (esimerkiksi mobiili-, hajautus- ja komponenttiteknologiat). Arkkitehtuurin merkitys näkyy monessa asiassa ohjelmistokehitysprosessissa. Inkrementaalinen ja rinnakkainen ohjelmistokehitys saavutetaan yleensä arkkitehtuuritason ratkaisuilla. Arkkitehtuuri on tärkeä työnjaon kannalta: vain arkkitehtuuritasolla tunnistettavat osat järjestelmää ovat mielekkäitä työn jakamisen yksiköitä. Arkkitehtuuri on olennainen myös testauksen ja ylläpidon kannalta: hyvä arkkitehtuuri jakaa ohjelmiston osiin, jotka on helppo testata erillisinä ja jotka paikallistavat ylläpidossa tarvittavat muutostyöt. Arkkitehtuuri antaa korkean abstraktiotason näkymän ohjelmistoon, mikä mahdollistaa aikaisempaa monimutkaisempien järjestelmien tarkastelun ja myös erilaisten sidosryhmien välisen kommunikoinnin järjestelmästä. Arkkitehtuurin eriytyminen omaksi alueekseen on tukenut erilaisten standardiratkaisujen kehittämistä ja dokumentoimista arkkitehtuuritasolle, jolloin myös arkkitehtuurien käytölle ja määrittelemiselle voidaan asettaa selkeät perussäännöt. Arkkitehtuurien painoarvoa kasvattaa se, että arkkitehtuurin määritteleminen ja dokumentointi mahdollistaa järjestelmän arvioinnin joidenkin kriittisten tekijöiden osalta jo hyvin varhaisessa vaiheessa ohjelmistokehitystä, jolloin järjestelmän muuttaminen on vielä halpaa. Koska arkkitehtuuri toimii yleisenä ohjenuorana ohjelmistokehitykselle ja ohjelmiston ylläpidolle, arkkitehtuurivaiheessa siirrytään ongelman käsitteistöstä ratkaisun käsitteistöön. Epäonnistuneesta järjestelmästä voidaan usein syyttää arkkitehtuuria. Huono arkkitehtuuri voi ilmetä monin eri tavoin järjestelmän kehittämisen, käyttämisen ja ylläpidon aikana. Pahin mahdollisuus on, että järjestelmää ei pystytä lainkaan toteuttamaan tarkoitetussa laajuudessa kyseisessä organisaatiossa. Arkkitehtuuri voi esimerkiksi tehdä olemassa olevasta teknologiasta oletuksia, jotka eivät pidä paikkaansa. Vastaavasti arkkitehtuuri voi tehdä toteuttamisen niin vaikeaksi, ettei sitä pystytä tekemään suunnitellussa aikataulussa. Arkkitehtuurin heikkouksien takia järjestelmä ei ehkä pysty tehokkaasti suoriutumaan kuin pienistä tieto- tai käyttäjämääristä, tai arkkitehtuuri saattaa tehdä esimerkiksi käyttöliittymästä niin hitaan, ettei sitä voi järkevästi käyttää. Arkkitehtuuri voi tehdä myös järjestelmän testauksesta tai ylläpidosta vaikeaa ja kallista, jos se ei tue osien erillistä testausta tai muutosten tekemistä. Jos arkkitehtuuri ei esimerkiksi selkeästi erota ympäristöstä (esim. käyttöjärjestelmä) riippuvia osia, järjestelmän siirtäminen uuteen ympäristöön voi olla vaikeaa. Epäonnistuminen voi tapahtua myös ensimmäisen version onnistuneen käyttöönoton jälkeen. Koska arkkitehtuuri on keskeinen tekijä ohjelmistojen uudelleenkäytössä, epäonnistuminen arkkitehtuurisuunnittelussa voi käytännössä estää suunnitellun laajuisen uudelleenkäytön.

18 Ohjelmistoarkkitehtuurit Johdanto 19 1.2 Mikä on ohjelmistoarkkitehtuuri? Vaikka ohjelmistoarkkitehtuureista puhutaan paljon, usein niillä tarkoitetaan hivenen eri asiaa puhujan kokemusmaailman mukaisesti. Tarkastelemme seuraavassa lähemmin ohjelmistoarkkitehtuurin määritelmää. 1.2.1 Ohjelmistoarkkitehtuurin määritelmä Ohjelmistoarkkitehtuureille on esitetty useita erilaisia määritelmiä kirjallisuudessa. IEEE:n arkkitehtuurien kuvaamista koskeva standardi määrittelee ohjelmistoarkkitehtuurin järjestelmän perusorganisaatioksi, joka sisältää järjestelmän osat, niiden keskinäiset suhteet ja niiden suhteet ympäristöön sekä periaatteet, jotka ohjaavat järjestelmän suunnittelua ja evoluutiota (IEEE 2000). Olennaista määritelmässä on, että arkkitehtuuri ei kata pelkästään järjestelmän jakamista osiin, vaan myös näiden osien välisiä suhteita ja niiden kehittymistä. Koska suhteet ovat usein luonteeltaan ajoaikaiseen käyttäytymiseen liittyviä, arkitehtuuri koskee paitsi rakennetta myös käyttäytymistä. Toisaalta arkkitehtuuri ei koske ainoastaan ohjelmiston staattista rakennetta (koodin rakennetta), vaan myös ohjelman suorituksen aikaisia rakenteita, esimerkiksi dynaamisia oliorakenteita. Yksinkertaisuuden vuoksi ohjelmiston arkkitehtuuria tarkastellaan usein jostakin tietystä näkökulmasta, esimerkiksi tiedostorakenteen, loogisen rakenteen, prosessirakenteen jne. näkökulmista. Olennaista on myös, että arkkitehtuuriin katsotaan kuuluvan tiettyjen ratkaisujen perustelu, ei ainoastaan kuvaus. Lisäksi arkkitehtuuriin yleensä liittyy joukko sääntöjä ja periaatteita, jotka säätelevät sitä, miten järjestelmiä kehitetään tähän arkkitehtuuriin perustuen. Säännöt, joita tietyn arkkitehtuurin mukaan rakennettavassa järjestelmässä on noudatettava, voivat koskea teknologian käyttöä (esim. käytettävä JavaBeans-komponentteja), algoritmien valintaa (esim. lajittelussa käytettävä quicksortia), tietorakenneratkaisuja (esim. joukot toteutettava kahteen suuntaan linkitettyinä listoina), sekä suunnittelu- ja toteutusmalleja (esim. kommunikointiin käytettävä Observer-suunnittelumallia). Voidaankin ajatella, että arkkitehtuuri on järjestelmän perustuslaki. Sitä on noudatettava järjestelmää rakennettaessa, ja sitä voi- daan muuttaa vain erittäin painavilla perusteilla. Samaa asiaa korostavat Catalysis-suunnittelumenetelmän kehittäjät d'souza ja Wills, jotka määrittelevät arkkitehtuurin joukoksi päätöksiä, jotka estävät toteuttajia ja ylläpitäjiä olemasta tarpeettoman luovia (D Souza ja Wills 1998). Toisin sanoen arkkitehtuuri määrittelee rajat, joiden puitteissa järjestelmää on rakennettava ja ylläpidettävä. Arkkitehtuuri määrittelee siis järjestelmän ytimen, joka pysyy olennaisesti samana kehityksen ja ylläpidon aikana. Niitä osia, jotka eivät kuulu tähän ytimeen, voidaan vapaasti muunnella tarkoituksenmukaisemmiksi. Tämä ajattelutapa pätee erityisen hyvin nk. tuoterunkoarkkitehtuureihin, joihin tutustumme myöhemmin tässä teoksessa; tällöin vaihtuvat osat vastaavat sovelluskohtaisia osia. Tämä määritelmä on sikäli yleinen, että se sallii myös arkkitehtuurit, joissa tärkein osa ei ole varsinainen ohjelmistokuvaus, vaan esimerkiksi jokin tietty menettelytapa, jonka avulla ohjelmistoa voidaan muunnella. Esimerkiksi jokin tietty käyttöjärjestelmä voi vaatia, että kaikki resurssit näkyvät sovellusohjelmille niitä hallinnoivien palvelinten kautta. Tällaisia periaatteita kutsutaan joskus myös arkkitehtuurien filosofioiksi. 1.2.2 Arkkitehtuurin tehtävät Arkkitehtuurin tehtävänä on ottaa kantaa keskeisiin ohjelmiston ratkaisuihin, jotka voivat koskea paitsi yleistä jakamista osiin myös osien välistä komminkointitapaa, prosesseja ja niiden välistä kommukointia, tiedon saantitapoja ja pysyvyyden toteuttamista, toiminnallisuuden sijoittelua eri järjestelmän osiin, hajautetun järjestelmän fyysistä rakennetta, järjestelmän kykyä käsitellä suuria tieto- ja käyttäjämääriä, tehokkuutta, varautumista tulevaisuuden tarpeisiin, uudelleenkäytettävyyttä jne. Koska monia näistä ratkaisuista on vaikea arvioida etukäteen, joudutaan arkkitehtuurin toimivuutta usein kokeilemaan osin puutteellisella tai keinotekoisesti rakennetulla järjestelmällä. Näiden kokeilujen systematisointi johtaa ns. inkrementaaliseen kehitykseen. Tällöin ensimmäinen vaihe joutuu tyypillisesti ottamaan kantaa perusarkkitehtuuriin, ja muut vaiheet tuovat olemassaolevaan runkoon enemmän ja enemmän toiminnallisuutta (Boehm 1988). Arkkitehtuuri perustuu ohjelmiston ositukseen tietyllä periaatteella. Ohjelmistojen dekompositio (osiin pilkkominen) voidaan teh-

20 Ohjelmistoarkkitehtuurit Johdanto 21 dä monilla perusteilla, esimerkiksi toiminnallisuuteen, yleisyyteen, hajautukseen, käsitemalliin, joustavuusnäkökulmaan ym. perustuen. Aspektiperustainen ohjelmointi pyrkii strukturoimaan ohjelmiston paitsi perinteisen arkkitehtuurin, myös erilaisten arkkitehtuurin määrittelemien rakenneyksiköiden yhteisten aspektien (kuten vaikkapa virheidenkäsittely, tiedon pysyvyys, hajautus, tietty järjestelmän ulkoisesti havaittava piirre jne.) kannalta (Filman et al. 2005). Koska tällaiset aspektit ovat yleensä riippumattomia komponenttijaosta, aspektit edustavat komponentteja läpileikkaavia (cross-cutting) viipaleita järjestelmästä. Näin järjestelmä voidaan samanaikaisesti strukturoida useassa eri ulottuvuudessa. Kärjistettynä tämä näkemys johtaa ajatukseen, että ohjelmistot ovat perusluonteeltaan moniulotteisia rakenteita ja että mikään yksittäinen komponenttijako ei pysty tavoittamaan tätä ominaisuutta. 1.2.3 Arkkitehtuurin dokumentointi Jos arkkitehtuuri ei ole selkeästi dokumentoitu, sitä ei ole oikeastaan olemassa: arkkitehtuuri materialisoituu kuvauksena. Vaikka järjestelmän dokumentoimattomasta arkkitehtuurista voidaan puhua, eri henkilöt tekevät tällöin todennäköisesti hyvin erilaisia olettamuksia siitä, mikä kuuluu järjestelmän arkkitehtuuriin ja mikä ei. Vaikka järjestelmällä olisikin alun perin ollut selkeä arkkitehtuuri, arkkitehtuurikuvauksen puuttuminen johtaa jossain vaiheessa järjestelmän ja sen arkkitehtuurin rapautumiseen (Clements et al. 2003). Periaatteena tulisi olla, että ohjelmistoprojektia, joka ei ole saavuttanut selvää arkkitehtuurin kuvausta, ei pitäisi päästää jatkamaan: projektilta puuttuu sen perustuslaki, jolloin sen kehitys saattaa helposti muuttua anarkiaksi. 1.3 Arkkitehtuuripainotteinen ohjelmistokehitysprosessi Arkkitehtuuripainotteisessa ohjelmistokehitysprosessissa korostetaan arkkitehtuurin suunnittelua ja arviointia keskeisenä vaiheena ennen siirtymistä yksityiskohtaiseen suunnitteluun ja toteutukseen. Arkkitehtuuri pyritään johtamaan inkrementaalisesti ja iteratiivisesti lähtien arkkitehtuurin kannalta merkittävistä vaatimuksista. Arkkitehtuuriin vaikuttavat toisaalta kaikkein keskeisimmät toiminnalliset vaatimukset ja toisaalta laadulliset (ei-toiminnalliset) vaatimukset. Prosessi etenee tyypillisesti siten, että ensimmäinen versio arkkitehtuurista tehdään toiminnallisten vaatimusten pohjalta, ja sitä arvioidaan sitten vasten laadullisia vaatimuksia. Tarpeen vaatiessa arkkitehtuuria uudistetaan niin, että kukin laadullinen vaatimus täyttyy. Kun kaikki laadulliset vaatimukset on saatu näin täytettyä, järjestelmän perusarkkitehtuuri on valmis. Tämän pohjalta edetään yksityiskohtaiseen suunnitteluun, toteutukseen ja testaukseen, jolloin saadaan ensimmäinen, keskeisimmät toiminnalliset vaatimukset täyttävä toteutus. Tämän jälkeen tarkastellaan sekundaarisia toiminnallisia vaatimuksia ja toteutetaan ne perusarkkitehtuurin pohjalle. Tässäkin vaiheessa voidaan vielä havaita tarvetta muuttaa arkkitehtuuria. Toteutus tehdään yleensä inkrementaalisesti vaatimus (tai kokokoelma toisiinsa liittyviä vaatimuksia) kerrallaan. Mikäli sovelluksen käyttöönoton jälkeen tulee uusia vaatimuksia tai vaatimukset muuttuvat, joudutaan prosessi periaatteessa käymään läpi alusta lähtien: jos esimerkiksi uudet vaatimukset ovat arkkitehtuurin kannalta merkittäviä, joudutaan myös arkkitehtuuri muuttamaan tai ainakin arvioimaan uudestaan. Jos arkkitehtuurisuunnittelussa sovelletaan käyttötapauksiin (use case) pohjautuvaa prosessia, primääriset ja sekundääriset toiminnalliset vaatimukset saadaan jakamalla käyttötapaukset arkkitehtuurin kannalta kriittisiin ja vähemmän kriittisiin. Käyttötapaukset voivat tällöin suoraan edustaa vaatimuksia. Kuvassa 1.2 esitetty prosessimalli on monessa suhteessa idealistinen mutta antaa kuitenkin karkean mallin, jota voidaan soveltaa käytännöllisissä prosessimalleissa. Vaikka arkkitehtuurin suunnittelun lähtökohtana ovat yleensä tärkeimmät toiminnalliset vaatimukset, lopullisen arkkitehtuurin muodon sanelevat kuitenkin usein pikemmin ei-toiminnalliset, laatuun liittyvät vaatimukset ("*ilities"). Varsinkin joustavuus ja muunneltavuus sekä toisaalta tehokkuus ja muistin kulutus ovat keskeisiä, arkkitehtuuriin usein vastakkaisesti vaikuttavia tekijöitä. Toisaalta voidaan kysyä, minkä suhteen halutaan olla joustavia, sillä kaikkien ohjelmiston ominaisuuksien kannalta joustavuuden vaatiminen on epärealistista. Jos joustavuuden kohdetta ei määritellä etukäteen, voi tuloksena olla järjestelmä, joka on periaatteessa joustava mutta jossa

22 Ohjelmistoarkkitehtuurit Johdanto 23 Uusia tai muuttuneita vaatimuksia Käyttöönotto Toissijaiset toiminnalliset vaatimukset Testaus Arkkitehtuurin kannalta merkittävät vaatimukset Alustava arkkitehtuurisuunnittelu Toteutus Alustava arkkitehtuuri Arkkitehtuurin muunnos Vaatimusanalyysi Yksityiskohtainen suunnittelu Arvioi laatuominaisuus Toiminnalliset perusvaatimukset Laatuvaatimukset Perusarkkitehtuuri Kuva 1.2: Arkkitehtuuriperustainen ohjelmistokehitysprosessi väärät tässä tapauksessa siis vakiona pysyvät asiat voidaan muuttaa helposti, mutta käytännössä muuttuvat asiat vaativat enemmän työtä. Vaikka arkkitehtuurisuunnittelussa on periaatteessa kyse kokoelmasta yhteensopiva ratkaisuita, joiden avulla voidaan täyttää kaikki vaatimukset, toteutuksista on usein luettavissa, että jokin vaatimus tai jotkin vaatimukset ovat selvästi dominoineet arkkitehtuurisuunnittelua. Tyypillisesti jokin arkkitehtoonisesti merkittävistä vaatimuksista on niin paljon tärkeämpi kuin muut, että se on käytännössä johtanut tiettyyn perusarkkitehtuuriin, johon muut vaatimukset on sitten pakotettu. Arkkitehtuurin eräs olennainen tehtävä onkin kuvata, kuinka (tai missä määrin) arkkitehtoonisesti merkittävät vaatimukset täyttyvät annetulla arkkitehtuurilla. Tässä mielessä arkkitehtuuri voidaan nähdä kokoelmana korkean tason suunnitteluratkaisuja, jotka pyrkivät tiettyjen, erityisesti laadullisten vaatimusten ja niistä seuraavien ongelmien ratkaisuun. ei OK OK 1.4 Arkkitehtuurin käyttö toteutusvälineenä Toinen puoli arkkitehtuuripainotteista ohjelmistokehitystä on, että uusia ohjelmistoja toteutetaan yhä enemmän perustuen olemassaolevaan arkkitehtuuriin. Tämä johtuu yleisestä pyrkimyksestä lisätä ohjelmistojen uudelleenkäyttöä, joka ilmenee erilaisina ohjelmistoalustoina. Kun ohjelmistoalustalla on arkkitehtuuri, joka sovelluskehittäjän täytyy ottaa huomioon, arkkitehtuurille tulee toteutusvälineen rooli, joka on verrattavissa ohjelmointikielen rooliin. Arkkitehtuurin tarjoamat välineet ovat vain korkeammalla tasolla kuin ohjelmointikielen tarjoamat välineet. Sovelluskehittäjän kannalta olennaiseksi ongelmaksi tulee pikemmin se, miten sovelluksen vaatimukset saadaan toteutettua alustan tarjoamalla arkkitehtuurilla, kuin se, miten ne saadaan toteutettua tietyllä ohjelmointikielellä. Tässä roolissa arkkitehtuurilta edellytetään ominaisuuksia, jotka tavallisesti liitetään ohjelmointikieliin. Arkkitehtuurin tulee olla määritelty täsmällisesti ja täydellisesti (syntaksi ja semantiikka), ja sen dokumentoinnin tulee olla käyttäjälle suuntautunutta. Arkkitehtuurilla voidaan myös ajatella olevan staattiset ja dynaamiset oikeellisuussäännöt kuten ohjelmointikielillä (esimerkiksi tyyppisäännöt). Työkalujen kannalta kiinnostava havainto on, että arkkitehtuurille voidaan rakentaa samantapaisia tukiympäristöjä kuin ohjelmointikielille, tukemaan esimerkiksi arkkitehtuurin oikeellisuussääntöjen noudattamista, koodin generointia, visualisointia, takaisinkääntämistä ym. Suuntaus kohti arkkitehtuuritason toteutusvälineistöä antaa aiheen puhua uudesta ohjelmointiparadigmasta, arkkitehtuuriperustaisesta ohjelmoinnista. Tarkastellaan esimerkkinä Enterprise Java Beans -teknologiaa (EJB). Kun sovellus tehdään EJB:n pohjalle, olennainen suunnitteluongelma on se, miten sovelluksen käsitteet toteutetaan EJB:n tarjoamilla välineillä esimerkiksi mitkä asiat toteutetaan nk. istuntopavulla (session bean), mitkä nk. säilykepavulla (entity bean) ei niinkään miten Javalla toteutetaan tietyt asiat. Toinen esimerkki on graafisen käyttöliittymän toteutus esimerkiksi Swingin (Java-ympäristön GUI-kehys) pohjalle. Tässäkään tapauksessa ongelmana ei ole niinkään Javan käyttö sinänsä, vaan Swingin tarjoamien mekanismien käyttö toteutusvälineenä.

24 Ohjelmistoarkkitehtuurit Johdanto 25 1.5 Arkkitehtuurin ja organisaation yhteys Järjestelmän arkkitehtuurilla on myös läheinen yhteys järjestelmää kehittävään tai ylläpitävään organisaatioon. Mielekkäästi toimiva organisaatio alkaa muistuttaa rakenteeltaan järjestelmän arkkitehtuuria. Tämä johtuu viime kädessä siitä, että tyypillisesti komponentti, joka on arkkitehtuurin perusyksikkö, annetaan yhden henkilön kehitettäväksi. Toisiinsa liittyvät komponentit pyritään antamaan tietylle ryhmälle, joka saa näin vastuulleen tyypillisesti jonkin alijärjestelmän. Tämä tulee selvästi näkyviin esimerkiksi tuoterunkoarkkitehtuurien kohdalla: ohjelmistoalustasta vastaa tavallisesti oma organisaation yksikkö, kun taas tuotekohtaisesta ohjelmistosta vastaa oma yksikkö. Vastaavasti organisaatio, joka vuodesta toiseen ylläpitää samaa ohjelmistoa, yleensä jakaa ylläpidon arkkitehtuurin sallimalla tavalla. Yleisesti ilmiö tunnetaan nimellä Conwayn laki (Conway 1968). Ohjelmiston kehittämiseen liittyy useita sidosryhmiä (stakeholder), joita ovat esimerkiksi kehittäjät, ylläpitäjät, testaajat ja käyttäjät. Kullakin sidosryhmällä on yleensä oma näkökulmansa ohjelmistoon, ja tästä näkökulmasta seuraavat odotukset ja vaatimukset. Usein eri sidosryhmien vaatimukset ovat keskenään ristiriitaisia. Arkkitehdin keskeisenä tehtävänä on määritellä arkkitehtuuri, joka tuottaa vaatimusten välille siedettävän kompromissin riittävän monen sidosryhmän kannalta. 1.6 Arkkitehtuurinäkymät Arkkitehtuureja voidaan tarkastella eri näkökulmista (viewpoints). Tässä yhteydessä kutsumme arkkitehtuurin kuvausta tietystä näkökulmasta (arkkitehtuuri)näkymäksi (view). Tätä on havainnollistettu kuvassa 1.3. Kukin näkymä mallintaa jonkin asian järjestelmästä. Kun kyse on saman järjestelmän eri näkymistä, niillä on luonnollisesti paljon riippuvuuksia: jos jotain kohtaa muutetaan yhdessä näkymässä, täytyy mahdollisesti useita kohtia muuttaa muissa näkymissä. Yhdessä näkymät muodostavat kattavan, osittain päällekkäisen kuvauksen järjestelmän arkkitehtuurista. Erilaisilla työkaluilla voidaan jossain määrin tuottaa automaattisesti näkymiä olemassaolevista järjestel- Näkymä Näkökulma Näkymä Kuva 1.3: Arkkitehtuurinäkymiä Näkymä Järjestelmä mistä (reverse engineering) tai koodia näkymien perusteella (code generation). Työkalut voivat myös varmistaa, että näkymät ovat keskenään yhtäpitäviä. Tarkastelemme eri näkökulmia lähemmin luvussa 2. 1.7 Arkkitehtuurin abstraktiotasoista Järjestelmän arkkitehtooninen malli Arkkitehtuurilla ymmärretään usein ainoastaan ohjelmointitason rakenteita. Tämä on kuitenkin hyvin rajoittunut näkökulma, sillä arkkitehtuurin tarjoamat edut vaativat yleensä useiden erilaisten abstraktiotasojen hyödyntämistä. Hyvin korkealla abstraktiotasolla jonkin järjestelmäkategorian perusrakenne voidaan antaa esimerkiksi nk. arkkitehtuurityylinä tai referenssiarkkitehtuurina; tällainen kuvaus määrittelee arkkitehtuuriin liittyvät käsitteet yleisin tai sovellusaluekohtaisin termein, ottamatta kantaa yksittäiseen järjestelmään. Toisaalta arkkitehtuurikuvaus voidaan antaa konkreettisen järjestelmän lähdekoodin rakenteena eri tarkkuustasoilla riippuen käyttötarkoituksesta. Viime aikoina eri abstraktiotasoilla olevien arkkitehtuurikuvausten väliset transformaatiot ovat herättäneet suurta mielenkiintoa.

26 Ohjelmistoarkkitehtuurit Johdanto 27 Eräs konkreettinen hanke on OMG:n (Object Management Group) MDA-hanke, malliperustainen arkkitehtuuri (Model-Driven Architecture) (Object Management Group 2003). Malliperustaisen arkkitehtuurin tavoitteena on tarjota ohjelmoijalle mahdollisuus rakentaa abstrakteja kuvauksia järjestelmän arkkitehtuurista, ja tämän jälkeen generoida sopiva toteutustason arkkitehtuuri jollekin tietylle sovellusalustalle noudattaen tämän nimenomaisen alustan käytäntöjä. Generointi voi tapahtua joko automaattisesti tai suunnittelijan avustamana. Malliperustaisen arkkitehtuurin olennaisena piirteenä voidaankin pitää eri tasojen välisiä mallitransformaatioita, joiden avulla saadaan abstraktimpia tai yksityiskohtaisempia näkymiä arkkitehtuuriin. Samalla arkkitehtuurin merkitys korostuu, sillä se on esitettävä tarkasti ja yksiselitteisesti transformaatioiden mahdollistamiseksi. 1.8 Johdatus teoksen muihin lukuihin Teos koostuu kolmesta toisiaan täydentävästä kokonaisuudesta. Näistä ensimmäinen on johdanto ohjelmistoarkkitehtuurien luonteeseen ja peruskäsitteisiin; osa koostuu tästä johdannosta ja seuraavasta luvusta, jossa tarkastellaan arkkitehtuurien kuvaamista yleisesti. Lukujen yhteinen tavoite on tarjota riittävä käsitteellinen ja terminologinen perusta, jotta seuraavien osien läpikäyminen olisi mahdollista. Teoksen toinen osa käsittelee arkkitehtuureja lähtien liikkeelle arkkitehtuurin peruselementeistä ja siitä, ja millaisilla ratkaisuilla hallitaan niiden välisiä suhteita. Tässä arkkitehtuuri nähdään pienessä mittakaavassa: käymme läpi joukon tekniikoita, joiden avulla tiettyjä komponenttien suhteisiin liittyviä ongelmia voidaan ratkaista. Ohjelmistoarkkitehtuuri on hyvin pitkälle komponenttien välisten riippuvuuksien hallintaa, jolloin arkkitehtuuriratkaisuilla pyritään näiden riippuvuuksien poistamiseen tai heikentämiseen. Toisen osan luvut esittelevät arkkitehtuurin perusyksiköt, komponentit ja rajapinnat sekä kuvaavat erilaisia tapoja hallita komponenttien välisiä riippuvuuksia. Koska käytännössä riippuvuuksia hallitaan usein nk. suunnittelumallien (design pattern) avulla, myös tämä alue tulee suhteellisen kattavasti käsiteltyä tässä osassa: käymme läpi erityyppisiä suunnittelumalleina(kin) esitettyjä perusratkaisuita. Lisäksi suunnittelumallin käsite esitellään erikseen omassa lu- vussaan. Osan tavoitteena on tarjota konkreettista apua käytännön ongelmiin arkkitehtuurisuunnittelussa. Teoksen kolmas ja viimeinen osa keskittyy arkkitehtuuriin suuressa mittakaavassa, jolloin arkkitehtuurin käsitettä tarkastellaan järjestelmätasolla pikemmin kuin yksittäisten komponenttien tasolla. Arkkitehtuuriratkaisujen osalta tarkastelemme kaikkein korkeimmalla järjestelmätasolla sovellettavia ajatusmalleja, nk. arkkitehtuurityylejä, jotka määräävät järjestelmän perusluonteen. Osa sisältää myös tuoterunkoarkkitehtuurien esittelyn ja niiden suositun olioperustaisen toteutustekniikan, sovelluskehysten, kuvauksen. Lisäksi tarkastelemme arkkitehtuurien arviointia ja esittelemme systemaattisen tavan suorittaa arkkitehtuurikatselmus järjestelmän laatuominaisuuksien selvittämiseksi. 1.9 Yhteenveto Ohjelmistoarkkitehtuuri on osa ohjelmistosuunnittelua; kaikki suunnitteluasiat eivät kuitenkaan ole arkkitehtuuria. Komponenttien väliset suhteet kuuluvat arkkitehtuuriin, mutta niiden sisäiset asiat eivät. Arkkitehtuuriin sisältyvät myös ratkaisujen perustelut. Ohjelmistoarkkitehtuuri voidaan nähdä rakennettavan järjestelmän "perustuslakina", joka antaa rajat yksityiskohtaiseen suunnitteluun ja toteutukseen. Arkkitehtuuriperustainen ohjelmistokehitys korostaa arkkitehtuurin roolia kehitysprosessia ohjaavana suunnitteluartifaktina. Ohjelmistoarkkitehtuuri voidaan kuvata eri asioita korostavista näkökulmista käsin ja eri abstraktiotasoilla. 1.10 Harjoitustehtäviä 1.1 Suuressa ohjelmistoprojektissa (tai tuotelinjassa) voi työskennellä useita satoja ohjelmistosuunnittelijoita. Miten mielestäsi arkkitehtuurisuunnittelu tulisi sisällyttää osaksi ohjelmistosuunnittelua tällaisessa ympäristössä?

28 Ohjelmistoarkkitehtuurit 1.2 Mitä ongelmia huonosti määritelty arkkitehtuuri voi aiheuttaa toteutusvaiheessa? Millainen ohjelmistokehitysprosessin tulisi olla, jotta näiltä ongelmilta vältyttäisiin? 1.3 Etsi www:stä kolme ohjelmistoarkkitehtuurin määritelmää (esim. http://www.sei.cmu.edu/architecture/definitions.html), joita pidät tavalla tai toisella oikeaan osuvina (älä kuitenkaan valitse tässä kirjassa esitettyä määritelmää). Vertaile määritelmiä keskenään ja tässä kirjassa annetun määritelmän kanssa. Millainen ohjelmistoarkkitehtuurin määritelmä vastaisi eniten sitä intuitiivista käsitystä, joka sinulla on tähän mennessä ohjelmistoarkkitehtuureista? 1.4 Kuvaa jonkin tuntemasi järjestelmän (esim. jokin harjoitustyö) arkkitehtuuri yhdellä vapaamuotoisella tavalla. Miten hyvin tämä kuvaus vastaa tehtävässä 1.3 esitettyjä ohjelmistoarkkitehtuurin määritelmiä? 1.5 Etsi ja suomenna seuraavien käsitteiden määrittelyt www:stä: a) product-line architecture, b) architectural style, c) design pattern, d) component, e) application framework. 1.6 Argumentoi puolesta tai vastaan seuraavaa väitettä: Ohjelmistojen rakentamisessa pitäisi korkean tason suunnittelu antaa tehtäväksi vain ohjelmistoarkkitehdin tutkinnon suorittaneille henkilöille, samaan tapaan kuin rakennusten suunnittelu annetaan vain arkkitehdin koulutuksen saaneiden henkilöiden tehtäväksi. 1.7 Argumentoi puolesta tai vastaan seuraavaa väitettä: Ohjelmistoarkkitehdin koulutuksen pitäisi poiketa ohjelmistosuunnittelijan koulutuksesta, samaan tapaan kuin rakennusarkkitehdin ja rakennesuunnittelijan koulutus eroavat toisistaan. 1.8 Minkälaisia muunnoksia mielestäsi tarvitaan arkkitehtuurien abstraktiotasojen välille malliperustaista arkkitehtuuria toteutettaessa? Mitkä tasot mielestäsi tarvitsevat tukea suunnittelijalta, ja mitkä voidaan toteuttaa automaattisesti? Minkälaiset työkalut voisivat auttaa malliperustaisuuden toteuttamisessa?

2 Ohjelmistoarkkitehtuurin kuvaus Ohjelmistoarkkitehtuurin kuvaus on keskeinen dokumentti, jossa arkkitehtuuri materialisoituu. Tarkastelemme tässä luvussa arkkitehtuurikuvauksen merkitystä ja erilaisia lähestymistapoja arkkitehtuurin kuvaukseen. 2.1 Arkkitehtuurikuvauksen merkitys Ohjelmiston arkkitehtuuri on tärkein ohjelmistoa luonnehtiva informaatio. Tästä syystä ohjelmiston eri sidosryhmien välinen kommunikointi koskee usein arkkitehtuuriin liittyviä kysymyksiä. Jotta kaikilla olisi sama käsitys ohjelmiston arkkitehtuurista, arkkitehtuurilla tulisi olla mahdollisimman kattava ja yksiselitteinen kuvaus. Vain tällaiseen kuvaukseen pohjautuen on mahdollista ilmaista täsmällisiä arkkitehtuuria (ja ylipäänsä koko järjestelmää) koskevia faktoja. Arkkitehtuurilla on näin tärkeä merkitys järkevän kommunikaation mahdollistavana ohjelmistoartefaktina, joka antaa paitsi keskeiset ohjelmistoratkaisut myös käsitteistön ja sanaston, johon pohjautuen järjestelmästä voidaan puhua. Nykyisin teollisuudessakin ymmärretään arkkitehtuurikuvausten merkitys, ja niistä on tullut keskeinen dokumentti ohjelmistokehitysprosesseissa. Ohjelmistoarkkitehtuurien kuvaus on kuitenkin vielä verrattain uusi ja edelleen kehittyvä ohjelmistotekniikan alue. Ohjelmiston arkkitehtuuri on pikemmin järjestelmää koskeva spesifikaatio kuin jokin järjestelmän ominaisuus, joka voitaisiin päätellä suoraan järjestelmästä. On tosin olemassa (puoli)automaattisia tekniikoita, joilla arkkitehtuuritason informaatiota voidaan tuottaa takaisinmallintamalla (reverse engineering) järjestelmää, mutta täl-

30 Ohjelmistoarkkitehtuurit Ohjelmistoarkkitehtuurin kuvaus 31 laiset tekniikat tuottavat tyypillisesti vain arkkitehtuurin kuvaukseen tarvittavaa tietoa, eivät varsinaisia arkkitehtuurikuvauksia. Käytännöllisistä syistä on mahdollista ajatella, että arkkitehtuurin kuvaus on ohjelmistoarkkitehtuurin konkreettinen ilmenemismuoto: arkkitehtuuria ei ole olemassa ilman sen kuvausta. Tämä pätee myös silloin, kun itse järjestelmä on olemassa. Tällaisessa tilanteessa järjestelmän arkkitehtuurista puhuminen on erityisen vaarallista, koska eri ihmiset voivat olemassaolevan järjestelmän perusteella helposti tehdä erilaisia tulkintoja siitä, mikä on järjestelmän arkkitehtuuri ja mitkä asiat kuuluvat siihen. Varsinaisen rakenteen lisäksi arkkitehtuuria siis käytetään myös selittämään järjestelmää. Toisaalta arkkitehtuurin kuvaus voidaan antaa eri tarkkuustasoilla. Olennaista on, että kukaan ei tee arkkitehtuurista oletuksia, jotka menevät yli sen kuvauksen. Tätä on usein kuitenkin vaikea välttää, jos kuvaus annetaan hyvin abstraktilla tasolla. Arkkitehtuurikuvaus voitaisiin antaa esimerkiksi seuraavasti: järjestelmä on J2EE-teknologiaan ja asiakas-palvelin-arkkitehtuuriin perustuva liiketoimintasovellus. Tämä on sinänsä validi kuvaus, koska se perustuu käsitteisiin, joiden voi olettaa olevan yleisesti tunnettuja. Sen perusteella voidaan keskustella järjestelmän perusratkaisusta hyvin yleisellä tasolla, vaikkapa sanomalla, että järjestelmä sopisi paremmin web-palveluksi (web service). Mitään tarkempia oletuksia esimerkiksi siitä, mitkä osat ovat asiakaspäässä ja mitkä palvelinpäässä ei voi tämän perusteella tehdä. Siitä huolimatta monet, jotka tietävät jotakin järjestelmän tarkoitetusta toiminnallisuudesta, tekevät todennäköisesti mielessään mahdollisesti tiedostamattaan erilaisia tätä koskevia oletuksia. Arkkitehtuurikuvaus on keskeinen kommunikointiväline arkkitehdin ja toteutus- tai ylläpitoryhmän välillä. Jos arkkitehtuurin tarkka kuvaus on olemassa ainoastaan arkkitehdin päässä, ryhmä tulee varmasti tekemään ratkaisuja, jotka ovat ristiriidassa tuon kuvauksen kanssa. Tällaiset ongelmat voivat tulla esiin vasta hyvin myöhäisessä vaiheessa, ja ne voivat maksaa yritykselle paljon. Arkkitehdin velvollisuutena on siksi huolehtia siitä, että ryhmällä on käytettävissään arkkitehtuurin kuvaus, joka kertoo täsmällisesti, mitkä asiat kuuluvat arkkitehtuuriin ja mitä arkkitehtuuri sallii. Arkkitehtuurin kuvaustekniikat liittyvät läheisesti työkalutukeen. Työkalutukea ei tarvita ainoastaan arkkitehtuurimallien ja -näkymien tuottamiseen, vaan myös varmistamaan, että nämä mallit ovat keskenään ristiriidattomia ja että yksityiskohtaisessa suunnitte- lussa ja toteutuksessa noudatetaan näitä malleja. Työkaluja voidaan myös käyttää tuottamaan automaattisesti arkkitehtuurinäkymiä toisten mallien tai olemassaolevan lähdekoodin perusteella. Tässä suhteessa standardoidut kuvaustekniikat, kuten UML, tarjoavat hyvän pohjan työkalukehitykselle. Ohjelmistotekniikan pitkän tähtäyksen suuntauksena on lisätä ohjelmistojen kuvauksen abstraktiotasoa, ja tuottaa toimivia järjestelmiä yhä korkeamman tason kuvauksista. Arkkitehtuurikuvaus on korkeimman abstraktiotason ratkaisukuvaus, joten voisi ajatella, että tällaisesta kuvauksesta voitaisiin joskus tuottaa toimivia järjestelmiä automaattisesti. Tämä edellyttää kuitenkin arkkitehtuurikuvaukselta täsmällisyyttä ja kattavuutta, joka on toistaiseksi mahdollista vain hyvin rajatussa mielessä, esimerkiksi jollakin kapealla sovellusalueella. 2.2 Arkkitehtuurikuvaukseen liittyvät käsitteet Jotta ymmärrettäisiin mitä asioita ohjelmistoarkkitehtuurin kuvaukseen sisältyy, on tarkasteltava käsitteitä, jotka tavalla tai toisella liittyvät arkkitehtuureihin. IEEE on julkaissut arkkitehtuurien kuvaamisesta standardin (IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, IEEE Std 1471-2000), jossa annetaan arkkitehtuureja koskeva käsitekaavio UML:n luokkakaaviona. Kuvassa 2.1 on esitetty hieman yksinkertaistettu versio tästä kaaviosta. Kuvan 2.1 mukaisesti jokainen järjestelmä täyttää yhden tai useampia tehtäviä (mission) toimintaympäristössään. Järjestelmällä on sidosryhmiä (stakeholder), joista kullakin on omat tavoitteensa ja huolenaiheensa (concern) järjestelmän suhteen. Jos järjestelmällä on arkkitehtuuri, sillä täytyy olla myös täsmälleen yksi arkkitehtuurikuvaus. Huomaa, että vaikka tämä malli esittää arkkitehtuurin ja arkkitehtuurikuvauksen erillisinä käsitteinä, arkkitehtuuri voi mallin mukaan olla olemassa vain, jos siitä on kuvaus. Arkkitehtuurikuvaus muodostuu erilaisista näkymistä (view), jotka seuraavat tiettyjä näkökulmia (viewpoint). Näkökulma määrää tietyn esitysmuodon ja tavoitteen kuvaukselle, näkymä on yksittäiselle järjestelmälle annettu osittainen arkkitehtuurikuvaus, joka noudattaa jonkin näkökulman esitysmuotoa. Tarkastelemme näkökulmia ja näkymiä lähemmin jatkossa.

32 Ohjelmistoarkkitehtuurit Ohjelmistoarkkitehtuurin kuvaus 33 Environment has Mission fulfills System 1..* 1..* has an identifies 1..* Architecture 1 described by Architectural description 1..* organized by provides selects Rationale Konkreettinen arkkitehtuuri Referenssiarkkitehtuuri Metaarkkitehtuuri Yksityiskohtainen suunnittelu Organization * 1..* Stakeholder 1..* View has 1..* 1..* is addressed to conforms to Concern Viewpoint 1..* Tuoterunkoarkkitehtuuri Tuotearkkitehtuuri Lähdekoodi Kuva 2.1: IEEE:n standardin mukainen (yksinkertaistettu) käsitemalli arkkitehtuureille Kuva 2.2: Arkkitehtuurityypit ja niiden väliset suhteet Toisaalta arkkitehtuurikuvaus muodostuu malleista (esimerkiksi UML-kaavioista), joita näkymät hyödyntävät. Kuhunkin näkymään voi liittyä useita malleja, ja malli voi esiintyä useassa näkymässä. Arkkitehtuurikuvauksen tulee antaa myös perustelu (rationale), joka kertoo, miksi kyseiset ratkaisut on tehty. 2.3 Arkkitehtuurikuvauksen abstraktiotaso Tietojenkäsittelytehtävä voidaan kuvata eri abstraktiotasoilla esimerkiksi epäformaalina algoritmina, pseudokoodiesityksenä, parametroituna koodirunkona (esim. C++:n template) tai suoritettavana ohjelmakoodina. Samaan tapaan ohjelmistoarkkitehtuuri voidaan antaa esimerkiksi yleisenä, abstraktina ratkaisumallina tietyn tyyppisille järjestelmille, jonkin järjestelmäperheen yhteisen arkkitehtuurin kuvauksena, tai yksittäisen konkreettisen järjestelmän kuvauksena. Arkkitehtuurikuvausta annettaessa on syytä tehdä selväksi, minkä tyyppisestä arkkitehtuurista on kyse. Kuvassa 2.2 on esitetty eri arkkitehtuurityypit ja niiden väliset suhteet UML:n luokkakaaviona. Riippuvuussuhde (katkonuoli) tarkoittaa, että lähde noudattaa kohdetta (esimerkiksi tuotearkkitehtuuri noudattaa tuoterunkoarkkitehtuuria). Kuvaan on otettu mukaan myös yksityiskohtainen suunnittelu ja lähdekooditoteutus, jotka eivät luonnollisesti ole arkkitehtuuritason kuvauksia. Meta-arkkitehtuuri ei kuvaa ohjelmistoarkkitehtuuria itseään, vaan käsitteistön ja mekanismit, joilla varsinaisia arkkitehtuurikuvauksia annetaan. Meta-arkkitehtuuri voi näin kuvata esimerkiksi komponenttikategorioita ja niiden välisiä suhteita. Esimerkki meta-arkkitehtuurista on UML:n profiili, joka on annettu (tietyn tyyppisten) arkkitehtuurien kuvaamiseen. Profiili mekanismina on UML:n metamallin laajennos, joka erikoistaa joitakin UML:n standardielementtejä ja antaa niitä koskevia ylimääräisiä rajoitteita. Profiili voisi esimerkiksi erikoistaa UML:n komponenttielementin uudeksi mallielementiksi, joka edustaa tiettyä komponenttikategoriaa. Yritys voi antaa meta-arkkitehtuurikuvauksen ohjenuorana, jonka noudattamista edellytetään yrityksen kehittämien järjestelmien arkkitehtuurikuvauksissa. Meta-arkkitehtuuria voi abstraktissa mielessä ajatella kielioppina, jonka mukaisesti varsinaisia arkkitehtuureja kuvataan. Referenssiarkkitehtuuri ei myöskään kuvaa mitään konkreettista järjestelmää, vaan antaa yleisen ratkaisumallin tietyn tyyppisten järjestelmien tai niiden osien arkkitehtuureille. Toisin kuin meta-arkkitehtuuri, referenssiarkkitehtuuri kuvaa arkkitehtuuriratkaisun, mutta abstraktilla tasolla liittämättä sitä mihinkään todelliseen järjestelmään. Esimerkiksi yleiset arkkitehtuurityylit ja -mallit, joita käsit-

34 Ohjelmistoarkkitehtuurit Ohjelmistoarkkitehtuurin kuvaus 35 telemme myöhemmin tässä kirjassa, voidaan esittää referenssiarkkitehtuurina. Samoin on usein mielekästä antaa sovellusaluekohtaisia (tai jopa yrityskohtaisia) referenssiarkkitehtuureja, jotka kuvaavat tietyllä sovellusalueella hyviksi havaittuja arkkitehtuuriratkaisuja ja niihin liittyviä erikoiskäsitteitä. Konkreettinen arkkitehtuuri esittää yksittäisen ohjelmiston arkkitehtuurin. Esimerkiksi tietyn sovelluksen arkkitehtuuridokumentti antaa näin aina konkreettisen arkkitehtuurin, joskin siinä voidaan viitata eri referenssi- ja meta-arkkitehtuureihin, joita konkreettinen arkkitehtuuri noudattaa. Sekä konkreettinen arkkitehtuuri että referenssiarkkitehtuuri noudattavat aina jotakin meta-arkkitehtuuria, vaikka tätä ei välttämättä tiedostettaisi. Arkkitehtuurikuvaus nimittäin perustuu aina joihinkin käsitteisiin, joiden oletetaan olevan tunnettuja, ja nämä käsitteet muodostavat meta-arkkitehtuurin. Jos esimerkiksi UML:ää käytetään arkkitehtuurikuvauksiin, meta-arkkitehtuurina on UML:n metamalli. Jos arkkitehtuurikuvaus perustuu UML:n profiileihin, metaarkkitehtuurina on tämän metamallin eräs laajennus. Jos kuvaukseen käytetään erityistä arkkitehtuurin kuvauskieltä (ADL, Architecture Description Language), meta-arkkitehtuurina on tämän kielen spesifikaatio. Mitä erikoistuneempia käsitteitä meta-arkkitehtuuri tarjoaa, sitä enemmän se rajoittaa kuvattavia arkkitehtuureja, mutta toisaalta sitä enemmän se myös tukee arkkitehtuurikuvausten antamista rajoitetulla alueella. Periaatteessa on mahdollista antaa meta-arkkitehtuuri, joka tukee yhden ainoan järjestelmän arkkitehtuurin kuvausta. Tuoterunkoarkkitehtuuri kuvaa toisaalta ohjelmistoalustan arkkitehtuurin ja toisaalta antaa säännöt yksittäisten ohjelmistotuotteiden rakentamiseen alustan pohjalle. Edellisen kannalta tuoterunkoarkkitehtuuri on siis konkreettinen arkkitehtuuri, jälkimmäisen kannalta tuoterunkoarkkitehtuuriin saattaa usein sisältyä meta-arkkitehtuurin piirteitä. Palaamme tuoterunkoarkkitehtuureihin luvussa 7. Tuotearkkitehtuuri on yksittäisen ohjelmistotuotteen arkkitehtuuri. Tällainen tuote voi olla rakennettu tuoterungon päälle, jolloin se noudattaa tuoterunkoarkkitehtuuria, tai se voi olla täysin itsenäinen sovellus. Kummassakin tapauksessa tuotearkkitehtuuri on konkreettinen. Arkkitehtuurikeskeisessä ohjelmistokehityksessä arkkitehtuuria noudatetaan yksityiskohtaisessa suunnittelussa, toteutuksessa ja ylläpidossa. Parhaassa tapauksessa noudattamista valvotaan työkalujen avulla. Kuvan 2.2 "noudattaa"-suhteet (katkonuoli) ilmaisevat, millaisia arkkitehtuuriin liittyviä tarkistuksia ohjelmistokehitysprosessissa voi tehdä: lähdekoodi voidaan tarkistaa yksityiskohtaista suunnittelua vasten, suunnittelu voidaan puolestaan tarkistaa konkreettista arkkitehtuuria vasten, ja konkreettinen arkkitehtuuri voidaan lopuksi tarkistaa meta-arkkitehtuuria vasten. 2.4 Näkökulmat arkkitehtuurien kuvauksessa Ohjelmistoarkkitehtuurin tulisi aikaisemman määritelmän mukaan kertoa, millaisia komponentteja järjestelmässä on ja millaisia suhteita niillä on keskenään. Komponentteihin liittyy kuitenkin niin monenlaisia suhteita ja puolia, että näin yleisen määritelmän perusteella on vaikea tietää, mitä asioita arkkitehtuurin kuvaukseen tulisi sisällyttää ja millainen rakenne kuvauksella tulisi olla. Tätä varten on otettu käyttöön käsite näkökulma (viewpoint): arkkitehtuurikuvaus koostuu tiettyjen näkökulmien mukaisista näkymistä (view) järjestelmään. Tässä näkökulma tarkoittaa yleistä, järjestelmästä riippumatonta tapaa kuvata tiettyä arkkitehtuurin kannalta merkityksellistä ohjelmistojen ominaisuutta. Näkymä on varsinainen järjestelmästä riippuva kuvaus, joka noudattaa jotakin näkökulmaa. Näkökulman ja näkymän suhde on samantapainen kuin esimerkiksi luokan ja olion: näkymä on näkökulman ilmentymä tietyn järjestelmän yhteydessä. Näkökulma on ortogonaalinen järjestelmän strukturoinnin kanssa: mitä hyvänsä osaa järjestelmästä voidaan periaatteessa katsoa mistä hyvänsä näkökulmasta, joskin jotkin näkökulmat saattavat käytännössä olla mielekkäämpiä tietyn järjestelmän osan tapauksessa kuin toiset. Nk. 4+1-malli esittää viisi näkökulmaa ohjelmistoarkkitehtuurien kuvaamiseen (Kruchten 1995). Tästä mallista on esitetty myöhemmin hieman toisistaan poikkeavia versioita. Järjestelmän luonteesta riippuen jotkin 4+1 -mallin näkökulmista ovat keskeisiä, jotkin toiset taas vähemmän tärkeitä. On toisaalta mahdollista, että jossakin järjestelmässä on syytä ottaa myös muita näkökulmia arkkitehtuurin kuvaukseen. Tässä teoksessa seuraamme 4+1-mallia, mutta otamme mukaan uuden näkökulman, joka on olennainen erityisesti tuoterunkoarkkitehtuurien yhteydessä. Tämä kuudes näkökulma (variaatio- eli muuntelunäkökulma) käsittelee sitä, miten arkkitehtuuri tukee jär-