UML-kuvauskielten käyttö ohjelmistojen vaatimusmäärittelyissä

Transkriptio

1 UML-kuvauskielten käyttö ohjelmistojen vaatimusmäärittelyissä Hannu A Heikkinen Helsinki HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

2 ii Sisältö 1 Johdanto 1 2 Ohjelmistojen vaatimusmäärittely 1 3 UML 2.0 vaatimusmäärittelyissä UML:n historia Muutoksia UML 1 versioista 2 versioon vaatimusmäärittelyn näkökulmasta Näkymät ja kaaviotyypit Käyttötapauskaavio Käyttötapauskaavio ja ei-toiminnalliset vaatimukset Aktiviteettikaaviot UML vaatimusten analysoinnissa 11 5 UML ja toiminnalliset vaatimukset 11 6 UML ja ei-toiminnalliset vaatimukset 11 7 Yhteenveto 11 Lähteet 12

3 1 1 Johdanto UML-kuvauskielten perhe on ollut oliopohjaisen ohjelmistotuotannon kulmakivi. Kieliä on käytetty lähinnä oliopohjaisessa suunnittelussa, mutta niitä on mahdollista käyttää myös muissa oliopohjaisen ohjelmistotuotannon työvaiheissa. Vaatimusmäärittely on merkittävä vaihe suunnitelmallisessa ohjelmistoprosessissa. Mitä aikaisemmin virhe havaitaan ohjelmiston määrittelyssä sitä edullisempaa sen korjaaminen on. Tämän vuoksi vaatimusmäärittelyn menetelmien kehittäminen on erityisen kannattavaa. Opinnäytteen tavoitteena on perehtyä UML-kuvauskielen käyttöön vaatimusmäärittelyn menetelmänä kirjallisuudessa esitettyjen tulosten avulla ja selvittää mitä UML:n avulla kannattaa ja on mahdollista toteuttaa vaatimusmäärittelyssä. 2 Ohjelmistojen vaatimusmäärittely * * * 3 UML 2.0 vaatimusmäärittelyissä UML (Unified Modeling Language) on kieli, jolla voidaan visualisoida ohjelmistojen toimintaa, sisältöjä ja ohjelmistoa suorittavaa järjestelmää [Obj07]. UML on yleiskäyttöinen kieli, joka tarkoittaa sitä, että sitä voidaan käyttää kaikilla olemassa olevilla toteutusympäristöillä ja sovellusalueilla sekä sovellustyypeillä. Toteutusympäristöllä tarkoitetaan alustan ja ohjelmointikielen yhdistelmää, kuten J2EE tai.net. Sovellusalueilla tarkoitetaan sitä olosuhdeympäristöä, jossa ohjelmistoa käytetään kuten terveydenhoito, talous, tietoliikenne. Sovellustyypillä tarkoitetaan ohjelmiston lajia, joita ovat informaatiojärjestelmä, hallintajärjestelmä, muunnosjärjestelmä, kytkentäjärjestelmä ja työkaluohjelmisto [BRA02]. UML-kaavioita käsiteltäessä MOF (Meta-Object Facility) eli UML-kielen metamalli toimii säännöstönä kaavioiden piirtämiselle. XMI (XML Metadata Interchange) on XML:ään perustuva formaatti UMLkielen metadatan siirtämiseen. UML on standardin kaltainen tapa kuvata toteutettavaa järjestelmää oliopohjaisessa ohjelmistotuotannossa [Lan02]. UML:n yleiskäyttöisyys ja laaja hyväksyntä pitävät sen

