TIE355 Ohjelmistoarkkitehtuurit, Bosch QASAR (Keskeneräinen)

Transkriptio

1 TIE355 Ohjelmistoarkkitehtuurit, Bosch QASAR (Keskeneräinen) Jonne Itkonen 21. maaliskuuta Yleistä Tämä on vuoden 2003 ohjelmistoarkkitehtuurien kurssin keskeneräisestä monisteesta irrotettu osa, jossa käsitellään Jan Boschin ja kumppaneiden QASAR-menetelmää ohjelmiston arkkitehtuurin luontiin. Lisäbonuksena on monisteen arkkitehtuurikieliä käsittelevä osuus, myös keskeneräisenä. Vastuuvapautus on voimassa, elikkäs tekstissä on todennäköisesti joitain virheitä. Korjailen niitä 2005 vuoden luennoilla, jahka esille tulevat. Tätä monistetta ei ole tarkoitettu ainoaksi itseopiskelun lähteeksi. Tämä vain kokoaa ja tuo esille joitain piirteitä joistain ohjelmistoarkkitehtuurien eri aspekteista. 2 Tyylit Katso lähde [4]. Seuraavassa on arvioitu tyylejä Boschin profiilien mukaan. 2.1 Oliotyyli Boschin [1] mukaan: Suorituskyky Olio-ohjelmia pidetään suorituskyvyltään heikompina kuin perinteisiä ohjelmia, mutta tämä johtuu alkuaikojen olio-kielistä ja ympäristöistä. Jos taas miettii hetken olioiden mukanaan tuomia teknologioita, on päivänselvää, ettei väite voi pitää paikkaansa: Jos teknologiat mahdollistavat tarkemman erikoistamisen, erikoistapauksien paremman huomioonottamisen, miten teknologia voisi tuottaa suorituskyvyltään heikompia ohjelmia. Usein (olio-ohjelmien) huono suorituskyky onkin suoraa seurausta sovelluskehittäjän huonosta ohjelmointitaidosta. Toki osa syystä on vieritettävä huonojen kääntäjätoteutusten niskaan. Suorituskyvyn kanssa kannattaa huomioida ylläpidettävyys, jotka varsin usein vaikuttavat toisiaan vastaan. Kuitenkin ylläpidettävyyden kannalta olisi hyvä, jos ylläpito vaikuttaisi vain harvoihin olioihin, kuin on myös suorituskyvyn kannalta, silloin kun mielellään yleisimmät käyttötapaukset tulisi suunnitella niin, että ne käyttäisivät (ts. kuormittaisivat) mahdollisimman pientä määrää olioita. Tässä valossa suorituskyky ja ylläpidettävyys näyttäisivät olevan lähellä toisiaan. Olio-ohjelmien naiivi hajauttaminen on Boschin mielestä valitettavan yleistä. Sen sijaan, että hajautettaisiin ohjelma tapahtumien (operaatioiden?) mukaan, hajautetaankin oliot. Jälkimmäinen, huonompi, tapa johtaa suureen määrään [context switch] ja synkronointipisteitä käyttötapauksissa, eli huonoon suorituskykyyn. 1

2 Ylläpidettävyys Tämähän on olio-ohjelmoinnin markkinointitermien kuningas! Kaikki olio-ohjelmat ovat helposti ylläpidettäviä ja vieläpä uudelleenkäytettäviäkin. Kuitenkin, oikein tehdyille olioille tämä toimii. Inhibiittori: Olion tulee tietää kohdeolion viite. Jos kohdeolion viite tai tyyppi on kovakoodattu luokkaan tai olioon, tulee tästä ongelmia. Tämän vastustamisessa voidaan myös mennä yli, hyvänä esimerkkinä suunnittelumallit. Luotettavuus Aika neutraali, yhtenä ongelmana se, että ongelmien käsittely tulee pakottaa olion rajojen sisään. Toisaalta ne rajat pitävät myös ongelmat sisällään. AOP, meta, jnpp. Turvallisuus Koska reaalimaailma on esimerkkinä, tämän pitäisi olla ok. Varmuus Kapselointi ja tiedon suojaus takaavat tämän, toisaalta tiedon fragmentoituminen toimii sekä vastaan että myötä. Toisaalta on myös huomioitava kyvykkyyksien luontainen toteutuminen oliojärjestelmissä. 2.2 Putket ja suodattimet Boschin [1] mukaan: Suorituskyky Suodattimet ovat oikein hyviä hajautusyksiköitä ja putkien luoma kapea liittymä johtaa harvoihin synkronointipisteisiin. Tämä voi kuitenkin johtaa myös huonoon suorituskykyyn, jos suodattimet tekevät vain pienen työn jolloin [context switch] määrä kasvaa suureksi. Ylläpidettävyys Kaksipiippuinen juttu taas: Toisaalta järjestelmän konfiguroitavuus on hyvä ja konfiguraation muutos jopa ajonaikaisesti mahdollista, mutta vaatimusten muuttaminen aiheuttaa usein muutoksia moniin filttereihin samanaikaisesti. Bosch äityy jopa sanomaan kokemuksen syvällä rintaäänellä, ettei putki-suodatin-tyyli sovi ylläpidettävyydeltään vaativiin järjestelmiin. Luotettavuus riippuu suuresti järjestelmän topologiasta, joten mitään yleistä on siitä hankala sanoa. Tosin suodattimien luonne ketjuttua saa helposti aikaan johtopäätöksen, että järjestelmä on enintään yhtä luotettava kuin sen heikoin lenkki. Turvallisuus Tähän sopii sama päättely kuin edelliseen. Koska laskenta riippuu useista komponenteista, pienikin virhe ketjun alkupäässä voi kasvaa valtavaksi kohden loppua. Toisaalta se, että tulos tulee harvasta suodattimesta tekee tuloksen tarkkailusta helpompaa. Varmuus Tyylin järjestelmät ovat rajallisia ja hyvin määriteltyjä, joten tiedon varmistus, autorisointi ja salaus on helposti toteutettavissa. 2.3 Kerrosrakenne Boschin [1] mukaan: Suorituskyky Koska jako kerroksiin tapahtuu abstraktiotason eikä toiminnallisuuden mukaan, hajoavat toiminnot useisiin kerroksiin. Tämä johtaa taas suorituskyvyn heikkenemiseen, mistä esimerkkinä taas kommunikointiprotokollat, jotka vaikka esitetäänkin kerrosjärjestelmänä harvoin sellaisena toteutetaan. Kuten olioilla, naiivi tapa hajauttaa kerrosjärjestelmä on kerros kerrokselta. Parempi olisi hajauttaa tapahtumittain ja tehdä kerroksista [re-entrant, suomi rapistuu, snif]. Jälkimmäinen tapa johtaa parempaan suorituskykyyn. [hmm, yllä hajauttaa viittaa sanaan concurrency, ei distributed] Ylläpidettävyys Jos kerroksien välillä ei ole turhia sidoksia, on ylläpidettävyys kerrosjärjestelmillä hyvä. Jos taas sidoksia on, esimerkiksi toiminnot hajautuneena useisiin kerroksiin, voi ylläpito vaikeutua huomattavasti. Luotettavuus Jos alemmassa kerroksessa tapahtuu virhe, välittyy se ylempiin kerroksiin. Toisaalta ylemmissä kerroksissa voidaan paremmin varautua virhetilanteisiin, sillä niissä on yleensä parempi käsitys kokonaistilanteesta. Turvallisuus Kuten piipuille ja filttereille. Lisäksi voidaan kahden kerroksen väliin laittaa järjestelmän toimivuutta tarkkailevia kerroksia parantamaan järjestelmän turvallisuutta. Varmuus Kuten yllä, järjestelmään voi helposti lisätä tietoturvakerroksia. 2

