Miksi matematiikkaa tietojenkäsittelytieteessä? Wilhelmiina Hämäläinen Joensuun yliopisto Tietojenkäsittelytieteen laitos whamalai@cs.joensuu.fi Uudessa ACM:n curriculumissa matematiikan ja teoreettisten tietojenkäsittelytieteen kurssien oppimääriä on pienennetty radikaalisti. Varsinaisesta matematiikasta ydinainekseen kuuluu vain 40 tuntia diskreettiä matematiikka. Lisäksi suositellaan muitakin matematiikan kursseja, kuten tilastotiedettä, differentiaali- ja integraalilaskentaa, lineaarialgebraa, numeerisia metodeja, lukuteoriaa, geometriaa tai symbolista logiikkaa.[cur01] Curriculum-komitea on perustellut matematiikan ja teorian osuuden vähentämistä sillä, että 1) teoreettisten alueiden (algoritmiikan ja ohjelmointikielten teorian) merkitys on suhteessa pienentynyt muihin alueisiin nähden, 2) curriculum pyrkii palvelemaan mahdollisimman monenlaisia instituutioita ja 3) curriculummallin tulee palvella nykyisyyttä ja tulevaisuutta, eikä pitäytyä menneisyyden tietojenkäsittelytieteessä. Alan ammattilaiset ovat kuitenkin toista mieltä. Almstrumin [Alm03] tutkimuksessa 500 pääasiassa yhdysvaltalaista tietojenkäsittelytieteen ammattilaista kertoi kokemuksistaan matematiikan tarpeellisuudesta työssään. Vastaajista noin 1/3 työskenteli pääasiassa opetusalalla ja noin 1/3 teollisuudessa. Peräti 75% piti hyvää matematiikan ymmärrystä tärkeänä vaatimuksena alan työssä. 1 Monet asiantuntijat ovat myös esittäneet puheenvuoronsa matematiikan tarpeellisuuden puolesta varsinkin ACM Communications -lehdessä. Suomalaisista asiantuntijoista Orponen [Orp03] on käsitellyt kysymystä, mihin tietojenkäsittelytieteen teoriaa tarvitaan. Ohjelmistotuotannossa tarvittavaa matematiikan roolia on käsitellyt mm. Valmari [Val00, Val01]. Seuraavissa kappaleissa käsittelen heidän tärkeimpiä argumenttejaan. 1 On syytä huomata, että vastaajista lähes 80% oli naisia. Muiden tutkimusten mukaan tietojenkäsittelytieteessä naisille ymmärtäminen on tärkeämpää, kun taas miehet nauttivat rakentamisesta ja tekemisestä. [Dev03] 44
Hämäläinen 45 1 Kyky ajatella matemaattisesti Matematiikan ja teoreettisen tietojenkäsittelytieteen puolustajat ovat nostaneet esiin monia ajankohtaisia ja tulevaisuuden kehityksen kannalta tärkeitä tietojenkäsittelytieteen sovellusalueita, joissa tarvitaan matemaattisia valmiuksia. Tärkeimmät argumentit matematiikan opintojen pakollisuudelle ovat kuitenkin kyky oppia matemaattista (loogista/abstraktia/analyyttistä) ajattelua sekä kestävän kehityksen takaaminen. Devlin [Dev03] korostaa sitä, että tietojenkäsittelytieteen tuotteet ovat puhtaasti abstrakteja, ja tällaisten abstraktien tuotteiden määrittely, suunnittelu ja testaus edellyttävät abstraktia ajattelua. Henderson [Hen03] huomauttaa, että ohjelmistotuotanto edellyttää kykyä ajatella loogisesti ja täsmällisesti aivan kuten matematiikassa ja ohjelmistotuotannossa käytetään jatkuvasti implisiittisesti matemaattista päättelyä. Laajasti ottaen matemaattinen päättely voidaan määritellä "matemaattisten tekniikoiden, käsitteiden ja prosessien soveltamiseksi eksplisiittisesti tai implisiittisesti ongelmien ratkaisemisessa", jolloin kaikessa ongelmanratkaisussa tarvitaan matemaattista päättelyä [HBD + 01]. Bruce et al. [BSKT03] korostavat, ettei tärkeää ole minkään yksittäisen matematiikan osa-alueen hallinta, vaan korkean tason matemaattinen kyvykkyys: useimmat tietojenkäsittelytieteen ongelmat edellyttävät matemaattisen mallin luomista fyysisestä todellisuudesta. Tärkein hyöty matematiikasta onkin yleinen kyky formaaliin määrittelyyn ja matemaattiseen päättelyyn. Lisäksi monet kirjoittajista (esimerkiksi Devlin [Dev03], Henderson [Hen03]) korostavat, että yliopistoopiskelun tärkeimpiä päämääriä on tarjota pohja myöhemmälle oppimiselle. Vaikkei opiskelija tarvitsisi jotain tiettyä teoreemaa tai tekniikkaa koskaan tulevaisuudessa, hän on silti saanut valmiudet oppia tarvittavia uusia asioita. Tämä perustuu siihen, että oppiessa ihmisaivot aina luovat ja vahvistavat uusia hermopolkuja, jotka pysyvät kauan sen jälkeen, kun niiden luomiseen käytetyt faktat unohtuvat. Ei siis haittaa, vaikka faktat katoavat, sillä kyvyt säilyvät! [Dev03] Tietojenkäsittelytieteessä kyky jatkuvaan oppimiseen on erityisen tärkeää, sillä ala on nopeasti muuttuva. Matemaattinen tieto puolestaan on pysyvää ja hyvin testattua, eikä se vanhene. Kukaan ei esimerkiksi tiedä, mikä on neljän vuoden päästä vallitseva ohjelmointiparadigma tai -kieli, mutta on varmaa, että sille on kyettävä laatimaan kääntäjiä ja ohjelmoijien on opittava käyttämään sitä. Suomalaiset asiantuntijat ovat korostaneet, kuinka tärkeää on taata kestävä kehitys. Tietotekniikan matemaattisen teorian edistys muodostaa pitkän aikavälin kehityksen todellisen perustan, kuten Orponen [Orp97] toteaa. Valmari [Val00] on huomauttanut, että teollisuudessa haluttu täsmäkoulutus ja karsaus matemaattisia/teoreettisia kursseja kohtaan on kovin lyhytnäköistä. Laajempi
46 Miksi matematiikkaa teoreettinen yleissivistys auttaa sopeutumaan tulevaisuuden tekniikoihin, jolloin henkilökunnan osaaminen ei vanhene teknologian myötä. Teollisuus hyötyy teoreettisesta osaamisesta myös toisella tapaa: teorian tuntemus auttaa arvioimaan eri teknologioiden etuja ja haittoja tärkeissä strategisissa päätöksissä. 2 Missä matematiikkaa tarvitaan? 2.1 Ohjelmointitaidot Matemaattisten taitojen ja ohjelmointitaitojen välillä on havaittu selvä korrelaatio. Devlin [Dev03] selittää tämän sillä, että hyvä ohjelmointitaito edellyttää kykyä käsitellä abstraktioita tarkasti joka on matemaattinen taito. Page [Pag03] on huomannut, että matemaattisen induktion ymmärtäminen auttaa opiskelijoita ymmärtämään muitakin siihen liittyviä käsitteitä kuten rekursiota, numeerisia rekursioyhtälöitä ja silmukkavariantteja. Bruce et al. [BSKT03] ovat myös korostaneet induktiokäsitteen merkitystä rekursiivisten ohjelmien laatimisessa. Rekursiiviset ohjelmat ovat usein tehokkaita ja yksinkertaisia, mutta niiden laatiminen edellyttää rekursion idean ymmärtämistä ja mikä vielä tärkeämpää lisäksi on varmistettava, että rekursiivinen ohjelma täyttää määrittelyn. Tähän tarvitaan matemaattista induktiota. Ohjelmoijan, joka taitaa induktion, on helpompi laatia rekursiivisia ohjelmia ja varmistua niiden toimivuudesta. Lisäksi induktion käyttö mahdollistaa sen, että ohjelman kehitys ja verifiointi voidaan suorittaa samanaikaisesti. Kun opiskelija on harjaantunut induktion käytössä, ei formaalia todistusta enää tarvita, vaan induktioperiaatetta voidaan soveltaa implisiittisesti. Laskettavuuden teoria on tietojenkäsittelytieteen matemaattisimpia kursseja, jolla on myös käytännön vaikutusta ohjelmointitaitoihin. 2 Kun opiskelija oppii tunnistamaan ongelmaa vastaavan formaalin kieliluokan (esimerkiksi äärellinen kieli, LL(1)-kieli, deterministinen kontekstiton kieli), hän voi soveltaa ongelman ratkaisussa suoraan oppimiaan tehokkaita työkaluja (automaattien tai jäsentäjän ohjelmatoteutusta). Kontekstittomat kieliopit auttavat myös hahmottamaan rekursion käsitettä ja ohjelmoimaan rekursiivisen määrittelyn. 2.2 Ohjelmistotuotanto Matematiikasta on hyötyä kaikissa ohjelmistokehityksen vaiheissa: määrittelystä ja suunnittelusta koodaukseen sekä lopullisen toteutuksen turvallisuuden ja oikeellisuuden verifiointiin [BSKT03]. Myös empiirisissä kokeissa on havaittu matemaattisten taitojen tehostavan 2 Laskettavuuden teoria tarjoaa työkaluja vieläkin perustavampaa laatua olevaan kysymykseen: onko kohdattu ongelma ylipäänsä ratkeava? Tämä ongelma on itsessään laskennallisesti ratkeamaton, joten ainut keino varmistua ratkeamattomuudesta on matemaattinen todistus, mutta kurssi harjaannuttaa opiskelijoita tunnistamaan ratkeamattomat ongelmat.
Hämäläinen 47 ohjelmistotuotantoa. Esimerkiksi Sobel [Sob00] on raportoinut vertailututkimuksesta, jossa yhdelle opiskelijaryhmälle opetettiin perinteisiä ohjelmistotuotannon menetelmiä ja toiselle formaaleja metodeja. Havaintojen mukaan formaalin kurssin käyneet opiskelijat kykenivät abstrahoimaan ongelmat paremmin ja tuottamaan virheettömämpiä sekä rakenteellisesti laadukkaampia ohjelmia. Monet teollisuudessa tehdyt tutkimukset [LFB96, PH97, CW96, CMCP + 99] ovat päätyneet samaan johtopäätökseen: formaalit menetelmät tuottavat virheettömämpiä, tehokkaampia ja luotettavampia ohjelmistoja. Henderson [Hen03] muistuttaa, että ohjelmistotuotannon tärkeimmät tekijät ovat tuotteen kehityskustannukset ja luotettavuus mitattuna virheinä 1000:tta koodiriviä kohden. Matematiikka tarjoaa apukeinoja tehostaa tuotantoprosessia ja havaita virheet mahdollisimman aikaisessa vaiheessa. Henderson [Hen03] ja Valmari [Val00, Val01] korostavat erityisesti kahta (osittain päällekkäistä) määrittelyja suunnitteluvaiheen toimintoa, joissa matematiikasta on hyötyä: täsmällistä kommunikointia ja tuotteen abstraktia mallinnusta. Yhteisen kuvauskielen merkitys on koko ajan kasvanut, kun ohjelmistojen koko ja kehitykseen osallistuvien ihmisten lukumäärä ovat kasvaneet. Lähes poikkeuksetta ohjelmistotuotteen kehittäminen edellyttää useiden ihmisten yhteistyötä. Tätä varten tarvitaan täsmällistä yhteistä kieltä. Aivan ensiksi ohjelmistotuottajan on kyettävä karsimaan epäolennaisuudet ja kuvaamaan haluttu tuote täsmällisesti käyttäjän hajanaisten ja usein ristiriitaistenkin toiveiden pohjalta. Mikä tahansa abstrakti kuvaus ei kuitenkaan riitä, vaan se on esitettävä muiden samaan hankkeeseen osallistuvien ymmärtämässä muodossa. Ohjelmistotuottajan on kyettävä keskustelemaan ei ainoastaan oman alan vaan muidenkin alojen kollegojen kanssa. Matematiikka tarjoaa rikkaan, ymmärrettävän ja universaalin kielen kommunikoimiseen. Matemaattisilla notaatiolla ja symboleilla voidaan määritellä täsmällisesti esimerkiksi datatyypit ja haluttujen operaatioiden semantiikka. Puhekielellä ei samaan täsmällisyyteen ylletä. Toiseksi Henderson [Hen03] muistuttaa, että ohjelmisto on abstrakti tuote, jonka laatiminen edellyttää abstraktia mallia. Mitä täsmällisempi malli on, sitä aikaisemmassa vaiheessa mahdolliset virheet voidaan havaita. Matematiikka tarjoaa vahvan työkalun mallien rakentamiseen, tarkastamiseen, analysoimiseen ja testaamiseen. Valmarin [Val00, Val01] mukaan matematiikan suurin hyöty onkin juuri siinä, että se tarjoaa työkaluja abstraktioiden tunnistamiseen, muotoilemiseen ja niistä päättelemiseen. Myös ohjelman osien välisten rajapintojen, tietovarastojen, tiedostomuotojen ja ohjelmakomponenttikirjastojen suunnittelussa voidaan hyödyntää matemaattisia työkaluja.
48 Miksi matematiikkaa 2.3 Muiden tuotteiden formaali määrittely ja verifiointi Formaalia määrittelyä ei tarvita ainoastaan ohjelmistotuotannossa, vaan mikä tahansa tuote (käyttöjärjestelmä, laitteisto, tietoliikenneprotokolla) voidaan kuvata matemaattisella määrittelyllä. Vastaavasti valmis toteutus verifioidaan matememaattisilla todistuksilla. Suunnittelussa mahdollisesti tapahtunut virhe on valtavan kallis, ja siksi esimerkiksi laitteistopiirin tai protokollan suorituskyky ja turvallisuus on verifioitava huolella ennen tuotteen julkistamista. [BSKT03] Erityisen tärkeää verifiointi on turvallisuuskriittisten järjestelmien kohdalla. Bruce et al. [BSKT03] muistuttavat, että nykyisten virusten ja turvallisuusrikkomusten aikana on erityisen kriittistä ymmärtää olemassaolevat ja potentiaaliset uhat järjestelmälle. Turvallisuustodistukset ovat aikaavieviä, mutta vaiva maksaa itsensä takaisin, koska sillä voi ehkäistä lataamasta vahingossa viruksia tai muuta vahingollista koodia. Rinnakkaisten ja hajautettujen järjestelmien yleistyminen sekä tietoliikenteen kasvu ovat erityisesti lisänneet spesifioinnin ja verifioinnin merkitystä. Esimerkiksi tietoliikenneverkkojen reititys ja protokollien testaus ja verifiointi edellyttävät matemaattisia taitoja. 2.4 Algoritmien analyysi Matematiikka on keskeistä algoritmien suunnittelussa ja analyysissa. Vastaväitteenä voidaan esittää, että riittää kun jotkut osaavat analysoida algoritmeja, toiset voivat aina valita valmiin algoritmin. Tämä ei kuitenkaan ole helppoa! Käytännön ongelmat ovat usein spesifejä 3 ja monimutkaisia, ja toteuttajan on itse kyettävä valitsemaan paras toteutustapa. Matemaattiset todistukset ovat ainut tapa valita paras vaihtoehto. [BSKT03] Algoritmin analyysitaitoja tarvitaan hyvinkin jokapäiväisissä ohjelmointitehtävissä, kuten seuraava yksinkertainen esimerkki [BSKT03] havainnollistaa: Tehtävänä on sijoittaa alkioita yksi kerrallaan taulukkoon. Kun taulukko täyttyy, sitä on kasvatettava. Kannattaako sitä kasvattaa aina vakiomäärän F verran vai tietty prosenttimäärä p% entisestä koosta? Kun analysoidaan kumpikin vaihtoehto, huomataan, että ensimmäisellä tavalla alkion lisäys maksaa keskimäärin O(n) kun toisella tavalla lisäyksen keskimääräinen kustannus on vakio! Vaihtoehtojen välillä on siis iso ero, mutta tämän havaitseminen edellyttää algoritmin matemaattista analyysia. 2.5 Ohjelmointikielten kääntäjät Orponen [Orp97] muistuttaa, että korkean tason ohjelmointikielet ja niiden tehokkaat kääntäjät ovat ohjelmisto- 3 Itse asiassa kaikkia mahdollisia laskennallisia ongelmia on ylinumeroituvan monta, joten samanlaisen ratkaistun ongelman löytäminen on hyvin epätodennäköistä.
Hämäläinen 49 tuotannon perusdellytys edelleen haastava tehtävä! Ohjelmointikielten syntaksi on määritelty formaalisti kontekstittomilla kieliopeilla, jolloin sekä kääntäjän laatijalle että ohjelmoijalle on selkeää, mikä on laillinen syntaksi. Ohjelmointikielet ja niiden kääntäjät kehittyvät jatkuvasti, mutta näiden lisäksi jäsennysteoria on saanut uuden haasteen XML:stä. XML:ää voidaan jäsentää kuten ohjelmointikieliä ja tuottaa jäsennyspuita. Näitä puolestaan voidaan verifioida tietotyyppimäärittelyjä vasten samantapaisilla tekniikoilla kuin kääntäjien tyyppitarkistimet. XML:n tietotyypit eivät kuitenkaan ole kiinnitettyjä, vaan yhteistä dataa käyttävät ryhmät voivat sopia uusia merkintöjä erilaisten tietotyyppien esittämiseen. Tietotyypin rakenne voidaan määritellä samaan tapaan kuin säännölliset lausekkeet. Tällöin voidaan tarkastaa yksinkertaisilla äärellisiin automaatteihin perustuvilla algoritmeilla, että tuleva tieto on tyyppimäärittelyn mukaista. Kielioppeihin perustuvilla algoritmeilla voidaan puolestaan jäsentää ja muuntaa data muihin formaatteihin. [BSKT03] 2.6 Tietoverkot Tietoverkkojen voimakas kasvu on synnyttänyt uusia polttavia haasteita tietojenkäsittelytieteen teorialle. Edellä mainitsin jo tietoliikenneprotokollien verifioinnin, jolla pyritään varmistamaan, ettei viestejä katoa tai monistu eikä järjestelmä lukkiudu. Tiedonvälitykseen liittyy myös toisenlaisia turvallisuusongelmia: Ensinnäkin tieto pitäisi kyetä suojaamaan asiaankuulumattomilta tahoilta, ja toiseksi on kyettävä varmistumaan lähettäjätietojen aitoudesta. Ns. julkisen salauksen avaimen salausjärjestelmät ovat esimerkki salausalgoritmeista. Muita kryptografian sovelluskohteita ovat sähköinen tunnistaminen (esimerkiksi sähköraha ) ja yksityisyyden suojan turvaaminen. Kaikki nämä edellyttävät hyvin laaja-alaista matematiikan osaamista. (Ks. esimerkiksi Orponen [Orp97]). 2.7 Muita sovelluksia Edellä luetellut sovellusalueet eivät suinkaan kata kaikkia tietojenkäsittelytieteen alueita, joissa matematiikkaa tarvitaan. Esimerkiksi tietokonegrafiikka on nykyisin huomattava tuotannonala, joka edellyttää lineaarialgebraa. Tehokkaiden tiedonhakumenetelmien (information retrieval) merkitys on kasvanut entisestään tietomäärän paisuessa. Alan sovelluksissa tarvitaan mm. todennäköisyyslaskentaa, matriisilaskennan perusteita ja formaalien kielten teoriaa. Muita tärkeitä sovellusallueita ovat mm. relaatiotietokannat, hahmontunnistus, koneoppiminen, bioinformatiikka sekä muut muista tieteistä nousevat laskentatehtävät.
50 Miksi matematiikkaa 3 Miten opettaa matematiikkaa? Henderson [Hen03] korostaa, että on tärkeää opettaa matemaattiset peruskäsitteet mahdollisimman varhaisessa vaiheessa opintoja, ja käyttää ja vahvistaa niitä sitten myöhemmillä tietojenkäsittelytieteen kursseilla. Riittävällä harjoittelulla matemaattiset käsitteet muuttuvat mielen sisäisiksi ja tukevat ajattelua. Tucker et al. [TKB01] korostavat, että teoria ja käytäntö tulee integroida toisiinsa ja matematiikkaa tulee käsitellä myös tietojenkäsittelytieteen käytännöllisemmillä kursseilla. Myös Valmari [Val01] ja Page [Pag03] ovat korostaneet, ettei matematiikkaa tule opettaa irrallaan tietojenkäsittelytieteen sovelluksista. Esimerkiksi induktiotodistuksen esimerkit voivat koskea ohjelman/ohjelmiston oikeellisuutta tai resurssien käyttöä. Pagen [Pag03] kuvaamassa Besemeprojektissa diskreettiä matematiikkaa opeteltiin funktionaalisen ohjelmoinnin avulla. (Ohjelmointikielenä oli Haskell, mutta vastaavissa projekteissa on käytetty myös Schemeä.) Perusajatuksena oli, että funktionaalinen ohjelmointi tarjoaa suoraviivaisen tavan esittää matemaattisia käsitteitä kuten predikaattilogiikka ja todistus induktiolla. Beseme-projektin materiaalissa funktionaalisia ohjelmia käytettiin ilmaisemaan ehtoja, joita minkä tahansa funktion (esimerkiksi lisäys listaan tai puuhun, puun tasapainotus) oli täytettävä toimiakseen oikeellisesti. Beseme-projektissa havaittiin opiskelijoiden pärjäävän paljon paremmin käytännön ohjelmistotuotantotehtävissä, kun he olivat opiskelleet diskreettiä matematiikkaa sovellettuna ohjelmistotuotteisiin. Merkittäväksi havainnon tekee se, että projektiin osallistuvat opiskelijat olivat hieman keskimääräistä vähemmän lahjakkaita, mutta kurssin jälkeen heidän taitonsa olivat paremmat kuin lahjakkaampien, perinteisesti diskreettiä matematiikkaa opiskelleiden opiskelijoiden. Tämä antoi aihetta johtopäätökseen, että loogisen päättelyn harjoittelu ohjelmistotuotteilla tehostaa opiskelijoiden kykyjä käytännön ohjelmistojen kehittäjinä. 4 Millaista matematiikkaa tietojenkäsittelijä tarvitsee? Sekä ACM:n curriculumin että asiantuntijoiden mukaan diskreetti matematiikka on tärkein matematiikan osa-alue, jota tietojenkäsittelijä tarvitsee. Toinen tärkeä alue on todennäköisyyslaskenta, jonka perusteet on integroitu ACM:n vuoden mittaiseen diskreettien rakenteiden kurssiin. Tämän lisäksi ACM:n curriculum suosittelee sisällyttämään muitakin matematiikan kursseja, erityisesti vuoden kurssia differentiaali- ja integraalilaskennasta kehittämään matemaattista kypsyyttä ja ajattelua sekä varmistamaan riittävät esitiedot [cur01]. Curriculumin muilla kursseilla ei matematiikkaa kuitenkaan tarvita: matematiikkaa vaati-
Hämäläinen 51 vat kurssit kuten ohjelmistokielet, algoritmit ja tietorakenteet, laskennan teoria, numeerinen ja symbolinen laskenta on joko kokonaan pudotettu ydinaineksesta tai niiden osuus on karsittu minimiin. Jäljellä olevat kurssit on suunniteltu mahdollisimman käytännöllisiksi, niin että lopputulos muistuttaa enemmän kokoelmaa nykyteknologian tekniikoista ja tuotteista kuin tiedettä, kuten Tucker et. al [TKB01] toteavat. Tämä on omiaan vahvistamaan opiskelijoiden käsitystä, ettei matematiikkaa tarvita käytännössä. Siksi olisikin tärkeää integroida teoria ja käytäntö kaikilla curriculumin kursseilla. Valmari [Val01] on muistuttanut, että ohjelmistotuottaja tarvitsee erilaista matematiikkaa kuin fyysikko tai insinööri. Opintoihin pakollisena kuuluva mutta valtaosalle tarpeeton matematiikka koetaan vain turhana rasitteena, joka kasvattaa opiskelijoissa negatiivisia asenteita matematiikkaa ja teoriaa kohtaan. Differentiaalimatematiikan ja muiden numeeristen menetelmien sijasta Valmari suositteleekin keskittymistä diskreetin matematiikkaan, logiikkaan ja laskennan teoriaan. Tärkeintä on, että opiskelijat oppivat työkaluja, joilla käsitellä, ryhmitellä ja jäsentää käsitteitä sekä ilmaista niiden välisiä suhteita, kuten diskreetit rakenteet, tilakoneet, kieliopit, aikavaativuusluokat ja induktio. Jos opiskelija oppii ymmärtämään näistä useimmat, se harjaannuttaa häntä ajattelemaan täsmällisin käsittein. Muita matematiikan kursseja opiskelijat voivat sitten valita suuntautumisensa mukaan. Viitteet [Alm03] V.L. Almstrum. What is the attraction to computing? Communications of the ACM, 46(9):51 55, Sep 2003. [BSKT03] K.B. Bruce, R.L. Scot, C. Kelemen, and A. Tucker. Why math? Communications of the ACM, 46(9):41 44, Sep 2003. [CMCP + 99] E. Ciapessoni, P. Mirandola, A. Coen- Porisini, D. Mandrioli, and A. Morzenti. From formal models to formally based methods: an industrial experience. ACM Trans. Softw. Eng. Methodol., 8(1):79 113, 1999. [cur01] Computing curricula 2001. Technical report, ACM, December 15 2001. http://www.computer.org/ education/cc2001/final/ index.htm. [CW96] E. M. Clarke and J. M. Wing. Formal methods: state of the art and future directions. ACM Comput. Surv., 28(4):626 643, 1996. [Dev03] K. Devlin. Why universities require computer science
52 Miksi matematiikkaa [HBD + 01] [Hen03] [LFB96] students to take math. Communications of the ACM, 46(9):37 39, Sep 2003. P. B. Henderson, D. Baldwin, V. Dasigi, M. Dupras, J. Fritz, D. Ginat, D. Goelman, J. Hamer, L. Hitchner, W. Lloyd, Jr. B. Marion, C. Riedesel, and H. Walker. Striving for mathematical thinking. In Working group reports from ITiCSE on Innovation and technology in computer science education, pages 114 124. ACM Press, 2001. P.B. Henderson. Mathematical reasoning in software engineering education. Communications of the ACM, 46(9):45 50, Sep 2003. P. G. Larsen, J. Fitzgerald, and T. Brookes. Applying formal specification in industry. IEEE Softw., 13(3):48 56, 1996. [Orp97] P. Orponen. Matematiikka ja tietojenkäsittelytiede. Arkhimedes, (2):25 29, 1997. [Orp03] P. Orponen. Mitä tietojenkäsittelyteoriaan kuuluu? Tietojenkäsittelytiede, (19):15 28, 2003. [Pag03] R.L. Page. Software is discrete mathematics. ACM SIGPLAN Notices, 38(9):79 86, September 2003. [PH97] [Sob00] [TKB01] [Val00] S. L. Pfleeger and L. Hatton. Investigating the influence of formal methods. Computer, 30(2):33 43, 1997. A. E. Kelley Sobel. Empirical results of a software engineering curriculum incorporating formal methods. In Proceedings of the thirtyfirst SIGCSE technical symposium on Computer science education, pages 157 161. ACM Press, 2000. A.B. Tucker, C.F. Kelemen, and K.B. Bruce. Our curriculum has become mathphobic! SIGCSE Bulletin, (33):243 247, 2001. A. Valmari. Kun ohjelmistotuotanto ei riitä. Tietojenkäsittelytiede, (13):10 14, Kesäkuu 2000. [Val01] A. Valmari. Matematiikan tarve ohjelmistotyössä. Arkhimedes, (2):18 22, 2001.