Johdanto ATAM-menetelmä Esimerkki Käytännön kokemuksia ja ...ohar/luennot/luennot2009/Ohar9 Arviointi1.pdf · Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1 9

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

9. Ohjelmistoarkkitehtuurien arviointi9. Ohjelmistoarkkitehtuurien arviointi

JohdantoATAM-menetelmäEsimerkkiKäytännön kokemuksia ja ongelmiaYhteenveto


Miksi ohjelmistoarkkitehtuuria on arvioitava?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 2009 TTY Ohjelmistotekniikka

Muita mahdollisia hyötyjä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?Milloin ohjelmistoarkkitehtuuri olisi arvioitava?

• Ensimmäisten (vaihtoehtoisten) luonnosten pohjalta (alustava arkkitehtuuridokumentti)

• Arkkitehtuurisuunnittelun jälkeen, ennen toteutuksenaloittamista (järjestelmä/alijärjestelmäarkkitehtuuri-dokumentti)

• Olemassaolevalle järjestelmälle (esim. vanhan järjestelmän uudistaminen)


Arkkitehtuurin rakentaminen kehitysprosessissaArkkitehtuurin rakentaminen kehitysprosessissaArkkitehtuurin kannalta merkittävät vaatimukset

Alustavaarkkitehtuuri

Vaatimus-analyysi

Arkkitehtuurinarviointi

Alustavaarkkitehtuuri-suunnittelu

Laatu-vaatimuksenhuomiointi

Keskeisettoiminnallisetvaatimukset

Laatu-vaatimukset

Arkkitehtuuri

Kaikkikäsitelty

ei OK

Toissijaisettoiminnallisetvaatimukset

Rajoitteet

Yksityiskohtainensuunnittelu

OK

Yleisten ratkaisu-mallien soveltaminen

Arkkitehtuuri-muunnos

Ympäristö-vaatimukset


Arkkitehtuuri ja laatuvaatimuksetArkkitehtuuri ja laatuvaatimukset

• Tässä laadulla ei viitata virheettömyyteen vaan siihen millä laadulla järjestelmä tekee loogiset toimintonsa

• Arkkitehtuuri määrää miten (useimmat) laatuvaatimuksettoteutuvat. Hiukan kärjistäen: Ohjelmistoarkkitehtuuri on tapa toteuttaa ohjelmiston laatuvaatimukset

• Arkkitehtuurin kuvauksen täytyy sisältää kaikki se informaatio, joka tarvitaan päättelemään laatuvaatimustentoteutuminen tai toteutumattomuus

• Arkkitehtuuria arvioidaan (yleensä) vasten laatuvaatimuksia


Ohjelmistojen laatuominaisuudetOhjelmistojen 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


ISO 9126 laatukehikkoISO 9126 laatukehikko


Tarkennetut laatuominaisuudetTarkennetut laatuominaisuudet

EfficiencyTime performanceResource utilizationResponse timeMemory usageScalabilityThroughput

MaintainabilityAnalyzabilityChangeabilityStabilityTestabilityVariabilitySubsetabilityConceptual integrityTraceability

ReliabilityMaturityFault toleranceRecoverabilityAvailabilityPredictability

UsabilityUnderstandabilityLearnabilityOperabilityAttractiveness

PortabilityAdaptabilityInstallabilityCo-existenceReplaceability

FunctionalitySuitabilityAccuracyInteroperabilitySecurityData securityAccess security

Safety

Ryhmittelyllä ei käytännössä paljon merkitystä arvioinnissa


Arkkitehtuuri ja liiketoimintatavoitteetArkkitehtuuri ja liiketoimintatavoitteet

10


Arvioinnin tulokset Arvioinnin tulokset

Ohjelmistoarkkitehtuurin arviointi vastaa tyypillisesti seuraaviinkysymyksiin:

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?


VarauksiaVarauksia

• 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