3 2.4 Tietovarasto Boschin [1] mukaan: Suorituskyky Suorituskyky ei ole tämän mallin vahvimpia puolia. Paljon aikaa menee taustatoimintaan, esimerkiksi varaston tilan muutosten tarkkailuun, tai useamman KS:n koettaessa käsitellä samaa tietoa. Myos se, ettei KS:ien suoritusjärjestys ole sidottu, saattaa aiheuttaa suorituskyvyn heikkenemistä. Kuitenkin myös tehokkaita tietovarastoarkkitehtuureja on toteutettu, vielapä reaaliaikasovelluksiin. Ylläpidettävyys Tyylin mukaiset järjestelmät ovat erittain ylläpidettaviä. Ainut hieman jäykempi komponentti on kontrolloiva osa järjestelmää, mutta tämäkin voidaan toteuttaa niin, ettei edes tiedon esitysmuodon muutos (tietyissa rajoissa) aiheuta ongelmia (tiedon metamallit). Kuitenkin, mitä tehokkaammaksi viilattu järjestelmä, sitä enemmän sen ylläpidettävyys kärsii. Luotettavuus Toisaalta tyylin mukaiset järjestelmät ovat luotettavia hajautetun rakenteensa ansiosta, toisaalta juuri järjestelmän toiminnan tarkan kuvauksen puute heikentää sen luotettavuutta. Turvallisuus Hajautettu rakenne tekee järjestelmästä hieman turvattoman, saattaahan joku osa järjestelmästä muuttaa tietoa niin, että tieto ei ole enää kunnossa. Viallisesti toimivan osan löytäminen on vaikeaa toiminnan tarkan kuvauksen puuttuessa. Varmuus Vaikka tiedon säilyttäminen yhdessä paikassa tekee tiedon turvaamisesta hieman selkeämpää, aiheuttaa järjestelmän dynaaminen luonne riskin järjestelmän turvallisuudelle. 2.5 Implisiittinen kutsu Boschin [1] mukaan: Suorituskyky Kuten tietovarastotyylissä. Lisäksi jos toiminnassa tarvitaan apuna tietoa toista komponenttia, generoituu ja käsitellään joka kerta (ainakin) kaksi tapahtumaa. Tämä saattaa johtaa toiminnan pirstoutumiseen, joka taas heikentää suorituskykyä ja ylläpidettävyyttä. Toiminnan pirstoutumiseen voidaan jossain määrin vaikuttaa eksplisiittisellä järjestelmän konfiguroinnilla. Ylläpidettävyys Ajonaikainen järjestelmän muokattavuus voi edesauttaa ylläpidettävyyttä, jos komponenttimalli on kunnossa, kuten oliomalli oliotyylissä. Odotettavissa olevien muutosten tulisi kohdistua vain pieneen osaan komponentteja. Luotettavuus Kuten olioille ja tietovarastoille. Yhtenä etuna mahdollisuus viestiä kaikille komponenteille virheellisestä toiminnasta. Turvallisuus Kuten oliotyylille. Varmuus Kuten oliotyylille. 3 Yleistä 3.1 Perinteinen ohjelmistokehitys Perinteisesti ohjelmistokehityksessä on pyritty toteuttamaan yksi ohjelma ajallaan budjetissa pysyen. Sitä, kuinka ohjelma tulee muuntumaan ja kehittymään ei ole pahemmin pohdittu, saati mahdollisuutta tehdä kerralla useampi ohjelma. Näistä piirteistä on yleensä aiheutunut vain toimitusajan ja budjetin ylittymistä, järjestelmän laadun laskua, ylläpitokulujen kasvua ja kilpailukyvyn heikkenemistä. Valitettavasti Bosch ei juuri perustele näitä havaintojaan. Jonkinlaisena lumivyörynä ne voitaneen kuitenkin nähdä: kun aikataulut ja budjetti uhkaavat ylittyä, karsitaan laadusta, joka johtaa suurempaan ylläpidon tarpeeseen, joka taas johtaa suurempaan budjetin ylittymiseen ja työntekijöiden loppuunpalamiseen. Aikaa ei myöskään jää bugeja korjatessa uusille innovaatioille, jolloin jäljellejääneetkin työntekijät vaihtavat rauhallisempiin ympäristöihin. Näistä epäkohdista saadaankin hyvät tavoitteet ohjelman kehitykselle, tietty toimivan sovelluksen lisäksi. 3

