Johdatus sovellussuunnitteluun

Transkriptio

1 DO NOT PRINT THIS DOCUMENT D Harri Laine Johdatus sovellussuunnitteluun luentomoniste osa 2 Helsingin yliopisto Tietojenkäsittelytieteen laitos 1999

2 Sisältö: MONISTE ON JATKOA OSALLE YLEISTYSHIERARKIA OLIOIDEN YHTEISTYÖ JA PALVELUIDEN MÄÄRITTELY SEKVENSSIKAAVIO YHTEISTYÖRAKENNEKAAVIO PALVELUJEN MÄÄRITTELYSTÄ JÄRJESTELMÄN PALVELUT SIDOSRYHMÄKAAVIO KÄYTTÖTAPAUSMALLI KÄYTTÖTAPAUSTEN JA SISÄLTÖLUOKKIEN YHTEENSOPIVUUS KUVAUKSET JA KEHITTÄMISPROSESSI... 75

3 3.5 Yleistyshierarkia Luokkakaavion laatiminen on kohdealueen jäsentämistä. Sitä tehtäessä luodaan tai kirjataan luokitusjärjestelmä kohdealueen ilmiöille. Luokitusjärjestelmälle voidaan asettaa erilaisia vaatimuksia. Joissakin menetelmissä edellytetään, että ilmiöt on luokiteltava siten, että kaikki luokat ovat erillisiä, ts. niillä ei ole yhteisiä ilmentymiä. Toiset menetelmät puolestaan sallivat ainakin jonkinasteisen luokkien päällekkäisyyden. Luonnollisessa kielessä luokittelu on vapaata. Käsitteet ja niitä vastaavat luokat ovat limittäisiä tai päällekkäisiä. Kun tarkastellaan miten luokan ilmentymien joukko suhtautuu toisen luokan ilmentymien joukkoon voidaan erottaa tapaukset: ilmentymäjoukot ovat aina pistevieraat (esim auto ja henkilö) ilmentymäjoukot voivat sisältää yhteisiä ilmentymiä (esim. nainen ja johtaja) ilmentymäjoukko sisältyy aina toisen luokan ilmentymäjoukkoon (esim. nainen ja henkilö). Jos luokan A ilmentymäjoukko sisältää aina luokan B ilmentymäjoukon on luokkien välillä yleistys-erikoistus (generalization - specialization) suhde. Käsite B on erikoistapaus käsitteestä A (nainen on henkilön erikoistapaus) tai päinvastoin käsite A on yleistys käsitteestä B (henkilö on yleiskäsite, johon nainen sisältyy). Kun luokkien suhdetta tarkastellaan yleistys-erikoistus suhteeseen perustuen kutsutaan yleisempää luokkaa yläluokaksi (super class) ja erikoistuneempaa alaluokaksi (subclass). Yläluokka on yleistyshierarkiassa (luokkahierarkiassa) ylemmällä tasolla, siis yleisempi, kuin alaluokka. Esimerkiksi voitaisiin määritellä luokka nainen on luokan henkilö alaluokka, luokka johtaja on luokan henkilö alaluokka, luokat auto, laiva ja lentokone ovat luokan kulkuväline alaluokkia. Siitä, että luokka B on luokan A alaluokka seuraa, että jokainen B:n ilmentymä on myös A:n ilmentymä, eli jokainen johtaja on myös henkilö. Tästä taas seuraa, että 40

4 kaikki yhteydet ja attribuutit, jotka ovat mahdollisia luokan A ilmentymille ovat mahdollisia myös B:n ilmentymille. Jos siis henkilölle on määritelty attribuutti Nimi ja johtaja on henkilön alaluokka, niin myös johtajalla on automaattisesti Nimiattribuutti. Jos henkilö on määritelty osapuoleksi työsuhde-yhteyteen, myös johtajan ilmentymä voi olla osapuolena työsuhde yhteydessä. Tätä ilmiötä kutsutaan periytymiseksi (inheritance). Periytymisessä yläluokkaan liitetyt attribuutit, palvelut ja yhteydet periytyvät alaluokalle, eli ovat voimassa myös alaluokan ilmentymille. On syytä pitää mielessä, että periytyminen on luokkien välistä määrittelyjen periytymistä - ilmentymät eivät peri mitään toisilta ilmentymiltä. Luokkakaavion laatimisen kannalta periytyminen tarkoittaa sitä, että piirrettä, joka on liitetty yläluokkaan ei tarvitse erikseen liittää alaluokkaan, vaan se liittyy sinne automaattisesti. Alaluokan ja yläluokan välinen riippuvuus kuvataan luokkakaaviossa alaluokasta yläluokkaan osoittavalla nuolella, jossa on iso kolmionmuotoinen kärki (kuva 3.32). Alaluokka Yläluokka Johtaja Henkilö Kuva 3.32: Yleistyshierarkian esittäminen. Alaluokkaan voidaan liittää yläluokalta perittyjen attribuuttien, palvelujen ja yhteyksien lisäksi omia attribuutteja, yhteyksiä ja palveluja. Esimerkiksi johtajalle voitaisiin lisätä attribuutit vastuualue ja alaisten määrä, joita ei ole henkilöillä yleisesti. Johtaja voitaisiin määritellä myös rooliin käyttäjä 'edustustilin käyttöoikeus' -yhteyteen ja rooliin esimies työnjohto-yhteydessä (kuva 3.33). 41

5 työnjohto * esimies Johtaja Vastuualue Alaisten määrä Henkilö 0..* Edustustilin käyttöoikeus 0..1 Edustustili Kuva 3.33: Johtajan lisäattribuutit ja -yhteydet Alaluokkaan johtaja voidaan liittää myös sellaisia palveluita, joita henkilöllä ei yleisesti ole. Tällaisia voisivat olla esimerkiksi maksa edustustililtä, laadi luettelo alaisista. Alaluokassa voidaan myös syrjäyttää (override) yläluokassa määritelty palvelu. Syrjäyttämisellä tarkoitetaan palvelun sisällön tai toteutustavan uudelleenmäärittelyä, nimen säilyessä kuitenkin ennallaan. Esimerkiksi Henkilöluokalle voisi olla määritelty palvelu Viikkoraportti, jonka sisältönä olisi kerro ajankäyttö työtehtäviin. Tämä voitaisiin syrjäyttää Johtaja-luokassa siten, että johtajan Viikkoraportti palvelun sisältö olisikin kerro ajankäyttö työtehtäviin, laadi yhteenveto alaisten viikkoraporteista raportoi edustustilin käyttö. Olio-ohjelmoinnissa olio tietää oman luokkansa ja suorittaa palvelunsa oman luokkansa mukaisina. Niinpä olio-ohjelmassa miltä tahansa luokan henkilö tai sen alaluokan oliolta voidaan pyytää Viikkoraportti-palvelua. Jos olio ei ole johtaja, vaan tavallinen henkilö, hän kertoo oman ajankäyttönsä, mutta jos olio onkin johtaja, hän toimii johtajan Viikkoraportti-palvelun mukaisesti ja laatii lisäksi yhteenvedon alaisten viikkoraporteista ja raportoi edustustilin käyttönsä. 42

