Oppimispäiväkirja

Ohjelmistojen suunnittelumenetelmät ja -työkalut

Tämä oppimispäiväkirja on Jyväskylän yliopiston kurssille Ohjelmistojen suunnittelumenetelmät ja -työkalut syksyllä 2004.

1. luento: Korppi

Oppimispäiväkirjan pitäisi olla mukava tapa suorittaa kurssi, sillä tarkoitus on sisällön pänttäämisen sijaan pohtia. Tämä on ensimmäinen oppimispäiväkirjani, vaikkakin kolmas, jota yritän aloittaa. Tämän päiväkirjan ensimmäinen aloitusyritys oli luennon jälkeen tiistaina. Nyt on toinen yritys, ja päiväkirjaohjelmistojen sijaan päädyin tekstieditoriin.

Ennen ensimmäistä luentoa käsitykseni kurssista oli lähes olematon. Ensimmäisen luennon esitys pakostakin osoitti kurssin aihealuetta, ja demoaiheiksi mainitut Eclipse-kehitysympäristö ja Naked Objects -kehitysmenetelmä viittaavat ohjelmointiharjoituksiin. Kumpikaan aiheista ei ole minulle käytännössä tuttu, mutta kiinnostavat.

Korppi oli tuttu projekti ja sopiva esitys ensimmäiselle luennolle. Kysymyksiä esitettiin paljon ja monilla oli myös korjausehdotuksia Korpin tilanteeseen. Ne tuntuivat perustuvan opittuun joko tietojärjestelmien kehitysprojekteista tai ohjelmoinnista, mutta käytännössä ratkaisuihin tarvittaisiin molempia. Itsekin oli pakko kysyä hajautuksesta, kun tietokantapalvelimeen pullonkaulana oli vaikea uskoa.

Korppi kuitenkin on käytössä ja kehitys jatkuu, isosta kaupallisesta kilpailijasta huolimatta. Haluaisin ajatella, että Korppi on osoitus siitä, kuinka ohjelmistonkehitys onnistuu keveillä työkaluilla ja pienellä byrokratiallakin. Tärkeää olisi saada vastaus luennollakin sivuttuihin kysymyksiin: Mikä on Korpin olemassaolon oikeutus? Millaisia tuottoja ja kuluja Korpista on ollut? En haluaisi tarkkoja euromääriä, vaan kokonaiskuvan, joka ottaa huomioon myös arvot, joita ei mitata rahassa.

Korppi on sekä iso että tyypillinen ohjelmisto — siinä mielessä että Linux, Apache, Tomcat, Java-servletit ja JSP ovat käytössä muuallakin www-sovelluksia kehitettäessä. Nyt sovellusprojektien opiskelijat saavat kehittää siihen uusia palikoita. Sekä sovellusprojekteissa että muillakin kursseilla voitaisiin ottaa tutkittavaksi ylläpitovaiheessa muodostuneita ongelmia: automaattinen testaus, koodin siistiminen refaktoroimalla, koodin ja tietokannan dokumentointi, uudelleenkäytön helpottaminen luetteloimalla, ohjelmiston uudelleenmodularisointi, Java–JSP-suhde, paremmat versionhallintajärjestelmät.

1. demotilaisuus: keskustelua

Demot alkoivat pienellä porukalla ja tutuista työkaluista varovasti keskustellen. Itse olen pääasiassa käyttänyt tekstieditorina Emacsia, kääntö- ja kokoamistyökaluna Makea ja versionhallintaan CVS:ää. Ohjelmointikielistä ei tainnut olla puhetta, niistä mainitsisin ainakin Javan, C:n, Pythonin ja Haskellin. Kommunikaatiokin jäi sivuun, sähköpostin lisäksi olen käyttänyt paljon wiki-sivuja ja IRC-keskusteluja.

Emacs-käyttäjänä en ole edistynyt juurikaan syntaksiväritystä pidemmälle. En oikeastaan pidä tekstitilassa toimivista ohjelmista sekavuuden ja heikon opittavuuden vuoksi. Vaikka Emacsissa on myös jonkinlaiset valikot, ei niidenkään avulla paljoa opi. Demoissa kuulin, että Emacsista voisi saada käyttöönsä kaikki ominaisuudet, jotka graafisista kehitysympäristöistäkin löytyy. Agoralla tuskin onnistuu, kun edes syntaksiväritystä ei ilmeisesti ole asennettu.

