T2-vaiheessa tehdyt muutokset

Kappaleen 2.4 rajoituksia tarkennettu.

1. Johdanto

1.1 Tavoitteet

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 ajanhallinnan tehostamiseksi ja helpottamiseksi. 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-PROD-hankkeen tutkijoille.

1.2 Käsitteitä

Vaatimukset on luokiteltu prioriteettin mukaan kolmiasteisesti seuraavassa tärkeysjärjestyksessä.

• Toteutetaan, eli lopputuotteessa on oltava kyseiset ominaisuudet, eikä niistä voida joustaa. Synonyymi: vaaditaan.
• Pyritään toteuttamaan, eli kyseiset ominaisuudet ovat lopputuotteelle erittäin oleellisia, mutta niistä voidaan joustaa, mikäli työmäärä on arvioitu paljon todellista pienemmäksi.
• Voidaan toteuttaa, eli kyseiset ominaisuudet ovat hyviä olemassa, ja ne toteutetaan, mikäli muut ominaisuudet saadaan toteutettua selvästi suunniteltua nopeammin.

Projektin käyttämä termistö on määritelty erillisellä dokumentissa [OSPREY-T].

1.3 Dokumentin rakenne

Johdantokappale esittelee lyhyesti projektin taustan, määrittelee termistön ja esittelee dokumentin rakenteen. Toinen kappale antaa yleiskuvauksen koko arkkitehtuurista ja sen toimintaympäristöstä. Kolmas dokumentin kappale kuvaa järjestelmän toiminnalliset vaatimukset. Neljäs kappale määrittää vaatimukset arkkitehtuurin liittymisestä toimintaympäristöön. Järjestelmän muut vaatimukset on listattu viidennessä kappaleessa.

2 Yleiskuvaus

2.1 Kalenterin liittyminen ympäristöön

Perinteisen kalenteriasettelun - eli kalenteri ja sen käyttäjä - sijaan projektin tuloksena syntyvä kalenteriarkkitehtuuri mahdollistaa monipuolisemman toteutuksen kalenterin ja sen ympäristön suhteen.

Kalenteriarkkitehtuuri kattaa ne ohjelmiston osat, jotka tarjoavat kalenteripalveluja niin loppukäyttäjille kuin kalenteriin tietoa tuottaville tahoillekin. Kalenteripalveluihin kuuluvat loppukäyttäjien osalta ne palvelut, joilla voidaan toteuttaa kappaleessa 3 määritellyt toiminnot. Tiedon tuottajille tarjotaan mahdollisuudet lisätä tietoa ja sekä muokata että poistaa tarjolla olevia omia tietoja.

Kalenteriasiakasohjelmisto tarkoittaa ohjelmistoa, jolla loppukäyttäjät käyttävät kalenteripalveluja. Asiakasohjelmisto on kevyt ts. se ei sisällä juuri muuta toiminnallisuutta kuin palvelimelta saatavan tiedon visualisoinnin. Kaikki muu toiminnallisuus pyydetään kalenteriarkkitehtuurin mukaiselta palvelinjärjestelmältä. Kalenteriarkkitehtuuri ei ota kantaa kalenteriasiakasohjelmiston toteuttamiseen, vaan tarjoaa rajapinnan käyttöä varten.

Kalenteripalvelimet ovat tekemisissä mahdollisesti hyvin arkaluontoisen henkilökohtaisen tiedon kanssa ja siten arkkitehtuurin oleelliseksi osaksi muodostuu eri käyttäjien tunnistaminen ja oikeuksien hallinta. Näiden palvelujen toteuttamiseen käytetään mahdollisuuksien mukaan ulkopuolisia järjestelmiä, jotta arkkitehtuuri itsessään pysyisi mahdollisimman yksinkertaisena ja kevyenä.

