Aihe hyväksytty osastoneuvoston kokouksessa Tarkastajat: Erikoistutkija Ossi Nykänen (TTY) Professori Seppo Pohjolainen (TTY)

Transkriptio

1 Tietotekniikan osasto ANTTI EVERI LOKITIETOANALYYSI VERKKOPALVELUN MALLINTAMISEN JA ANALYSOINNIN VÄLINEENÄ Diplomityö Aihe hyväksytty osastoneuvoston kokouksessa Tarkastajat: Erikoistutkija Ossi Nykänen (TTY) Professori Seppo Pohjolainen (TTY)

2 Alkulause Tämä työ on tehty Tampereen teknillisen yliopiston Hypermedialaboratoriossa osana laajempaa einsurance Uuden ajan sähköiset vakuutuspalvelut -tutkimushanketta. Kiitokset tasapuolisesti kaikille hankkeessa mukana olleille osapuolille. Haluan erityisesti kiittää työn ohjaajana ja tarkastajana toiminutta erikoistutkija Ossi Nykästä. Lisäksi haluan esittää kiitokseni työn toiselle tarkastajalle professori Seppo Pohjolaiselle. Lämmin kiitos myös koko Hypermedialaboratorion muulle henkilökunnalle motivoivasta ja monitieteisestä työilmapiiristä. Vanhempiani Ullaa ja Mattia sekä siskoani Annaa haluan kiittää koko opiskeluideni ajan jatkuneesta tuesta ja kannustuksesta. Tampereella Antti Everi Tumppi 3 E Tampere antti.everi@tut.fi i

3 Sisällysluettelo Alkulause Sisällysluettelo Tiivistelmä Abstract Lyhenteet i ii iv vi viii 1. Johdanto 1 2. Reaali- ja verkkopalvelun rakentaminen Mallit ja mallintaminen UML-standardin mukainen mallinnus UML-standardi yleisesti Luokkakaavio Aktiviteettikaavio Hypermediasovellusten mallinnus UML:n avulla pelkistetysti Hypermediasovellusten mallinnus UML:n avulla perusteellisemmin Motivaatio reaalipalvelun mallintamiseen UML-standardin välineillä Reaalipalvelun mallinnus UML-standardin välineillä UML-malleista semanttisen webin välineisiin Semanttinen web lyhyesti XML UML-standardista XML-skeemoihin Mallinnuskieliä erityisesti hypermediasovelluksille RMM WebML OOHDM Lokitietoanalyysi Lokitieto Web-tiedonlouhinta Web-tiedonlouhinta yleisesti Personointi Uudelleenjärjestely Liiketiedustelu Web-tiedonlouhintaprosessin vaiheet Datan keräys Datan esiprosessointi Käyttäjien tunnistus Istuntojen muodostus Episodien muodostus Hahmontunnistus Tietämyksen hyväksikäyttö Hahmontunnistusmenetelmiä 33 ii

4 3.4.1 Tilastollinen analyysi Luokittelu Klusterointi Segmentointi Assosiaatio Sekvensointi Liiketoiminnan yhteys verkkopalvelun käyttöön Yhteyden eri tasot Reaalipalvelun prosessien ja lokitietojen kytkös Käytännön välineitä Olemassa olevat välineet Oman tiedonlouhinta-alustan suunnittelu Case: einsurance einsurance-hanke lyhyesti Vakuutusaiheinen verkkopalvelu Vahinkoilmoituslomake Vakuutuspalvelun prosessien mallinnus Analysoitava data Lokitietojen analysointi päätöspuun avulla Perustelut menetelmän valintaan Tietojen muuttaminen Analysointi prosessi AnswerTree-ohjelmalla Tulokset ja johtopäätökset Lomakkeen muu analysointi Analyysi tuloksista ja johtopäätökset Yhteenveto 67 Lähdeluettelo 70 Liite 1 Liite 2 Liite 3 iii

5 Tiivistelmä TAMPEREEN TEKNILLINEN YLIOPISTO Tietotekniikan osasto Hypermedia EVERI, ANTTI: Lokitietoanalyysi verkkopalvelun mallintamisen ja analysoinnin välineenä Diplomityö, 76 sivua, 6 liitesivua Tarkastajat: Erikoistutkija Ossi Nykänen Professori Seppo Pohjolainen Rahoittaja: Tampereen teknillinen yliopisto, Hypermedialaboratorio, yhteisrahoitteinen Tekes-hanke einsurance Uuden ajan sähköiset vakuutuspalvelut Maaliskuu 2006 Avainsanat: lokitieto, lokitietoanalyysi, mallintaminen, vakuutuspalvelu, verkkopalvelu, web-tiedonlouhinta Toimiva verkkopalvelu edellyttää, että se jäsentyy kiinteäksi osaksi yrityksen koko palvelukonseptia. Jäsentymistä voidaan tutkia vertaamalla yrityksen käsitemallia ja liiketoimintaprosesseja verkkopalvelun rakenteeseen ja käytöstä aiheutuviin lokitietoihin. Yrityksen käsitemalli ja verkkopalvelun rakenne ovat mallinnettavissa UML-luokkakaavion avulla ja vastaavasti liiketoimintaprosessit ja verkkopalvelun käyttäjien navigointipolut UML-aktiviteettikaavion avulla. Verkkopalvelujen käytöstä kirjautuu valtava määrä tietoa verkkopalvelimien lokitietoihin. Tiedonlouhinta on hahmojen etsimistä yleensä suurista tietovarastoista ja Web-tiedonlouhinta vastaavaa etsimistä www-maailmassa. Verkkopalvelimien lokitiedoista on louhittavissa käyttötietoa, jota voidaan käyttää verkkopalvelun personointiin ja uudelleenjärjestelyyn tai tukena yrityksen liiketiedustelussa. Webtiedonlouhintaprosessi alkaa datan keräyksellä ja esikäsittelyllä. Seuraavaksi datasta tunnistetaan käyttäjät, istunnot ja episodit, jonka jälkeen alkaa varsinainen hahmojen tunnistus ja sitä seuraava tietämyksen hyväksikäyttö. Ottamalla huomioon web-tiedonlouhinnassa yrityksen reaali- ja verkkopalveluiden erilaiset mallit, saadaan tutkittua verkkopalvelun käytön suhdetta reaalipalveluun. Tutkimista voidaan helpottaa jakamalla reaali- ja verkkopalvelun rakenteet käsite- tai palvelupohjaiseen hierarkiaan. Käsitepohjaisessa hierarkiassa palveluiden eri käsitteet on jaettu yleisemmiksi luokiksi niiden merkityksen perusteella. Palvelupohjaisessa iv

6 hierarkiassa palveluiden eri osat on jaettu niiden toiminnallisuuksien mukaan. Webtiedonlouhinnalla saatuja tuloksia voidaan manuaalisesti käyttää hyväksi päätöksenteon tukena tai käytön seurannassa. On olemassa myös järjestelmiä, jotka esimerkiksi personoivat verkkopalvelua automaattisesti palvelun käytön perusteella. Web-tiedonlouhintaa kokeiltiin käytännössä vakuutusaiheisessa case-tutkimuksessa. Tutkimuskohteena oli Pohjola-Yhtymän ajoneuvovahinkoihin liittyvä ilmoituslomake. Raporttina tämä diplomityö ei sisällä luottamukselliseksi katsottavaa aineistoa. Erityisesti, Pohjola-Yhtymän vahinkoilmoituslomaketta käsittelevä osio rajoittuu lähinnä tilastollisten tunnuslukujen ja loppukäyttäjälle julkisessa verkossa näkyvän käyttöliittymän osalle. Vahinkoilmoituslomaketta tutkittaessa pyrittiin segmentoinnin avulla saamaan selville asioita, jotka vaikuttavat lomakkeen täytön ja lähetyksen onnistumiseen. Segmentointimenetelmäksi valittiin päätöspuut, mutta mielenkiintoisten ominaisuuksien puutteesta johtuen segmentoinnin tulokset jäivät osin laihoiksi. Parempia tuloksia saatiin tutkimalla vahinkoilmoituslomaketta tilastollisesti ja käytettävyyden näkökulmasta. Merkittävä syy lomakkeen täytön epäonnistumiseen saattavat olla lomaketta käsittelevän palvelimen ongelmat vastata lähetysyrityksiin. Käytettävyydeltään lomaketta ei arvioitu parhaaksi mahdolliseksi, vaan todettiin, että lomakkeentäyttöprosessi tulisi muuttaa enemmän sovellusmaiseksi. Vaikka webtiedonlouhinta ei case-tutkimuksessa tuottanutkaan kovin mielenkiintoisia tuloksia, on se tehokas menetelmä, kun sovellusalueen käsitteistö on rikkaampaa ja testidataa on saatavilla enemmän tai koko sovellusalue on laajempi. v

