Luku 1.2: Ohjelman suunnittelusta

Mitä suunnittelu on?

Ohjelman suunnittelu on toisaalta prosessi, jossa ohjelmalle esitetyistä vaatimuksista ja toiveista tuotetaan ensimmäinen suunnitelma jonka pohjalta toteutus alkaa, mutta suunnittelu on myös toimintaa, joka jatkuu ja jota tarvitaan läpi koko projektin toteutuksen ja elinkaaren. Vaikka suunnittelua siis tarvitaan paljon juuri projektin alussa, vuorottelee suunnittelu eri muodoissaan toteutuksen kanssa.

Ohjelman suunnitteluun ei ole mitään suoraviivaista reseptiä, jota noudattamalla ideasta syntyisi lopulta toimiva ohjelma. Erilaisia suunnittelumenetelmiä ja apuvälineitä on kuitenkin olemassa.

Tässä luvussa tutustumme ohjelman suunnittelun alkuvaiheisiin esimerkkiprojektin kautta.

Esimerkkiprojekti: Timeliner

Sanallinen kuvaus ohjelmasta

Timeliner-projektin on tarkoitus ratkaista ikiaikainen opiskelijoiden ja opettajien ongelma - samaan aikaan sijoittuvat työpiikit.

Samoille päiville ja jopa tunneille sijoittuva työ on hankalaa sekä opiskelijoille, opettajille, että opetuksen suunnittelijoille. Suunnitellaan ja toteutetaan työkalu, jolla opettajat ja muutkin tahot voivat sijoittaa kurssiensa luentoja, tenttejä, harjoituksia, tapaamisia, projekteja, eli yleensä ottaen kaikkea opiskelijan aikaa vievää, kalenteriin jotta nämä näkyvät sekä oppilaille että muille opettajille. Kun työkalu vielä tietää mitä kursseja opiskelijat samana lukukautena ottavat, se voi näyttää kursseja ottavien opiskelijoiden muut määräajat opettajalle jo suunnitteluvaiheessa. Näine ominaisuuksineen ohjelma on vasta jonkinlainen yhteisöllinen kalenteri, mutta mielenkiintoinen työkalusta tulee kun opiskelijoille annetaan mahdollisuus jakaa vaikkapa projektityön tunnit haluamiinsa osiin ja sijoittaa projektin julkaisuhetken ja määräajan välille raahaamalla ne haluamiinsa paikkoihin. Luonnollisesti joitakin menoja kuten Wappua ei voi siirtää, tai suorittaa osissa.

Ohjelma siis pitää kirjaa työpäiville ja työviikoille suunnitellusta työkuormasta ja esteistä. Lisäksi ohjelma esittää tämän sekä opiskelijoille itselleen, että opetuksen suunnittelijoille ja opettajille.

Vaikka varsinainen projekti onkin järkevintä toteuttaa verkkopalveluna, rakennamme ensimmäisen prototyypin, jolla voidaan kokeilla konseptin toimivuutta, työpöytäsovelluksena. Verkossa toimivan projektin pääsee kasaamaan vaikkapa kurssilla CSE-C3210 Web Software Development.

Vaatimusmäärittelyistä ja mallinnuksesta

Tosielämässä projektista tehtäisiin selvästi tarkempi vaatimusmäärittely ennen töiden aloittamista, mutta perehdymme nyt ohjelmien mallinnukseen ja toteutukseen. Vaatimusmäärittelystä ja mallinnuksesta voi opiskella lisää vaikkapa kursseilla CSE-C3600 Software Design and Modelling ja CSE-C3610 Software Engineering

Kuinka pitäisi edetä?

Vähänkin suuremman ohjelman kohdalla on hyvä idea suunnitella ja mallintaa ohjelman rakennetta ja pohtia eri vaihtoehtoja ennen kuin syöksyy näppäimistölle. Tällä säästää todennäköisesti paljon turhaa työtä.

Suunnitteluun ei ole olemassa kaiken kattavaa parasta tapaa tehdä asia, aivan kuten ohjelman kirjoittamiseenkaan ei ole. Suunnittelu myös jatkuu läpi ohjelman toteutuksen, sillä asiakas voi päivittää vaatimuksiaan tai toteuttaessa ohjelmaa havaitaan että suunnitelmaa kannattaa muuttaa, jotta saadaan parempi lopputulos tai yleensä ottaen saadaan projekti valmiiksi.