Viimeisimmässä ohjelmointiprojektissa käytin versionhallintaan Darcsia, ja ihastuin siihen heti. En opetellut sen käyttöä, mutta ilmeisesti aiempi CVS:n käyttö ja GNU Archin (entisen TLA:n) opettelu antoivat tarvittavan pohjan. Viimeisimmällä työpaikallani huomasimme, että CVS ei oikein sovi hajautettuun ohjelmistokehitykseen: versioiden täytyy kulkea keskitetyn palvelimen kautta (joka on jumissa aina kun on kiire) ja versiomalli ohjaa vahvasti yhteen, viralliseen, uusimpaan versioon, johon kehittäjät tekevät hyvin pieniä muutoksia kerrallaan. Darcsissa jokainen koodin kopio on oma versiovarastonsa, ja muutoksia voi siirrellä minkä tahansa varastojen välillä. Varaston voi julkaista mm. www-palvelimella ja muutoksia siirtää sähköpostina.

Kysyin, onko aiheena pelkästään työkalut vai myös menetelmät. Taas tuli sellainen kuva, että ei menetelmiä käytännössä noudateta. Jonkinlainen iteratiivinen tai ketterä kehitysprosessi voi olla, mutta mitään tiettyä menetelmää ei valita eikä sovelleta kokonaisuutena. Luotan itsekin enemmän hyvään projektijohtoon ja kommunikaatioon, mutta esimerkiksi Extreme Programmingia voisi olla hyödyllistä joskus kokeilla käytännössä. Törmäsin taas myös siihen, että olisin ottanut omakseni kurssin Oliokeskeinen tietojärjestelmien kehittäminen, vaikken siitä lainkaan pitänytkään. Kyllä siellä yksinkertainen ohjelmistonkehitysmenetelmä opetetaan.

Satuin demotilaisuutta seuraavana päivänä kyseisen kurssin luennolle, ja jonkun kalvon yläreunassa puhuttiin "UML-menetelmästä". Ehkä kaikki peruskurssit ovat opiskelijoiden harhaanjohtamista.

2. luento: Pupesoft.com

Ihme kyllä olin jostain kuullut Pupesoft.com-kirjanpito-ohjelmistosta aikaisemminkin. Projekti ei silloin herättänyt luottamusta, eikä nytkään. Uutisryhmistä löytyi muutama maininta ohjelmistosta, mutta esimerkiksi Freshmeatin vapaaohjelmistohakemistoon sitä ei ole ilmoitettu. Suomenkielinen (minkähänkielinen koodi on?) ja Suomen oloihin kehitetty vapaaohjelmisto levinnee käyttäjältä toiselle, jos kokemukset siitä ovat hyviä.

Vaikka projektin lähdekoodi onkin julkaistu vapaaohjelmistolisenssillä, en kutsuisi itse projektia vapaaohjelmistoprojektiksi ennen kuin ohjelmiston versiot, moduulit, versionhallinta, sähköpostilista ja bugiseuranta on kuvattu julkisesti ja muilla on mahdollisuus osallistua kehitykseen.

Luennon perusteella Pupesoftin kehittäjäyritys Arwidsonissa on edistyksellinen tietotekniikkastrategia ja se on onnistunut esimerkillisesti. Tietotekniikka ei ole haitannut liiketoimintaa vaan tukenut sen prosesseja, eivätkä investoinnit ole olleet suuria. Vähitellen on sisäisesti kehitetty nopea, luotettava, helppokäyttöinen ja yhdenmukainen järjestelmä, joka hyödyntää lain tarjoamat mahdollisuudet koneistaa toimintaa.

Metaforista oppimani perusteella käsittäisin, että koneistetut järjestelmät usein simuloivat paperinkäsittelyä. Hyödyllinen metafora taas olisi mahdollisimman kaukana entisestä, jotta hyödynnettäisiin uutuudet. Luennon perusteella Pupesoftissa keskeinen metafora olisi kirjanpidon tapahtuma. Yrityksen tuttujen prosessien onnistunutta ja suhteellisen suoraviivaista koneistusta kuvaisi se, että tällainen yksinkertainen käsite on muuttunut joukosta epämääräisesti yhteenliittyviä paperidokumentteja tosiaikaisesti seurattavaksi, liiketoiminnan kaikki vaiheet yhdistäväksi sovellus- ja käyttöliittymäelementiksi.

Arwidsonin ratkaisujen yleistymistä estänee, että yritys lienee monin tavoin epätavallinen. Ennen vapaaohjelmistoja käytössä oli Applen tuotteet. Järjestelmät ovat myös olleet itsetehtyjä ja kehittäjät sovellusalueensa asiantuntijoita. Yrityksen edistyksellisyyttä kuvaa myös, että muissa yrityksissä tietotekniikkaa vielä ulkoistetaan, toisiin kulttuureihinkin. Muilla voi jo olla käytössä ulkoistettuja vapaaohjelmistoja tai omien sovellusasiantuntijoiden vetämiä kehitysprojekteja. Ehkä yhdeltä kannalta otettu aktiivinen rooli ja tietotekniikan mahdollisuuksien näkeminen saavat jatkossa panostamaan lisää.

