![\includegraphics[width=0.9\textwidth]{graphics/kontekstit.eps}](img1.png) |
Määrittelydokumentti
The Converge Group
0.1 14.10.2002 Dokumentin sisältöä rakennettu Mikko Hiipakka 0.2 19.10.2002 Sisältöä tarkennettu Mikko Hiipakka 0.2.1 22.10.2002 - "" - Ryhmä 0.3 30.10.2002 Sisältöä muutettu ja tarkennettu Mikko Hiipakka 0.5 11.11.2002 Dokumenttia muutettu ja selkeytetty Ryhmä 0.6 12.11.2002 - "" - Joni, Tea, Olli
Tämä on Convergence of Messaging -ryhmän projektityön määrittelydokumentti. Dokumentin tavoitteena on määritellä viestintäjärjestelmän osat ja toiminnallisuus sekä määritellä, mitä näistä toteutetaan projektin kuluessa. Lisäksi dokumentti esittelee järjestelmän käyttäjä- ja sidosryhmät sekä eri käyttäjien käyttötapauksia.
Toteutettava järjestelmä on tarkoitettu käyttäjän viestien hallitsemiseen. Ohjelmiston avulla käyttäjä voi valikoida hänelle kulloinkin toimitettavat viestit ja päättää, mihin laitteeseen ne toimitetaan. Lisäksi käyttäjä voi lajitella vastaanottamiaan viestejä niiden sisällön tai asiayhteyden mukaan. Käyttäjä voi esimerkiksi muodostaa työviesteistään alikokonaisuuksia, joista kukin käsittää esimerkiksi tiettyyn projektiin liittyvät viestit. Käsiteltävät viestit eivät ole ainoastaan sähköpostiviestejä, vaan saapuvat erilaisilta tiedontarjoajilta. Sähköpostin lisäksi erilaiset tiedontarjoajilta saatavat viestit voivat olla esimerkiksi uutisryhmien viestejä, tekstiviestejä, kuvaviestejä sekä muuta informaatiota, kuten osakekursseja, aikatauluja tai käyttäjää kiinnostavia uutisia.
Tiedontarjoajalta järjestelmään saapuva viesti käsitellään järjestelmässä, jolloin tehdään päätös viestin eteenpäin toimittamisesta: järjestelmä pyrkii ratkaisemaan käyttäjän antaman informaation, sekä käyttäjän kulloinkin käyttämien laitteiden ja tilanteen perusteella sen, mihin laitteeseen toimitettava viesti lähetetään. Esimerkiksi kiireellisiksi määritellyt viestit voidaan toimittaa suoraan matkapuhelimeen tai kämmentietokoneeseen, jos havaitaan, ettei käyttäjä ole tietokoneensa ääressä. Toisaalta taas viestejä ei välttämättä toimiteta perille, jos voidaan olettaa, etteivät ne kiinnosta käyttäjää kyseisellä hetkellä. Tällainen tilanne voi syntyä esimerkiksi käyttäjän ollessa työkokouksessa, jona aikana hän ei halua vastaanottaa henkilökohtaisia viestejään.
Tässä määrittelydokumentissa käytetään termejä, jotka voivat lukijasta riippuen saada erilaisia merkityksiä. Tämän vuoksi tässä osassa määritellään ne termit, joiden tarkoitus tai sisältö voi olla epäselvä.
Konteksti on tapa kuvata henkilön ''statusta'' ja asiayhteyttä, johon henkilö kuuluu. Se kuvaa tilannetta ja ympäristöä, jossa hän on, hänen kiinnostuksen kohteitaan, tulevaisuuden suunnitelmiaan tai muuta henkilöstä kertovaa. Tätä asiayhteyttä voidaan kuvata erilaisilla tiedoilla ja ominaisuuksilla, jotka liittyvät kyseessä olevaan tilanteeseen. Henkilö voi kuulua samanaikaisesti moneen eri asiayhteyteen, kontekstiin, jotka voivat suhtautua toisiinsa siten, että ne ovat erillisiä, toisiaan leikkaavia tai sisäkkäisiä.
Esimerkkinä voidaan ajatella henkilöä, joka osallistuu muiden työntekijöiden kanssa esimiehen järjestämään palaveriin. Tällöin henkilöllä pätee konteksti, joka kuvaa hänen olevan osallisena työpalaverissa. Tietoja, joilla tätä kontekstia voidaan kuvata olisivat esimerkiksi 1) paikka, ollaan työpaikan tiloissa, 2) aika, on arkipäivä ja virka-aika, 3) ympäristö (sisältää myös paikan), ollaan työpaikalla muiden työntekijöiden kanssa, 4) tilanne, kokoontuminen johon esimies on kutsunut. Toinen konteksti, joka henkilölle pätee ja sisältyy aidosti edelliseen olisi hänen projektipäällikön asemansa. Kolmas henkilölle pätevä konteksti, joka kuitenkin leikkaa ensimmäisen määritetyn kontekstin olisi, että hän on työpaikkansa ''vapaa-ajan huvitoimikunnan vetäjä''. Tämän kontekstin voidaan ajatella olevan henkilön työajalla tekemiä retkijärjestelyjä, mutta se pitää sisällään paljon sellaista, joka ei liity mitenkään muuten hänen työnkuvaansa. Neljäs täysin erillinen konteksti, joka henkilölle pätee samaan aikaan, olisi hänen vankkumaton kiinnostuksensa kaikkeen urheiluun ja kuulumisensa TPS:n jalkapalloseuraan.
Tässä dokumentissa kontekstilla tarkoitetaan käyttäjään liittyviä, tietyllä ajanhetkellä vallitsevia, reaalimaailman tilanteita. Järjestelmän sisäinen käsitys käyttäjän kontekstista määritellään muuttujien avulla antamalla niille tilannetta kuvaavat arvot, esimerkiksi kännykkä, Helsinki, klo 8.15.
Attribuutit ovat järjestelmän sisäisiä muuttujia, joilla on nimi, tyyppi ja arvo.
Esimerkiksi attribuutti voi liittyä käyttäjän sen hetkiseen kontekstiin
( <kännykkä_auki><boolean><true> )
tai johonkin yksittääiseen viestiin
(<viestin_otsikko><string><''Palaveri tänään kahdelta!''> ).
Attribuutteja kutsutaan alemmiksi attribuuteiksi kun arvolle on yksikäsitteinen tiedonlähde ja ylemmiksi attribuuteiksi kun arvo riippuu muiden attribuuttien arvoista ja sen määrittäminen vaatii ajoaikaista laskentaa. Järjestelmä kuitenkin käsittelee kaikkia attribuutteja samalla tavalla.
Säännöt ovat loogisia lausekkeita, jotka määrittävät miten käyttäjälle saapuvia viestejä käsitellään.
Esimerkki säännöstä voisi olla: Jos <viestin_lähettäjä> sisältää merkkijonon
''ville@mbnet.fi'', <kännykkä_auki> == true, <kello> >= 10.00 ja <kello> <= 22.00, niin
laukaistaan toiminto ''lähetä viesti käyttäjän kännykkään''.
Termi kontekstimalli tarkoittaa käyttäjän järjestelmään määrittelemää kuvausta jostain reaalimaailman kontekstista. Järjestelmään on määritelty joukko attribuutteja, joista valitaan osajoukko kuvaamaan kontekstimallia. Näille valituille attribuuteille määritellään arvovälit, joiden tarkoitus on rajata sellaiset arvot, joilla attribuutit toteuttavat kyseisen kontekstimallin vaatimukset.
Kun viesti saapuu järjestelmään, lasketaan jokaisen kontekstimallin kohdalla luku (esim. 0-100), joka kertoo kuinka hyvin viesti kuuluu ko. malliin.
Järjestelmää kuvattaessa termillä profiili tarkoitetaan käyttäjän määrittelemää sääntöjoukkoa, jolla ohjataan järjestelmän toimintaa. Täten profiili on siis käyttäjän itseensä liittämiä järjestelmän toiminnallisia ominaisuuksia.
Lisäksi profiilissa määritelläään käytettävät kontekstimallit ja niihin liittyvät kynnysarvot. Eli kuinka hyvin viestin pitää sopia johonkin kontekstimalliin, jotta profiilissa määriteltyjä sääntöjä sovelletaan ko. viestiin. Esimerkiksi voitaisiin laukaista jokin toiminto, jos viesti kuuluu kontekstimalliin ''työ'' 80-prosenttisesti.
Tässä osassa kuvataan järjestelmään liittyvät käyttäjä- ja sidosryhmät siten, että jokainen määritelty ryhmä muodostaa oman erillisen osajoukkonsa.
Peruskäyttäjällä tarkoitetaan henkilöryhmää, jonka edustajilla on pääasiallisena tavoitteenaan käyttää järjestelmää viestien hallitsemiseen ja lukemiseen. Järjestelmän tulee tarjota käyttäjälle toiminnallisuuksia, joilla tavoitteet on mahdollista suorittaa. Tavoitteita, ja siten myös vaadittavia toiminnallisuuksia kuvataan käyttötapauksilla.
Ennen kuin peruskäyttäjän on mahdollista käyttää järjestelmää, tulee hänen rekisteröityä järjestelmään, jolloin käyttäjällä on kaikki järjestelmän tarjoamat toiminnallisuudet ja palvelut käytössään. Kun käyttäjä haluaa luopua järjestelmän käytöstä, tulee hänen poistaa rekisteröitymisensä järjestelmästä. Tämä tarkoittaa, että kaikki käyttäjään liitetyt tiedot poistetaan järjestelmästä ja käyttäjän ei ole enää mahdollista käyttää järjestelmän toimintoja ja palveluita.
Kun rekisteröitynyt käyttäjä haluaa muuttaa tai käyttää järjestelmässä olevia tietojaan, on hänen kirjauduttava sisään järjestelmään.
Käyttäjän on mahdollista luoda kontekstimalleja, jotka ovat reaalimaailman konteksteja kuvaavia attribuutti- ja arvovälijoukkoja. Näiden mallien avulla käyttäjä voi kuvata omaa toimintaansa, ympäristöään sekä tavoitteitaan. Käyttäjän on mahdollista myös muuttaa jo määriteltyjen kontekstimallien sisältöä esim. ennalta määritelty kontekstimalli ''Vapaa-aika'' ei enää päde lauantaisin, koska henkilö on ottanut lisätöitä. Kontekstimallien poistamisella tarkoitetaan, että käyttäjä poistaa luomansa kontekstimallin järjestelmästä.
Käyttäjän on mahdollista luoda, muuttaa sekä poistaa profiileja. Profiili on järjestelmälle määritelty sääntöjoukko, joilla hän voi ohjata järjestelmän toimintaa, kun järjestelmään saapuu viestejä.
Järjestelmään rekisteröityneille käyttäjille on tarjolla keskustelukanava, jonka avulla käyttäjät voivat viestiä toisilleen reaaliaikaisesti. Kun joku käyttäjistä perustaa kanavan, voivat muut järjestelmän käyttäjät liittyä kanavan jäseniksi. Käyttäjät, jotka ovat jäseniä, voivat lähettää kanavaan viestin, joka lähetetään kaikille muille kanavan jäsenille heti järjestelmään saavuttuaan.
Järjestelmään sisäänkirjautunut käyttäjä saa näkymän hänelle lähetettyihin viesteihin siten, että hänen on mahdollista hallinnoida henkilökohtaisia viestejään ja viesteihin luotuja näkymiä. Käyttäjä voi lukea, siirtää ja poistaa viestin tai muuttaa viestin tilaa esim. merkitä suuren joukon toisarvoisia viestejä luetuiksi.
Järjestelmän on tarkoitus tukea ryhmäviestintää, jonka avulla järjestelmään voidaan määritellä sisäisiä yksikköjä. Nämä yksiköt ovat järjestelmälle kuin yksittäinen käyttäjä, mutta käyttäjille kyseessä on kuuluminen ryhmään, jolle on määritetty kaikille jäsenille sovellettavia yhteisiä toimintoja ja sääntöjä.
Timo R-O on aloittanut ohjelmistotuotantoprojektin Helsingin yliopistossa. Projektipäällikkö Mikko Hiipakka tiedottaa joka päivä klo 10.00 projektin edistymisestä ja työrutiinien jaoista ryhmäläisilleen sähköpostitse.
Eräänä aamuna klo 10.00 Timo ei onnistu lukemaan sähköpostiaan, koska modeemi on mennyt rikki. Edellisyön ukonilma on ollut koneelle liikaa. ''Olisipa jokin mahdollisuus lukea viesti kännykällä'', tuumii Timo.
Tällä kertaa Timo jää ilman päivittäistä tietoiskuaan. Projektilla ei kuitenkaan vastaisuudessa ole varaa kommunikointikatkoksista johtuviin viivytyksiin, sillä projekti on aikataulustaan jo entuudestaan jäljessä. Projektipäällikkö määrää Timon sekä muiden projektiryhmäläisten rekisteröitymään yleiskäyttöisen viestintäpalvelun käyttäjäksi osoitteessa www.converge.org.
Timo R-O kirjoittaa pöytäkoneessaan pyörivän selaimen osoiteriville ''www.converge.org'', jolloin hän saa eteensä Converge aloitussivun. Sivulla olevaa ''rekisteröidy''-linkkiä painamalla avautuu rekisteröintilomake jossa henkilöltä kerätään välttämättömät perustiedot, muun muassa nimi, sähköpostiosoite, käyttäjätunnus, salasana. Rekisteröitymisen yhteydessä Timolla on mahdollisuus määrittää kiinnostuksen kohteitaan rastittamalla valmiiksi esitettyjä aihealueita.
Timo R-O menee www.converge.org ''irtisanoudu''-linkin kautta irtisanoutumissivulle. Sivulla olevaan lomakekenttään hän kirjoittaa käyttäjätunnuksensa ja salasanansa sekä painaa Vahvista-painiketta.
Suuri työmäärä on uuvuttanut Timon ja projektipäällikkö joutuu myöntämään hänelle pari viikkoa vapaata projektista nähtyään lääkärinlausunnon. Yksikin työasiaan liittyvä viesti voi viedä Timon antenniosastolle lopullisesti, joten Timo päättää muuttaa kontekstimalliaan. Hän kirjautuu järjestelmään ja menee kontekstimallien muokkaussivulle. Siellä hän kieltää järjestelmää lähettämästä viestejä, joiden lähettäjinä ovat projektiryhmäläiset valitsemalla ryhmäläiset boikottilistalle. Lisäksi hän määrittää että viestit joiden sisältä on löydettävissä avainsanoja work, projekti, aikataulu, ''menikö hermot?'' jne. ei lähetetä. Lisäksi hän poistaa kiellettyjen viestien säännöistä avainsanat ''loma'' ja ''matka''.
Timo R-O tutkii erään Converge järjestelmään liittyneen sääpalvelun ajantasaisia säätietoja autotietokoneestaan matkalla kohti Helsinki-Vantaan lentoasemaa.
Graafisena suunnittelijana työskentelevä Masa lähtee muutaman viikon lomalle Etelä-Ranskaan ja ainoa tänä aikana käytettävissä oleva kommunikointiväline on matkapuhelin. Hän ei luonnollisesti aio juurikaan ajatella työasioita, mutta hänellä on kuitenkin pari projektia kesken, joihin liittyen hän saattaa joutua yllättäen vaivaamaan itseään. Niinpä hän haluaa työsähköposteistaan puhelimeensa vain koostetiedot, eli viestien lukumäärän, lähettäjät ja otsikot. Nämä tiedot hän asettaa noudettavaksi päivittäin, kello 10.
Sen sijaan kaikki kaveriltaan Villeltä tulevat sähköpostit Masa haluaa saada välittömästi luettavaksi puhelimeensa. Villen on tarkoitus nimittäin liittyä lomailevan Masan seuraan myöhemmin, ja muutama käytännön asia on vielä sopimatta.
(Muitakin sähköpostiviestejä Masa voi toki käydä lukemassa, mutta niitä ei automaattisesti lähetetä hänen matkapuhelimeensa.)
Sami on kotona surffailemassa webissä ja saa puhelimitse valmentajalta tiedon siitä, että illan salibandytreenit on peruttu. Hän lupaa ilmoittaa asiasta kolmelle muulle joukkuetoverille (jotka kaikki sattuvat käyttämään Converge-järjestelmää).
Niinpä Sami siirtyy selaimesta Convergen asiakasohjelmaan, joka hänen Windows-työpöydällään onkin valmiiksi auki. Ohjelman ''Reaaliaikainen viestintä''-välilehdellä hän kirjoittaa uuden viestin ja valitsee vastaanottajiksi kontaktilistaltaan kyseiset kolme henkilöä. Viestin prioriteetin hän määrittelee korkeaksi, jotta tieto treenien peruuntumisesta tavoittaisi pelikaverit mahdollisimman pian.
Yksi pelikavereista on juuri pöytäkoneen ääressä kirjautuneena järjestelmään oman asiakasohjelmistonsa kautta, ja hän huomaakin heti uuteen ikkunaan avautuvan viestin Samilta; kahdelle muulle viesti välittyy automaattisesti kännykkään.
Ylläpitäjällä tarkoitetaan järjestelmän toimintaa valvovaa henkilöryhmää, jonka pääasiallisena tehtävänä on hallinnoida käyttäjärekisteriä ja määritellä järjestelmään uusia tiedontarjoajia.
Ylläpitäjä voi tehdä haluamiaan muutoksia käyttäjärekisteriin, esimerkiksi uuden käyttäjäryhmän luominen kuuluu ylläpitäjän tehtäviin. Ylläpitäjä voi myös lisätä ja poistaa käyttäjiä käyttäjäryhmästä. Käyttäjäryhmästä voidaan valita yksi tai useampi käyttäjä ryhmän hallinnoijaksi, jolloin jäsenen liittäminen ryhmään ja ryhmästä poistaminen voidaan jättää ryhmän hallinnoijan vastuulle.
Toinen ylläpitäjän tehtävä on huolehtia uusien tietolähteiden lisäämisestä. Koska tietolähteiden tiedostomuoto ei ole aina standardimuotoista, pitää ylläpitäjän joissakin tapauksissa huolehtia tiedon muuttamisesta järjestelmän sisäiseen muotoon. Tämä voidaan tehdä ohjelmoimalla tarkoitukseen sopiva muunnosmoduli.
Jos järjestelmää käytetään osittain mainosrahoitteisesti, ylläpitäjän tehtäviin kuuluu myös mainostajien laskutus.
Matti Meikäläinen kertoo ylläpitäjälle sähköpostitse, että ohjelmistotuotantoryhmälle ZYX pitäisi perustaa järjestelmään oma käyttäjäryhmä, jolloin ryhmän jäsenet voisivat kommunikoida helposti keskenään. Ryhmän hallinnoijaksi pitäisi nimetä Matti Meikäläinen ja Niina Nieminen, jolloin he voivat itse lisätä ryhmään uusia ihmisiä tarpeen mukaan.
Kuopion kaupungilla on sähköinen palveluhakemisto, jossa on listattuna kaikki Kuopion julkiset palvelut, bussien aikataulut, ravintolat, tapahtumat ym. Tämä tietolähde pitäisi lisätä järjestelmään ennen marraskuussa pidettäviä Kuopion XXVII Kalakukkofestivaaleja, jolloin Kuopioon lähtee suuri joukko Converge-järjestelmässä mukana olevia ihmisiä.
Penan Pizza toimii Tampereella ja haluaisi liittyä mukaan järjestelmään mainostajana. Mainoksia pitäisi lähettää kun
joku 15-25-vuotias saapuu Tampereelle klo 17-20 välisenä aikana. Mainoksen sisältö käydään hakemassa päivittäin osoitteesta
http://www.penanpizza.fi/mainos.rdf.
Tiedontarjoajalla tarkoitetaan tietoliikennerajapinnan kautta järjestelmän kanssa keskustelevaa toista järjestelmää. Tiedontarjoajat määritellään siten, että niiden tarjoama tieto on tarkoitettu käyttäjälle välitettäväksi, esimerkiksi sähköpostiviestit.
Aktiiviset tiedontarjoajat voivat rekisteröityä järjestelmän käyttäjiksi ja toki myös lopettaa järjestelmän käytön. Muita toimintoja ovat järjestelmään tarjottavien tietojen lisääminen, muuttaminen ja poistaminen. Lisäksi tiedontarjoajat voivat tutkia tietojensa käyttöön liittyviä lokitietoja.
Sähköpostipalvelin on puolestaan esimerkki passiivisesta tiedontarjoajasta. Tällöin järjestelmän on itse haettava tarvitsemansa tieto tiedontarjoajalta.
Helsinkiläinen pystybaari on joutunut nykyaikaisten kahvilabaarien esiinmarssissa ahdinkoon. Nykyinen asiakaskunta on pieni, ikääntynyt ja maksukyvyltään rajoittunut. Taloudellinen tilanne ei anna mahdollisuutta investointeihin ja rakennuksen uudistamiseen.
Baarin isäntä tietää, että paras myynninedistäjä on halpa hinnoittelu - etenkin alkoholin myynnissä. Potentiaalisen asiakaskunnan informoiminen on kuitenkin tavallisella mainonnalla kallista ja tehotonta. Baaritiskillä notkuva Converge-projektin ex-jäsen kuulee isännän valituksen ja ehdottaa tälle rekisteröitymistä pian valmistuvaan Converge palveluun. Hän selostaa isännälle, kuinka Converge-palvelun avulla kohdennettu mainonta janoisten kännykkään on ''kuin leikkiä vain''.
Pystybaarin isäntä menee kirjaston tietokoneella rekisteröitymissivustolle osoitteessa www.converge.org/mainostajat. Hänen tarvitsee syöttää rekisteröityäkseen ainoastaan yritystunnuksensa, haluamansa käyttäjätunnuksen ja salasanan.
Pystybaarin isäntä kirjautuu järjestelmään osoitteessa www.converge.org/mainostajat (salasanalla ja käyttäjätunnuksella) ja syöttää yritystunnuksen sekä painaa poista rekisteristä painiketta.
Baarin isäntä menee kirjaston tietokoneelle ja kirjautuu www.converge.org/mainostajat sivulla järjestelmään (antaa käyttäjätunnuksen ja salasanan). ''Tuotetietojen syöttö''-sivulla isäntä kirjoittaa ison tuopin nimen ja hinnan sekä tarjousajankohdan.
Baarin isäntä kirjautuu järjestelmään ja menee ''Tuotetietojen
syöttö''-sivulle
(www.converge.org/mainostajat/syotto). Hän poistaa ne tuotteet
joita ei halua enää mainostettavan. Järjestelmä poistaa automaattisesti ne mainokset,
joiden ''parasta ennen'' päivämäärä on mennyt umpeen.
Baarin isäntä kirjautuu järjestelmään ja menee ''Tuotetietojen syöttö''-sivulle. Hän muokkaa tuotenimikkeiden hintoja ja päivämääriä.
Baarin isäntä kirjautuu järjestelmään ja menee ''Ovilaskuri''-sivulle (www.converge.org/mainostajat/ovilaskuri). Sivulla isäntä näkee kuhunkin tuotteeseen kohdistuneet kyselyt, yrityksen yhteystietojen kyselyt ym.
Palveluntarjoajalla tarkoitetaan tietoliikennerajapinnan kautta järjestelmän kanssa keskustelevaa toista järjestelmää. Palveluntarjoajat määritellään siten, että niiden tarjoama tieto ei ole tarkoitettu käyttäjälle välitettäväksi, vaan on järjestelmän sisäiseen käyttöön, esim. palvelu, josta saadaan tieto käyttäjän kännykän sijainnista.
Kuten tiedontarjoajat voidaan myös palveluntarjoajat jakaa aktiivisiin ja passiivisiin: Aktiiviset lähettävät tietoa järjestelmälle ilman, että sitä olisi erikseen pyydetty. Passiiviset palveluntarjoajat tarjoavat sen sijaan järjestelmälle mahdollisuuden kysyä jotakin tietoa tarvittaessa.
| tiedontarjoaja | palveluntarjoaja | |
|---|---|---|
| passiivinen | sähköpostilaatikko | mobiililaitteen paikannus |
| aktiivinen | mainostaja | mobiililaitteen kirjautuminen verkkoon |
| Taulukko 1: Esimerkki tiedontarjoajista ja palveluntarjoajien tarjoamista palveluista | ||
Järjestelmän toiminta ja vaatimukset -osassa annetaan ymmärrettäviä selityksiä järjestelmän tukemista toiminnoista. Kaikki järjestelmän tarjoama toiminnallisuus sekä ominaisuudet kuvataan tarkasti ja yksikäsitteisesti järjestelmälle asetettuina vaatimuksina, jotka määrittelevät millainen toteutettu järjestelmä kaikilta osiltaan on.
Järjestelmä hakee viestit sille annettujen sääntöjen mukaan käyttäjän määrittelemältä postipalvelimelta tai muusta tiedonlähteestä. Viestin nouto voi tapahtua säännöllisesti määrätyn kellonajan mukaan tai kun käyttäjä kirjautuu järjestelmään. Järjestelmä myös ottaa vastaan aktiivisten tiedontarjoajien (esim. mainostajien) lähettämät viestit.
Järjestelmään saapuneiden käyttäjille tarkoitettujen viestien käsittely on keskeinen järjestelmälle kuuluva toiminnallisuus. Saapuneet viestit käsitellään käyttäjän määrittelemien kontekstimallien ja profiilien perusteella. Sama viesti voidaan kontekstimalleihin määriteltyjen muuttujien arvovälien perusteella liittää useisiin viestinäkymiin.
Viestinäkymien sisältö määräytyy käyttäjän määrittelemien kontekstimallien attribuuteista sekä profiissa olevista säännöistä. Sama viesti voi kuulua useaan eri näkymään, mutta järjestelmään saapuneesta viestistä on olemassa vain yksi kopio, johon kaikista näkymistä on mahdollisuus viitata.
Järjestelmä tarjoaa käyttäjälle mahdollisuuden siirtää, poistaa, kopioida ja lukea näkymän sisältämiä viestejä sekä muuttaa niiden tilaa, esim. merkitä viesti luetuiksi.
Viestin poistaminen näkymästä poistaa viestin kyseisestä näkymästä, mutta säilyttää muiden kansioiden näkymät ennallaan. Tämä voidaan kuitenkin kumota antamalla poistotoiminnolle lupa poistaa viesti kaikista niistä näkymistä, joista kyseiseen viestiin on viitattu. Tämän toimenpiteen jälkeen ei viestiin ole järjestelmässä mahdollisuus viitata.
Viestin siirtäminen näkymästä toiseen siirtää viestin viitteen kohdenäkymään sekä poistaa sen alkuperäisestä näkymästä. Siirtämisellä ei ole vaikutuksia muihin viestiin liittyviin näkymiin.
Viestin kopioiminen näkymästä toiseen lisää viestin kohdenäkymään.
Viestin tilan muuttaminen muuttaa käyttäjälle näytettävää näkymää viestin suhteen. Viestin tilan muuttaminen vaikuttaa myös kaikkiin muihin viestiin viittaaviin näkymiin. Viestillä on siis yksikäsitteinen tila, joka on kaikille näkymille sama.
Järjestelmä tarjoaa käyttäjille mahdollisuuden käyttää reaaliaikaista keskustelukanavaa. Kanava toimii käyttäjien välillä siten, että lähettäjä määrittelee vastaanottavan kanavan, jonka jäseninä voi olla joko toinen järjestelmään rekisteröitynyt käyttäjä tai heistä muodostettu ryhmä. Kun käyttäjä lähettää viestin järjestelmään, toimitetaan viesti kaikille järjestelmään sillä hetkellä sisäänkirjautuneena oleville vastaanottajille välittömästi.
Reaaliaikaiselle keskustelukanavalle viestin lähettäminen tapahtuu suoraviivaisesti siten, että kanava, johon käyttäjän käyttämä asiakasohjelma on liittyneenä, on viestin vastaanottaja ilman sen tarkempaa määrittelyä.
Rekisteröityneet käyttäjät voivat muodostaa järjestelmään sisäisiä ryhmiä. Järjestelmä käsittelee ryhmää siten kuin se olisi vain yksi käyttäjä eli toiminnot, jotka ovat mahdollista yksittäiselle käyttäjälle ovat määriteltävissä myös ryhmätasolla esim. ryhmän kontekstimalliin voidaan muodostaa arvovälejä, joilla voidaan hallinnoida ryhmälle lähetettäviä viestejä.
Jokainen järjestelmään rekisteröitynyt käyttäjä voi määritellä itselleen kontekstimalleja. Mallia määritellessään käyttäjällä on mahdollisuus valita järjestelmään määritellyistä muuttujista osajoukko, joka muodostaa kyseisen kontekstimallin. Jokaiselle malliin valitulle muuttujalle käyttäjän tulee määritellä arvoväli, joka kuvaa kyseiselle muuttujalle sallitun arvojoukon, johon saapuvien viestien muuttujien arvoja tullaan vertaamaan.
Käyttäjän on mahdollista muuttaa jo määrittelemiään kontekstimalleja: Tällöin muutokset aktivoituvat järjestelmässä heti käyttäjän hyväksyttyä ne. Muutosten tekeminen kontekstimalleihin seuraa täysin mallien luomisessa määriteltyjä sääntöjä kun muutostoiminnallisuus on käynnistetty.
Käyttäjän on mahdollista luoda järjestelmään uusia profiileja, joiden avulla hän saa järjestelmän tarjoamista toiminnallisuuksista määriteltyä itselleen sopivan kokonaisuuden. Profiilia luotaessa käyttäjän on määriteltävä järjestelmän sisältämistä säännöistä ja toiminnoista osajoukko, joka määrää kyseisen profiilin käyttämät säännöt sekä säännön toteutumisesta seuraavat toiminnot.
Käyttäjälle on mahdollista muuttaa järjestelmään määrittelemiään profiileja. Muutosten tekeminen seuraa luomisen yhteydessä määriteltyjä sääntöjä ja muutokset aktivoituvat järjestelmän käyttöön käyttäjän ne hyväksyttyä.
Kontaktilistat ovat käyttäjän määrittämiä kontaktitietoja sisältäviä listoja. Ne toimivat samaan tapaan kuin useimmissa sähköpostiohjelmissa olevat osoitekirjat.
Järjestelmälle asetetaan mahdollisesti suurten samanaikaisten käyttäjämäärien vuoksi korkea vikasietoisuuden taso. Tällä tarkoitetaan, että järjestelmä ei saa kaatua, jumittua tai muuten tulla toimintakyvyttömäksi toiminnallisten virheiden vuoksi. Virhetilanteet tulee rajata siten, että yhdessä käyttäjäsäikeessä tulevat häiriöt pysyvät paikallisina ja järjestelmä voi pahimmillaan joutua alustamaan uudelleen mahdollisesti häiriöllisen osan (esim. hallitsemattomassa tilanteessa katkaistaan yhteys asiakasohjelmaan).
Järjestelmän palvelun suorituskyvyn on pysyttävä yleisesti hyväksyttävissä rajoissa, jona voidaan pitää esimerkiksi palvelun välittömyyttä eli palautteen käyttäjälle on tultava niin nopeasti, että käyttäjä ei koe viivettä häiritsevänä.
Järjestelmän tulee pystyä hallitsemaan useita rinnakkaisia käyttäjiä siten, että järjestelmän käytettävyys säilyy hyvänä. Hyvän käytettävyyden rajana voidaan pitää loppukäyttäjien palautteena saatujen suorituskyky- sekä toimintavarmuusvaatimusten täyttymisarviot.
Järjestelmän rakenteelle asetetaan modulaarisuuden kannalta vaatimus, että toimintalogiikka on jaettu osiin siten, että toiminnan kannalta yhden toimintakokonaisuuden hoitaa yksi moduuli. Tällä saavutetaan ylläpidettävyyttä sekä vaihdettavuutta järjestelmän osille, mitkä ovat hyvin todennäköisiä tarpeita tämän tyyppiselle laajalle ja uutta ongelmaa käsittelevälle järjestelmälle.
Järjestelmälle tarkoitettu toiminta asettaa järjestelmälle vaatimuksen myös siitä miten järjestelmän toiminnallisuutta hallinnoidaan. Koska samanlaisen toiminnon voi laukaista monta täysin erilaista rinnakkain suorittavaa alijärjestelmää, joiden tarpeet toiminnon osalta saattavat myös olla täysin erilaisia, on järjestelmän toimittava tapahtumapohjaisesti. Tällöin toimintoa kutsuva alijärjestelmä rekisteröityy kuuntelijaksi tarvitsemalleen tapahtumantuottajalle ja vastaanottaa kapseloidun tapahtuman, jota kuuntelija voi itse käsitellä sekä kutsua tarvittavaa toiminnontarjoavaa alijärjestelmää. Tapahtumantuottaja voisi olla esimerkiksi moduuli, joka lähettää tapahtuman käyttäjän ilmestymisestä linjoille esim. http-yhteys muodostettu.
Järjestelmä kirjaa tapahtumia lokitiedostoon. Kerättyä aineistoa on mahdollisuus hyödyntää alan tutkimuksessa.
ClientManagerissa toteutetaan rajapinta, jonka avulla järjestelmään voidaan liittää erilaisia asiakassovelluksia tukevia alimoduuleja. Nämä alimoduulit voivat tukea joko kaikkia rajapinnan ominaisuuksia tai vain osaa siitä. Esimerkiksi SOAP-protokollalla toteutettu viestintä pystyisi tukemaan sääntöjen lisäämistä järjestelmään, mutta IMAP-protokollan toteutus ei siihen välttämättä pystyisi.
Tässä järjestelmässä Droolsia käytetään viestien käsittelyssä määrittelemään viestiin kohdistuvaa toimintoa. Syötteenä Drools saa XML-muotoisia sääntödokumentteja ja kulloinkin tarkasteltavana olevan viestin. Sääntöjen määräämänä tämä sääntökäsittelijä tekee viestille halutut toimenpiteet, esimerkiksi lähettää sen edelleen ClientManagerille.
ServiceManager mahdollistaa erilaisten tietolähteiden liittämisen järjestelmään. Jokaista erityyppistä lähdettä varten voidaan liittää erillinen alimoduuli, joka muokkaa saamansa tiedon järjestelmän sisäiseen muotoon. Tällä tavoin erilaisten tietolähteiden tuottama tieto voidaan käsitellä järjestelmässä samalla tavalla.
Esimerkkitapaus ajastetusta tehtävästä voisi olla käyttäjän profiiliin liitetty toiminto hakea uudet sähköpostiviestit tasaisin väliajoin.
Käyttäjien etukäteen määrittelemien tapahtumien hallinnointia varten järjestelmään liitetään kalenteri, jonka avulla käyttäjä pystyy esim. automatisoimaan profiiliensa muutoksia ja vaihtoja.
Tärkein toteutettavista rajapinnoista on IMAP-postin haku sähköpostipalvelimelta. Vastaavasti täytyy toteuttaa rajapinta, jonka kautta järjestelmä kommunikoi erilaisten asiakasohjelmien kanssa. Tässä laajennetaan mahdollisesti XML-pohjaista SOAP-protokollaa. Asiakasohjelma, joka käyttää järjestelmää kyseisen rajapinnan kautta, toteutetaan - ainakin prototyyppiversiona.
Muita järjestelmään tarvittaessa liitettäviä rajapintakomponentteja voisivat olla esimerkiksi uutisryhmien lukua tukeva komponentti, mainostajien viestejä vastaanottava komponentti ja mobiililaitteiden paikkatietoa kyselevä komponentti.
Tässä dokumentissa määritelty järjestelmä on kokonaisuudessaan kooltaan ja aikavaatimukseltaan niin iso, että projektiryhmällä ei ole mahdollisuutta projektin rajatussa aikataulussa toteuttaa järjestelmää tässä mittakaavassa. Tässä luvussa määritellään toteutettavat järjestelmän osat.
Osa aiemmin luetelluista käyttötapauksista on tarkoitettu vain antamaan viitteitä ohjelman jatkokehitystä varten, mm. mainostajien käyttötapaukset. Toteutettava prototyyppi ei siis välttämättä tue kaikkia lueteltuja käyttötapauksia.
Projektiryhmän tulee määritellä ne kaikki osat sekä toiminnallisuus järjestelmästä, jotka kuuluvat asiakkaan vaatimusten mukaan kokonaisuutena toteutettavaan järjestelmään.
Toteutusvaiheessa toteutettava prototyyppi määritellään kokonaisuuden osajoukkona siten, että prototyyppi ei tule tukemaan kaikkia aiemmin kuvattuja järjestelmän ominaisuuksia. Osa ominaisuuksista jätetään kokonaan prototyypissä toteuttamatta ja osa tullaan toteuttamaan vain osittain. Rajaus prototyypin osalta määritellään otsikon Toteutusvaiheen rajaus sekä prototyypin määrittely alla.
Projektiryhmän tulee suunnitella järjestelmä siten, että tarkka suunnittelu tehdään ainoastaan toteutusvaiheessa toteutettavan prototyypin osalta. Prototyypin suunnittelun ulkopuolelle jäävät järjestelmän osat oletetaan olemassa oleviksi valmiiksi alijärjestelmiksi, joiden käyttöönoton suunnittelu oletetaan myös olevan valmis.
Reaaliaikaista keskustelukanavaa varten voidaan käyttää esimerkiksi Jabber-arkkitehtuurin mukaista XML-pohjaista viestintäprotokollaa, jonka voidaan olettaa olevan valmiiksi suunniteltu ja toteutettu alijärjestelmä. Järjestelmää suunniteltaessa otetaan huomioon reaaliaikaisen keskustelukanavan viestien käsittely siten, että viestien käsittelyn mahdollistaminen ei vaadi ohjelmaan kohtuuttoman isoja muutoksia.
Projektiryhmän tulee rajata määrittelystä ne osat järjestelmästä, jotka se aikoo toteuttaa järjestelmän prototyyppiin projektille asetetussa aikataulussa sekä määritellä mahdolliset muutokset asetetuille vaatimuksille.
Järjestelmän prototyyppiin tullaan toteuttamaan valittuun tietokantaan rajapinta, jota tietokantatoiminnallisuuden järjestelmälle tarjoava komponentti voi hyödyntää.
Prototyypissä tullaan tarjoamaan käyttäjille mahdollisuus selailla ja lukea hänelle lähetettyjä sähköpostiviestejä, jotka noudetaan hänen määrittelemältään IMAP-palvelimelta SSL-suojausta käyttäen. Viestit tallennetaan tietokantaan myöhempää käyttöä varten.
Projektissa tullaan toteuttamaan asiakasrajapintaan liitettävä HTTP-rajapinta, johon voidaan ottaa yhteys olemassa olevilla WWW-selaimilla. Rajapinta tarjoaa toimintoja, joita voidaan hallinnoida asiakasohjelmistolla. Näitä toiminnallisuuksia ovat järjestelmään sisäänkirjautuminen, järjestelmään käyttäjälle toimitettujen viestien lukeminen ja poistaminen, profiilien määrittäminen.
Koska asiakasohjelmistona käytetään WWW-selainta, voi asiakasohjelmiston ulkonäkö vaihdella käytetystä WWW-selaimesta riippuen. Asiakasohjelmistolle ei tehdä käytettävyystestausta.
Prototyypin toiminnallisuuteen liittyy käyttäjälle lähetettyjen sähköpostiviestien selailu ja lukeminen, joten tiedontarjoajarajapintaan tullaan toteuttamaan IMAP-rajapinta SSL-tuella postipalvelimien kanssa kommunikointiin.
Toteutettavan prototyypin toimintavarmuuden hyväksyttäväksi rajaksi asetetaan hallittu toiminnon lopettaminen virhetilanteissa. Tällainen toimintavarmuus taataan prototyypillä enintään viiden yhdenaikaisen käyttäjän hallinnoinnille. Järjestelmän ei tarvitse pystyä itsenäisesti toipumaan virhetilanteista, mutta täydellinen kaatuminen ei ole toivottavaa ja virhetilanteen aiheuttaneen moduulin on tuotettava lokitieto tilanteesta.
Käyttäjän pitää pystyä kirjautumaan sisään järjestelmään ja määrittämään itselleen haluamansa profiilitiedot. Myös ylläpitäjä voi muokata käyttäjien tietoja.
Käyttäjäryhmien luomisesta ja muusta hallinnasta huolehtii ylläpitäjä.
Järjestelmään toteutetaan sääntökäsittelijä, joka käyttäjän antamien profiilimallitietojen ja käyttäjän kontekstin perusteella tekee saapuville viesteille käyttäjän haluamat toiminnot.
Järjestelmän käytöstä kerätään lokitietoja mahdollisten virhetilanteiden selvittämiseksi ja myös tutkijoiden tarpeita varten. Lokiin tulevat tärkeimmät virheilmoitukset sekä myös tilastotietoa järjestelmän käytöstä.
Lista niistä ominaisuuksista tai komponenteista, jotka halutaan korostetusti rajata toteutuksen ulkopuolelle.
Reaaliaikaisen keskustelukanavan viestien talletus
Reaaliaikaisessa keskustelukanavassa käyttäjien toisilleen lähettämiä viestejä ei
tallenneta järjestelmän kantaan. Käyttäjät, jotka eivät ole sisäänkirjautuneina
viestin järjestelmään saapumishetkellä eivät siis tule viestiä vastaanottamaan.
Palveluntarjoajan rajapinta
Prototyypissä ei tulla hyödyntämään mahdollisesti jo olemassa olevien palveluntarjoajien
palveluita, joten yhtään niiden tarvitsemaa rajapintaa ei tulla toteuttamaan.
Tämä dokumentti tehtiin ohjelmistolla LaTeX2HTML translator Version 2002 (1.62)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
Komentoriviargumentit olivat:
latex2html -split 0 maarittelydokumentti.tex.
Komennon ajoi Joni J Karppinen 2002-11-12
![\includegraphics[width=1.0\textwidth]{graphics/basicuser.eps}](img2.png)
![\includegraphics[width=0.9\textwidth]{graphics/rootuser.eps}](img3.png)
![\includegraphics[width=0.9\textwidth]{graphics/tiedontarjoaja.eps}](img4.png)
![\includegraphics[width=0.8\textwidth]{graphics/moduulit.eps}](img5.png)