Muuttujien roolit noviisien kirjoittamissa C- kielisissä ohjelmissa

Transkriptio

1 Muuttujien roolit noviisien kirjoittamissa C- kielisissä ohjelmissa Samppa Timonen Joensuun yliopisto Tietojenkäsittelytiede Pro gradu -tutkielma

2 Tiivistelmä Tietokoneohjelmaa voidaan tarkastella laskennallisesta tai psykologisesta näkökulmasta. Laskennallisesta näkökulmasta tietokoneohjelma on tekstiä, jonka tarkoituksena on kuvata tietokoneen tulkittavissa olevassa muodossa tietorakenteita ja toimenpiteitä tietyn funktion laskemiseksi. Psykologisesta näkökulmasta tietokoneohjelma on moniulotteinen kokonaisuus ja keskeisenä tarkastelun kohteena on ohjelman lukijan kyky ymmärtää ohjelman toimintaa ja tunnistaa sen osat. Noviisiohjelmoijilta puuttuu ohjelmointikokemuksen mukanaan tuoma kyky nähdä ohjelmien toimintaa syvällisesti. Eksperttiohjelmoija kykenee ohjelmointikokemuksensa kautta syntyneiden mentaalisten mallien avulla hahmottamaan ohjelman syvärakenteita. Koska noviiseilta puuttuu kyky tunnistaa syvärakenteita, he turvautuvat usein ohjelmakoodia tulkitessaan ohjelman pintatietoon. Yksi keino auttaa noviiseja hyödyntämään tavallisesti eksperteiltä löytyvää hiljaista tietoa on opettaa muuttujien rooliajattelua. Muuttujien roolien avulla noviisiohjelmoija voi tulkita ja keskustella ohjelman toiminnasta ilman, että hänen tarvitsee puuttua ohjelman syntaktisiin yksityiskohtiin. Muuttujien rooleihin liittyneen, opettajilla suoritetun kokeen perusteella voidaan todeta, että muuttujan roolit ovat mielekkäitä ja niitä voidaan käyttää ohjelmien toiminnan kuvaamiseen. Muuttujien rooleja on tutkittu aiemmin eri ohjelmointiparadigmoihin liittyen. Tässä opinnäytetyössä tarkastellaan roolien esiintymistä proseduraalista ohjelmointiparadigmaa edustavassa C-kielessä. Tarkastelemalla C-kielisten harjoitustöiden muuttujien rooleja on pyritty selvittämään, missä määrin noviisitasoisten C-kielisten ohjelmien sisältämien muuttujien roolien suhde vastaa samaa paradigmaa edustavan Pascal-kielen roolien esiintymien suhdetta. Tämän tiedon avulla voidaan päätellä, kuinka hyvin C- kielisten ohjelmien muuttujien roolit vastaavat sen ohjelmointiparadigman mukaista roolien suhdetta. ACM-luokat (ACM Computing Classification System, 1998 version): D.m., K.3.2 Avainsanat: muuttujien roolit, C-kieli, ohjelmointi, noviisi i

3 Esipuhe Pro gradu -tutkielman kirjoittaminen on ollut minulle prosessi, jonka aikana olen oppinut käsittelemieni aiheiden ja tieteellisen ilmaisutavan lisäksi myös paljon itsestäni. Elämäntilanne ja omat valinnat ovat omalta osaltaan vaikuttaneet siihen, miltä tällaisen tutkielman kirjoittamisen vaatima aika ja työmäärä ovat tuntuneet. Epävarmuus ja innostuneisuus ovat vuoroin painostaneet ja kannustaneet eteenpäin, mutta minulla on myös ollut onni saada olla tekemisissä sellaisten ihmisten kanssa, jotka ovat antaneet tukensa yritykselleni saada tutkielma tehdyksi. Haluan kiittää tutkielmani ohjaajaa, lehtori Marja Kuittista sekä professori Jorma Sajaniemeä kannustuksesta ja joustavuudesta. Näillä tekijöillä on ollut suuri merkitys tämän työn valmistumisessa. Kiitokset myös perheelleni, jonka nuorimmat jäsenet kokivat tilanteen varmastikin isän läsnäolon merkittävänä vähentymisenä. Jyväskylässä kesäkuussa 2008 Samppa Timonen ii

4 Sisältö 1 Johdanto 1 2 Ohjelmoinnin kognitiivista taustaa Tietokoneohjelman käsite Tietokoneohjelma psykologisesta näkökulmasta Erilaiset ohjelmoijatyypit 6 4 Muuttujien roolit käsitteenä Roolit Roolijoukkion kehittyminen Roolien käyttö eri ohjelmointiparadigmoissa Roolien esiintyminen ja omaksuminen Roolien esiintyminen eri paradigmoissa Opettajien roolien omaksuminen Roolien kuvaukset Muuttujien roolit ja ohjelmointi C-kielellä 30 7 Muuttujien roolit C-kielisissä harjoitustöissä Aineisto ja roolituksen suorittaminen Tulosten tarkastelu Yhteenveto 43 Viitteet 45 iii

5 1 Johdanto Aloittelevat ohjelmoijat pitävät usein ohjelmien rakenteen ja ohjelman osien keskinäisten vuorovaikutussuhteiden ymmärtämistä vaikeana. Ohjelmoinnin opetuksessa, kuten myös ohjelmoinnin oppaissa, on ohjelmointikielen yleisen kuvailun kautta siirrytty ohjelman osasten ja ohjelmointikielen syntaksin opetteluun. Jotta ohjelmoinnin oppimista voitaisiin tehostaa, tutkijoiden täytyy perehtyä siihen, millaista tietoa ohjelmoija käyttää hyväkseen ohjelmoidessaan, miten tieto jäsentyy mielessä. Ohjelmoinnin kognitiivisen tutkimuksen avulla on pyritty selvittämään niitä mielen mekanismeja, jotka vaikuttavat ohjelmien tulkintaan ja laadintaan. Ohjelmointi on hyvin monimutkaista toimintaa, jossa ohjelmoija käyttää hyväkseen esimerkiksi muistia, päättelyä, käsitteitä ja havaintoja. Tästä syystä ohjelmointiin liittyvä mielen tapahtumien ja aivojen tietojenkäsittelyn tutkiminen on hyvin haasteellista. Muuttujien roolien tutkimuksella on tavoitteena luoda yksittäisten ohjelmointikielten syntaksista ja käytetyistä algoritmeista riippumaton keino kuvata ohjelman toimintaa. Tällöin ohjelmoijalle syntyy tietoa, jota voidaan soveltaa ohjelmiin, jotka on kirjoitettu eri kieltä tai ohjelmointiparadigmaa käyttäen. Muuttujien rooleja on tutkittu eri ohjelmointikielten ja paradigmojen suhteen. Yhtenä tavoitteena on osoittaa, että muuttujien rooleja voidaan käyttää kieli ja paradigmariippumattomasti. Tämä työ pyrkii selvittämään tällaista riippumattomuutta yhden ohjelmointikielen osalta. Tämän tutkielman tavoitteena on tarkastella muuttujien rooleja ja ottaa mukaan tarkasteluun proseduraalista ohjelmointiparadigmaa edustava C-kieli. Aihetta lähestytään ensin ohjelmointiin liittyvien kognitiivisten käsitteiden kautta. Seuraavaksi tarkastellaan eritasoisten ohjelmoijien eroavaisuuksia. Tämän jälkeen syvennytään muuttujien roolien käsitteeseen, roolien oppimiseen ja niiden käyttökelpoisuuteen ohjelmoinnin opetuksen näkökulmasta. Muuttujien rooleihin tutustumisen jälkeen siirrytään tarkastelemaan muuttujien rooleja C-kielisiin ohjelmiin liittyen. Lopuksi tarkastellaan C- kielisten ohjelmien analysoinnista saatuja, muuttujien rooleihin liittyviä tuloksia ja verrataan niitä samaa paradigmaa edustavan Pascalin tuloksin. 1