Arwidson ei nähdäkseni vielä ole antanut vapaaohjelmistoyhteisölle takaisin läheskään yhtä paljon kuin on saanut. Se ei kuitenkaan haittaa, sillä informaation saaminen ei ole muilta pois, joten riittää kun jokainen antaa takaisin minkä sopivaksi katsoo. Sitä paitsi jo vapaaohjelmistojen käytöstä luennointi edistää niiden asiaa. Kaikilta pois on tiedon patentointi ja muu tiedonkäytön rajoittaminen esimerkiksi tekijänoikeuksien haltijoiden keinotekoiseksi eduksi.

2. demotilaisuus: ohjelmoijatestausta Eclipsellä

Olin tehnyt testejä JUnitilla aiemminkin ja Jonne oli pitänyt jollain kurssilla luennon ohjelmoijatestauksesta Eclipsellä. Muille nämä saattoivat olla täysin tuntemattomiakin, vaikka graafista Java-kehitysympäristöä ehkä olikin käytetty. Automaattisissa testeissä vaikeaa on ainakin oppia, kuinka paljon on järkevää testata ja kuinka erikoisempia syöte- ja tulostemuotoja kuten verkkoliikennettä tai OpenGL:ää testataan. Ohjelmoijatesteistä en ole vielä missään saanut kattavaa kokonaisuutta, ehkä osasyynä on ollut kiire kirjoittaa ominaisuudet ennen testejä. Joka tapauksessa näitä on hyvä harjoitella käytännössä.

Valitettavasti Agoran mikroluokkien ohjelmointiympäristö on huono. Windowsista ei taida saada säätämälläkään sopivaa, muttei edes Emacsia ja Eclipseä saada asennettua sinne kunnolla — Eclipsestä puuttui tutoriaaleja ja API-dokumentaatiota. VNC-yhteys Linux-palvelimelle toimii tuurilla tai säätämällä, mm. näppäimistöongelmia lukuunottamatta. Palvelimella ei ole Javaa tai Eclipseä asennettuna, mutta sinne ne sentään voi hakea suht nopeasti.

Oma laskurinkasvatustestimme testasi vain, että lisäyksen jälkeen arvo oli 1, joten testi ei ollut kovin hyvä. Esimerkkiratkaisussa taas kutsuttiin lisäystä satunnainen määrä kertoja, jonka jälkeen tarkistettiin, että arvo oli kyseinen satunnaisluku. Näin ainakin varmistettiin, ettei palauteta vakioarvoa. Olen aiemmin oppinut, että testien tuloksen pitäisi olla vakio — eikä siis riippua satunnaisluvusta — jotta tulos olisi aina toistettavissa ja olisi selvää, läpäiseekö ohjelmistoversio testit vai ei. Jos satunnaisluku sattuu kahteen miljardiin, testin suorituskin kestää jo jonkin aikaa. Parempi voisikin olla jokin seuraavanlainen:

laskuri.lisää();
assertEquals(1, laskuri.arvo());
laskuri.lisää();
assertEquals(2, laskuri.arvo());

Tällä yksinkertaisella, nopealla ja vakiotuloksisella testilläkin varmistuisi, että laskurin tila vaikuttaa lisäykseen ja että ainakin kahdessa tapauksessa arvo kasvaa yhdellä. Yksinkertaisuusperiaatteen mukainen this.arvo = 1; ei enää riitä, eikä ainakaan tule mieleen molemmat varmistukset läpäisevää yksinkertaista toteutusta, joka ei olisi this.arvo++;. Totta kai vaikka jakojäännöksen tai ehtolauseen lisäämällä testiä voi huiputtaa, mutta ainakaan ohjelmoijatestien tapauksessa tätä mahdollisuutta ei kannata huomioida.

Raja-arvoistakin 0 tulee testattua. Kuten esimerkkiratkaisun kerrotusta virheestä huomasimme, toinen olisi laskurin maksimiarvo. Sitä varten kirjoittaisin erillisen testin, sillä se on kasvatuksesta erillinen ominaisuus. Testillä voisimme määritellä, että maksimiarvon ylityksestä tulisi sopiva ajonaikaisesti tarkistettu poikkeus. Viimeisimmässä projektissani opin, että myös poikkeuksenjälkeinen tila kannattaa määritellä. Jotain tällaista siis:

public void testaaMaksimiarvo() {
    laskuri.arvo = 0x7FFFFFFF; // INT_MAX
    try {
        laskuri.lisää();
        fail("Maksimiarvon ylitys ei aiheuttanut poikkeusta.");
    } catch (ArithmeticException _) {
        // Odotettu
    }
    assertEquals(0x7FFFFFFF, laskuri.arvo());
}

3. luento: tietoturvaohjelmistot

SSH Communications Security edustaa tietoturvan perinteistä, tietoliikenteen tekniseen turvallisuuteen perustuvaa näkökulmaa. Vaikka Bruce Schneier ja muut ovat nostaneet kokonaiskuvan ja ihmislähtöiset puitteet suosioon, näkisin kuitenkin, että fyysisten rajoitteiden vähentyessä salausteknologiat muodostavat pohjan kaikelle turvallisuudelle. Ennen luentoa en ollut ajatellut kuinka SSH ja F-Secure edustavat vastakkaisia näkökulmia.

Oli mukava kuulla, että Tatu Ylösen alkuperäinen päätös julkaista SSH vapaaohjelmistona ei ole estänyt yrityksen liiketoimintaa. Toisaalta he eivät ilmeisesti olleet tuloksiin tyytyväisiä, koska enää heillä ei ole vapaaohjelmistokehitystä. Viimeisestä vapaaohjelmistoversiosta jatkokehitetty OpenSSH auttaa varmasti edelleen yritystä pitämällä SSH2-protokollaa standardina, jota siitä tuskin kaupallisena tuotteena olisi tullut. Sitä ihmettelen, että vaikka eräs monopoliyritys on saatu painostettua näyttämään osia lähdekoodistaan joillekin valtioille, SSH:n koodia ei ole kukaan halunnut nähdä.

Ohjelmointikielet, -paradigmat ja -mallit kiinnostavat minua, koska ajattelen ohjelmoinnin ongelmia ilmaisun kautta. Kielivalintana C ei ollut yllätyksellinen, eivät myöskään perustelut sen käytön puolesta tai vastaan. Sen sijaan Schemen käyttö oli yllätys. Tärkeä syy sen valinnalle skriptikieleksi oli ilmeisesti, että Teknillisessä korkeakoulussa tietotekniikkaa opiskelleille se on tuttu. Eipähän tarvitse generoida koodia piirustusten perusteella, kun kieli mahdollistaa rankatkin abstraktiot.

Tapahtumapohjainen ohjelmointimalli mainittiin ratkaisuna, jos säikeitä ei ole käytettävissä. Olen ollut erittäin tyytyväinen Twisted Pythoniin, jossa kaikki verkko-ohjelmointi tarkoituksella hoidetaan tapahtumien mukaan kutsutuilla käsittelyfunktioilla säikeiden sijaan. Esimerkiksi Javan käyttöliittymäkirjastojakin käytetään tapahtumapohjaisesti. Ei tietenkään kannata yrittää selvitä ilman abstraktioita, vaan esimerkiksi satunnaisina paketteina verkosta tulevan tietovirran voi lähettää ylemmille tasoille merkityksellisen kokoisiksi puskuroituina viesteinä.

Luennon yleisö halusi keskustella myös käytettävyyden ja tietoturvan suhteesta eräissä laajalti käytetyissä ohjelmistoissa. Yleinen väite on, että käytettävyys ja tietoturva ovat vaihtoehtoisia. Luennoitsija sai mielestäni hyvin osoitettua, että käytettävyyttä varten ei tarvitse uhrata kaikkea tietoturvaa: taulukkolaskentatiedostoissa ei tarvitsisi ainakaan oletuksena sallia käyttöjärjestelmäkutsuja. Tuli mieleen myös, ettei pitäisi olla tarvetta ajaa www-selainta pääkäyttäjän oikeuksilla, vaan vain niitä yksinkertaisia ohjelmia, joilla käyttöoikeuksia säädetään.

3. demotilaisuus: johdanto Naked Objects -kehykseen

Nimen perusteella saattoi arvata, että Naked Objects yrittää olla ohjelmointia oikeilla, lisämausteettomilla oliolla. Käytännössä tuli vaikutelma vähänkäytetystä komponenttisovelluskehyksestä. Odotin ehkä pienempää kirjastoa — tai ehken valmista koodia ollenkaan — ja että Javaa olisi käytetty suoremmin.