Tiedon tuottajina arkkitehtuuria silmällä pitäen toimivat esimerkiksi Otaniemen alueella Teknillinen korkeakoulu ja sen eri osastot. Myös kursseilla saattaa olla intressejä tuottaa tietopalveluita kalenterijärjestelmään. Olemassaolevista tietovarastoista voitaisiin esimerkiksi muodostaa eri osastojen sähköisiä kalentereita, jotka näkyisivät automaattisesti opiskelijoiden kalentereissa.

Kalenteriarkkitehtuuri piilottaa kaikki liitynnät ulkoisiin laitteisiin ja palveluihin abstraktien rajapintojen taakse. Arkkitehtuuri siis sallii ulkoisten tietolähteiden käytön lisäarvon ja -palveluiden tuottamiseen, mutta ei ota kantaa niiden toteutustapaan. Tällaisiin ulkoisiin palveluihin kuuluvat mm. lokaatiopalvelut, tietoyhteyksien salaus ja suojaus sekä liitynnät kalenteripalvelinrakenteen ulkopuolisiin tietolähteisiin. Samoin tämän kalenteriarkkitehtuurin mukaiset sovellukset voivat käyttää hyväkseen muita kalenterisovelluksia, mutta väliin on rakennettava rajapinnan mukaiset sovittimet, jotka tulkkaavat eri sovellusten kalenterimerkinnät tähän arkkitehtuuriin sopiviksi.

Kalenteriarkkitehtuurin rajapinnat ulkoisiin laitteisiin ja palveluihin on kuvattu tarkemmin luvussa 4.

Em. ominaisuuksien ansiosta kalenteriarkkitehtuuri mahdollistaa asiakkaan vaatimusten mukaisesti verkkoympäristöön monitahoisesti sulautuvan kalenterijärjestelmän, jota voidaan laajentaa ulkoisilla palveluilla aina tarvittaessa. Eri kalenterijärjestelmät voivat profiloitua erilaisiin käyttäjien tarpeisiin mutta kuitenkin olla saumattomasti yhteydessä toisiinsa.

2.2 Käyttäjät

Projektin tuloksena syntyvän kalenteriarkkitehtuurin käyttäjät muodostuvat pääasiassa Teknillisen korkeakoulun GO-PROD-projektin tutkijoista. Lopullisen arkkitehtuurin pohjalle rakennettujen kalenterisovellusten käyttäjinä toimivat kaikki henkilökohtaista ajanhallintaa tarvitsevat, tietokonetta käyttävät henkilöt.

2.3 Käyttöympäristö

Kalenteriarkkitehtuuri ei sinällään ota kantaa käyttöympäristöön, mutta esimerkkisovellusta varten tarvitaan jonkinlainen rajoitettu ympäristö. Koska esimerkkisovellus tulee GO-PROD-projektin käyttöön, muodostuu luonnolliseksi käyttöympäristöksi Otaniemen alueen WLAN-verkko, joka on jo käytössä GO-PROD-projektissa.

2.4 Rajoitukset

Kalenteriarkkitehtuurin yhtenä suunnittelulähtökohtana on ollut tarpeettomien rajoitusten välttäminen. Esimerkkitoteutuksen kehityskieleksi valittiin tätä silmälläpitäen Java ja kehitysympäristöksi Sun Microsystemsin Java 2 Standard Edition –kehitysympäristö, sillä J2SE toimii useimmissa tietokoneissa. Esimerkkitoteutusta rajoittavat siis Javan kyvyt ja puutteet, mutta kalenteriarkkitehtuuri ei ole sidottu yksittäiseen ohjelmointikieleen.

Esimerkkiasiakasohjelma tulee myöskin käyttämään J2SE:tä, mutta valinta ei millään tavoin sido muita asiakasohjelmia.

Kalenteriarkkitehtuuria ei ole sidottu mihinkään tiettyyn sovelluskerroksen verkkoprotokollaan. Koska esimerkkiasiakassovelluksen ja kalenteriarkkitehtuurin kommunikointi tapahtuu Dynamics – HUT MobileIP –verkossa, näiden välisen protokollan tulee kuitenkin pohjautua IPv4-verkkotekniikkaan. IPv4-tekniikan päällä käytettäville protokollille ei kuitenkaan aseteta rajoituksia.

