Keltsi

Keltsi-projektissa tehtävänä oli laatia proof of concept -käytännön toteutusta keltaisiin sivuihin semantic web-tekniikalla. Projektin alussa asiakkaan tehtävämäärittely oli laaja, mutta lopulta päädyimme toteuttamaan keltaisten sivujen selaimen, joka käyttää semantic web-tekniikkaa ilmoitusten löytämiseen älykkäämmin kuin mihin perinteisillä menetelmillä pystytään. Rajasimme muut toiminnallisuudet, kuten ilmoitusten syötön ja hallinnan projektin ulkopuolelle, ja pyrimme keskittymään mahdollisimman hyvän selaimen rakentamiseen.

Projektimme alkoi viikolla 22 (29.5.2002) ja kesti 12 viikkoa aina 27.8.2002 asti, jolloin projekti palautettiin ja demottiin yhdessä muiden Helsingin yliopiston tietojenkäsittelytieteen laitoksen ohjelmistotuotantoprojektien kanssa. Projektissa käytettiin menetelmänä omaa Extreme Programming ja tavoitepohjaisen käyttöliittymäsuunnittelumenetelmän yhdistelmää. Projekti saavutti erinomaisesti monia oppimistavoitteitaan ja toimitti lopputuotoksen ajallaan. Joistakin tavoitteista, kuten automaattisten testien laatimisesta ja menetelmän kirjaimellisesta käytöstä lipsuttiin projektin viimeisissä iteraatioissa, kun paineet toimivan lopputuotoksen saamiseksi valmiiksi kasvoivat. Tämä kuitenkaan ei ollut merkityksellistä projektin lopputuloksen kannalta, sillä saimme eroteltua asiakkaan tarpeet ja toteutettua niistä tärkeimmät resurssiemme suomissa puitteissa. Kaiken kaikkiaan projekti oli menestys oleellisin osin.

Aluksi tässä dokumentaatiossa käydään läpi projektin aikana tehdyt iteraatiot. Tämän jälkeen kerrotaan projektin loppuvaiheen tilanne ja mitä saatiin oikeastaan valmiiksi. Seuraavaksi kappaleessa 4 kerrotaan mitä kokemuksia projektin aikana kertyi eri osa-alueista. Kappaleessa 5 kerrotaan jatkokehitysehdotuksia projektille. Liitteessä 1 on yksityiskohtaiset projektin palautekyselyn tulokset. Liitteessä 2 on projektin kaikkien kokouksien pöytäkirjat. Liitteessä 3 on yhteenveto projektin tuntikirjanpidosta.

Päiväys	Versio	Kommentti
19.8.2002	0.01	Ensimmäinen versio. Liitteet.
23.8.2002	0.02	Korjattu versio ohjaajan palautteen perusteella.
23.8.2002	0.03	Yhdistetty ensimmäinen julkaisukandidaatti.
26.8.2002	0.04	Täydennetty lukuja 4.3 ja 6.1, lisätty luku 8.
27.8.2002	1.00	Palautettu versio.

2. Iteraatiot

Projektin aikana tehtiin seitsemän iteraatiota, joiden yhteenlaskettu kesto oli 12 viikkoa. Projekti eteni resurssien käytön puolesta ja määriteltyjen testimittarien mukaan taulukon 1 mukaisesti. Projektille määriteltiin alussa 3 mittaria. Tuntikirjanpidon avulla laskimme projektiin käytettyjen tuntien määrää. Mittasimme automaattisten testien valmistumismäärää ja läpimenoprosenttia. Automaattisia testejä oli käytössä kahdenlaisia; funktionaalisia hyväksymistestejä (func) testaamaan asiakastarinoiden valmistumista ja yksikkötestejä (unit) testaamaan yksittäisiä koodiluokkia. Yksikkötestejä oli tarkoitus tehdä jokaiselle luokalle ja niiden läpimenoprosentin oli tarkoitus olla 100%. Funktionaalisia testejä oli tarkoitus laatia jokaiselle asiakastarinalle ja niiden läpimenoprosentin kasvun oli tarkoitus kuvata projektin etenemistä. Projektin nopeus on iteraation aikana valmistuneiden tehtäväkorttien alunperin arvioitu tuntimäärä.

Testien laatiminen ei onnistunut missään vaihetta projektia. Projektin ohjaus nopeusmittarin avulla toimi aluksi hyvin, mutta pian sen pääsi pois hallinnasta ja korjaustoimenpiteenämme tekemä tehtävän hyväksymiskriteerin nostaminen sisältämään tehdyn testin aiheutti, ettei tehtäviä valmistunut enää juuri lainkaan. Testien tekeminen koettiin ryhmän puolesta liian hankalina ja aikaa vievinä. Työajan käyttö oli tasaista koko projektin ajan.

vk	tunteja	func	func%	unit	unit%	nopeus
22	55	0	0	0	0	?
23	111	0	0	0	0	?
24	94	1	100	0	0	?
25	69	1	100	0	0	?
26	110	1	100	0	0	?
27	94	1	100	2	50	9
28	105	1	100	2	50	15
29	107,5	1	100	3	0	45
30	102	1	0	3	0	7
31	98	1	0	3	0	9
32	104	24	21	0	0	0
33	106	24	21	0	0	0
34	78,5	-	-	-	-	-
35	6	-	-	-	-	-
36	6	-	-	-	-	-

2.1 Tuotekehitysympäristön rakentaminen

