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 Taina 1
Mallinnuksen etuja 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 Abstraktiot 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 Taina 2
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 yhteyksiä 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 3
Arkkitehtuurimalliesimerkki (myös luku 1,kalvo 21 ) Radar Transponder Data comms. Aircraft comm s. Telep ho ne Position processor Backup position processor C o m m s. processor Backu p comms. processor Aircraft s imu lation Flight plan d at abas e Air Traffic Control architecture Weather map Acco un ting Controller info. Controller consoles Kuva I. Sommerville 2004 Activ ity log ging 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 Taina 4
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 ja siitä lähtevät tieto- ja materiavuot ovat edelleen mukana myös tarkennuksissa. Kevät 2005 Ohjelmistotuotanto / Taina 10 Taina 5
Esimerkki: korkeimman tason tietovuokaavio Korkeimman tason tietovuokaavio. Katkoviivat osoittavat kehitettävän järjestelmän rajat. Kuva I. Sommerville 2004 Kevät 2005 Ohjelmistotuotanto / Taina 11 Esimerkki: Korkeimman tason kaavion prosessin tarkennus Tarkennus edellisestä kaaviosta prosessista Place equipment order Kuva I. Sommerville 2004 Kevät 2005 Ohjelmistotuotanto / Taina 12 Taina 6
5.1.Käyttötapauskaavio Käyttötapauskaavio 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 Käyttötapauskaavion rakenne 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 Taina 7
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. Kevät 2005 Ohjelmistotuotanto / Taina 15 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 16 Taina 8
Sisältyvyydet 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. Kevät 2005 Ohjelmistotuotanto / Taina 17 Käyttötapauskaavion symbolit Käyttötapaus (Use Case) Toimija/rooli (actor) Yleistys (generalization) <<include>> Sisältyvyys Käyttötapaus (Use Case) Käyttötapaus (Use Case) Kevät 2005 Ohjelmistotuotanto / Taina 18 Taina 9
Käyttötapauskaavioesimerkki Lainaus Asiakas Varaus Palautus Kirjastojen välinen teoshakemisto Kirjastonhoitaja Automaatille Tiskille Laskutus Teos myöhässä Kevät 2005 Ohjelmistotuotanto / Taina 19 5.4. Tilasiirtymäkaaviot 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 Taina 10
Tilasiirtymäkaavion käyttö 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 Tilat ja siirtymät 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 Taina 11
Tilasiirtymäkaavioesimerkki Kuva I. Sommerville 2004 Kevät 2005 Ohjelmistotuotanto / Taina 23 UML:n mukainen tilasiirtymäkaavioesimerkki (hissi) Ensimmäisessä kerroksessa ylös (kerros) Menossa ylös Lähtöpiste perillä perillä ylös (kerros) Menossa ensimmäiseen kerrokseen Menossa alas perillä Odottaa ajastin = 0 do/kasvata ajastinta help/anna opastusta alas (kerros) [ajastin = maksimi odotusaika]/alas (ensimmäinen kerros) Kevät 2005 Ohjelmistotuotanto / Taina 24 Taina 12
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. Kevät 2005 Ohjelmistotuotanto / Taina 25 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. Kuva I. Sommerville 2004 Kevät 2005 Ohjelmistotuotanto / Taina 26 Taina 13
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 Taina 14
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 Kuva I. Sommerville 2004 Kevät 2005 Ohjelmistotuotanto / Taina 30 Taina 15