3 Toiminnalliset vaatimukset

3.1 Yleistä

Ensimmäisen ja toisen vaiheen aikana suunniteltujen skenaarioiden pohjalta koottiin älykkäälle kalenterille seuraavat toiminnot. Toiminnot ovat pääosin prioriteettijärjestyksessä, mutta tarkemmin prioriteetit on määritelty luvussa 3.3. Jokaisen toiminnon loppuun on kirjoitettu, mihin skenaarioon se perustuu. Toimintojen pohjaksi muodostettu koottu skenaario löytyy liitteestä A.

Projektin kuluessa on tarkoitus suunnitella kalenteriarkkitehtuuri, joka täysimittaisesti implementoituna kykenisi suorittamaan kaikki alla olevat toiminnot. Pääpainona on siis nimenomaan arkkitehtuurin potentiaaliset ominaisuudet, ei niinkään yksittäiset ominaisuudet demosovelluksessa. Demosovellusta varten arkkitehtuuri implementoidaan mahdollisimman pitkälle käyttäen vahvasti yksinkertaistettua toteutusta, ja varsinaisia toimintoja kehitetään sitten prioriteettijärjestyksessä niin pitkälle kuin aikaa riittää.

Vaatimusten prioriteetit saattavat muuttua jonkin verran sen perusteella, mikä osoittautuu ryhmän ja asiakkaan mielestä mielenkiintoiseksi tutkimuskohteeksi. Prioriteettien muutoksista sovitaan asiakkaan ja ryhmän välillä. Lisävaatimuksia pyritään välttämään, mutta mikäli ryhmä ja asiakas ovat sitä mieltä, että kyseinen ominaisuus on välttämätön, voidaan se lisätä muiden ominaisuuksien kustannuksella.

3.2 Toiminnalliset vaatimukset eriteltyinä

Alla olevissa luetteloissa on toiminnallisen vaatimuksen numeron perässä sulkeissa lyhenne tot., jos vaatimus toteutetaan, pyr., jos vaatimus pyritään toteuttamaan, ja void., jos vaatimus voidaan toteuttaa (kts. kappaleet 1.2 ja 3.3).

3.2.1 Kalenterimerkintöjen selaus

Toiminnot perustuvat kaikkiin skenaarion tilanteisiin.

TVAAT01 (tot.): Kalenterissa olevia merkintöjä tulee pystyä selaamaan.

TVAAT02 (tot.): Kuukausi-, viikko- ja päivänäkymät.

TVAAT03 (tot.): Kalenterissa tulee olla sanahakutoiminto, jolla voidaan etsiä tiettyä sanaa omista merkinnöistä.

TVAAT04 (tot.): Kalenterimerkinnöistä tulee selvästi ilmetä omien merkintöjen ja ulkoa tarjottujen tapahtumien ero.

3.2.2 Kalenteritapahtumien merkintä, poisto ja muuttaminen

Toiminnot perustuvat kaikkiin skenaarion tilanteisiin.

TVAAT05 (tot.): Kalenteriin on voitava lisätä omia tapahtumia.

TVAAT06 (tot.): Kalenterista on voitava poistaa omia tapahtumia.

TVAAT07 (tot.): Tapahtumien attribuutteja täytyy pystyä muuttamaan vapaasti.

3.2.3 Käyttäjän profiilin muokkaus

Toiminnot perustuvat kaikkiin skenaarion tilanteisiin.

TVAAT08 (tot.): Käyttäjän pitää voida tutkia ja muuttaa profiilissaan olevia tietoja.

TVAAT09 (tot.): Tietojen suodatuksessa käytettyjä parametrejä tulee voida muuttaa.

TVAAT10 (tot.): Kaikkien käyttöasetuksien on oltava muokattavissa.

TVAAT11 (tot.): Käyttäjän tulee voida muokata omia sidosryhmiään, eli listaa ystävistä ja yhteistyökumppaneista.

