Oliosuunnitelma

Yleistä

Listaa ensin ohjelmassa esiintyvät käsitteet. Käsitteillä on aina loogisia yhteyksiä muihin käsitteisiin, ja näitä yhteyksiä voidaan olio-ohjelmassa esittää eri tavoin. Pitää vain valita, mitkä asiat mallinnetaan luokkina, mitkä luokkien muuttujina ja metodeina. Osalle käsitteistä ei aina löydy luontevaa esitystä oliomaailmassa, jolloin ne voidaan rinnastaa johonkin muuhun asiaan tai ehkä karsia kokonaan pois mallista.

Keksi luokkia ja niiden välisiä yhteyksiä. Mitkä asiat on parasta kuvata luokkina, mille asioille riittää luokan attribuutti (muuttuja), mitä palveluita luokka voisi tarjota (eli mitkä asiat ovat selkeästi luokan omalla vastuulla, ja mitkä hommat on parasta jättää toisten luokkien huoleksi), mitkä oliot vaihtavat keskenään tietoja jne. Jonkinlainen peukalosääntö voisi olla esim. "substantiivit ovat potentiaalisia luokkia, verbit metodeja, adjektiivit ja adverbit attribuutteja"...

• Mitä luokkia ohjelmassa voisi olla? Miksi? Tarvitaanko aliluokkia? Onko jokin luokka olemassaoloriippuvainen toisesta?
• Mitkä ovat luokkien väliset suhteet? Mitkä luokat joutuvat tekemisiin keskenään?
• Nimeä luokkien väliset suhteet, muuten on mahdotonta päätellä, mikä looginen yhteys kahdella luokalla on. Perintää ja koostumussuhdetta ei nimetä, koska niillä on oma symboli.
• Luokkakaavio esittää vain luokkien loogisen rakenteen. Java-toteutuksessa voidaan joitain osia tehdä toisin kuin kaaviossa, esim. kaavion luokka voidaan toteuttaa attribuuttina tai päinvastoin.

Muista, että tähän työvaiheeseen voidaan hyvin palata vaikka useita kertoja. Ei siis tarvitse vielä lyödä lukkoon mitään, vaan tärkeintä on saada aikaan jonkinlainen luokkarakennelma. Jos myöhemmin huomataan, että jokin luokka on ylimääräinen (tarpeeton, sitä ei käytetä mihinkään tai se on selvästi naimisissa jonkin toisen luokan kanssa), tai että jokin luokka on jäänyt puuttumaan, ne voidaan lisätä malliin.

Tee sitten muutama kappale dynaamisia malleja, eli ohjelman toimintaa kuvaavia hahmotelmia. Luokkien määrittelyhän ei vielä kerro mitään siitä, missä järjestyksessä luokat kutsuvat toisiensa metodeita ja mitkä luokat ylipäätään käyttävät toistensa palveluita, toisin sanoen oloiden keskinäisestä viestinnästä. Tämä olioiden "juttelu" tai viestintä on olio-ohjelman ehkä tärkein suunnitteluvaihe, ja se määrää suoraan, minkälainen ohjelmasta muodostuu. Kuvauksessa tulisi esitellä kaikki ne erilaiset tilanteet, joita ohjelman kulussa voi tulla. Kuvauksessa näkyy, millä oliolla ohjelman kontrolli kulloinkin on (eli missä metodikutsussa ollaan), mitä olioita tilanteessa kutsutaan, mitä kutsun palatessa tapahtuu jne.

• Hahmottele tyypillisiä ohjelman käyttötilanteita, konkreettisia esimerkkejä yksittäistapauksista. Esim. ohjelman aloitus ja alustus, yhden tyypillisen "kierroksen"/etenemisaskelen/toiminnon kulku, jonkin toisen tyypillisen tilanteen kulku, poikkeustilanne, virhe, tilanteen muuttuminen, tiedon hakeminen/analysointi/keruu...
• Mikä luokka kutsuu mitäkin? Milloin? Miksi? Mitä kutsu palauttaa?
• Nimeä myös, mitä tietoa kutsuissa välitetään ja palautetaan.
• Tilanteita voi tarkentaa toisissa kuvauksissa, eli kuvaus voi rakentua osista.
• Jos huomaat, että jonkin tiedon kaivaminen tai välittäminen ei onnistu, tai muuten hahmotelma kaipaa täydentämistä, lisää uusia suhteita olioiden välille luokkakuvauksessa tai keksi uusia luokkia.

