HY / TKTL / 58160-8 Ohjelmoinnin harjoitustyö / Sami Nikander
Copyright © 1998 Sami Nikander, <niksu@iki.fi>. Tämän oppimateriaalin käyttö on sallittu vain yksityishenkilöille opiskelutarkoituksissa. Materiaalin käyttö muihin tarkoituksiin, kuten kaupallisilla tai muilla kursseilla, on kielletty.
12.10.98

OMT (Object Modeling Technique)

Olioperustainen suunnittelumenetelmä

Johdanto

Tässä ohjeessa on suppea selostus OMT-tekniikasta (Object Modeling Technique). Se on olio-ohjelmien suunnittelumenetelmä, jossa kaavioiden ja piirrosten avulla kuvataan toteutettavan järjestelmän piirteet. OMT-suunnitelman pohjalta ohjelman koodaus on "helpompaa" ja suoraviivaisempaa kuin pystymetsästä lähtien. Hyvin suunniteltu ohjelma on 2/3 tehty, ja OMT-kuvaus on eräs suosittu väline hyvään suunnitteluun. Se on jo olio-ohjelmoinnin eräänlaiseksi "klassikoksi" muodostunut perusmenetelmä ja on laajalti käytössä ohjelmistoteollisuudessa. Tämän ohjeen laatimisessa on käytetty vapaasti muokaten lähteenä seuraavia teoksia:
Rumbaugh et al: Object-oriented modeling and design. Prentice-Hall 1991.
Koskimies: Pieni oliokirja. Suomen ATK-kustannus Oy 1997.

Miksi käyttäisin OMT:tä?

Siksi, että joudut kuitenkin uhraamaan hieman aikaa suunnittelutyöhön, jos aiot saada aikaan hyvän - tai edes toimivan - ohjelman. Miksi et käyttäisi koeteltua, hyväksi havaittua ja taatusti toimivaa menetelmää? Miksi keksisit pyörän uudelleen? 100-rivisen ohjelman voi kuka tahansa aloittelija tehdä ilman kummempia suunnitelmia, ehkä 500-rivisenkin. 1000-rivinen ohjelma (kuten Ohjelmoinnin harjoitustyö) vaatii jo useimmilta suunnittelua. "Oikeissa töissä" tehdään satojen tuhansien koodirivien mittaisia ohjelmia, ja huolellinen suunnittelu on tällöin itsestäänselvyys.

OMT-kuvaus tarjoaa suhteellisen helposti hahmotettavan visuaalisen kuvauksen järjestelmästä. Se on ohjelmointiin perehtymättömällekin intuitiivisesti ymmärrettävissä, joten sitä apuna käyttäen on usein helpompaa esim. keskustella ohjelman toiminnasta asiakkaiden kanssa. Lisäksi se on erinomainen tapa dokumentoida ohjelman rakenne. Yksi kaavio kertoo enemmän kuin tuhat sanaa, ja tekee sen huomattavasti eksaktimmin kuin paraskaan proosateksti. Tosin pelkkä kaaviokaan ei yksin riitä, se pitää myös perustella sanallisesti.

OMT-suunnitteluun kuuluu rinnakkaisina tai limittäisinä työvaiheina sekä abstraktia että teknistä suunnittelua. Analyysi- ja oliosuunnitteluvaiheessa muodostetaan sovelluksen loogisen käsitteistön kuvaus, eikä huomioida lainkaan toteutusnäkökohtia. Halutaan siis ymmärtää, mitä toteutetaan. Systeeminsuunnitteluvaiheessa taas tehdään puhtaasti teknisiä päätöksiä (esim. tietorakenteiden toteutustavan valinta, ohjelman jako osajärjestelmiin, ja toteutuskielen ominaisuuksista riippuvia muita valintoja).

Kun näitä näkökulmia vähitellen lähennetään toisiinsa, saadaan suunnitelma, joka huomioi sekä toteutustekniset rajoitteet ja jipot, että ongelman itsensä tuomat rajoitteet ja tarpeet. Valmiista OMT-suunnitelmasta voi (jos se on kunnolla mietitty) periaatteessa suoraan alkaa kirjoittaa olio-ohjelman koodia, joten se ei jää pelkäksi turhaksi A4-saasteeksi tai teoreettiseksi malliksi.

