![\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
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ä ja tehdään päätös viestin eteenpäin toimittamisesta sekä kohteesta, johon viesti toimitetaan. 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.
Järjestelmää voidaan käyttää myös tiedostonhallintaan. Esimerkiksi käyttäjän vastaanottaessa viestin, joka sisältää liitetiedoston, poistetaan liitetiedosto käyttäjälle toimitettavasta viestistä ja lähetetään pointteri, joka kertoo, mistä kyseinen liitetiedosto on luettavissa.
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, jotka voivat olla epämääräisiä tai niiden tarkoitus ja sisältö on 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, mitkä liittyvät kyseessä olevaan tilanteeseen. Henkilö voi kuulua samanaikaisesti moneen eri asiayhteyteen, kontekstiin, jotka voivat suhtautua toisiinsa siten, että ne ovat erillisiä, toisiansa 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 samaan aikaan täysin erillinen konteksti, joka henkilölle pätee, olisi hänen vankkumaton kiinnostuksensa kaikkeen urheiluun ja kuulumisensa TPS:n jalkapalloseuraan.
Tässä dokumentissa kontekstilla tarkoitetaan käyttäjään liittyvistä, tietyllä ajanhetkellä vallitsevista, reaalimaailman tilanteista ja järjestelmän sisäistä käsitystä niistä. Järjestelmän sisäinen käsitys käyttäjän reaalimaailman kontekstista määritellään järjestelmässä määriteltyjen muuttujien avulla, määrittelemällä niille tilannetta kuvaavat arvot esim. kännykkä, Helsinki, klo 8.15.
Termi kontekstimalli tarkoittaa käyttäjän järjestelmään määrittelemää kuvausta jostain reaalimaailman kontekstistaan. Järjestelmään on määritelty joukko attribuutteja, joista valitaan osajoukko kuvaamaan kontekstimallia. Malliin liitetyille attribuuteille määritellään arvoväli, jonka tarkoitus on rajata kyseisen attribuutin arvot, joilla attribuutin voidaan todeta toteuttavan määritellyn kontekstimalliin vaatimukset. Termeillä kontekstimalli ja konteksti viitataan samaan asiaan, mutta ero niiden välillä on kuitenkin selvä. Kontekstimalli on järjestelmään ohjelmallisesti attribuuttien ja funktioiden avulla luotu kuvaus. Kontekstimalliin voidaan esimerkiksi määritellä attribuutille nimeltä ''kello'' arvoväli 8-16, jolloin malli kuvaa reaalimaailman kontekstia joka on voimassa vain annetun arvovälin aikana.
Ero kontekstin ja profiilin välillä on pieni. Profiili eroaa kontekstista ainakin siinä, että profiili luettelee vain henkilöön itseensä liitettäviä ominaisuuksia. Sivistyssanakirja luonnehtii profiilin seuraavasti:
''Profiili : ominaispiirteet, luonteenomaiset piirteet; erityiset ominaisuudet t. niiden kuvaus; ääriviivat; poikkileikkaus. Muut merkitykset ovat syntyneet siitä, että sellaisen on katsottu sisältävän kohdetta luonnehtivan esityksen. Nykyisin sana viittaa usein jonkin joukon ominaisuuksiin, esim. ''asiakasprofiili'' 'asiakaskunnan yleiset ominaisuudet ja jakautuminen eri asiakastyyppeihin'.''
Profiili ei siis pidä sisällään ympäristöä ja tilannetta kuvaavia ominaisuuksia.
Esimerkiksi projektipäällikön profiiliin ei voitaisi liittää tietoa henkilöä (on kiinnostunut urheilusta sekä kuuluu TPS:n jalkapallojoukkueeseen) sillä hetkellä ympäröivästä tilanteesta tai ympäristöstä.
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. Esimerkiksi käyttäjä määrittelee säännön, joka käyttää eri vastaanottavaa päätelaitetta eri vuorokaudenaikaan: virka-aikana kaikki viestit näkyvät vain esim. WWW-selaimen asiakasohjelman kautta, muulloin viestit ohjataan esim. tekstiviestinä GSM-puhelimeen.
Termiä attribuutti käytetään kuvaamaan yksikäsitteisesti nimettyä yksikköä, jolle voidaan määrätä attribuutin tyypin mukainen arvo. Attribuutti kuvataan kolmikkona, jossa attribuutilla on tyyppi, nimi ja arvo esim. <lähetyskanavan ominaisuus> <kännykkä linjoilla> <kyllä>. Attribuutin arvokenttä voi olla joko yksikäsitteinen esim. kyllä/ei, tai se voi vaatia ajonaikaista laskemista, jolloin arvo on itse asiassa funktio. Attribuutin arvo lasketaan kyseiselle attribuutille sen mukaan mitkä ovat funktion käsittelemien muiden attribuuttien arvot esim. attribuutin A:n arvo on ''Kyllä'' ja B:n ''Kyllä'' ja funktion tuottama tulos saadaan laskusäännöllä A == B, jolloin attribuutti, jonka arvokenttään on tällainen funktio sidottu, saa ajonaikaisesti lasketun arvon ''Kyllä''.
Tällä tavalla jaotelluita attribuutteja kutsutaan alemmiksi attribuuteiksi kun arvolle on yksikäsitteinen tiedonlähde ja ylemmiksi attribuuteiksi kun arvon määrittäminen vaatii funktiolaskennan suorittamisen.
Kuten edellisessä kappaleessa todettiin, funktio on arvon tuottava laskusääntö, jonka tulos riippuu syötteenä annettavien attribuuttien arvoista. Tämä on funktion perusperiaate ja siten kaikki funktion attribuutit näkevät, mutta itse funktiot voidaan jakaa toiminnallisuuden mukaan ryhmiin. Funktioissa käytettävien attribuuttien arvot voivat olla riippuvaisia jonkin toisen funktion laskennan tuloksesta. Tällaisia toisia funktioita käyttäviä funktioita kutsutaan ''korkean tason funktioiksi''. ''Alemman tason funktioiden'' toiminta ei edellytä toisen funktion käyttöä, vaan palautettava arvo pystytään laskemaan olemassa olevien toisten attribuuttien arvojen perusteella. Toisaalta ''alemman tason funktioksi'' kutsutaan myös funktiota, jonka toimintaan ei liity attribuutteja, vaan sen tehtävänä on selvittää haluttu arvo. Esimerkiksi funktio FA:n toimintona on selvittää saapuneesta viestistä lähettäjän metatiedon arvo ja palauttaa se.
Termillä toiminto tarkoitetaan järjestelmän toiminnallisuuden tuottavia alijärjestelmiä, jotka tuottavat toiminnallisen palvelun sitä kutsuvalle tai käyttävälle taholle, esimerkiksi alijärjestelmä, joka huolehtii vain viestin fyysisestä lähettämisestä käyttäjän aktiiviseen päätelaitteeseen.
Säännöt ovat toiminnan laukaisevia loogisia lausekkeita, joiden toiminta on samantyyppistä kuin funktioiden, mutta ne eivät palauta mitään arvoa vaan tuottavat joko toiminnon laukeamisen tai toiminnon mahdollisen suorituksen hylkäämisen. Esimerkiksi määritelty sääntö, jossa on ehtoina, että jos funktion FA:n arvo muuttujan B ja C numeerisilla arvoilla >(on suurempi kuin) 200 ja muuttujan D arvo on ''Kyllä'' niin sitten laukaistaan toiminta ''viestin lähetys käyttäjälle''.
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 aktivoida järjestelmän toiminnallisuudet käyttöönsä on hänen kirjauduttava sisään järjestelmään. Tällöin järjestelmä tiedostaa käyttäjän olevan tavoitettavissa ja käyttäjää koskeva järjestelmän toiminnallisuus asetetaan aktiiviseen toimintaan.
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ä.
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 Converge-client -ohjelmaan, joka hänen Windows-työpöydällään onkin valmiiksi auki. Ohjelman ''Reaaliaikainen viestintä''-välilehdellä hän kirjoittaa uuden IM-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ä, loggautuneena järjestelmään oman clienttinsa kautta, ja hän huomaakin heti uuteen ikkunaan avautuvan viestin Samilta; kahdelle muulle viesti välittyy automaattisesti kännykkään.
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: 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. Koska paras ilma näyttää olevan Mombasassa ostaa hän lennon sinne.
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än voi tehdä joko kirjoittamalla sopiva muunnosmoduli tai muuttamalla saapuvan XML-tiedon muotoa määriteltyjen sääntöjen perusteella.
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.
Pizzamainoksia on lähetetty edellisen kuukauden aikana yhteensä 1218 kappaletta, ja mainoksista lähetetään lasku Penan Pizzalle.
Tutkijat ovat henkilöryhmä, jonka tavoitteena voidaan ajatella olevan tutustuminen järjestelmän toimintaan ulkoisien ominaisuuksien, sisäisen rakenteen tai jopa toteutettujen algoritmien tasolla.
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.
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.
| tiedontarjoaja | palveluntarjoaja | |
|---|---|---|
| passiivinen | sähköposti | mobiililaitteen paikannus |
| aktiivinen | mainostaja | mobiililaitteen kirjautuminen verkkoon |
| Taulukko 1: Esimerkki tiedontarjoajien ja palveluntarjoajien eroista | ||
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.
Peruskäyttäjälle järjestelmä näyttää tavalliselta postipalvelimelta siten, että käyttäjä pystyy käyttämällään client-ohjelmistolla näkemään ja lukemaan kaikki hänelle lähetetyt sähköpostiviestit.
Järjestelmään ei kuitenkaan voi lähettää suoraan sähköpostiviestejä, vaan käyttäjän pitää konfiguroida järjestelmään hänen oikean sähköpostipalvelimensa osoite josta järjestelmä käy noutamassa uudet viestit tarpeen mukaan. Käyttäjä voi määritellä järjestelmään useita sähköpostipalvelimia.
Normaalille käyttäjälle järjestelmä näyttää tavalliselta uutisryhmäpalvelimelta siten, että käyttäjä pystyy käyttämällään client-ohjelmistolla lukemaan kaikki haluamansa uutisryhmiin lähetetyt viestit.
Järjestelmä ei itse kuitenkaan toimi uutisryhmäpalvelimena vaan käyttäjän pitää konfiguroida järjestelmään käyttämiensä uutisryhmäpalvelimien osoitteet.
Järjestelmään saapuneiden käyttäjille tarkoitettujen viestien käsittely on keskeinen järjestelmälle kuuluva toiminnallisuus. Toiminta-ajatuksena on, että käyttäjä määrittelee kontekstimallin, jossa kuvataan saapuvalle viestille asetettavien vaatimusten raja-arvot, esimerkiksi Työ-kontekstimalliin kuuluvat vain työpaikan esimieheltä työaikana (8-16) lähetetyt viestit. Sama viesti voi kontekstimalleihin määriteltyjen muuttujien arvovälien perusteella kuulua useaan kontekstimalliin, tällöin se on myös löydettävissä usean kontekstimallin kansion sisältä.
Viestinäkymien sisältämiä viestejä ei säilytetä fyysisesti kopioituna fyysisissä kansioissa. Kansiot ovat loogisia näkymiä käyttäjän viesteihin, jolloin näkymien sisältämät viestit rakentuvat näkymään liitetyn tietokantakyselyn perusteella. Tällöin viestistä on järjestelmässä vain yksi kopio, joka on kaikkien näkymien saatavissa.
Järjestelmä tarjoaa käyttäjälle kansiohierarkisen hallinnoinnin saapuneille viestelle, missä jokaiselle kontekstimallille luodaan oma kansionsa johon saapuneet viestit sijoitetaan, ellei käyttäjä ole määritellyt viesteille kohdekansiota. Käyttäjälle tarjotaan mahdollisuus siirtää, poistaa, kopioida ja lukea kansion sisältämiä viestejä sekä muuttaa niiden tilaa, esim. merkitä luetuiksi.
Viestin poistaminen kansiosta poistaa viestin kyseisestä kansiosta, mutta säilyttää muiden kansioiden näkymät ennallaan. Tämä voidaan kuitenkin kumota antamalla poistotoiminnolle lupa poistaa kaikki kyseiseen viestiin olevat näkymät eli viestiin ei tämän jälkeen ole järjestelmässä mahdollisuus viitata.
Viestin siirtäminen kansiosta toiseen siirtää viestin viitteen kohdekansioon sekä poistaa sen alkuperäisestä kansiosta. Siirtäminen ei vaikuta muissa kansioissa mahdollisesti oleviin viestin viitteisiin.
Viestin kopioiminen kansiosta toiseen lisää viestin kohdekansion näkymään.
Viestin tilan muuttaminen muuttaa käyttäjälle näytettävän kansion näkymää viestin suhteen. Viestin tilan muuttaminen vaikuttaa myös kaikkiin muihin viestin sisältävien kansioiden näkymään, viestillä on siis yksikäsitteinen tila, joka on kaikille kansioille 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ä.
Järjestelmään rekisteröityneiden käyttäjien on mahdollista 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ä.
Kuka tahansa rekisteröityneistä käyttäjistä voi muodostaa ryhmän. Tällöin tästä käyttäjästä tulee tämän ryhmän vastuuhenkilö, jolle on määritelty oikeus hallinnoida ryhmää. Muut rekisteröityneet käyttäjät voivat listautua ryhmään pyrkivien listalle, josta vastuuhenkilö voi heidät ryhmän jäseneksi hyväksyä. Vastuuhenkilö ei voi liittää ryhmään jäseniä, jotka eivät ole pyrkivien listalle listautuneet. On kuitenkin mahdollista muodostaa hyväksyttävien jäsenten lista etukäteen, jolloin kyseisiltä käyttäjiltä vahvistetaan ryhmään kuuluminen automaattisesti ensimmäisessä tarvittavassa tilanteessa.
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än ulkopuolelle rajataan ominaisuuksia, jotka eivät kuulu suoraan tässä projektissa määriteltävään ja suunniteltavaan järjestelmään, mutta saattavat vaatia erillisen huomion puuttumiselleen. Tässä osassa mainittujen poissuljettujen ominaisuuksien lisäksi järjestelmän ulkopuolelle jää myös kaikki, mitä ei ole erikseen vaatimuksiksi määritelty.
Kun käyttäjä on sisäänkirjautuneena, voi hän käyttää järjestelmän tarjoamia palveluja sähköposti- ja uutisryhmäviestien lukemiseen liittyen. Järjestelmä siis noutaa viestit oikealta palvelimelta ja prosessoi ne käyttäjän määrittelemien kontekstimallien ja profiilien mukaan sekä lähettää käyttäjälle hänellä käytössä olevaan asiakaspäätteelle. Järjestelmä ei kuitenkaan tule tukemaan toiminnallisuutta, jolla käyttäjä voisi käyttämällään asiakasohjelmalla lähettää viestin järjestelmään käsiteltäväksi ja edelleen lähetettäväksi oikealle palvelimelle. Viestinnän suunta on siis järjestelmän kannalta yksisuuntaista. Jos käyttäjä haluaa lähettää postia toiselle järjestelmään rekisteröityneelle käyttäjälle, on hänen lähetettävä viesti omalle oikealle palvelimelleen, joka välittää viestin edelleen oikeaan osoitteeseen ja siten tavoittaa toisen käyttäjän.
Järjestelmään on kuitenkin toteutettu palvelu, joka palauttaa kutsuttaessa käyttäjän konfiguroiman palvelimen osoitteen. Tällöin on mahdollista toteuttaa asiakasohjelma rajapintaan palvelu, joka ottaa asiakaspäätteeltä vastaan lähetettävän viestin ja välittää sen edelleen eteenpäin, mutta ei kuitenkaan anna sitä suoraan järjestelmän käsiteltäväksi.
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 toteutettava WWW-pohjainen käyttöliittymä tukee sääntöjen lisäämistä järjestelmään, mutta (ei toteutettava) IMAP-protokollan toteutus ei sitä välttämättä tukisi.
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.
Tärkein toteutettavista rajapinnoista on IMAP-postin haku sähköpostipalvelimelta. Vastaavasti täytyy toteuttaa jokin rajapinta, jolla peruskäyttäjä pystyy lukemaan sähköpostiviestinsä. Tässä asiakaspuolen protokollassa laajennetaan XML-pohjaista SOAP-protokollaa. Asiakasohjelma, joka käyttää järjestelmää kyseisen rajapinnan kautta, toteutetaan - ainakin prototyyppiversiona.
Muita järjestelmään tarvittaessa liitettäviä rajapintakomponentteja ovat muun muassa uutisryhmien lukua tukeva komponentti, mainostajien viestejä vastaanottava komponentti ja mobiililaitteiden paikkatietoa kyselevä komponentti. Eli järjestelmän sisäisen rajapinnan avulla voidaan siihen liittää hyvinkin erilaisia ulkoisia rajapintoja.
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.
Projektiryhmän tulee määritellä ne kaikki osat sekä toiminnallisuus järjestelmästä, jotka kuuluisivat asiakkaan vaatimusten mukaan kokonaisuutena toteutettavaan järjestelmään.
Toteutusvaiheessa toteutettava prototyyppi määritellään kokonaisuuden osajoukkona siten, että prototyyppi ei tule tukemaan kaikkia toiminnallisia vaatimuksista. Osa vaatimuksista 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äytön suunnittelu oletetaan myös toteutettavassa osassa valmiiksi.
Jabber on viestintäarkkitehtuuri, joka on tarkoitettu Instant Message -tyyppiseen viestintään, joka toimii client-server arkkitehtuurin mukaisesti. Jabber on XML-pohjainen open source -viestintäprotokolla.
Järjestelmä suunnitellaan niin modulaarisesti, että reaaliaikainen viestintä voidaan hoitaa myös kolmannen osapuolen tarjoamalla komponentilla. Instant Message -viestintää tukevan ulkoisen arkkitehtuurin liittäminen järjestelmään toteutetaan suunnittelutasolla, joten suunnitteluvaiheen toteutukseen kuuluu mahdollisen Jabber-arkkitehtuurin liittämisen suunnittelu.
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.
Projektissa tullaan toteuttamaan asiakas rajapintaan 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 ja järjestelmään käyttäjälle toimitettujen viestien lukeminen.
Asiakasohjelmille näkyvän käyttöliittymän yhtenäisyyttä eri asiakasohjelmien välillä sekä käyttöliittymän käytettävyystestausta ei tulla toteuttamaan.
Prototyypin toiminnallisuuteen liittyy käyttäjälle lähetettyjen sähköpostiviestien selailu ja lukeminen, joten tiedontarjoajarajapintaan tullaan toteuttamaan IMAP-rajapinta postipalvelimien kanssa kommunikointiin.
Toteutettavan prototyypin toimintavarmuuden hyväksyttäväksi rajaksi asetetaan hallittu toiminnon lopettaminen virhetilanteissa. Tällainen toimintavarmuus taataan prototyypillä enintään 5 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 aiheuttaman moduulin on tuotettava lokitieto tilanteesta.
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-04
![\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)