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.
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.
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ä.
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.
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.
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ä.
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ä.
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.
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.