4 Ohjelmistoja kehittäessä tulisi pyrkiä pitämään kehitys- ja ylläpitokustannukset alhaisina, laatu korkeana ja toimitusaika ohjelmalle suunnitelmista asiakkaan tietokoneeseen mahdollisimman lyhyenä. Yksi perinteinen ratkaisu on ohjelmistokomponentit. 3.2 Komponentit ratkaisuna Ohjelmistojen uudelleenkäyttö komponentteina ei ole mikään kovin uusi keksintö, sillä tätä ehdotti McIlroy jo vuonna Tätä ohjelmistotekniikan pyhää päämäärää on sen jälkeen pidetty hyvänä vaihtoehtona edellälueteltujen ongelmien korjaamiseen. Boschin mukaan tässä tavoitteessa onnistuneita komponentteja ovat käyttöjärjestelmät, tietokannanhallintajärjestelmät, kääntäjät, graafiset käyttöliittymät, komponenttien välisen vuorovaikutuksen standardien toteutukset, sekä uusimpana verkkopalvelimet ja -selaimet. Lista komponenteista saattaa näyttää oudolta, mutta komponenttien elinkaaren pohdinta auttaa ymmärtämään sen. Alussa komponentti on ollut kiinteä osa ohjelmaa. Seuraavassa vaiheessa on huomattu sen eriävyys muusta ohjelmasta. Komponentti on eriytetty omaksi osakseen, ja sen yleistämistä on tutkittu. Siitä on tehty markkinoitava kokonaisuus, joka sitten lopulta suuren yhtiön toimesta on integroitu osaksi järjestelmää. Monet muistavat tämän parhaiten graafisen käyttöliittymän, www-selaimen ja Microsoftin kohdalta. Josko uudelleenkäytettävyys tavallaan näiden komponenttien kohdalla onkin onnistunut, sovellusalueen komponenttien kohdalla se ei ole. Komponentti on yhä muokattava sovellusalueelleen, tai sitten se on niin yleinen, että se kasvaa liian massiiviseksi ja hankalaksi käyttää. Yksinkertaisia, uudelleenkäytettäviä komponentteja löytyy vain pienistä yksinkertaisista sovelluksista. Vaihtoehtona ohjelmien uudelleenkäytölle Bosch tarjoaa ohjelmistoarkkitehtuureja ja ohjelmistotuotelinjoja. Arkkitehtuurit vaikuttavat positiivisesti laatuun, tuotelinjat laadun lisäksi kehitys- ja ylläpitokuluihin sekä ohjelman valmistumisaikaan. 4 Arkkitehtuurin suunnittelumetodi Arkkitehtuurin suunnittelu ei ole sovelluskehityksestä irrallinen toimenpide, vaan yksi osa kehitysprosessia, vieläpä kovin vähän tiedostettu. Sovelluksen kehitys aloitetaan monesti vaatimusten keräämisellä. Nämä vaatimukset jakautuvat toiminnallisiin ja laadullisiin vaatimuksiin. Toiminnalliset vaatimukset tulevat hyvin esille kaikille tutuissa sovellukehityksen vaiheissa ja niiden tuotteissa alkaen jo käyttötapauskuvauksista. Laadulliset vaatimukset taas jäävät hyvin usein hiljaisen tiedon harteille. Kokemus ja sovellusalan tunteminen auttaa myös paljon laadullisten vaatimusten täyttämisessä. Bosch [1] jakaa tuotteen, s.o. kehitettävän sovelluksen, elinkaaren neljään iteratiiviseen prosessiin. Uloimpana on vaatimusten kehittyminen tuotteen elinkaaren aikana versio versiolta. Seuraava sisempi prosessisykli on tuotteen iteratiivinen kehitys, sillä harvempi asiakas osaa heti asettaa kaikki tarpeelliset vaatimukset tuotteelle ja asettaa ne oikein. Myös kehittäjien asettamat vaatimukset usein muuttuvat ja tarkentuvat. Voidaan myös käyttää jo luonteeltaan iteratiivista kehitysmallia. Kaksi sisintä prosessia muodostavat Boschin kirjassaan kuvaileman ohjelmistoarkkitehtuurin kehitysmenetelmän laadullisiin atribuutteihin painottuen. Näistä sisemmässä prosessissa suunnitellaan, varmennetaan ja muunnetaan ohjelmistoarkkitehtuuri vastaamaan laadullisia vaatimuksia ulomman prosessin näitä vaatimuksia sille syöttäessä. Ulommassa prosessissa valitaan joukko tärkeimpiä vaatimuksia sisemmän käsiteltäväksi, tätä toistaen, kunnes kaikki vaatimukset on käsitelty. Myöhemmin tulemme huomaamaan, että sisempi prosessi saattaa luoda uusia toiminnallisia ja laadullisia vaatimuksia. Paitsi prosessin tämä ohjelmistoarkkitehtuurien suunnittelumetodi määrittelee myös joukon tuotteita, artefakteja, joita prosessi tuottaa. Nämä jakautuvat kahteen kategoriaan, vaatimusmäärityksiin ja ohjelmistoarkkitehtuuriin. Vaatimusmääritykset jakautuvat, yllätys, toiminnallisiin ja laadullisiin vaatimuksiin. Toiminnalliset vaatimukset tulisi priorisoida vaadittuihin, toivottuihin ja 4

5 valinnaisiin vaatimuksiin. Laadullisiin vaatimuksiin tulisi liittää suunnitelmaprofiili (scenario), joka määrittää tilanteen, mihin laadullinen vaatimus kuuluu. Ohjelmistoarkkitehtuuri koostuu neljästä artefaktista: järjestelmäkontekstista, arkkityypeistä, arkkitehturaalisesta rakenteesta ja suunnittelupäätöksistä. Järjestelmäkonteksti kuvaa ohjelmiston rajapinnat kontekstiinsa, arkkityyppi järjestelmän rakentamiseen käytetyt yleistykset ja arkkitehturaalinen rakenne järjestelmän perusrakennusosat sekä näiden väliset suhteet. Suunnittelupäätöksiä on kolmea tyyppiä: muunnoksia, rajoitteita ja sääntöjä. 4.1 Vaatimukset Sovelluksen kehityksen alkuvaiheissa kiinnitetään paljon huomiota toiminnallisiin vaatimuksiin. Laadulliset vaatimukset tahtovat jäädä lähes kokonaan unholaan, tai sitten niitä käsitellään vain pintapuolisesti hutaisten. Seuraavassa keskitytään enemmän laadullisiin vaatimuksiin ja niiden merkitykseen ohjelmistoarkkitehtuurin kehityksessä. Järjestelmän vaatimukset jaetaan ohjelmisto-, laitteisto- ja mekaanisiin vaatimuksiin. Näistä meitä kiinnostavin, ohjelmistovaatimukset, jakautuvat taas toiminnallisiin ja laadullisiin vaatimuksiin. Jälkimmäinen jakautuu edelleen kehitysvaatimuksiin, joita ovat esimerkiksi ylläpidettävyys, uudelleenkäytettävyys, joustavuus ja esiteltävyys, ja toimintovaatimuksiin (operational requirements ), joita ovat esimerkiksi suorituskyky, luotettavuus, lujuus (robustness ) ja virhesietoisuus. Laatuvaatimukset eivät ole nähtävissä yksittäisinä osina sovellusta, vaan koko sovelluksen ominaisuuksina (vrt. AOP). Aiemmin tuli jo mainittua esimerkkinä käyttötapaukset toiminnallisten vaatimusten kuvaajina. Bosch [1] tarjoaa laadullisille vaatimuksille vastaavaksi kuvaajaksi profiileita, joukkoja skenaarioista, eri atribuuttityypeille erilaisia. Käyttöprofiilit kuvaisivat toimintovaatimuksia, esimerkiksi suorituskyky- ja luotettavuusvaatimuksia. Turvallisuutta voisi kuvata riskiskenaariot ja ylläpidettävyyttä muutosskenaariot. Profiileista lisää myöhemmin. 4.2 Metodi lyhyesti Yleensä sovelluksia tehdessä ei laadullisiin vaatimuksiin juurikaan kiinnitetä huomiota. Ne täyttyvät joko sattumalta, muun osaamisen johdosta, tai ne ovat sovellusalueelle niin olennaisia, että ne täyttyvät huomaamatta. On myös erityisiä tutkimusaloja, jotka ovat keskittyneet laadullisiin vaatimuksiin, valitettavasti usein vain yhteen kerrallaan. Sovelluksen toimintaa pyritään tehostamaan esimerkiksi suorituskyvyn tai varmuuden kannalta. Näiden vaatimusten yhdistämistä ei auta se, että usein vaatimukset ovat toisilleen epäsuotuisia. Laadullisia vaatimuksia koetetaan kyllä arvioida hieman sovelluksen valmistuttua, mutta tällöin muutosten tekeminen, varsinkin, jos ne vaikuttavat vahvasti sovelluksen arkkitehtuuriin, on perin kallista. Tämän takia myös olisi hyvä kiinnittää huomiota laadullisiin vaatimuksiin kehityksen alkuvaiheissa, jolloin muutoskustannukset ovat yleisesti pienempiä. Tässä esitelty metodi perustuu kolmeen toteutettuun järjestelmään. Järjestelmät on paremmin esitelty lähteessä [1, Luku kolme eteenpäin]. Vaikka tämä arkkitehtuurin suunnitteluprosessi voidaan nähdä funktiona, jonka syötteinä ovat vaatimukset ja tuloksena arkkitehtuurikuvaus, ei prosessi suinkaan ole automaattinen, vaan vaatii ohjelmistoarkkitehdeilta panostusta ja luovuutta. Prosessi, joka on esitelty kuvassa 1 sivulla 5 alkaa toiminnallisista vaatimuksista arkkitehtuurin laatimisella. Tämän jälkeen arvioidaan, täyttyvätkö kaikki laadulliset vaatimukset, jotka ovat tällä kierroksella tarkastelun kohteena. Jokainen vaadeatribuutti arvioidaan kvalitatiivisesti tai kvantitatiivisesti, ja näitä arvioita verrataan vaatimuksissa esitettyihin arvoihin. Jos kaikki arviot ovat yhtähyviä tai parempia kuin vaatimukset, siirrytään tutkimaan seuraavaa vaatimusjoukkoa. Jos 5

