UML-kaavio

Unified Modeling Language (UML) on yleiskäyttöinen, kehittävä mallinnuskieli ohjelmistotekniikan alalla, jonka tarkoituksena on tarjota standardoitu tapa visualisoida järjestelmän suunnittelu. [1]

UML:n taustalla oli alun perin halu standardoida ohjelmistosuunnittelun erilaiset merkintäjärjestelmät ja lähestymistavat, jotka Grady Booch, Ivar Jacobson ja James Rumbaugh kehittivät Rational Software -yhtiössä vuosina 1994-95. He jatkoivat kehitystyötä vuoteen 1996 asti. [1]

Vuonna 1997 Object Management Group (OMG) hyväksyi UML:n standardiksi, ja se on siitä lähtien hallinnoinut sitä. Vuonna 2005 myös Kansainvälinen standardisoimisjärjestö (ISO) julkaisi Unified Modeling Language -standardin hyväksyttynä ISO-standardina.[2] Siitä lähtien sitä on tarkistettu määräajoin UML:n uusimman version kattamiseksi. [3]

Vaikka UML on tunnettu ja sitä käytetään laajalti koulutuksessa ja akateemisissa julkaisuissa, vuodesta 2013 lähtien sitä on käytetty teollisuudessa vain vähän, ja suurin osa käytöstä on epävirallista ja tilapäistä. [4]

Sisältö

 [piilota] 

  • 1 Historia
    • 1.1 Ennen UML 1.x
    • 1.2 UML 1.x
    • 1.3 UML 2.x
  • 2 Suunnittelu
    • 2.1 Ohjelmistokehitysmenetelmät
    • 2.2 Mallintaminen
  • 3 Kaaviot
    • 3.1 Rakennekaaviot
    • 3.2 Käyttäytymiskaaviot
      • 3.2.1 Vuorovaikutuskaaviot
  • 4 Meta-mallinnus
  • 5 Hyväksyminen
  • 6 Kritiikki
    • 6.1 UML 1.x:n kritiikki

Historia[muokkaa lähdettä | muokkaa]

Oliosuuntautuneiden menetelmien ja merkintätapojen historia

UML on kehittynyt 1990-luvun jälkipuoliskolta lähtien, ja sen juuret ovat 1980-luvun lopulla ja 1990-luvun alussa kehitetyissä oliosuuntautuneissa menetelmissä. Aikajana (ks. kuva) esittää kohokohtia oliopohjaisten mallinnusmenetelmien ja -merkintöjen historiasta.

Se perustuu alun perin Boochin menetelmän, objektimallinnustekniikan (OMT) ja oliopohjaisen ohjelmistotekniikan (OOSE) merkintöihin, jotka se on integroinut yhdeksi kieleksi. [5]

Ennen UML 1.x[muokkaa lähdettä | muokkaa]

Rational Software Corporation palkkasi James Rumbaughin General Electriciltä vuonna 1994, ja sen jälkeen yhtiöstä tuli kahden tämän päivän suosituimman oliosuuntautuneen mallinnusmenetelmän lähde:[6] Rumbaughin Object-modeling technique (OMT) ja Grady Boochin menetelmä. Pian heidän apunaan toimi Ivar Jacobson, joka oli OOSE-menetelmän (Object-oriented software engineering) luoja ja joka liittyi Rationaliin vuonna 1995. [1]

Näiden kolmen (Rumbaugh, Jacobson ja Booch) teknisen johtajan johdolla perustettiin vuonna 1996 konsortio nimeltä UML Partners, jonka tehtävänä oli saada valmiiksi yhtenäistetyn mallinnuskielen (Unified Modeling Language, UML) spesifikaatio ja ehdottaa sitä Object Management Groupille (OMG) standardointia varten. Kumppanuuteen kuului myös muita kiinnostuneita osapuolia (esimerkiksi HP, DEC, IBM ja Microsoft). Konsortio ehdotti UML Partnersin UML 1.0 -luonnosta OMG:lle tammikuussa 1997. Samassa kuussa UML Partners perusti ryhmän, jonka tehtävänä oli määritellä kielikonstruktioiden tarkka merkitys, ja jonka puheenjohtajana toimi Cris Kobryn ja hallinnoijana Ed Eykholt, ja jonka tehtävänä oli viimeistellä spesifikaatio ja integroida se muihin standardointipyrkimyksiin. Tämän työn tulos, UML 1.1, toimitettiin OMG:lle elokuussa 1997, ja OMG hyväksyi sen marraskuussa 1997. [1][7]

