Päivi Ovaska Tutkijaopettaja LTY/Tite

1. Ohjelmistotuotannon menetelmätSyksy 2003 Ohjelmiston määrittely, mallintaminen ja UML käyttötapaukset Päivi Ovaska Tutkijaopettaja LTY/Tite

2. Sisältö • Määrittely osana ohjelmistokehitystä • Mitä on määrittely • Oliokeskeisyys vs. toimintokeskeisyys • Mitä määritellään • Mallintaminen • Oliomäärittely • UML • UML käyttötapaukset ja niiden laatiminen • Tyypillisiä virheitä • Käyttötapausten hyödyt • Hyviä tenttikysymyksiä

3. Määrittely Suunnittelu& toteutus Määrittelyn asemointi asiakasvaatimukset ohjelmistovaatimukset

4. Mitä on määrittely • Sovellusalueen mallintaminen ohjelmistoksi • Lopputuloksena ohjelmistovaatimukset • Oliokeskeisen menetelmät vs rakenteiset menetelmät • Oliomenetelmät ovat 1980-luvun loppupuolelta lähtien vallanneet alaa ja ovat nyt “valtavirta” -- toisaalta ohjelmistot kehitetään käytännössä useimmiten ilman sen juhlallisempia menetelmiä.

5. Oliokeskeisyys vs. toimintokeskeisyys Oliokeskeinen Toimintokeskeinen Asiakas vaatimukset Perinteinen OOA = Object Oriented Analysis OOD = Object Oriented Design OOP = Object Oriented Programming OOA määrittely (esim SA) Perinteinen OOD suunnittelu Perinteinen OOP ohjelmointi