Ad-hoc mallinnusta - Substantiivimetodi / verb-noun method

Verbi-substantiivimenetelmä (noun method, noun-phrase approach, noun-verb method etc.) on usein esitelty tekniikka tehdä ensimmäinen karkea malli ohjelman luokkarakenteesta. Mallin ei ole tarkoitus olla mitenkään täydellinen ratkaisu ongelmaan, vaan tarjota aloituspiste, josta suunnitelmaa lähdetään muokkaamaan.

Menetelmästä löytyy runsaasti hieman erilaisia versioita, mutta sen ensimmäiset vaiheet toimivat periaattessa seuraavasti:

  1. Kirjoitetaan lyhyehkö mutta tarkka sanallinen kuvaus ohjelman toimintavaatimuksista. Käyttöliittymään liittyvät asiat jätetään tässä vaiheessa tietoisesti pois.

  2. Etsitään kuvauksesta kaikki substantiivit ja pyritään ryhmittelemään näistä ohjelmamme luokkia ja niiden ilmentymämuuttujia (instance variable, field).

    • On helppo huomata, että osa substantiiveista voidaan hylätä suoraan. Osasta luokkia asia selviää vasta myöhemmin.
    • Ne asiat joille voi laatia omia hyödyllisiä kenttiä ovat potentiaalisia luokkia. Muut ovat usein luokkien kenttiä jotka viittaavat muiden määrittelemimme luokkien ilmentymiin, tai kuvataan Pythonin tarjoamia tyyppejä käyttäen.
    • Myöhemmin voi osoittautua, että on tarpeen tai hyödyksi laatia “teknisiä apuluokkia”, joilla ei ole suoraa vastinetta “reaalimaailmassa”. Liikkeelle lähdetään luokkarakennetta laadittaessa kuitenkin juuri aihealueen käsitteistöstä.
  3. Etsitään tekstistä verbit. Näiden joukosta löytyvät taasen potentiaaliset metodit
    • Karsitaan jälleen heti aluksi turhat verbit pois.
    • Sijoitetaan tämän jälkeen toiminnot (metodit) sinne missä niiden käsittelemä data on.
    • Vihjeitä metodien sijoituspaikasta saa siitä, mitä tietoa ne käsittelevät. Kannattaa pohtia mihin muuttujiin eri toimintojen ohjelmassa tulisi vaikuttaa, ja minkä muuttujien arvoja ne tarvitsevat toimiakseen.

Entäs ne muut sanat?

Joissakin tämän menetelmän variaatioissa otetaan kantaa myös adjektiiveihin tai adverbeihin, joita mallinnetaan joskus instanssimuuttujilla, joskus taas piirreluokilla.

Lopputuloksena on alustava malli, josta puuttuu vielä paljon. Kun ensimmäinen malli on saatu pohdittua niin sitä ryhdytään muokkaamaan ja tarkistetaan voidaanko sen avulla todella toteuttaa vaatimukset.

  1. Luokista puuttuu varmasti instanssimuuttujia ja välttämättömiä metodeja, joita voi tarvittaessa lisätä. Myös kokonaisia luokkia varmasti puuttuu, niitä täytyy yhdistellä, tai jakaa paloihin, jne. Näitä voidaan tässä vaiheessa lisätä ja poistella mallista varsin pienellä vaivalla.

No onko tähän jotain käteviä työkaluja?

Tähän vaiheeseen ei oikeastaan tarvita mitään dedikoituja välineitä. Ehkä tehokkain työkalu sanojen etsintään ja lajitteluun on käyttää vaikkapa tussitaulua ja läjää Post-it lappuja. Sanat voi kirjoitella lapuille ja hoitaa ryhmittelyn liikuttelemalla niitä taululla. Yhtälailla sanan homman voi tehdä paperilla, tai vaikkapa taulukkolaskentaohjelmassa, jossa jokaiselle luokalle voi tehdä oman kolmunin ja raahailla sanoja paikasta toiseen.

Kun lopputulos alkaa vaikuttaa hyvältä, voidaan mallista piirtää UML-luokkakaavio jolla on kätevämpää kuvata luokkien välisiä suhteita ja saada kokonaiskuva ohjelmasta. Syksyn kurssilla tämäntyyppisiä kaavioita on käytetty jo monesti, vaikka asiasta ei olekaan erikseen mainittu. Tutustumme UML:n (Unified Modeling Language) luokkakaavioon heti seuraavassa luvussa.