Ohjelmistoarkkitehtuurien arvioinnin ongelmaOhjelmistoarkkitehtuurien arvioinnin ongelma

Laatu-vaatimukset

Ohjelmisto-arkkitehtuuri

?


Laatuvaatimukset tulevat sidosryhmiltäLaatuvaatimukset tulevat sidosryhmiltä

Loppukäyttäjä

Hyvä suorituskyky, luotettava,hyvä käytettävyys

Ylläpitäjä

Helposti ylläpidettävä,siirrettävä


Laatuominaisuuksien arviointiLaatuominaisuuksien 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


Laatuvaatimusten täsmentäminen Laatuvaatimusten täsmentäminen skenaarioillaskenaarioilla

• 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


Tiedon louhinta arkkitehtuurista Tiedon louhinta arkkitehtuurista

• Asiantuntijoiden näkemyksetesim. pääarkkitehti, muita vastaavia järjestelmiäsuunnitelleet arkkitehdit ym.

• Takaisinmallinnuskoodia voidaan abstrahoida takaisinmallinnustyökaluilla, ei tuota varsinaista arkkitehtuurikuvausta vaan analysoi erilaisia riippuvuuksia

• Simulointijos on olemassa ajettava malli, voidaan tutkia arkkitehtuurista johtuvaa suorituskykyä, luotettavuutta; edellyttää järjestelmän mallintamista ja hyvää työkalua

• Metriikatvoidaan käyttää karkeana työkaluna epäilyttävien kohtienlöytämiseen (toimii lähinnä ylläpidettävyydelle),edellyttää hyviä työkalujaesim. suuret luokat, paljon riippuvuuksia komponenttien välillä


Analysointityökalujen hyödyntäminenAnalysointityö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ä


Esimerkki (Columbus): koodin kopiointiEsimerkki (Columbus): koodin kopiointi


Ohjelmistoarkkitehtuurien arvioinnin ongelman Ohjelmistoarkkitehtuurien arvioinnin ongelman ratkaisu: skenaariopohjainen arviointiratkaisu: skenaariopohjainen arviointi

Laatu-vaatimukset


Skenaariot

Vaatimustentarkennus

Arkkitehtuuri-ratkaisut

Ratkaisujenidentifiointi

Analyysi

?


Ohjelmistoarkkitehtuurien arvioinnin ongelman Ohjelmistoarkkitehtuurien arvioinnin ongelman ratkaisu: tarkistuslistapohjainen arviointiratkaisu: tarkistuslistapohjainen arviointi

Laatu-vaatimukset


Yleinentarkistuslista

Analyysi

?

Sovitettutarkistuslista

Järjestelmätyyppi

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?