Mitä OMT-kuvaukseen vaaditaan?

  1. Olio-ohjelmoinnin peruskäsitteiden (luokka, luokan ilmentymä, metodi jne) ymmärtäminen - niiden, joita esim. Johdatus ohjelmointiin -kurssilla opetetaan.
  2. Analysoitavan ongelman mahdollisimman täsmällinen sanallinen kuvaus.
  3. Kynä ja paperia.

OMT ei ole kieliriippuvainen kuvaus. OMT:llä suunnitellun luokkarakenteen voi siis toteuttaa periaatteessa millä tahansa olio-ohjelmointikielellä. Jos kuitenkin toteutuskieli on jostain syystä lyöty lukkoon jo ennen suunnitteluvaihetta (kuten esim. Ohjelmoinnin harjoitustyössä Java), sen piirteitä on mahdollista - ja syytäkin - huomioida jo OMT-suunnittelussa. OMT:henhan kuuluu olennaisesana osana myös teknisten yksityiskohtien päättämistä, eli esim. käyttämiesi Javan valmispakkausten ja komponenttien valintaa ja niillä "leikittelyä".

Eräs parhaita välineitä OMT-kehittelyyn on ainakin suunnittelun alkuvaiheessa tavallinen paperi ja kynä. OMT-suunnitelman hiominen vaatii tyypillisesti ainakin 3-5 iteraatiota (kehittelykierrosta), joten suttupaperia kulunee.

OMT-kaavioiden piirtämiseen ja muokkaamiseen on olemassa myös useita valmisohjelmia. TKTL:llä on käytössä mm. Mermaid-niminen ohjelmisto (Win95/NT), jolla kaavioita voi editoida monipuolisesti. Monissa yleiskäyttöisissä kaavioidenpiirto-ohjelmissa (ja jopa Word-tekstinkäsittelyohjelmassa) löytyy välineitä OMT-symbolien piirtoon. Myös tavallisilla piirto-ohjelmilla voi luonnollisesti piirtää kaavioita, tosin ainakin bittigrafiikkana niiden korjailu on varsin työlästä.

Yleistä oliosuunnittelusta

Ymmärrä ongelma

Oliomalli kuvaa järjestelmän osia, niiden välisiä suhteita ja riippuvuuksia, ja osille tyypillisiä piirteitä (ominaisuuksia ja toimintoja). Oliomalli tuottaa järjestelmästä reaalimaailman ominaisuuksia melko tarkkaan vastaavan kuvan. Niinpä myös esikuvaan tehtävät muutokset on helppo huomioida mallissa. Tämä kaikki edellyttää tietenkin, että esikuva on riittävän tarkasti tutkittavissa - tehtävänannon tai ainakin ongelman analyysin pitää olla niin täsmällinen kuin mahdollista. Epätarkasta kuvasta tulee epätarkka malli, epätarkasta mallista huonosti todellisuutta ja todellisia tarpeita vastaava ohjelma.

Esim. jos pankkisovelluksen tehtävänannossa tai ko. tehtävästä erikseen tehdyssä analyysissä ei riittävän tarkkaan kerrota, miten pankin tilitapahtumat käsitellään, ei valmiissa ohjelmassakaan niiden käsittely voi olla parhaalla mahdollisella tolalla.

Oliosuunnittelu on makuasia

Olioiden tarkoitus on kuvata reaalimaailmaa (sovellusaluetta) ja tarjota lähtökohta sovellusalueen tietokonetoteutukselle. Ongelmakentän jaottelu olioiksi ei ole suoraviivaista, ja paras lähestymistapa riippuu aina täysin ongelmasta itsestään. Yhtä ainoaa oikeaa ratkaisua ei ole. Oliosuunnittelu on pitkälti makuasioita, kompromisseja ja asioiden tärkeysjärjestykseen laittamista. Kannattaa kokeilla useita eri vaihtoehtoja ja pitää mieli avoimena. Muista, että tämä on suunnittelutyön kriittisin vaihe, ja mitä kuvaavamman mallin saa tällä menetelmällä aikaan, sitä enemmän se säästää työtä myöhemmissä vaiheissa.

