OHJELMISTOKEHYSTEN ERIKOISTAMISTUTORIAALIT FRED- YMPÄRISTÖSSÄ

Transkriptio

1 TAMPEREEN TEKNILLINEN YLIOPISTO Tietotekniikan osasto PEKKA SAVOLAINEN OHJELMISTOKEHYSTEN ERIKOISTAMISTUTORIAALIT FRED- YMPÄRISTÖSSÄ Diplomityö Aihe hyväksytty osastoneuvoston kokouksessa Tarkastajat: Kai Koskimies (TTY) Juha Hautamäki (TTY)

2 Alkulause Olen tehnyt diplomityöni toimiessani tutkimusapulaisena Tampereen teknillisen yliopiston Digitaalisen median instituutissa. Työni on osa DMI:n Java Frames -projektia. Esitän kiitokseni työni tarkastajille, prof. Kai Koskimiehelle ja fil. lis. Juha Hautamäelle. Lisäksi kiitän erityisesti työtoveriani Markku Hakalaa hyvistä ohjeista työtä tehdessäni. Kiitän myös Anne Halosta hänen antamastaan tuesta ja kieliasun tarkistamisesta. Tampereella Pekka Savolainen Hikivuorenkatu 8-10 C Tampere puh ii

3 Sisällysluettelo ALKULAUSE...II SISÄLLYSLUETTELO... III TIIVISTELMÄ... V ABSTRACT...VI LYHENNELUETTELO JA TERMINOLOGIA...VII 1 JOHDANTO TAUSTA TUOTELINJA-ARKKITEHTUURIT Peruskäsitteitä Tuotelinja-arkkitehtuurin syntytavat Tuotelinja-arkkitehtuurien ongelmat Tuotelinja-arkkitehtuurien toteutustavat OHJELMISTOKEHYKSET Peruskäsitteitä Ohjelmistokehyksien syntytavat ja evoluutio Ohjelmistokehyksien ongelmat OHJELMISTOKEHYSTEN DOKUMENTOINTI Dokumentoinnin vaatimukset Perinteiset dokumentointitavat ja ohjelmistokehysten dokumentoinnin erityisongelmat Ohjelmistokehysten dokumenttityypit Dokumentoinnin ohjelmallinen tukeminen FRED IDEAT FREDIN TAUSTALLA FREDIN KÄSITTEISTÖ Mallit, roolit ja rajoitteet...28 iii

4 3.2.2 Mallien ja tehtävien suhde OHJELMISTOKEHITYS FRED-YMPÄRISTÖSSÄ Ohjelmistokehyksen kehittäjän näkökulma Sovelluskehittäjän näkökulma FRED KÄYTÄNNÖSSÄ JAVA PAGES TYÖKALUN TAUSTALLA OLEVAT IDEAT TYÖKALUN ESITTELY Java Pages -nauhoitin Java Pages -palvelin Java Pages -selain TYÖKALUN TOTEUTUS Java Pages -palvelimen ja -selaimen välinen tiedonsiirto Java Pages -nauhoitteen rakenne Java Pages -nauhoittimen integrointirajapinta JATKOKEHITYS KOKEMUKSIA JÄRJESTELMÄN TOIMINNASTA JATKOKEHITYSIDEOITA YHTEENVETO...59 LÄHDELUETTELO...60 VIITATUT URL-OSOITTEET...64 LIITTEET...65 LIITE LIITE iv

5 Tiivistelmä TAMPEREEN TEKNILLINEN YLIOPISTO Tietotekniikan osasto Ohjelmistotekniikka SAVOLAINEN, PEKKA: Ohjelmistokehysten erikoistamistutoriaalit Fred-ympäristössä Diplomityö, 64 s., 11 liites. Tarkastajat: prof. Kai Koskimies, fil. lis. Juha Hautamäki Helmikuu 2003 Avainsanat: Documentation, Framework, Fred, Guided Construction Tour, Pattern Tuotelinja-arkkitehtuurien ja ohjelmistokehyksien käyttö on yleistynyt ohjelmistotuotannossa. Näihin menetelmiin liittyy runsaasti tavoittelemisen arvoisia etuja, mutta tämänhetkisten työkalujen ja ohjelmointikielien tuki näille menetelmille ottaa vasta ensimmäisiä askeliaan. Fred on Tampereen teknillisen yliopiston ja Helsingin yliopiston yhteistyöhankkeena kehitetty työkaluprototyyppi, joka tukee ohjelmaelementtien arkkitehtonisten suhteiden kuvaamista uudelleenkäyttöä tukevalla tavalla. Työkalu valvoo, että ohjelmistokehyksen erikoistaja noudattaa valittua arkkitehtuuria. Tässä diplomityössä toteutettiin Java Pages -työkalu, prototyyppi välineestä, jolla voidaan nauhoittaa ohjattuja toteutusesimerkkejä Fred-ympäristössä. Ohjatun toteutusesimerkin luominen toteutetaan nauhoittamalla ohjelmistokehyksen mallitapauksen erikoistaminen Fred-ympäristössä ja hyödyntämällä Fredin käyttäjälle tarjoamaa ohjeistusta. Ohjattujen toteutusesimerkkien avulla ohjelmistokehyksien opettelu tapahtuu konkreettisten ja käytännönläheisten esimerkkien avulla. Luotuja esimerkkejä voi selata WWW-selaimessa, eikä selaaminen vaadi käyttäjältä ohjelmistojen asentamista tietokoneelle. Diplomityössä todettiin valittu lähestymistapa toimivaksi, mutta toteutettuun nauhoitustyökaluun liittyy vielä runsas joukko jatkokehitysajatuksia, joilla sen käyttömukavuutta voitaisiin parantaa. v

6 Abstract TAMPERE UNIVERSITY OF TECHNOLOGY Department of Information Technology Software Systems Laboratory SAVOLAINEN, PEKKA: Framework Specialization Tutorials in Fred Master of Science Thesis, 64 pages, 11 enclosure pages Examiner: prof. Kai Koskimies, lic. phil. Juha Hautamäki February 2003 Keywords: Documentation, Framework, Fred, Guided Construction Tour, Pattern Product line architectures and frameworks are becoming more and more important concepts in the field of software engineering. They promise benefits in the form of program code and design reuse, but currently only limited support for their implementation exists in the form of tools and programming languages. Fred is a result of co-operation of Tampere University of Technology and University of Helsinki. It is a prototype of a tool that supports describing complex architectural dependencies between program elements. It also automatically checks that the framework specialization fills the requirements of the architecture. In this thesis Java Pages tool was implemented and integrated to Fred environment. It allows framework architects to create tutorials about the use of their frameworks in the form of guided construction tours. The tutorials are created by recording user interactions in the Fred tool in the case of an example specialization. A guided construction tour has several benefits over a textbook tutorial. It allows software developers to look at concrete examples concerning the problems confronted during the framework specialization process. Java Pages tool is operated using a WWW-browser. It was noticed that the tool was based on a working concept. However, experiences showed that there are still some usability issues regarding the integration to the Fred environment. vi

7 Lyhenneluettelo ja terminologia Applet FAQ HTML JAR Java MIDP RMI SDK Servlet Socket UML WWW XML XML schema WWW-selaimen automaattisesti lataama ohjelma, jonka selain suorittaa, kun appletin sisältävälle sivulle saavutaan. Frequently Asked Questions; usein esitettyjen kysymyksien palsta. Hypertext Markup Language; WWW:ssä käytetty sivunkuvauskieli. Java Archive, Javan tarjoama tiedostomuoto resurssien pakkaamiseksi yhteen tiedostoon. Laitteistoriippumaton, Sun MicroSystemsin kehittämä imperatiivinen olio-ohjelmointikieli, jota ajetaan virtuaalikoneessa. Mobile Information Device Profile; Javan tarjoama kirjastojen kokoelma, joka tarjoaa ydinpalvelut kannettavien laitteiden ohjelmointiin. Remote method invocation; etämetodikutsuissa käytettävä tekniikka. Software Development Kit; kirjastoista ja työkaluista koostuva kokonaisuus, jonka avulla voidaan kehittää sovelluksia tietylle alustalle. Javan palvelinsovelluksissa käytetty tekniikka. Matalan tason tietorakenne, jota käytetään verkko-ohjelmoinnissa tietoliikenneyhteyksien mallintamiseen. Unified Modeling Language; notaatio, jolla voidaan kuvata ohjelman staattinen ja dynaaminen rakenne. World Wide Web; Internetin linkkien avulla graafisesti navigoitavissa oleva osa. extensible Markup Language; yleinen kieli rakenteellisten dokumenttien määrittelemiseksi. Tapa määritellä XML-dokumentilta vaadittava kieliopillinen rakenne. vii

8 1 Johdanto Ohjelmistotuotannossa ollaan vuosien varrella siirrytty pienistä järjestelmistä kohti suurempia ja suurempia ohjelmistotuotteita. Ohjelmistojen koon kasvu on ollut huomattavasti nopeampaa kuin ohjelmistotekniikan tuottavuuden kasvu [HaMä98]. Tärkeänä syynä tähän on se, että käytössä olleet työvälineet eivät ole kehittyneet yhtä nopeasti kuin ohjelmistojen koko ja monimutkaisuus ovat kasvaneet. Tuotelinja-arkkitehtuurien ja ohjelmistokehyksien avulla on pyritty vastaamaan tarpeeseen nostaa ohjelmistoprojektien tuottavuutta ja parantaa ohjelmistotuotteiden laatua. Keskeisenä ajatuksena on ollut uudelleenkäyttää jo ennestään testattua ja toimivaksi todettua ohjelmakoodia. Tuotelinja-arkkitehtuureilla pystytään nopeuttamaan useiden samankaltaisten tuotteiden toteuttamista tekemällä tuotteille yhteiset osat vain kertaalleen. Ohjelmistokehykset ovat yksi tapa toteuttaa tuotelinja-arkkitehtuuri. Ohjelmistokehykset ovat uudelleenkäytettävistä luokista ja rajapinnoista koostuvia sovellusrunkoja, jotka täydennetään suoritettavaksi ohjelmaksi sovelluskohtaisella ohjelmakoodilla. Ohjelmistokehyksillä on usein toisistaan erilliset kehittäjänsä ja soveltajansa. Kehysten soveltajat eli erikoistajat toteuttavat kehyksistä ohjelmia täydentämällä jotkin ohjelmistokehyksessä tyhjiksi jätetyt kohdat ohjelmistolle spesifisellä ohjelmakoodilla tai ylimäärittelemällä kehyksen tarjoamia toimintojen oletustoteutuksia. Voidakseen suorittaa ohjelman erikoistamisen kehyksestä erikoistajan on kuitenkin ensin opittava käyttämään ohjelmistokehystä. Ohjelmistokehyksen tapauksessa oppimisprosessi ei ole yksinkertainen, sillä erikoistamisrajapinta on usein laaja ja vaatii ohjelmistokehyksen käsitteiden tuntemista. Fred on prototyyppi työkalusta, jolla ohjelmistokehyksen kehittäjä voi luoda malleja, jotka ohjaavat ohjelmistokehyksen erikoistamisprosessia. Mallien perusteella Fred antaa ohjelmistokehyksen erikoistajalle ohjeita siitä, miten erikoistamisprosessia voi jatkaa. Käytännössä erikoistaja näkee tehtävälistassa tehtäviä, joita toteuttamalla hän suorittaa askelittaisen ohjelmistokehyksen erikoistamisen. Samalla Fred valvoo, ettei erikoistaja 1

9 riko mallin asettamia vaatimuksia seuraamalla käyttäjän tekemiä tehtäviä ja lähdekoodieditorissa tapahtuvia muutoksia. Frediä on käsitelty tarkemmin Hakalan ym. artikkeleissa [Ha01a, Ha01b]. Java Pages on Frediin tehty laajennus, jonka avulla ohjelmistokehyksen kehittäjä voi nauhoittaa mallitapauksia ohjelmistokehyksen erikoistamisesta. Java Pages käyttää hyväkseen Fredin generoimaa ohjeistusta. Fredissä suoritetuista tehtävistä ja niiden tilanteeseen mukautuvasta dokumentaatiosta saadaan luotua ohjatun toteutusesimerkin sisältävä nauhoite. Nauhoite siirretään Java Pages -palvelimelle, joka julkaisee sen verkossa. Ohjelmistokehyksen käyttöä harjoitteleva henkilö voi tämän jälkeen perehtyä nauhoitteeseen WWW-selaimen avulla. Ohjattujen toteutusesimerkkien suurin hyöty on se, että ne tarjoavat edes jonkinasteisen ratkaisun oppimiseen liittyvään paradoksiin, jonka mukaan käyttäjän täytyy päästä olemaan vuorovaikutuksessa oppiakseen, mutta voidakseen tehdä niin, hänen tulee oppia ensin [Ca90]. Käytännössä konkreettisten esimerkkien etu näkyy siinä, että ne vähentävät kantapään kautta tehtävää oppimista. Lisäksi tiedetään, että konkreettisten esimerkkien avulla oppiminen on helpompaa kuin asiaa käsittelevän tekstikirjamaisen abstraktin tekstin ymmärtäminen [Ha94, En88, LoLo91]. Ohjatussa toteutusesimerkissä kunkin ohjelman osan merkitys erikoistamisprosessissa selitetään, ja esimerkkiä täydennetään käyttäjän itsensä valitsemalla nopeudella askel kerrallaan. Toisessa luvussa käsitellään tuotelinja-arkkitehtuureita, ohjelmistokehyksiä sekä ohjelmistokehyksien dokumentointitapoja, sillä näillä on keskeinen rooli työn pohjana. Samalla luku toimii johdatuksena aiheeseen. Kolmannessa luvussa esitellään Fred eli työkalu, jonka ympärille tämän diplomityön aihe Java Pages on tehty. Fredin toimintaa ja rakennetta ei ole kuvattu kovin yksityiskohtaisella tasolla, sillä kyseessä on laaja ja monimutkainen kokonaisuus, jonka täydellinen käsitteleminen tämän työn yhteydessä ei ole mahdollista. Sen sijaan luku käsittelee muutamia olennaisimpia Fredin ideoita ja toimintaperiaatteita, joilla on merkitystä Java Pages -järjestelmän toiminnan ymmärtämiseen. 2

10 Neljännessä luvussa esitellään Java Pages sekä sen toimintaperiaatteet. Java Pages on Fred-ympäristöön integroitu työkalu, joka mahdollistaa ohjatun toteutusesimerkin nauhoittamisen Fredissä tehdystä ohjelmistokehyksen erikoistamisprosessista. Lisäksi Java Pages -työkalulla voidaan julkaista luotu nauhoite verkossa, sekä mahdollistaa nauhoitteen askelittainen läpikäyminen WWW-selaimessa. Luvussa keskitytään tehdyn ratkaisun kuvaamiseen ja teknisestä toteutuksesta käsitellään mielenkiintoisimmat yksityiskohdat. Liitteessä A on konkreettinen esimerkki Java Pages -työkalulla tehdyn nauhoitteen selaamisesta applet-käyttöliittymässä. Viidennessä luvussa käsitellään ohjelman käytöstä saatuja kokemuksia ja esille nousseita jatkokehitysajatuksia. Samalla pohditaan missä asioissa ohjelman toteutuksessa ollaan onnistuttu hyvin ja mitä voitaisiin jatkossa tehdä paremmin. Kuudennessa luvussa vedetään yhteen tämän työn tulokset. Luku esittää siis lyhyesti aiheet ja johtopäätökset, joihin tässä diplomityössä on päädytty. 3

11 2 Tausta Ohjelmistojen ymmärtämiseksi dokumentoinnilla ja koodin kommentoimisella on aina ollut tärkeä sija ohjelmoinnissa. Järjestelmien monimutkaistuessa kommentoinnin merkitys on yhä kasvanut ja tuotelinja-arkkitehtuurin tai ohjelmistokehyksen käytön oppiminen on haaste ohjelmoijalle, vaikka hyvä dokumentaatio olisi olemassakin. Tämä luku esittelee tuotelinja-arkkitehtuurit sekä ohjelmistokehykset tuotelinja-arkkitehtuurien yhtenä mahdollisena toteutustekniikkana. Lisäksi luvussa käsitellään ohjelmistokehyksien dokumentointiin liittyvää ongelmakenttää. 2.1 Tuotelinja-arkkitehtuurit Tuotelinja-arkkitehtuurien käyttö on yksi tapa nostaa ohjelmistoteollisuuden tehokkuutta ja samalla tuottaa laadukkaampia tuotteita. Tekniikan etuja ja haittoja käsitellään seuraavissa kappaleissa Peruskäsitteitä Perinteisessä teollisuudessa asiakkaaseen keskittyminen ja asiakkaan potentiaalisten tarpeiden ennakoiminen on johtanut tarpeeseen parantaa suunnittelun laatua ja siirtyä integroiduksi tuotannoksi kutsuttuun menettely- ja ajattelutapaan. Yritykset ovat asettaneet tavoitteekseen tuotevalikoimansa suurentamisen ja toimitusaikansa minimoimisen. [An00] Vastaava ajattelu on yleistynyt myös ohjelmistoteollisuudessa, jossa yritykset pyrkivät tuottavuuden lisäämiseen, projektien parempaan ennustettavuuteen, lyhennettyyn tuotantoaikaan, ohjelmistotuotannon standardisointiin, tuotteiden luotettavuuden nostamiseen, riskien pienentämiseen ja mahdollisuuteen tuottaa nopeasti prototyyppejä [Ko00]. Näiden pyrkimysten taustalla näkyy tarve tehostaa yrityksen toimintaa, mutta samalla myös tavoite parantaa ohjelmistojen laatua ja helpottaa yrityksen toiminnan ymmärtämistä. 4

12 Pidemmällä aikavälillä yrityksen tuotteet yleensä keskittyvät jollekin tietylle osa-alueelle, josta kehittyy yrityksen ydinosaamisen alue ja sitä kautta myös kilpailuvaltti markkinoilla. Samalla yritys tuottaa useita samankaltaisia tuotteita, joilla on toisiaan muistuttava rakenne ja toiminnallisuus. Näiden samankaltaisten tuotteiden joukkoa kutsutaan tuoteperheeksi (product family) ja niiden yhteistä arkkitehtuuria tuotelinja-arkkitehtuuriksi (product-line architecture). Tuotelinja-arkkitehtuuri voidaan määritellä myös joukoksi järjestelmiä, joilla on yhteinen arkkitehtuuri ja uudelleenkäytettävien komponenttien joukko [Bo00]. Tämä määritelmä korostaa uudelleenkäytön tärkeyttä tuotelinja-arkkitehtuureissa ja juuri uudelleenkäyttöasteen kasvaminen muodostaakin suuren osan tuotelinja-arkkitehtuurien eduista. Kuva 2.1 esittää tuotelinja-arkkitehtuurin idean. Tuoterunko (product platform) sisältää kaikille sovelluksille yhteiset osat. Arkkitehtuuri tarjoaa erilaisia liitoskohtia tuoterunkoon. Liitoskohtien erilaisella täydentämisellä erilaiset tuoteperheen tuotteet saavat omat erityispiirteensä. Tuoterungon lisäksi arkkitehtuuri voi tarjota rajoittamattoman suuren joukon komponentteja, jotka toteuttavat tuoterungon rajapintoja. Valitsemalla sopivan toteutuksen ohjelmistokehittäjä säästyy itse toteuttamasta tarvitsemaansa tuotteen piirrettä ja piirteen toteuttavaa komponenttia voidaan käyttää myös muissa sovelluksissa. Tuoterunko Tuoterunko Komponentit Tuotelinja Tuote Kuva 2.1. Tuotelinja ja tuote 5