6 Vaatimuksen valinta Toiminnallisuuteen perustuva arkkitehtuuriratkaisu FR (Osittainen) vaatimusmäärittely Sovellusarkkitehtuuri Arkkitehtuurin muunnos QA-optimointi ratkaisut Ei OK Arvioi laatuatribuutit OK QR (Perus) QASAR Lisää vaatimuksia? Kyllä QASAR (iteratiivinen) Kuva 1: Boschin QASAR-malli [1]. jokin arvio jää alle vaaditun tason, muunnetaan arkkitehtuuria ja arvioidaan vaadeatribuutit uudelleen. Tätä toistetaan, kunnes kaikki laatuvaatimukset on täytetty, tai tehtävä huomataan mahdottomaksi, jolloin vaatimuksista täytyy neuvotella uudestaan asiakkaan kanssa. 4.3 Arkkitehtuurin suunnittelu toiminnallisuuden perusteella Tämän ensimmäisen vaiheen tarkoituksena on löytää järjestelmän ydinkäsitteet, joiden mukaan järjestelmä rakentuu. Näitä yleistyksen kohteita ei useinkaan löydy suoraan sovellusalueesta, vaan niiden läytymiseen tarvitaan hieman luovuutta ja analysointia. Kun yleistykset ovat löytyneet, tarkennetaan niiden välisten toimintojen kuvauksia. Itse arkkitehtuurin suunnittelu kannattaa tehdä top-down-menetelmällä, onhan kyse yleisistä järjestelmän rakenteista. Bottom-up-menetelmällä jouduttaisiin liikaa tekemisiin järjestelmän yksityiskohtien kanssa. 4.4 Laatuatribuuttien varmistus Laatuatribuuttien varmistamiseen on tarjolla neljä eri vaihtoehtoa. Voidaan käyttää skenaarioiden arviointia, simulaatiota, matemaattista mallintamista tai järkeilyä. Skenaarioita tarvitaan kaksi, toinen suunnittelua ja toinen arviointia varten. Ajamalla näitä skenaarioita läpi saadaan arvio laatuatribuuttien täyttymisestä. Esimerkiksi jos muutosskenaariot aiheuttavat suuria muutoksia arkkitehtuuriin, on järjestelmän ylläpidettävyys heikkoa. Simuloitaessa toteutetaan ensin arkkitehtuurin pääkomponentit, jäljelle jääneitä komponentteja simuloidaan ohjelmallisesti. Toinen vaihtoehto on tehdä prototyyppi, jolloin arkkitehtuuri toteutetaan osittain, ja tätä osittaista toteutusta ajetaan oikeassa ympäristössä. Vaihtoehtona simuloinnille on tarjolla järjestelmän matemaattinen mallintaminen. Tätä käytetään varsinkin toiminnollisten laatuatribuuttien arviointiin. Simuloinnin apuna voi myös käyttää matemaattista mallintamista, sillä täysin toisensa poissulkevia ne eivät ole. Järkeilyä ei tule aliarvioidan yhtenä laatuatribuuttien arviointimenetelmänä, vaikka se on kovin subjektiivinen tapa arvioida. Kokemus on valttia näissäkin asioissa. 6