Iteraation aikana rakennettiin tuotekehitysympäristöä ja opeteltiin valittujen työkalujen käyttöä. Kuitenkin tämä osoittautui vaikeammaksi kuin aluksi ajateltiin, ja etenkin versiohallintana käytetty komentorivi-CVS oli hankala ottaa käyttöön.

2.2 Ensimmäinen demo

Tämän iteraation aikana tavoitteena oli laatia hahmotelmia käyttöliittymästä, prototyyppi tietokantayhteydestä, Jena RDF(S)-prototyyppi sekä esimerkkiontologia. Käyttöliittymästä ei saatu selkeää kuvaa, vaan sen selvittämistä jatkettiin mm. asiakaskäynnillä Keltaiset Sivut Oy:ssä.

2.3 Semantic web backend

Teimme ensimmäisiä kokeiluja käyttöliittymästä JSP/Custom Tag-tekniikalla. Laadimme luokkia, joiden avulla voidaan tehdä RDF:stä kyselyitä esimerkiksi luokan ominaisuudet ja ominaisuuden omistavat luokat. Juhannuksen takia pidimme lyhennetyn työviikon jälkimmäisellä iteraation viikolla.

2.4 Franchising-yritysten etsiminen

Käyttäjäkuvauksen valmistuttua ja sen priorisoituamme lähdimme toteuttamaan ensimmäistä asiakastarinaa. Sen mukaan järjestelmän avulla esimerkkikäyttäjämme Pirkko pystyy etsimään parturi-kampaamo -franchising-ketjuja. Aikaisemman palautteen ansiosta täsmensimme dokumentaatiotamme ja aloitimme mm. iteraatioprujun tekemisen.

2.5 Synonyymipalveluluokat

Synonyymipalveluokat-iteraation aikana tarkoitus oli lisätä toiminnallisuus, jonka avulla voidaan helposti saada listattua samankaltaista palvelua tarjoavia yrityksiä vaikka ne olisivat eri luokituksessa. Tälläisiä ovat mm. parturi-kampaamot, parturit ja kampaamo-parturit. Myöhemmin havaitsimme, että tämän kaltainen tilanne ei välttämättä esiinny normaaleilla keltaisilla sivuilla. Siirryimme myös käyttämään DAML-API:a.

2.6 Palveluiden yhdistäminen

Saimme viimein valmiiksi lopullisen prototyypin käyttöliittymästä, joka ratkaisee määritellyt ongelmat. Iteraation aikana yhdistimme aikaisemmin erillään olleet komponentit yhdeksi sivustoksi. Antti laati joitain funktionaalisia testejä (24 kpl). Iteraation loputtua käytössämme oli toimiva iteraation lopputuotos ensimmäistä kertaa projektin aikana.

2.7 Työn palautus

Iteraation aikana viimeisteltiin ohjelmakoodi demokelpoiseen kuntoon ja laadittiin projektin loppuraportti, tuotekehitysympäristön kuvaus ja käyttöohje. Iteraation päätteeksi työ palautettiin ryhmän ohjaajalle.

3. Lopputilanne

Projektin lopussa saimme viimein valmiiksi demottavan version ohjelmistosta. Keltsi-projektilla oli käytössä varsin toimiva työskentely- ja tuotekehitysympäristö, jonka avulla uuden koodin kirjoittaminen ja yhteistoiminta oli helppoa.

Kuten suunniteltiinkin, itse lopputuotoksen avulla voi selata palveluontologiaa, ja katsoa sieltä löytyviä ilmoituksia. Toisin sanoen projekti tuotti pohjimmiltaan ontologiaselaimen. Pelkän selauksen lisäksi ohjelmisto tarjoaa mahdollisuuden linkittää eri ilmoituksia toisiinsa erilaisilla poikittaisilla linkeillä. Esimerkiksi projektissa mallinnettiin parturi-kampaamo -ketjun toiminta franchising-periaateella siten, että yksittäisistä ketjun jäsenyrityksistä näytetään mielenkiintoisina linkkeinä franchising-lisenssin tarjoajayritys. Vastaavasti linkkejä voidaan rakentaa lähes minkälaisina suhteina halutaan. Toisena esimerkkinä käytimme Oululaista hotellia, joka suosittelee läheistä ravintolaa ja paikallista kulttuuritapahtumaa, jonka sponsorina hotelli on juuri kyseisenä viikonloppuna.

3.1 Projektin tavoitteet

Asiakkaamme ensisijainen tavoite projektille oli saada proof of concept-tyylinen demo käytännön sovellutuksesta, jolla voidaan kokeilla keltsi-järjestelmän toimivuutta käytännön sovellutuksessa.

Tietojenkäsittelytieteen laitoksen tavoite kurssin suhteen oli harjaannuttaa ohjelmistotuotannon tekniikoihin, ryhmätyöskentelyyn, tavoitteelliseen projektityöhön ja dokumentointiin.

Suomen Keltaiset Sivut Oy toivoi projektilta tietoa uusista mahdollisuuksista, joita käytetty Semantic Web -tekniikka voisi tuoda heidän palvelutarjontaansa.

Oma tavoitteemme oli ottaa käyttöön XP-menetelmän automaattinen testaus, pariohjelmointi, refaktorointi, planning game, nopeat iteraatiot, koodin yhteinen omistus ja yhteinen ohjelmointityyli. Käyttöliittymäsuunnittelumenetelmässä tavoitteena oli selvittää todellisten käyttäjien tavoitteet, goalit, laatia niiden pohjalta uusi käyttöliittymäsuunnitelma, tehdä goalipohjainen läpikäynti (walk through) sekä käyttäjätesti.