3.2.4 Tapahtumapaikkojen välimatkan ja matka-ajan arviointi

Toiminnot perustuvat skenaarion tilanteeseen 2.

TVAAT12 (tot.): Kalenteri selvittää eri tapahtumien sijaintipaikat ja laskee niiden etäisyydet.

TVAAT13 (tot.): Kalenterin tulee etäisyyksien perusteella pystyä arvioimaan summittaisesti tapahtumapaikasta toiseen siirtymiseen kuluva aika.

3.2.5 Ennakoiva hälyttäminen tapahtumista

Toiminnot perustuvat skenaarion tilanteeseen 2.

TVAAT14 (tot.): Kalenterin tulee ilmoittaa tapahtumista etukäteen käyttäjän määrittelemänä aikana.

TVAAT15 (tot.): Kalenterin tulee käyttäjän niin halutessa ilmoittaa tapahtumista kohdassa [TVAAT13] määritelty aika etukäteen.

3.2.6 Paikoilla omat kalenterit

Toiminnot perustuvat skenaarion tilanteeseen 3.

TVAAT16 (pyr.): Eri paikoilla on voitava olla omia kalentereitaan.

TVAAT17 (pyr.): Paikkojen kalentereihin täytyy pystyä ilmoittautumaan.

TVAAT18 (pyr.): Paikka on voitava varata varata tietyksi aikaa.

TVAAT19 (pyr.): Paikkojen kalenterit on voitava yhdistää pääkalenterinäkymään.

TVAAT20 (pyr.): Paikkojen kalentereita täytyy pystyä katselemaan myös omalla sivullaan.

3.2.7 Lähialueen kalenterimerkintöjen näyttö

Toiminnot perustuvat skenaarion tilanteeseen 2.

TVAAT21 (pyr.): Kalenterin tulee pystyä tunnistamaan käyttäjän lähiympäristölle määritellyt muut kalenterit.

TVAAT22 (pyr.): Käyttäjän on voitava määritellä, kuinka lista vaatimuksessa [TVAAT21] määritellyistä kalentereista päivittyy, vaihtoehtoina esim. "joka viides minuutti" tai "nyt".

TVAAT24 (pyr.): Kalenterin tulee käyttäjän profiilin perusteella pystyä suodattamaan pois käyttäjälle mielenkiinnotonta materiaalia ja korostamaan mielenkiintoista.

3.2.8 Käyttäjän sijainnin ennakointi

Toiminto perustuu skenaarion tilanteeseen 1.

TVAAT25 (pyr.): Kalenterin tulee osata summittaisesti ennakoida käyttäjän tulevaa sijaintia kalenterimerkintöjen perusteella.

3.2.9 Kalenterimerkintöjen yhteyksien havaitseminen

Toiminnot perustuvat skenaarion tilanteisiin 1 ja 2.

TVAAT26 (pyr.): Kalenterin tulee osata yhdistää käyttäjän kalenterimerkintöjä muiden käyttäjien ja paikkojen merkintöihin sen perusteella, että ne ovat kielellisesti samankaltaisia hyvin yksinkertaisten kielellisten sääntöjen perusteella.

TVAAT27 (pyr.): Kalenterin tulee osata yhdistää merkintöjä sen perusteella, että niiden tapahtumapaikat ovat lähellä toisiaan.

TVAAT28 (pyr.): Kalenterin tulee osata yhdistää merkintöjä sen perusteella, että ne on tehty lähellä toisiaan.

TVAAT29 (pyr.): Kalenterin tulee osata yhdistää merkintöjä sen perusteella, että ne koskevat käyttäjän määrittelemää sidosryhmää. (Määritelty vaatimuksessa [TVAAT11]).

TVAAT30 (pyr.): Kalenterin tulee osata yhdistää vaatimuksissa [TVAAT26-29] määriteltyjä ominaisuuksia siten, että useampia ehtoja toteuttavat tapahtumaparit yhdistetään varmemmin.

