Tik-76.115 Suunnittelupäätökset

Älykäs kalenteri

Viimeksi päivitetty $Date: 2001/04/20 13:41:34 $.

Sisällysluettelo

1. Johdanto
2. Suunnittelupäätökset
2.1. Kalenteriprotokolla 2.1.1. CAP-protokolla 2.1.2. CAP-parseri 2.2. Palvelimeen liittyvät päätökset 2.2.1. Ohjelmiston ydin 2.2.2. Kielellinen älykkyys 2.2.3. Kalenterimerkintöjen tallentaminen 2.2.4. Yksikkötestaus 2.2.5. Suodattimet 2.2.6. Moduulit 2.2.7. Todo- ja tapahtumamerkinnät 2.3. Asiakasohjelmistoon liittyvät päätökset 2.3.1. Toteutusarkkitehtuuri 2.3.2. Yksittäisten HTML-sivujen toteutus 2.3.3. Merkkien suodattaminen

Versiohistoria

1. Johdanto

Dokumentti on asiakkaan toivomuksesta tehty koottu kokoelma suunnittelupäätöksiä. Dokumentin tarkoituksena on täydentää ja tuoda taustaa projektin teknisen määrittelyn sisältämille yksityiskohdille. Dokumentin tarkoituksena on toimia eräänlaisena referenssinä ja vastata kysymyksiin, jotka heräävät esimerkiksi ohjelmistojen lähdekoodia luettaessa.

Dokumenttia päivitetään projektin kuluessa.

2. Suunnittelupäätökset

2.1. Kalenteriprotokolla

2.1.1. CAP-protokolla

CAP-protokollan [CAP] ja iCalendar-olioiden esitystavan [RFC2445] käyttö palvelimien ja asiakasohjelmistojen välillä.

Katsottiin tärkeäksi potentiaalinen yhteensopivuus muiden kalenteriohjelmistojen kanssa tulevaisuudessa. Protokollan valinta on siis tietoinen riski, koska kyseessä on vasta ehdotus protokollaksi ja sitä ei tueta missään kalenteriohjelmistossa.

Alkuperäinen suunnitelma oli käyttää kalenteriserverin ulkoisena rajapintana XML-pohjaista esitysmuotoa. XML-esitysmuoto olisi helpottanut jonkin verran parsimista, mutta tärkeämmäksi katsottiin CAP-protokollan tarjoama yhteensopivuus tulevaisuudessa sitä tukevien kalenteriohjelmistojen kanssa. XML:lle ei vastaavasti löytynyt potentiaalista standardia tiedon siirtoon.

Vaihtoehtona olisi myös ollut tehdä oma protokolla. Tämä koettiin kuitenkin turhaksi CAP:n speksin ollessa verrattain hyvällä tasolla jo projektin alkuvaiheessa.

SyncML hylättiin jo alkumetreillä, koska julkista tietoa protokollasta ei ollut saatavilla tarpeeksi aikaisin.

• CAP:n valinta tiesi sitä, että protokollaa joudutaan erityisesti profiileja käsitellessä hieman laajentamaan (ks. tekninen määrittely). Myös CAP:n categoryn käyttäminen kalenteritapahtumista tehtävän lisätiedon säilytyspaikkana liikkuu protokollamäärityksen äärirajoilla.
• Potentiaalinen mahdollisuus kommunikointiin muiden kalenteripalvelimien kanssa, mikäli CAP saavuttaa standardin aseman.

Tekninen määrittely, CAP-spesifikaatio [CAP].

2.1.2. CAP-parseri

CAP-parserin toteutus JLex:llä ja JavaCUP:lla.

CAP on verrattain monipuolinen protokolla. Luotettavan parserin teko käsin ilman apuvälineitä koettiin turhaksi ja liikaa aikaa vieväksi tehtäväksi. Sen sijaan päätettiin käyttää tuttuja työkaluja leksikaalisen analyysin (JLex) ja parsinnan toteuttamiseksi (JavaCUP) nopeasti.

Vaihtoehtona olisi ollut tehdä oma parseri tai käyttää muita samantyyppisiä työkaluja parsinnan toteuttamiseen. JavaCUP ja JLex edustavat toteukseltaan kuitenkin perinteisiä Unix-työkaluja kääntäjien teossa, joten muiden työkalujen käyttö ei ollut perusteltua.

TCP/IP-pohjaisen protokollan parsintaan JavaCUP ja JLex eivät ole valitettavasti niitä kaikkein parhaita esim. Streamin lopun havaitsemisen suhteen. Toteutuksessa vaadittiin siis pientä kikkailua.

• Protokollatuki on implementoitu verrattain pienellä koodimäärällä, joskin runsaalla kieliopilla.
• Protokollan muokkaaminen on helppoa.

-

2.2. Palvelimeen liittyvät päätökset