6 2 Ohjelmoinnin kognitiivista taustaa Jotta voisimme ymmärtää, mitä ohjelmoinnin tai ohjelman tulkinnan aikana mielessä tapahtuu, täytyy ensin ymmärtää millä eri tavoilla tietokoneohjelma voidaan hahmottaa. Tarkastelemme seuraavaksi tietokoneohjelman käsitettä ja erityisesti tietokoneohjelmaa psykologisesta näkökulmasta. 2.1 Tietokoneohjelman käsite Tietokoneohjelman käsitettä voidaan tarkastella kahdesta eri näkökulmasta, jotka ovat laskennallinen ja psykologinen näkökulma. Détiennen (2002) mukaan tietokoneohjelma on syntaktisesti ajatellen tekstiä, joka on muodostettu tarkkaan määritellyn kielioppisääntöjen joukon mukaan. Ohjelmien semantiikkaa ajatellen tietokoneohjelma kuvaa laskentaa tai laskentojen joukkoa. Détienne mainitsee Pairin kuvailleen ohjelmointia toiminnaksi, jossa jotain tiettyä funktiota kuvaavat määrittelyt muunnetaan ohjelmaksi. Toisin sanoen ohjelma on tekstiä, jota tietokone pystyy tulkitsemaan kyseessä olevan funktion laskemiseksi. Tietokoneohjelma laaditaan ohjelmointikielellä, joka edustaa jotain tiettyä ohjelmointiparadigmaa. On olemassa myös ohjelmointikieliä, joilla voidaan ohjelmoida useamman eri paradigman mukaan. Ohjelmointiparadigmoja ovat esimerkiksi proseduraalinen, funktionaalinen ja olio-ohjelmointiparadigma. Jokaisessa ohjelmointiparadigmassa on omat ominaispiirteensä, joiden suhteen ne erottuvat muista ohjelmointiparadigmoista. Kaikkien imperatiivisten, toisin sanoen proseduraalisten, ohjelmointikielten peruspiirteisiin kuuluu kolme ohjausrakennetta, jotka ovat toisto, peräkkäisyys ja valinta. Toiston avulla ohjelman osia voidaan suorittaa uudelleen, mikäli toistolle määritelty ehto tai ehdot täyttyvät. Peräkkäisyys mahdollistaa ohjelman suorituksen etenemisen ja valinnan avulla voidaan ohjata laskentaa ohjelman algoritmiin liittyvän ehdon mukaan. Ohjausrakenteiden lisäksi myös muuttujat liittyvät olennaisesti imperatiivisten ohjelmointikielten peruskäsitteistöön. Toisena esimerkkinä voidaan mainita olio-ohjelmat. Olio-ohjelma voidaan nähdä kokoelmana olioita, jotka ovat vuorovaikutuksessa keskenään, piilottaen sisäisen toimintansa ja tarjoten julkisen rajapinnan tietojen vaihtoon ja olion tilan muutoksiin. Toisto voidaan toteuttaa oliomaisesti iteraattoreilla, kun taas 2

7 proseduraalisessa ohjelmassa käytetään toistoon erityisiä toistolauseita. Détienne (2002) kuvailee tietokoneohjelmaa kaksijakoiseksi kokonaisuudeksi. Ohjelma on laskennan tai tietyn proseduurin kuvaus käyttäen kyseessä olevaa ohjelmointikieltä, mutta se myös kuvailee kyseisessä tapauksessa käytettäviä olioita. Détienne käyttää tässä yhteydessä olio-käsitettä siten, että se sisältää myös tietorakenteet. Ohjelman laadinta koostuu näin ollen laskennan suorittamiseen tarvittavien vaiheiden muuttamisen algoritmeiksi ja algoritmin suorittamiseksi tarvittavien olioiden määrittelystä. Détienne viittaa Wirthin määritelmään, jonka mukaan tietokoneohjelma koostuu algoritmista ja tietorakenteista. Koska tietokoneohjelma on algoritmin ja tietorakenteiden muodostama ilmaus jollain ohjelmointikielellä, se on samalla myös tekstiä. Tällä seikalla on ollut Détiennen (2002) mukaan voimakas vaikutus tapaan, jolla ohjelmien ymmärtämiseen liittyvää tutkimusta on suoritettu. Esimerkiksi ohjelmien ymmärtämiseen liittyvässä tutkimuksessa käytetään hyväksi malleja, jotka ovat peräisin luonnollisiin kieliin liittyvästä tutkimuksesta. Ohjelmointikielet eroavat kuitenkin luonnollisista kielistä esimerkiksi siten, että ohjelmointikielet ovat syntaktisesti yksiselitteisiä. Toinen ero on luonnollisissa kielissä käytettävistä epäsuorista viittauksista pronominien avulla. Tekstinäkökulmaa ajatellen tietokoneohjelma voidaan nähdä kerronnallisena tai proseduraalisena tekstinä. Ohjelman ymmärtämisessä kerronnallisena tai proseduraalisena tekstinä liittyy Détiennen (2002) mukaan kuitenkin omat heikkoutensa. Ohjelman käsittäminen kerronnallisena tekstinä voi tehdä ohjelman ymmärtämisestä vaikeaa, koska ohjelman osatavoitteet liittyvät toisiinsa tavalla, joka on epätavallista kertomuksille. Proseduraalisena teksti ei puolestaan kykene kuvaamaan ohjelman sisältämiä vuorovaikutussuhteita. Esimerkiksi koettaessaan ymmärtää ohjelmointioppaassa olevaa ohjelmaa, ohjelmoija ei mallinna mielessään varsinaista tekstiä, vaan pyrkii luomaan joukon yleiskäyttöisiä sääntöjä. 2.2 Tietokoneohjelma psykologisesta näkökulmasta Tarkastellaksemme tietokoneohjelmaa psykologisesta näkökulmasta tarvitsemme avuksi tähän soveltuvia käsitteitä. Détienne (2002) mainitsee Noam Chomskyn esitelleen ensimmäisenä kaksi ohjelmoinnin psykologiassa käytettävää käsitettä, jotka ovat pintarakenne ja syvärakenne. Käsitteet oli alun perin luotu lingvistiikan tarpeita ajatel- 3

8 len, eivätkä ole sovellettavissa suoraan tässä yhteydessä. Käsitteiden ajatus on kuitenkin hyvin samankaltainen. Détiennen (2002) mukaan ohjelman pintarakenne (surface structure) tarkoittaa ohjelman tekstuaalista rakennetta, eli ohjelmasta suoraan nähtävissä olevien osasten muodostamaa kokonaisuutta ja tapaa jolla osaset järjestetään. Tällaisia osasia ovat esimerkiksi yksinkertaiset operaatiot, proseduurien ja funktioiden osat sekä ohjausrakenteiden osat. Ohjelman syvärakenne (deep structure) tarkoittaa ohjelman sisältämiä riippuvuus- ja vuorovaikutussuhteita, joita ei voi nähdä pintarakennetta tarkastelemalla. Esimerkiksi ohjelman lauseiden syvärakennetta ovat niiden muodostamat abstraktit suhteet toisiinsa, toisin sanoen lauseiden merkityksellinen sisältö ohjelman tai sen osan tavoitetta ajatellen. Jos ajatellaan tietokoneohjelman eri esitystapoja, pintarakennetta voidaan tarkastella katselemalla ohjelmakoodin muodostamaa kokonaisuutta. Syvärakennetta voidaan vastaavasti kuvata jollain sovelluksen logiikkaa kuvaavalla tavalla, kuten esimerkiksi vuokaavion avulla. Ohjelma voidaan ajatella kokonaisuudeksi, jolla on ainakin yksi päätavoite. Ohjelman päätavoite koostuu yleensä useista osatavoitteista, joista jokaisella voi olla lisää osatavoitteita. Détiennen (2002) määritelmän mukaan plani (plan) on joukko toimintoja, joiden suorittaminen määrätyssä järjestyksessä johtaa osatavoitteen suorittamiseen loppuun. Toisin sanoen ohjelma voidaan käsittää joukoksi planeja, joista jokainen omalta osaltaan mahdollistaa ohjelman tavoitteen saavuttamisen. Planit kuuluvat yhdessä osatavoitteiden, tietovirtojen ja olio-ohjelmoinnin olioiden kanssa ohjelman syvärakenteeseen. Skeema (schema) tarkoittaa Détiennen (2002) mukaan tietorakennetta, joka edustaa muistiin tallentuneita yleisiä käsitteitä. Skeeman käsitteeseen liittyvä teoria koskee tiedon järjestäytyneisyyttä muistissa ja niitä prosesseja, joiden avulla muistissa olevaa tietoa voidaan käyttää hyväksi. Skeeman käsite syntyi tekoälyyn ja tekstin ymmärtämiseen liittyvän tutkimuksen myötä. Skeeman ja planin välistä eroa voidaan kuvata käytännön tasolla siten, että plani on joukko tapahtumia tietyssä ohjelmassa, kun taas skeema on rakenteista tietämystä. Détienne mainitseekin edistyneempien ohjelmoijien pitävän plania ohjelmointiskeeman ilmentymänä tai erikoistapauksena. Skeema voidaan käsittää muuttujien muodostamaksi rakenteeksi mahdollisine arvoineen, jolloin edellä mainittua erikoistapausta voidaan luonnehtia tiettyjen arvojen valinnaksi tietyn yksit- 4