4 2 toistaiseksi suosittuna, joskaan ei ainoana visualisointiin soveltuvana tapana. Tämä tutkielman kappale keskittyy UML:n ominaisuuksiin, joita käytetään ohjelmistojen vaatimusmäärittelyssä. Erityisesti tarkastellaan UML:n 2 version uusia ominaisuuksia. 3.1 UML:n historia UML:n kehitys alkoi vuonna 1994, jolloin Grady Booch ja James Rumbaugh aloittivat työn yhdistääkseen aikaisemmin omilla tahoillaan kehittelemiänsä oliomallinnustekniikoita. Vuonna 1995 Ivar Jacobson toi mukaan oman menetelmänsä. Menetelmien yhdistäminen oli järkevää kolmesta syystä. Menetelmät olivat jo kehittymässä samaan suuntaan, käsitteiden yhdenmukaistaminen toisi vakautta ja helpottaisi ohjelmistoprojektien yhteensovittamista. Menetelmien yhdessä kehittäminen toi ratkaisuja ongelmiin, joita ei aikaisemmin kyetty ratkaisemaan yksin. Vuonna 1996 OMG (Object Management Group) julkaisi ehdotuksen UML 1.0 versioksi, jonka pohjalta UML on kehittynyt lukuisten yhteisöjen panoksen tukemana [DJA01]. UML:n versioista tällä hetkellä 2.0:n ominaisuudet ovat saaneet riittävän työkaluohjelmistojen tuen. UML:n tämän hetkinen virallinen versio on 2.1.1, joka julkaistiin elokuussa Kehitystyö versiota varten on käynnissä. 3.2 Muutoksia UML 1 versioista 2 versioon vaatimusmäärittelyn näkökulmasta. UML 2.0 versiossa tuli mahdolliseksi asettaa kaavio sisältämään toinen toisiaan. Periaatteessa mikä tahansa UML:n kaaviokomponentti voi toimia säiliönä (classifier) toiselle kaaviolle. UML:ää käyttävät työkaluohjelmistot kykenevät, metamalliin perustuen, tarjoamaan toiminnallisuuden, jossa kaaviot ovat linkitetty toisiinsa sisäkkäisesti [OMG08]. Tämä tarjoaa vaatimusmäärittelylle käytännöllisen tavan yhdistää käyttötapauskaavioihin muita UML:n kaavioita ja antaa käyttötapauskaaviolle mahdollisuuden sisältyä toiseen komponenttiin. Vaatimusmäärittelyn kannalta esimerkiksi kaavioon kuvattu käyttötapaus voi linkittää itseensä aktiviteettikaavioina kuvattuja liiketoimintaan liittyviä logiikoita. Käyttötapauskaaviossa teknisenä muutoksena on suhteiden kuvauksessa käytettyjen nimien muutos [EPL04]. Merkinnät "uses" ja "extends" ovat muutettu merkinnöiksi "include" ja "extend". Täysin uusi suhteen tyyppi on "generalize". Muutokset näissä suhdemerkinnöissä on herättänyt kritiikkiä. Merkintöjen monitulkintaisuus

5 3 on aiheuttanut epätietoisuutta järjestelmien kehittäjille [AlI04]. Aktiviteettikaaviolla kuvataan ohjelmiston dynaamista toimintaa. UML 2 mukana aktiviteettikaavioon on tullut uusia mallinnuselementtejä. Näitä ovat aktiviteetin aloitus- ja jälkiehtoa kuvaavat merkit (Pin) ja kutsun välittämistä kuvaavien lähetys ja vastaanotto komponentit. 3.3 Näkymät ja kaaviotyypit Ohjelmiston määrittely ei onnistu yhdellä kaaviolla eikä useankaan UML:ssä käytetyn kaavion esittäminen sellaisenaan toisi kuvaukseen riittävää kattavuutta. Kruchtenin 1995 esittelemä "4+1-malli" esittelee tietojärjestelmien kehitykseen näkökulmapohjaisen lähestymistavan [Kru95]. 4+1-mallissa on alun perin esitelty oma UML:stä poikkeava notaatio, mutta periaate on sama. Mallissa painotetaan tarkastelemaan kehitettävää järjestelmää eri näkökulmista, jotta projektia kuvataan kaikkien sidosryhmien kannalta. 4+1-mallin näkökulmat ovat looginen-, prosessi-, fyysinen- ja kehitysnäkökulma. Lisäksi 4+1-mallissa on skenaarionäkökulma. Skenaarionäkökulmassa kuvataan järjestelmää käytännön käyttötapausesimerkkien kautta. UML:n kehittäjät ottivat 4+1- mallin UML:ään. Näkökulma asettaa UML-kaavion tarkastelulle lähtökohdan ja helpottaa siten sen tulkintaa. Näkökulmia ovat käyttötapausnäkymä (use-case view), looginen näkymä (logical view), toteutusnäkymä (implementation view), prosessinäkymä (process view) ja käyttöönottonäkymä (deployment view) [EPL04]. UML:n käyttö ei edellytä näiden näkymien huomioon ottamista ja kaaviot toimivat sellaisenaan halutulla tavalla kehitettävänä olevan järjestelmän kuvaamisessa. Toisaalta kehitettävän järjestelmän tarkastelu eri näkökulmista helpottaa määrittelyä. Jos järjestelmän olennainen tehtävä on automatisoida yrityksessä suoritettavia työvaiheita, on järkevää miettiä asioita työnkulun näkökulmasta. Tuotanto- tai liiketoimintavaiheen kuvaaminen aktiviteettikaaviolla prosessin alusta loppuun luo tilanteesta kokonaiskuvan, johon muita vaatimusmäärittelyjä voidaan verrata. UML-kielen versiossa 2.0 on määritelty 13 erilaista kaaviotyyppiä [OMG08]. Kaavioita on kolmea eri tyyppiä. Staattista rakennetta, käyttäytymistä, ja vuorovaikutusta kuvaavia kaavioita. Staattista rakennetta kuvaavia kaavioita ovat luokkakaavio (Class diagram), oliokaavio (Object diagram), komponenttikaavio (Component diagram), rakennekaavio (Composite Structure diagram), pakkauskaavio (Package diagram) ja