6 Mahdollisuus syrjäyttää palvelumäärityksiä on olio-ohjelmoinnin tärkeimpiä etuja perinteisiin ohjelmointikieliin verrattuna. Se lisää joustavuutta ohjelmakirjastojen käytössä, edistää ohjelmistokomponenttien uudelleenkäytettävyyttä ja muodostaa perustan erilaisten ohjelmistokehysten rakentamiselle (kehykset ovat eräänlaisia sovellusrunkoja, joissa toiminnan yksityiskohdat on jätetty esimerkiksi syrjäyttämisen avulla täsmennettäväksi). Syrjäyttämismahdollisuus onkin olio-ohjelmoinnin kannalta merkittävin syy yleistyshierarkian käyttöön. Sen hyväksikäyttömahdollisuudet tulevat kuitenkin usein esiin vasta laadittaessa teknisen tason suunnitelmaa ohjelmiston luokkarakenteesta. Luokkakaaviossa syrjäytetty palvelu kuvataan toistamalla palvelun nimi alaluokassa. Kuva 3.34 on henkilö-luokan palvelu viikkoraportti syrjäytetty luokassa johtaja. Sen sijaan palvelu kerro_palkka periytyy samansisältöisenä luokalta henkilö luokalle johtaja * esimies Johtaja Henkilö Vastuualue Alaisten määrä viikkoraportti kerro_palkka viikkoraportti 0..* Edustustilin käyttöoikeus 0..1 Edustustili Kuva 3.34: Syrjäytetty palvelu viikkoraportti Kohdealuetta mallinnettaessa yleistyshierarkian tärkein käyttötilanne on kuvausvaivan säästäminen ja erilaisten sääntöjen täsmällinen ilmaiseminen. Jos usealla luokalla on samoja attribuutteja ja luokille voidaan määritellä yhteinen yläluokka, voidaan yhteiset attribuutit liittää yläluokkaan ja määritellä näin vain kertaalleen. Sääntöjen täsmällisemmästä esittämisestä voidaan tarkastella esimerkkinä tilannetta, jossa on 43

7 kuvattava auton omistusta. Auton omistajana voi olla henkilö tai yritys. Jokaisella autolla täytyy olla omistaja. Yleistyshierarkiaa käyttäen asia voidaan esittää kuvan 3.35 mukaisesti. Tällöin sääntö saadaan esitettyä. Jos asia yritetään esittää ilman yleistyshierarkiaa, päädytään esimerkiksi kuvan 3.36 mukaiseen malliin. Siinä sääntö ei näy kaaviossa, vaan se on esitettävä erikseen tekstikuvauksessa (oheisesa kuvassa puhekuplana), jolloin se jää vähemmälle huomiolle. oikeushenkilö 1..* * auto omistaja yritys henkilö Kuva 3.35: Auton omistus yleistyshierarkiaa käyttäen, pakollinen omistus näkyy. henkilö_omistus henkilö yritys 0..* omistaja * auto * 0..* yritys_omistus omistaja autolla pitää olla joko henkilöomistaja tai yritysomistaja Kuva 3.36: Auton omistus ilman yleistyshierarkiaa, omistuksen pakollisuus on esitettävä erillisenä sääntönä. Tilannetta, jossa luokka on useamman kuin yhden luokan välitön alaluokka kutsutaan moniperiytymiseksi (multiple inheritance) (kuva 3.37). 44

8 Kenraali Johtaja Sotilas Kuva 3.37: Moniperiytyminen. Moniperiytyminen voi olla kätevä tapa kohdealueen mallinnuksessa. Kaikki olioohjelmointikielet, esimerkiksi Java, eivät kuitenkaan tue moniperintää, UML-kuvaustekniikassa voidaan antaa myös alaluokkajakoon liittyviä selvennyksiä ja rajoitteita. Esimerkkinä voidaan tarkastella henkilön alaluokkia nainen ja johtaja. Jos oletamme (toisin kuin olio-ohjelmointikielissä), että olio voi kuulua samanaikaisesti useaan alimman tason luokkaan, voitaisiin luokat nainen ja johtaja määritellä osittain päällekkäisiksi kuvan 3.38 mukaisesti. Henkilö overlaps Nainen Johtaja Kuva 3.38: Osittain päällekkäiset alaluokat Kuvan 3.38 rakenteesta on syytä huomata, että se ei ole mahdollinen useimmissa olio-ohjelmointikielissä. Niissä olio voi tyypillisesti kuulua vain yhteen yleistys- 45

9 hierarkian alimman tason luokkaan. Yllä oleva tilanne olisi tällöin hoidettava lisäluokalla naisjohtaja (kuva 3.39). Tällainen rakenne taas on mahdollinen vain, jos moniperintä on mahdollista. Henkilö overlaps Nainen Johtaja Naisjohtaja Kuva 3.39: Päällekkäisten luokkien hyväksikäyttö olio-ohjelmointikielissä. UML:ssä toisensa poissulkevat samaan luokittelukriteeriin perustuvat alaluokat kuvataan yhteisellä kolmiokärjellä (kuva 3.40) nainen henkilö mies complete Kuva 3.40: Henkilön jako luokkiin nainen ja mies (lisämääre complete ilmaisee että henkilö on joko mies tai nainen eikä muuta). 46

10 4 Olioiden yhteistyö ja palveluiden määrittely Oliojärjestelmän toiminta perustuu olioiden yhteistyöhön. Yhteistyö ei tule esiin luokka- tai oliokaavioissa. Luokkakaaviossa esitetään luokan palvelut, mutta siitä ei näy miten palvelun suoritus hyödyntää muita palveluita tai muita olioita. Yhteistyön selvittäminen on kiinteästi sidoksissa olioiden palveluiden määrittelyyn, sillä yhteistyö toteutuu palvelujen kautta. Samalla kun määrittelemme oliolle palveluja meidän tulisi ottaa kantaa siihen millaista yhteistyötä olioiden välillä palvelun suorittamiseen liittyy. Palvelujen ja olioyhteistyön määrittely on ohjelmiston teknisen suunnittelun tehtäviä. Nämä tehdään siis myöhemmin kuin sovellusalueen kannalta keskeisten luokkien määrittely, joka tapahtuu jo ohjelmiston määrittelyvaiheessa. UML tarjoaa kaksi tekniikkaa olioyhteistyön kuvaamiseen: sekvenssikaavion ja yhteistyörakennekaavion. Sekvenssikaaviossa (yhteistyöpoluissa, sequence diagram) keskitytään kuvaamaan operaatioiden suoritusjärjestystä ja kontrollin etenemistä oliolta toiselle. Yhteistyörakennekaaviossa (collaboration diagram) kuvataan erityisesti sitä miten yhteistyö perustuu olioiden välisiin yhteyksiin. Suoritusjärjestys ja kontrollin eteneminen kuvataan myös, mutta ei yhtä helppolukuisesti kuin sekvenssikaavioissa. 4.1 Sekvenssikaavio Sekvenssikaavio kuvaa tietyn palvelun suorittamiseen liittyvän olioiden yhteistyön. Kuvattava palvelu voi olla järjestelmän palvelu eli käyttötapaus (näitä tarkastellaan myöhemmin) tai johonkin luokkaan liittyvä palvelu. Sekvenssikaaviossa esitetään mitä avustavia olioita palvelun suoritukseen osallistuu ja mitä näiden palveluita käytetään. Kaavio kuvaa myös missä järjestyksessä avustavien olioiden palveluja käytetään. Kuva 4.1 esittää kaaviotekniikassa käytettävät symbolit. 47