7 4.5 Arkkitehtuurin muuntaminen Kun laatuatribuutit eivät täyty, tulee arkkitehtuuria muuntaa paremmaksi. Tämä voi tapahtua sovittamalla arkkitehtuuria johonkin tunnettuu arkkitehtuurityyliin. Arkkitehtuurityylit ovat koko arkkitehtuuria hallitsevia, joskin niitä voi yhdistellä hieman. Arkkitehtuurimallit ovat keskenään ja arkkitehtuurityylin kanssa ortogonaalisia, ja siten pikemminkin verrattavissa aspektisuuntautuneeseen ohjelmointitapaan kuin suunnittelumalleihin. Arkkitehtuurimallit muokkaavat koko arkkitehtuuria tai suurta osaa siitä, kun taas haluttaessa muokata vain pientä osaa arkkitehtuurista voidaan käyttää suunnittelumalleja. Jos nämä keinot eivät riitä, täytyy käyttää järeämpiä keinoja. Laatuvaatimuksia voidaan sopivissa yhteyksissä muuttaa toiminnallisiksi, josta esimerkkinä Bosch mainitsee poikkeutukset vikasietoisuuden parantajina. Viimeinen keino on vanha tuttu: hajoita ja hallitse. Tällöin vaatimus hajoitetaan useammaksi laadulliseksi vaatimukseksi järjestelmän komponenteille, tai kahdeksi tai useammaksi toiminnalliseksi vaatimukseksi. 5 Arkkitehtuurin suunnittelu toiminnallisuuden perusteella Ensimmäisessä vaiheessa muodostetaan arkkitehtuurisuunnitelma toiminnallisten vaatimusten perusteella. Bosch [1] pitää täten syntynyttä arkkitehtuurisuunnitelmaa hyvänä alkuna jatkokehittelylle. Hän sanoo tämän perussuunnitelman olevan jopa kelvollisen saman sovellusalueen eri laatuvaatimusjoukoille. Kuitenkin tämä ensimmäinenkin suunnitelma arkkitehtuurista on hyödyllinen ja arvioidaan laatuvaatimusten perusteella. Tämä ensimmäinen vaihe jakautuu neljään seuraavissa kappaleissa lueteltavaan alivaiheeseen. 5.1 Määritellään puitteet, eli asiayhteys Ensin tarkastellaan järjestelmää osana sovellusaluettaan. Järjestelmällä voi olla rajapintoja ulkopuolisiin osiin, ja nämä rajapinnat tulisi tässä vaiheessa tunnistaa ja arvioida niin toiminnallisten kuin laadullistenkin vaatimusten suhteen. Samalla tulee määriteltyä järjestelmän konteksti ja rajat. Tämän voidaan katsoa auttavan suunnittelijoita ja kehittäjiä keskittymään oleelliseen, eikä laajentamaan rajoja aina sopivan tilaisuuden tullen. 5.2 Tunnistetaan arkkityypit Seuraavassa vaiheessa, lähtien järjestelmän kokonaiskuvauksesta, pyritään top-down -menetelmällä löytämään järjestelmän yleiset perusrakenneosat, arkkityypit. Kannattaa olla varovainen, ettei tässä vaiheessa lipsahda olioanalyysin pariin, sillä ajatusmalli on täysin eri. Oliomallissa pyritään kuvaamaan järjestelmä pienempien osasten muodostamana kokonaisuutena, kun taas tässä pyritään tunnistamaan samankaltaisia kokonaisuuksia järjestelmästä. Kun järjestelmästä löytyy toistuvia, samankaltaisia kokonaisuuksia, tehdään näistä järjestelmän arkkityyppejä. Kun arkkityyppien kirjo on yhdistelemällä ja mukauttamalla saatu hallittavaksi joukoksi, keskitytään arkkityyppien välisiin suhteisiin. Nämä suhteet ovat sovellusaluekohtaisia ja kuvaavat järjestelmän kontrolli- ja tietovuota. Näitä yhteyksiä ei tule sotkea olioanalyysin assosiaatioihin, eikä arkkitehtuurityylien liitoksiin. Jälkimmäiset esittävät yhden mahdollisen tavan toteuttaa arkkityyppien välinen suhde. Tämä vaihe lopetetaan, kun kehitysryhmässä vallitsee yhteisymmärrys siitä, että arkkityyppejä ja näiden välisiä suhteita on tarpeeksi tutkittu. Vaihe on luova, ja tulee varoa, ettei siitä toisaalta poistuta liian ajoissa, toisaalta jätetä sitä turhan vähälle iteraatiolle. 7

8 5.3 Hajoitetaan arkkitehtuuri komponentteihin Tässä vaiheessa tunnistetaan ja määritellään järjestelmän komponentit ja näiden väliset suhteet. Komponenttien tunnistamisessa voidaan käyttää apuna järjestelmän rajapintoja ensimmäisestä vaiheesta, sovellusalueen tai sen alialueiden esittämistä komponentteina, järjestelmän jakoa eri kerroksiin, sovellusalueelle tyypillisiä entiteettejä ja arkkityyppien instantiointia. Kun komponentit on saatu tunnistettua, etsitään niiden välisiä suhteita. Suhteiden löytymiseen voidaan käyttää apuna samoja alueita kuin komponentteja etsittäessä. Tämän jälkeen on hyvä vielä käyttää skenaarioita esimerkiksi komponenttien välisessä viestinnässä tarvittavien suhteiden löytymisen apuna. Tulee myös muistaa, että tässä toimitaan vielä sovellusalueen eikä ratkaisualueen käsitteillä. Suuri suhteiden määrä on yleensä vihje huonosta suunnittelusta. 5.4 Kuvaillaan järjestelmän toteutukset Tässä vaiheessa kuvaillaan järjestelmälle yksi tai useampi mahdollinen toteutus 1. Arkkitehtuurin komponentin jaetaan pienempiin, alemman tason komponentteihin. Jokainen näistä komponenteista on yhden tai useamman arkkityypin kooste. Instantioiduille arkkityypeille instantioidaan niiden väliset suhteet. Vielä varmistetaan, että järjestelmän yleistykset ja konkreetimpi jako ovat yhteensopivat. 6 Laatuatribuuttien varmistus Laadullisia vaatimuksia on kovin hankalaa mitata, ellei mahdotonta, järjestelmän abstraktin mallin avulla. Tarkoituksena onkin tarkan mittaamisen sijaan arvioida, millaiset mahdollisuudet järjestelmä antaa laadullisten vaatimusten täyttymiselle. Arvioinnin kohteita ovat laadullisuus, esimerkiksi arkkitehtuuri A on atribuutin kannalta parempi kuin arkkitehtuuri B; määrällisyys, esimerkiksi transaktioita aikayksikössä; asetettu optimi, jonka täyttymistä, atribuuttien arvojen etäisyyttä siitä, arvioidaan. Kullekin laadullisen vaatimuksen atribuutille määritellään joukko skenaarioita, joilla atribuutteja pyritään arvioimaan. Nämä skenaariot ryhmitellään profiileihin, joita käytetään apuna varsinaisessa arviointitapahtumassa. Tuloksien avulla pyritään sitten arvioimaan laadullisen vaatimuksen täyttymistä ja sitä, miten arkkitehtuuria tulee muuntaa, jotta vaatimus täyttyisi paremmin. 6.1 Profiilit Profiili koostuu skenaarioista. Profiili voi olla joko täydellinen, jolloin se sisältää kaikki mahdolliset skenaariot, tai skenaariosta valittu kattava otos. Ensimmäinen onnistunee vain pienille projekteille. Skenaarioiden valinta profiiliin taas on perin hankalaa, sillä yleensä valitsijan, joka usein on ollut myös skenaarioiden tekijänä, mieltymykset vaikuttavat valintaan suuresti. Jottei näin pääsisi tapahtumaan, päätyy Bosch ehdottamaan seuraavaa: 1. jaetaan skenaariojoukko useaan pienempään joukkoon (kategorisointi), Bosch: 4 8 joukkoa, 2. valitaan skenaariot profiiliin eri kategorioista. Tämän jälkeen painotetaan skenaariot, esimekiksi arvoilla 1 10, 1 100, (- -, -, 0, +, + +). Painoarvojen on oltava kvalitatiivisia ja verrattavissa (lasketaan kaikki painot yhteen ja osapaino jaetaan tällä summalla suhteellinen_paino i = paino i paino ). Esimekiksi käyttöprofiileille paino voi ilmoittaa kuinka usein tietty skenaario toteutuu, ylläpitoprofiileille suhteutetun todennäköisyyden skenaarion toteutumiselle. 1. Toteutukset instantiations, sana, jota ei löytynyt minun sanakirjoistani, joten suomensin sen vapaasti näin. 8