Esimerkki: Timelinerin mallinnusta substantiivimenetelmällä

Yliviivataan substantiivit vihreällä, mutta ei yliviivata samoja substantiivejä useaan kertaan. Tarvittaessa tarkennetaan joitain substantiiveja lisäämällä niihin määreitä.

../_images/substantiivit.png

Substantiivit (yksikössä):

ongelma, työpiikki, päivä, tunti, työ, opiskelija, opettaja, suunnittelija, työkalu, taho, kurssi, luento, tentti, harjoitus, tapaaminen, kaikki opiskelijan aikaa vievä, kalenteri, lukukausi, määräaika, suunnitteluvaihe, ominaisuus, ohjelma, mahdollisuus, osa, projekti, projektityö, julkaisuhetki, väli, paikka, meno, Wappu, työpäivä, työviikko, työkuorma, este

Kirjoitetaan substantiivit lapuille, ja laitetaan ne ryhmittelyä varten taululle.

../_images/timeliner-laput-v00.jpg

Kaikki löydetyt substantiivit eivät varmaankaan ole yhtä hyödyllisiä ohjelman luokkien tunnistamisessa. Lisäksi voi olla, että kaikkia tärkeitä luokkia ei edes suoraan ole mainittu. Miten oikein keksimme tarvittavat luokat lappujen avulla?

Lähdetään liikkeelle ryhmittelemällä substantiiveja joidenkin yhteisten aihepiirien alle. Tämä tuskin ensiyrittämällä tuottaa täydellistä lopputulosta, mutta pääsemme luultavasti hieman eteenpäin.

Osa substantiiveista kuvaa aikaa. Kootaan kaikki aikaan liittyvät laput samaan ryhmään. Lisätään substantiiviin väli tarkennus, että kyseessä on julkaisuhetken ja määräajan väli.

Aika:

päivä, tunti, lukukausi, määräaika, suunnitteluvaihe, julkaisuhetki, (julkaisuhetken ja määräajan) väli, työpäivä, työviikko,

Ihminen:

Toinen ryhmä liittyy ihmisiin. Tarkennetaan substantiivi taho muotoon muu taho (kuten tekstissä oli), jotta on helpompi ymmärtää kyseessä olevan ihminen.

opiskelija, opettaja, suunnittelija, (muu) taho,

Kalenteri:

Kolmas ryhmä liittyy kalentereihin. Tarkennetaan paikka kalenterissa olevaksi paikaksi, sillä kyseessä ei ole mikä tahansa paikka.

kalenteri, paikka (kalenterissa)

Tekeminen:

Neljäs ja kaikkein suurin ryhmä liittyy tekemisiin, joita ihmiset tekevät, jotka vievät aikaa ja jotka on tarkoitus sopivasti saada sijoiteltua kalentereihin. Tehdään myös substantiiville osa tarkennus muotoon (projektityön) osa, että erotamme sen muista osista.

kurssi, luento, tentti, harjoitus, tapaaminen, kaikki opiskelijan aikaa vievä, (projektityön) osa, projekti, projektityö, meno, Wappu, työkuorma, este, työpiikki

Hylätty:

Joukko substantiiveja jäi ylitse. Ne eivät vaikuta oleellisilta, koska ne eivät liity käsiteltävään ongelma-alueeseen vaan tähän suunnitteluprosessiimme. Hylätään nämä sanat tässä vaiheessa.

ongelma, työkalu, ohjelma, mahdollisuus, ominaisuus

Tässä vaiheessa meillä on siis seuraava ryhmittely:

../_images/timeliner-laput-v01.jpg

Katsotaan ryhmiä tarkemmin ja yritetään tunnistaa luokkia.