11 Olio1 Olio2 Aloitusviesti [ehto]viesti(parametrit) palvelu paluuviesti aika Olion oman palvelun käyttö Kuva 4.1: Sekvenssikaavion symbolit Sekvenssikaaviossa oliot kuvataan suorakaiteina, jonka sisällä on olion tunnus. Suorakaiteesta alaspäin lähtevä viiva kuvaa olion elinkaarta. Viivalla oleva paksunnos (laatikko) kuvaa palvelun suoritusta. Paksunnoksen pituus kuvaa palvelun kestoa lähinnä kontrollin kannalta. Oliolla on kontrolli suoritukseen palvelun keston ajan. Olio pyytää avustavalta oliolta palvelua lähettämällä tälle viestin. Olio-ohjelmassa viestin lähettäminen tarkoittaa yleensä metodikutsua (esim. Javassa). Kaaviossa viestin lähettäminen kuvataan lähettäjältä vastaanottajalle menevänä nuolena. Nuoleen liitetään tekstinä lähetettävä viesti. Yleensä tämä muodostuu pyydettävän palvelun nimestä ja pyynnön yhteydessä välitettävistä parametreistä. Ohjelmissa metodit voivat tuottaa paluuarvon. Tällaisia ei yleensä piirretä kaavioon. Palauteviesti voidaan piirtää kaavioon, mutta sitä käytetään lähinnä poikkeuksellisissa tilanteissa, esimerkiksi silloin kun rinnakkain toimiva palvelu palauttaa jo ennen päättymistään jotain tietoa palvelun pyytäjälle. Viestiin voidaan liittää myös ehto, jonka voimassaollessa viesti voidaan lähettää. Ehdon liittäminen ei ole välttämätöntä. 48

12 Esimerkki: Tarkastellaan seuraava Java-ohjelman osaa class A { B oliob; C olioc; D oliod; } public int doit() { oliob.assist1(); olioc.assist2(oliod); } class B { E olioe; } public void assist1() { olioe.dosomething(); } class C { } public void assist2(d od) { od.serviced() } Palveluun A.doIt liittyvä yhteistyökaavio on esitetty kuvassa 4.2. olioa:a oliob:b: olioe:e olioc:c oliod:d assist1() dosometring() assist2(oliod) serviced Kuva 4.2: Esimerkkiohjelman palvelun A:doIt sekvenssikaavio. 49

13 Sekvenssikaavion tarkoituksena on havainnollistaa olioiden välistä yhteistyötä. Etenkin järjestelmätason palveluita tarkasteltaessa saattaa palvelun suoritukseen osallistua kymmeniä olioita ja yhteistyöpolut muodostuvat pitkiksi. Yhdessä kaaviossa ei ole kuitenkaan tarkoituksenmukaista esittää kovin pitkiä yhteistyöpolkuja. 2-3 palvelupyynnön ketju on sopivan pituinen. Jatko voidaan esittää erillisessä kaaviossa, jos se on tarpeen (kuva 4.3). Kuva 4.3: Pitkän yhteistyöketjun ositus eri kaavioihin Sekvenssikaaviossa voidaan esittää myös olioiden luonti ja tuhoaminen (kuva 4.4). Ohjelmissa esiintyy usein silmukoita, joissa palvelua pyydetään esimerkiksi kaikilta kokoelman jäseniltä. Silmukoiden esittämistä sekvenssikaavioissa havainnollistetaan kuvassa

14 luoja create luomus serve destroy Kuva 4.4: Olion luonti ja tuhoaminen. olioa oliob olioc * serviceb * servicex servicey Kuva 4.5: Silmukoiden esittäminen 51

15 Kuvan 4.5 silmukat voisivat olla muotoa: foreach oliob in kokoelma1 do { oliob.serviceb() } foreach (oliob, olioc) in kokoelma2 do { oliob.servicex; olioc.servicey() } Sekvenssikaavioita ei yleensä ole tarpeen laatia kaikille palveluille. Yhteistyön ymmärtämisen kannalta keskeiset palvelut on syytä kuvata. Samantapaisista yhteistyökuvioista riittää yleensä yksi esimerkki. Hyvin yksinkertaisia palveluita ei ole tarpeen kuvata kaaviolla. 4.2 Yhteistyörakennekaavio Yhteistyörakennekaavioissa esitetään miten yhteistyö käyttää hyväkseen olioiden välisiä yhteyksiä. Yhteistyö perustuu olioiden välisiin yhteyksiin, sillä olio voi pyytää palvelua vain sellaiselta oliolta, jonka olemassaolon se tietää. Tämä tietäminen kuvataan luokkakaaviossa yhteyksien avulla. Yhteistyörakennekaaviossa käytettävät symbolit selviävät kuvasta 4.6. i: palvelu Olio1 Olio2 Yhteys1 k:palvelu Yhteys2 j:palvelu Olio3 Kuva 4.6: Yhteistyörakennekaavio 52

16 Yhteistyörakennekaaviossa palvelujen suoritusjärjestys kuvataan palvelun nimen eteen sijoitettavan järjestysnumeron avulla. Järjestysnumero voidaan antaa tasoittain. Jos oliolta A pyydetyn palvelun X järjestysnumero olisi i, niin ensimmäinen olion A palvelun X sisällä pyytämä palvelu olisi järjestysnumeroltaan i.1 ja seuraava i.2. Kuvan 4.2 sekvenssikaaviossa esitetty yhteistyö kuvataan yhteistyörakenteena kuvan 4.7 mukaisesti. 1: assist1() olioa :B oliob 2: assist2(oliod) oliod :C olioc 1.1: dosomething() :E olioe 2.1: serviced() Kuva 4.7: Yhteistyörakennekaavio 4.3 Palvelujen määrittelystä Luokkien palveluja määriteltäessä voidaan luokille aluksi antaa attribuuttien kysymiseen ja niiden arvojen asetukseen liittyvät peruspalvelut (set- ja get metodit). Monipuolisempien palvelujen kohdalla on otettava kantaa yhteistyöhön tarvitseeko joku muu olio suunniteltua palvelua millaisiin yhteistyöketjuihin palvelu osallistuu. Yhteistyön määrittelyn luonnollinen aloituskohta ovat järjestelmän palvelut. Järjestelmän palvelujen toteutukseen osallistuvat käyttöliittymäoliot (ikkunat, valikot, napit, jne), joiden tehtävänä on hoitaa yhteys käyttäjän ja sisältöolioiden välillä 53

