Ohjelmistoarkkitehtuurit Kevät 2011-2012 Johannes Koskinen http://www.cs.tut.fi/~ohar/ Esimerkki: Auton toiminnan monitorointijä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. 2 CANBus CANFilter MessageDispatcherIF XMLMsg Message Dispatcher Msg type(): MsgType Component receive(msg) send(msg) register(msgtype,component) BrakeViewIF update() Brake- View BrakeModelIF BrakeController handleevent(event) BrakeState recordusage checkcondition register(view) getstate() setstate() GSMComp sendreport DBAccess 3 1
Analyysi (Vaihe 1) Arkkitehtuuriratkaisujen identifiointi tunnistetaan ja nimetään käytetyt tyylit, suunnittelumallit ja omat ratkaisut selitetään miksi ratkaisuun on päädytty 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. 4 Muita ratkaisuja? 5 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ä: Tietoturvallisuus Tarkkuus Suorituskyky 6 2
Laatuominaisuuksien tarkentaminen Tiedon muunneltavuus Laitteiden muutokset Tietokantamuutokset Tietoliikennemuutokset Suorituskyky Tapahtumien käsittely Tietokannan kapasiteetti Tarkkuus Tapahtumatietojen tarkkuus Tapahtuma-aikojen tarkkuus Tietoturvallisuus Tietoliikenneturvallisuus Tietovarastoturvallisuus Luotettavuus 7 Laatupuu ja taulukkomuodossa* Laatuvaatimus Skenaario Tärkeys Vaikeus Ratkaisut Riski *Käytetään tässä yksinkertaisuuden vuoksi Laatupuun rakentaminen Analyysi 8 Tarkennetaan laatuvaatimukset ja annetaan skenaariot Laatuvaatimus (tarkennettu) Tiedon muunneltavuus Skenaario Tärkeys Vaikeus Ratkaisut Riski Viestiformaatti muutetaan binääriseksi CAN-väylän jokin viesti muuttuu rakenteeltaan, muutos viikossa M H H L 9 3
Harjoitus Anna esimerkkijärjestelmälle skenaario, joka liittyy a) Laitteiden muutoksiin b) Tapahtumatietojen tarkkuuteen c) Luotettavuuteen 10 Analyysi (Vaihe 1) Arkkitehtuuriratkaisujen analysointi skenaarioiden pohjalta keskitytään tärkeimpiin skenaarioihin (priorisointi) kysytään: tekeekö tämä arkkitehtuuri mahdolliseksi skenaarion, miksi? pyritään tunnistamaan riskit, turvalliset ratkaisut, herkkyyskohdat ja tasapainokohdat 11 Täydennetään taulukko Laatuvaatimus (tarkennettu) Tiedon muunneltavuus Skenaario Tärkeys Vaikeus Ratkaisut Riski Viestiformaatti muutetaan binääriseksi CAN-väylän jokin viesti muuttuu rakenteeltaan, muutos viikossa M H Viestirajapinta H L CANFilter erottaa CANin monitorijärjestelmästä Riski: Viestien rakentaminen ja tulkinta muuttuu kaikissa komponenteissa. Ei riskejä 12 4
(Systemaattisempi tapa) 1) Arkkitehti kertoo vapaamuotoisesti, miten skenaario hoituu 2) Tunnistetaan ratkaisut, jotka mahdollisesti liittyvät skenaarioon 3) Analysoidaan tarkemmin, miten ko. ratkaisu liittyy skenaarioon ja onko se riski, ei-riski, 13 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 14 Täydennetään taulukko Laatuvaatimus (tarkennettu) Tiedon muunneltavuus Skenaario Tärkeys Vaikeus Ratkaisutapa Viestiformaatti muutetaan binääriseksi CAN-väylän jokin viesti muuttuu rakenteeltaan, muutos viikossa Otetaan käyttöön uusi väylä kahdessa M H Viestirajapinta H L CANFilter erottaa CANin monitorijärjestelmästä H M Riski Riski: Viestien rakentaminen ja tulkinta muuttuu kaikissa komponenteissa Ei riskejä 15 5
Testaus (Vaihe 2) Uusinta- tärkeimmät skenaariot tarkistetaan vasten arkkitehtuuria mahdolliset uudet riskit tunnistetaan 16 Täydennetään taulukko Laatuvaatimus (tarkennettu) Tiedon muunneltavuus Skenaario Tärkeys Vaikeus Ratkaisutapa Viestiformaatti muutetaan binääriseksi CAN-väylän jokin viesti muuttuu rakenteeltaan, muutos viikossa Otetaan käyttöön uusi väylä kahdessa M H Viestirajapinta H L CANFilter erottaa CANin monitorijärjestelmästä Riski Riski: Viestien rakentaminen ja tulkinta muuttuu kaikissa komponenteissa Ei riskejä H M Ei tukea Ei riski: joudutaan vaihtamaan vain filtteri 17 Kysyttävää? 18 6
Käytännön kokemuksia ja ongelmia skenaariopohjaisessa arvioinnissa Arkkitehtuurien arvioinnissa on monia käytännöllisiä ongelmia ja osittain avoimia kysymyksiä: Oikeiden laatuattribuuttien löytäminen Skenaarioiden tehokas löytäminen Skenaarioiden kattavuus Skenaarioiden priorisointi Skenaarioiden analysointi vasten arkkitehtuuria Analysointityökalujen hyödyntäminen 19 Oikeiden laatuattribuuttien lö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 Olennaista loppujen lopuksi on saada oikeat skenaariot, laatukehikkojen tehtävä on tukea tätä 20 Hyödyllisten skenaarioiden tehokas löytäminen Skenaarioiden keksiminen on prosessin kriittisin ja vaativin vaihe, edellyttää luovuutta Vaarana, että skenaariot ovat (tahattomasti) rajattuja: Skenaariot löydetään henkilöiden omien näkökulmien mukaan Skenaariot liittyvät sen hetkiseen tilanteeseen projektissa Skenaariot saattavat edustaa osallistujien kapeaa näkemystä Yksi ratkaisu: skenaariot kehitellään pareittan (yritys, arvioija) - villejä skenaarioita tulee helpommin 21 7
Skenaarioiden kattavuus Miten varmistutaan, että löydetty skenaariojoukko johtaa olennaisten laatuominaisuuksien riittävän kattavaan analysointiin? Vrt. testaaminen: testitapaukset ovat parempia kun eivät tule kehittäjiltä 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äyttötarpeiden kannalta kattaa muunneltavuuden jonkin laatuominaisuuskehikon kannalta 22 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, yrityksen edustajilla, arkkitehdillä, managerilla? Usein henkilö priorisoi kiinnostavia skenaarioita, ei välttämättä olennaisia Usein turvalliset skenaariot priorisoidaan 23 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, silti aina epätarkkaa Ongelmia voi helposti jäädä huomaamatta 24 8
Yhteenvetoa Arkkitehtuurin arviointi on suunnittelun testausta Arkkitehtuurien arviointia voidaan pitää systemaattisena arkkitehtuurin katselmointina. Arviointimenetelmät antavat mahdollisuuden kommunikointiin, mikä pitäisi joka tapauksessa jossain vaiheessa tehdä. 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. 25 Kysyttävää? 26 9