6 4 sijoituskaavio (Deployment diagram). Käyttäytymistä kuvaavia kaavioita ovat käyttötapauskaavio (Use Case diagram), aktiviteettikaavio (Activity diagram) ja tilakaavio (State machine diagram). Vuorovaikutusta kuvaavia kaavioita ovat sekvenssikaavio (Sequence diagram), kommunikaatiokaavio (Communication diagram), ajoituskaavio (Timing diagram) ja vuorovaikutuskaavio (Interaction diagram). Kaaviot voidaan luokitella rakennetta ja käyttäytymistä kuvaaviin kaavioihin. Kuvassa 1 on kuvattu UMLkaavioiden luokittelu. UML-kaavioita ei sellaisenaan sovelleta mihinkään tiettyyn ohjelmiston määrittelyn tai suunnittelun vaiheeseen. UML-kaavioiden käytön ratkaisee se, minkä tyyppisestä ohjelmistosta on kyse. Minkälainen lähestymistapa valitaan ohjelmiston vaatimusmäärittelyyn. Lähestytäänkö tehtäväaluetta liiketoimintaprosessien kautta vai asetetaanko ohjelmistolle tiettyjä perustavoitteita, joita sen tulee täyttää. Minkälaista Kuva 1: UML-kaavioiden luokittelu [ViG06] prosessimallia aiotaan kehityksen aikana käyttää. Tukevatko käytetyt työkaluohjelmistot prosessin mukaista työskentelyä ja löytyykö työkaluohjelmistoista tuki käytetyille kaavioille. Nämä ja monet muut asiat vaikuttavat siihen, mitä ja miten yhdisteltyinä UMLkaavioita käytetään. Yksi tyypillinen yhdistelmä esiintyy RUP-prosessimallissa (Rational Unified Process), jota pidetään yleisesti käyttötapauksiin perustuvaksi ja arkkitehtuuriorientoituneeksi tavaksi toteuttaa oliopohjaisia ohjelmistoja. Käyttötapauk-