13 Tuotelinja-arkkitehtuurin idea on yksinkertainen, mutta toimivalla tuotelinjaarkkitehtuurilla voidaan saavuttaa useita ohjelmistokehityksen tavoitteita. Tuotteiden yhteinen arkkitehtuuri helpottaa niiden kaikkien toiminnan ymmärtämistä, ja ohjelmoinnin tuottavuus nousee. Koska samaa ohjelmakoodia käytetään tuoterungossa ja komponenteissa uudelleen, säästetään aikaa ja vältytään virheiltä, sillä uudelleenkäytettävien komponenttien viat on jo mitä luultavimmin löydetty ja korjattu Tuotelinja-arkkitehtuurin syntytavat Tuotelinja-arkkitehtuurit voivat syntyä kahdella tavalla. Mikäli ymmärretään, että samankaltaisia tuotteita tullaan tarvitsemaan paljon, voidaan suunnittelun pohjaksi ottaa tuotelinja-arkkitehtuurinen lähestymistapa ja pyrkiä saavuttamaan sen tarjoamat edut heti suoralta kädeltä. Usein ollaan kuitenkin tilanteessa, jossa yrityksellä on valmiina lukuisa joukko samankaltaisia tuotteita, joiden ylläpitoa helpottaisi niiden yhteisten osien kerääminen samaan paikkaan ja ylläpitäminen ohjelmistoista erillisenä kokonaisuutena. Tuotelinja-arkkitehtuurin luominen joukolle tuotteita on mahdollista vain, jos tuotteiden välinen varianssi on riittävän pieni. Käytännössä ohjelmissa on tällöin riittävästi yhteisiä osia, jotka voidaan kerätä arkkitehtuurin sisään uudelleenkäytettäviksi yksiköiksi. [Ko00] Tuotelinja-arkkitehtuurin luominen puhtaalta pöydältä on hidas ja vaikea prosessi. Tässä lähestymistavassa on tärkeää tuntea tarkoin sovellusalueen tarpeet ja suorittaa sovellusalueen kartoitus (domain analysis). Sovellusalueen kartoituksessa pyritään löytämään sovellusalueen tuotteisiin liittyvät yhtenäisyydet ja eroavaisuudet. Tämän jälkeen prosessia voidaan jatkaa suunnittelemalla eroavaisuuksiin liittyvät varianssipisteet (variance point) ja niiden avulla edelleen koko arkkitehtuurinen rakenne. Mikäli tuotelinja-arkkitehtuuria luodaan olemassa olevien tuotteiden pohjalta, on kyseessä tuotelinja-arkkitehtuurin palautus (architecture recovery). Tämä perustuu olemassa olevien tuotteiden arkkitehtuuriin perehtymiseen sekä eri tuotteiden yhteneväisyyksien ja eroavaisuuksien tutkimiseen. [Ha01c] Joissain tapauksissa tuotelinja-arkkitehtuureihin siirtyminen voi johtaa yrityksen organisaatiorakenteen muutoksiin. Perinteisesti ohjelmoijat ovat rakentaneet kutakin ohjelmaa omana projektinaan, mutta tuotelinja-arkkitehtuurien myötä eri ohjelmien 6

14 yhteiset osat kerätään omaksi kokonaisuudekseen, joka on yhteinen kaikille erillisille ohjelmistoprojekteille. Tästä seuraa usein tuotelinja-arkkitehtuurin luomisesta ja ylläpitämisestä vastaavan yksikön synty erillisiä ohjelmistoprojekteja vetävien yksiköiden rinnalle. Asiakkaan vaatimukset toimivat ohjelmistoprojektien tekijöiden vaatimuksina ja näiden aiheuttamat korjaus- ja muutostarpeet arkkitehtuurissa puolestaan tuotelinjaarkkitehtuurin ylläpitäjien asiakasvaatimuksina Tuotelinja-arkkitehtuurien ongelmat Tuotelinja-arkkitehtuureihin liittyy hyvien puolien lisäksi myös joukko ongelmia. Hyvän arkkitehtuurin suunnitteleminen vaatii aikaa, eikä yleensä onnistu kerralla. Usein kyseessä on iteratiivinen prosessi, jossa arkkitehtuuri paranee pienin askelin. Koska kaikki tuotteet kuitenkin rakennetaan arkkitehtuurin ympärille, voi arkkitehtuurin muuttaminen olla työlästä, sillä kaikki siihen nojaavat tuotteet täytyy korjata, jos niiden käyttämiin rajapintoihin tulee muutoksia. Lisäksi on aina olemassa riski, ettei arkkitehtuurin suunnitteleminen onnistu ja kaikki siihen uhratut resurssit ovat menneet hukkaan. Tuotelinja-arkkitehtuuriin liittyy lisäksi sama ongelma kuin kaikkeen abstrahointiin: ohjelmien tehokkuus laskee. Tämän ongelman suuruutta voi pienentää huolellisella suunnittelulla, mutta kokonaan sitä on mahdotonta välttää. Jo dynaamisen sidonnan kautta tehtävä funktiokutsu on normaalia funktiokutsua kalliimpi, ja abstraktioasteen kasvaessa erilaisten rajapintojen, dynaamisen sidonnan ja perinnän merkitys kasvaa [RiJo00]. Samalla erilaisiin muutostarpeisiin varautuminen aiheuttaa yhden sovelluksen kannalta turhaa tehokkuushävikkiä. Oman lisänsä ongelmiin tuovat tulevaisuuden muutospaineet. Ajan kuluessa tuotteisiin halutaan yhä uusia ja uusia toimintoja, jotka pitäisi pystyä toteuttamaan mahdollisimman helposti. Kun useisiin tuotteisiin aletaan tarvita samanlaisia toimintoja, ne siirtyvät tuotelinja-arkkitehtuurilta kaivattujen toimintojen joukkoon. Näin syntyy muutoksia arkkitehtuurin ytimeen asti. Muutoksien toteuttaminen voi olla vaikeaa, sillä yksi muutos saattaa vaatia korjauksia useaan komponenttiin ja näin olleen muodostaa riippuvuuksia uudelleenkäytettävien komponenttien välille. Lisäksi muutos voi olla ristiriitainen jonkin 7

15 muun vaatimuksen kanssa. Usein komponenteista alkaa ajan myötä syntyä useita versiota, joka tietenkin kasvattaa ylläpidon työmäärää. Toiminnallisten vaatimusten lisäksi joihinkin tuotteisiin voi liittyä myös laadullisia vaatimuksia. Uusi tuote saattaa esimerkiksi tulla ympäristöön, jossa ohjelmakoodin määrän minimoinen on olennaisen tärkeää tai ohjelmakoodin tehokkuus on maksimoitava. Tämänkaltaisiin vaatimuksiin reagoiminen on kaikkein vaikeinta, sillä tuotelinjaarkkitehtuurin suunnittelussa joustavuuden (flexibility) maksimointi on jo valittu tärkeäksi suunnittelupäämääräksi ja se saattaa olla ristiriidassa uusien laadullisten ominaisuuksien kanssa. Ajan kuluessa riittävän suuret muutospaineet saattavat johtaa tuotelinjaarkkitehtuurin uudistamiseen tai toisen tuotelinja-arkkitehtuurin kehittämiseen, sillä arkkitehtuuria on korjattava tai on kehitettävä uusi, jos se ei enää sovellu tuoteperheen muuttuneisiin vaatimuksiin [Ku99]. Tuotelinja-arkkitehtuurin testaamiseen liittyy tiettyjä erityisongelmia, sillä tuoterunko yksin ei ole kokonainen ajettava ohjelma. Se tarjoaa ytimen, josta yksittäinen ajettava sovellus voidaan erikoistaa. Testattaessa täytyy luoda tuoterunkoa käyttäviä testisovelluksia, mutta kaikkien syötearvojen kombinaatioiden testaaminen ei ole mahdollista. Näin ollen testaus keskittyy erilaisiin rajatapauksiin, jotka kattavat mahdollisimman suuren osan tuoterungon ja komponenttien toiminnallisuudesta. Työ voidaan jakaa kolmeen osaan, jotka ovat tarpeellisten testitapausten määritys, testiympäristön rakentaminen sekä testaaminen ja tulosten analysointi. Tuoterunko ja komponentit voivat sisältää erityisiä testaamista helpottavia rajapintoja. [No01] Sen lisäksi, että hyvää tuotelinja-arkkitehtuuria on vaikeaa suunnitella, myös sen käyttäminen on aluksi vaikeampaa kuin normaalin ohjelmakoodin kirjoittaminen. Tuotelinja-arkkitehtuurit tarjoavat useita palveluja valmiina komponentteina, mutta niitä on ensin opittava käyttämään ja kokonaisarkkitehtuuri on omaksuttava. Vaikka tuotelinjaarkkitehtuurista olisi kirjoitettu täydellinen dokumentaatio, joka harvoin on tilanne tosielämässä, on uuden laajan järjestelmän omaksuminen aikaa vievä tapahtuma. Näin ollen oppimiskynnys on korkea ja uuden työntekijän tuottavuus nousee vasta hänen sisäistettyään järjestelmän arkkitehtuurin. 8

16 2.1.4 Tuotelinja-arkkitehtuurien toteutustavat Tuotelinja-arkkitehtuurilla on useita toteutustapoja, joista tärkeässä asemassa ovat kerrosarkkitehtuurit, komponentit ja ohjelmistokehykset [Ko00]. Ohjelmistokehyksiä tarkastellaan tarkemmin kohdassa 2.2, kerrosarkkitehtuurit ja komponentit jäävät tämän työn aihepiirin ulkopuolelle. Olemassa olevista teknologioista ja malleista tuotelinja-arkkitehtuureihin liittyvät mm. kerrosarkkitehtuurit ja muut tunnetut arkkitehtuurit, komponentti-integraattorit, erilaiset oliotekniikat, sovelluskohtaiset kielet, ohjelmistokehittimet, suunnittelumallit, ohjelmistokehykset, generatiivinen ohjelmointi ja komponenttiteknologiat kuten DCOM, (Enterprise) Java Beans ja CORBA. [Ko01] 2.2 Ohjelmistokehykset Ohjelmistokehykset ovat yksi tuotelinja-arkkitehtuurien toteutustavoista. Ohjelmoijat tuntevat ne kuitenkin paremmin esimerkiksi Smalltalkin MVC-arkkitehtuurin [Go84 KrPo88, LaPu91] muodossa, ja useat ohjelmoijat käyttävät ohjelmistokehyksiä työssään tunnistamatta niitä millään erityisellä termillä. Tässä kohdassa määritellään mikä ohjelmistokehys on ja käsitellään mitä etuja ja haittoja niiden käyttöön liittyy Peruskäsitteitä Ohjelmistokehyksellä (framework) tarkoitetaan sellaisten toisiinsa liittyvien luokkien kokoelmaa, jotka muodostavat yhdessä ohjelmiston rungon, ja josta voidaan luoda ajettavia sovelluksia tai komponentteja täyttämällä kehykseen jätetyt aukot erikoistamiskohtaisella ohjelmakoodilla. Tuotelinja-arkkitehtuurien yhteydessä ohjelmistokehys voidaan myös määritellä tavalla, joka korostaa sen merkitystä tuotelinja-arkkitehtuurin toteutustekniikkana. Tämän määritelmän mukaan ohjelmistokehyksellä tarkoitetaan olio-ohjelmoinnin yhteydessä kiinteästi toisiinsa liittyvien luokkien ja/tai rajapintojen kokoelmaa, joka toteuttaa tietyn ohjelmistoperheen perusarkkitehtuurin [Ko00]. 9

17 Ohjelmistokehystä kuvataan usein kuvan 2.2 mukaisena rakenteena. Ohjelmistokehyksen runko koostuu toisiinsa tiukasti sidoksista olevista luokista, mutta kehys ei ole kuitenkaan täydellinen ilman erikoistavaa osaa. Erikoistamista varten kehys tarjoaa erikoistamisrajapinnan, jonka avulla sovelluskohtainen erikoistava osa saadaan liitettyä kehykseen. Erikoistamisrajapinta on usein monimutkainen kokonaisuus, joka edellyttää useiden, mahdollisesti toisiinsa liittyvien, luokkien toteuttamista ja liittämistä ohjelmistokehykseen. Erikoistamiskohdalla (hotspot) tarkoitetaan yhtä erikoistajan täydennettäväksi jätettyä kohtaa ohjelmistokehyksessä [Pr95a]. Erikoistamiskohta voidaan nähdä kehyksen sisältämänä kaavainmetodina (template method), joka toteuttaa esimerkiksi algoritmin rungon jättäen joitakin toteutuksen yksityiskohtia aliluokan erikoistettavaksi. Kukin asia, jonka aliluokka voi erikoistaa toteutetaan omana metodinaan. Jos yliluokka vain esittelee metodin, joka tulee erikoistaa, kyseessä on abstrakti yliluokka, jonka abstraktit metodit on pakko toteuttaa konkreettisessa aliluokassa. Jos yliluokka sen sijaan tarjoaa oletustoteutuksen erikoistamiseen käytettäville metodeille, jotka aliluokka voi ylimääritellä, kutsutaan metodeja koukkumetodeiksi (hook method). [Pr95a] Kuvaan 2.2 on merkitty kontrollin kulku ohjelmistokehyksen ja kehystä erikoistavan ohjelmakoodin välillä nuolia käyttäen. Perinteisesti ohjelmoijille on tarjottu luokkakirjastoja, joita on kutsuttu sovelluksen koodista. Luokkakirjastojen avulla usein tarvittavia metodeja ja toimintoja on voitu käyttää uudelleen ja samalla ohjelmointi on helpottunut, kun kaikki usein tarvittavat ratkaisut on kerätty helppokäyttöiseksi ja hyvin dokumentoiduksi kokonaisuudeksi. Ohjelmistokehykset pyrkivät luokkien ja rutiininen uudelleenkäytön lisäksi myös arkkitehtuurin uudelleenkäyttöön [Pr95b]. Niille on tyypillistä kontrollin kaksisuuntainen kulku ohjelmistokehyksen ja erikoistavan osan välillä. Ohjelmistokehyksen erikoistaminen saattaa esimerkiksi vaatia tietyn rajapinnan toteuttamisen, jolloin ohjelmistokehyksen koodi kutsuu erikoistajan tekemää toteutusta tuntemansa rajapinnan läpi. Tätä ohjelmistokehyksille tyypillistä takaisinkutsumenetelmää kutsutaan Hollywood-periaatteeksi (don t call us, we ll call you). 10

18 Ohjelmistokehys Erikoistava osa Kuva 2.2. Ohjelmistokehyksen erikoistaminen Erikoistaminen voidaan käytännössä toteuttaa perinnän, koostamisen, rajapintojen, geneeristen rakenteiden instantioinnin ja reflektion avulla [Ko01]. Käytännössä ohjelmistokehyksen erikoistaminen perustuu harvoin vain yhteen näistä tavoista ja joskus käytettyä erikoistamistapaa voi olla vaikea nimetä. Usein erikoistamisrajapinnasta on tunnistettavissa suunnittelumalleja (design pattern), joiden yhden osan erikoistaja toteuttaa omalla luokallaan. Suunnittelumalleja käsitellään tarkemmin esimerkiksi Gamman ym. kirjassa [Ga01]. Lyhyesti selitettynä suunnittelumalli kuvaa yleistä ratkaisua toistuvasti esiintyvään suunnitteluongelmaan. Perinnän avulla suoritettavassa erikoistamisessa ohjelmistokehys sisältää yliluokkia ja abstrakteja luokkia, joiden metodeja ylimääritellään erikoistajan toteuttamissa aliluokissa halutun sovelluskohtaisen toiminnallisuuden aikaansaamiseksi. Tällä tavalla erikoistettavaa ohjelmistokehystä kutsutaan muunneltavaksi kehykseksi (white-box framework). Koostamisen avulla erikoistettava ohjelmistokehys perustuu siihen, että kehyksen luokista luodaan ilmentymiä sopivilla alustusparametreilla ja niistä kootaan halutunlainen oliokokoelma. Koostamiseen perustuvaa ohjelmistokehystä kutsutaan nimellä koottava kehys (black-box framework). Rajapintojen avulla erikoistettava kehys määrittelee joukon rajapintoja, jotka erikoistajan tulee toteuttaa konkreettisissa luokissa. Tämän tyyppinen kehys on usein erittäin joustava, 11

19 mutta sen erikoistamisessa on paljon työtä. Rajapintojen toteuttajan täytyy aloittaa työnsä puhtaalta pöydältä, eikä hän voi esimerkiksi valita ylikirjoittaako metodin oletustoteutuksen. Geneeristen rakenteiden avulla tapahtuva erikoistaminen voi perustua esimerkiksi kaavainmekanismeihin (template). Niiden avulla voidaan suunnitella ohjelmistokehys, joka käsittelee tietyn kaavaimen mukaisia tietorakenteita ja tarkka tyyppi jää erikoistajan valittavaksi. Reflektiota hyödynnettäessä käytetään ohjelman kykyä tutkia omaa rakennettaan. Sen avulla voidaan aikaansaada esimerkiksi ylimääräisiä luokkien nimiin perustuvia valintakonventioita tai muuta lisäinformaatiota, jonka perusteella ohjelmistokehys voi valita suoritettavia erikoistamisosia. Myös metodien kutsuminen tuntemattoman rajapinnan läpi on mahdollista, mutta vaatii tarkasti määritellyn ja noudatetun nimikonvention toimiakseen. Kerroksittaiset ohjelmistokehykset pyrkivät yhdistämään eri erikoistamistapojen hyviä puolia. Kerroksittainen ohjelmistokehys on nimensä mukaisesti monikerroksinen rakenne, jossa kehyksen ylin taso voi olla esimerkiksi rajapintojen toteutukseen perustuva erittäin joustava ohjelmistokehys, jota on työläs laajentaa. Sen alapuolelle voidaan erikoistaa ohjelmistokehys, joka konkretisoi tiettyjä osia ylimmän tason kehyksestä, mutta jättää yhä suurimman osan toteutuksesta erikoistajalle. Tämän alapuolelle voidaan tehdä haluttu määrä uusia, yhä enemmin erikoistettuja kehyksen versiota. Rakennetta voidaan myös haaroittaa tekemällä erilaisia erikoistamisratkaisuja ja näin saavuttaa puumainen rakenne, josta erikoistaja voi valita käyttötarkoitukseensa sopivan kehyksen version. Erilaisten erikoistamistapojen lisäksi ohjelmistokehykset voidaan jakaa sovelluskehyksiin (application framework) ja kehyskomponentteihin (framework component, framelet). Sovelluskehyksellä tarkoitetaan ohjelmistokehystä, jonka erikoistamisen tuloksena syntyy ajettava ohjelma. Kehyskomponentilla tarkoitetaan puolestaan ohjelmistokehystä, jonka erikoistamisen tuloksena syntyy komponentti eli itsenäinen ohjelmayksikkö, jolla on julkinen palvelurajapinta sen käyttöä varten. Kehyskomponenttia voidaan käyttää osana 12

20 sovellusta, jossa on kehyskomponentin palvelurajapinnan kanssa yhteen toimiva osa tai se voidaan liittää edelleen johonkin komponenttikehykseen (component framework). Komponenttikehyksellä tarkoitetaan kehystä, joka sisältää komponenttien tarvitseman yleisen tai sovelluskohtaisen tuen ja jota erikoistetaan liittämällä siihen komponentteja Ohjelmistokehyksien syntytavat ja evoluutio Ohjelmistokehyksien käyttö on viime vuosina yleistynyt niiden tarjoamien hyötyjen vuoksi. Ohjelmakoodin uudelleenkäyttöasteen nostaminen on usein suurin syy ohjelmistokehyksien käyttöön siirtymiseen, sillä joidenkin tutkimuksien mukaan jopa 60-80% sovelluksen ohjelmakoodista voidaan saada ohjelmistokehyksestä [Ko00]. Myös ohjelmistojen laadun paraneminen, toimitusajan lyheneminen, tuotteiden ja tuotantoprosessien yhdenmukaistuminen sekä mahdollisuus tuottaa nopeasti prototyyppejä ovat lisänneet kiinnostusta ohjelmistokehyksien käyttöön. Samalla tuotelinjaarkkitehtuurit ovat yleistyneet ja sovelluskehyksien käyttö niiden toteutustapana on nostanut ohjelmistokehysten kiinnostavuutta entisestään. Ohjelmistokehysten syntytapoja tuotelinja-arkkitehtuurien yhteydessä on käsitelty kohdassa Ohjelmistokehysmäiseen ratkaisuun voidaan päätyä suoraan hyvän suunnittelun tuloksena, mutta se on harvinaista. Usein ohjelmistokehyksen kehittäminen on aikaa vievä iteratiivinen prosessi, jossa siirrytään askelittain kohti toimivaa ja riittävän geneeristä ratkaisua. Tällä hetkellä ei tunneta mitään systemaattista menetelmää, jolla voitaisiin taata onnistuneen ohjelmistokehyksen aikaansaaminen. Teollisuudessa ohjelmistokehyksiä on käytetty vaihtelevalla menestyksellä, mutta kokemukset ovat olleet pääosin positiivisia. Ohjelmistokehyksiä on sovellettu esimerkiksi piirtotyökalujen kuten JhotDraw [JHotDraw], reititysalgoritmien [Go90], hypermediaan liittyvien järjestelmien [Me86], käyttöjärjestelmien [Ru91] ja tuotannonohjauksen [Sc95] yhteydessä. Ohjelmistokehyksen tekeminen on aikaa vievä ja epävarma prosessi. Tämän takia ohjelmistokehyksen toteutus ei saa kuulua ohjelmistotuotteen kehityksen kriittiselle polulle, sillä muuten ohjelmistokehyksen kehitysprosessi voisi aiheuttaa viivästymistä koko projektin etenemiselle. Hyvän sovelluskehyksen luominen vaatii lisäksi hyvää 13