UML 1.x[muokkaa lähdettä | muokkaa]

Ensimmäisen julkaisun jälkeen perustettiin[1] työryhmä parantamaan kieltä, joka julkaisi useita pieniä tarkistuksia, 1.3, 1.4 ja 1.5. [8]

Sen tuottamat standardit (samoin kuin alkuperäinen standardi) on todettu epäselviksi ja epäjohdonmukaisiksi. [9][10]

UML 2.x[muokkaa lähdettä | muokkaa]

UML 2.0:n pääversio korvasi vuonna 2005 version 1.5, jota kehitettiin laajennetussa konsortiossa kielen parantamiseksi edelleen sen ominaisuuksien käytöstä saatujen uusien kokemusten perusteella. [11]

Vaikka UML 2.1:tä ei koskaan julkaistu virallisena spesifikaationa, versiot 2.1.1 ja 2.1.2 ilmestyivät vuonna 2007, ja UML 2.2 julkaistiin helmikuussa 2009. UML 2.3 julkaistiin virallisesti toukokuussa 2010.[12] UML 2.4.1 julkaistiin virallisesti elokuussa 2011.[12] UML 2.5 julkaistiin lokakuussa 2012 "In process" -versiona, ja se julkaistiin virallisesti kesäkuussa 2015. [12]

UML 2.x -spesifikaatiossa on neljä osaa:

  1. Päällysrakenne, joka määrittelee kaavioiden ja niiden mallielementtien merkintätavan ja semantiikan.
  2. Infrastruktuuri, joka määrittelee metamallin, johon päällysrakenne perustuu.
  3. Object Constraint Language (OCL) mallin elementtien sääntöjen määrittelyä varten
  4. UML Diagram Interchange, joka määrittelee, miten UML 2 -kaavioiden ulkoasuja vaihdetaan.

Näiden standardien nykyiset versiot ovat seuraavat: UML Superstructure versio 2.4.1, UML Infrastructure versio 2.4.1, OCL versio 2.3.1 ja UML Diagram Interchange versio 1.0.[13] Sitä päivitetään ja parannetaan edelleen tarkistustyöryhmän toimesta, joka ratkaisee kaikki kielen ongelmat. [14]

Suunnittelu[muokkaa lähdettä | muokkaa]

Unified Modeling Language (UML) tarjoaa tavan visualisoida järjestelmän arkkitehtuurisuunnitelmat kaaviossa (ks. kuva), joka sisältää muun muassa seuraavat[5] elementit:

  • Mikä tahansa toiminta (työpaikat)
  • Järjestelmän yksittäiset osat
    • Ja miten ne voivat olla vuorovaikutuksessa muiden ohjelmistokomponenttien kanssa.
  • Miten järjestelmä toimii
  • Miten kokonaisuudet ovat vuorovaikutuksessa toisten kanssa (komponentit ja rajapinnat).
  • Ulkoinen käyttöliittymä

Vaikka yhtenäistetty mallinnuskieli (Unified Modeling Language, UML) oli alun perin tarkoitettu ainoastaan oliosuuntautuneen suunnittelun dokumentointiin, sitä on laajennettu kattamaan laajempi joukko suunnittelun dokumentointia (kuten edellä on lueteltu), [15]ja se on todettu hyödylliseksi monissa yhteyksissä. [16]

Ohjelmistokehitysmenetelmät[muokkaa lähdettä | muokkaa]