7 5 set määrittelevät ohjelmiston kehityksen sekä asiakkaalle, että ohjelmiston suunnittelijoille. RUP-prosessin mukainen ohjelmiston määrittely kuvataan UML-kielen käyttötapauskaaviolla [Ree02]. RUP:n ja muidenkin vakiintuneiden prosessimallien tueksi on olemassa työkaluohjelmistoja, joissa käytetään kuvauskielenä UML:ää. 3.4 Käyttötapauskaavio Käyttötapauskaavio on UML:n paljon käytetty perustyökalu vaatimusmäärittelyssä. Käyttötapaukset ovat yleinen tapa määritellä ohjelmiston toiminnallisia vaatimuksia. Käyttötapauksilla annetaan korkean tason kuva siitä, miten järjestelmä toimii suhteessa sen käyttäjään. Toiminnalliset vaatimukset kuvataan käyttötapauskaaviossa helpoilla symboleilla, jolloin se on hyvin helposti ymmärrettävä myös ohjelmistotekniikkaan perehtymättömälle henkilölle [EPL04]. Kognitio-psykologisessa tutkimuksessa, jossa verrattiin luokkakaavioiden ja käyttötapauskaavioiden käyttämistä, todettiin käyttötapauskaavioiden olevan hyvä kommunikaatiotyökalu. Luokkakaavio soveltuu myös vaatimusten kuvaamiseen, mutta on tekniikaltaan monimutkaisempi. Luokkakaavion tuoma näkökulma määriteltävään järjestelmään poikkeaa käyttötapauskaavion näkökulmasta, joten sen avulla vaatimukset kuvautuvat eri tavalla [SiL04]. Käyttötapauskaavion Symboleja ovat toimija (Actor), käyttötapaus (Use Case), yhdysviiva (Connector) [Lan02]. Kuvassa (Kuva 2) on esitetty symbolit tilanteessa, jossa toimijat ja käyttötapaukset on säiliöity kuvan vasemmalla puolella pakkauksiin. Tässä tapauksessa UML:n kaaviotyyppi pakkaus toimii säiliönä käyttötapauskomponenteille. Kuvan oikealla puolella on käyttötapauskaavio, jossa käytetään pakkausten komponentteja. Käyttötapauskaaviossa toimija-symboli (actor) esittää järjestelmän ulkoista toimijaa. Toimija voi olla todellinen käyttäjä tai järjestelmän ulkopuolinen toinen järjestelmä, joka käyttää kuvatun järjestelmän tarjoamia palveluja. Toimijasta on piirretty suhdeviiva, jonka nuoli osoittaa käyttötapausta. Nuoli kertoo näiden välillä olevan vuorovaikutussuhteen. Ovaali-kuvio käsittää järjestelmässä olevan toiminnallisuuden. Kaavioon liittyy aina erillinen dokumentti, joka kuvaa kunkin käyttötapauksen seikkaperäisesti. Käyttötapaus voi olla esimerkiksi "Lipun varaus". Kuvan oikeaan alakulmaan on kuvattu järjestelmän ulkopuolinen automaattinen järjestelmä, jossa on käytetty UML:n laajentamismahdollisuutta stereotyypillä. Stereotyyppi kertoo, että kyseessä on toimija. Vaikka käyttötapauskaavioiden hyödyllisyyttä on kyseenalaistettu, on niistä

8 6 edelleen apua vaatimusten määrittelyssä. Yhden käyttötapauksen sijoittaminen yhteen käyttötapauskomponenttiin, jota käytetään tekstin, toimijoiden ja muiden kaavioiden sitojana on selkeästi hyödyllinen mallintamiskeino. Kuva 2: Käyttötapausten kuvaus käyttötapauskaaviolla 3.5 Käyttötapauskaavio ja ei-toiminnalliset vaatimukset Ei-toiminnalliset vaatimukset ovat järjestelmän toimintaan ja -laatuun liittyviä ehtoja, kuten riittävä suorituskyky, vasteaika, palvelun laatu, saatavuus. Ohjelmiston vaatimusmäärittelyssä nämä ehdot kirjataan ylös vaatimuksia, mutta niiden seuraaminen osana ohjelmistonkehitysprosessia on hankalaa. Usein kriittisimmän virheet ohjelmistossa liittyvät sen ei-toiminnallisiin vaatimuksiin. Nämä ovat tyypillisesti hankalimpia vikoja korjata. 4+1-mallissa ei-toiminnalliset vaatimuksia kuvataan prosessi-näkökulmassa [Kru95]. Myös UML:n prosessinäkökulma on tarkoitettu ei-toiminnallisten vaatimusten kuvaamiseen. Ongelmana tässä on kuitenkin se, että vaatimukset eivät tule huomatuksi

