UML-mallien testaaminen

Esitys aiheesta: "UML-mallien testaaminen"— Esityksen transkriptio:

1 UML-mallien testaaminen

2 UML-mallien testaaminen
käyttötapaukset (use cases) sekvenssikaaviot (sequence diagrams) luokkakaaviot (class diagrams) tilakaaviot (state-transition diagrams) [Copeland 2003]

3 UML-mallin testaamisen näkökulmat
Syntaksi, muoto ”Noudattaako kaavio sääntöjä?" Sovellusalueen osaaja ”Onko kaavio oikein?” ”Mitä kaaviosta puuttuu jonka pitäisi olla siellä?” Jäljitettävyys ”Onko kaavio jäljitettävissä sen edeltäjään?” ”Onko edeltäjä tulkittu oikein tässä kaaviossa?” [Copeland 2003]

4 Mikä on käyttötapaus? Listaa Vetää pois Etsii Tarjoaa Vetäytyy

5 Käyttötapauksen nimi Tarjous kohteesta Käyttöyhteys Tarjoaja haluaa ostaa kohteen Laajuus Järjestelmä Taso Ensisijainen tehtävä Ensisijainen toimija Tarjoaja Sidosryhmät ja intressit Myyjä, FLAKE.com Esiehdot Ei ole Onnistunut lopetus Tarjous on prosessoitu kohdetta vastaan Epäonnistunut lopetus Tarjousta ei ole prosessoitu; kohde ja sen tämänhetkinen tarjous Laukaisija Tarjoaja laitaa tarjouksen FLAKEen Kuvaus Askel 1 Tarjoaja antaa ”tarjoa kohteesta”- pyynnön Askel 2 FLAKE kierrättää uuden tarjouksen kaikkien aktiivisten tarjoajien kautta Askel 3 FLAKE odottaa tarjouksen ajastimen vanhenemista Askel 4 FLAKE ilmoittaa tarjoajille voitoista ja häviöistä Listaa Vetää pois Etsii Tarjoaa Vetäytyy Laajennukset EI OLE Muunnelmat Prioriteetti Kriittinen Vasteaika 5 sekunnissa Käyttötaajuus Noin kertaa päivässä Ensisijaisen toimijan kanavat Interaktiivinen web-käyttöliittymä Toissijaiset toimijat Toissijaisten toimijoiden kanavat Ei sovellettavissa Valmiuspäivämäärä Avoimet kysymykset

6 Käyttötapaus - Muodon näkökulma (1/2)
Täydellisyys: Onko kaikki kentät täytetty? Ymmärrämmekö todella mitä sanat tarkoittavat? Onko kaikki askeleet mukana määrittelyssä? Onko kaikki tavat tehdä asia oikein tunnistettu ja käsitelty sopivalla tavalla? Onko kaikkia yhdistelmiä harkittu? Onko tavat joilla asia voi mennä pieleen tunnistettu ja käsitelty sopivalla tavalla? Onko kaikkia yhdistelmiä harkittu? Yhdenmukaisuus: Pystyykö järjestelmä täyttämään määritellyt tavoitteet? [Copeland 2003]

7 Käyttötapaus - Muodon näkökulma (2/2)
Oikeellisuus: Onko käyttötapauksen nimi päätoimijan tavoite aktiiviverbimuodossa? Onko käyttötapauksen kuvauksen taso sopiva? Ovatko esiehdot pakollisia? Voiko järjestelmä taata ne? Suojaako epäonnistunut lopputilanne kaikkien osallisten etuja? Tyydyttääkö onnistunut lopputilanne kaikkia osallistujia? Kulkeeko pääskenaario käynnistymisestä onnistuneeseen lopputilaan? Ovatko askeleet oikein? Onko kukin askel nyt tapahtuvana aktiivisena toimintana joka edistää tavoitteen saavuttamista? Onko selkeää missä ja miksi vaihtoehtoiset skenaariot eroavat pääskenaariosta? Onko suunnittelupäätökset (GUI, tietokanta) jätetty pois käyttötapauksesta? Käytetäänkö ”yleistää”, ”sisältää” ja ”laajentaa” suhteita täysillä mutta oikein?