Demo-ohjelma oli myös yllätys, mutta johti pian ilmeisesti oikeille jäljille. Käyttöliittymän oppiminen vei useammankin hetken, enkä vieläkään ymmärrä käyttöä kokonaan. Käyttö olisi varmaankin voitu opettaa nopeastikin, mutta olisimme menettäneet tilaisuutemme kokea helppokäyttöisyys tai sen puute. Mitenkään komeaksi en ulkoasua sanoisi, joten pian mietimmekin miten vaihtoehtoisia käyttöliittymiä toteutettaisiin ja kuinka se laajentaisi sovellusaluetta esimerkiksi peleihin.

En ehtinyt kirjoittaa tehtävänä ollutta kerhon jäsenkortistoa juurikaan. Lähdin kirjoittamaan koodia yksinkertaisuusperiaatteella, mikä auttoi selvittämään että AbstractNakedObject ei ole oikeastaan toteutukseltaan mitenkään abstract. Koodiesimerkitkin olisivat ehkä voineet lähteä mahdollisimman yksinkertaisesta ja lisäykset olisi sitten perusteltu kommenteissa.

4. luento: sovellusintegraatio

Luento oli hyödyllinen selventämään, mistä aakkoskeitossa oikein on kysymys. Luulisin, että loppupuolella oli oleellinen sivuhuomautus, että kyseessä eivät olleet triviaalitapaukset vaan kymmenien järjestelmien integrointi. Samoin aihetta rajoitti, että oli kyse integrointia huomioimatta toteutetuista yrityssovelluksista.

Kanditutkielmassani olen uppoutunut toisenlaiseen, ehkä tutumpaan integrointiin. Käyttöjärjestelmä, ohjelmointikieli ja kirjastot muodostavat sovellusalustan, jolla sovellusohjelmat tietyssä määrin integroituvat suoraan tai ominaisuuksien normaalin toteutuksen myötä. Tommi Kärkkäinen ehdotti heti alkujaan, että haen varmaankin takaa jotain samankaltaista kuin yrityssovellusintegraatio. En osannut luennolla kysyä, kuinka nämä voisivat liittyä toisiinsa.

Näin jälkikäteen ajateltuna kyse voisi olla vaikka siitä, kuinka merkittävää on, onko integroitavat sovellukset kaikki kehitetty vaikkapa J2EE:llä. Sovellusintegraation puolesta hyviä perusteluita olivat, että yrityksissä on käytössä paljon järjestelmiä ja lisäksi niiden elinkaaret eroavat toteutusteknologioiden elinkaarista. Järjestelmiä myös integroidaan organisaatiorajojen yli, jolloin ei ole mahdollista vaihtaa kaikkien toimijoiden alustaa samaksi.

Päällimmäisenä epäilyttävää oli tiedon eheys sovellusten välisillä rajoilla ja tietoturva. Edelleen voi ajatella integraatioratkaisua eräänä ohuena järjestelmäarkkitehtuurina valmiiden palikoiden päällä. Riippuen toivotuista laadullisista vaatimuksista arkkitehtuurin pitäisi olla erilainen. Perimmillään oli kuin sovelluskehitys olisi kopioitu uudelle tasolle: sovitinrajapinnat, sovitinsovittimet, pyritään yhteen integrointiympäristöön. Aikaisemmalla luennolla kuulimme jo vaihtoehdon: muutama työntekijä voi toteuttaa taloushallinnon kokonaisuutena ja uusimpia mahdollisuuksia hyödyntäen. Luennon aikana tuli mieleen tutkimuskysymys "Pitäisikö alustat suunnitella ja valita integrointiominaisuuksien perusteella?"

4. demotilaisuus: Naked Objects -kehitysmenetelmä

Itse asiassa kerhon jäsenrekisteri ei jäänytkään kovin pahasti kesken. Periaatteessa jo henkilöolioilla voidaan esittää yhden kerhon jäsenet. Lisäsin kuitenkin vielä kerho-oliot, joihin jäsenet voidaan merkitä kuuluviksi. En päässyt ohjelmoijatestien kokeilemiseen asti, muttei tainnut ehtiä moni muukaan. Esimerkkitestit näyttivät kyllä hienoilta — Naked Objectsissa on selvästi otettu testattavuus huomioon.

Näyttää kovin hassulta, kuinka sovellusalueen attribuutit ovat luokkien private final -jäseniä, ja sitten erikseen on public-saantimetodit. Ensinnäkin paljon turhaa kirjoittamista ja toisekseen noinko olio kapseloi käytöstä ja dataa? Ilmeisesti täytyy olla metodit resolve- ja objectChanged-kutsuihin käytön yhteydessä kentille, jotka eivät ole final. Taas Java estää piilottamasta asioita, joista sovelluskehys huolehtii. Ehkä saantimetodit ovat hyvä ratkaisu, kun attribuutit vieläpä esitetään suoraan käyttäjälle, sillä jotenkinhan käyttöliittymän pitää voida olioita käsitellä.