2.2.1. Ohjelmiston ydin

Ytimestä tehtiin pelkästään moduulien jakopaikka

Ytimestä haluttiin mahdollisimman kevyt ja yksinkertainen, vieläpä siten että se ottaa hyvin vähän kantaa itse kalenterisovellukseen. Nykyinen rakenne toteuttaa vaatimukset hyvin. Siinä ei ole mitään kalenterispesifisyyttä, mutta se takaa kuitenkin helpon laajennettavuuden.

Ydin vastaanottaa viestejä ja välittää viestit tyypin perusteella oikealle moduulille. Koska tässä vaiheessa ei kuitenkaan ollut selvää kuvaa mitä ytimen tulisi osata, tämä toiminnallisuus siirtyi CalendarModulelle. Samoin haluttiin ettei ytimen rajapinta muutu vaikka viestintä jouduttaisiinkin muuttamaan erilaiseksi.

Täysin toinen lähestymistapa olisi ollut kalenterirungon rakentaminen monoliittisesti, mutta tästä ajatuksesta luovuttiin välittömästi, sillä vaatimukset pakottavat mahdollisimman modulaariseen lähestymistapaan.

Moduulit kommunikoivat käyttäen ydintä. Moduuleilla ei ole suoria linkkejä toisiinsa.

Tekninen määrittely.

2.2.2. Kielellinen älykkyys

Ulkoinen kieliohjelmisto jätettiin pois

Alunperin asiakkaan ajatuksissa oli käyttää GATE-projektin tuottamaa monipuolista tekstin analysointiohjelmistoa GATE:a [GATE]. Ohjelmisto osoittautui kuitenkin kaikkea muuta kuin sopivaksi reaaliaikaiseen kalenteripalvelimeen nopeutensa puolesta. Ohjelmisto päätettiin hylätä tämän vuoksi.

Kielellisen älykkyyden myöhemmin lisäämistä varten arkkitehtuuriin jätettiin kuitenkin selkeä oma paikkansa.

Yksi vaihtoehto olisi ollut tehdä oma kielellistä älyä sisällään pitävä analysaattori. Tämä ei kuitenkaan kuulunut missään määrin projektin tavoitteisiin, joten päätettiin toteuttaa hyvin yksinkertainen avainsanoihin perustuva kielellinen älykkyys (ks. tekninen määrittely).

• Monipuolinen kielellinen analyysi ei onnistu sovellukselta, vaan analyysi perustuu avainsanoihin.
• arkkitehtuurissa on paikka myöhempää integrointia varten.

Tekninen määrittely.

2.2.3. Kalenterimerkintöjen tallentaminen

Relaatiokannan käyttö kalenterivarastona

Kalenterivarastoksi tarvittiin persistentti varasto ja yksinkertaisesti helpoimmaksi vaihtoehdoksi todettiin relaatiokannan (RDBMS) käyttö JDBC-yhteyden avulla.

Lisäksi relaatiokantoja löytyy useita kappaleita ilmaisversioina, minkä katsottiin olevan selkeä etu projektin luonteen vuoksi.

Objektipohjainen tietokanta (ODBMS) olisi tarjonnut suoremman konversion sisäisen iCalendar-objektirakenteen ja tietokannan välillä, mutta toimivia vapaasti levitettäviä ja laajasti käytössä olevia oliokantoja ei ole olemassa. Relaatiokantaa käytettäessä syntyi jonkin verran ns. mapping koodia relaatiosta sisäiseen objektimuotoon ja päinvastoin.

• JDBC-yhteyden avulla useimmat kannat käyttökelpoisia kalenterivarastoina.
• Useita ilmaisvaihtoehtoja varastoiksi.
• Relaatioiden ja objektiesitysmuotojen erojen vuoksi syntyy ylimääräistä mapping koodia.

Tekninen määrittely

2.2.4. Yksikkötestaus

JUnitin käyttö yksikkötestauksessa

Muutettaessa jotain kohtaa ohjelmasta, on helppo rikkoa muita siitä riippuvia osia. JUnitin avulla on mahdollista automatisoida testit, jotka tarkastavat koko ohjelman toiminnan. Toisekseen yksittäiset moduulit saadaan niitä toteuttaessa helposti testattua, kun testikoodia varten ei tarvita erillisjärjestelyitä.

JUnit testit ovat vielä vaiheessa T3 laajamittaisesti toteuttamatta.

Muita testausohjelmia ei juuri tutkittu JUnitista kuultujen positiivisten kokemusten vuoksi, lähinnä eXtreme Programming -prosessin kanssa käytettynä. Vaihtoehtona oli lähinnä yksikkötestien tekemättä jättäminen ja luottaminen siihen, että ohjelman uudelleenkääntäminen ja pieni testiajo paljastavat riippuvuudet.

