Ohjelmistoarkkitehtuurit. Kevät

Transkriptio

1 Ohjelmistoarkkitehtuurit Kevät Johannes Koskinen 1

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

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

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

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

6 Muita ratkaisuja? 6

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

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

9 Laatupuu ja analyysi taulukkomuodossa* Muunneltavuus Laatuvaatimus Skenaario Tärkeys Vaikeus Ratkaisut Riski analyysi *Käytetään tässä yksinkertaisuuden vuoksi Laatupuun rakentaminen Analyysi 9

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

11 Harjoitus Anna esimerkkijärjestelmälle skenaario, joka liittyy a) Laitteiden muutoksiin b) Tapahtumatietojen tarkkuuteen c) Luotettavuuteen 11

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

13 Täydennetään taulukko Muunneltavuus Laatuvaatimus (tarkennettu) Skenaario Tärkeys Vaikeus Ratkaisut 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ä 13

14 (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, 14

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

16 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ä Otetaan käyttöön uusi väylä kahdessa kuukaudessa H M 16

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

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

19 Kysyttävää?

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

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

22 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 pareittain (yritys, arvioija) - villejä skenaarioita tulee helpommin 22

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

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

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

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

27 Kysyttävää?