Aikaan liittyvät substantiivit näyttävät kuvaavan joko yksittäisiä ajanhetkiä (määräaika, julkaisuhetki) tai aikavälejä (päivä, tunti, lukukausi, työpäivä, työviikko, suunnitteluvaihe, (julkaisuhetken ja määräajan) väli). Kullakin aikavälillä on alkuhetki ja loppuhetki. Tuntuisi siis, että tarvitsemme ainakin luokat ajanhetki ja aikaväli. Hyvällä onnella nämä saattavat jopa löytyä valmiina kirjastoluokkina. Ei ole selvää, tarvitsemmeko erikseen luokkia esim. päivää, tuntia ja lukukautta varten vai riittäkö pelkkä aikaväli. Jos esim. osoittautuu, että päivällä on joitain kenttiä joita aikavälillä ei ole, on perusteltua määrittää päivä omaksi aikavälin alaluokaksi. Vastaavasti mäöräaika ja julkaisuhetki voisivat olla ajanhetken aliluokkia, mutta ei ole vielä selvää tarvitseeko niitä määrittää. Ei tehdä lopullista päätöstä vielä tästä. Yleensäkin suunnittelussa ei kannata tehdä lopullisia valintoja epäselvissä tilanteissa.

Entä tekemisiin liittyvät substantiivit? Nämä kuvaavat pääosin opiskeluun ja opettamiseen liittyvää tekemistä vaikka mukana on myös muita asioita kuten työ, este, työkuorma ja Wappu. Yritetään ensin saada tolkkua opetukseen ja opiskeluun liittyvistä luokista.

Ongelman kuvauksen perusteella tärkeä substantiivi näyttäisi olevan kurssi. Siihen näyttää liittyvän opettaja ja joukko opiskelijoita, jotka ovat ottaneet kurssin. Ongelman kuvauksen perusteella luento, tentti, harjoitus, tapaaminen ja projekti kuuluvat johonkin kurssiin. Yhdellä kurssilla varmaankin voi olla vaihteleva määrä näitä. Tunnistamme uuden luokan kurssin osa, jota ongelman kuvauksessa ei ole mainittu, mutta joka kuvaa mitä tahansa kurssiin kuuluvaa tekemistä, esimerkiksi luentoa tai tenttiä. Voimme kenties määrittää, että luento jne. ovat kurssin osan aliluokkia. Ei ole vielä selvää, onko tämä kannattavaa, joten ei tehdä lopullista päätöstä. Ongelman kuvauksesta käy ilmi, että esimerkiksi projektityö voidaan edelleen jakaa osiin. Oletetaan, että muitakin kurssin osia voi jakaa osiin. Näin voidaan pudottaa ryhmästä pois (projektityön) osa ja korvata se yleisemmällä luokalla osatekeminen.

Voimme vielä tehdä kalenterista ja ihmisestä omat luokkansa. Opettaja, opiskelija, suunnittelija ja muu taho voivat tarvittaessa olla ihmisen alaluokkia.

Tämän vaiheen tuloksena olemme saaneet alla olevan kuvan mukaisen jaottelun. Kuvassa olemme ympäröineet yhtenäisellä vihreällä viivalla tunnistamamme luokat. Vihreän pilkkuviivan sisällä on näiden mahdolliset aliluokat (emme vielä ole varmoja, tarvitsemmeko niitä). Sinisellä pilkkuviivalla on ympäröity substantiivit, joita emme vielä ole käyttäneet emmekä hylänneet.

../_images/timeliner-laput-v02.jpg

Luokat:

Tässä vaiheessa meillä on alustava lista luokkia:

ihminen, ajanhetki, aikaväli, kalenteri, kurssi, kurssin osa, osatekeminen

Katsotaan seuraavaksi verbejä ja alleviivataan ne punaisella.

../_images/verbitkin.png

Kirjoitetaan verbit perusmuodossa.

Verbit:

ratkaista, sijoittua, olla, suunnitella, toteuttaa, sijoittaa, näkyä, tietää, ottaa, näyttää, tulla, antaa, jakaa, sijoittaa, raahata, siirtää, suorittaa, pitää-kirjaa, esittää

Samoin voimme hylätä osan verbeistä jo tässä vaiheessa. Verbit “ratkaista” ja “tulla” kuvaavat ohjelman kehitysprosessiin liittyvää tekemistä eikä ohjelman tekemää toimintaa. “Olla” verbillä kuvataan monenlaisia asioita, jotka kuitenkaan eivät ole toimintaa (ks. oheinen tekstilaatikko)

Nyt jäljelle jääneistä verbeistä pitäisi muodostaa metodeja.