7 Abstract TAMPERE UNIVERSITY OF TECHNOLOGY Department of Information Technology Hypermedia EVERI, ANTTI: Log analysis as a tool for modeling and analysis of web service Master of Science Thesis, 76 pages, 6 appendix pages Examiners: Senior Researcher Ossi Nykänen Professor Seppo Pohjolainen Funding: Tampere University of Technology, Hypermedia Laboratory, Tekes funded shared-cost action project einsurance Novel Electronic Insurance Services March 2006 Keywords: insurance service, log analysis, log data, modeling, web mining, web service Prerequisite for a good web service is that it is build as a part of corporation s service concept. This can be researched by comparing corporation s entity model and business processes to its web service structure model and navigation paths. Corporation s entity model and web service structure model can be modeled with UML class diagram. Business processes and navigation paths can be modeled with UML activity diagram. A huge amount of usage data is saved every day to web servers. Data mining is searching large amounts of data for patterns. Web mining is data mining in the World Wide Web. Web usage data can be mined from web server s logs and it can be used to personalize and modify sites or to obtain business intelligence information. Web mining project starts with collecting and preprocessing data, followed by user, session and episode identifications. After the data is identified, final process phases are pattern recognition and analysis. When observing corporation s different real and web service structures in web mining, it is possible to research how the usage of web service is connected to the real service. Dividing real and web service structures into concept or service-based hierarchy, this research can be made easier. In concept-based hierarchy different concepts have been divided into more general classes by their meaning. In servicebased hierarchy different concepts have been divided by their action types. Results from web-usage mining can be used manually as a support when for example making vi

8 decisions or monitoring usage. There are also systems that can personalize web service automatically by the usage of the web service. Web mining was tested in practice in insurance related case study. Target of the research was the specific damage report form used by the Pohjola insurance group. This Master of Science thesis doesn't contain any confidential information as a report. Particularly chapter that reports on Pohjola insurance groups damage report form is restricted to statistical key figures and information that is shown to the end-user via the public network. Segmenting was used in this research to reveal the facts affecting the success of filling out and sending the form. Decision trees were selected as a tool for segmenting, but because the lack of interesting form properties, results were not satisfactory. Better results were obtained when the form was researched statistically and from the usability viewpoint. Remarkable reason for a web service operation failure of the research target can be the web server s problems to respond to the user, when the user is trying to send the form. Usability of the form was not good and as a conclusion it was discovered that the form should be changed to operate more like an application. Even though web mining did not bring very good results in this case study, it still is very effective method, when research objects entity model is richer and there is more test data available or when the whole research object is larger as a whole. vii

9 Lyhenteet CLF Common Log Format CoLF Combined Log Format DTD Document Type Definition ER Entity-Relationship HDM A Model for the Design of Hypertext applications HTML Hypertext Markup Language IIS Internet Information Services IP Internet Protocol MOF Meta Object Facility OMG Object Management Group OOHDM Object-Oriented Hypermedia Design Model OWL Web Ontology Language PACT Profile Aggregations based on Clustering Transactions RDF Resource Description Framework RMM Relationship Management Methodology SPARQL SPARQL Protocol And Query Language UML Unified Modeling Language URI Uniform Resource Identifier URL Uniform Resource Locator W3C World Wide Web Consortium WebML Web Modeling Language WUM Web Utilization Miner WWW World Wide Web XMI XML Metadata Interchange XML Extensible Markup Language XSL Extensible Stylesheet Language viii

10 1. Johdanto Sähköinen liiketoiminta on arkipäivää jo kaikilla yrityselämän sektoreilla. Yritykset sekä tarjoavat tietoa omista tuotteistaan ja palveluistaan että myyvät niitä verkon välityksellä. Monet perinteisten toimialojen yritykset ovat pyrkineet siirtämään liiketoimintaansa verkkoon vaihtelevalla menestyksellä. Toimiva verkkopalvelu kuitenkin edellyttää, että se jäsentyy kiinteäksi osaksi yrityksen koko palvelukonseptia. Verkkopalvelun jäsentymistä on mahdollista seurata tutkimalla sen rakennetta ja käyttöä. Käytön liittäminen suoraan liiketoimintaprosesseihin on kuitenkin hankalaa. Yhteys on rakennettavissa mallintamalla palvelun eritasoiset osa-alueet. Ylemmällä tasolla on yrityksen sovellusalueen käsitemalli ja siihen liittyvät liiketoimintaprosessit. Alemman tason muodostavat yrityksen verkkopalvelu ja verkkopalvelun käytöstä kertovat lokitiedot. Sovellusalueen mallintamiseksi on olemassa erilaisia tekniikoita. UML (Unified Modeling Language) on perinteisesti ohjelmistotuotannossa käytetty mallinnuskieli, jota nykyisin käytetään yhä enemmän myös liiketoiminnan ja tietovarastojen mallinnuksessa. Mallinnettaessa sekä yrityksen palvelualueen käsitteistö liiketoimintaprosesseineen että verkkopalvelun rakenne ja lokitiedot samoilla välineillä voidaan helposti vertailla yhtäläisyyksiä sekä suhteuttaa eri osia ja tapahtumia toisiinsa. 1

11 Verkkopalvelun käytöstä muodostuu verkkopalvelimelle lokitietoja. Lokitiedot ovat palvelimen ylläpitäjille tarkoitettuja tietoja, jotka kirjaavat tarkasti asiakkaiden palvelimelta pyytämät tehtävät ja kuinka palvelin on kyseisistä tehtävistä suoriutunut. Näitä tietoja voidaan analysoida suoraviivaisesti laskemalla lokien yleisiä tilastotietoja, mutta niiden syvempi analysointi onnistuu vain tiedonlouhinnan välineillä. Web-tiedonlouhinta on tiedonlouhintaa webissä. Sitä voidaan kohdistaa verkkopalvelun sisältö-, rakenne- ja käyttötietoihin. Käyttötiedonlouhinnassa sovelletaan palvelimien lokitietoihin tyypillisiä tiedonlouhinnan menetelmiä. Web-tiedonlouhinnan avulla yrityksen on mahdollista saada arvokasta tietoa oman verkkopalvelunsa käytöstä. Tietojen avulla yritys voi muokata palveluaan entistä paremmaksi, jolloin siitä hyötyvät sekä asiakkaat että myös yritys itse. Tämän diplomityön tarkoituksena on tutkia, miten lokitietoja voidaan analysoida tiedonlouhinnan menetelmin. Tiedonlouhintaa ohjaavat reaalipalvelun käsitemalli ja liiketoimintaprosessit. Näin saavutetulla yhteydellä voidaan tutkia verkkopalvelun suhdetta reaalipalveluun ja verkkopalvelun käytön suhdetta tavoiteltuihin liiketoimintaprosesseihin. Seuraavaksi luvussa kaksi käsitellään reaali- ja verkkopalvelun mallinnusta. Siinä esitellään tämän työn kannalta keskeisimmät UML-kaaviotyypit ja kerrotaan, miten niillä voidaan mallintaa reaali- ja verkkopalvelua. Lisäksi luvussa esitellään myös muita verkkopalvelun mallintamiseen soveltuvia kieliä, joista useimmilla onkin selkeitä yhtäläisyyksiä UML:n kanssa. Kolmannessa luvussa kerrotaan perustiedot lokitiedoista ja perehdytään laajemmin webtiedonlouhintaan. Luvussa esitellään web-tiedonlouhinnalla tavoiteltavia hyötyjä, tyypillisen louhintaprosessin eri vaiheita ja niihin liittyviä toimenpiteitä sekä muutamia keskeisimpiä tiedonlouhintamenetelmiä. Neljäs luku yhdistää toisen ja kolmannen luvun tietoja. Siinä esitellään tarkemmin, miten reaalipalvelu on kytkettävissä verkkopalveluun ja edelleen, miten liiketoimintaprosessit ovat kytkettävissä lokitietoihin. Luvussa käsitellään myös käytännön välineitä analysoinnin tueksi. 2

