7. Ohjelmistoarkkitehtuurien arviointi

Transkriptio

1 7. Ohjelmistoarkkitehtuurien arviointi Johdanto ATAM-menetelmä Esimerkki Käytännön kokemuksia ja ongelmia 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 Arkkitehtuurin rakentaminen kehitysprosessissa Laatuvaatimukset Arkkitehtuurin kannalta merkittävät vaatimukset Vaatimusanalyysi Keskeiset toiminnalliset vaatimukset Alustava arkkitehtuuri Alustava arkkitehtuurisuunnittelu Laatuvaatimuksen huomiointi Rajoitteet Toissijaiset toiminnalliset vaatimukset Arkkitehtuurimuunnos ei OK OK Kaikki käsitelty Yksityiskohtainen suunnittelu Arkkitehtuurin katselmointi Arkkitehtuuri 4

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

6 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

7 ISO 9126 laatukehikko 7

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

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

10 Varauksia Arviointi pohjautuu arkkitehtuurin kuvaukseen ja saatavilla olevaan informaatioon Arvioinnin tulosten tarkkuus riippuu lähtötietojen tarkkuudesta Arvioinnissa täytyy olettaa järkevä toteutus, arkkitehtuurin täytyy mahdollistaa järkevä toteutus 10

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

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

13 Laatuvaatimusten täsmentt smentäminenminen 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 13

14 Esimerkki skenaariosta Maintainability Extendability Easy to attach new devices A new sensor is attached Scenario: A new boom position sensor (& driver) for Model XYZ is taken into use in a week Skenaario voi olla käyttötapauksen kaltainen toimintakuvaus, tai ylläpito- tai muutostoimenpide, tai muulla tavoin konkretisoitu ja yksilöity laatuvaatimus, jota vasten arkkitehtuuria voidaan arvioida. Skenaario liittyy aina johonkin yleiseen laatuominaisuuteen. Skenaario voi olla järjestelmän rajoja hakeva tai tulevia mahdollisia muutoksia ennakoiva. 14

15 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ä 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ää hyvää työkalua 15

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

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

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

19 ATAM tietovuo Len Bass 19

20 Esittely (Vaihe 1) ATAM prosessi 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 20

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

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

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

24 Esimerkki 24

25 tai tekstinä: Muunneltavuus Käyttöliittymä Kielen vaihtaminen skenaario: kieli vaihdetaan venäjäksi 2 viikossa priorisointi: (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 priorisointi: (M, M) ratkaisu: MVC riski: tapahtumapohjainen Web GUI huonosti ymmärretty Tietokanta 25

26 tai perusteellisemmin analysoituna: 26

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

28 Riskitön n 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). 28

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

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

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

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

33 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 4.1 General Observations 4.2 Specific Issues 4.3 About the Process 5. Conclusions References Appendix: Complete Scenario List 33

34 Esimerkki: Auton toiminnan monitorointijärjestelm rjestelmä 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. 34

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

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

37 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 Tietoturvallisuus Tarkkuus Suorituskyky Saatavuus 37

38 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 tyypiltään H L 38

39 Harjoitus Anna esimerkkijärjestelmälle skenaario, joka liittyy a) tietoturvallisuuteen (security) b) tarkkuuteen (accuracy) c) muunneltavuuteen (modifiability) - XML viestityypin skeeman muuttuminen d) luotettavuus - viallinen CAN-viesti ei kaada järjestelmää - viallinen XML-viesti ei kaada järjestelmää 39

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

41 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 Riski: Viestien rakentaminen ja tulkinta muuttuu kaikissa komponenteissa. CAN-väylän jokin viesti muuttuu tyypiltään H L CANFilter erottaa CANin monitorijärjestelmästä Ei riskejä 41

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

43 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 Riski: Viestien rakentaminen ja tulkinta muuttuu kaikissa komponenteissa CAN-väylän jokin viesti muuttuu tyypiltään H L CANFilter erottaa CANin monitorijärjestelmästä Ei riskejä Otetaan käyttöön uusi väylä H M 43

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

45 Muunneltavuus Täydennetään n taulukko Laatuvaatimus (tarkennettu) 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 tyypiltään 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 45