21 tuntemusta kyseessä olevasta sovellusalueesta ja olio-ohjelmoinnista sekä koko projektin sitoutumista sovelluskehyksen kehitysprosessiin. Suurten kehittämiskustannusten vuoksi sovelluskehykset muuttuvat yleensä kannattaviksi vasta, kun niitä on päästy hyödyntämään useissa sovelluksissa. Joissakin lähteissä mainitaan, että ohjelmistokehys muuttuu tyypillisesti kannattavaksi, kun siitä on erikoistettu 3-6 sovellusta. Sääntö ei kuitenkaan päde kaikille kehyksille, vaan pyrkii lähinnä antamaan suuntaviivoja siitä, millainen kannattavuuskynnyksen arvo voisi esimerkiksi olla. Mikäli ylläpidon helpottuminen nähdään tärkeänä tekijänä, voi kannattavuuskynnys olla pienempikin. Ohjelmistokehyksiin liittyy myös evoluutiota iteratiivisen kehittämisprosessin jälkeen. Sovelluksiin tulee lisäyksiä, uudet erikoistettavat sovellukset asettavat uusia vaatimuksia ohjelmistokehyksille, virheitä korjataan ja vanhoja ratkaisuja parannellaan. Samalla alkuvaiheessa yleensä perintään perustunut muunneltava ohjelmistokehys muuttuu kohti koostamiseen perustuvaa koottavaa ohjelmistokehystä [JoFo88]. Tähän muutosprosessiin liittyy myös ongelmia, sillä usein ohjelmistokehys samalla laajenee ja kasvaa kohti monoliittista rakennelmaa, jonka ylläpito vaikeutuu. Ohjelmistokehyksiin kohdistuu muutospaineita myös ohjelman ulkoisen toimintaympäristön muuttuessa. Ympäristön muutokset voidaan nähdä muutoksina ohjelmistokehyksen asiakasvaatimuksiin, ja ne voivat vaatia suuria muutoksia ohjelmistokehykseen. Mikäli muutokset ovat riittävän suuria, voi kyseeseen tulla myös kokonaan uuden, uusiin ympäristön vaatimuksiin vastaavan, ohjelmistokehyksen kehittäminen Ohjelmistokehyksien ongelmat Ohjelmistokehyksiin liittyy samoja ongelmia kuin tuotelinja-arkkitehtuureihin. Ohjelman suoritustehokkuuden laskemista, korkeata oppimiskynnystä, laadullisia vaatimuksia, tulevaisuuden tarpeiden huomiointia ja testauksen vaikeutumista on käsitelty tuotelinjaarkkitehtuurien yhteydessä alikohdassa Muita ohjelmistokehyksiin liittyviä 14

22 ongelmia ovat kasvu monoliittiseksi rakenteeksi, useampien kehyksien yhdistäminen, kehitysympäristöjen vaillinainen tuki sovelluskehyksien käyttämiselle ja dokumentointi. Ohjelmistokehyksen evoluution vaikutuksena kehys pyrkii hitaasti paisumaan yhä suuremmaksi, koska kehystä laajennetaan tarjoamaan helppo toteutus yhä suuremmalle joukolle palveluja. Samalla ohjelmistokehyksen modulaarisuus yleensä rappeutuu ja siitä muodostuu suuri ja vaikeasti ymmärrettävä luokkakokoelma. Tämän kehityksen seurauksena syntynyttä kompleksista rakennetta kutsutaan monoliitiksi. Monoliittisiä rakenteita voidaan välttää esimerkiksi kehyskomponenttien käytöllä. Tällöin yhden kehyskomponentin erikoistaminen tuottaa pienemmän ja helpommin hallittavan komponentin ja sovellus voidaan rakentaa yhdistämällä komponentit. Näin ohjelmoijan tarvitsee tuntea vain yhden kehyskomponentin rajapinta kerrallaan ja kokonaisuuden ymmärtäminen on helpompaa. Useiden ohjelmistokehyksien käyttäminen yhdessä on yleensä vaikeaa. Kehyksen erikoistava osa on suunniteltava tarkasti sellaiseksi, että se täydentää ohjelmistokehyksen täsmälleen halutulla tavalla toimivaksi kokonaisuudeksi. Jos samalla yritetään erikoistaa useampaa ohjelmistokehystä, voi kokonaisuuden hahmottaminen olla vaikeaa, ja eri kehysten asettamat vaatimukset erikoistavalle ohjelmakoodille voivat olla ristiriitaisia. Sparks ym. [Sp96] ovat tarkastelleet ongelmia, jotka liittyvät useiden sovelluskehyksien käyttämiseen samassa sovelluksessa. Nykyiset ohjelmistojen kehitysympäristöt eivät tarjoa tukea sovelluskehyksien käytölle. Sovelluskehystä ei voida merkitä eksplisiittisesti näkyviin työvälineessä, eikä erikoistamiseen liittyviä toisiinsa sidoksissa olevia tehtäviä voida suorittaa ohjatusti. Luvussa 3 esitellään Fred, joka on prototyyppi kehitysympäristöstä, joka tukee ohjelmistokehyksien askelittaista erikoistamista mallien avulla. Viimeinen, mutta ei suinkaan vähäisin ohjelmistokehyksiin liittyvä ongelma on niiden dokumentoinnin tekeminen siten, että kehyksen ymmärtäminen ja erikoistaminen olisi helppoa. Dokumentaatio on tärkeää, sillä ohjelmistokehyksien erikoistamisrajapinta asettaa suuren joukon vaatimuksia erikoistavalle ohjelmakoodille, eikä kaikkia näitä 15

23 vaatimuksia voida nähdä suoraan erikoistamisrajapinnasta. Esimerkiksi yksi erikoistamisrajapinnan vaatimus voi säteillä ohjelmakoodissa monien luokkien ja metodien toteutukseen. Ohjelmistokehyksien dokumentointia ja siihen liittyvää ongelmakenttää käsitellään tarkemmin kohdassa Ohjelmistokehysten dokumentointi Ohjelmien ymmärtämiseksi niiden riittävä dokumentointi on ollut välttämätöntä kautta aikojen. Matalan tason kielien, kuten Assemblerin, tapauksessa itse ohjelmakoodin ymmärtäminen ilman selkeää ja riittävää kommentointia voi olla jälkikäteen lähes mahdotonta. Korkeamman tason ohjelmointikielien tapauksessa ohjelmakoodi on huomattavasti luettavampaa, joten kommentoimisen merkitys vähenee. Siirryttäessä matalamman tason ohjelmointikielistä korkeamman tason ohjelmointikieliin toteutettavien järjestelmien koko kuitenkin kasvaa ja tämä aiheuttaa uudenlaisen dokumentoinnin tarpeen. Ohjelmakoodin ymmärtämisen lisäksi dokumentoinnin olisi kyettävä kuvaamaan ohjelman arkkitehtuuriset perusratkaisut ja ohjelman eri osien väliset riippuvuudet. Tämä kohta käsittelee erityisesti ohjelmistokehyksien dokumentointiin liittyvää ongelmakenttää Dokumentoinnin vaatimukset Dokumentointiin liittyy useita suosituksia ja vaatimuksia, jotka voivat joissain tilanteissa olla keskenään ristiriitaisia. Tässä alikohdassa käsitellyt vaatimukset perustuvat Østerbyen ym. esittämään jakoon [Øs00]. Ohjelman dokumentoiminen on tasapainoilua kahden näkökulman välillä. Dokumentaation tulee olla riittävän laaja, jotta se kuvaa kaiken tarpeellisen ohjelmasta. Toisaalta sen tulee olla mahdollisimman pieni, sillä ylimääräinen dokumentaation tuottamiseen käytettävä aika olisi voitu käyttää itse ohjelman kehittämiseen. Myös dokumentaation käyttäjän kannalta riittävä, mutta minimaalinen dokumentaatio on paras vaihtoehto [Øs99]. Dokumentaation kirjoittajalle sen kirjoittamisen tulee olla luonnollinen osa ohjelmiston kehitysprosessia. Dokumentoinnin tulee tapahtua osana ohjelmiston tuotantoprosessia 16

24 samassa yhteydessä, kun asiaan liittyvä suunnittelu tai ohjelmakoodin toteutus tehdään. Vastaavasti dokumentin ylläpitämisen tulee tapahtua samassa yhteydessä, jossa suunnitteluun tai ohjelmakoodiin tehdään tarvittavat muutokset. [Øs00] Dokumentaation helppo saatavuus on monesti lukijoille tärkeää, sillä ohjelmistokehitys tapahtuu nykyään hajautettuna prosessina. Maantieteellisesti eri paikoissa työskentelevien ohjelmoijien tulee päästä käyttämään samaa ajantasaista versiota ohjelman dokumentaatiosta. Dokumentaation tulee kuvata ohjelman rakenne ja toiminnallisuus, sillä niiden ymmärtäminen on välttämätöntä ohjelman rakenteen oppimiseksi ja perusedellytys ohjelmaan tulevien muutoksien suunnittelemiselle. Tämän lisäksi dokumentaation tulee kuvata ohjelmiston suunnittelussa tehdyt tärkeimmät abstraktiot ja yleiset suunnitteluperiaatteet, joiden ymmärtäminen on edellytys ohjelman tarkemman suunnittelun ja toiminnan ymmärtämiselle, sekä järjestelmän jatkokehitykselle. Kirjoitusprosessissa dokumentteihin syntyy helposti toistuvuutta, jonka minimoiminen on tärkeä näkökulma dokumentaation tekemisessä. Toistuvuus vaikeuttaa ylläpitämistä ja muutoksia tehtäessä jokin samaa asiaa toistavista kohdista jää helposti korjaamatta, jolloin dokumentaatioon syntyy ristiriitaisuuksia. Tämän takia asiat tulee kertoa dokumentaatiossa vain yhteen kertaan. Lisäksi asioiden esittämisjärjestyksellä on olennainen merkitys dokumentaatioin helpolle luettavuudelle. Käytännössä verkossa olevissa dokumenteissa tekstin linkittäminen ratkaisee useita asiaan liittyviä ongelmia. Linkkien avulla kukin asia voidaan kertoa yhteen kertaan ja viitata asian selitykseen kohdissa, joissa aihetta sivutaan. Tällä tavalla lukija voi tarvittaessa lukea aiheesta enemmän, tai ohittaa linkin mikäli aihe on ennestään tuttu. Ohjelmistoprosessissa halutaan usein todentaa, että ohjelmoijat tekevät oikeita asioita. Lisäksi on tarpeen tietää, miksi ohjelmaan on toteutettu jokin tietty osa. Tämän vuoksi dokumentaation tulee tukea sekä eteenpäin että taaksepäin jäljitettävyyttä (forward and backward traceability). Eteenpäin jäljitettävyydellä tarkoitetaan sitä, että kustakin ohjelmiston toiminnallisen vaatimuksen kuvauksesta alkaa katkeamaton ketju 17

25 vaatimuksen toteuttavaan ohjelmakoodiin. Tätä ketjua seuraamalla voidaan siis nähdä, miten tietty asiakkaan vaatimus on huomioitu ohjelmistoprosessin eri vaiheissa kuten suunnittelussa ja kuinka se on lopulta toteutettu ohjelmakoodissa. Taaksepäin jäljitettävyydellä tarkoitetaan vastaavasti sitä, että ohjelman toteutuksesta voidaan löytää katkeamaton ketju eri ohjelmistoprosessin vaiheiden läpi takaisin vaatimuksiin, joiden vuoksi kyseinen ohjelman osa on olemassa. Lukemisen helpottamiseksi dokumentaatio tulee jakaa osiin, jotka kuvaavat eri näkökulmia ohjelmaan. Näkökulmia voivat olla esimerkiksi staattinen arkkitehtuuri, dynaaminen käyttäytyminen ja asiaan liittyvä muu dokumentaatio. Näin käyttäjien on helpompi löytää etsimänsä tieto dokumentaatiosta, ja erilaiset asiat tulevat jaetuksi loogisesti omiin kokonaisuuksiinsa. Ohjelmiston toiminnan ymmärtämiseksi dokumentaation tulee kuvata myös ympäristö, johon ohjelma liittyy. Ympäristön lyhyen kuvaamisen lisäksi ohjelmiston ja ympäristön välisestä rajapinnasta tulee kuvata ohjelmiston saamat syötteet (input) ja sen tuottamat tulosteet (output), jotta saadaan määritettyä tarkalleen mitä järjestelmä tekee ja mitä se ei tee. Lisäksi dokumentaation tulee määritellä kuinka järjestelmä reagoi ympäristön generoimiin tapahtumiin (event), sekä sisältää viitteitä dokumentteihin, jotka kuvaavat tällaisen tapahtuman aiheutumisen tarkemmin Perinteiset dokumentointitavat ja ohjelmistokehysten dokumentoinnin erityisongelmat Ohjelmiston suunnitteluvaiheessa kuvataan ohjelman rakenne. Rakenteen kuvaamisessa käytettäviä menetelmiä on suuri joukko. Jo niiden lukumäärästä voi päätellä, että kyseessä on tärkeä aihe ohjelmistotekniikassa. Viime vuosien aikana UML (Unified Modelling Language) on syrjäyttänyt tehokkaasti vanhempia kuvausmuotoja. UML:n notaation laajuudesta ja kuvaustavan uutuudesta huolimatta edes se ei tue ohjelmistokehysten dokumentointia riittävällä tarkkuudella. UML sisältää standardistereotyypin <<framework>>, jolla voidaan täsmentää esimerkiksi pakkaus (package). Tällainen pakkaus sisältää siis ohjelmistokehyksen. Ongelma on, että UML ei tue 18

26 ohjelmistokehyksien välisten luokkien yhteistoiminnan kuvaamista, joka olisi välttämätöntä uudelleenkäytön mahdollistamiseksi [Ga95]. Vastaava riittämättömyyden ongelma on nähtävissä myös ohjelmistokehyksien lähdekoodin dokumentoinnissa. Perinteisesti ohjelmia on aina kommentoitu, jotta niiden ymmärtäminen olisi helpompaa. Alussa kommenteille ei ollut muuta tarkkaa muotoa, kuin ohjelmointikielen syntaksin asettama aloitusmerkki sekä mahdollisesti vastaava lopetusmerkki, joskin erilliset kommentoinnin tyylisäännöt yhdenmukaistivat samassa projektissa tai yrityksessä käytettävää kommentointitapaa nopeasti. Myöhemmin erilaiset työkalut, kuten JavaDoc [JavaDoc], ovat määritelleet tarkemmin kommentoinnissa käytettävän tyylin sekä mahdollistaneet kommenttien automaattisen erottamisen ohjelmakoodin joukosta. Näin generoitu dokumentaatio muunnetaan samalla automaattisesti helpommin luettavaan muotoon, kuten html-dokumentiksi. Ohjelmistokehyksien tapauksessa pelkkä rajapintojen tai metodien sisäisen toteutuksen kommentoiminen ei kuitenkaan riitä selittämään ohjelmoijille ohjelmistokehyksen erikoistamisrajapintojen käyttöä tai tiettyjen metodien välillä olevia riippuvuuksia. Joissain tapauksissa suunnittelumalleista on ollut apua ohjelmistokehyksien dokumentoinnissa [Jo92]. Suunnittelumalli tarkoittaa yleistä ratkaisua toistuvasti esiintyvään suunnitteluongelmaan [Ga01]. Suunnittelumalli eivät siis sisällä konkreettista toteutusta, toisin kuin ohjelmistokehykset [HaMä98]. Ohjelmistokehyksen toteuttaja voi käyttää suunnittelumalleja ohjelmistokehyksen rajapinnassa siten, että jokin suunnittelumallin osa jää erikoistajan toteutettavaksi. Tunnettuun suunnittelumalliin viittaaminen auttaa selvittämään erikoistajalle kokonaisuutta, jonka kanssa hän työskentelee. Suunnittelumallit eivät kuitenkaan ole riittävä tapa ohjelmistokehyksien rajapinnan dokumentointiin. Erikoistamisrajapinnan täydentäminen edellyttää yleensä myös muiden kuin suunnittelumallin osina toimivien luokkien kirjoittamista. Lisäksi suunnittelumallit ovat suunnittelutason käsitteitä, joten ne eivät itsessään dokumentoi suunnittelumallin tarkkaa toteutustapaa. Voidaankin todeta, että ohjelmistokehykset vaativat laajempaa dokumentaatiota kuin mitä luokkakaavioilla, muilla UML:n tukemilla piirteillä, 19

27 ohjelmakoodin joukkoon kirjoitetuilla kommenteilla ja suunnittelumalleilla voidaan saada aikaan. Ralph Johnson esittää, että ohjelmistokehyksestä tulee dokumentoida tarkoitus, käyttö ja arkkitehtuuri. Lisäksi tehtävää dokumentaatiota tulee havainnollistaa esimerkein [Jo92]. Alikohdassa käsitellään eräs ohjelmistokehyksien yhteydessä käytettävien dokumentaatiotapojen jako Ohjelmistokehysten dokumenttityypit Ohjelmistokehyksestä kirjoitettu dokumentaatio voidaan jakaa erilaisiin osiin, joista jokaisella on oma käyttäjäkuntansa. Tarve tällaiseen jakoon syntyy siitä tosiasiasta, että dokumentaation käyttäjät poikkeavat toisistaan niin taidoiltaan kuin kokemukseltaankin. Järjestelmään ensi kertaa tutustuva henkilö tarvitsee tarkasti ohjaavan selityksen kaikelle näkemälleen, kun taas järjestelmän kanssa jatkuvasti toimivat henkilöt kaipaavat täydellistä, mutta kompaktia koostetta siitä, miten järjestelmän yksittäiset osat toimivat. Dokumentaatio voidaan luokitella tutoriaalidokumentaatioon (tutorial documentation), koostavaan dokumentaatioon (reference documentation) ja perustelevaan dokumentaatioon (rationale documentation). Koostava dokumentaatio voidaan jakaa edelleen arkkitehtuuriseen dokumentaatioon ja aihekohtaiseen koostavaan dokumentaatioon. [Øs00] Tutoriaalidokumentaatio Tutoriaalidokumentaatio on tarkoitettu aloittelijoille. Se pyrkii luomaan hyvän yleiskuvan järjestelmästä ja kuvaa siihen liittyvät tärkeimmät osat. Kyseessä on siis järjestelmän karkealla tasolla kuvaava dokumentti, joka ei pyri järjestelmän yksityiskohtien täydelliseen kuvaamiseen. Tutoriaalidokumentaatio voidaan kirjoittaa eri muotoihin. Keittokirjamainen (cookbook) tutoriaali kertoo kuinka tietyt tyypilliset ongelmat ratkaistaan. Se toimii siis tietynlaisena hakuteoksena yleisimmin kohdattavien ongelmien ratkaisuihin, mutta pyrkii valitsemaan ongelmat siten, että perehtymällä niiden 20

28 ratkaisutapoihin käyttäjä saa samalla hyvän kuvan koko järjestelmän toiminnasta. Esimerkiksi Smalltalk-80:n MVC-arkkitehtuuri on kuvattu keittokirjamaisesti [KrPo88]. Tekstikirjamainen (textbook) tutoriaali on tarkka esitys ohjelman jostakin tietystä osasta tai koko ohjelmasta. Tämä dokumentointitapa on lähinnä perinteistä dokumentointia. Ohjelmistokehyksien alkuajoilta tunnettu DEMOS-niminen ohjelmistokehys on dokumentoitu tällä tavalla [Bi79]. Konkreettisista esimerkeistä koostuva tutoriaali koostuu joukosta lyhyitä ja helppotajuisia esimerkkejä. Kukin esimerkki pyrkii kuvaamaan tietyn osan ohjelmasta, mutta esimerkit eivät ole niin laajoja, että ne kuvaisivat kokonaisen ohjelman erikoistamisen. Tutkimalla esimerkkejä lukijalle syntyy kuva siitä, miten eri asiat tulisi tehdä sovelluskehystä käytettäessä. Ohjattu toteutusesimerkki (guided construction tour) on yleensä interaktiivisena demona toteutettu ohjeistus, joka kuvaa ensin esimerkkiin liittyvät vaatimukset ja tämän jälkeen käyttäjä voi selata toteutusesimerkkiä askelittain eteenpäin. Ohjattujen esimerkkien avulla saadaan kuvattua sekä tuotteen kehitys, että siihen liittyvän prosessin eri vaiheet. Luvussa 4 kuvattu Java Pages -järjestelmä on esimerkki työkalusta, jolla voidaan luoda ohjattuja toteutusesimerkkejä. Usein esitettyjen kysymysten palsta, FAQ (frequently asked questions), on yksi tapa toteuttaa tutoriaali. Sen etuna on, että se vastaa kysymyksiin, joita käyttäjille nousee järjestelmää omaksuttaessa. Usein esitettyjen kysymysten palstalla olevista kysymyksistä voi päätellä, mitkä osat tutoriaalidokumentaatiosta mahdollisesti kaipaisivat täydennystä. Eräs viime vuosien aikoina yleistynyt dokumentaatiotapa on mallien käyttö. Mallilla (pattern) tarkoitetaan tässä yhteydessä tarkasti määriteltyä tapaa kuvata kuinka jokin asia tulisi tehdä esimerkiksi ohjelmistokehystä erikoistettaessa. Tätä lähestymistapaa käsitellään tarkemmin esimerkiksi Johnsonin julkaisussa [Jo92]. Luvussa 3 käsitellään Fred-työkalua, jonka toiminta perustuu malleihin, joiden avulla ohjelmistokehyksen erikoistajaa voidaan avustaa kehyksen erikoistamisrajapinnan täydentämisessä. Fredin 21

