Olioteknologiaa on väitetty yhdeksi systeemityön menestystekijöistä 90-luvulla. Sen on esitetty tuovan etuja monimutkaistuvien järjestelmien rakentamisen ja ylläpidon kanssa kamppaileville yrityksille ja parantavan systeemityön tuottavuutta. Tämän artikkelin tavoitteena on tarkastella eräitä olioteknologiaan liittyviä väitteitä oliosovellusten rakentamisessa saatujen kokemuksien kautta. Erityisesti tarkastelemme olioparadigman suhdetta yleisiin järjestelmän suunnittelun perusteisiin, periytymistä, olioiden uudelleenkäyttöä, ja luokkakirjastojen hyödyntämistä. Tarkastelun konkretisoinniksi käytämme esimerkkinä oliosovelluksesta MetaEdit+ CASE-välinettä: Se on suunniteltu oliomenetelmillä ja toteutettu Smalltalk-oliokielellä käyttäen kolmansien osapuolten luokkakirjastoja. Väline itse tukee erilaisia oliomenetelmiä (esim. OMT), sillä laaditut mallit talletetaan oliotietokantaan ja se generoi koodia olio-ohjelmointikielille. Toisin sanoen, oliosuuntautuneenpaa sovellusta kokemuksien perustaksi tuskin voi saada.
Kaiken insinööritieteen perustana ovat hyvät suunnitelmat ja mallit. Olioteknologiaan perustuva systeemityö ei ole poikkeus. Itse asiassa, oliosuuntautuneisuuden parhainta antia on yhdenmukaiset käsitteet ja tavat systeemien rakentamiseen: analyysin ja suunnittelun välillä on konkreettisempi yhteys toteutukseen kuin esimerkiksi perinteisillä rakenteisilla menetelmillä ja -kielillä. Mikäli oliomallin perusteella tehty suunnitelmat ovat hyvät niin toteutus sujuu joustavasti ja mahdolliset muutokset ylläpidon aikana pystytään rajaamaan mahdollisimman pieneen mallin osaan.
Vaikka oliot tuovat mukanaan joukon uusia tekniikoita systeemityöhön, kokemuksiemme mukaan yleiset suunnitteluperiaatteet, kuten heikko kytkentä ja voimakas sidos, käyttöliittymän ja toimintalogiikan erottaminen toisistaan, ja monimutkaisuuden osittaminen pienempiin, paremmin hallittaviin osiin, ovat tärkeitä myös olioihin perustuvassa systeemityössä. Oliomalli tosin tarjoaa näiden universaalien periaatteiden noudattamiseen paremmat mahdollisuudet. Tästä esimerkkinä kapseloinnin käyttö komponenttien välisten kytkentöjen hallinnassa. Kapseloinnilla pyritään rakenteeseen, jossa olioiden rakenne (tiedot) ja käyttäytyminen (sallitut) operaatiot ovat kytketty yhteen. Tällöin olioiden luonteenomainen piirre on se, että niiden sisäinen toiminta on erotettu niistä ohjelman osista jotka niitä käyttävät. Tästä esimerkkinä CASE-välineellä tuotettujen kaavioiden esitystavan riippumattomuus. Oheisen kuvan mukaisesti esimerkiksi Use case kaavio voidaan esittää kolmessa eri työkalussa vaikka kyseessä on vain yksi ja sama use case kaavio. Muutokset use case-kaavion yhdessä työkalussa päivittyvät automaattisesti muihin työkaluihin.
Oliomallin tarjoaman kapseloinnin mukaisesti tämä ominaisuus on toteutettu esimerkkimme sovelluksessa siten, että mikään työkalu ei itse tiedä esimerkiksi montako suhdetta kaaviossa on tai mitä tietoa yksittäinen use case sisältää. Kukin työkalu keskittyy vain use case kaavion esittämiseen ja hallintaan. Esimerkiksi use case 'update product quantity information' on oma olionsa, joka tietää sisältönsä (esim. use casen nimi ja kuvaus) ja käyttäytymisensä (use case:jä voidaan lisätä, päivittää, poistaa mallista, tai se voidaan räjäyttää use case:ä käsitteleväksi luokkamalliksi). Työkalujen, kuten piirtoikkunan, ei kuitenkaan tarvitse tietää miten use case:jä käsitellään malleissa.
Kapseloinnista seuraa, ettei ohjelmoijien tarvitse tietää kovinkaan paljoa toistensa tekemisistä: laajatkin sovellukset voidaan jakaa erillisiin komponentteihin, jotka sisältävät vain muutamia luokkia. Itse asiassa, äärimmilleen vietynä kukin luokka voidaan toteuttaa eri ohjelmoijien toimesta, kunhan vain olioiden välinen kommunikointi on ennalta määritetty.
Kapseloinnilla ja komponenttien osittamisella on myös systeemityön hallinnan kannalta suuri merkitys: Koska komponenttien koko ja rajapinnat ovat paremmin määriteltävissä voidaan suunnittelun ja toteuttamisen vastuut ja resurssit paremmin ennakoida.
Suunnitelmien ja koodin uudelleenkäytettävyyttä on väitetty yhdeksi tärkeimmistä olioteknologian tuomista hyödyistä. Esimerkiksi Grady Booch (1994) pitää hyvänä saavutuksena 60-70% uudelleenkäyttöä. Tällöin esimerkiksi vain kolmannes sovelluksen vaatimista luokista on itse tehtyjä, ja loput tulevat "ilmaiseksi".
Koska MetaEdit+ on toteutettu vain oliokielellä olemme pyrkineet mahdollisimman pitkälle hyödyntämään periytymistä. MetaEdit+:n tapauksessa olemme käyttäneet perityistä esimerkiksi siten, että use case on yksi ja sama luokka, josta taulukossa, matriisissa ja piirtoikkunassa on kukin esityksestä vastaava luokkansa. Piirtoikkunan esitysluokka tietää sijaintinsa piirtoalueella, matriisin esitys tietää paikkansa akseleilla ja taulukkoesitys paikan taulukossa. Kaikilla näillä on kuitenkin yhteinen yliluokkansa, joka vastaa esitysten luonnista ja tuhoamisesta. Tällöin esimerkiksi samat säännöt, joita käytetään use casen lisäämiseen tai siirtämiseen piirtoikkunassa ovat osin samankaltaiset myös use case kaavion suhteille. Siksi käyttäjä voi työskennellä samoin periaattein, olipa kyseessä kaaviossa oleva olio (esim. use case), suhde (esim. kommunikaatio suhde) tai ominaisuus (esim. use case:n nimi).
Omien kokemustemme perusteella olemme huomanneet että uudelleenkäyttö tulee osin automaattiseksi kunhan vain sovellus ja sen komponentit ovat hyvin määritetty. MetaEdit+:ssa noin 80% luokista on uudelleenkäytettyjä: Toisin sanoen, kun sovelluksen koko on noin 750 luokkaa on niistä itse tehtyjä vain noin 150.
Luokkakirjastojen täysimittainen hyödyntäminen perustuu osin valmiiden luokkien uudelleenkäytettävyydelle osin omien luokkien periyttämiseen. Itse olemme soveltaneet molempia tapoja. MetaEdit+ CASE-väline on kirjoitettu VisualWorksin Smalltalkilla, käyttäen kolmannen osapuolen luokkakirjastoja: NEDT grafiikassa ja ArtBase tietokantana. Tietokannan tarjoamat luokat sisältyvät automaattisesti MetaEdit+:aan sellaisenaan. Toisaalta koko piirtoikkuna on periytetty NEDT:n tarjoamasta geneerisestä piirtoikkunasta. Periytettyyn MetaEdit+:n piirtoikkunaan on vain lisätty CASE-välineelle luonteenomaisia piirteitä kuten suhteiden siirtyminen olioita (esim. use case) liikuteltaessa ja symbolien skaalautuminen.
Luokkakirjastot ovat kuitenkin kaksiteräinen miekka: Toisaalta ne säästävät paljon työtä mutta toisaalta on vaikea ennalta löytää soveltuvaa kirjastoa, joka esimerkiksi mahdollistaa halutunlaisten ominaisuuksien muodostamisen luokkakirjaston tarjoamia luokkia periyttämällä. MetaEdit+:n tapauksessa luokkakirjastojen soveltamista on edistänyt Smalltalkin tarjoama hyvä luokkakirjasto: Visual Worksin Smalltalk tarjoaa noin 1300 luokkaa (lue: valmista sovelluskomponenttia).
Olioteknologian vaikutusta systeemityön tuottavuuteen on vaikea arvioida. Ensinnäkin perinteiset metriikat ohjelmiston koon tai kompleksisuuden mittaamiseen eivät huomioi oliomallin tarjoamaan periytymistä. Tällöin metriikoihin perustuvat vertailut oliosovellusten ja muilla keinoilla toteutettujen järjestelmien välillä ovat vähintäänkin kyseenalaisia.
Itse emme ole mitanneet tuottavuutta toimintopisteiden tai ohjelman koon ja käytettyjen resurssien suhteen. Tästä huolimatta on kaikilla kehitystyöhön osallistuneilla yhteinen näkemys: Olioteknologian hyödyntäminen on mahdollistanut MetaEdit+:n toteuttamisen halutuilla ominaisuuksilla aikataulussa. Ilman olioteknologiaa, esimerkiksi käyttämällä kolmannen sukupolven ohjelmointikieliä, rakenteisia menetelmiä ja relaatiotietokantoja, olisimme kyenneet esittelemään jonkinlaisen prototyypin ensi vuosituhannella - ehkä.
Tuija Postari-Kivistö