9 6.2 Eri profiilit Seuraavassa on kuvailtu eri profiilit ja niiden ominaisuuksia. Nämä profiilit ovat jo tuttuja kappaleesta 2. Suorituskyky kuvaa, kuinka tehokkaasti järjestelmä toimii. Hidastavin osa suurissa järjestelmissä ei usein ole sovelluskohtainen toiminnallisuus, vaan arkkitehtuuriliitännäiset osat, kuten synkronointipisteet, muistinhallinta, kommunikoinnin aiheuttama kuormitus, rinnakkaistuksen toteutuksen aiheuttamat kuormitukset. Profiiliksi sopii täydellinen tai valittu joukko esiintymistä yhden käyttäjän järjestelmän käytöstä. Kategoriat voidaan muodostaa käyttäjätyypeittäin tai järjestelmärajapinnoittain. Painona voidaan käyttää esimerkiksi suhteellista käyttötaajuutta. Etukäteen tarvitaan perustietous komponenteista ja niiden toiminnasta, järjestelmän toiminnasta käyttöskenaariossa, tarvittavasta toiminnasta komponenteissa, sekä tieto keskimääräisestä (ja pahimmasta) synkronointiviipeestä. Tämän tiedon tuottavat arkkitehdit arvioiden tai kerätyn havaintoaineiston (historia) avulla. Ylläpidettävyys eli kuinka vastata muutostarpeisiin. Tärkeää on selvittää millaine muutos on kyseessä. Vähiten arkkitehtuuriin vaikuttavasta eniten vaikuttavaan ovat eri muutoksia lokaali muutos, laaja muutos, arkkitehtuurin eroosio. Muutokset tulisi pystyä tekemään ilman muutoksia arkkitehtuuriin, sillä arkkitehtuurin muunnokset ovat kalliita. Profiili on ylläpitoprofiili, joka koostuu muutostrategioista, jotka koostuvat muutosskenaarioista. Muutoskategorioita voivat määräytyä järjestelmän ja sen ympäristön välisten rajapintojen, esimerkiksi laitteisto, käyttöjärjestelmä, muut järjestelmät, tai käyttöliittymän jokaiselle käyttätyypille mukaan. Muutosskenaariot kuvaavat ohjelmiston muutoksiin johtavat muutosvaatimukset, painona (suhteellinen) mahdollisuus sille, että muutos tapahtuu aikayksikössä. Muutoksia voi tapahtua useita aikayksikössä, sama skenaario toteutuu kuitenkin vain kerran. Koska lasketaan vaikutusta arkkitehtuuriin, esimerkiksi muutettavien koodirivien määrää, tarvitaan arvio komponentin koodirivien määrästä. Luotettavuus (reliability ) Yleisesti luotettavuuteen vaikuttavia tekijöitä ovat esimerkiksi arkkitehtuuri, yksityiskohtainen suunnittelu, sekä toteuttajien koulutus- ja kokemustaso. Arkkitehturaaliselta kannalta näitä tekijöitä ovat komponenttien välinen toiminta operaation aikana ja sen virheiden vaikutus koko järjestelmään. Käyttöskenaariot, joissa vähän komponentteja, ovat luotettavampia. Profiili on käyttöprofiili, jossa arvioidaan käyttöskenaarioita komponenttien luotettavuuden mukaan, näistä ja relatiivisista painoista järjestelmän painon laskien. Tarvitaan tietoa komponenteista, niiden välisestä toiminnasta, sekä luotettavuusdataa. Luotettavuusdata (historiadata) on kokemusperäistä tai arvioita. Suunnittelijat ja toteuttajat voivat varmistaa, että luotettavuusdatan taso täyttyy, erityisesti jos data muutetaan komponentin vaatimuksiksi. Turvallisuus (safety ) Jos järjestelmällä on negatiivinen tai tuohoava vaikutus tosimaailman kohteisiin, ei se ole turvallinen. Turvallisuus ei kuitenkaan ole tekemisissä järjestelmän toiminnallisuuden kanssa, se on luotettavuuden heiniä. Turvallisuus sisältää järjestelmän virheet ja syötevirheet. (Epä)turvallisuutta on, ettei dialyysikone huomaa ilmakuplia ruumiin ulkopuolisessa verenkierrossa. Se, että pankkiautomaatti antaa rahat väärin, ei liity turvallisuuteen. Profiilina on hasardiprofiili, johon kuuluu hasardiskenaariot, eli tilanteet, joissa vian toteamattajättäminen johtaa vakaviin tai tuohoisiin seuraamuksiin. Kategorisointi voi tapahtua sertifikaattidokumenttien mukaan, järjestelmän ja maailman vaikutuspisteiden mukaan, tai kriittisten komponenttien mukaan. Turvallisuus on yleensä sulautettujen järjestelmien ongelma, joten tarvitaan tietää eksplisiittinen ja selvä kuvaus suhteesta järjestelmän arkkitehtuurin ja ohjelmiston arkkitehtuurin välillä. Varmuus (tietoturvallisuus, security ) voidaan jakaa kolmeen osaan: salaisuuteen, yhtenäisyyteen (integrity ) ja saavutettavuuteen (availability ). Jos salaisuus rikkoutuu, tieto pääsee vääriin käsiin. Jos yhtenäisyys rikkoutuu, järjestelmän osia pääsee laittomasti muokkaamaan. Jos taas saavutettavuus on liian laaja, voi järjestelmä joutua esimerkiksi palvelunestohyökkäyksen kohteeksi. Varmuutta voidaan tarkastella joko koko järjestelmän tai sen osasten ominaisuutena. Profiili voidaan jakaa salaisuuden, yhtenäisyyden ja saavutettavuuden mukaan, tai rajapintojen mukaan. Arvioinnin apuna voidaan käyttää myös käyttöprofiileja. 9