Nimet ja käsitteet ovat tärkeitä

Eri asioiden (luokat, luokkien väliset suhteet ja roolit eri suhteissa) nimeäminen on tärkeämpää kuin päällepäin saattaa näyttää. Nimet antavat hyvin vahvoja (piilo)merkityksiä eri asioille, siksi huolellinen nimeäminen auttaa huomattavasti ohjelman rakenteen hahmottamisessa. Ylimalkaiset ja epähavainnolliset nimivalinnat taas voivat johtaa pahasti harhaan myöhemmässä suunnittelussa. Nimeäminen onkin yksi hyvän oliosuunnittelun vaikeimmista tehtävistä! Nimenantamisen lisäksi kaikki asiat pitäisi määritellä niin tarkkaan kuin mahdollista, ainakin suunnittelun kuluessa pikku hiljaa. OMT-kuvaukseen kuuluukin yleensä ns. mallisanasto, jossa sovellusalueen käsitteet (jotka muuntuvat luokiksi ja muiksi) määritellään sanallisesti. Tämä on hyvä asia, sillä se pakottaa miettimään, mitä oikeastaan tarkoittaa jollain tietyllä sanalla.

Luokalle annetaan siis sen toimintaa mahdollisimman hyvin kuvaava nimi (muiden asioiden nimeämistä käsitellään tuonnempana ohjeessa). Nimeäminen riippuu pohjimmiltaan siitä, mihin tarkoitukseen ohjelmaa tehdään, eli mikä on sen sovellusalue. Luokan rooli ohjelmassa pitää miettiä eri näkökulmista, ennen kuin sen nimeää. Nimi ei saisi olla liian "kapeakatseinen", sen ei pidä kuvata vain yhtä luokan aspektia tai piirrettä.

Esimerkki:

Oletetaan että tehtävänä on käsitellä muiden tietojen ohella ihmisten ja yritysten yhteyksiä, mm. ihmisten työskentelyä firmoissa. Olisiko juuri työsuhde kuvaavin näkökulma? Miksei samantien nimeäisi ihmisiä mallintavaa luokkaa suoraan Työntekijäksi ja firmojen tietoja sisältävää luokkaa Työnantajaksi?

Vastaus on: Riippuu siitä, millaista ohjelmaa ollaan tekemässä! Jos tarkoitus on tehdä ohjelmalla muutakin kuin vain työsuhteiden kirjaamista, olisi harhaanjohtavaa nimetä luokat vain yhden näkökulman mukaan. Ihmistä käsittelevälle luokalle lienee ehkä muutakin käyttöä kuin listata firman työntekijöitä ja firmalle halutaan ehkä muitakin ominaisuuksia, kuin työnantajan rooliin liittyviä. Tällöin neutraalimmat nimet, esim. Henkilö ja Yritys ovat paljon parempia nimiä ko. luokille, kuin palkkatyöhön vahvasti suuntautuneet nimet. Jos kuitenkin olet tekemässä nimenomaan palkanlaskentasovellusta, Työntekijä- ja Työnantaja-nimet voivat ollakin hyviä.

Ei hakuammuntaa, vaan jatkuvaa kehittelyä

Varaudu siihen, että joudut viilaamaan suunnitelmia useaan otteeseen. Harva suunnitelma on täydellinen syntyessään, ja osa koko suunnittelua on nimenomaan etsiä ongelmia ja sudenkuoppia tehtävänannosta. Onhan mukavampaa löytää ne heti kättelyssä kuin törmätä niihin vasta kun ohjelma on jo valmis... Oliosuunnittelussa on aivan tavanomaista, että OMT-kaaviosta joutuu laatimaan 3-5 versiota ennen kuin se on kohdallaan, joskus enemmänkin.