12 Viides luku esittää vakuutusaiheisen case-tutkimuksen. Luku sisältää taustatietoa tutkimuksen ympärillä olevasta einsurance-hankkeesta ja tarkasteltavasta vahinkoilmoituslomakkeesta. Näiden tietojen pohjalta tutkitaan lomakkeen käytön onnistumiseen ja epäonnistumiseen liittyviä tekijöitä. Tutkimuksessa käytetään hyväksi mallinnuksen, tiedonlouhinnan ja käytettävyyden osa-alueita. Tulosten pohjalta annetaan jatkokehitysideoita käytön onnistumisen parantamiseksi. Viimeisenä oleva kuudes luku on varattu yhteenvedolle työn eri aihealueista. Siinä esitetään tutkimuksesta saatuja keskeisiä tuloksia ja samalla myös arvioidaan jatkokehitysmahdollisuuksia. 3

13 2. Reaali- ja verkkopalvelun mallintaminen 2.1 Mallit ja mallintaminen Mallit auttavat käyttäjää ymmärtämään monimutkaisiakin tosielämän ongelmia ja ilmiöitä. Ne tarjoavat yksinkertaistetun ja jäsennellyn kuvan kohteestaan, jotta käyttäjä voisi paremmin hahmottaa kokonaisuuden [1]. Mallintamisessa ei tavoitella sitä, että maailma olisi kyseisen mallin mukainen. Sen sijaan maailmaa vain kuvataan yksinkertaistetusti kyseisen mallin avulla analysoinnin helpottamiseksi. Takaisinmallinnuksen kohteena on valmis tuote. Tuotteen komponentit, niiden suhteet ja tuotteen toiminnallisuus pyritään analysoimaan ja johtamaan siitä ylemmän abstraktiotason malli. [2] Malleja käytetään suunnittelu- ja toteutusprosessin eri vaiheissa ja ne toimivat myös projektinhallinnan apuvälineinä [1]. Hyvän mallin ominaisuuksia ovat täydellisyys, tarkkuus, virheettömyys, ymmärrettävyys, testattavuus ja jäljitettävyys [3]. Harvoin kaikki mainitut ominaisuudet yhdistyvät täydellisesti hyvässäkään mallissa, mutta niitä voidaan pitää lähtökohtana mallia työstettäessä. Malli voidaan rakentaa 4

14 kuvaustekniikoiden eli notaatioiden avulla. Notaatiot ovat kieliä erilaisten asioiden ilmaisemiseksi. [3] 2.2 UML-standardin mukainen mallinnus UML-standardi yleisesti Tämä alakohta perustuu UML Superstructure 2.0 spesifikaatioon [4]. UML on OMG (Object Management Group) ryhmittymän vuonna 1997 hyväksymä notaatiostandardi. Sitä käytetään pääasiassa ohjelmistojen suunnittelussa, mutta nykyisin myös yhä enemmän liiketoiminnan ja tietovarastojen mallinnuksessa. UML koostuu joukosta erilaisia notaatioita. UML-standardin uusin versio 2.0 määrittelee 13 erilaista kaaviotyyppiä, jotka on jaettu kolmeen eri kategoriaan: rakenne-, käyttäytymis- ja keskustelukaaviot. Rakennekaavioihin kuuluvat luokka-, olio-, komponentti-, kooste-, paketti- ja sijoittelukaaviot. Käyttäytymiskaavioihin lukeutuvat käyttötapaus-, aktiviteetti- ja tilakaaviot. Keskustelukaavioita ovat sekvenssi-, kommunikaatio-, ajoitus- ja vuorovaikutuskaaviot. Laajennusmekanismien avulla UML:n perusosille voidaan määritellä lisäominaisuuksia. Seuraavissa alakohdissa tarkastellaan lähemmin tässä työssä tarpeellisia kaaviotyyppejä, luokkakaaviota ja aktiviteettikaaviota sekä tutustutaan hypermediasovellusten mallintamiseen UML:n avulla Luokkakaavio Tämä alakohta perustuu Haikalan ja Märijärven Ohjelmistotuotanto-kirjaan [3] ja UML Superstructure 2.0 spesifikaatioon [4]. Luokkakaaviolla esitetään luokkia, niiden välisiä yhteyksiä ja yhteyksiin liittyviä lukumääräsuhteita. Luokkakaavioita käytetään yleisesti hyväksi oliokeskeisien menetelmien suunnittelu- ja määrittelytehtävissä. Se kuvaa sovellusalueen käsitteet ja sillä voidaan määritellä tai rajata järjestelmän 5

15 tietosisältöä. Myös tietokantasuunnittelussa käytetään yleisesti luokkakaaviota, sillä luokkakaavion vastaavuus relaatiotietokantaan on selkeä. Luokat kuvaavat järjestelmän keskeisiä käsitteitä. Oliokeskeisissä menetelmissä luokkaan liitetään usein myös luokan attribuutit ja operaatiot. Kunkin luokan ilmentymä on olio. Luokkakaavioon luokka piirretään suorakulmiona, joka on jaettu kolmeen osaan. Ylimmäisessä osassa on luokan nimi, keskellä luokan attribuutit ja alimpana luokan operaatiot. Luokkien välillä on yhteyksiä eli assosiaatioita. Ne ovat oletusarvoisesti kaksisuuntaisia, mutta yksisuuntaisiakin yhteyksiä voi määritellä. Myös yhteyksiin voidaan liittää attribuutteja assosiaatioluokan avulla. Yhteyksiin voidaan liittää myös rajoitteita. Yhteydet luokkien väliin piirretään luokkakaavioon viivalla ja yhteyden nimi tulee kyseisen viivan päälle. Yhteyksien rajoitteet merkitään katkoviivalla yhteyksien välille. Yhteyksiin liittyvät lukumääräsuhteet kertovat montako oliota vähintään ja enintään voi liittyä tiettyyn olioon yhteyden toisessa päässä. Lukumääräsuhteet ovat muotoa N..M. Merkillä * voidaan kuvata monta, eli merkintä 1..* tarkoittaa yksi tai enemmän. Lukumääräsuhteet merkitään luokkakaavioon luokkien yhteyksien päihin. Luokkakaaviossa voi olla myös tavallisesta poikkeavia yhteyksiä luokkien välillä. Yleistäminen ja periytyminen ovat tapoja, joissa yksi luokka voi olla abstrakti yliluokka ja siitä voidaan periyttää alaluokkia. Alaluokat perivät yliluokan attribuutit ja operaatiot. Periytyminen kuvataan piirtämällä yhteyden yliluokan päähän nuoli. Jos alaluokkia on useita, voidaan nuolet yhdistää. Koostumisella ilmaistaan olion olevan toisen olion komponentti. Mikäli olio on kiinteästi riippuvainen toisesta oliosta, voidaan puhua muodosteesta. Koostuminen merkitään luokkakaavioon yhteyden päähän piirrettävällä vinoneliöllä. Muodosteen merkki on sama, paitsi nyt kyseinen neliö on väritetty mustakasi. Luokkakaavion komponenteille voidaan antaa lisäksi lisämääreitä stereotyyppien avulla. Ne merkitään kaksoisväkästen väliin ja esimerkiksi luokan tapauksessa luokan 6