Lisäksi suunniteltiin, että projekti tehtäisiin käyttäen Tomcat ja JSP/custom tag -tekniikkaa, Ant, CVS, Protege ja Jena .

3.2 Tavoitteiden saavuttaminen

XP-menetelmän käytännöistä otimme onnistuneesti käyttöömme nopeat iteraatiot, jotka juhannuksen (vk 25) jälkeen juurtuivat säännölliseksi rutiiniksi. Koodin yhteinen omistus toimi myös kohtuullisesti, joskin CVS:n käytössä oli ongelmia. Pariohjelmointia pyrittiin harrastamaan projektin alkuvaiheessa, mutta loppua kohti johtuen kasvaneesta paineesta saada työtä valmiiksi siitä vähitellen lipsuttiin. Alussa siitä oli kuitenkin selvästi apua oppimisessa.

Automaattisia testejä ei saatu tehtyä projektin aikana paria yksittäistä kokeilua laskematta. Testien tekeminen koettiin vaikeaksi ja muutosten tekemistä haittaaviksi etenkin projektin alkuvaiheessa, jolloin muutosten tekeminen oli jatkuvaa. Refaktorointia testien avulla ei myöskään siten tehty. Automaattiset testit olivat kenties liian vaativa ohjelmistotuotantomenetelmä muutosten tekemisen helpottamiseen kun muutenkin työkalujen ja muiden käytäntöjen opettelu oli hyvin aikaa vievää. Loppuvaiheessa tehtyjä 24 funktionaalista testiä ei saatu otettua käyttöön määrittelemään itse ohjelmakoodin testausta, vaan ne jäivät irrallisiksi testeiksi.

Sisällön suhteen ideana oli, että projektin määritelty laajuus vaihtuu ja tarkentuu joustavasti projektin aikana. Projektin kannalta oli edullista, ettei alussa yritettykään suunnitella liikaa projektin teknistä sisältöä, sillä kukaan ei siitä juuri tiennyt mitään. Projektin sisällölliset tavoitteet täsmentyivät pikku hiljaa projektin edetessä kuten oli tarkoituskin.

Iteraation aikana tehty 1h planning game (iteraation alussa tehtävä suunnittelupeli) havaittiin riittämättömäksi suunnittelutyökaluksi. Suunnitteluun vaadittaisiin vähintään puoli päivää. Projektin loppua kohden suunnittelukäytännöistäkin alettiin lipsumaan. Tehtävämäärittelyjä ei enää noudatettu, mikä näkyy mitatun projektin nopeuden tippumisessa nollaan. Projektikurin säilyttäminen on selvästi tärkeää mikäli aiotaan säilyttää projektin ohjautuvuus. Kenties projektikäytännöt, mittarit ja niiden noudattaminen tulisi sitoa esimerkiksi palkkaukseen, jolloin projektin eteneminen olisi hallitumpaa.