Skenaariopohjaiset arviointimenetelmätSkenaariopohjaiset arviointimenetelmätSAAM (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


ATAM tietovuoATAM tietovuo

Len Bass


ATAMin peruskäsitteetATAMin 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ökulmastaEi-riski: arkkitehtuuripäätös joka voi edesauttaa laatuominaisuuden toteutumisessa


Skenaariot ja skenaariolajitSkenaariot 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ö – VasteKä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 muutoksiaJä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.


Skenaario esimerkkiSkenaario esimerkki


Skenaarion priorisointiSkenaarion priorisointi

27

• 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ä


HarjoitusHarjoitus

28

Anna muunneltavuuteen liittyvä skenaario robotinvalmistajan tuotannonohjausjärjestelmälle

Anna turvallisuuteen liittyvä skenaario hissinohjausjärjestelmälle


Esimerkki: laatupuuEsimerkki: laatupuu

Laatu

Suorituskyky

Muunneltavuus

Saatavuus

Tietoturvallisuus

laatuominaisuudet skenaariottarkennukset

TransaktioidenKäsittely

Vasteaika

GUI muutokset

Tietokanta-muutokset

Laitteistoviat

Palvelimenkaatuminen

Korttien käyttö

Käsittelee 1000 palvelupyyntöä/sek. (H,M)Käyttäjävarmistus < 1 sek. (H,M)

GUI Web-pohjaiseksi1 kk:ssa (M,H)

Tietokanta vaihdetaanOracleksi 6 kk:ssa (L,H)

Palvelimen kovalevyn hajoamisenjälkeen uusintakäynnistys5 min:ssa (L,H)

Uudelleenkäynnistysautentikaatiopalvelimen kaatuessa 5 min:ssa (M,M)

Luottokortin tiedot turvassa99.999% (H,L)


HerkkyyskohtaHerkkyyskohta

Herkkyyskohta = arkkitehtuuriratkaisu, joka on kriittinen jonkin laatuominaisuuden saavuttamisen kannalta.

Esimerkki:

MVC-mallin käyttö GUI arkkitehtuurissa on olennaista järjestelmän siirrettävyyden kannalta.


TasapainokohtaTasapainokohta

Tasapainokohta = herkkyyskohta, joka koskee useaalaatuominaisuutta (yleensä vastakkaisiin suuntiin)

Esimerkki:

XML:n käyttö syöttöformaattina parantaa järjestelmän integroitavuutta mutta heikentää sen suorituskykyä.


RiskiRiski

Riski = potentiaalisesti ongelmallinen arkkitehtuuriratkaisu, joka voi heikentää jotain laatuominaisuutta

Riski = ratkaisu/fakta + laatuseuraamus + perustelu

Esimerkki:

Kriteerit ja säännöt keskimmäisen kerroksen komponenttientekemiselle ovat epäselvät (ratkaisu/fakta). Tästä voi seuratatoiminnallisuuden replikointia eri kerroksissa (perustelu), mikä heikentää ylläpidettävyyttä (laatuseuraamus).


EiEi--riskiriski

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 kuintakaisinkutsu- ja rekisteröintirajapinnat (perustelu).


ATAMin ATAMin vaiheet (2 päiväinen)vaiheet (2 päiväinen)

1. päivä

2. päivä

0. Ennakkovalmistelu1. ATAMin esittely2. Liiketoiminnan asettamat vaatimukset tuotteelle3. Arkkitehtuuriesittely4. Arkkitehtuurilähestymistapojen tunnistaminen5. Laatupuun ja skenaarioiden laadinta6. Arkkitehtuurilähestymistapojen analysointi7. Skenaarioaivoriihi ja priorisointi8. Arkkitehtuurilähestymistapojen analysointi9. Tulosten esittäminen


OsallistujatOsallistujat

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 olleitaArviointiryhmä

2. päivä5-10 hlöä. Kattavasti kaikkien sidosryhmien edustajiaArviointiryhmä


ATAM prosessiATAM prosessiPä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


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


Täydennys (Päivä 2))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


RaportointiRaportointi

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


Raportin rakenne (esimerkiksi)Raportin rakenne (esimerkiksi)

1. Introduction2. Target System

2.1 Description of the System2.2 Most Important Architectural Solutions

3. Analyzed Scenarios3.1 Maintainability3.2 Reliability 3.3 Efficiency 3.4 Usability

4. Analysis Overview4.1 General Observations4.2 Specific Issues4.3 About the Process

5. ConclusionsReferences Appendix: Complete Scenario List


ArviointiraporttiArviointiraportti

41

Tyypillisesti 10-15 korkealle priorisoitua skenaariota

Skenaarioon liittyvät arkkitehtuuriratkaisut tunnistetaan ja luokitellaan (esim. T = tasapainokohta, R = riski, N = ei-riski)

Arkkitehdin selvitys skenaarion hoitumisesta kirjataan (Description)

Kunkin ratkaisun liittyminen skenaarioon selitetään (Argumentation)

…

Documents

Johdanto ATAM-menetelmä Esimerkki Käytännön kokemuksia ja ...ohar/luennot/luennot2009/Ohar9 Arviointi1.pdf · Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1 9