8 Käyttötapaus: sovellusalueen asiantuntijan näkökulma
Täydellisyys: Onko kaikki toimijat tunnistettu? Voitko nimetä tietyn ihmisen joka toimii kussakin toimijan roolissa? Onko tämä kaikki mitä pitää kehittää? Käsitelläänkö kaikki ulkoiset järjestelmä käynnistimet käsitelty? Onko kaikki sanat jotka viittaavat keskeneräisyyteen (joku, jne...) poistettu? Oikeellisuus: Onko tämä sitä mitä todella halutaan? Onko tämä kaikki jota todella halutaan? Onko tämä enemmän kuin oikeasti halutaan? Yhdenmukaisuus: Kun rakennamme järjestelmän näiden käyttötapausten mukaan, voimmeko määrittää että olemme onnistuneet? Voidaanko kuvattu järjestelmä oikeasti rakentaa? [Copeland 2003]

9 Käyttötapaus: jäljitettävyyden näkökulma
Täydellisyys: Muodostavatko käyttötapaukset tarinan joka avautuu loogisesti ylhäältä alas? Onko olemassa kontekstin asettava, korkean tason käyttötapaus kuvaamaan suunnittelun rajaa jokaiselle päätoimijalle? Oikeellisuus: Ilmaisevatko käyttötapaukset kaikkia järjestelmän toiminnallisia vaatimuksia? Onko kaikki tietolähteet listattu? Yhdenmukaisuus: Määrittävätkö käyttötapaukset kaiken toiminnallisuuden järjestelmän laajuudessa eikä mitään sen ulkopuolelta? Voimmeko jäljittää jokaisen käyttötapauksen sen käyttäjävaatimuksiin? Voimmeko jäljittää jokaisen käyttötapauksen eteenpäin sen toteuttaviin luokkiin ja kaavioihin? [Copeland 2003]

10 Sekvenssikaavio (1/2) } Totuusarvo Olio Aktiivinen Viesti Elinviiva
:Bidder :ListOf Bidders :Item :BidTimer Totuusarvo Olio new() setTimer() Aktiivinen newBidder(item, maxBidAmount) [validBidder] bid(item, maxBidAmount) Viesti bidUp() *[foreachBidder] Elinviiva } until noAddedBidUps timeElapsed() Iterointi setWinningBid (currentBid) Palautus youAreHighBidder() youAreHighBidder() Poisto

11 Sekvenssikaavio (2/2) Olio. Jokainen olio, joka osallistuu sekvenssikaavion esittämään tiedon käsittelyyn, piirretään kaavion yläreunaan. Elinviiva. Katkoviiva laskeutuu jokaisesta oliosta sekvenssikaaviossa. Aika etenee ylhäältä alas. Aktiivinen. Aikaviiva piirretään ohuena suorakulmiona osoittamaan, että olio on ajossa, ts. sillä on CPU hallinnassaan Viesti. Vaakasuora nuoli ilmaisee viestiä (komentoa), joka lähetetään yhdeltä oliolta toiselle. Palautus. Kun yksi olio komentaa toista, usein tulee takaisin paluuarvo. Katkoviivaa voidaan käyttää, jos vastauksessa on viivettä. Totuusarvo. Hakasulkeita käytetään ilmaisemaan ehdollista, t.s. Boolean-lausetta, joka päätyy joko arvoon TOSI tai EPÄTOSI. Viesti lähetetään vain jos tulos on TOSI. Iterointi. Hakasulut, joiden edessä on tähti(*), osoittavat iteraatiota. Poisto. X:ää käytetään osoittamaan olion päättymistä (tuhoamista).

12 Sekvenssikaavio: muodon näkökulma
Täydellisyys: Ilmeneekö jokainen tarvittava objekti kaaviossa? Oikeellisuus: Onko kaikki objektit joita ei tarvita vuorovaikutuksessa poistettu kaaviosta? Alkaako ja loppuuko objektin elinikä sopivaan aikaan? Onko objektien aktivointi kuvattu oikein? Kun objektin elinikä loppuu, onko se merkitty? Onko kukin viesti nimetty hyvin verbillä? Onko sopivat parametrit kullekin viestille määritelty? Onko ehtohaarat piirretty oikein? Yhdenmukaisuus: Sisältävätkö ehdot kaikki tapaukset? Onko ehtojen päällekkäisyyksiä poistettu? [Copeland 2003]