9 täisen ohjelman tavoitteen saavuttamiseksi. Esimerkiksi ohjelmoija käyttää skeemoja pyrkiessään ymmärtämään jonkin tietyn ohjelman toimintaa. Ohjelmoija pystyy muistiinsa tallentuneiden ohjelmointiskeemojen ja ohjelmakoodista tunnistamiensa osien avulla päättelemään ainakin osittain ohjelman tai sen osan tavoitteen. Ohjelmointiin liittyvissä tutkimuksissa on tullut ilmi, että eksperttiohjelmoijat säilyttävät muistissaan tiettyihin ohjelmoinnin osa-alueisiin liittyviä skeemoja. Détienne (2002) jakaa nämä skeemat kahteen ryhmään, jotka ovat yksinkertaiset ohjelmointiskeemat ja algoritmiset tai monimutkaiset ohjelmointiskeemat. Yksinkertaiset ohjelmointiskeemat käsittävät ohjausrakenteisiin ja muuttujiin liittyvää tietoa. Algoritmiset skeemat taas liittyvät tietoon algoritmien rakenteista. Ohjelmoijalla voi olla muistissaan tietoa erilaisista lajittelualgoritmeista. Algoritmiset skeemat ovat tavallisesti ohjelmointikielestä riippumattomia ja ne voidaan nähdä rakentuvaksi yksinkertaisista ohjelmointiskeemoista. Mentaalinen malli (mental model) on Détiennen (2002) mukaan ohjelman ymmärtämiseen liittyvä malli, joka yhdistää rakenteellisen ja funktionaalisen lähestymistavan, toisin sanoen se liittää yhteen sisältörikkaat tietoon perustuvat ja rakenteisiin liittyvät skeemat. Mentaalisen mallin käsitteen avulla pyritään kuvaamaan reaalimaailmaan liittyvää tietoa, joka voi esiintyä eri muodoissa. Mentaalisen mallin käsite on sisällöltään hyvin lähellä skeeman käsitettä ja näitä käsitteitä käytetäänkin usein toistensa synonyymeina. 5

10 3 Erilaiset ohjelmoijatyypit Ohjelmoijana voidaan pitää henkilöä, joka tietoteknisiä laitteita ja sovelluksia apuna käyttäen pyrkii laatimaan kulloinkin kyseessä olevaan tarpeeseen liittyvän tietokoneohjelman ja joskus hänen tehtäviinsä kuuluu myös testaaminen (Tietotekniikan liitto, 2004). Ohjelmoijan tavoitteena on ohjelman avulla ratkaista jonkin reaalimaailman toimintaan liittyvän ongelman siten, että ratkaisumallia voidaan tarvittaessa toistaa käyttäen erilaisia lähtötietoja. Tällaisen tietokoneohjelman laatiminen edellyttää usein ohjelmoijalta hyvin monenlaista osaamista. Ohjelmoijan täytyy esimerkiksi tuntea käyttämänsä ohjelmointikieli ja laiteympäristö vähintään siinä määrin, että kykenee laatimaan vaaditunlaisen ohjelman. Lisäksi ohjelmoijan täytyy ymmärtää esimerkiksi mikä on ohjelman tavoite ja joskus myös tuntea sovellusalueeseen liittyviä ongelmia ja yleisiä ratkaisumalleja. Ohjelmoijan tieto- ja taitotaso voi vaihdella laajasti. Ohjelmoija voi olla esimerkiksi itsenäisesti ohjelmointia opetteleva henkilö tai kymmeniä vuosia ohjelmointityötä pääsääntöisesti tehnyt ammattilainen. Jotta tiedoiltaan ja taidoiltaan erilaisten ohjelmoijien eroavaisuuksia voitaisiin tarkastella, ohjelmoijat pyritään jakamaan tasoihin. Ohjelmoijia voidaan katsoa olevan kolmea tasoa: noviiseja, edistyneitä (Expert Apprentices) ja eksperttejä (Berlin, 1993). Ohjelmoinnin psykologiaan liittyvässä kirjallisuudessa ja artikkeleissa käytetään kuitenkin usein yksinkertaisempaa jakoa ekspertteihin ja noviiseihin. Ekspertit osaavat ohjelmoida ainakin jollain ohjelmointikielellä hyvin. Heillä on kokemusta joistain ohjelmointityössä tarvittavista työkaluohjelmista ja heillä on muutaman vuoden kokemus sovellusohjelmoinnista. Eksperttiyden käsite ei ole kuitenkaan helposti rajattavissa, koska siihen liittyy erilaisia ulottuvuuksia. Ohjelmoija voi olla ekspertti tietyn ohjelmointikielen piirteiden suhteen, tiettyjen algoritmien tai tietorakenteiden suhteen tai jonkin erityisen sovellusalueen suhteen (Gugerty & Olson, 1986). Tällöin eksperttiohjelmoijankin voidaan katsoa olevan jollain muulla kuin omalla eksperttiyteen liittyvällä ohjelmoinnin osa-alueella noviisi. Eksperttiyden yhtenä piirteenä voidaan pitää erikoistumista johonkin tiettyyn osaalueeseen. Eksperteillä voi olla esimerkiksi aiempaa kokemusta tietyn ohjelmointikielen soveltuvuudesta erilaisia laitteistoja tai järjestelmiä hyväksikäyttävässä ympäristössä. Ekspertit ovat laajan ohjelmointikokemuksen kautta tutustuneet erilaisiin tieto- 6

11 rakenteisiin ja algoritmeihin, tuntevat näiden eri toteutusvaihtoehtojen erot ja soveltuvuuden kulloinkin kyseessä olevaan tehtävään. Eksperttiys voi ilmetä tietyn sovellusalueen suhteen tilanteissa, joissa sovelluksen tulee toimia erityisessä ympäristössä tai tiettyä erikoistarkoitusta varten. Tällainen ympäristövaatimus tai erikoistarkoituksen edellyttämä eksperttiyden alue voi olla esimerkiksi internet-verkkoa hyväksikäyttävä sovellus tai esimerkiksi tietojen salaukseen tarvittava tietämys. Eksperteillä on työympäristössään kaksi tärkeää roolia: he suunnittelevat ohjelmistoja ja mahdollisesti myös toteuttavat näitä sekä toimivat muiden työntekijöiden ohjaajina ja tietolähteinä (Berlin, 1993). Ekspertit kykenevät aiemman kokemuksensa avulla hahmottamaan laajempia kokonaisuuksia ja laatimaan kokonaisen sovelluksen kattavia korkeantason toteutussuunnitelmia. Ekspertit toimivat usein noviisien tietolähteinä ja tarjoavat noviiseille apua ongelmanratkaisussa ja ohjelmointiteknisiin yksityiskohtiin liittyen. Noviisiksi nimitetään ohjelmoijaa, jonka katsotaan ohjelmointiteknisiltä tiedoiltaan ja taidoiltaan olevan aloittelija. Noviiseilla on vähän työkokemusta, heillä on puutteelliset taidot ohjelmoinnissa tarvittavien työkaluohjelmien käytössä (Shneiderman, 1986). Ohjelmoijan toiminnan voidaan ajatella yleisesti olevan riippuvainen seuraavista neljästä tekijästä: yleinen kokemus: aiemmin toimivaksi todettujen ongelmanratkaisustrategioiden käyttö henkilökohtaiset tottumukset: jotka ovat ohjelmoijan omia mieltymyksiä ongelmanratkaisukeinojen suhteen ohjaus: käsittää yleisten ohjelmointimenetelmien ja kulloinkin kyseessä olevan ongelman ratkaisuun liittyvät neuvot ja ohjeet ohjelmointikokemus: kuinka paljon ohjelmoija on aiemmin ratkaissut ongelmia ohjelmoimalla Nämä neljä tekijää ovat merkittäviä noviiseja ja eksperttejä verrattaessa. Noviisiohjelmoijalla kaksi ensimmäistä tekijää korostuvat huomattavasti enemmän, koska noviiseilla ei ole hyödynnettävänä eksperttien laajaa ohjelmointikokemusta. Noviisit eivät useinkaan ole lyhyestä ohjelmointihistoriastaan johtuen ehtineet saada tapauskohtaista ohjausta samassa määrin kuin ekspertit noviiseina ollessaan. 7

