Seminaariesitelmä 26.9.2000 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Sisällys 1 Johdanto 1 2 UML:n perusteet 2 2.1 Kaaviot 2 2.1.1 Yleiskäsitteet ja käyttötapauskaavio 2 2.1.2 Luokkakaavio 3 2.1.3 Tilasiirtymäkaavio 4 2.1.4 Vuorovaikutuskaaviot 4 2.1.5 Toteutustason kaaviot 5 2.2 Kattavuus 5 3 UML metamallina 6 3.1 Arkkitehtuuri 6 3.2 Miten metamalli määritellään? 8 3.2.1 Esimerkki pakkauksen määritelmästä 8 3.3 Miten metamallia voi hyödyntää? 10 3.3.1 Stereotyypit eli lajit 10 3.3 Metamallin ongelmat 11 4 Lähteet 13
1 Johdanto Unified Modeling Language (UML) on kuvauskieli, jota voidaan käyttää apuvälineenä erityisesti komponentti- ja olioperustaisen ohjelmistotuotannon eri vaiheissa. Sen kehittivät Grady Booch, Ivar Jacobson ja Jim Rumbaugh Rational Software -yhtiössä. Kehittäjien tavoitteena oli luoda helppokäyttöinen ja tehokas visuaalinen kuvauskieli, joka tukee erilaisten korkean tason ratkaisujen, kuten suunnittelumallien ja komponenttien käyttöä. Kielen haluttiin olevan myös laajennettavissa ja erikoistettavissa, mikäli se on tarpeen jonkin erikoisalan ratkaisujen kuvaamisessa. Kehityksen perustana käytettiin erityisesti erilaisia oliomenetelmiä (object oriented methods), mutta myös olioihin perustumattomilla menetelmillä (non-oo influences) ovat vaikuttaneet UML:ään. UML:ssä käytetään kaavioita suunnitteluongelmien esittämiseen ja ratkaisujen kuvaamiseen. Määrittelyvaiheessa selvitetään asiakkaan vaatimuksia ja esitellään suunnitelmia esimerkiksi käyttötapauskaavioiden avulla. Suunnittelu- ja toteutusvaiheessa ohjelmiston ja sen osien loogista rakennetta ja kontrollin kulkua kuvataan vaikkapa luokka- ja sekvenssikaavioilla. Järjestelmän dokumentaatiossa kaaviot auttavat kokonaiskuvan hahmottamisessa. Kaavioiden avulla luodaan myös erilaisia näkymiä järjestelmään 4+1"-mallin mukaisesti [Kru95]. 1
2 UML:n perusteet UML tarjoaa kuvaustekniikoita ohjelmistotuotteiden määrittelyyn (VSHFLI\LQJ), visualisointiin (YLVXDOL]LQJ), rakentamiseen (FRQVWUXFWLQJ) ja dokumentointiin (GRFXPHQWLQJ). Määrittelyn apuvälineenä kaaviot kertovat havainnollisesti, mitä järjestelmältä vaaditaan ja miten se pitäisi toteuttaa. Suunnitteluvaiheessa esitetään erilaisin kaavioin järjestelmän kokonaisrakenne ja tärkeät yksityiskohdat. Näin ratkaisut säilyvät tallessa ja niihin voidaan palata tai vedota myöhemmin suunnitteluvaiheessa. Määrittely-, suunnittelu- ja toteutusvaiheen ratkaisuja kuvaavat kaaviot on hyvä sisällyttää järjestelmän dokumentaatioon, siten saadaan jatkokehityksen ja ylläpidon kannalta arvokasta tietoa järjestelmän elinkaaresta [Sia98a]. 2.1 Kaaviot Perus-UML tarjoaa paljon kaaviotyyppejä eri tarkoituksiin [Rat00]. Järjestelmän käyttötapauksia kuvataan käyttötapauskaaviolla. Loogista rakennetta kuvataan luokkakaavioilla ja kontrollin kulun kuvaamiseen käytetään tilasiirtymä- ja sekvenssikaavioita. Komponenttijakoa ja laitteistosijoittelua kuvataan komponentti- ja laitteistotkaavioin. Yleiskatsauksen eri osapuolten välisestä yhteistyöstä saa yhteistyökaaviosta. 2.1.1 Yleiskäsitteet ja käyttötapauskaavio Yleiskäsitteitä (General purpose concepts) ovat pakkaus (package), ja riippuvuussuhteen selitys (dependency note). Niitä kuvaavia symboleja voidaan käyttää kaikissa kaavioissa. Käyttötapauskaavion (Use-case diagram, kuva 2.1) avulla esitetään ja tarkennetaan käyttäjien ja ohjelman välista vuorovaikutusta ohjelmistosuunnittelun alkuvaiheessa. Käyttötapauskaavioon liittyviä käsitteitä ovat toimija (actor), käyttötapaus (use case) ja yhteys (association). 2
2.1.2 Luokkakaavio Erityisesti suunnittelu- ja toteutusvaiheessa on hyötyä järjestelmän loogista rakennetta - luokkia ja niiden välisiä suhteita - kuvaavista luokkakaavioista (Class diagram, kuva 2.2). Luokkakaavioon liittyviä käsitteitä ovat mm. Luokka, Rajoitteet, Ominaisuudet tai Yleistys/Erikoistus Kuva 2-2 Luokkakaavio 3
2.1.3 Tilasiirtymäkaavio Tilasiirtymäkaavio (State transition diagram ) (kuva 2.3) perustuu David Harelin kehittämään kuvaustekniikkaan. Kaaviossa näkyvät järjestelmän mahdolliset tilat, tapahtumat jotka aiheuttavat siirtymisen tilasta toiseen ja tilasiirtymän seurauksena tapahtuvat tapahtumat. Kuva 2-3 Tilasiirtymäkaavio 2.1.4 Vuorovaikutuskaaviot Sekvenssikaavio (Sequence diagram) ja yhteistyökaavio (Collaboratin diagram) havainnollistavat järjestelmän olioiden vuorovaikutusta (kuva 2.4). Kuva 2-4 Vuorovaikutuskaavio 4
2.1.5 Toteustutason kaaviot Toteutusta kuvaavat komponentti- ja laitekaaviot (component and deployment diagrams) (kuva 2.5). Komponenttikaavio kuvaa komponenttien välisiä riippuvuuksia ja deploymentkaavio kuvaa ajonaikaisten elementtien konfiguraatiota. Nämä kaaviot ovat erityisen hyödyllisiä ohjelmiston ylläpidettävyyden ja jatkokehityksen kannalta. Kuva 2-5 Toteutustason kaaviot 2.2 Kattavuus (Scope of UML) UML on työväline, jota käyttäen ohjelmistotuotteeseen liittyvää tietoa voidaan esittää kuvallisesti. Kuvallinen esitys on usein helpommin hahmotettavissa kuin pelkkään tekstiin perustuva, joten UML-kaavioita voidaan käyttää esimerkiksi tiedon välitykseen ohjelmiston tuottajalta asiakkaalle ja ohjelmoijalta toiselle, sekä apuna järjestelmän suunnittelussa ja ongelmien ratkaisemisessa. UML ei ole visuaalinen ohjelmointikieli vaan visuaalinen kuvauskieli. Vaikka sitä voidaan käyttää apuna suunnitteluongelmien ratkaisemisessa, se ei itsessään ole mikään ongelmanratkaisuväline [Sia98b]. 5
3 UML metamallina Koska UML on kieli, vaikkakin kuvallinen, sillä on semantiikka ja kielioppi (syntaksi) niinkuin kaikilla kielillä. UML:n semantiikka ja syntaksin kuvaillaan sen metamallissa. Siinä määritellään kaikki UML:n käsitteet ja kuvataan niiden väliset suhteet UML:n omalla luokkakaavionotaatiolla. UML on siis osaksi määritelty itsellään! Metamalli toimii perustana erilaisille UML:ää tukeville työkaluille. Työkalun on mahdollistettava tiettyjen standardielementtien käyttö, mutta siinä voi olla myös metamallia laajentamalla aikaansaatuja uusia elementtejä [Kos97]. 3.1 Arkkitehtuuri UML:n arkkitehtuuri perustuu neljän tason metamalliin (four-layer metamodel structure). Ylimmällä tasolla on meta-metamalli (meta-metamodel), seuraavalla metamalli (metamodel), sitten malli (model) ja alimpana, konkreettisimpana, käyttäjän objektit (user objects). Esimerkiksi metamallin Luokka on metametamallin MetaLuokan ilmentymä. UML-määritelmässä sanaa metamalli käytetään hieman häiritsevästi sekä koko neljän tason arkkitehtonisesta kokonaisuudesta, että yhdestä sen tasoista. Taulukko 3.1 Neljän tason metamallinnusarkkitehtuuri (metamodelling arch.) Taso Kuvaus Esimerkki PHWDPHWDPDOOL 0HWDPDOOL 0DOOL.l\WWlMlREMHNWLWXVHUGDWD 0HWDPDOOLUDNHQWHHQSHUXVWD.XYDDNLHOHQMROODPHWDPDOOL PllULWHOOllQ 0HWDPHWDPDOOLQLOPHQW\Pl.XYDDNLHOHQMROODPDOOL PllULWHOOllQ 0HWDPDOOLQLOPHQW\Pl.XYDD NLHOHQMROODVRYHOOXVDOD LQIRUPDWLRQGRPDLQ NXYDLOODDQ 0DOOLQLOPHQW\Pl.XYDD VRYHOOXVDOXHHQ 0HWD&ODVVV0HWD$WWULEXWH 0HWD2SHUDWLRQ &ODVVV$WWULEXWH2SHUDWLRQ &RPSRQHQW 6WRFN6KDUHDVN3ULFH 6HOO/LPLW2UGHU 6WRFN4XRWH6HUYHU $FPHB6:B6KDUHB! VHOOBOLPLWBRUGHU 6
Neljän tason metamalli kuvaa vain UML:n loogisen rakenteen. Olioparadigman mukaisesti metamalli määrittelee rajapinnan, jota toteutuksen pitää vastata. Fyysinen rakenne ja toteutus siis piilotetaan. Koska toteutuksesta ei anneta tarkkaa kuvausta, saattavat eri ohjelmistoyrittäjien UML-kaavionpiirto-ohjelmat olla suorituskyvyltään hyvinkin erilaisia. Myöskään symbolien ulkoasuun ei puututa metamallin määritelmässä vaan ne kuvataan erikseen UML:n määritelmässä (UML Notation Guide)[OMG99]. Myös metamallitaso on jaettu loogisiin kokonaisuuksiin. Pakkauksia on kolme: Foundation, Behavioral Elements ja Model Management (kuva 3.1), jotka vuorostaan on jaettu pakkauksiin tarpeen mukaan. Esimerkiksi Foundation sisältää Core-, Extension Mechanisms- ja Data Types -pakkaukset (kuva 3.2). Kuva 3-1 Metamallitason pakkaukset Kuva 3-2 Foundation-pakkauksen alipakkaukset 7
3.2 Miten metamalli määritellään? UML:n metamallin virallinen määritelmä löytyy Rational Softwaren WWWsivuilta. Kielioppi kuvataan UML-kaaviolla, muotosäännöt ja semantiikka luonnolisella tai formaalilla kielellä. Taulukko 3.2 Metamallin määritelmän osat Määritelmän osa Abstrakti kielioppi (Abstract Syntax) Muotosäännöt (Well-Formedness Rules) Semantiikka (Semantics) Vakioelementit (Standard Elements) Huomautukset (Notes) Tarkoitus UML-notaatiolla tehty luokkakaavio Sanallinen tai formaalikielinen (Object Constrant Language) kuvaus UMLmetaluokkien pysyvistä (static) ominaisuuksista. Sanallinen selitys rakenteiden merkityksestä. Aiemmin samassa osassa määriteltyjen metaluokkien stereotyyppien kuvaukset, mahdollisesti muotosääntöineen. Sanallinen selitys esimerkiksi metamallin ratkaisujen syistä tai käytännön neuvoja tai esimerkkejä. 3.2.1 Esimerkki pakkauksen määritelmästä Esimerkkinä metamallin määritelmästä esitetään alku Extension Mechanisms - pakkauksen määritelmästä. Määritelmä on otettu suoraan UMLspesifikaatiosta[OMG99]. $EVWUDFW6\QWD[ 8
&RQVWUDLQW 7KHFRQVWUDLQWFRQFHSWDOORZVQHZVHPDQWLFVWREHVSHFLILHGOLQJXLVWLFDOO\IRUD PRGHOHOHPHQW... $WWULEXWHV ERG\ $ERROHDQH[SUHVVLRQGHILQLQJWKHFRQVWUDLQW([SUHVVLRQVDUH ZULWWHQDVVWULQJVLQDGHVLJQDWHGODQJXDJH)RUWKHPRGHOWREH ZHOOIRUPHGWKHH[SUHVVLRQPXVWDOZD\V\LHOGDWUXHYDOXHZKHQ HYDOXDWHGIRULQVWDQFHVRIWKHFRQVWUDLQHGHOHPHQWVDWDQ\WLPH ZKHQWKHV\VWHPLVVWDEOHLHQRWGXULQJWKHH[HFXWLRQRIDQ DWRPLFRSHUDWLRQ $VVRFLDWLRQV FRQVWUDLQHG(OHPHQW$QRUGHUHGOLVWRIHOHPHQWVVXEMHFWWRWKHFRQVWUDLQW7KH FRQVWUDLQWDSSOLHVWRWKHLULQVWDQFHV,IWKHHOHPHQWLVDVWHUHRW\SH WKHQWKHFRQVWUDLQWDSSOLHVWRWKHHOHPHQWVFODVVLILHGXVLQJLW :HOO)RUPHGQHVV5XOHV 7KHIROORZLQJZHOOIRUPHGQHVVUXOHVDSSO\WRWKH([WHQVLRQ0HFKDQLVPV SDFNDJH &RQVWUDLQW... >@$&RQVWUDLQWDWWDFKHGWRD6WHUHRW\SHPXVWQRWFRQIOLFWZLWK &RQVWUDLQWVRQDQ\LQKHULWHG6WHUHRW\SHRUDVVRFLDWHGZLWKWKH EDVH&ODVV -- cannot be specified with OCL >@$&RQVWUDLQWDWWDFKHGWRDVWHUHRW\SHG0RGHO(OHPHQWPXVWQRW FRQIOLFWZLWKDQ\FRQVWUDLQWVRQWKHDWWDFKHGFODVVLI\LQJ6WHUHRW\SH QRUZLWKWKH&ODVVWKH EDVH&ODVVRIWKH0RGHO(OHPHQW -- cannot be specified with OCL >@$&RQVWUDLQWDWWDFKHGWRD6WHUHRW\SHZLOODSSO\WRDOO 0RGHO(OHPHQWVFODVVLILHGE\WKDW6WHUHRW\SHDQGPXVWQRWFRQIOLFWZLWK DQ\FRQVWUDLQWVRQWKHDWWDFKHGFODVVLI\LQJ6WHUHRW\SHQRUZLWKWKH &ODVVWKHEDVH&ODVVRIWKH0RGHO(OHPHQW -- cannot be specified with OCL 9
3.3 Miten metamallia voi hyödyntää? Vaikka UML:n peruskaaviot ovatkin hyvin ilmaisuvoimaisia ja yleiskäyttöisiä, toisinaan sovellusalan mukaiseksi räätälöity kaavio olisi tarpeen. Miten tämä onnistuisi? UML:ä voi laajentaa ja räätälöidä valmiiden laajennusmenetelmien (extension mechanisms) avulla. Laajennusmenetelmiä ovat stereotyyppien määrittely, metamallin elementin ominaisuuksien muuttaminen, rajoitteiden määrittely ja avainsana-arvo parien (tagged values) määrittely. Näillä keinoin saa lisättyä uudentyyppisiä elementtijä UML-kaavioon tai muutettua olemassa olevien elementtien ominaisuuksia paremmin sovellusalaa vastaaviksi. Laajennuksia tehdessä täytyy kuitenkin muistaa, etteivät ne enää ole yhtä laajalti tunnistettuja ja ymmärrettyjä kuin perus-uml. 3.3.1 Stereotyypit eli lajit Jokaiseen kaavion yksittäiseen elementtiin (model element) voidaan liittää sen laji (stereotype). Laji ilmoittaa elementin metaluokan, siis sen luokan, jonka ilmentymä kyseinen elementti on kaavion metamallissa (mallissa, joka kuvaa itse kaavion). Perusnotaatioon kuuluu kokoelma lajeja, mutta lajeja voidaan myös lisätä valmiita elementtityyppejä laajentamalla [Kos97]. Elementtejä voidaan jaotella (classify) niiden lajien perusteella. Yleisen luokan eri lajeje voisivat esimerkiksi olla interface, controller tai metaclass [Kos97]. Elementtiä voidaan laajentaa määrittelemällä sille uusia ominaisuuksia (properties), rajoitteita (constraints) tai avain-arvopareja (tagged values). Uudella elementtilajilla on henkilökohtaisten ominaisuuksiensa lisäksi myös lajityypilliset ominaisuudet. Niiden avulla UML-työkalu osaa käsitellä myös laajennettua elementtiä. Alkuperäinen laji näytetään kaksoiskulmasulkujen <<>> 10
sisällä luokkalaatikossa. Uudella lajilla saattaa olla myös oma kuvallinen esitysmuoto. Kuva 3-2 Luokan symboli Kehitystyön tavoitteena on ollut, että laajentaminen onnistuu ilman lisäyksiä tai muutoksia metamalliin. Toisaalta, laajennuksia voi tehdä myös metamallia muokkaamalla. Tällä hetkellä UML:ssä on kaksi valmista laajennosta, Objectory Process ja Business Engineering. 3.4 Metamallin ongelmat UML määrittelee seuraavat säännöt laajennusmekanismien käyttöön liittyen. Elementti (Model Element) on nimetty abstraktio mallinnuksen kohteena olevan järjestelmän osasta. Kattaa kaikki metaluokat. Luokittelija (Classifier) on elementti, joka kuvaa käyttäytymistä (behavioral) tai rakennetta (structural features). Luokittelija kattaa siis esimerkiksi mallitason luokat, tietotyypit ja rajapinnat. Ilmentymä (Instance) on elementti, jolla on tila ja tilan muuttamiseen käytettäviä operaatioita. Kaikki käyttäjän tason oliot ovat ilmentymiä ylemmän tason luokista. Elementti Lajisääntö: Elementti voidaan liittää korkeintaan yhteen Lajiin. Laji voidaan liittää nollaan tai useampaan elementtiin. Luokittelija - Ilmentymäsääntö: Ilmentymä saa liittyä yhteen tai useampaan luokittelijaan. Luokittelija voi liittyä nollaan tai useampaan ilmentymään. Luokittelija Ilmentymä Laji sääntö: Ilmentymällä täytyy olla sama Laji kuin sen luokittelijalla. Ilmentymän ei kuitenkaantarvitse visuaalisesti näyttää lajiaan. Luokittelijanotaatiosääntö: Luokittelija-käsitteen (luokan) ilmentymä 11
(objekti) kuvataan symbolina, jolla voi olla nimi (merkkijono), joka on alleviivattu. Luokittelijasuhteen (Classifier association) ilmentymä (link) kuvataan viivana, jolla voi olla nimi. Yhteys saattaa myös näyttää osapuolten nimet, jolloin ne pitää alleviivata. Lajin kuvaussääntö: (concept) Luokan tai olion laji kuvataan symbolilla, jossa käsitteen nimi on kaksoiskulmasulkujen sisällä << Nimi >>. Samoin suhteen laji nimi on kulmasulkeiden sisällä. Metamallissa on kuitenkin muutamia virheitä ja ristiriitoja, jotka ilmenevät edellä esiteltyjen laajennussääntöjen yhteydessä [Sia99]. Luokittelija Ilmentymä Lajisääntö on ongelmallinen, sillä säännön mukaisesti olioiden lajit eivät välttämättä näy kaavioista. Ongelma ratkeaisi sallimalla ilmentymien piirtää lajinsa näkyviin. Elementti Laji -sääntö ja Luokittelija Ilmentymäsääntö ovat ristiriitaiset. Jälkimmäinen sääntö sanoo, etttä Ilmentymä voi liittyä yhteen tai useampaan Luokittelijaan, joten Ilmentymällä voi sen takia olla nolla tai enemmän lajeja (yksi per Luokittelija). Toisaalta ensimmäinen sääntö sanoo, että elementtiin voi liittyä yksi tai ei-yhtään lajia. Kun kerran Ilmentymä on elementti, sillä ei saisi olla kuin korkeintaan yksi laji, mutta toisaalta sillä saa olla useampikin, koska se saa jälkimmäisen säännön mukaan liiittyä usempaan Luokittelijaan. Luokittelijanotaatio- ja lajinotaatiosäännöt ovat epäyhtenevät: Käsitteen (concept) laji ja suhteen laji kuvataan kulmasulkeilla täsmälleen samoin. Käsitteen luokittelu (classification) ja suhteen luokittelu (classification) kuvataan kuitenkin eri tavoin (mokkula ja viiva). Koska uusien lajien muodostaminen (stereotyping) ja luokittelu ovat kumpikin ilmentymänteon (instantiating) muotoja, ne pitäisi piirtää jollain yhtenäisemmällä tavalla. 12
4 Lähteet Kru95 Kruchten P.,B.: The 4+1 View Model of Architecture, IEEE Software, Nov 1995, pp 42-50. Sia98a Si Allhir, S. What is the Unified Modelling language (UML)? http://home.earthlink.net/~salhir/whatistheuml.html Rat00 Rational Software Corporation, Quick Reference for Rational Rose KWWSZZZUDWLRQDOFRPXPOUHVRXUFHVTXLFNXPOBSRVWHUMVS Sia98b Si Alhir, S., Applying the Unified Modeling Language (UML), http://home.earthlink.net/~salhir/applyingtheuml.html OMG99 OMG Unified Modeling Language Specification http://www.cs.helsinki.fi/u/laine/99-06-08.pdf Kos97 Koskimies, K. Pieni oliokirja, Suomen atk-kustannus, Espoo, Suomi Sia99 Si Alhir, S. Extending the Unified Modeling Language (UML) http://home.earthlink.net/~salhir/extendingtheuml.html 13