Viimeksi päivitetty $Date: 2001/04/20 13:41:35 $
Dokumentti kuvaa Teknillisen korkeakoulun Tietojenkäsittelyopin ohjelmistotyö kurssin Tik-76.115 tehtävän Osprey-projektin toiminnallisen määrittelyn. Projektin tarkoituksena on luoda pohja uuden sukupolven älykkäille kalenterisovelluksille luomalla kalenteriarkkitehtuuri, joka käyttää hyväkseen sekä lokaatiopohjaista tietoa että kalenterimerkinnöistä pääteltyä tietoa. Arkkitehtuuri mahdollistaa edelleen sen päälle loppukäyttäjille suunnattujen palveluiden rakentamisen.
Projektin tuloksena syntyvä kalenteriarkkitehtuuri ja sen toteutus mahdollistavat perinteisten kalenteritoimintojen kuten merkintöjen selailun, lisäämisen ja poistamisen lisäksi myös joukon uuden tyyppisiä toiminnallisuuksia. Paikkatiedon liittäminen kalenterimerkintöihin mahdollistaa mm. käyttäjän kalenterimerkintöjen fyysisen etäisyyden päättelyn ja paikkasidonnaisten lisätietosivujen selailun. Kieliteknologian käyttö auttaa tiedon löytämisessä ja suodattamisessa. Perinteisistä kalentereista poiketen kalenteriarkkitehtuuri mahdollistaa käyttäjän antamien ToDo-merkintöjen automaattisen ajoittamisen paikkatietoa hyväksikäyttäen.
Kalenteriarkkitehtuuriin kuuluvat olennaisena osana liitynnät ulkoisiin palveluihin. Esimerkiksi välimatkojen arviointi ja paikkasidonnaisen lisätiedon tarjoaminen ovat sangen oleellisia palveluita, mutta niiden toteuttaminen kuuluu selvästi muille osapuolille. Projektissa ei tästä syystä tulla keskittymään em. palveluiden implementointiin, vaan arkkitehtuurin suunnitteluun palveluiden käytön mahdollistavaksi.
Arkkitehtuurissa ei kiinnitetä suorituskykyyn erityistä huomiota muutoin kuin että arkkitehtuurin toteutuksen käytettävyys säilyy. Suorituskykyä ei kuitenkaan tulla rajaamaan tarpeettomasti suunnittelupäätöksillä. Arkkitehtuurissa ei oteta mitään kantaa vikasietoisuuteen.
Esimerkkitoteutus kalenteriarkkitehtuurista tullaan implementoimaan Java 2 Standard Edition -kehitysympäristöä käyttäen. Lähdekoodi tullaan dokumentoimaan JavaDoc-muotoa käyttäen.
Kalenteriarkkitehtuurin toimivuutta tullaan demonstroimaan toteuttamalla esimerkkikalenteriohjelmisto, joka todentaa arkkitehtuurin toimivuuden.
1. JOHDANTO
1.3 Määritelmät, termit ja lyhenteet
2. YLEISKUVAUS
3. TIEDOT
4. TOIMINNOT
4.1 Kalenterimerkintöjen selaus
4.1.2 Merkintäjen näyttäminen eri väreillä
4.1.3 Sanahaku kalenterin merkintöihin
4.2 Kalenteritapahtumien merkintä, poisto ja muuttaminen
4.3 Kayttäjän profiilin muokkaus
4.3.1 Käyttäjä muokkaa profiilia
4.3.2 Profiilin automaattinen muokkaus
4.4 Tapahtumapaikkojen välimatkan ja matka-ajan arviointi
4.4.3 Välimatkan ja matka-ajan automaattinen arviointi
4.5 Ennakoiva hälyttäminen tapahtumista
4.5.1 Hälyttäminen tapahtumasta
4.5.2 Hälytysajan määrittäminen
4.6.1 Paikkojen kalenterien tiedon näyttäminen käyttäjälle
4.6.2 Paikkojen kalenterien ylläpito
4.6.3 Tiedon etsiminen paikkojen kalentereista
4.6.4 Tiedon näyttäminen käyttäjälle tapahtumasivujen kautta
4.7 Lähialueen kalenterimerkintöjen näyttö
4.7.2 Käyttäjän lähellä olevien muiden kalenterien tunnistaminen
4.7.3 Käyttäjän paikkahistorian tallennus
4.7.5 Eräiden tietojen korostamista
4.8 Käyttäjän sijainnin ennakointi
4.8.1 Kartta käyttäjän tulevasta kulusta
4.8.2 Tulevien tapahtumien näyttö
4.9 Kalenterimerkintöjen yhteyksien havaitseminen
4.9.1 Tapahtumien yhteyksien havaitseminen kielellisesti
4.9.2 Tapahtumien yhteyksien havaitseminen paikkatietojen perusteella
4.10 Kalenterimerkintöjän linkittäminen kalenterien välillä
4.11 Muutosten propagointi linkitetyissä kalentereissa
4.11.2 Muutoksen päivittyminen automaattisesti kaikille asianosaisille
4.11.3 Muutoksen päivittyminen ilmoituksella automaattisesti kaikille asianosaisille
4.11.4 Hyväksymisehdotus muutoksesta käyttäjälle
4.11.6 Muutostiedon propagointi epäonnistuu
4.12.1 Todo-merkinnän lisäys kalenteriin
4.12.2 Todo-merkinnän muuttaminen
4.12.3 Todo-merkinnän poistaminen
4.13 Todo-merkintöjen suorituksen ajoittaminen
4.13.1 Todo-merkintöjen sijoittaminen kalenteriin
4.13.2 Todo-merkintöjen suoritusajan lukitseminen
4.14 Paikkaan sidottujen merkintöjen selaaminen olematta fyysisesti paikalla
4.14.1 Paikkojen haku sanahaulla
4.14.2 Paikkojen haku koordinaattihaulla
4.14.3 Paikkojen haku tulevan tapahtuman perusteella
4.14.4 Paikan tietojen selaus tapahtumasivulla
5. ULKOISET LIITTYMÄT
5.1.1 Tietoa tuottavat lisälaitteet
5.2.2 Kalenterien tunnistus ja niiden oikeudet
5.2.3 Muut ohjelmistoliittymät
6. MUUT OMINAISUUDET
6.1 Suorituskyky ja vasteajate
6.2 Käytettävyys, toipuminen, turvallisuus, suojauksete
6.4 Siirrettävyys/kannettavuus, yhteensopivuus
7. SUUNNITTELURAJOITTEET
8. JATKOKEHITYSAJATUKSIA
0.1 |
2.11.2000 |
Ensimmäinen versio |
Juha, Kari, Niko, Teemu |
1.0 |
5.11.2000 |
T1-vaiheen palautus |
Juha, Kari, Niko, Santeri, Teemu |
1.2 |
20.4.2001 |
LU-vaiheen muutokset |
Santeri |
Kappaleesta 3 ja 7 XML-viitteet poistettu. Lisäksi Teknisen määrittelyn yhteydessä tehtiin asiakasohjelmiston käyttöliittymästä oma dokumentti, jossa on esitetty käyttöliittymän ei-teknisiä toiminnallisuuksia [OSPREY-K].
Tämä dokumentti sisältää lopputuotteen toiminnallisen määrittelyn asiakkaan kanssa tehdyn sopimuksen mukaisesti. Dokumentti on suunnattu projektin jatkokehityksen kanssa työskenteleville suunnittelijoille.
Toiminnallinen määrittely kattaa peruskalenteriarkkitehtuurin toiminnallisuuden ja edelleen arkkitehtuurilla toteutettavissa olevat toiminnallisuudet. Näistä osaa tullaan demonstroimaan esimerkkikalenteriohjelmistolla. Projektin tutkimusluonteesta johtuen dokumentti on kuitenkin vasta alustava kuvaus lopullisesta toiminnallisuudesta. Dokumentissa on kuvattu erikseen kalenteriarkkitehtuurin mahdollistamat toiminnot ja toteutettavat toiminnot.
Tämä dokumentti on osa Osprey-projektia, jonka tavoitteena on määritellä älykäs kalenteriarkkitehtuuri ja toteuttaa ko. arkkitehtuuria soveltava kalenterirunko. Älykkyys tässä tapauksessa tarkoittaa paikannustiedon ja kalenterimerkinnöistä päätellyn tiedon hyväksikäyttöä ja kalenterien ad hoc -verkottumista.
[OSPREY-CC] Kari Hiitola, Projekti Ospreyn ohjelmointikäytäntö, codeconv.html, viitattu 2.11.2000
[OSPREY-K] Osprey-ryhmä, Projekt Ospreyn kalenteriasiakasohjelmiston toiminnallinen määrittely, toiminnallinenmaarittely-kayttoliittyma.html, viitattu 10.12.2000
[OSPREY-T] Osprey-ryhmä, Projekti Ospreyn termistöä, termit.html, viitattu 2.11.2000
[RFC2445] Dawson, F. Stenerson, D. Internet Calendaring and Scheduling Core Object Specification (iCalendar), ftp://ftp.funet.fi/pub/standards/RFC/rfc2445.txt, viitattu 2.11.2000
[SUN-JDOC] Sun Microsystems, How to Write Doc Comments for Javadoc, http://java.sun.com/products/jdk/javadoc/writingdoccomments/index.html, viitattu 2.11.2000
Dokumentin ensimmäinen kappale pitää sisällään lyhyen johdannon, kertoo dokumentin tarkoituksen ja määrittelee dokumentissa myöhemmin käytettävät termit.
Toinen kappale esittelee kalenteriarkkitehtuurin ympäristön ja toiminnan. Myös käyttäjäryhmä sekä yleiset rajoitteet ja oletukset ovat tiivistetysti kuvattu kappaleessa.
Kolmas kappale kuvaa kalenteriarkkitehtuurin tietosisältöä.
Neljäs kappale määrittää tämänhetkisen tietämyksen pohjalta kalenteriarkkitehtuuriin liittyvät toiminnot.
Viides kappale kuvaa toiminnallisesti kalenteriarkkitehtuurin liitynnät ulkoisiin järjestelmiin.
Kuudes kappale keskittyy muihin kuin em. kappaleissa mainittuihin ominaisuuksiin. Kappaleessa kuvataan mm. arkkitehtuurin suorituskykyyn, käytettävyyteen, virheistä toipumiseen, turvallisuuteen, suojaukseen ja ylläpidettävyyteen liittyviä ominaisuuksia. Myös siirrettävyyteen ja operointiin liittyvät ominaisuudet käsitellään.
Seitsemäs kappale kuvaa arkkitehtuurin muut suunnittelurajoitteet standardien, ohjelmisto- ja laitteistorajoitteiden muodossa.
Kalenteriarkkitehtuurin ympäristö ja kalenterin suhde siihen on kuvattu vaatimusmäärittelyn kappaleessa 2.1.
Kalenteriarkkitehtuuri mahdollistaa kalenteriasiakasohjelmistoille tarkoitetun palvelurajapinnan kautta perusominaisuuksina mm. kalenterimerkintöjen tekemisen ja muokkauksen, erilaiset tapahtumanäkymät, tapahtumahälytykset, paikkahistorian ja -tulevaisuuden selailun, käyttäjäprofiilin käytön ulkopuolelta tulevien tapahtumien suodattamiseen ja ToDo-merkintöjen dynaamisen allokoinnin kalenterimerkinnöiksi.
Em. toimintojen arkkitehtuurin toteutukseen lisätään erilaisia kalenterimerkintöihin perustuvia lisäinformaatiopalveluita, kuten merkintöjen välisten yhteyksien löytäminen kielellisellä tulkinnalla, tapahtumiin liittyvien informaatiosivujen haku ja tapahtumapaikkojen välillä liikkumiseen tarvittavan ajan ja reitin arviointi.
Näistä perustoiminnoista ja lisäpalveluista tullaan arkkitehtuuria demonstroivaan esimerkkikalenteriohjelmistoon toteuttamaan vain osa priorisoiden tärkeimpiä perustoimintoja. Lopuista toiminnoista ja palveluista toteutetaan ne, jotka katsotaan tarpeelliseksi arkkitehtuurin kokonaisvaltaisen toimivuuden osoittamisen kannalta.
Lopullinen kalenteriarkkitehtuuri on tarkoitettu kaikenlaisten käyttäjien tarpeiden toteuttamisen mahdollistamiseen. Kalenteriarkkitehtuurin laajennettavuus takaa sen, että uusien käyttäjäryhmien kohdalla tuotetaan vain uusia palveluita arkkitehtuurin implementaation käytettäväksi.
Kalenteriarkkitehtuurin toteutusta demonstroiva esimerkkikalenteriasiakasohjelmisto rajaa käyttäjäryhmäksi teekkarit. Se toimii pohjimmiltaan teekkarikalenterin elektronisena versiona, johon on lisätty mm. paikkatietoon pohjautuvia lisäarvopalveluita. Asiakasohjelmiston käyttöönotossa on avuksi, jos käyttäjä on aikaisemmin käyttänyt elektronisia kalentereita ja on tutustunut teekkarikalenteriin.
Projektin luonteen vuoksi loppukäyttäjälle monipuolisten ominaisuuksien toteuttamiseen ei keskitytä, vaan rajoitetaan kehitystyö helposti laajennettavan ja myöhemminkin kehitettävän alustan luomiseksi. Toteutettava asiakasohjelmisto ja kalenteripalvelin esittelevät arkkitehtuurin mahdollisuudet, mutta jättävät tien auki tuleville laajennuksille.
Tehtäväkentästä rajataan siis pois esim. täydellinen kielellinen älykkyys ja reaalimaailmassa toimiva käyttäjän GPS-paikannus. Nämä tullaan simuloimaan yksinkertaisemmilla versioilla tai simulaatiolla. Myöskin paikannussimulaatiossa rajoitutaan vain Otaniemen alueelle, sillä koko maailman simuloiminen veisi turhia resursseja, koska tarvittava toiminnallisuus voidan esitellä myös pienempään alueeseen rajoittuen.
Kaikki projektin lopputuotteena syntyvät dokumentit, ohjelmat ja lähdekoodit julkaistaan GNU General Public License:n alaisena. Tämä antaa kaikille kiinnostuneille mahdollisuuden projektin jatkokehitykseen ja hyödyntämiseen.
Kalenteriarkkitehtuurissa tullaan käyttämään sisäisenä esitysmuotona iCalendar-standardin mukaista kuvausta laajennettuna tarpeen mukaan.
Arkkitehtuurin toteutukselle vaaditaan suorituskykyinen laitteisto TCP/IP-verkkoyhteyksillä. Kehitysympäristönä tullaan käyttämään Java 2 Standard Edition -ympäristöä. Esimerkkikalenteriasiakassovelluksen kehitysympäristöä ei ole vielä päätetty.
Lopullinen kalenteritoteutua ei sisällä salaus-, allekirjoitus- ja autentikaatiometodeja, mutta arkkitehtuuri tulee tarjoamaan rajapinnan salauspalveluja varten. Tämä rajapinta määritellään myöhemmin.
Toimivan kalenterisovelluksen tulee käyttää julkisen avaimen salausalgoritmeja yhteyksien salaamiseen ja allekirjoittamiseen. Allekirjoituksella varmennetaan vastapuolen identiteetti ja yhdessä salauksen kanssa varmistetaan, että henkilökohtaiset kalenteritiedot eivät joudu vääriin käsiin. Salaus- ja allekirjoitusavaimien oikeellisuus todennetaan esimerkiksi julkisen avaimen infrastrukturin mukaisilla luotettavan kolmannen osapuolen (Trusted Third Party, TTP) luovuttamilla sertifikaateilla.
Kalenterimerkinnät tallennetaan käyttäen iCalendar merkintöjä [RFC2445]. iCalendarin määrittelemien kenttien lisäksi käytämme kalenterimerkinnöissä omia laajennuksia, joiden avulla kalenterimerkinnöistä saadaan lokaatio- ja kontekstisensitiivisiä.
Perinteisten kalenterien merkinnät sisältävät vain ajan ja käyttäjän määrittelemän vapaan tekstin. Tämän projektin kalenterimerkintä tulee sisältämään mm. tiedon paikasta, lisäinformaatiota kalenterimerkinnän kontekstin perusteella sekä linkkejä muihin merkintöihin. Nämä laajennukset määritellään myöhemmin.
Arkkitehtuurille ja esimerkkisovellukselle asetettavat suorituskykyvaatimukset määritellään projektin seuraavassa vaiheessa.
Koska esimerkkisovelluksen tehtävänä on ainoastaan osoittaa arkkitehtuurin toimivuus, sen suorituskyvylle ei aseteta suuria vaatimuksia. Lähtökohtana on selvitä yhden käyttäjän normaalikäytöllä aiheuttamasta kuormasta, joskin vaatimusta voidaan kasvattaa myöhemmin.
Arkkitehtuurille ja esimerkkisovellukselle asetettavat kapasiteettivaatimukset määritellään projektin seuraavassa vaiheessa.
Toiminnot on muodostettu vaatimusmäärittelyn pohjalta. Pääotsikkoina ovat toiminnallisten vaatimusten otsikot vaatimusmäärittelystä ja niiden alla on listattu niihin kuuluvat toiminnot. Kunkin toiminnon perässä on viite [TVAATxx], joka kertoo, mihin vaatimusmäärittelyn vaatimukseen se on jäljitettävissä. Kaikkia toimintoja ei määritellä vielä tässä vaiheessa. Priorisointi on määritelty vaatimusmäärittelyssä. Toteutetut toiminnot demonstroidaan esimerkkikalenteriasiakasohjelmistolla.
Käyttöliittymässä on mahdollisuus valita päivä-, viikko-, kuukausi- tai vuosinäkymä. Varsinaisia merkintöjä pystyy tekemään ja näkemään päivä- ja viikkonäkymissä, muut ovat mukana helpottamassa navigointia. Lisäksi on tabeja, joista saa erillisiä tapahtumasivuja tai muuta informaatiota. [TVAAT02]
Värikoodauksen avulla voidaan kalenterin merkinnät erottaa toisistaan helposti. Käyttäjän omat merkinnät erottuvat ulkoa tarjotuista ja käyttäjä voi nähdä tärkeät tapahtumat nopeasti. Lisäksi esimerkiksi tapahtumaan tullut muutos näkyy aina tietyllä värillä, jolloin se havaitaan. Tämä toiminto parantaa kalenterin käytettävyyttä. [TVAAT04]
Kun kalenterimerkintöjä on paljon, voi tietyn tapahtuman löytäminen olla vaikeaa. Perusnavigointiapuna kalenteri tarjoaa sanahaun, jolla tiettyjä sanoja voi etsiä ainakin omista merkinnöistä ja tarjotuista tapahtumista. Hakuun voidaan liittää lisäehtoja kuten tapahtuman tyyppi ja paikka. Haun aikaväli voidaan myös rajata, samoin käytetty kalenteri. Haulla on mahdollista hakea ainoastaan muiden kalenterien sillä hetkellä tarjoamia julkisia tapahtumia; muunlaiseen tutkimiseen ei tietoturva- ja tehokkuussyistä tarjota mahdollisuutta. [TVAAT03]
Peruskalenterimerkintä sisältää ajan, keston ja lyhyen sanallisen kuvauksen tapahtumasta. Merkintään voidaan myös liittää lisätietoa kuten paikka ja tyyppi, mutta näitä ei määritellä vielä tarkemmin. Kalenteri pyrkii mahdollisuuksien mukaan päättelemään tapahtuman kuvauksesta automaattisesti lisätietoa ja täydentämään merkintää ilman käyttäjän vuorovaikutusta. Kalenteri varoittaa haluttaessa, jos tapahtuma menee päällekkäin jo olemassaolevan merkinnän kanssa. [TVAAT05]
Kalenteriin aikaisemmin tehdyn merkinnän poistaminen. Poiston voi tehdä käyttäjä itse, tai sitten kalenteri ehdottaa sitä automaattisesti saatuaan esim. tiedon kyseisen tapahtuman peruuntumisesta. Kalenteri ei kuitenkaan automaattisesti poista merkintöjä, jotta vältytään tiedon vahingossa tuhoutumiselta. [TVAAT06]
Tehtyä merkintää voi muuttaa, siihen voi lisätä tietoa tai sen voi siirtää eri ajankohdalle. Muutos voi olla käyttäjän itsensä tekemä, tai kalenteri voi ehdottaa sitä saadessaan lisätietoa. Muutos tarvitsee - asetuksista riippuen - vahvistuksen käyttäjältä. [TVAAT07]
Käyttäjän profiili sisältää parametrit, joiden avulla kalenterin toiminta mukautetaan käyttäjän mieltymysten mukaiseksi [TVAAT08]. Profiili sisältää ainakin seuraavat parametrit:
Kalenteri seuraa käyttäjän liikkumista ja kalenterimerkintöjä ja päättelee niiden perusteella käyttäjän mieltymyksiä. Käyttäjän asetusten perusteella profiilia voidaan joko muokata automaattisesti tai sitten muutokset hyväksytetään käyttäjällä. Profilointi kapsuloidaan omaan moduuliin, joten profilointitapaa on helppo muuttaa. Profilointi tullaan toteuttamaan avainsanojen esiintymisiä tarkkailemalla.
Kalenteri pyrkii selvittämään, mihin paikkaan mikäkin merkintä viittaa. Kun paikat ja niiden välimatka on selvillä, on mahdollista arvioida välin kulkemiseen kuluvaa aikaa. [TVAAT12]
Koska kahden pisteen välin kulkemiseen kuluvan ajan päättely ei ole lainkaan triviaalia, matka-ajan arviointi toteutetaan omana helposti vaihdettavana modulinaan. Moduli voi esimerkiksi ottaa yhteyden johonkin alueen palvelimeen, joka tietää paikallisia matka-aikoja. [TVAAT13]
Matka-ajan arviointi suoritetaan yksinkertaisesti kertomalla välimatka jollain aikavakiolla.
Käyttäjän tehdessä kalenteriinsa merkintöjä kalenteri pystyy toiminnon 4.4 avulla tarkistamaan paikasta toiseen siirtymiseen vaadittavat ajat ja aikatauluttamaan tapahtumat niin, että aikaa riittää siirtymiseen.
Kalenteri muistuttaa käyttäjäänsä sopivan aikaa ennen tapahtumaa. Hälytys voi tapahtua usealla eri tavalla kuten GSM-lyhytviestillä tai äänimerkillä käyttäjän tietokoneessa. [TVAAT14]
Hälytysaika asetetaan joko käyttäjän asettamalla ennakolla tai päättelemällä luvussa 4.4 määritellyllä tavalla aika, joka käyttäjällä menisi siirtymiseen nykyisestä sijainnistaan tapahtuman sijaintiin. [TVAAT15]
Tiettyihin sijainteihin voidaan liittää oma kalenteri. Esimerkiksi luentosalilla voi olla oma kalenterinsa.
Paikkojen kalenterit toimivat muuten kuin tavalliset käyttäjien kalenterit; erona on ainoastaan tarve monipuolisemmalle oikeuksien hallinnalle: Paikat eivät itse täytä omaa kalenteriaan, vaan merkinnät tekee aina joku muu. Yleensä merkintöjen teko on lisäksi rajoitettu johonkin tiettyyn käyttäjäryhmään ja silloinkin tietyin reunaehdoin. [TVAAT16]
Yksittäisen paikan kalenteri voidaan valita katseltavaksi, jolloin näytetään vain kyseisen paikan kalenterin tiedot. Tiedot näytetään samaan tapaan kuin kohdassa 4.1 on kuvattu. [TVAAT17]
Paikkojen kalenterien ylläpidossa on käytössä samat toiminnot kuin tavallisen kalenterinkin muokkauksessa (ks. 4.2). Erona on ainoastaan tiettyjen älytoimintojen jääminen pois (esimerkiksi. tapahtuman linkittäminen) ja se, että tietoja muokkaa toinen käyttäjä. [TVAAT18]
Paikkojen kalentereista voidaan etsiä tapahtumia hakusanoilla tai ajan perusteella. Haku voidaan ulottaa joko yhden paikan kalenteriin tai kaikkiin sillä hetkellä auki oleviin kalentereihin. [TVAAT19]
Eri paikkojen kalentereista voidaan näyttää yhdistelmä tapahtumia. Tapahtumia voidaan myös suodattaa. [TVAAT20]
Kalenteri saa selville käyttäjän sijainnin, jota käytetään apuna muiden toimintojen toteuttamisessa. Paikantaminen on kätketty omaan moduliin, joten paikannusteknologian kehittyessä uusien paikannustapojen käyttöönotto on helppoa. [TVAAT21]
Paikkatiedon perusteella haetaan paikkojen kalentereita käyttäjän määrittelemän etäisyyden sisäpuolelta. [TVAAT22]
Käyttäjän sijaintitiedosta jää jälki, jonka perusteella hän voi myöhemmin seurata liikkeitään tai katsoa kalenterimerkinnät, jotka ovat olleet näkyvissä hänen ollessaan jossain aikaisemmassa sijainnissa. [TVAAT23]
Koska lähiseudun kalenterimerkintöjä voi olla paljon, kalenteri suodattaa pois merkintöjä, jotka todennäköisesti eivät kiinnosta käyttäjää. Tätä varten analysoidaan merkintöjä ja verrataan sitä käyttäjän profiiliin. [TVAAT24]
Suodatusta vastaavalla tekniikalla kalenteri myös korostaa visuaalisin keinoin osaa tapahtumista, jotka todennäköisesti ovat erityisen kiinnostavia.
Kalenteriin merkittyjen tapahtumien sijaintitiedon perusteella kalenteri ennakoi käyttäjän sijainnin kullakin hetkellä. [TVAAT25]
Tulevan sijaintitiedon perusteella kalenteri näyttää kyseisen paikan tapahtumat samaan tapaan kuin käyttäjä olisi fyysisesti jo kyseisellä paikalla kuten kohdassa 4.7.
Kalenterimerkintöjen yhteyksiä havaitaan kohdissa 4.9.1-3 merkityillä tavoilla, yhdistämällä näitä käikkia tapoja keskenään. Merkintöjen välille voidaan luoda linkkejä, jotka kytkevät tapahtumia toisiinsa. [TVAAT30]
Tapahtumien yhteyksien kielellinen havainnointi tapahtuu epäsuorasti. Kielellisellä päättelyllä pyritään hankkimaan lisätietoa kalenterimerkinnästä, mm. tapahtuman tyyppi ja osallistujat. Saatuja lisätietoja käytetään tapahtumien linkitysten selvittämiseen. [TVAAT26], [TVAAT29]
Kalenteri havaitsee muihin kalentereihin kirjoitetut merkinnät, jotka ovat fyysiseltä sijainniltaan omien merkintöjen läheisyydessä. Samoin voidaan päätellä yhteyksiä siitä, että kahden tai useamman tapahtuman merkitseminen on tehty samassa paikassa. Yhteyksiä ei aleta hakemaan mielivaltaisesti kaikkien käyttäjien kesken, vaan hakua täytyy rajoittaa käyttäen hyväksi esimerkiksi käyttäjän määrittelemiä sidosryhmiä. [TVAAT27], [TVAAT28]
Kalenterimerkintä voidaan linkittää toiseen merkintään joko täysin manuaalisesti tai käyttämällä luvussa 4.9 käytettyjä tekniikoita apuna. Linkitettävät kalenterimerkinnät voivat sijaita myös eri kalentereissa. [TVAAT31]
Kullekin linkitetylle tapahtumalle voidaan valita tapa, jolla kalenterissa ilmoitetaan tapahtuman muutoksesta. Yleensä ilmoitustapa on voimassa tapahtumatyypille, mutta tapaa voidaan muuttaa yksittäisiin tapahtumiinkin. [TVAAT32]
Tapahtuman muuttuessa muutos tehdään automaattisesti myös siihen linkitettyihin tapahtumiin ilman käyttäjän interaktiota. [TVAAT33]
Tapahtuman muuttuessa siitä lähetetään ilmoitus niille käyttäjille, joiden kalentereista on linkki tähän tapahtumaan. [TVAAT33]
Kalenteri ilmoittaa muutoksesta käyttäjälle ja pyytää hyväksymään tai hylkäämään muutosehdotuksen. [TVAAT33]
Jonkin kalenterin kieltäytyessä muutoksesta linkki muuttavan kalenterin ja kieltäytyvän kalenterin välillä rikkoutuu. Molemmilla on nyt erilliset ja erilaiset versiot tapahtumasta. [TVAAT34]
Jos muutostietoa ei saada propagoitua kaikille asianosaisille kalentereille, muutoksen tekevä kalenteripalvelin tallettaa muutostiedot ja yrittää lähettää niitä myöhemmin uudestaan.
ToDo-merkintä tarkoittaa tehtävää, joka on suoritettava tietyllä aikavälillä, mutta jolle ei ole vielä määritelty täsmällistä suoritushetkeä. [TVAAT35]
ToDo-merkintä lisätään kalenteriin ja sille määritellään aikaväli, esim. alku- ja loppupäivämäärä, siihen kuluva aika, sekä kellonajat joiden välille se voidaan sijoittaa. Lisäksi tarvitaan paikka, jossa tehtävä voidaan suorittaa, sekä mahdollisesti myös tieto siitä, voidaanko suurikokoinen tehtävä hajauttaa useampaan palaseen. [TVAAT36]
Tietoja, jotka on määritelty edellisessä kohdassa, voidaan myös muokata.
ToDo-merkinnän poistaminen poistaa myös siitä dynaamisesti luodut tapahtumamerkinnät. (4.13)
Kalenteri sijoittaa ToDo-tyyppisinä sisään syötetyt merkinnät automaattisesti tavallisiksi kalenterimerkinnöiksi etsimällä niille sopivan suoritusajan. Tähän kalenteri käyttää luvussa 4.8 kuvattua käyttäjän sijainnin ennakointia, luvussa 4.4 kuvattua siirtymisajan päättelyä ja ToDo-merkinnän parametreina annettuja rajoja suoritusajasta ja -paikasta. [TVAAT37], [TVAAT38]
Kun käyttäjä näkee ToDo-merkinnän sijoitettuna tiettyyn paikkaan, hän voi lukita sen suoritettavaksi kyseisenä aikana. Tämän jälkeen dynaaminen sijoittaminen lakkaa toimimasta, mutta poistamalla lukitus se voidaan jälleen aktivoida. Käyttäjä voi myös syöttää itse ajan, jolloin tehtävän suorittaa. [TVAAT39]
Käyttäjä voi valita paikan, jossa hän haluaa virtuaalisesti sijaita, ja katsella näin tapahtumia, jotka on sidottu kyseiseen paikkaan. Virtuaaliläsnäolon tulee tarjota samat tiedot kuin fyysinen paikallaolo. Palveluille ei myöskään saa käydä ilmi, onko käyttäjä paikalla fyysisesti vai virtuaalisesti. [TVAAT41]
Kalenterille annetaan paikan nimi tai osa siitä, jolloin käyttäjälle voidaan palauttaa lista kuvaukseen sopivista paikoista. Nimitörmäykset voidaan tunnistaa paikkahierarkian perusteella, esim. Suomi-Tampere-Särkänniemi-Planetaario. [TVAAT43]
Kalenterille annetaan suoraan maantieteelliset koordinaatit, jonka perusteella kalenteri antaa tietyllä säteellä sijaitsevat muut kalenterit. Kalenterilistaan voidaan tarvittaessa käyttää jonkinlaista suodatusta esimerkiksi kalenterin tyypin mukaan. [TVAAT43]
Sijainniksi voidaan valita paikka, jossa tapahtuu jokin kalenterissa valmiiksi oleva tapahtuma.
Löydettyyn paikkaan liittyvät tapahtumat voidaan esittää erillisellä tapahtumasivulla, jossa niitä voidaan selailla kuten muitakin kalenterimerkintöjä. [TVAAT42]
Kalenteriarkkitehtuuri ei suoraan liity ulkoisiin laitteistoihin, joten suoria laitteistoliittymiä ei ole.
Kalenteriarkkitehtuurin piirteisiin kuuluu, että tietoa järjestelmän käyttöön voivat tuottaa myös erilaisia lisälaitteita käyttävät tahot. Kalenteriarkkitehtuuri ei kuitenkaan ota näitä erikseen huomioon, vaan tiedontuottajan tehtävänä on huolehtia muutoksesta kalenteriarkkitehtuurin käyttämään tietomuotoon.
Kalenteriarkkitehtuurin tärkein laitteistoliittymä on paikkatiedon hankkiminen. Paikkatietoa tuottaville laitteille ja palveluille on arkkitehtuurissa rajapinta, jonka kautta erilaiset paikkatietolähteet (GPS, GSM-kolmiomittaus, LIF:n tulevat standardit) tuottavat samanarvoista dataa kalenteriasiakasohjelmiston sijainnista.
Lokaatiopalvelurajapinnan ja lokaatiopalvelun väliin jäävän sovittimen tehtävänä on vastata arkkitehtuurin tekemiin abstrakteihin palvelupyyntöihin kyseistä lokaatiopalvelua hyväksikäyttäen. Tarkempi rajapinta tullaan määrittämään myöhemmin, mutta esimerkkinä rajapinnan palveluista mainittakoon mahdollisuus kysyä kahden kalenterin etäisyyttä toisistaan.
Tämän projektin puitteissa luotavan lopputuotteen paikkatieto tuotetaan WLAN-verkon antaman karkean solutiedon sekä simuloinnin avulla, sillä tarkan ja todellisen paikkatiedon saaminen ei nykytekniikoilla ja -standardeilla ole toteutettavissa projektin puitteissa. Koska paikkatieto syötetään kalenterille rajapinnan kautta, ei kalenterijärjestelmän toiminta poikkea riippuen siitä, onko paikkatieto todellista vai simuloitua.
Kalenteriarkkitehtuurissa ei itsessään ole toiminnallisuutta kalenterien yksilöisemiseksi ja niiden välisten oikeuksien selvittämiseksi. Mahdollisuus toiminnallisuuden lisäämiseksi projektin ulkopuolella projektin päätyttyä kuitenkin säilytetään. Tämä otetaan huomioon erillisellä rajapinnalla em. palveluita tarjoavaan tahoon päin. Rajapinta tullaan määrittelemään myöhemmässä vaiheessa.
Kalenteriarkkitehtuuriin osana kuuluvat tiedontuottajat tuovat tiedot käyttäen arkkitehtuurin heille tarjoamaa palvelurajapintaa. Tiedontuottajilla voi edelleen olla käytössään liittymiä tietokantoihin, WWW-sivuihin yms. Näitä liittymiä käyttäen he tuottavat tiedon kalenteriarkkitehtuurin käytettäväksi. Liittymät eivät kuitenkaan kuulu projektin alueeseen.
Kalenteriarkkitehtuuri on suunniteltu ensisijaisesti mobiililaitteille, jotka ovat langattomassa yhteydessä (esim. WLAN) Internetiin IPv6:n tai vastaavan mobiili-IP-protokollan kautta. Arkkitehtuuri itsessään ei aseta vaatimuksia tietoliikenneyhteyksien toteutukselle, sillä järjestelmä käyttää käyttöjärjestelmän palveluita tietoliikenneyhteksien muodostamiseen edelleen Java-ajoympäristön välityksellä, ja tietoliikenneyhteysspesifiset lokaatiopalvelut on eristetty arkkitehtuurista omaksi osakseen.
On mahdollista, että arkkitehtuuria halutaan käyttää jatkossa uusien ad hoc -verkottumista tukevien protokollien päällä. Tämä ja arkkitehtuurin vaatimus tukea tietoturvan lisääminen myöhemmin aiheuttavat sen, että tietoliikenneyhteyksien käsittelyt tullaan erottamaan omiksi osikseen arkkitehtuurin sisällä. Näin tarvittaessa käytetyn tietoliikennöintitavan ja/tai lisäkerroksien lisääminen protokollapinoon ei ole ongelmallista.
Arkkitehtuurin suorituskyvylle ei asetata erityisiä tiukkoja mitattavia standardien mukaisia suorituskykyvaatimuksia. Järjestelmän loppukäyttäjäkunta koostuu ihmisistä, mikä asettaa järjestelmän käytettävyydelle rajat. Käytettävyyden tuomat suorituskykyvaatimukset määritellään myöhemmin.
Arkkitehtuuria demonstroivalle asiakasohjelmistolle ei aseteta erityisiä suorituskykyyn tai vasteaikoihin liittyviä vaatimuksia, vaan vaatimukset heijastuvat arkkitehtuurin vaatimuksiin kuten edellä on todettu.
Kalenteriarkkitehtuurin näkymättömyydestä loppukäyttäjälle johtuen arkkitehtuurin ei kohdistu käytettävyysvaatimuksia kuin edellisen kappaleen käsittelemällä suorituskykytasolla.
Kalenteriarkkitehtuuri ei tue vikasietoisuutta millään tasolla. Tietojen korruptoitumisesta tai järjestelmän osien kaatumisesta ei tulla toipumaan ilman ylläpitäjän toimia. Arkkitehtuurin suunnittelu ei kuitenkaan saa tarpeettomasti rajoittaa em. ominaisuuksien toteuttamista vikasietoisella tavalla.
Kuten aiemmin on todettu, arkkitehtuuriin ei tulla toteuttamaan tietojen salausta tai turvallisuutta millään tasolla. Kuten myös aiemmin on todettu, niille tullaan kuitenkin tarjoamaan mahdollisuus projektia mahdollisesti seuraavissa jatkohankkeissa arkkitehtuurin joustavuuden myötä.
Arkkitehtuuria demonstroiva esimerkkikalenteriasiakasohjelmisto ei myöskään tue tietojen salausta, turvallisuutta tai vikatilanteista toipumista.
Esimerkkikalenteriohjelmiston käyttöliittymään ei tulla kiinnittämään suurta huomiota, koska se ei ole oleellista tutkimusnäkokulman kannalta. Ohjelmistoja, joissa on tehty hienoja käyttöliittymiä, on nykyään jo tarpeeksi aiheesta liikkellä. Siksi luodaan käyttöliittymä, joka on riittävä vain demostroimaan arkkitehtuurin toiminnot, mutta sen ulkoasuun tai käytettävyyteen ei panosteta.
Koska projektin tuloksena syntyvän kalenteriarkkitehtuurin jatkokäyttö on keskeisiä intressejä asiakkaalla (ks. projektisuunnitelma ja asiakkaan tavoitteet), ylläpidettävyyteen tullaan panostamaan erityisesti.
Perusvaatimuksena ylläpidettävyydelle on selkeä ja modulaarinen arkkitehtuuri. Sen komponenttien väliset suhteet, rajapinnat ja viestintä dokumentoidaan tarkkuudella jo suunnitteluvaiheessa. Edelleen asiakkaan toivomuksesta järjestelmän jatkokehityksen vuoksi suunnitteluvaiheen tärkeimmät päätökset ja niiden kriteerit halutaan dokumentoitavan.
Syntyvän ohjelmistokoodin huolellinen dokumentointi on myös keskeistä ylläpidettävyyden kannalta. Lähdekoodin dokumentointi suoritetaan käyttäen standardia JavaDoc-muotoa Sun Microsystemsin konventiota noudattaen [SUN-JDOC]. Dokumentointi katsotaan niin tärkeäksi, että jopa ohjelmiston testauksesta voidaan karsia resursseja sen toteuttamiseksi.
Lähdekoodin kirjoituskonventiona käytetään edelleen Sun Microsystemsin määritelmän pohjalta laadittua projektiryhmän omaa konventiota [OSPREY-CC].
Toteutuskielenä on Java 2 Standard Edition, ja arkkitehtuuri on laitteistoriippumaton.
Ohjelmisto käyttää arkkitehtuurin tarpeiden mukaan laajennettua iCalendar-standardia [RFC2445] kalenterimerkintöjen siirtoon ja talletukseen.
Arkkitehtuurin ainoa laitteistovaatimus on suorituskykyinen tietokone TCP/IP-verkkoyhteyksilla.
Esimerkkisovellus ei aseta muita vaatimuksia.
Kalenteriarkkitehtuurin ohjelmistorajoitteista ainoa vaatimus on Java 2 Standard Edition -ajoympäristön ja -kehitysympäristön käyttö.
Esimerkkikalenterisovelluksen ajoympäristöä ei ole projektin tässä vaiheessa vielä päätetty. Ympäristönä tulee olemaan joko Java 2 Standard Edition -ympäristö Swing-kirjastoja käyttäen tai Java 2 Standard Edition Servlet -ympäristö Apache WWW-palvelimessa.
Muita rajoitteita ei projektin tässä vaiheessa ole tiedossa.
Kalenteriarkkitehtuurin jatkoajatuskehityksiä tullaan kirjaamaan projektin myöhemmissä vaiheissa.