9. Ohjelmistoarkkitehtuurien arviointi

Transkriptio

1 9. Ohjelmistoarkkitehtuurien arviointi Johdanto ATAM menetelmä Esimerkki Yhteenveto 1

2 Miksi ohjelmistoarkkitehtuuria on arvioitava? Arkkitehtuuri on ensimmäinen täsmällinen kuvaus järjestelmästä Arkkitehtuuri sisältää järjestelmän kannalta kriittisimmät ratkaisut Arkkitehtuurin arviointi auttaa ymmärtämään paremmin järjestelmää Arkkitehtuurilla on vaikutuksia prosesseihin ja organisaatioon 2

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

4 Arkkitehtuuri ja laatuvaatimukset Arkkitehtuuri määrää miten (useimmat) laatuvaatimukset toteutuvat Arkkitehtuurin kuvauksen täytyy sisältää kaikki se informaatio, joka tarvitaan päättelemään laatuvaatimusten toteutuminen tai toteutumattomuus Arkkitehtuuria arvioidaan (yleensä) vasten laatuvaatimuksia 4

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

6 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? 6

7 Varauksia Arviointi pohjautuu arkkitehtuurin kuvaukseen Arvioinnin tulosten tarkkuus riippuu kuvauksen tarkkuudesta Arvioinnissa täytyy olettaa järkevä toteutus, arkkitehtuurin täytyy mahdollistaa järkevä toteutus 7

8 Arvioinnin perusongelma Laatuvaatimukset Arkkitehtuuri Täsmennys Täsmennetyt vaatimukset Vastaavuuden löytäminen Arvioinnin perustana oleva tieto arkkitehtuurista Tiedon louhinta 8

9 Laatuvaatimusten täsmennyst Hyvä suorituskyky, luotettava, hyvä käytettävyys Helposti ylläpidettävä, siirrettävä? Loppukäyttäjä Ylläpitäjä 9

10 Laatuvaatimusten täsmentt smentäminen 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. käyttötapaus toiminnallinen vaatimus Esimerkki: sadastuhannes käyttäjä pystyy loggautumaan sisään järjestelmään 0.1 sekunnissa (suorituskyky, skaalautuvuus) 10

11 Tiedon louhinta arkkitehtuurista Asiantuntijoiden näkemykset esim. pääarkkitehti, muita vastaavia järjestelmiä suunnitelleet arkkitehdit ym. 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ä Simulointi jos on olemassa ajettava malli, voidaan tutkia arkkitehtuurista johtuvaa suorituskykyä, luotettavuutta; edellyttää hyvää työkalua 11

12 Laatuvaatimusten liittäminen arkkitehtuuriin Skenaarioiden läpikäynti arkkitehtuurin kannalta arkkitehti suorittaa yksin (voi olla osa arkkitehtuurin rakentamista) tehdään ryhmässä arkkitehdin kanssa (ATAM) arkkitehtuurin valmistuttua Yleisten laatuvaatimus-arkkitehtuuri yhteyksien hyväksi käyttäminen 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? 12

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

14 ATAM (Architecture Tradeoff Analysis Method) Valmistelu Vaihe 1 Esittely Analyysi Vaihe 2 Testaus Raportointi 14

15 ATAM tietovuo Len Bass 15

16 Esittely (Vaihe 1) ATAM menetelmän kuvaus ATAMin vaiheet ATAMin tekniikat (skenaariot, laatupuu, jne) Liiketoimintanäkökulma tärkeimmät toiminnallisuudet käyttäjien kannalta liiketoimintatavoitteet taloudelliset, poliittiset yms. rajoitteet Arkkitehtuurin esittely tekniset rajoitteet (kj, ohjelmistoalustat, laitteisto jne.) järjestelmän ulkoiset rajapinnat arkkitehtuurin kuvaus 16

17 Analyysi (Vaihe 1) Arkkitehtuuriratkaisujen identifiointi tunnistetaan ja nimetään käytetyt tyylit, suunnittelumallit ja omat ratkaisut selitetään miten ratkaisuilla oletetaan saavutettavan tietyt laatuvaatimukset Laatupuun rakentaminen tarkennetaan laatuvaatimukset järjestelmäkohtaisella ryhmittelyllä konkretisoidaan kukin tarkennettu laatuvaatimus skenaariolla priorisoidaan skenaariot tärkeyden ja vaikeuden perusteella Arkkitehtuuriratkaisujen analysointi skenaarioiden pohjalta keskitytään tärkeimpiin skenaarioihin kysytään: tekeekö tämä arkkitehtuuri mahdolliseksi skenaarion, miksi? pyritään tunnistamaan riskit, turvalliset ratkaisut, herkkyyskohdat ja tasapainokohdat 17