Erillinen lista attribuuteista järjestystä varten (fieldOrder-metodissa) tuo mieleen hakemistot tiedostojärjestelmässä. Usein olisi kätevää, että tiedostoilla olisi suoraan myös järjestys (siis muukin kuin luonti-, aakkos- tai satunnaisjärjestys).

Tällä hetkellä ihmetyttää eniten ettäkö Naked Objects olisi vastaisku datanmallinnustekniikoille: onko tässä muutakin joskus luvassa?

5. luento: Semantic Web

Työskentely VTT:llä ja yliopistolla on ilmeisesti samankaltaistunut, kun edellinen on syventänyt tutkimusta ja jälkimmäinen hankkinut yritysyhteistyötä. Opetustehtävän puuttuminen varmasti helpottaa projektien tasapainoilua VTT:llä, mutta vaikeuttaakohan se osaamisen säilyttämistä organisaatiossa? Vapaaohjelmistot kuulostivat yllättäen olevan enemmän arkipäivää kuin yliopistolla.

RDF on mielenkiintoinen standardi, vaikkei se sanokaan juuri mitään. Tietoa esitetään subjekti–predikaatti–objekti -kolmikoiden verkolla, jossa vähintään subjekti ja objekti ovat URIja. Käytännössä neljänneksi alkioksi pitää usein ottaa lähde, jotta esim. erotetaan tiedon rakenteen määritykset itse tiedosta. Vaan eipä XML-standardikaan paljoa määrää, syntaksin sentään.

Luennoitsijakin sanoi toisaalta, ettei käyttäjän pitäisi olla tekemisissä RDF:n kanssa, toisaalta että kaaviot voisi esittää käyttäjälle. Vaikka merkitystaso ei muutukaan eikä käytetä RDF-XML:ää, tekstuaalisesta esityksestä verkkoa ei hahmota, kun taas graafinen esitys antaa käyttäjän selata ja hahmottaa tietoa. Ensinnäkin väittäisin, että XML on yleistynyt RDF:ää nopeammin jo pelkästään siitä syystä, että RDF sopii huonosti tekstieditoriin.

Toiseksi yleiskäyttöinen, graafinen RDF-editori toisi RDF:n ja koko Semantic Webin lähemmäs ihmisiä, niin ohjelmistokehittäjiä kuin loppukäyttäjiä. Ohjelmistokehittäjän kannalta nykyiset RDF-syntaksit ovat pitkälti merkkimössöä, vain hieman parempaa kuin XML-tagimössö tai binäärimössö. Verkko, jossa asioita yhdistellään toisiinsa, ei voi olla kovin vieras, jos on piirrellyt ajatuskarttoja.

Kuten edelliselläkin luennolla, pyöritään kanditutkielmani aihepiirissä. Olen yrittänyt jäsentää, mitä RDF:n käyttö tarkoittaa sovellusohjelmoinnin ja integroinnin kannalta. Ontologioiden kohdalla mennään kuitenkin tämänhetkisen kokonaiskuvani yli: yhteinen sanasto on ymmärrettävästi hyödyllinen, mutta en näe tarvetta sijoitella oliot luokkiin ja rajoittaa attribuutteja. Sovellusohjelmissa olisi pitkä askel, jos samaa tietoa voisi käsitellä eri ohjelmissa, mutta www ja selaimet ovat kai jo tämän vaiheen ohittaneet. Tutkimuskysymys: tarvitaanko Semantic Desktop vai riittääkö RDF Desktop? Luennolla tuli havainnollinen vertaus: UML:n tavoin OWL:ää voi käyttää suunnitteluun ja viestintään.

5. demotilaisuus: prototyypin kehitys

Olin menossa demoluokkaan kaksi tuntia etukäteen mutta demot olivatkin kaksi tuntia aikaisemmin kuin muistelin, joten ajoitus oli erittäin täsmällinen. En olekaan ennen ohjelmoinut yhdessä muiden kanssa opiskeluun liittyen. Onneksi aiemmilla kerroilla olimme opetelleet Eclipsen yhteiseksi ympäristöksi ja sen CVS-käyttöliittymä toimii normaalin CVS:n tavoin.