• Ohjelmakoodi pysyy ehjänä muutoksista huolimatta
• Helpottaa testikoodin kirjoittamista

Testaussuunnitelma
http://www.junit.org/
http://www.extremeprogramming.org/

2.2.5. Suodattimet

Javalla toteutetun suodatinjärjestelmän käyttö

Koska eri kalentereiden tapahtumia yhdistellessä dataa tulee varsin paljon, tarvittiin joustava tapa valita kiinnostavimmat. Monipuolisen suodatuksen toteuttaminen oli yksinkertaisinta serverissä muutenkin käytössä olevalla kielellä, eli Javalla. Suodatinten dynaaminen luonne oli helppoa toteuttaa ohjelmoimalla eri tarkoituksia varten yksittäisiä suodattimia ja panemalla niitä sopivassa järjesteyksessä, ja eri parametreilla peräkkäin. CPU-kuormaa saadaan myös siirrettyä helpommin hajautettaville käyttäjien henkilökohtaisille servereille päin suosittujen paikkaservereiden sijaan.

Jonkinlaista suodatusta oltaisiin voitu tehdä myös CAP-protokollaan kuuluvilla SQL-kyselyillä, mutta sillä ei oltaisi saatu aikaan riittävän monipuolista järjestelmää.

• Uusien suodatinten tekeminen yksinkertaista
• Aiheutettu lisäkuorma asiakasservereille
• Uuden suodatintyypin tekeminen vaatii ohjelmointia

2.2.6. Moduulit

Älyominaisuuksien sijoittaminen jalostajamoduuleihin ja parametrien kuljettaminen icalendarin categoryissä.

Arkkitehtuurin on tarkoitus olla pohja jatkotutkimukselle ja mahdollistaa mielivaltaisten älyominaisuuksien lisääminen. Ainoa mahdollinen tapa toteuttaa tällainen rakenne on tunkea älytoiminnot jonkinlaiseen mustaan laatikkoon, niin että meillä on käytössä minimaalinen rajapinta, joka antaa maksimaalisen vapauden itse moduulille.

Ensimmäisen tarvekartoituksen perusteella sopivaksi rajapinnaksi löytyi profiilin ja VEventin välittäminen jalostajamoduulille. Profiili kuitenkin havaittiin pian tarpeettomaksi osassa moduuleista, samoin VEvent huomattiin liian suppeaksi tavaksi välittää tietoa. Muokattu rajapinta ottaa vastaan VCommand-olion ja näyttää riittävän hyvin monimutkaistenkin moduulien tarpeisiin.

Moduulit tarvitsevat myös paikan, jonne tallettaa generoimaansa tietoa. Sen sijaan että olisimme tarjonneet moduuleille tavan tallettaa mielivaltaista tietoa päädyimme toteuttamaan tietovaraston pelkkinä arvopari merkkijonoina CAP:n categories-kenttiin. Moduulit voivat siis tallettaa mitä tahansa, kunhan pystyvät ilmaisemaan sen avain-arvo -merkkijonoparina.

Vaihtoehtona oli älytoimintojen liittäminen kalenterioperaatiomoduuliin ja moduulien tarvitsemien kenttien lisääminen suoraan icalendar-tietorakenteisiin. Tämä olisi lyhyellä tähtäimellä helpottanut tehtävää, mutta ratkaisuna se olisi ollut ala-arvoinen.

Nykyisen toteutuksen vaihtoehtona mietittiin myös useampivaiheisia jalostajamoduuleita Apache-moduulien tyyliin. Apachessa moduulit voivat liittyä työnkulun eri vaiheisiin: autentikointiin, urlin uudelleenkirjoitukseen, sisällöntuottoon. Tämä vaihtoehto hylättiin kuitenkin sen vaatiman ylimääräisen työmäärän takia, mutta sitä voisi tutkia myöhemmin uudestaan. Nyt lähes sama toiminnallisuus saadaan efektiivisesti moduulien tarkalla latausjärjestyksellä (esim. autorisointimoduuli ladataan ennen muita jalostajamoduuleita).

Lisäksi hyödyllinen ominaisuus jalostajilla olisi mahdollisuus "äänestää", joidenkin kenttien arvosta. Voi nimittäin olla, että moduuli on jostain asiasta vain esimerkiksi 50%:n varma. Tällöin jonkun toisen moduulin päättely voisi varmistaa tapahtuman todeksi. Tätä toiminnallisuutta ei ajanpuutteen vuoksi sen kummemmin suunniteltu.

• Uusien suodatinten tekeminen yksinkertaista
• Aiheutettu lisäkuorma asiakasservereille
• Uuden suodatintyypin tekeminen vaatii ohjelmointia

Tekninen määrittely.

2.2.7. Todo- ja tapahtumamerkinnät

Tekninen määrittely.

2.3. Asiakasohjelmistoon liittyvät päätökset

2.3.1. Toteutusarkkitehtuuri