18 Laatu Suorituskyky Muunneltavuus Saatavuus Tietoturvallisuus laatuominaisuudet Laatupuu Transaktioiden käsittely Vasteaika GUI muutokset Tietokantamuutokset Laitteistoviat Palvelimen kaatuminen Korttien käyttö tarkennukset skenaariot 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) Kovalevyn hajoamisen jälkeen uusintakäynnistys 5 min:ssa (L,H) Uudelleenkäynnistys palvelimen kaatuessa 5 min:ssa (M,M) Luottokortin tiedot turvassa % (H,L) 18

19 Muunneltavuus Taulukkomuodossa Laatuvaatimus Skenaario Tärkeys Vaikeus Ratkaisutapa Riski analyysi Laatupuun rakentaminen Analyysi 19

20 Esimerkki 20

21 tai tekstinä: Muunneltavuus Käyttöliittymä Kielen vaihtaminen skenaario: kieli vaihdetaan venäjäksi 2 viikossa (H, L) ratkaisu: lokalisointitaulut, Unicode riski: käänteiset lukemisjärjestykset eivät tuettuja GUI:ssa Alustan vaihtaminen skenaario: Web-pohjainen GUI toteutetaan 1 kk:ssa (M, M) ratkaisu: MVC riski: tapahtumapohjainen Web GUI huonosti ymmärretty Tietokanta 21

22 Esimerkki 22

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

24 Turvallinen ratkaisu Turvallinen ratkaisu = arkkitehtuuriratkaisu, jolla on tiedossa (lähinnä) vain hyviä laatuseuraamuksia. Turvallinen ratkaisu = 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). 24

25 Herkkyyskohdat Herkkyyskohta = arkkitehtuuriratkaisu, joka on kriittinen jonkin laatuominaisuuden saavuttamisen kannalta. Esimerkkejä: MVC-mallin käyttö GUI arkkitehtuurissa on olennaista järjestelmän siirrettävyyden kannalta. Abstraktin tehtaan käyttö erilaisten ajurien luomiseen on olennaista järjestelmän muunneltavuuden kannalta. 25

26 Tasapainokohdat Tasapainokohta = herkkyyskohta, joka koskee useaa laatuominaisuutta (yleensä vastakkaisiin suuntiin) Esimerkkejä: Tila-suunnittelumallin käyttö tilakoneen arkkitehtuurissa parantaa muunneltavuutta mutta heikentää suorituskykyä verrattuna suoraan haarautumalauseeseen pohjautuvaan toteutukseen. XML:n käyttö syöttöformaattina parantaa järjestelmän integroitavuutta mutta heikentää sen suorituskykyä. 26

27 Testaus (Vaihe 2) Laatupuun täydentäminen 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 27

28 Raportointi ATAM:in tulokset: Keskeisten arkkitehtuuriratkaisujen tunnistaminen ja analyysi Olennaisimpien laatuun vaikuttavien käyttö- ja kehitysskenaarioiden tunnistaminen Laatupuu tiiviinä kuvauksena laatuvaatimusten ja arkkitehtuuriratkaisujen yhteydestä Arkkitehtuuriin liittyvien riskien tunnistaminen 28

29 Raportin rakenne (esimerkiksi) 29

30 Example: Car service monitor system A car control system needs to be extended with a subsystem that collects various kinds of data during the running of the car, to be used for monitoring and service purposes. The control system is based on a CAN-bus. The bus is used to send messages between the components in the system. The monitoring system (called MS) listens to the messages sent along the CAN-bus. It should be possible to add later various kinds of processing capabilities to MS, reading certain kinds of messages, performing arbitrary computation on the basis of the transferred data, possibly storing the computed data on a local database, and sending in certain cases information to a central service station through GSM. For example, MS may collect information about the usage of gears and breaks, about the speed, about engine temperatures, consumption etc. The driver should have access to the collected information through a graphical user interface and activate or passivate certain information collecting services. Since MS is not controlling critical functions, there are no hard real-time requirements. It should be possible to receive monitored information also from external unknown systems, and to receive monitoring requests from such external systems. The system should be easily configurable to various kinds of cars, and it should be possible to upgrade the system at run-time. 30

31 CANBus CANFilter MessageDispatcherIF XMLMsg Message Dispatcher Msg type(): MsgType Component receive(msg) send(msg) register(msgtype,component) BrakeModelIF BrakeViewIF update() Brake- View BrakeController handleevent(event) BrakeState recordusage checkcondition register(view) getstate() setstate() GSMComp sendreport DB 31

32 Analyysi (Vaihe 1) Arkkitehtuuriratkaisujen identifiointi tunnistetaan ja nimetään käytetyt tyylit, suunnittelumallit ja omat ratkaisut selitetään miten ratkaisuilla oletetaan saavutettavan tietyt laatuvaatimukset Esimerkki: Viestinvälitysarkkitehtuuri Komponentit kommunikoivat keskenään viesteillä, jotka välitetään erityisen viestien jakajan (tai viestiväylän) kautta. Selitys Ratkaisu tukee järjestelmän dynaamista laajennettavuutta, koska uusia palveluja ja komponentteja voi ladata järjestelmään ajoaikana. 32