Tarkoituksena oli toteuttaa Naked Objects -menetelmän tutkimusvaihe kirjaston lainausjärjestelmälle, mutta pieleen taisi mennä. Demo-ohjeen mukaan vaiheessa pitäisi toistaa olioiden ja niiden vastuiden määrittelyä, prototyypin toteuttamista ja toimintaskenaarioiden kokeilua protolla.

Ensimmäisen tunnin ajan yritimme kiristää asiakkaalta tarkkoja vaatimusmäärittelyitä ja piirsimme luokkakaavioita — vastuut siis jäivät ilman suoraa huomiota. Toisen tunnin aikana toteutimme jokainen jonkin luokan prototyypin. Rinnakkaisen toteutuksen vuoksi assosiaatiot jäivät yksisuuntaisiksi. Kokeilemaan emme päässeet, sillä tuhlasimme niukkaa aikaamme kokeilun kannalta turhiin olioiden attribuutteihin sekä hienoihin suomenkielisiin nimiin ja otsikoihin.

Emme varmaankaan olleet sisäistäneet aiempien demokertojen sisältöjä niin, että olisimme osanneet toimia niiden mukaisesti. Kokeilu oli kuitenkin kivaa ja saimme kaikista luokista toimivaa koodia valmiiksi. Toivottavasti voimme ensi viikolla lyhyen tilannekatsauksen jälkeen jatkaa tutkimusvaihetta. Määrittely- ja jakeluvaiheisiin ei taida olla aikaa, varsinkaan kun emme ehtineet kokeilla Naked Objects -testausta.

6. luento: www-sovellusten kehitys

Luennon ensimmäinen osuus oli siedettävä. Microsoftin edustaja esitteli yrityksen Suomen toimintoja, Microsoft Researchia ja Imagine Cup -kilpailua tunnin sen verran rivakasti ja sensuroidusti, ettei kysymyksiä tullut esitettyä. Myöhemmäksi mietittäväksi jäävät siis liikevoiton suuruuden eettisyys, tutkimuslaitoksen poissaolo Suomessa tai tarve rajoittaa kilpailutyökalut tiettyihin tuotteisiin. Fysiikkamallinnusdemossa piti tietenkin ajatella käyttöliittymää, ja mieleen tuli 3d-luonnosteluohjelma Teddy. (Hae ja pura zip-paketti, käynnistä komennolla java -cp teddy.jar teddy.Teddy.)

Toisen osuuden aihe, tarkoitus ja suunniteltu kohderyhmä eivät hahmottuneet. Valitettavasti tiesin www-sovellusten kehityksestä jo etukäteen sen verran, että yksinkertaiset väitteet lähinnä häiritsivät eivätkä ainakaan tuoneet mitään uutta. Kovin nopeasti ei saisi sanotuksi olio-ohjelmoinnista mitään sillä tasolla, jolla tällä kurssilla aihetta on jo käsitelty. Aiheenpa ei pitänytkään olla olio-ohjelmointi.

Käsitteet Internet, www ja nettisivu olivat tilaisuudessa hukassa. "Internet-pohjainen sovelluskehitys" voisi kai tarkoittaa IP-protokollaa käyttävien sovellusten ohjelmointia, mutta ennemmin Internetissä toimivien sovellusten kehitystä Internetissä. Jos aiheena olivat sovellukset, joiden käyttöliittymä on www, niin koulutusyrityksen edustaja oli hukassa. Sovelluksia www:ssä ovat kotisivut, verkkolehdet, tietohakemistot, hakukoneet, wikit …, eivätkä yritykset siirtää työpöytä- ja paperisimulaatioita www-selaimen tehtäväksi.

Toisin kuin edustaja esitti, oleellista www-sovellusta tehtäessä ei ole lomakkeen kenttien tarkastaminen selainpäässä, vaan vaikkapa löytämisen, navigoinnin ja luettavuuden varmistaminen. Ohjelmoijan kannalta www-sovelluksessa on mielenkiintoista, että ohjelmisto toimii palvelinpäässä, jolloin ympäristö voidaan valita teknisin perustein, eikä käyttäjien tarvitse ylläpitää ohjelmistoasennusta. Luentoa mielenkiintoisempi näkökulma www-sovelluksiin on vaikkapa Paul Grahamin essee The Other Road Ahead, jossa hän erään menestyksekkään kehityskokemuksen pohjalta toteaa muunmuassa: "I would not even use Javascript, if I were you. Viaweb didn't."