9 7 kehitysprosessin aikana tätä kautta. Ratkaisuksi ongelmaan on ehdotettu ei-toiminnallisten vaatimusten liittämistä osaksi käyttötapausten mallintamista kontrollitapausten avulla [ZoP07]. Ei-toiminnallisten vaatimusten nostaminen 4+1-malliin keskelle skenaario-näkökulmaan pakottaa ottamaan järjestelmän suunnittelussa huomioon käyttötapausten lisäksi siihen liittyvän ei-toiminnallisen vaatimuksen (kuva 3). Kuva 3: 4+2 malli [ZoP07] Kontrollitapaus (control case) on ei-toiminnallinen vaatimus. Kontrollitapauksena kuvattu ei-toiminnallinen vaatimus voidaan liittää käyttötapauskaaviossa käyttötapaukseen. Kontrollitapauksien suunnittelu aloitetaan tunnistamalla ei-toiminnallisiin vaatimuksiin vaikuttavat olosuhdetekijät (operating conditions). Näitä ovat esimerkiksi tietoliikenneyhteyden katkeaminen, järjestelmän kuormittuminen, sähkökatkos. Kontrollitapauksiin kuvataan myös riskit ja seuraukset sidosryhmille. Kontrollitapaukset luokitellaan pääkategorioihin kuten, luotettavuus, saatavuus, eheys, skaalautuvuus ja tietoturva. Kontrollitapaus siis kuvaa sen laatuvaatimuksen, jonka järjestelmän täytyy täyttää ettei siihen liittyvä riski toteudu. Suorituskykyyn liittyvä kontrollitapaus esimerkkinä kuvassa 4.

10 8 Kuva 4: Kontrollitapaus esimerkki [ZoP07] Kontrollitapauksen liittäminen käyttötapauskaavioon tapahtuu hyödyntämällä UML:n stereotyypitystä. Stereotyypityksellä voidaan laajentaa UML:n omaa ilmaisuvoimaa. Kontrollitapauksia varten on esitetty yksinkertainen notaatio (kuva 5). Notaatiossa olosuhdetekijää kuvaa oma symboli, joka liitetään suhdeviivalla käyttötapaukseen. Suhdeviivaa tarkennetaan stereotyypillä "<<operating under>>". Näin käyttötapaukseen liitetään aina yksi tai useampia olosuhdetekijöitä. Olosuhdetekijään liitetään suhdeviivalla yksi kontrollitapaus stereotyypillä "<<controlled by>>". Kuva 5: Notaatio kontrollitapauksen liittämiseksi käyttötapauskaavioon [ZoP07] 3.6 Aktiviteettikaaviot Aktiviteettikaaviolla voidaan mallintaa organisaatioiden olemassa olevia työnkulkuja sekä mallintaa jonkin tietyn olioksi mallinnettavan asian sisäinen toiminta. Aktiviteettikaavio on kuvaustavaltaan tilakaavion kaltainen verkko, mutta sitä käytetään eri tarkoitukseen. Aktiviteettikaavioilla kuvataan ohjelmiston vaatimusmäärittelyssä toi-

11 9 mintojen kulkua ja niiden tuloksia. Riippuen UML-kielen käyttötavasta, aktiviteettikaaviolla voidaan vaatimusmäärittelyssä kuvata tehtäväalueen korkean tason käyttäytymistä tai kuvata tarkasti jonkin tietyn toiminnon vaiheita. Korkean tason kuvauksen yhteydessä kaaviosta käytetään englannin kielellä nimitystä "activity diagram" ja toiminnon kuvauksen yhteydessä "activity chart". Kuvassa (kuva 6) on esitetty yksinkertainen esimerkki aktiviteettikaaviosta, jossa kuvataan perunoiden keittämistä. Kuvassa huomionarvoista ovat ehtosolmut. Perunoiden kypsentäminen vaatii prosessin aloittamisen alkusolmusta eli veden kiehuttamisen ja syötteenä raakoja perunoita. Näiden esiehtojen täytyttyä siirrytään saman tien perunoiden keittoon, joka vaatii kiehuvaa vettä ja perunoita. Lopputuotteena saadaan kypsiä perunoita. Kuva 6: Aktiviteettikaavio Järjestelmän käyttäytymistä kuvaavissa aktiviteettikaavioissa (diagrams) toimintoja voidaan osioida liiketoimintaan liittyvien toimijoiden mukaisesti. Kahteen eri osioon voidaan jakaa palvelun tuottava osa ja palvelua tarjoava osa kuvattavasta ohjelmiston osasta. Osiot kuvataan "uima-altaan ratoihin" (Swimlanes) assosioiduilla pystyviivoilla, joiden välillä aktiviteetteihin liittyvät suhteet on kuvattu viivoilla. Kuvassa (kuva 7) on yksinkertaisella kirjan syntyprosessia kuvaavalla esimerkillä kuvattu liiketoimintaprosessin kuvaamista ja sen osioimista. Osiot mahdollistavat aktiviteettikaavion jakamisen korkean tason käsitteisiin. Osioituun kaavioon voi sisällyttää muitakin aktiviteettikaa-