33 Analyysi ( Vaihe 1) Laatupuun rakentaminen tarkennetaan laatuvaatimukset järjestelmäkohtaisella ryhmittelyllä konkretisoidaan kukin tarkennettu laatuvaatimus skenaariolla priorisoidaan skenaariot tärkeyden ja vaikeuden perusteella Keskeiset laatuominaisuudet tässä järjestelmässä: Muunneltavuus Laajennettavuus Suorityskyky Saatavuus Käytettävyys Ks. ISO 9126: Software product quality 33

34 Tarkennetaan laatuvaatimukset ja annetaan skenaariot Muunneltavuus Laatuvaatimus (tarkennettu) Skenaario Tärkeys Vaikeus Ratkaisutapa Riski analyysi Tiedon muunneltavuus Viestiformaatti muutetaan binääriseksi kuukaudessa (viestioliot) M H CAN-väylän jokin viesti muuttuu tai poistuu H L 34

35 Analyysi (Vaihe 1) Arkkitehtuuriratkaisujen analysointi skenaarioiden pohjalta keskitytään tärkeimpiin skenaarioihin kysytään: tekeekö tämä arkkitehtuuri mahdolliseksi skenaarion, miksi? pyritään tunnistamaan riskit, turvalliset ratkaisut, herkkyyskohdat ja tasapainokohdat 35

36 Täydennetään n taulukko Muunneltavuus Laatuvaatimus (tarkennettu) Skenaario Tärkeys Vaikeus Ratkaisutapa Riski analyysi Tiedon muunneltavuus Viestiformaatti muutetaan binääriseksi kuukaudessa (viestioliot) M H Viestirajapinta Viestien rakentaminen ja tulkinta muuttuu kaikissa komponenteissa CAN-väylän jokin viesti muuttuu tai poistuu H L CANFilter erottaa CANin monitorijärjestelmästä Ei riskejä 36

37 Testaus (Vaihe 2) Laatupuun täydentäminen kaikki osapuolet esittävät skenaarioita omilta näkökulmiltaan uudet skenaariot priorisoidaan ja liitetään laatupuuhun vanhat skenaariot vahvistetaan Tuotepäällikkö esittää seuraavan skenaarion: On mahdollista, että tulevaisuudessa yritys käyttää autoissaan omaa tiedonsiirtoväylää CANin asemasta tai lisäksi. Siksi järjestelmän tulisi voida lukea tietoa myös muualta kuin CAN-väylältä. => lisätään muunneltavuuskenaario ja priorisoidaan se 37

38 Täydennetään n taulukko Muunneltavuus Laatuvaatimus (tarkennettu) Skenaario Tärkeys Vaikeus Ratkaisutapa Riski analyysi Tiedon muunneltavuus Viestiformaatti muutetaan binääriseksi kuukaudessa (viestioliot) M H Viestirajapinta Viestien rakentaminen ja tulkinta muuttuu kaikissa komponenteissa CAN-väylän jokin viesti muuttuu tai poistuu H L CANFilter erottaa CANin monitorijärjestelmästä Ei riskejä Otetaan käyttöön uusi tiedon lähde H M 38

39 Testaus (Vaihe 2) Uusinta-analyysi tärkeimmät skenaariot tarkistetaan vasten arkkitehtuuria mahdolliset uudet riskit tunnistetaan 39

40 Muunneltavuus Laatuvaatimus (tarkennettu) Täydennetään n taulukko Skenaario Tärkeys Vaikeus Ratkaisutapa Riski analyysi Tiedon muunneltavuus Viestiformaatti muutetaan binääriseksi kuukaudessa (viestioliot) M H Viestirajapinta Riski: Viestien rakentaminen ja tulkinta muuttuu kaikissa komponenteissa CAN-väylän jokin viesti muuttuu tai poistuu H L CANFilter erottaa CANin monitorijärjestelmästä Ei riskejä Otetaan käyttöön uusi tiedon lähde H M Ei tukea Riski: Arkkitehtuuri on kiinteästi sidottu CANiin 40

41 Yhteenvetoa Arviointimenetelmät antavat mahdollisuuden kommunikointiin, mikä pitäisi joka tapauksessa jossain vaiheessa tehdä. Arkkitehtuurien arviointia voidaan pitää tavallista syvällisempänä ja systemaattisempana arkkitehtuurin katselmointina. Arkkitehtuurin arviointimenetelmät eivät ole kovin täsmällisiä, ne voidaan (ja on syytäkin) räätälöidä yrityskohtaisesti. Esim. ATAM vaatii perusmuodossaan paljon resursseja, mitkä eivät ole aina saatavilla. 41