UML ei ole itsessään mikään kehitysmenetelmä, [17]mutta se on suunniteltu yhteensopivaksi aikansa johtavien oliosuuntautuneiden ohjelmistokehitysmenetelmien kanssa (esimerkiksiOMT, Boochin menetelmä, Objectory) ja erityisesti RUP:n kanssa, jota sen oli alun perin tarkoitus käyttää, kun työ aloitettiin Rational Software Inc:ssä.

Mallinnus[muokkaa lähdettä | muokkaa]

On tärkeää erottaa toisistaan UML-malli ja järjestelmän kaaviot. Kaavio on järjestelmän mallin osittainen graafinen esitys. Kaavioiden joukon ei tarvitse kattaa mallia kokonaan, eikä kaavion poistaminen muuta mallia. Malli voi sisältää myös dokumentaatiota, joka ohjaa mallin elementtejä ja kaavioita (esimerkiksi kirjalliset käyttötapaukset).

UML-kaaviot edustavat kahta eri näkymää järjestelmämallista: [18]

  • Staattinen (tai rakenteellinen) näkemys: korostaa järjestelmän staattista rakennetta objektien, attribuuttien, operaatioiden ja suhteiden avulla. Rakenteellinen näkymä sisältää luokkakaaviot ja yhdistelmärakennekaaviot.
  • Dynaaminen (tai käyttäytymis-) näkymä: korostaa järjestelmän dynaamista käyttäytymistä näyttämällä objektien välistä yhteistyötä ja objektien sisäisten tilojen muutoksia. Tähän näkymään kuuluvat sekvenssikaaviot, toimintokaaviot ja tilakoneiden kaaviot.

UML-malleja voidaan vaihtaa UML-työkalujen välillä käyttämällä XML Metadata Interchange (XMI) -vaihtoformaattia.

Kaaviot[muokkaa lähdettä | muokkaa]

UML-kaaviot

Rakenteelliset UML-kaaviot

  • Luokkakaavio
  • Komponenttikaavio
  • Yhdistelmärakennekaavio
  • Käyttöönottokaavio
  • Objektikaavio
  • Pakettikaavio
  • Profiilikaavio

Käyttäytymiseen liittyvät UML-kaaviot

  • Toimintakaavio
  • Viestintäkaavio
  • Vuorovaikutuksen yleiskuvauskaavio
  • Järjestyskaavio
  • Tilakaavio
  • Ajoituskaavio
  • Käyttötapauskaavio

UML 2:ssa on monia erilaisia kaaviotyyppejä, jotka jaetaan kahteen luokkaan.[5] Jotkin tyypit esittävät rakenteellista tietoa, ja loput esittävät yleisiä käyttäytymistyyppejä, mukaan lukien muutamat, jotka esittävät vuorovaikutuksen eri näkökohtia. Nämä kaaviot voidaan luokitella hierarkkisesti, kuten seuraavassa luokkakaaviossa[5] esitetään:

Kaikissa kaavioissa voi olla kommentteja tai huomautuksia, joissa selitetään käyttöä, rajoituksia tai tarkoitusta.

Rakennekaaviot[muokkaa lähdettä | muokkaa]

Rakennekaavioissa korostetaan asioita, joiden on oltava läsnä mallinnettavassa järjestelmässä. Koska rakennekaaviot kuvaavat rakennetta, niitä käytetään laajasti ohjelmistojärjestelmien ohjelmistoarkkitehtuurin dokumentoinnissa. Esimerkiksi komponenttikaavio, joka kuvaa, miten ohjelmistojärjestelmä on jaettu komponentteihin, ja osoittaa näiden komponenttien väliset riippuvuudet.

  • Komponenttikaavio
  • Luokkakaavio

Käyttäytymiskaaviot[muokkaa lähdettä | muokkaa]