Verbiä sijoittaa käytetään ongelman kuvauksessa seuraavasti: “opettajat ja muutkin tahot voivat sijoittaa kurssiensa luentoja, tenttejä, harjoituksia, tapaamisia, projekteja, eli yleensä ottaen kaikkea opiskelijan aikaa vievää, kalenteriin”. Tässä kohtaa huomaamme, että voisi olla parempi käyttää “opiskelijan aikaa vievää” asiaa kuvaamaan jotain yleisempää luokkaa kuin aikaisemmin määrittämämme kurssin osa. Sivuun laittamistamme lapuista löytyy substantiivi työ, joka sopii tähän. Määritämme siis luokan työ ja teemme siitä luokan kurssin osa yläluokan. Verbiä sijoittaa vastaamaan voimme määritellä metodin sijoitaTyö joka ottaa parametrinaan kalenterin ja työn. Arvatenkin haluamme myös pystyä poistamaan töitä kalenterista, joten määritetään vastaavasti metodi poistaTyö. Havaitsemme samalla, että kalenteri on säiliöluokka luokan työ ilmentymille.

Verbiä näkyä käytetään seuraavasti: “nämä [kaikki opiskelijan aikaa vievä] näkyvät sekä oppilaille että muille opettajille”. Ohjelman kannalta tämä näkyminen tarkoittaa, että kalenterin sisältämät työt voidaan lukea jollain metodilla. Nimetään tämä metodiksi lueTyöt, joka ottaa parametrinaan kalenterin ja palauttaa kalenterin sisältämät työt.

Verbiä ottaa käytetään kuvauksessa näin: “mitä kursseja opiskelijat samana lukukautena ottavat”. Mitä ohjelmamme kannalta tarkoittaa, että opiskelija ottaa kurssin? Varmaankin kurssiin sisältyvät työt (luennot, tentit, harjoitukset jne.) sijoitetaan opiskelijan kalenteriin.

Tässä kohtaa huomaamme, että opiskelija tarvitsee oman kalenterin, jonne töitä voi lisätä. Määritetään metodi otaKurssi, joka saa parametrina opiskelijan ja kurssin ja joka lisää kurssin työt opiskelijan kalenteriin. Jos kullakin opiskelijalla on kalenteri, missä on hänen työnsä niin pitäisikö kaikilla ihmisillä olla vastaava henkilökohtainen kalenteri? Voinemme liittää kuhunkin ihmiseen henkilökohtaisen kalenterin. Mutta mikä kalenteri on se, johon opettaja sijoittaa kurssiin liittyviä töitä? Voisimme kenties sijoittaa nämä opettajan henkilökohtaiseen kalenteriin, mutta on ehkä siistimpää tehdä jokaiselle kurssille oma kalenteri, joka sisältää kurssin työt.

Verbiä näyttää käytetään seuraavasti: “näyttää kursseja ottavien opiskelijoiden muut määräajat opettajalle jo suunnitteluvaiheessa”. Kyse on siis määräaikojen näyttämisestä. Määritetään metodi näytäMuutMääräajat, jonka parametreina on kurssi ja joka antaa tuloksena joukon ajanhetkiä. Nämä määräajat ovat siis eri työtehtäviin liittyviä määräaikoja. Voidaan siis päätellä, että luokan työ ilmentymiin liittyy määräaika. Saimme siis vihdoin ratkaistua aiemman avoimen ongelman, pitääkö määräajan olla luokka: Ei tarvitse, vaan kyseessä on luokan työ ilmentymän ominaisuus. Samaten voimme tehdä tekstissä mainitusta julkaisuhetkestä ominaisuuden. Määräaika ja julkaisuhetki ovat siis työhön liittyviä ominaisuuksia, jotka rajaavat aikavälin, jona työ tehdään. Koska julkaisuhetki ja määräaika esiintyvät tässä pareittain, voimme korvata ne yhdellä ominaisuudella aikarajoite, joka on luokan aikaväli ilmentymä. Työhön liittyy yleensä myös arvioitu kesto, joka voi olla joko lyhyempi tai yhtä pitkä kuin aikarajoite.

Verbiä jakaa käytetään kuvauksessa näin: “opiskelijoille annetaan mahdollisuus jakaa vaikkapa projektityön tunnit haluamiinsa osiin ja sijoittaa projektin julkaisuhetken ja määräajan välille”. Kyseessä ei välttämättä tarvitse olla projektityön vaan minkä tahansa työn jakamisesta osiin. Määritetään metodi jaaTyöOsiin , joka ottaa parametrina työn ja tuottaa tuloksenaan joukon luokan osatekeminen ilmentymiä. Mutta mistä metodi tietää, millaisiin osiin työ jaetaan? Emme tässä vaiheessa määritä mitään algoritmia tähän, mutta varaudumme erilaisiin tapoihin määrittämällä luokan jakoPolitiikka, jonka ilmentymä annetaan myös parametrina metodille jaaTyöOsiin.