46 Käytännön n kokemuksia ja ongelmia skenaariopohjaisessa arvioinnissa Arkkitehtuurien arvioinnissa on monia käytännöllisiä ongelmia ja osittain avoimia kysymyksiä: Arviointiprosessin organisointi Oikeiden laatuattribuuttien löytäminen Skenaarioiden tehokas löytäminen Skenaarioiden kattavuus Skenaarioiden priorisointi Skenaarioiden analysointi vasten arkkitehtuuria Analysointityökalujen hyödyntäminen 46

47 Arviointiprosessin organisointi Kysely Kyselyn tulokset Valmistelupalaveri Vaatimussessio Skenaariot Arkkitehtuurisessio Analyysi raportti Katselmointi Laatumallit Vaatimusdokumentit Arkkitehtuuridokumentit 47

48 Oikeiden laatuattribuuttien löytl ytäminen Olemassaolevat laatukehikot (esim. ISO 9126) saattavat olla vähemmän sopivia tietylle yritykselle/järjestelmälle (epärelevantteja laatuominaisuuksia, puuttuvia laatuominaisuuksia) Laatuominaisuudet voivat olla päällekkäisiä (esim. muunneltavuus vs. ylläpidettävyys vs. uudelleenkäytettävyys) Laatuominaisuuksia ei aina ymmärretä samalla tavalla TTY: Laatumalleja käytetään vasta jälkikäteen tarkistusmielessä ja selittämään laatuominaisuuksien merkitys. 48

49 Skenaarioiden tehokas löytl ytäminen Prosessin kriittisin ja vaativin vaihe Analogia: miten löydetään sopivat testitapaukset Vaarat: Skenaariot valitaan henkilöiden omien agendojen mukaan Skenaariot valitaan tukemaan nykyisiä valintoja ja päätöksiä Skenaariot edustavat osallistujien liian kapeaa näkemystä TTY: Skenaariot kehitellään pareittan (yritys, tutkija) edut: tehokkuus, villejä skenaarioita tulee helpommin 49

50 Skenaarioiden kattavuus Miten varmistutaan, että löydetty skenaariojoukko johtaa olennaisten laatuominaisuuksien riittävän kattavaan analysointiin? Mitä tarkoittaa kattava? Esim. oletetaan, että ollaan kiinnostuneita muunneltavuudesta. Mistä tiedetään, että skenaariot kattavat olennaiset asiat muunneltavuudesta? kattaa muunneltavuuden järjestelmän elinkaaren kannalta kattaa muunneltavuuden järjestelmän rakenteen kannalta kattaa muunneltavuuden järjestelmän käytön kannalta kattaa muunneltavuuden jonkin laatuominaisuuskehikon kannalta Käytännössä viimeksi mainittu on yksinkertaisin ja helpoin 50

51 Skenaarioiden priorisointi Tarkoitus: keskitytään olennaisiin laatuasioihin ko. järjestelmän suhteen (rajalliset resurssit analysoinnissa) Mikä on olennaista? olennaista projektin nykytilanteen kannalta olennaista pitkällä tähtäyksellä olennaista jonkin henkilön tai ryhmän omalla agendalla olennaista projektin pitämiseksi valitulla uralla Keillä on äänioikeus? Kaikilla, vai vain yrityksen edustajilla? Usein henkilö äänestää kiinnostavia skenaarioita, ei välttämättä olennaisia Tyypillisesti turvalliset skenaariot saavat paljon ääniä 51

52 Skenaarioiden analysointi vasten arkkitehtuuria Edellyttää kuvitteellisen järjestelmän tai sen evoluution suorittamista Yleensä arkkitehdin ja suunnittelijoiden tehtävä, koska heillä on tarvittava informaatio Nojaa arkkitehdin kykyyn ja motivaatioon tehdä riittävän huolellinen analyysi Ongelmia voi helposti jäädä huomaamatta 52

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

54 Esimerkki (Columbus): metriikat NII = number of incoming invocations 54

55 Esimerkki (Columbus): koodin kopiointi 55

56 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 ohjeistetussa muodossaan paljon resursseja, mitkä eivät ole aina saatavilla. 56