3.2.10 Muutosten propagointi linkitetyissä tapahtumissa

Toiminnot perustuvat skenaarion tilanteeseen 2.

TVAAT31 (pyr.): Käyttäjän on voitava määritellä samassa tai eri kalenterissa sijaitsevien merkintöjen välille linkki hyväksymällä vaatimuksissa [TVAAT26-30] ehdotettu yhteys.

TVAAT32 (pyr.): Käyttäjän on voitava määritellä samassa tai eri kalentereissa sijaitsevien merkintöjen välille linkki valitsemalla käsin linkitettävät tapahtumat.

TVAAT33 (pyr.): Keskenään linkitettyihin tapahtumiiin tehtyjen muutosten on voitava propagoitua käyttäjän niin määritellessä automaattisesti tai pyytämällä muutokseen käyttäjän hyväksyntä.

TVAAT34 (void.): Keskenään linkitettyihin tapahtumiin tehtyjen muutosten propagoituminen on voitava kieltää.

3.2.11 ToDo-merkintöjen teko

Toiminnot perustuvat skenaarion tilanteisiin 1 ja 2.

TVAAT35 (void.): Käyttäjän tulee voida lisätä kalenteriin ToDo-merkintöjä, so. tapahtumia jotka pitää suorittaa, mutta joille ei ole määritelty suoritushetkeä.

TVAAT36 (void.): ToDo-merkintöihin tulee voida liittää tapahtuman kesto, paikka, paikkatyyppi ja tapahtuman takaraja.

3.2.12 ToDo-merkintöjen suorituksen ajoittaminen

Toiminnot perustuvat skenaarion tilanteeseen 1.

TVAAT37 (void.): Kalenterin tulee pyrkiä sijoittamaan olemassaolevat ToDo-merkinnät dynaamisesti käyttäjän kalenteriin siten, että tehtävä tulee suoritettua ennen määräaikaa ja mahdollisimman vähällä ylimääräisellä liikkumisella. Ts. kalenteri ehdottaa tehtävää kun käyttäjä on lähistöllä. Toiminto käyttää hyväkseen vaatimusten [TVAAT12-13,25] toimintoja.

TVAAT38 (void.): Käyttäjän tulee voida muokata ToDo-merkintää missä tahansa vaiheessa, jolloin kalenteri etsii ToDo-merkinnälle mahdollisesti uuden paikan merkinnän muuttuneiden tietojen perusteella.

TVAAT39 (void.): Sijoitettu merkintä on voitava lukita paikalleen, jolloin sijoitusalgoritmi ei pääse sitä enää liikuttelemaan.

TVAAT40 (void.): Vaatimuksen [TVAAT39] mukaisesti lukittu merkintä on pystyttävä vapauttamaan, jolloin sijoitusalgoritmi pääsee jälleen etsimään sille uuden paikan.

3.2.13 Paikkatietojen etäselailu

Toiminto perustuu skenaarion tilanteeseen 3.

TVAAT41 (void.): Käyttäjän tulee voida selata paikkaan sidottuja tapahtumia, kuten vaatimuksissa [TVAAT21-24], liikkumatta fyysisesti kyseiseen paikkaan.

TVAAT42 (void.): Käyttäjän käymistä paikoista tulee tallettaa historiatietoa, ja aikaisempiin sijainteihin on voitava siirtyä virtuaalisesti.

TVAAT43 (void.): Paikkojen haun tulee onnistua sana- ja koordinaattihaulla.

3.3 Toiminnallisten vaatimusten priorisointi

Alla on koottu edellisessä kappaleessa luetellut toiminnalliset vaatimukset kappaleen 1.2 mukaisissa luokissa. Vaatimukset toteutetaan esimerkkisovellukseen siinä prioriteettijärjestyksessä kuin ne on alla lueteltu.