HTTP:tä ja HTML:ää käyttävää sovellusta kehitettäessä kannattaa miettiä, kuinka ohjelmakoodi ja HTML-koodi erotetaan vaikka templaateilla. Tilan säilyttäminen HTTP-pyyntöjen välillä on myös merkittävää ohjelmiston rakenteen kannalta. Ehkä Microsoftin tuotteissa oli hienoja vaihtoehtoja näihin, mutta hitaan puheen ja pienen fontin vuoksi ne eivät välittyneet ainakaan minulle. Tuote-esittelyssä taisi tällä kertaa jäädä kuuntelijan vastuulle keksiä, mitä ongelmia tuotteet mahtaisivat ratkaista.

6. demotilaisuus: prototyypin paikkailu

Kehitystyö tuntui pysähtyvän kuin liisteriin. Helpot hommat oli tehty edellisellä kerralla, nyt olisi pitänyt selvittää miten keskeiset ongelmat ratkaistaan. Samoin luokkien välisten suhteiden järjestäminen olisi vaatinut yhteisten päätösten tekemistä, mieluiten joidenkin tekemän kokeilun perusteella.

Jo viime demotilaisuudesta olisi voinut kommentoida, kuinka hierarkiaa ei muodostunut luonnostaan. Se ei haitannut silloin, enkä usko, että hierarkia olisi tälläkään kertaa innostanut kuin korkeintaan syyllisen etsintään. Jo viimeksi jäimme viilailuun, emmekä päässeet tälläkään kertaa käyttökokeiluihin, vaan nyt yritimme paikkailla pahimpia puutteita.

Kahden tunnin aikana ongelmien suuruus varmaankin konkretisoitui kaikille ja selvisi tarkemmin, mitä ongelmakohtia on. Assosiaation toteutukseen ei ole Javassa eikä Naked Objectsissakaan valmista avainsanaa, vaan pitää miettiä, millaiset viitteet olioiden välille tarvitaan ja kuinka niitä sovelluskehyksessä ylläpidetään.

7. demotilaisuus: prototyypin virittely

Viimeisessä demotilaisuudessa kehitys taisi mennä sen verran eteenpäin, että voimme kaikki olla tyytyväisiä työhömme. Ohjelmistosta ei tullut valmista, ei edes prototyypistä, mutta opimme Naked Objects -kehityksestä ja pääsimme edellisen kerran ongelmista eteenpäin.

Olin tällä kertaa mukana kirjoittamassa edellisellä kerralla aloitettuja hyväksymistestejä. Saimme neljästä käyttötapauksesta ensimmäisen testattua ja toisenkin pitkälti, tosin emme keksineet miten lainan palautuksessa saadaan olio tuhottua tai edes viitteet poistettua. Yritimme jossain vaiheessa dokumentaation lisäksi etsiä esimerkkejä, mutta mistään emme löytäneet näihin apua.

Testauksessa kirjoitettava koodi oli täysin erilaista kuin toimintoja toteutettaessa. Uuden käyttöliittymän kirjoittaminen olisi ehkä lähempänä, sillä hyväksymistestit kirjoitettiin eräänlaisten näkymien kautta (luokat org.nakedobjects.testing.View ja org.nakedobjects.testing.ClassView). Näkymien kautta oli ainakin periaatteessa käytettävissä samat toiminnot kuin käyttöliittymässä, ja näkymän metodikutsut kirjoittivat testin suorituksen aikana yksityiskohtaista käyttöohjetta. (Kielisotkusta näkyy hyvin, mikä on kehittäjien kirjoittamaa.)

Testejä kirjoittaessa meni pitkälti ohi, mitä muut saivat aikaan. Sovimme, että lopputulosta saa levittää. Lisäsin jälkikäteen projektiin Makefilen, jolla ohjelman voi kääntää, ajaa ja paketoida. Sen tuottaman jar-paketin voi hakea, ajaa komennolla java -jar kirjasto-2004-12-11.jar tai purkaa ja tutkia. (Laitoin myös CVS:ssä olevista lähdekoodi- ja projektitiedostoista paketin.) Nyt assosiaatiot näyttäisivät olevan testauskunnossa, mutta eivät ne vielä koko ajan pysy ristiriidattomina.

Mielestäni demotilaisuuksissa saatiin uusi, hyödyllinen kuva siitä, mitä olio-ohjelmointi ja sovelluskehyksen käyttö voi käytännössä olla. Naked Objects oli hauska myös siksi, että se soveltuu ilmeisesti hyvin nimenomaan "liiketoimintasovellusten" alustaksi — eli niiden, joita muka kannattaa kehittää "UML-menetelmillä" sun muilla.


http://www.iki.fi/Tuukka.Hastrup/2004/tie343/opk
© 2004 Tuukka Hastrup (Tuukka.Hastrup@iki.fi)

Valid XHTML 1.0!

Valid CSS!