9. Ohjelmistoarkkitehtuurien arviointi Johdanto ATAM-menetelmä Esimerkki Käytännön kokemuksia ja ongelmia Yhteenveto Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 1
Mitä on ohjelmistoarkkitehtuurin arviointi? Ohjelmistoarkkitehtuurin arviointi tarkoittaa toimintaa, jonka avulla voidaan tehdä johtopäätöksiä siitä, miten hyvin tietty ohjelmistoarkkitehtuuri tukee ko. järjestelmän vaatimusten toteutumista Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 2
Miksi ohjelmistoarkkitehtuuria on arvioitava? Arkkitehtuuri on ensimmäinen täsmällinen kuvaus järjestelmästä Arviointi vahvistaa hyvät ratkaisut ja kiinnittää huomiota mahdollisiin ongelmiin aikaisin Arviointi auttaa ymmärtämään paremmin järjestelmää Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 3
Muita mahdollisia hyötyjä Kehitystrendien sekä potentiaalisten kehitys- ja riskialueiden tunnistaminen Arvioinnilla voidaan varmistua muiden tekemien ohjelmistojen (esim. alihankinta) laadusta Arkkitehtuurin suunnittelua ohjaavien laatuvaatimusten kirjaaminen ja tarkentaminen Arkkitehtuuriratkaisuiden kirjaaminen ja liittäminen laatuvaatimuksiin Arkkitehtuuridokumentaation parantaminen Kommunikaation lisääminen Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka
Milloin ohjelmistoarkkitehtuuri olisi arvioitava? Ensimmäisten (vaihtoehtoisten) luonnosten pohjalta (alustava arkkitehtuuridokumentti) Arkkitehtuurisuunnittelun jälkeen, ennen toteutuksen aloittamista (järjestelmä/alijärjestelmäarkkitehtuuridokumentti) Olemassaolevalle järjestelmälle (esim. vanhan järjestelmän uudistaminen) Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 5
Arkkitehtuurin rakentaminen kehitysprosessissa Laatuvaatimukset Arkkitehtuurin kannalta merkittävät vaatimukset Vaatimusanalyysi Keskeiset toiminnalliset vaatimukset Ympäristövaatimukset Alustava arkkitehtuuri Alustava arkkitehtuurisuunnittelu Laatuvaatimuksen huomiointi Rajoitteet Yleisten ratkaisumallien soveltaminen Arkkitehtuurimuunnos ei OK OK Toissijaiset toiminnalliset vaatimukset Kaikki käsitelty Yksityiskohtainen suunnittelu Arkkitehtuurin arviointi Arkkitehtuuri Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 6
Arkkitehtuuri ja laatuvaatimukset Tässä laadulla ei viitata virheettömyyteen vaan siihen millä laadulla järjestelmä tekee loogiset toimintonsa Arkkitehtuuri määrää miten (useimmat) laatuvaatimukset toteutuvat. Hiukan kärjistäen: Ohjelmistoarkkitehtuuri on tapa toteuttaa ohjelmiston laatuvaatimukset Arkkitehtuurin kuvauksen täytyy sisältää kaikki se informaatio, joka tarvitaan päättelemään laatuvaatimusten toteutuminen tai toteutumattomuus Arkkitehtuuria arvioidaan (yleensä) vasten laatuvaatimuksia Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 7
Ohjelmistojen laatuominaisuudet Ajoaikaiset laatuominaisuudet Suorituskyky Tilankäyttö Luotettavuus Saatavuus Tietoturvallisuus Käytettävyys Kehitys- ja evoluutioaikaiset laatuominaisuudet: Muunneltavuus Siirrettävyys Ylläpidettävyys Uudelleenkäytettävyys Laatustandardit: esim. ISO 9126 Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 8
ISO 9126 laatukehikko Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 9
Tarkennetut laatuominaisuudet Efficiency Time performance Resource utilization Response time Memory usage Scalability Throughput Maintainability Analyzability Changeability Stability Testability Variability Subsetability Conceptual integrity Traceability Portability Adaptability Installability Co-existence Replaceability Functionality Suitability Accuracy Interoperability Security Data security Access security Safety Reliability Maturity Fault tolerance Recoverability Availability Predictability Usability Understandability Learnability Operability Attractiveness Ryhmittelyllä ei käytännössä paljon merkitystä arvioinnissa Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 10
Arkkitehtuuri ja liiketoimintatavoitteet Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 11
Arvioinnin tulokset Ohjelmistoarkkitehtuurin arviointi vastaa tyypillisesti seuraaviin kysymyksiin: 1) Täyttääkö suunniteltu arkkitehtuuri olennaiset laatuvaatimukset? Jos täyttää, miksi? Jos ei täytä, miksi? 2) Mikä vaihtoehtoisista arkkitehtuuriratkaisuista sopii parhaiten järjestelmälle? Miksi? 3) Kuinka hyvin tietty laatuvaatimus voidaan saavuttaa suunnitellulla arkkitehtuurilla? Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 12
Varauksia Arviointi pohjautuu arkkitehtuurin kuvaukseen, saatavilla olevaan informaatioon ja osallistujien aktiivisuuteen Arvioinnin tulosten tarkkuus riippuu lähtötietojen tarkkuudesta Arvioinnissa täytyy olettaa järkevä toteutus, arkkitehtuurin täytyy mahdollistaa järkevä toteutus Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 13
Ohjelmistoarkkitehtuurien arvioinnin ongelma? Laatuvaatimukset Ohjelmistoarkkitehtuuri Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 14
Laatuvaatimukset tulevat sidosryhmiltä Hyvä suorituskyky, luotettava, hyvä käytettävyys Helposti ylläpidettävä, siirrettävä Loppukäyttäjä Ylläpitäjä Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 15
Laatuominaisuuksien arviointi Laatuominaisuuksille ei ole selviä täyttymiskriteerejä Esim. ylläpidettävyys: järjestelmän on oltava helppo muuttaa kun sen käyttöympäristö muuttuu Miten arvioida jotain ominaisuutta, jolla on suuri (ääretön) määrä erilaisia tilanteita, joissa ominaisuuden olemassaolo on potentiaalisesti uhattuna Vrt. oikeellisuus testaus Yleinen menetelmä: määrää tavoitteet järjestelmälle, johda niistä halutut laatuominaisuudet, tarkenna ne, anna kullekin tarkennetulle laatuominaisuudelle esimerkkitilanne, ja tutki täyttyykö ko. laatuominaisuus tässä esimerkkitilanteessa Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 16
Laatuvaatimusten täsmentäminen skenaarioilla Skenaario = tilanne tai tapahtumasarja, joka tuo esille jonkin laatuvaatimuksen täyttymisen (jonkin järjestelmän osan kannalta) Skenaario konkretisoi laatuvaatimuksen esimerkillä Skenaarion on oltava riittävän täsmällinen, jotta arkkitehtuuria voidaan arvioida sitä vasten usein tarkkoja lukuarvoja Vrt. perinteinen käyttötapaus toiminnallinen vaatimus Skenaario = arkkitehtuurin testitapaus Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 17
Tiedon louhinta arkkitehtuurista Asiantuntijoiden näkemykset esim. pääarkkitehti, muita vastaavia järjestelmiä suunnitelleet arkkitehdit ym. Takaisinmallinnus koodia voidaan abstrahoida takaisinmallinnustyökaluilla, ei tuota varsinaista arkkitehtuurikuvausta vaan analysoi erilaisia riippuvuuksia Simulointi jos on olemassa ajettava malli, voidaan tutkia arkkitehtuurista johtuvaa suorituskykyä, luotettavuutta; edellyttää järjestelmän mallintamista ja hyvää työkalua Metriikat voidaan käyttää karkeana työkaluna epäilyttävien kohtien löytämiseen (toimii lähinnä ylläpidettävyydelle), edellyttää hyviä työkaluja esim. suuret luokat, paljon riippuvuuksia komponenttien välillä Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 18
Analysointityökalujen hyödyntäminen Olemassaolevan järjestelmän arkkitehtuuriarvioinnissa voidaan käyttää erilaisia työkaluja (esim. metriikkatyökalut, sääntöjen tarkistustyökalut, visualisointityökalut, riippuvuusanalysaattorit, koodin kopioinnin tarkistajat, takaisinmallinnustyökalut) (esim. Rigi, Columbus) Erityisen hyödyllistä ylläpidettävyyden ja muunneltavuuden analysoinnissa Monet työkalut toimivat koodin perusteella -> ei välttämättä arkkitehtuuritason informaatiota Voidaan hyödyntää skenaariopohjaisessa arvioinnissa esim. hakemalla ja priorisoimalla skenaarioita, jotka kohdistuvat epäilyttäviin osiin järjestelmässä Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 19
Esimerkki (Columbus): koodin kopiointi Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 20
Ohjelmistoarkkitehtuurien arvioinnin ongelman ratkaisu: skenaariopohjainen arviointi? Vaatimusten tarkennus Skenaariot Analyysi Laatuvaatimukset Ohjelmistoarkkitehtuuri Arkkitehtuuriratkaisut Ratkaisujen identifiointi Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 21
Ohjelmistoarkkitehtuurien arvioinnin ongelman ratkaisu: tarkistuslistapohjainen arviointi? Laatuvaatimukset Ohjelmistoarkkitehtuuri Yleinen tarkistuslista Järjestelmätyyppi Sovitettu tarkistuslista Analyysi yleiset/järjestelmätyyppikohtaiset tarkistuslistat: esim.: onko käyttöliittymäosat erotettu selvästi sovelluslogiikasta? onko kerrosten välillä selvät rajapinnat? onko tietokanta abstrahoitu yleisen rajapinnan taakse? Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 22
Skenaariopohjaiset arviointimenetelmät SAAM (Software Architecture Analysis Method) keskittyy erityisesti muunneltavuuteen, siirrettävyyteen, ylläpidettävyyteen kehitetty SEI:ssä perustuu evoluutioaikaisiin skenaarioihin ATAM (Architecture Tradeoff Analysis Method) soveltuu kaikille laatuominaisuuksille kehitetty SEI:ssä johdettu SAAM:ista MPM (Maintenance Prediction Method) keskittyy ylläpidettävyyteen pyrkii löytämään suht. tarkat kustannusarviot ylläpidolle Jan Bosch:in kehittämä perustuu ylläpitoskenaarioihin Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 23
ATAM tietovuo Len Bass Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 24
ATAMin peruskäsitteet Skenaario: arkkitehtuurin testitapaus Laatupuu: kohdejärjestelmän laatuvaatimusten tarkennus asteittain skenaarioiksi (utility tree) Herkkyyskohta: muutokset tämän arkkitehtuuripäätöksen suhteen voivat aiheuttaa merkittäviä muutoksia johonkin laatuominaisuuteen (sensitivity point) Tasapainokohta: arkkitehtuuripäätös joka vaikuttaa useampaan laatuominaisuuteen vastakkaisiin suuntiin (tradeoff) Riski: arkkitehtuuripäätös joka saattaa aiheuttaa ongelmia tulevaisuudessa laatuattribuutin näkökulmasta Ei-riski: arkkitehtuuripäätös joka voi edesauttaa laatuominaisuuden toteutumisessa Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka
Skenaariot ja skenaariolajit Skenaario konkretisoi laatuvaatimuksen esimerkillä. Tapahtuma tai tapahtumasarja, joka liittyy johonkin laatuvaatimukseen. Skenaario on täsmällinen (vrt. testitapaus, use case) Skenaarion rakenne: Ärsyke - Ympäristö Vaste Käyttötapausskenaario: käyttäjän interaktio järjestelmän kanssa Etäkäyttäjä hakee tietokantaraportin web-käyttöliittymästä suurimman kuormahuipun aikana ja saa sen 5s kuluessa. Kasvuskenaario: ennakoituja muutoksia Järjestelmään lisätään uusi datapalvelin latenssin vähentämiseksi 2,5s, työ tehdään 1 henkilötyöviikossa. Tutkiva skenaario: odottamattomia muutoksia, kuormituksia jne. Puolet palvelimista kaatuu normaalissa käyttötilanteessa, tämä ei vaikuta järjestelmän saavutettavuuteen. Oletusympäristö: Normaali käyttötilanne Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka
Skenaario esimerkki Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 27
Skenaarion priorisointi Tavallisesti kaksiosainen prioriteetti: kuinka tärkeä (tuotepäällikkö, projektipäällikkö) kuinka vaikea toteuttaa (arkkitehti) Kolme arvoa: H (high), M (medium), L (low) Voidaan tehdä myös äänestämällä Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 28
Harjoitus Anna muunneltavuuteen liittyvä skenaario matkatavaroiden käsittelyjärjestelmälle Anna turvallisuuteen liittyvä skenaario matkatavaroiden käsittelyjärjestelmälle Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 29
laatuominaisuudet Suorituskyky Esimerkki: laatupuu tarkennukset Transaktioiden Käsittely Vasteaika skenaariot Käsittelee 1000 palvelupyyntöä/sek. (H,M) Käyttäjävarmistus < 1 sek. (H,M) GUI Web-pohjaiseksi 1 kk:ssa (M,H) Laatu Muunneltavuus Saatavuus GUI muutokset Tietokantamuutokset Laitteistoviat Tietokanta vaihdetaan Oracleksi 6 kk:ssa (L,H) Palvelimen kovalevyn hajoamisen jälkeen uusintakäynnistys 5 min:ssa (L,H) Tietoturvallisuus Palvelimen kaatuminen Korttien käyttö Uudelleenkäynnistys autentikaatiopalvelimen kaatuessa 5 min:ssa (M,M) Luottokortin tiedot turvassa 99.999% (H,L) Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka
Herkkyyskohta Herkkyyskohta = arkkitehtuuriratkaisu, joka on kriittinen jonkin laatuominaisuuden saavuttamisen kannalta. Esimerkki: MVC-mallin käyttö GUI arkkitehtuurissa on olennaista järjestelmän siirrettävyyden kannalta. Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 31
Tasapainokohta Tasapainokohta = herkkyyskohta, joka koskee useaa laatuominaisuutta (yleensä vastakkaisiin suuntiin) Esimerkki: XML:n käyttö syöttöformaattina parantaa järjestelmän integroitavuutta mutta heikentää sen suorituskykyä. Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 32
Riski Riski = potentiaalisesti ongelmallinen arkkitehtuuriratkaisu, joka voi heikentää jotain laatuominaisuutta Riski = ratkaisu/fakta + laatuseuraamus + perustelu Esimerkki: Kriteerit ja säännöt keskimmäisen kerroksen komponenttien tekemiselle ovat epäselvät (ratkaisu/fakta). Tästä voi seurata toiminnallisuuden replikointia eri kerroksissa (perustelu), mikä heikentää ylläpidettävyyttä (laatuseuraamus). Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 33
Ei-riski Ei-riski = arkkitehtuuriratkaisu, jolla on tiedossa (lähinnä) vain hyviä laatuseuraamuksia. Ei-riski = oletus + ratkaisu + laatuseuraamus + perustelu Esimerkki: Olettaen, että komponentit eivät joudu tutkimaan toistensa tilaa (oletus), Tarkkailija-suunnittelumallin käyttö komponenttien välisessä kommunikoinnissa (ratkaisu) parantaa muunneltavuutta (laatuseuraamus), koska komponenttien ei tarvitse tietää toisistaan mitään muuta kuin takaisinkutsu- ja rekisteröintirajapinnat (perustelu). Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 34
ATAMin vaiheet (2 päiväinen) 0. Ennakkovalmistelu 1. ATAMin esittely 2. Liiketoiminnan asettamat vaatimukset tuotteelle 3. Arkkitehtuuriesittely 4. Arkkitehtuurilähestymistapojen tunnistaminen 5. Laatupuun ja skenaarioiden laadinta 6. Arkkitehtuurilähestymistapojen analysointi 7. Skenaarioaivoriihi ja priorisointi 8. Arkkitehtuurilähestymistapojen analysointi 9. Tulosten esittäminen 1. päivä 2. päivä Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka
Osallistujat Sidosryhmät: Arkkitehti Ylläpitäjä Testaaja Standardiasiantuntija Turvallisuusvastaava Projektipäällikkö Tuotepäällikkö Asiakas Loppukäyttäjä Oheispalveluvastaava Sovellusalueen asiantuntija Laiteasiantuntija Huolto Markkinointi Ohjelmistokehittäjä 1. päivä 3-5 hlöä. Arkkitehti ja muista kiinteästi suunnittelussa tai toteutuksessa mukana olleita Arviointiryhmä 2. päivä 5-10 hlöä. Kattavasti kaikkien sidosryhmien edustajia Arviointiryhmä Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka
Päivä 1 ATAM prosessi ATAMin esittely ATAMin vaiheet ATAMin tekniikat (skenaariot, laatupuu, jne) Liiketoimintanäkökulma tärkeimmät toiminnallisuudet käyttäjien kannalta liiketoimintatavoitteet taloudelliset, poliittiset yms. rajoitteet Arkkitehtuuriesittely tekniset rajoitteet (kj, ohjelmistoalustat, laitteisto jne.) järjestelmän ulkoiset rajapinnat arkkitehtuurin kuvaus Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 37
Päivä 1 jatkuu Arkkitehtuuriratkaisujen tunnistaminen tunnistetaan ja nimetään käytetyt tyylit, suunnittelumallit ja omat ratkaisut selitetään miten ratkaisuilla oletetaan saavutettavan tietyt laatuvaatimukset Laatupuun ja skenaarioiden laatiminen tarkennetaan laatuvaatimukset järjestelmäkohtaisella ryhmittelyllä konkretisoidaan kukin tarkennettu laatuvaatimus skenaariolla priorisoidaan skenaariot tärkeyden ja vaikeuden perusteella Arkkitehtuuriratkaisujen analysointi keskitytään tärkeimpiin skenaarioihin kysytään: tekeekö tämä arkkitehtuuri mahdolliseksi skenaarion, miksi? arkkitehtuuri on syyllinen kunnes toisin todistetaan pyritään tunnistamaan riskit, turvalliset ratkaisut, herkkyyskohdat ja tasapainokohdat Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 38
Täydennys (Päivä 2) Skenaarioaivoriihi kaikki osapuolet esittävät skenaarioita omilta näkökulmiltaan uudet skenaariot priorisoidaan ja liitetään laatupuuhun vanhat skenaariot vahvistetaan Uusinta-analyysi tärkeimmät skenaariot tarkistetaan vasten arkkitehtuuria mahdolliset uudet riskit tunnistetaan Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 39
Raportointi ATAM:in tärkeimmät tulokset: Keskeisten arkkitehtuuriratkaisujen tunnistaminen Olennaisimpien laatuun vaikuttavien käyttö- ja kehitysskenaarioiden tunnistaminen Laatupuu skenaarioineen: kuvaus laatuvaatimusten ja arkkitehtuuriratkaisujen yhteydestä Arkkitehtuuriin liittyvien riskien tunnistaminen Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 40
Raportin rakenne (esimerkiksi) 1. Introduction 2. Target System 2.1 Description of the System 2.2 Most Important Architectural Solutions 3. Analyzed Scenarios 3.1 Maintainability 3.2 Reliability 3.3 Efficiency 3.4 Usability 4. Analysis Overview 4.1 General Observations 4.2 Specific Issues 4.3 About the Process 5. Conclusions References Appendix: Complete Scenario List Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 41
Skenaariot arviointiraportissa (esim.) Tyypillisesti 10-15 korkealle priorisoitua skenaariota Skenaarioon liittyvät arkkitehtuuriratkaisut tunnistetaan ja luokitellaan (esim. T = tasapainokohta, R = riski, N = eiriski) Arkkitehdin selvitys skenaarion hoitumisesta kirjataan (Description) Kunkin ratkaisun liittyminen skenaarioon selitetään (Argumentation) Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 42