Mallinnus. 5. Järjestelmämallit. Abstraktiot. Mallinnuksen etuja. Arkkitehtuurimalli. Yhteysmallit. Ohjelmistotuotanto, järjestelmämallit Kevät 2005

Transkriptio

1 5. Järjestelmämallit Käyttäjävaatimukset pitää kirjoittaa luonnollisella kielellä. Niitä lukevat myös asiakkaat ja loppukäyttäjät. Järjestelmävaatimukset kannattaa kirjoittaa jollain rakenteisella kuvaustavalla. Näin niiden yhtenäisyys säilyy ja moniselitteisyyden vaara pienenee. Kevät 2005 Ohjelmistotuotanto / Taina 1 Mallinnus Eräs tapa tarkentaa vaatimuksia on kuvata kehitettävä järjestelmä järjestelmämalleilla. Järjestelmämalli on graafinen kuvaus, joka voi kuvata tuotteeseen liittyvät liiketoimintaprosessit, ratkaistavaan ongelmaan liittyviä asioita, kehitettävää järjestelmää. Kevät 2005 Ohjelmistotuotanto / Taina 2 Mallinnuksen etuja Abstraktiot Mallit ovat luonnolliseen kieleen verrattuna helpommin ymmärrettävissä, kompaktimpia, yksiselitteisempiä, sopivampia vaatimusanalyysista saatavaksi suunnitteluprosessin syötteeksi. Mallit eivät kuitenkaan korvaa käyttäjäja järjestelmävaatimuslistoja! Kevät 2005 Ohjelmistotuotanto / Taina 3 Mallinnuksen tärkein piirre on abstrahointi. Malliin ei sisällytetä kaikkea tietoa, vaan kukin malli on abstraktio järjestelmästä. Mitä korkeampi abstraktio on mallilla, sitä vähemmän yksityiskohtia näkyy. Mitä matalampi abstraktio, sitä vaikeampaa on saada mallista kokonaiskuvaa. Molemman tyyppisiä malleja tarvitaan. Kevät 2005 Ohjelmistotuotanto / Taina 4 Yhteysmallit Vaatimusmäärittelyn alkuvaiheessa pitää päättää kehitettävän järjestelmän ja sen toimintaympäristön rajat: mitä järjestelmään kuuluu, minkä muiden järjestelmien kanssa järjestelmä toimii yhteistyössä. Rajat saadaan selvitettyä keskustelemalla järjestelmän sidosryhmien edustajien kanssa. Kevät 2005 Ohjelmistotuotanto / Taina 5 Arkkitehtuurimalli Yksinkertaisin yhteysmalli on arkkitehtuurimalli. Malli kuvaa järjestelmät laatikkoina ja järjestelmien viivoina. Arkkitehtuurimallia voidaan käyttää sekä kuvaamaan kehitettävän järjestelmän yhteyksiä ulkomaailmaan että järjestelmän jakautumista osajärjestelmiksi. Kevät 2005 Ohjelmistotuotanto / Taina 6 Taina 1