Verbiä siirtää käytetään näin: “joitakin menoja kuten Wappua ei voi siirtää, tai suorittaa osissa”. Tässä meno lienee työn synonyymi. Siirtäminen voidaan toteuttaa aiemmin määritetyillä metodeilla poistaTyö ja sijoitaTyö. Tekstistä kuitenkin käy ilmi, että tämä ei ole aina sallittua. Liitämme luokkaan työ kentät jaettavissa ja siirrettävissä.

Käyttäjätarinat

Ketterissä menetelmissä (agile methods) ohjelman vaatimuksia voidaan kuvata ns. kayttäjätarinoiden kautta. Käyttäjätarina on muodoltaan epäformaalimpi kuin käyttötapauskuvaus, jotka ovat toinen yleinen tapa kuvata käyttöskenaarioita. Vaikka käyttäjätarinan ei tarvitsekaan olla yksittäinen virke, ovat ne usein tietoisesti lyhyitä ja mielellään tarinasta pitäisi olla helppo muodostaa testitapaus. Käyttäjätarinan kirjoittaa yleensä asiakas, kun taas käytötapauskuvaus kirjoitetaan projektin kehittäjän ja asiakkaiden yhteistyönä.

käyttäjätarinoita Timeliner-projektistamme

  1. “Opettajana, haluaisin luoda kurssilleni tentin.”
  2. “Opettajana, haluaisin editoida vain omien kurssini tehtävien työkuormia. Muut eivät saa editoida kurssejani.”
  3. “Oppilaana, haluan että valitessani kurssin sen kaikki tapahtumat ilmestyvät kalenteriini.”
  4. “Oppilaana, haluan pystyä jakamaan projektityön tunnit useammalle viikolle.”
  5. “Oppilaana, haluaisin että tekemäni muutokset tallentutuvat automaattisesti ilman erillistä tallentamista.”
  6. “Oppilaana, haluaisin että ohjelma muistuttaisi minua kun määrittelemäni työtehtävä lähestyy.”
  7. “Opetuksen suunnittelijana, haluaisin nähdä koulutusohjelman koko vuosikurssin työkuorman jollain tavalla kootusti.”
  8. “Opettajana, haluaisin saada varoituksen jos joku sijoittaa pakollisen menon jonkin kurssini työtehtävän läheisyyteen.”
  9. “Opettajana, haluaisin nähdä milloin oppilaat aikovat tehdä kurssini suorituksia.”

Ketterät menetelmät eivät painota etukäteissuunnittelua, vaikka niidenkin tapauksessa jonkinlainen ensimmäinen malli ohjelmasta onkin luotava. Tyypillistä näiden menetelmien filosofialle on, että ohjelman suunnitelma sekä saa että sen tuleekin elää ohjelman kehityksen aikana.

Tutustutaan seuraavaksi Responsibility-Driven Design -menetelmään sekä CRC-kortteihin ja kokeillaan muutaman yllä listatun käyttäjätarinan avulla, kuinka hyvin substantiivimenetelmällä muodostetut luokat toimivat tässä yhteydessä.

CRC-kortit ja Responsibility-Driven Design

CRC, Class-Responsibility-Collaborators -menetelmä, (Beck, Cunningham 1989) rakentuu vastaavasti nimettyjen CRC-korttien varaan. Jokaisessa kortissa on kolme osiota, luokan nimi kortin yläosassa, luokan vastuut kortin vasemmassa laidassa ja luokan yhteistyökumppanit oikeassa. Vastuut ovat asioita, jotka kortissa kuvattu luokka lupaa hoitaa muiden luokkien puolesta. Ja kun luokka tarvitsee tietoa tai toiminnallisuutta, jotka jokin muu luokka toteuttaa, kirjataan nämä oikeanpuoleiseen kenttään.

