Esimerkki: Auton toiminnan monitorointijärjestelmä

Transkriptio

1 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. Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 1

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

3 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. Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 3

4 Muita ratkaisuja? Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 4

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ä: Muunneltavuus Tietoturvallisuus Tarkkuus Suorituskyky Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 5

6 Laatuominaisuuksien tarkentaminen Muunneltavuus Tiedon muunneltavuus Laitteiden muutokset Tietokantamuutokset Tietoliikennemuutokset Suorituskyky Tapahtumien käsittely Tietokannan kapasiteetti Tarkkuus Tapahtumatietojen tarkkuus Tapahtuma-aikojen tarkkuus Tietoturvallisuus Tietoliikenneturvallisuus Tietovarastoturvallisuus Luotettavuus Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 6

7 Muunneltavuus Laatupuu ja analyysi taulukkomuodossa* Laatuvaatimus Skenaario Tärkeys Vaikeus Ratkaisut Riski analyysi *Käytetään tässä yksinkertaisuuden vuoksi Laatupuun rakentaminen Analyysi Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 7

8 Tarkennetaan laatuvaatimukset ja annetaan skenaariot Muunneltavuus Laatuvaatimus (tarkennettu) Skenaario Tärkeys Vaikeus Ratkaisutapa Riski analyysi Tiedon muunneltavuus Viestiformaatti muutetaan binääriseksi kuukaudessa M H CAN-väylän jokin viesti muuttuu rakenteeltaan, muutos viikossa H L Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 8

9 Harjoitus Anna esimerkkijärjestelmälle skenaario, joka liittyy a) Laitteiden muutoksiin b) Tapahtumatietojen tarkkuuteen c) Luotettavuuteen Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 9

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 Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 10

11 Täydennetään taulukko Muunneltavuus Laatuvaatimus (tarkennettu) Skenaario Tärkeys Vaikeus Ratkaisutapa Riski analyysi Tiedon muunneltavuus Viestiformaatti muutetaan binääriseksi kuukaudessa M H Viestirajapinta Riski: Viestien rakentaminen ja tulkinta muuttuu kaikissa komponenteissa. CAN-väylän jokin viesti muuttuu rakenteeltaan, muutos viikossa H L CANFilter erottaa CANin monitorijärjestelmästä Ei riskejä Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 11

12 (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, Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 12

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 Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 13

14 Muunneltavuus Laatuvaatimus (tarkennettu) Täydennetään taulukko Skenaario Tärkeys Vaikeus Ratkaisutapa Riski analyysi Tiedon muunneltavuus Viestiformaatti muutetaan binääriseksi kuukaudessa M H Viestirajapinta Riski: Viestien rakentaminen ja tulkinta muuttuu kaikissa komponenteissa CAN-väylän jokin viesti muuttuu rakenteeltaan, muutos viikossa H L CANFilter erottaa CANin monitorijärjestelmästä Ei riskejä Otetaan käyttöön uusi väylä kahdessa kuukaudessa H M Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 14

15 Testaus (Vaihe 2) Uusinta-analyysi tärkeimmät skenaariot tarkistetaan vasten arkkitehtuuria mahdolliset uudet riskit tunnistetaan Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 15

16 Muunneltavuus Laatuvaatimus (tarkennettu) Täydennetään taulukko Skenaario Tärkeys Vaikeus Ratkaisutapa Riski analyysi Tiedon muunneltavuus Viestiformaatti muutetaan binääriseksi kuukaudessa M H Viestirajapinta Riski: Viestien rakentaminen ja tulkinta muuttuu kaikissa komponenteissa CAN-väylän jokin viesti muuttuu rakenteeltaan, muutos viikossa H L CANFilter erottaa CANin monitorijärjestelmästä Ei riskejä Otetaan käyttöön uusi väylä kahdessa kuukaudessa H M Ei tukea Riski: Arkkitehtuuri on kiinteästi sidottu CANiin Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 16

17 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 Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 17

18 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ä Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 18

19 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 Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 19

20 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äytön kannalta kattaa muunneltavuuden jonkin laatuominaisuuskehikon kannalta Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 20

21 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ä Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 21

22 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, silti aina epätarkkaa Ongelmia voi helposti jäädä huomaamatta Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 22

23 Skenaarioiden johtaminen geneerisistä skenaarioista Node Yleinen skenaario Control functionality Intelligent sensor Log feed Boom movement Harvesteri skenaario Cabin door sensor Pressure sensor Porauskone skenaario Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 23

24 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. Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 24