17 sisältöoliot, jotka toteuttavat reaalimaailman simulointimallin tekniset apuoliot (tietokantarakenteet, tietoliikenneoliot, jne) Sisältöolioiden ja käyttöliittymäolioiden väliseen kytkentään on esitetty monenlaisia ratkaisumalleja. Yleisperiaatteena useissa malleissa on käyttöliittymän ja sisällön erottaminen. Tämä tarkoittaa sitä, että sisältöolioiden pitäisi tarjota käyttöliittymästä riippumattomia palveluja sisällön käsittelyyn. Näitä palveluja aktivoidaan käyttöliittymän kautta. Tällainen ratkaisu tekee mahdolliseksi toteuttaa helposti erilaisia käyttöliittymiä samaan sisältöön perustuen. Ratkaisumallissa käyttöliittymän muuttaminen ei myöskään vaikuta sisältöluokkiin. Oliot tarjoavat ensisijaisesti omaan tietosisältöönsä perustuvia palveluja. Yhteyksien kautta olioon kytkeytyvät yhteyskumppanit sisältyvät olion tietosisältöön. Olio voi käyttää näitä apuna omissa palveluissaan. Palvelujen liittäminen luokkiin ei ole aivan yksinkertainen asia. Suunnittelija joutuu usein miettimään mille luokalle hän palvelun määrittelisi. Kirjallisuudessa on yleisesti käytetty esimerkkinä palvelun määrittelyn vaikeudesta hevosen satulointia. Oletetaan, että sekä hevonen että satula ovat luokkia ja satuloituna olo puolestaan hevosen ja satulan välinen yhteys (kuva 4.8). hevonen satula selässä Kuva: 4.8: Hevonen ja satula Tarkastellaan hevosen satulointi tehtävää. Meillä on ainakin 3 mahdollisuutta liittää palvelu luokkiin: hevoselle määritellään palvelu satuloidu, jolle annetaan parametrinä satula, satulalle määritellään palvelu kiinnity, jolla annetaan parametrinä hevonen, otetaan käyttöön ylimääräinen luokka ratsastaja ja määritellään tälle palvelu satuloi, parametreinä hevonen ja satula. Reaalimaailmassa viimeisin vaihtoehto olisi luonnollinen tapa hahmottaa ilmiö, mutta olio-ohjelmissa joudutaan usein antamaan palveluja myös olioille, joiden reaalimaail- 54

18 mavastineet ovat sellaisiin kykenemättömiä. Niinpä esimerkin tapauksessa ei voida sanoa, mikä näistä ratkaisuista olisi yksiselitteisesti paras. Ratkaisu, mikä aluksi näyttää hyvältä, saattaa myöhemmin osoittautua huonoksi valinnaksi tuottamalla esimerkiksi runsaasti ohjelmakoodia. Huono valinta taas aiheuttaa tarpeen muuttaa suunnitelmaa. Kun luokalle määritellään palvelu on selvitettävä pystyykö luokan olio hoitamaan sen itsenäisesti vai tarvitaanko avustavia olioita. Jos avustavia olioita tarvitaan, on suunniteltava miten yhteistyö toimii. Esimerkki: Tarkastellaan lipunvarausjärjestelmää (kuva 3.31) ja sen palvelua Selvitä annettuna päivänä annetulla aikavälillä tarjolla olevat elokuvanäytökset. Seuraavassa tarkastellaan vain sisältöolioiden palveluita. Ohjelmakarttaluokan olioilla on tieto näytöksistä. Oletetaan, että yksi Ohjelmakartta-ilmentymä tietää kaikki näytökset. Se pystyy tämän tietonsa pohjalta toteuttamaan tehtävän. Määritellään Ohjelmakartalle tehtävää varten palvelu näytöksetaikavälillä(päiväys, välin_alku, välin_loppu). Palvelu tuottakoon tuloksenaan merkkijonotaulukon, jonka kukin alkio kuvaa yhden näytöksen. Koska Ohjelmakartta-olio tietää vain näytösten olemassaolon, se ei omin avuin kykene tuottamaan tulostaulukon alkioita. Sen on käytettävä näiden tuottamisessa apuna Näytös-olioita, joilla on enemmän tietoa näytöksistä. Ennen Näytös-olioiden hyväksikäyttöä on kuitenkin tarkasteltava Ohjelmakartta-olion ja Näytös-olioiden välistä yhteyttä: Onko ohjelmakartta-oliosta suora pääsy näytös-olioihin?. Suora pääsy kaikkiin Näytös-olioihin on mahdollinen, jos kaikki Näytös-oliot ovat keskusmuistissa tai käytössä on oliotietokanta, joka toimii tavallaan keskusmuistin laajennoksen kaltaisesti. Tällöin Näytös-luokkaan voidaan liittää näytöksen kuulumisen oikealle aikavälille testaava palvelu tai palvelut esimerkiksi esitetäänpäivänä(päiväys) ja alkaavälillä(alku, loppu). Ellei suoraa pääsyä ole, vaan Näytös-olioiden tiedot olisivat vaikkapa relaatiotietokannassa, tarvitaan apuoliona tietokantakysely, joka luo keskusmuistiin tarvittavat Näytös-oliot. Tällainen 55

19 voisi olla luokan NäytösHaku olio, jolla olisi palvelu haenäytökset(päiväys, välin_alku, välin_loppu). Kysely hakisi tiedot tietokannasta, loisi Näytös-oliot vastauksen perusteella ja palauttaisi kokoelman, joka sisältää suorat viitteet luotuihin olioihin. Näytös-luokalle voidaan määritellä palvelu näytösrivi, joka tuottaa tuloksenaan näytöstä kuvaavan merkkijonon. Tämän muodostukseen Näytös voisi tarjota apupalveluja: milloin-palvelu antaisi päiväyksen ja kellonajan, missäpalvelu antaisi teatterin nimen ja mikä-palvelu antaisi elokuvan nimen. Kahta viimeksimainittua Näytös ei kykene hoitamaan omin avuin, vaan jälleen tarvitaan yhteistyötä. Teatterin nimen selvittämiseksi pyydetään Teatteri-oliolta palvelua annanimi. Elokuvan nimi voitaisiin saada Elokuva-olion annanimipalvelulla. Jos Näytös-oliosta ei ole suoraa pääsyä siihen kytkettyyn Elokuvaja Teatteri-olioon, on pääsy mahdollistettava ennen palvelujen pyytämistä vaikkapa tietokantakyselyiden avulla. Tämä voidaan hoitaa vaikkapa määrittelemällä yllä mainittu haenäytökset toimimaan siten, että se luo myös Elokuva- ja Teatteri-oliot, mikäli niitä ei vielä ole keskusmuistissa. Kuvassa 4.9 on kuvattu tarkastellun järjestelmäpalvelun toteutukseen liittyvä yhteistyö tilanteessa jossa ohjelmakartasta on suora pääsy kaikkiin näytöksiin. Kuvassa 4.10 on kuvattu yhteistyö tilanteessa, jossa joudutaan käyttämään tietokantakyselyä luomaan tarvittavat näytös-, elokuva- ja teatteri- oliot. 56

20 :Ohjelmakartta :Näytös :Elokuva :Teatteri * esitetäänpäivänä(päiväys) alkaavälillä(alku,loppu) näytösrivi() mitä() annanimi() missä() annanimi() milloin() Kuva 4.9: Palveluun Ohjelmakartta.näytöksetAikavälillä liittyvä yhteistyö kun kaikkiin olioihin on suora pääsy. 57

21 :Ohjelmakartta :NäytösKysely haenäytökset(päiväys,alku,loppu) *create :Näytös *create *create :Elokuva :Teatteri näytösrivi() * mitä() annanimi() missä() annanimi() milloin() Kuva 4.10: Palveluun Ohjelmakartta.näytöksetAikavälillä liittyvä yhteistyö kun avustavat oliot täytyy luoda tietokantakyselyn avulla. Esimerkki: Tarkastellaan järjestelmäpalvelua Selvitä näytöksen vapaat paikat. Palvelu näyttäisi sopivan luokalle Näytös. Seuraavassa esitetään 2 vaihtoehtoista ratkaisua. 58