12 vioiden symboleja. Esimerkissä on käytetty tilakaavioista tuttuja alku- ja loppusolmun symboleja. 10 Kuva 7: Aktiviteettikaavio, jossa liiketoimintaprosessit on osioitu Käyttötapauksia voidaan tarkentaa aktiviteettikaavioilla. Tapaustutkimuksessa, jossa tutkittiin käyttöliittymäsuunnitelman tarkentamista aktiviteettikaavioilla, todettiin aktiviteettikaavioiden auttavan käyttötapausten toiminnallisessa määrittelyssä [AlI04]. Tutkimuksessa johdettiin käyttötapausten suhdemäärittelyn perusteella käyttöliittymän toiminnallista määrittelyä varten aktiviteettikaaviot. Aktiviteettikaaviot tarkensivat käyttötapauskaavion kuvausta vaatimusmäärittelyn kannalta silloin, kun tilasiirtymässä kuvattiin oli ehdollisuutta. Tapaustutkimuksessa aktiviteettikaavioihin oli otettu mukaan käyttöliittymän toteuttavat ohjelmistokomponentit tilasiirtymiin liitettyinä stereotyyppeinä.

13 11 4 UML vaatimusten analysoinnissa * * * 5 UML ja toiminnalliset vaatimukset * * * 6 UML ja ei-toiminnalliset vaatimukset * * * 7 Yhteenveto UML-kuvauskielen kaaviotyypeistä erityisesti käyttötapauskaavio on vaatimusmäärittelyn työkalu. Olennaista on kuvata ohjelmistoa monesta eri näkökulmasta, että kaikki ohjelmistoon liittyvät seikat tulevat huomioitua. UML:n tarjoamat kaaviot ovat hyvä visualisoinnin työkalu. UML yhdistettynä hyvään prosessimalliin, jolle löytyy työkalutuki, edesauttaa ohjelmiston vaatimusmäärittelyn toteutumista kaikissa seuraavissa ohjelmistoprosessin vaiheissa. UML:n laajentaminen ja jatkokehitys tarjoaa tulevaisuudessa lisää välineitä entistä laadukkaampien ohjelmistojen tuotantoon.

14 12 Lähteet [AlI04] [Bra02] [DJA01] [EPL04] [Kru95] [Lan02] [Obj07] Almendros-Jiménez J. M., Iribarne L., Describing Use Cases with Activity Charts, LNCS Springer, Vol. 3511, 2005, sivut Bray, Ian K., An Introduction to Requirements Engineering, Addison Wesley Braun D., Sivils J., Shapiro A., Versteegh J. Kennesaw State University, [ ] Eriksson, H., Penker M., Lyons, B., Fado D. UML 2 Toolkit. Wiley Publishing Inc., Kruhten P., The 4+1 View Model of Architecture, IEEE Software JNL, Vol. 12, 1995, sivut Lanman J. Using UML Use Case and Activity Diagrams to Describe Software Requirements. Department of Computer and Mathematics Embry- Riddle Aeronautical University, 25 February Object Management Group,Unified Modeling Language: Infrastructure, version 2.1.1, February 2007 [OMG08] OMG - Object Management Group, Introduction to OMG's Unified Modeling Language. [ ] [Ree02] [SiL04] [ViG06] Reed P., From Developing Applications with Java and UML, Addison-Wesley, 2002, [ ] Siau K., Lee L., Are use case and class diagrams complementary in requirements analysis? An experimental study on use case and class diagrams inuml, Springer, Requirements Engineering, vol. 9, sivut Viljamaa J., Gustafsson J., Ohjelmistotekniikan menetelmät, luentokalvot. [ ]

15 13 [ZoP07] Zou J., Pavlovski C. J., Control case approach to record and model nonfunctional requirements, Springer Information Systems and E-Business Management Journal, Vol. 6, No. 1., 2008.