16 nimen yläpuolelle. UML-standardi määrittelee joukon valmiita stereotyyppejä, mutta niitä saa keksiä myös vapaasti lisää. Kuva 2.1. Esimerkki asiakkaan ja vakuutuksen suhteesta. Yksinkertaistetussa esimerkissä luokkakaaviosta voitaisiin tarkastella vakuutuksen ja asiakkaan suhdetta (kuva 2.1). Asiakas ja vakuutus ovat luokkia ja niiden välillä on yhteys turvaa. Yhteyden lukumääräsuhteet ovat merkitty molempiin päihin tähdellä. Vakuutus voi siis liittyä moneen tai ei yhteenkään asiakkaaseen ja myös asiakkaalla voi olla monta tai ei yhtään vakuutusta. Vakuutuksella on tyyppi-attribuutti ja Asiakkaalla on nimi-attribuutti Aktiviteettikaavio Tämä alakohta perustuu UML Superstructure 2.0 spesifikaatioon [4]. Aktiviteettikaaviolla voidaan kuvata erilaisia algoritmeja ja prosesseja. Kaaviotyyppiä käytetään ohjelmistotuotannon lisäksi myös yleisissä liiketoimintaprosessien kuvauksissa. Aktiviteettikaaviolla kuvattavassa tapahtumassa voi yhtä aikaa toimia useita eri luokkia, jolloin jokaisella luokalla on oma ns. uimarata. Algoritmin alkua kuvataan täysin mustalla ympyrällä. Loppua kuvaa samanlainen ympyrä, jonka ympärille on vielä piirretty ohut rengas. Aktiviteetit on piirretty suorakulmioilla, joiden reunat on pyöristetty. Algoritmissa on usein mukana ehtoja, jotka kuvataan salmiakin muotoisilla merkeillä. Nuolet siirtävät toiminnan seuraavan aktiviteettiin tai ehtoon. Ehtojen valinnat ovat kuvattuna niitä seuraavien nuolien päälle hakasulkeiden sisään. Kahden aktiviteetin välillä voi lisäksi kulkea tietoa. Tietoa kuvataan suorakulmiolla ja sen kulkua katkoviivoitetuilla nuolilla. 7

17 Kuva 2.2. Esimerkki vakuutustiedon etsintä ja hyväksikäyttö -algoritmista. Esimerkkinä aktiviteettikaaviosta voidaan tarkastella yksinkertaista algoritmia, jonka tarkoituksena on ensin etsiä vakuutustietoa ja sen jälkeen tutustua siihen (kuva 2.2). Alkupisteen jälkeen vakuutustiedon etsiminen alkaa. Jos tietoa löytyi, tutustutaan siihen, jonka jälkeen algoritmi loppuu. Ellei tietoa taas löydy palataan uudelleen etsimään sitä Hypermediasovellusten mallinnus UML:n avulla pelkistetysti UML-standardi soveltuu hyvin hypermediasovellusten mallintamiseen. Standardia käyttävien menetelmien avulla voidaan suunnitella vaativiakin järjestelmiä. Luokkakaaviota voidaan soveltaa verkkopalvelun rakenteen mallintamiseen [5]. Tällöin kaavion luokka vastaa sivua/näkymää, luokan attribuutit vastaavat tietoja (yleisesti), luokan operaatiot vastaavat toiminnallisuuksia ja luokkien väliset yhteydet linkkejä. Myös laajempi verkkopalvelu voidaan mallintaa luokkakaavion avulla sopivasti yleistettynä. Kuva 2.3. UML-luokkakaavio sivustosta. Kuvassa 2.3 on mallinnettu yksinkertaiset verkkosivut UML-luokkakaavion avulla. Luokkina toimivat sivut ja niiden attribuutteina sivujen osat. Kotisivulta on yhteys linkit- ja vieraskirja-sivuille, jolloin kotisivulta voi käytännössä myös navigoida näille sivuille. Vieraskirja-sivulla on myös lisää viesti() toiminnallisuus, jolla voidaan lisätä uusi viesti vieraskirjaan. 8

18 Verkkopalvelun prosesseja voidaan kuvata aktiviteettikaavion avulla. Aktiviteetit vastaavat käyttäjän toimia verkkopalvelun sisällä ja ehdot luonnollisesti käyttäjän mahdollisia valintoja tai toteamuksia. Kuva 2.4. UML-aktiviteettikaavio verkkopalvelun prosessista yksinkertaistettuna. Kuvan 2.4 prosessissa verkkopalvelun käyttäjä selailee ensin sopivia tuotteita verkkopalvelun tuotetietoja. Toiminta jakaantuu siitä riippuen, löytyykö sopiva tuote vai ei. Mikäli sopiva tuote löytyy, lisätään tuote ostokoriin ja lisäostosten tarpeesta riippuen jatketaan ostoksia tai poistutaan kassan kautta. Mikäli sopivaa tuotetta ei toiminnan jakaantuessa löytynyt, toiminta jakaantuu uudelleen. Jos ostoskorissa oli tuotteita, maksetaan ne ja poistutaan, mutta jos korissa ei ollut tuotteita, poistutaan saman tien Hypermediasovellusten mallinnus UML:n avulla perusteellisemmin UML-standardin päälle on kehitetty myös monimutkaisempia ja erityisesti hypermediasovellusten (rakenteen) suunnitteluun tarkoitettuja suunnittelumenetelmiä [6] [7], joihin tämä alakohta perustuu. Niissä suunnitteluprosessi on jaettu neljään eri vaiheeseen: 1. Käsitteellinen mallinnus, 2. ja 3. Navigoinnin mallinnus ja 4. Ulkoasun mallinnus. Käsitteellisessä mallintamisessa mallinnetaan sovellusalueen käsitteet luokkakaavioksi. Käsitteitä mallinnettaessa käytetään aktiivisesti yleistämistä, periyttämistä, koostamista ja muodostamista. Käsitteiden lisäksi määritellään luokkien attribuutit, operaatiot ja suhteet toisiin luokkiin lukumäärineen. Vaikka suhteet tulevatkin määriteltyä, ei ensimmäisessä vaiheessa edes yritetä ottaa huomioon navigointiratkaisuja. 9

19 Navigoinnin mallinnus on jakaantunut kahteen osaan. Ensimmäisessä osassa (2. vaihe) määritellään, mitkä objektit ovat yhteydessä toisiinsa. Toisen vaiheen lähtökohtana on ensimmäisen vaiheen käsitemalli. Kaikki luokat ja yhteydet, jotka eivät ole välttämättömiä navigoinnin kannalta jätetään huomioimatta tai muutetaan toisten luokkien attribuuteiksi. Yleisesti pyritään välttämään yli yhden pituisia polkuja pääsivujen välillä, joten tämän seurauksena kaavioon myös lisätään yhteyksiä luokkien välille. Vaiheen tuloksena on luokkakaavio (kuva 2.5), johon perustuu myös navigoinnin mallinnuksen toinen vaihe. Kuva 2.5. Navigointimalli (1.vaihe) yrityksen verkkopalvelusta [6]. Navigoinnin mallinnuksen toisessa vaiheessa (3. vaihe) määritellään, miten objektit ovat yhteydessä toisiinsa. Vaihe on kaksijakoinen. Ensin laajennetaan edellisen vaiheen luokkakaaviota navigoinnin osalta tarpeen mukaan erilaisin elementein (hakemistot, opastetut kierrokset, kyselyt), jonka jälkeen johdetaan valikkoina toimivat elementit. Vaiheen lopputuloksena on luokkakaavio tyyppinen esitys verkkopalvelun rakenteesta ja navigointimahdollisuuksista Neljäntenä ja viimeisenä vaiheena on ulkoasun mallinnus. Nimestään huolimatta vaihe ei ota kantaa fyysiseen ulkoasuun (värit ym.), vaan ennemminkin eri elementtien sijoitteluun. Ulkoasun malli koostuu staattisesta ja dynaamisesta mallista. Staattinen malli kuvaa siis luokkakaavion avulla staattisen ulkoasun. Dynaaminen malli taas kertoo, miten eri elementit vastaavat käyttäjän toimintaan ja se on kuvattavissa tilakaavion avulla. 10