12 Détienne (2002) mainitsee kolme tietoon liittyvien skeemojen vaihetta, jotka noviisi käy läpi kehittyessään kohti eksperttiyttä. Nämä vaiheet ovat alkeellisten ohjelmointiskeemojen kehittyminen, algoritmisten ohjelmointiskeemojen kehittyminen ja skeemojen sisäisen rakenteen muuttuminen hierarkiaksi. Noviiseilta puuttuu tämän näkökulman mukaan sellaiset hierarkiset skeemat, joita eksperttiohjelmoija voi käyttää suoraan ohjelman muodostamiseen. Ekspertit kykenevät muodostamaan ongelmasta abstraktin käsitteellisen mallin, kun taas noviisit käsittelevät ongelmaa pintatiedon avulla (Détienne, 2002). Samansuuntaiseen tulokseen tuli myös Wiedenbeck (1984) kokeessaan, jossa pyrittiin selvittämään kokeneen ohjelmoijan suorituskykyä ohjelmointiin liittyvissä tehtävissä. Wiedenbeck toteaa kokemuksen lisäävän kykyä erottaa merkityksiä ohjelmakoodista, vaikkakin myöntää suorittamansa kokeen perusteella löytyneen yhteyden olevan heikko. Yksi keino selvittää aloittelijoiden ja muun tasoisten ohjelmoijien ajatusmallien ja ongelmanratkaisukykyjen eroavaisuuksia on tarkkailla heidän toimintaa virheiden etsinnässä toimimattomasta tai virheellisesti toimivasta ohjelmasta. Virheiden eli bugien etsinnästä ja korjauksesta käytetään yleisesti nimitystä debuggaus, jota pidetään keskeisenä osana ohjelmointia (Gugerty & Olson, 1986). Yksinkertaiset ohjelmassa piilevät syntaktiset virheet on melko helppo löytää ja tähän on monesti tarjolla työkaluja tai apuohjelmia. Vaikeamman ongelman muodostavat ohjelmakoodin semanttiset virheet, joiden selvittäminen vaatii kulloinkin kyseessä olevan ohjelman tai sen osan toiminnan tavoitteen ymmärtämistä. Virheiden debuggaukseen tarvittavia keinoja opetetaan joskus ohjelmointikursseilla, joskus toiset ohjelmoijat antavat ohjeita tai niitä löytyy esimerkiksi ohjelmointikielten käsikirjoista. Gugertyn ja Olsonin (1986) suorittamassa kokeessa pyrittiin selvittämään noviisi- ja eksperttiohjelmoijien kykyä löytää bugeja ohjelmista, jotka on kirjoitettu heille ennestään tuntemattomalla ohjelmointikielellä. Noviisit olivat suorittaneet ensimmäisen tai toisen kurssin Pascal-kielestä ja ekspertit olivat tietojenkäsittelytieteen jatkoopiskelijoita. Kokeessa ekspertit löysivät bugit 89 % tapauksista, kun noviisit löysivät 72 % tapauksista. Merkittävin ero löytyi kuitenkin bugien jäljitysnopeudesta. Keskimääräinen bugin löytymiseen kulunut aika oli kokeessa käytettyjen ohjelmien tapauksessa eksperteillä 7 minuuttia ja aloittelijoilla 18,2 minuuttia. Eron havaittiin johtuvan eksperttien kokemukseen perustuvasta kyvystä onnistua ensimmäisellä hypoteesin kokeilulla. Ekspertit onnistuivat löytämään virheen ensimmäisellä hypoteesin kokeilulla 8

13 56 % tapauksista ja noviisit 21 % tapauksista. Edellä mainitussa Gugertyn ja Olsonin kokeessa havaittin, että noviiseille on piirteenomaista lisätä ohjelmaan bugeja yrittäessään löytää bugia. Noviisien tekemät uudet bugit olivat korrelaatiossa debuggauksen onnistumiseen. Mikäli noviisi ei löytänyt bugia ohjelmasta, hän 92 % tapauksista oli lisännyt ohjelmaan vähintään yhden bugin. Jos noviisi löysi bugin, noviisin lisäämiä uusia bugeja löytyi vain 23 %. Tähän havaittiin johtuvan noviisien vianhakustrategiasta, jossa he muuttivat kohtaa jossa olettivat bugin olevan, mutta erehdyksen havaittuaan eivät muistaneet tai osanneet palauttaa kohtaa ennalleen. Gugertyn ja Olsonin (1986) kokeen lopputuloksesta oli johdettavissa johtopäätös, jonka mukaan eksperttien ylivoimaisuus perustui heidän kykyynsä ymmärtää ohjelman toimintaa paremmin. Ekspertit muodostivat ohjelmointikokemuksensa perusteella nopeammin oikeita hypoteeseja, kun taas noviisit tekivät huomattavasti enemmän vääriä olettamuksia. Schmidt (1983) on saanut tuloksestaan hyvin samansuuntaisia tuloksia kuin Gugerty ja Olson. Hän havaitsi eksperteillä olevan noviiseihin verrattuna huomattavasti kehittyneempi kyky tunnistaa nopeasti merkityksellisiä osia suuremmasta kokonaisuudesta. Mikäli informaatiolla on mielekäs rakenne, ekspertit kykenevät omaksumaan ja palauttamaan mieleen ohjelman osia huomattavasti noviiseja paremmin. Tällaista eroa ei esiinny rakenteeltaan satunnaisen tiedon yhteydessä. Tämä viittaa siihen, että eksperttiohjelmoijat käyttävät skeematietoa ohjelman tulkintaan. Schmidthin (1983) suorittamassa kokeessa tutkittiin eritasoisten ohjelmoijien lukunopeutta, kykyä suoriutua annetusta ohjelmointitehtävästä mahdollisimman vähillä virheillä ja kykyä ymmärtää ohjelman toiminta. Tulokset osoittavat kokeneempien ohjelmoijien kykenevän ratkaisemaan ongelmia paremmin ja kirjoittamaan virheettömämpää ohjelmakoodia. Ohjelman ymmärtämiselle ja ohjelmointikokemukselle ei löytynyt tilastollista korrelaatiota. Schmidthin (1983) kokeessa kokeneemmat ohjelmoijat lukivat testiaineistoa kokemattomampia nopeammin vain silloin, kun luettu informaatio oli merkityksellistä. Tätä havaintoa tukevat erilaisia kokemustasoja edustavien shakin pelaajien kanssa suoritetut kokeet, joissa on tutkittu koehenkilöinä olleiden shakin pelaajien kykyä palauttaa mieleen ja ratkaista pelitilanteita. 9

14 Ohjelmointikokemuksen vaikutus näyttäisi korostuvan tilanteisiin, joissa ohjelmoija voi verrata aiemmin näkemiensä ohjelmien semanttisen tason malleja kyseessä olevaan ohjelmaan ja hahmottaa näitä malleja apuna käyttäen ohjelman rakennetta ja toimintaa. Noviisit käyttävät erilaista mentaalimallia kuin ekspertit jäsentäessään ohjelmaa osaongelmiin. Tämä korostuu erityisesti ohjelman koon kasvaessa. Ekspertit jakavat ohjelman toimintaa tulkitessaan ohjelman koodiryhmiin koodin toteuttaman toiminnallisuuden perusteella. Aloittajat käyttävät jakoa, joka erityisesti ohjelman kompleksisuuden kasvaessa keskittyy syntaksin mukaiseen ryhmittelyyn (Wiedenbeck, 1986). 10