29 käyttämien mallien graafisesta ja tekstuaalisesta osasta koostuvaa esitystä voidaan käyttää ohjelmistokehyksen erikoistamisrajapinnan dokumentointiin. Esimerkkejä tällä tavalla kuvatuista erikoistamiskohdista löytyy esimerkiksi Hautamäen lisensiaattityöstä [Ha02b]. Käytännössä tutoriaalit koostuvat usein monista yllä luetelluista tutoriaalityypeistä, mutta yleensä ei ole järkevää käyttää niitä kaikkia kuvaamaan samaa asiaa järjestelmästä. Koostava dokumentaatio Koostavalla dokumentaatio on tarkoitettu kokeneiden käyttäjien tarpeisiin. Sen tulisi olla täydellinen, jotta siitä löytyy vastaukset etsittyihin ongelmiin ja samalla kompakti, jotta etsityt vastaukset löytyvät nopeasti. Kaikenkattavan dokumentaation kirjoittaminen ei käytännössä ole mahdollista, koska siihen kuluvat resurssit tarvitaan muuhun käyttöön, eikä liian tarkka dokumentaatio maksa itseään rahallisesti takaisin. Koostava dokumentaatio voidaan jakaa edelleen arkkitehtuuriseen dokumentaatioon ja aihekohtaiseen koostavaan dokumentaatioon. Arkkitehtuurinen dokumentaatio kuvaa arkkitehtuuriset tavoitteet, ohjelman pääosat sekä niiden väliset suhteet ja interaktiot. Lisäksi se kuvaa moduulijaon perusteet, sekä sisältää mahdollisesti linkkejä lisäinformaatiota sisältäviin dokumentteihin. Aihekohtainen koostava dokumentaatio on jonkin konkreettisen osan, kuten prosessin, luokan, tai pakkauksen tarkka dokumentaatio. Se kirjoitetaan usein kyseessä olevan ohjelman toteutukseen ja erotetaan sieltä automaattisesti jollakin työvälineellä. Esimerkiksi JavaDoc on Javan yhteydessä käytettävä työkalu, joka luo tietyllä kommentointitavalla lähdekoodin joukkoon kirjoitetuista kommenteista html-muotoisen kuvauksen kyseisestä ohjelman osasta. Østerbye ym. ehdottavat, että aihekohtaisen koostavan dokumentaation tulisi kuvata luokan ja moduulin velvollisuudet, operaatioiden merkitys, pakkauksien ja luokkien invariantit, operaatioiden esi- ja jälkiehdot sekä kaikissa tapauksissa tyyppitiedot ja laajennusvaatimukset [Øs00]. Näin mittavan dokumentaation kirjoittaminen ei ole usein kuitenkaan mahdollista aikataulujen ja kustannusten takia. 22

30 Perusteleva dokumentaatio Perusteleva dokumentaatio on dokumentaation osa, joka kuvaa järjestelmän suunnittelussa harkitut vaihtoehdot ja selvittää syyt, miksi johonkin ratkaisuvaihtoehtoon on päädytty. Lisäksi se kuvaa syyt, minkä takia jostakin ratkaisuvaihtoehdosta on luovuttu myöhemmässä ohjelmistokehityksen vaiheessa, jotta samaa virhettä ei tehdä toistamiseen. Perustelevan dokumentaation hyödyt tulevat esiin vasta pidemmällä aikavälillä, sillä järjestelmää kehitettäessä kaikille on päätöksentekohetkellä selvää, miksi jokin päätös tehdään. Siitä voi olla kuitenkin huomattavaa hyötyä, jos järjestelmään tulee tehdä muutoksia pidemmän ajan kuluttua sen valmistumisesta, jolloin sen alkuperäiset suunnittelijat voivat olla esimerkiksi jo jättäneet yrityksen Dokumentoinnin ohjelmallinen tukeminen Ohjelmistoprosessin edetessä on eduksi, jos dokumentaation generointia voidaan automatisoida. Työmäärän vähentämisen lisäksi sillä voidaan varmistaa, että kaikki dokumentaatio kerätään yhteen. Muutoksien tapahtuessa automaattinen dokumentaation päivitys varmistaa, ettei dokumentaatio jää päivittämättä. Erilaisia dokumentoimiseen liittyviä työvälineitä on lukuisia ja tässä alikohdassa esitellään niistä vain pieni osa esimerkin vuoksi. Rational SoDA (Software Documentation Automation) [Rational SoDA] on työkalu, joka mahdollistaa dokumentaation keräämisen yhteen useista eri lähteistä. Sillä voidaan esimerkiksi kerätä yhteen Word-dokumenttiin Rational Rosella [Rational Rose] tuotettu materiaali. Aihekohtaisen koostavan dokumentaation erottamiseen lähdekoodista on useita työvälineitä. JavaDoc on Javan yhteydessä käytettävä työväline, joka generoi htmlmuotoisen dokumentaation pakkaus-, luokka-, ja metodikohtaisista JavaDoc-syntaksin mukaisista kommenteista [JavaDoc]. BumbleBee [BumbleBee] ja George [George] ovat C++-kielen yhteydessä käytettäviä aihekohtaisen koostavan dokumentaation tuottavia työkaluja. Muita vastaavia työkaluja ovat mm. DOC++ [DOC], Doxygen [Doxygen] ja HappyDoc [HappyDoc]. 23

31 Vestdam on esittellyt työvälineen, joka yhdistää konkreettisiin esimerkkeihin ja tekstikirjamaiseen tutoriaaliin liittyvät piirteet. Vestdamin esittelemä työväline mahdollistaa hyperlinkkeihin perustuvien ohjelmatutoriaalien tekemisen ja ohjelmakoodiesimerkkien luontevan liittämisen selittävän tekstin joukkoon. [Ve02] Java Pages on Fred-ympäristöön tehty laajennus, joka mahdollistaa ohjattujen toteutusesimerkkien tallentamisen ohjelmistokehystä erikoistettaessa ja tallenteen selaamisen WWW-selaimella Java-appletin kautta. Sen ideana on mahdollistaa ohjelmistokehyksen käytön opettelu ilman, että ohjelmistokehyksen lähdekoodeja tai mitään ohjelmointiympäristöä tarvitsee asentaa omalle koneelleen. Java Pages -työkalua on käsitelty tarkemmin luvussa 4 ja Fred ympäristöä luvussa 3. 24

32 3 Fred Ohjelmistokehyksien omaksuminen vaatii aikaa, eikä käyttäjällä ole välttämättä alkuvaiheessa edes tietoa siitä, mistä uuden ohjelmistokehyksen käytön opetteleminen kannattaisi aloittaa. Lisäksi ohjelmistokehyksien dokumentoimiseen liittyy omia erityisongelmiaan. Fred on prototyyppi työkalusta, joka pyrkii helpottamaan ohjelmistokehyksien käyttöön liittyviä ongelmia. Fred-ympäristössä ohjelmistokehyksen kehittäjä (system architect) voi kuvata ohjelmistokehyksen erikoistamisrajapinnan mallien avulla. Fred ohjaa erikoistamista tekevää sovelluskehittäjää (application developer) näiden mallien pohjalta ja varmistaa, ettei erikoistus riko mallien asettamia vaatimuksia. Kuva 3.1 esittää Fredin merkitystä tässä prosessissa. Fred on Tampereen teknillisen yliopiston ja Helsingin yliopiston yhteistyöhankeen tulos. Tämä luku pyrkii kuvaamaan Fredin keskeiset ideat ja periaatteet, joiden ymmärtäminen on tärkeää luvussa 4 kuvatun Frediin tehdyn Java Pages -laajennuksen toiminnan ymmärtämiseksi. Fredin toteutusta ja yksityiskohtia käsitellään tarkemmin Hakalan ym. artikkeleissa [Ha01a, Ha01b]. Ohjelmistokehyksen kehittäjä Fred Sovelluskehittäjä Mallit Tehtävät Toimenpiteet Kuva 3.1. Ohjelmistokehyksen kehittäjän, Fred-työkalun ja erikoistajan suhde [Ha02b] 25

33 3.1 Ideat Fredin taustalla Ohjelmointiympäristöt tarjoavat nykyään paljon erilaista lähdekoodin kirjoittamiseen liittyvää tukea ohjelmoijille. Lähdekoodia voidaan esimerkiksi generoida käyttäjän muokkaamista pohjista (template) napin painalluksella ja luokan rajapinnan metodit voidaan listata käyttäjälle automaattisesti kirjoittamalla luokan instanssin nimen perään piste. Tuotantokäytössä olevista työkaluista puuttuu kuitenkin tuki arkkitehtuurin valvomiselle, ylläpitämiselle ja kehittämiselle. Ohjelmointikieletkään eivät tarjoa riittävää tukea erikoistamiskohtien riippuvuuksien määrittelemiseksi. Ne voivat mahdollistaa esimerkiksi metodin julistamisen lopulliseksi (Javan final-määre), jolloin sitä ei enää voi ylimääritellä tai julistaa abstraktiksi aliluokissa. Monimutkaisempien riippuvuuksien (jos on jäsenmuuttuja X on oltava metodi Y) tai rajoitteiden (jos jäsenmuuttujan X tyyppi on Z niin metodin Y paluuarvon tyyppi on oltava Z) kuvaaminen ei ole kuitenkaan mahdollista ohjelmointikielen tasolla. Fredin suunnittelun pohjalla on neljä vahvaa ideaa. Ensimmäiseksi, se tukee erikoistamisprosessia, joka on inkrementaalinen, iteratiivinen ja interaktiivinen. Ohjelmistokehyksen erikoistamista ei voida yleensä esittää velhon (wizard) ohjaamana suoraviivaisena prosessina, jossa käyttäjä valitsee vaihtoehtoja ja ratkaisu generoidaan automaattisesti. Velhon käyttö ei ole mahdollista, koska erikoistamiseen liittyy paljon valintoja, jotka määrittävät seuraavat tehtävissä olevat valinnat, eikä käyttäjä kykenisi ymmärtämään valinnoistaan riippuvia seurauksia. Kun velhon käytön päätteeksi generoitaisiin kerralla koko ohjelman lähdekoodi, käyttäjä ei ymmärtäisi kunkin valinnan ja generoidun ohjelmakoodiin välistä riippuvuutta. Tämän takia käyttäjän on voitava tehdä erikoistaminen pienissä paloissa ja nähdä valintojensa vaikutukset lähdekoodiin heti. Tämän lisäksi hänellä tulee olla mahdollisuus korjata tekemiään erehdyksiä, mikäli sellaisia syntyy. Dynaaminen, käyttäjän päätöksien mukaisesti päivittyvä tehtävälista on Fredissä käytössä oleva ratkaisu näiden tavoitteiden saavuttamiseksi. Tehtävälistan avulla käyttäjä pystyy paremmin kontrolloimaan erikoistamisprosessia ja ymmärtämään erilaisten valintojen vaikutukset prosessissa. 26

34 Toinen Fredin perusidea on käyttää erikoistuvia erikoistamisohjeita. Normaalisti ohjelmistokehyksen erikoistamisessa kohdattava ongelma vaatii rajapintadokumentaation tutkimista ja ohjelmistokehyksen muun dokumentaation selaamista, jotta nähtäisiin puhutaanko siellä kyseisestä ongelmasta mitään. Samalla käyttäjä joutuu tutkimaan esimerkkejä, joilla ei ole mitään tekemistä hänen ohjelmakoodinsa kanssa, ja ymmärtämään mikä esimerkin ja hänen itse tuottamansa ohjelmakoodin suhde on. Fredin lähestymistavassa erikoistamisohjeet luodaan erikoistamisprosessin edistyessä, ja näin ollen niissä voidaan käyttää ajonaikaisesti kerättyä, kyseiseen erikoistamisprosessiin liittyvää tietoa kuten käyttäjän antamia luokkien ja metodien nimiä. Erikoistamisprosessin edetessä myös erikoistamiseen liittyvä dokumentaatio tarkentuu vastaamaan kyseistä tilannetta yhä tarkemmin. Tämän ansioista erikoistamisohjeiden seuraaminen on huomattavasti helpompaa kuin perinteisen dokumentaation tapauksessa. Kolmas idea on käyttää arkkitehtuurisensitiivistä lähdekoodieditoria. Arkkitehtuurin sanelemat säännöt kiinnittävät aina toteutuksen tiettyjä osia toteutettavaksi joidenkin ohjelmointikielen sääntöjen mukaisesti. Näitä sääntöjä voidaan pitää lähdekoodin kannalta vastaavina kuin ohjelmointikielen syntaksin asettamia vaatimuksia ohjelmakoodin oikeellisuudelle. Seuraamalla muutoksia lähdekoodissa Fred voi ilmoittaa käyttäjälle, milloin arkkitehtuurin asettamia vaatimuksia on rikottu. Käytännössä rikkomuksien seurauksena syntyy korjaustehtäviä käyttäjän tehtävälistaan. Neljäs idea on se, että erikoistamisprosessi ei koskaan pääty. Käytännössä erikoistamisprosessin jatkuttua tietyn aikaa käyttäjä on saanut aikaan ajettavan sovelluksen (tai yhden toimivan komponentin, jos kyseessä oli kehyskomponentin erikoistaminen) ja luultavasti siis saavuttanut oman tavoitteensa. Työkalu ei kuitenkaan tulkitse tehtävää suoritetuksi omalta kannaltaan, vaan jatkaa arkkitehtuurin noudattamisen seuraamista jatkossakin. Tämä ominaisuus mahdollistaa tuen tulevaisuudessa tapahtuvalle ohjelman ylläpidolle ja laajentamiselle. 27

35 3.2 Fredin käsitteistö Täsmällisesti ottaen Fred on ohjelmointiympäristö, johon voidaan liittää helposti erilaisia laajennuksia. Mallikone on eräs Fredin laajennus, joka toteuttaa käytännössä tässä luvussa kuvatut Fredin malleihin liittyvät toiminnot. Koska kyseessä on erillinen komponentti, myös sen integroiminen muihin ohjelmistokehitysympäristöihin on mahdollista, mikäli ne tarjoavat riittävän kattavan integrointirajapinnan. Mallikoneen integrointia muihin ohjelmistoympäristöihin käsitellään lisää kohdassa 3.4. Puhuttaessa Fredistä tässä diplomityössä tarkoitetaan kokonaisuutta, joka sisältää sekä Fredohjelmistokehitysympäristön, että siihen integroidun mallikoneen. Fredin toiminnan ymmärtämiseksi on syytä käydä läpi hiukan sen toiminnan teoreettista perustaa. Fred on kokonaisuutena monimutkainen työkalu, johon liittyy paljon omaa terminologiaa. Näiden käsitteiden täydellinen ymmärtäminen ei ole tarpeen Frediä käyttävälle ohjelmistokehyksen erikoistajalle, mutta niiden avulla järjestelmästä saa huomattavasti kattavamman kuvan. Ohjelmistokehyksen ja sen erikoistamismallien tekijän on sen sijaan syytä ymmärtää ainakin hiukan teoriaa voidakseen hyödyntää kaikkia työkalun mahdollisuuksia Mallit, roolit ja rajoitteet Fredin toiminta perustuu mallien käsitteeseen. Mallit ovat alunperin rakennusarkkitehtuurialan käsite, ja niiden isä on Christopher Alexander. Alexander on kirjoittanut aiheesta useita julkaisuja, joista mallien ideaa on käsitelty kattavammin esimerkiksi kirjoissa A Pattern Language [Al77] ja The Timeless Way of Building [Al79]. Rakennusarkkitehtuurin yhteydessä mallien perusideana oli helpottaa suunnitteluprosessia samojen suunnitteluratkaisujen uudelleenkäytön avulla. Rakennustekniikan mallien ideaa on lainattu ohjelmistotekniikkaan ja tuloksena ovat syntyneet muun muassa viime vuosina hyvin tunnetuksi tulleet suunnittelumallit, joita on käsitellyt kattavammin Gamma ym. [Ga95]. 28

36 Fredin tapauksessa malleja käytetään esittämään monimutkaisia riippuvuusrakenteita ja niiden avulla voidaan kuvata eri ohjelman osien välisiä riippuvuuksia. Ohjelmointikielien syntaksi on usein riittämätön kuvamaan kaikkia ohjelman osien välisiä suhteita, joten Fredin mallit tarjoavat ilmaisuvoimaisemman tavan erilaisten riippuvuuksien esittämiseen.. Mallien avulla mahdollistetaan lähdekoodin validointi arkkitehtuurista mallia vastaan. Malleja käytetään usein kuvaamaan ohjelmistokehyksen erikoistamisrajapinnan vaatimuksia, mutta ne soveltuvat myös esimerkiksi suunnittelumallien ja erilaisten konventioiden kuten Java Beans:in asettamien sääntöjen valvomiseen. Erikoistamismallilla (specialization pattern) tarkoitetaan mallia, joka kuvaa ohjelmistokehyksen erikoistamiskohdan asettamat vaatimukset. Erikoistamismalli ei kiinnitä yhtä tapaa toteuttaa erikoistus, vaan rajaa sallittujen toteutuksien joukkoa pienemmäksi. Erikoistavan ohjelmakoodin tulee olla asetettujen vaatimusten mukainen, mutta juuri erikoistamiskohtien toisistaan poikkeavilla toteutuksilla saadaan aikaan kehykseen perustuvat erilaiset ohjelmavariantit. Malli on siis abstrakti kuvaus toistuvasta ohjelmarakenteesta. Jos ohjelmassa on mallin mukainen rakenne, sanotaan, että ohjelma toteuttaa mallin. Fred keskittyy kuvaamaan tätä ohjelman ja mallin välistä suhdetta yksityiskohtaisella tasolla. Fredissä mallit koostuvat rooleista. Ohjelman rakenneosia, kuten luokkia, metodeja ja jäsenmuuttujia kutsutaan ohjelmaelementiksi. Mallin ja ohjelman välistä suhdetta kuvataan joukkona roolien ja ohjelmaelementtien välillä olevia sidontoja. Näiden perusteella voidaan tarkistaa, onko ohjelmakoodi mallin mukainen, sekä haluttaessa laajentaa ohjelmaa mallin edellyttämällä tavalla. Kuva 3.2 esittää mallien, roolien, sidontojen ja ohjelmaelementtien välisiä suhteita. 29

37 Malli Ohjelmakoodi Sidontoja Rooleja Ohjelmaelementtejä Sidontoja Kuva 3.2. Fredin peruskäsitteet Jokaiseen rooliin liittyy joukko ominaisuuksia (property), jotka määräävät roolin semantiikan. Puhumme esimerkiksi luokkarooleista, metodirooleista, jäsenmuuttujarooleista jne. Luokkaroolin tapauksessa eräs ominaisuuksista on periytyvyys, joka määrää roolin ohjelmakoodissa toteuttavan luokan perinnälle asetettavat vaatimukset. Tällaisia rajoittavia ominaisuuksia kutsutaan rajoitteiksi (constraint). Jotkut ominaisuudet ohjaavat sen sijaan esimerkiksi oletustoteutuksen generoimista tai ohjetekstien luontia. Tämänkaltaisia rooleja kutsutaan kaavaimiksi (template). Niitä käytetään tekstin generoimiseen, mutta niiden oikeellisuutta ei tarkisteta jälkikäteen. Ohjelmaelementtejä voidaan sitoa täyttämään tietty rooli ja tällaista yhteyttä kutsutaan sidonnaksi (binding). Kardinaliteetti (cardinality) määrittää roolin ja ohjelmaelementtien välisen lukumääräsuhteen. Kunkin roolin kardinaliteetti voi olla 1, 0..1, 1..* tai 0..*. Kardinaliteetti 1 määrää, että roolia tulee vastata täsmälleen yksi ohjelmaelementti. Kardinaliteetti 0..1 tarkoittaa, että roolia saa vastata yksi ohjelmaelementti, mutta se ei ole pakollista. Kardinaliteetti 1..* tarkoittaa, että roolia tulee vastata vähintään yhden ohjelmaelementin ja 0..* vastaavasti sitä, että roolia saa vastata määrittelemätön määrä ohjelmaelementtejä. Toisinpäin vastaavaa vaatimusta ei ole: kukin ohjelmaelementti voi toteuttaa yhden roolin, useita rooleja, tai olla toteuttamatta yhtään roolia. Ohjelmaelementin voi sitoa myös rooliin, jonka asettamia vaatimuksia se ei täytä. Tämän seurauksena Fred luo käyttäjälle tehtäviä, joilla se ilmoittaa arkkitehtuurin asettamien vaatimuksien rikkomisesta. Tehtäviä käsitellään tarkemmin alikohdassa