20 Suunnittelumenetelmät perustuvat kokonaan UML-standardin mukaisen luokkakaavion (ja tilakaavion). Suunnittelun vaiheiden eri osissa kaavioita laajennetaan moninkin eri stereotyypein, mutta yhtä kaikki, kokonaisuus pysyy standardin mukaisena. Tästä seuraa välittömänä hyötynä se, että voidaan käyttää olemassa olevia UML-standardin mukaisia mallinnusohjelmistoja Motivaatio reaalipalvelun mallintamiseen UML-standardin välineillä Reaalipalvelua ei ole tyypillisesti mallinnettu UML-standardiin nojautuen, eikä UMLstandardia myöskään ole alun perin tähän tarkoitukseen suunniteltu. UML on kuitenkin joustava standardi, joka taipuu monenlaisiin käyttötarkoituksiin. Lisäksi sen käyttöön on olemassa mm. taloudellisia ja käytännöllisiä perusteluja. Monilla tietotekniikka-alaa ainakin sivuavilla yrityksillä on jo valmiiksi hallussaan UML-standardin mukaisia mallinnusohjelmistoja. Usein samoilla yrityksillä on myös henkilökuntaa, joka osaa käyttää kyseisiä ohjelmistoja. Tällöin voidaan saavuttaa useiden tuhansien eurojen säästöjä, koska uusia ohjelmistoja ei tarvitse ostaa ja henkilökunnan koulutuksen tarvekin on vähäisempää. Käytännöllinen hyöty mallinnettaessa reaalipalvelu UML-standardin mukaisesti on mallin vastaavuus esimerkiksi ohjelmistotuotannon vastaaviin malleihin. Näin voidaan vertailla mallien vastaavuutta ja tarvittaessa tehdä muutoksia malleihin. Mikäli esimerkiksi verkkokaupan suunnitellun ostoprosessin kuvaavassa aktiviteettikaaviossa havaitaan oleellinen ristiriita reaalipalvelun vastaavaan ostoprosessiin, voidaan suunnittelua tarpeen vaatiessa muuttaa. Tästä vastaavuudesta puhutaan lisää tämän työn luvussa neljä Reaalipalvelun mallinnus UML-standardin välineillä Reaalipalvelu voidaan yksinkertaistaa koostuvaksi palvelualueen käsitteistä, niiden suhteista ja prosesseista. Tässä alikohdassa kerrotaan miten reaalipalvelu on mallinnettavissa luokka- ja aktiviteettikaavioiden avulla. 11

21 Palvelualueen käsitteen voidaan suoraan mallintaa luokkakaavion luokkina, jolloin luonnollisesti niiden väliset suhteet mallinnetaan luokkien välisinä yhteyksinä. Mikäli palveluun liittyy attribuutteja tai toimintoja, mallinnetaan ne suoraa luokkien attribuutteina ja toimintoina. Stereotyyppien käytöllä tässä yhteydessä on hyvä tarkentaa eri komponenttien ominaisuuksia. Kokonaisuutena käsitteiden mallinnus vastaa pitkälti tavallista luokkakaavion suunnitteluprosessia. Reaalipalveluiden tapauksessa luokkakaavioista tulee helposti huomattavan laajoja, jolloin on järkevää pohtia mallin yksinkertaistamista/rajoittamista käyttötarkoituksen perusteella. Esimerkiksi ei ole tarkoituksenmukaista mallintaa koko tavaratalon käsitteistöä, jos halutaan tutkia kassahenkilön toimenkuvaa. Reaalipalveluun liittyvien prosessien mallinnukseen luonteva kaaviotyyppi on aktiviteettikaavio [8]. Se on suunniteltu juuri algoritmien ja prosessien kuvaukseen, jolloin prosessien suunnittelu ainakin yksinkertaistetusti on jopa triviaali toimenpide mallinnuksen teknisen puolen näkökulmasta. 2.3 UML-malleista semanttisen webin välineisiin Semanttinen web lyhyesti Semanttinen Web on järjestelmä, jonka päämääränä on esittää dataa tietokoneohjelmien ymmärtämässä muodossa. Se ei ole nykyisen webin ulkopuolinen verkko, vaan ennemminkin laajennus, jossa data olisi kaikkien eri osapuolten ymmärtämässä muodossa.. Toteutuessaan Semanttinen Web voisi olla siis maailmanlaajuinen tietokanta, josta tietoa voitaisiin hakea monimutkaisillakin tavoilla. [9] Semanttisen webin kannalta kaksi tärkeää teknologiaa on jo standardisoitu: XML (Extensible Markup Language) [10] ja RDF (Resource Description Framework) [11]. XML-merkkauskielestä puhutaan enemmän seuraavassa aliluvussa RDF antaa tiedolle merkityksen eli sillä kuvataan metatietoa. Kuvaus tapahtuu kolmikkojen subjekti, predikaatti ja objekti avulla [11]. RDF-kuvailutietoa voidaan julkaista XML- 12