22 Vaihtoehto 1: Näytös pyytää teatteriltaan kaikki paikat ja käy ne sitten yksitellen läpi kysyen varauksiltaan kohdistuvatko ne kyseiseen paikkaan. Ratkaisu toimii, mutta vaikuttaa hitaalta (koska varaukset joudutaan lataamaan keskusmuistiin). Ratkaisuun perustuvan yhteistyökaavion hahmotelma on kuvassa Kuvassa ei ole esitetty mahdollisesti tarvittavia tietokantakyselyjä. :Näytös :Teatteri :Varaus :Lippu :Paikka annapaikat * onkokohde(paikka) * onkokohde(paikka) annarivijanumero() Kuva 4.11: Olioiden yhteistyö ja palvelut selvitettäessä näytöksen vapaita paikkoja (vaihtoehto 1). Vaihtoehto 2: Otetaan käyttöön apurakenne Salikartta. Teatteri osaa muodostaa salikartan, jossa kaikki paikat ovat vapaita. Salikartalla on palvelu varaa(rivi,paikka) ja peru(rivi,paikka). Salikartta-olio liitetään Näytös-olioon sen luonnin yhteydessä ja jokainen varaus merkitään salikarttaan. Salikartta osaa kertoa vapaat paikat vaikkapa metodilla vapaat(). Tämä tuottaa (rivi, paikka) pareista muodostuvan taulukon. Näytös tuottaa tiedot vapaista paikoista kysymällä paikat salikartaltaan. Ratkaisu on nopea ja yhteistyöltään yksinkertainen, mutta vaatii jonkin verran muistitilaa. Vapaan paikan kysymiseen liittyvä yhteistyötä on hahmoteltu kuvassa Tässä vaihtoehdossa 59

23 paikan varaus ja varauksen peruutus muodostuvat olioiden yhteistyöratkaisultaan erilaisiksi kuin vaihtoehdossa 1. :Näytös :Salikartta vapaat() Kuva 4.12: Olioiden yhteistyö ja palvelut selvitettäessä näytöksen vapaita paikkoja (vaihtoehto 2). Yllä olevissa esimerkeissä on palvelua ja yhteistyötä suunniteltaessa päädytty esittelemään uusia teknisen tason luokkia. Nämä eivät ole välttämättömiä ongelman ymmärtämisen kannalta, mutta ovat toki oleellisia teknisen ratkaisun kannalta siinä vaiheessa kun järjestelmän määrittelystä siirrytään tekniseen suunnitteluun. Palveluiden määrittely saattaa myös aiheuttaa tarpeita muuttaa luokkiin liitettyjä attribuutteja ja luokkien välisiä yhteyksiä. Muutokset voivat hyvinkin olla sen tasoisia, että niiden tulisi näkyä myös sisältömallissa. Tästä syystä järjestelmän luokkakaaviokaan ei ole valmis ennenkuin palvelut ja yhteistyö on suunniteltu. 5 Järjestelmän palvelut Tietojärjestelmät tarjoavat tietoa sekä käyttäjilleen että epäsuorasti muille tahoille. Tahoja, jotka ovat järjestelmän ulkopuolella, mutta kuitenkin palvelujen kautta kytkeytyneitä järjestelmään kutsutaan järjestelmän sidosryhmiksi. Tällainen taho voi toimia tiedon tuottajana järjestelmään tai tiedon hyväksikäyttäjänä 60

24 Sidosryhmien tunnistaminen on ensimmäinen tehtävä järjestelmän palveluja määriteltäessä. Tässä tehtävässä eri sidosryhmät nimetään sekä määritellään lyhyellä tekstikuvauksella. Sidosryhmien löytämiseksi voidaan esittää kysymykset: kuka / mikä saa tulosteita järjestelmästä? kuka / mikä toimittaa tietoa järjestelmään? kuka käyttää järjestelmää? mihin muihin järjestelmiin kehitettävä järjestelmä on yhteydessä. Näiden kysymysten perusteella luokitellaan samankaltaiset tahot sidosryhmiksi. Tietojenkäsittelytieteen laitoksen opetustietojärjestelmän sidosryhmiä ovat esimerkiksi opiskelijat opettajat vastuuhenkilöt laitoksen johtoryhmä siivoojat vahtimestarit opintosuoritusrekisteri-järjestelmä. Järjestelmä voi tarjota eri sidosryhmille erilaisia palveluita. Palvelujen tai tarpeiden erilaisuus onkin yksi peruste ryhmien muodostamiselle. Sidosryhmä voi olla suorassa yhteydessä järjestelmään tai joko saada tietoja järjestelmästä tai toimittaa tietoa järjestelmään epäsuorasti. Esimerkiksi yllä olevista sidosryhmistä siivoojat eivät ole suorassa yhteydessä opetustietojärjestelmään kuten ei myöskään laitoksen johtoryhmä. Merkittävän osuuden suorassa yhteydessä järjestelmään olevista sidosryhmistä muodostavat järjestelmän käyttäjät. Yllä olevista sidosryhmistä käyttäjäryhmiä ovat opiskelijat, opettajat, vastuuhenkilöt ja vahtimestarit. Opintosuoritusrekisterijärjestelmä on erillinen järjestelmä, jonka palveluita laitoksen opetustietojärjestelmä hyödyntää (opintosuoritusote, kirjauspalvelut). 61

25 5. 1 Sidosryhmäkaavio Karkean tason yleiskuva järjestelmästä voidaan esittää sidosryhmäkaaviona (context diagram), jossa näkyvät järjestelmä, keskeisenä komponenttina, järjestelmän sidosryhmät ja tärkeimmät järjestelmän tarjoamat ja käyttämät palvelut tai palvelukokonaisuudet. Palvelut esitetään kaaviossa sidosryhmän järjestelmään yhdistävänä viivana. Sidosryhmäkaavion tulisi antaa yleiskuva järjestelmästä. Tämän vuoksi sitä ei voi esittää kovin yksityiskohtaisella tasolla. Samankaltaisia palveluita on syytä koota yhteen ryhmiksi, jotka sitten esitetään kaaviossa yhtenä palvelukokonaisuutena. Käytämme sidosryhmäkaaviota siten, että liitämme palveluja kuvaavaan viivaan nuolenkärjen, joka osoittaa palvelun tarjoajaan. Jos kyseessä on järjestelmän itsensä tarjoama palvelu osoittaa nuoli siis järjestelmään. Jos taas kyseessä on ulkoisen järjestelmän käyttö, osoittaa nuoli kyseiseen ulkoiseen järjestelmään. Kuvassa 5.1 on vapaamuotoisin symbolein esitetty yleiskuvaus lipunvälitys-järjestelmästä. Asiakas käyttää järjestelmän palveluita 'tiedustelu', 'tilaus' ja 'toimitus'. Lipunvälitys-järjestelmä käyttää elokuvayhtiökohtaisten varausjärjestelmien palveluita 'kysely' ja 'varaus' sekä pankkijärjestelmien palveluita 'lasku' ja 'maksu'. 62

26 tiedustelu tilaus toimitus Lippujen välitys Asiakas kysely varaus lasku maksu Varausjärjestelmä Pankki Kuva 5.1: Lipunvälitysjärjestelmän yleiskaavio. Pelkkä kaavio ei ole riittävä järjestelmän yleiskuvan antamiseksi. Kaavion täydennykseksi tarvitaan sanalliset kuvaukset sekä sidosryhmistä että tuotettavista ja käytettävistä palveluista. 5.2 Käyttötapausmalli Tietojärjestelmä tarjoaa käyttäjilleen palveluita, jotka perustuvat järjestelmän tietosisältöön. Järjestelmän toiminnalliset vaatimukset voidaan määritellä määrittelemällä millaisia palveluita järjestelmän on tarjottava. Käyttötapausmalli (use case model) on viime aikoina suosioon tullut tapa järjestelmän palvelujen määrittelyyn. 1 UML tarjoaa kuvaustekniikan käyttötapausmallin esittämiseen. 1 Jacobson: Object-Oriented Software Engineering: A use case driven approach, Addison-Wesley,

