Jarkko Enden Tietojenkäsittelytieteen laitos Helsingin yliopisto OHJELMISTO- TUOTANTO- VÄLINEET 20.11. 2000 UML:n perustekniikat ja Rational Rose Enterprise Edition -työkalu
1 JOHDANTO 2 2 UML:N PERUSTEKNIIKAT 2 2.1 Yhteystyypit 2 2.1.1 Assosiaatio 3 2.1.2 Aggregaatio 3 2.1.3 Perintä 3 2.1.4 Riippuvuus 4 2.1.5 Roolit 4 2.1.5 Yhdestä moneen - ja monesta moneen yhteydet 4 2.2 Näkyvyyssäännöt 5 2.3 Käyttötapauskaavio 6 2.4 Aktiviteettikaavio 7 2.5 Luokkakaavio 9 2.6 Sekvenssikaavio ja olioyhteistyökaavio 9 2.7 Tilakaavio 11 2.8 Komponenttikaavio 13 2.9 Toteutuskaavio 14 3 RATIONAL UNIFIED PROCESS JA RATIONAL ROSE ENTERPRISE EDITION 15 1
1 Johdanto UML (Unified Modelling Language) on kuvauskieli, joka on suunniteltu järjestelmien loogiseen mallintamiseen. Kieli soveltuu erityisesti tietokoneisiin liittyvien järjestelmien mallintamiseen, vaikka se ei niihin periaatteessa ole rajoittunutkaan. UML:n kehittivät vuonna 1995 yhteistyössä kolme järjestelmien mallintamiseen perehtynyttä arvostettua tutkijaa, Jim Rumbaugh, Grady Booch ja Ivar Jacobson, ja siitä tuli nopeasti tietojärjestelmien suosituin mallinnuskieli. UML ei ole riippuvainen mistään työkalusta, ohjelmointikielestä tai prosessista mutta se tukee monia erilaisia lähestymistapoja järjestelmän kehittämiseen. Pääasiallisesti sitä kuitenkin käytetään oliopohjaisten tietojärjestelmien ongelmien ja niiden ratkaisujen visualisoimisessa. Tässä dokumentissa käydään läpi UML:n perussyntaksi [1, 4], joka koostuu useista erilaisista kaavioista, ja annetaan esimerkkejä yleisimmin käytetyistä kaavioista. Perustekniikoiden yhteydessä esitellään myös Rational Rose Enterprise Editionin [3] tapaa tehdä UML-syntaksin mukaisia kaavioita. Työkalun täysipainoinen hyödyntäminen edellyttää, että tuotantoprosessi seuraa ainakin osittain Rational Unified Processia [2], Rational Rosen ehdotusta järjestelmän kehitystyössä käytettävästä prosessista. Rational Unified Processia ja Rational Rose Enterprise Editionia käsitellään tarkemmin luvussa 3. 2 UML:n perustekniikat UML:n syntaksi koostuu useista erilaisista mutta kuitenkin monella tapaa toisiinsa liittyvistä kaavioista. Koska tiettyä järjestelmää mallintavat kaaviot kuvaavat samaa järjestelmää, ne sisältävät usein samoja olioita tai elementtejä, mutta tarkastelevat niiden sisältöä tai toimintaa eri näkökulmasta. Tässä dokumentissa käsitellään kaikki Rational Rose-työkalun tukemat kaaviotyypit: käyttötapauskaavio (engl. use case diagram), aktiviteettikaavio (engl. activity diagram), luokkakaavio (engl. class diagram), sekvenssikaavio (engl. sequence diagram), olioyhteistyökaavio (engl. collaboration diagram), tilakaavio (engl. statechart diagram), komponenttikaavio (engl. component diagram) ja toteutuskaavio (engl. deployment diagram). UML-standardi sisältää myös muutamia muita harvemmin käytettyjä kaavioita, joita ei käsitellä tässä. Kaikissa kaavioissa käytetään riippuvuussuhteita kuvaamaan kaavioiden olioiden toimintaa ja suhteita toisiinsa. UML:n määrittelemät yhteystyypit on kuvattu luvussa 2.1. 2.1 Yhteystyypit Kaavioiden oliot ovat yleensä riippuvaisia toisistaan. Tässä luvussa on kuvattu erilaiset merkintätavat, joilla olioiden välisiä yhteyksiä voidaan kuvata. Kaikki yhteystyypit eivät ole mahdollisia kaikissa kaavioissa. 2
2.1.1 Assosiaatio Assosiaatio (engl. association) on yleisin ja yksinkertaisin yhteistyyppi. Jos kahden olion välillä on assosiaatio, ne ovat jollakin tavalla tekemisissä toistensa kanssa. Kuvassa 1 näkyy yksinkertainen assosiaatio. Assosiaatioon, kuten myös muihin yhteystyyppeihin, voi liittyä suunta, rooleja ja olioiden lukumäärän ilmoittavia indikaattoreita, joista kerrotaan lisää seuraavissa luvuissa. Jos yhteydelle ei ole merkitty suuntaa (kummassakaan päässä ei ole nuolta), yhteys on molemminsuuntainen. Assosiaatioyhteyttä voi käyttää kaikissa kaavioissa. Luokka 1 Luokka2 Kuva 1: Yksinkertainen assosiaatio 2.1.2 Aggregaatio Aggregaatiota (engl. aggregation) voidaan käyttää tilanteissa, joissa kokonaisuus on riippuvainen osistaan (tai vastaavasti osa on riippuvainen kokonaisuudesta). Kuvassa 2 näkyy normaali aggregaatioriippuvuus. Jos halutaan korostaa, että kokonaisuus koostuu osistaan, voidaan käyttää koostumusaggregaatiota (engl. composite aggregation), jolloin aggregaatiota kuvaava timantti on väritetty. Aggregaatiota käytetään etupäässä luokkakaavioissa. Luokka 1 Luokka2 Kuva 2: Aggregaatio. Luokka 2 on Luokan 1 osa. 2.1.3 Perintä Perinnässä (engl. inheritance) aliluokka perii yliluokan ominaisuuksia ja/tai toimintoja. Esimerkki perintäsuhteesta on esitetty kuvassa 3. Perintää käytetään etupäässä luokkakaavioissa. Luokka 1 Luokka2 Kuva 3: Luokka 2 perii Luokan 1. 3
2.1.4 Riippuvuus Riippuvuussuhde (engl. dependency) kuvaa tilannetta, jossa oliot ovat tavalla tai toisella riippuvaisia toisistaan. Esimerkiksi kuvassa 4 esitetty riippuvuussuhde tarkoittaa, että Luokka1 on riippuvainen Luokasta 2, eli Luokassa 2 tehdyt muutokset saattavat vaikuttaa Luokan 1 toimintaan. Rational Rosen prosessissa riippuvuussuhteita käytetään usein etenkin pakkausten (kuva 5) ja komponenttien välisten yhteyksien kuvaamisessa mutta niitä voidaan käyttää myös muissa kaavioissa. Luokka 1 Luokka2 Kuva 4: Riippuvuussuhde. Luokka 1 on riippuvainen Luokasta 2. Pakkaus 1 Pakkaus 2 Kuva 5: Pakkausten välinen riippuvuussuhde. 2.1.5 Roolit Riippuvuussuhteen molemmille osapuolille voidaan merkitä rooli, joka kuvaa osapuolien tapaa osallistua riippuvuussuhteen. Esimerkki roolien käytöstä on esitetty kuvassa 6. Pomo +Komentaa +Tottelee Alainen Kuva 6: Roolit sisältävä assosiaatio. 2.1.5 Yhdestä moneen - ja monesta moneen yhteydet Yhteyksille voi myös määrittää, kuinka monta yhteyteen osallistuvien luokkien oliota toimintaan osallistuu. Kuvassa 7 on esimerkki monesta moneen -yhteydestä. Yritykseen voi kuulua nollasta äärettömään kappaletta työntekijöitä, jotka voivat työskennellä yhdessä tai kahdessa eri yrityksessä. 4
Jos yhteydelle ei ole merkitty näitä ns. "multiplicity"-määreitä, voidaan olettaa, että rajoitus on 1 tai sillä ei ole merkitystä. Seuraavassa on joitakin sallittuja notaatioita yhteyksiin osallistuvien olioiden määrien kuvaamiseksi: 1..* (= yhdestä äärettömään määrään) 1 2 1,2,4..6,8 (=1,2,4,5,6,8) * (= 0 - ääretön) 1..n (=1 - ääretön) n (= 0 - ääretön) Yritys Työntekijä n 1..2 Kuva 7: Monesta moneen assosiaatio 2.2 Näkyvyyssäännöt Lähes kaikille kaavioiden osille (esim. luokat, niidet attribuutit ja metodit, roolit jne.) voidaan asettaa näkyvyyssääntöjä, jotka määrittelevät, kenellä on oikeus käyttää kaavion olioita tai niiden osia. Näkyvyyssäännöt ovat: 1) Public, näkyy kaikkille, etumerkki + 2) Protected, näkyy rajatulle osalle (esim. pakkaukselle), etumerkki # 3) Private, ei näy ulospäin, etumerkki - Sääntöjen merkitys ei ole tarkkaan määrätty vaan se sovitaan usein tapauskohtaisesti. Näkyvyyssäännöt ovat peräisin yleisesti käytetyistä ohjelmointikielistä, joissa ne ovat olleet käytössä jo ennen UML:n syntyä. Näkyvyyssääntöjen merkityksissä on kielten välisiä eroja - esimerkiksi säännöllä Protected on eri merkitys ohjelmointikielissä C++ ja Java. Tästä johtuen etenkin toteutustason dokumenttien näkyvyysmääreiden tulkinta on usein riippuvainen käytettävästä toteutuskielestä tai -ympäristöstä. Näkyvyyssääntöjä kuvataan UM-työkaluissa usein graafisilla merkinnöillä etumerkkimerkinnän sijaan. Kuvassa 8 on esitetty luokkakaavio, jossa on käytetty molempia merkintätapoja. Luokan 1 metodien näkyvyyssäännöt on kuvattu graafisilla symboleilla, luokan 2 rooli "käyttää" etumerkillä. 5
Luokka 1 public metodi() protected metodi() private metodi() #käyttää Luokka 2 Kuva 8: Esimerkki näkyvyyssääntöjen käytöstä 2.3 Käyttötapauskaavio Jos UML-kaavioita halutaan käyttää jo järjestelmän määrittelyvaiheessa, aloitetaan yleensä käyttötapauksista, joita kuvataan käyttötapauskaavioilla. Ensimmäisessä vaiheessa etsitään järjestelmän käyttäjät (engl. actors), jotka voivat olla mitä tahansa olioita, jotka käyttävät järjestelmää tavalla tai toisella. Ne voivat siis olla ihmisiä tai esimerkiksi järjestelmän luomia prosesseja. Kun käyttäjät on löydetty, voidaan määritellä käyttötapaukset. Käyttötapaus kuvaa yhden loogisen kokonaisuuden, jolla käyttäjä suorittaa järjestelmän toiminnon tai kokoelman toimintoja. Käyttötapauksen tulisi sisältää selkeä alku ja loppu ja antaa järjestelmän käyttäjälle jokin hyöty. Yksittäisen käyttötapauksen sisältö kuvataan yleensä tekstimuodossa. Käyttötapauskaavio kuvaa järjestelmän käyttäjiä, heidän käyttötapauksiaan ja niiden suhteita toisiinsa. Kuvassa 9 on esimerkki käyttötapauskaaviosta. Käyttäjän ja käyttötapausten sekä käyttötapausten välisille yhteyksille voidaan antaa nimiä, jotka kuvaavat yhteyden merkitystä. Rational Rose tukee myös ns. stereotyyppejä, jotka ovat standarditapoja kuvata yhteyden laatua. Esimerkissä on käytetty stereotyyppiä include, joka ilmaisee, että ennen käyttötapauksen Anna arvosanat suorittamista käyttäjän Professori tulee suorittaa käyttötapaus Kirjaudu järjestelmään. Sama koskee käyttäjää Opiskelija ennen käyttötapauksen Katso arvosanoja suoritusta. Käyttötapaukset ja käyttötapauskaaviot ovat tärkeä osa järjestelmän mallintamisessa. Ne luovat pohjan, jolta voidaan edetä suunnitteluvaiheeseen. 6
Opiskelija Katso arvosanoja <<include>> <<include>> Kirjaudu järestelmään Professori Anna arvosanat Kuva 9: Käyttötapauskaavio 2.4 Aktiviteettikaavio Aktiviteettikaavioita voidaan käyttää sekä määrittely- että suunnitteluvaiheessa. Määrittelyvaiheessa niillä voidaan kuvata yksittäisten käyttötapausten toiminnan etenemistä tai useiden käyttötapausten välistä toimintaa, suunnitteluvaiheessa niillä voidaan kuvata esimerkiksi metodien toiminnan etenemistä. Aktiviteettikaaviot sisältävät aktiviteetteja, siirtymiä, päätöspisteitä ja synkronointipalkkeja. Kaavio koostuu siis aktiviteeteista, joista siirrytään siirtymillä toisiin aktiviteetteihin. Päätöspisteistä voidaan edetä eri suuntiin riippuen päätöspisteessä määritellyn ehdon saamasta arvosta. Synkronointipalkeilla voidaan kuvata, mitkä aktiviteetit voivat edetä rinnakkain tai mitkä aktiviteetit tulee suorittaa ennen kuin voidaan edetä tiettyyn pisteeseen. Kuvan 10 aktiviteettikaaviossa toiminta alkaa alkutilasta, jota kuvataan mustalla ympyrällä. Siitä edetään aktiviteettiin Kirjaudu, jossa käyttäjä yrittää kirjautua järjestelmään. 7
Kirjaudu Onko OK? [ Ei ] [ Kyllä ] Anna arvosanat Lähetä sähköposti arvosanojen valmistumisesta Erota huonot oppilaat Kuva 10: Aktiviteettikaavio Päätöspisteessä Onko OK? tarkistetaan, onko kirjautuminen OK. Jos se on, voidaan jatkaa, muuten palataan takaisin käyttötapaukseen Kirjaudu. Kun professori on antanut kaikkien arvosanat, hän voi lähettää oppilaille sähköpostin arvosanojen valmistumisesta tai erottaa huonot oppilaat. Nämä toiminnot voivat tapahtua rinnakkain. Kun molemmat toiminnot on suoritettu, voidaan edetä lopputilaan. 8
2.5 Luokkakaavio Luokkakaaviot ovat staattisia kaavioita, jotka kuvaavat järjestelmän rakennetta, eli sen luokkia ja niiden välisiä suhteita. Luokkakaaviot otetaan yleensä käyttöön suunnitteluvaiheessa. Luokka voi sisältää attribuutteja, jotka kuvaavat luokan tietosisältöä ja metodeja, jotka kuvaavat luokan toimintaa. Luokat ja niiden toiminta oletetaan ennestään tutuiksi, joten niitä ei käsitellä tässä sen enempää. Luokkakaaviot ovat keskeinen osa järjestelmän rakenteen kuvaamisessa. Luokkien ja niiden operaatioiden löytäminen sekä luokkien välisten suhteiden kuvaaminen on tärkein osa oliopohjaisen järjestelmän suunnitteluvaiheessa. Luokat kuvataan kaavioissa yleensä suorakulmioina. Rational Rosen työkalu tukee myös muita kuvaustapoja luokille, mutta niitä ei käsitellä tässä. Kuvassa 11 on esitetty luokka Oppilas, josta on kuvattu attribuutit Nimi ja Osoite sekä operaatiot kirjaudu (näkyvyys public) ja asetaosoite (näkyvyys protected). Luokkaavioissa voi käyttää kaikkia luvussa 2.1 käsiteltyjä yhteyksiä. Samassa luvussa on myös esimerkkejä luokkakaavioista. Rational Rose-työkalulla on mahdollista määrätä, mitkä attribuutit ja operaatiot luokasta halutaan näyttää tietyssä kaaviossa. Luokan tiedot säilytetään yhdessä paikassa, joten sama luokka tarvitsee luoda vain kerran, mutta sitä voi käyttää useissa eri kaavioissa. Opiskelija nimi osoite kirj audu() asetaosoite() Kuva 11: Luokka Opiskelija 2.6 Sekvenssikaavio ja olioyhteistyökaavio Sekvenssikaaviot ja olioyhteistyökaaviot kuvaavat olioiden yhteistyötä järjestettynä ajan suhteen. Yksi kaavio esittää graafisesti yhden tyypillisen skenaarion eli yhden tavan suorittaa jokin järjestelmän toiminto. Sekvenssi- ja olioyhteistyökaaviot kuvaavat luokkia ja olioita sekä niiden toisilleen välittämää informaatiota, jonka avulla kyseinen skenaario saadaan suoritettua. Sekvenssikaavioita käytetään usein käyttötapausten toiminnan kuvaamiseen. Yksi sekvenssikaavio sisältää tällöin yhden tyypillisen tavan edetä käyttötapauksen eri vaiheiden läpi. 9
Olioyhteistyökaavioita käytetään usein myöhemmässä suunnitteluvaiheessa, jolloin oliot ovat järjestelmän sisältämien luokkien edustajia ja olioiden lähettämät viesti metodikutsuja. Periaatteessa sekvenssi- ja olioyhteistyökaavioilla voidaan esittää täsmälleen samat asiat. On kuitenkin todettu, että määrittelyvaiheessa on hyvä käyttää sekvenssikaavioita, jotka ovat helpommin ymmärrettäviä myös vähemmän teknisille ihmisille. Suunnitteluvaiheessa taas olioiden yhteistyötä on usein kätevämpi kuvata olioyhteistyökaavioilla. Rational Rosen työkalulla sekvenssikaavio voidaan muuntaa yhdellä komennolla olioyhteistyökaavioksi ja päinvastoin. Kuvien 12 ja 13 kaaviot kuvaavat saman skenaarion, jossa Professori lisää uuden kurssin järjestelmään. Kyseeessä on määrittelyvaiheen käyttötapauksen skenaario ja kuvista nähdään, että sekvenssikaavio antaa selkeämmän kuvan tapahtumien etenemisestä ajan suhteen. Professori Arvosanalomake Kontrolleri Kurssi syötä kurssin tiedot lähetä suorituspyyntö lisää kurssi lisää kurssi anna palaute Kuva 12: Sekvenssikaavio 10
Professo ri 1: syötä kurssin tiedot 2: lähetä suorituspyyntö 5: anna palaute Arvosanalo make 3: lisää kurssi Kontrolle ri 4: lisää kurssi Kurssi Kuva 13: Olioyhteistyökaavio 2.7 Tilakaavio Tilakaavioita voidaan käyttää useisiin eri käyttötarkoituksiin mutta Rational Rosen prosessissa niitä käytetään kuvaamaan runsaasti dynaamista toiminnallisuutta sisältävien luokkien toimintaa. Yhdellä tilakaaviolla tulisi kuvata yhden luokan sisäinen toiminta, eli luokan kaikki tilat sekä luokan saamat toimintopyynnöt ja niiden aiheuttama toiminta. Olio on koko elinkaarensa ajan jossakin tilassa, jossa se toteuttaa jonkin ehdon, suorittaa jonkin toiminnon tai odottaa jotakin toimintoa. Olion tila määräytyy sen attribuuttien ja muihin olioihin viittaavien linkkien perusteella. Tilat kuvataan tilakaaviossa suorakulmioilla, joissa on pyöristetyt kulmat. Tilasta toiseen siirrytään tilasiirtymillä. Tilasiirtymään voi liittyä suoritettava toiminto tai se voi olla automaattinen siirtymä, joka suoritetaan, kun tilan toiminnot on suoritettu. Jos tilasiirtymään liittyy toiminto, se kuvataan siirtymän yhteydessä antamalla siirtymälle toiminnon nimi. Tilasiirtymä kuvataan yksisuuntaisella nuolella alkuperäisestä tilasta seuraavaan tilaan. Tilakaaviossa on kaksi erityismerkityksen omaavaa tilaa, alkutila ja lopputila. Nämä on esitetty kuvassa 14. 11
Alkutila Lopputila Kuva 14: Alku- ja lopputila Tiloihin voi liittyä kolmenlaisia toimintoja: tilaan tultaessa suoritettavat toiminnot (engl. entry actions), tilassa suoritettavat toiminnot ja tilasta poistuttaessa suoritettavat toiminnot (engl. exit actions). Kuvan 15 tilakaaviossa on kuvattu Opiskelijan lisääminen Kurssille. Kaavio on luokan Kurssi sisäinen tilakaavio.tilassa Initialisointi suoritetaan tilan sisäinen toiminto Initialisoi kurssin data. Siitä edetään, kun suoritettavaksi tulee toiminto lisääoppilas, joka aiheuttaa toiminnon ^OsallistujaLista.luo. Merkillä ^, jota seuraa luokan nimi ilmaistaan, että suoritettava toiminto on kyseisen luokan toiminto, edellisessä siis luokan OsallistujaLista toiminto luo. Jos toiminto on tilakaavion kuvaaman luokan sisäinen toiminto, siihen viitataan vain toiminnon nimellä. Seuraavaksi voidaan edetä tilaan Avattu, jossa suoritetaan tilaan tultaessa luokan sisäinen toiminto Rekisteröi oppilas. Tilasta poistuttaessa suoritetaan luokan OsallistujaLista toiminto lisääoppilas. Tämän jälkeen voidaan lisätä korkeintaan kymmenen oppilasta kurssille, jonka jälkeen siirrytään tilaan Suljettu ja siitä lopputilaan. Tilasta Avattu ja Suljettu voidaan myös edetä tilaan Peruutettu, jolloin OsallistujaLista deletoidaan. Alkutila Initialisointi do/ Initialisoi kurssin data lisääoppilas ^OsallistujaLista.luo [ määrä<10 ] / lisääoppilas Avattu entry/ Rekisteröi oppilas exit/ ^OsallistujaLista.lisääOppilas(Oppilas) [ määrä=10 ] Suljettu peruuta peruuta Peruutettu ^OsallistujaLista.deletoi Lopputila Kuva 15: Tilakaavio 12
2.8 Komponenttikaavio Komponenttikaavioita voidaan käyttää moniin erilaisiin tarkoituksiin. Rational Rosen työkalulla voidaan tehdä kolmentyyppisiä komponenttikaavioita: pakkauskomponenteista, lähdekoodikomponenteista tai ajonaikaisista komponenteista koostuvia kaavioita. Pakkauksilla järjestelmän osat voidaaan jakaa hierarkkisiin pakkauksiin, jotka kukin sisältävät jonkin yhtenäisen kokonaisuuden järjestelmästä. Lähdekoodikomponetit kuvaavat pakkausten sisältämiä fyysisiä lähdekooditiedostoja. Yksi komponentti voi sisältää useamman luokan, mutta useimmiten yhtä luokkaa vastaa yksi lähdekooditiedosto ja vastaavasti yksi lähdekoodikomponentti. Ajonaikaiset komponentit voivat olla esimerkiksi exe-tiedostoja, appletteja tai vaikkapa COM-komponentteja. Kuvassa 5 (luku 2.1) on esitetty pakkauskomponenteista koostuva komponenttikaavio. Pakkauksia voidaan käyttää sekä suunnitteluvaiheen logiikkaa kuvaavissa kaavioissa että järjestelmän fyysistä rakennetta kuvaavissa komponenttikaavioissa. Kuvan 16 kaavio esittää kolmea lähdekoodikomponenttia, jotka kukin "mappautuvat" yhteen suunnitteluvaiheessa määriteltyyn luokkaan. Profes sori Opiske lija Kurssi Kuva 16: Lähdekoodikomponenteista koostuva komponenttikaavio Kuvan 17 kaavio koostuu ajonaikaisista komponenteista. Kaavion kuvaama järjestelmä sisältää kaksi DLL-komponenttia ja niitä käyttävän EXE-tiedoston. Rajapinnat, tässä LaskutusAPI ja TietokantaAPI, kuvataan "tikkarinotaatiolla" (engl. loppypop notation). 13
<<EXE>> Professorin toiminnot <<DLL>> Kurssit <<DLL>> Tietokanta KurssitAPI Tietokanta API Kuva 17: Ajonaikaisista komponenteista koostuva komponenttikaavio 2.9 Toteutuskaavio Toteutuskaaviossa (engl. deployment diagram) ohjelmisto liitetään sen suoritusympäristöön. Toteutuskaavio esittää prosessoivat elementit, niiden yhteydet toisiinsa ja niissä suoritettavat prosessit. Se auttaa ymmärtämään järjestelmän topologiaa, skaalautuvuutta, suorituskykyvaatimuksia, ympäristövaatimuksia ja laitteistovaatimuksia ja ottaa huomioon asioita kuten laitteistojen fyysinen sijainti, kaistanlaajuus ja rinnakkaisprosessointi. Kuvan 18 kaavio kuvaa järjestelmää, jossa on kolme eri laitteistoa. Kaikki prosessoivat osat tarvitsevat Tietokantapalvelinta. Tietokantapalvelina toimii Netfinity 5000-laitteisto. 14
Tietokantapalvelin ERP-järjestelmä Netfinity 5000 preemptive WWWPalvelin Kuva 18: Toteutuskaavio 3 Rational Unified Process ja Rational Rose Enterprise Edition Rational Unified Process on Rationalin ehdotus ohjelmistonkehitysprosessiksi. Se perustuu vahvasti UML:ään ja Rationalin UML-työkaluihin. Prosessista on raskaampia ja kevyempiä versioita, mutta niissä kaikissa olisi tarkoitus käyttää mahdollisimman paljon hyväksi edellisissä luvuissa esiteltyjä kaavioita. Rational Unified Processissa järjestelmän kehitys aloitetaan määrittelyllä, jossa yritetään identifioida järjestelmän käyttäjät ja käyttötapaukset. Käyttötapaukset jaetaan pakkauksiin, jotka sisältävät käyttötapauskaavioita. Käyttötapauksiin voi liittyä sekvenssi- ja aktiviteettikaavioita, mutta niitä ei kuitenkaan tarvitse käyttää, jos käyttötapaus on yksinkertainen. Nämä kaaviot sisältyvät työkalussa Käyttötapausnäkymään. Looginen näkymä sisältää käyttötapausten ongelmia ratkovia suunnitteluvaiheen kaavioita. Tähän vaiheeseen kuuluvat etenkin luokkakaaviot ja tilakaaviot. Myös sekvenssikaavioita, olioyhteistyökaavioita ja aktiviteettikaavioita voidaan käyttää. Tiettyyn määrittelyvaiheen käyttötapaukseen liittyvät kaaviot voidaan liittää osaksi käyttötapauksen toteutusta (engl. realization). Komponenttinäkymä sisältää komponentteja ja komponenttikaavioita. Komponentit voidaan liittää osaksi suunnitteluvaiheen luokkien ja pakkausten toteutusta. Toteutusnäkymä sisältää toteutuskaaviot, jotka kuvaavat järjestelmän topologiaa, prosessoreita ja muita fyysisiä laitteita. 15
Kaikkiin olioihin voidaan liittää työkalun ulkopuolella tuotettuja tiedostoja, kuten käyttötapausten tekstikuvauksia. Työkalu ei luonnollisestikaan osaa avata kaiken tyyppisiä tiedostoja, mutta sillä voi pitää kirjaa järjestelmään liittyvistä dokumenteista. Rational Rose Enterprise Edition on kehitetty tukemaan Rational Unified Processia ja se suoriutuukin siitä melko hyvin. Se on suunniteltu koko järjestelmän kehitysprosessin työkaluksi, joten siinä on panostettu eri vaiheiden integrointiin. Eri kaavioissa voi käyttää samoja olioita (olioita, joilla on sama tietosisältö) mutta esittää ne eri tavalla. Myös määrittelyvaiheen, suunnitteluvaiheen ja toteutusvaiheen integrointi on toteutettu melko hyvin. Suunnitteluvaiheessa voidaan luoda niin sanottuja Realization-kaavioita määrittelyvaiheen kaavioista, jolloin muutokset määrittelyssä huomataan myös suunnitteluvaiheen vastaavissa osuuksissa. Eri vaiheissa luotuja olioita voi käyttää myös eri vaiheiden kaavioissa, jolloin ne saavat eri merkityksen. Olioita on helppo lisätä uusiin kaavioihin hiirellä drag-and-dropperiaatteella. Jos olio on laillinen kaaviossa, johon sitä yritetään siirtää, siirto onnistuu. Jos olion tietosisältöön tehdään jossakin kaaviossa muutoksia, muutokset näkyvät kaikissa kaavioissa, joissa olio esiintyy. Työkalu yrittää pitää huolta myös olioiden nimeämisestä, samaan nimiavaruuteen ei voida luoda useita saman nimisiä olioita ja suunnitteluvaiheen olio oletetaan vastaavan nimisen määrittelyvaiheen olion toteutukseksi, jos sellainen löytyy. Rational Unified Process määrittelee paljon stereotyyppejä, jotka voivat olla yhteyksiä tai ominaisuuksia, joilla on kaavioissa erikoismerkitys. Näiden tuki on työkalussa hyvinkin laajaa. Huonojakin puolia löytyy. Kaikkia UML:ssä määriteltyjä piirteitä ei ole toteutettu ja joitakin poisjätettyjä piirteitä jää kaipaamaan. Jotkin toiminnot ovat myös hieman oudosti toteutettuja, esimerkiksi pakkauksen käyttötapauskaavion saa luotua ainoastaan kaksoisklikkaamalla Use Case Viewin Main-kaaviossa olevaa pakkausta, vaikka muut kaaviot saa luotua sekä ikkunan päävalikoista että oikealla hiirennapilla aukeavasta valikosta. Kaaviossa olevien olioiden kaksoisklikkaaminen aiheuttaa muutenkin aivan erilaisia toimintoja eri kaavioissa ja jopa saman kaavion eri olioille, mikä aiheuttaa välillä sekaannuksia. Export-toimintoa kaavioiden muuntamiseksi esimerkiksi gif- tai jpeg-formaatteihin ei ole ja se on selkeä miinus. Ohjelmasta löytyy myös muutamia oikeita bugeja, mutta se ei kuitenkaan kaadu helposti. Kokonaisuudessaan Rational Rose Enterprise Edition on varsin hyvä työkalu, joka ei ole enää pelkkä kaavioeditori vaan koko ohjelmistonkehitysprosessia tukeva merkittävä apuväline. 16
LÄHTEET [1] Fowler, Kendall (1997). UML distilled : applying the Standard Object Modelling Language [2] Quatrani, 2000, Visual Modeling with Rational Rose 2000 and UML. [3] Rational Rose Modeler Edition CD [4] UML 1.1 Notation Guide, http://www.rational.com/media/uml/resources/media/ad970805_uml11_notation2.pdf. 17