22 merkkauksen yhteydessä. RDF ei ole ainoa, eikä vahvin kuvailukieli Semanttisen Webin metatiedolle, mutta se on yleisimmin käytetty ja de facto standardi. RDF-kuvailutietoon voidaan tehdä hakuja kyselykielten avulla. Yhtään kyselykieltä ei ole vielä virallisesti standardoitu, mutta lähimpänä standardointia on SPARQL (SPARQL Protocol And Query Language, tätä dokumenttia kirjoittaessa SPARQL on jo ns. last call vaiheessa) [12]. SPARQL on melko yksinkertainen kyselykieli, joka nojautuu vahvasti RDF-graafin rakenteeseen. SPARQL-kyselyt eivät oletuksena tulkitse semanttista päättelyä, mutta kyselymekanismi sallii kuitenkin laajennukset. Ontologiat ovat teknisesti formaaleja, koneen tulkittavissa olevia kuvauksia niistä käsitteistä ja näiden välisistä suhteista, joita älykkäällä toimijalla ja toimijajoukolla on käytettävissään [13]. Semanttisen Webin ontologiat ovat sanastoja, joiden avulla tietoverkkojen sisällöt (metatiedot) voidaan ilmaista koneen ymmärtämällä tavalla. Koneymmärrettävät sisällöt mahdollistavat yhteentoimivuuden lisäksi entistä älykkäämpien järjestelmien kehittämisen [14]. Ontologiat ovat Semanttisen Webin kolmas keskeinen teknologia XML:n ja RDF:n lisäksi. Ontologioiden kieleksi on määritelty OWL (Web Ontology Language ja se on jo W3C:n (World Wide Web Consortium) standardoima [15]. OWL käyttää hyväkseen RDF:ää ja RDF-skeemaa (RDF Schema), lisäten niiden päälle vielä lisää mahdollisuuksia sanastojen määrittelyyn XML XML on yksinkertainen ja joustava kieli sähköiseen tiedonjulkaisuun ja -vaihtoon [10]. XML-kieli on tarkoitettu koneiden tuottamaksi ja luettavaksi, mutta sen suunnittelussa on otettu huomioon myös kielen luettavuus ihmisten näkökulmasta. Kieltä käytetään pääasiassa tekstimuotoisen tiedon esittämiseen, mutta sillä voidaan kuvata myös grafiikkaa ja sitä voidaan käyttää ohjelmistojen sisäisessä tiedonsiirrossa. XML-perhe ei ole yksi standardi, vaan laajempi joukko tekniikoita. Kaiken perusta on kuitenkin XML 1.0 merkkauskieli, johon edellisen kappaleen lauseetkin viittaavat. XML 1.0 määrittää miten rakenteisia dokumentteja tulisi merkata ja kuinka dokumentin 13

23 looginen rakenne voidaan osoittaa. Muita tärkeitä suosituksia ovat XML-nimiavaruudet, XSL (Extensible Stylesheet Language) muunnos, XML dokumenttien tyyppimääritykset ja XML-skeemat. Merkittäviä suosituksia olisi toki enemmänkin, mutta tämän työn kannalta ei ole järkevää esitellä niitä kaikkia. [16] Kuva 2.6. Esimerkki XML-dokumentista. Kuvassa 2.6 on esimerkki XML 1.0 standardin mukaisesta dokumentista. Dokumentti koostuu merkkauksesta ja merkkidatasta. Dokumentin elementit ja attribuutit ovat merkkausta ja niiden arvot vastaavasti merkkidataa. Elementit koostuvat standardin mukaan aina alku- ja lopputagista, poikkeuksena tyhjät elementit, joilla on vain alkutagi. Attribuutit liitetään elementin alkutagiin ja niillä on aina nimi ja arvo. XML-nimiavaruudet yksilöivät sanastoja URI (Uniform Resource Identifier) tunnisteiden avulla [17]. Sanastoilla tarkoitetaan XML-dokumenttien elementtejä ja attribuutteja. XML-nimiavaruuksien avulla dokumentti voi sisältää useita eri sanastoja ilman, että ne sekoittuvat toisiinsa. Elementeillä on aina oletusnimiavaruudet, joihin ne jälkeläisineen kuuluvat [17]. Elementin nimiavaruus on kuitenkin mahdollista muuttaa toiseksi etuliitteen avulla. XSL-muunnoksen avulla voidaan muuntaa XML-dokumentteja toisiksi XML- tai muiksi dokumenteiksi [18]. Muunnos määrittelee säännöt, joilla lähdedokumentin jäsennystä vastaava lähdepuu on kuvattavissa tulospuuksi. Muunnoksessa verrataan määriteltyjä hahmoja lähdepuuhun ja muodostetaan mallipohjien avulla tulospuu. XSLmuunnos on fyysisesti XML-merkkausta, mutta ulkonäöstään huolimatta se voidaan laskea ohjelmointikieleksi. XML-skeema (XML Schema) on W3C:n suositus XML 1.0 dokumenttien tyypin määrittelyyn [19]. Dokumentin tyypillä tarkoitetaan mallia dokumentin elementti- ja attribuuttirakenteelle [20]. Dokumentin tyypin täsmällinen määrittely on ensiarvoisen tärkeää, sillä ilman sitä XML-dokumentit ovat tietokoneille vain merkkidataa, vailla loogista merkitystä. XML-skeema ei kuitenkaan ole ainoa käytössä oleva 14

24 tyyppimäärityskieli, vaan mm. yksinkertaisempi XML DTD (Document Type Declaration) [10] on myös hyvin yleisesti käytössä. XML-skeeman edut XML DTD:hen nähden ovat datatyyppien monipuolisempi ja perusteellisempi määrittely sekä nimiavaruuksien huomattavasti parempi huomiointi. Kuva 2.7. Esimerkki XML-skeema-tyyppimäärityskielestä. Kuvassa 2.7 on esimerkki skeemasta, jolla voitaisiin määritellä kuvan 2.5 XMLdokumentin tyyppi. Ensin määritellään elementti työntekijä, joka on tyypiltään kompleksinen. Kompleksinen tyyppi voi sisältää muita elementtejä ja/tai sillä voi olla attribuutteja. Kompleksisen elementin sisällä on ensin sekvenssi, jonka sisällä edelleen on ainoana elementtinä merkkimuotoinen nimi. Sekvenssin lisäksi kompleksisen elementin sisällä on sen attribuutti id, joka on tyypiltään merkkimuotoinen UML-standardista XML-skeemoihin UML-standardin mukainen luokkakaavio voidaan suoraviivaisesti kuvata XMLskeeman avulla OMG-ryhmittymän määrittelemän MOF (Meta Object Facility) 2.0 XMI (XML Metadata Interchange) Mapping -spesifikaation perusteella [21]. Taulukossa 2.1 on lyhyesti esittely, miten yleisimmät luokkakaavion komponentit kuvataan XML-skeeman avulla. Taulukko 2.1. UML-komponenttien kuvaus XML-skeeman avulla [22]. UMLkomponentti Komponentin esitys XML-skeeman avulla Pakkaus Pakkauksesta generoidaan skeema (schema-elementti). Jos pakkaus sisältää luokkia toisesta pakkauksesta, jolla on annettu arvot targetnamespace ja targetnamespaceprefix, nämä 15

25 sisällytetään (include) skeeman attribuuteiksi. Luokka Attribuutti Yhteys Yleistäminen (Periytyminen) Kaikista viitatuista pakkauksista luodaan import- tai includeelementti. Include-elementtiä käytetään, kun ulkoinen pakkaus jakaa saman nimiavaruuden ja import-elementtiä, kun nimiavaruus ei ole sama. Luodaan juuritason elementti, joka on tyypiltään kompleksinen (complextype). Elementin nimi ja tyyppi ovat samoja kuin luokan nimi. Luokan sisältämiä attribuutteja varten luodaan sekvenssi. Jokaiselle luokan attribuutille luodaan oma elementti. Elementin nimeksi annetaan luokan nimi lisättynä attribuutin nimellä (esimerkiksi luokka.attribuutti). Asetetaan elementin lukumääräsuhteet (minoccurs ja maxoccurs) attribuutin kardinaliteetin mukaan (mikäli määritelty). Jos attribuutti viittaa toiseen luokkaan, elementtiä seuraa kompleksinen tyyppi (complextype) -määrittely, joka sisältää viittauksen vastaavaan kompleksiseen tyyppiin. Luodaan elementti jokaista luokasta lähtevää yhteyttä kohti. Elementin nimeksi annetaan luokan nimeen lisätty yhteyden nimi. Elementtiä seuraa kompleksinen tyyppimäärittely (complextype), joka sisältää elementin, jolla on viittaus (refattribuutti) yhteyden toisen pään elementtiin. Viittauksen lisäksi määritellään lukumääräsuhteet (minoccurs ja maxoccurs) yhteyden kardinaliteetin mukaan. Mikäli yhteyden suuntaa ei ole määritelty, voidaan se puoli, johon elementti luodaan, olettaa lähtöpisteeksi. Yliluokasta periytetylle alaluokalle luodaan aluksi tavallisen luokan tapaan juuritason elementti, joka on tyypiltään kompleksinen (complextype). Elementti laajentavat yliluokkaa, joten se merkataan laajennus-elementillä (extension), jonka kanta-attribuutin (base) arvoksi annetaan yliluokan nimi. 16

26 Kuvan 2.1 tilanne, jossa vakuutus turvaa asiakkaan, voitaisiin siis määritellä myös XML-skeeman avulla. Esimerkkikoodi tilanteesta kuvassa 2.8. Kuva 2.8. XML-skeeman koodi kuvan 2.1 luokkakaavion pohjalta. Prosessi onnistuu tietenkin myös käänteisesti, eli XML-skeema (kuten myös XML DTD) voidaan kuvata UML-luokkakaavion avulla. 2.4 Mallinnuskieliä erityisesti hypermediasovelluksille RMM Tämä alakohta perustuu artikkeleihin [23] ja [24]. RMM (Relationship Management Methodology) on suunnittelumenetelmä, joka mahdollistaa sekä koko sovelluksen että yksittäisten sivujen sisällön ja rakenteen suunnittelun. Lisäksi se ottaa suunnittelussa huomioon navigoinnin ja sovelluksen toiminnallisuuden. RMM-menetelmällä voidaan suunnitella pieniäkin sovelluksia, mutta sen hyödyt tulevat erityisesti esille suunniteltaessa laajoja kokonaisuuksia. RMM-menetelmän kivijalka on RMDM-tietomalli. Se on ER (Entity-Relationship) ja HDM (A Model for the Design of Hypertext applications ) malleista kehitetty tapa mallintaa hypermediasovelluksen käsitteitä, niiden välisiä yhteyksiä ja yhteyksien 17

27 lukumääräsuhteita. RMDM-mallissa on valmiina komponentit tietoalkioiden, näkymien ja mitä erilaisimpien navigointirakenteiden suunnitteluun. Menetelmässä suunnittelu on jaettu seitsemään eri välivaiheeseen, jotka toistuvat pääasiallisesti sarjassa. Vaikka menetelmässä edetäänkin vesiputousmallin tyyppisesti vaiheesta toiseen, voidaan suunnittelussa aina palata myös alkuun ja aloittaa uusi kierros. Erityisen huomion kohteena menetelmässä ovat kolme ensimmäistä vaihetta. Vaihe 1: Tietomallin suunnittelu. Mallinnetaan sovellusalueen käsitteet tietoalkioksi. Lisäksi määritellään tietoalkioiden väliset suhteet ja nimetään ne. Ensimmäisen vaiheen tuloksena saadaan tietomalli ER-kaaviona. Mallinnuksessa käytettävä ER-kaavio muistuttaa paljon aikaisemmin esitettyä UML-luokkakaaviota ja voisi olla esitettävissä myös sen avulla. Vaihe 2: Näkymien suunnittelu. Jakamalla tietoalkiot sopiviin pienempiin palasiin, saadaan muodostettua tietoalkion näkymät. Tietoalkiolla voi olla useita eri näkymiä, mutta sillä on oltava ainakin yksi oletusarvoinen näkymä head. Näkymien väliset yhteydet määritellään ja nimetään. Vaiheen tarkoitus on antaa suunnittelijalle mahdollisuus erityisesti keskittyä kerrallaan yhteen tietoalkioon ja suunnitella sen sisältöä. Tuloksena saadaan rikastettu ER-kaavio, eli ER+ -kaavio. Siinä on edellisen vaiheen ER-kaavion lisätty jokaiseen tietoalkioon sen näkymäsuunnittelu. Vaihe 3: Navigaation suunnittelu. Suunnitellaan menu-tyyppiset navigointirakenteet sovellukselle. Valitaan myös tietomallin tietoalkioiden välisistä yhteyksistä nyt ne, jotka ovat lopullisessa sovelluksessa navigoitavissa. Kolmas vaihe tuottaa sovelluksen RMDM-kaavion, jossa navigointiratkaisut on otettu huomioon. Vaihe 4: Muunnosprosessin suunnittelu. Määritellään säännöt joilla suunnitellut komponentit voidaan muuntaa kohdejärjestelmän mukaisiksi. Muunnos voidaan tehdä käsin (esim. html (Hypertext Markup Language [25])) tai automaattisesti (esim. ohjelmointikieli ja tietokanta). Vaiheen tuloksena ovat muunnossäännöt. 18

28 Vaihe 5: Käyttöliittymän suunnittelu. Luonnostellaan käyttöliittymän yleinen ilme ja sijoitetaan kaikki vaiheen kolme RMDM-kaavion komponentit (navigointi, sisältö ym.) sivupohjiin. Vaihe 6: Ajonaikaisen toiminnallisuuden suunnittelu. Suunnitellaan miten sovelluksen toiminnallisuus muuttuu käyttäjän toimien mukaan. Voidaan siis esimerkiksi jäsentää käyttöliittymää asiakkaan navigointihistorian tai hänen tekemien hakujen perusteella. Vaihe 7: Toteutus ja testaus. Käytännön ohjelmointi ja merkkaus vaihe, jossa rakennetaan sovellus. Testauksessa todetaan sovelluksen toimivuus, erityisesti navigoinnin osalta. Verkkopalveluiden laajetessa ja niiden määrän lisääntyessä, on tullut tarvetta vakinaisille suunnitteluprosesseille. Tällöin projektien henkilökunta ja johto pystyy paremmin seuraamaan edistymistä ja hoitamaan oman osansa oikea-aikaisesti. RMM on yksi hyvä ja melko suosittu tapa vastata tähän tarpeeseen WebML Tämä alakohta perustuu artikkeliin [26]. WebML (Web Modeling Language) on mallinnuskieli datakeskeisille hypermediasovelluksille. Sen avulla voidaan suunnitella sovelluksen ydintoiminnot ottamatta kantaa sovelluksen arkkitehtuuriin. WebML hyödyntää XML-kieltä, jolloin tehty suunnittelu voidaan suoraa kääntää ohjelmakoodiksi sopivilla työvälineillä. Suunnitteluprosessi koostuu karkeasti jaoteltuna neljästä vaiheesta. Prosessissa on eriytetty sovelluksen rakenne, rakenteen osien väliset yhteydet, ulkoasu ja personointi. Menetelmästä hyödytään, kun jokaista prosessin osaa voidaan valita suunnittelemaan sen osa-alueen ammattilaiset. Vaihe 1: Rakennemalli. Mallinnetaan sovellusalueen käsitteet tietoalkioiksi ja määritellään niiden väliset suhteet. Malli voidaan esittää graafisesti ER-kaavion tai 19

29 UML-luokkakaavion avulla, mutta yhtä hyvin se voidaan kuvata myös XMLdokumenttina. Vaihe 2: Hypertekstimalli. Hypertekstimallilla kuvataan yhtä tai useampaa hypertekstiä, jotka sivuilla julkaistaan. Hyperteksti määrittää mallissa näkymän. Näkymä koostuu ladonta- ja navigointimalleista, jotka ovat hypertekstimallin alimalleja. Vaihe 3: Esitysmalli. Esitysmalli määrittää taiton sovellukselle. Se on laite- ja ohjelmointiriippumaton tapa kuvata taittoa XML-kielen avulla. Kuvaukset voivat olla yleisiä koko sivustolle, mutta myös yksittäisten sivujen ulkoasu voidaan määritellä erikseen. Vaihe 4: Personointimalli. Vaiheessa mallinnetaan käyttäjien personointiin liittyviä ominaisuuksia. Voidaan siis luoda sääntöjä, joilla verkkopalvelua mukautuu käyttäjän antamien tietojen tai hänen tekemien toimien mukaan. Nämä säännöt voidaan mallintaa XML-kielellä. Esimerkki säännöistä voisi olla vaikka levykaupan suositus vastaavista levyistä, mitä käyttäjä juuri katsoo. Personointia voidaan liittää yksittäisten käyttäjien lisäksi myös tiettyihin käyttäjäryhmiin. WebML-mallinnuskieli kattaa koko verkkopalvelun rakenteellisen suunnitteluprosessin, lisäten siihen vielä tavan mallintaa ulkoasua, käyttäjiä ja personointia. Sitä on jo käytetty verkkopalvelun suunnittelualustoissa, jotka osaavat automaattisesti generoida koodia erilaisten mallien pohjalta. Tarkoitus on luoda alusta, joka osaa WebML-kielellä tehdyn mallin pohjalta tehdä multimodaalisia verkkopalveluita OOHDM Tämä alakohta perustuu artikkeliin [27]. OOHDM (Object-Oriented Hypermedia Design Model) on oliopohjainen suunnittelumalli laajojen hypermediasovellusten suunnitteluun. Siinä on erityisesti pyritty kiinnittämään huomiota sovellusten tietorakenteen ja navigoinnin kuvauksiin. 20

30 OOHDM-malli koostuu neljästä eri vaiheesta: vaatimusten määrittelystä, käsitteellisestä mallintamisesta, navigoinnin suunnittelusta ja käyttöliittymän suunnittelusta. Lisäksi loppuun voidaan vielä lisätä toteutusvaihe. Vaiheita voidaan käydä läpi myös ohjelmistotuotannosta tuttujen protoilu- tai inkrementaalisten mallien [3] tapaan. Jokaisessa vaiheessa muodostetaan oliopohjainen malli, jota sitten seuraavissa iteraatiokierroksissa voidaan rikastaa. Myös luokittelu, koostaminen ja yleistäminen/erikoistaminen ovat käytössä kaikissa suunnitteluprosessin vaiheissa. Vaihe 1: Vaatimusten määrittely. Vaiheessa määritellään toimijat, käyttöskenaariot ja näiden välinen yhteys. Käytännössä tämä tapahtuu esimerkiksi käyttötapauskaavion muodossa. Vaihe 2: Käsitteellinen mallintaminen. Mallinnetaan sovellusalueen käsitteet tietoalkioiksi. Määritellään lisäksi käsitteiden väliset yhteydet, niiden lukumääräsuhteet ja käsitteeseen liittyvät attribuutit. Yleisesti mallintamisen käytetään UMLluokkakaaviota. Vaiheen lopputuloksena saadaan sovellusalueen käsitekaavio eli UML:n tapauksessa luokkakaavio. Vaihe 3: Navigoinnin suunnittelu. Suunnitellaan ensimmäisen ja toisen vaiheen pohjalta sovelluksen navigointimalli. Suunnittelu voidaan tehdä vaikka käsitekaavioon, jolloin käsitteet toimivat näkyminä ja käsitteiden väliset yhteydet linkkeinä. Samalle sovellukselle voidaan tehdä useita navigoinnin suunnitteluja, jolloin eri suunnitelmat edustavat erilaisia navigointimahdollisuuksia erilaisissa tilanteissa. Vaihe 4: Käyttöliittymän suunnittelu. Mallinnetaan käyttöliittymän eri visuaaliset objektit käyttöliittymäluokiksi. Nämä luokat ovat koosteluokkia yleisemmistä luokista, kuten tekstikenttä- tai painike- ja rekursiivisesti toisista käyttöliittymäluokista. Visuaaliset objektit liittyvät edellisen vaiheen navigoinnin objekteihin. Vaiheessa voidaan myös määritellä, miten objektit reagoivat käyttäjän toimiin. Viimeisenä vuorossa olevassa toteutusvaiheessa toteutetaan ja otetaan käyttöön suunniteltu sovellus. OOHDM-mallia on onnistuneesti käytetty multimedia- ja websovellusten suunnittelu- ja toteutustyössä. 21

31 3. Lokitietoanalyysi 3.1 Lokitieto Lokitiedolla tarkoitetaan systemaattisesti pidettyä päiväkirjaa eli sellaista kirjanpitoa, johon on aikajärjestyksessä lisätty merkintöjä tietynlaisista tapahtumista [28]. Lokitietoja kerätään resurssien käytön seurannan ja optimoinnin vuoksi. Myös tietoturvallisuutta voidaan seurata lokitietojen avulla. Lokitietoja luovat monet ohjelmat aina käyttöjärjestelmistä yksinkertaisiin skriptiohjelmiin. Tässä luvussa keskitytään erityisesti http-palvelimiin ja niiden lokitietoihin. Käyttöjärjestelmät ja monet muut ohjelmat luovat lokeja. Ne ovat tärkeitä, kun halutaan tietää, miten johonkin outoon tilanteeseen päädyttiin, vaikka kyseessä ei olisikaan tahallinen tietoturvaloukkaus. Keskitytään nyt erityisesti http-palvelimiin ja niiden lokitietoihin. Saatavan lokitiedon tarkka syntaksi riippuu aina http-palvelinohjelmistosta. Ylivoimainen markkinajohtaja alalla on Apache HTTP Server -ohjelmisto lähes 70 % markkinaosuudella [29]. Toinen merkittävä tekijä on Microsoft IIS (Internet Information Services) ohjelmistollaan. Saatavasta datasta järjestelmän ylläpitäjä voi tarkkailla palvelimen kuormitusta ja ratkaista mahdollisia ongelmia ja virhetilanteita. Apachen palvelinohjelmisto sisältää Access- (eli tapahtuma-), Error-(eli virhe-), PID 22

32 File-, Script- ja Rewrite-lokit, joista kaksi ensin mainittua ovat merkittävimmät liittyen palvelimen tapahtumiin ja virhetilanteisiin [30]. Kuva 3.1. Esimerkki tapahtumalokin tapahtumasta. Tapahtumaloki kirjaa ylös kaikki palvelimelle tulevat http-pyynnöt. Ylläpitäjä voi itse määritellä lokitietojen muodon ja kirjattavat tiedot, mutta yleisesti käytössä kaksi formaattia: CLF (Common Log Format) ja CoLF (Combined Log Format) [30]. CLFrivi koostuu seuraavaista tiedoista: etäisäntä, etäkäyttäjä, tunnistettu käyttäjä RFC1413, pvm, URL (Uniform Resource Locator), pyynnön tila, siirretty tavumäärä. CoLF:ssa on lisäksi tiedot asiakkaan selaimesta (agentti) ja mistä selain linkittyi. Esimerkki CLF:n mukaisesta rivistä on kuvassa 3.1. Kuva 3.2. Esimerkki virhelokin tapahtumasta Virheloki on järjestelmän ylläpitäjän tärkein työväline. Se sisältää tiedot kaikista virhetilanteista, joita palvelimella tapahtuu http-pyyntöjen käsittelyssä. Virheloki kuvaa, mikä virhetilanteessa meni pieleen ja yleensä vielä, miten sen voi korjata. Lokin formaatti ei ole niin tarkka kuin tapahtumalokissa, mutta tietyt tiedot, kuten aika, virheen vakavuus, asiakkaan IP:n (Internet Protocol) ja virheen kuvaus, löytyvät yleensä lokitapahtumasta. Esimerkki virhelokista, jossa sivua ei löydy, on kuvassa Web-tiedonlouhinta Web-tiedonlouhinta yleisesti Tiedonlouhinta on ei-triviaalia implisiittisen ja aiemmin tuntemattoman tiedon keräämistä datasta. [31]. Se tulee avuksi silloin, kun tutkittavan datan määrä tai laatu on liian monimutkaista tutkittavaksi ihmiselle. Web-tiedonlouhinta on tiedonlouhintaa webissä [32]. Tietoa voidaan louhia webistä sisällön, rakenteen ja käytön perusteella 23

33 [33]. Käyttötiedonlouhintaa voidaan tehdä lokitietoja hyväksikäyttäen ja jatkossa keskitytäänkin erityisesti siihen osa-alueeseen. HTTP-palvelimet sisältävät valtavat määrät dataa, josta on jalostettavissa kiinnostavaa tietoa web-tiedonlouhinnan menetelmin. Keräämällä tietoa verkkopalvelun käyttäjistä ja miten he verkkopalvelua käyttäjät, voidaan kehittää verkkopalvelua suuntaan, joka on edullinen molemmille osapuolille. Seuraavissa alakohdissa tarkastellaan yleisimpiä web-tiedonlouhinnalla tavoiteltavia hyötyjä. Web-tiedonlouhintaprosessin eri vaiheita on esitelty kohdassa 3.3 ja siihen liittyviä erilaisia menetelmiä kohdassa Personointi Verkkopalvelun personoinnissa palvelua mukautetaan käyttäjän ominaisuuksia ja tarpeita vastaavaksi [33]. Personointi voidaan kohdistaa verkkopalvelun sisältöön, rakenteeseen ja ulkoasuun, ensin ja viimeksi mainitun ollessa kuitenkin yleisimmät tavat [33]. Hyvä esimerkki toimivasta sisällön personoinnista on verkkokauppa Amazon (kuva 3.3). Amazon personoi sisältöä verkkosivuillaan käyttäjän oman, muiden käyttäjien ja ulkopuolisten sponsorien välittämän tiedon perusteella. Toimivalla personoinnilla yritysten on mahdollista kasvattaa tulostaan, mutta se tuo lisäarvoa myös tavalliselle käyttäjälle. Kuva 3.3. Amazon verkkokauppa suosittelee dynaamisesti kirjoja Personointia voidaan tehdä verkkopalveluissa manuaalisesti tai automaattisesti. Manuaalisessa personoinnissa käyttäjältä kysytään suoraan esimerkiksi lomakkeiden avulla, mistä hän on kiinnostunut. Manuaalinen personointi vaatii myös käyttäjien 24