RDD, Responsibility-Driven Design on oliosuuntautunut suunnittelumenetelmä, joka korostaa käyttäytymistä ja joka toimii hyvin CRC-korttien kanssa. Prosessi jolla kortteja luodaan ja niiden kuvaamien luokkien toimivuutta kokeillaan on eräänlaista korttipeliä. Kun alustavat luokat ovat olemassa, kokeillaan niiden toimintaa suorittamalla erilaisia käyttötapauksia.

Kokeillaan

Valitaan yllä kuvatuista Timeliner-projektin käyttäjätarinoista ensimmäinen. Kun tarinaa käydään läpi, kortteja täytetään samalla: vastuita ja luokkien välisiä suhteita lisätään, kuten myös täysin uusiakin luokkia. Vastaavasti voidaan tehdä muutoksia jo olemassaoleviin luokkiin, siirtää vastuita jne., pilkkoa luokkia pienempiin osiin tai yhdistää niitä.

“Opettajana, haluaisin luoda kurssilleni tentin.”

Ohitetaan tässä kaikki käyttöliitymään liittyvä ja oletetaan, että meillä on lähtötilanteessa opettajan kurssiolio.

Tentti on kurssin osa (KurssinOsa). -> Tarvitsemme siis olion, joka kykenee luomaan kurssin osia. Luonnollisimmalta tuntuisi, että tästä vastaisi Kurssi -olio. (Merkitään tämä Kurssi-luokan vastuisiin.)

Hmm.. Kurssiolioon liittyy oma Kalenteri ja tentti varmaankin pitäisi lisätä tähän kalenteriin. (Merkitään Kalenteri Kurssi-luokan yhteistyökumppaneihin.) Kuten aiemmin todettiin, Työ on KurssinOsan yläluokka ja työhön sisältyy aikarajoite, jona työ tehdään sekä arvioitu kesto. (Kirjataan nämä kortteihin.) Todetaan lisäksi, että tentin tapauksessa arvioitu kesto on sama kuin aikarajoitteen pituus.

Onko vielä jotain erityisesti tenttiin liittyvää? Substantiivimenetelmän yhteydessä noteerattiin että opiskelija tulee siirtämään ja jakamaan kurssin töitä omaan kalenteriinsa. Tenttiin osallistumisen kohdalla tämä ei tietenkään saa olla mahdollista, joten KurssinOsan täytyy pitää kirjaa jaettavissa ja siirrettävissä olemisesta. (Kirjataan nämä asiat KurssinOsa:n vastuisiin)

Tarkina kannattaa nyt käydä läpi uudelleen niin että todella “näyttelee” kunkin luokan tehtävät ja kokeilee että kaikki oleellinen tuli merkattua muistiin. Kokeneemmat menetelmän käyttäjät kehoittavat välttämään kiirettä.

Ensimmäisen tarinan jälkeen kortit näyttävät tältä:

../_images/crc.jpg

On selvää, että luokissa on vielä paljon tehtävää. Harjoitusta voi jatkaa itsenäisesti tai parin kanssa eteenpäin - tuotoksille, eli mallinnetuille luokille löytyy käyttöä seuraavan luvun tehtävässä, jossa niistä piirretään kaavio.

Yhteenvetoa

  • Ohjelman suunnittelu on prosessi joka jatkuu läpi ohjelman elinkaaren
  • Suunnittelu ei ole helppoa tai suoraviivaista ja sitä oppii ensisijaisesti tekemällä. Kokeneilla ohjelmoijilla on (muistissaan) käytössä valmiita ratkaisumalleja, skeemoja, joita he osaavat suunnitellessaan tunnistaa ongelma-alueesta ja tällöin soveltaa tuntemiaan rakenteita ja menetelmiä.
  • Verb-noun method tarjoaa yhden tavan löytää lähtökohta suunnittelulle. Se tuottaa alkuarvauksen tarvittavista luokista.
  • Responsibility-driven design on menetelmä, jolla käyttäjien kuvaamaa toimintaa simuloiden voidaan kokeilla ja tarkentaa suunnitelmaa tarvittavista luokista.

Tulevaa

  • Seuraavassa luvussa tutustutaan UML-luokkakaavioon, jolla voidaan visualisoida ja dokumentoida suunnittelemaamme luokkarakennetta.
  • Luvussa 2.1 katsotaan kuinka suunnitelmaa voidaan ryhtyä toteuttamaan.
  • Luvussa 2.2 katsotaan yksikkötestausta, jolla osaltaan voidaan varmentaa että ohjelma tekee mitä se lupaa.