2 Radar P o siti on Aircraft s imulatio n Weather map Accounting Arkkitehtuurimalliesimerkki (myös luku 1,kalvo 21 ) Transpo nd er Backup p os ition Da ta com ms. Flight plan d atabas e C o ntro l er info. C o m m s. Aircraft c om m s. Activ ity logging Telep ho ne Backup comms. Air Traffic Control architecture Controller consoles Kevät 2005 Ohjelmistotuotanto / Taina 7 Tietovuokaavio Tietovuokaavio kuvaa järjestelmän toiminnan yksityiskohtia. Malli kuvaa prosessit (tehtävät), prosessien välillä kulkevat syötteet ja tulosteet sekä mahdolliset tieto- ja materiavarastot. Kaaviot ovat hierarkkisia: yhtä kaavion prosessia voidaan tarkentaa uudessa kaaviossa aliprosesseiksi. Kevät 2005 Ohjelmistotuotanto / Taina 8 Korkeimman tason tietovuokaavio Syystä tai toisesta Sommerville kutsuu korkeimman tason kaaviota prosessimalliksi. Kyseessä on kuitenkin tietovuokaavio. Korkeimman tason kaaviossa kuvataan järjestelmän korkean tason prosessit ja järjestelmän kanssa yhteistyössä olevat muut järjestelmät sopivalla tarkkuudella. Kevät 2005 Ohjelmistotuotanto / Taina 9 Alemman tason tietovuokaaviot Kutakin prosessia voidaan tarkentaa aliprosesseiksi uudessa kaaviossa. Tällöin siirrytään samalla matalampaan abstraktioon. Tarkennuksessa tietoa ja materiaa ei synny eikä katoa. Toisin sanottuna kaikki prosessiin tulevat ka siitä lähtevät tieto- ja materiavuot ovat edelleen mukana myös tarkennuksissa. Kevät 2005 Ohjelmistotuotanto / Taina 10 Esimerkki: korkeimman tason tietovuokaavio Esimerkki: Korkeimman tason kaavion prosessin tarkennus Korkeimman tason tietovuokaavio. Katkoviivat osoittavat kehitettävän järjestelmän rajat. Kevät 2005 Ohjelmistotuotanto / Taina 11 Tarkennus edellisestä kaaviosta prosessista Place equipment order Kevät 2005 Ohjelmistotuotanto / Taina 12 Taina 2

3 5.1.kaavio kaavion rakenne kaavio kuvaa yhden tai useamman käyttötapauksen, tapausten toimijat tai roolit (actors) ja tapauksien keskinäiset ja roolien väliset suhteet. Kaaviotekniikka selkeyttää käyttötapausten keskinäisiä suhteita ja käyttötapauksiin liittyviä toimijoita. Silti sanalliset kuvaukset ovat käyttötapausten ydin. Kevät 2005 Ohjelmistotuotanto / Taina 13 Kuvattava käyttötapaus on jokin toimijan ja järjestelmän välinen toiminta alusta loppuun. Alku: Tila juuri ennen käyttötapausta. Esim. henkilö on käynnistämässä ohjelmaa. Loppu: Tila käyttötapauksen päätyttyä. Esim. henkilö sulkee käyttämänsä ohjelman. Kevät 2005 Ohjelmistotuotanto / Taina 14 Toimijat Toimija tai rooli liittyy yhteen tai useampaan käyttötapaukseen, ja yhteen käyttötapaukseen liittyy yksi tai useampi toimija. Yksi henkilö voi olla useassa eri roolissa eli useana eri toimijana käyttötapauksessa. Erikoistapaukset Käyttötapauksista voidaan tehdä erikoistapauksia Yleistys-relaatiolla. Näitä käytetään esimerkiksi silloin, kun halutaan kuvata oikein toimittuun käyttötapaukseen liittyviä virheellisiä toimintoja. Relaatio on Yleistys, koska varsinainen käyttötapaus on yleistys erikoistuneesta käyttötapauksesta. Kevät 2005 Ohjelmistotuotanto / Taina 15 Kevät 2005 Ohjelmistotuotanto / Taina 16 Sisältyvyydet kaavion symbolit Käyttötapauksien välillä voi olla sisältyvyyksiä (include). Tällöin useat käyttötapaukset voivat sisältää omiksi käyttötapauksiksi eroteltuja yhteisiä osia. Sisältyvyys on eräänlainen käyttötapauskaavion alikaavio, jota voidaan käyttää ylemmän tason kaavioista. Toimija/rooli (actor) Yleistys (generalization) <<include>> Sisältyvyys Kevät 2005 Ohjelmistotuotanto / Taina 17 Kevät 2005 Ohjelmistotuotanto / Taina 18 Taina 3