6. Mitä on määriteltävä - menetelmästä riippumatta Asiakasvaatimusten analysointi (=sovellusalueen ja ratkaistavan ongelman ymmärtäminen • Määrittely • Toiminnalliset ominaisuudet. • Ei-toiminnalliset ominaisuudet. • Rajoitteet ja reunaehdot.

7. Mallintaminen • mahdollistavat todellisuuden havainnollistamisen ja yksinkertaistamisen • sallivat eri abstraktiotasot, laajuudet ja näkökulmat • auttavat ymmärtämään sovellusaluetta • helpottavat kommunikointia koskien järjestelmää ja sovellusaluetta

8. Mallintaminen Takaisin- mallinnus Mallien generointi, tarkistus, ... Koodi Mallinnus Koodin generointi Järjestelmä

9. Oliomäärittely • Eri OOA-menetelmät ovat "enemmän samanlaisia kuin erilaisia" ja sisältävät seuraavia piirteitä: • Havainnollistetaan ja selvitetään asiakasvaatimuksia käyttötapauksilla. • Käyttötapausten perusteella pohditaan järjestelmän toiminnot. • Etsitään luokat (luokkakaaviot). • Etsitään olioiden väliset yhteydet ja periytymissuhteet. • Tutkitaan luokkien tilakäyttäytymistä (tilakaaviot). • Tutkitaan luokkien välistä kommunikointia (tapahtumasekvenssit ja oliovuorovaikutuskaaviot). • Yritetään jaotella luokat osajärjestelmiin.

10. UML • UML = Unified Modelling Language • Standardoi ohjelmistomallien esitystavan • UML ei ole menetelmä, vaan kaavioidenpiirtostandardi • Pitkän evoluution tulos, kehittyy edelleen • Tarkoitettu erityisesti oliopohjaisille ohjelmistoille • Ei liity suoranaisesti mihinkään suunnittelumenetelmään • OMG:n siunaama (standardoitu 1997) • Uusin versio 1.5 • Erittäin laaja • Tosiasiallinen standardi työkaluissa, kirjallisuudessa, teollisuudessa

11. UML – synteesi tunnetuimmista menetelmistä ”Three amigos” James Rumbaugh Ivar Jacobsson Grady Booch Designed by TerryQuatrani UML evangelist

12. UML kaaviot Käyttötapaus Käsittele puu Kuljettaja Sahaa tukki

13. UML:ää tukevia välineitä • CASE-välineet (Rational Rose, Prosa, Rhapsody, Together…) • Hinta verraten korkea (10-50kmk). • Perustuvat tietokantaan, johon talletetaan kaikki malliin liittyvät tiedot, kaaviot ovat vain “näkymiä” tietokantaan. • “Ymmärtävät” kaavioiden semantiikkaa ainakin jossain määrin. • Reverse Engineering+Forward Engineering = Round Trip Engineering. • Tukevat dokumentointia (esim. Soda+Rose) • Piirto-ohjelmat (Visio, ABCFlowcharter) • Hinta muutama KMK. • Ainakin Visiossa melko hyvä UML-tuki, lähestyy CASE-välineen ominaisuuksia. • Hyvä valinta, jos ei tarvitse CASE-välineen tietokannan tuomia lisäetuja. • www-osoitteessa http://www.objectsbydesign.com/tools/umltools_byCompany.html löytyy lista erilaisista UML työkaluista toimittajittain • Julkisohjelmiakin löytyy verkosta

14. View Contr UML ohjelmistonkehityksessä (yksinkertaistettu versio) Suunnitteluvaiheen luokkamalli Dialogimallit Analyysimalli Koodi Vaatimukset Class C { … } void C::m() { … } User User System UI User System Käyttötapaukset Operaatio- spesifikaatiot Tehtävä- spesifikaatiot Suunnitteluvaiheen tapahtumasekvenssit

15. UML puutteita • arkkitehtuurikuvaus jätetty huonommalle • voidaan soveltaa pakettikaavioita, sijoittelukaavioita, komponenttikaavioita, tapahtumasekvenssikaavioita… • näistä lisää arkkitehtuurisuunnittelun yhteydessä

16. UML käyttötapaukset • kehittäjä Ivar Jacobsson • järjestelmän ulkoinen interaktio, ulkoinen toiminnallisuus • yksinkertainen menetelmä asikasvaatimusten kuvaamiseen • kuvaa järjestelmän toiminnallisuuden käyttäjän järjestelmällä suorittamien toimintojen kuvauksenmuodossa • graafinen käyttötapauskaavio: järjestelmän interaktio käyttäjien kanssa • käyttötapauskuvaus: toiminnan yksityiskohtainen kuvaaminen • kukin käyttötapaus kuvataan tekstimuodossa (tukena voidaan käyttää myös muita kuvaustekniikoita, esim.tapahtumasekvenssikaavio, tilakaavio,aktiviteettikaavio) • kuhunkin käyttötapaukseen liittyy käyttäjärooleja (actor) • käyttäjä suorittaa kyseisen käyttötapauksen • samalla todellisella käyttäjällä voi olla useita rooleja • kuvaukseen voidaan merkitä myös käyttötapausten välisiä suhteita • käyttösuhde (include tai uses): monelle käyttötapaukselle yhteinen (osa)käyttötapaus voidaan kuvata erillisenä • laajennussuhde (extends): kuvaa käyttötapauksen olevan erikoistapaus toisesta (esim. salin varaaminen extends ls varaaminen ja hs varaaminen – ks. seuraava esimerkki) • myös muita suhteita voidaan käyttää

17. Graafinen käyttötapauskaavio: notaatio Järjestelmä Käyttötapaus sisältää laajennuskohtia, joihin toinen käyttötapaus voidaan sijoittaa Aktori: käyttötapaukseen osallistuva käyttäjä- tyyppi Käyttötapaus <<extend>> Käyttötapaus Käyttötapaus <<include>> Aktori Käyttötapaus on erikoistapaus toisesta Käyttötapaus Käyttötapaus sisältää toisen osanaan

18. Laajennusrelaatio Accounting System Pay invoice <<extend>> Seller Perform interaction Byer Pay overdraft fee

20. Toimija (actor) ja sen roolit Generalization

21. Yhteydet • UML 1.5 standardi • Generalization • Extend • Include

22. Käyttötapauskuvaus • UML ei standardoi esitystapaa. • Käyttötapauksen sisältö voidaan kuvata esimerkiksi: • Käyttötapauksen nimi: Kuvaava nimi • Osallistujat: Mitkä aktorit osallistuvat • Tuloehdot: Mitkä ehdot ovat voimassa, kun käyttötapaus • aloitetaan • Kuvaus: Epäformaali, voidaan käyttää myös sekvenssikaavioita • Poikkeukset: Poikkeustilanteet (mainitaan myös kuvauksessa) • Lopputulos: Mitkä ehdot ovat voimassa, kun käyttötapaus • lopetetaan • Muut vaatimukset: käyttötapaukseen liittyvät ei-toiminnalliset • vaatimukset

23. Esimerkki käyttötapauskuvauksesta • Nimi: Luentosalin varaaminen, versio 1.0 / ijh • Osallistujat: Kurssin vastuuhenkilö • Tuloehdot: Vastuuhenkilö ja kurssi on syötetty järjestelmään (KT henkilötietojen ylläpito) • Kuvaus: Vastuuhenkilö seuraa WWW-linkkiä, joka johtaa järjestelmän pääsivulle. Hän syöttää järjestelmään käyttäjätunnuksensa ja salasanansa (include: KT käyttäjän identifiointi). Käyttäjä pyytää järjestelmää näyttämään salin varaustilanteen haluamaltaan aikaväliltä. Hän saa eteensä salin lukujärjestysnäytön (ks. liite). Käyttäjä näkee näytöstä vapaat ajat sekä myös, mille kursseille sali on milloinkin varattu ja kuinka monelle viikolle. Käyttäjä tekee varauksen joltain vapaaksi havaitsemaltaan ajankohdalta. [Poikkeus: varaus ei onnistu]. • Poikkeukset: Varaus ei onnistu: Varaustilanne on voinut muuttua sillä aikaa kun varaaja tekee varausta. Järjestelmä ilmoittaa tilanteesta käyttäjälle ja käyttäjä yrittää uudelleen. • Lopputulos:Varaukset kurssin luentoajoiksi on tehty. • Muut vaatimukset:Päivittäin käsitellään kiireisimpänäkin aikana enintään n. 100 varausta. Vastausajan on oltava alle 1 sekuntia, lukujärjestysnäytön päivitys saa kestää 5 sekuntia.

24. Toinen esimerkki

25. Käyttötapausten laatimisesta • Käyttötapauskaavio tukee käyttötapojen suhteiden kuvaamista, ei niiden sisällön kuvaamista. UML ei määrittele sisällön esitystapaa. • Käyttötapausten tulee olla ymmärrettävissä sekä asiakkaan että suunnittelijan kannalta. • Kaikkia käyttötilanteita ei voi eikä kannata antaa käyttötapauksina. • Käyttötapauksella tulee olla selkeä aloitustilanne ja lopetustilanne. • Käyttötapauksen "suuruudesta" päättäminen voi olla vaikeaa: • Käyttötapauksen tulisi olla suhteellisen lyhyt (yhden sivun kuvaus). • Käyttötapaus tuottaa käyttäjälle lisäarvoa (ei yleensä yksittäinen ohjelmiston toiminto, vaan kokonainen tuloksen tuottava ketju toimintoja). • Käyttötapaus ei siis yleensä ole yksittäinen ohjelmalla suoritettava toiminto (ei siis esimerkiksi: tekstin kopiointi leikkuupöydälle).

26. Käyttötapauksen laatiminen • Määrittele roolit, jotka käyttävät järjestelmää = toimija, actor • Valitse yksi näistä toimijoista • Määrittele, mitä tämä toimija haluaa tehdä järjestelmällä

27. … käyttötapauksen laatiminen • Jokaisesta niistä asiasta, jota toimijaa haluaa tehdä järjestelmällä, tulee käyttötapaus (Use Case) • Jokaisesta käyttötapauksesta päätä, mikä on tavallisin tapahtumasarjojen ketju, jota käyttäjä tekee. Mitä tavallisesti tapahtuu. Tästä tulee perustapaus (basic course) • Kuvaa tämä perustapaus • Describe it as "Actor does something, system does something. Actor does something, system does something." but keep it at a high level. Do not mention any GUI specifics for example. Also you only describe things that the system does that the actor would be aware of and conversely you only describe what the actor does that the system would be aware of. • Do not worry about the alternate paths (extend) or common courses (include) ! Yet.

28. Esimerkki

29. … käyttötapauksen laatiminen 7. Kun olet tyytyväinen perustapaukseen, mieti poikkeustapaukset ja liitä ne laajennuksiksi (extend) perustapaukseen

30. Toista kohdat 2-7 jokaiselle toimijalle (actor)

31. … käyttötapauksen laatiminen • Katselmoi jokainen käyttötapaus ja vertaa niitä muihin käyttötapauksiin. Etsi yhteisiä osia. Erottele ne osiot, joissa yhteisiä tapauksia (include yhteys). Tämä on ainoa tapa erottaa nämä yhteiset tapaukset ja include yhteydet • The used, common course, Use Cases are actually the least important of the Use Cases to find. You would have a complete Use Case model even if you did no analysis of the Uses Cases to find these common courses. This is important to remember. Of course if you did not extract these common courses then you would not identify any commonality.

32. Esimerkki yhteisistä osista • UML 1.5 standardin mukaan uses=<<include>> extends=>>extend>>

33. … Käyttötapauksen laatiminen Älä kuvaa liikaa, mieluummin liian vähän!

34. Mikä vialla? Remember the purpose of Use Case modelling is to capture high-level user-centric requirements for the purpose of scoping the project and giving it some structure. Each Use Case is a unit of estimation and the smallest unit of deliverable.

35. Mikä vialla? Use Case: Enter A Sales Order • The actor selects a customer from a list displayed by the system. Use use case "Lookup Customer". The system then displays the sales order screen and the actor enters the item code and quantity required for each item. The system displays a running total of the value of the order. Once the order is complete the actor confirms the order and the systems resets ready for the next order. Use Case: Lookup Customer • The actor selects a customer by entering their reference number. The system then displays the complete details of that customer, name, address etc along with a complete history of purchases they have made.

36. Parempi versio Use Case: Enter A Sales Order • The actor selects a customer from a list displayed by the system. The actor selects a customer by entering their reference number. The system then displays the complete details of that customer, name, address etc along with a complete history of purchases they have made. The system then displays the sales order screen and the actor enters the item code and quantity required for each item. The system displays a running total of the value of the order. Once the order is complete the actor confirms the order and the systems resets ready for the next order.

37. Parannettu versio

38. Vielä yksinkertaistusta

39. Mikä suhteissa vialla?

40. Tyypillisiä virheitä käyttötapauskuvauksissa Use Case: Enter A Sales Order • The actor selects a customer from a list displayed by the system. The system then displays the sales order screen and the actor enters the item code and quantity required for each item. The system displays a running total of the value of the order. Once the order is complete the actor confirms the order and the systems resets ready for the next order. tai • Display list of customers from central database. • Actor chooses one of those customers. • The system displays sales order form. • While there are more items for this orderactor enters item and quantitysystem updates running total • End While • Confirm the Order Parannettu versio: The sales person selects a customer. The system prompts the salesperson to enter the details of the order (item code and quantity) and maintains a running total of the value of the order. Once the salesperson is happy with the order they confirm it and the system records the confirmed order.

41. Käyttötapausten hyödyt • Liittää asiakasvaatimukset järjestelmän toimintoihin (helpottaa ohjelmistovaatimusten muodostamista asiakasvaatimuksista) • Mahdollistaa vaatimusten täsmentämisen • Mahdollistaa yhteisen käsityksen tehtävästä järjestelmästä • Rajaa järjestelmän ympäristöstään • Auttaa tunnistamaan kuka tai mikä käyttää järjestelmää • Määrittää järjestelmän korkean tason toiminnallisuuden • Määrittää järjestelmän perustermit • Apuna olioiden tunnistamisessa • Voidaan käyttää ohjelmistokehityksen organisointiin (iteraatioiden suunnittelu) • Testauksen suunnittelu • Käyttöohjeiden laatiminen • Käyttöliittymäsuunnittelun perusta • Luo pohjaa toteutustyön jakamiselle

42. Vääriä luuloja … • Käyttötapaukset (mm.) eivät • ole arkkitehtuurisuunnittelun perusta • kuvaudu moduulirakenteeksi (yhtä käyttötapausta toteuttaa monta modulia; ks.seuraava kuva

43. Hyviä tenttikysymyksiä • Mikä on käyttötapausten rooli järjestelmän määrittelyn yhteydessä ? • Seuraava vaatimusmäärittely kuvaa kuljetusten hallintajärjestelmän: Järjestelmälle tulee kuljetuspyyntöjä, joissa annetaan kuljetettavan tavaran paino, koko sekä määränpää (kuljetukset tapahtuvat samasta varastosta). Kuljetukset tapahtuvat autoilla, joilla kullakin on oma kapasiteettinsa painon ja tavaroiden yhteiskoon suhteen. Lisäksi kuljetus voi tapahtua kiireellisissä tapauksissa helikopterilla, jolla on samoin oma kapasiteettinsa. Järjestelmällä on tieto käytettävissä olevasta kuljetuskalustosta, jota päivitetään aina, kun kuljetusväline lähtee tai saapuu. Järjestelmä pyrkii optimoimaan kuljetukset määräämällä tavaraerät mahdollisimman sopiviin kuljetusvälineisiin. Kuljetuksia voidaan yhdistää, jos niiden määränpäät ovat samalla alueella. Järjestelmällä on käytettävissään pieni geograafinen tietokanta. • Määrittele sovellukselle käyttötapaukset (graafinen esitys sekä yhdestä käyttötapauksesta sanallinen kuvaus) • Mitä tarkoitetaan ohjelmiston määrittelyllä ? Mikä on määrittelyn tarkoitus ja tavoitteet? • Mitä hyötyä on käyttötapausten tekemisellä ohjelmiston määrittelyssä? • Mitä tarkoittaa ohjelmiston mallintaminen ja miten UML kieli voi siinä auttaa?