Erityistä huomiota täytyy kiinnittää kontrollin sijaintiin ohjelmassa: olio-ohjelma koostuu alusta loppuun metodikutsuista, eli palvelupyynnöistä, joita oliot lähettelevät toisilleen. Täten kontrolli on vuorollaan aina jollain tietyllä oliolla, ja sen pitäisi myös palata aikanaan palvelupyynnön esittäneelle kutsujalle. Kutsujen ja niistä palaamisen pitää siis esiintyä yleensä aina pareittain! (Poikkeuksiakin on, liittyen esim. Javan säikeisiin eli rinnakkaiseen kontrolliin, ja tapahtumien käsittelyyn, mutta näitä tilanteita ei käsitellä tässä ohjeessa.) Helpoiten saat kutsut ja paluut pidettyä järjestyksessä, kun pidät kirjaa siitä, kuka on kutsuja ja ketä kutsutaan. Usein tilanteisiin liittyy sisäkkäisiä kutsuja, joissa oliot kutsuvat toisiaan "ristiin". Nämä ovat eri asia kuin kaksi peräkkäistä kutsua, ja näissä tulee myös useimmin tulkintavirheitä. Esimerkkikuvassa on havainnollistettu kutsuja ja niistä paluuta (ESIMERKKIKUVA PUUTTUU!).

Tähänkin toimintakuvaukseen voi käyttää erilaisia menetelmiä. OMT-menetelmässä käytettävät skenaariot ovat havainnollinen tapa kuvata olioiden keskinäistä "juttelua" ja ajonaikaisia suhteita. Vaikka et käyttäisikään juuri näitä merkintätapoja, pitää ohjelman toiminnasta pystyä kertomaan nämä samat asiat jollain muulla tavoin! Seuraavat ohjeet pätevät siis kaikkeen toimintojen kuvaukseen.

(Esimerkkikuva skenaariosta puuttuu)

Yhden skenaarion osapuolina ovat "tilanteen" selvittämiseen osallistuvat luokat. Lisäksi on aivan sallittua ja tarpeellista laittaa yhdeksi osapuoleksi myös esim. "käyttäjä", vaikka se ei varsinainen luokka olekaan. Näin saadaan kuvaan mukaan ohjelman kommunikointi ihmisen kanssa (ohjelman syötteet ja tulosteet).

Jos tilanne on monimutkainen, se kannattaa jakaa osiin, eli rakentaa ensin yleiskuvaus, jossa viitataan eri osatoimintoihin ja tarkentaa sitä sitten asteittain. Nyrkkisääntönä voisi olla, että jos skenaariossa esiintyy jokin epämääräinen maininta, joka tuntuu sisältävän paljon "toimintaa" (vaatii todennäköisesti aina juttelua muiden olioiden kanssa) esim. "tarkista tilanne" tai "laske seuraava vaihe", se pitää tarkentaa. Toimintaa ei siis saa piilottaa tällaiseen "mustaan laatikkoon", josta tulos maagisesti putkahtaa esiin, vaan se on esitettävä eri kuvauksessa tarkemmin. Jos näitä tilanteita ei kuvaa riittävän tarkasti, tulee koodauksessa vastaan ongelma: on luotettu siihen, että tieto ilmestyy tyhjästä, ja koodissa pitäisikin saada tieto jotenkin tuotettua.

Skenaarioita pitäisi olla useampia, kaikista realistisista tilanteista ja siten, että ne kattavat ohjelman toiminnot. Yksi skenaario sisältää yhden mahdollisen tilanteen, esim. yhden käyttäjän tekemän toimenpiteen ja siihen reagoinnin. Tarkoitus ei ole tehdä kaikenkattavia kuvauksia kaikista mahdollisista erilaisista poluista ohjelman suorituksen läpi, riittää kun eri tyyppisistä tilanteista on kustakin oma kuvauksensa.

Esimerkki 1: Jos mallinnettavana on vaikkapa shakkipeli, riittää että yhden esimerkkisiirron kulku kuvataan, ei tarvitse erikseen tehdä skenaariota kymmenistä erilaisista siirroista. Tässä olisi ehkä hyvä kuvata tilanne ensin yleisellä tasolla, ja sitten tarkentaa skenaario aliskenaarioihin: osatoimintoja ovat esim. siirrettävän nappulan valinta, kohderuudun valinta, laillisuuden tarkistus, mahdollinen nappulan syönti, shakki- ja matti-tilanteiden tarkastus, tuloskirjanpidon päivittäminen. Lisäksi on tietysti vielä tarpeen kuvata muitakin ohjelman toimintoja, esimerkiksi pelin alustus, mahdollinen pelitilanteen talletus, tms.

Esimerkki 2: Mallinnetaan matematiikan/vieraan kielen tenttausohjelmaa. Tässä voitaisiin tehdä skenaario ainakin yhden kyselykierroksen kulusta (kysymysten arvonta/valinta, vastauksen kysyminen, oikeellisuuden tulkinta, oikean/väärän vastauksen rekisteröinti jne.). Jos kysymysten arvontaan liittyy esimerkiksi vaikeustason nosto tms. toiminnan muuttaminen ajon aikana, se lienee syytä kuvata aliskenaarionaan. Jos ohjelmaan liittyy esim. väärin vastattujen kysymysten uudelleententtausmahdollisuus, myös sen järjestäminen pitää näyttää.

Oliko tehtävänanto sittenkin liian hutera? Voit hyvin palata välillä täydentämään tehtävänmäärittelyä! Ota ohjaajaan yhteyttä, jos työ tuntuu vaikealta. Oliosuunnittelu ei avaudu yhdessä silmänräpäyksessä!