Yhteiseksi ohjelmointityyliksi valittiin Sunin Java Coding Convention [http://java.sun.com/docs/codeconv/] , jonka noudattamisen tarkastamiseksi build-skriptoihin lisättiin Checkstyle-työkalu. Projektin lopussa checkstyle:n mukaan oli Coding Conventionista poikkeavuuksia 909kpl kun kesken projektin työkalun käyttöön oton aikaan poikkavuuksia oli 1453 kpl. Toisin sanoen projektin loppua kohden yhteisen ohjelmointityylin käyttö parani merkittävästi, joskaan kuitenkaan ei ollut täydellistä.

Käyttöliittymää varten tavoitteista poiketen loppukäyttäjiä ei observoitu. Käyttäjäkuvaukset ja heidän tavoitteensa perustuivat haastatteluihin ja Keltaiset sivut Oy:ltä saatuun markkinointitietoon. Suunnittelu oli jatkuvasti myöhässä johtuen itse projektin johtamisen viemästä ajasta. Läpikäyntejä ei ehditty tekemään, ja suunnitelman pohjalta laaditun prototyypin käyttäjätesti jäi tekemättä johtuen laitoksen tietokoneympäristön käyttökatkosta viikonloppuna, jolloin testi oli tarkoitus suorittaa.

Projekti laadittiin toivomusten mukaisesti käyttäen Tomcatia, JSP/Custom Tag-tekniikkaa, Ant, CVS, Jenaa ja Protege:ta. Opimme käyttämään kaikkia työkaluja, sekä lisäksi muutamia ylimääräisiä.

Projektin tuntimäärä ylittyi suunnitellusta 1200:sta tunnista noin 50:llä (4%). Toisin sanoen projekti saavutti resurssinkulutustavoitteensa kohtuullisesti vain hienoisella ylityksellä.

Pyrimme täyttämään asiakkaan tavoitteet projektin suhteet tekemällä proof of concept-demon. Onnistuimme priorisoimaan asiakkaan toiveet ja karsimaan niistä kaikkein olennaisimmat asiat. Luonnollisesti kaikkia asiakkaan toiveita ei pystytty toteuttamaan, vaan jouduimme toimimaan resurssiemme asettamissa rajoissa. Vielä emme ole kuulleet onko asiakas tyytyväinen tuottamaamme ratkaisuun.

Laitoksen kannalta projektin aikana monet tavoitteet toteutuivat erinomaisesti. Ryhmä oppi käyttämään monia eri ohjelmistotuotannon työkaluja kuten Ant ja CVS. Ryhmä toimi perinteistä huomattavasti tiiviimmässä ryhmätyössä, mikä oli opettavaista. Toisaalta osasta projektin asetetuista tavoitteista lipsuttiin paljon, mutta toisaalta monia myös saavutettiin. Projektin dokumentointia kehitettiin jatkuvasti kaikkia osapuolia tyydyttäväksi, joskin projektimme ei alkuun tukenut hyvin paperimuotoista dokumentointia. Sen sijaan verkossa ollut Wiki-pohjainen dokumentointi paljastui erinomaiseksi.

Suomen Keltaiset Sivut Oy:lle projektin avulla voitiin havaita, että käytetty tekniikka helpottaa ainakin palveluluokitusten hallintaa. Lisäksi eri ulkopuolisten tahojen välinen yhteistyö helpottuu, kun käytössä on standardit luokitukset ja kuvaustavat. Mahdollisuutena projektin aikana nähtiin elektronisen kaupankäynnin helpottuminen, kun käyttöön otetaan DAML ja DAML-S -pohjaiset agentit kauppapaikkojen konemuotoiseen kanssakäymiseen.

4. Yhteenveto kokemuksista

Seuraavaksi kerrotaan yhteenveto kuinka ryhmä koki itse projektin eri osa-alueiden toimivuuden. Aluksi käydään läpi kaikki tuotekehitysympäristöön ja työskentelyyn liittyvät asiat, sitten menetelmä ja viimeiseksi tekniikka.

4.1 Työskentely- ja tuotekehitysympäristö

Oman työtilan järjestäminen projektin käyttöön koettiin hyväksi kokemukseksi. Se tarjosi rauhallisen paikan, jossa kaikki ryhmäläiset pystyivät yhdessä tekemään töitä omassa rauhassa. Lisäksi D327:n ilmastointi auttoi pitämään työolosuhteet miellyttävinä kuumina kesäpäivinäkin. Ainoa luokan haittapuoli oli hitaat koneet.

Ant havaittiin loistavaksi build-työkaluksi, ja suosittelemme sen käyttöä muissakin projekteissa. Komentorivi CVS osoittautui vaikeaksi oppia. Yhteistyö oli hankalaa ja monesti filet jäivät tallentamatta. Komentorivi CVS:n suurin heikkous on, ettei sen avulla helposti näe mitä versionhallinnassa tällä hetkellä on ja mitä ei, ja onko omat muutokset jo lisätty.

Ryhmä käytti monia eri editoreja kuten jed, XEmacs, pico ja kate. Xemacs herätti positiivista palautetta, kuten myös kate. Yhtenäinen editori olisi kuitenkin saattanut olla vielä parempi valinta, joten monien editorien käyttö osoittaa, ettei yksikään niistä ollut ylivoimaisesti toisia parempi.

UML-kaavioiden piirtäminen aloitettiin vasta projektin puolivälissä. Suurin ongelma oli erinomaisen, kaikkiin tarpeisiin sopivan UML-editorin puute. Lopulta päädyimme dia:n käyttöön, jonka opettelun koettiin olevan korkean kynnyksen takana. Tosin luokkakaaviot ja monet muutkin kaaviot saatiin sen avulla piirrettyä ja heikkotehoisiin koneisiimme se oli sopivan kevyt.

Laitoksen ympäristö petti projektin aikana kolme kertaa siten, että siitä koitui haittaa ryhmällemme.

* Pe 14.6.2002 klo 12.30 TKTL tiedostojärjestelmä hajosi. Projekti menetti 5x 1,5h tehokasta työaikaa.

* Su 4.8.2002 TKTL kaikki järjestelmät ovat poissa käytöstä. Käyttäjätesti jäi tekemättä.

* Pe 9.8.2002 klo 14.00 TKTL linux-ympäristössä vikoja. CVS ja java eivät toimi. Webbiselaimet kaatuvat. Menetetään 3x2h tehokasta työaikaa kun työt joudutaan keskeyttämään ennenaikaisesti, sekä koko aamupäivän tallentamattomat työt. Tuomo ei voi tehdä viikonloppuna töitä, koska kaikkea koodia ei saada tallennettua ennen seuraavaa viikkoa ihmisten ollessa poissa kaupungista.

Yhteensä projekti tuhlasi työaikaa 30h, joka kuitenkaan 1250h:sta projektiin kokonaisuudessaan menneestä tunnista on 2,4% työskentelyajasta. Emme kuitenkaan osaa arvioida kuinka tavallinen tämänkaltainen menetys on esimerkiksi yrityksissä.

Tiivis ryhmätyö tuo riskejä. Jos laitteisto ei toimi, koko ryhmä menettää työaikaa eikä vain yksittäinen henkilö, kuten jos työtä tehtäisiin itsenäisesti esim. kotona. Toisaalta ryhmätyö parantaa kommunikointia ja vähentää väärinkäsityksiä ja ylimääräistä työtä. Lisäksi se nopeuttaa oppimista selvästi verrattuna tilanteeseen, jossa kaikki työkalut olisi joutunut opettelemaan omatoimisesti.

WikiWikiWeb oli näppärä dokumentointityökalu. Sen ainoa ongelma oli, ettei sen sisältöä saanut helposti tulostettua. Jatkossa olisikin hyvä kehittää siihen esimerkiksi Wiki->Latex -konvertteri. Wikin käyttöä olisi entisestäänkin helpottanut, jos projektilla olisi ollut käytössä vapaasti liikuteltava kannettava tietokone ainakin sihteerin käyttöön ellei koko ryhmälle. Toisaalta laitos ei käsityksemme mukaan välttämättä ollut tyytyväinen Wikistä saatuihin paperidokumentteihin.

4.2 Menetelmä

XP vaati huomattavasti enemmän oppimista kuin tavallinen vesiputousmenetelmä olisi vaatinut. Menetelmä oli liian erilainen äkkiseltään käyttöön otettavaksi. Olisi ollut hyödyllistä, jos useampi ryhmäläinen olisi tuntenut sen paremmin alussa.

Projektin alussa ei oikein saatu riittävän tehokkaasti puhuttua projektin kokonaiskuvasta, vaikka kokouksia pidettiin ahkerasti. Planning Game:n aikana perjantaisin tehtyyn suunnitteluun käytettiin aivan liian vähän aikaa. Yksi tunti iteraatiossa ei riittänyt asiasta keskusteluun tai järkevän kuvan muodostamiseen ongelmakentästä tai ratkaisusta. Suunnittelua varten olisi tarvittu vähintään puoli päivää tai kenties jopa yksi kokonainen päivä. Iteraatiot lisäksi olivat puhdasoppiseen XP:n nähden tavallista nopeampia, sillä teimme vain 20h/vk työtä täyden 40h sijasta, mutta iteraatiot olivat silti XP:n normaalin 2 viikon mittaisia.

Käyttöliittymäsuunnittelumenetelmän ongelmina havaittiin asiakasongelman ja käyttäjien tavoitteiden liittäminen XP:n asiakastarinoihin. Se ei ollutkaan niin suoraviivaista kuin projektin alkaessa oli luultu. Käyttöliittymäsuunnittelu oli lisäksi jatkuvasti myöhässä, mikä haittasi koodausta. Jatkossa käyttöliittymäsuunnittelu ja tavoitteiden selvittäminen sekä niiden muuntaminen iteraatiotason asiakastarinoiksi tulisi kenties laatia edellisen releasen aikana (~3kk etukäteen).

Jälkikäteen todettiin, että olisi ollut varsin hyödyllistä laatia suuri yleiskuva esim. arkkitehtuurikuvauksesta ja ripustaa se seinälle kaikkien nähtäväksi. Se olisi helpottanut ongelman ratkaisua ja siitä puhumista jo projektin alkuvaiheessa. Aikaisin aloitettuun UML-kaavioon olisi voinut kirjoittaa jatkokehitystoiveita ja se olisi ollut pohjana yhteiselle keskustelulle.

Säännöllinen työrytmi havaittiin hyväksi auttamaan pitämään projekti kurissa ja jatkuvasti etenemässä.

4.3. Tekniikka

4.3.1. Tietämyskanta

Toimeksiannon perusteella tietämyskanta esitettiin Resource Description Framework RDF-verkkona [RDF]. Sanastot (ontologiat) on kuvattu RDF Schemalla [RDFS]. Tietämyskanta kuvaa mainostettavia palveluja. Esimerkiksi kuvaus "Eila Jurva on kampaamo Vantaalla" esitetään kolmikoina (subjekti, predikaatti, objekti) seuraavasti:

Tietämyskantaa muokattiin Protégélla [PROTEGE], joka on RDFS-editori. Protégén käyttö aiheutti eräitä ongelmia. Se ei salli xml:lang-attribuuttien käyttöä ja tuhoaa ne. Se ei salli muokata instansseille mielekästä rdfs:label-attribuuttia. Protégén avulla on mahdollista hallita usean ontologian projektia siten että kukin ontologia on omassa tiedostossaan ja omassa nimiavaruudessaan. Nämä mahdollisuudet valkenivat meille liian myöhään.

RDFS ei tarjonnut välineitä kaikkien tarvittavien suhteiden ilmaisemiseen. Protégé täydentää RDFS:ää omilla ominaisuuksilla kuten maxCardinality ja allowedParents. Ne ovat sinänsä hyödyllisiä, mutta epästandardeja.

Tietämyskannan ydin muodostuu palveluontologiasta. Palveluontogiaksi valittiin Universal Standard Products and ServicesCode [UNSPSC], jonka luokat 70-99 ovat palveluluokkia. Vaihtoehto olisi ollut Keltaisten Sivujen [KS] luokitus, mutta se soveltuu huonosti selattavaksi koska ensimmäisen tason luokilla on useita kymmeniä alaluokkia, toisen tason luokilla tyypillisesti vain yksi. Toinen vaihtoehto on Euroopan yhteisön tilastollinen toimialaluokitus [NACE].

Tuoteontologiaa tarvitaan, jotta voidaan esittää ajatus "Kaken Kamera huoltaa kameroita" (<service:KakenKamera>, <keltsi:maintains>, <productclass:Cameras>). Näin vältetään palveluontologian valtava laajentamistarve. Lisäksi on helppo ilmaista muidenkin kuin myymälä-tyyppisten palveluiden myyvän tuotteita: "Kaisan Kampaamo myy hiushoitotarvikkeita" (<service:KaisanKampaamo>, <keltsi:retails>, <productclass:HairCareSupplies>).

Toteuttamaton mahdollisuus on, että tuoteontologian instansseiksi (tai alaontologioiksi) luodaan tuotemerkkejä ja jopa malleja, jolloin voidaan ilmaista ajatus "Kaken Kamera huoltaa Nikon-kameroita" (<service:KakenKamera>, <keltsi:maintains>, <product:Nikon>) tai alaontologian avulla (<service:KakenKamera>, <keltsi:maintains>, <nikoncameras:APSCameras>).

Tuoteontologiaksi valittiin myös UNSPSC, luokat 00-69 ovat tuoteluokkia. Vaihtoehto tuoteontologiaksi olisi ollut mm. CPA [CPA], joka on EU:n virallinen tuoteluokitus. CPV on sen tarkennus, julkishallinon hankintasanasto.

4.3.2 Tietosisältökerros

Tietämyskannan käsittelyyn valittiin Jena [JENA]. Jena tarjoaa kolme vaihtoehtoista mallia: (1) ModelMem, jossa RDF-verkko on aina kokonaan muistissa (2) ModelRDB, jossa RDF-verkko on tietokannassa ja (3) DAMLModel, jossa DAML-verkko on muistissa.

DAML [DAML] sisältää RDFS:n ja DAMLModel tekee lähes kaiken RDFS:n edellyttämästä päättelystä. Siksi projektin puolivälissä siirryttiin ModelMemistä DAMLModelin käyttöön.

Ongelmien 4 ja 5 ratkaisemiseksi aloitettiin siirtyminen pois DAMLModelin käytöstä. RDFS-päättely on toteutettu Sesamesta [SESAME] omaksutulla tavalla. Riittävä osa pääteltävistä kaarista lisätään verkkoon tietosisältökerroksen luonnin yhteydessä (pavelun käynnistyessä). Sitten voidaan kytkeä "setUseEquivalence" pois, ja hakujen vaatima aika putoaa noin sadasosaan. Lisäksi nyt on mahdollista käyttää RDQL-kyselykieltä, koska RDF-verkossa on valmiina riittävästi tietoa.

Jena sisältää kyselykielenään RDQL:n [RDQL]. Se on RDF-pohjainen, eli ei tee RDFS:n edellyttämiä päättelyitä. RQL-kyselykieli [RQL], joka sisältyy mm. Sesameen [SESAME], on RDFS-taitoinen.

Kyselyjä toteutettiin sekä RDQL-kyselykielellä että Jenan valitsimiten (Selector) avulla. Valitsimet ovat nopea tapa hakea yksinkertaisen kaavion mukaisia kolmikoita. Valitsimella (null, <rdf:type>, <serviceclass:HairCare>) löytyvät kaikki tyyppiä HairCare olevat oliot, mukana edellä mainittu Eila Jurvan Kampaamo. Yhdellä valitsinhaulla ei kuitenkaan voi hakea vain helsinkiläisiä hiushoitopalvelut. Se onnistuu RDQL:n avulla kyselyllä:

SELECT ?service
WHERE (?service, <rdf:type>, <serviceclass:HairCare>)
(?service, <keltsi:location>, <location:Vantaa>)

Lopuksi tarkastellaan luvun alussa olevan kuvan tilannetta. Palvelummen asiakas haluaa löytää kaikki uusmaalaiset kauneudenhoitopalvelut. Hän merktsee haun aloituskohdat ontologioissa, kuvassa keltaisella. Kokeillaan RDQL-kyselyä.

SELECT ?service
WHERE (?service, <rdf:type>, <serviceclass:PersonalAppearance>)
(?service, <keltsi:location>, <location:Uusimaa>)

Kysely ei tuota tulosta, ellei näitä pääteltyjä kaaria ole kirjattu RDF-verkkoon. Nykyisessä toteutuksessa on kirjattu päätellyt subClassOf-kaaret, jolloin RDQL-kysely

SELECT ?service
WHERE (?service, <rdf:type>, ?class1)
(?class1, <rdfs:subClassOf>, <serviceclass:PersonalAppearance>)
(?service, <keltsi:location>, ?class2)
(?class2, <rdfs:subClassOf>, <location:Uusimaa>)

tuottaa odotetun tuloksen (kuvassa vihreällä merkityt palvelut). Ratkaisu ei kuitenkaan ole riittävä, jos palveluiden ominaisuuksien arvoiksi sallitaan muitakin kuin ontologian (luokkahierarkian) lehtisolmuja. Jos palvelu ilmoittaa paikakseen Uusimaa, se ei löytyisi haettaessa paikan Helsinki palveluita.

4.3.3. Rajapinta- ja kontrollikerros

Sovellusta käytetään selaimella. Sivut tuotetaan Java Server Pages -tekniikalla [JSP]. Tavoitteena oli erottaa sisältö ja ulkoasu käyttämällä Custom Tag -tekniikkaa. Custom Tagien käyttö osoittautui kuitenkin työlääksi oppia ja sovltaa. Toteutuksen olisi saanut helpommin aikaiseksi servlettinä.

5. Jatkokehitysehdotukset

Ilmoitusten syöttötyökalussa tulisi keskittyä myös sellaisen kenties komentorivipohjaisen työkalun tekemiseen, joka siirtäisi ilmoituksia suoraan vanhasta järjestelmästä uuteen. Tai vaihtoehtoisesti mielenkiintoinen ratkaisu voisi olla käyttää suoraan olemassaolevia tietokantoja ja lisätä tarvittava metatieto uuteen RDF-tietokantaan.

Jotta järjestelmän saisi oikeaan tuotantokäyttöön, se tulisi rakentaa nykyisen tiedostopohjaisen tietomallin sijasta tietokannan päälle. Projektin alkuvaiheessa tutkimme mahdollisuutta käyttää Oraclea ja PostgreSQL:ää. Nykyinen toteutus ei ota huomioon lainkaan, jos kuvaukseen halutaan lisätä tai poistaa tietoja.

Mielenkiintoista voisi olla selvittää Sesame -frameworkin sopivuutta Jenan tilalle. Se saattaa tarjota hyödyllisiä ominaisuuksia, kuten kehittyneempää sulkeutumien käsittelyä.

Jatkokehityksessä saattaisi olla hyvä tutkia toimintalogiikan määrittämistä DAML-L:llä tms. itse RDF-skemaan.

SOAP, UDDI ja muut Web Services-tekniikat voisi olla mielenkiintoisia tekniikoita kokeiltaviksi.

Keltaisten Sivujen oma luokitus on erilainen kuin käyttämämme UNSPSC, jolloin oma luokitus tulisi laatia erikseen. Toisaalta esim. Keltaisten sivujen nykyiset välitason luokitukset kuten "parturi" ja "parturi-kampaamo" on helppoa siirtää sellaisinaan toiseen luokitukseen.

Luokituksen eri kieliversiot voisi rakentaa esimerkiksi xml:lang -määrityksen avulla. UNSPSC on kuitenkin määritelty ainoastaan englanniksi, joten se tulisi myös suomentaa tai sitten miettiä toista luokitusta, jossa käännökset useammalle kielelle on olemassa valmiiksi.

6. Järjestelmän kuvaus

Seuraavaksi kuvataan järjestelmän toiminta aluksi yleisellä arkkitehtuuritasolla. Seuraavaksi esitellään luokkakaavio sekä viimeiseksi tuotekehitysympäristö ja kuinka järjestelmä voidaan ottaa käyttöön uudessa ympäristössä.

6.1 Yleinen arkkitehtuurikuvaus

Kuvan 2 kerrosrakenne ja pakkausten väliset riippuvuudet ovat loogisia luokkien käyttöön liittyviä riippuvuuksia ja havainnollistavat ohjelmistonosien vastuiden jakautumisen. Kuvassa ei ota kantaa ohjelmistonosien suorituksen aikaiseen fyysiseen sijaintiin.

Keltsi-järjestelmän arkkitehtuuri on kolmikerroksinen. Ylimmällä kerroksella on järjestelmän rajapinta ja kontrolli-luokat, jotka yhdessä mahdollistavat vuorovaikutuksen käyttäjien kanssa. Keskimmäisellä kerroksella on tieto-luokat, jotka vastaavat järjestelmän tietosisällöstä. Alimmalla kerroksella on järjestelmän tietämyskanta.

6.2 Rajapinta- ja kontrollikerros (Boundary and Control)

Keltsi-järjestelmän ja sen käyttäjien välinen rajapinta on graafinen www-käyttöliittymä. Järjestelmän toiminnot ilmenevät käyttöliittymässä näyttöinä, jotka tarjoavat käyttäjille erilaisia syötteen anto mahdollisuuksia. Syötteet välittyvät näytöiltä kontrolli-luokille, jotka vastaavat järjestelmän toimintojen suorituksen ohjauksesta.

Toimintojen suoritus edellyttää tietosisältökerroksen tieto-luokkien palveluiden hyväksikäyttöä. Kontrolli-luokat määrittävät näytöiltä välittyvistä syötteistä, mitä tieto-luokkien palveluita niiden tulee kutsua ja mitä syötteitä niiden tulee välittää tieto-luokille palveluiden suoritusta varten. Palvelupyynnöt aiheuttavat kutsuttujen operaatioiden suorituksen tieto-luokissa. Ne palauttavat kontrolli-luokalle tyypillisesti tieto-olion tai kokoelman tieto-olioita, joiden palveluita kutsumalla (edelleen näytöiltä välittyneiden syötteiden ohjaamana) kontrolli-luokka saa paluuarvona tuotokset, jotka se muokkaa näytöille. Kontrolli-luokat vastaavat siten myös järjestelmän käyttäytymisen esittämisestä käyttäjille.

6.3 Tietosisältökerros (Entity)

Tietosisältökerros sisältää ydinontologioista johdetut tietoluokat. Ne yhdistävät tiedon ja kyseistä tietoa käsittelevät operaatiot. Operaatiot ovat tyypillisesti tiedonkeruu tapahtumia (kyselyitä), jotka kohdistuvat tietämyskantaan. Ne palauttavat pääsääntöisesti kokoelman tieto-olioita. Esimerkiksi Advertisement-luokan metodi getServices(), palauttaa kokoelman kyseisen luokan ilmentymään liittyvistä Service-olioista.

6.4 Tietämyskanta (Knowledge Base)

Tietämyskanta muodostuu ydinontologioista, oheisontologioista ja näiden instansseista. Ydinontologiat ovat kiinteä osa Keltsi-järjestelmää. Niiden muuntaminen tai poistaminen vaati vastaavien toimenpiteiden suorittamista tietosisältökerroksessa. Sen sijaan oheisontologiat ovat hyvin 'kevyesti' järjestelmään kiinnitettyjä. Niitä on tarkoitus kyetä lisäämään ja poistamaan helposti, tarpeen vaatimalla tavalla. Ydinontologioita ovat Service, Advertisement, Contact ja ImageFile. Keltsi-projektissa käytetyt oheisontologiat ovat Product, Location ja Restaurant. Ydinontologioihin määritellyt kardinaliteetit käyvät ilmi kuvasta 3, jossa on määritelty tietosisältökerroksen tietoluokat ja niiden väliset suhteet.

Kuvassa 4 on esitetty graafisesti, kuinka ilmoittaviin yrityksiin ja heidän tarjoamiinsa palveluihin liittyvät tiedot on mallinnettu Keltsi-järjestelmän tietämyskantaan. Tietämyskanta koostuu ontologioista, instansseista ja näiden välisistä suhteista. Ontologiat on kuvattu laatikoina ja instanssit soikioina. Jokaisesta soikiosta lähtee katkoviivainen nuoli, joka osoittaa ontologian luokkaa ja kertoo näin minkä luokan instanssi kyseinen soikio on. Ominaisuutta kuvaa yhtenäinen nuoli, jonka päästä löytyy ominiasuuden arvo. Nuoleen on liitetty ominsaisuuden nimi.

Kuvan 4 esimerkkitapauksessa on mallinnettu ilmoitus (advertisement1), jossa palvelun tarjoaja mainostaa kolmea palvelua: kokouskeskusta (service1), hotellia (service2) ja ravintolaa (service3). Ilmoituksessa on lueteltu kaksi hotellia, joista toinen sijaitsee Helsingissä (ominaisuus location saa arvon Helsinki) ja toinen Kajaanissa (ominaisuus location saa arvon Kajaani). Helsingissä sijaitsevan hotellin yhteydessä on kokouskeskus (instanssi contact1 liittyy ominaisuuden contact arvona sekä service1 - että service2 instanssiin ja lisäksi instansseilla service1 ja service2 on sama arvo ominaisuudella location) ja Kajaanissa sijaitsevan hotellin yhteydessä on tanssiravintola (instanssi contact2 liittyy ominaisuuden contact arvona sekä service2 - ja service3 instanssiin ja lisäksi instansseilla service2 ja service3 on sama arvo ominaisuudella location) (ominaisuuden restaurantType arvona on Dancing). Ilmoituksessa on myös kuva (instanssiin advertisement1 liittyy ominaisuuden image arvona instanssi image1). Oheisontologiat (auxiliary ontologies) ovat luokituksia, joiden luokkia käytetään suoraan ominaisuuden arvoina.

6.5 Tuotekehitysympäristön kuvaus

Tuotekehitysympäristö on jaettu kahteen päätasoon tools ja project. Hakemistossa tools on Keltsi-projektissa käytetyt työkalut: Jena, Protege, Checkstyle, httpUnit, JUnit, build-työkalu Ant sekä Tomcat servlet container. Kyseisten työkalujen tarvittavat classpath -ja path muuttujien asetukset saadaan ajamalla keltsi/project hakemiston skripti setk.

Hakemistoon project on tallennettu projektissa käytetyt ohjelmatiedostot. Sovelluksen käännös ja jakelu tapahtuu suorittamalla project hakemistossa ant deploy. Tämä luo tools/tomcat/webapps/keltsi hakemistoon staattisen sivuston sekä kääntää java luokat WEB-INF/classes hakemiston alle kunkin luokan package-määreen osoittamaan hakemistorakenteeseen.

Jsp-sivuilla käytettyjen tagien kuvaustiedosto keltsitag.tld on alihakemistossa jsp/WEB-INF. Täältä löytyvät viitteet sivustolla käytettyjen custom tagien ja tagien toiminnallisuuden toteuttavien luokkien välille. Custom tagien luokat löytyvät hakemistosta src/customtags.

6.6 Hakemistorakenne

6.7 Käyttöohje

kenttään kirjoitetaan sana ravintola, avautuu Service-palvelupuusta kohta Restaurants, joka näkyy tähdellä merkittynä. Tähti on aina sen palveluluokan edessä, joka on viimeksi toiminut hakukriteerinä. Tämän yläpuolella näkyvät palvelut listana, joita pitkin kyseiseen hakutulokseen päästiin.

Tummennetulla alueelle palkin keskiosassa näkyvät palveluiden ominaisuudet, joita ilmestyy näkyville sitä mukaa, kun niitä kulloisenakin hetkenä käsiteltävällä palvelulla on määritelty. Näistä ominaisuuksista voidaan sitten rajata ja tarkentaa hakua. Esimerkiksi palvelulla restaurants on paikka(Area) ominaisuuden lisäksi ominaisuudet Rating, Ambiance, RestaurantType, joista klikkaamalla saadaan mahdolliset arvot näkyville. Arvojen hyperlinkkiä seuraamalla valitaan uusi hakuehto.

Alimpana palkissa näkyy LIST RESULTS linkki, josta klikkaamalla alle tulostuu hakutuloksen mukaiset palvelut. Näistä valitsemalla, oikeanpuoleiseen kehykseen latautuu valitun palveluntarjoajan mainos sekä kontaktitiedot.

Mainoksen yläpuolella on lista valitun palveluntarjoajan ominaisuuksista. Näiden linkkien vasenta osaa napsauttamalla, vaihtuu liittymän vasemman kehyksen sisältö vastaavan hakupuun kohtaan. Tämä vastaa siis tilannetta "muita instansseja, jotka tarjoavat myös kyseistä palvelua". Linkin oikeaa puolta klikkaamalla mainos vaihtuu valitun linkin tarjoamaan mainokseen.

Mainoksen alapuolella on linkit muihin kyseisen mainostajan tarjoamiin palveluihin sekä mainostajan muut suositukset.

7. Yhteenveto

Projekti onnistui ryhmän mielestä kuitenkin hyvin. Sen aikana opittiin paljon sekä työkaluista, projektityöskentelystä, että semantic web-tekniikasta. Alun perin suunnitellut toimintatavat osoittautuivat liian raskaiksi ryhmälle. Niiden opetteluun meni suuri osa projektin ajasta, ja olisi ollut hyödyllistä jos ne olisi esitelty aikaisemmilla kursseilla valmiiksi.

Projekti sai kuitenkin aikaan ohjelmiston, jolla voidaan selata ontologiassa olevia ilmoituksia. Ohjelma toimii hyvin ja se on vakaa. Kaiken kaikkiaan projekti oli varsin opettavainen ja mielenkiintoinen kokemus.