Käyttäytymiskaavioissa korostetaan, mitä mallinnettavassa järjestelmässä on tapahduttava. Koska käyttäytymiskaaviot havainnollistavat järjestelmän käyttäytymistä, niitä käytetään laajasti ohjelmistojärjestelmien toiminnallisuuden kuvaamiseen. Esimerkkinä toimintakaavio kuvaa järjestelmän komponenttien liiketoiminnalliset ja toiminnalliset vaiheittaiset toiminnot.

  • Toimintakaavio
  • Käyttötapauskaavio

Vuorovaikutuskaaviot[muokkaa lähdettä | muokkaa]

Vuorovaikutuskaavioissa, jotka ovat käyttäytymiskaavioiden alaryhmä, korostetaan mallinnettavan järjestelmän asioiden välistä ohjaus- ja tiedonkulkua. Esimerkiksi sekvenssikaavio, joka osoittaa, miten objektit kommunikoivat toistensa kanssa viestien sekvenssin muodossa.

  • Järjestyskaavio
  • Viestintäkaavio

Metamallinnus[muokkaa lähdettä | muokkaa]

Tärkein artikkeli: Meta-Objekti-väline

Meta-objekti-välineen kuvaus

Object Management Group (OMG) on kehittänyt metamallinnusarkkitehtuurin, jota kutsutaan nimellä Meta-Object Facility (MOF) ja joka määrittelee yhtenäistetyn mallinnuskielen (UML).[19] Meta-Object Facility on suunniteltu nelikerroksiseksi arkkitehtuuriksi, kuten oikealla olevassa kuvassa näkyy. Se tarjoaa meta-metamallin ylimmässä kerroksessa, jota kutsutaan M3-kerrokseksi. Tämä M3-malli on kieli, jota Meta-Object Facility käyttää rakentaessaan metamalleja, joita kutsutaan M2-malleiksi.

Tunnetuin esimerkki kerroksen 2 meta-objektifasiliteetin mallista on UML-metamalli, eli malli, joka kuvaa itse UML:ää. Nämä M2-mallit kuvaavat M1-kerroksen elementtejä ja siten M1-malleja. Näitä olisivat esimerkiksi UML:llä kirjoitetut mallit. Viimeinen kerros on M0-kerros eli datakerros. Sitä käytetään kuvaamaan järjestelmän ajonaikaisia instansseja. [20]

Metamallia voidaan laajentaa käyttämällä mekanismia, jota kutsutaan stereotyypittelyksi. Brian Henderson-Sellers ja Cesar Gonzalez-Perez ovat kritisoineet tätä riittämättömäksi/epäkelvottomaksi artikkelissaan "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0". [21]

Adoptio[muokkaa lähdettä | muokkaa]

UML:n on todettu olevan hyödyllinen monissa suunnittelukonteksteissa, ja[16] siitä on tullut lähes jokapaikan tietotekniikkayhteisössä. [22]

Sitä on toisinaan pidetty suunnittelun ihmelääkkeenä, mikä on johtanut ongelmiin sen käytössä. Väärinkäyttöön kuuluu sen liiallinen käyttö (järjestelmän koodin jokaisen pienen osan suunnittelu sen avulla, mikä on tarpeetonta) ja oletus, että kuka tahansa voi suunnitella sen avulla mitä tahansa (jopa ne, jotka eivät ole ohjelmoineet). [23]

Se on suuri kieli, jossa on monia konstruktioita. Joidenkin mielestä (myös Jacobsonin mielestä) niitä on liikaa, mikä haittaa sen oppimista (ja siten käyttöä). [24]

Kritiikki[muokkaa lähdettä | muokkaa]

Tämän artikkelin Criticism or Controversy -osio saattaa vaarantaa artikkelin neutraalin näkökulman aiheeseen. Ole hyvä ja yhdistä jakson sisältö koko artikkeliin tai kirjoita aineisto uudelleen. (Joulukuu 2010)