Mitä ikinä teetkin, älä ryhdy hakuammuntaan. Älä ainakaan arvo kuvioita, luokkia, sanoja tai suhteita paperille täysin sokkona. Vaikka suunnittelua tehdäänkin "ruutupaperille pöydänkulmalla" -periaatteella, ei se tarkoita sitä, että luokkia tai suhteita tempaistaan "hihasta" ilman perusteita. Joskus tosin tuntuu, että tämä on ristiriidassa avoimen kokeilumielen kanssa. Loppujen lopuksi kaavion järkevyys punnitaan sillä, ratkaiseeko se annetun ongelman vai ei, joten kokeilu on suositeltavaa, kunhan tajuaa aina, mitä on yrittämässä.

Kuva kertoo mitä tehdään, teksti kertoo miksi

Kaavioiden seurana tulisi aina olla sanallinen selostus, jossa perustellaan tehdyt valinnat, sekä jokaisen luokan ja riippuvuuden olemassaolon tarkoitus. Kaavio toki on informatiivinen sinälläänkin, mutta kertoo vain lopputuloksen - ei sitä, onko kaikki ongelmaan liittyvät seikat huomioitu, eikä sitä, miksi suunnittelija on tehnyt juuri näin. Kaavio ilman perusteluja on vaillinainen. Tekstissä voi esimerkiksi kertoa, mitä vaihtoehtoisia ratkaisuja on ollut esillä, miksi muut on hylätty ja mikä on valitun ratkaisun etu.

Staattinen ja dynaaminen kuvaus

OMT-menetelmässä kuvataan systeemiä sekä sen staattisen (käännösaikaisen) luokkarakenteen että dynaamisen (ajonaikaisen) toiminnan näkökulmasta. Staattinen malli eli luokkakaavio (class diagram) kuvaa luokkien ominaisuuksia ja niiden väliset suhteet. Se ei ota kantaa siihen, mitä tapahtuu ohjelman yksittäisellä suorituskerralla (esim. jollain käyttökerralla luokat X ja Y eivät ehkä lainkaan kommunikoikaan keskenään, vaikka niillä on kyky siihen). Staattiseen malliin sisältyy yleensä myös keskeiset käsitteet luetteleva mallisanasto.

Dynaamisessa mallissa puolestaan simuloidaan, mitä ohjelmassa jollain kuvitteellisella suorituskerralla tapahtuu: mistä tehtävistä kukin olio (luokka) vastaa, miten luokkien ilmentymät kommunikoivat toistensa kanssa ja tekevät yhteistyötä. Dynaaminen malli havainnollistaa, missä tilassa järjestelmä kulloinkin on, ja mille sen osalle kontrolli siirtyy eri aikoina. Lisäksi dynaaminen malli auttaa mm. hahmottamaan, puuttuuko luokkakaaviosta jokin yhteys, jota ei aiemmin ole huomattu (esim. simuloinnin tuloksena todetaan että luokan X pitäisikin saada tietoa luokalta Y).

Ajonaikaista käyttäytymistä kuvataan skenaariokaavioilla (sequence diagram, event trace diagram). Apuna käytetään monimutkaisten ohjelmien kuvaamisessa usein ns. tilakaavioita (äärellisiä automaatteja) - jos käsite ei ole tuttu, ei syytä huoleen, ne eivät kuulu Ohjelmoinnin harjoitustyön piiriin! Tässä ohjeessa esitellään vain skenaarioiden käyttöä, tila-automaatteihin tutustutaan mm. TKTL:n cl-tason kursseilla Ohjelmistotuotanto ja Laskennan teoria.

Molempia kuvauksia voidaan tarkentaa asteittain alikaavioiksi. Tämä onkin suositeltavaa, jos tietoa on enemmän kuin yhdelle paperiarkille suosiolla mahtuu.

Yksityiskohtaisemmat ohjeet

Luokkakaavio: staattinen OMT-kuvaus

Skenaariot: dynaaminen OMT-kuvaus

Pikaohje: tarkistuslista luokkakaavion piirtäjälle

Takaisin OMT-etusivulle




<niksu@iki.fi>