Seuraavat vaatimukset toteutetaan: [TVAAT01], [TVAAT02], [TVAAT03], [TVAAT04], [TVAAT05], [TVAAT06], [TVAAT07], [TVAAT08], [TVAAT09], [TVAAT10], [TVAAT11], [TVAAT12], [TVAAT13], [TVAAT14] ja [TVAAT15].

Seuraavat vaatimukset pyritään toteuttamaan: [TVAAT16], [TVAAT17], [TVAAT18], [TVAAT19], [TVAAT20], [TVAAT21], [TVAAT22], [TVAAT24], [TVAAT25], [TVAAT26], [TVAAT27], [TVAAT28], [TVAAT29], [TVAAT30], [TVAAT31], [TVAAT32] ja [TVAAT33]

Seuraavat vaatimukset Voidaan toteuttaa: [TVAAT34], [TVAAT35], [TVAAT36], [TVAAT37], [TVAAT38], [TVAAT39], [TVAAT40], [TVAAT41], [TVAAT42] ja [TVAAT43]

4 Ulkoiset liittymät

Kuvassa 1 liityntöjä on edelleen havainnollistettu. Kuvassa suorakaide viittaa asiakasohjelmistoon, kahdeksankulmio ulkoiseen arkkitehtuurin käyttämään palveluun ja tynnyri ulkoista tietovarastoa.

4.1 Kalenteriasiakasohjelmisto

Kalenteriarkkitehtuurin osana ei varsinaisesti ole käyttöliittymää, vaan arkkitehtuuri toteuttaa ainoastaan palvelurajapinnan asiakasohjelmille.

Toimintojen demonstroimista varten toteutetaan tätä rajapintaa käyttäen asiakasohjelma, johon pyritään toteuttamaan mahdollisimman paljon arkkitehtuurin mahdollistamia ominaisuuksia kappaleen 3 priorisointia noudattaen. Asiakasohjelmisto toimii liittymänä asiakkaaseen päin.

4.2 Liityntä olemassa oleviin kalenteriratkaisuihin

Nykyiset kalenteriratkaisut käyttävät lähes poikkeuksetta valmistajakohtaisia julkaisemattomia standardeja. Tämän vuoksi kalenteriarkkitehtuuri toteuttaa abstraktin rajapinnan, joka eristää liitynnät jo olemassa oleviin kalenteripalvelimiin abstraktin rajapinnan taakse.

4.3 Liityntä kalenteriin tietoja tuottaviin osapuoliin

4.4 Liityntä lokaatiopalveluihin

Lokaatiopalveluiden standardimäärittely on vasta aluillaan, joten geneeristä yleisesti hyväksyttyä liityntärajapintaa ei ole määritelty. Samoin perustein kuin kohdassa 4.2 rajapinta toteutetaan abstraktiksi, ja kalenteriarkkitehtuurin ja lokaatiopalvelun välisen kommunikoinnin tulkkaus jätetään sovittimen tehtäväksi.

Esimerkkisovelluksena toteutetaan karkea paikannus tukiaseman tarkkuudella käyttäen Otaniemessä toimivaa Mediapolin WLAN-verkkoa. Tukiasemasta, jonka alueella ollaan, päätellään käyttäjän sijainti. Paikannustiedon simulointi toteutetaan demonstroimisen helpottamiseksi.

4.5 Liityntä tunnistus- ja oikeuspalveluihin

Kalenteriarkkitehtuuri pyrkii käyttämään mahdollisimman pitkälle muiden tahojen luomia palveluita. Tämän vuoksi käyttäjien tunnistus ja käyttäjien välisten oikeussuhteiden selvittäminen eristetään arkkitehtuurista edelleen pyrkimällä toteuttamaan ne erillisen rajapinnan taakse.

Esimerkkisovelluksessa ei vaadita kyseisten palveluiden käyttöä. Rajapinta pyritään osoittamaan toimivaksi esimerkkisovelluksella.

4.6 Liitynta ulkoisiin tietolähteisiin