13 Sekvenssikaavio: sovellusalueen asiantuntijan näkökulma
Täydellisyys: Onko tavat joilla toiminta voi mennä oikein tunnistettu ja käsitelty oikein? Onko tavat joilla toiminta voi mennä väärin tunnistettu ja käsitelty oikein? Kulkeeko pääskenaario käynnistymisestä onnistuneeseen lopputilaan? Oikeellisuus: Näkyykö sekvenssikaaviossa kukin askel joka pitää suorittaa toiminnon aikaansaamiseksi? Voidaanko kukin askel oikeasti toteuttaa? [Copeland 2003]

14 Sekvenssikaavio: jäljitettävyyden näkökulma
Yhdenmukaisuus: Onko jokainen käyttötapaus esitetty ainakin yhdellä sekvenssikaaviolla? Esiintyykö kukin toimija ainakin yhdessä sekvenssikaaviossa? [Copeland 2003]

15 Luokkakaavio (1/2) Luokka Perintä Luokan nimi Aggregaatio Yksityinen
Attribuutit Julkinen Metodit Roolinimi Moninkertaisuus / Kardinaliteetti Assosiaatio

16 Luokkakaavio (2/2) Olio. Kokonaisuus tai käsite, jolla on merkitystä sovellusalueella. Luokka. Määritelmä joukolle mahdollisia olioita, joilla on sama tietosisältö, käytös ja suhteet. Attribuutti. Arvo, joka on määritelty luokassa ja sisältyy olioon. Käytös. Palvelu, joka on määritelty luokassa, ja jonka olio tarjoaa. Metodi. Käytöksen toteutus olio-ohjelmointikielellä. Assosiaatio. “Vertaiselta-to-vertaiselle“- suhde luokkien välillä. Aggregaatio. “Kokonaisuus- /osa-“ suhde luokkien välillä. Perintä. “Yleistys/yksittäistapaus" –suhde luokkien välillä. Kardinaliteetti/Moninkertaisuus. Assosiaatioon tai aggregaatioon osallistuvien olioiden minimi- ja maksimimäärät. Polymorfismi. Kyky lähettää viesti oliolle ilman, että tietää sen tarkkaa luokkaa.

17 Luokkakaavio: muodon näkökulma (1/2)
Täydellisyys: Määritteleekö kukin luokka attribuutit, metodit, suhteet ja määräsuhteet? Onko kukin assosiaatio nimetty selkeästi? Onko kunkin assosiaation ja aggregaation määräsuhde oikein? Yhdenmukaisuus: Onko kaikki 0..* ja 1..* suhteet toteutettu kokoelmina (containers/collectors)? Ovatko assosiaatioiden määräsuhteet yhdenmukaisia (hetkellinen vs jatkuva) [Copeland 2003]

18 Luokkakaavio: muodon näkökulma (2/2)
Oikeellisuus: Ovatko kaikki attribuutit yksityisiä? Ovatko kaikki parametrit eksplisiittisiä sen sijaan että ne olisi upotettu metodien nimiin? Toteuttavat aliluokat alisuhteen oikein? Esitetäänkö kaikki objektin tilat eksplisiittisesti tilojen ja siirtymien avulla aliluokkien sijaan? Onko perintärakenteissa kaikki attribuutit ja metodit niin ylhäällä kuin sopivaa? Onko kaikki polymorfiset metodit nimetty samalla tavalla liittyvissä aliluokissa? Heijastaako kukin assosiaatio suhdetta joka on olemassa objektien eliniän?

19 Luokkakaavio: sovellusalueen asiantuntijan näkökulma (1/2)
Oikeellisuus: Onko luokka nimetty substantiivilla Onko kaikki turhat, epäoleelliset tai epämääräiset luokat poistettu kaaviosta? Onko kukin attribuutti määritelty sopivassa luokassa? Onko se oikean tyyppinen? Onko kunkin attribuutin näkyvyys oikein? Onko oletusarvot attribuuteille määritelty oikein? Onko kukin attribuutti oleellinen sen sijaan että se olisi laskettavissa toisista? Onko jokainen metodi oikeassa luokassa? Ovatko metodien nimet verbejä? [Copeland 2003]