10 Tieto turvallisuusoperaation suorituksen kestosta auttaa tunnistamaan hyökkäyksen. 6.3 Arviointitapoja Yleinen tapa arvioinnille on seuraava: Ensin alustetaan arviointi, eli valitaan laatuatribuutit, määritetään profiili jokaiselle niistä, ja valitaan varmistustekniikka. Jokaisella suunnittelukierroksella suoritetaan arviointi jokaiselle laatuatribuutille ja kerää tulokset ja päätä jatkosta, uudelleenneuvotteluista, projektin terminoinnista. Arviointitavat voidaan jakaa skenaarioperustaiseen, simulointiin, matemtaattiseen mallintamiseen ja kokemusperäiseen arviointiin. Skenaarioperustainen arviointi tapahtuu skenaarion mukaan, jolloin toimivuus ja sopivuus riippuu skenaarion laadusta ja kattavuudesta. Skenaariot muistuttavat olio-ohjelmoinnista tuttuja käyttötapauksia, mutta ne kuvaavat laadullisia ominaisuuksia, eivät toiminnallisia. Skenaariot ja käyttötapaukset kannattaa pitää erillään. Paitsi arkkitehtuurin arviointiin voidaan skenaarioita käyttää kahden arkkitehtuurin vertailuun. Skenaarioperustaisen arvioinnin vaiheet ovat vaikutusanalyysi: skenaarion vaikutus arkkitehtuuriin, esimerkiksi muutos muutettujen komponenttien ja rivien määrät; ja laatuatribuuttien arvojen ennustus: koko järjestelmän muutosarvio, muutoksen aiheuttamien kustannusten arviointi. Skenaarioperustainen arviointi on hyvä ylläpidon ja kvalitatiiviseen arviointiin. Simulointi, eli kerätään arviointidataa järjestelmää simuloimalla. Tämä tapahtuu seuraavasti: määritellään ja toteutetaan konteksti, toteutetaan arkkitehtuurin komponentit, implementoidaan profiili, ajetaan simulaatiota suorittaen haluttuja profiileita, ja ennustetaan laadullisten atribuuttien arvot profiilien suorituksen aikana kerätyn datan avulla. Simulointia lähellä on prototyypitys, jossa puolivalmista sovellusta ajetaan oikeassa ympäristössä. Matemaattinen malli, jossa arvioidaan laatuatribuutteja staattisesti matematiikan keinoin. Tämä tapahtuu seuraavasti: Valitaan ja yleistetään matemaattinen malli, esitetään arkkitehtuuri mallin termein, arvioidaan syöttö (puuttuva data), ja ennustaan laatuatribuuttien arvot. Matemaattisessa mallintamisessa perinteisistä ohjelmistometriikoista voi olla apua. Matemaattinen mallintaminen auttaa ja joskus jopa korvaa simuloinnin. Kokemusperäinen arviointi on kvalitatiivista edellisten arviointtapojen ollessa kvantitatiivista. Tätä ei kuitenkaan tule aliarvioida, sillä usein kokemusperäinen tieto on arvokkain väline arvioinnissa. Kokemusperäisen tiedon dokumentointi on erittäin tärkeää. 7 Arkkitehtuurin muuntaminen Jos edellisessä vaiheessa toiminnallisista vaatimuksista syntynyt arkkitehtuuri ei täytä kaikkia laadullisia vaatimuksia, täytyy arkkitehtuuria muuttaa. Seuraavassa esitellään neljä arkkitehtuurin muuntamistapaa eniten vaikuttavasta vähiten vaikuttavaan: arkkitehtuurityyli, arkkitehtuurimalli, suunnittelumalli ja laadullisen vaatimuksen muuntaminen. Muuntamisella, vaikka se onkin välttämätöntä, on myös varjopuolensa. Ensimmäinen versio arkkitehtuurista on usein hyvin selkeä, lähellä sovellusaluetta, ja siten helposti kehittäjien ymmärrettävissä. Jokainen arkkitehtuurimuunnos vie arkkitehtuuria kauemmas tästä ensimäisestä versiosta, ja siten jokainen versio on aina hieman hankalampi ymmärtää. Asiaa ei suinkaan auta se, että arkkitehtuurimuunnoksilla on tapana kasvattaa komponenttien määrää moninkertaisesti. Tämän vuoksi on tärkeää muistaa jokaisen muunnoksen aikana varmistaa, että arkkitehtuuri pysyy mahdollisimman yksinkertaisena ja selkeänä. Arkkitehtuurin muuntamisen vaiheet ovat seuraavat: 1. Tunnistetaan laadulliset vaatimukset, jotka eivät ole täyttyneet. Sen jälkeen jokaiselle tällaiselle vaatimukselle tehdään seuraavat toimenpiteet: 2. Tunnistetaan laadulliset ominaisuudet, jotka vaatimukseen liittyvät, sekä komponentit tai paikat arkkitehtuurissa, jotka näiden ominaisuuksien täyttymistä rajottavat. 10