38 Kardinaliteetit ovat suhteellisia ja riippuvaisia ympäristöstään. Esimerkiksi luokasta A riippuva metodirooli B, jonka kardinaliteetti on 1 tarkoittaa, että kutakin luokkaroolin A toteuttavaa ohjelmaelementtiä kohden tulee olla yksi metodiroolin B toteuttava ohjelmaelementti. Käytännössä ohjelmassa voi siis olla useita metodiroolin B mukaisia metodeja (yksi jokaista A:n ilmentymää kohti) huolimatta siitä, että metodiroolin B kardinaliteetti on 1. Kardinaliteetteihin liittyviä asioita on käsitelty tarkemmin Hakalan ym. julkaisuissa [Ha01a, Ha01b, Ha00] Mallien ja tehtävien suhde Fredin keskeinen työkalu on tehtävälista. Tehtävälistassa näkyvät tehtävät, jotka Fred luo ohjatakseen käyttäjän erikoistamisprosessia. Käytännössä Fred tutkii roolien ja niihin sitoutuneiden ohjelmaelementtien suhteita. Potentiaalisella sitomisella (potential binding) tarkoitetaan tilannetta, jossa ohjelmaelementin sitominen rooliin tietyllä hetkellä on mahdollista. Kun Fred havaitsee tällaisen tilanteen, se näyttää tehtävälistassa tehtävän, joka ehdottaa sidonnan suorittamista. Tehtävälistassa näkyvä tehtävän kuvaus määräytyy roolin ominaisuuksien pohjalta, ja esimerkiksi siihen liittyvät ohjetekstit voidaan generoida roolin kaavaimien perusteella siten, että ohjeteksti käyttää erikoistuksen terminologiaa luokkien nimien, metodien ja muiden vastaavien tietojen osalta. Kuva 3.3 esittää mallin, sidontakuvion (cast) ja lähdekoodin suhdetta esimerkissä, jossa malliin kuuluu luokkarooli, jolla on keskenään riippuvaisia jäsenmuuttuja- ja metodirooleja. Malli määrää, että jokaista luokan jäsenmuuttujaa kohden tulee olla metodi, jolla jäsenmuuttujan arvon voi hakea (getter). Lisäksi jokaista jäsenmuuttujaa kohden saa olla yksi asetusmetodi (setter). Mallin roolit yhdistyvät lähdekoodiin sidontakuviossa esitetyllä tavalla, ja sidontakuviosta voidaan generoida tehtävälista. Sidontakuviossa näkyy toteutettu tehtävä, joka on käytännössä sitonut luokkaroolin (Class) lähdekoodin luokkaan X. Luokkaroolin kardinaliteetti on 1..*, joten samalla sidontakuvioon on syntynyt uusi potentiaalinen sidonta luokkaa varten (näkyy sidontakuviossa valkoisena ympyränä, joka on nimetty Class 2). Tämän sidonnan avulla luokkarooliin voitaisiin nyt sitoa toinenkin luokka ja syntyisi taas uusi potentiaalinen sidonta. Kuvasta nähdään myös, että yksi jäsenmuuttujarooli on sidottu lähdekoodissa 31

39 jäsenmuuttujaan _y ja jäsenmuuttujaroolista riippunut metodirooli Setter on sidontakuviossa yhdistetty metodiin sety. Tämä on ollut vapaaehtoinen tehtävä, sillä Setter-roolin kardinaliteetti on Koska roolin sidontojen yläraja on 1, ei sidontakuvioon generoidu tehtävää toisen Setter-metodin tekemiseksi samalle jäsenmuuttujalle. Sidontakuviossa näkyvä pakollinen tehtävä on metodin sitominen Getter-rooliin. Tämä tehtävä on pakollinen, sillä kyseessä on potentiaalinen sidonta (sidontakuviossa on tehtynä molemmat tehtävät, joista tämä sidonta riippuu) ja roolin kardinaliteetti on 1. Huomaa, että jos jäsenmuuttujarooliin olisi sidottuna useita lähdekoodin jäsenmuuttujia, kutakin tällaista sidontaa kohti muodostuisi yksi pakollinen tehtävä Getter-metodin toteuttamiseksi ja yksi vapaaehtoinen tehtävä Setter-metodin toteuttamiseksi. On myös hyvä huomata, että vapaaehtoisen tehtävän suorittaminen voi saada aikaan pakollisien tehtävien syntymisiä. Jos esimerkissämme sidottaisiin toinenkin jäsenmuuttuja ohjelmakoodiin (vapaaehtoinen tehtävä), se aiheuttaisi pakollisen tehtävän luoda Gettermetodi tälle jäsenmuuttujalle. Malli Sidontakuvio Lähdekoodi Class 2 Class (1..*) Field 2 Class 1 public class X { private int _y; Field(0..*) Setter(0..1) Field 1 Setter 1 public void sety( int y ) { _y = y; } } Getter(1) Getter 1 luokkarooli jäsenmuuttujarooli metodirooli tehty tehtävä pakollinen tehtävä vapaaehtoinen tehtävä Kuva 3.3. Mallin, sidontakuvion ja lähdekoodin suhde 32

40 Käyttäjälle näkyvä tehtävälista saadaan muodostettua sidontakuviosta. Ideaalitilanteessa tehtävälistaa päivitetään samanaikaisesti kun käyttäjä työskentelee ohjelmointiympäristössä. 3.3 Ohjelmistokehitys Fred-ympäristössä Ohjelmistokehykset jakavat usein yrityksen ohjelmoijat kahteen osaan. Toisista tulee ohjelmistokehyksen kehittäjiä ja toisista sovelluskehittäjiä eli sovelluskehyksen erikoistajia. Fred pyrkii palvelemaan prosessin molempia osapuolia. Kuva 3.1 esitti tämän idean. Ohjelmistokehyksen kehittäjä kirjoittaa ohjelmistokehyksen ohjelmakoodin sekä tekee siihen liittyvät mallit Fred-ympäristöön. Tämän jälkeen sovelluskehittäjä erikoistaa kehyksestä sovelluksia Fredin vastatessa siitä, että erikoistuksesta tulee ohjelmistokehyksen laatijan tekemien mallien mukainen Ohjelmistokehyksen kehittäjän näkökulma Ohjelmistokehyksen kehittäjä on henkilö, joka suunnittelee, toteuttaa ja ylläpitää ohjelmistokehystä. Hänellä on selkeä kuva kehyksen sisäisestä arkkitehtuurista sekä sen mahdollisuuksista ja rajoituksista. Ohjelmistokehyksen kehittäjän vastuulla on kehyksen ylläpitäminen ja tarvittavien muutosten tekeminen. Ohjelmistokehyksen kehittäjien toimenkuvaan kuuluu myös kirjoittaa ohjelmistokehyksen käyttöön ja opetteluun tarvittava dokumentaatio. Tietoja voi kuvata esimerkiksi keittokirjamaisin tutoriaalein, selkeällä rajapintojen dokumentoinnilla ja muilla kohdassa 2.3 kuvatuilla tavoilla. Fred-ympäristössä hänellä on lisäksi käytössään uusi mahdollisuus erikoistamisrajapinnan kuvaamiseen. Fred-ympäristön mallit mahdollistavat erikoistamisrajapinnan kuvaamisen entistä tarkemmin, ja erikoistajien ohjaaminen ja valvominen siirtyy Fredin tehtäväksi. Ohjelmistokehyksen erikoistamisrajapinta on triviaaleja esimerkkejä lukuun ottamatta yleensä laaja, joten kutakin ohjelmistokehyksen erikoistamiskohtaa varten kannattaa muodostaa oma erikoistamismallinsa. Näin mallit pysyvät ymmärrettävän kokoisina. Erikoistamiskohtien tunnistaminen ohjelmistokehyksestä on yleensä helppoa, koska 33

41 ohjelmistokehittäjä on itse suunnitellut ohjelmistokehyksen ja näin ollen hän tietää kuinka kehys on suunniteltu laajennettavaksi. Joskus on kuitenkin tilanteita, joissa halutaan tehdä malleja ohjaamaan jonkun toisen ohjelmoijan tekemän ohjelmistokehyksen erikoistamista. Tällöin mallin tekemiseen liittyvä ensimmäinen tehtävä on erikoistamiskohtien paikantaminen. Paikantaminen perustuu yleensä abstrakteina luokkina tai rajapintoina kuvattujen käsitteiden hahmottamiseen. Jos tutkittavasta ohjelmistokehyksestä on saatavilla esimerkkisovelluksia, voidaan erikoistamiskohtia paikantaa etsimällä ylimääriteltyjä metodeja, sillä laajennettavuus perustuu yleensä monimuotoisuuteen (polymorphism) [De98]. Viljamaa [Vi01] käsittelee tarkemmin järjestelmän rakenteen pohjalta tapahtuvaa erikoistamiskohtien mallintamista. Erikoistamista ohjaavien mallien teko on iteratiivinen ohjelmistokehyksen tekoon verrattava prosessi, jossa malli kehittyy askelittain täydellisemmäksi. Kaikkia tarpeita on vaikeaa ymmärtää ensimmäisellä kerralla, joten alkuvaiheessa on parasta suunnitella malli, joka asettaa väljät rajat erikoistajalle. Tätä mallia on myöhemmin helppo täydentää, tai samaan erikoistamiskohtaan voidaan tehdä useita malleja, joista erikoistaja voi valita tarvitsemansa. Päämäärähakuisessa (goal-oriented) erikoistamiskohtien mallintamisessa ohjelmistokehyksen kehittäjä tietää mihin erikoistajat haluavat käyttää ohjelmistokehystä. Tämän tiedon pohjalta hän voi kehittää malleja, joiden avulla erikoistajat pääsevät haluamiinsa päämääriin. Hautamäki [Ha02b] käsittelee tätä lähestymistapaa tarkemmin. Mallien automaattista etsimistä on myös tutkittu. Viljamaa [Vi02] käsittelee mahdollisuutta mallien automaattiseen generointiin. Menetelmä perustuu ohjelmistokehyksestä erikoistettujen sovellusten ohjelmalliseen tutkimiseen ja sillä on saavutettu rohkaisevia tuloksia. Erikoistamismallin valmistuttua se tulee alustaa (pattern initialization) käyttöön. Osa mallin rooleista liittyy ohjelmistokehyksen luokkiin, metodeihin ja jäsenmuuttujiin, joten 34

42 ohjelmistokehyksen kehittäjä sitoo nämä mallin osat ohjelmistokehyksen toteutukseen. Erikoistamisosaan liittyvät roolit jätetään tietenkin vielä sitomatta, koska vasta erikoistamisvaiheessa luodaan toteutus, johon ne voidaan sitoa Sovelluskehittäjän näkökulma Sovelluskehittäjä näkee Fredin hänen työtään ohjaavana ja valvovana työvälineenä, jolta voi myös pyytää oletustoteutuksia tehtävälistassa näkyville tehtäville. Erikoistaminen etenee tehtävälistassa näkyvien tehtävien mukaisesti, ja tehtäviä voi suorittaa vapaavalinnaisessa järjestyksessä. Käytännössä järjestys määräytyy tietysti pääosin siten, että tehtävää ei näy tehtävälistassa ennen kuin kaikki tehtävät, joista se riippuu on tehty. Tehtävät voi suorittaa kolmella eri tavalla. Käyttäjä voi kirjoittaa itse ohjelmakoodia, joka täyttää tehtävän. Toinen vaihtoehto on pyytää Frediä tarjoamaan oletustoteutus tehtävän suorittamiseksi. Tällöin Fred generoi ohjelmakoodin tehtävään liittyvän roolin ominaisuuksien perusteella, ja käyttäjä voi itse mukauttaa sen tarpeidensa mukaiseksi. Kolmas vaihtoehto on sitoa tehtävä johonkin olemassa olevaan ohjelmaelementtiin. Jos erikoistaja muokkaa lähdekoodia siten, että se rikkoo arkkitehtuurin asettamia rajoituksia, Fred luo tarvittavia korjaustehtäviä. Kun kaikki pakolliset tehtävät ja haluttu määrä vapaaehtoisia tehtäviä on suoritettu, erikoistus on valmis. Tämän jälkeen erikoistaja voi jatkaa työtään esimerkiksi valitsemalla toiseen erikoistamiskohtaan sopivan mallin ja luomalla sen perusteella seuraavan erikoistuksen, kunnes kaikki ohjelmistokehyksen erikoistamiskohdat on täytetty ja ohjelma on valmis. 3.4 Fred käytännössä Fred on ohjelmointiympäristö, jota on mahdollista täydentää yksittäisten laajennusten (plugin) avulla. Fredin keskeisin osa on mallikone (pattern engine), joka toteuttaa tässä luvussa käsitellyn malleihin liittyvän logiikan. Mallikone ja Fred on molemmat toteutettu täysin Javalla, mutta arkkitehtuurisesti mallikone on Fred-työkalussa oleva yksittäinen komponentti. Mallikone on mahdollista integroida myös muihin ohjelmointiympäristöihin, 35

43 jotka tarjoavat riittävän kattavan rajapinnan integroinnin suorittamiseksi. Kuva 3.4 esittää Fredin integroituna Eclipse-ympäristöön. Käyttöliittymästä voidaan erottaa joitakin yksittäisiä kokonaisuuksia, joilla on merkitystä tässä luvussa käsitellyn Fredille ominaisen toiminnallisuuden aikaansaamiseksi. Eclipsen tapauksessa työskentelynäkymän voi koostaa itse haluamistaan osista, joten tässä käytettävä näkymä on vain yksi mahdollinen kokonaisuus. Vasemmassa yläreunassa näkyvä arkkitehtuurinäkymä sisältää kaikki olemassa olevat mallit. Esimerkkimme tapauksessa näkymässä on kaksi mallia: Bean ja MyBean. Käyttäjä voi luoda uusia malleja. Kuva 3.4. Fred integroituna Eclipse-ympäristöön 36

44 Vasemmassa alareunassa on Eclipsen standardinäkymiin kuuluva Navigator-näkymä, jossa näkyy projektiin kuuluvat tiedostot. Se ei sinänsä liity Fredin toiminnallisuuteen, mutta on tarpeen projektin hallitsemiseksi. Käyttöliittymän keskiosassa oleva Eclipsen oma lähdekoodieditori sisältää auki olevat projektin tiedostot. Esimerkissämme näkymässä on avoinna MyBean -luokan toteutuksen sisältävä tiedosto. Kun tiedostoihin tehdään muutoksia käyttäen lähdekoodieditoria, mallikone saa ilmoituksen kaikista muutoksista ja päivittää näytön alaosassa näkyvää tehtävälistaa muutoksien mukaisesti. Tehtävälistassa näkyy avoinna oleva malli MyBean, sekä yksi tehty tehtävä, jolla on toteutettu MyBean-luokka. Näkymän oikeassa reunassa näkyvät MyBeanohjelmaelementtiin liittyvät alitehtävät. Tässä tapauksessa näillä voidaan toteuttaa uusia jäsenmuuttujia ja niihin liittyviä getter ja setter -metodeja. Esimerkissämme käyttäjä on päättänyt toteuttaa getter-metodin, jolloin Fred tarjoaa käyttäjälle vaihtoehtoina luoda automaattinen oletustoteutus metodille tai antaa käyttäjän poimia ennestään tehty ja tarkoitukseen sopiva toteutus metodille. Tehtävälistan tilasta käyttäjä näkee heti, onko ohjelma arkkitehtuurin mukainen. Jos jäljellä ei ole tehtäviä tai kaikki jäljellä olevat tehtävät ovat vapaaehtoisia, on erikoistus mallin mukainen (jos jäljellä on vapaaehtoisia tehtäviä, niiden toteuttaminen voi kuitenkin olla tarpeellista halutun toiminnallisuuden aikaansaamiseksi). Jos tehtäviä on jäljellä, erikoistamisprosessi etenee loogisessa järjestyksessä niitä toteuttamalla. Valitsemalla tehtävän Fred näyttää sen kuvauksen käyttäjälle. Kuvaus voi olla selitys siitä, miksi tekemätön tehtävä tulee suorittaa (sen merkitys erikoistamisprosessille), tehdyn tehtävän tapauksessa selitys siitä, mikä tehtävän merkitys kokonaisuudelle on tai rikotun tehtävän tapauksessa korjausohje ohjelman palauttamiseksi arkkitehtuurin mukaiseksi. 37

45 4 Java Pages Ohjelmistokehyksien opetteleminen on hidas ja vaikea prosessi. Perinteisesti kehyksen opiskeleminen perustuu erilaisten tekstikirjamaisten dokumentaatioiden tutkimiseen, usein esitettyjen kysymyksien -palstan selaamiseen sekä tietysti ohjelmistokehyksen rajapintadokumentaatioon perehtymiseen. Tapauksissa, joissa dokumentaatio on riittämätöntä ja ohjelmistokehyksen toteutus saatavilla, opiskelu sisältää myös itse lähdekoodin tutkiskelua toimintalogiikan ymmärtämiseksi. Java Pages on Frediin tehty työkalu, joka mahdollistaa mallitapauksien nauhoittamisen ohjelmistokehyksen erikoistamisprosessista sekä näin saatujen nauhoitteiden tutkimisen tavallisessa WWW-selaimessa. Kuva 4.1 kuvaa Java Pages -työkalun toimintaperiaatetta. Tässä luvussa käsitellään Java Pages -työkalun taustalla olevia ideoita, työkalun toimintaa sekä sen toteutustapaa. Työkalun alustava määrittely on alunperin julkaistu Hakalan ym. julkaisuna [Ha02a]. Ohjelmistokehyksen kehittäjä Fred Sovelluskehittäjä Mallit Tehtävät Toimenpiteet Ohjelmistokehyksen käytön opiskelija Java Pages -selain Massamuisti Nauhoite Kuva 4.1. Java Pages -työkalun periaate 38

46 4.1 Työkalun taustalla olevat ideat Fred näyttää käyttäjälle aktiivisen keittokirjan tavoin toimivaa dokumentaatiota erikoistamisprosessin aikana. Fred antaa siis käyttäjälle ohjeita siitä, kuinka erikoistamista voi kulloinkin jatkaa, ja erikoistamisohjeet tarkentuvat käyttäjän edetessä erikoistamisprosessissa. Tämän ansioista Fred voi generoida ohjeisiin esimerkiksi käyttäjän itsensä määrittelemien luokkien nimiä. Fredin antama ohjeistus on siis erikoistamisaikaista. Usein on kuitenkin tilanne, jossa käyttäjä haluaa opiskella ohjelmistokehyksen käyttöä, tai tutkia miten jokin ohjelmistokehyksen erikoistamiskohta tulee erikoistaa. Jos mahdollista, tämä olisi voitava tehdä ilman minkään ylimääräisien ohjelmien, kuten Fredin, asentamista. Lisäksi käyttäjän olisi hyvä saada kokonaiskuva kehyksen toiminnasta ennen kuin hän aloittaa erikoistamisprosessin. Toisaalta käyttäjien tulee olla vuorovaikutuksessa järjestelmän kanssa oppiakseen, mutta voidakseen tehdä niin, heidän tulee oppia ensin [Ca90]. Tämä näennäinen ristiriita voidaan ratkaista esimerkiksi käyttämällä ohjattuja toteutusesimerkkejä. Näiden avulla käyttäjä pääsee tutustumaan konkreettisesti ohjelmakoodiin liittyviin yksityiskohtiin ja tutkimaan, miten kukin asia on ratkaistu. Ratkaisu esitetään sarjana pieniä muutoksia, joten yksittäisten ohjelmakoodin osien merkityksen ymmärtäminen on helpompaa. Konkreettisten esimerkkien avulla oppiminen on helpompaa kuin asiaa käsittelevän tekstikirjamaisen abstraktin tekstin ymmärtäminen [Ha94, En88, LoLo91]. Java Pages -työkalun suunnittelussa on otettu huomioon tarve opiskella ohjelmistokehyksen käyttöä erilaisissa ympäristöissä. Työkalulla tehtyjä ohjattuja toteutusesimerkkejä voi tutkia WWW-selaimessa toimivassa Java-appletissa, joka on täysin riippumaton tietokoneeseen asennetuista ohjelmistoympäristöistä tai Fredtyökalusta. Koska minkään ohjelmistokehykseen liittyvien osien asentaminen tai lataaminen omalle tietokoneelle ei ole tarpeellista, prosessi on käyttäjälle äärimmäisen yksinkertainen. Päivitettäessä ohjattua toteutusesimerkkiä ei ole vaaraa, että käyttäjille jäisi vanha versio, sillä appletti hakee tietonsa joka kerta uudelleen palvelimelta. 39