27 Käyttötapauksella mallinnetaan käyttäjän järjestelmän avulla suorittamaa tehtävää eli tapaa käyttää järjestelmää. Luonteva tapa on kytkeä käyttötapaukset käyttäjän työtehtäviin. Käyttötapauksen laajuus on hyvin keskeinen tekijä mallin ymmärrettävyyden ja hallittavuuden kannalta. Käyttötapaukset eivät saisi olla liian laajoja eivätkä myöskään liian suppeita. Keskikokoisessa hankkeissa käyttötapauksia on yleensä muutamia kymmeniä ja isommissa hankkeissa jopa satoja. Pääperiaatteena on, että yhden käyttötapauksen tulisi muodostaa looginen konaisuus, jolla on sekä selvä lähtökohta että merkityksen omaava lopputulos. Lähtökohtana eli herätteenä on tapahtuma tai tarve, joka käynnistää käyttötapauksen. Tapahtuma voi olla joko käyttäjän itsensä, jonkin ulkopuolisen tekijän tai järjestelmän aiheuttama. Se voi olla myös ajan kulumisesta aiheutuva. Kuvan 5.1 esimerkissä asiakkaan saamia palveluita voidaan ajatella käyttötapauksina. Koska kyseessä ei ole asiakkaan työtä avustava järjestelmä, ne eivät liity asiakkaan työtehtäviin. Tiedustelu-käyttötapauksen lähtökohtana on tietotarve ja lopputuloksena haluttu tieto. Tilaus -käyttötapauksen lähtökohtana on tarve varata paikka näytökseen ja lopputuloksena aikaansaatu varaus. Termiä käyttötapaus käytetään yleisesti sekä luokkatason käsitteenä että ilmentymätason käsitteenä. Jatkossa käyttämme mahdollisissa epäselvissä tilanteissa luokkatasolla termiä käyttötapausluokka ja ilmentymätasolla termiä käyttötapausilmentymä tai esimerkkitapaus. UML:ssä käyttötapauksia kuvataan luokkatasolla. Esimerkki: Käyttötapausluokka: Paikan varaaminen elokuvanäytökseen Esimerkkitapaus: Kalle Kenkkunen varaa paikan 308 Tennispalatsi 12:n näytökseen klo 21. Käyttötapauksella on käyttäjä (actor), joka käyttötapauksessa toimii vuorovaikutteisesti järjestelmän kanssa toteuttaakseen tavoitteensa. Käyttäjän toiminta on syötteiden antamista ja palautteen saamista. Usein käyttäjä on ihminen, mutta käyttäjä voi olla 64

28 myös ulkoinen järjestelmä. Käyttötapaukseen liittyy aina tavoite = asia, jonka käyttäjä haluaa saada aikaan käyttötapauksen avulla. Käyttötapausta kuvattaessa kerrotaan käyttäjän ja järjestelmän välisen vuoropuhelun sisältö, mitä käyttötapauksessa tapahtuu ja mistä asioista käyttäjä ja järjestelmä vaihtavat tietoa. Miten kommunikointi käytännössä tapahtuu määritellään vasta suunnitteluvaiheessa. Käyttöliittymää ei siis tässä vaiheessa vielä kiinnitetä, joskin joitain periaatteita saattaa olla tarpeen hahmotella, jotta käyttäjät ymmärtäisivät, mistä on kyse. Käyttötapaus kuvataan esittämällä vuoropuhelun peruskulku. Mahdolliset käyttötapauksen kulkua muuttavat poikkeustilanteet voidaan määritellä erillisinä käyttötapausta täydentävinä käyttötapauksina. Käyttötapaukseen voi liittyä vaatimuksia koskien suojausta, vasteaikoja, yms. Esimerkkejä ilmoittautumisjärjesrtelmään liittyen: Kurssille Ilmoittautuminen Suorittajana opiskelija Opiskelija antaa tunnistustietonsa ja valitsee kurssin sekä kurssin harjoitusryhmän. Opiskelija saa tiedon ilmoittautumisen onnistumisesta. Opiskelija ei voi ilmoittautua täynnä olevaan ryhmään Opiskelija ei voi ilmoittautua, jos hänelle on kirjattu osallistumiseste. 2 ruuhkahuippua vuodessa, n 1400 ilmoittautumista tunnissa, muulloin vähän Esimerkkitapaus: NN ilmoittautuu JSS/s99 kurssin harjoitusryhmään 3. Ilmoittautumisen peruminen Suorittajana opiskelija Opiskelija antaa tunnistetietonsa ja valitsee ilmoittautumisen, jonka hän haluaa perua. Järjestelmä ilmoittaa operaation suorituksesta Esimerkkitapaus: NN peruu ilmoittautumisensa JSS/s99 kurssin harjoitusryhmään 3 65

29 Esimerkkejä lipunvälitysjärjestelmään liittyen Elokuvan näytösaikojen ja paikkojen selvitys Suorittajana asiakas Asiakas valitsee elokuvan sekä aikavälin alku- ja loppupäivät ja aikarajat näytöksen alkamisajalle. Lisäksi asiakas voi määritellä näytetäänkö tulos teattereittain vaiko alkamisaikojen perusteella järjestettynä. Tuloksena asiakas saa luettelon näytöksistä määrittelemässään järjestyksessä Esimerkkitapaus: NN haluaa saada selville tänään välillä alkavien Star Wars Episode 1 näytösten ajat ja paikat Helsingissä Lippujen varaus näytökseen Suorittajana asiakas Asiakas valitsee näytöksen ja saa tiedot vapaina olevista paikoista. Hän valitsee näistä mieleisensä (yhden tai useampia) ja antaa tunnistetietonsa. Järjestelmä vahvistaa varauksen antamalla asiakkaalle varausnumeron sekä tuottamalla laskun, jonka asiakas maksaa pankkijärjestelmänsä avulla. Lasku jää odottamaan maksamista. Kun asiakas on maksanut laskun hän tulostaa itselleen liput. Esimerkkitapaus: Kalle Kenkkunen varaa paikan 308 Tennispalatsi 12:n näytökseen klo 21. Hän saa varausnumeron ja laskun jonka hän maksaa Meritan Solo järjestelmän avulla. Hän tulostaa liput omalla mustesuihkukirjoittimellaan. Laajoissa järjestelmissä voidaan lähteä liikkeelle käyttäjien työtehtäviin perustuvista käyttötapauksista. Käyttötapauksia analysoitaessa niistä saatetaan löytää yhteisiä osia, jotka voidaan erottaa omiksi käyttötapauksiksi. Samoin erilaiset virhe- ja poikkeustilanteet sekä vaihtoehtoiset kulut käyttötapauksessa olisi syytä erottaa omiksi erillisiksi käyttötapauksiksi. Näin syntyy riippuvuuksia käyttötapausten välille. Jacobson on määritellyt riippuvuuksien esittämiseen soveltuvan kaaviotekniikan. Tässä tekniikassa on kahden tyyppisiä riippuvuuksia laajennoksia ja hyväksikäyttöä. 66

