johdanto atam-menetelmä esimerkki käytännön kokemuksia ja ...ohar/luennot/luennot2010/ohar9...

Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 1

9. Ohjelmistoarkkitehtuurien arviointi

Johdanto

ATAM-menetelmä

Esimerkki

Käytännön kokemuksia ja ongelmia

Yhteenveto

Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka

Mitä on ohjelmistoarkkitehtuurin arviointi?

2

Ohjelmistoarkkitehtuurin arviointi tarkoittaa

toimintaa, jonka avulla voidaan tehdä johtopäätöksiä

siitä, miten hyvin tietty ohjelmistoarkkitehtuuri tukee

ko. järjestelmän vaatimusten toteutumista


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


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

dokumentti)

• Olemassaolevalle järjestelmälle (esim. vanhan

järjestelmän uudistaminen)


Arkkitehtuurin rakentaminen kehitysprosessissa

Arkkitehtuurin kannalta merkittävät vaatimukset

Alustava

arkkitehtuuriVaatimus-

analyysi

Arkkitehtuurin

arviointi

Alustava

arkkitehtuuri-

suunnittelu

Laatu-

vaatimuksen

huomiointi

Keskeiset

toiminnalliset

vaatimukset

Laatu-

vaatimukset

Arkkitehtuuri

Kaikki

käsitelty

ei

OK

Toissijaiset

toiminnalliset

vaatimukset

Rajoitteet

Yksityiskohtainen

suunnittelu

OK

Yleisten ratkaisu-

mallien

soveltaminen

Arkkitehtuuri-

muunnos

Ympäristö-

vaatimukset


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


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


ISO 9126 laatukehikko


Tarkennetut laatuominaisuudet

Efficiency

Time performance

Resource utilization

Response time

Memory usage

Scalability

Throughput

Maintainability

Analyzability

Changeability

Stability

Testability

Variability

Subsetability

Conceptual integrity

Traceability

Reliability

Maturity

Fault tolerance

Recoverability

Availability

Predictability

Usability

Understandability

Learnability

Operability

Attractiveness

Portability

Adaptability

Installability

Co-existence

Replaceability

Functionality

Suitability

Accuracy

Interoperability

Security

Data security

Access security

Safety

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


Arkkitehtuuri ja liiketoimintatavoitteet

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?


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


Ohjelmistoarkkitehtuurien arvioinnin ongelma

Laatu-

vaatimukset

Ohjelmisto-

arkkitehtuuri

?


Laatuvaatimukset tulevat sidosryhmiltä

Loppukäyttäjä

Hyvä suorituskyky, luotettava,

hyvä käytettävyys

Ylläpitäjä

Helposti ylläpidettävä,

siirrettävä


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


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


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 kohtien

löytämiseen (toimii lähinnä ylläpidettävyydelle),

edellyttää hyviä työkaluja

esim. suuret luokat, paljon riippuvuuksia komponenttien välillä


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ä


Esimerkki (Columbus): koodin kopiointi


Ohjelmistoarkkitehtuurien arvioinnin ongelman

ratkaisu: skenaariopohjainen arviointi

Laatu-

vaatimukset

Ohjelmisto-

arkkitehtuuri

Skenaariot

Vaatimusten

tarkennus

Arkkitehtuuri-

ratkaisut

Ratkaisujen

identifiointi

Analyysi

?


Ohjelmistoarkkitehtuurien arvioinnin ongelman

ratkaisu: tarkistuslistapohjainen arviointi

Laatu-

vaatimukset

Ohjelmisto-

arkkitehtuuri

Yleinen

tarkistuslista

Analyysi

?

Sovitettu

tarkistuslista

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


ATAM tietovuo

Len Bass


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


Skenaarion priorisointi

28

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


Harjoitus

29

Anna muunneltavuuteen liittyvä skenaario matkatavaroiden

käsittelyjärjestelmälle

Anna turvallisuuteen liittyvä skenaario matkatavaroiden

käsittelyjärjestelmälle


Esimerkki: laatupuu

Laatu

Suorituskyky

Muunneltavuus

Saatavuus

Tietoturvallisuus

laatuominaisuudet skenaariottarkennukset

Transaktioiden

Käsittely

Vasteaika

GUI muutokset

Tietokanta-

muutokset

Laitteistoviat

Palvelimen

kaatuminen

Korttien käyttö

Käsittelee 1000

palvelupyyntöä/sek. (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)


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.


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


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).


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).


ATAMin vaiheet (2 päiväinen)

1. päivä

2. päivä

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


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ä


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


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)

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


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


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


Skenaariot arviointiraportissa (esim.)

42

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)

…

johdanto atam-menetelmä esimerkki käytännön kokemuksia ja ...ohar/luennot/luennot2010/ohar9...

Documents