15 4 Muuttujien roolit käsitteenä Muuttujalla tarkoitetaan suuretta, joka voi saada minkä hyvänsä arvon annetusta arvojoukosta (Tietotekniikan liitto, 2004). Muuttuja on ohjelmoinnissa merkeistä muodostuvaa symboli, jota käytetään jonkin tietorakenteen tai arvon tallentamiseen ja palauttamiseen. Muuttujat ovat keskeisessä asemassa ohjelman toiminnassa, koska niiden arvot ovat erilaisten aritmeettisten toimitusten kohteena. Muuttuja pyritään nimeämään ohjelmointikielen syntaksin mukaisesti ja tavallisesti käyttötarkoitukseensa nähden mielekkäästi. Muuttujan nimeäminen käyttötarkoitukseensa suhteen voi kuitenkin painottua eri tavoin. Muuttujien käyttö pyrkii noudattamaan ohjelmissa toistuvasti tiettyä käyttötapaa (Sajaniemi & al.,2006). Vaikuttaa siis siltä, että ohjelman laatija pyrkii nimeämään ja käyttämään tiettyä muuttujaa tarkoituksellisesti tietyntyyppiseen käyttötarkoitukseen. Esimerkiksi ohjelmointiin liittyvissä oppaissa esiintyy yleisesti muuttujia, joita käytetään laskureina ja tilapäisinä arvon säilyttäjinä. Tutustumme seuraavaksi muuttujien roolin käsitteeseen, käsitteen syntyhistoriaan ja siihen, miten muuttujien roolit liittyvät ohjelmiin. 4.1 Roolit Sajaniemen & al. (2006) mukaan muuttujan rooli kuvaa muuttujan arvon käyttäytymisen dynaamista luonnetta, toisin sanoen tapaa, jolla muuttuja saa alkuarvonsa ja jolla sen arvo muuttuu ohjelman suorituksen aikana. Muuttujan arvon käyttökohde ei vaikuta muuttujan roolin määräytymiseen vaan se, kuinka muuttujan arvo muuttuu. Esimerkiksi jos muuttujan roolina on kasvaa tasaisesti tiettyyn arvoon saakka, sillä ei ole merkitystä käytetäänkö muuttujan arvoa samalla jonkin toisen muuttujan arvon laskennassa. Muuttujien rooleja voidaan verrata suunnittelumalleihin (design patterns), jotka ovat ohjelmointikielestä ja sovelluksesta riippumattomia ratkaisutapoja usein esiintyviin ongelmiin. Sajaniemen & al. (2006) mukaan erilaisia suunnittelumalleja on käytännössä lähes rajaton määrä ja he mainitsevat Wallingfordin todenneen tiettyjen suunnittelumallien soveltuvan vain noviisiohjelmoijille. Lisäksi Sajaniemi & al. mainitsevat tiettyjen suunnittelumallien sopivan Nguyenin mukaan tietyille sovellusalueille. Muut- 11

16 tujien roolit soveltuvat suunnittelumalleihin verrattuna paremmin ohjelmoinnin opetteluun ja tulkintaan, koska roolien määrä on pieni. Muuttujien roolit keskittyvät yksittäisten muuttujien tiedonkäsittelyyn, joten ne ovat melko riippumattomia käytetyistä algoritmeista. Muuttujien roolien tavoitteena on Sajaniemen & al. (2006) mukaan kuvata muuttujien arvojen käyttäytymistä minimaalista roolijoukkoa käyttäen. Taulukossa 1 on esitelty version 2.0 mukaiset 11 muuttujan roolia lyhyine kuvauksineen. Tarkempi kuvaus kustakin muuttujasta löytyy esimerkiksi muuttujien roolien kotisivulta (Sajaniemi, 2006). Muuttujan rooli on ensisijaisesti kognitiivinen käsite, vaikka rooleille onkin laadittu Taulukko 1: Muuttujien roolit. Rooli kiintoarvo askeltaja tuoreimman säilyttäjä sopivimman säilyttäjä kokooja seuraaja yksisuuntainen lippu tilapäissäilö järjestelijä säiliö kulkija Lyhyt kuvaus muuttujan arvo ei muutu alustamisen jälkeen muuttujan arvo muuttuu jollain systemaattisella tavalla muuttujan arvo on jonkin joukon läpikäynnin tai syötteen viimeisin arvo muuttujan arvo on halutuin jonkin joukon läpikäynnissä kohdattu arvo muuttujan arvo kerääntyy aiemmin läpikäydyistä arvoista muuttuja saa arvokseen jonkin tietyn toisen muuttujan tai attribuutin vanhan arvon muuttujalla on kaksi mahdollista arvoa, eikä alkuperäinen arvo palaudu enää yhden muutoksen jälkeen muuttujan arvoa tarvitaan aina vain hyvin lyhytaikaisesti muuttuja on tietorakenne, jota käytetään alustuksen jälkeen siinä olevien tietojen järjestämiseen uudelleen muuttuja on tietorakenne, johon voidaan lisätä ja josta voidaan poistaa tietoja muuttujan avulla käydään läpi tietorakennetta tekniset määritelmät (Sajaniemi & al., 2006). Näin ollen on täysin mahdollista, että kahdella henkilöllä on eri näkemys yksittäisen muuttujan roolista tietyssä ohjelmassa tai ohjelman osassa. Koska roolien määritelmät eivät ole täysin toisiaan poissulkevia, tulkinnanvaraisissa tilanteissa roolin valinta voi riippua esimerkiksi siitä, mitä piirrettä 12

17 valitun roolin määrittelyssä halutaan korostaa. Yhtenä esimerkkinä roolin tulkinnanvaraisuudesta voidaan mainita Fibonaccin luvun laskeva ohjelma. Ohjelmassa muuttujan arvo muodostuu toistuvasti kahden edellisen lukuparin summasta. Fibonaccin luvun laskeva ohjelma voidaan esittää rekursiivisena algoritmina, kuten esimerkiksi int fib(int n) { if (n <= 2) return 1 else return fib(n-1) + fib(n-2) } Esimerkissä n voidaan nähdä muuttujana, joka saa peräkkäin ennalta pääteltävissä olevia arvoja. Toisaalta n voidaan nähdä myös muuttujana, jonka arvo muodostuu kertymällä. Jälkimmäinen näkemys voi tulla mieleen erityisesti silloin, kun koodia tarkasteleva henkilö ei ole ennestään tutustunut Fibonaccin luvun laskentaperiaatteeseen. Kumpikin näkemys on roolien suhteen oikein ja perusteltavissa. Näkemyserot eivät haittaa muuttujien roolien käyttöä, vaan ne ovat usein jopa hyödyllisiä, koska tällöin ohjelmien toimintaperiaatteen erilainen tulkinta tuo esille uusia näkökulmia. Muuttujien roolit ovat olleet aiemmin niin sanottua hiljaista tietoa (tacit knowledge), jollaista kehittyy usein ohjelmointikokemuksen kertyessä. Muuttujien roolien avulla on kuitenkin mahdollista opettaa hiljaista tietoa aloitteleville ohjelmoijille (Kuittinen & Sajaniemi, 2004). Roolit tarjoavat oppilaiden ja opettajien käyttöön uudenlaisen sanaston. Tämän sanaston avulla he voivat keskustella ohjelman rakenteesta ja toimintaperiaatteesta ilman, että tarvitsisi kiinnittää huomiota ohjelman syntaktisiin yksityiskohtiin. Esimerkkinä muuttujien roolien etsimisestä tarkastelemme seuraavaksi kuvassa 1 olevaa Pascal-kielistä ohjelmaa ja sen sisältämiä muuttujia. Ohjelmassa esiintyy kolme muuttujaa, data, count ja value. Ohjelma pyytää ensimmäisessä silmukassa toistokertojen lukumäärää. Mikäli käyttäjä syöttää yhtä pienemmän arvon, pyyntöä toistetaan kunnes käyttäjä syöttää positiivisen arvon. Tämän jälkeen ohjelman suoritus etenee seuraavaan silmukkaan, jossa ohjelma pyytää syöttämään arvon ja tulostaa näytölle syötetyn arvon kerrottuna kahdella. Silmukkaa toistetaan ensimmäisessä silmukassa annetun kertojen lukumäärän mukaisesti. 13

