Tik-76.115 Vaatimusmäärittely Älykäs kalenteri Viimeksi päivitetty 16.10.2000 12:59:32. Sisällysluettelo 1. Johdanto 2. Yleiskuvaus 3. Toiminnot 4. Ulkoiset liittymät 5. Muut ominaisuudet Versiohistoria Versio Pvm Muutos Muuttaja 0.05 9.10.2000 Ensimmäinen versio Ilkka, Niko, Teemu 0.1 12.10.2000 Toinen versio Kari, Teemu 1.0 14.10.2000 Projektisuunniteluvaihteen palautus Ilkka, Teemu 1. Johdanto 1.1 Tavoitteet Projektin akateemisen tutkimuspainotteisen luonteen johdosta vaatimusmäärittelyn teko projektisuunnitteluvaiheessa on jätetty alustavalle tasolle. Sekä asiakkaalla että ohjelmistotyön tekevällä ryhmällä ei ole ennen esitutkimusvaihetta mahdollista määritellä vaatimuksia niiden vaatimalla tasolla. Lopullinen vaatimusmäärittely tullaan tekemään vasta projektisuunnittelua seuraavassa vaiheessa esitutkimuksen jälkeen, kun sekä asiakkaalla että ryhmällä on selkeämpi käsitys projektin aihealueesta ja sen vaatimuksista. Projektin tuloksena syntyvästä ohjelmistosta tulee luonteeltaan avoin laajennettava kalenteriarkkitehtuuri, jonka päälle rakennetaan sitä edelleen käyttävä esimerkkikalenterisovellus. Projektin pääpaino on täten edelleen kehitettävän arkkitehtuurin suunnittelussa ja sen toteuttamisessa, ei itse loppukäyttäjälle sopivan sovelluksen teossa. Toteutettava kalenteriarkkitehtuuri mahdollistaa perinteisistä kalenterisovellutuksista poiketen lisäkeinojen käytön kalenterikäyttäjien ajanhallintaan tehostamiseen ja helpottamiseen. Edellä mainitut lisäkeinot muodostuvat kalenterin passiivisen roolin muuttamisesta aktiivisempaan päätelmiä tekevään rooliin. Lisäarvoa tuovien päätelmien teon pohjana toimivat paikannuspohjainen tieto sekä kalenterimerkintöjen tulkinta kielitekniikkaa käyttäen. Ohjelmisto tehdään edelleen käytettäväksi akateemisiin tutkimustarkoituksiin Teknillisen korkeakoulun GO-PRODhankkeen 1 tutkijoille. 1.2 Käsitteitä Context Konteksti kuvaa sitä informaatiota, joka kuvaa jonkin entiteetin tilaa. Entiteetti voi olla esim. esine, ihminen tai paikka oleellista on, että entiteetti on sovellukselle ja sen käyttäjälle olennainen elementti. Tilatieto puolestaan voi kuvata esim.entiteetin sijaintia, identiteettiä, aktiviteettia jne. Context Aware Kontekstia (ks. context) hyväkseen käyttävä sovellus. Erikoistapauksena mainittakoon Location Aware eli paikkatietoinen järjestelmä. GPS Global Positioning System, satelliittipohjainen järjestelmä joka mahdollistaa ympäri maailmaa maanpinnan päällisen paikannuksen ilman erillislaajennuksia noin kymmenen metrin tarkkuudella. Laitteet ovat nykyisin kuluttajille saatavissa hintaluokkansa puolesta ja mahdollistavat edelleen kytkennän tietokonelaitteistoon. 1 GO-PROD http://go.cs.hut.fi
IP ks. IPv4. IPv4 Internet Protocol versio 4, nykyisen Internet-tekniikan perustietoliikenneprotokolla, jolle koko Internet tällä hetkellä perustuu. Katselmointi Katselmoinnilla tarkoitetaan käytäntöä, jossa asiakas, ohjaaja tai asiakkaan määräämä henkilö arvioi subjektiivisesti kyseessä olevan dokumentin ja palauttaa sen kommenttien kera takaisin ryhmälle. Käytetään erityisesti arvioitaessa tavoitteiden täyttymistä, koska verrattain abstraktit tavoitteet ovat huonosti mitattavissa konkreettisilla mittareilla. Location Aware Paikkatietoinen järjestelmä on tietoinen omasta sijainnistaan, pystyy kommunikoimaan muiden järjestelmien kanssa ja käyttämään ympäristöstä mahdollisesti löytyviä resursseja. Ontologia Ontologia voidaan ymmärtää käsitteellistämisen määrittelyksi. Esimerkiksi mobiiliagenttien joukossa esiintyvien suhteiden ja konseptien kuvaus on ontologia. Semanttinen Merkitystä koskeva. Kalenteriyhteydessä tarkoittaa merkintöjen merkityksen ymmärtämistä. Skenaario Skenaario on kuviteltu tarina, joka kuvaa ohjelmiston käyttötilannetta. Skenaariota tutkimalla voidaan löytää edelleen vaadittuja järjestelmän ominaisuuksia jne. Wireless LAN ks. WLAN. 1.3 Dokumentin rakenne Johdantokappale esittelee lyhyesti projektin taustan ja sen tavoitteet. Toinen kappale yleiskuvauksen koko järjestelmän arkkitehtuurista ja järjestelmän toimintaympäristöstä. Kolmas dokumentin kappale kuvaa järjestelmän toiminnalliset ominaisuudet. Neljäs kappale tarkentaa edelleen toisen kappaleen aloittamaa järjestelmän arkkitehtuurin liittymistä toimintaympäristöön ja kuvaa liittymät yksityiskohtaisemmin. Järjestelmän muut halutut ominaisuudet ovat listattu viidennessä kappaleessa. 2 Yleiskuvaus 2.1 Kalenterin liittyminen ympäristöön Perinteisen kalenteriasettelun eli kalenteri ja sen käyttäjän sijaan projektin tuloksena syntyvä kalenteriarkkitehtuuri mahdollistaa monipuolisemman kalenterin ja sen ympäristön suhteen. Kuten johdannossa todettiin, kalenterin ja sen ympäristön vaikutus on projektin tässä vaiheessa sekä ryhmälle että asiakkaalle ja ohjaajalle kokonaisuudessaan epäselvää. Kalenterin suhtautumisesta ympäristöön voidaan kuitenkin erottaa seuraavat yksittäisen rajapinnat: 1. Kalenteriarkkitehtuuri keskustelee kalenterisovelluksen välityksellä edelleen loppukäyttäjien kanssa. On huomattava, että arkkitehtuurin voi toimia myös useita käyttäjiä yhdistävänä tekijänä. Perinteisten kalenterimerkintöjen lisäksi kalenteriarkkitehtuurilla voisi esimerkiksi kokoustilanteessa julkaista ko. kokouksen agendan läsnäoleville kalenterinkäyttäjille. 2. Toisena ääripäänä suhteessa ihmisiin sijaitsevat kalenteriarkkitehtuurin käytössä olevat tietovarastot ts. jo olemassa olevat kalenterijärjestelmät. Esimerkkinä em. järjestelmistä mainittakoon Microsoft Exchange palvelinperhe ja Microsoft Outlook kalenterijärjestelmä. 3. Edelleen perinteisistä kalentereista poiketen kalenteriarkkitehtuurin liittymistä ulkomaailmaan olennaisen osan muodostavat käyttäjien kalentereihin tietoja tuovat ulkoisten ei suoraan käyttäjien luomat tietovarastot. Rajapintaa voi pitää ulkopuolisten tiedontuottajien ja kalenterin kohtaamispintana. Esimerkkinä tällaisesta tiedontuottajasta voisi ajatella vaikka kauppaa, jonka ohitse kalenterin käyttäjä kävelee. Kauppa tuottaa palveluna esimerkiksi päiväntarjoukset, jotka käyttäjän kalenterissa näkyvät käyttäjän edelleen niistä ollessa kiinnostunut hänen kävelleessään kaupan lähistölle. 4. Kalenteriarkkitehtuurin käyttäessä oleellisesti hyväkseen paikannustietoa arkkitehtuurin ja edelleen mahdollisesti ulkopuolisen paikannustietoa tarjoavan palvelun väliin muodostuu paikannustiedon kannalta oleellinen rajapinta. Esimerkkinä paikannustiedon tuottajasta toimii matkapuhelinoperaattorin tuottama paikannuspalvelu puhelinnumeron perusteella. 5. Kalenteriarkkitehtuuri on tekemisissä mahdollisesti hyvin arkaluontoisen henkilökohtaisen tiedon kanssa ja siten oleelliseksi osaksi muodostuu eri käyttäjien oikeuksien hallinta ja tunnistaminen. Arkkitehtuuri käyttää mahdollisuuksien mukaan em. palveluiden toteuttamiseen ulkopuolisia järjestelmiä, jotka piiloutuvat omien
rajapintojensa taakse. Esimerkkinä tällaisesta palvelusta toimii viranomaisten tuottama kansallinen digitaalista henkilökorttia käyttävä tunnistuspalvelu. Edellä mainittujen rajapintojen sisään jäävä osuus muodostaa arkkitehtuurin ytimen. Älykäs kalenteri Tiedon jalostaja Ympäristö tiedot Omat tiedot Muiden käyttäjien tiedot Lokaatioon sidottu tieto Käyttäjän omat merkinnät Kuva 1 Kalenterin sijoittuminen käyttäjäympäristöön 2.2 Käyttäjät Projektin tuloksena syntyvän kalenteriarkkitehtuurin käyttäjät muodostuvat Teknillisen Korkeakoulun GO-PRODprojektin tutkijoista. 2.3 Käyttöympäristö Kalenteriarkkitehtuurin käyttäessä hyväkseen paikannuspohjaista tietoa maantieteellinen toimialue on erikseen määriteltävä. Projektin tulosten tullessa edelleen GO-PROD-projektin käyttöön, GO-PROD-projektin entuudestaan tukema maatieteellinen toimintaympäristö WLAN-verkon muodossa on ohjelmistoprojektille luontainen käyttöympäristö. Täten maantieteelliseksi käyttöympäristöksi muodostuu Otaniemen alue ja edelleen alueella toimiva WLAN-verkko. Käyttöympäristön tarkempi luokittelu tullaan määrittelemään tarkemmin vaatimusmäärittelyyn projektin seuraavan vaiheen aikana. 2.4 Rajoitukset Arkkitehtuurin kehitysympäristön ollessa Sun Microsystemsin Java 2 Standard Edition kehitysympäristö käytettävän laitteistoarkkitehtuurin on tuetta ko. kehitysympäristöä. Kehitysympäristö on määritelty edelleen Standard Editioniksi, jotta mahdollinen laitteistovalikoima ei karsiudu liikaa. Arkkitehtuurin asiakasohjelmiston tulee olla edelleen riittävän kevyt PDA-laitteille. Koska kalenteriarkkitehtuurin alla oleva verkkoinfrastruktuuri on GO-PROD-projektin käyttämä Teknillisessä korkeakoulussa kehitetty Dynamics HUT MobileIP verkko 2, kalenteriarkkitehtuurin tulee pohjautua IPv4- verkkotekniikkaan. IPv4-tekniikaan päällä edelleen käytettäville protokollille ei kuitenkaan aseteta rajoituksia. 3 Toiminnot Ohjelmistoprojektin akateemisen tutkimusläheisen luonteen vuoksi ohjelmiston toiminnallinen vaatimusmäärittely on mahdotonta sen vaatimalla lopullisella tasolla projektin tässä vaiheessa. Sen sijaan projektin asiakkaan GO- PROD-projekteissa paljon käytettyä skenaariolähtöistä tutkimusmenetelmää tullaan käyttämään. Tutkimusmenetelmän lähtökohtiin kuuluu, että ongelmaa lähestytään luomalla joukko hyvinkin avoimia skenaariota ja edelleen tilanteita skenaarion sisälle. Näitä lähdetään edelleen jalostamaan kriittisesti pienempään toteutettavampaan muotoon projektin aluksi. Lopulta skenaarioista eristetään yksi skenaario tai osa skenaariota, joka tullaan toteuttamaan projektin seuraavissa vaiheissa. On huomattava, että tämä eristysvaihe on jo sinällään hyvin 2 Dynamics HUT Mobile IP http://www.cs.hut.fi/research/dynamics
runsaasti aikaa vaativa. Projektin projektisuunnitteluvaiheessa on siis vasta luotu joukko skenaarioita, jotka tullaan jalostamaan projektisuunnitteluvaihetta seuraavassa vaiheessa lopulliseksi vaatimusmäärittelyksi. Kalenteriarkkitehtuurin toiminnallisuutta kuvaavat skenaariot ja tilanteet on liitetty tämän dokumentin liitteeksi A. 4 Ulkoiset liittymät Kuten edellä jo todettiinkin, kalenterin ja sen ympäristön vaikutus ei ole projektin tässä vaiheessa projektiryhmälle eikä asiakkaalle vielä selvä. Kappaleessa kaksi mainittuja liityntöjä pystytään kuitenkin kuvaamaan jo astetta tarkemmin projekin tässä vaiheessa. Seuraavassa kalenterin liityntöjä ympäristöön kuvaavan kuvan 2 liityntöjen selitykset: Rajapinta loppukäyttäjiin päin. Kuvassa tämä vastaa kalenterikäyttöliittymän ja sovelluksen väliä. Kalenterin liittäminen jo olemassa oleviin kalenteriratkaisuihin vaatii kalenterisovelluskohtaisen sovitintoteutuksen. Kuvassa tämä näkyy liityntänä vanhoihin järjestelmiin. Rajapinta tiedon tuottajiin palveluihin päin selviää vasta projektisuunnittelua seuraavassa vaiheessa. Kuvassa tämä on osa yhteyttä palveluihin päin. Kommunikointi kalenterien välillä vaatii joko kalenterien välisen oman protokollan tai muunnelman olemassa olevista kalenteritiedon välitysprotokollista. Kuvassa tämä ilmenee siten, että käyttäjiä on useampia. Liityntä lokaatiopalveluihin vaatii lokaatiopalveluspesifisen liitynnän standardien puuttuessa. Mikäli päädytään käyttämään GPS-paikanninta, käytetään tiedonsiirtoon NMEA 0183 standardia 3. Lokaatiopalvelut ovat osa kuvan palveluliityntää. Liitynnät käyttäjien autentikointi- ja oikeuspalveluihin vaativat palveluspesifisen liitynnän. Kuvassa nämä ovat osa palveluliityntää. Järjestelmä sijoittuu usean tietolähteen keskelle niitä yhdistäväksi tekijäksi. Liitynnät näihin ovat välttämättömiä, mutta eivät järjestelmän toteutuksen kannalta keskeisiä. Näin ollen liitynnät ulkoisiin järjestelmiin on eristettävä mahdollisimman pitkälle arkkitehtuurin ytimestä. Projektin tutkimuksellisesta luonteesta johtuen ulkoiset liittymät määritellään tarkemmin myöhemmin. Ympäristötiedot: Palvelut Profiilitiedot Kalenterikäyttöliittymä Sovellus Vanhat järjestelmät Omat tiedot: Omat merkinnät Kuva 2 Ulkoiset liittymät 5 Muut ominaisuudet 5.1 Arkkitehtuurin joustavuus, laajennattavuus ja uudelleen käytettävyys Arkkitehtuuri ei saa rajoittaa käytettävien terminaalien tyyppiä tai asettaa vaatimuksia verkkoyhteyden laadulle. Arkkitehtuurin liittyminen jo olemassa oleviin kalenteriratkaisuihin ei myöskään saa olla rajoitettu. Arkkitehtuurin sisäinen eri osien välinen kommunikointi toteutetaan mahdollisuuksien mukaan valmiita standardeja käyttäen. 3 Peter Bennet, The NMEA FAQ, 25.4.2000 http://www.vancouver-webpages.com/peter/nmeafaq.txt
Toteutuksen ja dokumentoinnin on oltava laadultaan sellaisia, että järjestelmän osien uudelleen käyttö on helppoa myös muissa lokaatio- ja asiakontekstisidonnaisuutta käyttävissä ohjelmistoissa. 5.2 Dokumentointi Projekti dokumentoidaan suomeksi, lukuunottamatta ohjelmakoodin sisälle kirjoitettuja kommentteja, jotka tehdään englanniksi. Koodin dokumentointi tehdään Javadoc 4 työkalua käyttäen esimerkin 5 mukaisesti. Epätriviaalit kohdat ohjelmakoodista on myös kommentoitava vapaamuotoisesti. Projekti tuottaa kurssin vaatimusten mukaiset dokumentit: Vaatimusmäärittely, Toiminnallinen määrittely, Tekninen määrittely, Testaussuunitelma, Testiraportti ja Käyttöohje kurssin ohjeiden 6 mukaisesti. Nämä dokumentit tuotetaan HTML-muodossa. 5.3 Suorituskyky Suorituskyvylle ei aseta erityisiä tehokkuusvaatimuksia, mutta arkkitehtuuri ei itsessään saa rajoittaa suorituskykyä ts. arkkitehtuuriset ratkaisut, jotka tarpeettomasti rajoittavat skaalautuvuutta eivät ole toivottuja. 5.4 Tietoturva Arkkitehtuurin tulee mahdollistaa kattavamman tietoturvan lisäämisen jälkikäteen, mutta projektin puitteissa itse tietoturvan toteuttamiseen ei paneuduta.. 4 How to Write Doc Comments for Javadoc http://java.sun.com/products/jdk/javadoc/writingdoccomments/index.html 5 Projekti Ospreyn ohjelmointikäytäntö http://www.hut.fi/~khiitola/osprey/codeconv.html 6 Tik-76.115 Ohjeet http://mordor.cs.hut.fi/tik-76.115/ohjeet