47 Suunnittelun ideoiden taustalla on ollut yrityksien tarve luoda sisäinen sivusto, jolta voidaan ladata ohjelmistoja, sekä niihin liittyvää dokumentaatiota. Yrityksen sisäisen sivuston ideana on mahdollistaa helppo ajantasaisten ohjelmistojen ja ohjelmistokehyksien kattava jakelu kaikille niitä tarvitseville työntekijöille. Toimiakseen järjestelmä tarvitsee tuekseen myös toimivan ja kattavan dokumentaation jakelukanavan. Usein dokumentaatioksi riittää perinteinen rajapintadokumentaatio, mutta ohjelmistokehyksien tapauksessa on tarpeen tarjota kattavampaa dokumentaatiota esimerkiksi ohjattujen toteutusesimerkkien muodossa. Kuten alikohdassa todettiin, dokumentaation luomisen tulisi olla osa ohjelmistokehittäjän luonnollista työskentelyä. Java Pages pyrkii tähän päämäärään nauhoittamalla ohjelmistokehyksen erikoistamisprosessin tapahtumia Fred-ympäristössä. Erikoistamisen tekeminen on osa ohjelmistokehyksen kehittäjän työtä, sillä hänen on joka tapauksessa testattava, että hänen Frediin tekemänsä malli toimii. Valitsemalla mallin testaamiseen käytettävän erikoistamistapauksen huolellisesti hän voi samalla kertaa tuottaa kehyksen erikoistamista hyvin kuvaavia Java Pages -nauhoitteita erikoistamisprosessin etenemisestä. Java Pages poikkeaa selvästi olemassa olevista ohjelmista, joilla voidaan generoida käyttöohjeiden yhteydessä suosittuja ohjelman käyttöä kuvaavia nauhoitteita. Käyttöohjetta selventävien nauhoitteiden ideana on tallentaa tietokoneen näytön näkymä videoksi, josta käyttäjä näkee kuinka tietty toiminto suoritetaan. Tämänkaltaisia nauhoitteita käytetään opettamaan käyttäjälle yksittäisten ohjelman toimintojen käyttöä. Java Pages -työkalun idea on keskittyä opettamaan ohjelmistokehyksen erikoistamista. Käyttöohjeiden yhteydessä käytettävä nauhoitin tallentaisi Fred-työkalun ulkoasun, sekä runsaasti käyttöliittymään liittyviä yksityiskohtia, joilla ei olisi merkitystä ohjelmistokehyksen opiskeluun. Samalla tallenteen tekemisen olisi tapahduttava nopeasti, jotta käyttäjän ei tarvitsisi katsella esimerkiksi ohjelmakoodin kirjoittamista. Valmiissa tallenteessa eri tiedostojen selaaminen omassa tahdissa ei olisi mahdollista ja nauhoitteen jakaminen erillisiin askeliin olisi vaikeaa. 40

48 Työkalun idea olisi tietenkin voitu toteuttaa myös muissa ympäristöissä kuin Fredtyökalussa. Fred-työkalun käyttäjän opastamisessa käyttämä aktiivista keittokirjaa muistuttava lähestymistapa sekä intuitiivisesti toimiva tehtävälista olivat kuitenkin hyviä lähtökohtia Java Pages -työkalun toiminnan pohjaksi. Muissa ympäristöissä nauhoitteen tekijän olisi täytynyt kirjoittaa itse selitys kunkin ohjelman osan merkitykselle, mutta Fredin tapauksessa ympäristö tarjoaa automaattisen ja kattavan dokumentoinnin eri ohjelmaelementeille. Lisäksi tarkoituksena oli alusta pitäen tutkia Fredin laajennusmahdollisuuksia ohjelmistokehyksen dokumentaation parantamiseksi. Java Pages on prototyyppi työkalusta aivan kuten koko Fred ympäristökin, joten sille ei ole asetettu teollisuudessa käytössä olevia tehokkuus- tai luotettavuusvaatimuksia. Sen sijaan se pyrkii tutkimaan taustallaan olevien ideoiden toimivuutta käytännössä. 4.2 Työkalun esittely Java Pages jakautuu kolmeen loogisesti ja toteutuksellisesti erilliseen osaan: nauhoittimeen, palvelimeen ja selaimeen. Nauhoitin on Frediin integroitu laajennus, jonka avulla voidaan tallentaa erikoismistapahtumien sarja erilliseen tiedostoon. Palvelin on Fredistä täysin erillään toimiva ohjelma, joka julkaisee sille annettuihin nauhoitteisiin liittyvät dokumentaatiot verkossa ja tarjoaa nauhoitteiden sisältämät tiedot Java Pages - selaimelle. Selain on normaalissa WWW-selaimessa toimiva appletti, joka tarjoaa yksinkertaisen käyttöliittymän nauhoitteen tarkastelemiseen. Java Pages -työkalun loppukäyttäjä, siis ohjelmistokehyksen käytön opiskelija, näkee vain työkalun selainosan Java Pages -nauhoitin Java Pages -nauhoitin on Frediin integroitu laajennus, joka toteuttaa yksinkertaisen käyttöliittymän nauhoitteiden luomiseen. Nauhoitus seuraa yhteen malliin liittyvien tehtävien toteuttamista. Kuva 4.2 esittää nauhoittimen käyttöliittymän. 41

49 Kuva 4.2. Java Pages -nauhoittimen käyttöliittymä Tallennusta aloitettaessa käyttäjältä pyydetään nimi ja kuvaus generoitavalle nauhoitteelle. Fredissä avoinna olevien tiedostojen sisältö ja tehtävälistan tila tallennetaan nauhoitteen alkutilaksi eli ensimmäiseksi askeleeksi. Jos nauhoitteen nimi on jo käytössä, varmistetaan halutaanko olemassa oleva nauhoite päällekirjoittaa. Nauhoituksen alettua käyttäjä voi vapaasti muokata lähdekoodia ja tehdä Fredin käyttäjälle näyttämiä tehtäviä. Fred siis toimii täsmälleen samalla tavalla kuin tilanteessa, jossa nauhoitus ei ole meneillään. Nauhoituksen tekeminen ei kuitenkaan ole täysin näkymätöntä, vaan käyttäjä voi Fredin normaalien toimintojen lisäksi luoda aina halutessaan nauhoitteeseen uuden askeleen (step). Kuhunkin askeleeseen tallentuu tieto sen aikana tehdyistä muutoksista tiedostoihin sekä tehtävälistan tila. Askeleet voidaan lisäksi nimetä. Luodun nauhoitteen ymmärrettävyys on pitkälti riippuvainen askeljaon onnistumisesta, sillä kussakin askeleessa tulisi olla yhteen asiaan liittyviä muutoksia, jotta nauhoitetta selaamalla olisi helppo saada hyvä kokonaiskuva erikoistamisprosessista. Nauhoitteeseen tallentuu tehtyjen tehtävien kuvaus siinä muodossa, jossa Fred esittää sen käyttäjälle, eli tässä tapauksessa nauhoitteen tekijälle. Koska Fred hyödyntää tilanteeseen mukautuvaa dokumentaatiota, tallenteeseen siirtyy siis automaattisesti asiaan liittyvien, käyttäjän itsensä syöttämien luokkien nimet, jotka ovat käytössä myös tehtävälistassa. 42

50 Nauhoitustapahtuma on milloin tahansa mahdollista lopettaa perumalla nauhoitus tai hyväksymällä luotu nauhoite. Peruminen poistaa levyltä siihen asti tehdyn nauhoitteen, ja käyttäjä voi jatkaa muita toimiaan kuten erikoistamista normaalisti. Mikäli nauhoittaminen päätetään hyväksymiseen, nauhoitin tarkistaa onko sen keräämässä materiaalissa linkkejä paikallisella koneella sijaitseviin dokumentteihin, joita voi sisältyä Fred-ympäristössä näkyviin tehtävien kuvauksiin. Paikalliset dokumentit on pakattava nauhoitteeseen, jotta Java Pages -palvelin osaa julkaista ne verkossa, ja linkin kohde voidaan avata normaalisti Java Pages -selaimessa. Kuva 4.3 esittää käyttöliittymän, jota käytetään dokumentaation liittämisessä nauhoitteeseen. Mikäli nauhoite ei sisällä yhtäkään linkkiä paikalliseen dokumentaatioon, nauhoite on valmis välittömästi kun käyttäjä painaa hyväksy-nappia. Kaikki paikallinen dokumentaatio, johon on linkkejä nauhoitteesta, voitaisiin periaatteessa sisällyttää automaattisesti nauhoitteen tiedostoon. Tämä ei kuitenkaan ole käytännössä hyvä ratkaisu, sillä usein html-muotoinen dokumentaatio sisältää linkkejä muihin htmldokumentteihin. Tällöin jouduttaisiin joko sisällyttämään pelkästään ensimmäisen linkin kohteena toimiva dokumentti mukaan nauhoitteeseen tai sisällytettäisiin nauhoitteeseen kaikki paikalliset dokumentit, joihin on viite jostakin nauhoitteeseen sisällytetyistä dokumenteista. Kuva 4.3. Dokumentaation sisällyttämiseen käytettävä näyttö 43

51 Kumpikaan edellä kuvatuista lähestymistavoista ei toimi yleisessä tapauksessa. Ensimmäinen tapa johtaisi joissain tapauksissa siihen, että dokumentaatiota otettaisiin mukaan liian pieni määrä asian ymmärtämiseksi ja sisällytetyn dokumentin linkit muihin asiaa käsitteleviin dokumentteihin puuttuisivat. Jälkimmäisen lähestymistavan ongelma on taas se, että mukaan saatettaisiin liittää käyttäjän huomaamatta puolivalmista tai salaista dokumentaatiota, joka ei ole tarkoitettu julkaistavaksi verkossa. Usein käyttäjillä on lisäksi esimerkiksi Java SDK:n (Software Development Kit) rajapintakuvaukset omalla tietokoneellaan, joten viittaus tämänkaltaiseen dokumentaatioon aiheuttaisi valtavan suuren turhan tietomäärän sisällyttämisen nauhoitteeseen. Java Pages -työkalun ratkaisu on esittää käyttäjälle lista dokumenteista, joihin on viitteitä. Tällöin käyttäjä voi helposti sisällyttää tarpeelliset tiedostot mukaan nauhoitteeseen. Koska käyttäjä näkee mihin dokumentaatioon nauhoitteesta on viitteitä, hän voi lisäksi liittää suurempiakin dokumentaatiokokonaisuuksia mukaan, jos hän tietää niihin olevan viitteitä sisällytetyistä dokumenteista. Käyttäjä voi halutessaan jättää sisällyttämättä viitatun dokumentin nauhoitteeseen, mutta tällöin siihen kohdistuvat linkit eivät toimi. Nauhoittimen käyttöön liittyviä virhetilanteita ovat esimerkiksi levytilan täyttyminen, jonkin Java Pages -nauhoittimen tarvitseman Fredin laajennuksen poistaminen käytöstä ja Fredin sammuttaminen kesken nauhoituksen. Virhetilanteessa käyttäjälle näytetään virheilmoitus ja siihen mennessä generoitu nauhoite tuhotaan. Kaikkiin erikois- ja virhetilanteisiin varautumista ei ole nähty tarpeellista toteuttaa käyttäjäystävällisimmällä mahdollisella tavalla, sillä nauhoitin on tarkoitettu käytettäväksi mallitilanteissa, joiden on tarkoitus toimia hyvinä käyttöesimerkkeinä erikoistamisesta Java Pages -palvelin Java Pages -nauhoittimella luodut nauhoitteet siirretään Java Pages -palvelimelle, kun ne halutaan ottaa käyttöön Java Pages -selaimessa. Java Pages ei tarjoa mitään automatisoitua tapaa siirtää Fredissä tehty nauhoite tietokoneelle, jossa Java Pages -palvelin on ajossa, vaan tämä jää käyttäjän tehtäväksi. Käytännössä nauhoitetiedosto tulee siis kopioida Fredin nauhoitehakemistosta halutun palvelimen nauhoitehakemistoon. 44

52 Java Pages -palvelin on sekä PC- että Unix-ympäristössä toimiva Java-ohjelma, joka tunnistaa Java Pages -nauhoittimella luodut nauhoitteet. Kun uusi nauhoite havaitaan, sen sisältämä dokumentaatio julkaistaan verkossa ja se lisätään Java Pages -selaimissa näkyvien nauhoitteiden listaan. Vastaavasti palvelin havaitsee automaattisesti, jos nauhoite poistetaan julkaistujen nauhoitteiden hakemistosta. Tällöin se tuhoaa siihen liittyvän julkaistun dokumentaation ja poistaa nauhoitteen Java Pages -selaimissa näkyvien nauhoitteiden listasta. Käytännössä Java Pages -palvelin ja -selain tulee konfiguroida toimimaan yhdessä sekä tietyt palvelimen hakemistot tulee asettaa näkymään verkossa näkyviksi käyttäen WWWpalvelinohjelmistoa (esimerkiksi Apache). Palvelin rekisteröi itsensä käytännössä etäolioksi Java RMI -palvelimelle ja Java Pages -selain käyttää sen tarjoamia palveluita. Tästä lisää alikohdassa Java Pages -palvelin käynnistetään komentoriviltä suoritettavalla käyttöjärjestelmäriippuvaisella käynnistyskäskyllä. Käsky käynnistää ohjelman, joka rekisteröi palvelinolion RMI:n nimipalveluun. Tämän jälkeen palvelua tarvitsevat Java Pages -selaimet löytävät sen tuntemansa nimen perusteella. Mahdollinen palvelimen antama palaute virhetilanteista tallennetaan lokitiedostoihin Java Pages -selain Suurimmalle osalle Java Pages -työkalun käyttäjistä Java Pages -selain on kaikkein näkyvin osa työkalua. Selain tarjoaa helpon tavan perehtyä Java Pages -nauhoittimella tehtyihin nauhoitteisiin. Käyttäjän ei tarvitse välittää taustalla toimivista tekniikoista, vaan hän voi keskittyä ohjelmistokehyksen käytön opettelemiseen tarkastelemalla selaimessa esitettäviä ohjattuja toteutusesimerkkejä. Kuva 4.4 esittää Java Pages -selaimen käyttöliittymän. Selaimen käyttämät värit ym. yksityiskohdat ovat säädettävissä appletin parametreilla, mutta käyttöliittymässä on aina sama toiminnallisuus. Ylhäällä näkyvästä valikosta on ladattavissa ohjattu toteutusesimerkki, jota halutaan tarkastella. Tämän lisäksi valikosta löytyvät ohjelman käyttöohjeet sekä mahdollisuus sulkea tarkasteltavana oleva nauhoite. 45

53 Kuva 4.4. Java Pages -selaimen käyttöliittymä Valikkojen alla on yksinkertainen työkalurivi, jossa on mahdollisuus siirtyä seuraavaan tai edelliseen ohjatun toteutusesimerkin vaiheeseen, mikäli sellainen on olemassa. Siirtyminen nauhoitteen askelien välillä tapahtuu painamalla eteenpäin tai taaksepäin nuolta. Lisäksi rivillä näkyy parhaillaan tarkasteltavana olevan askeleen nimi. Ruudun vasemmassa laidassa näkyy lista ohjelmaelementeistä, jotka on tehty tähän mennessä. Lista on vastaava hierarkkinen tehtävien esitystapa, joka löytyy Fredin käyttöliittymästä tehtävälistan nimellä, mutta Java Pages -selaimessa lista toimii rakennenäkymänä, jossa näkyvät ohjelmaan toteutetut ohjelmaelementit. Listaan on merkitty mustalla nuolella ne ohjelmaelementit, jotka on toteutettu tämän askeleen aikana. Valittuna olevaan ohjelmaelementtiin liittyvä dokumentaatio näytetään ruudun oikeassa ylälaidassa olevassa tekstialueessa. Mikäli dokumentaatioon liittyy linkkejä, niiden kohde 46

54 avataan uuteen selainikkunaan linkkiä painamalla. Jos kyseessä on ollut linkki alunperin paikalliseen dokumentaatioon, jota käyttäjä ei ole jostakin syystä sisällyttänyt nauhoitteeseen, on linkki rikki. Ruudun oikeassa alalaidassa näkyvä alue esittää askeleeseen liittyvät lähdekooditiedostot, kunkin omassa välilehdessään. Välilehdellä voi tarkastella tiedostossa olevaa lähdekoodia, mutta tiedostojen muokkaaminen ei ole mahdollista. Mikäli tiedosto on lisätty projektiin askeleen aikana, sen nimen perässä on merkintä (new), jos sitä puolestaan on muokattu askeleen aikana, sen nimen perässä on merkintä *. Parhaillaan näkyvissä olevan askeleen aikana tehdyt muutokset tiedostoihin on korostettu. Uusien tiedostojen ohjelmakoodiin ei ole merkitty askeleen aikana tapahtuneita muutoksia, sillä muuten uuden tiedoston koko lähdekoodi olisi aina korostettu. Selaimen toiminnasta saa paremman kuvan perehtymällä liitteessä A olevaan laajempaan esimerkkiin, jossa on kuva Java Pages -selaimen näytöstä kussakin ohjatun toteutusesimerkin askeleessa. 4.3 Työkalun toteutus Java Pages -työkalu on kaikilta osiltaan täysin Javalla toteutettu sovellus. Valinta oli luonnollinen, sillä nauhoittimen osalta toteutuskielen tuli olla sama, jolla Fred on toteutettu, jotta integrointi ei olisi vaatinut valtavia ylimääräisiä ponnisteluja. WWWkäyttöliittymää suunniteltaessa Java oli myös selvästi houkuttelevin vaihtoehto, sillä kielestä löytyy hyvä tuki WWW-palveluiden tekoon. Appletit tarjosivat tässä tapauksessa parhaan lähtökohdan toivotun toiminnallisuuden toteuttamiseen. Kun appletit oli valittu käyttöliittymän toteutustavaksi ja niiden toteutuskieli oli Java, myös palvelimen toteuttaminen samalla ohjelmointikielellä oli helppo valinta. Javan käyttäminen palvelimen toteutuskielenä teki palvelimesta samalla käyttöjärjestelmäriippumattoman. Tiedonsiirrossa palvelimen ja appletin välillä päädyttiin käyttämään Javan RMI-mekanismia, joskin toisena vaihtoehtona harkittiin binäärimuotoista tiedonsiirtoa servletin ja appletin välillä suoraa socket-yhteyttä käyttäen. 47

55 Java RMI:hin kuitenkin päädyttiin, sillä se tarjosi helpon tavan jakaa palvelimella oleva, olioiksi mallinnettu tieto appletin käyttöön. Tiedonsiirtoa Java Pages -selaimen ja - palvelimen välillä käsitellään tarkemmin alikohdassa Java Pages -nauhoitteen tallennusmuotona käytetään.rec päätteiseksi nimettyä JARtiedostoa, joka sisältää nauhoitteen tietosisällön xml-muodossa, sekä kaiken nauhoitteeseen liittyvän oheismateriaalin. Nauhoitteen rakennetta käsitellään tarkemmin alikohdassa Ohjelman toteutus on pääosin hyvin suoraviivaista olio-ohjelmoinnin mukaista ongelmanratkaisua. Yksityiskohtana käsitellään integrointirajapintaa, jolla nauhoitin on integroitu Fredin (kehitys)versioon 2.0. Koska Frediä ollaan parhaillaan integroimassa Eclipse-ympäristöön, oli nauhoittimen rajapinta tarpeen suunnitella siten, että sen integrointi muihinkin ohjelmointiympäristöihin on mahdollista. Integrointiin käytettävää rajapintaa käsitellään kohdassa Java Pages -palvelimen ja -selaimen välinen tiedonsiirto Java Pages -palvelimen ja -selaimen välillä tapahtuvaan tiedonsiirtoon käytetään Javan RMI-mekanismia. Ideana on, että Java Pages -palvelin tarjoaa palveluitaan rekisteröimällä palvelunsa Java RMI:n etäolioksi, ja Java Pages -selain voi hakea palvelua sen nimen perusteella. Palvelimen ja selaimen konfiguraatioilla säädetään se, että ne käyttävät samaa nimipalvelinta. Kuva 4.5 esittää RMI:n toimintaidean, jonka varaan tiedonsiirto Java Pages -järjestelmässä pohjautuu. Idea on yksinkertainen, vaikka toteutukseen liittyy paljon yksityiskohtia. Java Pages - palvelin luo palvelinolion ja sitoo sen RMI-rekisteriin tietylle nimelle. Asiakas kuvaa tässä tapauksessa Java Pages -selainta, joka hakee palvelinoliota RMI-rekisteristä tuntemansa nimen perusteella ja pääsee näin käsiksi palvelimeen, jolla asiakkaan tavoittelema olio on olemassa. Tällä tavalla saadun olion rajapinta tarjoaa asiakkaan eli Java Pages -selaimen tarvitsemat palvelut, jolla se saa käsiinsä listan palvelimella olevista nauhoitteista, sekä voi ladata tarvittaessa kunkin nauhoitteen tiedot itselleen. 48