11 3. Valitaan muunnos, jolla laadullinen ominaisuus saadaan täyttymään. Tulee arvioida, miten muunnos vaikuttaa laadullisiin ominaisuuksiin ja vaatimuksiin ja mihin. Sama muunnos voi parantaa toisia ominaisuuksia, mutta myös samalla heikentää toisia. 4. Toteutetaan muunnoksen vaatimat muutokset arkkitehtuuriin. Arkkitehtuurin muuntamisen jälkeen on taas vuorossa laadullisten ominaisuuksien arviointi, tämän jälkeen taas arkkitehtuurin muunnos. Tätä silmukkaa jatketaan, kunnes laadulliset vaatimukset täyttyvät. Vaan kuinka kauan jatketaan arkkitehtuurin suunnittelua? Bosch [1] antaa neuvoksi tarkastella laadullisia vaatimuksia. Jos ne ovat yksityiskohtaisia, tulee arkkitehtuurin suunnittelua jatkaa hyvin lähelle yksityiskohtaista suunnittelua, vaikka osittain päällekin, kunhan vain arkkitehtuuri täyttää kaikki sille asetetut vaatimukset. 7.1 Arkkitehtuurityylin sovitus Tässä vaihtoehdossa arkkitehtuuri sovitetaan jonkin arkkitehtuurityylin mukaiseksi. Tällainen sovitusoperaatio muuntaa yleensä koko arkkitehtuuria, jokaista komponenttia ja liitosta, joten se on erittäin raskas, kallis ja tarkkuutta vaativa operaatio. On myös mahdollista sovittaa useampi kuin yksi tyyli samaan arkkitehtuuriin, mutta tällöin on oltava erittäin tarkkana tyylien vaikutusten suhteen. Tosin, jos sopivia myönnytyksiä ollaan valmiita tekemään, voidaan keskenään ristiriitaisiakin tyylejä sovittaa yhteen. Kuitenkin tulee pitää mielessä selkeys ja yksinkertaisuus. Eri arkkitehtuurityylejä ja niiden vaikutuksia arkkitehtuuriin on käsitelty kappaleessa Arkkitehtuurimallit Toinen tapa muuntaa arkkitehtuuria, joka vaikuttaa koko arkkitehtuuriin tai ainakin suureen osaan sitä, on soveltaa siihen arkkitehtuurimallia. Arkkitehtuurimalli asettaa säännön arkkitehtuurille, kuinka sen tulisi hoitaa tietyt toiminnalliset aspektit. Nämä aspektit eivät yleensä liity sovellusalueeseen, vaan ennemminkin sovelluksen tietoteknisiin ominaisuuksiin. Esimerkkejä tällaisista aspekteista ovat rinnakkaistus, persistenttiys, synkronointi, transaktiot, hajautus, ajoinaikainen sitominen, tosiaikainen käytös ja graafiset käyttöliittymät, mutta muitakin löytyy. Arkkitehtuurimallit eivät niinkään muunna arkkitehtuurin rakennetta, vaan käytöstä. Toki samalla saattaa jokunen uusi komponentti mukaan ilmaantua, mutta muuten vain komponenttien käytös laajenee tai muuttuu. Koska näin komponentin käytöstä rajoitetaan, ei kahta samaan aspektiin vaikuttavaa arkkitehtuurimallia voi sovittaa samaan arkkitehtuuriin. Arkkitehtuurimallia tässä ei tule sotkea Buschmannin lähteessä [2] esitettämiin arkkitehtuurimalleihin, joissa samaa termiä architectural pattern on käytetty eri tarkoituksessa. Seuraavassa on lueteltu arkkitehtuurimalleja edelläluetelluille aspekteille. Lista ei ole kattava, eikä mallien vaikutusta arkkitehtuureihin käsitellä kurssilla. Lisätietoa halajavat löytävät etsimänsä lähteestä [1]. Rinnakkaistus Käyttöjärjestelmän prosessit ja säikeet, keskeyttävät säikeet, sovellustason skedulointi. Persistenttiys Tietokannanhallintajärjestelmät, sovellustason persistenttiys ja transaktiot. Hajautus Välittäjät (broker, CORBA), RMI. Graafiset käyttöliittymät MVC, Presentation-Abstraction-Controller (PAC) kuvassa Suunnittelumallit Vaikka moni suunnittelumalleista keskittyy uudelleenkäytön ja ylläpidettävyyden parantamiseen, usein laadullisten ominaisuuksien ja selkeyden kustannuksella, voidaan joitakin suunnittelumalleja käyttää laadullisten ominaisuuksien parantamiseen. Tällaisesta mallista mainittakoon esimerkkinä kärpässarjalainen, flyweight. 11

12 ViewCordinator 1 Abstraction Control 1 1 Presentation Kuva 2: PAC-suunnittelumalli. Suunnittelumalleista kiinnostuneita suositellaan hakeutumaan kirjan [3] kolmen ensimmäisen, ja viimeisen luvun pariin. Strategy 1..* Sensor * 1..* UpdateStrategy * AbstractSensor ConcreteSensor ClientUpdate PeriodicUpdate Trigger OnChangeUpdate Kuva 3: Strategia-suunnittelumallin soveltaminen tunnistinarkkitehtuuriin [1]. 7.4 Laadullisten vaatimusten muokkaus Laadullisia vaatimuksia voidaan muuntaa kahdella tavalla, joko muuntaen vaatimus toiminnalliseksi tai pilkkomalla se useammaksi, toiminnalliseksi tai laadulliseksi vaatimukseksi. Seuraavassa esitellään nämä tavat esimerkkien avulla. Laadullisten vaatimusten muunto toiminnallisiksi Järjestelmän toimintavarmuuden parantamiseksi voidaan siitä tehdä itseään valvova joko erillisellä valvontakerroksella tai erillisellä, järjestelmän rakennetta vastaavalla rinnakkaisjärjestelmällä. Järjestelmän vikasietoisuutta (redundancy ) voidaan taas parantaa N-versio -ohjelmoinnilla, jossa samasta ohjelmiston osasta tehdään useampi versio, ja yhden epäonnistuessa palautetaan ohjelma epäonnistumista edeltävään tilaan ja koetetaan ajaa toinen versio. Vaatimusten jakaminen Yksinkertainen esimerkki on vikasietoisuuden jakaminen vikasietoiseksi laskennallisuudeksi ja vikasietoiseksi kommunikoinniksi. Hieman monimutkaisempi esimerkki on palohälytinjärjestelmä [1]. Jokaisessa rakennuksessa on oma keskusyksikkönsä pyörittämässä palohälytinjärjestelmää. Koska useiden eri rakennusten järjestelmien tulee toimia yhteen, toteutetaan tämä monistamalla yhteinen taulu jokaiseen järjestelmään, ja rakentamalla järjestelmään osa, joka pitää kaikkien osajärjestelmien taulut samassa tilassa. 12

13 8 Loppuarviointi Jos kaikki laadulliset vaatimukset saadaan täytettyä, siirrytään ohjelman yksityiskohtaisempaan suunnitteluun ja edetä siitä perinteiseen tapaan eteenpäin. Kun ohjelmaa myöhemmin jatkokehitetään, voidaan uudet tai muuttuneet laadulliset vaatimukset varmistaa ja arkkitehtuuria niiden mukaan tarkentaa tai muokata tällä samalla metodilla. Jos taas kaikkia laadullisia vaatimuksia ei saada täyttymään, on vaihtoehtoja kaksi. Joko neuvotellaan asiakkaan kanssa vaatimuksista, tai projekti ajetaan alas hallitusti. Viitteet [1] Jan Bosch: Design and use of software architectures: adopting and evolving a product-line approach, ACM Press/Addison-Wesley Publishing Co., 2000, ISBN [2] Frank Buschmann et al.: Pattern-oriented software architecture: a system of patterns, John Wiley & Sons, Inc., 1996, ISBN [3] Erich Gamma et al.: Design patterns: elements of reusable object-oriented software, Addison-Wesley Longman Publishing Co., Inc., 1995, ISBN [4] David Garlan ja Mary Shaw: An Introduction to Software Architecture, Tekninen Raportti CMU- CS , Carnegie Mellon University, January URL 13