Asiaskasohjelmisto toteutetaan Java-Servlettinä

Asiakasohjelmistoa voidaan näin käyttää miltä tahansa päätelaitteelta, jolta löytyy WWW-selain, joka tukee kehyksiä. Ohjelmiston ulkoasu on suunniteltu käytettäväksi täysikokoiselta grafiikkanäytöltä, mutta käyttö onnistuu myös tekstiselaimella tai jopa PDA:lla. Muokkaus kyseisille laitteille sopivammaksi on helppo suorittaa myöhemmin.

Itsenäisen ohjelman toteuttaminen katsottiin liikaa aikaa vieväksi. Käyttöliittymän tekemiseen kuluva aika olisi pois toiminnallisuuden toteuttamiselta. WWW-ympäristössä käyttöliittymä on jo toteutettu valmiiksi WWW-selaimien kautta.

JSP-sivut olivat tasa-arvoisessa asemassa Java-Servlettien kanssa alustaa valittaessa, joten valinta suoritettiin henkilökohtaisten preferenssien perusteella.

Valmiit kalenteriohjelmistot hylättiin vapaasti muokattavan ohjelmiston löytämisen mahdottomuuden vuoksi. Kaupalliset ja suljetut ratkaisut eivät sovi projektin luonteeseen.

• Ohjelmiston käyttö vaatii WWW-selaimen ja TCP/IP-yhteyden.
• Ohjelmiston käyttö ei vaadi mitään tiettyä ympäristöä tai erikoisosaamista.

Tekninen määrittely, Asiakasohjelmistoliite

2.3.2. Yksittäisten HTML-sivujen toteutus

Kaikki asiakasohjelmiston WWW-sivut toteutetaan Java-luokkina.

Projektin alkuvaiheessa ei vielä ollut tiedossa, mitkä servlet-sivut tulisivat olemaan staattisia ja mitkä dynaamisia. Kaikkien sivujen tuottaminen Java-luokkien avulla mahdollisti toiminnallisuuksien helpomman luomisen mille tahansa servlet-sivulle.

Staattiset servlet-sivut olisi ollut mahdollista (ja helpompaakin) luoda suoraan puhtaina HTML-sivuina, joita kutsuttaisiin kuten mitä tahansa muitakin WWW-sivuja. Tällöin kuitenkin sivun muutaminen servlet-sivuksi tarpeen niin vaatiessa olisi ollut hankalampaa kuin alunperin ko. HTML-sivun toteuttaminen suoraan Java-luokkana.

Puhtaat HTML-sivut ovat kuitenkin kevyempiä käsitellä kuin Java-luokat, joten asiakasohjelmiston ajo kuluttaa nyt tarpeettomasti resursseja generoimalla staattiset servlet-sivut Java-virtuaalikoneella. Koska stattisia sivuja on kuitenkin suhteellisesti vähän dynaamisiin sivuihin verrattuna, kokonaishäviö ei ole merkittävä.

• Asiakasohjelmisto on hieman raskaampi kuin tarpeellista.
• Asiakasohjelmiston muokkaus on nyt huomattavasti helpompaa kuin silloin, jos servlet käyttäisi HTML-sivuja ja Java-luokkia sekaisin.

-

2.3.3. Merkkien suodattaminen

Kalenteripalvelin hyväksyy mm. tapahtumien kuvaamisessa vain puhdasta tekstiä, numeroita yms. "tavallisia" merkkejä.

Tällä taataan, että kalenteripalvelin pysyy toimintakykyisenä missä tahansa asiakasohjelmistoympäristössä, jossa palvelimelle saatetaan syöttää vahingossa tai tahallaan vääränlaista dataa.

Suodatus toteutettaisiin asiakasohjelmistossa. Vaihtoehto ei ole hyväksyttävä, sillä mahdollinen asiakasohjelmiston virhe saattaa aiheuttaa sen, että kalenteripalvelimen toiminta keskeytyy väärässä paikassa olevaan kontrollimerkkiin.

• Käyttäjien vapautta muokata kalenterimerkintöjä rajataan voimakkaasti.
• Asiakasohjelmiston toteutus ei vaikuta palvelimen toimintaan.

-

[CAP] S. Mansour, D. Rouer, G. Babics, Calendar Access Protocol (CAP), www.ietf.org/internet-drafts/draft-ietf-calsch-cap-03.txt, viitattu 5.2.2001

[GATE] GATE-projekti, GATE - General Architecture for Text Engineering WWW-sivut, http://www.dcs.shef.ac.uk/research/groups/nlp/gate, viitattu 5.2.2001

[RFC2445] Dawson, F. Stenerson, D. Internet Calendaring and Scheduling Core Object Specification (iCalendar), ftp://ftp.funet.fi/pub/standards/RFC/rfc2445.txt, viitattu 5.2.2001