56 WWW-palvelin WWW-palvelin URL URL URL RMI rekisteri RMI RMI Asiakas RMI Palvelinolio Palvelin Kuva 4.5. Java RMI:n toimintaperiaate RMI käyttää tavukoodin siirtämiseen asiakkaan ja palvelimen välillä URL-protokollia, kuten Toiminnan perustana on käyttää tavukoodin jakamiseen jo olemassa olevia WWW-palvelintekniikoita. Keskeisenä ideana on, että tavukoodia siirretään vain tarvittaessa. Tavukoodina voidaan siirtää esimerkiksi etämetodikutsussa parametrina välitettävään olioon liittyvä tavukoodi tapauksessa, jossa toisella kommunikoinnin osapuolella ei ole luokan tavukoodeja [Co01] Java Pages -nauhoitteen rakenne Java Pages -nauhoitteen rakenne on pyritty valitsemaan mahdollisimman selkeäksi ja helposti muutettavaksi. Lisäksi suunnittelussa on otettu huomioon mahdollinen tarve laajentaa ohjelmaa ja erottaa eri ohjelmaversioiden nauhoitteet toisistaan. Nauhoite on käytännössä.rec-pääteinen JAR (Java Archive) tiedosto. Tiedoston sisältö on jaoteltu hakemistoihin, ja kunkin askeleen tiedot on esitetty omana xml-tiedostonaan. Nauhoitteen rakenne on kuvattu liitteessä B, josta löytyy nauhoitteen tarkka tiedosto- ja hakemistorakenne, sekä sisäisten xml-tiedostojen rakenteen kuvaus XML schema - muodossa. Kuva 4.6 esittää UML-notaatiolla tiedot, jotka tallennetaan kustakin askeleesta. Tässä tapauksessa tiedot on esitetty juuri samalla tavalla kirjoitettuna kuin Liite B:ssä olevassa skeematiedostossa (schema) on esitetty, eikä kirjoitusasua ole muutettu vastaamaan normaalisti käytössä olevaa ohjelmoinnin nimeämiskonventiota esimerkiksi alkukirjainten osalta. 49

57 step tasktree node number nodeid name 1 * nodename description step_changer typeimage stateimage parentnodeid * file change new_file filename * startidx endidx path newtext id Kuva 4.6. Kustakin nauhoitteen askeleesta tallennettava tietosisältö Nauhoitteeseen tallentuu käytännössä askeleen lopussa voimassaoleva tehtävälistan tila ja tietoa nauhoitukseen liittyvistä tiedostoista. Tehtävälistan tapauksessa tallennetaan kaikkien tehtävälistaan liittyvien elementtien tiedot. Puurakenne puretaan yksitasoiseksi rakenteeksi, jossa kukin elementti tuntee oman vanhempansa. Kustakin tehtävälistan elementistä tallentuu nimi, kuvaus, tieto siitä onko elementti ilmestynyt listaan tämän askeleen aikana, elementtiin liittyvät kuvat sekä elementille automaattisesti generoitu tunniste. Tiedostoista tallennetaan nimi, polku, tieto siitä onko kyseessä uusi tiedosto ja tiedostoon tehdyt muutokset. Muutokset tallennetaan omana rakenteenaan, jossa ilmoitetaan muutoksen alkamispaikka ja loppumispaikka tiedostossa sekä alku- ja loppupisteen välille asetettu uusi teksti. Tällä rakenteella voidaan tallentaa helposti tekstin lisäämiseen, muokkaamiseen ja poistoon liittyvät muutokset. Käytännössä peräkkäiset muutokset kerätään yhdeksi suuremmaksi muutokseksi, jotta tiedostoista ei tulisi suuria pelkästään sen vuoksi, että ne sisältävät yhden lauseen kirjoittamisen merkki kerrallaan tehtävinä lisäyksinä. UML-kaavion step-niminen luokka vastaa XML-tiedostossa juurielementtiä. Muuttujien tyypit on jätetty pois kuvasta. Käytännössä tyypit vastaavat XML schema -määrittelyn 50

58 yleisesti käytettyjä tyyppejä kuten string. Lisäksi liitteen B skeema tarkentaa joitakin tyyppejä esittelemällä positiivisen kokonaisluvun tyypin ja ei-tyhjän merkkijonon, joilla voidaan varmistua, että talletettavat arvot ovat varmasti sallitussa arvossaan. Java Pages -palvelin pystyy tunnistamaan omat.rec-päätteiset tiedostonsa muiden ohjelmien mahdollisesti samaa päätettä käyttävistä tiedostoista, jotka olisivat sattumalta tehty vastaavalla rakenteella, sillä JAR-tiedostoon on liitetty Manifest-osaan nauhoitteen nimi ja versionumero. Mikäli palvelimelle annettava.rec pääteinen tiedosto ei ole käsiteltävissä normaalin JAR-tiedoston tavoin, se tulkitaan epäkelvoksi tiedostoksi. Jos tiedoston käsittely taas onnistuu JAR-tiedoston tavoin, siitä tarkistetaan ensimmäisenä nauhoitteen nimi ja versionumero. Jos toista tai kumpaakaan näistä tiedoista ei löydy, tiedosto hylätään yhteensopimattomana Java Pages -nauhoittimen integrointirajapinta Fredin mallikone on suunniteltu omaksi komponentikseen, joten sen integrointi uuteen ympäristöön on mahdollista. Täten myös Java Pages ja muut Frediin tehdyt laajennukset olisi tarpeen saada integroitua uuteen ohjelmointiympäristöön. Tämän mahdollistamiseksi Java Pages -nauhoittimeen on suunniteltu integrointirajapinta, jonka on tarkoitus olla riittävän joustava nauhoittimen liittämiseksi uusiin ohjelmistoympäristöihin. Rajapinnan joustavuus on ollut käytännössä riittävä vastaamaan Fred 2.0 kehityksen aikana tapahtuneisiin muutoksiin, sillä Java Pages on ollut integroituna eri kehitysversioihin onnistuneesti. Kuva 4.7 esittää Java Pages -nauhoittimen integrointirajapintaan liittyvät luokat suhteineen. Kuvasta on jätetty pois selkeyden vuoksi metodien parametrit ja paluuarvot. Kuvan metodeista on lihavoitu ne, jotka vaativat tyypillisesti ylimäärittelyn integroinnin yhteydessä ja ne, jotka ovat abstrakteja ja täytyy aina ylimääritellä. Lihavoimattomat metodit ovat apumetodeja, joita erikoistus yleensä käyttää, tai metodeita, joiden oletustoteutus on tyypillisesti riittävä. 51

59 RecorderInitializer {abstract} TaskTreeNode «interface» DirInfoProvider {abstract} getdefaultdocdir() getschemafilepath() getrecordsdir() «creates» getfilerecorder() gettasktreerecorder() getstepchangenotifier() getdirinfoprovider() getfilehandler() «creates» «creates» «creates» «creates» gettaskname() getoriginalpicture() getstatepicture() getdescription() getchildnodes() equals() FileHandler FileRecorder {abstract} StepChangeNotifier {abstract} TaskTreeRecorder {abstract} creteinstance() openfileforinput() openfileforoutput() deletefile() createfile() createdirectory() createdirectories() clean() endrecording() getfile() getfiles() initialize() startrecording() notifychangeinfile() doclean() endrecording() initialize() startrecording() notifystepchange() clean() endrecording() getnewestnodes() gettasktreerootnode() initialize() startrecording() haschanges() nochanges() notifychangeintree() Kuva 4.7. Java Pages -nauhoittimen integrointirajapinta RecorderInitializer on abstrakti luokka, josta tulee periyttää toteutus luokalle, joka vastaa kyseisessä integraatiossa toimivien, informaation käsittelyyn käytettävien, olioiden luomisesta. Käytännössä informaatiota käsittelevät luokat ovat luokista FileRecorder, StepChangeNotifier, TaskTreeRecorder ja DirInfoProvider -luokista periytetyt integraatiokohtaiset luokat. Tämän lisäksi voidaan tarpeen vaatiessa myös ylimääritellä luokan FileHandler toteutus. Integrointi täydennetään toteuttamalla ympäristökohtainen toteutus luokasta TaskTreeNode. FileRecorder-luokasta periytetään toteutus, jolla saadaan auki olevien tiedostojen tiedot, jotka liittyvät meneillään olevaan nauhoitukseen. StepChangeNotifier-luokasta periytetään toteutus, joka havaitsee askeleen vaihdon. Askeleen vaihdon havaitseminen voidaan jossakin tapauksissa automatisoida, tai luokka voi yksinkertaisesti seurata käyttöliittymään toteutettavaa nappia, jota käytetään askeleen vaihtamiseen. TaskTreeRecorder-luokasta periytetään tehtävälistan tilaa seuraava luokka. Sen tehtävänä on tarjota pääsy tehtävälistan kullakin hetkellä voimassa olevaan tilaan ja pitää tallessa tieto siitä, mitä muutoksia listaan on tehty askeleen aikana. TaskTreeNode-rajapinta takaa sen, että eri 52

60 ympäristöissä yhtä tehtävälistan tehtävää voidaan käsitellä saman rajapinnan läpi. Integroinnissa toteutetaan siis adapteri, joka toteuttaa tämän rajapinnan käyttämällä ympäristökohtaiseen tehtävälistaan kuuluvan tehtävää kuvaavan olion metodeja. DirInfoProvider on abstrakti luokka, josta periytetyssä luokassa toteutetaan ympäristöön liittyvien hakemistorakennetietojen palauttaminen nauhoittimelle. FileHandler on luokka, jolla on perustoteutus tiedostojen ja hakemistojen käsittelyyn. Se käyttää suoraan Javan tiedostonkäsittelyrajapintaa toimintojen toteuttamiseen. Sen periyttäminen on tarpeen, jos integroinnin kohteena oleva ohjelmointiympäristö tarvitsee esimerkiksi tiedon kaikista tiedostoihin kohdistuvista operaatioista tai tarjoaa oman rajapinnan tiedostojen käsittelyyn, jotta sen sisäinen tiedostojen tila pysyisi konsistenttina. Tämä on tilanne esimerkiksi Fredin kohdalla. Kokonaisuutena integrointirajapinta vaikuttaa nopeasti katsottuna melko monimutkaiselta, mutta käytännössä se on suhteellisen suoraviivaisesti toteutettavissa. Lisää joustavuutta tuo mahdollisuus ylimääritellä kuvissa lihavoimatta olevia metodeja, jolloin käyttäjän vastuulle jää tehtäviä, joista integrointirajapinta huolehtisi muuten itsenäisesti. 53

61 5 Jatkokehitys Java Pages on prototyyppi työkalusta, jolle nähtiin tarvetta ohjelmistokehyksien dokumentoinnin helpottamiseksi. Siitä ei ole pyritty tekemään täydellistä kaupallisen tuotteen tasolle yltävää järjestelmää, vaan tarkoituksena oli paremminkin tutkia työkalun edustamien ideoiden toimivuutta käytännössä. Tässä luvussa käsitellään työkalusta saatuja kokemuksia ja käytön aikana esiin nousseita jatkokehitysideoita. Jatkokehitysideat perustuvat pitkälti havaintoihin, joita on tehty työkalua testattaessa sekä palautteeseen, jota työkalun esittelyssä NWPER 02 (Nordic Workshop on Programming and Software Development Environment Research 2002) ja FIDJI 02 (International Workshop on Scientific Engineering of Distributed Java Applications) -foorumeilla saatiin. 5.1 Kokemuksia järjestelmän toiminnasta Järjestelmän käyttökokemukset on saatu ohjelman testaamisen aikana ja ovat pääosin positiivisia. Järjestelmän toimintaa on tutkittu suhteellisen vähän, sillä nauhoitinta on tehty Fred versioon 2.0, joka on ollut kehitteillä samaan aikaan Java Pages -järjestelmän kanssa. Työkalun integroiminen muuttuvaan järjestelmään on ollut vaikeaa. Samalla on kuitenkin tullut varmistuttua siitä, että alikohdassa kuvattu integrointirajapinta on kyennyt taipumaan muuttuviin järjestelmän vaatimuksiin. Fredin kaavaimien pohjalta luotu dokumentaatio on koettu erittäin hyödylliseksi ohjelmanosien dokumentointitavaksi, sillä nauhoittimen käyttäminen on helppoa, kun ohjatun toteutusesimerkin tekijän ei tarvitse kirjoittaa käsin selitystä kunkin ohjelmaelementin tarkoitukselle. Samalla Frediin malleihin kirjoitettujen kuvausten merkitys kasvaa, joten niiden oikeellisuuden varmistaminen esimerkiksi mallin muuttuessa on entistäkin tärkeämpää. 54

62 Fredissä yhdellä mallilla pyritään usein kuvaamaan yhden erikoistamiskohdan vaatimukset ohjelmakoodille. Tämä lähestymistapa on todettu toimivaksi, jotta mallit saadaan pidettyä ymmärrettävän kokoisina. Lisäksi yhden erikoistamiskohdan kuvaamiseksi voidaan tehdä useita malleja, joista käyttäjä voi valita käyttöönsä parhaiten sopivan. Java Pages -työkalun kannalta ongelmaksi voi tällöin nousta se, että yksi malli kuvaa vain hyvin pientä osaa ohjelmistokehyksen erikoistamisrajapinnasta. Näin ollen pelkkien Java Pages -nauhoitteiden selaaminen ei anna käyttäjälle kuvaa koko ohjelmistokehyksen erikoistamisprosessista, ja mahdollisen erikoistamiskohtien välisten riippuvuuksien kuvaaminen täytyy tehdä työkalun ulkopuolella. Appletti-pohjaisen käyttöliittymän valinta on osoittautunut toimivaksi ratkaisuksi, sillä täysin käyttöjärjestelmäriippumaton ja helposti verkosta käytettävissä oleva järjestelmä on vaivaton loppukäyttäjälle, jonka ei tarvitse asentaa omalle koneelleen mitään ylimääräisiä työkaluja. Sen sijaan Java RMI-tekniikan käyttöön on liittynyt ominaisuuksia, jotka tulevat esiin tietyissä marginaalisissa käyttötilanteissa. Verkkopohjaisen perustekniikan käyttö aiheuttaa ongelmia, jos järjestelmä on asennettuna yhdelle tietokoneelle, jossa ei ole verkkokorttia tai verkkoyhteyksiä ja näin ollen koneella ei ole omaa ip-osoitetta. Ongelma on kuitenkin merkitykseltään pieni, sillä ohjelma on alusta lähtien suunniteltu toimimaan verkossa ja häiritsee ainoastaan ohjelman esittelyä demotilanteissa, joissa kaikki ohjelman osat on asennettu samalle tietokoneelle eikä verkkoyhteyttä ole saatavilla. On ollut rohkaisevaa havaita, että työkalua kohtaan on osoitettu runsaasti mielenkiintoa. Saamamme palautteen perusteella tämänkaltaisen työkalun kehittäminen nähdään tärkeänä, sillä laajojen järjestelmien dokumentoimiseen kaivataan lisää apuvälineitä. Arvokkaana ominaisuutena Java Pages -työkalussa nähdään juuri sen mahdollisuus käyttää Fredin kaavaimista luotua dokumentaatiota, joka mahdollistaa ajantasaisen dokumentaation luomisen automaattisesti joka kerta kun erikoistaminen tehdään. 5.2 Jatkokehitysideoita Java Pages kehitettiin testaamaan Fredin kaavainten pohjalta luoman dokumentaation sopivuutta ohjelmistokehyksen erikoistamisrajapinnan dokumentointiin. Ensimmäinen 55

63 ohjelman versio mahdollisti askeleen nimen syöttämisen, mutta pian huomattiin, että nauhoitteesta olisi tärkeä voida syöttää myös nauhoitteen kuvaus. Käyttäjä valitsi kuvauksen perusteella nauhoitteet, jotka hän katsoi tutustumisen arvoiseksi. Tämä ominaisuus on lisätty Java Pages -työkalun uusimpaan versioon. Samaan ongelmaan liittyen nauhoitteen tekijä voisi haluta joskus kirjoittaa Fredin luomien ohjelmaelementtien kuvauksien ja askeleen nimen lisäksi myös tarkempaa kuvausta nauhoitteen yhden askeleen merkityksestä. Tätä varten nauhoitteen askeleen vaihdon yhteydessä käyttäjältä voitaisiin pyytää askeleen nimen lisäksi myös vapaaehtoinen kuvaus askeleesta, ja tämä kuvaus voitaisiin esittää Java Pages -appletissa omassa tekstialueessaan. Näin nauhoitteen tekijä voisi painottaa haluamiaan asioita nauhoitteen kustakin askeleesta käyttäjälle. Kussakin askeleessa Java Pages -selain näyttää askeleen aikana luodut uudet ohjelmaelementit mustalla nuolella. Olisi kuitenkin hyvä, jos myös muuttuneet ohjelmaelementit merkittäisiin käyttäen esimerkiksi harmaata nuolta. Tällöin käyttäjän olisi helpompi löytää muuttuneet ohjelmaelementit suuremman esimerkin tapauksessa. Käytettävyyttä parantaisi myös, jos kunkin ohjelmaelementin valitseminen avaisi myös siihen liittyvän ohjelmakoodin näkyviin pelkän ohjelmaelementin kuvauksen näyttämisen sijaan. Tällä hetkellä Java Pages -selaimen käyttöliittymä ei näytä parhaillaan tutkittavana olevan askeleen numeroa eikä nauhoitteeseen kuuluvien askelien lukumäärää. Näiden tietojen lisääminen käyttöliittymään selkeyttäisi työkalun käyttöä huomattavasti, sillä käyttäjällä olisi jonkinlainen kuva siitä, kuinka pitkää nauhoitetta hän on tutkimassa ja missä vaiheessa nauhoitetta hän on parhaillaan menossa. Askelien muokkaaminen ei tällä hetkellä ole mahdollista seuraavaan askeleeseen siirtymisen tai nauhoitteen hyväksymisen jälkeen. Käytettävyyttä parantaisi, jos nauhoitteen tekemisen aikana tai ennen lopullista hyväksymistä kutakin askelta voisi tarkastella, askelien nimiä muokata ja askelia yhdistellä. Tällä tavalla käyttäjä voisi jakaa tehtyä nauhoitetta uudelleen osiin, jotka ohjelmistokehyksen käyttöä opeteltaessa olisi 56