4 kaavioesimerkki 5.4. Tilasiirtymäkaaviot Asiakas Automaatille Lainaus Varaus Palautus Tiskille Teos myöhässä Laskutus Kirjastojen välinen teoshakemisto Kirjastonhoitaja Kevät 2005 Ohjelmistotuotanto / Taina 19 Kaikilla järjestelmilläja olioilla on tila: toteutuneiden tapahtumien vaikutus. Järjestelmä siirtyy tilasta toiseen, kun saapuva ulkoinen tapahtuma (event) vaikuttaa sen tilaan. Tilasiirtymäkaavioita käytetään kuvaamaan järjestelmän, osajärjestelmän tai olion kaikkia tiloja ja siirtymisiä tilasta toiseen. Kevät 2005 Ohjelmistotuotanto / Taina 20 Tilasiirtymäkaavion käyttö Tilat ja siirtymät Tilasiirtymäkaavio voidaan piirtää koko järjestelmästä, sen osasta tai oliosta. Periaate on aina sama. Vain mittakaava muuttuu. Tilasiirtymäkaavioilla voidaan esimerkiksi kuvata olion tai (osa)järjestelmän koko elinkaari. Kevät 2005 Ohjelmistotuotanto / Taina 21 Tilasiirtymäkaavioita käytetään kuvaamaan, miten järjestelmä reagoi tapahtumiin ja miten tapahtumat muuttavat järjestelmän tilaa. Jokainen tapahtuma tekee jotain järjestelmälle. Korkeilla abstraktiotasoilla tämä voidaan mallintaa sanomalla, että tapahtuma siirtää järjestelmän tilasta toiseen. Kevät 2005 Ohjelmistotuotanto / Taina 22 Tilasiirtymäkaavioesimerkki UML:n mukainen tilasiirtymäkaavioesimerkki (hissi) Ensimmäisessä kerroksessa ylös (kerros) ylös Lähtöpiste ensimmäiseen kerrokseen alas alas (kerros) Odottaa ajastin = 0 do/kasvata ajastinta help/anna opastusta Kevät 2005 Ohjelmistotuotanto / Taina 23 [ajastin = maksimi odotusaika]/alas (ensimmäinen kerros) Kevät 2005 Ohjelmistotuotanto / Taina 24 Taina 4

5 Tilaräjähdys Tietovuokaavioiden ongelma on siinä, että mahdollisten tilojen ja siirtymien määrä kasvaa erittäin nopeasti. Yksi tapa hallita kasvavia kaavioita on käyttää ylitiloja (superstates), jotka kapseloivat joukon tavallisia tiloja yhdeksi suureksi tilaksi. Ylitilaan tullaan ja sieltä lähdetään tavallisten tilojen tapaan. Ylitilaesimerkki Ylitilasta voi olla suoria siirtymiä ylitilan ulkopuolelle. Ylitilaan tultaessa tulee kertoa, mihin ylitilan sisäiseen tilaan tullaan. Ylitiloja käyttämällä saadaan hierarkisia tilasiirtymäkaavioita. Kevät 2005 Ohjelmistotuotanto / Taina 25 Kevät 2005 Ohjelmistotuotanto / Taina 26 Tietomallit Useimmissa isoissa ohjelmistoissa on osana tietokanta. Vaikka tietokannan suunnittelu on suunnittelua, työvaihe kannattaa silti tehdä vaatimusmäärittelyssä. Tietokannan rakenne voidaan esitellä asiakkaalle sopivalla tarkkuudella. Tietokannan tiedot ja yksityiskohdat saadaan varmistettua asiakkaalta. Kevät 2005 Ohjelmistotuotanto / Taina 27 ER-malli ja UML Yleisimmin käytetty tietokannan mallinnuskieli on ER-malli (Entity- Relationship). Sommerville kutsuu tätä ERA-malliksi (Entity-Relationship-Association). UML ei tarjoa puhdasta mallinnuskieltä, mutta UML:n luokkakaavioita voidaan käyttää tietokannan kuvaukseen. Kevät 2005 Ohjelmistotuotanto / Taina 28 Luokkakaavioista tietomalliin Luokkakaavioista saadaan tietomallin kuvauksia, kun käytetään vain luokkia ja tavallisia yhteyksiä, määritellään attribuuttien nimet ja tyypit, mutta ei määritellä luokille operaatioita, nimetään yhteydet ja kiinnitetään kullekin yhteydelle sen aste. Kevät 2005 Ohjelmistotuotanto / Taina 29 Tietomalliesimerkki Kevät 2005 Ohjelmistotuotanto / Taina 30 Taina 5