UML:ää kritisoidaan yleisesti teollisuudessa muun[4] muassa seuraavasti:

  • ei ole hyödyllistä: "[ei] tarjoa heille etuja nykyisiin, kehittyneisiin käytäntöihin ja esitystapoihin nähden."
  • liian monimutkainen, erityisesti asiakkaiden kanssa käytävässä viestinnässä: "tarpeettoman monimutkainen" ja "Paras syy olla käyttämättä UML:ää on se, että se ei ole kaikkien sidosryhmien luettavissa". Kuinka paljon UML on arvokas, jos liiketoimintakäyttäjä (asiakas) ei ymmärrä mallintamisponnistelujenne tulosta."
  • UML:n ja koodin on oltava synkronissa, kuten dokumentaatiossa yleensä

UML 1.x:n kritiikki[muokkaa lähdettä | muokkaa]

Kardinaalisuuden merkintätapa

Kuten Chenin, Bachmanin ja ISO ER-kaavioissa, luokkamalleissa käytetään "look-across"-kardinaliteetteja, vaikka useat kirjoittajat (muun[27] muassa Merise, [25]Elmasri ja Navathe[26]) suosivat rooleille "look-here"-kardinaliteetteja sekä minimi- että maksimikardinaliteetteja. Viimeaikaiset tutkijat (Feinerer, [28]Dullea ym[29].) ovat osoittaneet, että UML- ja ER-kaavioissa käytetty "look-across"-tekniikka ei ole yhtä tehokas ja johdonmukainen, kun sitä sovelletaan n-alkuisiin suhteisiin, joiden järjestys on >2.

Feinerer sanoo: "Ongelmia syntyy, jos käytämme UML:n assosiaatioiden yhteydessä käytettyä look-across-semantiikkaa. Hartmann [30]tutkii tätä tilannetta ja osoittaa, miten ja miksi erilaiset muunnokset epäonnistuvat." (Tosin mainittu "reduktio" on näennäistä, koska kaksi kaaviota 3.4 ja 3.5 ovat itse asiassa samat) ja myös "Kuten näemme seuraavilla sivuilla, look-across-tulkinta tuo mukanaan useita vaikeuksia, jotka estävät yksinkertaisten mekanismien laajentamisen binäärisistä assosiaatioista n-earisiin assosiaatioihin.""

Kysymyksiä ja vastauksia

K: Mikä on yhtenäistetty mallinnuskieli (UML)?


V: Unified Modeling Language (UML) on ohjelmistotekniikassa käytetty mallinnuskieli, joka tarjoaa standardoidun tavan näyttää, miltä järjestelmän suunnittelu näyttää.

K: Mikä oli UML:n alkuperäinen tarkoitus?


V: UML:n alkuperäisenä tarkoituksena oli standardoida erilaisia merkintäjärjestelmiä ja lähestymistapoja ohjelmistosuunnitteluun.

K: Kuka kehitti UML:n?


V: Grady Booch, Ivar Jacobson ja James Rumbaugh kehittivät UML:n Rational Software -yhtiössä vuosina 1994-1995 ja jatkokehittivät sitä heidän johdollaan vuoteen 1996 asti.

K: Milloin UML hyväksyttiin standardiksi?


V: Object Management Group (OMG) hyväksyi UML:n standardiksi vuonna 1997.

K: Kuka hallinnoi UML:ää?


V: Object Management Group on hallinnoinut UML:ää siitä lähtien, kun se hyväksyttiin standardiksi vuonna 1997.

K: Onko UML tunnustettu kansainväliseksi standardiksi?


V: Kyllä, Kansainvälinen standardisoimisjärjestö (ISO) tunnusti UML:n kansainväliseksi standardiksi vuonna 2005.

K: Mikä on UML:n tarkoitus ohjelmistotekniikassa?


V: UML:n tarkoitus ohjelmistosuunnittelussa on tarjota standardoitu tapa näyttää, miltä järjestelmän suunnittelu näyttää, jotta se on helposti ymmärrettävissä ja kommunikoitavissa kehittäjien ja sidosryhmien kesken.

AlegsaOnline.com - 2020 / 2023 - License CC3