30 Esimerkiksi käyttötapaukseen paikkojen varaus näytökseen voisi liittyä seuraavia poikkeuksia ja virhetilanteita: Valittuun näytökseen ei ole haluttua määrää vapaita paikkoja Asiakas ei ole rekisteröitynyt Asiakas on unohtanut tunnistetietonsa Asiakkaalla ei ole käyttöoikeutta pankkitietojärjestelmään Asiakkaalla ei ole kirjoitinta Yhteys järjestelmään katkeaa (eri vaiheissa). Laajennoksilla (extent) tarkoitetaan käyttötapauksia, joissa kommunikoinnin sisältö poikkeaa perussisällöstä. Esimerkiksi ilmoittautumisen laajennos olisi ensikertaa ilmoittatuminen, jossa opiskelijan on annettava kaikki henkilötietonsa. Paikkojen varaus näytökseen käyttötapauksen peruskulussa asiakas tulostaa lipun omalla kirjoittimellaan. Asiakkaalla ei kuitenkaan välttämättä ole kirjoitinta tai hän ei saa lippua tulostettua. Tällöin käyttötapauksen viimeiselle vaiheelle lipun toimitukselle tarvitaan vaihtoehtoinen ratkaisu. Toimitustavoiksi voitaisiinkin määritellä itsepalvelutulostus Lippu kirjataan noudettavaksi teatterin lippupisteestä. Asiakkaan on lippua noutaessaan annettava varausnumeronsa. Kun asiakas on noutanut lipun se kirjataan noudetuksi. toimitus lippupisteestä. Järjestelmä selvittää, tarvittaessa asiakkaalta kysymällä, millainen kirjoitin asiakkaalla on. Jos kirjoitin on tulostukseen soveltuva muodostetaan lippujen kuvat ja toimitetaan ne asiakkaan työasemaan. Asiakas tulostaa liput ja kuittaa tulostuksen onnistuneeksi. 67

31 Lipun tulostus Toimitus extends lippupisteestä extends itsepalvelutulostus uses extends Epäonnistunut tulostus Kuva 5.2: Käyttötapausten riippuvuuksia. Kuvassa 5.2 on UML-tekniikalla kuvattu käyttötapausten riippuvuuksia. Siinä on edellämainittujen käyttötapausten lisäksi määritelty poikkeustilanne epäonnistunut tulostus, joka aiheuttaa lipun toimituksen lippupisteestä. Tämä käyttötapaus käyttää hyväkseen toista käyttötapausta. Kuvassa 5.3 on esitetty UML:n käyttötapauskaavion symbolit. Käyttötapausten tekstimuotoinen kuvaus esimerkiksi taulukkomuodossa on kuitenkin oleellisempaa kuin graafinen käyttötapauskaavio, jonka informaatiosisältö on usein varsin vähäinen. 68

32 käyttötapaus Käyttäjä extends kt3 kt2 uses Kuva 5.3: UML-käyttötapauskaavion symbolit. Käyttäjä (actor) kuvaa käyttäjän roolia. Esimerkiksi henkilö voisi olla roolissa opettaja tai opiskelija. Nuoli käyttäjästä käyttötapaukseen kuvaa sitä, että kyseisessä käyttäjäroolissa oleva käyttäjä käyttää kyseistä käyttötapausta. Laajentaminen ja hyväksikäyttö määriteltiin yllä. Käyttötapausten avulla kuvataan kaikki järjestelmältä edellytettävät palvelut eli järjestelmän toiminnalliset vaatimukset. Käyttötapauksilla on hyvin keskeinen rooli ohjelmiston kehitysprosessin eri vaiheissa, sillä toiminnallisten vaatimusten määrittelyn lisäksi järjestelmä suunnitellaan ja toteutetaan usein niiden ohjaamina. Käyttötapauksiin liittyvät esimerkkitapaukset voivat toimia järjestelmän testitapauksina. Edellä on tarkasteltu käyttötapauksen sisällön määrittelyä. Käyttötapauksen toteutuksen suunnittelussa on perustana käyttöliittymän yleissuunnitelma. Sen pohjalta suunnitellaan yksityiskohtaisesti käyttötapauksen läpivienti käyttöliittymän avulla ja määritellään käyttöliittymäoliot ja niille käyttötapauksen tarvitsemia palveluita. Käyttötapaukset voivat toimia myös perustana järjestelmän sisältöluokkien määrittelyssä. Tähän perustuu ns. käyttötapauspohjainen (näkemyspohjainen) määrittely. Tässä lähestymistavassa laaditaan aluksi käyttötapauskohtaisia osamalleja, jotka sitten yhdistetään kokonaisvaltaiseksi malliksi (kuva 5.4). 69

33 Käyttötapaus k 1 Käyttötapaus k i Käyttötapaus k n Osamalli 1 Osamalli i Osamalli n YHDISTÄMINEN Kokonaismalli Kuva 5.4: Käyttötapauspohjainen tietosisällön määritys Kukin käyttötapauskohtainen osamalli määrittelee sisältöluokat vain käyttötapauksen edellyttämässä laajuudessa. Syntyvät mallit ovat siten kokonaismallia suppeampia ja näin helpommin aikaansaatavissa. Lähtökohdaksi mallinnukseen voidaan ottaa käyttötapauksen kuvaus, mahdollinen käyttötapaukseen liitetty luonnos käyttöliittymästä, raporttimalli tai lomake, joka liittyy käyttötapaukseen. Jos lähtökohtana on tekstikuvaus, mallinnus voi lähteä liikkeelle siten, että aluksi alleviivataan tekstistä luokkaehdokkaat. Usein nämä esiintyvät lauseiden subjekteina tai objekteina. Sen jälkeen aloitetaan mallin laatiminen arvioimalla luokkaehdokkaiden kelpoisuutta tietosisältömallin luokiksi: 70

34 muodostavatko ne järjestelmän kannalta oleellisia tietokohteita, liittyykö niihin ominaisuuksia, joista pitäisi säilyttää tietoja. Jos vastaus ylläoleviin kysymyksiin on positiivinen otetaan ehdokas mallin luokaksi. Lomakkeita tai raportteja analysoitaessa ei näistä löydy välttämättä suoraan luokkaehdokkaiden nimiä. Sensijaan löytyy tunnistetietoja, jotka epäsuorasti vihjaavat luokan olemassaolosta. Kuvissa 5.5 ja 5.6 on esimerkkinä raporttiin pohjautuvasta analyysista tarkasteltu lippuvarausjärjestelmältä tulokseksi haluttua elokuvalippua. Analyysin tuottama käyttötapauskohtainen osamalli on kuvassa 5.7. Elokuvalippu: Bristol I, Mikonkatu, Helsinki rivi 15 paikka 3, permanto Keskiviikko, , klo Imperiumin vastaisku, Star Wars 2 35 mk Elokuvalippu: Bristol I, Mikonkatu, Helsinki Keskiviikko, Kuva 5.5: Elokuvalippu analysoinnin kohteena 71

35 Elokuvalippu: Bristol I, Mikonkatu, Helsinki rivi 15 paikka 3, permanto Keskiviikko, , klo Imperiumin vastaisku, Star Wars 2 35 mk Elokuvalippu: Bristol I, Mikonkatu, Helsinki Keskiviikko, Lipun tunnus Teatterin tunnus Elokuvan nimi Paikan tunnus Varauksen tunnus Kuva 5.6: Elokuvalippu analysoituna 72