20 Luokkakaavio: sovellusalueen asiantuntijan näkökulma (2/2)
Oikeellisuus (jatkuu): Ottaako kukin metodi oikeat syöteparametrit ja palauttaa oikeat tulosparametrit? Onko kunkin metodin näkyvyys oikein? Toteuttaako kukin metodi vain yhden käyttäytymisen? Onko julkinen rajapinta määritelty ilman tarpeettomia metodeita? Yhdenmukaisuus: Onko luokkakaavio piirretty sopivalla tasolla: käsitekaavio, määrittely tai toteutus? [Copeland 2003]

21 Luokkakaavio: jäljitettävyyden näkökulma
Yhdenmukaisuus: Onko kukin sekvenssikaavion objekteista esitetty luokkana luokkakaaviossa? Onko jokainen viesti sekvenssikaaviossa peilattu metodina sopivassa luokassa? [Copeland 2003]

22 Tilakaavio (1/2) Toiminto Tapahtuma Vahti

23 Tilakaavio (2/2) Tila. Olion elinaikainen olotila, jossa se täyttää jonkun ehdon, suorittaa jonkun toiminnon tai odottaa jotakin tapahtumaa. Tapahtuma. Tapahtuma, joka voi laukaista tilasiirtymän. Tapahtumatyyppejä voivat olla eksplisiittinen signaali järjestelmän ulkopuolelta, heräte järjestelmän sisältä, tietyn ajanjakson kuluminen tai ehdon täyttyminen. Vahti. Boolean- lause. Kun se saa arvon tosi, se mahdollistaa sen, että tapahtuma voi laukaista tilasiirtymän. Siirtymä. Olion tilan muutos. Toiminto. Yksi tai useampi olion suorittama toiminto vastauksena tilasiirtymään.

24 Tilakaavio: muodon näkökulma (1/2)
Oikeellisuus: Onko kussakin tilasiirtymäkaaviossa tasan yksi alkutila? Jos tilakaavio on avoin (open-loop), onko sillä ainakin yksi lopputila? Jos tilakaavio on suljettu (closed-loop), onko se oikeasti tarpeen? Onko joka tilassa ainakin yksi poistuva siirtymä? Jos useita ehtoja on yhdelle tapahtumalle, ovatko ehdot toisensa poissulkevia? Onko kussakin tilassa tasan yksi siirtymä kullekin mahdollisille ehto-tapahtuma –kombinaatiolle? [Copeland 2003]

25 Tilakaavio: muodon näkökulma (2/2)
Oikeellisuus (jatkuu) Onko kaikki turhat ja toistuvat tilat tai siirtymät poistettu? Ovatko kaikki tilat saavutettavissa? Onko jokainen ”oikea” tila esitetty tasan yhtenä tilana kaaviossa? Onko jokainen tila ja siirtymä selkeästi nimetty? Ovatko kaikki mahdolliset polut sallittuja polkuja? Onko kaikki sallitut polut esitetty?

26 Tilakaavio: sovellusalueen asiantuntijan näkökulma
Täydellisyys: Onko kaikki tarvittavat tilat, tapahtumat, ehdot, siirtymät ja toiminnot kuvattu kaaviossa? Käsitelläänkö kaikki erikoistapaukset oikein? Oikeellisuus: Käytämmekö tilakaavioita vain luokilla joilla on monimutkaista ja kiinnostavaa käyttäytymistä? Ilmaiseeko kaavio oikein avointa/suljettua luonnetta luokassa? Onko kaikki tarvittavat tilat, tapahtumat, ehdot, siirtymät ja toiminnot oikein määritelty? Yhdenmukaisuus: Onko yksi yhteen suhde objektin tapahtumiin ja metodeihin nähtävissä? [Copeland 2003]

27 Tilakaavio: jäljitettävyyden näkökulma
Yhdenmukaisuus: Ilmentääkö tilasiirtymäkaavio kaikkia tiloja, tapahtumia, ehtoja, siirtymiä ja toimintoja vaatimuksista? [Copeland 2003]

28 Lähteet Copeland, L. Sequence Diagrams - Testing UML Models, Part a. Copeland, L. Use Cases - Testing UML Models, Part b. Copeland, L. Class Diagrams - Testing UML Models, Part a. Copeland, L. State-transition Diagrams - Testing UML Models, Part b.