Ontologistøttet søk i helsesystemer/store databaser. Kundestyrt Prosjekt - Gruppe 17

Transkript

1 Ontologistøttet søk i helsesystemer/store databaser Kundestyrt Prosjekt - Gruppe 17 Institutt for Datateknikk og Informasjonsvitenskap Norges Teknisk-Naturvitenskapelige Universitet

2

3 Forord Denne rapporten er sammen med protoypen kalt OntoSearch, resultatet av gruppe 17 sitt arbeid i faget TDT Kundestyrt prosjekt ved Institutt for Datateknikk og Informasjonsvitenskap (IDI) ved Norges teknisk-naturvitenskaplige universitet (NTNU) høsten Prosjektoppgaven ble gitt av trondheimsbedriften Extend AS, som er et programvareselskap som utvikler kvalitets- og prosesstøttesystemet EQS. EQS brukes i dag av en rekke bedrifter, blant annet i helsesektoren. I dette prosjektet har gruppa utviklet en prototyp for ontologistøttet søk i helsesystemer/store databaser. Ontologistøttet søk er et stort forsknings- og satsingsområde innen informasjonsgjenfinningsmiljøer. Gruppa vil rette takk til hovedveileder professor Jon Atle Gulla og hjelpeveileder Gunn Marie Navestad for god hjelp og rettledning gjennom hele prosjektperioden. Trondheim Jørn Ole Skaaraas Paul Christian Sandal Tarjei Lægreid Geir Øyvin Grimnes Håvard Mork Andreas Mathias Berg i

4 ii

5 Innhold I Prosjektdirektiv 1 II Forstudium 55 III Kravspesifikasjon 155 IV Konstruksjon 221 V Implementasjon 271 VI Testdokumentasjon 305 VII Evaluering 395 VIII Brukerveiledning 431 iii

6

7 Del I Prosjektdirektiv 1

8

9 Innhold 1 Innledning Hensikt Omfang Definisjoner Struktur Prosjektmandat Prosjektnavn Prosjektsponsor Interessenter Bakgrunn for prosjektet Effektmål Resultatmål Prosjektets omfang Rammebetingelser Økonomi Tid Prosjektplan Utviklingsmodell Faser Planlegging Forstudium Kravspesifikasjon Konstruksjon Implementasjon

10 INNHOLD INNHOLD Testing Dokumentasjon Evaluering Presentasjon og demonstrasjon Andre aktiviteter Prosjektledelse Forelesninger og selvstudium Milepæler Timeestimat Organisering Roller Beskrivelse av roller Prosjektleder Kundekontakt QA-ansvarlig Dokumentansvarlig Teknisk ansvarlig Testansvarlig Maler og standarder Møteinnkalling Møtereferat Statusrapport Standarder Katalogstruktur på fellesområde Fasedokumenter Føring av kilder Versjonskontroll CVS

11 INNHOLD INNHOLD 6 Prosjektoppfølging Interne møter Møter med kunde Møter med veileder Intern rapportering Statusrapportering TROKK Kvalitetssikring Responstider kunde Innkalling kundemøte Referat kundemøte Responstider veileder Innkalling veiledermøte Referat veiledermøte Interne responstider Kvalitet første gang Godkjenning av fasedokumenter A Begrepsordliste 33 B Interessenter 35 C Maler 37 D Gantt-diagrammer 43 D.1 Gantt-diagrammer D.2 Gantt-diagrammer E Risikoplan 47 5

12 INNHOLD INNHOLD 6

13 Kapittel 1 Innledning Dette kapitlet inneholder prosjektdirektivet for gruppe 17 i faget TDT4290 Kundestyrt Prosjekt, høsten Hensikt Prosjektdirektivet er et dynamisk dokument som skal oppdateres gjennom hele prosjektet. Dokumentet er ment som en veiledning i gjennomføringen av prosjektet. 1.2 Omfang Prosjektdirektivet regulerer den administrative biten av prosjektet og legger føringer på prosjektgjennomføringen. Alle endringer av planer og tidsfrister skal alltid oppdateres i dokumentet. 1.3 Definisjoner En ordliste med forklaringer av ord og definisjoner er presentert i vedlegg A. 1.4 Struktur Dokumentet er delt inn i 7 kapitler: Kapittel 2 inneholder prosjektmandatet, som gir en overordnet beskrivelse av prosjektet. Kapittel 3 beskriver prosjektets faser og inneholder tidsplaner for fasene. 7

14 1.4. STRUKTUR KAPITTEL 1. INNLEDNING Kapittel 4 innebærer. beskriver prosjektdeltagernes roller i prosjektet, og hva de forskjellige rollene Kapittel 5 beskriver maler for de forskjellige dokumentene som inngår i prosjektet, og beskriver ulike standarder som skal brukes. Kapittel 6 Kapittel 7 beskriver ulike tiltak for hvordan oppfølging skal gjennomføres i prosjektet. forklarer hvordan det skal sikres at kvaliteten ved prosjektet blir ivaretatt. 8

15 Kapittel 2 Prosjektmandat Dette kapitlet definerer prosjektets interessenter, mål, omfang og rammebetingelser. 2.1 Prosjektnavn Ontologistøttet søk i helsesystemer/store databaser. Navnet OntoSearch blir brukt som en arbeidstittel for prototypen gruppa utvikler. OntoSearch er ikke et registrert varemerke, og er heller ikke ment for kommersielt bruk. 2.2 Prosjektsponsor Extend AS Postboks 1237 Pirsenteret 7462 Trondheim E-post: firmapost@extend.no 2.3 Interessenter Interessentene i prosjektet er listet opp i vedlegg B 2.4 Bakgrunn for prosjektet I store informasjonssystemer er gjenfinning av informasjon en hyppig utført og viktig oppgave. Extend ønsker ved dette prosjektet å vurdere muligheten for å benytte ontologier til å søke etter dokumenter i en potensielt meget stor database. Målet er å gjenfinne korrekt informasjon på en mer effektiv måte enn det som er oppnådd i Extend sine systemer i dag. 9

16 2.5. EFFEKTMÅL KAPITTEL 2. PROSJEKTMANDAT 2.5 Effektmål Ontologistøttet søk skal forbedre et tradisjonelt søkesystem, enten ved at resultatutvalget gir høyere precision og recall, eller ved at det blir enklere for brukerne å spesifisere søket. 2.6 Resultatmål Prosjektet skal resultere i en prototyp av et søkesystem. Systemet skal effektivisere og forbedre dagens søkemotor hos Extend, ved å benytte ontologisk støttet søk. 2.7 Prosjektets omfang Gruppa skal sette seg inn i ontologibegrepet og omkringliggende teknologier. Etter en forstudiumsfase skal det skisseres en løsning som skal implementeres. I tillegg til et implementert system skal en prosjektrapport utarbeides. 2.8 Rammebetingelser Tabell 2.1 lister opp rammebetingelsene for prosjektet. Rapportens språk: Konfidensialitet: Begrensninger på utviklingsprogramvare: Begrensninger på brukergransesnitt: Norsk Åpent tilgjengelig Ingen begrensninger Web-basert Tabell 2.1: Rammebetingelser for prosjektet. 2.9 Økonomi Prosjektet budsjetteres med 310 timer per student, eller totalt 1860 timer for 6 studenter. Dette inkluderer to seminarer i gruppedynamikk og forelesninger Tid Prosjektets oppstart er 24. august. Torsdag 28. oktober er det preleveranse av forstudium og kravspesifikasjon. Prosjektet sluttføres 18. november. Denne dagen skal gruppa presentere prosjektet og demonstrere resultatet kl i rom IT

17 Kapittel 3 Prosjektplan Prosjektplanen inneholder de fasene gruppa har lagt opp til at prosjektet skal inneholde. For hver fase har hvert gruppemedlem ansvar for forskjellige arbeidspakker. Disse er listet opp, sammen med estimater for start- og sluttdato. De forskjellige fasene overlapper hverandre, og en påfølgende fase påbegynnes før den forrige avsluttes. Prosjektets milepæler er også beskrevet i dette kapitlet. 3.1 Utviklingsmodell Figur 3.1: Vannfallsmodell over fasene i prosjektet Vannfallsmodellen i figur 3.1 viser fremdriften i prosjektet, gjennom de forskjellige fasene. 11

18 3.2. FASER KAPITTEL 3. PROSJEKTPLAN En boks refererer til en fase, mens piler viser overganger mellom faser. Modellen er enkel og sekvensiell, og har klart definerte milepæler. Gruppa har valgt å ha en tilbakekobling fra testing til implementasjon. Årsaken for dette er at det etter testene vil bli behov for å kunne gå tilbake og implementere nye ting, evt. rette opp i feil i implementasjonen. Gruppa har også valgt å sette opp en tilbakekobling fra implementasjon til konstruksjon. Grunnen til dette er at det under implementasjonen kan dukke opp behov for konstruksjon av nye elementer. 3.2 Faser Prosjektet er delt inn i ni faser. Før hver fase er sluttført, utarbeides en detaljert plan for neste fase. Disse vedlegges direktivet fortløpende. Vedlegg D.1 viser et ganttdiagram over gjennomføringen av prosjektet slik gruppa planla det. I vedlegg D.2 er det satt inn et ganttdiagram som viser hvordan denne prosjektplanen endte opp. Ved en sammenligning av disse to diagrammene, går det frem at det stort sett er i siste halvdel av prosjektet det finnes avvik fra opprinnelig plan. Årsakene til avvikene fra den opprinnelige planen er diskutert i Evalueringen Planlegging I denne fasen utarbeides prosjektdirektivet. Arbeidet begynner ved prosjektstart og fordeles i gruppa på følgende måte: Arbeidspakke Beskrivelse Ansvarlig Prosjektmandat Beskrive prosjektnavn, innhold, interessenter, tid og omfang. Tarjei Prosjektplan Sette opp faser, aktiviteter og milepæler. Andreas og Paul Organisering Fordeling av roller og ansvar Jørn Ole Maler og standarder Lage dokumentmaler og katalogstruktur Geir Øyvin Versjonskontroll Utarbeide prosedyrer for versjonskontroll av dokumenter og Håvard kode Prosjektoppfølging Utarbeide faste rutiner for møter, rapportering og risikohåndtering Håvard og Jørn Ole Kvalitetssikring Avtale faste møtetider og responstider Tarjei Tabell 3.1: Planleggingsfasen - ansvarsfordeling Planleggingsfasen skal være fullført 5. september Forstudium Innhenting av relevant informasjon gjennom litteratur og studie av eksisterende løsninger.forstudiet påbegynnes 5. september. Arbeidspakkene som inngår i forstudiet er: Forstudiet skal være fullført 24. september. 12

19 KAPITTEL 3. PROSJEKTPLAN 3.2. FASER Arbeidspakke Beskrivelse Ansvarlig Søkealgoritmer Studere alternative søkealgoritmer/motorer for uthenting av Håvard ontologi Generering av ontologi Studere muligheter for å automatisk generere ontologier Håvard Brukegrensesnitt Finne alternativer til hvordan brukegrensesnitt skal se ut Andreas og Geir Øyvin Kontakte KITH Forsøke å få tilgang til KITHs ontologier og se om det er noen Andreas mulighet for at gruppa kan bruke disse Markedsanalyse Studere systemer som bruker ontologier Andreas Nåværende system Studere dagens system hos Extend Geir Øyvin og Jørn Ole Ontologier generelt Studere ontologier generelt Jørn Ole Kontakt med DIBgruppa Holde kontakt med DIB-gruppa for å se om det er måter å Jørn Ole samarbeide med dem Standarder Studere XML, RDF, OIL, DAML, OIL+DAML og OWL for å Paul og Tarjei finne ut hvilken ontologi gruppa bør bruke Programmeringsomgivelser Studere alternative programmeringsomgivelser for å finne ut Paul hvilken omgivelse gruppa skal implementere systemet i Wordnet Studere systemet Wordnet for å finne ut om det eventuelt kan brukes i prosjektet Tarjei Tabell 3.2: Forstudiefasen - ansvarsfordeling Kravspesifikasjon I kravspesifikasjonen utarbeides oversikt over alle typer krav til systemet og omgivelsene. Denne fasen påbegynnes 24. september. Arbeidspakkene som inngår i kravspesifikasjonsfasen er: 13

20 3.2. FASER KAPITTEL 3. PROSJEKTPLAN Arbeidspakke Beskrivelse Ansvarlig Korrektur på forstudiet. Lese over forstudiet og rette opp i feil og inkonsistens. Andreas og Geir Øyvin Introduksjon Introduksjon og generell innledning til kravspesifikasjonen. Håvard Overordnede krav Sette opp overordnede krav til systemet. Tarjei Brukergrensesnitt Krav grafisk brukergrensesnitt. Andreas Søkealgoritmer Detaljert beskrivelse av og krav til søkealgoritmer. Håvard Ontologisk behandling Krav til hvordan ontologien skal brukes. Tarjei Kommunikasjonsgrensesnitt Krav til grensesnitt mellom enheter i systemet. Jørn Ole Søkeindeksering Krav til indekseringsprosessen. Håvard Arkitektur Krav til systemarkitektur. Jørn Ole Dokumentasjon Krav til dokumentasjonen av prosjektet. Geir Øyvin Kildekode Krav til hvordan kode skal skrives og dokumenteres. Geir Øyvin Overordnet testplan Sette opp overordnet testplan. Paul Diskusjon med kunde Diskutere kravene med kunde. Alle Korrektur og kvalitetssikring Kvalitetssikre sine egne deler og helheten på dokumentet. Alle Tabell 3.3: Kravspesifikasjonsfasen - ansvarsfordeling Kravspesifikasjonen skal være ferdig 5. oktober Konstruksjon Systemet designes mer detaljert ut ifra kravspesifikasjon. Designet omfatter både valg av teknologi og struktur. I tillegg utvikles testplan for systemet, med detaljerte testspesifikasjoner. Fasen påbegynnes 5. oktober. Følgende arbeidspakker inngår i konstruksjonsfasen: 14

21 KAPITTEL 3. PROSJEKTPLAN 3.2. FASER Arbeidspakke Beskrivelse Ansvarlig Overordnet systemarkitektur Konstruksjon av systemarkitektur. Håvard Testplan Testplan med tester for alle krav. Andreas og Paul Datalagring Hvordan lagre dataene i systemet. Geir Øyvin Ontologimodul Konstruksjon av ontologisk grensesnitt og konstruksjon av ontologi. Tarjei og Paul Brukergrensesnitt Konstruksjon av brukergrensesnittet. Jørn Ole Søkemodul Detaljert konstruksjon av søkemodulen, inkludert søkealgoritmer. Håvard Indekseringsmodul Konstruksjon av indekseringsmodulen. Håvard Mapping mellom Sjekke at kravene blir fulgt og oppfylt i konstruksjonen. Geir Øyvin design og krav Innledning Skrive innledning til dokumentet Håvard og Tarjei Tabell 3.4: Konstruksjonsfasen - ansvarsfordeling Konstruksjonsfasen skal være fullført 20. oktober Implementasjon Systemet implementeres og dokumenteres (kode-dokumentasjon) etter krav og spesifikasjoner som er gitt i tidligere faser. Implementasjonsfasen påbegynnes 20. oktober. Følgende pakker inngår i fasen: Arbeidspakke Beskrivelse Ansvarlig Søkemodulen Implementasjon av søkemodulen. Håvard Testplan Testplan med tester for alle krav. Andreas og Paul Jena Grensesnitt mot ontologi. Tarjei og Paul Ontologimodul Implementering av ontologimodul. Tarjei og Paul Ontologi Oppbygging av ontologi. Paul og Geir Øyvin Brukergrensesnitt Implementasjon av brukergrensesnittet. Håvard og Jørn Ole Implementasjonsdokumentasjon Sette opp dokumentet. Geir Øyvin Kvalitetssikring av dokumenter Kvalitetssikre alle dokumenter. Tarjei Tabell 3.5: Implementasjonsfasen - ansvarsfordeling Implementasjonsfasen skal være fullført 3. november Testing I testfasen skal overordnet testplan, samt detaljerte tester utarbeides. Testene skal også utføres, og testresultatene skal dokumenteres. Dette vil inngå i et eget testfasedokument. Fasen begynner 11. oktober. Følgende arbeidspakker inngår i testfasen: 15

22 3.2. FASER KAPITTEL 3. PROSJEKTPLAN Arbeidspakke Beskrivelse Ansvarlig Overordnet testplan Utarbeide overordnet testplan for prosjektet. Paul Spesifikke tester Utarbeiding av spesifikke tester for alle krav. Andreas og Paul Sjekkliste Utarbeide sjekkliste for inspeksjon. Paul Enhetstester Utføre enhetstester på all kode i systemet (kodeinspeksjon). Alle Modultester Utføre tester på hver enkelt modul. Jørn Ole, Geir Øyvin og Paul Systemtest Utføre test på systemfunksjonalitet. Jørn Ole, Geir Øyvin og Paul Akseptansetest Utføre akseptansetest med kunde Andreas, Jørn Ole og Paul Testdokumentasjon Utarbeide testdokumentasjonen Paul Tabell 3.6: Testfasen - ansvarsfordeling Testfasen skal være fullført 9. november Dokumentasjon I denne fasen utvikles brukerveiledning og installasjonsveiledning som senere kan benyttes av sluttbrukere. Dokumentasjonsfasen begynner 3. november. Følgende pakker inngår i fasen: Arbeidspakke Beskrivelse Ansvarlig Brukerdokumentasjon Utarbeide brukerdokumentasjon for systemet. Andreas og Håvard Kodedokumentasjon Skrive javadoc for all kode. Håvard Implementasjon Skrive implementasjonsdokumentasjon Geir Øyvin Designspesifikasjon Utbedre dokumentasjon av systemdesignet. Jørn Ole og Tarjei Tabell 3.7: Dokumentasjonsfasen - ansvarsfordeling Dokumentasjonsfasen skal være fullført 9. november Evaluering I denne fasen skal prosjektgruppas arbeid evalureres, og sluttrapporten ferdigstilles. Evalueringsfasen begynner 9. november. Følgende arbeidspakker inngår i evalueringsfasen: Evalueringsfasen skal være fullført 12. november Presentasjon og demonstrasjon I denne fasen forberedes den endelige presentasjonen og alle dokmenter sluttføres. Fasen begynner 9. november. Følgende arbeidspakker inngår i denne fasen: 16

23 KAPITTEL 3. PROSJEKTPLAN 3.3. ANDRE AKTIVITETER Arbeidspakke Beskrivelse Ansvarlig Oppsett Sette opp struktur for dokumentet. Geir Øyvin Prosessen og resultatet En evaluering av gruppeprosessen og hva gruppa har oppnådd med prosjektet. Andreas Tidsforbruk Holdt gruppa tidsfristene? Hvorfor/Hvorfor ikke? Brukte gruppa Jørn Ole og mer timer enn planlagt? Andreas Kunden og oppgaven En evaluering av hvordan gruppa har oppfattet samarbeidet med kunde, og en evaluering av oppgaven gruppa har jobbet med. Andreas Faget En evaluering av faget TDT4290 Kundestyrt prosjekt. Geir Øyvin Videre arbeid Et forslag til hvordan prototypen kan utvikles og brukes videre hos kunde. Jørn Ole og Håvard Tabell 3.8: Evalueringsfasen - ansvarsfordeling Arbeidspakke Beskrivelse Ansvarlig Struktur Sette opp struktur for presentasjonen. Andreas og Jørn Ole Oppgaven og mål En innledning av oppgaven, og hvilke mål gruppa satte seg. Geir Øyvin Problemer og prioriteringer Hvilke problemer gruppa støtte på, og hvordan prioriteringer Tarjei og Paul ble gjort. Løsningen Beskrive løsning gruppa endte opp med. Håvard Demo Hva skal vises? Testdata? Rekkefølge? Jørn Ole og Håvard Konklusjon Nådde gruppa målene? Paul og Andreas Tabell 3.9: Presentasjonsfasen - ansvarsfordeling Presentasjon- og demonstrasjonsfasen skal være fullført 18. november. 3.3 Aktiviteter som pågår gjennom hele prosjektet Aktiviteter som pågår gjennom hele prosjektet defineres ikke som egne faser, men er likevel en viktig del av prosjektet. Dette gjelder: Prosjektledelse Denne aktiviteten vil pågå under hele prosjektets levetid og omfatter all organisering, kvalitetssikring, dokumentforvaltning, timeregistrering og annen administrativ virksomhet Forelesninger og selvstudium Denne aktiviteten omfatter obligatoriske og frivillige forelesninger i faget og individuelle selvstudier i forbindelse med prosjektet. Forelesninger og selvstudium vil pågå under hele prosjektet. 17

24 3.4. MILEPÆLER KAPITTEL 3. PROSJEKTPLAN 3.4 Milepæler Milepælene er satt relativt tett, da dette vil kunne være med på holde fokus innad i gruppa. Under følger en tabell med faseavslutningene, med estimert dato for fullføring av fasene. Estimert dato Fase avsluttet Planlegging ferdig Forstudium ferdig Kravspesifikasjon ferdig Konstruksjon ferdig Implementasjon ferdig Dokumentasjon ferdig Testing ferdig Evaluering ferdig Presentasjon og demo ferdig 3.5 Timeestimat Gruppa har tatt utgangspunkt i tidligere års rapporter ved beregning av timeestimat i prosjektet. Følgende timebruk er estimert: Aktivitet Belastning Timer pr/pers Timer totalt Prosjektledelse. 7% Forelesning og egenlæring. 8% Planlegging. 11% Forstudie 15% Kravspesifikasjon. 16% 49,5 297 Konstruksjon 15% Implementasjon 10% Dokumentasjon 4,5% Testing 3% 9 54 Evaluering 4,5% Presentasjon og demo 6% 18,5 111 Totalt 100% Tabell 3.10: Estimert ressursbruk per fase 18

25 Kapittel 4 Organisering I prosjekter er det viktig å avklare roller tidlig og å ha tillit til den som har den enkelte rollen for å kunne gjennomføre prosjektet på en mest mulig effektiv måte. Gruppa definerer roller for alle prosjektdeltakerne. Rollene definerer arbeidsområder, og hvem som har det overordnede ansvaret for de forskjellige oppgavene. Dette er viktig for at alle skal vite hvem som er ansvarlig for hva. Det blir dermed enklere å følge opp hver enkelt oppgave. 4.1 Roller For å fordele ansvar på en best mulig måte har gruppa valgt å gi alle deltakerne egne roller. Gruppa har gjort denne inndelingen på følgende måte: Rolle Prosjektleder: Kundekontakt: QA-ansvarlig Dokumentansvarlig: Teknisk ansvarlig: Test-ansvarlig: Referent: Navn Jørn Ole Andreas Tarjei Geir Øyvin Håvard Paul Rulleres innad i gruppa ukentlig. Tabell 4.1: Rollefordeling 4.2 Beskrivelse av roller I dette avsnittet følger en overordnet beskrivelse av hvilke ansvarsområder de forskjellige rollene innehar. Gruppa har valgt en gruppestruktur som vist i figur

26 4.2. BESKRIVELSE AV ROLLER KAPITTEL 4. ORGANISERING Figur 4.1: Gruppa bruker en linjeformet organisasjonsstruktur i prosjektet Prosjektleder Prosjektleder har overordnet ansvar for prosjektet. Han skal til enhver tid ha oversikt over status og fremdrift på prosjektet, og sørger for å gjøre nødvendige tiltak for å sikre at tidsfrister overholdes. Prosjektleder har ansvar for å følge opp at alle prosjektdeltakerne fører timer. Han har også ansvar for å skrive og levere statusrapport til veiledere. Prosjektlederen skal sørge for at fastsatte tidsplaner blir overholdt, samt koordinere oppgavene i prosjektet og lede veilder- og internmøter. Dersom det skulle oppstå konflikter i prosjektgruppa er det lederens ansvar å ta hånd om disse Kundekontakt Kundekontakt skal være kontaktperson for eksterne aktører. Han har ansvar for møteinnkallelser, herunder sette agenda, sende innkallelse og bestille møterom. Kundekontakt er også ordstyrer ved kundemøtene, og sørger for at dokumenter som skal fremlegges ved møtene er klargjort QA-ansvarlig Hovedansvaret til QA-ansvarlig er å påse at kundens eksplisitte og implisitte krav blir tilfredsstilt. Han har ansvar for at interne rutiner, arbeidsprosesser, metoder, teknikker og verktøy holder et nivå som muliggjør et godt sluttprodukt. Dette innebærer å sikre at terminologien og formateringen er konsistent i alle prosjektets dokumenter og kildekode. QA-ansvarlig skal også kontrollere at versjonshåndtering av dokumenter og kildekode fungerer på en tilfredsstillende måte. All dokumentasjon skal godkjennes av QA-ansvarlig og dokumentansvarlig Dokumentansvarlig Dokumentansvarlig har ansvar for maler og standarder. Han skal koordinere dokumenter fra de forskjellige gruppemedlemmene og har ansvar for katalogstruktur. Standarder for alle fasedokumenter skal også utarbeides av dokumentansvarlig. Dokumentansvarlig skal sammen med QA-ansvarlig godkjenne dokumentasjon. 20

27 KAPITTEL 4. ORGANISERING 4.2. BESKRIVELSE AV ROLLER Teknisk ansvarlig Teknisk ansvarlig har ansvar for driften av gruppas datamaskin, og for at CVS på gruppas fellesområde fungerer på en tilfredsstillende måte. Nettside-grensesnittet for registrering av timer er også teknisk ansvarlig sitt ansvar. Han har også hovedansvar for design og implementasjon av systemet, samt integrering med eventuelle eksisterende systemer Testansvarlig Testansvarlig har ansvaret for å lage overordnet testplan, samt plan for hver enkelt test som skal gjennomføres. Han har også ansvaret for at gjennomføring av testene utføres, og for å følge opp at retting av feil og retesting blir utført. I tillegg har han ansvaret for å skrive testdokumentasjon for prosjektet. 21

28 4.2. BESKRIVELSE AV ROLLER KAPITTEL 4. ORGANISERING 22

29 Kapittel 5 Maler og standarder Dette kapitlet inneholder maler som skal brukes for dokumenter, referater og rapporter. Gruppa holder seg til en standard for slike dokumenter. Dette for å forenkle arbeidet og holde god oversikt i prosjektet. Dette bidrar også til å unngå å bruke unødvendig mye tid på å skrive standard dokumenter som brukes mye i prosjektet (for eksempel møtereferater). 5.1 Møteinnkalling Maler for møteinnkallelser for: internmøter er vedlagt i vedlegg C veiledermøter er vedlagt i vedlegg C kundemøter er vedlagt i vedlegg C 5.2 Møtereferat Maler for møtereferater for: internmøter er vedlagt i vedlegg C kundemøter er vedlagt i vedlegg C veiledermøter er vedlagt i vedlegg C 5.3 Statusrapport Malen for statusrapporter er vedlagt i vedlegg C 23

30 5.4. STANDARDER KAPITTEL 5. MALER OG STANDARDER 5.4 Standarder Dette avsnittet beskriver diverse standarder som gruppemedlemmene skal følge gjennom hele prosjektet Katalogstruktur på fellesområde Alle filer som vedrører prosjektet skal lagres på fellesområdet på Ingen prosjektfiler skal lagres på private områder. Dette for å kunne følge opp hverandre, og å forhindre at dokumenter eksisterer i flere versjoner. Katalogene er navngitt etter dokumenttype (møter, maler, rapporter og faser), og filene er navngitt med datoen de er opprettet etterfulgt av beskrivelse, altså <[MMDD] [Beskrivelse]>. Møtekatalogen er videre inndelt i internmøter, kundemøter og veiledningsmøter. Fase-katalogen er inndelt i underfasene til prosjektet. Dessuten benyttes versjonskontroll, slik at alle endringer registreres. Dette er forklart nærmere i avsnitt 5.5. Figur 5.1: Filorganisering Fasedokumenter Alle fasedokumenter skal skrives i L A TEX. Dette gjelder også eventuelt også andre dokumenter som inngår i sluttrapporten. 24

31 KAPITTEL 5. MALER OG STANDARDER 5.5. VERSJONSKONTROLL Referater og møteinnkallelser skrives i Microsoft Word Føring av kilder For å unngå at kilder blir ført ulikt av de ulike gruppemedlemmene skal alle kilder føres ved å bruke BibTeX. Bokkilder Bokkilder føres etter følgende mal: Forfatter. Boknavn. Utgivelsesår. Forlag. Et eksempel på føring: Andrew S. Tanenbaum. Computer networks Inc. Prentice Hall PTR. Artikkelkilder Artikkelkilder føres etter følgende mal: Forfatter. Artikkelnavn. Utgivelsesår. Internettadresse (dersom tilgjengelig). Et eksempel på føring: Jim Farley. Microsoft.net vs. j2ee: How do they stack up? Internettkilder Kilder fra Internett føres etter følgende mal: Forfatter. Artikkelnavn. Publiseringsår. Internettadresse. Et eksempel på føring: Central Intelligence Agency. CIA - The World Factbook Versjonskontroll I løpet av prosjektet vil gruppa benytte et stort antall filer der alle deltakerne trenger skrivetilgang, og det oppstår derfor behov for å forsikre seg om at det ikke oppstår problemer dersom flere endrer samme filer samtidig. For å hindre inkonsistens tas det derfor i bruk et hjelpesystem CVS Gruppa bruker Concurrent Versions System (CVS) for versjonskontroll, da dette systemet har støtte for tekstlige dokumenter. 25

32 5.5. VERSJONSKONTROLL KAPITTEL 5. MALER OG STANDARDER CVS holder orden på historien til alle filene og sørger for at flere personer kan editere samme fil hver for seg uten at det oppstår problemer. Ved dette systemet slipper man også å lage symbolske linker for alle i gruppa, og man unngår å bruke mye tid på å sette rettigheter på filene. CVS brukes også for versjonshåndtering av kode. 26

33 Kapittel 6 Prosjektoppfølging For å påse at prosjektet har tilfredsstillende fremdrift innfører gruppa faste rutiner for å følge opp arbeidet og planlegge videre arbeid. Gruppa innfører rutiner for møtevirksomhet, håndtering av risiko, kartlegging av hvilke problemer som oppstår, samt hvordan man skal løse disse. 6.1 Interne møter Internmøter blir holdt på mandager kl.08.15, og torsdager kl Disse møtene blir holdt i femte etasje i P-15 bygget. På mandagens møte oppsummeres siste ukes arbeid og videre arbeid for den aktuelle uka planlegges. På torsdagens møte oppsummeres ukens kunde- og veiledermøte, samt status på arbeid. Konklusjoner fra disse møtene skrives ned i et referat. 6.2 Møter med kunde Hver tirsdag kl avholdes møte med kunden. Innkalling sendes senest 24 timer før møtet. Hensikten med disse møtene er å gi kunden status på fremdriften i prosjektet, samt å avklare aktuelle problemstillinger. 6.3 Møter med veileder Hver onsdag kl avholdes møte med hovedveileder. Innkalling til møtene sendes senest tirsdag kl Grunnen til at fristen er under 24t er for å få med aktuelle saker fra kundemøtet på agendaen. 27

34 6.4. INTERN RAPPORTERING KAPITTEL 6. PROSJEKTOPPFØLGING Dokumenter som skal gjennomgås på møtet sendes til hovedveileder og hjelpeveileder senest 24 timer før møtet. Statusrapport, referat fra forrige veildermøte og referat fra forrige kundemøte vedlegges alltid innkallelsen. 6.4 Intern rapportering Alle gruppemedlemmene skal registrere egne timer. Det skal registreres hva tiden er brukt til. Timerapporteringen for en uke regnes fra kl natt til mandag til kl søndag kveld. Registreringen gjøres på de interne websidene til gruppa, og skal registreres hver dag når arbeidet avsluttes. Prosjektleder følger ukentlig opp at alle fører timer. 6.5 Statusrapportering Statusrapporter brukes internt i gruppa, og som en rapport til veileder. Disse inneholder utført arbeid i perioden, hvilke problemer som har oppstått/blitt løst underveis, samt planlagt arbeid for neste periode. Mal for statusrapportering finnes i vedlegg C TROKK TROKK står for Tid, Risiko, Omfang, Kostnad og Kvalitet. Disse faktorene brukes ved rapportering av status til veileder. Statusrapportene produseres ukentlig i forkant av veiledermøtene. TROKK må derfor oppdateres ukentlig. Tid Det er viktig å dokumentere hvordan gruppa ligger an tidsmessig i forhold til fremdriftsplaner og milepæler. Det må tas hensyn til avvik i anvendt tid i forhold til planlagt tidsforbruk. Risiko Gruppa har samlet risikomomenter, sannsynligheter, konsekvenser og tiltak i en risikotabell. Risikomomentene kan få betydning for prosjektets fremdrift, kvalitet, kostnader og ressurser. Risikotabellen finnes i vedlegg E Omfang Dersom oppgaven eller kravene endrer seg underveis, må dette rapporteres i statusrapporten. 28

35 KAPITTEL 6. PROSJEKTOPPFØLGING 6.5. STATUSRAPPORTERING Kostnad/timer Teknisk ansvarlig har utviklet nettbasert system for registrering av timer. Dette for å gjøre det enklere å få en korrekt registrering av timer. Disse timene blir satt inn i en tabell sammen med totalt antall timer brukt sist uke, samt totalt brukt i prosjektet. Dette skjemaet legges ved statusrapporter. Det skal også redegjøres for hvordan prosjektet ligger an i forhold til planen, og om kostnadene har blitt overskredet. Skjemaet for timeregistrering finnes i vedlegg C. Kvalitet Her skal det dokumenteres om det har det skjedd noe underveis som forhindrer gruppa i å fullføre prosjektet i forhold til den planlagte grad av kvalitet. Det kan være visse deler av prosjektet som ikke kan fullføres ved at den tekniske vanskelighetsgraden er for høy eller at tiden ikke strekker til. 29

36 6.5. STATUSRAPPORTERING KAPITTEL 6. PROSJEKTOPPFØLGING 30

37 Kapittel 7 Kvalitetssikring Kvalitetssikringen i prosjektet søker å imøtekomme kundens implisitte og eksplisitte krav, samt å utarbeide gode rutiner for å følge tidsfrister i forhold til de dokumentene som skal utveksles. Kvalitetssikringens fremste oppgave er å hjelpe prosjektet med å gjøre kunden fornøyd, samt se etter forbedringsmuligheter i prosjektet. 7.1 Responstider med kunden Gruppa har avtalt følgende responstider med kunden: Referater skal sendes innen 24 timer etter møtet. Fristen for godkjenning av fasedokumenter og møtereferater er 2 virkedager. Kunden har sagt seg villig til å svare på spørsmål via e-post. Responstiden på disse spørsmålene er satt til 1 dag Innkalling til kundemøte Før alle møter med kunden sendes det ut en møteinnkalling der tid, sted, hensikt med møtet, agenda og bakgrunnsdokumenter inngår. Dersom det er ønskelig at kunden og/eller prosjektgruppa skal gjøre spesielle forberedelser i forkant av et møte skal dette presiseres i innkallingen. Innkallingen sendes senest 24 timer før møtet.mal for agenda til veiledermøtene finnes i vedlegg C Referat fra kundemøte Møtereferatene fra kundemøtene skal inneholde beslutninger, aksjoner, avklaringer og lignende som har betydning for det videre arbeidet med prosjektet. Referatene skal skrives ferdig, og sendes kunden innen 24 timer etter møtet finner sted. Tilbakemeldinger på referatene, med eventuelle bemerkninger, skal returneres fra kunden til gruppa innen 2 dager etter utsending av referatet. Mal for referat fra kundemøtene finnes i vedlegg C. 31

38 7.2. RESPONSTIDER VEILEDER KAPITTEL 7. KVALITETSSIKRING 7.2 Responstider med veileder Hovedveileder og hjelpeveileder gir tilbakemelding på dokumenter på neste veildermøte. Dokumentene skal være veilederne i hende senest 24 timer før møtene Innkalling til veiledermøte Innkalling til veiledermøtene sendes senest kl dagen før møtet. Mal for agenda til veiledermøtene finnes i vedlegg C Referat fra veiledermøter Møtereferatene fra veiledermøtene legges ved neste møteinnkalling og er et fast punkt på agendaen til veiledermøtet. Referatene skrives av prosjektleder innen kl dagen etter møtet, og godkjennes innen kl to dager etter møtet. Mal for referat fra veiledermøtene finnes i vedlegg C. 7.3 Interne responstider Internt i gruppa skal møtereferater godkjennes innen 24 timer, mens fasedokumenter skal godkjennes innen 48 timer. 7.4 Rutiner for å produsere kvalitet første gang Alle fasedokumenter skal godkjennes av dokumentansvarlig og QA-ansvarlig før de sendes til veileder eller kunde. Implementasjon skal gjennomgås av minst 1 person i tillegg til den som skriver koden. Dette for å sikre kvaliteten på koden. 7.5 Rutiner for godkjenning av fasedokumenter Fasedokumentene skal først godkjennes internt. Utbedringene gjøres av QA-ansvarlig. Når dokumentene er godkjent sendes de til kunden, som skal gi tilbakemeldinger innen 2 dager. Dokumentene sendes også til veiledere, som gir tilbakemelding ved neste veiledermøte. Veilederne skal ha dokumentene senest 24 timer før møtet. 32

39 Vedlegg A Begrepsordliste Concurrent Versions System (CVS) System for versjonshåndtering av filer. L A TEX L A TEXer et formateringsprogram. Hensikten med programmet er at man ikke skal måtte bry seg om utseende på dokumentet, og heller fokusere på innholdet. Ontologi: definerer begreper og relasjoner mellom disse i et gitt domene. Fungerer som et strukturert, semantisk leksikon over de termene som brukes innenfor domenet. Precision: Presisjon, her brukt om hvor presist et søk er. Recall: Gjenfinning. Her beskriver det hvor mange av de relevanten treffene søket finner. 33

40 34 VEDLEGG A. BEGREPSORDLISTE

41 Vedlegg B Interessenter Kunde Extend AS Postboks 1237 Pirsenteret 7462 Trondheim Tlf: firmapost@extend.no Kunderepresentanter Navn Jørgen Austvik Thomas Øhrbom Åse Berg E-post jorgen@extend.no thomas.ohrbom@extend.no ase.berg@hemit.no Prosjektgruppen Navn E-post Telefonnr. Håvard Mork havarmor@stud.ntnu.no Paul Christian Sandal paulchri@stud.ntnu.no Jørn Ole Skaaraas skaaraas@stud.ntnu.no Geir Øyvin Grimnes geiroyvi@stud.ntnu.no Andreas Mathias Berg andreb@stud.ntnu.no Tarjei Lægreid tarjeil@stud.ntnu.no Veiledere Rolle Navn E-post Hovedveileder Jon Atle Gulla jag@idi.ntnu.no Hjelpeveileder Gunn Marie Navestad gunnmari@stud.ntnu.no 35

42 VEDLEGG B. INTERESSENTER Andre KITH Navn Iver Nordhuus Jostein Ven E-post 36

43 Vedlegg C Maler Mal for statusrapport Statusrapport for perioden DD/MM - DD/MM 1. Oppsummering 2. Utført arbeid i perioden Dokumenter - status på dokumentene som skal utarbeides Møter Aktiviteter Annet 3. TROKK m/avvik og tiltak 4. Problemer - hva hindrer framdriften eller spiser ressurser 5. Planlagt arbeid neste periode Møter Aktiviteter Videre arbeid 37

44 VEDLEGG C. MALER Innkallelse til internmøte Dato: Tid: Sted: Til Gruppe Jørn Ole Skaaraas Paul Christian Sandal Håvard Mork Geir Øyvin Grimnes Tarjei Lægreid Andreas Mathias Berg Kopi til Agenda 1. Godkjenning av dagsorden 2. Godkjenning av referat fra forrige kundemøte 3. Punkter fra agenda i møteinnkallelse 4. Eventuelt Vedlegg Referat fra internmøte Dato: Tid: Sted: Møteleder: Referent: Tilstede Forfall Agenda 1. Godkjenning av dagsorden 2. Godkjenning av møtereferat fra forrige internmøte 3. Punkter fra agenda i møteinnkallelse 4. Eventuelt 38

45 VEDLEGG C. MALER Innkallelse til veiledermøte Dato: Tid: Sted: Til Hovedveileder Jon Atle Gulla Hjelpeveileder Gunn-Marie Navestad Gruppe Jørn Ole Skaaraas Paul Christian Sandal Håvard Mork Geir Øyvin Grimnes Tarjei Lægreid Andreas Mathias Berg Agenda 1. Godkjenning av dagsorden 2. Godkjenning av referat fra forrige veiledermøte 3. Godkjenning av referat fra forrige kundemøte 4. Godkjenning av statusrapport 5. Gjennomgang av vedlagte fasedokumenter 6. Neste møte/videre gang 7. Eventuelt Vedlegg Referat fra veiledermøte Dato: Tid: Sted: Møteleder: Referent: Tilstede Fra gruppa Fra fagstaben Forfall Agenda 1. Godkjenning av dagsorden 2. Godkjenning av møtereferat fra forrige veiledermøte 3. Godkjenning av møtereferat fra forrige kundemøte 4. Godkjenning av statusrapport 5. Gjennomgang av vedlagte fasedokumenter 6. Neste møte/videre gang 7. Eventuelt 39

46 VEDLEGG C. MALER Innkallelse til kundemøte Dato: Tid: Sted: Til Kunde Jørgen Austvik Gruppe Jørn Ole Skaaraas Paul Christian Sandal Håvard Mork Geir Øyvin Grimnes Tarjei Lægreid Andreas Mathias Berg Hjelpeveileder Gunn-Marie Navestad Kopi til Agenda 1. Godkjenning av dagsorden 2. Godkjenning av referat fra forrige kundemøte 3. Punkter fra agenda i møteinnkallelse 4. Neste møte/videre gang 5. Eventuelt Vedlegg Referat fra kundemøte Dato: Tid: Sted: Møteleder: Referent: Tilstede Fra kunden: Fra gruppen Fra fagstaben Forfall Agenda 1. Godkjenning av dagsorden 2. Godkjenning av møtereferat fra forrige kundemøte 3. Punkter fra agenda i møteinnkallelse 4. Neste møte / videre gang 5. Eventuelt 40

47 VEDLEGG C. MALER Skjema for timeregistrering Figur C.1: Timeregistreringsskjema 41

48 42 VEDLEGG C. MALER

49 Vedlegg D Gantt-diagrammer 43

50 D.1. GANTT-DIAGRAMMER VEDLEGG D. GANTT-DIAGRAMMER D.1 Gantt-diagram ved oppstart av prosjektet ID Fase/Milepæl Varighet Startdato Sluttdato Ansvarlig 1 Prosjektledelse 63 days Tue Thu September October November Forelesninger og selvstudium 63 days Tue Thu Planlegging 6 days Wed Wed Prosjektdirektiv ferdig 0 days Fri Fri Geir-Øyvin Forstudie 13 days Wed Fri Prosjektet avgrenset 0 days Fri Fri Jørn Ole Kravspesifikasjon 12 days Mon Tue Krav innhentet av kunde 0 days Wed Wed Andreas Konstruksjon 9 days Fri Wed Testplan Ferdig 0 days Thu Thu Paul Implementasjon 11 days Wed Wed Dokumentasjon 15 days Wed Tue Programmering ferdig 0 days Mon Mon Håvard Testing 4 days Thu Tue Prelev. forstudium og kravspek 0 days Mon Mon Tarjei Evaluering 3 days Wed Fri Presentasjon og demonstrasjon 5 days Fri Thu Prosjekt Avsluttet 0 days Thu Thu Jørn Ole Project: Prosjektplan Date: Mon Task Split Progress Milestone Summary Project Summary External Tasks External Milestone Deadline Page 1 Figur D.1: Gantt-diagram for prosjektet ved oppstart 44

51 VEDLEGG D. GANTT-DIAGRAMMER D.2. GANTT-DIAGRAMMER D.2 Gantt-diagram ved avslutning av prosjektet ID Fase/Milepæl Varighet Startdato Sluttdato Ansvarlig 1 Prosjektledelse 63 days Tue Thu September October November Forelesninger og selvstudium 63 days Tue Thu Planlegging 8 days Tue Thu Prosjektdirektiv ferdig 0 days Fri Fri Geir-Øyvin Forstudie 13 days Wed Fri Prosjektet avgrenset 0 days Fri Fri Jørn Ole Kravspesifikasjon 16 days Mon Mon Krav innhentet av kunde 0 days Wed Wed Andreas Konstruksjon 19 days Fri Wed Testplan Ferdig 0 days Thu Thu Paul Implementasjon 15 days Wed Tue Dokumentasjon 19 days Wed Mon Programmering ferdig 0 days Tue Tue Håvard Testing 7 days Thu Fri Prelev. forstudium og kravspek 0 days Mon Mon Tarjei Evaluering 3 days Wed Sun Presentasjon og demonstrasjon 5 days Fri Thu Prosjekt Avsluttet 0 days Thu Thu Jørn Ole Project: Prosjektplan Date: Mon Task Split Progress Milestone Summary Project Summary External Tasks External Milestone Deadline Page 1 Figur D.2: Oppdatert Gantt-diagram ved prosjektets avslutning 45

52 D.2. GANTT-DIAGRAMMER VEDLEGG D. GANTT-DIAGRAMMER 46

53 Vedlegg E Risikoplan Dette vedlegget omfatter risikoplanen for prosjektet. For hver risiko er det beskrevet konsekvens, sannsynlighet (S), strategi/tiltak, tidsfrist og ansvar. 47

54 VEDLEGG E. RISIKOPLAN Nr Aktivitet Risiko Konsekvens S Strategi/tiltak Tidsfrist Ansvar Alle 1 Implementasjon For høy teknisk kompleksitet av valgt løsning. 3 Forstudie Finner ikke noen god ontologi utviklet for helsevesenet. 4 Alle Tekniske problemer 5 Alle Problemer i samarbeidet med kunde. 6 Alle Kunde forstår ikke kravspesifikasjon. Høy arbeidsbelastning på gruppa. Oppgavene blir ikke gjort innen tidsfrist Ontologien må lages av prosjektgruppa. Tap av data (dokumenter, kode etc.) Vanskelig å bli enige om implementasjon av løsning eller kunden er usikker hva han trenger. Gruppens og kundens oppfatning av punkter i kravspesifikasjonen er ulik. L Proaktivt: Gjøre grundig arbeid i planleggingsfasen. Spørre veiledere om hvor teknisk vanskelige løsninger vil være. Reaktivt: Redusere krav til løsning i samråd med kunden. M Proaktivt: Avklare alle utenomfaglige aktiviteter i arbeidstiden på forhånd. Reaktivt: Endre plan, se om det er mulig å jobbe på alternative tidspunkter. M Proaktivt: Sette fokus på å få tak i dette tidlig i forstudiefasen. Reaktivt: Bruke/Lage en standard ontologi, ikke utviklet for helsevesenet. H Proaktivt: Ha gode backuprutiner (automatisk backup 1 gang i døgnet).. VersjonsKontinuer-ligroll for å hindre at endringer blir overskrevet. Reaktivt: Lære av hendelsen. Forbedre rutiner. L Proaktivt: Ikke overraske kunden. Alle møter må være godt planlagt i forveien. Reaktivt: Prøve å få med veiledere i dialogen, få inn ekstern hjelp i prosjektet. M Proaktivt: Gå svært nøye gjennom kravspesifikasjon med kunde for å oppklare eventuelle tvetydigheter. Reaktivt: Få klarhet i problemet så raskt som mulig, og gå gjennom kravspesifikasjon på nytt for å identifiserer eventuelle andre misforståelser. Kontinuerlig 2 Alle Konkurrerende aktiviteter reduserer tilgjengelig tid for prosjektarbeid Kontinuerlig Innen avslutning av forstudiet. Kontinuerlig Alle Alle Alle Kontinuerlig Prosjektleder, Kundekontakt Innen avslutning av kravspesifikasjon. Kundekontakt 48

55 VEDLEGG E. RISIKOPLAN Nr Aktivitet Risiko Konsekvens S Strategi/tiltak Tidsfrist Ansvar 7 Alle Sykdom Mer jobb på de andre i gruppa. Vanskeligere å overholde tidsfrister. 8 Alle Teknologisk risiko. 9 Alle Problemer med ytelse i søk. 10 Alle Interne stridigheter i gruppa. En implementert løsning kan stille urimelige krav for installering og bruk, eller kan kreve spesiell maskin- /programvare. Implementert løsning kan vise seg i ettertid å skalere dårlig til store datamengder og gi uønskelig store ventetider for brukeren. Stridighet kan hindre fremdrift i prosjektet, og skape dårlig klima innad i gruppa. M Proaktivt: Alt arbeid skal finnes et sentralt sted, slik at det er mulig for andre å overta et arbeid fra det fraværende gruppemedlemmet. Reaktivt: Omfordele arbeid til flere personer. L Proaktivt: Foreta grundig analyse av mulige realiseringsplattformer og gjøre praktiske eksperimenter med disse. Reaktivt: Vurdere å kode om programmer i ny plattform, eller redusere størrelsen av problemet med eksperthjelp. L Proaktivt: Være forsiktig med å stille konkrete krav til funksjonaliteten til søkealgoritmen. Hold den modulær med klart definerte grensesnitt. Reaktivt: Vurdere om realisering i annen omgivelse kan redusere problemet. Redusere krav til søket i samråd med kunde. L Proaktivt: Forsøke å løse konflikter på et tidlig stadium. Prosjektdeltakerne må komme med konstruktive tilbakemeldinger, og si ifra tidlig hvis en føler noe er galt. Reaktivt: Megling mellom partene. I verste fall fjerne en prosjektdeltaker hvis problemet ikke løser seg. Innen avslutning av forstudiet. Innen avslutning av forstudiet. Kontinuerlig Kontinuerlig Prosjektleder Prosjektleder Prosjektleder Alle Tabell E.1: Risikotabell for prosjektet 49

56 50 VEDLEGG E. RISIKOPLAN

57 Tabeller 2.1 Rammebetingelser for prosjektet Planleggingsfasen - ansvarsfordeling Forstudiefasen - ansvarsfordeling Kravspesifikasjonsfasen - ansvarsfordeling Konstruksjonsfasen - ansvarsfordeling Implementasjonsfasen - ansvarsfordeling Testfasen - ansvarsfordeling Dokumentasjonsfasen - ansvarsfordeling Evalueringsfasen - ansvarsfordeling Presentasjonsfasen - ansvarsfordeling Estimert ressursbruk per fase Rollefordeling E.1 Risikotabell for prosjektet

58 TABELLER TABELLER 52

59 Figurer 3.1 Vannfallsmodell over fasene i prosjektet Gruppa bruker en linjeformet organisasjonsstruktur i prosjektet Filorganisering C.1 Timeregistreringsskjema D.1 Gantt-diagram for prosjektet ved oppstart D.2 Oppdatert Gantt-diagram ved prosjektets avslutning

60 FIGURER FIGURER 54

61 Del II Forstudium 55

62

63 Innhold 1 Innledning Hensikt Omfang Definisjoner Struktur Dagens situasjon Om Extend Mål Strategi EQS overblikk EQS Content Roller og personifisering Bruksområder og funksjonalitet Fleksibilitet EQS Process EQS Feedback Bruksområder og funksjonalitet Fleksibilitet EQS Balansert målstyring EQS Public Målgrupper for EQS Informasjongjenfinning i EQS Relaterte dokumenter Navigering i kategoriene Søk Utfordringer/svakheter ved dagens søk

64 INNHOLD INNHOLD 3 Ønsket situasjon Forbedret brukergrensesnitt Bruk av ontologi Metainformasjon Evalueringskriterier Brukergrensesnitt Standarder Omgivelse Søkealgoritmer Ontologier og semantisk web Ontologi Bruksområder for ontologier Semantisk Web Ontologistandarder XML RDF Subjekt, predikat og objekt RDFS (RDF Schema) Objekt som ressurs Kjerneklasser og egenskaper i RDF Begrensninger ved RDF Schema OIL Bakgrunn Beskrivelse av OIL DAML Bakgrunn Beskrivelse av DAML Likheter mellom OIL og DAML Forskjeller mellom OIL og DAML OWL

65 INNHOLD INNHOLD OWL Full OWL DL (Description Logic) OWL Lite Sammenlikning av OWL-artene Sammenheng mellom OWL og RDF Sammendrag Markedsundersøkelse Medisinske ontologier MeSH SNOMED UMLS PubMED OpenGALEN LinKBase Ontologiverktøy Protégé OntoEdit LinKFactory Søkealgoritmer Mulige krav til søk Boolsk søk Søkealg. basert på vektorrom QR og SVD-faktorisering Relasjon til ontologier Generelle betraktninger Søk i bare ontologi Søk etter hyppige ord i dokumenter Autorativ ontologi med synonymer Vektorsøk med domenespesifikke indekser Ontologi for gruppering av søkeresultater Implementasjonskostnader

66 INNHOLD INNHOLD Lagringsteknikker Sammendrag Generering av ontologi Ønskede virkninger Optimaliseringstekn Stemming Stoppord Valg av viktige ord Andre statistiske metoder Testprogram Testresultat Sammendrag Brukergrensesnitt Utfordringer BG Spesifisering av søk Presentasjon av søkeresultat Dagens system Spesifisering av søk Visning av søkeresultat Nytt system Utfordringer ontologisøk Mulige løsninger Løsning 1 - Standardsøk Løsning 2 - Kategorisøk Løsning 3 - Navigering i søkeresultat med rammer Sammmendrag

67 INNHOLD INNHOLD 11 Omgivelser Introduksjon Overordnede krav Splitting av funk Sikkerhet Secure Socets Layer (SSL) Secure HTTP (HTTPS) Omgivelse Java 2 Platform Enterprise Edition (J2EE) Microsoft.NET J2EE vs.net Nettsideteknologi Ontologigrensesnitt JENA Wonderweb: OWL API Kommersielle alternativer Andre API Sammendrag Valg av løsning/konklusjon Evaluering Vurderinger Skissering A Begrepsordliste 139 B Automatisk generering av ontologi

68 INNHOLD INNHOLD 62

69 Kapittel 1 Innledning Kunden i dette prosjektet, Extend A/S, utvikler kvalitets- og prosesstøttesystem for ulike typer organisasjoner. Extend har bred kompetanse innen utvikling av nettløsninger og områder rundt kvalitetssikring. Extend ønsker ved å engasjere ei gruppe studenter i faget TDT Kundestyrt Prosjekt, å undersøke mulighetene for å utvikle mer avanserte metoder for søk i store datamengder, da primært i helsesystemer. Prosjektet kan karakteriseres som et pilotprosjekt, som skal resultere i en prototyp. 1.1 Hensikt Forstudiet har til hensikt å klargjøre hvilke ønsker og krav kunden har til et nytt system, og hvordan disse ønskene retter seg mot eksisterende teknologi. Forstudiet skal være en felles plattform for forståelse mellom deltakerne i prosjektet og kunden, og skisserer kriterier for valg av ulike tekniske løsninger opp mot kundens situasjon. 1.2 Omfang Gjennom forstudiefasen setter gruppa seg grundig inn i eksisterende teknologier, og skaffer oversikt over hvilke verktøy og teknologier som er tilgjengelige for utviklingen av prosjektet. Forstudiet vil senere være grunnlaget for utviklingen av en kravspesifikasjon. 1.3 Definisjoner En ordliste med forklaringer av ord og definisjoner er presentert i vedlegg A. 63

70 1.4. STRUKTUR KAPITTEL 1. INNLEDNING 1.4 Struktur Dokumentet er delt inn i følgende kapitler: Kapittel 2 beskriver dagens løsning i Extend, sammen med kvalitetsstøttesystemet EQS. Kapittel 3 tar for seg den situasjonen som kunden ser for seg at prototypen utviklet i det kundestyrte prosjektet vil løse. Kapittel 4 presenterer de kriteriene som er satt opp i samråd med kunden, som er grunnlaget for evaluering av ulike teknologier opp mot hverandre. Kapittel 5 gir en oversikt over bruksmåter for ontologier, og ser litt på semantisk web som en mulig utvidelse av dette. Kapittel 6 sammenligner de ulike standardene som finnes for oppbygging av ontologier, sammen med deres styrker og begrensinger. Kapittel 7 omhandler eksisterende løsninger på markedet i dag, hvor tilsvarende problemer er berørt. Kapittel 8 skisserer ulike fremgangsmåter som kan brukes for søk i store datamengder, sammen med hvordan søkemotorer forholder til ontologier. Kapittel 9 beskriver en måte for automatisk generering av ontologier ut fra en dokumentsamling basert på statistiske metoder. Kapittel 10 skisserer ulike grafiske brukergrensesnitt som kan brukes, og sammenligner opplevelsen av disse i bruk i kontekst av helsesystemer. Kapittel 11 gir en oversikt over tekniske aspekter ved implementasjon, programmeringsomgivelser og typer arkitektur. Kapittel 12 oppsummerer viktige bemerkinger i de foregående kapitlene. 64

71 Kapittel 2 Dagens situasjon Dette kapitlet beskriver kvalitets- og prosesstøttesystemet Extend Quality System (EQS) [12], dets funksjonalitet, de ulike modulene, samt systemets styrker og svakheter. Det beskriver også hvordan brukerne finner informasjon i EQS. Målet med kapitlet er å gi en forståelse av dagens system, samt gi en pekepinn på hvilke oppgaver det må jobbes med i prosjektet. 2.1 Om Extend Extend ble etablert i 1996 med utgangspunkt i utvikling og salg av løsninger for WWW (World Wide Web). I 1998 startet de utviklingen av EQS, et fagverktøy for kvalitetsstyring innen helsesektoren. Dette nettside-baserte kvalitetssystemet er i dag bedriftens satsningsområde. Systemet består av flere moduler som kan tilbys etter kundens behov, og er nærmere beskrevet i avsnitt 2.2. EQS er plattformuavhengig, databaseuavhengig, nettleseruavhengig, og er ikke avhengig av tredjeparts programvare. Dette medfører ifølge Extend en svært kostnadseffektiv distribusjon Mål Selskapets mål er at EQS metoden for ledelsesfokusert kvalitetsstyring skal bli internasjonalt anerkjent innen Strategi Extend ønsker å bygge opp partnerrelasjoner som ivaretar salg/distribusjon av EQS. Selskapet har fagkompetanse som driver opplæring av kunder og partnere, og som deltar i innføringsprosjekter hos kundene. 65

72 2.2. EQS OVERBLIKK KAPITTEL 2. DAGENS SITUASJON 2.2 EQS overblikk EQS er en fagapplikasjon for kvalitetssikring- og forbedringsarbeid i alle typer organisasjoner. Systemet er en 100% nettside-basert løsning hvor all funksjonalitet tilbys via en nettleser. Det har også muligheter for tilknytning opp mot andre fagapplikasjoner via standardiserte grensesnitt, og har en lav brukerterskel. Det grafiske brukergrensesnittet til EQS er integrert i form av prosesskart. Prosesskart er grafiske fremstillinger av organisasjonen/bedriftens prosesser, og fungerer som lenker til andre prosesskart, dokumenter og skjemaer som er definert i EQS. Man kan også ha lenker til andre dokumenter i et dokument. EQS skal gi hele den tilknyttede organisasjonen muligheten til å øke kvaliteten på eget arbeid, samt styrke og kvalitetssikre eksterne leveransekjeder. For å sikre ulike kunders behov er EQS bygd opp av moduler som kan leveres etter en trappetrinnmodell. På denne måten kan det skreddersys et system etter krav fra kunden. Figur 2.1 viser velkomstbildet i en demo av EQS. 2.3 EQS Content Content-modulen, som er grunnstammen i EQS systemet, er et nettside-basert forvaltningssystem for styrende dokumenter. Styrende dokumenter er dokumenter som beskriver hvordan organisasjoner skal arbeide, for eksempel hvordan ulike prosedyrer skal utføres. Disse dokumentene brukes ofte som basis for sertifisering innen for eksempel ISO-9000 [1] serien. Eksempler på styrende domumenter som kunder har i EQS Content: Økonomiske rutiner Rutiner for behandling av pasienter Passordrutiner Kodestandarder Extend har valgt å gi Content-modulen undertittelen Fra perm til skjermer [9], da modulen er utviklet for å flytte organisasjoners/bedrifters kvalitetssystem fra papirform til elektronisk format Roller og personifisering Samtlige brukere får tildelt roller i systemet. Rollene avgjør hvilke rettigheter, ansvar og oppgaver brukeren har i EQS Content. Hver enkelt bruker kan sette opp sin egen startside for å forenkle sine arbeidsoppgaver. 66

73 KAPITTEL 2. DAGENS SITUASJON 2.3. EQS CONTENT Figur 2.1: EQS-demo grensesnitt Bruksområder og funksjonalitet Dokumentadministrasjon i EQS er lagt opp slik at eieren av et dokument automatisk får ansvaret med å revidere og oppdatere det gjeldende dokumentet. Alle dokumenter i systemet må godkjennes av en overordnet. Ansvarsforholdet for oppdatering og godkjenning er derfor klart definert, samtidig som at rett dokument alltid er tilgjengelig for rett person. Ettersom distribusjonen av dokumentene skjer til hele organisasjonen i det øyeblikk dokumentene blir godkjent, vil hele distribusjonsprosessen av viktige dokumenter være rask, nøyaktig og pålitelig. Samtidig sikrer man at siste godkjente versjon alltid er tilgjengelig. For å sikre tilgjenglighet, er alle dokumenter i systemet indekserte og søkbare. Dokumentene i systemet kan også lenkes opp mot overordnede nasjonale og internasjonale bestemmelser via Internett. Historikken til dokumenter og prosesskart blir bevart i EQS. Alle tidligere versjoner av dokumenter er lagret og tilgjengelig ved behov. Dersom et avvik relatert til et dokument oppdages, kan dette enkelt rapporteres på en sikker og effektiv måte via en 67

74 2.4. EQS PROCESS KAPITTEL 2. DAGENS SITUASJON elektronisk beskjed Fleksibilitet Dokumentene som er definert i EQS kan enten være importerte Microsoft Word-dokumenter, eller man kan bruke EQS Contents egen editor for å bygge dokumenter i et Word-lignende grensesnitt. Kunden har muligheter til selv å definere organisasjonsstrukturen den ønsker å knytte de ulike dokumentene til, samtidig som kunden selv kan bygge opp dokumentkategorier etter organisasjonens struktur. 2.4 EQS Process EQS Process er en tilleggsmodul i EQS systemet. EQS Process lar brukerne tegne og behandle prosesskart. Disse brukes til å navigere i kvalitetssystemet. Prosesskart er underlagt det samme regimet som andre dokumenter i EQS, men har en egen Java-basert editor som gjør det mulig å tegne prosesskart. Hvert element i et prosesskart (boks, pil etc.) kan knyttes til ett eller flere objekter i eller utenfor EQS som en lenke. Noen eksempler er: Dokumenter Dokumentkategorier URL - Unified Resource Locator Skjema Rapporter Vedlegg (opplasting av binærfiler) Prosesskart skal fortelle hvordan prosessene i en bedrift skal gjennomføres. En ansatt skal kunne se at denne boksen er meg, og finne sin rolle i den store sammenhengen. I tillegg kan den ansatte få oversikt på et mer detaljert nivå over egen og andres prosesser. Ved at dokumenter knyttes til elementer (kan være prosesser) i prosesskartet, gjør man det mulig å navigere mellom prosesskart ved å trykke i dem. EQS Process er en prosesskarteditor, men også en bit av visningsdelen i EQS. Figur 2.2 viser grensesnittet til prosesseditoren i EQS Process 2.5 EQS Feedback EQS Feedback [10] er en tilleggsmodul til EQS Content som håndterer meldinger innad i systemet. Dette kan for eksempel være tilbakemeldinger på dokumenter eller avanserte avviksmeldinger. Alle brukere av systemet har muligheten til å bidra med meldinger uten å benytte annet enn en nettleser. 68

75 KAPITTEL 2. DAGENS SITUASJON 2.5. EQS FEEDBACK Figur 2.2: EQS Process prosesseditor Bruksområder og funksjonalitet Meldinger er grunnlaget for rapportering og forbedring av kvalitetsarbeid. EQS Feedback gir alle brukere av systemet mulighet til å registrere meldinger på en enkel og sikker måte. Meldinger vil aldri gå tapt, og de sendes til riktig mottaker. Mottakeren av en melding vil alltid ha et tilpasset sett verktøy tilgjengelig, som gjør at han kan behandle meldingen videre. Med EQS Feedback blir avviksbehandlingen en integrert del av kvalitetssystemet, og avvik kan relateres til eksisterende kvalitetsdokumenter og prosedyrer. Systemet skiller mellom ulike typer meldinger, og disse kan håndteres ulikt Fleksibilitet Ved at EQS skiller mellom de ulike meldingstypene sørger man for at brukeren ikke misforstår meldingen. Dette fordi ulike meldingstyper får ulike verktøy og ulik arbeidsflyt. Kunden kan selv definere organisasjonsstrukturen den ønsker å behandle meldinger etter. Feedbackmodulen sørger også for enkel deling av informasjon da den åpner for effektiv 69

76 2.5. EQS FEEDBACK KAPITTEL 2. DAGENS SITUASJON samhandling mellom enheter. Feedback har støtte for å samhandle informasjon med eksterne aktører. Det sørger også for ressursbesparing, samt lettere tilgjengelighet for bruk av meldinger. Ressursbesparing oppnås fordi registrering og behandling av meldinger går raskt og effektiv samtidig som distribusjonsleddet blir effektivisert. Lettere tilgjengelighet oppnås fordi tilgangen til å sende meldinger vil øke, noe som fører til økt bruk. Feedback har også muligheter for å aggregere statistikk og rapporter som kan være nyttig som ledelsesinformasjon. Denne informasjonen kan presenteres i EQS Content [10]. Figur 2.3 viser eksempel på representasjon av stolpediagram i EQS. Figur 2.3: Eksempel på representasjon av statistikk i EQS. 70

77 KAPITTEL 2. DAGENS SITUASJON 2.6. EQS BALANSERT MÅLSTYRING 2.6 EQS Balansert målstyring EQS Balansert målstyring (BMS) [11] (eng: balanced scorecard) er en tilleggsmodul i EQS systemet. Balanced scorecard defineres i [23] som a management system (not only a measurement system) that enables organizations to clarify their vision and strategy and translate them into action. It provides feedback around both the internal business processes and external outcomes in order to continuously improve strategic performance and results. For å støtte dette har Extend utvidet EQS sin funksjonalitet på presentasjoner av aggregering og nøkkeltall basert på innsamlede data. Dette gir igjen utvidet funksjonalitet på statistikkrapporter og prosesskart. 2.7 EQS Public EQS Public er en tilleggsmodul i EQS systemet. EQS Public gjør hele eller deler av det interne kvalitetssystemet tilgjengelig for eksterne aktører, som ikke har tilgang til EQS applikasjonen, via for eksempel Internett. De data som blir eksportert til eksterne aktører er i statisk HTML-format og kan på den måten enkelt gjøres tilgjengelig på et eksisterende nettsted eller CD-ROM. EQS Public består av flere nivåer med kvalitetssikring for hva som ender opp som eksporterte data. 2.8 Målgrupper for EQS Målgruppene som EQS retter seg mot per dags dato er helsesektoren, fylkeskommuner, kommuner, bedrifter og store organisasjoner. EQS er tilpasset behovet større organisasjoner har for å ivareta kvalitet i leveranseprosessen mellom kunde og leverandør. Eksempler her er outsourcing av IT-drift eller andre omfattende avtaler. EQS er også godt tilpasset kunder med et vidt spekter av antall brukere. Alt fra mindre organisasjoner med få brukere til store bedrifter med flere tusen brukere kan gjøre nytte av systemet. 2.9 Informasjongjenfinning i EQS Dette avsnittet tar for seg hvordan brukere navigerer i EQS for å finne den informasjonen de leter etter. Avsnittet er basert på erfaringer Extend har gjort med sine kunder Relaterte dokumenter Dokumenter kan være relaterte til hverandre. For eksempel kan en passordrutine være relatert til en passordliste. Brukerne kan navigere mellom relaterte dokumenter ved hjelp av: 71

78 2.9. INFORMASJONGJENFINNING I EQS KAPITTEL 2. DAGENS SITUASJON Prosesskart. Dette er grafiske fremstillinger av organisasjonen/bedriftens ulike jobber. Disse kan benyttes til å navigere i dokumentsamlingen. Dersom et prosesskart legges inn i det eneste dokumentet i dokumentkategorien eller på enhetens dokumenter vil det vises ekspandert, slik at man kan velge å navigere kun basert på prosesskart dersom man ønsker det. Dokumentlenker. Nytt i EQS versjon 3.0 er en måte å legge inn lenker til andre dokumenter som blir trykkbare i selve dokumentet, og som alltid går mot riktig revisjon av et dokument i EQS. Dersom dokumentet ikke finnes lenger (ingen gyldig revisjon) vil dette fremgå Navigering i kategoriene Administratorer i EQS kan sette opp kategorier (mapper) med dokumenter i et hierarki. Dette er svært likt filer og kataloger i et vanlig system som for eksempel Microsoft Windows. Man kan sette en tilgangskontroll på kategoriene, slik at noen av kategoriene kun vises for enkelte enheter/grupper. Ulempen med kategoriene er at de ofte gjenspeiler hvordan administratoren (ofte kvalitetsansvarlig) tenker på kvalitetssystemet, mens andre som benytter systemet kan ha en helt annen oppfatning av hva den logiske organiseringen er. Figur 2.4 viser navigering i kategori-treet i en demo av EQS. 72

79 KAPITTEL 2. DAGENS SITUASJON 2.9. INFORMASJONGJENFINNING I EQS Figur 2.4: Navigering i kategori-treet i en demo av EQS. (Venstre marg) Søk Dette avsnittet tar for seg søkemulighetene i dagens EQS system. Figur 2.5 viser søkeresultat i en demo av EQS. Det skilles mellom to typer søk: Enkelt søk lar brukeren skrive inn søkeord, og søker i dokumenter som er lett tilgjengelig for brukeren (laget for den enheten/gruppa brukeren tilhører) Dette er ofte den raskeste måten å finne et dokument på i EQS. Brukeren skriver inn et par ord fra tittelen eller teksten og får opp en liste med dokumenter som inneholder treff. Avansert søk fungerer som enkelt søk. Forskjellen er at brukeren søker i et bestemt utvalg dokumenter, samt dokumenter fra andre enheter enn den brukeren tilhører. 73

80 2.9. INFORMASJONGJENFINNING I EQS KAPITTEL 2. DAGENS SITUASJON Figur 2.5: Søkeresultat etter ordet kanyle i en demo av EQS Utfordringer/svakheter ved dagens søk Brukere av EQS har påpekt følgende svakheter ved søkefunksjonen i EQS: Nøkkelord Brukerne av EQS ønsker å kunne knytte nøkkelord til dokumenter som ikke nødvendigvis finnes i dokumentet. Stoppord Man tar ikke hensyn til stoppord i dagens søk. (Med stoppord menes generelle ord som binder sammen språket, og som dermed ikke sier noe om det semantiske innholdet i dokumentet) Fjerning av stoppord vil kunne øke ytelsen på søket. Stoppordene vil kunne variere fra domene til domene, og bør være i en liste som brukere vil få tilgang til å redigere. Synonymer Synonymer er svært viktige i helsevesenet da norske og latinske navn kan brukes om hverandre. Mapping mellom norske og latinske ord vil være en fordel da man 74

81 KAPITTEL 2. DAGENS SITUASJON 2.9. INFORMASJONGJENFINNING I EQS slipper å legge inn både norske og latinske nøkkelord. Hierarkier/sammenhenger I dagens system finnes det ingen hierarkier/sammenhenger mellom ord, som for eksempel at øret er en del av hodet. Presentasjon av søkeresultat I dagens system er det ikke muligheter for å kunne gå tilbake til søkeresultatet etter at man har åpnet et dokument. Dette kan løses ved å åpne lenker fra søkeresultatene i et nytt vindu i nettleseren. Søk i mer enn bare dokumenter Dagens system har bare støtte for søk i dokumenter. Det burde også hatt støtte for søk i for eksempel: Dokumentkategorier Skjema Personer Grupper Søk i forskjellige sett dokumenter Dagens søk fungerer bare på godkjente dokumenter. Brukere har gitt tilbakemelding på at de også ønsker å søke i dokumenter som er under utarbeidelse. 75

82 2.9. INFORMASJONGJENFINNING I EQS KAPITTEL 2. DAGENS SITUASJON 76

83 Kapittel 3 Ønsket situasjon Dette prototypprosjektet blir gjennomført for å undersøke muligheten for å forbedre søkealgoritmer og brukergrensesnitt for søk i kunnskapsdatabaser, med det håp å kunne gjøre brukerens opplevelse av systemet bedre. Dette kapitlet tar for seg de overordnede målene for et nytt system, sammen med de virkninger som forsøkes oppnådd med dem. Det er viktig å presisere at Extend stiller få krav til valg av løsning for dette prosjektet. Målet er en prototyp som undersøker potensielle forbedringer av det nåværende systemet, ved å bruke ontologier. Vinklingen i prosjektet er mye opp til prosjektgruppa selv å avgjøre, innenfor grensene satt opp av oppgavebeskrivelsen, prosjektets tidsramme og kundens retningslinjer. 3.1 Forbedret brukergrensesnitt En av de elementene som Extend mener det er aktuelt å vurdere i en prototypimplementasjon, er hvorvidt en annen utforming av brukergrensesnitt kan bidra til økt tilfredsstillelse for kunden og aksept av informasjonssystemet. Det er viktig å fokusere på kundens egne arbeidsrutiner. 3.2 Bruk av ontologi Extend ønsker med prototypprosjektet å undersøke hvorvidt bruk av domenespesifikke ontologier kan bedre søkeresultatene, og sammen med et tilrettelagt brukergrensesnitt bidra til å gjøre informasjonsgjenfinning raskere. I tillegg til bruk av ontologi, er det også aktuelt å berøre emner som hierarkier og sammenhenger, stoppord og synonymer. 77

84 3.3. METAINFORMASJON KAPITTEL 3. ØNSKET SITUASJON 3.3 Tilordning av metainformasjon Metoder og arkitekturer for tilordning av metainformasjon til dokumenter kan vurderes utprøvd i en prototyp. Metainformasjonen kan her komme i form av nøkkelord eller andre oppsummeringer. Nøkkelord kan for eksempel bli forsøkt automatisk hentet ut av dokumenter og senere redigeres manuelt. 78

85 Kapittel 4 Evalueringskriterier I dette kapitlet presenteres de kriteriene til systemet som er basis for forstudiumsfasen og valg av løsning. Kriteriene er satt opp i samarbeid med kunden, og er grunnlaget for evaluering av alternative løsninger. Da dette prosjektet skal resultere i en prototyp, og ikke et ferdig produkt, er det noen av kriteriene som blir mindre vektet her enn del ville ha blitt hvis et ferdig produkt skulle utvikles, og dette er markert på de punktene det er aktuelt. 4.1 Brukergrensesnitt God effektivitet for brukeren (valgfritt). Bør være enkelt å navigere i (valgfritt). Grensesnittet skal følge de widgetstandarder som eksisterer på WWW for å gi gjenkjenningsverdi for brukeren. Systemet skal opplyse brukeren om semantiske sammenhenger, og skal gi mulighet til å kunne bruke disse. 4.2 Standarder Fremtidsrettet, og/eller svært egnet standard (begrenset viktighet). Standarder som velges må være tilpasset oppgavedomenet. Skalerbarhet og utvidbarhet. Åpne standarder. 4.3 Implementasjonsomgivelse Open Source (begrenset viktighet). Nettsidebasert. 79

86 4.4. SØKEALGORITMER KAPITTEL 4. EVALUERINGSKRITERIER Nettleseruavhengig (valgfritt for prototypen). Databaseuavhengig (valgfritt for prototypen). Plattformuavhengig (valgfritt for prototypen). Standardisert API-grensesnitt mot lasting/behandling av ontologier. 4.4 Søkealgoritmer Algoritmen bør teoretisk sett ha best mulig recall og precision, hvis dette gir bedre brukertilfredshet. Algoritmen bør ha gode muligheter for å tilpasses bestemte bruksmåter. Søkeresultater bør ikke være bundet til å inneholde alle søketermene, men vekte basert på det (valgfritt). Bør skalere bra i forhold til antall dokumenter og antall ord. Søk bør utføres på mindre enn fire sekunder ved treff på 10 av 2000 dokumenter. 80

87 Kapittel 5 Ontologier og semantisk web Dette kapitlet beskriver generelt ontologibegrepet og preseneter tankene bak semantisk web. 5.1 Ontologi Begrepet ontologi stammer fra det gamle Hellas. Aristoteles beskrev ontologi som læren om å være med hensyn på at du er. Hva eksisterer?, Hva er?, Hva er jeg?, Hva beskriver dette for meg?, er alle eksempler på spørsmål rundt det å være. De beskriver det mest grunnleggende for ontologien som lære. Denne måten å beskrive eksistens har gitt opphav til ontologibegrepet også innen fagfeltet Informasjonsteknologi. En ontologi blir her brukt som en datastrukutur som definerer begreper, og relasjoner mellom begreper, innen et gitt domene. Den fungerer som et strukturert, semantisk leksikon over de termene som brukes innenfor domenet. For små domener kan ontologier være på bare noen få hundre begreper. I større domener, som for eksempel pasientjournaler og netthandel, vil en ontologi kunne inneholde flere tusen begreper. De fleste ontologier [31] er bygget opp av klasser. Klassene beskriver begrepene i domenet. Et klassisk eksempel er en klasse viner som representerer alle viner. Forskjellige viner er instanser av denne klassen. Et glass med Bordeaux vin er en instans av klassen Bordeaux vin. En klasse kan ha subklasser som representerer begrepene som er mer spesifikke enn superklassen. Man kan for eksempel dele klassene av vin inn i rød, hvit og róse vin. Alternativt kan man dele alle viner inn i klassene musserende og ikke-musserende viner Bruksområder for ontologier Ontologier brukes blant annet til å: 81

88 5.2. SEMANTISK WEB KAPITTEL 5. ONTOLOGIER OG SEMANTISK WEB Effektivisere søking i store dokumentbaser: Ved å støtte søket på en ontologi kan søket oppføre seg mer intelligent. Dette ved at relasjonene en ontologi er bygget opp av brukes i tillegg til bare å søke på begrepet. Gjenbruke kunnskap om domener: Dersom noen lager en ontologi for et domene, kan denne ontologien brukes til å bygge ut en annen ontologi. Hvis det skal bygges en stor ontologi over mange domener, kan ontologier for underdomener flettes inn i hovedontologien. Å bygge opp en ontologi kan minne om å bygge et objektorientert program, men det er likevel en vesentlig forskjell. Klasser og objekter i et program omhandler datastrukturer. Klasser og objekter i en ontologi omhandler begrep i den virkelige verden. Samtidig er det ofte samsvar mellom datastrukturer i dataprogram og definisjoner i en ontologi [20]. 5.2 Semantisk Web WWW er i stor grad basert på mennesker som brukere av systemet. Maskiner har i utgangspunktet ingen evne til å ressonere: nettlesere, nettsidetjenere og søkemotorer klarer ikke å skille værmeldingen fra vitenskapelige rapporter, og kan ikke skille innholdet i en personlig nettside fra en til et stort selskap. Denne manglende evnen til å prosessere innholdet i informasjon hemmer funksjonaliteten på dagens Internett. Datamaskiners funksjonalitet er i hovedsak å overføre data og presentere det som informasjon på nettsider. Mulighetene til å prosessere og tolke informasjonen er begrenset. Visjonen bak semantisk web er å lage et Internett der både maskiner og mennesker forstår informasjonen. Dette krever at informasjonen representeres strukturert nok til at også maskiner kan få tilgang til semantikken. For å forbedre utnyttelsen av de mulighetene som finnes på Internett, må metadata (semantisk representasjon) vises eksplisitt for å gjøre dem automatisk prosesserbare. Dette er samme prinsipp som brukes på mange bibliotek-kataloger i dag. Dersom nettsider publiserer sine egne metadata, kan søkemotorer automatisk trekke ut eksplisitt informasjon om innholdet, og bruke dette i søket. Informasjonen kan brukes til å bedre finne det brukeren faktisk er ute etter. For at data skal kunne være automatisk prosesserbar, må man bruke et standardisert format. Dette kan tilbys gjennom bruk av domenespesifikke ontologier. 82

89 Kapittel 6 Ontologistandarder Dette kapitlet presenterer ulike standarder for oppbygging av ontologier. Ettersom feltet er svært omfattende, velges det her kun å gå inn på de største og mest brukte, mens mindre standarder nedprioriteres. 6.1 XML (Extensible Markup Language) XML har utviklet seg til å bli en dominerende utvekslingsmekanisme på nett. XML kan sees som et sett regler for design av entydige format og strukturering av data. Ved bruk av merkelapper (en: tags) defineres ønsket struktur. Hvordan innholdet i de ulike merkelappene tolkes er opp til applikasjonen som leser XML-filen. Det eksisterer standardmåter å gjøre spørringer, lenke sammen og analysere XML-dokument. Dette gjør det enkelt å generere og lese data i XML [26]. 6.2 RDF (Resource Description Framework) En av de viktigste standardene for å beskrive semantisk web er RDF, utviklet av World Wide Web Consortium (W3C [14]). RDF er et XML-basert språk. Det er primært utviklet for å representere metadata om ressurser som kan identifiseres på Internett. RDF tilbyr et felles rammeverk for å uttrykke denne informasjonen eksplisitt, slik at den kan utveksles av applikasjoner uten tap av mening. Informasjonen kodes som et sett utsagn om ressursen ved hjelp av RDF-tripler. Et RDF-trippel er satt sammen av et subjekt, et predikat og et objekt. Trippelet uttrykker at det eksisterer en relasjon mellom subjektet og objektet. Relasjonen indikeres av predikatet. Et slikt trippel kan sees som en enkel graf. Figur 6.1 viser en slik graf [15] Subjekt, predikat og objekt Subjektet identifiserer ressursen som beskrives. Alt som kan identifiseres unikt (som har en URI (Unified Resource Identifier)) kan kalles en ressurs. En ressurs har egenskaper som i 83

90 6.2. RDF KAPITTEL 6. ONTOLOGISTANDARDER Figur 6.1: RDF-trippel representert som graf modellen identifiseres av et predikat. Predikatet er også representert ved en URI, dette for å sikre entydighet. På denne måten kan også egenskaper tilegnes prediktater. Et objekt kan være en tekststreng eller en ny ressurs. Et eksempel er setningen: Designeren av nettsiden er Nils. Subjektet er her representert ved URIen Designer er predikat og Nils er objekt. Figur 6.2 illustrerer et eksempel på dette. Figur 6.2: Eksempel på dekoding av ressurs RDFS (RDF Schema) I figur 6.2 er predikatet Designer. Men hva er egentlig en designer? Ofte er det av interesse også å få vite hvilken betydning som legges i et predikat. Mest sannsynlig eksisterer ulike definisjoner for samme begrep, og ulike mennesker vil tolke begrepets semantikk ulikt. Og viktigere: Hvordan skal maskiner og applikasjoner tolke begreper med et utall definisjoner entydig? RDF [16] tilbyr ingen definisjoner eller oversikt over ords betydning. I stedet kan definisjoner fra eksterne pakker eller ordlister nyttes, såkalte RDF Schema (no: skjema). Ved å la predikatet være en URI som eventuellt henviser til et slikt skjema er problemet med definering av ords betydning løst Objekt som ressurs I eksempelet er objektet en enkel tekststreng, Nils. Men et objekt kan være en ny ressurs med egenskaper og verdier. På denne måten gir modellen mulighet til å bygge nettverk av sammenhenger som enkelt kan utvides. RDF er altså skalerbart. Den enkle oppbyggingen med tripler gjør det også enkelt å søke etter og finne informasjon i RDF-strukturer [15] Kjerneklasser og egenskaper i RDF Tabell 6.1 viser noen av de viktigste klassene og egenskapene i RDF. Type-egenskapen spesifiserer en klasse som eier ressursene. Verdien dens er alltid en nett-ressurs som re- 84

91 KAPITTEL 6. ONTOLOGISTANDARDER 6.2. RDF presenterer klassen. Når en ressurs har en rdf:type egenskap med verdi innen en spesifikk klasse, sier man at ressursen er en instans av den spesifikke klassen. Verdien til en rdf:typeegenskap for en ressurs er en annen ressurs som må være en instans av rdfs:class. Klasser rdfs:resource Alle ting som beskrives i RDF-uttrykk er ressurser og betraktes som instanser av klassen rdfs:resource. rdfs:class Representerer det generiske konseptet av en type eller en kategori, og kan defineres til å representere nesten hva som helst (f. eks: nettsider, mennesker, dokumenter). rdf:property Representerer subsettet av RDF-ressurser som er egenskaper. Egenskaper rdf:type Indikerer at en ressurs er medlem av en klasse, og har all karakteristikken som forventes av medlemmer av denne klassen. rdfs:subclassof Denne egenskapen spesifiserer et subset/superset relasjon mellom klasser. Denne egenskapen er transitiv. rdfs:subpropertyof Dette er en instans av rdf:property som brukes til å spesifisere at en egenskap er en spesialisering av en annen. rdfs:range Brukes til å definere at verdiene til en egenskap er instanser av en eller flere deklarerte klasser rdfs:domain Brukes til å uttrykke at enhver ressurs som har en gitt egenskap er en instans av en eller flere klasser Tabell 6.1: Kjerneklasser og egenskaper i RDF Begrensninger ved RDF Schema RDF og RDFS muliggjør representasjon av noe ontologisk kunnskap. Hovedmodelleringsprimitivene i RDF/RDFS vedrører organiseringen av vokabularer i hierarkier: subklasseog subegenskap-forhold, domener og instanser av klasser. Men andre egenskaper mangler : Lokal rekkevidde for egenskaper: rdfs:range definerer spennvidden for en egenskap, for eksempel spiser, for alle klasser. Men i RDF Schema kan man ikke deklarere spennvidderestriksjoner som gjelder for bare noen klasser. For eksempel kan man ikke si at kuer spiser bare planter, mens andre dyr også spiser kjøtt. 85

92 6.3. OIL KAPITTEL 6. ONTOLOGISTANDARDER Disjunkte klasser: Noen ganger ønsker man at klasser skal være disjunkte (for eksempel mann og kvinne). Men i RDF Schema kan man bare angi subklasse-forhold: kvinne er en subklasse av person. Boolske kombinasjoner av klasser: Noen ganger ønsker man å bygge nye klasser ved å kombinere andre klasser ved hjelp av union, skjæringspunkt og komplement. For eksempel kan man ønske å definere klassen person som disjunkt union av klassene mann og kvinne. Dette er ikke mulig i RDF Schema. Kardinalitetsrestriksjoner: Noen ganger ønsker man å sette restriksjoner på hvor mange ulike verdier en egenskap kan, eller må ha. For eksempel kan man ønske at en person har nøyaktig to foreldre. Dette er også umulig å uttrykke i RDF Schema. Spesielle karakteristikker av egenskaper: Av og til er det nyttig å si at en egenskap er transitiv, unik eller invers av en annen egenskap. Heller ikke dette er mulig i RDF Schema På grunn av de ovennevnte årsakene trenger man et ontologispråk som er større enn RDF Schema. Man trenger altså et språk som har RDFS sine egenskaper, men man trenger også flere, f.eks relasjoner. Men generelt er det slik at desto rikere et språk er, desto mindre effektivt er det å gjøre resonnering. Dermed må man inngå et kompromiss mellom disse to faktorene, for å lage et språk som har god støtte for resonnering og som samtidig har muligheten for å uttrykke store klasser av ontologier og kunnskap. 6.3 OIL (Ontology Inference Layer) Dette avsnittet beskriver ontologistandarden OIL [39] Bakgrunn OIL er designet til å være en representasjon av semantikk av informasjon på Internett, og ble startet i 1999 av European Union programme for Information Society Technologies [25] som en del av deres forskningsprosjekt. OIL er en semantisk web-teknologi som har til hensikt å løse søkbarhetsproblemet, støtte e-handel og muliggjøre kunnskapsstyring. Det er basert på ideer fra beskrivende logikk, rammer (en: frames), XML og RDF Beskrivelse av OIL OIL fremstiller arbeid fra tre forskjellige miljø for å oppnå målet om et generelt markupspråk for semantisk web: Ramme-baserte systemer: har en lang historie innen AI. Deres sentrale modelleringsprimitiver er klasser (rammer) med egenskaper. 86

93 KAPITTEL 6. ONTOLOGISTANDARDER 6.4. DAML Beskrivende logikk: er utviklet i forskning innen kunnskapsrepresentasjon, og beskriver kunnskap i termer av konsepter (som kan sammenlignes med klasser) og roller (kan sammenlignes med egenskaper i ramme-systemer). Et viktig aspekt med beskrivende logikk er at den kan beskrives på en matematisk korrekt måte. OIL bruker den formelle semantikken som finnes i beskrivende logikk, noe som muliggjør effektiv bevis-støtte. Standarder: XML og RDF. I tillegg til modelleringsprimitiver (ramme-systemer) og deres semantikk (beskrivende logikk), trenger man en syntaks for markup-språket for semantisk web. OIL har definert syntaks i XML, basert på RDF og XML schema definisjonen. OIL har også definert syntaks som en utvidelse av RDF og RDF schema. RDF schema tilbyr to viktige bidrag: et standard sett av modelleringsprimitiver (som instance-of og subclass-of forhold), og en standardisert syntaks for å skrive klasse-hierarkier. 6.4 DAML (DARPA Agent Markup Language) Avsnittet tar for seg DAML [17], en ontologistandard som på mange måter kan sidestilles med OIL Bakgrunn Omtrent samtidig som OIL ble utviklet, startet utviklingen av DAML som en del av et forskningsprogram startet av DARPA [8], en forskningsorganisasjon underlagt amerikanske myndigheter. Hensikten med dette var å kunne utvide RDFS sitt rike uttrykksregister som et verktøy for å utvikle praktiske AI-systemer. I august 2000 ble DAML-ONT utgitt. Dette er et enkelt språk for å uttrykke mer sofistikerte RDF klasse-definisjoner enn det man kunne uttrykke i RDFS Beskrivelse av DAML DAML er ikke en datamodell, men et skjematisk språk som kan bruke begrensninger til å beskrive data i en RDF datamodell. DAML er altså en utvidelse av RDFS. Tilleggsverdien i DAML er at det beskriver RDF data, og dermed gjør det mulig å legge til mer semantikk til dataene. Det DAML legger til RDFS er flere måter å begrense tillatte verdier av egenskaper, og hvilke egenskaper en klasse kan ha. I tillegg tilbys egenskaper som kan brukes i generisk programvare: daml:samepropertyas; faktisk er samme egenskap gjør det mulig å si at to RDF egenskaper fra forskjellige skjema daml:inverseof; kan brukes til å si at en RDF egenskap er den inverse egenskapen av en annen. Dette betyr at sammen beskriver de to egenskapene et forhold begge veier. 87

94 6.5. OWL KAPITTEL 6. ONTOLOGISTANDARDER daml:transitiveproperty; en egenskapstype som andre egenskapstyper kan lage en subklasse av for å klargjøre at de er transitive. Kort sagt styrker altså DAML RDFs skjemaspråk, og legger til litt semantikk på toppen Likheter mellom OIL og DAML Følgende egenskaper er felles for OIL og DAML: Begge støtter hierarkier av klasser og egenskaper basert på subklasser og subegenskaprelasjoner. Begge støtter at klasser kan bygges ut fra andre klasser ved å bruke kombinasjoner av AND, OR og NOT. Begge tillater at domenet, spennvidden og kardinaliteten til egenskapene er begrenset. Begge støtter transitive og inverse egenskaper. Begge støtter konkrete datatyper Forskjeller mellom OIL og DAML Følgende egenskaper er forskjellige for OIL og DAML: OIL oppnår større bakoverkompabilitet med RDF enn DAML. OIL er designet for å mulliggjøre resonnement-tjenester som er sunne og komplette, samtidig som de er effektive. Tilsvarende resonnement-tjenester er umulig i DAML. DAML tolererer spesifisering av standard (en: default) verdier, som kan antas for en gitt egenskap når ingen andre verdier er spesifisert. OIL unngår dette, ettersom ingen formell semantikk for standardverdier eksisterer. I stedet for å fortsette med separate ontologispråk for semantisk web, samlet en gruppe forskere seg for å lage et nytt ontologispråk for Internett. Mange av disse deltakerne var de samme som var med på å utvikle henholdsvis OIL og DAML. Dette språket bygger på både OIL og DAML og fikk derav navnet DAML+OIL. Senere ble denne standarden utviklet videre til OWL. 6.5 OWL Web Ontology Language (OWL) er et ontologispråk som bygger på DAML+OIL. Målet med språket er å tilby et standard språk for representasjon av ontologier på World Wide Web. Det er utviklet av W3Cs Web Ontology Working Group [51], og består av tre inkompatible sett av subspråk/arter [30], som vist i figur

95 KAPITTEL 6. ONTOLOGISTANDARDER 6.5. OWL Figur 6.3: De tre artene av OWL OWL Full Det komplette språket kalles OWL Full, og bruker alle OWL språkprimitivene. Det tillater også vilkårlige kombinasjoner av disse primitivene med RDF og RDF Schema. Dette inkluderer muligheten til å forandre meningen av forhåndsdefinerte primitiver, ved å slå sammen språkprimitiver. Fordelen med OWL Full er at den er fullt kompatibel med RDF, både syntaktisk og semantisk; det vil si at ethvert gyldig RDF dokument også er et gyldig OWL Full dokument, og enhver gyldig RDF/RDF Schema konklusjon er også en gyldig OWL Full konklusjon. Ulempen med OWL Full er at språket har blitt så komplekst at det er vanskelig å bygge et verktøy for det. Det er også forholdsvis tregt å resonnere i, og gir ikke alltid brukeren et komplett svar OWL DL (Description Logic) OWL DL er designet for å gi støtte til beskrivende logikk, og å tilby et språksubsett som har fordelaktige utregningsegenskaper for resonnementssystemer. For å utnytte den formelle understøtten for beskrivende logikk, er følgende restriksjoner fulgt i en OWL DL ontologi: Vokabulær oppdeling: enhver ressurs kan bare være enten en klasse, en datatype, en datatype-egenskap, en objektegenskap, et individ, en dataverdi eller en del av det innebygde vokabularet, og ikke mer enn en av disse. Eksplisitte spesifiseringer: må være spesifisert eksplisitt. Alle ressurser må være partisjonert, og partisjoneringen Separerte egenskaper: Inverse egenskaper, invers funksjonalitet og symmetrisk karakteristikk kan aldri spesifiseres for datatype egenskaper. 89

96 6.5. OWL KAPITTEL 6. ONTOLOGISTANDARDER Det kan ikke legges noen begrens- Ingen begrensninger på transitiv kardinalitet: ninger på kardinaliteten til transitive egenskaper. Begrensede anonyme klasser: og owl:disjointwith. Anonyme klasser er kun tillatt i domenet: owl:equivalentclass OWL Lite OWL Lite er laget for å kunne implementeres enkelt og tilbyr brukerne et funksjonelt subsett av OWL. Den er spesielt rettet mot verktøybyggere som ønsker støtte for OWL, men som vil starte med et relativt lite og enkelt sett av språkegenskapene. En OWL Lite ontologi må være en OWL DL ontologi, og i tillegg tilfredsstille følgende krav: Konstruktorene owl:oneof, owl:disjointwith, owl:unionof, owl:complementof og owl:hasvalue er ikke tillatt Kardinalitetsutsagn (både minimal, maksimal og eksakt kardinalitet) kan bare lages ut fra verdiene 0 og 1. owl:equivalentclass utsagn kan ikke lenger lages mellom anonyme klasser, bare mellom klasseidentifikatorer Sammenlikning av OWL-artene En kort sammenlikning av OWL-artene er sammenfattet i tabell 6.2. OWL Full OWL DL OWL Lite - Alle språkprimitiver er tillatt. - RDF Schema definisjoner kan blandes med OWL definisjoner. - Kan ikke bruke owl:cardinality med TransitiveProperty. - En DL-ontologi kan ikke bruke hele OWL Full ontologien. - Kan ikke bruke en klasse som medlem i en annen klasse, dvs kan ikke ha metaklasser. - FunctionalProperty og InverseFunctionalProperty kan ikke brukes med datatyper (kun med ObjectProperty). Tabell 6.2: Sammenligning av OWL-artene - Samme restriksjoner som i DL, i tillegg til: - Kan ikke bruke owl:mincardinality eller owl:maxcardinality. - Eneste tillatte verdier for owl:cardinality er 0 og 1. - Kan ikke bruke owl:hasvalue. - Kan ikke bruke owl:disjointwith. - Kan ikke bruke owl:oneof. - Kan ikke bruke owl:complementof. - Kan ikke bruke owl:unionof. 90

97 KAPITTEL 6. ONTOLOGISTANDARDER 6.5. OWL Følgende regler for kompabilitet mellom de tre subspråkene gjelder: Enhver lovlig OWL Lite ontologi er en lovlig OWL DL ontologi. Enhver lovlig OWL DL ontologi er en lovlig OWL Full ontologi. Enhver gyldig OWL Lite konklusjon er en gyldig OWL DL konklusjon. Enhver gyldig OWL DL konklusjon er en gyldig OWL Full konklusjon Sammenheng mellom OWL og RDF OWL bruker RDF og RDF Schema i stort omfang: Alle varianter av OWL bruker RDF som syntax Instanser deklareres som i RDF, ved å bruke RDF beskrivelser OWL konstruksjoner som owl:class, owl:datatypeproperty og owl:objectproperty er alle spesialiseringer av deres RDF motstykker, som vist i figur 6.4. Figur 6.4: Forhold mellom subklasser i OWL og RDFS [13] 91

98 6.6. SAMMENDRAG KAPITTEL 6. ONTOLOGISTANDARDER 6.6 Sammendrag OWL er i dag foreslått som standard for web-ontologier av W3C. Det tillater beskrivelse av kunnskapssemantikk på en måte som er aksesserbar for maskiner. OWL bygger på RDF og RDF Schema: RDF syntaks blir brukt som basis; instanser defineres ved hjelp av RDF beskrivelser, og de fleste RDFS modelleringsprimitivene brukes. Formell semantikk og støtte for ressonering muliggjøres ved å mappe OWL på logikk. Predikatlogikk og beskrivende logikk blir brukt til dette formålet. Til tross for at OWL er rikt nok til å kunne brukes i praksis, lages det fremdeles utvidelser. Dette gjelder særlig med tanke på logikkegenskaper. 92

99 Kapittel 7 Markedsundersøkelse Dette kapitlet tar for seg eksisterende løsninger som finnes på markedet i dag. Først og fremst fokuseres det på løsninger som eksisterer innen feltet helse/medisin, men det nevnes også løsninger innen andre domener, samt generelle løsninger for ontologi-behandling. Ettersom både helseinformatikk og ontologier generelt er så store og raskt voksende fagområder, vil dette kapitlet verken gå dypt i detalj, eller ta for seg mange løsninger. Det tar for seg noen konkrete løsninger, og noen fellestrekk mellom disse. 7.1 Medisinske ontologier/ordbøker Det finnes i dag en rekke løsninger for ordbøker/oppslagsverk for medisinske uttrykk på Internett, både bygget på ontologier og andre metoder for bruk av semantisk sammenheng. Under følger en kort beskrivelse av funksjonaliteten, brukergrensesnittet og virkemåten til noen av disse. Det finnes også en rekke rene leksikalske verktøy, men disse er ikke beskrevet her MeSH The Medical Subject Headings (MeSH), er en ordliste produsert av The National Library of Medicine (National Library of Medicine) [34], og er brukt for indeksering, katalogisering og søking i medisinsk og helserelatert informasjon og dokumenter. Ordlista inneholder semantiske sammenhenger mellom relaterte ord og uttrykk, representert i en tre-struktur. MeSH Browser [33] gir mulighet for å søke gjennom hele ordlista etter ord og uttrykk, men tilbyr ingen direkte kobling mot dokumenter. Søkegrensesnittet tilby en rekke metoder for å søke i lista. Figur 7.1 viser dette. Søkeresultatet vises i tabellform, der relaterte ord og uttrykk blir listet opp. Disse er trykkbare, og ved å trykke på et ord eller uttrykk, utføres tilsvarende søkeprosedyre på dette ordet, og ny resultatside åpnes. I tillegg vises deler av treet der søkeordet befinner seg, for å gjøre det mulig å se de semantiske sammen- 93

100 7.1. MEDISINSKE ONTOLOGIER KAPITTEL 7. MARKEDSUNDERSØKELSE hengene mellom ord og uttrykk. Figur 7.1: Søkegrensesnittet til MeSH Browser SNOMED SNOMED CT (Clinical Terms) [45] er en terminologi med kliniske begreper innen helse/medisin. Det er brukt i en rekke forskjellige sammenhenger av organisasjoner og helsevesen i mange land, blant annet til å føre elektroniske journaler, beslutningsstøtte til ekspertsystemer og forskning. Den inneholder nesten fire hundre tusen konsepter, og nærmere halvannen million semantiske relasjoner. SNOMED finnes i engelsk, tysk og spansk versjon, og er på den måten aktuell for svært mange land. I tillegg til å være i bruk innen helsevesenet direkte blir også teknologien og arkitekturen mye brukt til forskning på området ontologier også innen andre fagområder. SNOMED tilbyr forskjellige produkter og tjenester, og alle koster fra 100 til 1000 USD per år. Dette gjør at SNOMED ikke er aktuelt for nærmere utdypning i dette prosjektet UMLS UMLS (Unified Medical Language System) [48] er utviklet av NLM for å komme nærmere naturlig språk-applikasjoner for helsevesen og medisin. Det inkluderer tre kunnskaps-kilder (en: knowledge sources), som inkluderer Metahesaurus, Semantic Network og SPECIALIST lexicon. Disse inneholder medisinske termer og uttrykk fra en rekke andre samlinger, blant annet SNOMED (7.1.2) og andre terminologier fra området. De er ikke applikasjonsavhengige, i den grad at de kan benyttes i forskjellige applikasjoner. 94

101 KAPITTEL 7. MARKEDSUNDERSØKELSE 7.1. MEDISINSKE ONTOLOGIER PubMED PubMED [35] er et system som benytter seg av blant annet MeSH. PubMED gir brukere mulighet til å søke i forskjellige typer helsedokumenter, og bruker da blant annet MeSH for å finne relevante dokumenter. Dette inkluderer dokumenter med semantisk sammenheng med søkeordet. PubMED gir ikke direkte tilgang til hele artikler eller dokumenter, men tilbyr utdrag fra disse. I tillegg benytter det seg av et system som kalles LinkOut [29], et system som tilbyr lenker til hele dokumentet, noe PubMED selv ikke tilbyr. PubMED er en del av en portal som heter Entrez [18], som tilbyr søking i mange forskjellige databaser og oversikter OpenGALEN OpenGALEN [41] er en åpent tilgjengelig klinisk ontologi som har til hensikt å forenkle klassifiseringsoppgaver for å hente ut data fra kunnskapsdatabaser. Den åpne versjonen er bare tilgjengelig på engelsk. Ontologien er utviklet med støtte fra EU, og forsøker primært å løse klassifiseringsproblemer med hensyn til gruppering av ulike typer kliniske tilstander LinKBase LinKBase [27]er en ontologi for medisinsk bruk utviklet av firmaet Language and Computing (L&C) [5]. Den er meget omfattende, og inneholder medisinske termer og uttrykk på flere språk. Den danner grunnlaget for en rekke andre produkter L&C har utviklet for å redigere og søke i ontologier, samt å bruke ontologier for å indeksere medisinske dokumentsamlinger. TeSSI er en produktserie som bruker LinKBase-ontologien i en rekke underprodukter for å indeksere ved hjelp av semantikk, gjenfinne informasjon og å ekstrahere informasjon fra dokumenter. Under følger en kort beskrivelse av de forskjellige modulene i TeSSI. Indexing Engine (IE) er et verktøy som automatiserer indeksering av dokumenter ved å ta hensyn til semantiske forbindelser og betydningen av ord. Den lager indekser som bruker LinKBase-konsepter (språkuavhengige meningsenheter). Ved å bruke disse indeksene når man utfører søk, sikres høyere precision og recall enn om søket kun hadde blitt utført på statiske, ikke-semantiske indekser. Search Engine Dette er modulen som utfører søket ved å ta søkestrengen og gjøre om denne fra et naturlig språk til konseptuelle uttrykk som den sammenligner med indeksene laget av indekseringsmodulen. Ved å kombinere disse finner den frem til de dokumentene som inneholder relevant semantisk forbundet informasjon med søkestrengen. Resultatene som blir vist bruker også ontologien for å gjøre andre relevante ord i dokumentet som blir vist trykkbare. Dette gir funksjonalitet for å ta med disse ordene i et utvidet søk, eller å utføre et nytt søk med bare disse ordene. Figur 7.2 viser dette. 95

102 7.2. ONTOLOGIVERKTØY KAPITTEL 7. MARKEDSUNDERSØKELSE Figur 7.2: Ord i treffdokument gjøres trykkbare for redefinering av søk [27]. Extraction Engine Et problem ved å søke i dokumenter skrevet av forskjellige mennesker, gjerne med forskjellig bakgrunn og vaner, er at det ikke finnes noen enerådende standard for hvordan et dokument ser ut. Dette vanskeliggjør søkeprosessen, og det er nettopp denne oppgaven ekstraheringsmodulen tar seg av. Den bruker avansert naturlig språk-algoritmer for å trekke ut informasjon fra dokumentene og strukturerer denne i standardformater. Den bruker tomme maler som den fyller ut ved å trekke ut informasjonen som skal være i de forskjellige feltene. Dette gir brukerne av systemet en enkel måte å finne relevant informasjon om et dokument. 7.2 Generelle ontologiverktøy Å redigere ontologier kan være svært omfattende, både på grunn av deres størrelse og kompleksitet, og fordi det kan være vanskelig å få oversikt over deres hierarkiske struktur og oppbygning. Ulike verktøy har blitt utviklet for å redusere vanskelighetene med å visualisere og redigere disse Protégé Protégé [49] er et verktøy som lar brukeren redigere en domeneontologi ved å angi klasser av objekter og instanser av objektene. Det er et av de mest brukte programmene for redigering av ontologier. 96

103 KAPITTEL 7. MARKEDSUNDERSØKELSE 7.2. ONTOLOGIVERKTØY Protégé bruker et eget format for ontologier, men kan importere og eksportere til både OWL (6.5) og RDF (6.2) vha. programtillegg OntoEdit OntoEdit [40] tilbyr, på lik linje med Protégé, et grafisk brukergrensesnitt for å redigere ontologier. Det lar også brukeren redigere schema (klasser) i tillegg til instanser, og tillater eksport av formater som RDF (6.2) og OIL (6.3) LinKFactory LinKFactory er et verktøy utviklet av L&C først og fremst for å kunne redigere LinKBase ontologien, men kan også brukes til å lage nye og utvide andre eksisterende ontologier. LinKFactory tilbyr forskjellige grensesnitt mot ontologiene. Disse grensesnittene er blant annet flere tre-visualiseringer av ontologiene, samt flere grafiske fremstillinger [28]. 97

104 7.2. ONTOLOGIVERKTØY KAPITTEL 7. MARKEDSUNDERSØKELSE 98

105 Kapittel 8 Søkealgoritmer I dette kapitlet beskrives ulike søkemetoder som kan brukes for å gjenfinne data i dokumentbasen. Det overordnede målet til prototypen er å finne frem til det utvalget av dokumenter som semantisk stemmer best overens med søketermene, eller søkerens intensjon, dersom brukeren er presis. I kontekst av ontologisk søk, vil det være en søkemotor som ligger i bunnen og gir treffene. Spesielt når det søkes etter begrep som ikke ligger i domenet til den ontologiske databasen er det nødvendig å ha godt utviklede søkemuligheter i bunnen. Målet er derfor å utvikle en algoritme som vil oppføre seg på ønsket måte også når forutsetninger om domenetilhørighet er oppnådd. Selve søket kan skrives inn som en rekke termer eller fullstendige setninger som tolkes som rekker av nøkkelord. I tillegg kan det vurderes å assistere brukeren i oppgaven med å velge ontologibegrep det skal søkes innenfor, ved for eksempel interaktiv grafikk og andre hjelpemidler. 8.1 Mulige krav til søk De klassiske attributtene som søkealgoritmer evalueres ut fra er recall (evne til å huske) og precision (dokumenters relevans til søkekriteriene). Recall kan regnes ut som den andelen av dokumentene som er relevante sammenlignet med totalt antall dokumenter som er relevante, mens precision kan regnes ut som antallet relevante dokumenter hentet frem i forhold til totalt antall dokumenter i samlingen. Det er vanskelig å lage søkealgoritmer som maksimerer begge disse, men dersom en av disse attributtene er utilstrekkelig oppnådd, vil søkefunksjonen virke ubrukelig for brukeren av systemet. Valg av algoritme bør derfor ta hensyn til disse kravene, foran andre krav som for eksempel ytelse og tilleggsfunksjonalitet. Andre funksjoner som det går an å vurdere i søkesystemer, er avansert søk slik som det blir implementert av Google (se figur 8.1) og andre søkemotorer. Fordelen med avansert søk, 99

106 8.1. MULIGE KRAV TIL SØK KAPITTEL 8. SØKEALGORITMER er at man har muligheten for å ekskludere ord som forekommer ofte sammen med resten av søkeuttrykket, men som ikke ønskes i søkeresultatet. Søking etter eksakt tekst kan også hjelpe å finne dokumenter som inneholder fraser som brukeren vet henger sammen. Et eksempel på dette er latinske betegnelser. Figur 8.1: Avansert søk i Google [3] Søkealgoritmer bør være i stand til å takle situasjoner hvor ord i søket aldri finnes i kombinasjon. En vanlig feil brukere gjør ved forsøk på gjenfinning av ord, er at de prøver å være altfor presise. Artikler om emner som en bruker ser etter, kan i noen tilfeller behandles over flere usammenhengende dokumenter, og derved bomme på brukerens søkekriterier. Det er også en fordel om skrivefeil fra brukeren kan oppdages. Hvis søkekriterier som har svært få treff skrives inn, bør systemet kunne foreslå andre lignende ord. En Levenshteinalgoritme [2] kan brukes for å finne likhet til andre ord. Hvor gode algoritmene er til å behandle endrede og nye dokumenter er også noe som må vurderes. Konsistens må kunne oppnås med minst mulig last på tjeneren. Hvorvidt algoritmen skal støtte søk etter fraser eller nærhetsdirektiver er noe som må vurderes i forhold til brukergrensesnitt. Hvis dette skal være mulig, stiller det ytterligere krav til dokumentbasens tilgjengelighet og eventuell mellomlagring, ettersom søkealgoritmen da må ha direkte tilgang til dokumentene. 100

107 KAPITTEL 8. SØKEALGORITMER 8.2. BOOLSK SØK Figur 8.2: VENN-diagram for et boolsk søk 8.2 Boolsk søk Boolsk søk er den enkleste formen for søk i tekstdokumenter. Søketermer angis direkte for å begrense søkeresultatene, ved bruk av konnektorer som AND, OR og NOT. Selv om denne måten å søke etter tekst oppfattes som naturlig for brukeren, er det ikke sikkert at det er den mest nyttige måten å gjennomføre søket på. Spesielt i dokumentsamlinger skrevet av mange ulike forfattere med potensielt ulik bakgrunn, vil det være ulik bruk i terminologi og språkbruk. Derfor vil informasjonsgjenfinning ha problemer med semantiske dimensjoner av søket. En klassisk måte å bygge opp boolsk søk, er å ha en todimensjonal rekke med alle tilgjengelige ord som rader, og hver enkelt kolonne som dokumentene i systemet. Celleverdiene er da en bit som angir at ordet finnes i det respektive dokumentet, eller et heltall med antall ganger det forekommer. I tilfellet der rekken er en serie med bits, vil AND-søk være så enkelt som å foreta logisk AND med ordene som er med i søket. Mer tilnærming til brukerens språk kan foretas ved å prioritere dokumenter hvor innskrevne nøkkelord ligger nær hverandre (avstanden kan måles i antall ord), eller dokumenter hvor innskrevne nøkkelord forekommer med høyere frekvens enn ellers i dokumentbasen. Ytelsen til denne metoden er svært bra. Nye dokumenter kan legges til uten at dokumentsamlingen blir inkonsistent i forhold til indekser, og metoden skalerer bra. 101

108 8.3. SØKEALG. BASERT PÅ VEKTORROM KAPITTEL 8. SØKEALGORITMER 8.3 Søkealgoritmer basert på vektorrom Søkemotorer for vektorrom (Vector Space Modell, VSM [4]) bruker en litt annen fremgangsmåte enn boolsk søk. Den henter inspirasjon fra matrisealgebra og vektorer for å sammenligne dokumenter. Metoden har en viss semantisk tilnærming ved at den tillater at ord i søkekriteriet ikke eksisterer i dokumentene det søkes i, men tar de beste resultatene den finner. Søket foregår ved at dokumenter indekseres i vektorer, hvor hver kolonne i vektorer angir om det respektive ordet eksisterer i dokumentet. Ord som ikke anses for å være viktige, for eksempel og, å og den, utelates fra indeksen fordi de er en kilde til støy i utregningene. Vektorene blir stort sett representert ved boolske verdier, hvor 1 angir at ordet finnes, og 0 betyr at det ikke finnes. Søkeforespørsler som mottas av systemet behandles på samme måte som dokumenter, og oversettes til en vektor. Ved å geometrisk sammenligne dokumentvektorene med søkets vektor, finner man et rimelig mål for likheten mellom dem. For å gjøre søket litt mer nyansert, kan også verdiene i vektorene erstattes med et tall som angir domenerelevans eller relativ frekvens - gjerne om det har større frekvens enn dokumenter ellers i dokumentsamlingen. Dette kan bidra til å nedprioritere uinteressante søketermers relevans og gi et mer presist resultat. VSM er likevel følsom ovenfor støy og gir i mange tilfeller resultater som er langt fra optimale. Selv om den kan gi treff som er bedre enn implementasjoner ved boolsk søk i noen tilfeller, bør mer avanserte algoritmer vurderes for å bedre evnen til å finne igjen dokumenter. I figur 8.3 er det vist hvordan et søk kan foregå i dokumenter med ulikt innhold. Dokumentene indekseres basert på et utvalg av nøkkelord, og det lages en matrise over normaliserte vekter for hvert av ordene som forekommer i dokumentene. Algoritmen som normaliserer vektene har som mål å prioritere ord som forekommer ofte, og samtidig unngå at ord som forekommer ofte i hele dokumentbasen ikke får alt for høy oppmerksomhet i søk. Vanlige algoritmer for å vekte nøkkelordene på er for eksempel TFIDF [6](term frequency / inverse document frequency, brukt i eksemplet) og LTC (normalisert TF-IDF cosinus-rating). 102

109 KAPITTEL 8. SØKEALGORITMER 8.4. RELASJON TIL ONTOLOGIER Figur 8.3: Eksempel på bruk av VSM i søk etter Bake Brød ([38]) Lagring av indekser for søkealgoritmen kan gjøres enten med et databasesystem eller med en record-orientert, indeksert filstruktur som ligger som rådata på disk QR og SVD-faktorisering QR-faktorisering [38] er en teknikk som kan brukes for å redusere kompleksiteten til dokument-ord-matriser og dermed redusere mengden støy i søket. Dette kan gjøre søket mer nøyaktig i forhold til VSM. Algoritmen til QR-faktorisering tar i stor grad bruk av matriseregning, og eliminerer unødvendige og duplikate termer i matrisa, som gir et mer presist resultat. SVD-faktorisering er forholdsvis likt QR. Ord-dokument-matrisa blir delt opp i tre matriser som enkelt kan reduseres hver for seg for å redusere graden til matrisene. Også her brukes reduksjon av matrisene til å eliminere støy under søket. 8.4 Relasjon til ontologier For å utvide søk i store databaser til å bruke ontologier, er det mange ulike fremgangsmåter som kan brukes. Spørsmålet er hvor i prosessen ontologien skal inngå som et element og bidra til å forbedre søkeresultatene. Ontologien kan brukes både til å øke samlingen av begreper man søker etter, og til å identifisere hvilke ord som er viktige innenfor domenet. Å avgjøre viktigheten av ord er blant annet aktuelt for å redusere mengden støy i søk, noe som også blir påvirket av valg av 103

110 8.4. RELASJON TIL ONTOLOGIER KAPITTEL 8. SØKEALGORITMER søkealgoritme og valg av ontologiens oppbygging. Det er derfor viktig at valg av arkitektur blir gjort med hensyn til en helhetlig forståelse av informasjonsflyten gjennom systemet Generelle betraktninger Et problem ved tradisjonelle søkemetoder er tvetydighet. Enkeltord kan ha ulike betydninger i ulike kontekster, og problemet blir ofte forsterket i sammensatte søkestrenger. Tvetydigheten medfører at større eller mindre deler av søkeresultatet er irrelevante treff i forhold til informasjonen som søkes. Ontologier kan brukes til å fjerne tvetydighet og dermed spesifiere søket. Et alternativ er å bruke ontologien til å presentere et sett ulike spesifiseringer av søket for bruker. Brukeren kan så velge den semantiske kategorien som virker mest relevant i forhold til informasjonen som søkes. Inndeling i kategorier kan gjøres på flere måter, men kan for eksempel baseres på synonymer og underordnede ord i ontologien. Bruken av synonymer vil kunne tilby en utvidelse av søket med mulighet for å finne relevante dokumenter selv om de ikke inneholder ord fra den opprinnelige søkestrengen. Bruk av underordnede ord gir mulighet for å presentere innsnevringer av søket. Metoden medfører et søk med en totrinns interaksjon for bruker: 1. Søkestrengen prosesseres og ulike alternativer utledes, et for hver semantiske kategori. 2. Bruker velger den kategoriseringen som passer best, og det spesifiserte søket sendes til søkemotoren. Det andre steget vil kunne fjernes ved å kjøre separate søk i hver kategori, og presentere resultatene kategori for kategori. Dette vil medføre en del merarbeid, men i begrensede dokumentbaser vil dette trolig ikke være noe stort problem. Metoden er i seg selv enkel, men et hovedproblem er de store kravene som stilles til ontologien. Dette er også konklusjonen i [37], der en tilsvarende metode er utprøvd. Ontologien kan også benyttes til klassifisering av søkeresultatet. Igjen kan synonymer og underordnede ord benyttes, men i stedet for å presentere ulike kategorier for bruker før søket utføres, opprettes en egen klassifiseringsvektor for hver semantiske kategori. Søkeresultatet testes så mot hver av vektorne og klassifiseres på gunnlag av dette. Testen kan for eksempel være å beregne cosinusavstand mellom dokumentene og de ulike vektorne. Metoden er utprøvd i [36] med lovende resultat Søk i bare ontologi Et alternativ for arkitekturen til systemet, er at søk blir foretatt direkte i ontologien. Søketermer blir da koblet direkte til begrepene i ontologien i et 1:1-forhold. Ontologien vil her typisk være automatisk generert av en leksikalsk analyse av ords hyppighet, og dokumenter med samsvarende nøkkelord blir lenket opp mot nøkkelordene med URI-er som er inkludert 104

111 KAPITTEL 8. SØKEALGORITMER 8.4. RELASJON TIL ONTOLOGIER i ontologien selv. Implementasjon av algoritmen vil være forholdsvis enkelt, ettersom den er avhengig av kunnskap om hvilke ord som forekommer mer hyppig enn andre i dokumentbasen. Rangering av treff kan gjøres ved å prioritere dokumenter som blir funnet på basis av skjeldne nøkkelord. Søket vil også være svært raskt, ettersom det bare krever oppslag i en grafstruktur for å finne potensielle løsningsdokumenter. Resultatene av søk på denne måten vil trolig være akseptable, også når man søker etter kombinasjoner av nøkkelord. Ord som ikke sier noe om semantisk innhold i dokumentene vil ikke være ønskelige å søke etter, og de vil heller ikke bli tatt med i ontologien. Siden rangering kan skje etter hvor stort avvik i antall forekomster det er i det aktuelle dokumentet, vil støy her bli et mindre relevant problem. Metoden krever for øvrig at det er et stabilt sett av domener som eksisterer i dokumentdatabasen. Dersom semantikken i dokumentdatabasen blir for bred, vil det bli vanskeligere å oppnå en akseptabel precision i løsningen, ettersom flere betydninger og relasjoner av ulike begreper innføres Søk etter hyppige ord i dokumenter Alternativt til å ha all informasjon om dokumentbasen i en ontologisk database, er det mulig å ha en ontologi som grupperer ord som ofte opptrer sammen. Her vil det eksempelvis eksistere like mange ontologiske grupper som det er hyppige ord i systemet. Hver ontologiske gruppe består av nøkkelordet og alle ord som blir er relatert til det. Dette er noe av det samme som er presentert i kapittel 8.3, bare at dokumentene selv ikke spesifiseres i ontologien. Søk med en slik arkitektur er trolig enklest å implementere med vektorbasert søk, hvor søkevektoren kan vektes. Ord som direkte inngår i søkestrengen vil da ha høyest prioritet, mens synonymer vil ha lavere vekt. På denne måten vil søkealgoritmen forsøke å returnere dokumenter som har en viss sammenheng mellom begrepene i søkestrengen og ordene i ontologien. Styrken til denne metoden fremfor metoden i kapittel er at denne vil enklere kunne ta med treff også når søkestrengen bare har svak semantisk likhet. Teoretisk sett vil metoden også være anvendbar når søkedomenet består av ulike domener, selv om støy da kan redusere presisjonen noe. En fare er at størrelsen på ontologien kan bli ganske betydelig, ettersom forholdsvis mange ord må lagres for hvert nøkkelord i ontologien for å gi gode gjenfinningsresultater. Algoritmen er eksperimentell, og det er uvisst om den vil oppføre seg som ønsket når implementert. For å tillate at brukere av systemet eller forfattere kan endre på hvordan ontologien opp- 105

112 8.4. RELASJON TIL ONTOLOGIER KAPITTEL 8. SØKEALGORITMER fører seg, bør metoden vurderes implementert sammen med måter å definere nøkkelord på hver-artikkel-basis. Dette kan gjøres for eksempel ved at det automatisk foreslås nøkkelord til brukeren når artikler forfattes, og det da gis mulighet for å inkludere nye eller fjerne foreslåtte nøkkelord Autorativ ontologi med synonymer For å ha en mer klassisk tilnærming til søkealgoritmer, går det an å enten manuelt opprette en ontologi eller automatisk generere en ontologi som blir redigert av fagpersonell, som brukes som en autorativ kilde til forbindelser mellom ord i systemet. Denne måten krever mer menneskelige ressurser, men kan eliminere en del uønskede treff i søk. Det går an å bruke både vektorsøk og boolsk søk for å benytte denne metoden, litt avhengig av hvordan ontologien bygges opp og hvor omfattende den er. For eksempel kan det være vanskelig å kombinere omfattende synonymdatabaser med boolsk søk, uten at støy fra ulike betydninger av ord vil redusere presisjonen. Algoritmen som velges kan altså utvides til å ekspandere nøkkelord til også å inkludere synonymer, og derved vil recall til søket bedres Vektorsøk med domenespesifikke indekser I større søkemotorer som for eksempel Google benyttes det noen interessante teknikker som kan demonstreres eksperimentelt gjennom enkle søk: Relevanssortering basert på dokumenters kvalitet: Dersom man skriver inn søkekriterier som består av enkle termer (f.eks. Bil ), vil de øverste dokumentene ha en tilbøyelighet til å være de med høyest mulig kvalitet. En slik kvalitetsmetrikk kan for eksempel baseres på at søketermene forekommer i en meningsfull kontekst - i en kontinuerlig tekstblokk, at artikkelen har samme språk eller tilhører samme domene. Domenespesifikt søk: I Google går det an å skrive inn søkedomener i tillegg til søkekriterier. Dette gjøres med tilde-operatoren ( ). Som et eksempel vil søk etter peanuts gi helt andre treff enn peanuts food. Dette demonstrerer hvordan Google klarer å klassifisere dokumenter basert på innholdet. Kvalitetssortering vil muligens ha litt mindre relevans når det gjelder søk i lukkede dokumentsamlinger, slik som Extend sin helse-dokumentsamling. Det er sannsynlig at klassifisering bare med hensyn til oppfyllelse av søkekriteriene er nok. Noe som er mer interessant, er hvordan større søkemotorer klassifiserer dokumenter ved hjelp av det som sannsynligvis ligner mye på ontologier. 106

113 KAPITTEL 8. SØKEALGORITMER 8.5. IMPLEMENTASJONSKOSTNADER Ved hjelp av inverse indekser i vektorsøkealgoritmer, kan man enkelt gjøre oppslag på hvor hvert enkelt ord forekommer i dokumentsamlingen. Dette kan, på samme måte som Googles domenespesifikke søk, kombineres med andre inverse indekser mellom ontologiens begreper og dokumenter. Med en hovedindeks for ord, og eventuelle indekser i tillegg for hver ontologi i systemet, kan en muligens skape en bedre forbindelse mellom den leksikalske søkemotoren og semantisk innhold i dokumentsamlingen Ontologi for gruppering av søkeresultater Et annet alternativ for ontologistøttet søk, er å utføre leksikalsk søk, og gruppere søkeresultatene med basis i grupper av sammenhørende ord. Dersom man har en ontologi som er bygd opp hierarkisk, vil det være mulig å trekke ut de viktigste ordene fra dokumenter (etter relativ hyppighet) og sammenligne disse med oppbygningen til et ontologisk hierarki. På denne måten vil brukeren enklere kunne spesifisere hva som ønskes av informasjon. Selv om denne måten innfører en viss indireksjon i søket (først fylle ut søketermer, deretter eventuelt velge hvilken gruppe man søker innenfor) kan det hende at den gir svært presise treff. Ulempen er da naturligvis at den krever mye menneskelige ressurser i utformingen av ontologien og vedlikehold av denne. For en dokumentsamling som stadig vokser, vil det være vanskelig vedlikeholde den, og det kan da være nødvendig å kombinere løsningen med andre søkemetoder for å ha en konsistent løsning. 8.5 Implementasjonskostnader De metodene som er skissert i dette kapitlet har til dels svært ulik implementasjonskostnad. Boolsk søk vil være relativt enkelt å implementere. Denne algoritmen har også mange implementasjoner som er fritt tilgjengelig som kan fungere som referanse. Vektorsøk som er et veldig godt alternativ til boolsk søk, er vanskeligere å implementere på grunn av dens matematiske natur. Det eksisterer fritt tilgjengelige matematikkbiblioteker for mange programmeringsomgivelser som kan ta seg av utfordringene når det gjelder matrisemanipulasjon, men forståelsen av hvordan den virker, overordnet implementasjon og parametrisering av funksjonsmåte vil gi betydelig mer arbeid enn boolsk søk. Bruk av lagerplass og minneforbruk vil også være nokså forskjellig mellom disse to hovedtypene av algoritmer. For boolsk søk vil en dokument-ord-celle typisk bli representert som en bit. I tilfellet med vektorsøk vil flyttall brukes (tall som er normalisert ut fra relativt antall forekomster i dokumentene/dokumentbasen), som kan være opptil 8 bytes stort. DBSize boolean = (words stopwords) documents 8 DBSize V SM = (words stopwords) documents sizeof(f loat) 107

114 8.6. SAMMENDRAG KAPITTEL 8. SØKEALGORITMER For en dokumentsamling med dokumenter og ulike ord, vil størrelsen til dokumentbasen for boolsk søk være i størrelsesodren av 12.5 MB, men den samme databasen for vektorsøk vil være rundt 64 ganger større. Optimiseringsteknikker kan brukes for å redusere størrelsen på søkevektorer, og kanskje spare inn noe lagerkostnader Lagringsteknikker En avveiing som må gjøres med hensyn til valg av søkealgoritme, er måten data skal lagres på. En måte er å bruke et databasesystem for lagring av dokument-ord-vektorer eller separate ordforekomster. Fordelene ved å bruke et databasesystem er at man slipper å ta hensyn til implementasjonssidene av konsistens, lagring, oppdatering og filindekser. Ulempene blir mest synlig når brukt i sammenheng med boolsk søk hvor søkeforespørsler bygges opp i ren SQL, en teknikk som har relativ høy ressurskostnad. For å optimisere ytelsen til søk er det viktig å ta bevisste valg om hva som lagres i minne og hva som lagres på disk. Lagring av ord-indekser i minnet, sammen med deres filposisjon, vil redusere belastningen på sekundærlager og gjøre det mye raskere. Men mengden av indekser som lagres i minnet må likevel avveies mot mengden av minne som vil være tilgjengelig på tjeneren. 8.6 Sammendrag Dagens søkesystem hos Extend er basert på boolske algoritmer. Årsaken til dette er at det er enkelt å implementere og gir akseptable resultater med middels mengder støy. For å søke i dimensjoner som ligger nærmere semantikk, vil det likevel være nødvendig å bruke vektorbaserte søkealgoritmer. Innholdet i dette kapitlet taler altså for at vektorsøk vil være den beste løsningen, med dens gode evner til å rangere søketreff og skalering med store datamengder. De gode mulighetene til også ha domenespesifikke utvidelser gjennom ontologi gjør det spesielt godt egnet til prosjektet som behandles i dette forstudiet. 108

115 Kapittel 9 Generering av ontologi Ontologier presenterer vanligvis ord som forekommer i et bestemt domene. Generelle uttrykk kommer lenger opp i strukturen enn uttrykk lenger ned i strukturen. De mest generelle uttrykkene ligger altså nærmes roten. Traversering av en slik graf vil gi nyttig informasjon som f.eks. ordenes sammenheng, og generaliserte og spesialiserte betydninger. Ontologier kan genereres automatisk dersom man reduserer kravene til hierarkisk oppbygging. I dette kapitlet vil en teknikk som henter ut grupper av relaterte ord fra en dokumentsamling beskrives, sammen med resultater av eksperimentering med den. Resultatet av slik uthenting er svært avhengig av hvor avanserte statistiske metoder som benyttes, men i utganspunktet vil ordene bare være svakt relaterte og inneholde en viss mengde feil. Graden av relasjon mellom termene og feilmarginen vil her observeres, og teknikker som kan brukes for å redusere feilene nevnes. 9.1 Ønskede virkninger Selv om det er svært vanskelig å oppnå at automatisk genererte ontologier er presise i forhold til det virkelige innholdet i dokumentbasen, vil en viss kursorisk kunnskap om innholdet kunne tolkes. Det er rimelig å anta at ord som er viktige, vil forekomme med høyere frekvens enn ord i forklarende tekst. De ordene som forekommer aller mest hyppig, vil ikke være viktig (såkalte stoppord). Men man kan ikke anta at alle relevante begrep forekommer i begrepsspesifikke dokumenter, og man kan heller ikke forvente at alle relevante fagord faktisk blir tolket som viktige. På basis av dette kan man se at en ontologi som er automatisk generert på denne måten aldri vil kunne være verken korrekt eller dekke hele domenet. Likevel er det mulig å lage en ontologi som kan berike søkeforespørsler nok til å kunne gi treff i dokumenter som brukeren ønsker. En slik ontologi vil kunne brukes for å berike søkestrenger eller assistere brukeren i tilfeller hvor det er lite treff. Spesielt vil teknikken være nyttig i dokumentsamlinger som inneholder dokumenter skrevet av ulike forfattere 109

116 9.2. OPTIMALISERINGSTEKN. KAPITTEL 9. GENERERING AV ONTOLOGI med forskjellig begrepsbruk. Ordene som blir lagt til i en ontologi bør ideelt sett være uavhengige av bøyingsformer. Ord som isolert sett er meningsløse (stoppord) bør også unngås. Relevante fagord som forekommer i dokumentsamlingen knyttes sammen i en ontologi gjennom relasjoner mellom ordene. En slik løsning vil kunne bedre en søkealgoritmes evne til recall over en dokumentsamling med variert begrepsbruk. 9.2 Optimaliseringsteknikker Dette avsnittet tar for seg teknikker brukt for å bedre resultatene i forbindelse med automatisk opprettelse av ontologier Stemming Stemming er en teknikk for å hente frem ordstammer til ord, for å redusere størrelsen til ordlister. Teknikken baserer seg på Porter s Stemming Algorithm [42]. Algoritmen som er tatt i bruk for den norske ordsamlingen som behandles her, baserer seg på tre lister over endelser som blir fjernet dersom de eksisterer. Et problem ved stemmingalgoritmer er at de ikke alltid vil gi korrekt resultat. For å få korrekt resultat, må ordlister som angir ords grunnformer brukes. Dette kommer av at ordstammer også kan inneholde for eksempel flertallsendelser, noe som er svært vanskelig å oppnå rent algoritmisk. Et eksempel på ordstammer som kan fjernes: String[] stem1 = new String[] { "a", "e", "ede", "ande", "ende", "ane", "ene", "hetene", "erte", "en", "heten", "ar", "er", "heter", "s", "as", "es", "edes", "endes", "enes", "hetenes","ens", "hetens", "ers", "ets", "et", "het", "ert", "ast", }; String[] stem2 = new String[] { "dt", "vt", }; String[] stem3 = new String[] { "leg", "eleg", "ig", "eig", 110

117 KAPITTEL 9. GENERERING AV ONTOLOGI 9.2. OPTIMALISERINGSTEKN. }; "lig", "elig", "els", "lov", "elov", "slov", "hetslov", Algoritmen omdanner for eksempel både ordene bankens og bankene til bank, noe som er korrekt. Men kontonummer, som allerede er en ordstamme, blir omdannet til kontonumm. Dette er en bieffekt av stemmingalgoritmer, men er ikke til å unngå med mindre en ordliste er tilgjengelig. Til tross for en litt uforutsigbar oppførsel på enkelte ord, vil de fleste ord bli satt til en stamme som er unik. Ved å kjøre den samme algoritmen på søketermer som brukeren skriver inn, vil relasjonene til de stemmede ordene i ontologien bli tydelige Stoppord De fleste ord som eksisterer i dokumenter vil bare være elementer i den grammatikken de forekommer i, og ha liten semantisk betydning hver for seg. Spesielt gjelder dette pronomener, preposisjoner og adverb. Det er ikke ønskelig at disse ordene skal inngå i den automatisk genererte ontologien, ettersom de vanligvis har svært lav grad av tilhørighet til de andre ordene. På Internett finnes det stoppordlister for de fleste språk, alle med ulike størrelsesordner. Nedenfor følger et eksempel på et utdrag fra stoppordlista i Snowball-prosjektet [46]. og i jeg det at en den til er som på de med han av ikke inte der så var meg seg men ett har om vi min mitt ha hade hu hun nå over da ved fra du ut sin dem oss opp man kan hans hvor eller hva skal selv sjøl her alle vil bli ble blei blitt Stoppordlister kan også automatisk genereres ved å liste opp ord som forekommer oftest i dokumentsamlinger. Slike samlinger bør likevel redigeres for å sørge for at ord som kan ha betydning i et søk ikke inkluderes Valg av viktige ord Å avgjøre hvilke ord i et dokument som er viktige, kan være vanskelig selv om stoppord og stemming brukes. I algoritmen som blir brukt i dette eksperimentet, blir ord som har 111

118 9.3. TESTPROGRAM KAPITTEL 9. GENERERING AV ONTOLOGI minst dobbel så høy relativ frekvens i hvert enkelt dokument i forhold til frekvensen ordet forekommer i i dokumentsamlingen til sammen, bli eksportert som et identifiserende nøkkelord. Alle nøkkelordene som blir sett på som identifiserende for et dokument, blir sortert etter hvor ofte de forekommer i dokumentet, og de hyppigste ordene blir tatt med i ontologien. Denne algoritmen kan muligens optimaliseres ved å ta hensyn til forholdet mellom frekvensen i hvert enkelt dokument og dokumentsamlingen ellers. I algoritmen implementert i dette eksperimentet, er det ikke tatt høyde for statistisk varians og gjennomsnittlig antall forekomster i hvert dokument. Dette kan vurderes implementert for å gi enda bedre forslag til hvilke ord som er relevante i ulike dokumenter Andre statistiske metoder Noe som ikke er implementert i dette testprogrammet, men som bør vurderes dersom det skal bygges videre på dette, er avanserte statistiske metoder som gir ytterligere informasjon om ordenes sammenheng. Noen relevante teknikker er: Å sammenligne ordforekomster med eksterne referansesamlinger, for å unngå frekvensforskjeller som ikke er avhengig av domenets spesialisering. Å ta hensyn til at ord som ofte forekommer sammen i par (evt. nært hverandre) vil ha større sannsynlighet for å være relaterte. Å ta hensyn til at ord som forekommer i samme setning som regel omhandler hverandre. Disse teknikkene går i stor grad inn i emner som data mining, og vil ikke behandles nærmere her pga. omfanget et slikt studie vil ha. Det er likevel noe som bør utredes i detalj dersom man skal bygge videre på en slik metode. 9.3 Testprogram Et program som analyserer innholdet i en dokumentsamling som tilsvarer det den ferdige prototypen skal arbeide med, er utviklet for å teste muligheten til å automatisk ekstrahere en ontologi. Programmeringsomgivelsen Java er brukt for dette. Programmet består av følgende komponenter: Run.java: Oppstartdelen til programmet. HTMLParser.java: Innlasting av alle ord fra HTML-dokumenter. Hopper over HTMLoppmerking og konverterer HTML-entiteter. 112

119 KAPITTEL 9. GENERERING AV ONTOLOGI 9.4. TESTRESULTAT HTMLWordTokenizer.java: Hjelpeklasse for å kunne finne grensene til ord. Fjerner parenteser, bindestrek og andre tegn fra teksten. StopWords.java: Hjelpeklasse for å finne ut hva som er stoppord og ikke. Stemmer.java: Stemming av norske ord. DocumentList.java: Holder orden på alle dokumentene som skal behandles i systemet. DocumentInfo.java: Representerer ett dokument, og holder orden på antall forekomster av hvert enkelt ord i dokumentet. StatisticsGen.java: Genererer statistikk basert på alle dokumentenes ordforekomster, og skriver ut ofte brukte ord fra hvert dokument. 9.4 Testresultat Testprogrammet fra avsnitt 9.3 er testet ut på en database med 209 dokumenter, som tilsammen utgjør 10 MB med tekst. Disse har tilsammen i underkant av 7000 ulike ord etter at stemming er utført. Lista i vedlegg B er et vilkårlig utdrag fra programkjøringen. Hver linje i tabellen består av ordet som er funnet, et tall som angir hyppigheten til ordet i dokumentsamlingen for øvrig (tallet er egentlig antall forekomster av det bestemte ordet pr ord), og et tall som angir hyppigheten til ordet i det bestemte dokumentet som behandles (i samme størrelsesorden som forrige). I ordene som er trekt ut av disse dokumentene ser man at det er en klar sammenheng mellom ordene og innholdet i dokumentet. Selv om de fleste ordene ikke har noe særlig med hverandre å gjøre isolert sett, vil de være forståelige satt i en kontekst. Ved observasjon kan det sees en sammenheng mellom ordene som forekommer høyere opp, og hva dokumentet handler om. Sammenhengen mellom ordene på ulike nivåer i eksporterte lister er derimot ikke imponerende. 9.5 Sammendrag Etter å ha eksperimentert med en prototyp implementasjon av en teknikk for å automatisk opprette ontologier, kan det slås fast at denne måten, slik den er implementert her, ikke er en god måte å opprette en ontologi. Ordene har sannsynligvis alt for stor avstand mellom hverandre til å være nyttige som oppbygging av en ontologi for bruk i søk. Bedre statistiske 113

120 9.5. SAMMENDRAG KAPITTEL 9. GENERERING AV ONTOLOGI metoder må brukes for at dette skal kunne utføres. Noe dette likevel kan være nyttig for, er å foreslå nøkkelord for dokumenter. Ved å foreslå nøkkelord fra en slik liste, vil brukeren kunne angi mer nøyaktig hva et dokument handler om (evt. sammen med andre nøkkelord som brukeren selv bestemmer). Slik informasjon kan lagres som metainformasjon for hvert dokument, søkealgoritmen kan da legge ekstra stor vekt på dokumenter hvor brukerens søkestreng inneholder ett av dokumentets nøkkelord. Bruk av automatisk generert ontologi, med en så enkel teknikk som implementert her, kan kanskje også være nyttig for bruk for å utvide søk til nærliggende domener. Dette gjelder hvis brukeren er usikker på hva han leter etter. Da kan en slik ontolgi være nyttig for å utvide spennet i søket, uten å innføre alt for store mengder av støy (irrelevante dokumenter). Dersom denne teknikken skal gjøres nyttig, må det likevel gjøres mye arbeid innenfor statistiske metoder og finjustering av algoritmer, noe som går langt utover skopet til dette prosjektet. 114

121 Kapittel 10 Brukergrensesnitt Dette kapitlet beskriver ulike typer brukergrensesnitt som kan være aktuelle å implementere for å realisere et ontologistøttet søkesystem Utfordringer for brukergrensesnitt Det finnes mange ulike typer brukergrensesnitt for søk, og mange måter å beskue de utfordringer og problemer som ligger i utviklingen av gode alternativer for brukeren. Under følger noen av hovedutfordringene: De fleste brukere har ikke dyp kunnskap om søkemetodikk. Det å skulle formulere et søk viser seg for mange å være en stor utfordring, selv om de egentlig godt vet hva de vil finne. Det å skulle oversette sin forespørsel til et effektivt søk er en utfordring som må tas alvorlig i utviklingen av grensesnitt. Brukere skjønner ikke alle aspekter ved et søkegrensesnitt. Mange av dagens søkeverktøy er forholdsvis like, men likevel er det forskjeller. Dette kan være forvirrende for brukere. Forskjellige måter å søke på, ved bruk av flere knapper, felter eller lignende kan skape mer problemer enn fordeler, hvis forskjellen mellom disse ikke er innlysende. Søk blir ofte brukt for å navigere sider. Det har blitt stadig mer vanlig at brukerne bruker søkeverktøy for å navigere også innen en side, i stedet for å bruke meny-systemer og andre lenker som egentlig er tiltenkt denne oppgaven. Det bør dermed informeres om hva søket omfatter av dokumenter eller sider. Brukeren skal ikke trenge å sette seg nøye inn i systemet for å kunne bruke det. Det bør være et mål at det å formulere gode søk skal være så enkelt som mulig for brukeren, og at denne ikke skal måtte behøve å lære seg store mengder spesialkommandoer eller fremmede språk. 115

122 10.1. UTFORDRINGER BG KAPITTEL 10. BRUKERGRENSESNITT Brukeren kan ha problemer med å skjønne den innebygde logikken i søket. I dag bruker mange søkeverktøy innebygget Boolsk logikk og andre logiske sammenhenger for å binde sammen de forskjellige ordene i et søk. Dette skaper ofte problem for brukere, fordi de som regel fokuserer mest på å finne igjen informasjon. Misforsåelse av logikken søket innebærer kan også gi brukerne av systemet dårligere precision og recall. Små feil gjort av brukeren skal ikke ødelegge hele søket. Feilstaving av ord bør ikke føre til at søket mislykkes helt. Dette er en stor utfordring, og kan kreve mye av implementasjonen. Forholdsvis få søkeverktøy som er tilgjengelige i dag har støtte for slik utvidet funksjonalitet Spesifisering av søk Ettersom Internett har blitt stadig mer utbredt, har det oppstått en slags stereotyp enighet om oppbyggingen av søkeverktøy. Mange søkeverktøyer består av et tekstfelt og en knapp, og noen har også muligheter for avansert søk, der man ofte med flere parametre kan spesifisere søket enda mer presist. De fleste store søkeverktøy som ligger tilgjengelig på Internett i dag bruker denne oppbygningen. Se figur Figur 10.1: Et typisk søkeverktøy, her representert ved AllTheWebs grensesnitt. Standardisering av måten man søker på, har hjulpet mye til at søking på Internett er enkelt for alle brukergrupper. Det er også negative sider ved denne utviklingen, ved at det blir høyere terskel før nye brukere forstår de mer avanserte søkemotorene som ikke følger standardene. For eksempel kan verktøy der brukeren må angi hvilke(t) domene(r) det skal søkes innenfor virke tungvint. Det ligger derfor en utfordring ved utvikling av nye søkeverktøy, nemlig å lage noe som oppfattes logisk og lett å bruke for brukere med vidt forskjellig ikke-tekniske bakgrunn [44] Presentasjon av søkeresultat En annen utfordring ved utvikling av nettsidebaserte søkesystemer er presentasjonen av søkeresultatet. Det å ha en god løsning på denne problemstillingen kan være forskjellen på et vellykket og et mislykket produkt. Utfordringene ligger i å vise hvilke dokumenter som 116

123 KAPITTEL 10. BRUKERGRENSESNITT DAGENS SYSTEM blir funnet, hva disse dokumentene faktisk inneholder, og at brukeren ikke overveldes med informasjon. Mange systemer sorterer resultatene etter relevans, ut ifra søket som utføres. Ofte består hvert enkelt treff av en overskrift, som gjerne er tittelen på dokumentet, og et kort sammendrag av dokumentet eller bare de fire-fem første linjene. I store søkemotorer på Internett presenteres også URLen til dokumentet som blir funnet, men dette er mindre relevant for lukkede dokumentsamlinger. Noen søkemotorer på Internett har også en relevansindikator som viser en prosentvis relevans som blir regnet ut for hvert dokument. Et type søkeresultat er vist i figur Figur 10.2: Visning av et søketreff fra AltaVista [44] Dagens system Her beskrives brukergrensesnittet som brukes i EQS idag. De forskjellige elementene blir kort beskrevet. Deretter beskrives det hva som bør utbedres Spesifisering av søk Søket (se figur 10.3) spesifiseres gjennom et søkefelt, der man kan skrive inn et eller flere nøkkelord. Det finnes også en lenke til en side med mer avanserte søkemuligheter, der man kan spesifisere kategorier, yrkesgrupper og andre parametre som begrenser søket. I standardsøket er knappen for å utføre søket formet som en pil, uten tekst, mens i den avanserte søkemuligheten er denne erstattet med en knapp med teksten Søk Visning av søkeresultat Når man har trykket på søket åpnes resultatsiden, og denne består av: Søkefelt Øverst vises søkefeltet, der søket man har utført står, slik at man kan se hva det har blitt søkt på. Man har også et ekstra valg for å begrense søket litt, uten å bruke det avanserte søket. Dette består av et valg mellom å søke kun i titlene til dokumentene, og å søke gjennom hele dokumentet. 117

124 10.2. DAGENS SYSTEM KAPITTEL 10. BRUKERGRENSESNITT Figur 10.3: Dagens søkesystem i EQS. Antall treff Før selve søkeresultatet viser systemet også hvor mange treff det har funnet. Søkeresultat Treffene fra søket listes opp som trykkbare lenker, der lenketeksten er tittelen på dokumentet. I tillegg vises versjonsnummer, og datoen dokumentet ble godkjent for systemet. Ved å trykke på tittel-lenken åpnes dokumentet i sin helhet. Når man har åpnet et dokument finnes ingen mulighet for å komme tilbake søkeresultatet med lista over andre dokumenter Utfordringer ved et nytt system Dagens brukergrensesnitt fremstår som svært enkelt, og har mange muligheter for forbedringer. For det første er den generelle affordance-en (gjenkjenningsverdi til komponenter i brukergrensesnittet) til systemet begrenset, da det ikke er samsvar mellom den visuelle syntaksen som er brukt mellom det søkefeltet man finner på førstesiden, og det som kommer på resultatsiden. På førstesiden har man kun en pil som søkeknapp, mens man senere, også på avansert søk-valget finner en større knapp med teksten Søk. En slik inkonsistens gir lavere gjenkjenningsverdi for brukeren, og kan virke forvirrende. Et annet problem er at man ikke kan navigere tilbake til søkeresultatet etter å ha åpnet et dokument. Dette fører til systemet er svært tungvint å bruke, dersom man ikke er sikker på hvilket dokument man er ute etter. Visningen av søkeresultatet som i dag bare er en liste med titler på dokumenter er heller ingen spesielt god løsning, da man ikke får noe informasjon om hva dokumentet inneholder utover overskriften, eller hvor relevant det spesifikke treffet er i forhold til de andre treffene. Dette bør vises bedre, og det bør informeres om hvorfor søkeresultatene er representert slik de er. 118

125 KAPITTEL 10. BRUKERGRENSESNITT UTFORDRINGER ONTOLOGISØK 10.3 Utfordringer ved ontologistøttet søk Når det skal utvikles et nytt søkesystem der en eller flere ontologier skal støtte søket ved å innføre semantiske sammenhenger i selve søkeprosessen, kreves flere endringer av det eksisterende grensesnittet for at det skal være mulig for brukeren å forstå mer av hvordan søkeprosessen gjøres. Noen av de viktigste endringene som bør gjøres er: Brukergrensesnittet bør gi god informasjon om hva det søkes etter også etter at søket er utført og om nye ord er tilført søket underveis grunnet semantiske sammenhenger. Søkeresulatet bør presenteres på en måte slik at brukeren kan sortere ut de treffene som er bedre enn andre på en enkel måte, og at de mest relevante søkene er lettere tilgjengelig enn de mindre relevante. Brukeren bør ha mulighet til å redefinere søket ved å bruke de semantiske sammenhengene, eller å redusere søketomfanget ved å fjerne enkelte ord. Søkeresultatene fra forrige søk bør være tilgjengelig også etter at et dokument er åpnet. Det bør være enkelt å navigere tilbake til treff-oversikten Mulige løsninger De forskjellige løsningsskissene under er ikke komplette grensesnitt, men grove omriss av hva som vil karakterisere løsninger. Alternativene gir et inntrykk av noen av måtene man kan fremstille ontologistøttet søk, og er ikke ment å presentere alle momentene som bidrar til å løse oppgaven samtidig. Hvert av alternativene blir beskrevet generelt, og noen fordeler og ulemper ved hvert alternativ blir fremsatt. Etter fremstillingen av de forskjellige mulighetene, vil det bli trukket sammenligninger og konklusjoner mellom dem Løsning 1 - Standardsøk Denne typen brukergrensesnitt (se figur 10.4) gir ikke noe ekstra informasjon eller funksjonalitet ut over det man kan forvente av et standard nettsidebasert søkesystem idag. Det opplyses ikke om hvorvidt søket som foretas gjøres ved bruk av ontologier, eller om det kun er et standard leksikalsk søk. Resultatsiden lister treffene nedenfor hverandre, der tittel på dokumentet, de fire-fem første linjene av hvert dokument og en lenke til dokumentet inngår på hvert treff. Se figur 10.5 I tillegg viser resultatsiden søkefelt, der det søket man har foretatt er vist. En eventuell lenke til et mer avansert søkeskjema kan inngå i grensesnittet. 119

126 10.4. MULIGE LØSNINGER KAPITTEL 10. BRUKERGRENSESNITT Figur 10.4: Standard søkemotor. Figur 10.5: Standard søkeresultat. Fordeler: En fordel ved å velge et grensesnitt som dette, er at de fleste brukere er vant til å bruke tilsvarende grensesnitt, og at de dermed har en viss forventning av hvordan søk fungerer i et slikt system. I tillegg er grensesnittet enkelt og ukomplisert for brukeren. Ulemper: Spesielt for ontologistøttet søk kan dette grensesnittet være utilstrekkelig. Brukeren får lite informasjon om søket og søkemulighetene. Dette begrenser effektivite- 120

127 KAPITTEL 10. BRUKERGRENSESNITT MULIGE LØSNINGER ten til systemet, ved at søket ikke blir avgrenset/utvidet på riktig måte. Ettersom et ontologistøttet søk også kan ha muligheten for å søke etter dokumenter med semantisk sammenheng til søkeuttrykket, bør det være mulighet for å bestemme noe rundt dette for brukeren. Søkeresultatet ved et slikt system er ofte statisk, og gir lite informasjon om det faktiske innholdet av treffene. Det kan være vanskelig for brukeren å vite relevansen av dokumentene søket returnerer. Konklusjon: Et standard/klassisk brukergrensesnitt vil antagelig ikke være noen fullgod løsning for et søkesystem støttet av ontologier. Det gir for få muligheter til å spesifisere søket, og gir også en begrenset tilbakemelding til brukeren om de treffene som blir funnet. Likevel skal det sies at slike systemer fungerer veldig godt i mange sammenhenger nettopp fordi de er såpass enkle som de er, og dette må man også tenke på når man skal utvikle systemet Løsning 2 - Kategorisøk Denne måten å søke på gir brukeren stor valgfrihet når det gjelder hvordan han vil søke, ved å tilby spesifisering av kategorier. På mange måter kan dette minne om avansert søkgrensesnittet man finner på mange nettsider. Brukeren velger kategorier ved å bruke avkrysningsbokser. En slik oppbygging av søk kan kombineres med ontologier, ved at kategoriene velger mellom ulike grener av ontologien, eller kanskje egne ontologier med spesiell tilknytning til valgt søkealgoritme. En skisse av hvordan kategorier kan velges er vist i figur Et utkast til hvordan søkeresultater kan vises med henhold til kategoritreff i ontologien er vist i figur 10.7 Fordeler: Ved å søke i kategorier blir brukeren mer bevisst på mulighetene for å spesifisere søket sitt, og eliminere støykilder fra andre deler av dokumentbasen. I figur 10.7 er det også tatt høyde for muligheten til å finne dokumenter som ligner på treffdokumenter ( Mer dokumenter som dette ). Dette er en billig måte å utdype søk videre, som er enkelt å implementere dersom vektorbasert søk velges som søkealgoritme. Ulemper: Å velge kategorier innfører et forholdsvis tungt element i brukergrensesnittet. Bruk av avanserte elementer bør begrenses i søkegrensesnitt som skal brukes av ikketeknikere. Ved bruk av kategorier kreves det også enten at ontologien har høy grad av kompletthet, eller eventuelt at systemet er i stand til å korrekt klassifisere dokumenter. Dette er da avhengig av hvilken metode som velges. Dersom muligheter til å begrense søket innføres, må det sikres at disse fungerer slik brukeren forventer det. 121

128 10.4. MULIGE LØSNINGER KAPITTEL 10. BRUKERGRENSESNITT Figur 10.6: Søkemotor med kategorier. Konklusjon: En slik måte å organisere søket på, hvor brukeren kan navigere mer i søket etter at hovedsøket er utført, kan absolutt forenkle oppgaven som brukeren har med gjenfinning av informasjon. Brukergrensesnittet kan holdes svært enkelt, og muligheter til videre manipulasjon er tilknyttet hvert søkeresultat Løsning 3 - Navigering i søkeresultat med rammer En metode for å presentere søkeresultater på en bedre måte, er å bruke HTML-rammer (se figur 10.8). Dette tillater at brukeren navigerer i dokumentene uten å forlate søkesystemet. Innlasting av treffdokumenter kan videresendes gjennom søkesystemet, eller dokumenter kan lastes inn direkte. Fordeler: Å bevare søkeresultatet i en toppramme vil gi brukeren muligheter til å enkelt bla mellom søkeresultatene, samt at søketreff lett kan merkes i dokumentet. Ettersom dokumenter som brukeren ser kan tunelleres gjennom søkesystemet, gir dette også muligheter for å presentere en del av ontologien sammen med dokumentet. Dette kan komme som en 122

129 KAPITTEL 10. BRUKERGRENSESNITT MULIGE LØSNINGER Figur 10.7: Søkeresultater med treff i ontolgier. trestruktur som viser hvordan nøkkelord/synonymer henger sammen. Trestrukturen kan være et utgangspunkt for å starte nye søk, ved bruk av mer generelle eller spesielle termer. Ulemper: Søk med rammer krever at alt går gjennom søkemotoren. Dette kan føre til mye trafikk på søketjeneren. Stabilitet vil være noe som må tas hensyn til i en realisert løsning. Konklusjon: Dette er en interessant utvidelse til søk, som har mange muligheter for utvidelser og finjustering på grunn av at all informasjon passerer gjennom søkegrensesnittet. 123

130 10.5. SAMMMENDRAG KAPITTEL 10. BRUKERGRENSESNITT Figur 10.8: Navigering i søkeresultater med HTML-ramme Sammmendrag Etter å ha sett på ulike måter som ontolgisk søk kan realiseres i et brukergrensesnitt, sitter man igjen med en rekke ulike komponenter som kan settes sammen til en helhetlig løsning. Utstrakt grad av kompleksitet vil medføre et oppkludret grensesnitt og systemet får en svært bratt lærekurve for brukerne. Et kategori-basert søk, som presentert i løsning 2, vil kunne sikre funksjonalitet og fleksibilitet for brukeren. Likevel vil presentering av søkeresultatet i rammer (løsning 3) også være attraktivt, spesielt om det er et system som har begrenset mengde trafikk. Dette gir trolig de beste mulighetene for å hjelpe brukeren til å finne det han leter etter. Den ontologiske tilknytningen i brukergrensesnittet kan likevel begrenses til måten den er skissert i løsning 2, men den bør tilby noe utvidet funksjonalitet i forhold til navigasjonen i løsningen. 124

131 Kapittel 11 Implementasjonsomgivelser I dette kapitlet vurderes tekniske løsninger og implementasjonsomgivelser Introduksjon I dette kapitlet vil ulike tekniske løsninger vurderes. Et absolutt krav fra kunden er at systemet skal være nettsidebasert. Dette begrenser antall vurderinger som gjøres. Drøftingen tar utgangspunkt i arkitekturen som er skissert i figur Som det fremgår av figuren er det en hovedsplitting i tjenerside og klientside. Kommunikasjonen mellom disse vil gå over HTTP, (Hypettext transfer protocol) som er kommunikasjonsprotokollen på Internett. Tjeneren må i tillegg ha tilgang til data som brukes i systemet. Data kan ligge på samme fysiske maskin, eller kommunikasjon kan foregå over nettverk (for eksempel ved hjelp av XML). Figur 11.1: Overordnet arkitektur Videre diskuteres valg av implementasjonsomgivelse, samt ulike standariserte API for lasting og behandling av ontologier. Diskusjonen oppsummeres i kapittel Overordnede krav til teknisk løsning Kunden stiller relativt få krav til selve implementasjonen. Dette skyldes først og fremst at det som er ønsket er en frittstående prototyp brukt for demonstrering. Det er ikke stillt krav til at systemet skal være kompatibelt med eksisterende systemer, og det er således ikke 125

132 11.3. SPLITTING AV FUNK. KAPITTEL 11. OMGIVELSER lagt sterke føringer for valg av implementasjonsomgivelse. Følgende evalueringskriterier er uttrykt: Systemet skal være nettsidebasert Systemet skal utvikles basert på åpne standarder og språk Systemet skal benytte et standardisert API for lasting/behandling av ontologier Systemet skal være nettleseruavhengig Systemet skal være databaseuavhengig Systemet skal være plattformuavhengig Kravene er vektet ulikt, og enkelte er mindre viktige for vår prototyp. I de følgende avsnittene vil det vurderes ulike sider av den tekniske løsningen med utgangspunkt i punktene over. Den endelige vektingen og vurdering av teknisk løsning opp mot kravene kommer i konklusjonen i kapittel Splitting av funksjonalitet Det må tas stilling til hvordan funksjonaliteten skal fordeles mellom tjener og klient. To alternativer foreligger: All prosessering foregår på tjenersiden. (Tynn klient) Prosessering delt på klient og tjener. (Tykk klient) Et viktig aspekt i vurderingen av de to alternativene er hvor applikasjonsspesifikk klientsiden trenger å være. Klienten tilbyr grensesnittet mot bruker, og hvordan interaksjonen mellom bruker og applikasjon skal foregå er avgjørende. Dersom interaksjonen krever høy grad av prosessering vil det trolig være fordelaktig å la klienten gjøre mest mulig av dette. På denne måten lettes byrden på tjeneren, noe som gjør systemet mindre sårbart ved mange samtidige brukere. Båndbredden på nettverket er også viktig. Jo tynnere klienten er, jo større trafikk over nettverket vil være nødvendig. Et tregt nettverk taler derfor for bruk av tykke klienter. Utviklingskostnaden ved de ulike alternativene må også tas med i betraktningen. Utvikling av en tykk klient vil være relativt kostbart, mens en tynn klient kan være noe så enkelt som HTML tolket av en nettleser. Dette alternativet møter også kundens ønske om nettleseruavhengighet. Samtidig vil trolig utvikling av tjenerside koste mer ved en slik løsning. Dersom systemet skal kunne nyttes av trådløse enheter vil det være en fordel med så tynn klient som mulig. 126

133 KAPITTEL 11. OMGIVELSER SIKKERHET 11.4 Sikkerhet Kravet om en nettsidebasert protoyp reiser spørsmålet om sikkerhet. Kommunikasjonen vil foregå over HTTP og informasjon på tjener etterspørres ved å angi URL-er. Tjeneren vil potensielt ha tilgang til sensitiv informasjon og det er derfor nødvendig å vurdere måter å sikre kommunikasjonen Secure Socets Layer (SSL) SSL [47] er en krypteringsprotokoll for sikker kommunikasjon på Internett. Protokollen sikrer at kun sender og mottaker kan forstå informasjonen som utveksles. SSL krypterer ved hjelp av RSA-algoritmen, som er basert på primtallsteori (Utviklet av Rivest, Shamir og Adleman). Algoritmen regnes som sikker da ingen så langt har klart å dekode RSAkryptert data uten å vite nøkkelen Secure HTTP (HTTPS) Bruk av HTTP over SSL forkortes HTTPS. Dette er den dominerende måten å sikre kommunikasjon over HTTP, og vil være svært aktuell for kryptering av data som sendes mellom tjener og klient i systemet. Lagene i HTTPS er illustrert i figur Figur 11.2: Lagene i HTTPS [47] 11.5 Omgivelse Det finnes flere alternativer til implementasjonsomgivelse. Kundens føringer legger flere muligheter åpne. To alternativer skisseres: J2EE fra Java og Microsoft.NET. De to tilbyr mye av det samme men på forskjellige måter Java 2 Platform Enterprise Edition (J2EE) Hovedfokus i J2EE er å tilby en enkel, modulær standard for programutvikling i bedrifter. J2EE har sitt utgangspunkt i Sun Microsystems [32], som er ansvarlig for publisering av J2EE-standarden. All kildekode er åpen og utviklingen styres av programmerere fra hele 127

134 11.5. OMGIVELSE KAPITTEL 11. OMGIVELSER verden gjennom Java Community Process [43]. J2EE benytter programmeringsspråket Java. Dette er et plattformuavhengig språk som først kompileres til bytekode. Denne kjøres så i Java Runtime Environment(JRE), som finnes til alle plattformer. Java er et velutviklet språk med et rikt API, og det anses for å være enkelt og sikkert å bruke. Dette har gjort det til et populært språk med brukere over hele verden. Java undervises på mange universiteter, deriblant NTNU. Figur 11.3: Aktuelt subsett av J2EE arkitekturen J2EE tilbyr også en standard for utvikling av nettside-tjenester. Arkitekturen er skissert i figur Java Server Pages (JSP) tilbyr dynamisk HTML og WML over HTTP. JSP kommuniserer med Enterprise Java Beans (EJB) som tar seg av forretningslogikk og transaksjoner. Kommunikasjon med databaser og eventuelle bakgrunnssytemer behandles også her. Et alternativ til HTML og WML er egne applets som kommuniserer direkte med EJB Microsoft.NET Som det fremgår av navnet er.net en del av Microsofts program-portefølje. Rammeverket er språkuavhengig og muliggjør kompilering av kode skrevet i ulike språk til et felles kjøretidsspråk, Microsoft Intermediate Language (IL), som er analogt til Javas bytekode. I prinsippet kan alle språk som har utviklet en IL-kompilator integreres i.net, og en rekke språk har slik støtte i dag. Kjøretidsspråket IL kjøres så i Common Language Runtime(CLR) som kan sammenlignes med JRE i Java. En viktig hovedforskjell er at Java er plattformuavhengig, mens CLR bare er delvis uavhengig. Noen utvidelser til.net-plattformen, som 128

135 KAPITTEL 11. OMGIVELSER J2EE VS.NET ASP.NET (nettside-applikasjoner) og ADO.NET (databasefunksjonalitet), er fortsatt beskyttet av Microsoft-patenter. Det er utviklet en open source utviklingsplattform basert på.net for Linux. Prosjektet kalles Mono og inkluderer både utviklingsverktøy og infrastruktur for kjøring av.net klient- og serverapplikasjoner. I tillegg til å støtte en rekke språk har.net også sitt eget språk, C#, som har ekvivalent semantikk og store syntaktiske likehetstrekk med Java..NET har også et eget utviklingsverktøy, Visual Studio.NET som er et velutviklet IDE (integrated development environment) med støtte for de ulike språk som inngår i rammeverket. Figur 11.4: Aktuelt subsett av.net arkitekturen Nettside-applikasjoner realiseres ved hjelp av ASP.NET som oversetter brukergrensesnitt i HTML, XHTML eller WML(for trådløse enheter). Som en del av.net-familien kan også ASP-kode skrives i ulike språk. Under ASP.NET laget ligger.net Managed Components som tar seg av kommunikasjon med database og eventuelle bakgrunnssystem [19] [50] J2EE vs.net En sammenligning av hovedmomenter hos de to omgivelsene er gitt i tabell Begge språkene har relativ god modenhet, og begge er tilpasset bruk i nettverksomgivelser med sockets. Selv om.net har utmerket verktøystøtte i Visual Studio, er det likevel spørsmål rundt åpenhet i kildekode og lisenser som må behandles. 129

136 11.7. NETTSIDETEKNOLOGI KAPITTEL 11. OMGIVELSER Egenskap.NET J2EE Selskap Microsoft Mange Språk Alle med IL-kompilator Java Plattform Microsoft (Mono for Linux) Uavhengig Kjøretidssystem Common Language Runtime Java Runtime Environment (CLR) (JRE) Dynamiske nettsider ASP.NET JSP Kjernefunkjsonalitet.NET Common components Enterprise Java Beans (Java Core API) Kobling til bakgrunnsystem Host Integration Server Java Connector Architecture Databasetilgang ADO.NET JDBC, SQL/J, JDO, CMB Lisens Rammeverket i utgangspunktet fritt tilgjengelig, men enkelte deler som ASP.NET og Visual Studio.NET er lisensbelagt og må kjøpes. NTNU deler imidlertid har lisenser til disse produktene og de er således gratis for studenter. Fritt tilgjengelig. Tabell 11.1: Sammenligning av.net og J2EE 11.7 Teknologier for nettsider For å utvikle et grensesnitt mot brukeren, trengs det en programmeringsomgivelse som gir muligheter for rask utvikling, enkel feilsøking og har bred støtte i nettsidetjenere. Modenhet vil også være viktig for et ferdig produkt, men er ikke så viktig for en prototyp. Der finnes flere alternativer: PHP er et ganske vanlig programmeringsspråk for nettsider som er tilgjengelig på svært mange UNIX- og Windows-tjenere. Språket er populært i bruk, fordi det er enkelt å bruke i forhold til å behandle informasjonskapsler og brukerdata. Det har et enkelt grensesnitt mot databaser og henter mye av dynamikken fra andre programmeringsspråk (blant annet PERL og C). Det finnes PHP-versjoner for de fleste plattformer på markedet. En svakhet er at det er vanskelig å programmere strukturert og effektivt i språket, og det skalerer dårlig til større prosjekter. JSP er plattformuavhengig, og lar brukeren ta i bruk det svært omfattende klassebiblioteket til Java. Det har streng syntaks og er fullstendig objektorientert, slik at utvikling 130

137 KAPITTEL 11. OMGIVELSER ONTOLOGIGRENSESNITT av større prosjekter blir forenklet med dette språket. Det skalerer også bra med større prosjekter. ASP.NET er ikke plattformuavhengig, men har svært god verktøystøtte i Visual Studio. Med dette går det an å enkelt utvikle store prosjekter, som integreres sammen med andre.net-verktøysett for databasetilgang og annet. Javascript er et plattformuavhengig scriptspråk som ble utviklet av Netscape, og som bare er marginellt relatert til Java. JavaScript og Java må derfor ikke tolkes til å være det samme selv om de ligner på hverandre i navn og syntaks. Javascript tilbyr et raskt og enkelt spåk til websider og servere, og er innkapslet som et program på en webside og blir kjørt fra webklienten. Javascript gir mulighet til å lage dynamiske websider, og Javascriptmetodene blir kjørt på bakgrunn av museklikk, knapper eller annen interaksjon fra brukeren Grensesnitt mot ontologiske standarder Det er avgjørende for dette prosjektet å ha et fungerende grensesnitt mellom utviklingsspråket og de ontologiske standarder som systemet skal støtte. Et alternativ er å utvikle et skreddersydd grensesnitt internt. Dette krever inngående kjennskap til standarden samt omhyggelig design av grensesnittet. Et annet, og i utgangspunket mer realistisk alternativ er å benytte et eksisterende API JENA 2 Jena 2 [21] er et rammeverk for utvikling av Semantisk web-applikasjoner i språket Java. Det tilbyr et fullstendig API med metoder for manipulering av RDF-modeller, samt en egen RDF/XML parser (ARP). Rammeverket har også et subsystem for ontologier basert på RDF. Dette støtter OWL, DAML+OIL og RDFS, og har et eget inferensystem tilpasset disse. Subsystemet har også søtte for systematisk og organisert importering av ontologier [24]. RDQL er et spørrespråk for RDF-data som benyttes av Jena 2. For å gjøre spørringer mer effektive søker Jena 2 å plassere mest mulig av spørringen inne i en databasemotor. En mekanisme for dynamisk generering av SQL basert på RDQL-spørringer er derfor utviklet. Databasemotorene MySQL, PostgreSQL og Oracle støttes av rammeverket. Jena 2 er open source Wonderweb: OWL API Wonderweb [7] er navnet på et prosjekt ved University of Manchester, Vrije Universitait Amsterdam og University of Karlsruhe. Prosjektet har som hovedmål å utarbeide en in- 131

138 11.9. SAMMENDRAG KAPITTEL 11. OMGIVELSER frastruktur for utvikling av ontologier i stor skala. Et av delmålene er å utarbeide en API for OWL. Resultatet er Wonderweb OWL API. Dette må, i følge utviklerne selv, foreløpig ansees som et forslag til hvordan et slikt API bør bygges opp. Koden er fritt tilgjengelig og håpet er at denne skal videreutvikles ved hjelp av eksterne bidrag, og at rammeverket skal bli en fremherskende komponent i applikajoner utviklet for semantisk web. Rammeveket tilbyr programmatisk aksess til data i OWL-format for applikasjoner skrevet i Java. Hovedpakkene i rammeverket er model som tilbyr lesing av OWL-ontologier, change som tilbyr manipulering, og inference som gir tilgang til funksjonalitet for resonering med OWL-ontologier Kommersielle alternativer Det eksisterer også kommersielle alternativ på markedet i dag. Dette er systemer som eventuelt må kjøpes inn, noe som begrenser aktualiteten for dette prosjektet. Likevel presenteres ett eksisterende relevant system. Network Inference [22] tilbyr gjennom sitt produkt Cerebra Server et gresesnitt for behandling og bruk av store ontologier i OWL-format. Programmvareplattformen har mekansimer for forenkling av store kompliserte ontologier, linking av forskjellige ontologier og konsistenssjekking. Systemet skal være skalerbart til flere brukere, databaser og konsepter (ontologier), og endringer behandles dynamisk. Cerebra Server tilbyr et Web Service API til.net og J2EE Andre API Det har ikke lykkes å finne flere fritt tilgjengelige API mot OWL. Det eksisterer derimot API for parsing, søking og manipulering i RDF modeller til flere språk. RAP for PHP, Pyrple for Python, PerlRDF for Perl, Sambuca for Smalltalk og Drive for.net (C#) er eksempler på dette. Det er også utviklet en rekke RDF API for Java. Problemet er at bruk av RDF gir svært begrensede muligheter for representering av ontologier, noe som gjør bruk av disse rammeverkene mindre aktuelt Sammendrag Gruppa har fått få føringer på valg av teknisk løsning. For den nettsidebaserte prototypen vil en fullgod klient trolig kunne realiseres med HTML tolket i en standard nettleser. Kommunikasjonen mellom klient og tjener vil gå over HTTP og kan sikres ved bruk av SSL. De to implementasjonsomgivelsene, Microsoft.NET og J2EE, som er vurdert kommer rimelig likt ut. Hovedforskjellen er at enkelte komponenter av.net plattformen er lisensbelagt. Dette er likevel ikke noe reelt problem da studenter ved Institutt for Datateknikk ved NTNU har tilgang til gratis lisenser. Det som likevel gir Java et fortrinn er tilgangen 132

139 KAPITTEL 11. OMGIVELSER SAMMENDRAG til standardisert API mot OWL. Dersom systemet skal støtte OWL taler dette for bruk av Java. Det som later til å være det mest utviklede fritt tilgjengelige API mot OWL er Jena 2, som er laget for Java. Dersom Java velges eliminerer dette ASP.NET som utviklingsverktøy for HTML-grensesnittet. Valget står da mellom JSP og PHP. JSP gir tilgang til hele Java bilblioteket og er dermed en sterk kandidat. PHP på den annen side er enkelt og velutviklet, og kjennskapen til teknologien innad i gruppa er større enn tilfellet er for JSP, men når det gjelder skalering kommer JSP best ut. For endelig konklusjon og valg, se kapittel

140 11.9. SAMMENDRAG KAPITTEL 11. OMGIVELSER 134

141 Kapittel 12 Valg av løsning/konklusjon I dette kapitlet presenteres de kriteriene til systemet som er basis for forstudiumsfasen og valg av løsning. Kriteriene er satt opp i samarbeid med kunden, og er grunnlaget for evaluering av alternative løsninger. De forskjellige kriteriene er vektet med bokstaver; Lav(L), Middels(M), Høy(H). Disse angir viktigheten av kriteriet. Siden dette prosjektet skal resultere i en prototyp, vil vektingen på noen av kriteriene være litt forskjellige fra hvordan de ville vært vektet i et kommersielt system. I et slikt system ville det sannsynligvis heller ikke vært aktuelt å utarbeide en ontologi, og krav som vedrører ontologien ville sannsynligvis ikke vært med. Årsaken til dette er at det er en svært omfattende jobb å lage en ontologi Evaluering av løsninger I tabell 12.2 blir de forskjellige mulighetene som har blitt lansert tidligere i dokumentet vektet etter dekningsgrad av de forskjellige kriteriene. Det er også her brukt betegnelsene Høy(H), Middels(M) og Lav(L) for å angi dekningsgraden. Vektingene brukt for viktigheten av kriteriene, og dekningen av disse for de forskjellige løsningene blir så slått sammen for hver løsning i kolonnen TOTALT. Måten dette er gjort på er at Lav gir 1 poeng, Middels 2, og Høy 3. Viktigheten og dekningsgraden på hvert kriterie blir så multiplisert sammen, for så å bli summert for hver alternativ løsning. Sluttvurderingen blir så gjort utifra den høyeste og den laveste scoren, der de(n) laveste får Lav, og de(n) høyeste får høy. Der det er liten forskjell kan flere alternativer få samme sluttverdi. I disse tilfellene vil andre kriterier spille inn, og disse er beskrevet i

142 12.2. VURDERINGER KAPITTEL 12. VALG AV LØSNING/KONKLUSJON Brukergrensesnitt EV1 God effektivitet for brukeren. M EV2 Bør være enkelt å navigere i. Det vil si konsistens i form, farge og struktur. M EV3 Grensesnittet skal følge widgetstandarder for å gi gjenkjenningsverdi M EV4 Systemet skal opplyse brukeren om semantiske sammenhenger, og skal gi brukeren mulighet til å bruke disse H Ontologistandarder EV5 Fremtidsrettet, og/eller svært egnet standard. M EV6 Standarder som velges må være tilpasset oppgavedomenet H EV7 Skalerbarhet og utvidbarhet H EV8 Åpne standarder L Implementasjonsomgivelse EV9 Open Source L EV10 Nettsidebasert H EV11 Nettleseruavhengig. M EV12 Databaseuavhengig. L EV13 Plattformuavhengig. L EV14 Standardisert API mot lasting/behandling av ontologier M Nettside-språk EV15 Nettside-språkets mulighet for utviding/skalerbarhet M EV16 Nettside-språkets støtte på aktuelle nettside-tjenere/implementasonsomgivelse M EV17 Nettside-språkets verktøystøtte. (Kommunikasjon, tabellbehandling osv) M Søkealgoritmer EV18 Algoritmen bør teoretisk sett ha best mulig recall og precision. H EV19 Algoritmen bør ha gode muligheter for å tilpasses bestemte bruksmåter. H EV20 Søkeresultater bør ikke være bundet til å inneholde alle søketermene, men vekte basert L på det. EV21 Bør skalere bra i forhold til antall dokumenter og antall ord. M Generering av Ontologi EV22 Ontologien skal være enkel å utvide, både mtp. struktur og innhold. H EV23 Ontologien skal dekke semantisk innhold av dokumentsamlingen. H Tabell 12.1: Evalueringskriterier 12.2 Vurderinger Som det kommer frem av tabell 12.2 er det i flere tilfeller vanskelig å skille de forskjellige mulige løsningene fra hverandre. Flere steder rangeres flere løsninger til en totalverdi H. I disse tilfellene har er det gjort en analyse som går litt utenfor den rent strukturelt oppsatte evalueringen, og gjort et endelig valg. Diskusjon rundt dette følger nedenfor: Brukergrensesnitt Kategorisøk velges, da dette gir brukeren en utvidet funksjonalitet i forhold til det helt enkle standardsøket. I forhold til søkeresultat med rammer vurderes sistnevnte til å være en svært god løsning funksjonelt, men taper litt på brukervennlighet for brukere som ikke er vant til å jobbe med datamaskiner. Hovedvalget blir derfor at det 136

143 KAPITTEL 12. VALG AV LØSNING/KONKLUSJON VURDERINGER Brukergrensesnitt EV1 EV2 EV3 EV4 TOTALT Standard søk H M H L M Kategorisøk H M H H H Søkeresultat med rammer H H M M H Ontologistandarder EV5 EV6 EV7 EV8 TOTALT RDF M H H H H OIL/DAML L H M H M OWL H H H H H Implementasjonsomgivelse EV9 EV10 EV11 EV12 EV13 EV14 TOTALT J2EE (Java) H H H M H H H Microsoft.NET L H H H L M M Nettside-språk EV15 EV16 EV17 TOTALT PHP L M H M JSP H H H H ASP.NET M L H M Søkealgoritmer EV18 EV19 EV20 EV21 EV22 TOTALT Boolsk søk M H L M M M QR-Kvantifisering H H H H H H SVD-Kvantifisering H H H H H H Vektorsøk H H H H H H Generering av Ontologi EV22 EV23 TOTALT Automatisk generering H H H Semi-automatisk generering H M M Manuell generering L M L Tabell 12.2: Sammenligning av løsninger implementeres et kategorisøk. Ontologistandarder OWL velges her som standard, da dette er den teknologien som i dag er i ferd med å etablere seg som en standard for lignende løsninger. OWL blir også anbefalt av W3C, noe som veies tungt. Implementasjonsomgivelser Java blir her valgt fremfor.net-teknologi, da lisensbetingelser for Java-programmer er enklere, samt at dette er et språk alle i gruppa har gode erfaringer med fra før. Jena 2, et velutviklet API mot OWL er også tilgjengelig ved bruk av Java. 137

144 12.3. SKISSERING KAPITTEL 12. VALG AV LØSNING/KONKLUSJON Nettside-språk Det er viktig at det nettside-språket som blir valgt er kompatibelt med den implementasjonsomgivelsen som gjelder for resten av systemet. ASP.NET faller dermed automatisk bort, da denne ikke har god kompabilitet med Java. PHP scorer dårlig på skalering, og blir derfor en svakere kandidat enn JSP. Søkealgoritmer På grunn av tekniske vanskeligheter vil søkealgoritmer basert på QRog SVD-kvantifisering ikke bli brukt videre i en løsning. Selv om disse ville gitt noe bedre søkeresultater, anses ikke den mengden av arbeidsinnsats som kreves å være nødvendig for prototypen som skal utvikles i prosjektet. Generering av Ontologi Det ideelle hadde vært å kunne generere ontologien automatisk utifra dokumentene. Likevel har gruppa bestemt at metoden som skal brukes er en semiautomatisk generering basert på statistiske data trukket ut fra dokumentene. Ontologien skal så settes opp og korrigeres/justeres manuelt. Dette vil føre til en del ekstraarbeid i forhold til automatisk, men da automatisk generering også er meget avansert logisk og bundet opp mot forståelse av naturlig språk, vil ikke dette bli implementert Skissering av valgt løsning Fra tabell 12.2 kommer det frem at løsningen som gruppa vil anbefale, baserer seg på et kategoribasert ontologisk grensesnitt, hvor ontologien utgjør stammen i kategoriene. Hvordan denne tilknytningen skal skje, er et spørsmål om teknisk design som vil bli behandlet i større detalj i senere faser. Søk basert på bruk av flere dokumentrammer er en alternativ metode dersom et forbedret grensesnitt viser seg å være nødvendig. Ontologistandarden OWL vil bli bruket i prosjektet. Hvilket nivå av OWL-standarden som tas i bruk, er et spørsmål om teknisk design som det ikke tas hensyn til her. J2EE anses som det sterkeste alternativet for en implementasjonsomgivelse. Særlig denne plattformens åpenhet, samt tilgang til velutviklet API mot OWL gjør at gruppa foretrekker at systemet utvikles basert på den, og brukes for eventuelle fremtidige produkter. Av de søkealgoritmene som er presentert, vil vektorsøk med bruk av avanserte kvantifiseringsteknikker gi best oppfyllelse av evalueringskriteriene. Men gruppa har på grunn av de begrensede ressursene dette prosjektet har, begrenset seg til standard vektorsøk uten utvidelser. Dette gir en svakere oppfyllelse av evalueringskriterier, særlig EV18, men bruk av normalt vektorsøk vil være tilstrekkelig for å demonstrere hvorvidt ontologisk søk gir en reell forbedring av søkeresultater. 138

145 Vedlegg A Begrepsordliste Under følger en liste over stikkord brukt i forstudiet. ADO:.NET-modul for databasekommunikasjon i.net Affordance: Den intuitive handling et element i et brukergrensesnitt utstråler. AI: Artificial Intelligence (Kunstig intelligens) API: Application Programming Interface-et sett definisjoner for kommunikasjon mellom adskilte programdeler. Applet: ARP: Selvstendig javaprogram som kan innlemmes i HTML og kjøres i nettleser. RDF/HTML parser i Jena2 ASP.NET: Active Server Pages.NET- modul for nettside-baserte apllikasjoner i.net Boolsk søk: En søkealgoritme som finner treff basert på koeksistens til termer i et bestemt dokument C#: CLR: programmeringsspråk for.net rammeverket Common Language Runtime-kjøretidsmiljø for.net IL kjøres her. DAML: (DARPA Agent Markup Language). utvidelse av XML og RDF for å lage ontologier og formidle informasjon slik at den er forståelig og leselig for maskiner. Se også OIL. 139

146 VEDLEGG A. BEGREPSORDLISTE Data mining: Arbeid med å finne fram til informasjon i store datamengder. EJB: EQS: Enterprise Java Beans-betegnelse på kjernefunksjonaliteten i J2EE-arkitekturen Extend Quality System. Dagens løsning hos Extend. Google: HTML: HTTP: HTTPS: Den mest brukte søkemotoren på WWW. HyperText Markup Language - markeringsspråk for hyperlenket tekst Hyper Text Transfer Protocol-kommunikasjonsprotokoll for Internett HTTP kryptert vha SSL IDE: Integrated Development Environment- utviklingsverktøy IL: Windows Intermediate Language-kode som skal kjøres i.net kompileres først til kjøretidsspråket IL ISO-9000: Internasjonal standard for programvarekvalitet. J2EE: Java: JCP: JRE: JSP: Jena2: Java 2 Platform Enterprise Edition-standard for programutvikling i bedrifter Programeringsmiljø utivklet av Sun Microsystems. Java Community Process-åpent utviklerssmfunn for Java Java Runtime Environment-kjøretidsmiljø for Java Java Server Pages-språk for dynamiske nettsider med bruk av Java-biblioteket Rammeverk for utvikling av Semantisk web-applikasjoner i språket Java Kardinalitet: Et mål for størrelsen på en mengde. L&C: Language and Computing [5]. Lemmatisering: ordet. Operasjonen å fjerne bøyningsformer på ord for å få grunnformen av 140

147 VEDLEGG A. BEGREPSORDLISTE Levenshteinalgoritme: Algoritme som finner redigeringsavstand mellom ord. LTC: Mono:.NET: Normalisert TF-IDF cosinus-rating. Open source: plattform for linux basert på.net Managed Components- kjernemodulen i.net NLM: National Library of Medicine [34]. NTNU: Norges Teknisk- Naturvitenskapelig Universitet. Nøkkelord: Et annet ord for en term (et vanlig ord) som forekommer i dokumenter. OIL: (Ontology Inference Layer). nettside-basert standard for å spesifisere ontologier. Se også DAML. Ontologi: definerer begreper og relasjoner mellom disse i et gitt domene. Fungerer som et strukturert, semantisk leksikon over de termene som brukes innenfor domenet Open source: Tjenesteutsettning. Sette ut hele eller deler av et arbeid til eksterne ak- Outsourcing: tører. Åpen kildekode. Kildekoden gjøres tilgjengelig for omverdenen. OWL: (Web Ontology Language). Bygger på RDF, legger til mer vokabular, beskrivelse av egenskaper og klasser. Parsing: Precision: Tolkning av data. Presisjon, her brukt om hvor presist et søk er. QR/SVD-faktorisering: Avanserte teknikker for å regne ut hvor viktig et ords forekomst er for et bestemt dokument. Benytter seg av komplisert matriseregning for å utelate dokumenter hvor et ords forekomst sannsynligvis har liten betydning. Recall: Gjenfinning. Her beskriver det hvor mange av de relevanten treffene søket finner. RDF: (Resource Description Framework). Fundament for å prosessere metadata; mulliggjør kommunikasjon mellom applikasjoner som utveksler maskin-forsåelig informasjon på WWW. Bygger på XML 141

148 VEDLEGG A. BEGREPSORDLISTE RDQL: spørrespråk for RDF-data benyttet av Jena 2 Semantisk Web: Utvidelse av WWW der informasjon har en vel-definert betydning, noe som muliggjør kommunikasjon mellom mennesker og maskiner. Semantisk Web er en abstrakt representasjon av data på WWW basert på RDF standarden. Sockets: Kommunikasjonsbegrep innen programmering. SQL: SSL: Structured Query Language- standard spørrespråk i databaser Secure Socets Layer-krypteringsprotokoll for sikker kommunikasjon over nettverk Stemming: En teknikk for å fjerne typiske bøyingsformer fra ord. Stemming kan redusere kompleksiteten til et vokabular mye, ved å f.eks. slå sammen ord som bil, biler, bilene osv. til en enkelt term. Ren mekanisk, og ser ikke på betydningen av ordet som kommer ut. Stoppord: Stoppord er ord som forekommer ofte, og har for tekstanalyseformål ingen semantisk verdi om de forekommer i en setning. Søkemotor: Fellesbegrep for søketjenester. TF-IDF: (Term Frequency Inverse Document Frequency). En enkel teknikk for å analysere hvor viktig et ords forekomst er i sammenhengen sin. Baserer seg på å simpelthen analysere ordets frekvens i dokumentet i forhold til dets frekvens i dokumentsamlingen for øvrig. Transitivitet: Gjennomsiktighet. I programmeringsmiljøer brukt om mellomledd som holdes skjult for brukeren eller andre deler av systemet. URI: (Uniform Resource Identifier). Kort tekststreng som beskriver navn og adresse som kan brukes til å referere til en abstrakt eller fysisk ressurs. URL: Uniform Resource Locator-entydig nettverksadresse Vektorsøk: En søkealgoritme som finner dokumenter som ligner mest på søkestrengen ved hjelp av geometriske metoder. Nettleser Program som leser nettsider og viser disse. (Internet Explorer, Opera og Mozilla er eksempler på slike) 142

149 VEDLEGG A. BEGREPSORDLISTE Nettside-tjener Tjenermaskin som lagrer nettsider og tilbyr disse til brukere. WML: Wireless Markup Language-markeringsspråk for informasjon tilgjengelig via trådløs kommunikasjon WWW: (World Wide Web). Hypertekstsystem som opererer over internett. Man bruker en nettleser til å lese deler av informasjon (dokumenter eller nettsider) fra nettside-tjenere. Man kan følge hyperlinkene på hver side til andre dokumenter eller sende informasjon tilbake til tjeneren. Å følge linker på denne måten kalles ofte å surfe på internett. XHTML: extensible HTML- HTML med restriksjoner W3C: (World Wide Web Consortium). Sammenslutning av både industriaktører, akademia og offentlige institusjoner, som arbeider for å skape enighet om standarder for World Wide Web. 143

150 144 VEDLEGG A. BEGREPSORDLISTE

151 Vedlegg B Automatisk generering av ontologi Nedenfor er et utsnitt av utdata for kjøring av automatisk uthenting av ontologiord fra dokumenter. Utdata er presentert på per-dokument-basis, hvor hvert dokument er adskilt med en linje med bare stigetegn. For hvert ord er det tre kolonner. Ordene er sortert etter hvor ofte ordene forekommer i det bestemte dokumentet, i forhold til alle andre dokumenter. Ord som har størst avvik fra normal antall forekomster kommer øverst, mens ord som har vanlig forekomstfrekvens blir helt oversett. Den første kolonnen er ordet selv. Kolonne 2 (Treff/10kOrd) angir hvor ofte det bestemte ordet gjennomsnittelig forekommer i dokumentsamlingen (i antall forekomster pr ord. Den siste kolonnen angir hvor ofte det samme ordet forekommer i dokumentet som er under behandling nå. Dette er også antall forekomster pr ord. For små dokumenter hvor der er mye mindre enn ord, så kan sistnevnte tall bli unaturlig høyt. Ontology Generator for medical databases Copyright (C) 2004 KproGrp17, Extend A/S * 209 documents found in docs subdirectory for processing ################################################ Document: D:\misc\eqs_docs2\test \docs\doc_1040\index.html Prosedyre epikriser - diagnosekoding ORD Treff/10kOrd Dok diktere epikris pasient poliklinikk diagnos notat operasjonskod prosedyr

152 VEDLEGG B. AUTOMATISK GENERERING AV ONTOLOGI skriving ncsp behandlend diagnosekoding helsedepartement icd kod kontroll sosial lev arbeidet ethv 0 78 fagl 6 78 ferdigbehandl 0 78 finansiering 0 78 forskrift fullstend 1 78 fyll 4 78 før gjeld godtgjør 1 78 grunnlagsinformasjon gul 1 78 arbeidsbeskriv helsetilsyn 3 78 hold 2 78 arbeidsdagen 0 78 inngrep 1 78 innherred innsatsstyrt 0 78 janu 2 78 journal kirurgisk kith 0 78 ################################################ Document: D:\misc\eqs_docs2\test \docs\doc_1041\index.html Prosedyre for utlevring av journalkopier ORD Treff/10kOrd Dok pasient journal kopi når forsikringsselskap gjeld journalopplysning godtgjør jfr henvend

153 VEDLEGG B. AUTOMATISK GENERERING AV ONTOLOGI honor håndtere avtalen instans bokstav dnlf journalen journalkopi advokat følgebrev anmodning avdelingsover person prosedyr sjef utlegning utlevring vurdering ønsk forsikringsforbund 0 59 arbeidsbeskriv fremsette 0 59 fullmakt 1 59 følge 6 59 ark 3 59 følgeskriv 0 59 ################################################ Document: D:\misc\eqs_docs2\test \docs\doc_1494\index.html C. Brann og eksplosjonsforebyggende tiltak ORD Treff/10kOrd Dok elektrisk klinikkled brann installasjon kontroll tiltak juledekorasjon kaffetrakter klinikk brannvernled gas melde skjerm eksplosjonsforebyggend væsk brunsvidd 0 66 bryt 1 66 dekorasjon

154 VEDLEGG B. AUTOMATISK GENERERING AV ONTOLOGI desinfeksjonsvæsk 0 66 eksplosjon 1 66 antennelseskild 0 66 apparat 5 66 far 2 66 fest 0 66 flytt 0 66 forbrenningshastigh 0 66 forebyggend 3 66 forsiktigh 0 66 forsyningsavdeling 1 66 frakobl 0 66 full 0 66 ################################################ Document: D:\misc\eqs_docs2\test \docs\doc_1495\index.html E. Evakuering ORD Treff/10kOrd Dok evakuering brann plan klinikk bring entyd avtalt folk følgend gjenglemt informasjon innehold intern katastrofeplan ansvarl klinikkled kvalitetsmål meny opptred organisatorisk organisere brannmannskap proses punkt resultat rom rømningsvei

155 Bibliografi [1] [2] Efficient implementation of the levenshtein-algorithm. [3] Google. [4] Introduction: Vector space model. textmining/node5.html. [5] Language and computing. [6] Tf idf. [7] Wonderweb ontology infrastructure for the semantic web [8] Defense Advanced Research Projects Agency. Darpa home. [9] Extend AS. Eqs content - dokumentstyring på iso-nivå [10] Extend AS. Eqs feedback - meldings- og avvikshåndtering html. [11] Extend AS. Extend - eqs balansert målstyring [12] Extend AS. Extend - quality becomes the way you work! [13] Sean Bechhofer, Frank van Harmelen, Jim Hendler, Ian Horrocks, Deborah L McGuinness, Peter F. Patel-Schneider, and Lynn Andrea Stein. Owl web ontology language reference w3.org/tr/2004/rec-owl-ref /. [14] World Wide Web Consortium. Leading the web to its full potential [15] World Wide Web Consortium. Rdf primer [16] World Wide Web Consortium. Rdf vocabulary description language 1.0: Rdf schema http: // [17] DAML.org. The darpa agent markup language homepage. [18] Entrez. Entrez cross-database search. [19] Jim Farley. Microsoft.net vs. j2ee: How do they stack up? farley_0800.html/. [20] A. Farquhar. Ontolingua tutorial pdf. [21] Jena Semantic Web Framework. Jena - a semantic web framework for java sourceforge.net. [22] Network Inference

156 BIBLIOGRAFI BIBLIOGRAFI [23] The Balanced Scorecard Institute. What is the balanced scorecard? balancedscorecard.org/basic/bsc1.html. [24] HP invent. Jena 2 - a semantic web framework [25] IST. Istweb - home page. [26] Bijan Parsia James Hendler. Xml semantic web XML-J-Oct2002.pdf. [27] Language and Computing. Linkbase. [28] Language and Computing. Linkfactory. [29] LinkOut. Linkout home page. [30] Deborah L McGuinness and Frank van Harmelen. Owl web ontology language overview [31] Deborah L McGuinness and Natalya F. Noy. Ontology development 101: A guide to creating your first ontology. ontology-tutorial-noy-mcguinness.pdf. [32] Sun Microsystems [33] The National Library of Medicine. Mesh. [34] The National Library of Medicine. The national library of medicine. [35] The National Library of Medicine. Pubmed. [36] Ernesto William De Luca og Andreas Nürnberger. Ontology-based semantic online classification of documents: Supporting users in searching the web ~deluca/eunite2004_deluca_nuernberger.pdf. [37] Ahmed Abdelali og James Cowie og David Farwell og Bill Ogden og Stephen Helmreich. Crosslanguage information retrieval using ontology taln2003/articles/abdelali.pdf. [38] Philip Fung og Vivek Chandran. Matrices, vector spaces, and information retrieval. ugcs.caltech.edu/~chandran/cs20/project.html. [39] Ontoknowledge. Welcome to the oil-page. [40] OntoPrise. Ontoedit -ontology editor. [41] OpenGALEN. Opengalen. [42] Martin Porter. The porter stemming algorithm. PorterStemmer/. [43] Java Community Process [44] Derek Sisson. Considering search. 05.Juli [45] Snomed. Snomed. [46] Snowball. Norwegian stop word list. [47] Andrew S. Tanenbaum. Computer networks Inc. Prentice Hall PTR. [48] UMLS. The national library of medicine. [49] Stanford University. The protege project. [50] Ed Vawter, Chad og Roman. J2ee vs. microsoft.net: A comparison of building xml-based web services [51] W3C. Web-ontology (webont) working group

157 Tabeller 6.1 Kjerneklasser og egenskaper i RDF Sammenligning av OWL-artene Sammenligning av.net og J2EE Evalueringskriterier Sammenligning av løsninger

158 TABELLER TABELLER 152

159 Figurer 2.1 EQS-demo grensesnitt EQS Process prosesseditor Eksempel på representasjon av statistikk i EQS Navigering i kategori-treet i en demo av EQS. (Venstre marg) Søkeresultat etter ordet kanyle i en demo av EQS RDF-trippel representert som graf Eksempel på dekoding av ressurs De tre artene av OWL Forhold mellom subklasser i OWL og RDFS [13] Søkegrensesnittet til MeSH Browser Ord i treffdokument blir gjort trykkbare for å kunne redefinere eller utvide søk [27] Avansert søk i Google [3] VENN-diagram for et boolsk søk Eksempel på bruk av VSM i søk etter Bake Brød ([38]) Et typisk søkeverktøy, her representert ved AllTheWebs grensesnitt Visning av et søketreff fra AltaVista [44] Dagens søkesystem i EQS Standard søkemotor Standard søkeresultat Søkemotor med kategorier Søkeresultater med treff i ontolgier Navigering i søkeresultater med HTML-ramme Overordnet arkitektur Lagene i HTTPS [47] Aktuelt subsett av J2EE arkitekturen

160 FIGURER FIGURER 11.4 Aktuelt subsett av.net arkitekturen

161 Del III Kravspesifikasjon 155

162

163 Innhold 1 Innledning Hensikt Omfang Definisjoner Struktur Overordnet beskrivelse Systemets perspektiv Systemgrensesnitt Brukergrensesnitt Maskinvaregrensesnitt Programvaregrensesnitt Kommunikasjonsgrensesnitt Produktfunksjoner Moduler Identifisering av krav Brukerkarakteristikk Krav til arkitektur Krav til søkemodul Oversikt Eksternt grensesnitt Søkeforespørsler og resultater Administrative funksjoner Oppbygging

164 INNHOLD INNHOLD 4.4 Krav til grensesnitt Søkeprosess Presentasjonsprosess Krav til indekseringsmodul Krav til ontologimodul Ontologi Bruk Ikke-funksjonelle krav Ytelse Portabilitet Sikkerhet Brukergrensesnitt Brukerdokumentasjon Dokumentasjon av kode Testdokumentasjon A Begrepsordliste 189 B Use Case 193 B.1 Aktører i systemet B.2 Use Case-beskrivelser B.3 Forklaring av syntaks B.3.1 Syntaks for Aktør B.3.2 Syntaks for Use Case C Use Case-basert estimering 203 C.1 Kommentar D Sporingsmatriser 207 D.1 Funksjonelle krav D.2 Ikke-funksjonelle krav

165 INNHOLD INNHOLD E Diagrammer 211 E.1 Sekvensdiagrammer E.2 Dataflytdiagram

166 INNHOLD INNHOLD 160

167 Kapittel 1 Innledning Dette dokumentet omhandler kravspesifikasjonen. Dokumentet har som mål å skape en felles forståelse av prototypen for kunde og prosjektdeltakerne, for å unngå eventuelle misforståelser. 1.1 Hensikt En kravspesifikasjon har som mål å være en avtale mellom kunde og leverandør om hvilke krav og forventninger som stilles til et system, sammen med spesielle hensyn som må tas. Dokumentet vil være en felles plattform for videre diskusjon og realisering av systemet. 1.2 Omfang Kravspesifikasjonen gjelder for prototypen til et system for søk i helse-dokumenter i store databaser. Prototypen utvikles som et prosjekt i faget TDT 4290 Kundestyrt Prosjekt ved NTNU, med Extend AS som oppdragsgiver. Prototypen demonstrerer bruk av konsepter som Extend AS synes er interessante å prøve ut vedrørende ontologistøttet søk i dokumentdatabaser. Enkelte krav man vanligvis ville hatt til et ferdig produkt, vil derfor bli vurdert som mindre viktig, nettopp på grunn av at målet er en prototyp. Prototypen vil ikke være et ferdig produkt, og vil ikke gjøres klar til å kjøre i et produksjonsmiljø. Den vil fokusere på metoder for å forene en leksikalsk søkemotor med ontologi, sammen med hvordan denne forbindelsen kan gjøres synlig og enkel anvendbar for brukeren. Det overordnede målet med prosjektet er å øke evnen til informasjonsgjenfinning. 161

168 1.3. DEFINISJONER KAPITTEL 1. INNLEDNING 1.3 Definisjoner En ordliste med forklaringer av ord og definisjoner som er brukt i dette dokumentet er presentert i vedlegg A. 1.4 Struktur Kapittel 2 gir en oversikt over systemets struktur og mål. Avsnitt 2.1 presenterer miljøet som prototypen skal utvikles mot. Avsnitt 2.2 til 2.5 behandler hvilke problemer systemet skal løse og hvem som vil være brukerne. Kapittel 3 Kapittel 4 Kapittel 5 Kapittel 6 Kapittel 7 presenterer funksjonelle krav til den overordnede arkitekturen til prototypen. presenterer funksjonelle krav til søkemodulen. presenterer funksjonelle krav til indekseringsmodulen. presenterer funksjonelle krav til ontologimodulen. omhandler ikke-funksjonelle krav som stilles til prototypen. 162

169 Kapittel 2 Overordnet beskrivelse Dette kapitlet presenterer den overordnede strukturen til prototypen. Kapitlet presenterer ingen krav, men gir bakgrunnsinformasjon for kravene som presenteres i senere kapitler. 2.1 Systemets perspektiv Perspektivet prototypen skal operere i inneholder blant annet grensesnitt til andre systemer, grafisk brukergrensesnitt, krav til maskinvare for realisering og andre krav som stilles til kjøretidsmiljøet. Figur 2.1 viser et dataflytdiagram av systemet. I prosess 1 utføres autentisering av bruker og administrator slik at de får logget seg på systemet. Administrator er også avhengig av denne prosessen for å få tilgang til administratorfunksjonene. I prosess 2 blir dokumentenesamlingen indeksert, og resultatet av indekseringen blir lagret i indeksdatalageret. Det er bare administrator som har rettigheter til å utføre dette. I prosess 3 utføres søk på dokumentsamlingen på bakgrunn av søkeforespørsel fra bruker eller administrator. Prosessen bruker informasjon fra ontologi- og indeksdatalageret i søket. Prosess 3 leverer så søkeresultatet til prosess 4, som presenterer det mottatte resultatet til bruker eller administrator Systemgrensesnitt Målet med prototypen er å undersøke hvordan ontologistøttet søk kan gjøre det enklere for brukere å finne igjen informasjon. På grunn av at prototypen ikke utvikles for et produksjonsmiljø, trengs det ikke å ta hensyn til andre systemer eller eventuell skalerbarhet for å kunne passe inn i fremtidige systemer. 163

170 2.1. SYSTEMETS PERSPEKTIV KAPITTEL 2. OVERORDNET BESKRIVELSE Figur 2.1: Sammenheng mellom dokumenter, søkebegreper og ontologi Brukergrensesnitt Prototypen har i utgangspunktet bare ett grensesnitt mot andre brukere, og dette er et nettsidebasert grensesnitt som skal være tilgjengelig med en hvilken som helst nettleser. Det må være mulig å spesifisere søkekriterier for brukeren, og deretter få listet opp artikler fra dokumentbasen som samsvarer med søkekriteriene. Grensesnittene for spesifisering av søk og presentasjon av resultater må være enkelt å forstå for brukere med lite erfaring ved bruk av Internett-søkemotorer. Ingen kunnskap om ontologiers struktur og anvendelsesområder er påkrevd for å bruke systemet Maskinvaregrensesnitt For at søk skal gå effektivt, stilles det visse krav til maskinvareplattformen som prototypen kjøres på. Selv om det ikke stilles krav til maskinvaren, vil utførelsen av søk være avhengig av hvor effektiv plattformen kan utføre programkoden. I utgangspunktet anbefales følgende: 164

171 KAPITTEL 2. OVERORDNET BESKRIVELSE 2.2. PRODUKTFUNKSJONER x86-arkitektur (eller annen plattform med kompatibilitet i programvaregrensesnitt) 256 MB minne Minst 500 MHz prosessor Programvaregrensesnitt Følgende programvare er påkrevd for å kjøre prototypen: Apache Jakarta Tomcat 5.0 eller nyere Er tilgjengelig for både Windows- og UNIX-plattformer. Java eller nyere Er tilgjengelig for både Windows- og UNIX-plattformer. Eldre versjoner av denne programvaren kan støttes, men testing vil ikke bil foretatt for disse Kommunikasjonsgrensesnitt Prototypen kommuniserer med brukerne via et standard HTTP grensesnitt. Dette grensesnittet er en del av nettsidetjeneren som skal brukes, og vil ikke presenteres i større detalj her. Kommunikasjon internt mellom brukergrensesnitt (nettsidetjener) og søketjener skjer via et mellomvaregrensesnitt basert på Java RMI [1]. Siden både brukergrensesnitt og søketjener benytter seg av Java-baserte teknologier, er dette ønskelig. Java RMI omtales ikke nærmere her. 2.2 Produktfunksjoner Funksjoner som prototypen skal utføre inkluderer: Utføre søk etter tekst i en dokumentsamling. Utvide brukerens søkekriterier til også å inkludere relaterte ord til ord det søkes etter. Presentere ontologiske utvidelser til brukeren sammen med søkeresultater for å hjelpe brukeren med å videre raffinere søkekriterier. Ettersom det er en prototyp som skal utvikles, stilles det få krav til funksjonalitet som retter seg mot vedlikehold av databaser, oppdatering av indekser, og ingen krav til brukerstøttet oppdatering av ontologi. Noe prototypen ikke tar hensyn til, men som må sees på i en implementering til et produksjonsmiljø, er blant annet: 165

172 2.3. MODULER KAPITTEL 2. OVERORDNET BESKRIVELSE Administrering av dokumentsamlingen, og spesifisering av dokumenters metainformasjon. Søkealgoritmens ikke-funksjonelle krav, som for eksempel skalering til store datamengder, hastighet og pålitelighet. Optimalisering av brukergrensesnitt til de ulike bruksmåter som den vil inngå i. 2.3 Moduler Systemet inndeles i fire moduler: Brukergrensesnitt. Denne modulen presenterer søkegrensesnittet for brukeren, og har underliggende funksjonalitet for å kommunisere med ontologimodulen og søkemodulen. Søkemodul. Denne modulen inneholder funksjonalitet for søk i dokumentdatabasen og kommunikasjon med ontologimodulen for å utvide og begrense søket. Indekseringsmodul. ytelsen på søk. Denne modulen indekserer dokumenter. Dette gjøres for å øke Ontologimodul flere søkeuttrykk. Denne modulen har funksjonalitet for å finne relaterte ord til ett eller 2.4 Identifisering av krav Hvert krav tildeles en unik ID. Dette gjøres for å øke sporbarheten til kravene. Funksjonelle krav har en ID som starter med FK, mens ikke-funksjonelle krav har en ID som starter med IF. I hver krav ID tas det også med en bokstav som beskriver hvilken seksjon det tilhører. For eksempel står B for brukergrensesnitt. Strukturen blir da: <FK> eller <IF>- <en bokstav som beskriver seksjon><nummer>. Tabell 2.1 lister opp de forskjellige typene krav som er brukt. Kravene er basert på en forstudierapport gjort tidligere i prosjektet, og dekker ulike evalueringskriterier der. Koblingen mellom evalueringskriterier og de spesifikke kravene er definert i en sporingsmatrise i vedlegg D. 2.5 Brukerkarakteristikk Brukere av et eventuelt kommersielt system i et produksjonsmiljø, inkluderer ansatte i helsesektoren, som har lite eller ingen erfaring med søkemotorer. Mange ansatte i helsesektoren har lav erfaring med bruk av IKT-verktøy. Prototypen skal 166

173 KAPITTEL 2. OVERORDNET BESKRIVELSE 2.5. BRUKERKARAKTERISTIKK FK-A FK-G FK-S FK-P FK-I FK-O IF-Y IF-P IF-S IF-B IF-D Funksjonelle krav til arkitektur Funksjonelle krav til grensesnitt Funksjonelle krav til søkeprosess Funksjonelle krav til presentasjonsprosess Funksjonelle krav til søkeindeksering Funksjonelle krav til ontologibehandling Ikke-funksjonelle krav til ytelse Ikke-funksjonelle krav til portabilitet Ikke-funksjonelle krav til sikkerhet Ikke-funksjonelle krav til brukergrensesnitt Ikke-funksjonelle krav til dokumentasjon Tabell 2.1: Kravskategorier ta hensyn til dette, og basere seg på en minimalistisk presentasjon av innhold i brukergrensesnittet. Dette for å unngå IKT-spesifikk terminologi. Det kan være en rimelig antakelse at brukerne av en fremtidig løsning har kjennskap til Extends system EQS. En viss gjenkjenningsverdi og relatering mellom brukergrensesnittene kan derfor gi en flatere læringskurve for brukerne av prototypen. Testing må utføres med personell som er representative for prototypens potensielle brukere. Dette er beskrevet mer nøyaktig i testplanen (eget dokument). 167

174 2.5. BRUKERKARAKTERISTIKK KAPITTEL 2. OVERORDNET BESKRIVELSE 168

175 Kapittel 3 Krav til arkitektur I tillegg til krav til de forskjellige modulene, stilles det krav til den overordnede arkitekturen til prototypen. Dette for å skape en overordnet forståelse av hvordan prototypen fungerer som helhet. Klienten kjøres ved hjelp av en nettleser. Med denne skal klienten kunne kommunisere med tjeneren. Tjeneren bruker en database eller sekvensiell fil for å lagre søkeindekser. Se figur 3.1 for en overordnet illustrasjon over kommunikasjonen. Ontologibehandling, søk og håndtering/indeksering av dokumenter behandles på datatjeneren. De forskjellige enhetene på tjeneren kan befinne seg på samme fysiske maskin, men det er ikke et krav at de gjør det. Følgende krav stilles til prototypens arkitektur: Krav Beskrivelse av krav Vekting FK-A1 Klientmodulen for prototypen må være tilgjengelig via en nettleser. H FK-A2 Tjeneren skal ha en nettverksforbindelse. H FK-A3 Søkeprosessen skal utføres av datatjeneren. H FK-A4 Datatjeneren skal lagre søkeindekser. H FK-A5 Datatjeneren skal ha en ontologi tilgjengelig. H Tabell 3.1: Funksjonelle krav til arkitektur FK-A1 Med dette menes det at prototypen er tilgjengelig ved bruk av en hvilken som helst standard nettleser. FK-A2 Tjeneren skal kunne kommunisere med klienten over en nettverksforbindelse, enten over Internett eller et intranett. 169

176 KAPITTEL 3. KRAV TIL ARKITEKTUR FK-A3 Som vist i figur 3.1 består tjeneren av 3 hoveddeler; nettsidetjener, datatjener og database. Det er datatjeneren som skal behandle søking, bruk av ontologi og uthenting av søkeresultat. FK-A4 Databasen skal lagre søkeindekser basert på de dokumentene som foreligger i dokumentsamlingen. FK-A5 Datatjeneren skal ha tilgang til en ontologi som skal kunne brukes for å utvide eller konkretisere søkestrengen. Figur 3.1 viser overordnet hvordan de forskjellige enhetene Figur 3.1: Arkitekturmodell fungerer i forhold til hverandre. Når brukeren utfører et søk sender klienten en forespørsel som inneholder en søkestreng til nettsidetjeneren. Nettsidetjeneren sender søkestrengen videre til en datatjener der all dataprosessering foregår. Datatjeneren søker gjennom ontologien etter ord relatert til ord i søkestrengen. Dersom relaterte ord finnes legges disse til i søkestrengen. Deretter utfører datatjeneren søk i dokumentsamlingen basert på søkestrengen. Svar på søket returneres så nedover tilbake til nettsidetjeneren og til slutt tilbake til brukeren. Både søkemodulen og ontologimodulen ligger altså på datatjeneren. Nettsidetjeneren behandles ikke som en egen modul, ettersom denne er en Jakarta Tomcat tjener som bare brukes til å kommunisere med datatjeneren. 170

177 Kapittel 4 Krav til søkemodul Dette kapitlet inneholder de funksjonelle kravene som stilles til søkemodulens implementasjon i prototypen. Først presenteres kravene som stilles til modulens programmeringsgrensesnitt, deretter følger kravene som går direkte opp mot funksjonsmåten til søkealgoritmen. 4.1 Oversikt Søkemodulen er sammen med ontologimodulen det sentrale elementet i prototypen. Brukerens søkeforespørsler behandles ved at en rekke søkeord sendes til datatjeneren. Disse søkeordene vil bli satt i sammenheng med en ontologi, og utvidet for å også inkludere relaterte ord til søkeordene. Etter denne pre-prosesseringen vil den utvidede søkeforespørselen sendes til søkemodulen, som returnerer søkeresultater. Dette kapitlet gir bare en oversikt over de kravene som stilles til funksjonaliteten til søkemodulen, og hvordan denne forholder seg til andre deler av prototypen. 4.2 Eksternt grensesnitt Her spesifiseres kravene som stilles til det eksterne grensesnittet for søkemodulen. Det eksterne grensesnittet skal legge vekt på å være uavhengig av andre komponenter i prototypen Søkeforespørsler og resultater Søkeforespørsler er data som kommer fra brukere av systemet. Dette er en sekvens av ord, som videre er grunnlaget for informasjonsgjenfinning som blir foretatt. Dokumenter som blir funnet, returneres i form av veldefinerte objekter som angir dokumentenes overskrift, adresse og kategori, samt metainformasjon som forklarer hvilket grunnlag treffet blir gjort på. Dette er vist i sekvensdiagrammet i figur 4.1. Syntaksen til sekvensdiagrammer er forklart i et vedlegg i konstruksjonsdokumentet. Søkealgoritmen kommuniserer med nettsidetjeneren for å motta søkeforespørsler og returnere svar på disse. Denne kommunikasjonen 171

178 4.2. EKSTERNT GRENSESNITT KAPITTEL 4. KRAV TIL SØKEMODUL Figur 4.1: Sekvensdiagram for utføring av søk fungerer synkront, ved bruk av Java RMI. Data som kommer som parameter til søkemodulen er en rekke av ord som er adskilt av skilletegn. Skilletegnene kan være enten mellomrom eller tabulatortegn. Ord kan bestå av alle andre tegn i Unicode, men skal være formatert i tegnkodingen UTF-8. Data sendes tilbake til nettsidetjeneren i form av veldefinerte objekter. Innholdet skal være uavhengig av brukergrensesnittløsningen, og skal derfor ikke inneholde tekstoppmerking. Dette gjelder også tekstoppmerking som kommer fra eventuelle korte utdrag fra dokumentet. Et unntak for dette er ord som inngår i søkeforespørselen. Dette fordi trefford etter et søk bør utheves slik at brukeren enklere kan se ordene i et utdrag. Søkeforespørsler etterfølges av retur av enten feilkode eller søkeresultater. Resultater skal sendes tilbake til kallende modul innen 2 sekunder etter at søkeforespørselen er mottatt, ved søk i en dokumentsamling på 250 dokumenter Administrative funksjoner De administrative funksjonene av prototypen skal være enkle og adgangsbegrensede for å parametrisere systemet og utføre vedlikeholdsoperasjoner uten å måtte starte det på nytt. 172

179 KAPITTEL 4. KRAV TIL SØKEMODUL 4.3. OPPBYGGING Administrative funksjoner skal være tilknyttet brukergrensesnittet, og tillater systemansvarlige å utføre vedlikehold. Vanlige brukere skal ikke ha adgang til disse funksjonene. 4.3 Oppbygging Søkemodulen er den delen av systemet som finner forbindelser mellom søkeforespørsler skrevet inn av en bruker, og dokumentene i dokumentsamlingen. Modulen identifiserer hvilke dokumenter som har best samsvar med søkestrengen. Dette gjøres i indekseringsmodulen ved å identifisere søkeordenes frekvens i dokumenter. Modulen bygges opp som en selvstendig komponent, som skiller brukergrensesnitt fra den utførende delen av programmet. Dette gjøres for at komponenter enkelt kan byttes ut eller uten å samtidig måtte vedlikeholde andre komponenter som følge av endringene. Oppsummert punktvis vil modulen tilby følgende funksjonalitet: Foreta søk i dokumentsamlingen på grunnlag av en søkestreng, og returnere dokumenter som har samsvar med denne. Prioritere søkeresultatene etter hvilke som har best samsvar med søkestrengen. 4.4 Krav til grensesnitt Kravene som stilles til modulens grensesnittet sørger for at integrasjonen mot andre deler av systemet blir veldefinert. 173

180 4.5. SØKEPROSESS KAPITTEL 4. KRAV TIL SØKEMODUL Krav Beskrivelse av krav Vekting FK-G1 Algoritmen skal ikke returnere data som er spesifikk for brukergrensesnitt. H FK-G1.1 Returdata fra søkealgoritmens grensesnitt skal være fast strukturert data som kan behandles elektronisk. FK-G2 Bare nødvendige funksjonskall skal være tilgjengelige for omverdenen. M Tilstrekkelige funksjonskall for å utføre nødvendig inferens mot dokumentsamlingen må være tilgjengelig. FK-G3 Grensesnittet skal være økt-basert. H FK-G3.1 Data som tilhører en bestemt økt skal ikke være tilgjengelig for andre økter. FK-G3.2 En økt skal heller ikke påvirke operasjonsmåten til andre økter som er aktive samtidig. FK-G3.3 Økter skal avsluttes når nettleseren blir lukket. FK-G3.4 For hver økt skal det lagres informasjon om de sist brukte søkeuttrykkene. FK-G3.5 Data som lagres i økter skal slettes automatisk fra tjeneren etter 1 time uten at øktdata blir brukt. Tabell 4.1: Krav til eksterne grensesnitt FK-G1 Grunnen til at det stilles krav til at returdata skal være uavhengig av brukergrensesnitt, er at det ønskes å skape en modularitet i systemet, hvor elementer kan byttes ut, eller realiseres i en annen programmeringsomgivelse. Veldefinerte grensesnitt vil være behjelpelig både ved utvikling og utvidelse av brukergrensesnitt og eventuell feilsøking. FK-G2 Kravet vil gjøre utviklingen av systemet og feilsøking enklere. Det vil være enklere å tilpasse modulen til andre omgivelser. FK-G3 Økter (sessions) benyttes for å gi brukeren tilpasset tilbakemelding under søkeprosessen. Det ligger her også et personvernperspektiv: det legges til rette for at brukere kan logge ut av systemet ved å lukke nettleseren, og derved fjerne alle spor etter hva det er søkt etter. Innlogging til systemet og annen personlig identifiserbar informasjon vil ikke bli behandlet i denne prototypen. 4.5 Søkeprosess Kravene i tabell 4.2 rammer inn den sentrale funksjonaliteten som tilbys for omverdenen. 174

181 KAPITTEL 4. KRAV TIL SØKEMODUL 4.5. SØKEPROSESS Krav Beskrivelse av krav Vekting FK-S1 Søkemodulen skal ta imot sekvenser av nøkkelord og finne informasjon H i dokumentbasen som samsvarer med nøkkelordene. FK-S2 Ugyldige forespørsler til systemet må gjenkjennes, og veldefinerte M feilkoder må returneres når disse mottas. FK-S3 En standard Levenshtein-algoritme skal brukes for å finne alternative H ord, dersom søkeren taster et ord feil. FK-S4 En algoritme med vekting tilsvarende vektorsøk skal brukes. M FK-S4.1 Algoritmen skal benytte seg av TF-IDF kvantifisering. FK-S4.2 Søkeresultater skal rangeres etter hvor mange av brukerens søkeord som finnes i dokumentet, samt etter treffordenes TF- IDF vekting. FK-S5 Stemming skal utføres på søketermer for å forsøke å fjerne bøyingsformer. H FK-S5.1 Norske lemmatiseringsregler skal benyttes. FK-S5.2 Ord som er stemmet trenger ikke å være korrekt norsk. FK-S5.3 Ord som er stemmet kan presenteres til brukeren ved at ordstammen blir fremhevet i utdrag fra dokumentene. FK-S6 Ord som forekommer med jevn frekvens i alle dokumenter, H og som ikke har semantisk differensierende verdi, skal utelates (stoppord) fra søket. FK-S6.1 Stoppordlisten skal bestå av minst 100 ord som ikke er meningsbærende, i en helse-referansesamling. Tabell 4.2: Krav til søkeprosessen FK-S1 Dette kravet stilles til den overordnede funksjonaliteten til søkemodulen. Søkeforespørsler skal mottas og behandles av systemet. FK-S2 Veldefinerte feilkoder bør returneres, betyr at feilkoder ikke skal være udefinerte eller ha tilfeldige verdier. Feil som returneres tilbake til kallende moduler (nettsidetjener) skal være sporbare tilbake til den situasjonen som skapte dem. Ugyldige forespørsler defineres som ord kun bestående av spesialtegn, stoppord og blanke søk. FK-S3 En søkeforespørsel bør alltid gi et svar, med unntak av hvis ingen gyldige ord ble gjenkjent i søkeforespørselen. Dersom ugyldige ord oppdages, for eksempel ord som ikke fins i noen av indeksene, bør systemet foreslå nærmeste alternativ til dette ordet. FK-S4 Vektorsøk er nærmere forklart i forstudiet. Det er ikke et krav at algoritmen skal være et genuint vektorsøk, men at den skal tilsvare vektorsøk i måten som dokumenter vektes på. 175

182 4.6. PRESENTASJONSPROSESS KAPITTEL 4. KRAV TIL SØKEMODUL FK-S5 Både søkeord og i indeksene i systemet skal ord stemmes. På denne måten vil mange bøyingsformer bli eliminert. Lemmatiserte ord kan presenteres til brukeren i et forsøk på å fjerne tvetydighet, det vil si å forklare til brukeren hvorfor et bestemt søketreff ble oppdaget. FK-S6 En stoppordliste skal benyttes. Denne stoppordlisten kan genereres for eksempel ut fra dokumentsamlingen som Extend har gjort tilgjengelig for prosjektgruppen. 4.6 Presentasjonsprosess Presentasjonsprosessen for søkemodulen setter grenser for hvilke inndata og utdata som skal være mulig mot denne. Krav Beskrivelse av krav Vekting FK-P1 Som et resultat av søket, skal det returneres en liste over dokumenter H som passer til søkeforespørselen. FK-P2 Data som returneres for hvert søkeresultat inkluderer en oppsummering H av dokumentet eller utsnitt av det. FK-P3 Treff i ontologien skal vises med en annen oppmerking enn for M vanlige søketreff. FK-P4 Søkestrengen skal kunne utvides enten manuelt ved at brukeren skriver inn flere ord, eller ved hjelp av ontologien. H Tabell 4.3: Krav til presentasjonsprosessen FK-P1 Returdata fra prosessen bør være veldefinert og sortert etter hvor godt samsvar det er mellom nøkkelordene og dokumentet. Se også FK-S1. FK-P2 Oversikten over data som skal returneres er kursorisk, og mer opplysninger vil trolig være ønskelig, men dette vil bli belyst under design-fasen. FK-P3 Ord som kommer inn som et resultat av direkte bruker-input må eksplisitt merkes. Ord som kommer inn som resultat av ontologien bør merkes spesielt for ikke å forvirre brukeren. FK-P4 Dette går på grensesnittet til søkemodulen. Søkeforespørsler skal kunne endres etter første gang de er skrevet inn i systemet, ved å enten skrive inn flere ord, eller ved å gi ytterligere informasjon via ontologiske tilknytninger som er returnert med søkeresultater. 176

183 Kapittel 5 Krav til indekseringsmodul Indeksering er en prosess som gjøres for å øke ytelsen på søk. Dette oppnås ved å samle informasjon fra dokumenter i indekser som kan brukes til å utføre inferens mot dokumentsamlingen. Kravene som stilles må sees i sammenheng med søkemodulen, og målet med søkeindekseringen er å opprette en invers indeks som er en sentral del av søkemodulen. Krav til indekseringsmodul er definert i tabell 5.1 Krav Beskrivelse av krav Vekting FK-I1 Modulen må kunne gå gjennom dokumenter og indeksere ord i H en invers matrise. FK-I1.1 HTML-oppmerking i teksten må overses. FK-I1.2 Indeksereren må være i stand til å identifisere tittelen til dokumenter, og annen metainformasjon fra dokumentene. FK-I2 Ord i indeksen skal være stemmet for å eliminere bøyingsformer. H FK-I3 Systemet skal inneholde en liste over alle ord som forekommer H i dokumentsamlingen. FK-I4 Hvert felt i den inverse matrisen skal lagres som et flyttall, der M tallet angir en normalisert kvantifisering av ordets viktighet for hvert dokument. FK-I4.1 En TF-IDF vektingsalgoritme skal brukes for å kvantifisere ordets forekomst. FK-I5 Dokumenter skal kunne legges til i dokumentsamlingen uten at H det er nødvendig å gjenopprette hele søkeindeksen. FK-I6 Gjenoppretting av indekser bør kunne utføres uten at gamle indekser blir utilgjengelige for søkemotoren. Tabell 5.1: Krav til søkeindeksering 177

184 KAPITTEL 5. KRAV TIL INDEKSERINGSMODUL FK-I1 Overordnet funksjon. HTML-koder må ikke komme med i indekser, ettersom dette bidrar til ekstra støy. UTF-8 skal benyttes for å overholde kompatibilitet med andre språk. FK-I2 Ordindekser skal være stemmet for å eliminere bøyingsformer. FK-I3 Vokabularet bør til enhver tid ligge lagret i minnet for å optimalisere uthentingshastighet. Det bør også lagres til et ikke-volatilt medium (disk) slik at dokumenter ikke må re-indekseres om tjeneren må startes på nytt. FK-I4 Bestemmer hvordan indekser skal lagres. Dette kravet er en naturlig følge av bruk av vektorsøk. FK-I5 Det er antatt at det vil være forholdsvis høy gjennomstrømming av dokumenter i samlingen. Det bør derfor holdes orden på kvaliteten til indeksen til enhver tid, og foreslås for en administrator at dokumentsamlingen indekseres på nytt når mange endringer har blitt gjort. På denne måten vil det forsøkes å gi søkeindeksen en viss konsistens over tid, og samtidig ikke forstyrre systemets operasjon. FK-I6 Det skal være mulig å gjennomføre et søk samtidig som en reindeksering av dokumentene foretas. 178

185 Kapittel 6 Krav til ontologimodul Ettersom Extend per dags dato ikke har tilgang på noen ontologi innen domenet, må det som en del av prosjektet lages en ontologi som er tilpasset et utvalg av dokumentsamlingen. Dette kapitlet inneholder kravene til en slik ontologi. Kravene ville altså ikke vært relevante for et ferdig system, men brukes kun for prototypen som utarbeides i prosjektet. 6.1 Ontologi En ontologi definerer begreper og relasjoner mellom disse i et gitt domene, og fungerer som et semantisk leksikon over termene som brukes innenfor domenet. De funksjonelle kravene som søker å oppfylle dette er listet i tabell

186 6.1. ONTOLOGI KAPITTEL 6. KRAV TIL ONTOLOGIMODUL Krav Beskrivelse av krav Vekting FK-O1 Ontologien skal være en distinkt ressurs som har en egen unik H identifikator (URI referanse) FK-O2 Ontologien skal være mulig å endre og utvide. Dette gjelder H både stukturen og innholdet. FK-O3 Ontologien skal være entydig og konsistent. H FK-O4 Det skal være mulig å legge til metadata i ontologien (for eksempel L forfatter). FK-O5 Ontologien må kunne uttrykke komplekse klassedefinisjoner. H Dette innebærer subklasser av klasseuttrykk. FK-O6 Ontologien må kunne definere klasseegenskaper og subegenskaper. H FK-O7 Ontologien må kunne uttrykke klasse- og egenskapsekvivalens. H FK-O8 Ontologien skal inneholde minst 60 begreper. H FK-O9 Ontologien skal dekke minst 20 dokumenter fra dokumentsamlingen H til Extend. FK-O10 Ontologien skal genereres ved å hente ut statistisk informasjon fra dokumentene, for deretter å opprette ontologien basert på denne informasjonen. L Tabell 6.1: Funksjonelle krav til ontologien FK-O1 For at ontologien skal være offentlig tilgjengelig, og for at ontologien skal kunne utvide andre ontologier (ved å tilby ekstra definisjoner) må dette kravet være oppfylt. FK-O2 Dokumentsamlingen ontologien skal brukes til å søke i er dynamisk (dokumenter kan legges til, endres og fjernes). Dermed må også ontologien være mulig å endre, ettersom denne er definert ut fra innholdet i dokumentene. For å kunne identifisere noe i en ontologi må ontologien være entydig og konsi- FK-O3 stent. FK-O4 Det er nyttig å kunne lagre metadata i ontologien for å kunne lagre informasjon om forfatter, dato og versjon om ontologien. FK-O5 og FK-O6 Ontologien må kunne uttrykke et bredt spekter av kunnskap, samtidig som det skal være mulig å gjøre raske slutninger. Disse kravene er motstridende, men kan løses ved hjelp av komplekse klassedefinisjoner (som for eksempel å dele opp i subklasser/subegenskaper). Dette kravet gjør det også enklere å oppdage inkonsistens. FK-O7 Dette er nyttig i ontologier blant annet for å kunne uttrykke synonymer. 180

187 KAPITTEL 6. KRAV TIL ONTOLOGIMODUL 6.2. BRUK FK-O8 og FK-O9 For at ontologien skal kunne brukes til å eksemplifisere effektivisering av søk, bør den være av en viss størrelseorden. Denne må reflektere størrelsen på dokumentdatabasen. FK-O10 Ettersom det per dags dato ikke finnes noen offentlig tilgjengelig metode for å generere en ontologi ut fra dokumenter, må dette gjøres manuelt. For å forenkle denne prosessen, vil det være nyttig å hente ut statistisk informasjon (for eksempel telling av forekomster av ord) fra dokumentene. 6.2 Bruk av ontologien Ontologien skal brukes til å utvide brukerens søkestreng. Dette gjøres ved at ontologien inneholder ord og relasjoner mellom disse. Kravene i tabell 6.2 omhandler hvordan ontologien skal brukes til å utvide søket. Krav Beskrivelse av krav Vekting FK-O11 Søkestrengen skal utvides med relaterte ord før den sendes til H søkemodulen. FK-O12 Brukeren skal informeres om hva den faktiske søkestrengen M inneholder etter at den er modifisert. FK-O13 Dersom søkestrengen er utenfor ontologiens domene, skal søkestrengen sendes videre til søkemodulen uten å bli modifisert. H Tabell 6.2: Krav til sammenheng mellom ontologi og søk FK-O11 Dersom det finnes relaterte ord i ontologien skal søkestrengen utvides med disse. Eventuelle utvidelser skal eksplisitt merkes, slik at søkemodulen kan tolke hvilke deler av strengen som kommer fra ontologien. FK-O12 Når brukeren taster inn en søkestreng og denne blir endret, skal brukeren kunne se hva den faktiske søkestrengen er. FK-O13 De delene av søkestrengen som evt ikke har relaterte ord i ontologien skal sendes videre til søkemodulen uten å bli modifisert. På denne måten vil man sikre at det brukeren skriver inn uansett vil bli tatt med i søkeprosessen. 181

188 6.2. BRUK KAPITTEL 6. KRAV TIL ONTOLOGIMODUL 182

189 Kapittel 7 Ikke-funksjonelle krav Dette kapitlet tar for seg de ikke-funksjonelle kravene som stilles til systemet. Ikke-funksjonelle krav fokuserer ikke på systemets funksjonalitet, men andre egenskaper ved prototypen. Kapitlet tar også for seg krav til dokumentasjon. Det stilles krav til brukerdokumentasjon, implementasjonsdokumentasjon og testdokumentasjon. 7.1 Ytelse Ytelse er viktig i et søkesystem. Det er avgjørende for brukers inntrykk av systemets kvalitet at responstiden på søkeforespørsler er lav. Et potensielt problem med indekser er at de kan bli veldig store. Kravene til ytelse søker å redusere dette problemet. Krav Beskrivelse av krav Vekting IF-Y1 Søkeresultat skal foreligge innen fire sekunder. M IF-Y2 Lagerbehov for søkeindekser på sekundærlager bør være under 300 MB for dokumenter. L Tabell 7.1: Ikke-funksjonelle krav til ytelse IF-Y1 Fra brukeren trykker på Søk -knappen i brukergrensesnittet til resultat-siden foreligger, skal det maks gå fire sekunder. IF-Y2 Dette er viktig for å hindre at indeks ikke skal kreve for mye ressurser og fordi det er ønskelig at hele indeksen skal kunne lastes inn i arbeidsminnet for raskere tilgang. 183

190 7.2. PORTABILITET KAPITTEL 7. IKKE-FUNKSJONELLE KRAV 7.2 Portabilitet Det er ønskelig at prototypen skal kunne kjøres på ulike plattformer. I tillegg skal brukergrensesnittet være nettleseruavhengig. Krav Beskrivelse av krav Vekting IF-P1 Prototypen skal være plattformuavhengig. M IF-P2 Prototypen skal være nettleseruavhengig. H Tabell 7.2: Ikke-funksjonelle krav til portabilitet IF-P1 Prototypen skal kunne kjøres på IBM x86-kompatible maskiner, SUNs UltraS- PARC og Apples XServe-systemer. IF-P2 Prototypen skal kunne brukes i alle nettlesere som har støtte for HTML 3.2- standard eller høyere. 7.3 Sikkerhet I et eventuelt kommersielt system vil sikkerhet være avgjørende. Streng tilgangskontroll og kryptering av informasjon vil være nødvendig da et slikt system potensiellt vil ha tilgang til sensitiv informasjon. I prototypen er ikke sikkerhet hovedfokus, men innlogging av brukere er nødvendig for eventuelt å kunne tilby personlig tilpassede grensenitt og lagring av brukerhistorikk. Krav Beskrivelse av krav Vekting IF-S1 Tilgang til systemet skal være autorisert. L IF-S2 Ved inaktivitet i 60 minutter skal en økt automatisk avsluttes. L Tabell 7.3: Ikke-funksjonelle krav til sikkerhet IF-S1 For å få tilgang til å bruke systemet må brukeren logge på med brukernavn og passord. Det skal også være mulighet for en administrator å logge på systemet for å kjøre reindekseringer og gjøre annet vedlikehold. IF-S2 Brukeren skal bli logget ut, og må logge inn på nytt for å fortsette å bruke systemet. 184

191 KAPITTEL 7. IKKE-FUNKSJONELLE KRAV 7.4. BRUKERGRENSESNITT 7.4 Brukergrensesnitt Brukergrensesnittet skal realiseres som en nettside med mulighet for søk i dokumentsamlingen. Da søkesystemet skal kunne brukes av personell uten spesiell dataerfaring, vil det stilles strenge krav til brukervennlighet. Krav Beskrivelse av krav Vekting IF-B1 Grensesnittet skal være nettside-basert. H IF-B2 Systemet skal vises på en oversiktlig måte i vindusbaserte systemer H med oppløsning på 800*600 punkter eller høyere. IF-B3 Grensesnittet skal tilby enkel hjelpefunksjon. L IF-B4 Det skal være mulig for brukeren å navigere tilbake til søkeresultatene H etter å ha åpnet et dokument. IF-B5 Grensesnittet skal ligne søkesystemer brukere vil kunne ha H kjennskap til fra Internett. IF-B6 Systemet skal benytte standard-komponenter når det gjelder elementer i grensesnittet. H Tabell 7.4: Ikke-funksjonelle krav til brukergrensesnitt IF-B1 Koden til brukergrensesnittet skal være kompatibel med HTML 3.2-standarden. IF-B2 Med vindusbaserte systemer menes operativsystemer som kjører grafiske shell (no: skall). Grensesnittet skal først og fremst være tilpasset skriverbords-pcer. Grensesnittet skal ikke være tilpasset håndholdte enheters operativsystemer som PocketPC o.l. IF-B3 Ved å trykke på en lenke vil brukeren få tilgang til enkel hjelpefunksjon som beskriver systemets hovedfunksjoner og virkemåte. Hjelpefunksjonen vil i prototypen være begrenset, og bør i en fullverdig versjon av systemet utvides. IF-B4 Ved å navigere med nettleserens Tilbakeknapp eller ved å trykke på en lenke i brukergrensesnittet, skal brukeren kunne komme tilbake til søkeresultatet etter å ha åpnet et dokument, hvis dette dokumentet ikke viser seg å være det rette. IF-B5 Systemet skal ha visuelle likheter med store søkemotorer på Internett, som for eksempel Google og Altavista. Med dette menes at grensesnittet skal inneholde enkelt tekstfelt for innskriving av søkestreng, og knapp for å utføre søket. IF-B6 Standard-elementer er elementer som input-felt, søkeknapp og checkboxer. Bruk av slike standarder vil kunne sikre at brukeren vil skjønne hvordan systemet skal benyttes. 185

192 7.5. BRUKERDOKUMENTASJON KAPITTEL 7. IKKE-FUNKSJONELLE KRAV 7.5 Brukerdokumentasjon God brukerdokumentasjon er viktig for å forenkle opplæringen av brukere. Krav Beskrivelse av krav Vekting IF-D1 Systemet skal ha en informativ brukerdokumentasjon. M IF-D2 Brukerdokumentasjonen skal skrives med ikke-teknisk norsk. M IF-D3 Brukerdokumentasjonen skal være tilgjengelig i PDF-format. M Tabell 7.5: Krav til brukerdokumentasjon IF-D1 Prototypen skal ha en brukerdokumentasjon som skal kunne leses og forstås på under 1 time. IF-D2 Ved skriving av brukerdokumentasjonen skal det legges spesielt vekt på at språket som brukes skal være generell, ikke-teknisk norsk slik at dokumentet skal være brukbart også for folk uten spesiell dataerfaring. IF-D3 Da prototypen skal være plattformuavhengig er det også viktig at brukerdokumentasjonen er dette. Ved å bruke PDF-format vil denne kunne åpnes på forskjellige plattformer. 7.6 Dokumentasjon av kode Kravene i dette avsnittet legger føringer for hvordan koden skal dokumenteres. Siden prosjektet skal ende opp med en prototyp, og dermed et potensielt utgangspunkt for videreutvikling, er god dokumentasjon veldig viktig. Krav Beskrivelse av krav Vekting IF-D4 Koden skal dokumenteres nøye for at andre utviklere skal kunne H sette seg inn i koden. IF-D5 All kildekode skal dokumenteres i JavaDoc [2]. H Tabell 7.6: Krav til implementasjonsdokumentasjon IF-D4 Kildekoden som skrives skal dokumenteres for å gi andre utviklere muligheten til å sette seg inn i koden som er laget. Dette er spesielt viktig da dette prosjektet kun skal resultere i en prototyp som andre skal ta over og kunne videreutvikle. 186

193 KAPITTEL 7. IKKE-FUNKSJONELLE KRAV 7.7. TESTDOKUMENTASJON IF-D5 Koden som skrives skal dokumenteres ved å bruke JavaDoc. JavaDoc er et anerkjent format for dokumentasjon, og vil derfor være et naturlig valg. 7.7 Testdokumentasjon Testaktiviteten dokumenteres i eget fasedokument for testing. Testdokumentasjonen er viktig for å vise at systemet er skikkelig testet, samt for å få frem problemer som har oppstått og hvordan disse er blitt løst. Krav Beskrivelse av krav Vekting IF-D6 Alle testspesifikasjoner skal følge en felles mal. H IF-D7 Testresultater skal dokumenteres etter felles mal. H IF-D7.1 Hver enkelt test dokumenteres eksplisitt. IF-D7.2 Alle feil og medførende tiltak dokumenteres. IF-D7.3 Feil som ikke er rettet dokumenteres grundig, med forslag til hvordan problemet kan omgås/rettes opp. IF-D8 Sporingsmatriser skal benyttes for å spore tester til krav. H Tabell 7.7: Krav til testdokumentasjon IF-D6 For å sikre sporbarheten og konsistens i test-fasen er det viktig at alle tester følger en bestemt mal. Denne malen er beskrevet i detalj i testplan-dokumentet. IF-D7 Enten en test blir godkjent eller feiler er det viktig å få dokumentert resultatet av testen. Dette skal også følge maler satt opp i testplan-dokumentet. IF-D8 For å sikre at alle kravene blir dekket av de testene som utføres skal sporingsmatriser benyttes. Slike matriser gir god støtte i å spore hvilke tester som dekker hvilke krav. 187

194 7.7. TESTDOKUMENTASJON KAPITTEL 7. IKKE-FUNKSJONELLE KRAV 188

195 Vedlegg A Begrepsordliste API: Application Programming Interface et sett definisjoner for kommunikasjon mellom adskilte programdeler. EQS: Extend Quality System. Dagens løsning hos Extend. Funksjonelle krav: Krav til oppgaver som systemet må være i stand til å løse. HTTP: Hyper Text Transfer Protocol-kommunikasjonsprotokoll for Internett Ikke-funksjonelle krav: Krav som stilles til systemets operasjon, men som ikke er tilknyttet en bestemt brukerfunksjon. Indeksering: prosessen det er å lage en invers fil basert på ett eller flere dokumenter. Invers fil: Datastruktur som brukes for å raskt kunne gjøre oppslag på hvor ulike ord fins i et dokument eller en dokumentsamlingen. Det er en vanlig måte å ordne tekstsøk på. Java: Programeringsmiljø utivklet av Sun Microsystems. Java RMI: Java Remote Method Invocation brukes for kommunikasjon mellom objekter, ved å innføre veldefinerte grensesnitt mellom disse. JavaDoc: Java-dokumentasjonsformat som kan autogenereres utifra dokumentasjon gjort i kildekoden. Lemmatisering: Eliminering av bøyingsformer på ord. Levenshteinalgoritme: Algoritme som finner redigeringsavstand mellom ord. 189

196 VEDLEGG A. BEGREPSORDLISTE nettside-tjener: Med dette menes en tjener som lagrer og tilbyr visning av nettsider som kan leses av nettlesere. Ontologi: Definerer begreper og relasjoner mellom disse i et gitt domene. Fungerer som et strukturert, semantisk leksikon over de termene som brukes innenfor domenet Ordstamme: Grunnformen av et ord. (Grunnformen av mannen er mann.) PDF: Portable Document Format. Filformat som brukes mye til plattformuavhengig dokumentasjon. Session: Engelsk ord for økt. Stemming: Forsøk på å lemmatisere ord ved å bruke standardregler for fjerning av typiske bøyningsformer. Stoppord: Ord som forekommer ofte, men har ingen semantisk verdi når de blir tatt ut av kontekst. Stoppord vil vanligvis bare bidra til ekstra støy i søket dersom de er søketermer, og derfor er det ønskelig at slike ord både fjernes fra dokumentindekser og søkeforespørsler. Søketerm: Ord som det søkes etter. En term betyr vanligvis et teknisk ord, men her brukes ordet i dens vide betydning (alle ord, men stoppord blir ikke behandlet som søketermer). TF-IDF vekting: Teknikk for å kvantifisere hvor viktig et ords forekomst er i et dokument. TF-IDF gir verdier som er basert på hvor ofte ord forekommer i dokumentet i forhold til det som er vanlig i en dokumentsamling. Unicode: Unicode er et tegnsett med det formål å skape et standard tegnsett som støtter alle språk som er i praktisk bruk. URI-referanse: Unified Resource Identificator. En global unik indentifikator. Use Case: Norsk: Brukstilfelle. Mye brukt metode for å skissere eksplisitte brukstilfeller. Gjerne brukt for diskusjon mellom utvikler og kunde. UTF-8: 8-bits transformasjonsformat for Unicode. Vektorsøk: Teknikk for å undersøke likhet mellom tekstansamlinger, ved å bruke matrisealgebra. Likhet mellom dokumenter blir kalkulert ut fra hvor lik frekvensfordeling det er av ord i dokumentene. 190

197 VEDLEGG A. BEGREPSORDLISTE WWW: (World Wide Web). Hypertekstsystem som opererer over internett. Man bruker en nettleser til å lese deler av informasjon (dokumenter eller nettsider) fra nettsidetjenere. Man kan følge hyperlinkene på hver side til andre dokumenter eller sende informasjon tilbake til tjeneren. Å følge linker på denne måten kalles ofte å surfe på internett. Økt: En tidsavgrenset interaksjon mellom bruker og system. 191

198 192 VEDLEGG A. BEGREPSORDLISTE

199 Vedlegg B Use Case I dette vedlegget følger en rekke tekstlige Use Case for en del av kjernefunksjonene i prototypen. I avsnitt B.1 aktørene som interagerer med systemet. En aktør kan være både en person eller en systemmodul. I avsnitt B.2 følger Use Casene. Til slutt, i avsnitt B.3 følger en forklaring av syntaksen brukt i Use Casene. B.1 Aktører i systemet. Under beskrives de aktørene i systemet som er brukt i Use Case-beskrivelsene. Aktørene er både personer og systemmoduler. Aktør Beskrivelse Eksempel 1 - Bruker Brukeren er en person som bruker systemet for å søke. Sluttbruker. En ansatt på et sykehus. Aktør 1: Bruker Aktør Beskrivelse Eksempel 2 - System Overordnet aktør som omfatter alle andre aktører bortsett fra brukeren. OntoSearch Aktør 2: System 193

200 B.1. AKTØRER I SYSTEMET. VEDLEGG B. USE CASE Aktør Beskrivelse Eksempel Brukergrensesnitt Nettsidegrensesnittet i søkemotoren. nettside for søkesystem Aktør 2.1: Brukergrensesnitt Aktør Beskrivelse Eksempel Ontologimodul Ontologien og bruk av denne. Oversikt over begreper som finnes dokumentsamling samt relaterte ord og deres semantiske relasjoner til hverandre. Funksjonalitet som gjør atdette kan brukes for å utvide søkestrenger. Aktør 2.2: Ontologimodul Aktør Beskrivelse Eksempel Søkemodul Søkemodulen er den delen av systemet som henter ut treff og rangerer disse. Vektorsøk-basert modul som søker gjennom indekser og henter ut treff. Aktør 2.3: Søkemodul Aktør Beskrivelse Eksempel Tjener Aktør som innebærer annen funksjonalitet enn selve søkeprosedyren. Nettside-tjener, Datatjener etc.. Aktør 2.4: Tjener Aktør Beskrivelse Eksempel Indekseringsmodul Indekseringsmodul som lager indekser basert på dokumentbasen. Asynkron indekseringsenhet. Aktør 2.5: Indekseringsmodul. 194

201 VEDLEGG B. USE CASE B.1. AKTØRER I SYSTEMET. Aktør Beskrivelse Eksempel 3 - Administrator Person som har tilgang til utvidede funksjoner i systemet. Systemansvarlig for stedet der systemet skal implementeres. Aktør 3: Administrator. 195

202 B.2. USE CASE-BESKRIVELSER VEDLEGG B. USE CASE B.2 Use Case-beskrivelser Under følger Use Case-beskrivelser av de vanligste operasjonene i systemet. Da store deler av systemet baserer seg på bakgrunnslogikk og ikke så mye på mange muligheter for brukeren er Use Case-beskrivelsene bygget mer på interne hendelser og interaksjoner internt mellom moduler enn på brukerinteraksjon. Først kommer en overordnet funksjonalitet for systemet, og denne er siden brutt opp i mindre deler etter hvor det foregår interaksjon. Nummereringen av de forskjellige Use Case er gjort etter hvilket punkt i det overordnede caset som skal spesifiseres. Hvis for eksempel punkt 5 i Use Case 1 skal spesifiseres blir dette 1.5. Use Case 1 viser et Use Case av den overordnede funksjonaliteten i prototypen. Use Case 1 Mål: Forutsetning: Slutt-tilstand: Aktør: Trigger Beskrivelse Variasjoner Overordnet funksjonalitet. Brukeren skal få utført søk. Brukeren ønsker å utføre søk. Søket utført, resultat vist på skjerm. Bruker (B) System (S) Bruker ønsker å finne et dokument. Trinn Handling 1 B logger inn på systemet. 2 S åpner søkesiden. 3 B skriver inn ønsket søkestreng. 4 B trykker på knapp: Søk. 5 S utfører søket. 6 S viser søkeresultatet. 7 B trykker på et treff. 8 S viser dokumentet. Trinn Avvikende handling 2a Innlogging feiler grunnet feil brukernavn/passord. S viser en feilmelding, og tilbyr B om å logge inn på nytt. Use Case 1: Overordnet funksjonalitet til systemet. 196

203 VEDLEGG B. USE CASE B.2. USE CASE-BESKRIVELSER Use Case 1.1 viser et hvordan innlogging utføres. Use Case 1.1 Mål: Forutsetning: Slutt-tilstand: Aktør: Trigger Beskrivelse Variasjoner Innlogging Brukeren skal logge inn på systemet. Brukeren er registert bruker av systemet. Bruker er innlogget, økt startet. Bruker (B) Brukergrensesnitt (G) Tjener (T) Bruker ønsker å benytte systemet. Trinn Handling 1 B åpner URL til søkesystemet i nettleser. 2 G tilbyr innlogging. 3 B skriver inn brukernavn og passord 4 B trykker på knapp: Logg inn. 5 G tar imot brukerdata og sender til T. 6 T godkjenner brukernavn og passord. 7 G gir brukeren beskjed om at innlogging var vellykket, og åpner søkesiden. Trinn Avvikende handling 5a Tjener er ikke tilgjengelig. Feilmelding vises. 6a Brukernavn og/eller passord er feil. G viser feilmelding. Use Case 1.1: Innlogging. 197

204 B.2. USE CASE-BESKRIVELSER VEDLEGG B. USE CASE Use Case 1.5 viser utføring av søk. Use Case 1.5 Mål: Forutsetning: Slutt-tilstand: Aktør: Trigger Beskrivelse Variasjoner Utføring av søk. Systemet skal utføre søk. Brukeren er logget inn på systemet. Systemet returnerer søkeresultat. Brukergrensesnitt (G) Tjener (T) Ontologi (O) Søkemodul (S) Bruker har skrevet inn søkestreng og trykket Søk. Trinn Handling 1 G sender søkestreng til T. 2 T fjerner stoppord fra søkestreng. 3 O utvider søkestreng. 4 S slår opp i indekser etter søkestreng. 5 S rangerer søkeresultat og sender videre til G. 6 G viser rangert søkeresultat. Trinn Avvikende handling 4a O inneholder ingen utvidelser. Søkestrengen blir sendt uendret videre til S. Use Case 1.5: Utføring av søk. 198

205 VEDLEGG B. USE CASE B.2. USE CASE-BESKRIVELSER Use Case viser hvordan utvidelse av søkeuttrykk ved hjelp av ontologien foregår. Use Case Mål: Forutsetning: Slutt-tilstand: Aktør: Trigger Beskrivelse Variasjoner Utvidelse av søkeuttrykk vha. ontologi. Søkestrengen skal bli utvidet. Bruker har sendt søkestreng til systemet. Søkestreng er utvidet. Ontologimodul (O) Tjener (T) Søkemodul (S) Bruker trykker på søketreff. Trinn Handling 1 T sender søkestreng til O. 2 O analyserer søkestreng. 3 O finner relaterte ord og begrep til søkestreng. 4 O utvider søkestreng med disse. 5 O sender utvidet søkestreng til S. Trinn Avvikende handling Use Case 1.5.3: Utvidelse av søkestreng ved hjelp av ontologi. 199

206 B.3. FORKLARING AV SYNTAKS VEDLEGG B. USE CASE Use Case 2 viser hvordan indeksering av dokumenter utføres. Use Case 2 Mål: Forutsetning: Slutt-tilstand: Aktør: Trigger Beskrivelse Variasjoner (Re)Indeksering av dokumenter Oppdaterte indekser skal foreligge Det finnes dokumenter som ikke er indeksert Indekser er oppdaterte Indekseringsmodul (I) Administrator (A) Brukergrensesnitt (G) Bruker trykker på søketreff. Trinn Handling 1 A logger inn (se 1.1). 2 A trykker på knapp for (re)indeksering. 3 I setter semaforlås. 4 I indekserer forekomster i hvert dokument. 5 I skriver nye indekser til disk. 6 I setter ny indeks til aktiv indeks for systemet. 7 I sender melding om at indeksering er ferdig til G. 8 G viser melding til A. Trinn Avvikende handling Use Case 2: (Re)Indeksering av dokumentsamling. B.3 Forklaring av syntaks B.3.1 Syntaks for Aktør Dette avsnittet beskriver syntaksen brukt i aktørene, vha. tabell B.1. Hver aktør har en ID og et beskrivende navn. I tillegg har de en kort beskrivelse av aktøren. Til slutt følger et generelt eksempel på en slik aktør, som ikke har noen spesiell tilknytning til aktøren brukt i dette systemet. Aktør Beskrivelse Eksempel <ID> - <Navn> <Kort beskrivelse av aktøren> <Et generelt eksempel på en slik type aktør> Tabell B.1: Eksempel på aktør 200

207 VEDLEGG B. USE CASE B.3. FORKLARING AV SYNTAKS B.3.2 Syntaks for Use Case Dette avsnittet forklarer syntaksen på Use Casene, vha. tabell B.2. I tillegg til den unike IDen forklart i forrige avsnitt har hvert Use Case et mer beskrivende navn. Målet for hver operasjon blir så kort beskrevet, sammen med forutsetningen for å kunne utføre operasjonen. Den slutttilstanden som ønskes etter å ha utført en vellykket operasjon blir så kort beskrevet, før det listes opp de aktørene som spiller en rolle i det bestemte Use Case. Så blir det beskrevet en trigger. Denne triggeren kan sees på det siste handling som ble gjort før Use Caset begynner. Den bestemte handlings-rekkefølgen kommer så listet opp. Denne rekkefølgen kalles også ofte basis-sti. Hvis det skulle være noen mulige avvik fra denne basis-stien, er disse beskrevet i neste felt, nemlig ved hjelp av variasjoner. En variasjon identifiseres ved samme nummer som handlingen i basis-stien den avviker fra, etterfulgt av en bokstav a, b, c osv. hvis det er flere avvik fra samme punkt på basis-stien. UseCase nr <Navn på UseCase> Mål: <Målet for Use Casets operasjon> Forutsetning: <Forutsetningen for å kunne utføre operasjon> Slutt-tilstand: <Ønsket slutt-tilstand> Aktør: <Aktørene> Trigger <Hva er det som gjør at man kommer til denne forutsetningstilstanden?> Beskrivelse Trinn Punkt for punkt hvilke deloperasjoner som skjer. 1 Handling 1 2 Handling 2 3 Handling 3 4 Handling 4 5 Handling 5 Variasjoner Trinn Avvikende handling, hvis en slik skulle eksistere 1 Handling 1 2 Handling 2 3 Handling 3 4 Handling 4 5 Handling 5 Tabell B.2: Eksempel på Use Case 201

208 B.3. FORKLARING AV SYNTAKS VEDLEGG B. USE CASE 202

209 Vedlegg C Use Case-basert estimering Dette vedlegget tar for seg metoden med Use Case-basert estimering av arbeidsmengden som er forventet i implementasjonsfasen. Estimeringsmetoden er utviklet av Reidar Conradi (IDI/NTNU) og dr. Bente Anda (Simulasenteret/UiO). Den baserer seg på at man utifra kompleksiteten i use casene og en del andre parametre for kompleksitet i systemet og erfaringen til gruppemedlemmene skal kunne gjøre et estimat på antall timeverk som vil gå med i implementasjonen. Selve estimeringen er gjort ved hjelp av et Microsoft Excel regneark hvor man plotter inn de forskjellige parametrene som gjelder Use Case ene og gruppa som skal implementere systemet. Skjermbilde av regnearket med utfylte data for utviklingen av prototypen i dette prosjektet følger under C

210 VEDLEGG C. USE CASE-BASERT ESTIMERING 204 Figur C.1: Skjermbilde fra Use Case-estimering.

211 VEDLEGG C. USE CASE-BASERT ESTIMERING C.1. KOMMENTAR C.1 Kommentar Ved å analysere resultatet av estimeringen ser man raskt at denne antagelsen er helt urealistisk for dette prosjektet. Hele prosjektet inkludert alle fasene er estimert å ta 1860 timeverk, fordelt på seks personer. Implementasjonen er beregnet til å ta 10 % av dette. Man må dermed konkludere at estimeringsmetoden ved å bruke Use Cases ikke vil være særlig anvendbar i denne sammenhengen. Gruppa føler at det må legges mye sterkere føring på hvordan de forskjellige Use Case ene skal bygges opp med tanke på detaljnivå. Hvis slike føringer legges, er det grunn til å tro at estimatet vil kunne bli mye mer nøyaktig. 205

212 C.1. KOMMENTAR VEDLEGG C. USE CASE-BASERT ESTIMERING 206

213 Vedlegg D Sporingsmatriser Kravspesifiseringen har utgangspunkt i evalueringskriteriene presentert i forstudiet. I dette vedlegget følger sporingsmatriser for de forskjellige kravene, som viser hvilke evalueringskriterier de ulike kravene har sitt utgangspunkt i. Som det fremgår av matrisene er verken alle evalueringskriterier eller alle krav representert i matrisene. Følgende evalueringskriterier er utelatt: EV8, EV9, EV14, EV15, EV16 og EV17. Felles for alle disse kriteriene er at de går direkte på implementasjon av systemet, og er alle dekket gjennom valg av Java og JSP som implementasjonsspråk, samt Jena 2 som API mot ontologier. Videre mangler også EV11 om databaseuavhengighet. Dette fordi det ikke skal brukes databaser direkte prototypen. Kravene til dokumentasjon, IF- Dx, kan heller ikke spores tilbake til noen av evalueringskriteriene og er derfor ikke med i sporingsmatrisene. 207

214 D.1. FUNKSJONELLE KRAV VEDLEGG D. SPORINGSMATRISER D.1 Funksjonelle krav EV1 EV4 EV5 EV6 EV7 EV10 Krav FK-A1 X FK-A2 X FK-A3 X FK-A4 X FK-A5 X FK-G1 X X FK-G2 X FK-G3 X FK-S1 X FK-S2 X X FK-S3 X FK-S4 X FK-S5 X X FK-S6 X FK-P1 X FK-P2 X X FK-P3 X FK-P4 X X FK-I1 X X FK-I2 X X FK-I3 X X FK-I4 X X FK-I5 X FK-I6 X FK-O1 X X FK-O2 X FK-O3 X X FK-O4 X FK-O5 X X X FK-O6 X X X FK-O7 X X X FK-O8 X FK-O9 X FK-O10 X X FK-O11 X X FK-O12 X FK-O13 X EV11 EV18 EV19 EV20 Sporingsmatrise 1: Funksjonelle krav EV21 EV22 EV23 208

215 VEDLEGG D. SPORINGSMATRISER D.2. IKKE-FUNKSJONELLE KRAV D.2 Ikke-funksjonelle krav Krav IF-Y1 IF-Y2 IF-P1 IF-P2 IF-S1 IF-S2 IF-B1 IF-B2 IF-B3 IF-B4 IF-B5 IF-B6 EV1 EV2 EV3 EV10 EV11 EV13 EV21 X X X X X X X X X X X X Sporingsmatrise 2: Ikke-funksjonelle krav 209

216 D.2. IKKE-FUNKSJONELLE KRAV VEDLEGG D. SPORINGSMATRISER 210

217 Vedlegg E Diagrammer E.1 Sekvensdiagrammer I vedlegget beskrives notasjonen brukt i sekvensdiagrammer. Sekvensdiagrammer er modeller som beskriver hvordan grupper av objekter samhandler. 211

218 E.2. DATAFLYTDIAGRAM VEDLEGG E. DIAGRAMMER Objekt Objekt og livslinje. I et sekvensdiagram er objektet vist som et rektangel på toppen av en vertikal stiplet linje. Alle objekt har en livslinje, og lengen på linjen angir hvor lenge objektet lever. Aktiveringslinje. Aktiveringslinjen sier når objektet er levende og utfører en operasjon. a Ekstern aktør Aktør. Aktøren setter i gang prosessen som sekvensdiagrammet viser. meldingsnavn Melding. Meldinger er modellert som piler mellom objekter. Meldingsnavnet kan for eksempel være et funksjonskall. Retur. Returpilen indikerer et svar på en melding. Asynkron dataflyt. En melding kan bli spesifisert som asynkron dersom senderen fortsetter utførelsen, uavhengig av når den mottar respons av mottager. I dette vedlegget forklares modelleringsnotasjonen som er brukt i kravspesifikasjonen. E.2 Dataflytdiagram Et dataflytdiagram viser flyten og behandlingen av data i et system. 212

219 VEDLEGG E. DIAGRAMMER E.2. DATAFLYTDIAGRAM 1 Prosessnavn * Prosess. Behandlingen av data i systemet skjer i prosesser. Prosessnavnet beskriver hva behandlingen innebærer. Stjernen nederst til høyre i prosessen sier at den aktuelle prosessen ikke dekomponeres videre. Det vil si at det ikke vil bli spesifisert nærmere hva som faktisk skjer inne i prosessen. a Ekstern aktør Ekstern aktør. En ekstern aktør definerer en person eller organisasjonsenhet som interagerer med systemet. D1 Datalager Datalager. Et datalager et sted hvor data lagres, for eksempel en database. flytbeskrivelse flytbeskrivelse Dataflyt. En dataflyt representerer input eller outout av data til en prosess. 213

220 E.2. DATAFLYTDIAGRAM VEDLEGG E. DIAGRAMMER 214

221 Bibliografi [1] Sun Microsystems Inc. Java remote method invocation (java rmi) sun.com/products/jdk/rmi/. [2] Sun Microsystems Inc. Javadoc tool home page javadoc/. 215

222 BIBLIOGRAFI BIBLIOGRAFI 216

223 Tabeller 2.1 Kravskategorier Funksjonelle krav til arkitektur Krav til eksterne grensesnitt Krav til søkeprosessen Krav til presentasjonsprosessen Krav til søkeindeksering Funksjonelle krav til ontologien Krav til sammenheng mellom ontologi og søk Ikke-funksjonelle krav til ytelse Ikke-funksjonelle krav til portabilitet Ikke-funksjonelle krav til sikkerhet Ikke-funksjonelle krav til brukergrensesnitt Krav til brukerdokumentasjon Krav til implementasjonsdokumentasjon Krav til testdokumentasjon Aktører 1 Bruker System Brukergrensesnitt Ontologimodul Søkemodul Tjener Indekseringsmodul Administrator Use Case 1 Overordnet funksjonalitet til systemet

224 TABELLER TABELLER 1.1 Innlogging Utføring av søk Utvidelse av søkestreng ved hjelp av ontologi (Re)Indeksering av dokumentsamling B.1 Eksempel på aktør B.2 Eksempel på Use Case Sporingsmatriser 1 Funksjonelle krav Ikke-funksjonelle krav

225 Figurer 2.1 Sammenheng mellom dokumenter, søkebegreper og ontologi Arkitekturmodell Sekvensdiagram for utføring av søk C.1 Skjermbilde fra Use Case-estimering

226 FIGURER FIGURER 220

227 Del IV Konstruksjon 221

228

229 Innhold 1 Innledning Hensikt Omfang Definisjoner Struktur Teknologi Java JavaServer Pages (JSP) JSP-tjener (nettsidetjener) Javascript Ontologistandard Protégé JENA Systemarkitektur Moduler Søkemodul Ontologimodul Indekseringsmodul Brukergrensesnitt Felles verktøysett Kommunikasjon Grensesnitt Kjøretidsmiljø

230 INNHOLD INNHOLD 4 Filstrukturer Strategi for lagring i minne Strategi for lagring på disk Lagring av dokumenter Inverterte filer Brukergrensesnitt Søkeskjema Enkelt søk Avansert søk Presentasjon av resultat Fargekoding Brukerprofiler Normal bruker Administrator JSP filstruktur Søkemodul Oversikt Grensesnitt Algoritmer Algoritme søk-etter-tekst Algoritme søk-etter-tekst-i-kategori Feilkoder Begrensinger av design Indekseringsmodul Grensesnitt Algoritmer Algoritme indekser Algoritme indekser-dokument-ord Algoritme TFIDF Feilsituasjoner Begrensinger av design

231 INNHOLD INNHOLD 8 Ontologimodul Tilpasning Bruk av ontologi Grensesnitt Felles verktøysett Oversikt Stoppord Stemming Syntaksanalyse Levenshtein A Begrepsordliste 261 B Diagrammer 263 B.1 Komponentdiagram B.2 Klassediagram B.3 Use case diagram

232 INNHOLD INNHOLD 226

233 Kapittel 1 Innledning Dette kapitlet beskriver konstruksjonen av systemet og det arbeidet som er gjort for å lage en løsning som tilfredsstiller kravspesifikasjonen [3] på en best mulig måte. 1.1 Hensikt Konstruksjonen er utviklet for å klargjøre hvordan de ulike modulene i systemet fungerer, hvordan de samarbeider og hvordan de skal implementeres. Dette dokumentet er på mange måter en utvidelse av kravspesifikasjonen. Mange valg som ble gjort i kravspesifikasjonen vil sees på som implisitte for innholdet her. 1.2 Omfang Meningen med konstruksjonen er ikke å vise alle sider av systemet i full detalj, men å demonstrere at løsningen som er valgt lar seg implementere. Kravene som ble stilt til systemet i kravspesifikasjonen settes her inn i en overordnet arkitektur av systemet, og inngår i en plan for å enklest mulig behandle den kompleksiteten som systemimplementasjonen har. Det gjøres ingen direkte sporing til kravspesifikasjonen i dette kapitlet. Dette er behandlet i testfasen [4]. 1.3 Definisjoner En ordliste med forklaringer av ord og definisjoner er presentert i vedlegg A. 1.4 Struktur Kapittel 2 presenterer valgte teknologier som skal brukes for å realisere systemet. 227

234 1.4. STRUKTUR KAPITTEL 1. INNLEDNING Kapittel 3 viser en overordnet oversikt over hvordan systemet er organisert, sammen med organisering av ressurser i filsystemet og hvordan ulike grensesnitt mellom modulene er designet. Kapittel 4 presenterer ulike datastrukturer som brukes av systemet, sammen med teknikker som brukes for å behandle disse strukturene i primær- og sekundærlager. Kapittel 5 viser oppbygningen av brukergrensesnittet til systemet, og hvordan dette interagerer med en nettsidetjener. Kapittel 6 søk. Kapittel 7 Kapittel 8 Kapittel 9 av systemet. beskriver søkemodulen i systemet, og algoritmene som brukes for å utføre beskriver indekseringsmodulen og dens oppbygning i systemet. viser hvordan en ontologi brukes på toppen av søkemodulen. viser utformingen av et verktøysett av Java-klasser som brukes av ulike deler 228

235 Kapittel 2 Teknologi Ettersom valg av programmeringsspråk og utviklingspakker legger føringer på designet av systemet, må det i forkant av konstruksjonen besluttes hva slags teknologier som skal brukes ved implementasjon. I dette kapitlet omtales teknologiene som skal brukes, og hvordan disse muliggjør realisering av kravene i kravspesifikasjonen. Teknologiene er beskrevet i forstudiet. 2.1 Java Java (versjon J2SE 1.4.2) skal brukes som programmeringsspråk på nettsidetjeneren og datatjeneren i systemet. Java har innebygd støtte for nettverkskommunikasjon med Remote Method Invocation (RMI). Dette gjør at forskjellige enheter i nettverket kan kommunisere seg i mellom ved å indirekte kalle metoder hos hverandre. Java RMI brukes i kommunikasjonen mellom nettsidetjeneren og datatjeneren. Dette valget er tatt for å muliggjøre en distribuert arkitektur, og gi bedre skalerbarhet for bruk sammen med større dokumentmengder. 2.2 JavaServer Pages (JSP) JSP skal brukes til å implementere nettside-grensesnittet i systemet. Ettersom JSP-dokumenter blir bygd opp i Java ved kjøring, og derfor gjør det enkelt å kommunisere med med andre Java-systemer, har valget falt på dette språket JSP-tjener (nettsidetjener) JSP-tjeneren som skal brukes er Apache Jakarta Tomcat, versjon

236 2.3. JAVASCRIPT KAPITTEL 2. TEKNOLOGI 2.3 Javascript Javascript brukes for å utvide funksjonaliteten i JSP-sidene. JavaScript-koden skal fungere med både Internet Explorer document.all-syntaks og den mer standard getelementbyid()- syntaksen til moderne nettlesere. 2.4 Ontologistandard OWL Lite skal brukes som ontologistandard. OWL Lite tilbyr et funksjonelt subsett av OWL som er tilstrekkelig for ontologien som skal utvikles for systemet Protégé For å lage ontologien i systemet brukes Protégé-2000, versjon Protégé lar brukeren redigere en domeneontologi ved å angi klasser av objekter, instanser av objektene og relasjoner mellom disse JENA JENA (versjon 2.1) skal brukes for interaksjon med ontologien. JENA rammeverket tilbyr et fullstendig API med metoder for manipulering av RDF-modeller. Rammeverket har et subsystem for ontologier basert på RDF. Dette subsystemet støtter OWL, og har et eget inferenssystem tilpasset dette. 230

237 Kapittel 3 Systemarkitektur Dette kapitlet gir en detaljert oversikt over systemets arkitektur, sammen med de koblinger mellom moduler som er nødvendige for å få den nødvendige funksjonaliteten i systemet. Videre beskrives kjøretidsmiljøet som systemet vil operere innenfor. 3.1 Moduler Systemet deles opp i flere ulike moduler for å oppnå en viss oppdeling av koden. Dette gjøres for å forenkle feilsøking, integrasjon og utvikling. Modulene vil kunne operere delvis uavhengig av hverandre og vil derfor kunne testes separat. Hver modul realiseres som en egen Java-pakke for å isolere funksjonalitet og redusere krysskoblinger mellom disse. Et felles verktøysett som tilbyr tjenester som er felles for alle modulene, vil også konstrueres. Figur 3.1 viser et pakkediagram av pakkene systemet deles inn i. Diagramtypen er beskrevet i vedlegg B.2. Figur 3.1: Pakkediagram for systemet 231

238 3.1. MODULER KAPITTEL 3. SYSTEMARKITEKTUR Søkemodul Java-pakke ontosearch.search Beskrivelse Søkemodulen mottar sekvenser av nøkkelord som en søkeforespørsel, og returnerer en liste over dokumenter som passer best med kriteriene i søkeforespørselen Ontologimodul Java-pakke ontosearch.ontology Beskrivelse Behandlingen av ontologi splittes ut i en egen modul, som er ansvarlig for å omforme søkeforespørsler til å inkludere relaterte begreper, samt å behandle søkeresultater som kommer tilbake fra søkemotoren Indekseringsmodul Java-pakke ontosearch.index Beskrivelse Indekseringsmodulens oppgave er å ha en oppdatert liste over alle dokumenter det skal søkes i. Basert på disse dokumentene skal modulen opprette søkeindekser som brukes for å effektivisere søk Brukergrensesnitt Java-pakke Brukergrensesnittet utvikles som JSP-dokumenter, og holdes utenfor normal pakkestruktur. Dette gjøres fordi JSP-dokumenter lagres i en flat struktur i nettsidetjeneren Tomcat, og innføring av pakkestruktur gir unødig kompleksitet. Beskrivelse Brukergrensesnittet realiseres som en rekke nettsider som bistår brukeren i prosessen å finne informasjon. Den behandler all direkte interaksjon med brukeren og sender søkeforespørsler til søkemodulen Felles verktøysett Java-pakke ontosearch.toolkit Beskrivelse Et felles verktøysett med funksjonalitet som stemming, identifisering av stoppord og felles lagringsstrukturer må utvikles. Egendefinerte datatyper og klasser som brukes i grensesnitt mellom ulike moduler skal ligge her, for å ha høy grad av isolering i pakkestrukturen. 232

239 KAPITTEL 3. SYSTEMARKITEKTUR 3.2. KOMMUNIKASJON 3.2 Kommunikasjon I dette avsnittet skisseres kommunikasjonsgrensesnittene mellom modulene i systemet. Overordnet skjer kommunikasjon gjennom disse grensesnittene: Kommunikasjon mellom bruker og brukergrensesnitt: Dette grensesnittet består av en nettleser som kommuniserer over HTTP-protokollen mot en Tomcat nettsidetjener. Grensesnittet baserer seg på tredjeparts programvare, og vil ikke behandles i detalj. Kommunikasjon mellom Tomcat nettsidetjener og søketjener: Nettsidene, som skal realiseres i språket JSP, vil benytte seg av Java RMI for å kommunisere med søketjeneren. Søketjeneren er da ment som en forening av modulene søkemodul, ontologimodul og indekseringsmodul. Kommunikasjon mellom elementene i søketjeneren: Intern kommunikasjon mellom delene i søketjeneren gjøres via veldefinerte grensesnitt. At det er stabile grensesnitt vil være nødvendig for å ha en god, modulær struktur, og sørge for stabilitet i kodebasen. Dette gjøres for å sørge for at moduler kan endres hver for seg, uten at det blir store endringer på tvers av modulene. 3.3 Grensesnitt Ontologimodul Indekseringsmodul Søkemodul Brukergrensesnitt Figur 3.2: Systemarkitektur Figur 3.2 viser den overordnede arkitekturen til systemet i form av et komponentdiagram. Diagramtypen komponentdiagram er forklart i vedlegg B.1. En samling dokumenter blir indeksert ved hjelp av en indekseringsmodul (kapittel 7). Dokumentindeksene, som primært består av en ordliste, benyttes i en søkemodul (kapittel 6) for å returnere relevante dokumenttreff. En ontologimodul (kapittel 8) står for støtte både til selve søkeprosessen og for brukergrensesnittets presentering av søkeresultater. 233

240 3.4. KJØRETIDSMILJØ KAPITTEL 3. SYSTEMARKITEKTUR 3.4 Kjøretidsmiljø Kjøretidsmiljøet til datatjeneren skal være basert på en fast katalogstruktur. Katalogstrukturen som systemet skal realiseres i er som følger:./ Hovedkatalog (indekser, ontologi, konfigurasjon)./ontosearch Katalog for klasser (ontosearch.*)./ontosearch/search Katalog for klasser (ontosearch.search.*)./ontosearch/ontology Katalog for klasser (ontosearch.ontology.*)./ontosearch/index Katalog for klasser (ontosearch.index.*)./ontosearch/toolkit Katalog for klasser (ontosearch.toolkit.*)./logs Loggfiler for sporing av pålitelighet, ytelse og feil../web Nettsider for brukergrensesnitt Plasseringen til dokumentene som skal brukes av søkesystemet må kunne spesifiseres av konfigurasjonsfiler. Det kreves ikke at disse ligger i katalogstrukturen til systemet, men de må være tilgjengelig via filsystem, for eksempel NFS eller samba. Koden i kjøretidsmiljøet vil bli speilet over i en plassering slik at de blir tilgjengelige for nettsidetjeneren. For Tomcat sin del blir dette katalogen./webapps/app/web-inf/classes/. Nettsidene blir for sin del flyttet til./webapps/app/ ved oppstart av datatjeneren. Kjøretidsmiljøet til systemet vil være avhengig av følgende tre samtidig kjørende prosesser: Nettsidetjener (Apache Jakarta Tomcat), som også benytter seg av RMI-klientkode. RMI-register (rmiregistry), korrekt plassering. som tar imot RMI-oppslag og direkterer forespørsler til Datatjener, som fungerer som RMI-tjener og registrerer seg som en tjeneste hos RMIregisteret. Denne behandler søkeforespørsler, og setter igang en indekseringstråd etter behov. 234

241 Kapittel 4 Filstrukturer I dette kapitlet beskrives det hvordan ulike datatyper behandles internt i systemet, og hvordan disse lagres på disk. Datamengdene som lagres i informasjonsgenfinningssystemet til Extend er i størrelsesorden noen hundre MB, og det er derfor viktig at søk i strukturene er effektivt. 4.1 Strategi for lagring i minne Når man skal lagre data i minnet er det viktig at data blir lett tilgjengelig. Dette innebærer at programmet enkelt får tilgang til alle data, samtidig som prosessen med å hente data benytter minimalt av prosessortid. Datastrukturer bør også beskyttes fra ulovlig tilgang slik at det er vanskelig å skade data som ligger der. Dette kan gjøres ved å innkapsle data i Java-klasser som har begrenset mulighet for endring av data. 4.2 Strategi for lagring på disk Ved lagring av data på disk er det viktig at data som blir lagret tar lite plass på lagringsmediumet. Dette fordi tiden brukt på å aksessere data bedres, og det skalerer bedre med større datamengder. Feilsjekking og versjonshåndtering er også viktige aspekter ved lagring til sekundærlager. I dette prosjektet løses problemer rundt feilsjekking og versjonskontroll ved hjelp av Java Serialization. Serialization er en teknikk i Java som brukes for å automatisk skrive innholdet av Java-klasser til en utstrøm, sammen med eventuelle underklasser. På samme måte som instanser av Java-klasser enkelt kan skrives til disk, kan de også leses inn enkelt. Teknikken har god støtte for versjonskontroll. Serialization kan også brukes i sammenheng med komprimering av data. Ulempen ved å bruke en slik teknikk, er at det kan redusere ytelsen. 235

242 4.3. LAGRING AV DOKUMENTER KAPITTEL 4. FILSTRUKTURER 4.3 Lagring av dokumenter Klassen DocumentStore holder oversikt over hvilke dokumenter det skal søkes i. Den vedlikeholder en liste av Document instanser. Lister over dokumenter ligger alltid både i minnet og på disk. Klassediagram er vist i figur 4.1. Diagramtypen er beskrevet i vedlegg B.2. Figur 4.1: Document og DocumentStore klassene 4.4 Inverterte filer I begrepet invertert fil snakkes det om to filer. Den første filen inneholder en ordliste i form av en tabell med informasjon om ordforekomster i dokumentsamlingen og statistikk for hvor mange ganger et ord forekommer totalt i dokumentsamlingen, samt hvor mange ganger ordet forekommer i det dokumentet som har flest forekomster av det aktuelle ordet. Halen til tabellen inneholder en lenke til en array som ligger i den andre av de inverterte filene. Java Serialization tar seg av innholdet i tabellen til den første filen. Funksjonaliteten til Java Serialization er kort beskrevet i 4.2. Som nevnt tidligere lenker halen i tabellen i den første filen til en array i den andre. Denne arrayen inneholder informasjon om hvilke dokumenter (ID til dokument) som inneholder det aktuelle ordet, og et flyttall som angir ordets viktighet i dokumentet. Hver linje i ordlisten har en slik array knyttet til seg. Arrayen blir fylt opp serielt, med laveste dokument ID først. Flyttallene beregnes av TF-IDF algoritmen som beskrives i Figur 4.2 illustrerer inverterte filer. Figur 4.2: Invertert fil 236

243 Kapittel 5 Brukergrensesnitt Dette kapitlet presenterer designet av det grafiske brukergrensesnittet i systemet. For å kunne teste ut flere måter å bruke ontologien blir det designet to typer grafisk brukergrensesnitt, et for enkelt søk og et for avansert søk. 5.1 Søkeskjema Dette avsnittet tar for seg de to forskjellige søkeskjemaene. Det vektlegges å lage et stilrent brukergrensesnitt som er enkelt å bruke. Det skal i begge søkeskjemaene være en lenke til en tekstlig utskrift over ordene som finnes i ontologien, samt struktur og nivåer Enkelt søk Det enkle søket består av et felt der brukeren kan taste inn ett ord eller en sekvens av ord, og en søkeknapp. I tillegg er det en kobling til siden for avansert søk. Selve presentasjonen av siden for søkingen vil være ganske enkel. En skisse av det enkle søket finnes i figur 5.1. Dette brukergrensesnittet vil ikke forstyrre brukeren med elementer som kan virke forvirrende, og vil ha en stor grad av sammenlignbarhet med mye brukte søkesystemer, for eksempel Google. I denne typen søk brukes ontologien ved at søkebegrepet utvides med relaterte begreper dersom dette foreligger i ontologien. Dersom relaterte begreper ikke finnes i ontologien, fungerer søket som et vanlig søk, uten bruk av ontologi Avansert søk Avansert søk skiller seg fra enkelt søk ved at brukeren i tillegg skal kunne interagere direkte med ontologien. Dette gjøres ved at ontologien vises som et hierarki med avkrysningsbokser, med mulighet for å utvide nivåene og velge begreper man ønsker å søke etter. Ved å krysse 237

244 5.2. PRESENTASJON AV RESULTAT KAPITTEL 5. BRUKERGRENSESNITT Figur 5.1: Eksempel på brukergrensesnitt av på et begrep vil det bli utført søk etter dette begrepet. Dette begrepet vil ikke bli utvidet i ontologien, slik et innskrevet søk i tekstboksen vil bli. Grunnen til dette er at en avkrysning sees på som at brukeren ønsker å søke på nøyaktig dette begrepet. Hvis brukeren ønsker en spesifisering av dette begrepet skal det være enkelt å finne dette begrepet i nivået under i hierarkiet. Det skal i tillegg være enkelt å spesifisere og generalisere søkebegrepet ved hjelp av ontologien, i søkeresultatet. 5.2 Presentasjon av resultat Resultatsiden vil ha en toppdel som er lik som søkeskjemaet; logoen, tekstboks og søkeknapp. Tekstboksen vil inneholde det eksakte begrepet brukeren har søkt etter. Brukeren kan manipulere begrepet som står i tekstboksen og trykke på søkeknappen for å utføre et nytt søk. Under tekstboksen vil brukeren få informasjon om søkeresultatet. Begrep ikke funnet i dokumentsamlingen Dersom søkebegrepet brukeren la inn ikke finnes i noen dokumenter, vil brukeren få beskjed om at begrepet ikke ble funnet. 238

245 KAPITTEL 5. BRUKERGRENSESNITT 5.3. FARGEKODING Forslag til nærliggende ord Dersom begrepet ikke ble funnet i dokumentsamlingen, vil brukeren få forslag om å søke på begrep i dokumentsamlingen som stavemessig ligner. Det foreslåtte begrepet vil bli vist som en lenke, med en stjerne til slutt. Stjernen markerer at dette er ordstammen. Dersom uttrykket bil* blir foreslått, vil dette bety at ved å trykke på lenken blir det foretatt et søk etter alle begreper med bil som ordstamme. Resultatene kan være bil, biler, bilene osv. Det eksakte søkebegrepet I hvert søk som gir treff skal brukeren få beskjeden Ditt søk på <søkebgrep> ga <antall treff> treff. Dersom søkebegrepet finnes i ontologien, skal søkebegrepet her være en lenke. Ved å trykke på denne lenken skal bruken kunne generalisere og spesifisere søkebegrepet (ved å navigere seg opp og ned i ontologiens nivåer der begrepet finnes). Utvidelser i ontologien Dersom brukeren har skrevet inn et søkebegrep i tekstfeltet, og dette søkebegrepet finnes i ontologien, vil søkemotoren utvide søket ved også å søke på begrepene i det første nivået under selve søkebegrepet. Brukergrensesnittet skal da liste opp hvilke begrep søket er blitt utvidet med. Det skal også gi brukeren mulighet til å navigere seg rundt i ontologien for å generalisere og spesifisere disse utvidede begrepene, på samme måte som for det eksakte søkebegrepet. Liste med resultat Resultatene vil bli listet opp som i figur 5.2. Hvert treff skal komme opp med noen faste elementer. Øverste linje vil være dokumentets tittel. Denne vil være klikkbar, og peke på dokumentet som er funnet. Under denne linjen vil det komme et utdrag av dokumentet, der begrepet som ble funnet, er uthevet med fargekoding. Både de(t) ekstakte søkebegrep(ene) og utvidelser skal merkes. Dette utdraget av dokumentet kan være på 2-3 linjer. Under dette utdraget vil det bli listet opp inntil 7 begreper som finnes både i ontologien og dokumentet. Begrepet med størst forekomst i dokumentet skal komme først. Disse begrepene skal være klikkbare, og gi brukeren mulighet til å legge til begrepet til søkestrengen hvis ønskelig. 5.3 Fargekoding For å skille mellom resultater på det eksakte søkebegrepet og treff i ontologien, vil det brukes fargekoding. Det eksakte søkebegrepet vil bli merket med en sterk grønnfarge, mens utvidelser i ontologien vil bli merket med en rødfarge. Fargene er valgt ut for at de ikke kan blandes sammen med andre farger på siden. Denne fargekodingen vil bli brukt både øverst i resultatet der brukeren blir opplyst om begrepene det er søkt på, og i utdraget fra hvert dokument (dersom begrepet er listet opp i utdraget). Et eksempel på dette er vist i figur

246 5.4. BRUKERPROFILER KAPITTEL 5. BRUKERGRENSESNITT Figur 5.2: Eksempel på brukergrensesnitt ved resultatvisning 5.4 Brukerprofiler For å bruke systemet kreves det at brukeren logger seg på. Brukere kan ha to tilgangsnivåer; normal bruker eller administrator. Det vil ikke lages noe avansert autentiseringssystem i denne prototypen. Det vil være en enkel innlogging for å få tilgang til systemet. Dette blir påloggingen for Normal bruker. I tillegg vil en bruker måtte autentisere seg med et brukernavn og passord, for å få tilgang til administrasjonsdelen Normal bruker Ved å logge seg inn som normal bruker, vil ikke brukeren ha tilgang til noe annet enn selve søkemotoren Administrator Ved å trykke på lenken Administrasjon i brukergrensesnittet, vil brukeren bli spurt om brukernavn og passord. Etter denne autentiseringen vil brukeren få tilgang til en admini- 240

247 KAPITTEL 5. BRUKERGRENSESNITT 5.5. JSP FILSTRUKTUR Figur 5.3: Brukerprofiler og tilgang strasjonsside. På denne siden kan en administrator se informasjon som antall dokumenter som er indeksert, antall ord i ontologien og historikk over siste søkebegreper som er brukt. Administratoren vil også kunne oppdatere indekser og gjøre full reindeksering av dokumentsamlingen. 5.5 JSP filstruktur index.jsp Hoveddokument for søkemotoren. Presenterer en boks hvor brukeren kan skrive inn søkeforespørsel, sammen med ontologiutvidelse. resultat.jsp Resultatdokument. Viser resultatene av et søk, og gir brukeren muligheter til å raffinere søket videre. hjelp.jsp Hjelp til brukeren om bruk av systemet, og eksempler på hvordan en kan søke for å få best mulig resultater. admin.jsp Administratorside som krever spesiell autentisering, og som lar en administrator starte re-indeksering av dokumentsamlingen og lignende. 241

248 5.5. JSP FILSTRUKTUR KAPITTEL 5. BRUKERGRENSESNITT 242

249 Kapittel 6 Søkemodul Søkemodulen i systemet vil bli utformet med tanke på at den skal være generell og kunne bli brukt med ulike typer inndata. Ved å redusere kompleksiteten på data som kommer inn og går ut, vil det være enklere å verifisere funksjonsmåten. 6.1 Oversikt Forstudiet [2] konkluderte med at søkealgoritmen i systemet vil være basert på standard vektorsøk med TF-IDF vekting. På grunn av tekniske utfordringer man står ovenfor ved implementasjon, vil den implementerte algoritmen ikke være helt standard vektorsøk, men ha et arkitekturmessig slektskap til den. Søking og indeksering utføres basert på inverterte filer. Indeksering er nærmere beskrevet i kapittel 7. Figur 6.1: Eksempel på søkeindeks Figur 6.1 viser hvordan indekser rent konseptuelt ser ut. En tabell som er sortert på ord angir antall forekomster til ord i dokumentsamlingen totalt, og maksimalt antall ganger det bestemte ordet forekommer i et dokument. Disse verdiene brukes under indekseringsprosessen. 243

250 6.2. GRENSESNITT KAPITTEL 6. SØKEMODUL Søkemodulen designes med tanke på uavhengighet fra andre deler av systemet. Blant annet vil ontologiske utvidelser ligge utenfor denne modulen. 6.2 Grensesnitt Fasaden til selve søkemotoren er klassen SearchControl. Denne klassen kommuniserer med omverdenen blant annet ved hjelp av klassene SearchQuery og SearchResult, som henholdsvis representerer innholdet av en søkeforespørsel og resultat fra et utført søk. Et klassediagram for søkemodulen er presentert i figur 6.2. Hvordan modulen interagerer med resten av systemet er presentert i sekvensdiagrammet i figur 6.3. Diagramtypen sekvensdiagram er forklart i vedlegg til kravspesifikasjonen. Figur 6.2: Klassediagram for søkemodul I tillegg til disse klassene, benytter søkemodulen seg av data som lagres som et resultat av søkeindekseringen. Se kapittel 7.1 for beskrivelse av dette. SearchControl: SearchControl er hovedklassen i søkemodulen som står for alt av kontrollogikk. Klassen tar imot søkeforespørsler fra nettsidetjeneren, og returnerer en liste over 244

251 KAPITTEL 6. SØKEMODUL 6.2. GRENSESNITT Figur 6.3: Sekvensdiagram for utføring av søk dokumenter som er sortert synkende etter relevans. SearchQuery: Klassen SearchQuery er en innpakket søkeforespørsel som forenkler logikk rundt manipulering av brukerens søketermer. Manipulering av teksten i forespørselen, som for eksempel stemming, fjerning av punktsetting osv. SearchTerm: Enkelte søketermer lagres i klassen SearchTerm. Disse er nært koblet til SearchQuery. Det som gjør det nødvendig å splitte ut ordene til egne klasser, er at det også lagres egenskaper til disse ordene, som for eksempel om ordene er skrevet inn av brukeren, eller om de er et resultat av ontologiutvidelse. 245

252 6.3. ALGORITMER KAPITTEL 6. SØKEMODUL SearchResult: SearchResult er en klasse som isolerer resultatdokumentene fra søkemodulen. Resultatklassen har metoder for å returnere adressen og tittelen til dokumenter. 6.3 Algoritmer I dette avsnittet beskrives de ulike algoritmene som benyttes for gjenfinning av informasjon i systemet Algoritme søk-etter-tekst Algoritmen søk-etter-tekst er hovedalgoritmen for gjenfinning av informasjon. Den baserer seg på at brukeren sender en søkeforespørsel til systemet, og returnerer en liste av resultater. 1. Søkemodulen mottar funksjonskallet SearchControl.performSearch(s), hvor s er et søkeuttrykk som er ferdigbehandlet av ontologimodulen. 2. Et objekt av typen SearchQuery med informasjon om søkeforespørselen opprettes. SearchQuery vil da isolere innholdet som en egen økt, som vil kunne gå samtidig som andre økter. 3. SearchQuery parser søkeforespørselen og oppretter lagringsplass for hvert av ordenes data. Søkeordene blir stemmet (klassen toolkit.stemmer). Ord som stammer fra ontologien blir spesielt merket av i søkeforespørselen. 4. Stoppord blir eliminert fra søkeforespørselen (klassen toolkit.stopwords). 5. For hvert ord i SearchQuery, kalles metoden WordDictionary.getWord(word). Returverdier fra disse blir lagret i we[n]. 6. Dersom et ord ikke blir funnet i WordDictionary, utelates ordet fra søket, og Search- Term.setFound(false) kalles. 7. Alle dokumentreferanser lagret i hver we[n] (we[n].getdocumentreference()) blir slått sammen til docs[k]. Gjennomsnittet av vektene for hver referanse blir lagt i arrayen weights[k]. 8. Listen docs[k] og tilhørende liste weights[k] sorteres etter synkende verdi i weights[k]. 9. Listen docs[k] returneres sammen med hvert dokuments vekting. 246

253 KAPITTEL 6. SØKEMODUL 6.3. ALGORITMER Algoritme søk-etter-tekst-i-kategori Algoritmen søk-etter-tekst-i-kategori brukes for å søke etter resultater innenfor en bestemt klasse i ontologien. Denne funksjonen brukes når brukeren spesifiserer søket. 1. Motta funksjonskallet SearchControl.performSearch(s,cat), hvor s er en søkeforespørsel og cat er en klasse i ontologien det skal søkes innenfor. 2. Utfør R=søk-etter-tekst(s). 3. Eliminer resultater fra R hvor kategorien cat ikke er nært relatert. Bruk ontologien for å finne ut hvor nært søketreffet er. 4. Returner ny R Feilkoder Følgende feilkoder skal returneres av søkemodulen dersom ugyldige tilstander eller forespørsler oppdages: 0x0000 Udefinert feilkode 0x0001 Suksess (OK) 0x0011 Midlertidig vedlikehold 0x0012 Intern feil (exception) 0x0101 Søk feilet: ingen gyldige søketermer 0x0102 Søk feilet: ingen søketermer ble funnet i ordlista 0x0103 Søk feilet: indekser er utilgjengelige 0x0104 Søk feilet: annet 0x0200 Tjenesten utilgjengelig: Ingen dokumenter 0x0201 Tjenesten utilgjengelig: Ikke nok minne til å forhandle forespørselen 0x0202 Tjenesten utilgjengelig: For mange samtidige forespørsler 0x0203 Tjenesten utilgjengelig: annet Begrensinger av design Konstruksjonen modellerer bare søkealgoritmen til et slikt nivå at det går an å avgjøre hvorvidt den lar seg implementere. Noen av detaljene rundt implementasjon av søkealgoritmen er bevisst ikke tatt med. Dette gjelder blant annet: Vekting av treff ved søk: På grunn av usikkerhet rundt hvordan utvidelse av søkeresultater vil påvirke informasjonsgjenfinningsprosessen, vil det være nødvendig å eksperimentere med hvordan søkeresultater rangeres og hvordan termer vektes. Dette er noe det finnes lite litteratur om, som derfor testes ut i løpet av implementasjonen. 247

254 6.3. ALGORITMER KAPITTEL 6. SØKEMODUL 248

255 Kapittel 7 Indekseringsmodul Indekseringsmodulen har ansvaret for å holde orden på hvilke dokumenter det skal søkes i, hvilke ord som det går an å søke etter, samt selve indeksene for hvert dokument. En indekseringsprosess vil kjøre etter behov for å holde indeksene synkronisert med endringer i dokumentbasen. 7.1 Grensesnitt Dette avsnittet viser hvordan de ulike klassene i indekseringsmodulen samarbeider. Grunnen til at klassene får en så detaljert beskrivelse, er at problemer som denne modulen må behandle blant annet gjelder hvordan arkitekturen kan gjøres mest mulig effektiv. En oversikt over interaksjonen som skjer i indekseringsmodulen er gitt i sekvensdiagrammet i figur 7.2. WordDictionary Klassen WordDictionary er en generell ordbokklasse som holder orden på et vilkårlig antall WordEntry ordinstanser. Det er også nødvendig å ha semantikk for innlasting og lagring av ordlisten til sekundærlager. WordEntry En ordforekomst i en WordDictionary. Lagrer informasjon om antall forekomster og maks antall ganger et ord forekommer i et dokument. Hver WordEntry har også en liste av tilhørende OccurenceEntry-instanser, som angir i hvilke dokumenter disse ordene blir funnet. OccurenceEntry Et bindeledd mellom WordEntry og dokumentene hvor ordene befinner seg. Hver OccurenceEntry-instans er bundet opp mot en WordEntry, og består av et treffdokument og en vekting av treffet. Vektingen angir hvor viktig relasjonen mellom WordEntry-en og dokumentet er. Dokumenter hvor et bestemt ord er i tittelfeltet eller forekommer ofte, vil ha en høy verdi her. 249

256 7.1. GRENSESNITT KAPITTEL 7. INDEKSERINGSMODUL Figur 7.1: Klassediagram for indeksering Indexer Indexer er et Thread-objekt som kjører selvstendig for å indeksere alle dokumenter som er registrert i systemet (se klassen DocumentStore). Poenget med å kjøre den i et eget Thread-objekt er at indeksering kan foregå samtidig som brukere kan søke i de gamle søkeindeksene. Når Indexer er ferdig med indekseringen, vil ferdigproduserte ressurser kunne bli flyttet over til å bli aktive. DocumentStore DocumentStore brukes som en generell lagringsklasse som står for lasting og lagring av lister over hvilke dokumenter som skal behandles i systemet. FeatureWeighting Algoritmer for vekting av ordforekomster i dokumenter. Dette er et grensesnitt (Java-interface) som abstraherer ulike vektemetoder. Det er lagt opp til flere vektemetoder for eventuelt å kunne veksle mellom velprøvde metoder og mer eksperimentelle metoder under testing. TFIDFFeatureWeighting TF-IDF [1]. En spesialisering av FeatureWeighting som benytter seg av Document Representerer et dokument, med dets tittel og annen metainformasjon som kan være interessant for søkeindeksering og søking generelt. 250

257 KAPITTEL 7. INDEKSERINGSMODUL 7.2. ALGORITMER Figur 7.2: Sekvensdiagram for indeksering 7.2 Algoritmer Dette avsnittet behandler de ulike algoritmene som skal implementeres i systemet. Algoritmene presenteres som pseudokode for å vise de store trekkene i dem. Detaljnivået er satt til et nivå hvor det kan avgjøres hvorvidt løsningen lar seg implementere, og om tilstrekkelig informasjon er tilgjengelig for de ulike delene av systemet Algoritme indekser Algoritmen indekser er hovedalgoritmen for å bygge en invers fil basert på en samling dokumenter. Det sentrale her er at selve indekseringen må kjøres to ganger en gang for å finne ord og telle forekomster, og en gang for å avgjøre viktigheten av ord i dokumentet det forekommer i. indekser kjøres ved behov, når innholdet i dokumentsamlingen har endret seg så mye at vektingen kan være endret. Resultatet av kjøringen vil da typisk være ferdiggenererte inverterte indeksfiler [1] (en fil med OccurenceEntry-instanser) og vokabularfiler (WordEntryinstanser). 1. Initier en ny WordDictionary-instans. 251

258 7.2. ALGORITMER KAPITTEL 7. INDEKSERINGSMODUL 2. For hvert dokument i dokumentsamlingen, kjør algoritmen indekser-dokument-ord. 3. For hvert dokument i dokumentsamlingen, kjør algoritmen indekser-dokument-vekter. 4. Forsøk å få semaforlås (eksklusiv) på WordDictionary-objektet som er aktivt i systemet. 5. Erstatt WordDictionary-objektet med det nye objektet. 6. Frigi semaforlås Algoritme indekser-dokument-ord Algoritmen Algoritme indekser-dokument-ord(dokument,worddictionary) er den første delen av indekseringsprosessen. Målet er å identifisere alle ord som brukes, og finne frekvensen disse ordene forekommer i. Informasjon om hvor ofte ordene forekommer er nødvendig for å kunne utføre normalisering av ordforkomster i algoritmen indekser-dokument-vekter. 1. Åpne dokumentet. 2. Sett B=nil. 3. Les inn et ord fra dokumentet, utfør stemming. 4. Opprett ny WordEntry og legg det til i WordDictionary hvis det ikke er der fra før. Hvis det samme ordet allerede eksisterer i WordDictionary, oppdater antall forekomster i WordEntry i stedet. 5. Oppdater en lokal array B legg inn antall forekomster av det bestemte ordet i dokumentet som behandles. 6. Gå til For hvert ordantall i B, hvis dette antallet er større enn WordEntry.getMaxNumOccurences(), så kjør WordEntry. setmaxnumoccurences(bn). 8. Lukk dokumentet. Algoritme indekser-dokument-vekter Algoritmen indekser-dokument-vekter(dokument,worddictionary) er den andre delen av indekseringsprosessen. Her settes det vekter på ordene i hvert dokument. 1. Åpne dokumentet. 2. Les inn et ord fra dokumentet, utfør stemming. 252

259 KAPITTEL 7. INDEKSERINGSMODUL 7.3. FEILSITUASJONER 3. Regn ut den normaliserte vekten til ordets forekomst i dokumentet ved hjelp av TF-IDF [1] vektingsskjema. 4. Øk vekten til ordet dersom ordet forekom i tittel eller annen metainformasjon. 5. Lag en instans av OccurenceEntry. 6. Bind OccurenceEntry-instans til ordets WordEntry. 7. Gjenta fra 2 inntil ingen flere ord i dokumentet. 8. Lukk dokumentet Algoritme TFIDF Algoritmen TFIDF er en generisk algoritme som brukes til å vekte et ords viktighet i et dokument. 1. N = antall dokumenter i systemet. 2. n i = antall dokumenter hvor ordet k i forekommer totalt. 3. freq i, j = antall ganger k i forekommer i dokumentet d j. 4. max l = det største antallet av ganger en term blir nevnt i dokumentet d j. 5. Den normaliserte frekvensen f i, j for ordet k i i dokumentet d j er da TF i = f i, j = freq i, j / max l *freq l, j. 6. IDF i = log N/n i. 7. Returner w i, j = TF*IDF = f i, j * log N/n i. 7.3 Feilsituasjoner Et antall av feilsituasjoner må oppdages av indeksereren, og indikatorer på disse tilstandene må gjøres tydelig i indekser. Klassen WordDictionary skal inneholde funksjonalitet for spesifisering av hva som eventuelt har gått galt under indeksering. Av de feilsituasjonene det må tas hensyn til er: 0x0000 Udefinert feilkode 0x0001 Suksess (OK) 0x0401 Indekser er midlertidig utilgjengelige 0x0402 Ingen dokumenter i indeks 253

260 7.3. FEILSITUASJONER KAPITTEL 7. INDEKSERINGSMODUL 0x0403 Indekser oppdateres og er utilgjengelige 0x0404 Indekser er skadet og må bygges på nytt 0x0405 Indekser er utilgjengelige pga. ikke nok diskplass 0x0406 Indekser er utilgjengelige (annen grunn) Begrensinger av design På samme måte som i kapittel om søkealgoritmer, er det også gjort begrensinger med hensyn til modelleringen av søkeindekseringsprosessen. Også her er det ikke vektlagt å ha stor grad av kompletthet i modellerte klassediagrammer, av den grunn at en del eksperimentering sannsynligvis er nødvendig for å komme fram til en akseptabel løsning. 254

261 Kapittel 8 Ontologimodul Vanligvis vil det være en forutsetning å bruke eksisterende ontologier i systemer tilsvarende prosjektets prototyp. Ettersom det ikke har vært mulig å skaffe en slik, lages det som en del av prosjektet en egen ontologi basert på en liten del av dokumentsamlingen det skal søkes i. Å lage en god ontologi er en svært omfattende jobb, og det kreves stor kunnskap innen ontologiens domene. Samsvar mellom ontologien og dokumentenes innhold vil også ha mye å si for resultatene. På grunn av begrensede ressurser i dette prosjektet, vil ontologien som blir laget kun tilsvare en liten gren av en ontologi brukt i et reelt system. 8.1 Tilpasning Ontologien for systemet lages ved å manuelt gå gjennom hvert dokument og trekke ut ord og uttrykk som beskriver innholdet på en god måte, for så å legge disse inn under kategorien de hører til. I tillegg til å gå gjennom dokumentene manuelt, trekkes det ut statistisk informasjon om frekvensen av ord for alle dokumentene. Denne informasjonen brukes til hjelp ved genereringen av ontologien, for å forsikre at sentrale begreper i dokumenter tas med. Hvordan denne uthentingen foregår er beskrevet i forstudiet. 8.2 Bruk av ontologi Det finnes flere alternativer til hvordan en ontologi kan brukes som en utviding av søkesystemet. Metoden som vil bli utprøvd i dette prosjektet er at brukerens søkestreng utvides med relaterte ord, dersom dette finnes i ontologien. Utvidelsen kan gjøres automatisk eller utføres manuellt av bruker. Begge vil bli forsøkt implementert. 8.3 Grensesnitt Klassene som tilhører ontologimodulen blir i stor grad bestemt av klassebiblioteket JENA sin funksjonalitet. Ettersom JENA er forholdsvis tregt og det bare en en liten del av JENA 255

262 8.3. GRENSESNITT KAPITTEL 8. ONTOLOGIMODUL sin funksjonalitet som brukes, representeres klasser i ontologien som OntoNode. Klassen OntologyControlImpl holder rede på OntoNode objektene. JENA brukes altså til å hente ut ontologien fra en fil. Deretter brukes de to nevnte klassene til å representere ontologien. Figur 8.1: Klassediagram for ontologimodul OntologyControlImpl Denne klassen implementerer OntologyControl-grensesnittet. Klassen henter ut ontologi-strukturen fra OWL-ontologien og lager OntoNode-objekter av OWL-klasser. Dette gjøres for å enkelt kunne bruke ontologien videre uten å ta hensyn til eksterne grensesnitt. Ontonode Klassen OntoNode innkapsler ontologinode-objekter (objekter laget med utgangspunkt i klasser i ontologien). Figur 8.1 viser klassene i ontologimodulen. 256

263 Kapittel 9 Felles verktøysett Et verktøysett (toolkit) med felles funksjonalitet for flere moduler må utvikles. Her vil det inngå Java-klasser som løser små, spesifikke problemer, og kan implementeres separat fra hoveddelen av programmet. Et slikt verktøysett med godt definerte og dokumenterte klasser, vil både gjøre en del av utviklingen raskere (med gjenbruk) og gjøre testing enklere. 9.1 Oversikt Deler av funksjonaliteten til systemet som vil legges i et verktøysett er følgende: Stoppord Stemming for identifisering og behandling av stoppord. for å eliminere bøyingsformer på ord. Syntaksanalyse for HTML for å kunne trekke ut ord fra HTML-filer, samtidig som deler av språket HTML abstraheres. Levenshtein for å foreslå et nytt ord dersom et ord er skrevet feil. Systemlogger for å logge systemets oppførsel. Dette for å enklere kunne feilsøke. Klassene i toolkit-pakken vises i figur

264 9.2. STOPPORD KAPITTEL 9. FELLES VERKTØYSETT Figur 9.1: Klassediagram for verktøysettet 9.2 Stoppord Klassen StopWords vedlikeholder en liste over ord som forekommer ofte i vanlige dokumentsamlinger, og derfor ikke har noen differensierende betydning når de står alene. Spesielt konjunksjoner (og, eller, når... ), artikler og andre småord kommer i denne kategorien. Stoppord er nærmere beskrevet i forstudiet. Rent overordnet må klassen StopWords ha følgende funksjonalitet: interface StopWords { // Sjekker om et ord er stoppord // Parameteren s bør ikke være stemmet. boolean isstopword(string s); 258

265 KAPITTEL 9. FELLES VERKTØYSETT 9.3. STEMMING // Laste inn stoppordliste fra disk boolean load(string filename); // Lagre stoppordliste til disk boolean save(string filename); } // Henter ut standardfilnavn på aktuell stoppordliste. // Navnet bør være i filsystem-konvensjon, dvs. ikke // inneholde spesialtegn, backslash og andre kontrollkoder. String getdefaultname(); En implementasjon for norske stoppord vil bli laget i klassen NorwegianStopWords. For å raskt finne ut om et stoppord er registrert, skal NorwegianStopWords benytte seg av en trestruktur eller hashing for å oppnå logaritmisk kjøretid. Stoppord skal lagres i UTF-8-format på disk. Internt i minnet lagrer Java automatisk tekst som Unicode. 9.3 Stemming Stemming utføres på ord for å eliminere bøyingsformer. Teknikken baserer seg på Porter stemming algorithm[5], og detaljer rundt dette er beskrevet i forstudiet. Følgende funksjoner må implementeres i denne klassen: interface Stemmer { // Stemmer et ord String stem(string word); } En implementasjon av grensesnittet som gjør nødvendige tilpasninger for det norske språket, NorwegianStemmer, kan da implementeres. Metoden kalles opp svært ofte, og det er derfor viktig at lemmatiseringsregler blir utført effektivt. 9.4 Syntaksanalyse Syntaksanalyse av dokumenter er nødvendig for å kunne identifisere hvilke ord som fins i dokumenter, og eventuelt identifisere hva som er metainformasjon, tittelinformasjon og annet. Syntaksanalysen vil basere seg på følgende regler: Ingen HTML-oppmerking skal returneres som ord. 259

266 9.5. LEVENSHTEIN KAPITTEL 9. FELLES VERKTØYSETT Alle kommentarer mellom <! og > skal oversees. Tittelfelt skal returneres som ord, og i tillegg merkes spesielt. Systemet skal støtte identifikasjon av metainformasjon gjennom for eksempel META HTTP-EQUIV. Ord som returneres skal være i små bokstaver, og alle HTML-entiteter (aring, amp, copyright-symbol osv.) skal utvides til deres UTF-8-ekvivalenter. Følgende grensesnitt skal brukes for klassen DocumentParser interface DocumentParser { // Initialiserer parseren med en tekstblokk (dokumentet) void init(char[] buffer); // Henter ut neste ord String nextword(); // Sjekker om ordet sist returnert var et tittelord boolean iswordtitle(); } // Sjekker om ordet sist returnert var et meta-nøkkelord. boolean iswordmeta(); I systemet vil det i første omgang bare implementeres en parser for HTML. Klassen HTMLDocumentParser vil stå for denne tjenesten. Hvordan parsing av HTML løses i praksis tas ikke opp her. 9.5 Levenshtein I dagens søkesystemer er det vanlig med en mekanisme for å foreslå nye ord dersom brukeren taster inn ord feil. I dette systemet implementeres en Levenshtein-algoritme for å finne avstanden mellom det feiltastede ordet og et eksisterende ord. Dette brukes videre til å returnere nye foreslåtte ord til brukeren. En klasse LevenshteinDistance må implementeres for å kalkulere distansen mellom ord. 260

267 Vedlegg A Begrepsordliste API: Application Programming Interface et sett definisjoner for kommunikasjon mellom adskilte programdeler. Google: Den mest brukte søkemotoren på WWW. Indeksering dokumenter. Indeksering er prosessen å lage en invertert fil basert på ett eller flere Invertert fil En invertert fil er en datastruktur som brukes for å raskt kunne gjøre oppslag på hvor ulike ord fins i et dokument eller en dokumentsamlingen. Det er en vanlig måte å ordne tekstsøk på. Jena2: Java: JSP: Rammeverk for utvikling av Semantisk web applikasjoner i språket Java. Programeringsmiljø utivklet av Sun Microsystems. Java Server Pages språk for dynamiske nettsider med bruk av Java-biblioteket. Lemmatisering Lemmatisering vil si eliminering av de fleste bøyingsformer på ord, ved å fjerne vanlige bøyingsendelser på ord. Ontologi En ontologi betyr en trestruktur som beskriver relasjoner mellom ord. Disse relasjonene som eksisterer mellom ordene kan være for eksempel synonymer, generaliseringer, spesialiseringer og annet. Ontologisk utvidelse: relaterte ord til innskrevne nøkkelord legges til i søkestrengen i et forsøk på å øke recall til søkealgoritmen. OWL: (Web Ontology Language). Ontologisk standard. 261

268 VEDLEGG A. BEGREPSORDLISTE Parsing Parsing er en teknikk for syntaksanalyse og informasjonsuthenting fra strukturert data. Ved å gå gjennom hvert tegn i en tekst, vil en for eksempel ville kunne hente ut alle ordforekomster med parsing-teknikken. Precision: Presisjon, her brukt om hvor presist et søk er. Recall: Gjenfinning. Her beskriver det hvor mange av de relevanten treffene søket finner. RMI Remote Method Invocation. RMI er en kommunikasjonsprotokoll mellom en klient og en tjenestetilbyder, hvor klienten og tilbyderen kan (men ikke må) befinne seg på forskjellige datamaskiner. RMI gjør det enkelt å overføre data mellom forskjellige programmer som er bygd for det. Stemming: En teknikk for å fjerne typiske bøyingsformer fra ord. Stemming kan redusere kompleksiteten til et vokabular mye, ved å for eksempel slå sammen ord som bil, biler, bilene osv. til en enkelt term. Ren mekanisk, og ser ikke på betydningen av ordet som kommer ut. Stoppord Stoppord er ord som forekommer ofte, men har ingen semantisk verdi når de blir tatt ut av kontekst. Stoppord vil vanligvis bare bidra til ekstra støy i søket dersom de er søketermer, og derfor er det ønskelig at slike ord både fjernes fra dokumentindekser og søkeforespørsler. Søketerm En søketerm betyr et ord som det søkes etter. Term Betyr vanligvis et teknisk ord, men i dette dokumentet brukes ordet ofte i dens vide betydning (alle ord, men stoppord blir ikke alltid behandlet som termer). TF-IDF vekting Term Frequency Inverse Document Frequency. En teknikk for å kvantifisere hvor viktig et ords forekomst er i et dokument. TF-IDF gir verdier som er basert på hvor ofte ord forekommer i dokumentet i forhold til det som er vanlig i en dokumentsamling. Unicode språk. tilbyr et unikt nummer hvert bokstav, uavhengig av plattform, program og Vektorsøk Teknikk for å undersøke likhet mellom tekstansamlinger, ved å bruke matrisealgebra. Dokumenters likhet blir kalkulert ut fra hvor lik frekvensfordeling det er av ord i dokumentene. 262

269 Vedlegg B Diagrammer I dette vedlegget forklares modelleringsnotasjon som er brukt i konstruksjonen. B.1 Komponentdiagram Et komponentdiagram viser systemets overordnede komponenter, uten å gå inn på hvordan disse er realisert. Diagrammet illustrerer også koblinger mellom de ulike komponentene. Elementene som er brukt i komponentdiagrammer i dette prosjektet er vist nedenfor. Komponent Komponent. Indikerer overordnet komponent i systemarkitekturen. Komponent Komponent Assosiasjon. Beskriver assosiasjoner mellom komponenter. Retningen er ikke angitt, og assosiasjonen kan gjelde begge veier. 263

270 B.2. KLASSEDIAGRAM VEDLEGG B. DIAGRAMMER B.2 Klassediagram Et klassediagram viser klassene et system består av. Klassenes attributter og metoder vises også, sammen med relasjoner mellom klassene. De forskjellige elementene som er brukt i klassediagrammene i dette prosjektet er vist nedenfor. Pakke. En pakke kan bestå av flere pakker eller flere klasser. Klasse. Denne består av tre deler. Øverste del er klassenavn, midterste del inneholder attributter (med attributtyper) og nederste del inneholder metoder. Det er også illustrert synlighet for klassene. Dette gjelder både for attributter og metoder. Assosiasjoner mellom klasser. Beskriver assosiasjoner mellom klasser. Følgende kardinaliteter er brukt: 1 En. 1..* En eller flere. 0..* Null eller flere. Interface. Et grensesnitt. Implementasjon av interface. Viser interface implementert av en klasse. Klassen implementerer alle variable og metoder i interfacet. 264

271 VEDLEGG B. DIAGRAMMER B.3. USE CASE DIAGRAM B.3 Use case diagram Use case diagrammer brukes for å vise forskjellige scenarier, og aktørers interaksjon med de forskjellige delene av systemet. Notasjon som er brukt i dette dokumentet: Aktør. Dette er notasjonen for en aktør i systemet. En aktør er en rolle som en bruker spiller mot systemet. Use Case Dette er notasjon for et use case. Et use case i et use case diagram er en visuell representasjon av en distinkt funksjonalitet i systemet. 265

272 B.3. USE CASE DIAGRAM VEDLEGG B. DIAGRAMMER 266

273 Bibliografi [1] Ribeiro-Neto Baeza-Yates. Modern Information Retrieval. ACM Press, [2] Kundestyrt prosjekt gruppe 17. Forstudie. [3] Kundestyrt prosjekt gruppe 17. Kravspesifikasjon. [4] Kundestyrt prosjekt gruppe 17. Testdokumentasjon. [5] Martin Porter. The porter stemming algorithm. PorterStemmer/. 267

274 BIBLIOGRAFI BIBLIOGRAFI 268

275 Figurer 3.1 Pakkediagram for systemet Systemarkitektur Document og DocumentStore klassene Invertert fil Eksempel på brukergrensesnitt Eksempel på brukergrensesnitt ved resultatvisning Brukerprofiler og tilgang Eksempel på søkeindeks Klassediagram for søkemodul Sekvensdiagram for utføring av søk Klassediagram for indeksering Sekvensdiagram for indeksering Klassediagram for ontologimodul Klassediagram for verktøysettet

276 FIGURER FIGURER 270

277 Del V Implementasjon 271

278

279 Innhold 1 Innledning Hensikt Omfang Struktur Standarder Kommentering av kode Java-kode Eksempel på Java-kode JSP, HTML og Javascript HTML/JSP-kode Javascript Eksempel på JSP-kode og Javascript Søkemodul Bruk av RMI kommunikasjon Oppretting av søkeforespørsler Generering av nedtrekksmenyer Andre endringer fra konstruksjonen Ontologimodul Optimaliseringer Utvidelse av søk Synonymer

280 INNHOLD INNHOLD 5 Indekseringsmodul Dokumenter Indeksering Vekting av ord Lignende ord Brukergrensesnitt Felles verktøysett HTML syntaksanalyse Levenshtein ordsammenligning Andre forskjeller A Tilstandsdiagram 293 B Algoritmer 295 B.1 Utvidelse av søk B.2 TF-IDF B.3 Lignende ord B.4 Levenshtein

281 Kapittel 1 Innledning Dette dokumentet gir en oversikt over standarder som er fulgt under implementasjon, samt endringer som er gjort i forhold til opprinnelig design. 1.1 Hensikt Hensikten med dokumentet er å sette ned standarder for skriving og dokumentering av kode, og slik forenkle lesing av kildekode. Videre beskriver og begrunner dokumentet avvik fra designspesifikasjonen, og utdyper sentrale algoritmer som er implementert. 1.2 Omfang Dokumentet er ikke en detaljbeskrivelse av implementasjonen. Det er ment som en støtte til kildekode og kodedokumentasjon, med enkelte utdypninger der det er funnet nødvendig. 1.3 Struktur presenterer retningslinjene for kode og kommentarer som er brukt i imple- Kapittel 2 mentasjonen. Kapittel 3 Kapittel 4 Kapittel 5 Kapittel 6 viser et utdrag fra JSP-koden. viser en oversikt over implementasjon av ontologimodulen. viser en oversikt over implementasjon av indekseringsmodulen. viser en oversikt over implementasjon av brukergrensesnittet. 275

282 1.3. STRUKTUR KAPITTEL 1. INNLEDNING Kapittel 7 viser en oversikt over implementasjon av modulen for verktøysettet som brukes av de andre modulene. 276

283 Kapittel 2 Implementasjonsstandarder I dette kapitlet presenteres de ulike standardene som er fulgt under implementasjonen. Standardene bygger på anbefalinger fra Sun Microsystems [1]. De gir tre hovedgrunner til å bruke felles konvensjoner: 80% av livstidskostnaden til programvare går til vedlikehold. Programvare blir sjelden vedlikeholdt av sin opprinnelige utvikler gjennom hele livet. Kodekonvensjoner forbedrer lesbarheten til programvaren, noe som gjør det lettere å sette seg inn i og forstå ny kode. 2.1 Kommentering av kode Javadoc [2] muliggjør generering av HTML basert på kommentarer i kildekoden. Under følger et ekspempel på bruk av Javadoc. /** * Removes all punctuations from a string, and replaces the punctuations * with whitespaces. * s The string to be converted A string converted to a non-punctuated string. markerer starten på et flagg. Det eksisterer flere typer flagg. Eksempelet viser param og return som angir henholdsvis innparameter og returverdi til en metode. Andre vanlige flagg er author, version, throws og see. Kommentarblokker brukes for kommentarer som går over flere linjer, men som ikke skal være med når Javadoc genereres. Kommentarblokker starter med /*, mens Javadoc starter med /**. Videre har denne typen kommentarer ingen flagg. Et eksempel på en kommentarblokk er vist nedenfor. 277

284 2.2. JAVA-KODE KAPITTEL 2. STANDARDER /* * OntoSearch - Ontology supported search in health care databases * * Copyright c 2004 KPro Gruppe 17 * Copyright c 2004 Extend AS * All Rights Reserved */ Linjekommentarer brukes enten på linja over koden som kommenteres, eller bak på samme linje. Kommentarerne startes med // og varer ut linja, eksempelvis slik: //runs algorithm indexdocweight on every document in store. 2.2 Standard for Java-kode Følgende regler skal følges ved skriving av Java-kode: Navngiving Felles for all navngiving er at engelsk språk skal benyttes. Videre skal det, i alle navn som er satt sammen av flere ord, benyttes stor bokstav for hvert ord som startes inne i navnet. Eksempel: getlabel(). Det er også viktig at alle navn er beskrivende for innholdet de representerer. Pakkenavn skal være i små bokstaver. Eksempel: package ontosearch.toolkit Klassenavn og navn på grensesnitt skal starte med stor bokstav. Eksempel: class/interface OntologyControl Metodenavn skal starte med liten bokstav. Ekspempel: getdocumentdirectory() Variabelnavn skal starte med liten bokstav. Bør holdes så korte som mulig. Eksempel: ontokeys Konstanter skal i sin helhet skrives med store bokstaver. Mellomrom indikeres med underscore. Eksempel: MAX_DEPTH 278

285 KAPITTEL 2. STANDARDER 2.2. JAVA-KODE Innrykk skal brukes for å fremheve sammenhørende kodeblokker. Standard tabulatorinrykk på 4 mellomrom skal brukes Eksempel på Java-kode Koden under er et utdrag fra klassen SearchControlImpl, som demonstrerer hvordan kodestandarden er blitt brukt under implementasjonen: /* * OntoSearch - Ontology supported search in health care databases * * Copyright c 2004 KPro Gruppe 17 * Copyright c 2004 Extend AS * All Rights Reserved */ package ontosearch.ontology; import java.io.*; import java.util.*; import com.hp.hpl.jena.ontology.*; import com.hp.hpl.jena.util.iterator.*; import com.hp.hpl.jena.rdf.model.modelfactory; import ontosearch.toolkit.*; import ontosearch.search.*; import ontosearch.config; /** * Ontology controller class. This class offers services related to * manipulating the ontology and doing inference on it. */ public class OntologyControlImpl implements Serializable, OntologyControl { /** * The ontology model used (set as transient so it s not transferred * when serializing the object) */ transient private OntModel model; /** * Hash table of all ontology words, for faster look-ups */ Hashtable ontokeys = null; /** 279

286 2.2. JAVA-KODE KAPITTEL 2. STANDARDER * Norwegian stemmer */ Stemmer stemmer = new NorwegianStemmer(); /** * Constructor method */ public OntologyControlImpl() { model = ModelFactory.createOntologyModel(); InputStreamReader isr = null; try { isr = new InputStreamReader(new FileInputStream( new File(Config.getOntologyFilename())),"ISO "); } catch(exception e) { SystemLogger.error(e.toString()); SystemLogger.error("Klarte ikke åpne ontologifil"); throw new Error("Ontology file not found"); } model.read(isr,""); // Create a hashtable of all stemmed forms of the // words in the ontology (for linear time retrieval) ontokeys = new Hashtable(); ExtendedIterator it = model.listclasses(); while(it.hasnext()) { OntClass r = (OntClass)it.next(); String oname = stemmer.stem(r.getlocalname().tolowercase()); ontokeys.put(oname,r); } } ExtendedIterator labeliter = r.listlabels(null); while(labeliter.hasnext()) { Object o = labeliter.next(); String labelorig = (String)o.toString().toLowerCase(); String label = stemmer.stem(labelorig); ontokeys.put(label,r); } /** * Get all the root classes from the ontology an arraylist of all the root classes 280

287 KAPITTEL 2. STANDARDER 2.3. JSP, HTML OG JAVASCRIPT */ private ArrayList getrootclasses(){ ArrayList roots = new ArrayList(); ExtendedIterator it = model.listclasses(); while(it.hasnext()){ OntClass r = (OntClass)it.next(); if(r.getsuperclass() == null r.getsuperclass().equals(r)){ roots.add(r); } } return roots; } [...] 2.3 Standard for JSP- og HTML-kode og Javascript I dette avsnittet beskrives krav som stilles til JSP- og HTML-koden HTML/JSP-kode For HTML/JSP-kode stilles det følgende krav: Ett direktiv per linje. HTML-kode skal i størst mulig grad ha ett direktiv på hver linje, for eksempel at <title>...</title> står på en linje for seg selv. Innrykk. HTML-kode skal ha innrykk med fire mellomrom (eller en tabulator) der det er nødvendig for lesbarheten. For eksempel at <title> har innrykk innenfor <head> og </head>. Utskilling av kode JSP-filer skal benytte størst mulige deler med HTML, der det er mulig, for å enkelt kunne skille HTML- og JSP-kode. Sammenheng med Java-kode JSP-kode skal følge retningslinjene for Java-kode der flere sammenhengende linjer med Java-kode benyttes Javascript Kode i JavaScript har følgende krav: 281

288 2.3. JSP, HTML OG JAVASCRIPT KAPITTEL 2. STANDARDER Setningsavbrudd det. Setninger skal avbrytes med semikolon, selv når det ikke er krav om Innrykk 2 mellomrom skal benyttes som innrykk Eksempel på JSP-kode og Javascript <script type= text/javascript language= JavaScript > <!-- // cloak function getobj(name) { if (document.getelementbyid) { return document.getelementbyid(name); } else if (document.all) { return document.all[name]; } else return false; } function checkchildren(name) { // Do NOT mark children as checked [MODIFIED] // but expand children var i; var nval = getobj("c"+name).checked; if(nval) { var name0 = name+"_1"; if(getobj(name0)!=null && (getobj(name0).style.display== none )) { hideelm(name); } } } --> </script> 282

289 Kapittel 3 Søkemodul Dette kapitlet behandler de valgene som ble foretatt ved implementasjon av søkemodulen, og skisserer viktige algoritmer som ble brukt. Endringer fra konstruksjonen er også beskrevet. 3.1 Bruk av RMI kommunikasjon Under implementasjonen viste løsningen med RMI seg å være noe problematisk. På grunn av forskjeller mellom Java 1.3 og Java 1.4.1, ble det ikke mulig å få noen god kompatibilitet mellom disse versjonene. Å bruke Java RMI for kommunikasjon kan ha vært en arkitekturmessig tabbe, ettersom det ga relativt mye ekstraarbeid. På grunn av vanskeligheter med å få objekter på klient- og tjenerside til å jobbe sammen på en god måte, ble klassen SearchControlImpl brukt til å tunellere alle funksjonskall inn til tjenersiden. Denne strukturen bør revurderes i fremtiden. En mulig løsning er å implementere en egen protokoll basert på TCP/IP, både av ytelsesmessige grunner og for å kunne kontrollere modularitet i programmet. 3.2 Oppretting av søkeforespørsler Som skissert i konstruksjonen ble det implementert en løsning med SearchQuery-objekter som innkapsler søkeord. Søkeordene (SearchTerm) inneholder da både opprinnelig søkeord og den stemmede formen av søkeordet. En tredje klasse, SearchResult ble benyttet for å returnere søkeresultater tilbake til klienten (nettsidetjeneren). Dette viste seg også å være svært vellykket, ettersom det ga gode muligheter for manipulering av søkeresultater og minimering av data som går over nettverksprotokollen. 283

290 3.3. GENERERING AV NEDTREKKSMENYER KAPITTEL 3. SØKEMODUL 3.3 Generering av nedtrekksmenyer Nedtrekksmenyene man får presentert når man trykker på ord som finnes i ontologien, er ett av punktene hvor det brytes litt med tankegangen at koden i tjenerprogrammet skal være uavhengig av en bestemt tekstoppmerking. SearchControlImpl, og delvis også ontologimodulen, inneholder en begrenset mengde HTML-oppmerking. Dette bryter med tankegangen i design- og kravspesifikasjon, men ble allikevel ansett som en nødvendig utvidelse. 3.4 Andre endringer fra konstruksjonen Noen av de andre forskjellene fra designspesifikasjon som bør nevnes er: Feilkoder ble ikke brukt i implementasjonen. Årsaken til dette er at det aldri ble behov for stor grad av feilbehandling. Feilkodene ble erstattet av en systemlogg-klasse for å hjelpe til under utviklingen. ble ikke brukt fordi funksjonaliteten til den- Algoritmen søk-etter-tekst-i-kategori ne var lavt prioritert av kunden. Eksperimentering med ulike typer vekting ble ikke gjennomført, siden TF-IDFvektingen fra designspesifikasjonen viste seg å gi gode resultater. 284

291 Kapittel 4 Ontologimodul Dette kapitlet omhandler ontologimodulen og de endringene som ble foretatt i forhold til konstruksjonsdokumentet, samt hvilke vurderinger og antakelser som ble gjort under implementasjonen. 4.1 Optimaliseringer Et av problemene som dukket opp ved implementasjonen av ontologimodulen, var den dårlige ytelsen til verktøysettet Jena. Ved oppstart bruker Jena ca. 13 sekunder på å laste inn en ontologi bestående av ca 200 klasser, på en 1.8 GHz PC. Av denne årsaken ble det brukt en Hashtable for oppslag på stemmede ord, for å hente ut klassene i ontologien. Dette viste seg å både være effektivt i antall kodelinjer og i hastighet. 4.2 Utvidelse av søk Utvidelse av søk blir foretatt ved at alle barn-noder av søkeord som er i ontologien, blir lagt til i søket. Disse får lavere vekting enn søkeord som blir tastet inn i søkefeltet. I tillegg legges også synonymer til i søket. Synonymer gis samme vekting som ord som finnes som klasser i ontologien. Algoritmen for utvidelse av søket blir presentert i detalj i vedlegg B Synonymer Synonymer blir i ontologien representert som label. I OWL Lite er det tillatt å ha flere labels fra den samme ontologiklassen. Synonymene trenger heller ikke å eksistere i egne noder, i tilfelle det er en ufullstendig ontologi. 285

292 4.3. SYNONYMER KAPITTEL 4. ONTOLOGIMODUL 286

293 Kapittel 5 Indekseringsmodul I dette kapitlet blir indekseringsmodulen og dens funksjonalitet behandlet. Algoritmer og valg foretatt i modulen blir behandlet her. Dette inkluderer både selve indekseringen og gjenfinning av informasjon ved bruk av den. 5.1 Dokumenter Dokumenter blir lest inn fra en bestemt katalog som er definert i konfigurasjonsfilen config.ini. For at systemet skal kunne finne dokumentene i dokumentkatalogen, må de følge visse kriterier: Dokumentkatalogen må peke til korrekt katalog, for eksempel dok/docs. Dokumentene må ligge i underkataloger, for eksempel dok/docs/doc_1234/. Dokumentene under katalogen må hete index.html. Nummeret på underkatalogene må være unikt. Grunnen til at implementasjonen krever dette, er at systemet er tilpasset kundens nåværende system for behandling av dokumenter. 5.2 Indeksering Indeksering er implementert som i designspesifikasjonen, og derfor ikke behandlet her. 5.3 Vekting av ord En standard TF-IDF vektealgoritme ble implementert. Det ble ikke eksperimentert med andre løsninger, ettersom det var ikke lagt til rette for avanserte tester av precision og recall. Algoritmen viste seg å gi gode resultater. Algoritmen som ble brukt finnes i vedlegg B

294 5.4. LIGNENDE ORD KAPITTEL 5. INDEKSERINGSMODUL 5.4 Lignende ord En Levenshtein-algoritme for å finne lignende ord ble brukt. Algoritmen er nærmere forklart i kapittel 7.2. Detaljert implementasjonsbeskrivelse er presentert i vedlegg B.3. Det er uklart hvor godt denne algoritmen vil oppføre seg sammen med større mengder av ord, men trolig vil den fungere på en tilfredsstillende måte. Denne vurderingen er foretatt basert på antakelsen om at økningen av antall ord vil være logaritmisk ved innføring av flere dokumenter. 288

295 Kapittel 6 Brukergrensesnitt Brukergrensesnittet gjennomgikk ganske store endringer i implementasjonsfasen, etter ønske fra kunden. Det ferdig implementerte systemet benyttet seg av disse ulike tilstandene: Figur 6.1: Tilstandsdiagram for brukergrensesnittet 289

296 KAPITTEL 6. BRUKERGRENSESNITT Diagrammet i figur 6.1 er et tilstandsdiagram. De ulike tilstandene viser hvilke ulike situasjoner som brukeren vil oppleve at han går gjennom ved bruk av systemet. Syntaksen til tilstandsdiagrammer er forklart i appendiks A I figuren betyr betingelsene [Bet.1] at denne endringen bare skjer dersom avansert søk var forrige søkemetode brukt av brukeren. [Bet.2] betyr på samme måte at enkelt søk var brukerens forrige søkemetode. Avslutningsbetingelsen [Bet.3] betyr at brukeren er ferdig med sin aktivitet med informasjonsgjenfinning. Brukerens lesing av dokumenter og mulighet til å gå tilbake fra dokumenter, er ikke presentert i diagrammet. Lite endringer i brukergrensesnitt ble foretatt i forhold til det som er presentert i konstruksjonsdokumentet. 290

297 Kapittel 7 Felles verktøysett Dette kapitlet omhandler endringer og valg som er foretatt i det felles verktøysettet, i forhold til designspesifikasjonen. Det felles verktøysettet består av et sett med klasser som brukes ulike steder i systemet for behandling av informasjon. 7.1 HTML syntaksanalyse Klassen for HTML syntaksanalysering (HTMLDocumentParser) ble utvidet med ekstra funksjonalitet i forhold til konstruksjonsdokumentet, for å gjøre den i stand til å både returnere tekst hvor punktsetting er fjernet, og også være i stand til å returnere tekst med punktsetting. Årsaken til dette var at for å kunne vise gode dokumentutdrag, var det nødvendig å kunne beholde punktsettingen. Funksjonaliteten i grensesnittet DocumentParser for å sjekke om et ord er et metaord, ble ikke brukt. Dette fordi det viste seg at dokumentene systemet primært skulle behandle ikke inneholdt slik informasjon. 7.2 Levenshtein ordsammenligning Levenshtein-algoritmen som ble brukt (klassen LevenshteinDistance) for å sammenligne ikke funnede søkeord og ord i ordlisten, finnes i vedlegg B Andre forskjeller I konstruksjonsfasen og i kravspesifikasjon ble det lagt opp til bruk av tegnkodingen UTF- 8 for å kunne behandle internasjonale stoppord, osv. Dette ble det ikke tatt hensyn til i implementeringen, ut over det Java selv gjør. 291

298 7.3. ANDRE FORSKJELLER KAPITTEL 7. FELLES VERKTØYSETT 292

299 Vedlegg A Tilstandsdiagram Dette kapitlet forklarer syntaksen til tilstandsdiagrammer. Tilstandsdiagrammer brukes for å vise hvordan et system oppfører seg, ved å beskrive hvilke tilstander som det gåes gjennom som svar på handlinger eller andre hendelser. Den typen diagram som er brukt her, benytter seg av vanlig UML-syntaks. Starttilstand. Dette er den initielle tilstanden i systemet. Sluttilstand. I denne tilstanden er systemet avsluttet.. Overgang. En slik pil viser en overgang fra en tilstand til en annen. Testen Overgang sier hva slags hendelse som skal utføres eller handling som er utført. Betingelsen sier hva som må være oppfylt for at overgangen skal kunne skje. Tilstand. Dette objektet symboliserer en tilstand i systemet. Ved å følge overganger i pilens retning er det mulig å bevege seg til en ny tilstand. 293

300 294 VEDLEGG A. TILSTANDSDIAGRAM

301 Vedlegg B Algoritmer B.1 Utvidelse av søk Dette vedlegget viser algoritmen for utvidelse av søk ved hjelp av ontologien. /** * Annonate a search query with all ontological extensions that can be found. q The search query to be annonated. */ public void annonatesearch(searchquery q) { // Make a local copy of the search terms that will be treated. // We need this because we are actually changing the contents of q. SearchTerm terms[] = new SearchTerm[q.getNumWords()]; for(int i=0; i<terms.length; i++) terms[i] = q.getword(i); for(int i=0; i<terms.length; i++) { SearchTerm term = terms[i]; OntClass oclass = (OntClass)ontoKeys.get(term.getWord()); if(oclass==null) continue; // === Try to add synonyms === // Add the node hit itself -- it might be that a synonym is linking // to this class, thus, it need not be the same word as the key was q.addontologyword(oclass.getlocalname().tolowercase(), stemmer.stem(oclass.getlocalname().tolowercase())); // expand the keyword ExtendedIterator labeliter = oclass.listlabels(null); while(labeliter.hasnext()) { 295

302 B.2. TF-IDF VEDLEGG B. ALGORITMER Object o = labeliter.next(); String labelorig; if(o==null) continue; labelorig = o.tostring().tolowercase(); } // addontologyword also checks for dupes q.addontologyword(stemmer.stem(labelorig), labelorig); } } // === Try to add related words === // Only add ontology-stuff for references that are entered into the // search bar. Do NOT process button-checks or other types of data. if(term.gettype()==searchterm.specified_by_input) { ExtendedIterator it = oclass.listsubclasses(true); while(it.hasnext()){ OntClass s = (OntClass)it.next(); String word2 = stemmer.stem(word); q.addontologyword(word2,s.getlocalname().tolowercase()); } } B.2 TF-IDF Nedenfor følger en detaljert beskrivelse av TF-IDF algoritmen som er brukt i indekseringsmodulen. /** * TF-IDF feature weighting class */ public class TFIDFFeatureWeighting implements FeatureWeighting { /** * Calculate weight for a feature * doctot Number of documents in total in the system docsocc Number of documents in which the word occurs occmax The max num of occurences of the word in a doc thisdoc The num of occurences of the word in this doc the normalized weight */ public float weight(int doctot, int docsocc, int occmax, int thisdoc) { 296

303 VEDLEGG B. ALGORITMER B.3. LIGNENDE ORD } } // Term frequency float TF = (float)thisdoc / (float)occmax; // Document frequency (inverse) float IDF = (float)math.log(doctot) / (float)docsocc; return (float)(tf*idf); B.3 Lignende ord Nedenfor følger en detaljert beskrivelse av Levenshtein-algoritmen som er brukt i indekseringsmodulen. /** * Returns words that look like another string. The algorithm is based * upon a modified Levenshtein algorithm, which detects words that have * the least error fixes necessary to make the two string exactly alike. * word the string to look for an array of words that look like the word. */ public WordEntry[] getsimilarwords(string word) { SimilarWordEntry[] ent = new SimilarWordEntry[30]; int nent = 0; // Iterate over all word in vocabulary for(int i=0; i<kmap.size(); i++) { // Calculate its distance int score = LevenshteinDistance.numErrors((String)kmap.get(i),word); int worst = (ent[ent.length-1]==null)?32:ent[ent.length-1].score; // Check if distance is better than any of those in ent. if(score < worst) { for(int a=0; a<ent.length; a++) { if(ent[a]==null ent[a].score > score) { // We found insertion point for(int b=ent.length-1; b>a; b--) ent[b] = ent[b-1]; ent[a] = new SimilarWordEntry(score,i); nent++; 297

304 B.4. LEVENSHTEIN VEDLEGG B. ALGORITMER } } } } break; } int np = Math.min(6, nent); WordEntry[] entries = new WordEntry[np]; for(int i=0; i<entries.length; i++) entries[i] = (WordEntry)map.get(kmap.get(ent[i].pos)); return entries; B.4 Levenshtein Nedenfor følger Levenshtein-algorimen som ble brukt for å sammenligne ikke funnede søkeord og ord i ordlisten. /** * Find the least number of erraneous key-presses required for one of the * strings to become the other. A dynamic programming algorithm. havarmor (as an exercise in SIF8010 Algorithms and Data Structures */ public static int numerrors(string witherrors, String correctstr) { final int cbgal = witherrors.length()+1; final int cbriktig = correctstr.length()+1; char gale[] = new char[cbgal]; char riktige[] = new char[cbriktig]; witherrors.getchars(0,cbgal-1,gale,1); correctstr.getchars(0,cbriktig-1,riktige,1); int matrise[] = new int[cbriktig]; for(int i=0; i<cbriktig; i++) matrise[i] = i; int prevnum = 0; // Initiere for nedkutting av antall celler som skal // behandles. int delta = Math.max(cbriktig * 59/100,cbgal * 59/100); if(math.abs(cbgal-cbriktig)>delta) delta = Math.abs(cbgal-cbriktig); if(cbgal<40 && cbriktig<40) delta = 40; int b1=1-delta, b2=1+delta; 298

305 VEDLEGG B. ALGORITMER B.4. LEVENSHTEIN // Iterer for hver rad; gjenbruk dataene i matrise for perf. for(int i=1; i<cbgal; i++) { int nextdiag = matrise[0]++; char ch1 = gale[i]; prevnum = matrise[0]; b1++; b2++; // NB: Dette kompromitterer korrektheten... int min = (b1>1?b1:1); int max = (b2>cbriktig?cbriktig:b2); } // Foreta kalkulasjon for hver celle horisontalt i tabellen for(int j=min; j<max; j++) { int prevdiag = nextdiag; nextdiag = matrise[j]; if(ch1==riktige[j]) prevnum = prevdiag; else if(prevdiag>prevnum) prevnum++; else prevnum = ((prevdiag>nextdiag)?nextdiag:prevdiag)+1; matrise[j] = prevnum; } } return prevnum; 299

306 B.4. LEVENSHTEIN VEDLEGG B. ALGORITMER 300

307 Bibliografi [1] Sun Microsystems Inc. Code convention for the java programming language, [2] Sun Microsystems Inc. How to write doc comments for the javadoc tool, http: //java.sun.com/j2se/javadoc/writingdoccomments/. 301

308 BIBLIOGRAFI BIBLIOGRAFI 302

309 Figurer 6.1 Tilstandsdiagram for brukergrensesnittet

310 FIGURER FIGURER 304

311 Del VI Testdokumentasjon 305

312

313 Innhold 1 Innledning Hensikt Omfang Struktur Overordnet testplan Teststrategi Tester for prosjektgruppa Tester for bruker Godkjenningskriterier Avbruddskriterier Dokumentasjon Gjennomføring Enhetstester Modultester Brukergrensesnitt Ontologibehandling Søkemodul Indeksering Systemtest Testspesifikasjon

314 INNHOLD INNHOLD 6 Brukbarhetstest Gjennomføring Omgivelser for brukbarhetstesting Personer Gjennomføring av testen Akseptansetest Testlogg Brukergrensesnitt Ontologimodul Søkemodul Indekseringsmodul Systemtest Oppsummering Gjennomføring Testavbrudd Konklusjon A Maler 359 B Sporingsmatrise 361 B.1 Funksjonelle krav B.2 Ikke-funksjonelle krav C Rapport akseptansetest 365 C.1 Dokument C.2 Logg akseptansetest C.3 Brukerdokumentasjon C.4 Oppsummering

315 INNHOLD INNHOLD D Rapport brukbarhetstest 373 D.1 Personer tilstede D.2 Dokument D.3 Logg brukbarhetstest D.4 Oppsummering E Utvidet test av søkeresultat 379 E.1 Svakheter ved testen E.2 Testresultater E.3 Testkonklusjon F Tidsplan 383 F.1 Opprinnelig tidsplan F.2 Faktisk tidsbruk

316 INNHOLD INNHOLD 310

317 Kapittel 1 Innledning Testing er en sentral del av et prosjekt, og en grundig testing vil ofte være forskjellen på suksess og fiasko. Ideelt sett bør testarbeid foregå som en kontinuerlig prosess gjennom både kravspesifikasjon-, konstruksjon- og implementasjonsfasene. Dette for å avdekke feil og mangler på et tidlig tidspunkt, og slik begrense konsekvensene både rent ressursmessig og for prosjektet som helhet [2]. 1.1 Hensikt Testing har to overordnede mål: Verifisering. Testing av systemets funksjonalitet. Validering. Testing av systemet opp mot kundens ønsker og krav. Testing handler altså ikke bare om korrekthet av programkode, men skal også avdekke om systemet utvikles i henhold til de krav som er fastsatt i kravspesifikasjonen. 1.2 Omfang Testaktiviteten tar utgangspunkt i både de funksjonelle- og de ikke-funksjonelle kravene, og skal teste hele systemet grundig. Videre er grundig dokumentering av tester og resultat avgjørende. 1.3 Struktur Kapittel 2 er prosjektets testplan. Denne legger rammene for hvordan testing skal utføres i dette prosjektet. Kapittel 3 inneholder sjekklisten som skal brukes ved inspeksjon av kodeenheter. 311

318 1.3. STRUKTUR KAPITTEL 1. INNLEDNING Kapittel 4 Kapittel 5 Kapittel 6 Kapittel 7 Kapittel 8 Kapittel 9 omfatter testspesifikasjoner for modultest. omfatter testspesifikasjoner for systemtest. gir oversikt over brukbarhetstest for systemet. gir oversikt over hvordan akseptansetest utføres i prosjektet. dokumenterer resultatet av modul- og systemtestene. oppsummerer testaktiviteten i prosjektet. 312

319 Kapittel 2 Overordnet testplan Testplanen tar utgangspunkt i IEEE standard for software test spesification [3], men er justert en del i forhold til dette prosjektet. 2.1 Teststrategi Testingen deles i to hovedkategorier: Tester som utføres av prosjektgruppa, og tester som utføres av systemets brukere. Alle testene utformes av prosjektgruppa Tester for prosjektgruppa Dette er tester som utføres internt i gruppa. Enhetstest: Testing av de enkelte isolerte kodeenheter i prosjektet. Modultest: Når enheter settes sammen til moduler må det testes for å avdekke eventulle problem i samspillet mellom de forskjellige enhetene. Systemtest: Ved sammensetting av moduler til et komplett system må samspillet mellom modulene, og systemet som helhet testes. Enhetstest gjennomføres i dette prosjektet ved inspeksjon av kode. Sjekklister for inspeksjon utvikles, og all kildekode skal inspiseres av minst en person utenom den som selv har skrevet koden. Behandling av feil eller mangler avdekket under inspeksjon omtales i kapittel 2.3. Sjekklisten skal også brukes aktivt når kode utvikles. Dette vil trolig kunne begrense omfanget av inspeksjonene og slik øke effektiviteten i testingen. Inspeksjoner utføres under implementasjonsfasen. For modultester lages det detaljerte testspesifikasjoner i henhold til vedlegg A. Formålet 313

320 2.1. TESTSTRATEGI KAPITTEL 2. OVERORDNET TESTPLAN med testene er å sjekke at enhetene fungerer sammen, og at modulen har ønsket funksjonalitet. Test utføres så snart en modul er ferdig implementert, i praksis både under implementasjons- og testfasen. Systemtesten utføres eksplisitt når modulene er satt sammen, og skal fokusere på om systemet som helhet fungerer. Systemtest kan ikke kjøres før alle modultester er gjennomført og godkjent. Testspesifikasjoner for systemtest lages også i henhold til vedlegg A Tester for bruker Dette er tester som utføres av sluttbruker/kunde. Brukbarhetstest: Test av brukergrensesnitt for å oppnå et brukervennlig system. Akseptansetest: Kunden tester om det ferdige systemet svarer til forventningene. Denne type test kan også med fordel kjøres på potensielle kunder for Extend AS. For begge utarbeides detaljerte testspesifikasjoner med grundig steg-for-steg prosedyre for å sikre testkvaliteten. Testene har fokus på validering. Formålet med brukbarhetstesten er å sjekke at systemet er brukervennlig. Testen bør utføres av potensielle sluttbrukere. I dette prosjektet utvikles det et søkeverktøy for en dokumentdatabase. Søkeverktøyet har et brukergrensesnitt som ligner dagens søkemotorer på Internett, og brukergrensesnittet vil derfor ikke skille seg betydelig fra andre tilsvarende søkeverktøy. Det vil derfor kun bli utført en brukbarhetstest på det endelige systemet for å teste at det møter kravene som er stilt til brukergrensesnittet. Akseptansetesten utføres av en eller flere representanter fra kunden. Denne kan sees på som en endelig test der kunde utfører et testsett som til sammen dekker alle kravene. Det er en forutsetning at grundig testing er utført internt i gruppa på forhånd, slik at overraskelser ikke forekommer. Formålet med testen er at kunden skal kunne sjekke om systemet svarer til forventningene. Den samlede testprosessen skal bekrefte at systemet møter alle krav. En del av de funksjonelle kravene vil kunne testes på modulnivå, de resterende under systemtesten. De fleste ikke-funksjonelle kravene vil trolig også kunne testes internt av gruppa. De resterende ikkefunksjonelle krav skal dekkes av brukbarhetstest og akseptansetest. Sporingsmatriser skal brukes for å sjekke at alle krav dekkes av minst en test. Et eksempel på en slik matrise er vist i figur

321 KAPITTEL 2. OVERORDNET TESTPLAN 2.2. GODKJENNINGSKRITERIER Figur 2.1: Eksempel på sporingsmatrise for krav/test 2.2 Godkjenningskriterier Godkjenningskriterier vil variere fra test til test. For inspeksjonene vil sjekklisten ligge til grunn for godkjenning av testene. Personen som utfører inspeksjonen er ansvarlig sammen med kodeforfatter. For hver spesifiserte test skal egne godkjenningskriterier angis. Den som utfører testen er ansvarlig for å dokumentere alle feil, samt iverksette og dokumentere tiltak. 2.3 Avbruddskriterier Det er satt av begrenset tid til testing og det er derfor nødvendig å sette opp kriterier for når testing kan avbrytes. Det må gjøres en oppveging mellom tid og eventuellt mangelfull funksjonalitet. Gruppa benytter Hans Schaefers klassifisering av feil [5]. Kategori A: Feil i en eller flere funksjoner som forårsaker stopp. Eksempel: maskin, system eller funksjon må startes på nytt. Kategori B: Feil som har alvorlige konsekvenser i systemet. Eksempel: feil i database, alvorlige feil i rapporter slik at disse tolkes feil. Kategori C: Feil med mindre alvorlige konsekvenser. Eksempel: mindre grad av ustabilitet, mindre funksjons-/egenskapsmangler. Kategori D: Feil uten alvorlige konsekvenser. Eksempel: layout-/trykkfeil i skjermbilder, rapporter eller dokumentasjon som ikke går utover forståelsen av disse. Tester godkjennes ikke så lenge feil i kategori A eller B eksisterer. Feil i kategori C og D kan aksepteres, men i minst mulig grad. Feil i kategori C må dokumenteres grundig, og en oppskrift på hvordan feilen kan omgås eller rettes må inngå i testloggen. Endelig beslutning om å avbryte testing tas samlet i gruppa, helst i samsvar med kunde. 315

322 2.4. DOKUMENTASJON KAPITTEL 2. OVERORDNET TESTPLAN 2.4 Dokumentasjon All testaktivitet dokumenteres og legges ved dette dokumentet. Dette omfatter: Alle feil som oppdages. henhold til vedlegg A. Disse kategoriseres som omtalt i kapittel 2.3, og rapporteres i Spesifiserte tester dokumenteres ved en tabell for hver modul. Sporingsmatriser. Disse støtter opp under dokumentasjonen ved enkelt å vise hvordan krav er dekket av tester. 2.5 Gjennomføring Testingen deles inn i tre faser: Utvikling av testspesifikasjoner og sjekkliste for inspeksjon. Arbeidet kan starte så snart kravene foreligger, og må være ferdig ved implementasjonsstart. Gjennomføring av tester. Inspeksjon foregår parallellt med implementasjon. Modultester kjøres fortløpende, systemtest så snart modulene er satt sammen. Testrapportering. Innsamling av testresultat som danner grunnlag for avgjørelse om systemet er tilstrekkelig testet. Utføres etter implementasjonsfasen. Utvikling og gjennomføring av tester fordeles mest mulig jevnt internt. Tester skal ikke gjennomføres av de som har laget testen. Tidsplan er lagt ved i vedlegg F

323 Kapittel 3 Enhetstester Enhetstestingen skal foregå ved inspeksjon av kildekode til de forskjellige enhetene. Følgende sjekkliste [4][1] skal benyttes: Generelt Følger koding og kommentarer prosjektets kodestandard? Er det samsvar mellom konstruksjon og implementasjon? Avsluttes alle kodeblokker? Er det kun en kodelinje per tekstlinje? Variable og konstanter Eksisterer variable eller konstanter med forvirrende navn? Eksisterer variable som kunne vært konstanter? Eksisterer det ikke-lokale variable som kunne vært lokale? Metoder Eksisterer metoder med forvirrende/misvisende navn? Returneres riktig verdi i metoders forskjellige returpunkt? Inneholder alle metodekall riktige parametre? Har metodene riktig aksesseringsmodus? Klasser Har alle klasser riktig aksesseringsmodus? Har subklasser felles medlemsvariable som kan flyttes opp i superklassen? Kan arvehierarkiet forenkles? 317

324 KAPITTEL 3. ENHETSTESTER Beregninger Er presendens i alle utrykk riktig? Er tvetydighet fjernet? (Er det brukt nok paranteser?) Har variable og konstanter som inngår i beregningen samme type? Sammenligninger Er riktige sammenligningsoperatorer brukt i alle sammenligninger? Er alle boolske uttrykk korrekte? Kontrollflyt Er korrekt løkkemekanisme brukt i alle løkker? Er det riktig antall iterasjoner i alle løkker? Vil alle løkker avslutte? Er alle utganger av løkker behandlet riktig? Er nøstinger så dype at det er vanskelig å holde oversikt? Kan switch løse dette problemet? Er all nøsting korrekt? Avsluttes alle metoder? Input/Output Åpnes alle filer korrekt før de brukes? Lukkes alle filer etter bruk? Er all tekst som presenteres for bruker korrekt? Sjekkes alle mulige feiltilstander? (Fanges exeptions? Gis fornuftige feilmeldinger?) Kommentering av kode Har alle klasser og metoder en passende kommentar som beskriver oppførsel/funksjonalitet på en forståelig måte? Er alle variabel- og konstantdeklarasjoner kommentert? Samsvarer kommentarer med den faktiske funksjonalitet? Øker kommentarene forståelse av koden? (Kan noen fjernes/må noe legges til?) 318

325 KAPITTEL 3. ENHETSTESTER Ytelse Bør datastrukturer og algoritmer med bedre ytelse benyttes? Kan kostnader ved beregning av mye etterspurte verdier kuttes ved å lagre resultatet av beregningen en gang? Kan kode i løkker flyttes ut? Kan løkker som opererer på samme data slås sammen? Eksisterer duplisert kode som kan erstattes med metoder? 319

326 320 KAPITTEL 3. ENHETSTESTER

327 Kapittel 4 Modultester Systemet er delt inn i fire moduler. Disse testes separat før de integreres. Tester utføres fortløpende etter at de respektive modulene er implementert, og dokumenteres i loggen sammen med alle feil som oppdages under testingen. Kapitlet inneholder testspesifikasjoner for testing av de fire modulene; Brukergrensesnitt, Ontologimodul, Indekseringsmodul og Søkemodul 4.1 Brukergrensesnitt Dette ansnittet inneholder testspesifikasjoner for modulen Brukergrensesnitt. Rapport for testingen finnes i vedlegg 8.1. TestID Laget av Navn Utføres av Testspesifikasjon Krav som testes Godkjenningskriterie Relaterte Use Case T-B1 Andreas Berg Nettsidebasert grensesnitt Jørn Ole Skaaraas 1. Åpne URL for systemet i nettleser 2. Sette skjerminnstillingene til 800*600. IF-B1 IF-B2 FK-A1 1. Brukergrensesnittet skal åpnes. 2. Utseendet på grensesnittet skal ikke endres selv om skjerminnstillingen blir endret. 1.1 Innlogging T-B 1: Nettsidebasert brukergrensesnitt 321

328 4.1. BRUKERGRENSESNITT KAPITTEL 4. MODULTESTER TestID Laget av Navn Utføres av Testspesifikasjon T-B2 Andreas Berg Hjelpefunksjon Jørn Ole Skaaraas 1. Åpne brukergrensesnitt i nettleser. 2. Klikke på hjelpefunksjonslenke. IF-B3 Vindu med informasjon om systemets funksjoner åpnes Ingen T-B 2: Hjelpefunksjon TestID Laget av Navn Utføres av Testspesifikasjon Krav som testes Krav som testes Godkjenningskriterie Relaterte Use Case Godkjenningskriterie Relaterte Use Case T-B3 Andreas Berg Elementer i brukergrensesnitt Jørn Ole Skaaraas Sammenligne brukergrensesnittet med noen av de mest brukte søkemmotorene på Internett. IF-B5 IF-B6 Systemet inneholder de elementene de store søkesystemene har felles: - Inputfelt - Søkeknapp - Hjelpefunksjon - Avansert søkefunksjon - Listing av resultater Ingen T-B 3: Elementer i brukergrensesnitt. 322

329 KAPITTEL 4. MODULTESTER 4.2. ONTOLOGIBEHANDLING TestID Laget av Navn Utføres av Testspesifikasjon Krav som testes Godkjenningskriterie Relaterte Use Case T-B4 Andreas Berg Nettleseruavhengighet Jørn Ole Skaaraas Kjøre siden gjennom Markup Validator hos W3C: IF-P2 Siden blir godkjent i validatoren. Ingen 4.2 Ontologibehandling T-B 4: Nettleseruavhengighet Dette avsnittet inneholder testspesifikasjoner for ontologimodulen. Kravene FK-O9 og FK- O10 tilhører også denne modulen, og er fulgt under utvikling av ontologien. De er derimot ikke hensiktsmessige å teste i etterkant, og spesifiserte tester for disse kravene er derfor ikke laget. Rapport fra testing av ontologimodulen finnes i vedlegg 8.3. TestID Laget av Navn Utføres av Testspesifikasjon Krav som testes Godkjenningskriterie Relaterte Use Case T-O1 Paul Christian Sandal Tilgjengelighet ontologi Jørn Ole Skaaraas Angi URL til ontologien i nettleser. FK-O1 FK-A5 Nettleser finner og viser ontologien. Ingen T-O 1: Tilgjengelighet ontologi 323

330 4.2. ONTOLOGIBEHANDLING KAPITTEL 4. MODULTESTER TestID Laget av Navn Utføres av Testspesifikasjon Krav som testes Godkjenningskriterie Relaterte Use Case T-O 2: Ontologiegenskaper T-O2 Paul Christian Sandal Ontologiegenskaper Jørn Ole Skaaraas Åpne ontologien i Protégé. FK-O2 FK-O3 FK-O4 FK-O5 FK-O6 FK-O7 Kravene som testes her er implisitt oppfylt gjennom bruk av Protégé som utviklingsverktøy og OWL som standard. Det er derfor tilstrekkelig å sjekke at ontologien lar seg åpne i Protégé. Determine language - funksjonen i Protégé angir om ontologien følger OWLstandard. Ingen TestID Laget av Navn Utføres av Testspesifikasjon Krav som testes Godkjenningskriterie Relaterte Use Case T-O3 Paul Christian Sandal Ontologistørrelse Jørn Ole Skaaraas Telle antall begreper i ontologien. FK-O8 Ontologien inneholder mer enn 60 begreper. Ingen T-O 3: Ontologistørrelse 324

331 KAPITTEL 4. MODULTESTER 4.2. ONTOLOGIBEHANDLING TestID Laget av Navn Utføres av Testspesifikasjon T-O4 Andreas Berg Utvidelse av søkestreng Jørn Ole Skaaraas Kjøre metode for utviding av søkestreng, med input man vet at det eksisterer relaterte ord til i ontologien. FK-O11 Synonymer og relaterte ord returneres sammen med søkestrengen som ble sendt inn Utvidelse av søkestreng vha ontologi T-O 4: Utvidelse av søkestreng. TestID Laget av Navn Utføres av Testspesifikasjon Krav som testes Godkjenningskriterie Relaterte Use Case Krav som testes Godkjenningskriterie Relaterte Use Case T-O5 Andreas Berg Utvidelse av søkestreng Jørn Ole Skaaraas Kjøre metode for utviding av søkestreng, med input man vet det ikke finnes relaterte ord til i ontologien. FK-O13 Kun den opprinnelige søkestrengen blir returnert Utvidelse av søkestreng vha ontologi T-O 5: Utvidelse av søkestreng uten treff i ontologi. 325

332 4.3. SØKEMODUL KAPITTEL 4. MODULTESTER 4.3 Søkemodul Dette kapitlet inneholder testspesifikasjoner for Søkemodulen. Rapport for testingen finnes i vedlegg 8.5. TestID Laget av Navn Utføres av Testspesifikasjon Krav som testes Godkjenningskriterie Relaterte Use Case T-S 1: Format returdata TestID Laget av Navn Utføres av Testspesifikasjon T-S1 Andreas Berg Format returdata Geir Øyvin Grimnes Kjøre søk manuelt, uten brukergrensesnitt. FK-G1 Returnert output er uten kode formatert spesielt for brukergrensesnitt. Ingen Krav som testes Godkjenningskriterie Relaterte Use Case T-S2 Andreas Berg Grensesnitt til søkealgoritme Geir Øyvin Grimnes 1. Kalle funksjonene som tilbys eksterne moduler. 2. Kalle funksjoner som ikke tilbys eksterne moduler. FK-G2 Interne funksjoner skal ikke være tilgjengelig for eksterne moduler. Ingen T-S 2: Grensesnitt til søkealgoritme 326

333 KAPITTEL 4. MODULTESTER 4.3. SØKEMODUL Relaterte Use Case T-S3 Paul Christian Sandal Test av nøkkelordsøk. Geir Øyvin Grimnes Utføre fem søk med forskjellige sekvenser av nøkkelord. FK-S1 Alle dokumenter som blir returnert inneholder ett eller flere av nøkkelordene i søkestrengen. For utvidet test av søkeresultat se også vedlegg E. 1.5 Utføring av søk T-S 3: Test av nøkkelordsøk TestID Laget av Navn Utføres av Testspesifikasjon TestID Laget av Navn Utføres av Testspesifikasjon Krav som testes Godkjenningskriterie Krav som testes Godkjenningskriterie Relaterte Use Case T-S4 Andreas Berg Feilkoder ved søk. Geir Øyvin Grimnes 1. Kjøre søk med spesialtegn. 2. Kjøre søk med stoppord. 3. Kjøre blankt søk. FK-S2 Systemet returnerer feilmeldinger i naturlig språk med forklaring og årsak. 1.5 Utføring av søk T-S 4: Feilkoder ved søk 327

334 4.3. SØKEMODUL KAPITTEL 4. MODULTESTER TestID Laget av Navn Utføres av Testspesifikasjon Krav som testes Godkjenningskriterie Relaterte Use Case T-S5 Paul Christian Sandal Levenshtein Geir Øyvin Grimnes Kjøre søk både med ord som finnes, og ord som ikke finnes i indeksen. FK-S3 1. Hvis ordet ikke finnes i indeksen blir det fjernet, og Levenshtein-algoritme blir kjørt for å finne nærmeste ord. 2. Søkemodulen returnerer ord som ble fjernet, og foreslår nærmeste ord som eksisterer i indeksen sammen med søkeresultatet. 1.5 Utføring av søk T-S 5: Levenshtein. TestID Laget av Navn Utføres av Testspesifikasjon Krav som testes Godkjenningskriterie Relaterte Use Case T-S6 Andreas Berg Vekting Geir Øyvin Grimnes Kjøre søk rett mot søkemodulen med to ord. FK-S4 1. Hvert treff som blir returnert er vektet. 2. Dokumenter som inneholder begge ord blir vektet høyere enn de som bare har ett. 1.5 Utføring av søk T-S 6: Vekting 328

335 KAPITTEL 4. MODULTESTER 4.3. SØKEMODUL Relaterte Use Case T-S7 Andreas Berg Stemming Geir Øyvin Grimnes Kjøre søk med ord i forskjellige bøyningsformer. FK-S5 1. Søkeresultatet inneholder også dokumenter der ordet er brukt i andre former enn det som ble søkt på. 2. Ordstammen til stemmede ord er spesielt merket. Ingen T-S 7: Stemming TestID Laget av Navn Utføres av Testspesifikasjon TestID Laget av Navn Utføres av Testspesifikasjon Krav som testes Godkjenningskriterie Krav som testes Godkjenningskriterie Relaterte Use Case T-S8 Andreas Berg Stoppord Geir Øyvin Grimnes 1. Kjøre søk med både ordniære ord og stoppord. 2. Telle stoppord i stoppordlisten. FK-S6 1. Stoppordene blir fjernet før søket utføres. 2. Antall stoppord er over Utføring av søk T-S 8: Stoppord 329

336 4.3. SØKEMODUL KAPITTEL 4. MODULTESTER TestID Laget av Navn Utføres av Testspesifikasjon Krav som testes Godkjenningskriterie Relaterte Use Case T-S9 Andreas Berg Retur av søkeresultat Geir Øyvin Grimnes Utføre søk. FK-P1 FK-P2 FK-P3 FK-A3 Resultatet må som minstekrav ha følgende egenskaper: 1. Alle dokumenter som blir returnert inneholder hele, eller deler av søkestrengen. 2. Listen med resultater er sortert etter rangering. 3. Antall treff, URL og kort oppsummering av hvert dokument der treff fra søkestrengen er markert. Egen markering for treff fra ontologien. 1.5 Utføring av søk T-S 9: Retur av søkeresultat. 330

337 KAPITTEL 4. MODULTESTER 4.4. INDEKSERING 4.4 Indeksering Dette avsnittet tar for seg testing av indekseringsmodulen. Rapport for testingen finnes i vedlegg TestID Laget av Navn Utføres av Testspesifikasjon Krav som testes Godkjenningskriterie Relaterte Use Case T-I1 Andreas Berg Analyse av dokumenter Paul Christian Sandal Kjøre en indeksering på et utvalg av 10 dokumenter FK-I1 FK-I2 FK-A4 1. Indeks blir laget uten HTML-oppmerkning og tegnsetting. 2. Tittel og annen metainformasjon om dokumenter er hentet ut. 3. Ord i indeksen er stemmet. 2 (Re)Indeksering av dokumenter T-I 1: Analyse av dokumenter TestID Laget av Navn Utføres av Testspesifikasjon Krav som testes Godkjenningskriterie Relaterte Use Case T-I2 Andreas Berg Lagring av indeks Paul Christian Sandal Kjøre en indeksering på et utvalg av 5 dokumenter. FK-I3 FK-I4 1. En liste over samtlige ord i dokumentutvalget (ikke stoppord) skal være lagret. 2. Hvert felt i ord-dokument-matrisen er lagret som et flyttall. 2 (Re)Indeksering av dokumenter T-I 2: Lagring av indeks 331

338 4.4. INDEKSERING KAPITTEL 4. MODULTESTER TestID Laget av Navn Utføres av Testspesifikasjon Krav som testes Relaterte Use Case T-I3 Andreas Berg Oppdatering av søkeindeks Paul Christian Sandal 1. Kjøre indeksering på dokumentsamling. 2. Legge til et dokument. 4. Kjøre full reindeksering. FK-I5 FK-I6 1. Indeksering utføres uten feilmeldinger. 2. Dokument skal kunne legges til uten at reindeksering må gjøres. 3. Eksisterende indeks er tilgjengelig under reindeksering 2 (Re)Indeksering av dokumenter T-I 3: Oppdatering av søkeindeks TestID Laget av Navn Utføres av Testspesifikasjon Godkjenningskriterie Krav som testes Godkjenningskriterie Relaterte Use Case T-I4 Andreas Berg Lagerbehov Paul Christian Sandal 1. Indeksere tilgjengelig dokumentsamling. 2. Skalere opp indeksstørrelse tilsvarende indeksering av dokumenter vha. matematiske regler. IF-Y2 Resultatet av matematisk skalering skal ikke overskrive 300 MiB. Ingen T-I 4: Lagerbehov 332

339 Kapittel 5 Systemtest Det skal utføres test av systemet som helhet internt i gruppa. I denne testen skal modulene være satt sammen, og det er spesielt samspillet mellom de forskjellige modulene som skal testes. 5.1 Testspesifikasjon Under følger spesifikasjon av testene som skal utføres på den interne systemtesten. Rapport for systemtesten finnes i vedlegg TestID Laget av Navn Utføres av Testspesifikasjon Krav som testes Godkjenningskriterie Relaterte Use Case ST-1 Paul Christian Sandal Nettilgang tjener Jørn Ole Skaaraas Koble seg til tjener fra en annen maskin. FK-A2 Tjeneren er tilgjengelig over nettverk. Ingen ST- 1: Nettilgang tjener 333

340 5.1. TESTSPESIFIKASJON KAPITTEL 5. SYSTEMTEST TestID Laget av Navn Utføres av Testspesifikasjon Krav som testes Godkjenningskriterie Relaterte Use Case ST-2 Andreas Berg Autorisering Jørn Ole Skaaraas 1. Prøve å bruke systemet uten å logge på. 2. Logge på systemet med brukernavn og passord 3. Prøve å bruke systemet etterpå. 4. Logge på administratorkonto med eget brukernavn og passord. 5. La systemet stå ubrukt 60 minutter. IF-S1 IF-S2 1. Brukergrensesnittet skal ikke være tilgjengelig uten å logge inn. 2. Brukergrensesnittet skal være tilgjengelig etter innlogging. 3. Ved pålogging som administrator skal det vises en egen lenke til administratorside i brukergrensesnittet. 4. Etter 60 minutter med inaktivitet skal økten avsluttes. 1 Overordnet funksjonalitet ST- 2: Autorisering TestID Laget av Navn Utføres av Testspesifikasjon Krav som testes Godkjenningskriterie Relaterte Use Case ST-3 Paul Christian Sandal Øktbasert grensesnitt Jørn Ole Skaaraas 1. Åpne to økter samtidig. 2. Lukke nettleser. 3. La systemet stå en time uten å brukes. FK-G3 1. Økter påvirker ikke hverandre. 2. Økt avsluttes. 3. Data blir lagret og slettet i henhold til FK-G3.4 og FK-G3.5. Ingen ST- 3: Øktbasert grensesnitt 334

341 KAPITTEL 5. SYSTEMTEST 5.1. TESTSPESIFIKASJON ST-4 Andreas Berg Søketid Geir Øyvin Grimnes Kjøre søk mens man tar tiden. IF-Y1 Søkeresultatet foreligger innen 4 sekunder. Ingen ST- 4: Søketid TestID Laget av Navn Utføres av Testspesifikasjon TestID Laget av Navn Utføres av Testspesifikasjon Krav som testes Godkjenningskriterie Relaterte Use Case Krav som testes Godkjenningskriterie Relaterte Use Case ST-5 Andreas Berg Visning av søkestreng Geir Øyvin Grimnes Kjøre et søk med ord man vet har synonymer og/eller relaterte ord i ontologien. FK-O12 Brukergrensesnittet opplyser om hva søkestrengen som ble brukt under søket er. 1 Overordnet funksjonalitet Utvidelse av søkestreng vha ontologi ST- 5: Visning av søkestreng. 335

342 5.1. TESTSPESIFIKASJON KAPITTEL 5. SYSTEMTEST TestID Laget av Navn Utføres av Testspesifikasjon Krav som testes Godkjenningskriterie Relaterte Use Case ST- 6: Navigering til søkeresultater TestID Laget av Navn Utføres av Testspesifikasjon ST-6 Andreas Berg Navigering til søkeresultater Geir Øyvin Grimnes 1. Kjøre et søk. 2. Åpne et søkeresultat. 3. Klikke på lenke for å gå tilbake til søkeresultat. 4. Åpne et annet søkeresultat. 5. Bruke nettleserens Tilbake -funksjon for å gå tilbake til søkeresultatet. IF-B4 Søkeresultatet blir åpnet når man går tilbake både ved bruk av lenke, og ved bruk av nettleserens Tilbake - funksjon 1 Overordnet funksjonalitet Krav som testes Godkjenningskriterie Relaterte Use Case ST-7 Andreas Berg Utviding av søk Geir Øyvin Grimnes 1. Kjøre ordinært søk. 2. Utvide søkestrengen manuelt. 3. Utvide søkestrengen vha. ontologien. FK-P4 Søket blir utvidet med relaterte ord fra ontologien. Søkestrengen lar seg også utvide ved manuell modifikasjon. 1 Overordnet funksjonalitet Utvidelse av søkestreng vha ontologi ST- 7: Utviding av søk. 336

343 KAPITTEL 5. SYSTEMTEST 5.1. TESTSPESIFIKASJON TestID Laget av Navn Utføres av Testspesifikasjon Krav som testes Godkjenningskriterie Relaterte Use Case ST- 8: Reindeksering TestID Laget av Navn Utføres av Testspesifikasjon ST-8 Paul Christian Sandal Reindeksering Geir Øyvin Grimnes 1. Logge på som administrator. 2. Kjøre indeksering på dokumentsamling ved å klikke på lenke på administratorsiden. 3. Mens indeksering pågår logger man seg på som vanlig bruker fra en annen maskin. 4. Utføre søk mens indeksering pågår. FK-I6 1. Indeksering utføres uten feilmeldinger. 2. Søk skal kunne utføres uten feilmeldinger under reindeksering 2 (Re)Indeksering av dokumenter Krav som testes Godkjenningskriterie Relaterte Use Case ST-9 Andreas Berg Plattformuavhengighet Håvard Mork 1. Installere prototypen på flere plattformer: Intel X86 Sun UltraSparc Apple X-serve 2. Kjøre søk på de forskjellige plattformene. IF-P1 Søk kan utføres på alle plattformene som testes Ingen ST- 9: Plattformuavhengighet 337

344 5.1. TESTSPESIFIKASJON KAPITTEL 5. SYSTEMTEST 338

345 Kapittel 6 Brukbarhetstest Ettersom prototypens brukergrensesnitt i stor grad skal ligne veletablerte søkegrensesnitt på Internett, vil brukbarhetstesten av denne prototypen bli utført etter at prototypen er implementert. Brukbarhetstestingen vil være todelt, der den ene delen gjennomføres av en ekstern testperson (Potensiell sluttbruker). Den andre delen skal gjennomføres av kunden, som en del av akseptansetesten. 6.1 Gjennomføring av brukbarhetstesting I dette avsnittet beskrives rammen rundt brukbarhetstesten. I tillegg skisseres en gjennomgang av selve testen. Rapport fra testingen er vedlagt dokumentet D Omgivelser for brukbarhetstesting For at en brukbarhetstest skal kunne gjennomføres på en konstruktiv og effektiv måte, er det viktig at den er godt forberedt. Under følger en liste med noen av de rammene som skal ligge rundt selve testen. Testrommet skal være stort nok til at flere personer skal kunne oppholde seg der uten at det føles trangt. Rommet skal være stille og uten mange forstyrrende elementer. Testmaskinen skal være satt opp med en nettleser der førstesiden til systemet skal vises. Ingen andre programmer eller prosesser som kan virke forstyrrende på testpersonen skal kjøre på maskinen. Testoppgavene skal være utformet slik at brukeren ikke får for sterke føringer på hvordan en oppgave skal utføres, men spesifisert nok til at den skal kunne forstå oppgaven. Testansvarlig skal være behjelpelig med å veilede hvis testpersonen står fast. Oppgavene bør utformes slik at de dekker alle hoveddelene av systemet 339

346 6.1. GJENNOMFØRING KAPITTEL 6. BRUKBARHETSTEST Personer Under følger en kort presentasjon av de forskjellige personene som vil være tilstede under selve brukbarhetstestingen. Testansvarlig skal være en av prosjektdeltakerne. Denne personen har ansvaret for all interaksjon med testpersonen. Det er viktig at testansvarlig er rolig og vennlig i måten den snakker med testpersonen. Dette for å skape en god stemning. Testperson skal være en potensiell bruker av et ferdig system. Personen skal velges tilfeldig, dvs at det ikke skal være en som innehar spesiell erfaring med bruk av tilsvarende systemer, utover det som kan forventes av en mulig sluttbruker (gjerne en sykehusansatt). Sekretæren, som også er en av prosjektdeltakerne, skal ta notater under gjennomføringen av testen. Det er viktig at denne notatskrivingen skjer mest mulig diskret, slik at det ikke forstyrrer selve gjennomføringen. Observatøren er en tredje prosjektdeltaker som kun skal være tilstede for å observere testen, og på denne måten prøve å observere ting som testansvarlig og sekretær ikke får med seg. Denne har ingen konkrete oppgaver under intervjuet, og skal forholde seg passiv ovenfor testpersonen Gjennomføring av testen I dette avsnittet presenteres en liste med hovedpunktene som skal inngå i brukbarhetstesten. Innledning. Testansvarlig ønsker velkommen, og forteller om bakgrunnen for testingen, hva man ønsker å oppnå, og hvordan testen skal gjennomføres. Testansvarlig presenterer også de forskjellige aktørene og forklarer deres roller, slik at testpersonen er klar over hvorfor de er tilstede under gjennomføringen. Det er viktig at ansvarlig her forklarer at det ikke er testpersonen som skal testes, men at det er systemet som er utviklet som skal testes. Det er også viktig at testpersonen får beskjed om å tenke høyt, slik at sekretær og observatør forstår hva brukeren oppfatter, og dermed kunne trekke ut erfaringer. Gjennomføring. Testansvarlig presenterer oppgavene til testpersonen og ber den om å utføre disse slik den selv ville ha gjort det. Det er her viktig at testpersonen får prøve og feile en god stund uten at testansvarlig bryter inn. Dette fordi problemer for testpersonen kan gi gode indikasjoner på elementer i brukergrensesnittet som burde endres/forbedres. Testansvarlig skal, dersom testpersonen spør direkte, gi veiledning, men ikke direkte hjelp til oppgaven. 340

347 KAPITTEL 6. BRUKBARHETSTEST 6.1. GJENNOMFØRING Oppsummering. Når hele testsettet er gjennomgått skal testansvarlig foreta en oppsummering av testen ved å spørre testpersonen noen spørsmål om hvordan den opplevde testen, hva den mente var godt, og hva den mente var mindre godt. Hvis testpersonen har konkrete forslag til endringer skal også disse fanges opp her. Det er viktig å gi testpersonen god nok tid til å utdype sine meninger. Etterarbeid. Når testpersonen har avsluttet sine oppgaver, er det viktig at de deltakende personene fra prosjektgruppa blir sittende for å få en felles forståelse av resultatet av testen. Jo tidligere en slik renskriving blir gjort, jo bedre nytte vil man kunne ha av testen. 341

348 6.1. GJENNOMFØRING KAPITTEL 6. BRUKBARHETSTEST 342

349 Kapittel 7 Akseptansetest Det skal utføres en akseptansetest mot kunden etter at prototypen er ferdig utviklet for at kunden skal kunne sjekke om den svarer til forventningene. Kunden får utdelt et dokument i starten av akseptansetesten, som inneholder en beskrivelse av formålet med testen og et sett av oppgaver gruppa ønsker at kunden skal utføre. Testene er basert på systemtestene, men skrevet om til prosa for å være bedre tilpasset akseptansetesten. Dokumentet er lagt ved i vedlegg C sammen med rapporten fra testingen. Oppgavene har som formål å teste et vidt spekter av funksjonaliteten i prototypen. I tillegg til å teste funksjonaliteten, vil akseptansetesten også inkludere testing/godkjenning av dokumentasjonen som følger med. Denne godkjenningen vil gjøres nærmere prosjektets slutt, når dokumentasjonen foreligger i en fullstendig versjon. I tillegg til testsettet som er utviklet av prosjektgruppa, vil kunden på testdagen ha mulighet til å stille med egendefinerte tester for utvidet testing. 343

350 344 KAPITTEL 7. AKSEPTANSETEST

351 Kapittel 8 Testlogg I dette kapitlet følger loggen for alle testene som er utført av prosjektgruppa. Dette omfatter testing av hver enkelt modul, samt systemtestene som tester alle modulene satt sammen. Hvert delkapittel starter med en tabell som gir oversikt over hvilke tester som er utført og resultatet av disse. Eventuelle feil er i tabellen markert med unik id. De er dokumentert fortløpende etter tabellen. Tabellen har også et felt for kommentering av eventuelle avvik eller forklaringer der det er funnet nødvendig. 8.1 Brukergrensesnitt Tabell med rapportering av testene gjort på brukergrensesnittet. TestID Testet Testet av OK/ Feil- Kommentar dato ID T-B Jørn Ole Skaaraas OK T-B Jørn Ole Skaaraas OK T-B Jørn Ole Skaaraas OK T-B4 Retest Jørn Ole Skaaraas Jørn Ole Skaaraas F-B4 OK Valid HTML 4.01 Tabell 8.1: Brukergrensesnitt 8.2 Ontologimodul Tabell med rapportering av testene gjort på ontologimodulen. 345

352 8.2. ONTOLOGIMODUL KAPITTEL 8. TESTLOGG FeilID F-B4 TestID/Dato T-B4/ Kategori C Beskrivelse Validatoren godtok ikke nettsidene som HTML 3.2 Tiltak Feil utbedres. Dato for retest Retest utføres av Jørn Ole Skaaraas Tabell 8.2: F-B4 TestID T-O1 Retest Testet dato Testet av Jørn Ole Skaaraas Geir Øyvin Grimnes OK/ Feil- ID F-O1 OK Kommentar Ontologien er nå også tilgjengelig via URL T-O Jørn Ole Skaaraas OK T-O Jørn Ole Skaaraas OK Inneholder 277 begreper. Redusert til 270. T-O Jørn Ole Skaaraas OK T-O Jørn Ole Skaaraas OK Tabell 8.3: Ontologimodul FeilID TestID/Dato Kategori Beskrivelse F-O1 T-O1/ C Ontologien er disinkt ressurs og kan åpnes lokalt. Lar seg ikke åpne ved å angi URL (har ingen URL). Gjøre ontologien tilgjengelig ved å angi URL Tiltak Dato for retest Retest utføres av Geir Øyvin Grimnes Tabell 8.4: F-O1 346

353 KAPITTEL 8. TESTLOGG 8.3. SØKEMODUL 8.3 Søkemodul Tabell med rapportering av testene gjort på søkemodulen. TestID Testet Testet av OK/ Feil- Kommentar dato ID T-S Geir Øyvin Grimnes OK T-S Geir Øyvin Grimnes OK T-S3 Retest Geir Øyvin Grimnes Geir Øyvin Grimnes F-S3.1 F-S3.2 OK Ytterligere utbedringer vil ikke bli gjort T-S4 Retest Geir Øyvin Grimnes Geir Øyvin Grimnes F-S4 OK Se også vedlegg E Bruker blir opplyst om fjerning av stoppord. T-S5 Retest Geir Øyvin Grimnes Geir Øyvin Grimnes F-S5 OK Levenshtein fungerer T-S Geir Øyvin Grimnes F-S6 OK Ytterligere utbedringer vil ikke bli gjort T-S7 Retest Geir Øyvin Grimnes Geir Øyvin Grimnes F-S7.1 F-S7.2 OK Utelatt for å unngå å forvirre bruker. T-S8 Retest Geir Øyvin Grimnes Geir Øyvin Grimnes F-S8 OK Stoppordliste utbedret, men kan fortsatt utvides. T-S Geir Øyvin Grimnes F-S9 Vil ikke bli utbedret Tabell 8.5: Søkemodul 347

354 8.4. INDEKSERINGSMODUL KAPITTEL 8. TESTLOGG FeilID TestID/Dato Kategori Beskrivelse F-S3.1 T-S3/ C Søk som ble gjort: 1. helse -> OK 2. lege -> Øverste treffa inneholder ikke lege. Problem med vekting. 3. fylkeslege -> OK 4. avd.overlege -> splitter opp avd og overlege til 2 begrep, og gjør søk på disse to. 5. bagging -> OK Utbedring av feil Tiltak Dato for retest Retest utføres av Geir Øyvin Grimnes 8.4 Indekseringsmodul Tabell 8.6: F-S3.1 Tabell med rapportering av testene gjort på indekseringsmodulen. 348

355 KAPITTEL 8. TESTLOGG 8.4. INDEKSERINGSMODUL FeilID TestID/Dato Kategori Beskrivelse Tiltak Dato for retest Retest utføres av F-S3.2 T-S3/ C Vekting av ord som er med i søkestreng grunnet automatisk utviding er justert betydelig ned etter forrige test. Likevel forekommer (for eksempel) dokument som ikke inneholder lege som øverste treff når det søkes på lege. Grunnen til dette er at dokumentet inneholder mange forekomster av de ulike utvidingene av lege, som til sammen gir dokumentet høyere rangering enn dokumenter som også inneholder lege. Gruppa finner det likevel ikke hensiktsmessig å justere vekting av utvidleser mer ned, da dette vil kunne undergrave effekten av å utvide søkestrengen. Det er heller ikke gitt at de høyeste rangerte treffene er mindre relevante enn dokument som innneholder lege, da alle utvidelser er ulike typer leger. Dersom det derimot viser seg at dette er et stort problem kan det altså løses ved å justere ned vekting som blir gitt utvidelser ytterligere. En grundigere test av søkeresultat er også gjennomført. Se vedlegg E. Vil ikke bli utbedret Tabell 8.7: F-S3.2 FeilID TestID/Dato Kategori Beskrivelse F-S4 T-S4/ C Systemet gir ingen beskjed til brukeren om at stoppord og spesialtegn har blitt eksludert fra søket. Utbedring av feil Tiltak Dato for retest Retest utføres av Geir Øyvin Grimnes Tabell 8.8: F-S4 349

356 8.4. INDEKSERINGSMODUL KAPITTEL 8. TESTLOGG FeilID TestID/Dato Kategori Beskrivelse F-S5 T-S5/ C Levenshtein algoritme er ennå ikke implementert i systemet. Utbedring av feil Tiltak Dato for retest Retest utføres av Geir Øyvin Grimnes Tabell 8.9: F-S5 FeilID TestID/Dato Kategori Beskrivelse Tiltak Dato for retest Retest utføres av F-S3.2 T-S6/ C Kommentar: Dette er ikke en direkte en feil. Men testen feiler på enkelte søk. Dette skyldes vekting av treff. Faktisk søkestreng (det bruker skriver inn) blir gitt en høyere vekt en treff på ord fra utvidelser basert på ontologien. Dersom et dokument gir mange treff på utvidelser, vil vekten til dokumentet kunne overgå et dokument som faktisk inneholder begge (eller flere) søkeordene bruker skriver inn. Problemet kan muligens reduseres ytterligere ved å justere vektingsalgoritmen. Justeringen bør likevel ikke undergrave effekten av å utvide søkestrengen basert på ontologien. Vil ikke bli utbedret Tabell 8.10: F-S3.2 FeilID TestID/Dato Kategori Beskrivelse F-S7.1 T-S7/ C Ordstammen er ikke eksplisitt merket. Brukeren får ingen beskjed om at ordet er stemmet. Utbedring av feil Tiltak Dato for retest Retest utføres av Geir Øyvin Grimnes Tabell 8.11: F-S

357 KAPITTEL 8. TESTLOGG 8.4. INDEKSERINGSMODUL FeilID TestID/Dato Kategori Beskrivelse Tiltak Dato for retest Retest utføres av F-S7.2 T-S7/ C Brukegrensesnittet sier fortsatt ingenting om at ord blir stemmet før søk utføres. Gruppa har vurdert å opplyse om dette, men tror dette vil forvirre mer enn det vil forbedre. Det gis derimot en forklarig til bruk av Levenshtein som forklarer hvorfor stammen av ord er sentral. Vil ikke bli utbedret Tabell 8.12: F-S7.2 FeilID TestID/Dato Kategori Beskrivelse F-S8 T-S8/ C Stoppordliste må forbedres, brukeren får ikke beskjed om at ord er fjernet. Utbedring av feil Tiltak Dato for retest Retest utføres av Geir Øyvin Grimnes Tabell 8.13: F-S8 FeilID TestID/Dato Kategori Beskrivelse Tiltak Dato for retest Retest utføres av F-S9 T-S9/ D URL vises ikke. Vil ikke bli utbedret. Ser ikke nytten av det. Ingen Tabell 8.14: F-S9 351

358 8.4. INDEKSERINGSMODUL KAPITTEL 8. TESTLOGG TestID Testet Testet av OK/ Feil- Kommentar dato ID T-I Paul Christian Sandal OK Ingen annen metainformasjon enn tittel hentes ut ved indeksering. T-I Paul Christian Sandal F-I1 OK Fungerer som det er. T-I Paul Christian Sandal OK T-I Paul Christian Sandal OK Tabell 8.15: Indekseringsmodul FeilID TestID/Dato Kategori Beskrivelse Tiltak Dato for retest Retest utføres av F-I1 T-I2/ C ÆØÅ lagres som kråketegn i ordliste og indeks. Trolig ikke et problem siden søkestreng gjennomgår samme preprosessering som indeks og ordliste. Systemet fungerer med søk som inneholder æ, ø eller å. (Eksempel: Direktør) Trenger ikke utbedres. Tabell 8.16: F-I1 352

359 KAPITTEL 8. TESTLOGG 8.5. SYSTEMTEST 8.5 Systemtest Tabell som viser rapport fra systemtestene. TestID Testet dato Testet av OK/ Feil- ID ST Jørn Ole Skaaraas OK ST Jørn Ole Skaaraas F-ST2 Retest Geir Øyvin Grimnes OK ST-3 Retest Jørn Ole Skaaraas Geir Øyvin Grimnes F-ST3 OK ST Geir Øyvin Grimnes F-ST4 OK ST-5 Retest ST-6 Retest Geir Øyvin Grimnes Geir Øyvin Grimnes Geir Øyvin Grimnes Geir Øyvin Grimnes F-ST5 OK F-ST6 OK ST Geir Øyvin Grimnes OK ST Geir Øyvin Grimnes OK ST Håvard Mork F-ST9 OK Kommentar Må ha eget passord for å komme inn p å admin-siden. Lenken dit er synlig for alle. Godekjenningskriterie 2. og 3. også OK. Anser kravet som tilstrekkelig oppfylt. Kunden støtter dette. Faktisk søkestreng vises. Lenke tilbake til resultat i toppen på hvert dokument. Prototypen er testet på: Intel X86 og FreeBSD 4.9-STABLE #10 Tabell 8.17: Systemtest 353

360 8.5. SYSTEMTEST KAPITTEL 8. TESTLOGG FeilID TestID/Dato Kategori Beskrivelse Tiltak F-ST2 ST-2/ D Godkjenningskriterium 3: Lenke til administratorside vises alltid. Enten la lenke vise, men legge autorisering på adminsida, eller endre i henhold til test. Dato for retest Retest utføres av Jørn Ole Skaaraas Tabell 8.18: F-ST2 FeilID F-ST3 TestID/Dato ST-3/ Kategori C Beskrivelse Godkjenningskriterie 2. og 3. ikke testet. Tiltak Undersøke mulighet for å teste dette. Dato for retest Retest utføres av Jørn Ole Skaaraas Tabell 8.19: F-ST3 FeilID TestID/Dato Kategori Beskrivelse Tiltak Dato for retest Retest utføres av F-ST4 ST-4/ D Ved søk på tre hovedkategorier (mer enn 70 søkeord i søkestrengen) tar søket like i overkant av 4 sekund. Med lavere antall søkeord er søketiden klart under 4 sekund. Siden kravet er oppfylt for det gruppa anser som rimelig antall søkeord i en søkestreng, vil ikke utbedring av responstid prioriteres. Retest vil ikke bli gjort. Tabell 8.20: F-ST4 FeilID F-ST5 TestID/Dato ST-5/ Kategori C Beskrivelse Bruker får ikke opplyst faktisk søkestreng Tiltak Utbedres Dato for retest Retest utføres av Geir Øyvin Grimnes Tabell 8.21: F-ST5 354

361 KAPITTEL 8. TESTLOGG 8.5. SYSTEMTEST FeilID TestID/Dato Kategori Beskrivelse F-ST6 ST-6/ D Godkjenningskriterie 3: Dokumenter inneholder ingen lenke som leder tilbake til resultatsiden. Utbedres Tiltak Dato for retest Retest utføres av Geir Øyvin Grimnes Tabell 8.22: F-ST6 FeilID TestID/Dato Kategori Beskrivelse Tiltak Dato for retest Retest utføres av F-ST9 ST-9/ C Prototypen er i tillegg til Intel X86 testet på FreeBSD 4.9-STABLE #10. I følge kravet skulle den også vert installert på Sun UltraSparc og Apple X-serve. Grunnet manglende tilgang til disse plattformene er dette ikke gjort. At den lar seg installere på FreBSD indikerer likevel plattformuanvhengighet, og gruppa anser derfor kravet som oppfylt. Ingen tiltak. Tabell 8.23: F-ST9 355

362 8.5. SYSTEMTEST KAPITTEL 8. TESTLOGG 356

363 Kapittel 9 Oppsummering Dette kapitlet gir en kort oppsummering av testaktiviteten og kommenterer avvik fra testplanen. Eksisterende mangler ved testavbrudd beskrives også. 9.1 Gjennomføring Testingen har tatt utgangspunkt i testplanen. Enhetstester er utført ved inspeksjon av kodeenheter. Dette har vist seg å fungere bra for dette prosjektet, da det under modul- og systemtester ikke er oppdaget feil av kategori A eller B (beskrevet i avsnitt 2.3). Modulog systemtester er utført i henhold til utarbeidede testspesifikasjoner. Retester er utført for tester som feilet. Det er også gjennomført en brukbarhetstest og en akseptansetest. Disse ligger nær hverandre i innhold, og hovedforskjellen er testpersonen. Begge disse testene ga nyttig informasjon til forbedringspotensialer ved prototypen. Tidsmessig eksisterer det avvik fra opprinelig plan. Faktisk tidsbruk er lagt ved i vedlegg F.2. Hovedårsaken til at planen ble endret er at det tok lengre tid å utvikle testspesifikasjoner enn først antatt. Dette skyldes hovedsaklig at en del krav måtte gjøres mer testbare som en del av denne prosessen. Prosessen har således også bidratt til en forbedret kravspesifikasjon. 9.2 Testavbrudd Gruppa besluttet å avbryte testing selv om mindre mangler fortsatt forekom. Disse er alle i kategori C eller D, og testavbruddet er derfor ikke i strid med tesplanen. Alle mangler/avvik fra godkjenningskriterier er dokumentert i testloggen i kapittel 8. Prototypens faktiske evne til å finne relevant informasjon er, som presisert i vedlegg E, vanskelig å teste. En rekke parametere kan justeres i en videre tuning av prototypen: stoppordliste, vektingsalgoritme, ontologi, levenshtein, og stemming. Hva som gir den beste løsningen må til syvende og sist defineres subjektivt, og da helst av domeneeksperter. 357

364 9.3. KONKLUSJON KAPITTEL 9. OPPSUMMERING 9.3 Konklusjon Prototypen har gjennomgått en omfattende testing, men har oppført seg stabilt gjennom hele denne prosessen. Gruppa mener derfor, med de kommentarer som er gitt i testloggen, at prototypen i tilstrekkelig grad møter de krav som er stilt i kravspesifikasjonen. 358

365 Vedlegg A Maler TestID Laget av Navn Utføres av Testspesifikasjon Krav som testes Godkjenningskriterie Relaterte Use Case <Testidentifikator> <Navn på testforfatter> <Beskrivende navn> <Navn på tester> <Spesifisering av test> <Oppramsing av krav som testes> <Kriterie for godkjenning> <Id og navn på evt relatert Use Case> Tabell A.1: Mal for testspesifikasjon FeilID TestID/Dato Kategori Beskrivelse Tiltak Dato for retest Retest utføres av <Feilidentifikator> <Testidentifikator>/<Testdato> <Kategorisering av feilen> <Beskrivelse av feil> <Beskrivelse av tiltak> <Dato for evt ny test> <Navn på retester> Tabell A.2: Feilrapporteringsskjema 359

366 360 VEDLEGG A. MALER

367 Vedlegg B Sporingsmatrise Dette vedlegget inneholder sporingsmatriser for sporbarhet mellom kravene stilt i kravspesifikasjonen og testene beskrevet i testplanen. Det er skilt mellom funksjonelle og ikkefunksjonelle krav. B.1 Funksjonelle krav Under følger sporingsmatrise mellom tester og de funksjonelle kravene. Sporingen er gjort for hver modul, samt systemtestene. FK-O9 og FK-O10 dekkes ikke av noen tester da de ikke er direkte testbare, og er derfor heller ikke med i matrisen. 361

368 B.1. FUNKSJONELLE KRAV VEDLEGG B. SPORINGSMATRISE Krav T-B T-O T-S T-I ST FK-A1 X FK-A2 X FK-A3 X FK-A4 X FK-A5 X FK-G1 X FK-G2 X FK-G3 X FK-S1 X FK-S2 X FK-S3 X FK-S4 X FK-S5 X FK-S6 X FK-P1 X FK-P2 X FK-P3 X FK-P4 X FK-I1 X FK-I2 X FK-I3 X FK-I4 X FK-I5 X FK-I6 X FK-O1 X FK-O2 X FK-O3 X FK-O4 X FK-O5 X FK-O6 X X FK-O7 X FK-O8 X FK-O11 X FK-O12 X FK-O13 X Sporingsmatrise 1: Funksjonelle krav 362

369 VEDLEGG B. SPORINGSMATRISE B.2. IKKE-FUNKSJONELLE KRAV B.2 Ikke-funksjonelle krav Under følger sporingsmatrise mellom tester og de ikke-funksjonelle kravene. Sporingen er gjort for hver modul, samt for systemtestene. Kravene som er stilt til dokumentasjon er ikke dekket av noen av disse testene. IF-D1 til IF-D3 skal godkjennes av kunde, og inngår dermed i akseptansetesten. IF-D4 til IF-D8 går på skriving og kommentering av kode, samt testdokumentasjon. Gruppa har tilstrebet å møte disse kravene, men dette kan vanskelig testes objektivt, og er derfor ikke med. Krav T-B T-O T-S T-I ST IF-Y1 X IF-Y2 X IF-P1 X IF-P2 X IF-S1 X IF-S2 X IF-B1 X IF-B2 X IF-B3 X IF-B4 X IF-B5 X IF-B6 X Sporingsmatrise 2: Ikke-funksjonelle krav 363

370 B.2. IKKE-FUNKSJONELLE KRAV VEDLEGG B. SPORINGSMATRISE 364

371 Vedlegg C Rapport akseptansetest Dette vedlegget inneholder rapport fra akseptansetesten som ble utført med kvalitetsansvarlig hos Extend AS, Thomas Øhrbom, 9 november 2004 på Gløshaugen. Testen ble ledet av Andreas Berg. Tilstede under testen var også Jørn Ole Skaaraas som observatør og Paul Christian Sandal som sekretær. Kunden fikk utlevert et dokument før testen startet, med tester definert av gruppa. Dette dokumentet følger under. 365

372 C.1. DOKUMENT VEDLEGG C. RAPPORT AKSEPTANSETEST C.1 Dokument for akseptansetest Akseptansetest Dette dokumentet beskriver hovedtrekk ved systemet, samt spesifiserer en del oppgaver vi føler vil teste systemet på en god måte. Prototypens brukergrensesnitt har i hovedsak fire deler: Enkelt søk er den siden man kommer til etter å ha logget inn i systemet. Her kan brukeren skrive inn sitt søk, og klikke på Søk for å utføre søket. Ingen spesielle funksjoner blir tilbudt i brukergrensesnittet. Avansert søk kan man komme til via en lenke i det enkle grensesnittet. I det avanserte søket kan man selv navigere etter ord i ontologien man har lyst til å søke på vha. trestrukturer med avkrysningsbokser. Ved å krysse av i en boks, merkes også alle ordene som ligger under dette ordet i treet. I tillegg til avkrysning kan man skrive inn andre spesifikke ord i søkefeltet. Søket utføres ved å klikke på Søk. Resultatsiden viser resultatene av søket. I tillegg til de spesifikke treffene vises en del data om hva som har blitt søkt på, både det brukeren selv har spesifisert, og det som automatisk har blitt lagt til av ontologien. Administratorsiden er tilgjengelig via en lenke på søkesiden. På administratorsiden får man mulighet til å utføre oppdatering indekser, eller kjøre en full reindeksering. I tillegg tilbys en logg over de siste søkene som har blitt utført. Får også oversikt over noen nøkkelverdier for systemet. Under følger en rekke oppgaver som går på den overordnede funksjonaliteten til prototypen. Oppgavene er basert på systemtesten utført av gruppa internt. Før du går igang med testingen er det noen punkter som er viktige for hvordan testen blir utført: Dokumentsamlingen inneholder kun 294 dokumenter, og disse er et utdrag av dokumentsamling brukt i EQS i dag. Ontologien som er utviklet til prototypen er svært begrenset, og skal kun brukes til å vise konsepter ved bruk av teknologien. Alle begrepene i ontologien er hentet ut fra dokumenter som omhandler smittevern, så for å teste bruk av ontologien vil søk innen dette emnet være mest relevante. Dette vil kanskje ikke oppleves som en akseptanse-test slik disse vanligvis utføres, da det utviklede systemet er en prototyp og ikke et ferdig produkt som kan brukes 366

373 VEDLEGG C. RAPPORT AKSEPTANSETEST C.1. DOKUMENT kommersielt. Det er dermed naturlig at både funksjonaliteten og ytelse vil være noe begrenset i forhold til hva man ville kunne forventet av et komplett system. 367

374 C.1. DOKUMENT VEDLEGG C. RAPPORT AKSEPTANSETEST Oppgaver: AT-1 AT-2 AT-3 AT-4 Utføre søk AT-5 AT-6 AT-7 AT-8 AT-9 AT-10 AT-11 AT-12 AT-13 AT-14 AT-15 AT-16 Administrator AT-17 AT-18 AT-19 Åpne URL: i nettleser. Logge på systemet med brukernavn: kpro, og passord: ja. Åpne hjelpefunksjon og lese kjapt om den overordnede funksjonaliteten til systemet. Gå tilbake til søkesiden. Da prototypen er begrenset i omfang, både mtp dokumentsamling og spesielt mtp ontologien, vil vi her foreslå noen søk som får frem forskjellig bruk av ontologien. Utfør et enkelt søk med f.eks infeksjon. Prøv gjerne å skrive inn stoppord som og, eller, men, for osv. i tillegg. Forsøk å spesifisere søket ved å klikke på ordet som ble søkt på og erstatte dette med et annet ord. Forsøk å spesifisere søket ved å legge til et av ordene funnet i ontologien. Forsøk å generalisere på samme måte. Åpne et dokument. Gå tilbake til resultatsiden ved å klikke på lenke øverst i dokumentet. Prøv å bytte ut søkestrengen med et annet ord ved å klikke på et av begrepene listet under et dokumenttreff. Gå tilbake til søkesiden, og så til avansert søk. Utfør et avansert søk ved å velge et eller få ord fra ontologistrukturen. Navigér litt rundt i strukturen for selv å finne begrep. Forsøk å spesifisere søket vha. foreslåtte ord. Utfør et nytt avansert søk, denne gang med å velge mange begrep. (gjøres enkelt ved å krysse av i en eller flere hovedkategorier.) Forsøk å spesifisere igjen. Vi skal nå se på hva det administrative grensesnittet tilbyr. Klikk på lenke til administrator-side nederst på søkesiden. Kjør reindeksering etter ønske. Se endringer i oversikten over data. Dette var de testene vi har laget for å gi et innblikk i hva systemet tilbyr. Prøv gjerne å gjøre egne tester. 368

375 VEDLEGG C. RAPPORT AKSEPTANSETEST C.2. LOGG AKSEPTANSETEST C.2 Logg fra akseptansetest Under følger en tabell med logg fra selve testingen, med referanse til kommentarer som kom frem under testen. Den inneholder også et felt som angir eventuelle utbedringer som er gjort, i henhold til kundens kommentarer. TestID OK/KommentarID Tiltak AT-1 OK AT-2 OK AT-3 OK AT-4 OK AT-5 Kommentar AT-5 Utbedret AT-6 Kommentar AT-6 Utbedret AT-7 OK AT-8 OK AT-9 OK AT-10 OK AT-11 OK AT-12 Kommentar AT-12 AT-12.1 Utbedret AT-12.2: Forbedret, men forekommer fortsatt ved mye utviding. AT-13 Kommentar AT-13 Utbedret AT-14 Kommentar AT-14 Ikke utbedret. Kan trolig enklest løses ved bruk av JavaBeans. AT-15 Kommentar AT-15 AT-15.1: Forbedret. Problemet kan fjernes ved å gå over ontologien og fjerne begreper som ikke gir treff i dokumentsamlingen. AT-15.2: Forslag fra Levenshtein kan fortsatt i enkelte tilfeller oppleves som ukorrekt norsk siden det er ordsstammen som presenteres. AT-15.3: Utbedret AT-16 OK AT-17 OK AT-18 OK AT-19 OK Tabell C.1: Testlogg akseptansetest 369

376 C.2. LOGG AKSEPTANSETEST VEDLEGG C. RAPPORT AKSEPTANSETEST Kommentar AT-5 1 Vekting av dokumenter bør ikke presenteres for bruker. 2 Grensesnittet oppleves som litt smalt. Grensesnittelementene kan også med fordel gjøres større. 3 Fargekodingen av direkte treff/treff i ontologi bør byttes om og gjøres tydligere. 4 Tilbake til søk lenka bør endres. Oppleves merkelig når et søk ikke gir treff. Tabell C.2: Kommentar AT-5 Kommentar AT-6 1 Brukergrensesnittet bør få frem hva nøkkelordene under hvert dokumentresymé representerer. 2 Når bruker klikker på et slikt nøkkelord bør ordet hektes på søkestrengen, og evt vektes som ontologiord i nytt søk. Dette for å unngå at dokumentet man klikker på nøkkelord fra forsvinner når nytt søk gjøres. Tabell C.3: Kommentar AT-6 Kommentar AT-12 1 Opplisting av toppnivåbegreper oppleves merkelig. Bør endres fra til f.eks Sporadiske mellomrom i trestrukturen grunnet lange onologibegreper bør ikke forekomme. Tabell C.4: Kommentar AT-12 Kommentar AT-13 1 Oppleves som unødvendig å automatisk også krysse av alle underbegrep ved avkryssing av høynivåbegreper. Bedre å la bruker krysse alle han/hun vil ha med. Tabell C.5: Kommentar AT-13 Kommentar AT-14 1 Tilbake til søk bør ved bruk av avansert søk lede tilbake til søkesiden uten at avkryssninger i trestrukturen er fjernet. (Tapt arbeid). Tabell C.6: Kommentar AT

377 VEDLEGG C. RAPPORT AKSEPTANSETEST C.3. BRUKERDOKUMENTASJON Kommentar AT-15 1 Oppleves som merkelig at begreper avkrysset i ontologien ikke blir funnet i søket. 2 Videre kan det virke frustrerende at systemet foreslår ukorrekte norske ord når begreper (på korrekt norsk) ikke forekommer i samlingen (Levenshtein). 3 Informasjon til bruker ved treff med synonymer bør utbedres. Tabell C.7: Kommentar AT-15 C.3 Brukerdokumentasjon I etterkant av akseptansetesten ble kunden oversendt brukerdokumentasjon. Kunden godkjente denne og dermed er krav IF-D1 til IF-D3 også dekket av akseptansetesten. C.4 Oppsummering av akseptansetest Etter selve gjennomgangen ble det gjort en oppsummering. Kunden uttrykte i grove trekk at systemets oppførsel er tilfredstillende, og følgelig noe Extend AS vil kunne ha nytte av. Loggen viser at det kom frem momenter under testen som gruppa vil forsøke å utbedre. Punktene omfatter i grove trekk elementer i brukergrensesnittet, og går således ikke på kritiske systemfunksjoner. Det er likevel viktige punkter som vil heve prototypens kvalitet. Gruppa vil sette ressurser på å løse dette, og tiltak dokumenteres i loggen når de er gjennomført. 371

378 C.4. OPPSUMMERING VEDLEGG C. RAPPORT AKSEPTANSETEST 372

379 Vedlegg D Rapport brukbarhetstest Dette vedlegget inneholder rapport og logg fra brukbarhetstestingen som ble gjort med en potensiell bruker av et ferdig system. D.1 Personer tilstede I dette avsnittet følger informasjon om de forskjellige personene som tilstede under brukbarhetstestingen. Testperson Navn Arbeidsplass Stilling Databakgrunn Alder Marianne Sunde St. Olavs Hospital, Trondheim Sykepleier, Geriatrisk sengepost, Seksjon for Geriatri. Tekstbehandling, bruk av Internett og e-post, samt systemer brukt på arbeidsplassen. (Inkludert EQS) 23 år Tabell D.1: Informasjon om testperson Testansvarlig Sekretær Observatør Paul Christian Sandal Tarjei Lægreid Andreas Berg Tabell D.2: Andre personer tilstede under testen 373

380 D.2. DOKUMENT VEDLEGG D. RAPPORT BRUKBARHETSTEST D.2 Dokument for brukbarhetstest Det følgende dokumentet ble skrevet ut som et eget dokument og leveret til testpersonen før testen begynte. De inneholder generell informasjon om testgjennomføring, samt spesifisert testsett. Brukbarhetstest For at vi skal få mest mulig igjen for testen er det noen punkter som er viktige før du går igang med selve testen. Du testes ikke Denne testen har som formål å sjekke brukervennligheten til et søkesystem for en samling styringsdokumenter. Testen har ikke som hensikt å på noen måte teste dine kunnskaper eller ferdigheter. Den er kun for å hjelpe oss med å utvikle et så brukervennlig system som mulig. Tenk høyt Det er viktig at du prøver å forklare hva du tenker mens du prøver å løse de forskjellige oppgavene. På denne måten kan vi lettere se hvor vanskelighetene ligger. Ingen hjelp Vi ønsker at testen skal være så virkelighetstro som mulig, så derfor har vi ikke anledning til å svare på oppgavespesifikke spørsmål underveis. Skulle du likevel stå helt fast kan du spørre om assistanse, men vi ser heller at du ved en slik situasjon forklarer tydelig hvorfor du står fast, og så heller går videre til neste punkt i testsettet. Avbryt om nødvendig Om du i løpet av testen skulle føle ubehag eller ikke ha lyst til å fortsette må du ikke være redd for å avbryte testen. 374

381 VEDLEGG D. RAPPORT BRUKBARHETSTEST D.2. DOKUMENT Oppgavene: Logge inn For å kunne benytte systemet ønsker du å logge inn. BT-1 Åpne systemet i nettleser ved å bruke nett-adressen: BT-2 Logge på med brukernavn kpro og passord ja. Bruke hjelpfunksjonen BT-3 BT-4 BT-5 Enkelt søk BT-6 BT-7 BT-8 BT-9 BT-10 BT-11 BT-12 BT-13 Avansert søk. BT-14 Før du begynner er det lurt å lese gjennom bruken av systemet. Klikk på lenken Hjelp for å åpne hjelpefunksjonen. Les gjennom den overordnede delen av denne. Gå tilbake til førstesiden. Du ønsker å søke etter dokumenter som har med brann og brannvern å gjøre. Gjør et søk ved kun å skrive inn infeksjon i søkefeltet. Trykk på knappen for å utføre søket. Er det som presenteres på resultatsiden selvforklarende. Still evt. spørsmål du måtte ha høyt. Se på de første treffene, uten å åpne dokumentene. Ser noen av disse ut til å omhandle infeksjon? Prøv å endre søket ved å klikke på ordene under søkefeltet. Er virkningen av dette som forventet? Prøv også å klikke på ord som er farget blå etter et dokumentresymé. Er virkningen av dette som forventet? Skriv inn søkeordene Jeg og du. Klikk på søk. Hvordan opplever du resultatet? Skriv inn søkeordet doktor. Hvordan opplever du resultatet. Åpne siden for avansert søk. Du ønsker nå å finne dokumenter som omhandler smittevern og spesielt om hepatitt-smitte. Bruk ordlista i det avanserte søket til å finne fram til, og merke av ord du tror kan være nyttige. Hvis du ikke finner ordene i lista kan du i tillegg skrive i søkefeltet. Klikk på søk. Er resultatet som forventet? Takk for hjelpen! Din innsats har vært med på å sikre et bedre system. 375

382 D.3. LOGG BRUKBARHETSTESTVEDLEGG D. RAPPORT BRUKBARHETSTEST D.3 Logg fra brukbarhetstest Under følger en tabell med logg fra brukbarhetstesten. Tabellen har referanse til eventuelle kommentarer som kom frem under testen. Den har også en kollonne for dokumentering av eventuelle tiltak som har blitt gjennomført som konsekvens av kommentarene. TestID OK/KommentarID Tiltak BT-1 OK BT-2 OK BT-3 OK BT-4 OK BT-5 OK BT-6 Ok BT-7 OK BT-8 Kommentar BT-8 Ikke utbedret siden dette stridet med kundens kommentarer. BT-9 OK BT-10 Kommentar BT-10 Utbedret. BT-11 Kommentar BT-11 Ikke utbedret da dette trolig hovedsaklig skyldes at testpersonen ikke hadde brukt systemet før. BT-12 Kommentar BT-12 Utbedret. BT-13 Kommentar BT-13 Ikke utbedret da dette trolig hovedsaklig skyldes at testpersonen ikke hadde brukt systemet før. BT-14 Kommentar BT-14 Ikke utbedret. Å beholde avkryssinger kan trolig enklest løses ved bruk av JavaBeans. Tabell D.3: Testlogg brukbarhetstest Kommentar BT-8 1 Forstår at det er en sammenheng mellom de ulike fargekodede ordene (Grønn betyr overordnet begrep, rød spesialisering av dette). At det er flere ulike farger oppleves likevel som litt forstyrrende. Ser nytten av fargekoding, men burde kanskje tones noe ned. 2 Ingen problem med å forstå at tittel og sammendrag representerer et dokument som kan klikkes og leses. Tabell D.4: Kommentar BT-8 376

383 VEDLEGG D. RAPPORT BRUKBARHETSTESTD.3. LOGG BRUKBARHETSTEST Kommentar BT-10 1 Facinerende og nyttig at man ved å klikke på opplistede ord under søkefeltet får opp liste der man kan velge andre relaterte ord. Ingen problem med å forstå at lista som kommer opp er klikkbare ord, som fører til endret søk. 2 Ordet Forkjølelse ble tilfeldig valgt. Dette ordet ble ikke funnet i dokumentsamlingen, så systemet spurte Mente du forkjølt?. Opplevdes som litt merkelig, måtte forklares (Levenshtein). Bør kanskje ha en lenke til en side som forklarer hvorfor. Tabell D.5: Kommentar BT-10 Kommentar BT-11 1 Tror i utgangspunktet at stikkordene under dokumentresymé er lenker til andre relaterte dokumenter. Tabell D.6: Kommentar BT-11 Kommentar BT-12 1 I utgangspunktet frustrerende at ord blir fjernet. Måtte forklares. Bør kanskje legge inn en lenke til en side som forklarer hvorfor. Tabell D.7: Kommentar BT-12 Kommentar BT-13 1 Ser nytten av utvidelse med synonymer. Stusser over måten synonymer presenteres for bruker (i parantes). Bør kanskje endres/gjøres klarere. Tabell D.8: Kommentar BT-13 Kommentar BT-14 1 Treet i utgangspunktet veldig spennende, ser helt klart nytten av det. Problemer med utviding. Ikke innlysende at trykk på + utvider treet. (Utvidet først ved å krysse av) 2 Oppleves som rart og unødvendig at kryssene som ble valgt før søk ble utført er fjernet når man går tilbake og vil endre søket. Tabell D.9: Kommentar BT

384 D.4. OPPSUMMERING VEDLEGG D. RAPPORT BRUKBARHETSTEST D.4 Oppsummering av brukbarhetstest Etter testen fikk testperson anlendning til å fortelle om de intrykkene hun satt igjen med. Hun dro spesielt frem avansert søk, og redefinering av søk vha. trestruktur som spennende og bra. Hun ville endret litt på fargevalget, om ikke annet for å gjøre brukergrensesnittet mer estetisk. Hun hadde likevel ikke problem med å forstå nytten av fargekoding. Hun opplevde testen som interessant, og ser på systemet som greit å forstå og bruke. Endringer som blir gjort som følge av testen dokumenteres i loggen. 378

385 Vedlegg E Utvidet test av søkeresultat Vanlige mål på en søkemotors kvalitet er presisjon (eng: precision) og treffrate (eng: recall). Treffrate er andel dokumenter i resultatet som er relevante i forhold til søkestrengen, sammenlignet med totalt antall relevante dokumenter i dokumentsamlingen. Presisjon er antall relevante dokumenter hentet frem i forhold til totalt antall dokumenter i samlingen. De er matematisk enkle indikatorer, men en faktor som vanskeliggjør kraftig er at relevante treff er sentralt i begge beregningene. Det betyr i praksis at man for hver søkestreng som inngår i testsettet manuelt må gå gjennom dokumentsamlingen og avgjøre hva som er relevante treff. En videre gradering av relevans vil komplisere ytterligere. En slik klassifisering bør gjøres av domeneeksperter for å bli troverdig. Gruppa har ikke hatt ressurser, verken økonomisk eller tidsmessig, til å gjennomføre en slik klassifiserig sammen med eksperter på området. Som en alternativ tilnærming har gruppa gjennomført testing av et utvalg nøkkelord i henholdsvis protoypen, EQS og grep-funksjonen (enkelt tekstsøk) i unix, og sammenlignet antall treff. Denne testen sier lite om precission og recall, men gir en indikasjon på det utviklede systemets evne til å finne informasjon i forhold til dagens system (EQS), og et enkelt tekstsøkesystem (grep). E.1 Svakheter ved testen Testen har klare svakheter: Demoen av EQS har et noe større utvalg dokumenter enn det som er tilgjengelig i prototypen. Det søkes kun på enkeltord. Dette for å få sammenlignbare resultater. Grep-funskjonen utfører søk på patterns (no: mønster) Det vil si at søket utføres på hele sekvensen av ord. EQS er også uforutsigbar på søk med flere ord. For eksempel gir søket katastrofe brann ingen treff i EQS selv om dokumenter som inneholder begge søkeordene eksisterer. 379

386 E.2. TESTRESULTATER VEDLEGG E. UTVIDET TEST AV SØKERESULTAT Prototypen utfører stemming av søkestrengen før søket utføres. Dette er ikke tilfelle for verken EQS eller grep. E.2 Testresultater Tabell E.1 viser et utdrag fra testen som er utført. De seks første søkeordene eksisterer på ulike nivå i ontologien, mens de fire siste er begrep som ikke er lagt inn i ontologien. Man kan i grep bestemme om treff skal inneholde det eksakte ordet (grep -w), eller om det er nok at søkeordet er en del av større ord (grep). Testen er utført med begge variasjonene. Kolonnen U/terskel prototyp angir hvor mange dokumenter som er forkastet av protoypen på grunn av lav vekt. Som det fremgår av resultatene E.1 er EQS og grep tilnærmet Søkeord Treff U/terskel EQS grep-w grep protoyp protoyp Ansatt Overlege Infeksjon Kateter Magesår Isolering Prematur Evakuering Brann Arterie Tabell E.1: Utdrag fra test identiske. Avvik kommer av forskjell i tilgjengelig dokumentsamling. Protoypen gir likt eller større antall treff enn (grep -w) på alle typer søk (med og uten ontologiutviding). Grunnen til at det oftest er større, er at stemming stemming utføres. Dette gir treff også på ulike bøyningsformer dersom dette forekommer. Ved søk på høynivåbegreper i ontologien vil protoypen, på grunn av stor utviding søkestrengen, kunne gi høyere antall treff enn både EQS og grep. Søk på ansatt viser eksempel på dette. Prototypen forkaster derimot de treffene som får en vekt som kommer under en definert terskel, og det presenterte resultatet er derfor også i slike tilfeller oftest mindre enn tilfellet er for EQS og grep. 380

387 VEDLEGG E. UTVIDET TEST AV SØKERESULTAT E.3. TESTKONKLUSJON E.3 Testkonklusjon Testresultatene antyder at størrelsen på prototypens returnerte dokumentmengde er en mellomting mellom søk på eksakte ord (grep -w), og EQS, selv ved relativt stor ontologiutvidelse. Ved en eventuell implementasjon bør en mer fullverdig test av precision og recall vurderes. Domeneeksperter bør benyttes for å gi testen troverdighet. Resultater av en slik test vil kunne gi nyttig informasjon for justering av vektingsalgoritmen, og terskelverdien. Videre vil en slik test også gi svar på hvor mange av treffene som faktisk er relevante, og eventuellt hvor mange relevante treff som ikke er med i resultatet. 381

388 E.3. TESTKONKLUSJON VEDLEGG E. UTVIDET TEST AV SØKERESULTAT 382

389 Vedlegg F Tidsplan Dette vedlegget inneholder opprinnelig tidsplan for testingen og en oversikt over faktisk tidsbruk. Avvik er kommentert i kapittel9. 383

390 F.1. OPPRINNELIG TIDSPLAN VEDLEGG F. TIDSPLAN F.1 Opprinnelig tidsplan Figur F.1: Tidsplan for testaktiviteter 384

391 VEDLEGG F. TIDSPLAN F.2. FAKTISK TIDSBRUK F.2 Faktisk tidsbruk Figur F.2: Faktisk tidsbruk 385

392 F.2. FAKTISK TIDSBRUK VEDLEGG F. TIDSPLAN 386

393 Bibliografi [1] Christopher Fox. Code inspection checklist courses/cs555infosec99/deliverables/cppchk.htm. [2] Rick Hower. Software qa/test resource center. Hentet softwareqatest.com. [3] IEEE. Ieee standard for software test documentation. 16 September &prod=STD&arnumber=741968&arSt=&ared=&arAuthor=. [4] Macadamian Technologies Inc. Code review checklist. Hentet macadamian.com/codereview.htm. [5] Hans Schaefer. Mal for testplaner. Hentet testing/testplanmal.rtf. 387

394 BIBLIOGRAFI BIBLIOGRAFI 388

395 Tabeller Brukergrensesnitt 1 Nettsidebasert brukergrensesnitt Hjelpefunksjon Elementer i brukergrensesnitt Nettleseruavhengighet Ontologibehandling 1 Tilgjengelighet ontologi Ontologiegenskaper Ontologistørrelse Utvidelse av søkestreng Utvidelse av søkestreng uten treff i ontologi Søkemodul 1 Format returdata Grensesnitt til søkealgoritme Test av nøkkelordsøk Feilkoder ved søk Levenshtein Vekting Stemming Stoppord Retur av søkeresultat Indeksering 1 Analyse av dokumenter Lagring av indeks Oppdatering av søkeindeks Lagerbehov

396 TABELLER TABELLER Systemtest 1 Nettilgang tjener Autorisering Øktbasert grensesnitt Søketid Visning av søkestreng Navigering til søkeresultater Utviding av søk Reindeksering Plattformuavhengighet Brukergrensesnitt F-B Ontologimodul F-O Søkemodul F-S F-S F-S F-S F-S F-S F-S F-S F-S Indekseringsmodul F-I Systemtest F-ST F-ST F-ST F-ST

397 TABELLER TABELLER 8.22 F-ST F-ST A.1 Mal for testspesifikasjon A.2 Feilrapporteringsskjema Sporingsmatriser 1 Funksjonelle krav Ikke-funksjonelle krav C.1 Testlogg akseptansetest C.2 Kommentar AT C.3 Kommentar AT C.4 Kommentar AT C.5 Kommentar AT C.6 Kommentar AT C.7 Kommentar AT D.1 Informasjon om testperson D.2 Andre personer tilstede under testen D.3 Testlogg brukbarhetstest D.4 Kommentar BT D.5 Kommentar BT D.6 Kommentar BT D.7 Kommentar BT D.8 Kommentar BT D.9 Kommentar BT E.1 Utdrag fra test

398 TABELLER TABELLER 392

399 Figurer 2.1 Eksempel på sporingsmatrise for krav/test F.1 Tidsplan for testaktiviteter F.2 Faktisk tidsbruk

400 FIGURER FIGURER 394

401 Del VII Evaluering 395

402

403 Innhold 1 Innledning Hensikt Omfang Struktur Prosessen Oppgaven Gruppeprosessen Rollene Kommunikasjon Risiko som har slått til Faseevaluering Planlegging Forstudium Kravspesifikasjon Konstruksjon Implementasjon Testing Dokumentasjon Evaluering Presentasjon og demonstrasjon Kunden Produktet Tidsbruk Milepæler Timeforbruk

404 INNHOLD INNHOLD 3 Faget - Kundestyrt prosjekt Generelt Seminarer i gruppedynamikk Six thinking hats Teambuilding Forelesninger Prosjektplanlegging, prosjektdirektiv Kurs i CVS m/eclipse Eksempler ved studenter, forstudium og kravspesifikasjon Konstruksjon og testing Kurs i presentasjonsteknikk Veiledere Praktisk gjennomføring Grupperessurser Maskin- og programvare Rom Evaluering av verktøy Dokumentverktøy L A TEX Microsoft Word Modelleringsverktøy Microsoft Visio Rational Rose Implementasjonsverktøy Eclipse Prosjektverktøy CVS Microsoft Project Diverse verktøy

405 INNHOLD INNHOLD 6 Videre arbeid Arkitektur Bruk av verktøysett Søkeoperatorer Problemer med stemming Ytelse og datalagring Tidsestimat for gjenværende arbeid A Timerapportskjema

406 INNHOLD INNHOLD 400

407 Kapittel 1 Innledning Dette dokumentet gir en evaluering av gruppas gjennomføring av faget TDT4290 Kundestyrt Prosjekt. Denne evalueringen vil omfatte de fleste sider av faget. Gruppa har satt sammen denne evalueringen i felleskap, etter diskusjoner om hva som har fungert bra og hva som har fungert mindre bra. 1.1 Hensikt Hensikten med evalueringen er å se på alle sider ved gjennomføringen av prosjektet. Her er det interessant å se hva som gikk bra, hva som gikk dårlig og hva som er årsakene til de avvikene vi fikk fra planleggingsfasen. Resultatet av denne evalueringen skal kunne brukes som en oppsummering av våre erfaringer fra prosjektet. 1.2 Omfang Evalueringen tar for seg prosessen rundt gruppearbeidet, gruppas syn på faget, ressursene gruppa hadde til rådighet og verktøyene som ble brukt. 1.3 Struktur Evalueringsdokumentet er delt inn i følgende kapitler: Kapittel 2 behandler prosessen rundt prosjektarbeidet. Her evalueres gruppeprosessen og de ulike fasene i prosjektet. Kapittel 3 tar for seg gruppas syn på faget TDT4290 Kundestyrt Prosjekt generelt, samt veiledning, forelesninger og seminarer. 401

408 1.3. STRUKTUR KAPITTEL 1. INNLEDNING Kapittel 4 tar for seg ressursene gruppa hadde til rådighet for den praktiske gjennomføringen av prosjektet. Kapittel 5 Kapittel 6 tar for seg verktøyene gruppa har brukt i gjennomføringen av prosjektet. beskriver videre utvikling av prototypen mot et ferdig produkt. 402

409 Kapittel 2 Prosessen Evalueringen av prosessen rundt prosjektet fokuserer på gruppeprosessen og gir en evaluering av fasene i prosjektet. Prototypen som ble utviklet settes opp mot effektmålet og resultatmålet definert i prosjektdirektivet. I tillegg tar kapitlet for seg gruppas kommunikasjon med kunden, og hvordan gruppa har opplevd å ha en reell kunde å forholde seg til. Innledningsvis gis det en evaluering av oppgaven. 2.1 Oppgaven Oppgaven gikk på å utvikle en prototyp for ontologistøttet søk i potensielt store dokumentsamlinger. Gruppa hadde på forhånd ingen kunnskap innen ontologifeltet, og kun begrenset erfaring med utvikling av søkeverktøy. Noe som opplevdes positivt var at retningen på oppgaven kunne bli definert selv, ved å ta utgangspunkt i egne interesser og linjevalg. Kunden ga relativt frie tøyler til å utforme egen problemstilling og hvilke aspekter ved et søkesystem gruppa ville fokusere på. Sett i ettertid hadde det muligens vært enklere for gruppa å ha en strengere føring på hva kunden ønsket, men friheten medførte også positive erfaringer. Gruppa føler at de har fått mye kunnskap om et stort og interessant fagfelt, som også blir satset på i store forsknings- og utviklingsmiljøer. 2.2 Gruppeprosessen I dette avsnittet gis en evaluering av de ulike rollene i gruppa. Kommunikasjonen internt i gruppa evalueres også Rollene Gruppa delte opp rollene slik at hver person fikk en spesifikk rolle. Det vil her bli gitt en kort forklaring av hver enkelt rolle, samt en evaluering av hvordan rollen fungerte. 403

410 2.2. GRUPPEPROSESSEN KAPITTEL 2. PROSESSEN Prosjektleder har hatt det overordnede ansvaret for prosjektet. Han hadde ansvar for møter med veileder og internmøter. Prosjektleder er en svært viktig rolle i et prosjekt. Han må motivere gruppemedlemmene, ta avgjørelser og sørge for progresjon i prosjektet. Prosjektlederrollen har fungert fint gjennom hele prosjektet og har hatt kontroll på det administrative. Kundekontakt har hatt ansvaret for kommunikasjonen med kunden og andre eksterne aktører i prosjektperioden. Han har også vært ordstyrer på kundemøter.kundekontaktrollen har fungert bra gjennom hele prosjektperioden, men relevansen for denne rollen vil bli større i prosjekter med flere personer involvert. QA-ansvarlig har hatt ansvar for at kundens krav blir overholdt, samt at all dokumentasjon følger standardene som er satt og at det er gjennomgående konsistens i rapporten. Uten kontinuerlig konsistenssjekking og korrekturlesning er det fare for at sluttjobben med dette blir stor og dermed nedprioritert ettersom sluttfasen av et prosjekt ofte kan være svært hektisk. Dette har fungert godt gjennom hele prosjektet. Dokumentansvarlig har hatt ansvar for maler og standarder, samt koordinere administrative oppgaver i forbindelse med levering av sluttrapporten. Dokumentansvarlig er en viktig rolle i et prosjekt hvor det skal leveres en rapport som har et såpass stort omfang. Når det gjelder maler og standarder i dette prosjektet er det noe gruppa har satt i felleskap, og alle gruppemedlemmene har vært med på å følge disse. Testansvarlig har hatt det overordnede ansvaret for at testplan og de spesifikke testene har blitt produsert, samt at selve testingen har blitt gjennomført. Selve produksjonen av testingen viste seg å være en mye større og krevende oppgave enn først antatt, men ansvarlig taklet dette på en god måte, og gruppa er fornøyd med det arbeidet som har blitt gjort med tanke på testingen. Teknisk ansvarlig har hatt ansvaret for å gjøre de strategiske valgene for implementasjonen, samt å være en ressursperson for tekniske spørsmål og henvendelser både internt i gruppa, mot kunden og ovenfor eksterne aktører. Teknisk ansvarlig har satt seg godt inn i teknologien som er brukt, og hatt hovedansvar for å løse vanskelige problemer under implementasjon Kommunikasjon Kommunikasjonen internt i gruppa har gjennomgående vært god. Jevnlige internmøter har sikret at gruppas medlemmer har kunnet jobbe parallelt med sine egne oppgaver. Ved å legge fram arbeidet som har blitt gjort mellom hvert møte har de andre deltagerne på gruppa alltid hatt en formening om hvor prosjektet har befunnet seg, og har kunnet samkjøre sitt arbeid med de andre. Gruppa satt også ofte sammen på datasaler og jobbet, noe som 404

411 KAPITTEL 2. PROSESSEN 2.3. FASEEVALUERING har førte til at mange avgjørelser ble tatt fortløpende. I tillegg har gruppa hyppig benyttet hurtigmeldinger i form av MSN Messenger og e-post. Totalt sett har kommunikasjonen internt fungert svært godt Risiko som har slått til I prosjektdirketivet ble det satt opp en risikotabell med 10 punkter som gruppa så på som reelle farer i forbindelse med prosjektet. I dette avsnittet omtales punktene som slo til. Når gruppa i ettertid ser på risikotabellen er det to punkter som har slått til. Punkt 3 i risikotabellen tar for seg problemet med at gruppa ikke finner noen god ontologi utviklet for helsevesenet. Ettersom det ikke eksisterer en gratis norsk ontologi måtte gruppa lage en egen ontologi. Dette var noe gruppa var forberedt på, og konsekvensene ble ikke alvorlige. Det ble laget en begrenset ontologi med bakgrunn i et utvalg av dokumentene det søkes i. I konstruksjonsfasen opplevde gruppa problemet beskrevet i punkt 6 i risikoplanen. Kunden og gruppa hadde ulike oppfatninger rundt konstruksjonen av en mindre del av prototypen. Denne delen innebar bruken av ontologien i forhold til brukergrensesnittet. Da dette ble oppdaget måtte det iverksettes tiltak for å ordne opp i misforståelsene. Noe tid ble brukt på å utarbeide et dokument med skjermbilder av forskjellige løsningsskisser. Her ble det listet opp fordeler og ulemper med hver løsning. Dette ble sent til kunden. På det påfølgende kundemøtet ble misforståelsene oppklart, og konstruksjonen ble ferdigstilt utifra kundens ønsker. At dette punktet i risikoplanen slo til medførte at avslutningen av konstruksjonsfasen ble noe forskjøvet. Implementasjonsfasen ble også noe forlenget på grunn av dette. Siden gruppa hadde lagt inn litt ekstra tid på slutten av prosjektet, fikk dette ingen konsekvenser for ferdigstillingen av prosjektet innen den fastsatte datoen. 2.3 Faseevaluering Dette avsnittet inneholder en kort evaluering av hvordan gruppa har oppfattet hver av fasene med hensyn til gjennomføringen Planlegging Ettersom gruppa sto relativt fritt til å vinkle oppgaven, måtte det brukes noen dager på å finne ut hvordan dette skulle gjøres, og hvordan oppgaven skulle avgrenses. Samtidig måtte retningslinjene for prosjektet skrives. Dette førte til at det tok litt lang tid før arbeidet med å utføre selve oppgaven kom i gang. I ettertid har gruppa erfart at denne planleggingen og struktureringen av gruppa og gruppefunksjonene var nyttig, og har bidratt med å holde struktur og framdrift relativt god hele veien. 405

412 2.3. FASEEVALUERING KAPITTEL 2. PROSESSEN Forstudium Da fagområdet oppgaven omhandlet var nytt for alle på gruppa, ble denne fasen både viktig og kritisk for resten av prosjektgjennomføringen. Det ble satt av mye tid til å sette gruppa inn i de forskjellige mulighetene, og det arbeidet som er gjort på området av andre. Det ble produsert mye viktig bakgrunnsinformasjon i denne fasen, og den la på mange måter grunnlaget for de resterende fasene. Forstudiet var kanskje den fasen, bortsett fra dokumentasjonsjobbingen på slutten, der gruppa har jobbet best sammen Kravspesifikasjon Da kunden ga rimelig frie tøyler helt fra starten av, hadde den heller ikke så mange konkrete krav da gruppa skulle sette opp kravspesifikasjonen. Dette medførte at gruppa i stor grad selv formulerte kravene. Kunden godkjente tidlig kravene, og fasen ble derfor noe kortere enn først estimert Konstruksjon Etter at kravspesifikasjonen var ferdig og kravene fastsatt, ble fokus flyttet til realiseringen av systemet. Konstruksjonsdokumentet ble skrevet, med det utgangspunktet at alle kravene som skulle tilfredsstilles. I ettertid viste det seg at gruppa og kunden ikke hadde samme oppfatning vedrørende alle kravene, og dette medførte, som nevnt, en diskusjon rundt noe av funksjonaliteten som skulle utvikles. Dette resulterte i at fasen ikke kunne avsluttes til planlagt tid. Selv om noen ressurser ble satt til implementering, måtte hovedfokus være på avslutningen av konstruksjonsfasen Implementasjon I starten av implementasjonsfasen oppstod det, som tidligere nevnt, en diskusjon rundt noe av funksjonaliteten til prototypen. Kunden hadde en annen oppfatning av et par krav enn det gruppa selv hadde. Etter et oppklarningsmøte med kunden fortsatte konstruksjons- og implementasjonsfasen som normalt, og fasene må kunne sies å ha blitt gjennomført på en god måte selv med problemene underveis Testing Testfasen begynte under konstruksjonen, med at testene skulle skrives på bakgrunn av kravene fra kravspesifiskasjonen. Det viste seg at formuleringen av testene tok lengre tid enn antatt. Arbeidet med testplanen holdt på helt til slutten av implementasjonen, da det også underveis i denne fasen ble gjort små endringer i brukergrensesnitt og på funksjonaliteten som krevde endringer i testene. Akseptansetesten og brukbarhetstesten som ble utført var nyttige, og ga gode innspill og kommentarer. 406

413 KAPITTEL 2. PROSESSEN 2.4. KUNDEN Dokumentasjon Denne fasen ble brukt til å sette sammen sluttrapport, sørge for konsistens mellom de forskjellige dokumentene og korrektur av sluttrapporten. Dette tar mye tid, og i siste periode av prosjektet ble det brukt mye ressurser på denne fasen, siden sluttrapporten er et viktig resultat av prosjektet. Alle gruppens medlemmer har vært involvert i denne fasen, men noen har brukt mer tid enn andre, blant andre QA ansvarlig og dokumentansvarlig Evaluering Denne fasen ble brukt til å skrive evalueringskapitlet i sluttrapporten. Her har gruppa diskutert sin oppfatning av faget, kunden, gruppas egen prosess osv. Gruppa har også gjort vurderinger på hva som førte til avvik fra planleggingsfasen Presentasjon og demonstrasjon Den siste fasen av prosjektet innebar forberedelse til presentasjon og demonstrasjon, med den påfølgende siste presentasjonen for kunde, veileder og sensor. Denne fasen inneholdt oppsett av struktur for presentasjonen, og øvelse til presentasjonen. Siden gruppa har kort tid til å legge frem prosjektet på presentasjonen, må dette være nøye planlagt. 2.4 Kunden Kommunikasjonen mellom gruppa og kunden har gjennom hele prosjektperioden vært svært god, noe som er viktig for at et prosjekt skal bli vellykket. Kunden har vært behjelpelig med å svare på spørsmål, og med å gi bakgrunnsinformasjonen som har vært nødvendig. Kunden har også tydelig vist interesse for prosjektet, samtidig som det har blitt påpekt at jobben gruppa har gjort er nyttig for bedriften. Dette har helt klart påvirket motivasjonen til gruppemedlemmene. Vår kunderepresentant byttet midt i prosjektperioden arbeidsgiver. Dette medførte at kunderepresentanten ikke jobbet hos kunden i siste halvdel av prosjektperioden. Både kunde og kunderepresentants nye arbeidsgiver la likevel alt til rette for at dette ikke skulle føre til hindringer eller problemer for gruppa og prosjektet. Selv om det kunne virke noe spesielt at kunderepresentanten ikke jobbet hos gruppas kunde lengre, føler vi at dette fungerte svært bra. Byttet av arbeidsgiver medførte ingen merkbare forskjeller for vår utførelse av prosjektet. Under hele testfasen hadde gruppa også god kontakt med en testansvarlig hos kunden. Det å få en reell kunde i et skoleprosjekt har gruppa opplevd som veldig positivt, og det er med på å heve realismen i prosjektet betraktelig. Gruppas erfaringer etter det første møtet med en reell kunde er svært positive, og disse erfaringene er noe man vil kunne ha nytte av også i en jobbsituasjon senere. 407

414 2.5. PRODUKTET KAPITTEL 2. PROSESSEN 2.5 Produktet Dette avsnittet inneholder en evaluering av prototpyen som er laget, spesielt med hensyn på de effektmål og resultatmål som ble bestemt i planleggingsfasen. Her vil også en evaluering fra kunden rundt oppnåelse av disse målene legges ved. Effektmål Oppgavens effektmål var todelt, der det ene gikk på å høyne systemets precision og recall, mens det andre var å bedre brukervennligheten av systemet. Gruppa har kjørt tester for å få et bilde av forbedringene i forhold til det eksisterende systemet. Det ble utført brukbarhetstest mot en sluttbruker som bruker det eksisterende systemet i dag, samt at gruppa kjørte interne komparative tester mot dokumentsamlingen både med den prototypen som er utviklet, og med søkeverktøy tilsvarende dagens system. Resultatene fra brukbarhetstesten og akseptansetesten som ble gjennomført mot sluttbruker og kunden viser at begge disse mener det er store forbedringer i brukergrensesnittet. Dette kommer klart til syne i kommentarer fra kunden under akseptansetesten, der de kommenterte at funksjonalitet de har fått mye klager på, nå virker mye bedre. Resultatmål På bakgrunn av evalueringen av effektmålene nevnt ovenfor er det naturlig å slutte at gruppa også i stor grad har nådd det resultatmålet som ble satt. Prototypen som er utviklet gjennomfører et ontologistøttet søk mot dokumentsamlingen, og gruppa føler at søkeresultatene også er forbedret i forhold til det sluttbrukerne oppnår med dagens løsning. Kundens evaluering Kunden har også gjort en evaluering av hvorvidt effektmål og resultatmål er oppnåd. Under følger utdrag fra to mail fra kunden. Effektmål:... I tillegg mener jeg at det er blitt enklere for brukerne å endre på søket....her mener jeg at søket også er forbedret sett fra brukerens ståsted da det å søke blir gjort enklere. Brukeren får direkte hjelp til enkelt å utvide eller innsnevre sitt søk. Resultatmål: Dette mener jeg er oppfylt, og for å underbygge dette så kan jeg opplyse om at arbeidet med å se på hvilke lærdommer som kan plukkes opp fra prosjektet og hvordan disse skal legges inn i EQS allerede har begynt. Ledelsen i Extend ønsker å starte å legge inn deler av det dere har gjort i EQS før jul. Stikkord her er utvidelse med ontologier, bedre presentasjon av søkeresultat, stemming og stoppord. Prosjektet har helt klart hatt verdi for oss. Jeg tenker da spesielt på at vi har fått en prototype som konkret viser hvordan vi kan gi søk i EQS et kraftig løft, både mht kvalitet og brukervennlighet. Vi vet samtidig at søk er et område vi har mye ugjort på og at våre kunder melder dette som et viktig forbedringsområde i EQS. 408

415 KAPITTEL 2. PROSESSEN 2.6. TIDSBRUK 2.6 Tidsbruk Dette avsnittet inneholder en evaluering av tidsfristene og timeestimatene gruppa satt i planleggingsfasen av prosjektet. Det vil her bli evaluert om milepælene gruppa satte seg var realistiske, og hvorvidt de ble holdt. Det vil også bli diskutert årsaker til at frister og timeantall ikke ble holdt, der det er avvik fra estimerte verdier Milepæler I planleggingsfasen ble det satt opp en plan med milepæler for alle fasene i prosjektet. Disse milepælene var tidsfrister for når en fase burde avsluttes. Denne planen med milepæler ble satt opp i en tabell i prosjektdirektivet. I tabell 2.1 er tabellen fra prosjektdirektivet utvidet med en kolonne for reell avsluttet dato. Estimert dato Reell dato Fase avsluttet Planlegging ferdig Forstudium ferdig Kravspesifikasjon ferdig Konstruksjon ferdig Implementasjon ferdig Dokumentasjon ferdig Testing ferdig Evaluering ferdig Presentasjon og demo ferdig Tabell 2.1: Estimerte og reelle milepæler i prosjektet Disse milepælene ble satt opp for å ha en klar plan for når fasene i prosjektet skulle avsluttes. Noen av milepælene ble nok satt opp noe optimistisk for at gruppa skulle ha god tid på kvalitetssikring til slutt. Som det fremgår av tabell 2.1 holdt gruppa de første milepælene. Konstruksjonsfasen ble forskjøvet med en uke, noe som medførte en forskyvning av milepælene i fasene etter konstruksjonsfasen. Selv om milepælene kan ha vært noe optimistisk satt på de siste fasene, kan det likevel være interessant å se hva som er årsakene til avvikene. Gruppa planla god tid til forstudieog kravspesifikasjonsfasen i planleggingen. Grunnen til dette var at oppgaven var forholdsvis åpen, og at oppgaven innebar en del teknologier gruppa ikke var kjent med fra før. Gruppa trengte derfor å bruke mye tid til å sette seg inn i teknologiene og hvilke alternativer den hadde til implementeringen av systemet. Ferdigstillingen av konstruksjonsfasen måtte utsettes med 6 dager, noe som resulterte i en utsettelse av ferdigstillingen av implementasjonsfasen. Årsaken til at konstruksjonsfasen måtte utsettes skyldes flere ting. I utgangspunktet hadde kanskje gruppa satt av litt for lite tid til denne fasen. I tillegg oppsto det en misforståelse med kunde. Årsakene til at misforståelsene oppsto er diskutert i 409

416 2.6. TIDSBRUK KAPITTEL 2. PROSESSEN kapittel Selv om milepælene ble noe forskjøvet, innebar det ingen stor dramatikk for prosjektets sluttføring. Grunnen til dette var at gruppa hadde satt opp god tid på slutten i tilfelle noe uforutsett skulle inntreffe. Dersom det hadde blitt dramatisk med tidsfristen hadde gruppa måtte bruke sine egne valg fra kravspesifikasjonen til å konstruere utifra. Noen av fasene hadde overlappingsperioder, der noen i gruppa startet på neste fase før resten var ferdig med den gjeldende fasen. Dette ble gjort for at det skulle bli lettere å få planlagt hvilke arbeidspakker som skulle være med i den kommende fasen. Selv om konstruksjonsfasen ble noe forskjøvet, ble implementasjonsfasen startet når den skulle. Men med mindre ressurser enn planlagt, siden det ble brukt en del ressurser på konstruksjon i starten på implementasjonsfasen. Diskusjonen rundt konstrueringen gjaldt ingen kritiske elementer for implementasjonen, derfor kunne store deler av konstruksjonen implementeres før den siste biten kom på plass. Selv om fasene var avsluttet, var sjelden dokumentene helt ferdige. Men når fasen var avsluttet, skulle innholdet i dokumentene være ferdig. Det ble i tiden etter fasene brukt ressurser på gjennomlesing og korrektur på dokumentene. Gruppa måtte også bruke tid på å sørge for at alle dokumentene var konsistente. De siste fasene ble gjennomført noe i parallell. Testing ble utført noe i prallell med dokumentasjon, som planlagt. De siste dagene ble brukt til å planlegge og strukturere en god presentasjon. Som diskutert i neste kapittel brukte gruppa noe mer timer i siste periode av prosjektet. Likevel klarte gruppa å fullføre prosjektet innen tidsfristen, uten store tidsmessige problemer Timeforbruk Gruppa estimerte 1860 timer tilsammen for 6 personer på prosjektet. Dette gir ca. 143 timer per uke. Første uke startet på tirsdag, og siste uke slutter på torsdag, med presentasjonen. I grafen under er det likevel estimert med 143 timer i uka. Gruppa var hele tiden klar over at timeantallet ville stige noe den siste perioden av prosjektet. Totalt sett traff gruppa ganske rett på det totale timeantallet, og gikk bare noen prosenter over estimert total tid. Utifra figur 2.1 går det frem at timeantallet ligger noe under estimert tid i midten av prosjektperioden. Det er flere årskaer til dette. Som nevnt ovenfor var gruppen klar over at timeantallet ville stige noe de siste 2 ukene. Men gruppa ville allikevel ikke estimere denne stigningen i timeantall, da det var ønskelig å fordele timebruk mest mulig jevnt. I figur fig:timegraf fremgår det at timeforbruket har et bunnivå i uke 42. Dette skyldes i hovedsak at gruppas medlemmer hadde store karaktertellende innleveringer i andre fag denne uken. Det var ellers i ukene 38 til og med 42 mange store innleveringer i andre fag. Dette virket inn på timeantallet som ble ført i denne perioden for prosjektet. Gruppa føler 410

417 KAPITTEL 2. PROSESSEN 2.6. TIDSBRUK likevel at tiden ble brukt effektivt, og at tilbakemeldingen var at arbeidet som ble utført i perioden var av god kvalitet. Det totale timeantallet for prosjektet ble 1936 timer, mot 1860 timer estimert. Dette utgjør 75 timer. Siden denne differansen er relativt liten, er gruppa fornøyd med gjennomføringen. Gruppa førte timer i en nettsidebasert applikasjon som ble utviklet i planleggingsfasen. Denne applikasjonen genererer et timerapportskjema. Dette timerapportskjemaet er vedlagt i vedlegg A. Dette skjemaet gir en mer detaljert plan over timebruken i prosjektet. Timeantallet fikk en topp i uka før presentasjonen. Dette var gruppa klar over at kunne skje allerede i planleggingsfasen i prosjektet. Denne perioden ble det mye jobb med sluttføring av rapporten. Sluttrapporten er et viktig resultat av prosjektet, det var derfor ønskelig å bruke mye tid på å forbedre denne før innlevering. Figur 2.1: Timeforbuk i prosjektets faser 411

418 2.6. TIDSBRUK KAPITTEL 2. PROSESSEN Figur 2.2 viser antall timer brukt i forhold til antall timer estimert i hver fase. Timeantallet i forstudiefasen gikk noe over estimert timeantall. Dette skyldes at det var mange deler å sette seg inn i for å kunne velge gode løsninger. I kravspesifikasjonsfasen ble det brukt midre timer enn estimert. En av årsakene til dette var at gruppa hadde et klart bilde av kravene som burde inngå i systemet etter en god jobb med forstudiet. Kunde var umiddelbart fornøyd med kravene i kravspesifikasjonen, og det ble ikke utført mange iterasjoner på oppsetting av krav slik som var antatt i planleggingen av prosjektet. Gruppa ser i ettertid at det burde blitt utført flere iterasjoner med kunde på kravene som var satt opp, for å få en felles oppfattelse av alle delene i systemet. De største avvikene kommer på dokumentasjons- og testefasen. Årsaken til avviket i dokumentasjonsfasen er at all korrektur, sammensetting av sluttrapport og dokumentering har gått inn under denne fasen. Den siste perioden av prosjektet har det vært mye jobb med dokumenteringen. Testfasen tok også mye lengre tid enn antatt. Det ble utarbeidet en svært grundig og omfattende testrapport som tok mye tid. I tillegg tok test av precision og recall noe ekstra tid til slutt. På forelesninger sendte gruppa som oftest bare noen representanter. Timeantallet her er derfor noe under estimert. Under prosjektledelse har det stort sett bare blitt ført timer fra møter som prosjektleder har holdt, sammen med forberedelser og oppsetting av tidsplaner med arbeidspakker. Det ble derfor også her noe mindre timer enn estimert. Figur 2.2: Timeforbuk i prosjektets faser 412

419 Kapittel 3 Faget - Kundestyrt prosjekt I dette kapitlet vil gis en evaluering av faget TDT Kundestyrt Prosjekt, seminarene gruppa har deltatt på i forbindelse med faget, forelesningene og veilederhjelpen som har blitt gitt underveis i prosjektet. 3.1 Generelt Gruppa er svært positiv til faget Kundestyrt Prosjekt. Faget er det mest realistiske faget man får i løpet av studiet i forhold til en jobbsituasjon senere, og dette gjør faget svært viktig. Faget gir viktig erfaring innen prosjektarbeid og gruppesamarbeid som man kan få stor nytte av senere. Arbeidsbelastningen i faget er stor, men dette var noe gruppa visste om på forhånd, og alle gruppemedlemmene var innstilt på å ta i et tak. Det følger naturlig at man ved et så tett samarbeid over en såpass lang periode opplever både oppturer og nedturer, og at det kommer til uenigheter, men gruppa har hele veien prøvd å ha en åpen kommunikasjon internt, og dermed unngått de store konfliktene. 3.2 Seminarer i gruppedynamikk I forbindelse med faget har gruppa deltatt på to obligatoriske seminarer i gruppedynamikk. Det første seminaret ble holdt av Jens Aarup, som til daglig jobber med lederutvikling i Statoil. Det andre seminaret ble holdt av kadetter fra Luftkrigsskolen Six thinking hats Dette seminaret var delt inn i to deler, med Jens Aarup som foredragsholder. Den første delen omhandlet gruppedynamikk, og i den andre delen ble verktøyet Six thinking hats introdusert. I den første delen belyste Aarup forskjellige sider ved prosjektarbeid, blant annet om viktigheten av at prosjektgrupper jobber mot et felles mål. 413

420 3.3. FORELESNINGER KAPITTEL 3. FAGET - KUNDESTYRT PROSJEKT I den andre delen av seminaret ble Six thinking hats introdusert. Dette verktøyet inneholder seks fiktive hatter med hver sin farge. De ulike hattene representerer spesielle måter å tenke på, og når man tar på seg en hatt må man fokusere på å tenke i en bestemt retningen. Ved at hele gruppa bruker samme hatt samtidig, oppnår man at alle tenker i samme retning. Dette kan ved en god gjennomføring være et nyttig verktøy ved idémyldringsprosesser og lignende aktiviteter. Aarup fortalte også om reelle situasjoner i hans kariere hvor han hadde brukt tenkehattene med godt resultat. Dette var særdeles god motivasjon for bruken av hattene. Gruppa føler at seminaret var både lærerikt og morsomt og at Aarup var en utmerket foredragsholderen. Med sine kunnskaper, erfaringer og humor holdt han seminaret levende i alle de syv timene Teambuilding Seminaret var delt opp i to deler. Den første delen omhandelet generell gruppeteori, og ble holdt av kadetter ved Luftkrigsskolen. Etter dette gikk turen til Estenstadmarka hvor gruppa fikk tildelt to kadetter som ledet seminaret. Underveis utførte gruppa forskjellige oppgaver som krevde samarbeid. Det var også en lengre tilbakemeldingsdel hvor hver gruppemedlem fikk mulighet til å gi tilbakemelding til de andre på gruppa. Gruppa hadde derfor stor nytte av denne seansen. Hele seminaret ble avsluttet med en tautrekkingskonkurranse, og selv om regnet øste ned store deler av dagen, føler gruppa at seminaret var både nyttig og en fin opplevelse. 3.3 Forelesninger Dette avsnittet tar for seg de forelesningene som er gitt i faget, hvor personer fra gruppa har vært tilstede. Det blir gitt en kort evaluering av innholdet og gjennomføringen av hver forelesning Prosjektplanlegging, prosjektdirektiv. Holdt av: Jon Atle Gulla Evaluering: Denne forelesningen var helt i starten av prosjektet, og ga en god innføring i oppstartsfasen. Formålet med prosjektdirektivet ble forklart, og noen punkter for hvordan man skulle foreta en god planlegging ble gjennomgått. Forelesningen var nyttig da den ga gruppa hjelp til å komme skikkelig igang med arbeidet Kurs i CVS m/eclipse. Holdt av: Jon Espen Ingvaldsen 414

421 KAPITTEL 3. FAGET - KUNDESTYRT PROSJEKT 3.4. VEILEDERE Evaluering: En kort og informativ forelesning om hvordan man setter opp CVS og bruker editoren Eclipse for å få versjonskontroll. Gruppa valgte å ikke bruke CVS før implementasjonen, og det gikk dermed en god stund fra forelesningen ble holdt til CVS ble benyttet. Gruppa fikk likevel utbytte av forelesningen Eksempler ved studenter, forstudium og kravspesifikasjon Holdt av: Reidar Conradi og studenter Evaluering: Reidar Conradi innledet forelesningen med 20 minutter om Use Case-basert estimering. Her ble det vist til heftet om hvordan denne estimeringen kunne utføres. Det ble mye teoretisk informasjon om denne metoden, noe som gjorde det noe vanskelig å følge med på alt som ble lagt frem. I andre del av forelesningen ble det holdt en presentasjon om hvordan kravspesifikasjon og forstudium kunne utføres. Denne presentasjonen ble holdt av fjorårets studenter i faget. Studentene som holdt presentasjonen virket veldig godt forberedt, og det var interessant og lærerikt å høre hvordan studentene hadde utført disse fasene i fjorårets prosjekt Konstruksjon og testing Holdt av: Harald Rønneberg (Statoil) Evaluering: Forelesningen ble holdt i en ganske hektisk periode av prosjektet, der alle gruppene hadde mye å gjøre. Dette resulterte i et svært redusert oppmåte. Likevel var forelesningen svært god og lærerik, da det ble gitt eksempler fra Statoils egne prosjekter og deres dokumenter for fasene. Dette var med på å gjøre prosjektet enda mer realistisk, og ga av god bekreftelse på at prosjektgjennomføringen ikke er oppkonstruert for å passe til studentene Kurs i presentasjonsteknikk Holdt av: Per Kotte (Statoil) Evaluering: En veldig motiverende og god gjennomgang av en mengde feller det er lett å gå i når man skal holde et foredrag eller en presentasjon. Kotte hadde god kontakt med de frammøtte, og de fra gruppa som var tilstede, følte at det hadde vært en nyttig erfaring. 3.4 Veiledere Gjennom hele prosjektperioden har gruppa hatt professor Jon Atle Gulla som hovedveileder og femteårsstudent Gunn Marie Navestad som hjelpeveileder. Gruppa føler at veilederne har vært til stor hjelp, og at god veiledning er esensiellt for et godt resultat. Veilederne har 415

422 3.4. VEILEDERE KAPITTEL 3. FAGET - KUNDESTYRT PROSJEKT gjennom hele perioden vært flinke til å komme med tilbakemeldinger, korrektur og tips til valg av løsninger. De har også stilt godt forberedt til møter, noe som har gjort at effekten av møtene har vært stor. Gulla innehar stor kompetanse også innen området rundt søk og gjenfinning av informasjon, og dette har vært til stor nytte. Navestad tok faget høsten 2003 og hadde derfor erfaring med problemer gruppa møtte underveis. Gruppa kunne kanskje ha ønsket enda litt mer kritikk til noen av dokumentene, men dette har ikke ført til noen problemer. Gruppa er svært fornøyd med veiledningen gjennom prosjektet. 416

423 Kapittel 4 Praktisk gjennomføring I dette kapitlet vil gruppa gi en evaluering av de ressursene som var tilgjengelige for den praktiske gjennomføringen av prosjektet. 4.1 Grupperessurser Gruppa hadde 6 medlemmer og et estimert timeforbruk på 1860 timer totalt på hele prosjektet, noe som tilsvarer 310 timer per student. Timene har blitt ført på et nettsidebasert timeføringssystem, som gruppa laget i planleggingsfasen. Hver gruppe ble tildelt en e- postadresse som hovedsakelig ble brukt til møteinnkallelser og generell informasjon internt i gruppa. 4.2 Maskin- og programvare 4 klasse datateknikk har reservert femte etasje i P15-bygget. Her er det en datasal med Pentium 4 maskiner. Denne har til tider hatt et svært dårlig inneklima, da friskluftanlegget har vært ustabilt, samtidig som det ofte har vært mange av datamaskinene som har vært ute av drift. Denne ene datasalen ble ikke tilstrekkelig for alle studentene, noe som resulterte i bruk av andre datasaler i bygget. Alle datasalene var knyttet til printere i hver etasje. Grunnet disse salene har maskintilgang ikke vært noe stort problem. I tillegg til datasalen med generelle datamaskiner, har gruppa hatt tilgang på et ekstra rom hvor hver gruppe har fått disponere en maskin med fulle rettigheter. Det tok lang tid før tilgang og kontroll over denne maskinen ble tildelt gruppa, men dette førte heller ikke til større problemer. 417

424 4.3. ROM KAPITTEL 4. PRAKTISK GJENNOMFØRING 4.3 Rom Gruppa har gjennomført de fleste internmøtene i femte etasje i P15-bygget, enten på grupperom eller i en sittegruppe i fellesarealet samme etasje. De fleste kundemøtene har blitt gjennomført i Realfagsbygget, i et grupperom gruppa reserverte på fast tidspunkt hver uke. Veiledermøtene har blitt arrangert på møterom reservert av hovedveileder, i IT-bygget. Det har ikke vært noen problemer å få tak i rom for møter og annet gruppearbeid. 418

425 Kapittel 5 Evaluering av verktøy Dette kapitlet gir en evaluering av de verktøyene som har blitt benyttet i prosjektet. 5.1 Dokumentverktøy Dette avsnittet tar for seg verktøyene brukt til skriving av dokumentasjon L A TEX Gruppa valgte bruk av L A TEXtil skriving av fasedokumenter og sluttrapport. Valget var enkelt da fagstaben anbefalte bruk av L A TEXsamtidig som gruppemedlemmene hadde lyst til å lære seg verktøyet. Dokumentasjon om L A TEXpå Internett er også lett tilgjengelig, slik at det var greit å finne informasjon om verktøyet. Til selve skrivingen av dokumentene trenger man bare en standard teksteditor. Læringsprosessen gikk greit for alle på gruppa, og gruppemedlemmene sitter i dag igjen med kunnskap om et nyttig verktøy for senere prosjekt- og masteroppgaver Microsoft Word Gruppa brukte Microsoft Word til alle møteinnkalleser og møtereferat. Dette fordi disse skulle skrives allerede fra dag 1, og fordi dette aldri blir lange dokumenter. Microsoft Word er et svært anerkjent verktøy, og gruppa opplevde ingen problemer med dette. 5.2 Modelleringsverktøy Dette avsnittet tar for seg modelleringsverktøyene brukt i prosjektet. 419

426 5.3. IMPLEMENTASJONSVERKTØY KAPITTEL 5. EVALUERING AV VERKTØY Microsoft Visio Microsoft Visio ble blant annet brukt til å lage forslag til brukergrensesnitt for godkjenning hos kunden. I tillegg ble det benyttet til å lage modeller som viser overordnet funksjonalitet mellom moduler i systemet. Gruppa hadde erfaring med bruk av dette verktøyet fra tidligere, og er godt fornøyd med dette Rational Rose Rational Rose ble brukt for å lage klassediagrammer og datamodeller. Et anerkjent verktøy som er mye brukt, og som gruppa hadde erfaring med fra før. 5.3 Implementasjonsverktøy Dette avsnittet tar for seg implementasjonsvertøyet brukt i prosjektet Eclipse Etter råd fra fagstaben valgte gruppa å benytte open source-editoren Eclipse for kodeskrivingen. Dette først og fremst fordi dette verktøyet har god støtte for CVS versjonshåndtering, og fordi det er fritt tilgjengelig. Editoren virket for det meste bra, men gruppa opplevde også problemer med at den var treg og plutselig kunne henge seg uten noen åpenbar grunn. 5.4 Prosjektverktøy Gruppa har benyttet verktøy for versjonskontroll og for å administrere fremgangen og tidsplanene. Disse er beskrevet og evaluert nedenfor CVS Gruppa valgte å bruke CVS for versjonskontroll på implementasjonen. Fasedokumentene ble holdt utenfor, da CVS ikke ble satt opp før litt ute i prosjektet. CVS er et anerkjent produkt for versjonshåndtering, og fungerte bra til de formål gruppa brukte det til Microsoft Project For å lage og vedlikeholde framdrifts- og tidsplaner valgte gruppa å bruke Microsoft Project. Dette verktøyet er spesielt tilpasset denne typen oppgaver, og finnes tilgjengelig på skolens maskiner. Gruppa opplevde dette som et godt verktøy. Tidsplanene ble eksportert til bildeformat, for så å bli satt inn i sluttrapporten. 420

427 KAPITTEL 5. EVALUERING AV VERKTØY 5.5. DIVERSE VERKTØY 5.5 Diverse verktøy I tillegg til verktøyene nevnt ovenfor benyttet gruppa seg av diverse andre verktøy. Disse verktøyene vil ikke bli evaluert på lik linje med de andre, men vil likevel bli nevnt. Blant disse var: Internet Explorer - Brukt til testing av brukergrensesnitt. Mozilla Firefox - Brukt til testing av brukergrensesnitt. Opera - Brukt til testing av brukergrensesnitt. MSN Messenger - Brukt for hurtigmeldingskommunikasjon mellom gruppemedlemmene. Adobe Acrobat Reader - Brukt for å få lese fasedokumenter og sluttrapport. Adobe Photoshop - Brukt for å redigere bilder før innsetting i fasedokumenter/sluttrapport. F-Secure SSH-klient - Brukt for å koble seg til unix-shell på skolen. 421

428 5.5. DIVERSE VERKTØY KAPITTEL 5. EVALUERING AV VERKTØY 422

429 Kapittel 6 Videre arbeid Prototypen gruppa har utviklet, undersøker muligheten for å benytte ontologier for klassifisering av dokumenter i en potensielt meget stor database, spesielt med tanke på gjenfinning av informasjon. Dette kapitlet presenterer kursorisk informasjon om hvilke endringer og forbedringer som vil være nødvendig for å lage et ferdig produkt tilpasset et produksjonsmiljø. 6.1 Arkitektur Kommunikasjon med RMI kan vurderes omgjort til bruk av JavaBeans for å enklere kunne integrere systemet inn i nettside-applikasjoner. Selv om dette ikke er noe krav, vil ikke gruppa anbefale at RMI brukes i fremtiden med mindre det er et reellt krav om kjøring i en heterogen distribuert setting. 6.2 Bruk av verktøysett Et problem kunden advarte gruppa mot før implementering, var at verktøysettet JENA kunne ha visse problemer med ytelsen. Gruppa opplevde problem med oppstartshastighet, hvor ca. 13 sekunder brukes på innlesing av en ontologi på ca 200 ord. Et annet verktøysett kan vurderes for senere implementeringer, spesielt hvis ontologistørrelsen er betraktelig større enn den brukt i dette prosjektet. Problemet bør løses hvis det er krav om at administratorer selv skal kunne redigere ontologier. Dersom ontologier i fremtiden vil være bygd opp som rene trestrukturer, er en mulighet å vurdere et annet lagringsformat enn OWL. 423

430 6.3. SØKEOPERATORER KAPITTEL 6. VIDERE ARBEID 6.3 Søkeoperatorer Prototypen er implementert basert på at ikke alle søketermer må eksistere i treffdokumenter (OR-operator). Noen brukere ønsker også AND-funksjonalitet (krav om at et ordpar eksisterer) og søk etter ordsekvenser. Både å legge til støtte for søk etter ordsekvenser, og søk etter ord med AND-operator, er mulig med mindre arkitekturmessige endringer. 6.4 Problemer med stemming På grunn av at bare stemmede former av ord lagres ordlisten, blir presentering av lignende ord, ved hjelp av Levenshtein-algoritmen ikke optimal. De stemmede formene kan fort resultere i ukorrekt norsk, og dette er et punkt som kan utbedres. 6.5 Ytelse og datalagring Innlasting av vokabular og dokumentlister skjer nå ved hjelp av Java Serialization. Dersom prototypen går inn i produksjonsmiljø med et stort antall ord, bør funksjonalitet rundt innlasting og lagring av ordlisten endres. 6.6 Tidsestimat for gjenværende arbeid Det er antatt at utbedringer av eksisterende problemer vil kreve i størrelsesorden 30 arbeidstimer for utbedring, for personer med god erfaring innenfor Java og JSP. Dette estimatet inkluderer ikke verifisering, testing og dokumentering. Å videreutvikle konseptet med ontologistøttet søk, er allikevel en prosess som vil kreve mange pilotprosjekter med prøving og feiling. 424

431 Vedlegg A Timerapportskjema Figur A.1: Timerapportskjema ved avslutning av prosjekt 425

432 426 VEDLEGG A. TIMERAPPORTSKJEMA

433 Tabeller 2.1 Estimerte og reelle milepæler i prosjektet

434 TABELLER TABELLER 428

435 Figurer 2.1 Timeforbuk i prosjektets faser Timeforbuk i prosjektets faser A.1 Timerapportskjema ved avslutning av prosjekt

436 FIGURER FIGURER 430

437 Del VIII Brukerveiledning 431

438

439 Innhold 1 Innledning Hensikt Omfang Struktur Installasjon Maskinvare og operativsystem Forberedelse Installering av Apache Tomcat Installasjon Konfigurering Settings.bat Config.ini Kjøring for første gang Søking Enkelt søk Avansert søk Søkeresultat Administrasjon Vedlikehold Statistikk

440 INNHOLD INNHOLD 434

441 Kapittel 1 Innledning Dette er brukerveiledningen for prototypen OntoSearch - En ontologistøttet, nettsidebasert søkemotor, utviklet av gruppe 17 i faget TDT4290 Kundestyrt Prosjekt ved NTNU, høsten Hensikt Hensikten med brukerveiledningen er å gi informasjon om hvordan prototypen skal installeres og settes opp i et nytt miljø, samt å gi en innføring i bruken av de forskjellige funksjonene og mulighetene den tilbyr. 1.2 Omfang Dokumentet tar for seg installasjon og bruk, og forklarer de forskjellige skjermbildene brukergrensesnittet tilbyr. 1.3 Struktur Dokumentet er delt inn i følgende kapitler: Kapittel 2 inneholder en installasjonsveiledning for hvordan man skal sette opp prototypen for drift, samt hvordan man kjører prototypen etter installasjon. Kapittel 3 inneholder veiledning i generelle søkefunksjoner i systemet. Kapittel 4 beskriver administrasjonsfunksjonene i systemet og forklarer statistisk informasjon som kan hentes ut fra administrasjonssiden. 435

442 1.3. STRUKTUR KAPITTEL 1. INNLEDNING 436

443 Kapittel 2 Installasjons- og oppstartsveiledning Dette kapitlet beskriver hvordan OntoSearch og tilhørende programmerer kan installeres på et Windows-basert system. Selv om OntoSearch er kompatibel med de fleste plattformer gjennom sin implementering i Java, har implementeringen og testingen bare tatt hensyn til Windows. På grunn av dels forskjellig oppførsel med katalogstrukturer, Java-versjoner og RMI-kommunikasjon, garaneteres det ikke at OntoSearch virker på noe annet enn Windows. 2.1 Krav til maskinvare og operativsystem For effektiv kjøring av prototypen anbefales det maskinvare basert på x86-arkitekturen (eller annen plattform med kompatibilitet i programvaregrensesnitt) med prosessorhastighet på minimum 500 MHz og 256 MB minne. Prototypen vil kunne kjøres på alle Windows-systemer med Java Runtime Environment installert 2.2 Forberedelse For kjøring av OntoSearch trenger man et kjøretidsmiljø med følgende programmer installert: Apache Jakarta Tomcat 5.0 eller nyere. Java Runtime Environment versjon eller nyere. I tillegg til programvaren, trengs også en selvstendig Windows-maskin med minst Windows 98. En bør ha administrator-tilgang til denne maskinen. Det er viktig å forstå at OntoSearch består av to komponenter. En JSP nettsidetjener 437

444 2.3. INSTALLERING AV APACHE TOMCAT KAPITTEL 2. INSTALLASJON benyttes som et grensesnitt mot sluttbrukere. Tjeneren mottar forespørsler, og kommuniserer deretter med hovedprogrammet til OntoSearch. Hovedprogrammet er en selvstendig Java-applikasjon som enten kjører på samme maskin eller på en annen maskin. 2.3 Installering av Apache Tomcat For å installere Apache Jakarta Tomcat, er det anbefalt at en følger installeringsveiledningen som følger med programmet. De store trekkene i installeringen presenteres allikevel her: Laste ned Tomcat fra Tomcat ligger også tilgjengelig på installasjons-cd-en i katalogen \tools\programs. Installere Tomcat. Det er anbefalt å installere Tomcat til en katalog som ikke inneholder mellomrom, f.eks. C:\Tomcat5. Hvis en installerer f.eks. til katalogen C:\Program files\tomcat5 kan dette gi problemer senere pga. programfeil i Tomcat og/eller Java. Redigere filen C:\Tomcat5\conf\tomcat-users.cfg og legg til ønskede brukere og passord Starte Tomcat5 med å bruke kommandolinjen NET START TOMCAT5 eller bruke Services - skjermen til Tomcat-installeringen. Etter at Tomcat er installert, vil den være tilgjengelig via Installering av Ontosearch Installering av OntoSearch gjøres på følgende måte. Kopier inn mappen ontosearch fra CD-en til katalogen C:\ontosearch (slik at filene blir tilgjengelig som for eksempel C:\ontosearch\start.bat) VIKTIG. Dersom du valgte en annen installeringskatalog enn C:\Tomcat5 for Tomcat, eller dersom du ønsker å benytte en annen webapplikasjon enn / (ROOT) for OntoSearch, så må du redigere start.bat for å ta hensyn til dette. ADVARSEL: Webapplikasjonen som blir benyttet av OntoSearch, blir overskrevet når du kjører start.bat. Derfor er det viktig at du ikke peker OntoSearch til en webapplikasjon som allerede brukes til andre formål! Kjør start.bat. Denne vil kopiere filer til nødvendige plasseringer i Tomcat, starte Tomcat på nytt, og starte selve OntoSearch-programmet. 438

445 KAPITTEL 2. INSTALLASJON 2.5. KONFIGURERING 2.5 Konfigurering For konfigurering av Apache Tomcat, se respektiv manual [1] Konfigurasjon av OntoSearch gjøres via to filer, config.ini og settings.bat. Filen settings.bat brukes for å sette kjøretidsinnstillinger, som for eksempel hvor Tomcat er lokalisert. Du må endre denne før du begynner å bruke programmet. Filen config.ini brukes for å sette innstillinger for selve OntoSearch-programmet Settings.bat I filen settings.bat er det 4 viktige innstillinger som må endres før bruk av programmet: ONTOSEARCH DIR Hovedkatalogen til OntoSearch. Hvis du kopierer mappen ontosearch over til rotkatalogen på C:\, så sett denne variabelen til å være lik C:\ontosearch. JAVA HOME Rotkatalogen til Java-kjøretidsmiljøet. Dette er avhengig av hvor du har installert JRE eller J2SE/J2EE. Katalogen avhenger mye av hvilken versjon av Java som brukes. Standardverdien her er C:\j2sdk1.4.2_06, men Java kan også på noen systemer være installert i f.eks. C:\programfiler\java\JRE. JAVA BIN Programnavnet som brukes for å kjøre Java-programmer. Du trenger vanligvis ikke å endre på denne. TOMCAT WEBAPP DIR Katalogen til web-applikasjonen som OntoSearch skal benyttes i. ADVARSEL: Innholdet i denne webapplikasjonen vil bli overskrevet Config.ini Filen config.ini bestemmer innstillingene til hvordan OntoSearch-programmet skal kjøre. Merk at når denne filen redigeres, må forover-skråstrek (/) brukes i filnavn isteden for bakover-skråstrek (\). Av de innstillingene som det i første omgang er relevant å endre på, kan dette nevnes: documents.directory Katalog hvor OntoSearch ser etter nye dokumenter. log.adminexcerpt Antall linjer av logger som skal skrives ut på administrasjons-siden. Loggingen er bare nødvendig for feilsøking, og denne verdien kan settes til 0 dersom en ikke ønsker logginformasjon på administrasjonssiden. 439

446 2.6. KJØRING FOR FØRSTE GANG KAPITTEL 2. INSTALLASJON log.maxsize Maksimum størrelse på logger før loggene blir rotert. Når denne størrelsen (i bytes) oppnås, starter OntoSearch på en ny loggfil, og sletter alle loggdata som er større enn log.maxsize*2 bytes. ontology.filename Navnet på en OWL Lite-fil som inneholder ontologien som skal brukes i OntoSearch. En eksempelfil er vedlagt programmet. server.registryhost Tjenernavnet til et RMI-register som OntoSearch-programmet skal binde seg opp mot. Hvis du lar denne verdien være tom, vil OntoSearch opprette sitt eget RMI-register som andre kan koble seg opp mot. server.registryident Navnet til OntoSearch-komponentet, slik det blir registrert på RMI-registeret. Det er vanligvis ikke nødvendig å endre på denne verdien, med mindre det ligger sikkerhetshensyn til grunn, eller hvis flere kjørende OntoSearch-programmer skal være tilgjengelig samtidig (f.eks. ved lastfordeling eller tjenesteredundans). server.registryport Porten som RMI-registeret skal benytte. Hvis server.registryhost er tom, angir denne verdien den porten det nye registeret skal opprettes på. Hvis server.registryhost er satt til en annen tjener, angir den hvilken port som registeret er bundet til på den andre tjeneren. 2.6 Kjøring for første gang Fra kommandolinjen, kjør start.bat fra katalogen C:\ontosearch\. Den første gangen OntoSearch startes, vil alle dokumenter indekseres på nytt. Dette tar ca. et halvt minutt på de fleste systemer med dokumentsamlingen som er tatt med. Før selve programmet starter, vil også en del filer kopieres fra programkatalogen til Onto- Search til Apache Tomcats webapplikasjon-mappe. Så snart meldingen Server started står i programvinduet til OntoSearch, er programmet klart til å ta imot forespørsler. Da kan en peke nettleseren til nettsidetjeneren, vanligvis via adressen for å få tilgang til systemet. 440

447 Kapittel 3 Søking OntoSearch er et søkeverktøy for søking i dokumentsamlinger, og dette avsnittet forklarer hvordan man bruker søkefunksjonen, samt gi en forklaring av det presenterte søkeresultatet. 3.1 Enkelt søk Det enkle søket er den første siden man kommer til ved å åpne systemet i en nettleser. Denne består av et søkefelt og en søkeknapp som vist i figur 3.1. Her tilbys den enkleste måten å bruke søkemotoren på. Ved å skrive inn ett eller flere ord man vil søke etter, skilt av mellomrom, og så trykke på knappen Søk, utføres søket. Det hentes da fram dokumenter fra dokumentsamlingen som inneholder et eller flere av de ordene man skrev inn. Forskjellige bøyningsformer av ordene som ble skrevet inn vil også bli søkt på. I tillegg til dette, finner systemet andre ord relatert til dissee ordene, og bruker også disse i søket. 441

448 3.2. AVANSERT SØK KAPITTEL 3. SØKING Figur 3.1: Enkelt søkegrensesnitt 3.2 Avansert søk Ved å velge det avanserte søkealternativet får man opp et utvidet skjermbilde med en rekke ord med tilhørende avkrysningsbokser som vist i figur 3.2. Ordene er noen av de viktigste nøkkelordene fra dokumentsamlingen som systemet utfører søk i. Denne opplistingen skal gi hjelp til å finne et ord som godt beskriver det man har lyst til å finne. Der det vises et lite plusstegn til venstre for ordet, betyr det at dette ordet er et ord med flere underord. Ved å trykke på krysset utvides skjermbildet til også å vise underordene. Ved å krysse av i en bestemt boks, legges det aktuelle ordet til i søket som blir utført når man trykker på Søk. For å ta med både ord og underord kan man navigere nedover i strukturen og merke av ordene som vist i figur 3.3. Det er viktig å legge merke til at de ordene man krysser av for, kommer i tillegg til de ordene som blir skrevet inn i tekstfeltet. 442

449 KAPITTEL 3. SØKING 3.2. AVANSERT SØK Figur 3.2: Avansert søkegrensesnitt 443

450 3.2. AVANSERT SØK KAPITTEL 3. SØKING Figur 3.3: Avansert søkegrensesnitt - avkryssede ord 444

451 KAPITTEL 3. SØKING 3.3. SØKERESULTAT 3.3 Søkeresultat Når søket har blitt utført, åpnes en ny side med søkeresultatet som vist i figur 3.4. Denne siden inneholder en liste over de dokumenter som er funnet i dokumentsamlingen, såkalte treff. Hvert treff består av tittelen på dokumentet og et kort utdrag av dokumentet der ordene som ble søkt på er spesielt merket. Under utdraget følger også en liste over andre nøkkelord som finnes i det aktuelle dokumentet. Ved å trykke på et av disse nøkkelordene blir det utført et nytt søk der nøkkelordet er lagt til i søkestrengen. Resultatene er sortert etter hvor godt de samsvarer med det søket som ble spesifisert. Under søkefeltet listes de ordene som ble benyttet i søket, både de som ble skrevet inn, og de ordene systemet automatisk utvidet søket med. Ordene som ble søkt på direkte er merket med grønt og fete typer, mens ord som søkemotoren automatisk utvidet med er merket med rødt og kursiv. Ved å trykke på et av disse ordene får man opp en boks med mulighet for å gjøre om ordet til et mer (eller mindre) presist ord. Dette er vist i figur 3.5. Dette gjøres ved å trykke på ønsket ord. Mellom søkefeltet og resultater vises også eventuelle feilmeldinger. 445

452 3.3. SØKERESULTAT KAPITTEL 3. SØKING Figur 3.4: Søkeresultatet 446

453 KAPITTEL 3. SØKING 3.3. SØKERESULTAT Figur 3.5: Søkeresultat med utvidet boks for å respesifisere søk 447