next_inactive up previous


Määrittelydokumentti

Convergence of messaging

The Converge Group


Sisältö

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

Johdanto

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.

Yleiskuva järjestelmästä

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.

Termien määrittely

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

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.

Kuva 1: Kontekstit voivat olla rinnakkaisia tai sisäkkäisiä
\includegraphics[width=0.9\textwidth]{graphics/kontekstit.eps}

Attribuutti

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ääntö

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''.

Kontekstimalli

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.

Profiili

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.

Käyttäjät ja sidosryhmät

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ä

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ä.

Kuva 2: Käyttötapaus: peruskäyttäjä
\includegraphics[width=1.0\textwidth]{graphics/basicuser.eps}

Käyttötapausesimerkkejä

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.

Järjestelmään rekisteröityminen

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.

Järjestelmän käytön lopettaminen

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.

Kontekstimallin muokkaus (luonti, muutos, poisto)

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''.

Viestien lukeminen

Timo R-O tutkii erään Converge järjestelmään liittyneen sääpalvelun ajantasaisia säätietoja autotietokoneestaan matkalla kohti Helsinki-Vantaan lentoasemaa.

Esimerkkejä järjestelmän käytöstä

Sääntöjen luonti/muutos, viestien lukeminen

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.)

Reaaliaikaisen viestin lähetys

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ä

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.

Kuva 3: Käyttötapaus: ylläpitäjä
\includegraphics[width=0.9\textwidth]{graphics/rootuser.eps}

Käyttötapausesimerkkejä

Käyttäjäryhmän perustaminen

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.

Käyttäjäryhmän tietojen muuttaminen

ZYX:n Matti Meikäläinen sai hyvän työtarjouksen Nokialta ja päätti keskeyttää opintonsa. Nyt hänet pitäisi poistaa ZYX:n ryhmästä, ettei Nokia saisi tietoonsa luottamuksellista ZYX:n informaatiota.

Käyttäjäryhmän poistaminen

Ohjelmistotuotantoryhmä ZYX sai työnsä kunnialla päätökseen, joten nyt Convergeen ZYX:lle luotu ryhmä pitäisi poistaa.

Tietolähteiden lisääminen

Järjestelmän käyttäjä Heikki kertoo ylläpitäjälle uudesta tietolähteestä, joka olisi hyvä laittaa mukaan Convergen tietolähdevalikoimaan. Tietolähteen osoite on http://slashdot.org/slashdot.rdf ja se pitäisi luokitella alueelle ''Tietokoneet''.

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.

Tietolähteiden poistaminen

Microsoft osti Slashdotin emoyhtiön, ja tämän seurauksena Slashdotin tietolähteen muoto muuttui standardista RDF:stä Microsoftin omaksi kopiosuojatuksi tiedostomuodoksi, jota Converge ei pysty käsittelemään ilman lisenssimaksun maksamista. Slashdotin tiedot pitäisi saada poistettua järjestelmästä kunnes lisenssiasiat saadaan selvitettyä.

Tiedontarjoajat

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.

Kuva 4: Käyttötapaus: aktiivinen tiedontarjoaja
\includegraphics[width=0.9\textwidth]{graphics/tiedontarjoaja.eps}

Käyttötapausesimerkkejä

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''.

Yritys rekisteröityy palvelun käyttäjäksi

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.

Yritys poistaa itsensä rekisteristä

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.

Yritys syöttää mainostettavat tuotetiedot järjestelmään.

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.

Yritys poistaa mainostettavat tuotetiedot järjestelmästä

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.

Yritys muuttaa syötettyjä tuotetietoja

Baarin isäntä kirjautuu järjestelmään ja menee ''Tuotetietojen syöttö''-sivulle. Hän muokkaa tuotenimikkeiden hintoja ja päivämääriä.

Yritys tutkii lokitietoja

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.

Palveluntarjoajat

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

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.

Viestien hakeminen järjestelmään

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.

Saapuneiden viestien käsittely

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ö

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.

Viestin manipulointi

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.

Reaaliaikainen keskusteluryhmä

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ä.

Ryhmien hallinta

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ä.

Kontekstimallin luominen

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.

Kontekstimallin muuttaminen

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.

Profiilin luominen

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.

Profiilin muuttaminen

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

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.

Toimintavarmuus ja suorituskyky

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ä.

Rinnakkaisuus

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.

Modulaarisuus

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.

Tapahtumapohjaisuus

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.

Lokitietojen kerääminen