Kalenteriarkkitehtuuri voi toteuttaa mahdollisuuden viittauksiin muihin tietolähteisiin kuten WWW-sivustoihin käyttämällä URI-viittauksia. Asiakasohjelmisto käsittelee näitä haluamallaan tavalla. Arkkitehtuuri ei ota kantaa käsittelytapaan.

Kuva 1 Kalenteriarkkitehtuurin liitynnät

5 Muut ominaisuudet

5.1 Arkkitehtuurin joustavuus, laajennattavuus ja uudelleenkäytettävyys

Arkkitehtuuri toteutetaan terminaalien tyyppiä tai verkkoyhteyden laatua rajoittamattomasti.

Arkkitehtuurin liittyminen jo olemassa oleviin kalenteriratkaisuihin pyritään toteuttamaan rajoittumatta mihinkään yksittäiseen ratkaisuun.

Arkkitehtuurin sisäinen eri osien välinen kommunikointi voidaan toteuttaa mahdollisuuksien mukaan valmiita standardeja käyttäen.

Arkkitehtuuri pyritään suunnittelemaan siten, että järjestelmän osien uudelleenkäyttö on helppoa myös muissa lokaatio- ja asiakontekstisidonnaisuutta käyttävissä ohjelmistoissa.

Edellä mainitut arkkitehtuurin uudelleenkäyttö, laajennettavuus ja joustavuusvaatimukset eivät koske toteutettavaa esimerkkikalenterisovellusta. Tämä siksi, että, kuten aiemmin on todettu, sovelluksen tarkoitus on vain demonstroida arkkitehtuurin toimivuutta. Esimerkkikalenterisovelluksen implementaatio toteutetaan siten, että se osoittaa arkkitehtuurin toimivuuden.

5.2 Dokumentointi

Projekti dokumentointi vaaditaan suomeksi lukuunottamatta ohjelmakoodin sisälle kirjoitettuja kommentteja, jotka tehdään englanniksi. Koodin dokumentoinniksi vaaditaan JavaDoc-dokumentointia. Ohjelmakoodia pyritään kommentoimaan huolellisesti. Dokumentointi painottuu projektin päätuotteen eli kalenteriarkkitehtuurin dokumentointiin. Esimerkkikalenterisovelluksen dokumentointi on alemmalla prioriteetilla.

Projektilta vaaditaan kurssin vaatimusten mukaiset dokumentit: projektisuunnitelma, vaatimusmäärittely, toiminnallinen määrittely, tekninen määrittely, testaussuunitelma, testiraportti ja käyttöohje.

Lisänä edellä mainittuihin dokumentteihin vaaditaan dokumentaatio tärkeimmistä tehdystä suunnittelupäätöksistä ja niiden kriteereistä.

Kaikki edellä mainitut dokumentit vaaditaan tuotettavaksi HTML-muodossa.

5.3 Suorituskyky

Suorituskyvylle ei aseta erityisiä tehokkuusvaatimuksia, mutta arkkitehtuuri pyrittämään toteuttamaan siten se ei itsessään rajoita suorituskykyä; ts. arkkitehtuuriset ratkaisut, jotka tarpeettomasti rajoittavat skaalautuvuutta, eivät ole hyväksyttyjä.

Esimerkkikalenterisovelluksen suorituskyvylle ei aseteta muita vaatimuksia kuin, että sen käyttäminen vaaditaan olevan mahdollista ja - kuten kappaleessa 5.1:ssa jo todettiin - että voidaan todentaa arkkitehtuurin toimivuus.

5.4 Tietoturva

Arkkitehtuuri pyritään toteuttamaan siten, että se mahdollistaa kattavamman tietoturvan lisääminen jälkikäteen. Projektin puitteissa itse tietoturvan toteuttamiseen ei paneuduta.

Esimerkkikalenterisovelluksen tietoturvaominaisuuksille ei aseteta vaatimuksia.

Lähdeluettelo

[OSPREY-T] Osprey-ryhmä, Projekti Ospreyn termistöä, termit.html, viitattu 5.11.2000