Ohjelmistoarkkitehtuurit Kevät 2011-2012 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 9. Ohjelmistoarkkitehtuurien arviointi Johdanto ATAM-menetelmä Esimerkki Käytännön kokemuksia ja ongelmia Yhteenveto 2 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 3 1
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ää 4 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 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) 6 2
Arkkitehtuurin rakentaminen kehitysprosessissa Laatuvaatimukset Arkkitehtuurin kannalta merkittävät vaatimukset Vaatimusanalyysi Keskeiset toiminnalliset vaatimukset Arkkitehtuurimuunnos Ympäristövaatimukset Rajoitteet Toissijaiset toiminnalliset vaatimukset Yksityiskohtainen suunnittelu Alustava arkkitehtuuri Yleisten ratkaisumallien soveltaminen Arkkitehtuurin arviointi Alustava arkkitehtuurisuunnittelu Laatuvaatimuksen huomiointi ei OK Kaikki käsitelty Arkkitehtuuri OK 7 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 8 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 9 3
ISO 9126 laatukehikko 10 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 11 Arkkitehtuuri ja liiketoimintatavoitteet 12 4
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? 13 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 14 Kysyttävää? 15 5
Ohjelmistoarkkitehtuurien arvioinnin ongelma? Laatuvaatimukset Ohjelmistoarkkitehtuuri 16 Laatuvaatimukset tulevat sidosryhmiltä Hyvä suorituskyky, luotettava, hyvä käytettävyys Helposti ylläpidettävä, siirrettävä Loppukäyttäjä Ylläpitäjä 17 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 esimerkki- tilanne, ja tutki täyttyykö ko. laatuominaisuus tässä esimerkkitilanteessa 18 6
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 19 Ohjelmistoarkkitehtuurien arvioinnin ongelman ratkaisu: skenaariopohjainen arviointi? Vaatimusten tarkennus Skenaariot Analyysi Laatuvaatimukset Ohjelmistoarkkitehtuuri Arkkitehtuuriratkaisut Ratkaisujen identifiointi 20 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ä 21 7
Analysointityökalujen hyödyntäminen Olemassa olevan 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ä 22 Esimerkki (Columbus): koodin kopiointi 23 Vaihtoehtoinen tapa: 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? 24 8
Kysyttävää? 25 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 26 ATAM tietovuo Len Bass 27 9
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 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 Skenaario esimerkki 30 10
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ä 31 Harjoitus 32 Laatu Esimerkki: laatupuu laatuominaisuudet Suorituskyky Muunneltavuus Saatavuus Tietoturvallisuus tarkennukset Transaktioiden käsittely Vasteaika GUI muutokset Anna muunneltavuuteen liittyvä skenaario VR:n matkalippuautomaattijärjestelmälle. Tietokantamuutokset Laitteistoviat Palvelimen kaatuminen Korttien käyttö skenaariot Käsittelee 1000 palvelupyyntöä/sek ilman viivettä käyttäjille. (H,M) Käyttäjävarmistus < 1 sek. (H,M) GUI Web-pohjaiseksi 1 kk:ssa (M,H) Tietokanta vaihdetaan Oracleksi 6 kk:ssa (L,H) Palvelimen kovalevyn hajoamisen jälkeen uusintakäynnistys 5 min:ssa (L,H) Uudelleenkäynnistys autentikaatiopalvelimen kaatuessa 5 min:ssa (M,M) Luottokortin tiedot turvassa 99.999% (H,L) 11
Herkkyyskohta Herkkyyskohta = arkkitehtuuriratkaisu, joka on kriittinen jonkin laatuominaisuuden saavuttamisen kannalta. Esimerkki: MVC-tyylin käyttö GUI arkkitehtuurissa on olennaista järjestelmän siirrettävyyden kannalta. 34 Tasapainokohta Tasapainokohta = herkkyyskohta, joka koskee useaa laatuominaisuutta (yleensä vastakkaisiin suuntiin) Esimerkki: XML:n käyttö tietoformaattina parantaa järjestelmän integroitavuutta mutta heikentää sen suorituskykyä. 35 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). 36 12
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). 37 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ä 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ä 13
ATAM prosessi (Päivä 1) 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 40 ATAM prosessi (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 41 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 42 14
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 43 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 44 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) 45 15
Kysyttävää? 46 16