64 helpompi omaksua. Ideaa voidaan myös laajentaa kokonaiseksi nauhoite-editoriksi, jolla voitaisiin suorittaa olemassa olevien nauhoitteiden päivittämistä, askelten yhdistämistä, kuvausten muokkaamista jne. Fredillä tehdyn mallin muuttaminen johtaa kaikkien siitä tehtyjen nauhoitteiden uudelleen tekemiseen, sillä nauhoitetta ei ole mahdollista päivittää vastaamaan uutta mallia. Usein vanhan nauhoitteen automaattinen korjaaminen ei ole mahdollista, sillä uuden mallin myötä erikoistamiseen saattaa liittyä esimerkiksi uusien luokkien luomista erikoistamisprosessin aikana tai muita vastaavia toimenpiteitä, joiden automaattinen lisääminen nauhoitteeseen ei ole mahdollista. Tilanteissa, joissa on korjattu esimerkiksi ohjelmaelementtien merkityksien selityksiä, automaattinen päivittäminen olisi kuitenkin käytännössä mahdollista toteuttaa ja helpottaisi nauhoitteiden ylläpitoa. Java Pages -nauhoittimella tehty nauhoite tallennetaan paikallisesti samalle tietokoneelle, jossa Java Pages -nauhoitin on käytössä. Tapauksessa, jossa Java Pages -palvelin ei toimi samalla tietokoneella, käyttäjän on siirrettävä nauhoite jollakin tavalla palvelinkoneelle. Tätä tarkoitusta varten voitaisiin kehittää työkalu, jossa käyttäjä saisi siirrettyä nauhoitteen palvelimelle tuntemalla yksinkertaisesti palvelinkoneen nimen tai ip-osoitteen. Yhteen erikoistamiskohtaan voidaan soveltaa useita Fredillä tehtyjä malleja, mutta Java Pages -työkalun nykyinen versio ei kykene tallentamaan kuin yhteen malliin liittyviä tehtäviä kerrallaan. Jos useampaa mallia erikoistetaan nauhoittamisen aikana, tallentuvat kaikki lähdekoodeihin tehtävät muutokset, mutta kokonaisuuden hahmottuminen vaikeutuu, koska vain nauhoitettavaan malliin liittyvien ohjelmaelementtien merkitys tallentuu nauhoitteeseen. Käytännössä siis rakennenäkymässä näkyvät vain ne ohjelmaelementit, jotka kuuluvat nauhoituksen kohteena olevaan malliin. Jatkossa työkaluun voitaisiin mahdollistaa useamman eri mallin erikoistamisen seuraaminen, jolloin tuloksena syntyisi täydellisempi erikoistamisesimerkki ohjelmistokehyksen erikoistamisesta. Koska yksi malli kuvaa usein yhden erikoistamiskohdan vaatimuksia, tällöin olisi mahdollista myös tallentaa samaan nauhoitteeseen useamman kuin yhden erikoistamiskohdan erikoistaminen samalla kertaa. Tällä tavalla voitaisiin joissakin tilanteissa päästä täydellisempään erikoistamisrajapinnan kuvaamiseen. Täytyy kuitenkin 57

65 muistaa, että tällöin myös nauhoitteiden koko ja kompleksisuus kasvaisi, joten on syytä harkita onko tämä lähestymistapa tarpeellinen jatkossakaan. Teknisessä toteutuksessa voitaisiin tehostaa tehtävälistan tallentamista. Tällä hetkellä kustakin askeleesta tallennetaan nauhoitteeseen koko tehtävälistan sisältö, vaikka pelkkien muutoksien tallentaminen riittäisi. Kyseessä ei ole niin vakava nauhoitteiden tiedostokokoa kasvattava tekijä kuin miltä alkuvaiheessa voi vaikuttaa, sillä nauhoitteet pakataan JAR-tiedostomuodossa, ja nykyaikaiset pakkausalgoritmit pakkaavat toistuvat tekstit erittäin tehokkaasti. 58

66 6 Yhteenveto Ohjelmistokehityksen tuottavuuden nostaminen ohjelmakoodin uudelleenkäytön avulla on lisännyt tuotelinja-arkkitehtuurien ja ohjelmistokehyksien suosiota. Teollisuudessa käytössä olevien työkalujen antama tuki niiden käyttämiseen on kuitenkin vielä puutteellista. Fred on prototyyppi työkalusta, jonka avulla voidaan ottaa huomioon monimutkaisempia ohjelmaelementtien välisiä riippuvuuksia kuin mihin ohjelmointikielet antavat tällä hetkellä tuen ja valvoa käytettäväksi valitun arkkitehtuurin noudattamista ohjelmassa. Ohjelmistokehyksien käytön opetteleminen on haaste jokaiselle ohjelmoijalle, sillä ohjelmistokehys on tyypillisesti monimutkainen kokonaisuus, joka erikoistetaan ajettavaksi ohjelmaksi täydentämällä kehyksen erikoistamisrajapinta sovelluskohtaisella ohjelmakoodilla. Java Pages on työkalu, joka mahdollistaa ohjattujen toteutusesimerkkien luomisen Fred-ympäristössä normaalin kehyksen erikoistamisprosessin ohessa. Ohjattujen toteutusesimerkkien luominen tapahtuu normaalin Fredin käytön yhteydessä suorittamalla esimerkkitapaukseksi kelpaava kehyksen erikoistaminen. Ohjatut toteutusesimerkit voidaan julkaista verkossa, ja Java Pages -selaimen avulla ohjelmistokehyksen käytön opiskelija voi selata niitä omassa tahdissaan. Nauhoitteissa esitetään selkeästi kunkin ohjelmaelementin merkitys. Käymällä askelittain läpi erikoistamisprosessin kulkua käyttäjä ymmärtää toteutusyksityiskohtien merkityksen kokonaisuudelle. Java Pages -selain toimii normaalissa WWW-selaimessa, joten ohjelmistokehyksen käyttöä opetellakseen käyttäjän ei tarvitse asentaa tietokoneelleen mitään uusia ohjelmistoja. Java Pages -työkaluun kohdistunut mielenkiinto osoittaa, että kehittyneille dokumentointivälineille on tarvetta ohjelmistokehyksien yhteydessä. Tässä diplomityössä esitelty dokumentointityövälineen versio on osoittanut, että työvälineen taustalla olevat ideat ovat toimivia. Lukuisista jatkokehitysideoista voi kuitenkin päätellä, että dokumentointityökalun jatkokehitys on yhä tarpeen. 59

67 Lähdeluettelo [Al79] Alexander, C. The Timeless Way of Building. New York: Oxford University Press, s. [Al77] Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fiksdahl- King, I., Angel, S. A Pattern Language. New York: Oxford University Press, s. [An00] Annala, J. Laatujohtaminen. Tampere: Tampereen teknillinen korkeakoulu, Teollisuustalouden laitos, Luentomoniste. 106 s. [Bi79] Birtwistle, G.M. A System for Discrete Event Modelling on Simula. Lontoo: Macmillan Press, [Bo00] Bosch, J. Design and Use of Software architectures: Adopting and evolving a product line approach. Boston: Addison-Wesley, s. [Ca90] Carrol, J.M. The Nurnberg Funnel: Designing Minimalist Instruction for Practical Computer Skill. Cambridge: MIT Press, s. [Co01] Coulouris, G., Dollimore, J., Kindberg, T. Distributed systems, Concepts and Design. Harlow: Pearson Education Ltd, s. [De98] Demeyer, S. Analysis of Overridden Methods to Infer Hot Spots. 12th European Conference on Object-Oriented Programming (ECOOP 98) Workshop on Mobility and Replication, Lecture Notes in Computer Science 1543, Springer-Verlag, Berlin Heidelberg. Heinäkuu s [En88] Engeström, Y. Perustietoa opetuksesta. Helsinki: Valtiovarainministeriö ja Valtion painatuskeskus, s. [Ga95] Gamma, E., Helm, R., Johnson, R., Vlissides J. Design Patterns: Elements of Reusable Object-Oriented Software. Reading: Addison- Wesley, s. [Ga01] Gamma, E., Helm, R., Johnson, R., Vlissides J. Olio-ohjelmointi suunnittelumallit. Edita: IT Press, s. [Go84] Goldberg, A. Smalltalk-80: The Interactive Programming Environment. Reading: Addison-Wesley, s. 60

68 [Go90] [Ha94] [Ha00] [Ha01a] [Ha01b] [Ha02a] [HaMä98] [Ha01c] [Ha02b] Gossain, S. Object-Oriented Development and Reuse. Väitöskirja. University of Essex, Haapasalo, L. Oppiminen, tieto & ongelmanratkaisu. Jyväskylä: MEDUSA-Software, s. Hakala, M. Task-Based Tool Support for Framework Specialization. Tampereen teknillinen korkeakoulu, Ohjelmistotekniikan laitos, Raportti 21. s Hakala, M., Hautamäki, J., Koskimies, K., Paakki, J., Viljamaa, A., Viljamaa, J. Annotating Reusable Software Architectures with Specialization Patterns. Proc. Working IEEE/IFIP Conference on Software Architecture (WICSA 01), IEEE Computer Society, Los Alamitos. Elokuu s Hakala, M., Hautamäki, J., Koskimies, K., Paakki, J., Viljamaa, A., Viljamaa, J. Generating application development environments for Java frameworks. 3 rd International Conference on Generative and Component- Based Software Engineering (GCSE 01), Lecture Notes in Computer Science 2186, Springer-Verlag, Berlin Heidelberg. Syyskuu s Hakala, M., Hautamäki, J., Koskimies, K., Savolainen, P. Generating Pattern-Based Documentation for Application Frameworks. Proc. Workshop on scientific engineering of Distributed Java applications (FIDJI 02), Institute Superieur de Technologie, Luxemburg. Marraskuu s Haikala, I., Märijärvi, J. Ohjelmistotuotanto. Helsinki: Suomen Atkkustannus Oy, s. Harsu, M. A Survey of Product-Line Architectures. Tampere: Tampereen teknillinen korkeakoulu, Ohjelmistotekniikan laitos, Raportti s. Hautamäki, J. Task-Driven Framework Specialization - Goal-Oriented Approach. Lisensiaattityö. Tampereen yliopisto, Tietojenkäsittelytieteiden laitos, s. 61

69 [Jo92] Johnson, R.E. Documenting Frameworks Using Patterns. Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSA 92), SIGPLAN Notices, 27(10), ACM Press, New York. Lokakuu s [JoFo88] Johnson, R.E., Foote, B. Designing Reusable Classes. Journal of Object- Oriented Programming, 1(2), June/July s [Ko01] Koskimies, K. Ohjelmistoarkkitehtuurit. Tampere: Tampereen teknillinen korkeakoulu, Ohjelmistotekniikan laitos, Luentomoniste. 255 s. [Ko00] Koskimies, K. Oliokirja. Helsinki: Suomen Atk-kustannus Oy, s. [KrPo88] Krasner, G.E., Pope, S.T. A Cookbook for Using the Model-View- Controller User Interface Paradigm in Smalltalk-80. Journal of Object- Oriented Programming, 1(3), August-September s [Ku99] Kuusela, J. Architectural Evolution. Proc. TC2 First Working IFIP Conference on Software Architecture (WICSA1), Kluwer Academic, Boston. Helmikuu s [LaPu91] Lalonde, W.R., Pugh, J.R. Inside Smalltalk (Volume 2). Eaglewood Cliffs: Prentice-Hall, s. [LoLo91] Lonka, K., Lonka, I. Aktivoiva opetus: käsikirja aikuisten ja nuorten opettajille. Helsinki: Kirjayhtymä, s. [Me86] Meyrowitz, N. Intermedia: The Architecture and Construction of an Object-Oriented Hypermedia System and Application Framework. Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA 86), SIGPLAN Notices, 21(11), ACM Press, New York. Lokakuu s [No01] Northrop, L. A Framework for Software Product Line Practice Version 3.0. Carnegie-Mellon University, Software Engineering Institute, Luettavissa: Selattu 11/2002. [Pr95a] Pree, W. Design Patterns for Object Oriented Software Development. Reading: Addison-Wesley, s. 62

70 [Pr95b] [RiJo00] [Ru91] [Sc95] [Sp96] [Ve02] [Vi01] [Vi02] [Øs99] [Øs00] Pree, W., Promberger, G., Schappert, A., Sommerlad P. Active Guidance of Framework Development. Software-Concepts and Tools, 16(3), s Rintala, M., Jokinen, J. Olioiden ohjelmointi C++:lla. Helsinki: Suomen Atk-kustannus Oy, s. Russo, V.F. An Object-Oriented Operating System. Väitöskirja. University of Illinois at Urbana-Champaign, s. Schmid, H.A. Creating the Architecture of a Manufacturing Framework by Design Patterns. Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA 95), SIGPLAN Notices, 30(10), ACM Press, New York. Lokakuu s Sparks, S., Benner, K., Faris, C. Managing Object-Oriented Framework Reuse. IEEE Computer, 29(9), s Vestdam, T. Generating Consistent Program Tutorials. Proc. Nordic Workshop on Software Development Tools and Techniques (NWPER 02), IT University of Copenhagen, Kööpenhamina. Elokuu s Viljamaa, A. Pattern-Based Framework Annotation and Adaptation A Systematic Approach. Lisensiaattityö. Helsingin yliopisto, Tietojenkäsittelytieteen laitos, s. Viljamaa, J. Automatic Extraction of Framework Specialization Patterns. Lisensiaattityö. Helsingin yliopisto, Tietojenkäsittelytieteen laitos, s. Østerbye, K. Minimalist Documentation of Frameworks. Luettavissa: Selattu 11/2002. Østerbye, K., Lehrmann, M., Sandvad, E., Bjerring, C., Kammeyer, O., Skov, S.H., Hansen, F.O., Hansen, F. Documentation of Object-Oriented Systems and Frameworks, Tanska: Centre for Object Technology, COT/2-42-V s. 63

71 Viitatut URL-osoitteet [JavaDoc] [BumbleBee] [George] [DOC] [Doxygen] [HappyDoc] [Eclipse] [JhotDraw] [Rational Rose] [Rational SoDA] 64

72 Liitteet LIITE 1 Esimerkki Java Pages -nauhoitteen selaamisesta Java Pages -selaimessa LIITE 2 Java Pages -nauhoitteen rakenne 65

73 Liite 1 Tämä liite kuvaa Java Pages -selaimen käyttöä tilanteessa, jossa käyttäjä opiskelee kannettaviin, patterikäyttöisiin ja verkkoon kytkettyihin laitteisiin tarkoitetun MIDP (mobile information device profile) -sovelluksen käyttöliittymän tekemistä. Liite esittää kuvina näkymiä, jotka opiskelija näkee Java Pages -selaimessa. Ensimmäisessä askeleessa käyttäjä näkee perustilan nauhoitteen alusta. Näkymä on esitetty kuvassa L1.1. Tässä tapauksessa alkutilaan ei liity yhtään tiedostoa eikä tehtyjä tehtäviä, minkä takia rakennenäkymä on tyhjä lukuun ottamatta näkymän juurena toimivaa nauhoitteen kuvausta. Myös tiedostojen esitysalue ikkunan oikeassa alareunassa on tyhjä. Nauhoitteen kuvaus näkyy ikkunan oikeassa reunassa olevassa ylemmässä tekstialueessa ja sisältää linkin Sun Microsystemsin sivulle, josta aiheesta voisi lukea lisää. Kuva L1.1. MIDlet esimerkin askel 1 66

74 Kuva L1.2. MIDlet esimerkin askel 2 Askeleessa 2 on luotu uusi luokka. Askel on esitetty kuvassa L1.2. Askeleen otsikko näkyy työkalurivillä askeltamiseen käytettävien eteenpäin ja taaksepäin nuolten vieressä. Vasemmassa reunassa olevassa rakennenäkymässä on merkitty askeleen aikana tehdyt muutokset mustalla nuolella. Rakennepuussa on valittuna luokkaelementti, joka kuvaa askeleessa toteutettua luokkaa ja siihen liittyvä kuvaus näkyy oikeassa yläreunassa olevassa tekstialueessa kuvaten luokan merkityksen ohjelmassa. Tiedostonäkymään on ilmestynyt yksi uusi tiedosto, jossa näkyy askeleeseen liittyvä ohjelmakoodi. Koska tiedosto on lisätty askeleen aikana, sen nimen perässä on merkintä (new). 67

75 Kuva L1.3. MIDlet esimerkin askel 3 Askeleessa 3 on toteutettu kolme uutta ohjelmaelementtiä rakennepuuhun. Nämä ovat olleet Fredissä kolme erillistä tehtävää, joilla on luotu askeleessa 2 tehtyyn luokkaan 3 metodia. Kuva L1.3 esittää tilannetta. Kaikki askeleen aikana tehdyt ohjelmaelementit näkyvät mustalla nuolella merkittynä rakennenäkymässä, ja valitsemalla minkä tahansa rakennenäkymän ohjelmaelementin saa selityksen sen merkityksestä ohjelmalle ikkunan oikeassa ylänurkassa olevaan tekstialueeseen. Lähdekooditiedostossa näkyy askeleen aikana tehdyt lisäykset korostettuna. Koska tiedostoon on tehty muutoksia, sen nimen perässä on tähti. Tällä tavalla käyttäjä näkee helposti mihin tiedostoihin on tehty muutoksia ja vertaamalla korostettuja muutosalueita rakennenäkymän ohjelmaelementtien kuvauksiin on helppo ymmärtää kunkin ohjelmaelementin merkitys. 68

76 Kuva L1.4. MIDlet esimerkin askel 4 Askeleessa 4 on toteutettu toinen luokka sovellukseen. Kuva L1.4 kuvaa tätä tilannetta. Valitun ohjelmaelementin kuvaus näkyy jälleen ikkunan oikeassa yläreunassa olevassa tekstialueessa. Huomaa, että ohjelmaelementin kuvauksessa käytetään termejä, jotka liittyvät sovelluksen terminologiaan: kuvaus puhuu luokista MyCanvas ja MyMidlet, jotka ovat olleet esimerkintekijän valitsemia nimiä, ja johon Fredin dokumentaatio on automaattisesti mukautunut. Kun Java Pages -nauhoitinta on käytetty nauhoittamaan erikoistamisesimerkki, se on tällä tavalla saanut hyödynnettyä Fredin aktiivisen keittokirjan tavoin toimivaa käyttötilanteen terminologiaan mukautuvaa ohjeiden generointia. Sovellukseen liittyy nyt kaksi tiedostoa ja ne näkyvät oikeassa alareunassa omilla välilehdillään. Käyttäjä voi valita tarkasteltavan lähdekooditiedoston yksinkertaisesti valitsemalla haluamansa välilehden. 69

77 Kuva L1.5. MIDlet esimerkin askel 5 Askeleessa 5 on toteutettu luokan MyMIDlet jäsenmuuttujan ja rakentajan toteutus. Rakentajassa alustetaan lisäksi jäsenmuuttuja oikeaan alkuarvoonsa. Kuva L1.5 kuvaa tätä tilannetta. Askeleen otsikko sekä rakentajaan liittyvä kuvaus (näkyy ikkunan oikeassa yläreunassa olevassa tekstialueessa) selittävät käyttäjälle lähdekooditiedostoihin tehtyjä muutoksia, jotka näkyvät korostettuna ikkunan oikean alareunan tiedostonäkymässä. Tässä askeleessa näkyy erityisen hyvin se, miten kaksi Fredissä erillistä tehtävää voivat olla yhtenäinen kokonaisuus, jonka takia ne kannattaa kuvata yhdessä askeleessa tehtäessä nauhoitetta. On tietenkin nauhoitteen tekijän taidoista kiinni, kuinka hyvin hän onnistuu taltioimaan kuhunkin askeleeseen yhtenäisiä kokonaisuuksia. 70

78 Kuva L1.6. MIDlet esimerkin askel 6 Askelessa 6 MyCanvas luokalle on toteutettu jäsenmuuttuja ja rakentaja. Lisäksi MyMidlet luokan rakentajaan on korjattu MyCanvas luokan rakentajan kutsumiseen käytettävä parametri, jonka takia myös MyMIDlet-luokka näkyy muuttuneena tiedostona. Kuva L1.6 esittää tätä tilannetta. Askeleessa yhdistetään jälleen Fredissä erikseen toteutettuja tehtäviä yhtenäiseksi kokonaisuudeksi, jolloin käyttäjälle muodostuu parempi kokonaiskuva tilanteen edistymisestä, eikä askelien määrä esimerkissä nouse niin suureksi. 71

79 Kuva L1.7. MIDlet esimerkin askel 7 Askeleessa 7 on tehty luokkaan MyCanvas paint-metodi ja kirjoitettu sille toteutus. Toteutetun metodin merkitys ohjelmalle on selitetty oikeassa ylänurkassa sijaitsevassa tekstialueessa ja lähdekoodiin tehdyt muutokset on korostettu. Kuva L1.7 esittää tätä tilannetta. Fredissä paint-metodin oletustoteutus on voinut olla juuri kuvassa näkyvä, tai käyttäjä on voinut kirjoittaa tyhjälle metodille tässä näytetyn ratkaisun. Ohjelmistokehyksen erikoistamista harjoittelevan käyttäjän kannalta metodin ja sen toteutuksen luominen on kuitenkin selvästi loogisesti yhteen kuuluva kokonaisuus, joka on kuvattu yhtenä askeleena. 72

80 Kuva L1.8. MIDlet esimerkin askel 8 Askeleessa 8 on lisätty MyMIDlet luokkaan jäsenmuuttuja display, sekä tehty siihen liittyvät muutokset lähdekoodiin. Kuva L1.8 esittää tätä tilannetta. Oikean ylänurkan tekstialue esittää valittuna olevan metodin (startapp) kuvauksen. Huomaa, että kuvaus on päivittynyt siitä, mikä se oli askeleessa 3, kun sovelluksen tekeminen on edennyt. Kuvauksen päivittyminen on jälleen seurausta Fredin ominaisuuksista, eikä nauhoitteen tekijän ole tarvinnut kiinnittää mitään huomioita sen tekemiseen. 73