Järjestelmä kirjaa tapahtumia lokitiedostoon. Kerättyä aineistoa on mahdollisuus hyödyntää alan tutkimuksessa.

Moduulirakenne

Järjestelmä voidaan toiminnallisuuden mukaan jakaa useaan moduuliin, joita tässä luvussa kuvataan karkealla abstraktiotasolla, jota tullaan myöhemmin suunnitteluvaiheessa tarkentamaan.
Kuva 5: Moduulirakenne
\includegraphics[width=0.8\textwidth]{graphics/moduulit.eps}

Database

Järjestelmän pysyviksi tarkoitetut tiedot tallennetaan tietokantaan.

ClientManager

ClientManager liittää asiakasohjelmistot järjestelmään. Sen tarjoamia palveluita ovat järjestelmään liittyminen ja poistuminen, sisään- ja uloskirjautuminen, viestien vastaanotto ja lähetys sekä erilaisten sääntöjen lisäys, muokkaus ja poisto.

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.

UserManager

Käyttäjätietojen hallintaa varten tarvitaan UserManager, jonka avulla luodaan, muokataan ja poistetaan käyttäjän sekä ryhmien tietoja. Käyttöliittymänä toimii myös tässä yhteydessä ClientManagerin kanssa keskusteleva asiakasohjelma. (Kaikki järjestelmää tukevat asiakasohjelmat eivät välttämättä tue käyttäjätietojen hallintaa, mutta ainakin yhden täytyy siihen pystyä.)

ContextEngine

ContextEnginessä tehdään päätöksiä viestien käsittelystä ja kantaan tallentamisesta. Se määrittelee viestin, profiilien ja käyttäjän kontekstin avulla, mitä viestille tulee tehdä ja tarvittaessa antaa tiedot edelleen Drools-sääntökäsittelijälle.

Drools

The Werken Companyn Drools on sääntöjen käsittelyyn tehty väline. Sen avulla voidaan syötteenä saadun datan ja sääntöjen perusteella päättää, mitä datalle tulee tehdä. Toteutus käyttää hyväkseen Charles Forgyn kehittämää Rete-algoritmia.

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

Jotta järjestelmä voisi hakea tai saada viestejä, tarvitaan tiedontarjoajarajapinta. Sen avulla voidaan järjestelmään liittää erilaisia tiedonlähteitä, joista osa on mahdollisesti passiivisia, esimerkiksi sähköpostipalvelin, ja osa aktiivisia, esimerkiksi mainostaja.

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.

Activator

Activator-moduuli toimii tehtävien ajastajana ja samalla sen tulee hallita muun muassa säikeiden toimintaa.

Esimerkkitapaus ajastetusta tehtävästä voisi olla käyttäjän profiiliin liitetty toiminto hakea uudet sähköpostiviestit tasaisin väliajoin.

Calendar

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.

Ulkoiset liittymät

Järjestelmään voidaan liittää erilaisia viestintärajapintoja tarjoavia komponentteja. Nämä komponentit muuttavat ulkopuolelta tulevan tiedon järjestelmän sisäiseen muotoon ja järjestelmästä tulevan tiedon rajapintaa käyttävien sovellusten tarvitsemaan muotoon.

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.

Projektin toteutuksen rajaukset

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.

Määrittelyvaiheen rajaus

Projektiryhmän tulee määritellä ne kaikki osat sekä toiminnallisuus järjestelmästä, jotka kuuluvat asiakkaan vaatimusten mukaan kokonaisuutena toteutettavaan järjestelmään.

Toteutettavan prototyypin määrittely

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.

Suunnitteluvaiheen rajaus

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.

Reaaliaikainen keskustelukanava

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.

Toteutusvaiheen rajaus sekä prototyypin määrittely

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.

Tietokantarajapinta

Järjestelmän prototyyppiin tullaan toteuttamaan valittuun tietokantaan rajapinta, jota tietokantatoiminnallisuuden järjestelmälle tarjoava komponentti voi hyödyntää.

Sähköpostiviestien noutaminen

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.

Asiakasrajapinta

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.

Tiedontarjoajarajapinta

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.

Toimintavarmuus

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ähallinta

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ä.

Profiilit, profiilimallit, säännöt

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.

Lokitietojen kerääminen

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ä.

Toteuttamatta jätettävät komponentit

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ästä dokumentista ...

Convergence of messaging

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


next_inactive up previous
Joni J Karppinen 2002-11-12