18 Ohjelmassa muuttujaan data tallennetaan viimeisin käyttäjän antama syöte, jota ohjelmoija ei voi etukäteen päätellä, joten sen rooli on tuoreimman säilyttäjä. Muuttuja count saa alustuksensa jälkeen systemaattisesti ennalta pääteltävissä olevia arvoja, joten sen rooli on askeltaja. Muuttujan value arvo saadaan samalla tavoin kuin muuttujan data eli käyttäjän syötteestä. Tämänkin muuttujan arvo on täysin riippuvainen ohjelman käyttäjästä, joten se on tuoreimman säilyttäjä. Muuttujan rooli ohjelmakoodissa saattaa muuttua. Sajaniemi (2002) mainitsee kaksi roolin muuttumisen perustyyppiä. Puhtaassa muutoksessa (proper change) edeltävän roolin muuttujan arvoa käytetään alkuarvona muuttujalle seuraavassa roolissa. Hajanaisessa muutoksessa (sporadic change) aiempaa roolia edustava muuttuja saa täysin uuden arvon uuden roolin alkaessa. Roolin muutoksen tunnistaminen on tärkeää, jotta ohjelmaa tulkitseva henkilö pystyy ymmärtämään oikein ohjelman toiminnan. program doubles; var data, count, value: integer; begin repeat write( Syötä kerrat: ); readln(data) until data > 0; count := data; while count > 0 do begin write ( Syötä arvo: ); readln(value); writeln( Kaksi kertaa,value, on, 2*value; count := count -1 end end. Kuva 1: Yksinkertainen Pascal-kielinen ohjelma Sajaniemeä & al. (2006) mukaillen. 14

19 4.2 Roolijoukkion kehittyminen Muuttujien roolien kehitys on lähtenyt liikkeelle havainnosta, jonka mukaan muuttujia käytetään usein toistuvasti tietyillä tavoilla. Sajaniemi (2002) esitteli muuttujien roolien käsitteen, joka käsitti alustavan joukon rooleja ohjelmoinnin opetuksen ja laajojen ohjelmien analysoinnin tarpeisiin. Käsitteen pohjana Sajaniemi käytti Ehrlichin ja Solowayn, Ristin sekä Greenin ja Cornahin suorittamia tutkimuksia muuttujien käytöstä. Sajaniemen (2002) mukaan Ehrlich ja Soloway mainitsevat kolme esimerkkiroolia, jotka kuvaavat tavoitetta, joka muuttujan täytyy saavuttaa. Rist oli kehitellyt ajatusta eteenpäin ja määritellyt planin käsitteen. Green ja Cornah esittelivät oman joukkonsa rooleista, joka on hyvin lähellä Sajaniemen ensimmäistä roolien joukkoa. Merkittävin ero on kuitenkin se, ettei Sajaniemen esittämissä rooleissa oteta kantaa siihen, mihin muuttujien arvoa käytetään. Alkuperäinen Sajaniemen (2002) yhdeksän roolin roolijoukko koski proseduurien ja funktioiden muuttujia ja arvoparametreja. Roolit oli saatu analysoimalla 109 ohjelmaa ja ne kattoivat 99 % ohjelmissa esiintyneistä muuttujista. Taulukoita käsiteltiin yksittäisinä muuttujina, joiden roolin määräsi taulukon alkioiden rooli. Osoittimia ja tietueiden kenttiä käsiteltiin itsenäisinä muuttujina. Analyysistä jätettiin pois dynaamiset muuttujat ja tiedostomuuttujat. Noviisiohjelmoijien tarvitsemien roolien selvittäminen lähti liikkeelle kolmen Pascalkielen ohjelmointioppaan ohjelmien muuttujien analysoinnilla. Sajaniemen & al. (2006) mukaan alustavan proseduraalisen ohjelmoinnin roolijoukon loi yksi tutkija, joka kävi läpi roolien luokittelua varten kaikki kirjojen sisältämät ohjelmat. Tämän jälkeen tutkija kirjoitti lyhyen kuvauksen jokaista roolista. Seuraavaksi toinen tutkija analysoi samat muuttujat ensimmäisen analyysin tuloksiin nähden riippumattomasti. Tuloksien vertailu paljasti pieniä eroavaisuuksia, joiden seurauksena muutaman roolin kuvausta muutettiin hieman. Vuonna 2004 Ben-Ari ja Sajaniemi laajensivat roolijoukkoa yhdellä roolilla, jota nimitettiin muuntajaksi. Muuntaja korvasi joissain tietyissä tilanteissa aiemmin esiteltyjen tuoreimman säilyttäjän ja kiintoarvon roolin. Olio-ohjelmointiin ja funktionaaliseen ohjelmointiin liittyvien roolien luokittelu lähti liikkeelle proseduraalista ohjelmointia varten laaditusta roolijoukosta. Roolijoukkoa täydennettiin vain, mikäli siihen löytyi perusteltua tarvetta. Roolien määrittelyn kohteena oli olio-ohjelmoinnissa kaksi aloitteleville ohjelmoijille suunnattua Java- 15

20 ohjelmointikieltä käsittelevää kirjaa. Funktionaalista ohjelmointia varten valittiin neljä ML-ohjelmointikieltä käsittelevä kirjaa. Olio-ohjelmoinnin ja funktionaalisen ohjelmoinnin roolien etsintä eteni pääpiirteittäin samalla tavalla. Aluksi kaksi tutkijaa määritteli toisistaan riippumattomasti roolit ensimmäiseksi valitun kirjan ohjelmien muuttujille. Seuraavaksi tutkijat keskustelivat niistä perusteista, joilla olivat valinneet kunkin muuttujan roolin. Eroavat näkemykset kirjattiin ja ristiriitaisten tulkintojen perustelut selvitettiin. Näin edettiin jokaisen ohjelmointioppaan suhteen. Funktionaaliseen ohjelmointiin liittyvien roolien etsintä erosi edellä esitetystä menettelystä siten, että etsinnän suoritti yksi tutkija. 4.3 Roolien käyttö eri ohjelmointiparadigmoissa Eri ohjelmointiparadigmoissa muuttujia käytetään kullekin paradigmalle tyypillisillä tavoilla. Sajaniemi & al. (2006) kuvailee muuttujien roolien käyttöä kolmessa eri ohjelmointiparadigmassa, jotka ovat proseduraalinen ohjelmointi, olio-ohjelmointi ja funktionaalinen ohjelmointi. Proseduraalisessa ohjelmoinnissa ohjelma koostuu tavallisesti pääohjelmasta ja mahdollisesti yhdestä tai useammasta proseduurista ja funktiosta. Proseduraalisessa ohjelmoinnissa muuttujan rooli voidaan määritellä jokaisessa proseduurissa ja funktiossa erikseen. Tämä mahdollistaa samannimisten muuttujien esiintymisen proseduureissa tai funktioissa eri rooleissa. Olio-ohjelmoinnissa rooleja voidaan asettaa muuttujille proseduraalista ohjelmointia vastaavalla tavalla, mutta lisäksi voidaan roolittaa myös olioluokan attribuutit. Tietyissä tapauksissa voidaan myös olioiden ajatella käyttäytyvän muuttujien tapaan, jolloin niillekin voidaan kiinnittää oma roolinsa. Esimerkiksi Java-ohjelmointikielessä on käytettävissä kokonaislukuja varten Integer-luokka, jonka ilmentymäolioita voidaan käyttää perustietotyypin tapaan. Tällöin Integer-tyyppiselle oliolle voidaan määritellä rooli ikään kuin se olisi vastaavan kokonaislukujen perustietotyypin muuttuja. Edellisistä paradigmoista poiketen funktionaalisessa ohjelmoinnissa ei ole muuttujia ollenkaan, jolloin rooleja ei voi kiinnittää edellä kuvatuilla tavoilla. Roolien käsitettä voidaan kuitenkin soveltaa myös funktionaaliseen ohjelmointiin. Funktionaalisessa ohjelmoinnissa ohjelmalla on parametreja ja funktioiden paluuarvoja, jotka käyttäyty- 16

21 vät rekursiossa roolien tapaisesti. Näin ollen parametreille ja funktioiden paluuarvoille voidaan määritellä omat roolinsa. 17

22 5 Roolien esiintyminen ja omaksuminen Jotta rooliajattelun käyttö ohjelmoinnin opetuksessa ja ohjelmien toiminnan selvittämisessä olisi perusteltavissa, on muuttujien roolien oltava mielekkäitä ja niiden käyttökelpoisuus tulisi olla osoitettavissa. Tarkastelemme seuraavaksi miten muuttujien roolit esiintyvät eri ohjelmointiparadigmoissa ja millaisia havaintoja on saatu opettajilla suoritetuista muuttujien rooleihin liittyvistä kokeista. 5.1 Roolien esiintyminen eri paradigmoissa Vertailemalla kolmen eri ohjelmointiparadigman ohjelmointioppaiden sisältämien roolien esiintymämääriä Sajaniemi & al. (2006) havaitsi jokaisella ohjelmointiparadigmalla olevan tiettyjä ominaispiirteitä. Olio-ohjelmoinnissa esiintyy kahta muuta tutkittua paradigmaa enemmän kiintoarvoja. Olio-ohjelmoinnin oppaissa kiintoarvoja esiintyi vaihteluvälillä % kaikista rooleista, kun vastaava vaihteluväli proseduraalisen ohjelmoinnin oppaissa oli % ja funktionaalisen ohjelmoinnin oppaissa %. Tämän eron voidaan olettaa johtuvan olio-ohjelmoinnille tyypillisestä tarpeesta välittää arvoja parametrien avulla metodien välillä. Sajaniemen & al. (2006) ohjelmointioppaista keräämien tietojen mukaan proseduraalisessa ohjelmassa korostuu askeltajien käyttö. Proseduraalisen ohjelmoinnin oppaissa esiintyi askeltajia vaihteluvälillä %, kun vastaava roolin esiintymisen vaihteluväli oli olio-ohjelmointiin liittyen % ja funktionaaliseen ohjelmointiin liittyen %. Tämä selittyy tarpeella käyttää ohjelmissa paljon silmukoita toistoa ja taulukoiden läpikäyntiä varten. Esimerkiksi olio-ohjelmoinnissa proseduraalisten ohjelmien askeltajat korvataan usein iteraattoreilla. Funktionaalisessa ohjelmoinnissa toisto syntyy rekursion avulla ja toistoa tarvitaan pääasiassa tietorakenteiden käsittelyssä. Sajaniemen & al. (2006) mukaan eri ohjelmointiparadigmoille laadituissa ohjelmointioppaissa on muutamia huomattavia eroavaisuuksia. Esimerkiksi proseduraaliset ohjelmat käsittelevät enimmäkseen käyttäjän syötteitä ja tulostavat syötteisiin perustuvan laskennan tuloksia. Olio-ohjelmoinnin oppaissa korostuu staattiset tietojen väliset riippuvuudet, jolloin kiintoarvot esiintyvät muihin paradigmoihin verrattuna useammin. Grafiikkaohjelmointiin liittyvien ominaisuuksien esittely olio-ohjelmoinnin oppaissa johti vähäiseen määrään kokoajia ja sopivimman säilyttäjiä. Esimerkiksi ko- 18

23 koajien esiintymien vaihteluväli oli funktionaalisen ohjelmoinnin oppaissa %, kun vastaava vaihteluväli oli proseduraaliseen ohjelmointiin liittyen 5-7 % ja olioohjelmointiin liittyen 1-2 %. Olio-ohjelmoinnin oppaiden sisältämien ohjelmien yksisuuntaisien lippujen korostunut esiintymismäärä perustuu grafiikkaohjelmoinnin tarpeeseen käsitellä käyttäjän aiheuttamia tapahtumia ja animaatiota. Yksisuuntaisia lippuja esiintyi olio-ohjelmoinnin oppaissa 3 % verran, kun proseduraalisen ohjelmoinnin oppaissa niitä esiintyi enintään 2 % ja funktionaalisen ohjelmoinnin oppaissa enintään 1 %. Funktionaaliselle ohjelmoinnille oli oppaissa tyypillistä, että ne käsittelivät paljon listoja, jolloin kokoajia tarvittiin usein. Kokoajien esiintymien vaihteluväli oli funktionaalisessa ohjelmoinnissa %, kun vastaava väli oli olio-ohjelmoinnissa 1-2 % ja proseduraalisessa ohjelmoinnissa 5-7 %. Yksi erityispiirre funktionaalisen ohjelmoinnin oppaissa oli se, että tilapäissäiliöitä ei tarvittu ollenkaan. Vastaavasti muihin paradigmoihin liittyen tilapäissäiliöitä käytettiin ohjelmalohkoissa vain paikallisesti. Tällöin muuttujan roolia voitaisiin ajatella myös kiintoarvoksi. Tilapäissäiliöitä esiintyi enimmillään proseduraalisen ohjelmoinnin oppaissa 5 % verran ja olio-ohjelmoinnin oppaissa esiintymiä oli 1 %. Funktionaalisen ohjelmoinnin oppaiden analyysi tuotti kaksi uutta roolia, jotka liittyvät tietorakenteiden muokkaukseen. Nämä ovat muokkaaja (modifier) ja valitsija (selector). Tietorakenteiden muokkaus ei kuitenkaan kuulu tavallisesti ohjelmoinnin alkeiden opetukseen, joten näitä ei lisätty alkuperäiseen roolijoukkoon. Olio-ohjelmoinnissa käsitellään tietorakenteita varsin varhaisessa vaiheessa opetusta, mutta näihin liittyville muuttujille oli löydettävissä roolit alkuperäisten muuttujien roolien joukosta. Kirjallisuuden perusteella laaditun roolilistan ongelmana on se, että ne nojaavat valittuihin ohjelmoinnin oppaisiin ja analysoijien taipumukseen mukautua ja asennoitua muuttujien roolien teoriaan. Tätä vaikutusta Sajaniemen & al. tutkimuksessa pyrittiin minimoimaan valitsemalla jokaista ohjelmointiparadigmaa kohti useita teoksia. Tällöin yksittäisen kirjoittajan valitsema ohjelmointiin liittyvien asioiden käsittelytapa ei pääse vaikuttamaan liikaa roolien tunnistamiseen. 19

24 5.2 Opettajien roolien omaksuminen Muuttujien roolien käytön mielekkyyttä voidaan selvittää esimerkiksi tutkimalla tietojenkäsittelytieteen kouluttajien suhtautumista rooleihin. Sajaniemi & al. (2006) mainitsee kolmesta tutkimuksesta, joissa kouluttajat pyrkivät selainpohjaisessa ympäristössä omaksumaan muuttujien roolit ja käyttämään niitä kolmessa eri ohjelmointiparadigmassa. Tätä tavoitetta varten oli perustettu verkkosivusto, joka koostui kolmesta osiosta. Ensimmäisessä vaiheessa kuhunkin tutkimukseen osallistuville esiteltiin verkkosivujen avulla muuttujien roolien käsite ja roolien määritelmät sekä tarjottiin kutakin roolia selventäviä esimerkkejä. Seuraavaksi tutkimukseen osallistuville tarjottiin mahdollisuus harjoitella roolien nimeämistä kuuden yksittäin esitellyn ohjelman tai funktion sisältämien muuttujien avulla. Lyhytkestoisen muistin kuormituksen minimoimiseksi jokaisen roolivaihtoehto oli linkitetty kyseisen roolin kuvaukseen. Jokaisen ohjelman tai funktion muuttujien roolien valinnan jälkeen osallistuja sai palautetta tekemistään valinnoista. Kokeen viimeisessä vaiheessa toimittiin muuten samoin kuin harjoitteluvaiheessa, mutta nyt ohjelmat ja funktiot olivat samalla sivulla. Kaikissa tapauksissa osallistujilla oli myös mahdollisuus ehdottaa uutta roolia tai ilmaista, ettei tunnista muuttujan roolia. Sajaniemen & al. (2006) tutkimuksien tuloksena saatiin tietää, että keskimäärin 85 % proseduraalisen ohjelmoinnin kokeeseen osallistuneista valitsi oikean roolin. Vastaava luku oli olio-ohjelmoinnissa 62 % ja funktionaalisessa ohjelmoinnissa 88 %. Tulkinnanvaraisiakin tilanteita syntyi eli tilanteita, joissa roolin valitsija saattoi ymmärtää muuttujan roolin eri tavoin. Mikäli nämä tapaukset otetaan huomioon oikeina valintoina, edellä mainitut prosentit ovat vastaavasti 93 %, 83 % ja 91 %. Tästä voidaan päätellä, että roolit ovat helposti omaksuttavissa ja roolien määritelmät ovat melko objektiivisia. Sajaniemen & al. (2006) järjestämät kokeet toivat esille muutamia roolien luonteeseen liittyviä ongelmakohtia. Muuntaja osoittautui kaikissa kolmessa ohjelmointiparadigmassa vaikeimmin tunnistettavaksi. Muuntajan tarkoituksena oli ilmaista muuttujan roolia, jossa muuttujan arvo saadaan laskennan avulla. Erityisesti roolien tunnistamisessa parhaiten onnistuneet tarjosivat muuntajaa muiden roolien sijaan ja muita rooleja muuntajan sijaan. Tuoreimman säilyttäjä oli toinen muuttuja, jota tarjottiin usein jonkin toisen roolin sijaan. Tuoreimman säilyttäjän roolin tunnistaminen oli vaikeaa pro- 20

25 seduraalisessa ja olio-ohjelmoinnissa, mutta funktionaalisessa ohjelmoinnissa ei tämän roolin tunnistamisen suhteen ilmennyt ongelmia. Funktionaalisessa ohjelmoinnissa oli koehenkilöillä toisinaan vaikeuksia erottaa kokoaja ja uutena roolina esitelty muokkaaja. Tämä ongelma esiintyi erityisesti rooleja heikommin omaksuneilla koehenkilöillä, jotka eivät pintatiedon varassa ymmärtäneet ohjelman toiminnan kokonaisvaikutusta. Kokeisiin osallistuneet antoivat roolien käsitteestä pääasiassa positiivista palautetta. Yleinen näkemys oli, että muuttujien roolien käyttö edesauttaa ohjelmien ymmärtämisessä. Jotkut osallistujista toivoivat, että rooleissa otettaisiin enemmän huomioon yksittäisten paradigmojen peruskäsitteitä, kuten tietovirtoja tai stereotyyppisiä luokkien välisiä suhteita. Palautteen perusteella voidaan siis olettaa muuttujien roolien olevan opettajien näkökulmasta hyödyllinen väline ohjelmoinnin opetuksessa. 5.3 Roolien kuvaukset Tarkastelemme seuraavaksi yksittäisiä muuttujien rooleja. Kuvaillut yksitoista muuttujan roolia perustuvat Kuittisen ja Sajaniemen (2004) artikkelissa julkaisemaan luetteloon. Roolien kuvaukset perustuvat muuttujien roolien kotisivulta löytyviin version 1.1 mukaisiin roolikuvauksiin. Jokaisen roolin yhteydessä on myös taulukko ja kuvaus kulloinkin kyseessä olevaan rooliin liittyvistä alirooleista. Roolien alirooleja (subroles) voidaan käyttää tarkentamaan kunkin muuttujan rooliin liittyvää käyttötarkoitusta. Aliroolien käyttö roolin valinnassa ei ole ehdotonta, mutta niiden avulla voidaan perustella tietyn roolin valintaa tai helpottaa roolin tunnistamista. Tulkinnanvaraisissa tapauksissa roolin valitseva henkilö voi täsmentää aliroolin avulla, mitä piirrettä roolissa hän on halunnut korostaa. Aliroolia ei voida kuitenkaan kaikissa tapauksissa löytää yksiselitteisesti ja roolikohtaisten aliroolien määrä saattaa kasvaa hyvinkin suureksi. Tässä tutkielmassa esiintyvät roolit perustuvat tutkielmaan liittyvän rooleihin tutustumisen yhteydessä annettuun aliroolien luetteloon. Jos muuttujan roolille halutaan määritellä alirooli, on tätä varten laadittu erilliset aliroolilistat. Mikäli aliroolia ei voida kyseisen listan avulla päätellä, voidaan alirooli asettaa määrittelemättömäksi. Aliroolille voidaan määritellä tunniste, joka voi koostua esimerkiksi kahdesta kirjaimesta. Tällöin aliroolien merkintä voidaan tehdä lyhyesti, esimerkiksi tilastointia ajatellen. Seuraavissa roolien kuvauksissa on käytetty aliroolien suhteen tällaista kahden kirjaimen notaatiota. 21

26 Kiintoarvo Kiintoarvoksi (fixed value) nimitetään muuttujan roolia silloin, kun muuttujan saama arvo ei perustu laskentaan eikä sen arvoa muuteta muuttujan alustamisen jälkeen. Vakio-tyyppinen muuttuja ei ole kiintoarvo. Kiintoarvoja ovat tyypillisesti ohjelman syötteenä saamat, kertaluontoisesti muuttujiin tallennettavat arvot. Muuttujan arvoa voidaan käyttää laskentaan, mutta sen arvo ei muutu ohjelman tai sen osan suorituksen aikana. Taulukossa 2 on kiintoarvoon liittyvät aliroolit. in on alirooli muuttujalle, jonka arvo on saatu syötteestä. Muuttujan arvo on sijoitettu tällöin ilman muutoksia. ic-alirooli on muuten samanlainen kuin in, mutta arvolle on tehty korjaus ennen sijoitusta muuttujaan. Kun muuttujalle halutaan asettaa vakioarvo, käytetään aliroolia co ja jos halutaan sijoittaa toisen muuttujan arvo, alirooliksi annetaan va. Alirooli pa ilmaisee, että kiintoarvo-roolia edustavan muuttujan arvo on saatu parametrina. dv-aliroolilla ilmaistaan, että muuttujan arvo on saatu uuden dynaamisen muuttujan luonnin kautta. Mikäli kyseessä on kiintoarvoa edustava muuttuja, mutta mikään edellä kuvatuista ei sovi aliroolin tyypiksi, voidaan käyttää ot aliroolia. Taulukko 2: Kiintoarvon aliroolit. Alityyppi in ic co va pa dv ot Kuvaus arvo on saatu syötteestä, jolle ei ole tehty korjausta arvo on saatu syötteestä, jolle on tehty korjaus arvo on asetettu käyttäen yhtä vakioarvoa arvo on asetettu käyttäen yhtä muuttujaa saatu parameterina arvo on saatu luomalla uusi dynaaminen muuttuja muu Askeltaja Askeltaja (stepper) on rooli, jossa muuttujan arvo muuttuu jollain systemaattisella tavalla. Muutoksen kokoa ei ole rajattu ja arvot voivat muuttua myös jaksollisesti. Askeltajia käytetään ohjelmissa tavallisesti silmukkarakenteissa, lukumäärän laskennassa ja tietorakenteiden läpikäynnissä. 22

27 Taulukossa 3 on kuvattu askeltajan aliroolit. cn-alirooli liittyy askeltajan muuttujaan, jonka arvoa käytetään yhdellä kasvavana laskuriarvona, eikä suurinta arvoa voi tietää etukäteen. Vastaavasti nc-aliroolilla kuvataan muuttujan arvoa, joka pienenee yhdellä ilman tiedossa olevaa rajaa. Aliroolia i1 käytetään kuvaamaan muuttujan arvon käyttäytymistä, kun arvo kasvaa yhdellä ja suurin mahdollinen arvo on tiedossa etukäteen. Vastaavasti d1-aliroolilla kuvataan rajallista yhdellä pienenevää arvoa. in-alirooli kuvaa tilannetta, jossa muuttujan arvo kasvaa jollain muulla kuin yhdellä ja dn kuvaa vastaavalla tavalla pienenevää arvoa. Askeltajaa edustavan muuttujan arvo voi myös vaihdella kahden tai useamman arvon välillä. Jos kyseessä on vaihtelu kahden arvon välillä, käytetään aliroolia a2 ja useamman arvon tapauksessa aliroolia an. Linkitetyn listan läpikäynnissä käytetään aliroolia ll. Jos kyseessä on askeltajan muuttuja, mutta mikään edellä mainituista ei sovi alirooliksi, käytetään ot-aliroolia. Taulukko 3: Askeltajan aliroolit. Alityyppi cn i1 in nc d1 dn a2 an ll ot Kuvaus laskuri, jonka arvo kasvaa yhdellä ilman tiedossa olevaa rajaa arvo kasvaa yhdellä ja raja on tiedossa kasvaa jollain muulla arvolla negatiivinen laskuri, jonka arvo pienenee yhdellä ilman tiedossa olevaa rajaa arvo pienenee yhdellä ja raja on tiedossa pienenee jollain muulla arvolla vaihtelee kahden arvon välillä vaihtelee useamman arvon välillä kulkee linkitetyn listan läpi muu Tuoreimman säilyttäjä Tuoreimman säilyttäjä (most-recent holder) on muuttuja, jonka arvo on viimeisin jonkin arvojoukon läpikäynnissä. Se voi olla myös viimeisin syötteenä saatu arvo. Esimerkkeinä tyypillisistä tuoreimmman säilyttäjistä voidaan mainita muuttujat, jonka arvo on viimeisin taulukon läpikäynnissä saatu arvo. Taulukko 4 sisältää tuoreimman säilyttäjän aliroolit. Mikäli muuttujan arvon on saa- 23