Luokat
Luokka esitetään "laatikkona", jonka sisään on kirjoitettu vähintään luokan nimi. Jos kaaviosta halutaan yksityiskohtaisempi, myös luokan attribuutit (muuttujat) ja operaatiot (metodit) kirjoitetaan näkyviin (omiin osioihinsa). Varhaisessa luonnosteluvaiheessa on usein mukavampaa ja nopeampaa käyttää pelkkää luokan nimeä, kun piirrokset elävät ja muuttuvat koko ajan.
Attribuuteista voidaan kertoa tyyppi ja tarvittaessa alkuarvo. Metodeista ilmoitetaan tarvittaessa parametrilista ja (paluuarvon) tyyppi. Luokkamuuttujat ja -metodit eli staattiset piirteet (static) merkitään "$muuttuja". Abstraktin luokan nimen yhteyteen merkitään "{abstract}".
Periaatteessahan kaavion ei pidä olla riippuvainen valittavasta toteutuskielestä, mutta jos jo suunnitteluvaiheessa tiedät kielen (esim. a-laboratoriossa Java), metodit ja muuttujat voi kyllä esitellä kielen syntaksin mukaan.
Luokkien väliset suhteet (assosiaatiot)
Ohjelmassa luokat kutsuvat toistensa metodeita, eli ovat jossain tietyssä suhteessa toisiin luokkiin. Nämä suhteet eli assosiaatiot piirretään näkyviin luokkien välille. Jos esim. luokilla Auto ja Henkilö on jokin suhde (esim. "henkilö ajaa autoa" tai "henkilö omistaa auton"), niiden välille piirretään viiva.
Assosiaatiot ovat aina luokkien välisiä kytkentöjä, siis "kaksisuuntaisia" riippuvuussuhteita, eivätkä käsitteenä kuulu varsinaisesti kumpaankaan luokkaan. Niitä ei pidä tulkita pelkästään yksisuuntaisina viitteinä luokasta toiseen luokkaan (olioviitteinä, C/C++-osoittimina tms.). Assosiaatioita ei siis saa piilottaa esim. luokan attribuuteiksi (vaikka ne toteutusvaiheessa yleensä koodataankin olioviitteillä (Java) tai osoittimilla (C++ yms.)). Se hävittäisi olennaista tietoa assosiaation luonteesta.
Assosiaatio on nimettävä, ellei se ole aivan ilmeinen asiayhteydestä (ei yleensä ole!). Suhde on siis nimettävä mahdollisimman informatiivisesti, usein jokin tavallinen verbi on paras. Jo suhteen olemassaoloa ja tarvetta miettiessä tulee usein esille sopivia sanoja (esim. "henkilö omistaa auton" -> "omistaa"). Suhteen nimi luetaan usein "yhteen suuntaan", vaikka suhde onkin kaksisuuntainen ("omistaa", "työskentelee"). Suunnan saa valita vapaasti, sehän vaikuttaa lähinnä sopivan nimen valintaan. OMT:n "parannetussa painoksessa", UML-mallissa (Unified Modeling Language), lukusuuntaa voi merkitä pienellä nuolella nimen yhteydessä, tämä on kätevä tapa.
Suhteen osapuolille on myös annettava jokin kuvaava rooli assosiaatiossa. Esim. luokan Henkilö roolia työsuhteessa kuvannee hyvin "työntekijä" ja luokan Yritys roolia vastaavasti "työnantaja" (Muista myös mitä luokkien nimeämisestä sanotaan tämän ohjeen yleisosassa: luokan nimeksi ei pidä antaa vain yhden näkökulman mukaista "roolia" => siksi luokan nimeksi annetaan jokin yleisempi ja kattavampi. Suhteen roolinimiä puolestaan käytetään jonkin tietyn näkökulman kuvaamiseen). Joskus harvoin koko suhde voi olla jo asiayhteydestä selvä, jolloin erillisiä roolinimiäkään ei ehkä tarvita, tällöin luokkien nimet jo määrittelevät roolit.
Aliluokat ja periytyminen
Luokalla ja sen aliluokilla on myös eräänlainen assosiaatio - perimyssuhde. Perimishierarkia piirretään näkyviin pienellä kolmiolla keskellä assosiaatiota, jonka kärki osoittaa kohti yliluokkaa. Kolmion kannasta haarautuu jokaiseen aliluokkaan oma viivansa. Yhteyttä ei nimetä, kolmio kertoo mistä on kyse.
Yhden suhde moneen, monen suhde moneen
Suhteen kertautuminen (multiplicity)
Tosielämässä tilanne, jossa luokan X ilmentymällä on suhde täsmälleen
yhteen luokan Y ilmentymään, on oikeastaan melko harvinainen. Useammin
on kyseessä yhden suhde moneen (1-N -suhde), siis yhtä X:n ilmentymää
kohden on useampia Y-ilmentymiä. Esim. opettajalla on tyypillisesti
useita oppilaita, eikä vain yhtä. Geometriseen kuvioon kuuluu useita
pisteitä. Lähes yhtä usein on kyseessä monen suhde moneen (M-N -suhde).
Opettajaesimerkkiä jatkaen: oppilaalla voi lisäksi olla monta opettajaa.
Tai:
"Kaupassa myydään useaa tuotetta, ja samaa tuotetta myydään useassa
kaupassa."
Vielä useammin on kyse vapaaehtoisesta suhteesta (0-N -suhde tai 0-1 -suhde), siis X:llä ei välttämättä ole tietyllä ajanhetkellä suhdetta yhteenkään Y:hyn. Opettajalla ei välttämättä ole oppilaita koko ajan, esim. virkavapauden aikana.
OMT:ssä suhteen "moninkertaiseen" päähän merkataan kertautumisen lukumäärä. Perusmerkintätapa on kirjoittaa lukumäärä tai lukuväli assosiaation päähän, luokkalaatikon kylkeen, esim. "1-20" tai "1+". Seuraavat tapaukset ovat niin yleisiä, että niille on omat erikoismerkkinsä: "0-N kpl" merkitään mustalla pallolla ja "0-1 kpl" tyhjällä pallolla.
Kertautuminen on eräs tärkeimpiä assosiaatioiden ominaisuuksia, ja väärin valittu kertautuminen voi kostautua myöhemmin. Esim. jos puhelinmuistio-ohjelma on suunniteltu yhdistämään jokaiseen henkilöön täsmälleen yksi puhelinnumero, se ei tällöin ota lainkaan huomioon matkapuhelimia jne. Kertautuminen kannattaakin jättää alkuvaiheessa avoimeksi ja kiinnittää vasta suunnitelmien vakauduttua hieman.
Assosiaatioiden ominaisuudet
Myös assosiaatiolla voi olla attribuutteja, aivan kuten luokillakin. Esimerkiksi Henkilön ja Yrityksen suhde "työskentelee" voisi sisältää attribuutteja kuten "virkanimike", "palkka", "työsuhteen alkamispv". Nämä eivät ole kummankaan luokan ominaisuuksia, vaan selkeästi assosiaation omia. Assosiaatiolla voi olla myös sille ominaisia metodeja, edellistä esimerkkiä jatkaen "anna palkankorotus(summa)", "laske ikälisä" jne.
Vähintäänkin nämä piirteet pitää kirjata assosiaatioon, eikä piilottaa toisiin luokkiin. Assosiaatiosta voi usein tehdä oman luokkansa ja antaa sille saman nimen kuin suhteella olisi ("Työskentelee" - tai ehkä "Työsuhde" olisi parempi?). Tällöin kaikki assosiaatioon liittyvä tieto on helppo koota ko. luokkaan ja sen palveluihin.
Luokan yhteys itseensä
Luokan ilmentymillä voi useinkin olla assosiaatioita toisiin saman luokan ilmentymiin. Esim. Henkilö-luokkaan voi kuulua sekä työntekijöitä että heidän esimiehiään, jotka itsekin ovat samalla työntekijöitä. Tällöin roolien merkkaus on erityisen tärkeää.
Järjestetty assosiaatio (ordering)
Yleensä kertautuvan suhteen "moninkertaisella" puolella on vain järjestämätön joukko olioita. Jos ne kuitenkin ovat järjestyksessä, merkitään assosiaation kertautuvaan päähän "{ordered}". Järjestys on tällöin suhteen oleellinen ja kiinteä osa, esim."Kilpailijat ovat Tulostaulussa pisteidensä mukaisessa järjestyksessä".
Jos järjestys perustuu indeksinumeroon, käytetään merkintää {indexed},
esim.
"Monikulmio koostuu kolmesta tai useammasta pisteestä, jotka
liitetään toisiinsa tietyssä järjestyksessä".
Kvalifikaatio (qualification)
Moninkertaiset suhteet (1-N, M-N) ovat usein hankalia hahmottaa - ja toteuttaa. Moninkertaisuuden astetta voi pienentää käyttämällä kvalifiointia (qualifier), eli assosiaation luokittelua. Kvalifiointi "lokeroi" suhteen kertautuvassa päässä olevat oliot jonkin ominaisuuden suhteen. Usein kvalifioijaksi sopii sellainen ominaisuus, jota on suunniteltu eroteltavan olion attribuutiksi. Kvalifiointi kirjoitetaan pieneen laatikkoon suhteen siihen päähän, jossa luokittelua halutaan tehdä (siis vastapäätä luokiteltavaa oliota!). Huomaa, että kvalifiointi ei muuta sen pään kertautumista, johon se piirretään, ainoastaan sen pään, jota lokeroidaan!
Esimerkki 1:
"Hakemistossa on monta tiedostoa". Totta, mutta
informatiivisempaa olisi sanoa esim. "Hakemisto ja tiedostonimi yhdessä
määrittelevät yksikäsitteisesti tiedoston". Tiedostonimi toimii
tiedostojen erottelijana. Tiedostonimi on siis tiedoston attribuutti,
joka samalla on sen tunnistetieto. Tiedosto-luokalle voi ottaa
myös nimi-attribuutin, se ei sulje pois sen käyttöä kvalifioinnissa.
Esimerkki 2:
"Tuotetta myydään monessa tavaratalossa ja tavaratalossa
myydään useaa tuotetta". Hankalasti toteutettava monesta moneen -suhde.
Lisätään kvalifikaattori "tuotekoodi", ja suhde muuttuu helpommin
hahmotettavaksi: "Tavaratalo myy useaa tuotetta, joista jokaisella on
oma tuotekoodinsa, joka on yksikäsitteinen tietyn tavaratalon suhteen."
Kolmenvälinen yhteys (ternary association)
Joskus harvoin on tarpeen muodostaa monen luokan välinen assosiaatio. Esimerkki: "Ohjelmointiprojektissa työskentelee eri henkilöitä, ja eri projekteissa käytetään eri ohjelmointikieltä. Henkilöt osaavat eri kieliä, ja työskentelevät useissa projekteissa". Mikään yhdistelmä kahdenvälisiä suhteita (Projekti-Kieli, Kieli-Henkilö, ...) ei tällöin kykene ilmaisemaan kolmiyhteyttä Projekti-Kieli-Henkilö ilman, että jotain informaatiota häviää. Kolmenvälisiä (ternary association) tai useampiasteisia (N-nary association) yhteyksiä on kuitenkin syytä välttää. Niiden käsittely on nimittäin varsin hankalaa. Yleensä niille ei olekaan tarvetta. Huomaa myös edellä esitetty keino luokitella suhteita (kvalifikaatio). Sen avulla voidaan joskus purkaa tällainen yhteys kahdenväliseksi siten, että sopivasti valittu kvalifikaattori määrittelee kahdenvälisen suhteen niin, ettei informaatiota häviä.
Koostumussuhde (aggregation)
Eräs erikoistapaus luokkien välisissä suhteissa on koostumussuhde. Jonkin kokonaisuuden komponentteja tai osatekijöitä kuvaavat luokat muodostavat tällöin assosiaation kokonaisuutta esittävän luokan kanssa. Esim. "Asiakirja koostuu otsikosta ja kappaleista, kappaleet koostuvat lauseista". Koostumussuhde on paikallaan, jos kyseessä on olemassaoloriippuvuus: osaluokan ilmentymä ei voi olla olemassa itsenäisesti, ilman koosteluokan ilmentymää. Rajanveto koostumussuhteen ja tavallisen välillä on vaikeaa - jos et ole varma kumpaa pitäisi käyttää, tyydy tavalliseen (esim. "Koostuuko Auto mm. Renkaista, vai voivatko Renkaat olla itsenäisiäkin olioita?"). Koostumus merkitään pienellä salmiakkikuviolla assosiaation koosteluokan päähän. Koostumussuhdetta ei tarvitse nimetä erikseen, salmiakkikuvio ilmaisee oleelliset asiat.