36 elokuva nimi {id} 0..* 0..* {id} näytös näytös_pvm {+id} alkamisaika {+id} 1 esitetään tarjolla 1..* {id} 0..* 1 osasto_näytöksessä hinta {id} teatteri Nimi {id} Osoite Paikkakunta 1 1..* {id} varaus varausnumero {id} * paikkavaraus 0..* {id} paikkanäytöksessä 1 0..* {id} osasto osastotunnus {+id} 1 kuuluu lippu oikeuttaa istuin 1 * paikka * {id} lippunumero {id} tarkistusteksti 0..1 rivi {id} paikkanro {id} Kuva 5.7: Käyttötapauksen 'lipun tuottaminen' näkemys tietosisällöstä. Kuvan 5.7 mallin lähtökohtana on tuotettu elokuvalippu. Mallia ei ole kuitenkaan konstruoitu pelkästään lippua tarkastelemalla, vaan sen aikaansaamiseksi on täytynyt analysoida ja selvittää laajemmin esimerkiksi sitä, miten lipun hinta määräytyy. Tätä varten on voitu esimerkiksi haastatella teatterin johtoa. Lopulta on päädytty erilaiseen ratkaisuun kuin aiemmmin kuvan 3.31 kaaviossa. Tässä esitettävä näkemys perustuu siihen, että teatteri on jaettu osastoihin, joihin paikat kiinteästi liittyvät. Kaikilla osaston paikoilla on näytöskohtaisesti sama hinta. Kuvien 3.31 ja 5.7 sisältömallit kuvaavat samaa sisältöä, mutta ne ovat erilaisia. Emme voi välttämättä tuomita kumpaakaan malleista virheelliseksi. Ne ovat erilaisia näkemyksiä asiasta. Näkemysten yhdistämistehtävän tarkoituksena on tuottaa 73

37 yhteinen kokonaisnäkemys tietosisällöstä. Yhdistämisen yhteydessä joudutaan osanäkemyksiä vertailemaan ja analysoimaan. Yhdistäminen ei ole helppo tehtävä. Ongelmia tuottavat synonyymit (sama asia nimetty eri tavoin), homonyymit (eri asioista käytetään yhtä nimeä), erilaiset rakenteet ja rajoitteet, jotka vaativat yhteensovitusta. Yhdistämistehtävässä joudutaan usein nostamaan mallin abstraktiotasoa. Näkemysten konkreettiset käsitteet korvataan abstrakteilla käsitteillä. Esimerkiksi lippujärjestelmässä voitaisiin välittää lippuja myös autokilpailuihin, jolloin 'teatteri' ei ehkä ole yhdistetyssä mallissa hyvä nimitys tilaisuuden pitopaikkalle. Kuvassa 5.4 yhdistely on kuvattu yhtenä tehtävänä, jonka syötteinä on useita käyttötapauskohtaisia osamalleja. Tämä ei tarkoita sitä, että kaikki osamallit tulisi yhdistää kerralla. Osamalleja voidaan tuottaa erilaisin aikatauluin ja niitä voidaan myös yhdistellä eriaikaisesti. Voidaan esimerkiksi toimia siten, että otetaan jokin näkemys yhdistetyn kokonaismallin pohjaksi ja yhdistetään yksi kerrallaan muut näkemykset tähän yhdistemalliin. 5.3 Käyttötapausten ja sisältöluokkien yhteensopivuus Järjestelmän tietosisältö muotoutuu käyttötapausten tuloksena. Käyttötapaukset puolestaan muokkaavat ja hyödyntävät tietosisältöä. Kuvaukset ovat siis riippuvuussuhteessa toisiinsa. Kuvausten yhteensopivuuden varmistamiseksi voi käyttää riippuvuusmatriisia. Matriisissa riveinä ovat sisältöluokat ja yhteydet ja sarakkeina käyttötapaukset. Sarakkeen arvoksi tietylle riville merkitään miten käyttötapaus suhtautuu kyseisellä rivillä olevaan luokkaan tai yheyteen. Sarake jätetään tyhjäksi, jos luokalla ja käyttötapauksella ei ole mitään tekemistä toistensa kanssa. Sarakkeeseen merkitään L (luo), jos käyttötapaus luo luokalle uusia ilmentymiä. Sarakkeeseen merkitään P (poisto), jos käyttötapaus havittää luokan ilmentymiä. Sarakkeen arvona on M (muuttaa), jos käyttötapaus aiheuttaa muutoksia luokan olioiden attribuutteihin ja K (käyttää), jos käyttötapaus käyttää hyväksi luokan olioiden tietoja. 74

38 Käyttötapaukset Uusi artikkeli Uusi artikkeliversio Olioluokat Article L M K K K K K K M M M M M M M K K K K K Article version L L K M K K K M M M M M K Person X X X K K K K K K K K X K Reference K L M M M M K Journal L K K K K= Käyttää, L = Luo, M= Muuttaa, P= Poistaa, X=Luo tai muuttaa Tiedustelu artikkelin tilasta Lausunnonantajan valinta Lausunnon saapuminen Muistutus lausunnosta Puuttumaan jäänyt lausunto Valituksen käsittely Julkaisupäätöksen kirjaus Palautus korjattavaksi Julkaistavaksi hyväksymine Hylkääminen Viimeistellyn saapuminen Oikovedoksen lähettäminen Korjausten vastaanotto Eripainosten tilaus Henkilötietojen rekisteröinti Sisällysluettelo Vuosikertatiedot www-sivut Raportit Kuva 5.8: Riippuvuusmatriisi Matriisin käyttö kuvausten yhteensopivuuden tarkastukseen perustuu siihen, että jokaiselle sisältöluokalle täytyy löytyä ainakin yksi käyttötapaus, joka luo luokalle ilmentymiä. jokaiselle sisältöluokalle täytyy löytyä ainakin yksi käyttötapaus, joka käyttää hyväksi luokan olioiden tietoja jos luokan ilmentymäjoukko ei ole jatkuvasti kasvava, pitää löytyä käyttötapaus, jolla ilmentymiä voidaan hävittää (esimerkiksi ylläolevassa matriisissa ei ole lainkaan hävittämisen aikaansaavia käyttötapauksia) jos ilmentymän tiedot voivat muuttua, täytyy löytyä käyttötapaus, jolla muutos saadaan aikaan. jokaisen käyttötapauksen täytyy jotenkin liittyä vähintään yhteen sisältöluokkaan. 6 Kuvaukset ja kehittämisprosessi Kuvauksia järjestelmästä tuotetaan sen kehityksen eri vaiheissa. Kuvassa 6.1 on kuvattu miten tällä kurssilla esitetyt kuvaukset suhtautuvat kehittämisprosessiin. 75

39 Esitutkimus hyvin karkea sisältöluokkia kuvaava luokkakaavio Liiketoimintaprosessi osapuolten välisenä yhteistyökaaviona Sidosryhmäkaavio Määrittely Käyttötapausmalli keskeiset sisältöluokat yksityiskohtaisemmassa luokkakaaviossa käyttötapausten ja sisältöluokkien riippuvuusmatriisi suunnittelu Käyttöliittymän rakenne Käyttötapauksen läpivientimallit palveluilla ja teknisillä ratkaisuilla täydennetyt luokkakaaviot Olioiden yhteistyö toteutus Ohjelmakoodi Kuva 6.1: Kuvaukset järjestelmäkehityksen vaiheissa 76