Ontologidrevet dokumentforvaltning

Transkript

1 Ontologidrevet dokumentforvaltning Prosjektrapport TDT4290 Kundestyrt prosjekt Institutt fra datateknikk og informasjonsvitenskap Fakultet for informasjonsteknologi, matematikk og elektroteknikk Norges teknisk-naturvitenskapelige universitet Gruppe 14 Espen Hansen Ole-Marius Moe-Helgesen Geir Storli Karl Hatteland Steinar Skjerven Håvard Stranden

2

3 Forord Dette er rapporten fra prosjektet Ontologidrevet dokumentforvaltning i faget TDT4290 Kundestyrt prosjekt, høsten Gruppen som har jobbet med prosjektet består av 4. års stud.techn. ved Institutt for Datateknikk og Informasjonsvitenskap (IDI) ved Norges Teknisk-Naturvitenskapelige Universitet (NTNU). Prosjektets kunde, Doctors in Business AS, ønsket et verktøy for visualisering av ontologier. Forstudiet gjennomgikk tilgjengelige teknikker og verktøy, og det ble etter utarbeidelse av kravspesifikasjon bestemt at gruppen skulle lage et bibliotek som visualiserer ontologier som grafer. Resultatet ble en førsteutgave av biblioteket som kan tas i bruk og videreutvikles av Doctors in Business. Gruppen vil rette en stor takk til veilederne sine for et godt samarbeid og de konstruktive tilbakemeldingene vi har fått. Vi vil også takke kundens representant, Terje Brasethvik, for et godt og lærerikt samarbeid. Til slutt vil vi takke familier, venner og kjærester for tålmodighet gjennom et tungt og stressende semester. Trondheim, 15. november Espen Hansen <espenha@stud.ntnu.no> Karl Hatteland <karl@hatteland.com> Ole-Marius Moe-Helgesen <moehelge@idi.ntnu.no> Steinar Skjerven <steinas@idi.ntnu.no> Geir Storli <geirst@stud.ntnu.no> Håvard Stranden <havarden@idi.ntnu.no>

4

5 Innhold Prosjekrapporten består av følgende dokument: Prosjektdirektiv - 57 sider Forstudie - 89 sider Kravspesifikasjon - 75 sider Konstruksjon - 41 sider Implementasjon - 42 sider Testdokument - 71 sider Evaluering - 28 sider Vedlegg A - Forkortelser Vedlegg B - Fornorskninger

6 Ontologidrevet dokumentforvaltning Prosjektdirektiv TDT4290 Kundestyrt prosjekt Institutt fra datateknikk og informasjonsvitenskap Fakultet for informasjonsteknologi, matematikk og elektroteknikk Norges teknisk-naturvitenskapelige universitet Gruppe 14 Espen Hansen Ole-Marius Moe-Helgesen Geir Storli Karl Hatteland Steinar Skjerven Håvard Stranden

7

8 Prosjektdirektiv Innhold 1 Prosjektmandat Prosjektnavn Produktnavn Prosjektsponsor Interessenter Bakgrunn Prosjektmål Effektmål Resultatmål Prosjektets omfang Rammebetingelser Økonomi Tid Prosjektplan Faser Planlegging Forstudium Kravspesifikasjon Konstruksjon Implementasjon Testing Avslutning Tidsplan

9 Prosjektdirektiv 3 Organisering Arbeidsoppgaver Prosjektleder Dokumentansvarlig Testansvarlig Kundekontakt Maler og Standarder Fasedokument Møteinnkalling Møtereferater Statusrapporter Tid, risiko, omfang, kostnad og kvalitet (TROKK) Katalogstruktur og filnavn Referering Regler for hvordan man skal skrive i et dokument Versjonskontroll 22 6 Prosjektoppfølging Prosjektmøter Internmøter Veiledermøter Kundemøter Intern timerapportering Statusrapport Risikohåndtering og TROKK

10 Prosjektdirektiv 7 Kvalitetssikring Kvalitetskrav i gruppa Møteinnkalling til internmøte Møtereferat Rutiner for å produsere kvalitet første gang Rutiner for godkjenning av fasedokument Kvalitetskrav til veileder Responstider Møteinnkalling til veiledermøte Møtereferat fra veiledermøte Kvalitetskrav til kunde Responstider Møteinnkalling til kundemøte Møtereferat fra kundemøte A Detaljert Prosjektplan 29 B Maler 33 B.1 Mal for møte B.2 Mal for møtereferat B.3 Mal for statusrapport B.4 Mal for risikovurdering C Tabell over interessenter 43 D Faseplan for forstudiet 44 D.1 Inndeling av dokumentet D.2 Delansvarlige

11 Prosjektdirektiv E Faseplan for kravspesifikasjonen 47 E.1 Inndeling av dokumentet E.2 Delansvar F Faseplan for konstruksjonen 49 F.1 Inndeling av dokumentet F.2 Delansvarlige G Faseplan for implementasjon 51 G.1 Inndeling av dokumentet G.2 Delansvarlige H Faseplan for testfasen 53 H.1 Delansvarlige H.2 Tidsplan I Faseplan for avslutning 55 I.1 Inndeling av dokumentet I.2 Delansvarlige Referanser 57 5

12 Prosjektdirektiv 1 Prosjektmandat Prosjektmandatet inneholder informasjon om prosjektet, bakgrunn for det, prosjektets mål og rammebetingelser. 1.1 Prosjektnavn Prosjektets navn er "Ontologidrevet dokumentforvaltning". 1.2 Produktnavn Prosjektet skal produsere et bibliotek 1 med navn ovibe - ontology Visualization in business embedder. 1.3 Prosjektsponsor Prosjektsponsor er Doctors in Business AS (DiB). 1.4 Interessenter Interessentene er beskrevet i vedlegg C. 1.5 Bakgrunn Doctors in Business AS ble stiftet i Firmaet har siden da utviklet en arbeidsbenk for tekstanalyse og en ontologi-basert omgivelse for forvaltning av dokumenter. Arbeidbenken brukes til å trekke ut ontologier og relasjoner mellom disse fra dokumenter, men mangler en måte å visualisere resultatene på. Dette prosjektet skal derfor utvikle en komponent for å visualisere ontologier. 1 I lengre tid av prosjektet var hensikten å utvikle en enkeltstående komponent i stedet for et bibliotek. I de første dokumentene av prosjektet vil derfor begrepet komponent benyttes. 6

13 Prosjektdirektiv 1.6 Prosjektmål Her beskrives prosjektets effektmål og resultatmål. Med effektmål menes effekten som skal oppnås av prosjektet; med andre ord det kunden ønsker å oppnå med prosjektet. Med resultatmål menes de leveransene prosjektet skal overlevere til kunden; resultatene som må oppfylles for å oppnå den ønskede effekten Effektmål Prosjektets effektmål: Å lage en ferdig prototyp av en komponent for visualisering av ontologier. Produsere en fullstendig dokumentasjon av komponenten. Denne skal gjør rede for komponentens virkemåte, grensesnitt og funksjonalitet. Øke kundens kunnskaper om visualisering av ontologier Resultatmål Prosjektets resultatmål er: Å lage en visuell komponent, skrevet i Java, som skal kunne parse en OWL fil - størrelsen på filen vil avgjøre hvor lang tid parsingen tar. Progresjonen til parsingen skal visualiseres. filtrere - brukeren skal kunne velge hvilke deler av ontologien han/hun vil fokusere på. lage en graf - komponenten skal kunne lage en graf av ontologien. visualisere grafen på under ett minutt. dokumentasjon av komponenten som forklarer hvordan den er oppbygd og de enkelte elementene i kildekoden. 7

14 Prosjektdirektiv 1.7 Prosjektets omfang Prosjektet skal analysere tilgjengelige verktøy for visualisering og avgjøre om noen av disse kan brukes eller videreutvikles til å bli anvendelige for komponenten som skal lages. Det skal også analyseres tilgjengelige visualiseringsmetodikker og avgjøre hvilken metodikk som er den mest egnede. Den valgte metoden for visualisering skal så implementeres som en komponent til kundens eksisterende arbeidsbenk. 1.8 Rammebetingelser Rammebetingelser for prosjektet: Programmeringsspråket som skal benyttes er Java Verktøyet som skal utvikles skal lese OWL (Web Ontology Language) Prosjektet kan bruke tilgjengelige biblioteker og verktøy Prosjektet er begrenset av lisenser på de biblioteker og verktøy det velger å benytte Komponenten skal ha et grensesnitt som kan brukes i kundens arbeidsbenk for ontologier Prosjektet har et begrenset antall arbeidstimer tilgjengelig Prosjektet skal benytte LaTeX som dokumentasjonsverktøy Alle dokumenter skal skrives på norsk, skriftspråk bokmål Prosjektet har en PC tilgjengelig hos IDI Det er nedlagt en utskriftsbegrensning på 500 sider per person 1.9 Økonomi 310 timer er tilgjengelig per prosjektdeltaker. Totalt blir dette 1860 timer. Hver prosjektdeltaker registrerer timeforbruk på ukentlig basis. 8

15 Prosjektdirektiv 1.10 Tid Denne seksjonen beskriver viktige tidsfrister for prosjektet. Prosjektet startet 24. august 2004, og skal avsluttes 18. november Aktivitet Frist Preleveranse Avslutning og overlevering Tabell 1: Viktige tidsfrister 9

16 Prosjektdirektiv 2 Prosjektplan Dette kapittelet inneholder de ulike fasene gruppen ønsker å dele prosjektet opp i, tidsplanen for gjennomføringen av disse (se også vedlegg A) og en kort presentasjon av hver. 2.1 Faser Gruppen har valgt følgende oppdeling av prosjektet: 1. Planlegging 2. Forstudium 3. Kravspesifikasjon 4. Konstruksjon 5. Implementasjon 6. Testing 7. Avslutning For hver fase er det også én eller flere ansvarlige. Den eller disse har hovedansvaret for den avsluttende sammensetningen av dokumentet og at alle krav til fasen er oppfylt. Den ansvarlige skal også ligge i forkant av resten av gruppen når tid for oppstart av den aktuelle fasen nærmer seg Planlegging Ansvarlig: Espen Planleggingsfasen er den delen av prosjektet som går på utarbeidelse av første iterasjon av prosjektdirektivet. Opprinnelige tidsplaner og milepæler utarbeides også i denne fasen. I tabell 2 er det en oversikt over aktiviteter og ansvarlige for planleggingsfasen. 10

17 Prosjektdirektiv Aktivitet Dato Ansvarlig Prosjektmandat Karl Prosjektplan Ole-Marius Organisering Håvard Maler og Standarder Steinar Versjonskontroll Håvard Prosjektoppfølging Karl Kvalitetssikring Karl Risikoanalyse Espen Korrektur Håvard, Ole-Marius, Geir Tabell 2: Aktivitetsplan for planleggingsfase Forstudium Ansvarlig: Håvard Forstudiet har som mål å legge grunnlaget for å kunne ta videre beslutninger om fremgangen i prosjektet. Forstudiet skal sette opp forretningsmessige krav fra kunden, evaluere ulike løsninger og til slutt gjøre et valg av løsning for videre utvikling. Faseplan for forstudiet finnes i vedlegg D Kravspesifikasjon Ansvarlig: Karl I denne fasen skal det utarbeides detaljerte funksjonelle og ikke-funksjonelle krav til løsningen som ble valg i forstudiet. Disse skal senere fungere som både en kontrakt mellom kunde og utviklere og et utgangspunkt for konstruksjon, implementasjon og testing. Dersom gruppen finner det hensiktsmessig å legge opp til et iterativt løp for den videre utviklingen, skal denne beslutningen tas i kravspesifikasjonsfasen. Faseplan for kravspesifikasjonsfasen finnes i vedlegg E. 11

18 Prosjektdirektiv Konstruksjon Ansvarlig: Steinar Konstruksjonsfasen skal trekke på konklusjonene fra kravspesifikasjonen og legge grunnlaget for senere implementasjon. Etter endt konstruksjonsfase skal gruppen presentere Overordnet utviklingsstrategi. Herunder objektorienterte patterns som skal benyttes på systemnivå. Definisjon av ulike moduler i systemet og grensesnittene som tilbys av disse. Beskrivelse av klasser som inngår i de ulike modulene og grensesnitt mellom disse. Sekvensdiagrammer for viktige funksjoner. Her skal kommunikasjon mellom moduler, klasser og eksterne bibliotek komme klart frem. Pseudokode av deler av systemet, Use Case-diagrammer og andre virkemidler kan også benyttes dersom dette finnes hensiktsmessig. Dersom gruppen i kravspesifikasjonsfasen kom frem til å benytte en iterativ utviklingsmodell kan det bli flere konstruksjonsfaser også. Faseplan for konstruksjonsfasen finnes i vedlegg F Implementasjon Ansvarlig: Ole-Marius Implementasjonsfasen består av to hoveddeler: Programmering av systemet gruppen konstruerte i forrige fase. Dokumentering av både et eventuelt API gruppen har programmert og brukerdokumentasjon av de delene som benyttes av sluttbruker. Implementasjonen vil også bli delt i flere deler dersom gruppen velger en iterativ utviklingsmodell Faseplan for implementasjonsfasen finnes i vedlegg G. 12

19 Prosjektdirektiv Testing Ansvarlig: Geir I motsetning til de tidligere fasene vil testingen gå over hele utviklingsperioden. Gruppen har valgt å skille dette ut som en egen fase for å få en strømlinjeforming av testingen. De ulike fasene vil bli som følger: Studie av testmuligheter. Dette arbeidet vil bli gjort i planleggingsfasen av prosjektet. Målet her er å skaffe seg en oversikt over tilgjengelige metodikker for testing og gjøre en evaluering av disse. Utvikling av testplan. Denne delen av testfasen vil bli gjort i begynnelsen av kravspesifikasjonen. Målet med denne oppgaven er å spesifisere hvilke tester som ønskes og når disse skal utføres. Det forventes at deler av denne fasen vil bli utført under kravspesifikasjonen. Utvikling av tester. For hel- eller halvautomatiske tester som krever programmering, skal dette gjøres etter endt konstruksjon. Modul- og enhetstester skal fortrinnsvis ferdigstilles før modulene og enhetene som skal testes. Kjøring av tester. Tester av systemet som en helhet skal gjøres mot slutten av implementasjonsfasen. Faseplan for testfasen finnes i vedlegg H Avslutning Ansvarlig: Espen og Ole-Marius Avslutningsfasen dreier seg om to hovedmomenter: Evaluering av prosjektet og ferdigstillelse av siste leveranse til tirsdag 16. november. Presentasjon og demonstrasjon. 18. november skal prosjektgruppen presentere sine resultater. Dette krever naturlig nok en forberedelse. Faseplan for avslutningsfasen finnes i vedlegg I. 13

20 Prosjektdirektiv 2.2 Tidsplan Da kontakten vår hos kunde er utilgjengelig i perioden 11. til 26. september har gruppen en ekstra deadline som ikke kan flyttes. Da det ønsker å få ferdig forstudiet i midten av september vil gruppen levere et tidlig utkast til forstudie den 10. september. Milepælene våre er som vist i Tabell 3. Mer detaljerte Gantt-diagram, både opprinnelige og nåværende, og opprinnelig timesoverslag finnes i vedlegg A. Aktivitet Dato Forstudie - Førsteutkast Forstudie - Ferdigstillelse Kravspesifikasjon Konstruksjon Preleveranse Implementasjon Rapport ferdig Presentasjon Tabell 3: Milepælsplan 14

21 Prosjektdirektiv 3 Organisering Prosjektgruppen har 6 medlemmer med stillinger som beskrevet i tabellen over interessenter i vedlegg C. 3.1 Arbeidsoppgaver De ulike stillingene i prosjektgruppen har følgende arbeidsoppgaver: Prosjektleder Prosjektlederen har følgende arbeidsoppgaver: Hovedansvar for prosjektet Sende møteinnkallinger til alle møter unntatt kundemøtene Lede alle møter unntatt kundemøtene Ta seg av administrative oppgaver Ansvarlig for statusrapporter Holde oversikt over timeforbruk Dokumentansvarlig Dokumentansvarlig har følgende arbeidsoppgaver: Holde oversikt over og orden i alle dokumenter Ha kontroll på at dokumenter holder fastlagt standard Testansvarlig Testansvarlig har følgende arbeidsoppgaver: Ansvar for testplaner og tester 15

22 Prosjektdirektiv Kvalitetssikre tester Ansvar for gjennomføring av tester Kundekontakt Kundekontakten har følgende arbeidsoppgaver: Sende møteinnkallinger til kundemøter Lede kundemøter Være mellomledd mellom prosjektgruppen og kunden 16

23 Prosjektdirektiv 4 Maler og Standarder Her beskrives alle malene som skal brukes i prosjektet, og alle standarder som skal følges. 4.1 Fasedokument Fasedokumentene følger formatet til prosjektdirektivet. 4.2 Møteinnkalling Denne malen fins i vedlegg B, og skal brukes til alle møteinnkallinger. 4.3 Møtereferater Denne malen fins i vedlegg B, og skal brukes til alle møtereferater. 4.4 Statusrapporter Denne malen fins i vedlegg B, og skal brukes til alle statusrapporter. 4.5 Tid, risiko, omfang, kostnad og kvalitet (TROKK) Denne malen fins i vedlegg B, og skal brukes til alle risikovurderinger. 4.6 Katalogstruktur og filnavn Katalogstrukturen og navnekonvensjonen for CVS er beskrevet under (uppercase betyr at noe skal fylles inn). I figur 1 finnes en oversikt over katalogstrukturen som er brukt. YYYY betyr år, MM betyr måned (2-sifret), DD betyr dag (2-sifret), og WW betyr uke (2-sifret). Der ingen navnekonvensjon for filer er spesifisert, er navnene valgfrie. Overordnet kan man si at navnene kun bør inneholde internasjonale tegn, og at de skrives med kun små bokstaver så langt det er mulig. 17

24 Prosjektdirektiv Det er også lagd en modul project som inneholder både docs- og src-katalogene. Fasedokumenter skal ligge i en underkatalog av katalogen phases. Katalogen phases har underkataloger som representerer de ulike fasene i prosjektet. Møteinnkallinger legges i meetings/notifications. Filnavnene skal være på formen TYPE_YYYYMMDD.tex, for eksempel veiledermote_ tex. Møtereferater legges i meetings/minutes. Filnavnene skal være på formen TYPE_referat_YYYYMMDD.tex, for eksempel kundemote_referat_ tex. Statusrapporter legges i status. Filnavnene her skal være på formen YYYY-WW.tex, for eksempel tex. Alle maler legges i templates. Her skal navnene være på formen TYPE.tex, for eksempel moteinnkalling.tex. All kildekode legges i src-katalogen. Katalogen gen inneholder kildekode som ble generert fra UML-klassediagrammer, og som senere utvikles til å være kildekodetreet til komponenten. Katalogen lib inneholder alle eksterne bibliotek som brukes, mens katalogene pretesting og test inneholder henholdsvis tester som ble gjort før implementasjonen startet, og enhetstester for implementasjonen. 18

25 Prosjektdirektiv 4.7 Referering Navnekonvensjonen ved referering i forbindelse med tabeller, figurer og kapitler er: label{tab:tabellnavn} label{fig:figurnavn} label{sec:kapitellnavn} Navnene skal skrives sammenhengende, og med små bookstaver. Eks. dagenssituasjon. Refereringen skal legges på slutten av setningen, før punktum. Ved flere referanser i en setning skal de skilles med komma. 4.8 Regler for hvordan man skal skrive i et dokument Disse konvensjonene har gruppen kommet fram til for å skrive i et dokument. Forkortelser: Første gangen en forkortelse brukes skrives hele forkortelsen ut med forkortelsen i parantes. Web Ontology Language (OWL). Forkortelser skrives med store bokstaver. Egennavn: Egennavn skrives med store bokstaver. Fotnoter: Ikke bruk paranteser for å forklare ting. Man skriver heller en fotnote eller omformulerer setningen. Skåstrek: Skråstrek brukes helst ikke. Subjekt: Alle setninger skal inneholde subjekt. Orddeling: Bindestrek mellom ord som OWL-ontologi. Personlige promomen: Personlige pronomen brukes ikke i formelle dokument. Vi skrives om til gruppen og du skrives om til man. Oppdragsgiver: Når gruppen referer til oppdragsgiver bruker gruppen kunde eller DiB. 19

26 Prosjektdirektiv Fornorsking: Engelske ord skal om mulig fornorskes. For eksempel input til inndata. Tall: Tall opp til tolv skrives med bokstaver. Norske forkortelser: Norske forkortelser som f.eks. skal skrives ut. Overskrifter: Overskrifter skal ikke være et spørsmål eller en forkortelse. Kapittel og avsnitt: Bruk ordet kapittel om øverste nivå, og avsnitt om nivå under det. 20

27 Prosjektdirektiv /home/groups/kpro14/cvs docs/ phases/ plans/ prestudy/ req_spec/ construction/ implementation/ testing/ evaluation/ presentation/ meetings/ notifications/ TYPE_YYYYMMDD.tex minutes/ TYPE_referat_YYYYMMDD.tex status/ YYYY-WW.tex templates/ TYPE.tex src/ gen/ ovibe/ event/ filter/ graph/ gui/ io/ lib/ pretesting/ test/ Figur 1: Katalogstruktur 21

28 Prosjektdirektiv 5 Versjonskontroll Prosjektet benytter CVS for versjonskontroll av både dokumenter og kildekode. Området for lagring er tilgjengelig på /home/groups/kpro14 (Unix) eller \\sambastud.stud.ntnu.no\groups\kpro14 (Windows) På dette området ligger det en såkalt CVS repository. Denne ligger i katalogen cvs under kpro14.for å sjekke ut filer fra denne katalogen, skriver man (forutsatt at cvs-klienten er installert): cvs -d /home/groups/kpro14/cvs co project (Unix) eller cvs -d Z:\cvs co project (Windows, Z: er selvfølgelig et eksempel) Disse kommandoene vil lage en katalog project i nåværende katalog. Der ligger hele katalogstrukturen og alle filer som tilhører prosjektet. Alle medlemmer av gruppen har skrivetilgang til området. For mer utfyllende informasjon om bruk av cvs, nedlasting av cvs-klient og lignende, se hjemmesiden til CVS [2]. For informasjon om katalogstruktur og navnekonvensjoner, se kapittel 4. 22

29 Prosjektdirektiv 6 Prosjektoppfølging For å sikre god produktkvalitet er det viktig å ha gode rutiner for prosjektoppfølging underveis. Dette kapittelet omhandler hvordan prosjektet følges opp internt. Her finnes faste rutiner for møtevirksomhet og rapportering som skal følges. 6.1 Prosjektmøter Prosjektmøtene kan deles opp i tre kategorier: Internmøter Sted: R57 i realfagsbygget Tid: 12:15 til 14:00 hver mandag Hensikten med møtet er å gjøre opp status for prosjektet, samordne aktiviteter, samt planlegge og fordele arbeidsoppgaver. Prosjektleder har ansvaret for å lede dette møtet Veiledermøter Sted: R53 i realfagsbygget Tid: 08:15 til 09:00 hver onsdag I dette møtet vil prosjektgruppen få tilbakemedling på utført arbeid i forrige periode. I tillegg vil man kunne få oppklaring av problemer man eventuelt har. Prosjektleder har ansvaret for å lede dette møtet Kundemøter Kundemøter vil bli holdt etter behov. Dette møtet vil brukes til å klargjøre kundens krav og ønsker, og i tillegg vil gruppen presentere forslag og løsninger som kunden kan gi tilbakemelding på. Kundekontakt har ansvaret for å lede dette møtet. 23

30 Prosjektdirektiv 6.2 Intern timerapportering Prosjektleder har satt opp et webbasert system for timeregistrering på følgende adresse: Hvert gruppemedlem rapporterer i utgangspunktet antall timer fortløpende gjennom uka, men alle timer må være rapportert innen på søndag. Prosjektleder fører deretter alle timene inn i et eget timerapporteringsskjema. 6.3 Statusrapport Hver uke skal status for prosjektet rapporteres skriftlig til veilederne. På internmøtene hver mandag vil man gjøre opp status for de oppgavene prosjektgruppen jobbet med i forrige uke. Dette legger grunnlaget for statusrapporten prosjektleder skal utarbeide. Rapporten sendes deretter til veilederne sammen med andre dokumenter senest hver tirsdag. 6.4 Risikohåndtering og TROKK TROKK står for Tid, Risiko, Omfang, Kostnad og Kvalitet, og er en risikohåndtering som brukes for å holde oversikten over viktige sider ved prosjektarbeidet. Dette skal inngå i prosjektets statusrapport til veilederne. Viktige vurderinger i forbindelse med TROKK er om prosjektet holder seg innenfor tidsrammene, samt hvilke risikomomenter som finnes i prosjektet. Videre vurderes omfanget til prosjektet ved å ta hensyn til stabilitet og endringer, og kostnad i form av timer estimeres. I tillegg vurderes kvaliteten til produktet for å se om kvaliteten må reduseres. Se vedlegg B for risikotabell. 24

31 Prosjektdirektiv 7 Kvalitetssikring Under følger retningslinjer som skal benyttes for å sikre kvaliteten på produktet som skal produseres. 7.1 Kvalitetskrav i gruppa I følgende del finnes retningslinjer som prosjektgruppa har blitt enige om Møteinnkalling til internmøte Innkalling til interne møter i gruppa skal følge følgende rutine: Prosjektleder sender møteinnkalling til gruppemedlemmene senest dagen før møtet. For mandagsmøter er søndag akseptabel dag å sende innkalling. Det forventes at gruppemedlemmene skal lese søndag etter Mal for møteplan - internmøte (vedlegg B) skal brukes Møtereferat Referat fra interne møter skal gjøres i henhold til følgende rutine: Møtereferat sendes til gruppemedlemmene innen dagen etter møtet. Møtereferatet godkjennes hvis ingen sender innvendinger innen samme dag. Mal for møtereferat (vedlegg B) skal brukes Rutiner for å produsere kvalitet første gang Kvalitetssikring er tidkrevende, og det er derfor ønskelig at gruppen har færrest mulig runder mer korrektur og feilretting på produserte dokumenter og kildekode. For å ha større mulighet for å lage produkter av akseptabel kvalitet uten gjentatt retting og korrektur vil gruppa gjøre følgende: 25

32 Prosjektdirektiv Fredagene brukes til gruppearbeid på datasal i 5. etasje på P15 bygget. Alle skal sørge for at de følger malstandarden på alle dokumenter som lages. Dokumenter skal legges ut for godkjenning av gruppa før de blir behandlet videre Rutiner for godkjenning av fasedokument Alle fasedokumenter skal godkjennes på veiledermøtet. Rutinene for denne godkjenningen er som følger: Fasedokumentet skal være ferdig til første internmøte etter avsluttet fase. Faseansvarlig skal samle dokumenter til et dokument. Alle gruppemedlemmene skal lese igjennom dokumentet og gjøre notater. Gjennomgang av dokumentet gjøres på internmøtet, der det godkjennes av gruppemedlemmene. Veileder kommer med tilbakemelding på førstkommende veiledermøte. Dersom det ikke blir godkjent, må faseansvarlig sørge for at manglene i dokumentet blir rettet opp. 7.2 Kvalitetskrav til veileder I følgende del finnes retningslinjer som prosjektgruppa og veilederne har blitt enige om Responstider Følgende responstider har blitt avtalt med veilederne: Svare på spørsmål: 24 timer Skaffe til veie avtalte dokument: 24 timer 26

33 Prosjektdirektiv Møteinnkalling til veiledermøte Innkalling til veiledermøte skal gjøres i henhold til følgende rutine: Prosjektleder sender møteinnkalling til hovedveileder, hjelpeveileder og gruppemedlemmene senest dagen før møtet. Alle relevante dokumenter pakkes i en zip-fil og legges ved møteinnkallelsen. Mal for møteplan - veiledermøte (vedlegg B) skal brukes Møtereferat fra veiledermøte Referat fra veiledermøte skal gjøres i henhold til følgende rutine: Møtereferat fra veiledermøte legges ved møteinnkallingen til det neste veiledermøtet. Mal for møtereferat (vedlegg B) skal brukes. 7.3 Kvalitetskrav til kunde I følgende del finnes retningslinjer som prosjektgruppa og kunden har blitt enige om Responstider Følgende responstider har blitt avtalt med kunden: Godkjenning av referat fra kundemøte: 24 timer Tilbakemelding på fasedokument: 48 timer Godkjenning av fasedokument: 48 timer Svare på spørsmål: 24 timer Skaffe til veie avtalte dokumenter: 24 timer 27

34 Prosjektdirektiv Møteinnkalling til kundemøte Rutine for innkalling til kundemøte er som følger: Kundekontakt avtaler møtetidspunkt med kunden ved å sette opp en liste over alternative tidspunkt. Kunde bekrefter ett av tidspunktene i løpet av arbeidsdagen. Møteinnkalling sendes til kunde, hjelpeveileder og gruppemedlemmene senest dagen før møtet. Relevante dokumenter for møtet legges ved møteinnkallelsen. Mal for møteplan - kundemøte (vedlegg B) skal brukes Møtereferat fra kundemøte Rutine for utsending av møtereferat er som følger: Kundekontakt sender møtereferat til kunde senest dagen etter møtet, etter at prosjektgruppen har godkjent referatet. Mal for møtereferat (vedlegg B) skal brukes. 28

35 Prosjektdirektiv A Detaljert Prosjektplan Dette vedlegget inneholder mer detaljerte data for prosjektplanleggingen. I tabell 4 finnes en oversikt over den opprinnelige timesestimeringen. Figur 2 viser fremdriftsplanen som ble satt opp på samme tid, mens figur 3 viser fremdriftsplanen slik den er nå. Begge fremdriftsplanene er skjermutskrifter fra Microsoft Project. I evalueringen av prosjektet finnes detaljerte tall for faktisk tidsbruk og en analyse av disse [1]. I figur 3 ligger det en fase nederst med tittel Ikke utført. Dette er planlagte oppgaver som gruppen valgte å ikke gjennomføre. Oppgavene dette dreier seg om er konstruksjon og implementasjon av inkrement 2 som definert i kravspesifikasjonen. Underveis i prosjektet var dette planlagt gjennomført mellom 1. og 10. november. 29

36 Prosjektdirektiv Dager Timer Personer (snitt) Totalt timer Prosent Norm Prosjektledelse % 10% Forelesninger % 10% Planlegging % 7% Førsteutkast % Ferdigstillelse % Forstudie % 15% Planlegging % Utarbeidelse av krav % Kravspesifikasjon % 20% Konstruksjon % 15% Programmering % Dokumentasjon % Implementasjon % 13% Utvikle teststrategi % Utvikle testplan % Uvikle tester % Kjøre tester % Testing % Evaluering % 5% Presentasjon og Demo % 5% Avslutning % Totalt 1860 Totalt disponibelt 1860 Timer / Dagsverk 4.8 Tabell 4: Estimert timebruk 30

37 Prosjektdirektiv Figur 2: Opprinnelig Fremdriftsplan 31

38 Prosjektdirektiv Figur 3: Fremdrift 32

39 Prosjektdirektiv B Maler Dette vedlegget inneholder de forskjellige malene som skal brukes i prosjektet. B.1 Mal for møte Møteplan Møtetype Sted: Sted Tid: Tid Dato: Dato Agenda 1. sak 1 2. sak 2 3. sak 3 4. osv. 5. Eventuelt 33

40 Prosjektdirektiv B.2 Mal for møtereferat Møtereferat Møtetype Sted: Sted Tid: Tid Dato: Dato Tilstede: Tilstede Fraværende: Fraværende Referent: Referent Agenda 1. punkt1 punkt2 2. punkt1 punkt2 3. punkt1 punkt2 Møtet hevet ca. kl Tid 34

41 Prosjektdirektiv B.3 Mal for statusrapport 35

42 NTNU Norges teknisk-naturvitenskapelige universitet TDT4290 Kundestyrt prosjekt Gruppe 14 Statusrapport Fra: Til: Oppsummering 2 Utført arbeid i perioden 2.1 Dokumenter - status på dokumentene som skal utarbeides 2.2 Møter 2.3 Aktiviteter 2.4 Annet 3 TROKK 3.1 Tid 3.2 Omfang 3.3 Kvalitet 3.4 Endringer 4 Problemer 1

43 NTNU Norges teknisk-naturvitenskapelige universitet TDT4290 Kundestyrt prosjekt Gruppe 14 5 Planlagt arbeid for neste periode 5.1 Møter 5.2 Aktiviteter 5.3 Annet Vedlegg: 1. Vedlegg1 2. Vedlegg2 2

44 Prosjektdirektiv B.4 Mal for risikovurdering Tabell 5 til 8 viser risikotabellen for prosjektet. 38

45 Prosjektdirektiv Nr Aktivitet Risikofaktor Konsekvens Sanns. Strategi og tiltak Tidsfrist Ansvar. Hvilke av prosjektets aktiviteter påvirkes Beskrivende navn på risikofaktoren 1. Alle faser Konflikter i gruppen Start med H, M eller L før konsekvensen beskrives med ord 2. Alle faser Sykdom M. Et eller flere medlemmer i gruppen deltar ikke i arbeidet over en periode 3. Alle faser Dårlig kommunikasjon mellom kunde og gruppen H,M,L Angi valgt stragtegi: unngå, overføre, dempe og aksepter. Beskriv deretter tiltaket H. Lav moral. L Unngå. Teambuilding. Ta opp konflikten i gruppa. H. Misforståelser. Kravspesifikasjon reflekterer ikke det kunden ønsker. Prototype som ikke er i henhold til kundens ønsker. M Aksepter. Drikk tran. Stay fresh. L Dempe. Arrangere møter. Klare retningslinjer for kundekontakten i gruppen. Ta opp problemet med kunden Sett en entydig tidsfrist Gi en person ansvaret N/A Prosjektleder N/A Alle N/A Kundekontakt Tabell 5: Risikotabell del 1 39

46 Prosjektdirektiv 4. Alle faser Feil timefordeling til de forskjellige fasene. 5. Alle faser Malene følges ikke 6. Implementasjons-fasen Manglende kompetanse 7. Implementasjons-fasen Problem med software 8. Implementasjons-fasen Kravspek må endres H. For mye/lite tid til en fase M Dempe. Reallokering. Gi gass. H. Forskjellige dokumentformat. Masse ekstraarbeid når sluttrapporten skal slås sammen. M. Fasen tar lengre tid. Dårlige løsninger. M. Implementasjonen stopper opp. H. Mye tid går tapt. L Unngå. Alle må forstå fordelene med å følge malene. M Dempe. Skaffe seg nødvendig kompetanse. Bruk medstudenter og veiledere. L Unngå. Grundig forstudie. Teste all software. L Unngå. Være grundige i forstudiet og kravspesifikasjonen. God kommunikasjon med kunde. Mange iterasjoner i kravspesifikasjonen. Tabell 6: Risikotabell del 2 N/A Prosjektleder N/A Dokumentansvarlig N/A Ole-Marius (faseansvarlig) N/A Alle N/A Alle 40

47 Prosjektdirektiv 9. Alle Responstider (eksterne/interne) blir ikke overholdt 10. Presentasjonsfasesentasjon Utstyr til preker fun- ikke 11. Alle Data mistet/slettet 12. Prosjektledelse Timeføring ikke gjort skikkelig 13. Alle Veilederene blir ikke godt nok brukt 14. Alle Sosiale aktiviteter M. Usikkerhet. Forsinkelser. L Unngå. Alle SKAL holde tidene. Ta opp problemet med skyldige. H. Forsinket presentasjon. L Unngå. Teste utstyr før presentasjon. H. Må gjøre ting om igjen. L. Timeoppfølgingen blir ikke reell M. En stor ressurs blir oversett L. Redusert innsats L Unngå. Sørge for god katalogstruktur og versjonskontroll. Kontakt idi/drift for gjenoppretting. H Unngå. Sørge for å ha gode rutiner H Unngå. Ta opp saker på veiledermøte. Bruk tid på å planlegge veiledermøte. H Dempe. Prøve å tilpasse slik at aktiviteter ikke går ut over innsats Tabell 7: Risikotabell del 3 N/A Prosjektleder N/A Alle N/A Alle N/A Alle N/A Alle N/A Alle 41

48 Prosjektdirektiv 15. Alle Dårlig kvalitetssikring 16. Alle Stor faglig belastning utenom KPRO M Dempe. Alle leser alt. Nøye korrekturlesning. H. Ekstraarbeid. Redusert karakter. H. H Aksepter. Planlegg med hensyn på midtsemestereksamen og store tellende øvinger. De øvrige gruppemedlemmene må være forberedt på å jobbe ekstra. Tabell 8: Risikotabell del 4 N/A Alle N/A Alle 42

49 Prosjektdirektiv C Tabell over interessenter Tabell 9 viser interessentene for prosjektet Navn Telefon Rolle Doctors in Business AS - - Målgruppe Sensor - - Målgruppe Terje Brasethvik brase@idi.ntnu.no Kunderepresentant Ole-Marius Moe-Helgesen moehelge@stud.ntnu.no Prosjektleder/Eier Steinar Skjerven steinas@stud.ntnu.no Dokumentansvarlig/Eier Geir Storli geirst@stud.ntnu.no Testansvarlig/Eier Håvard Stranden havarden@stud.ntnu.no Kundekontakt/Eier Espen Hansen espenha@stud.ntnu.no Prosjektmedarbeider/Eier Karl Hatteland hattelan@stud.ntnu.no Prosjektmedarbeider/Eier Jon Espen Ingvaldsen jonespi@idi.ntnu.no Hovedveileder Olaug K. N. Østhus olaugkyo@stud.ntnu.no Hjelpeveileder Tabell 9: Interessenter 43

50 Prosjektdirektiv D Faseplan for forstudiet Gruppen har valgt et relativt omfattende forstudium. Begrunnelsen for dette er at både kunde og prosjektgruppe mangler kunnskaper i sentrale deler av prosjektet. D.1 Inndeling av dokumentet Første del av dokumentet skal dekke situasjonen hos kunden, krav fra kunden og evalueringskriterier for de senere delene. Disse kapitlene er: Innledning: Innledningen skal beskrive formålet med dokumentet og gi en oversikt over hva det inneholder. Dagens situasjon: Kapittelet skal gi en oversikt over hva kunden har av relevante systemer i dag, og definere og forklare viktige begreper. Ønsket situasjon: Kapittelet skal gi en analyse av den ønskede situasjonen hos kunden og legge grunnlaget for det videre forstudiet. Forretningsmessige krav: Kapittelet skal definere alle forretningsmessige krav kunden har til det ferdige produktet gruppen skal produsere. Evalueringskriterer: Kapittelet skal, med bakgrunn i de forretningsmessige kravene, gi en vektet oversikt over kriteriene som legges til grunn for resten av forstudiet. Andre del av dokumentet skal inneholde en analyse i samsvar med det gruppen kom frem til i kapittelet om ønsket situasjon og gjennomføres med evalueringer med basis i evalueringskriteriene som har blitt fastsatt. Gruppen kom frem til følgende inndeling. Tolker for OWL: Kapittelet skal vurdere biblioteker som kan tolke OWL-filer og gjøre dataene fra disse tilgjengelige for videre behandling i en grafstruktur og avslutningsvis anbefale ett eller flere bibliotek for videre bruk. 44

51 Prosjektdirektiv Filtrering: Kapittelet skal se på begreper og metoder for filtrering av grafer og anbefale filtre for implementasjon. Graflayout: Kapittelet skal se på algoritmer for grafutlegging og tilgjengelige verktøy og bibliotek for dette. Avslutningsvis skal kapittelet ha en anbefaling for hva som skal benyttes videre. Java og grafikk: Kapittelet skal se på bibliotek og verktøy for utvikling av brukergrensesnitt i Java. Avslutningsvis skal ett eller flere bibliotek og verktøy anbefales for videre bruk. Eksisterende Visualiseringsverktøy: Kapittelet skal se på produkter som er på markedet i dag og komme med anbefalinger av teknikker som kan benyttes i det endelige produktet. Valg av løsning: Kapittelet skal benytte alle konklusjoner fra tidligere kapitler til å komme med en komplett løsning for kundens ønsker. D.2 Delansvarlige Inndeling av ansvar for de ulike delene er som følger: Innledning - Ole-Marius Dagens situasjon - Geir og Espen Ønsket situasjon - Steinar Forretningsmessige Krav - Håvard Evalueringskriterer - Karl Tolker for OWL - Geir Filtrering - Steinar Graflayout - Håvard Java og grafikk - Ole-Marius 45

52 Prosjektdirektiv Eksisterende visualiseringsverktøy - Karl Valg av løsning - Ole-Marius 46

53 Prosjektdirektiv E Faseplan for kravspesifikasjonen Dette kapittelet inneholder en plan for kravspesifikasjonen og de ulike punktene som skal være med i den, samt tidsplanen for gjennomføringen av disse. En kort presentasjon av hvert punkt finnes i dokumentet IEEE Std E.1 Inndeling av dokumentet Strukturen for denne fasen skal være slik: Innledning: 1. Introduksjon 2. Formål 3. Omfang 4. Definisjoner 5. Oversikt Overordnet beskrivelse: 1. Produktperspektiv 2. Produktfunskjon 3. Brukerkarakterestikk 4. Restriksjoner 5. Antagelser og avhengigheter Kuttet da det ikke ble funnet noe til dette punktet Funksjonelle krav: Dette avsnittet skal inneholde alle de funksjonelle kravene som gruppen kommer frem til. Use Case: Dette avsnittet skal inneholde tekstlige use cases, og grafiske om det er hensiktsmessig, for å dekke viktige krav fra forrige punkt. Det skal også utføres use case-estimering i dette avsnittet. 2 Dokumentet er tilgjengelig fra IEEEs websider på 47

54 Prosjektdirektiv Ikke-funksjonelle krav: Dette avsnittet skal inneholde alle ikke-funksjonelle krav. Konstruksjon og implementasjon: Da gruppen i løpet av konstruksjonsfasen, i samarbeid med kunden, har tatt en beslutning om å benytte en iterativ utviklingsprosess, skal dette avsnittet inneholde en inndeling av de funksjonelle og ikke-funksjonelle kravene i inkrementer. Dokumentet vil bli utviklet i to faser, der den første inneholder punktene: Overodnet beskrivelse. Funksjonelle krav. Ikke-funksjonelle krav. Den andre fasen inneholder: Innledning. Testkrav til testdokumentet. E.2 Delansvar Gruppen ble enige om å fordele slik at arbeidsmengden ble mest mulig lik for alle. Punktene finnes i IEEE dokumentet på fagets hjemmeside, og utdyper hva som skal være med i alle punktene. Steinar har tatt på seg ansvaret for punkt 1 - Introduksjonen Håvard har tatt på seg ansvaret for punkt 2 - Overordnet beskrivelse punkt 2a og 2b Ole-Marius har tatt på seg ansvaret for punkt 3 - Overordnet beskrivelse punkt 2c, 2d og 2e Espen har tatt på seg ansvaret for punkt 4 - Funksjonelle krav Karl har tatt på seg ansvaret for punkt 5 - Ikke-funksjonelle krav Geir har tatt på seg ansvaret for punkt 6 - Testkrav 48

55 Prosjektdirektiv F Faseplan for konstruksjonen Gruppen har bestemt seg for en iterativ utviklingsmodell med sannsynligvis tre inkrement. Dette vil føre til at det blir flere konstruksjonsfaser. F.1 Inndeling av dokumentet Gruppen har brukt IEEEs anbefaling, IEEE Std , for inspirasjon til inndeling av dokumentet. Under er delene listet opp med hva de skal inneholde. Innledning: Innledningen skal inneholde formål, definisjoner og en oversikt over hva konstruksjonsdokumentet inneholder. Overordnet systembeskrivelse: Her deler man komponenten inn i designenheter. Generelle prinsipper som kjente designmønstre som er benyttet skal beskrives her. Definisjon av de ulike designenhetene og grensesnittene som tilbys av disse skal være med i denne delen. Hvilke krav som dekkes av de ulike modulene skal beskrives her. Avhengighetsbeskrivelse: Beskrivelse av avhengighetene mellom designenhetene. Dette skal gjøres både med et avhengighetsdiagram og tekst. Detaljert design: Beskrivelse av intern design av designenhetene. Her må klassediagrammene komme med og en beskrivelse av disse klassene og deres metoder med public synlighet. Sekvensdiagrammer for viktige funksjoner. I sekvensdiagrammene skal kommunikasjon mellom moduler, klasser og eksterne bibliotek komme klart frem. Pseudokode av deler og systemer, use case-diagrammer og andre virkemidler kan også brukes dersom dette finnes hensiktsmessig. I første inkrement skal den overordnede systembeskrivelsen og avhengighetsbeskrivelsen være ferdig. Detaljert design vil bli delt inn i flere deler avhengig av hvor mange konstruksjonsfaser det blir. Det første inkrementet i konstruksjonsfasen må inneholde nok detajert design til at gruppen skal kunne 49

56 Prosjektdirektiv implementere de funksjonelle kravene som tilhører det første inkrementet. I senere inkrement vil konstruksjonen bli basert på konstruksjonen fra første inkrement og her vil bare endringer og tillegg bli beskrevet. F.2 Delansvarlige Inndeling av ansvar er som følger: Innledning - Karl Overordnet systembeskrivelse - Karl og Ole-Marius Avhengighetsbeskrivelse - Espen Detaljert Design - Geir, Håvard og Steinar 50

57 Prosjektdirektiv G Faseplan for implementasjon Implementasjonsdokumentet skal skrives først for ett inkrement og deretter kompletteres med informasjon fra senere inkrementer på samme måte som konstruksjonsdokumentet. G.1 Inndeling av dokumentet Gruppen har for inndelingen av implementasjonsdokumentet sett til tidligere rapporter i faget. Inndelingen som er valgt er som følger: Innledning: Innledningen skal inneholde formål og informasjon om programmeringsmiljøet, samt en oversikt over resten av dokumentet. Kode- og dokumentasjonsstandard: Dette avsnittet skal definere alle retningslinjer og standarder kildekoden gruppen produserer skal følge. Implementasjon av første inkrement: Endringer gjort i forhold til konstruksjonen av første inkrement skal beskrives her, med sekvensdiagrammer om det er hensiktsmessig. Kildekode, skjermbilder og andre diagrammer kan også benyttes om det gjør dokumentet lettere å forstå. Senere inkrementer skal insettes i etterfølgende kapitler. Testapplikasjon: En kort beskrivelse av testapplikasjonen som utvikles for å teste biblioteket skal beskrives her. Status på produktet: Dette kapittelet skal oppsummere hva status på biblioteket er ved overlevering til kunde. Informasjon til nye utviklere: Endringer gruppen finner hensiktsmessig og andre forslag til videre utvikling etter overlevering til kunde skal beskrives her. Installsjonsveiledning: En detaljert veiledning for å komme i gang med å benytte biblioteket skal følge i dette kapittelet. 51

58 Prosjektdirektiv G.2 Delansvarlige Inndeling av ansvar er som følger: Innledning - Geir Kode- og dokumentasjonsstandard - Ole-Marius Implementasjon av første inkrement - Geir Testapplikasjon - Håvard Status på produktet - Håvard Videre Utvikling - Ole-Marius Installasjonsveiledning - Håvard 52

59 Prosjektdirektiv H Faseplan for testfasen Testfasen strekker seg over hele prosjektperioden. Testfasen innebærer å undersøke hvilken strategi gruppen ønsker å bruke for testing, utvikle tester og gjennomføre testene. Inndelingen som er valgt for testdokumentet er som følger: Innledning: Innledningen skal inneholde formål og en oversikt over resten av dokumentet. Overordnet testplan: Dette kapittelet vil undersøke testteknikker og teststrategier man kan benytte seg av. Man må også konkludere med hvilke testteknikker og teststrategier gruppen ønsker å benytte seg av. Videre må man beskrive hvordan man ønsker at testene skal utføres. Testbeskrivelser og testresultat for første inkrement: I dette kapittelet må man utføre det som blir beskrevet i den overordnede testplanen. Videre må man utføre tester man har skrevet og dokumentere resultat. Man må også i dette kapittelet beskrive feil som ble oppdaget fra gjennomføringen av tester og beskrive hva som ble gjort for å rette feilene. Konklusjon: I dette kapittelet må man trekke konklusjoner basert på resultater av de testene som er gjennomført. H.1 Delansvarlige Inndeling av ansvar er som følger: Innledning - Karl Overordnet testplan - Geir Testbeskrivelser og testresultat for første inkrement - Steinar Konklusjon - Karl 53

60 Prosjektdirektiv H.2 Tidsplan I starten av prosjektet vil gruppen utarbeide den overordnede testplanen. Videre må gruppen utvikle tester. Dette arbeidet begynner fra kravspesifikasjonen og vil foregå fram til selve utførelsen av tester starter. Utførelse av tester vil hovedsaklig foregå i implementasjonsfasen. 54

61 Prosjektdirektiv I Faseplan for avslutning Evalueringsdokumentet skal foreta en evaluering av ulike deler av prosjektet. Gruppen skal enes om all informasjon som er i dokumentet, og om gruppen på enkelte punkter har sterkt stridende meninger, skal dette fremkomme i dokumentet. I tillegg skal det i avslutningsfasen også forberedes en presentasjon. I.1 Inndeling av dokumentet Gruppen har for inndelingen av evalueringsdokumentet tatt utgangspunkt i kompendiet for faget og punktene gruppen selv ønsker å belyse. Inndelingen som er valgt er som følger: Innledning: Innledningen skal inneholde formål med evalueringen, kort om gruppens arbeidsmåte, samt en oversikt over resten av dokumentet. Gruppen: Dette avsnittet skal belyse gruppens erfaringer med gruppe- og arbeidsprosessene, hvordan arbeidsfordelingen er gjort, se på tidsbruken for de ulike fasene samt se på problemer og konflikter som har oppstått. Kunden: Dette avsnittet skal se på gruppens samarbeid med kunden, hvordan kunden har bidratt og eventuelle problemer og konflikter som har oppstått mellom gruppen og kunden. Faget: Dette avsnittet skal gi gruppens vurdering av faget prosjektet er gjennomført under, herunder seminarer og forelesninger gruppen har vært på, samarbeid med veilederne, oppgaven som har vært utført og generelle kommentarer til faget. Risiko: Dette kapittelet skal presentere momenter fra risikoanalysen som har slått til, samt risikomomenter som ikke ble funnet under analysen, men som allikevel har slått til. 55

62 Prosjektdirektiv Utnyttelse av ressursene: Dette avsnittet skal vurdere hvordan gruppen har utnyttet de tilgjengelige ressursene. Deler gruppen er fornøyde med: Avsnittet skal vise de delene av prosjektet gruppen er særlig fornøyd med, og se på årsakene til dette. Videre arbeid: Dette avsnittet skal beskrive det videre arbeidet som kan gjøres med det ferdige produktet. Timebruken på dette arbeidet skal estimeres. Presentasjonen skal inneholde alle de viktigste resultatene gruppen har kommet frem til, sentrale løsninger i design og implementasjon og en presentasjon av prototypen. I.2 Delansvarlige For å få en god helhet i evalueringsdokumentet, vil det være samme ansvarlig for de fleste punktene. For å enes om all informasjon i dokumentet skal gruppen gjennomføre fellesmøter både før og etter evalueringsdokumentet er skrevet. Espen er ansvarlig for alle deler med unntak av videre arbeid, dette har Ole-Marius ansvar for. For presentasjonen er Geir ansvarlig for å demonstrere prototypen, mens Ole-Marius er ansvarlig for de andre delene. 56

63 Prosjektdirektiv Referanser [1] Kundestyrt prosjekt, gruppe 14: Ontologidrevet dokumentforvaltning, evaluering, [2] CollabNet Inc. Concurrent versions system

64 Ontologidrevet dokumentforvaltning Forstudie TDT4290 Kundestyrt prosjekt Institutt fra datateknikk og informasjonsvitenskap Fakultet for informasjonsteknologi, matematikk og elektroteknikk Norges teknisk-naturvitenskapelige universitet Gruppe 14 Espen Hansen Ole-Marius Moe-Helgesen Geir Storli Karl Hatteland Steinar Skjerven Håvard Stranden

65

66 Forstudie Innhold 1 Innledning Formål Oversikt Dagens situasjon Dagens situasjon hos DiB Definisjon av ontologi Hensikten med ontologier OWL - Web Ontology Language OWL-strukturen OWL Lite Ønsket situasjon Ønsket situasjon hos DiB Komponent for visualisering av ontologier Forretningsmessige krav 26 5 Evalueringskriterier 27 6 Tolker for OWL Evalueringskriterier for tolker Evaluering av tolkerene Jena Hawk OWL API Konklusjon

67 Forstudie 7 Filtrering Bruksområder for filtrering i forbindelse med prosjektet Om filtre Forklaring av hva filter og visning er Aspekter ved filtre Brukerdefinerte og predefinerte filtre Sammensatte filtre Presentasjon av visninger Eksisterende implementasjoner av filtering i graf Evalueringskriterier Evaluering av InFlow Evaluering av TouchGraph GoogleBrowser Konklusjon Graflayout Grafer Representasjoner av grafer Evalueringskriterier Matematiske representasjoner GraphML The Graph Modelling Language (GML) Konvertering mellom OWL og GraphML Evalueringskriterier Xalan Algoritmer for grafutlegg Evalueringskriterier

68 Forstudie Kraftrettede grafutlegg Hierarkisk utlegg Ortogonalt utlegg Konklusjon Tilgjengelige grafbibliotek Evalueringskriterier GraphViz Java Universal Network/Graph Framework JGraph yfiles Konklusjon Java og grafikk Biblioteker for grafiske brukergrensesnitt Evalueringskriterier Swing Buoy Standard Widget Toolkit Forenklingsmetoder XML for å beskrive GUI GUI-design med grafiske hjelpemidler Tråding i Swing Klassen SwingWorker Foxtrot Spin Konklusjon

69 Forstudie 10 Eksisterende visualiseringsverktøy Evalueringskriterier IsaViz Protégé Plugin: ezowl FRODO RDFSViz Fractal Edge Konklusjon Valg av løsning 87 Referanser 89 5

70 Forstudie Tabeller 1 Forretningsmessige krav Overordnede evalueringskriterier Evalueringskriterier for tolker Evaluering av Jena Evaluering av Hawk Evaluering av OWL API Evalueringskriterier for filtrering Evaluering av InFlow Evaluering av TouchGraph GoogleBrowser Evalueringskriterier for grafrepresentasjoner Evaluering av matematiske representasjoner Evaluering av GraphML Evaluering av GML Evalueringskriterier for konverteringbibliotek Evaluering av Xalan Evalueringskriterier for utleggsalgoritmer Evaluering av Spring embedder Evaluering av Simulated annealing Evaluering av Kamada-Kawai Evaluering av GIOTTO Evalueringskriterier for grafbibliotek Evaluering av GraphViz Evaluering av JUNG Evaluering av JGraph

71 Forstudie 25 Evaluering av yfiles Evalueringskriterier for API for grafiske brukergrensesnitt Evaluering av Swing Evaluering av Buoy Evaluering av Standard Widget Toolkit Evalueringskriterier for forenklingsmetoder for GUI-konstruksjon Evaluering av SwixML Evaluering av SwingWorker Evaluering av Foxtrot Evaluering av Spin Evalueringskriterier for eksisterende løsninger Evaluering av IsaViz Evaluering av Protégé med ezowl-plugin Evaluering av FRODO RDFSViz Evaluering av Fractal Edge

72 Forstudie Figurer 1 Dagens situasjon hos DiB Illustrasjon av eksempelontologi Grunnlaget for OWL Visualisering av OWL-struktur Kildekode for OWL-eksempel, del Kildekode for OWL-eksempel, del Ønsket situasjon hos DiB Overordnet syn på komponenten Urettet graf Rettet graf med vekter på kantene Nabomatrise-representasjon av en graf Naboliste-representasjon av en graf GraphML-representasjon av en graf GML-representasjon av en graf Graf lagt ut med Spring embedder-algoritmen GIOTTO-algoritmen Skjermbilde fra IsaViz Skjermbilde 1 fra Protégé med ezowl-plugin Skjermbilde 2 fra Protégé med ezowl-plugin Skjermbilde fra FRODO RDFSViz Graf fra Fractal Edge Valg av komponenter for løsning

73

74 Forstudie 1 Innledning Forstudiet er et viktig utgangspunkt for et vellykket prosjekt. Det skal gi en oversikt over problemet og situasjon, og danner samtidig grunnlaget for alle kommende faser i prosjektet. 1.1 Formål Gjennom forstudiet skal prosjektgruppen få en dypere forståelse av problemet gitt av kunden, samt hvilke mulige løsninger som finnes. Det er viktig å finne ut hva kunden egentlig ønsker seg, og ut ifra dette evaluere de mulige løsningene for å finne den beste løsningen på problemet. Eksisterende komponenter og teknologier vil bli vurdert og evaluert for å finne ut om de kan brukes i den endelige løsningen på problemet. Et vektingssystem vil bli brukt i evalueringen, slik at den løsningen med høyest poengsum vil bli valgt. 1.2 Oversikt I kapittel 2 beskrives dagens situasjon hos Doctors in Businss AS(DiB). Videre i dét kapittelet vil et teknisk grunnlag bli lagt for resten av prosjektet. Gruppen forklarer der nærmere en del teknisk terminologi som er relevant for prosjektet. I kapittel 3 beskrives den ønskede situasjon til kunden. I kapittel 4 følger de forretningsmessige kravene som har blitt utarbeidet i samarbeid med kunden, og som komponenten 1 skal tilfredstille. Basert på disse kravene har gruppen kommet fram til overordnede evalueringskriterier for komponenten. Disse er beskrevet i kapittel 5. Den ønskede situasjonen til kunden ga gruppen en videre oversikt over hvilke løsningsalternativer som burde undersøkes og evalueres. Disse ønskene ble benyttet som grunnlag for å sette opp en oversikt over hvilke deler komponenten skulle bestå av. Evalueringer innen de ulike temaene for disse delene er i kapittel 6 til 9. Gruppen har videre i kapittel 10 også undersøkt eksisterende løsninger på markedet og sett på hvilke teknikker som burde benyttes fra disse. 1 Komponenten er i forstudiet brukt om visualiseringskomponenten prosjektet skal produsere. Mer om denne kan leses i kapittel 3. 10

75 Forstudie Avslutningsvis gjøres et valg av løsning på bakgrunn av delkonklusjoner og evalueringer beskrevet tidligere. Valg av løsningen kan man lese mer om i kapittel

76 Forstudie 2 Dagens situasjon Kapittelet beskriver dagens situasjon hos Doctors in Business. I avsnitt 2.1 vil den eksisterende arbeidsbenken de benytter bli beskrevet, og videre følger en introduksjon til en del av terminologien som benyttes i oppgaven. Denne delen er å finne i avsnitt 2.2 til 2.4. I forbindelse med ontologier vil kapittelet se på begreper som: ontologi; hva det er, og hvorfor der er blitt et viktig begrep i dataverdenen. semantisk web; hva det er og hensikten med den. Web Ontology Language (OWL); hva det er, hvorfor den er blitt til, og litt om strukturen. 2.1 Dagens situasjon hos DiB Doctors in Business har i dag en konfigurerbar arbeidsbenk for dokumentanalyse. Denne arbeidsbenken består av en serie med komponenter som hver står for ett steg i dokumentanalyseprosessen 2. Figur 1 viser de forskjellige stegene i denne prosessen. Stjerner representerer inndata og utdata, mens boksene representerer komponenter. Man har mulighet til både å utelukke visse steg i prosessen, samt endre rekkefølgen på dem. Figur 1 viser den vanligste konfigurasjonen. Som inndata til dokumentanalyseprosessen har man en norsk dokumentsamling fra ett gitt domene. Selv om dokumentsamlingen i prinsippet kan være på ulike språk, krever hvert språk sine egne tilrettelegginger. DiB har derfor kun støtte for analyse av norske dokumentsamlinger. Som inndata til prosessen er også en referanse til generelt språk. Denne referansen inneholder ord og fraser som er vanlige i domenet dokumentsamlingen er fra, men som ikke er med på å uttrykke innholdet i dokumentsamlingen. Den første komponenten konverterer dokumentsamlingen om til en XML-struktur som er egendefinert av DiB. Neste komponent gjennomfører en såkalt ordklassemerking. Dette innebærer å finne ordklassen for hvert enkelt ord, som substantiv, verb, preposisjon og så videre, og lagre dette i 2 En dokumentanalyseprosess er en prosess som analyserer dokumenter i henhold til visse ønskelige kriterier, og som gir ut et resultat på grunnlag av disse kriteriene. 12

77 Forstudie XML-strukturen. Den etterfølgende komponenten vil gjennomføre en lemmatisering, det vil si å redusere ordene til sin baseform. Et eksempel på det vil være å redusere ordet biler til ordet bil. Neste komponent vil utføre en frasedeteksjon, der den prøver å finne fraser og ord som ofte hører sammen. Etterfølgende komponent vil gjennomføre en rarhetsanalyse, der den vil telle forekomster av ord og fraser som har høy frekvens i dokumentsamlingen. Man vil her benytte referansen til det generelle språket for å filtrere bort ord som ikke er av interesse. Ut ifra dette beregnes en faktor som beskriver hvor spesielt ordet er. Komponenten vil så returnere en rangert liste over ord og fraser. Den siste komponenten vil gjennomføre en relasjonsanalyse, som regner ut sannsynligheten for at det finnes relasjoner mellom de ordene og frasene den forrige komponenten returnerte. Til slutt står man igjen med en XML-struktur som danner utgangspunktet for en ontologi over domenet. Ved å ta utgangspunkt i denne strukturen modellerer man ontologien manuelt ved å benytte Protègè. Resultatet er en OWL-fil som representerer ontologien. Denne representasjonen av ontologien er ikke i bruk i dag i noen egne ontologibaserte applikasjoner hos DiB. Det er disse ontologibaserte applikasjonene de ønsker å bygge i fremtiden. Dette er videre beskrevet i kapittel 3 om ønsket situasjon. I denne sammenheng er en visualiseringskomponent første trinn. 2.2 Definisjon av ontologi Siden ontologier er grunnlaget for forretningsidéen til DiB, er det på sin plass å se litt nærmere på hva dette er. Dette delkapittelet vil prøve å forklare nettopp dét. Opprinnelig stammer begrepet ontologi fra filosofien der man prøvde å beskrive de forskjellige entitetene i verden og hvordan de var relatert. Det er mange definisjoner av hva en ontologi er avhengig av hvilken kontekst man bruker begrepet i [9]. Tom Gruber sa det slik: An ontology is a specification of a conceptualization [12]. Sagt på en annen måte; en ontologi definerer de uttrykkene som brukes til å beskrive og representere et kunnskapsområde. Ontologiene inneholder definisjoner av domenets basiskonsepter, samt sammenhengene mellom disse. En slik representasjon gjøres mulig ved å benytte de tre konseptene klasser, relasjoner og egenskaper. Det er også vanlig å beskrive en ontologi som en begrepsmodell. 13

78 Forstudie Figur 1: Dagens situasjon hos DiB 14

79 Forstudie Et eksempel på en ontologi kan være følgende: Et målebeger rommer opptil 10 dl. Hvis begeret nå fylles med 5 dl vann, kan man si at begeret: er halvfullt er halvtomt inneholder halvparten av hva det rommer inneholder 5 dl vann Ontologien her kan illustreres som i figur 2. Denne viser at klassen Beholder har en egenskap som heter kapasitet. Dette er vist på flere måter i figuren. For det første er beholder registrert med Attributt:kapasitet. En annen måte er å vise den samme attributten med en relasjon. Det er der kapasitet er vist på pilen fra beholder-klassen. Kapasitet har videre to klasser som arver den: halvfull og halvtom. Pilene mellom disse viser at de er ekvivalente. Figur 2: Illustrasjon av eksempelontologi Poenget er at man kan beskrive det samme på forskjellige måter avhengig av perspektivet eller tankegangen. Ontologier er til for å samle disse beskrivelsene, slik at man vet at de betyr det samme. 15

80 Forstudie 2.3 Hensikten med ontologier For applikasjoner som skal søke gjennom og sette sammen informasjon fra forskjellige fagområder vil ontologier være nyttige. Innen fagområder som for eksempel medisin kan flere ord og uttrykk bety det samme. Derfor er det ønskelig å søke på begrepsnivå i stedet for i enkeltord. Dette vil en ontologi over fagområdet kunne hjelpe til med. I forbindelse med semantisk web (se avsnitt 2.4) kan ontologier brukes til å representere semantikken 3 i dokumenter, og derfor gjøre det mulig for webapplikasjoner å bruke denne semantikken til for eksempel søk. 2.4 OWL - Web Ontology Language OWL er et språk som skal legge til rette for at applikasjoner og maskiner skal kunne resonnere over data som ligger på World Wide Web (WWW) og i dokumenter [16]. Fram til idag, og forsåvidt fortsatt, har data på WWW stort sett blitt presentert for mennesker [18]. I maskinsammenheng er data som blir presentert veldig avgrenset til å gjelde spesifikke brukergrupper 4. I de tilfellene vil informasjonen bare kunne bli brukt av systemene innenfor brukergruppen. Disse systemene har da ofte skreddersydde løsninger som gjør det mulig for dem å utnytte informasjonen på en hensiktsmessig måte. Maskiner utenfor vil ikke kunne utnytte dette. Semantisk web har blitt til for å forbedre disse problemene. Målet til semantisk web er å utvide av den nåværende WWW, slik at alle data får en definert mening som gjør at maskiner og mennesker kan arbeide sammen på en bedre måte [16]. Semantisk web skal gi et felles rammeverk som gir støtte for deling og gjenbruk av data på tvers av applikasjonsgrenser, forretningsgrenser, gruppegrenser og geografiske grenser. OWL er en ny standard som skal legge til rette for dette OWL-strukturen OWL er et XML-basert format. I tillegg utnytter den funksjonaliteten og strukturen til RDF og RDF-Schema. XML, RDF og RDFS egner seg best til, 3 Med semantikk menes i denne sammenhengen betydningen av ordene. 4 Med brukergrupper i denne sammenheng menes det en gruppe av maskiner. 16

81 Forstudie og har hovedsaklig blitt brukt til, å framstille data for mennesker. Et eksempel er en webside. Man kan lese mer om strukturen til OWL på hjemmesidene til World Wide Web Consortium (W3C). OWL har tatt steget videre for å bedre kunne framstille meninger med og relasjoner mellom begreper i et dokument, da hovedsaklig med tanke på at maskiner skal kunne behandle det som står i et dokument. Sagt med andre ord har OWL utvidet ordforrådet som XML, RDF og RDFS har lagt til grunn. Dette skal gjøre det enklere for maskiner å resonnere over dokumenter. OWL deles inn i tre subspråk: OWL Lite, OWL DL og OWL Full. Disse tre språkene tilbyr forskjellig uttrykksnivå. OWL Lite er et subsett av OWL DL, som igjen er et subsett av OWL Full. Valg av OWL-dialekt styrer kompleksitetsnivået av modellen og mengden informasjon man kan få uttrykt. OWL Full gir flere muligheter og større kompleksitetsnivå enn OWL DL, som igjen gir flere muligheter og større kompleksitet enn OWL Lite. Figur 3 viser hvordan OWL passer inn sammen med andre teknologier og idéer. Denne figuren er tatt fra en presentasjon av Tim Berners-Lee, Direktør for W3C [2]. Boksen merket Ontology er stedet OWL hører hjemme. Figur 3: Grunnlaget for OWL I bunnen ligger Uniform Resource Identifiers (URI) og Unicode. Unicodestandarer definerer koder for de fleste kjente tegnsett og definerer fomater og kodinger for å representere disse. URIer benyttes for referanser til ressurser. URLer, som er kjent fra WWW, er eksempler på URIer. 17

82 Forstudie Ved å benytte Unicode-enkoding og URIer bygges XML-dokumenter. Disse har navnerom, eller namespace i figuren, som benyttes for å begrense skopet til et dokument eller sette det i kontekst. Med disse verktøyene bygges dokumenter i språket Resource Description Framework. Med M&S i figuren menes model and syntax, altså at både RDFmodellen og RDF-syntaksen benyttes. RDF-Schema strukturerer datene i de underliggende lagene i figuren. Strukturen blir seende likt ut som ER-diagram(Entity Relationship). RDF-Schema i seg selv gir ikke mye betydning. Laget som ligger over gir mer betydning og dette laget heter ontology. Dette laget har flere egenskaper og her kan man resonnere over datene. Regellaget som ligger over tilbyr muligheter for spørringer og filtrering. Det finnes ulike systemer som tilbyr mer eller mindre samme funksjonalitet. Det logiske laget er et rammeverk for å kunne skrive aksiomer om ontologien under. Dermed kan en bruker resonnere om de lagrede dataene. Det er fortsatt ikke enighet om standardisering for dette laget, men meningen er at man ut i fra dette kan resonnere seg fram til ulike bevis, eller proofs i figuren. På toppen ligger tillit. Ulike utsagn på WWW kommer i ulike kontekster og det er nødvendig for en applikasjon å vurdere hvert utsagn, hver applikasjon eller hver kontekst for å bestemme seg for om den kan ha tillit til informasjonen. For å sikre seg at en slik tillit kan oppnås, må signering og kryptering benyttes gjennom hele prosessen. Dette er symbolisert ved at dette ligger på siden av alle andre lag OWL Lite Gruppen skal fokusere på et subsett av OWL Lite-versjonen til visualiseringskomponenten. Gruppen har i samarbeid med kunden kommet fram til at det ikke er hensiktsmessig å ta med alle egenskapene som OWL Lite tilbyr. I stedet er de mest nødvendige og grunnleggende egenskapene tatt med. I figur 5 og 6 er et eksempel som bruker OWL Lite. Egenskapene bygger i hovedsak på RDFS [16], og er som følger: Class - En gruppe av individer som hører sammen fordi de deler noen attributter. 18

83 Forstudie rdfs:subclassof - Brukes til å lage klassehierarkier. rdf:property - Attributter kan bli brukt til å lage relasjoner mellom individer eller mellom individer og verdier. Den første er en ObjectProperty. Den andre er en DatatypeProperty. owl:objectproperty og owl:datatypeproperty er subklasser av RDF-klassen rdf:property. rdf:subpropertyof - Brukes til å lage attributthierakier. rdf:domain - Domenet til et attributt begrenser hvilke individer attributtet vil gjelde for. rdf:range - Range, eller variasjonsbredde, knyttes til en attributt og begrenser hvilke individer denne kan ha som sin verdi. Individual - Individer er instanser av klasser. Attributter kan bli brukt til å relatere et individ til et annet. I tillegg til disse egenskapene har OWL Lite en del egenskaper i forbindelse med likhet og ulikhet, kardinalitet, attributter, med flere. Som sagt vil ikke disse bli tatt med i dette prosjektet. Disse andre egenskapene har blitt til av årsaker allerede nevnt; å skape et språk som gjør det lettere for datamaskiner å behandle og bruke dataene som ligger i et dokument eller på WWW. Dette vil være veldig praktisk når maskiner skal resonnere over hva som står i et dokument, eksempelvis i forbindelse med å lage et resymé av dokumentet. Figur 4 er en visualisering i Protégé (se også avsnitt 10.3) av et OWL dokument som viser et klassehieraki og noen av de forskjellige egenskapene: Sorte piler angir subklasser. For eksempel er Lens en subklasse av PurchaseableItem. Blå piler viser relasjonene mellom klassene, klassenavn er i gul rad og attributtene er merket med en S. Kildekode i OWL for dette eksempelet er gitt i figur 5 og 6. 19

84 Forstudie Figur 4: Visualisering av OWL-struktur 20

85 Forstudie Figur 5: Kildekode for OWL-eksempel, del 1 21

86 Forstudie Figur 6: Kildekode for OWL-eksempel, del 2 22

87 Forstudie 3 Ønsket situasjon Dette kapittelet beskriver ønsket situasjon hos kunden, og hvordan denne gir opphav til problemet kunden ønsker en løsning på. 3.1 Ønsket situasjon hos DiB DiB ønsker å bygge ontologibaserte applikasjoner for ontologibasert dokumentforvaltning. Et eksempel på en slik applikasjon vil være en form for indekssystem 5, som vil gjøre det lettere for brukere å finne igjen aktuell informasjon i dokumentsamlingen. I den forbindelse ønsker de et grafisk brukergrensesnitt som fortrinnsvis visualiserer ontologien, men hvor man også har muligheten til å navigere i den. Etterhvert ønsker man også å vise kobling mellom ontologi og dokumentsamling i dette brukergrensesnittet. I tillegg er det også interessant å legge til muligheten for å søke i ontologien. Alt dette vil gjøre systemet interessant for brukere som skal holde oversikt over, vedlikeholde og lete etter informasjon i store dokumentsamlinger. Kunden ønsker derfor at prosjektgruppen skal lage en prototype av en komponent for visualisering av ontologier som de senere vil sette i en større sammenheng. Denne visualiseringskomponenten er første trinn for å kunne lage flere ontologibaserte applikasjoner. Figur 7 viser ønsket situasjon hos kunden. 3.2 Komponent for visualisering av ontologier I samarbeid med kunden har prosjektgruppen kommet fram til hvilke deler visualiseringskomponenten må bestå av. Utgangspunktet for visualiseringen er en OWL-ontologi med RDF/XML-syntaks. Denne filen er man nødt til å tolke slik at man får en objektstruktur man kan jobbe videre med i komponenten. Selv om komponten skal kunne lese OWL Full-ontologier, så er det bare et subsett av funksjonaliteten i OWL Lite som skal danne grunnlaget for visualiseringen. Tolkeprosessen vil derfor kun returnere en objektstruktur som benytter den gitte funksjonaliteten i OWL Lite. Alt annet vil ignoreres. Objektstrukturen danner grunnlaget for å generere en graf, som så vil legges ut etter diverse estetiske kriterier. Ved hjelp av et grafisk bibliotek vil grafen visualiseres for brukeren. Ettersom objektstrukturen typisk vil være så stor 5 Et indekssystem er en samling av indekserte referanser som er satt i system 23

88 Forstudie Figur 7: Ønsket situasjon hos DiB 24

89 Forstudie at det blir vanskelig å visualisere alt på en gang, vil det være nødvendig å foreta en form for filtrering der man velger ut hvilke deler av grafen som skal vises. Grafen legges ut på nytt, og visualiseres igjen for brukeren. Figur 8 viser hvilke deler visualiseringskomponenten skal bestå av. Figur 8: Overordnet syn på komponenten Denne oversikten over hva komponenten må bestå av danner grunnlaget for hvilke områder som er valgt for nærmere studie. Siden DiB i dag ikke har noen eksempelapplikasjoner som benytter OWL, må det i tillegg utvikles en liten applikasjon som benytter komponenten for å visualisere OWL-ontologier. Denne klientapplikasjonen skal være så enkel som overhodet mulig, og kun benyttes til testing og verifisering av komponenten. 25

90 Forstudie 4 Forretningsmessige krav Kapittelet inneholder de forretningsmessige kravene som er utarbeidet i samarbeid med kunden, og som komponenten skal tilfredstille. Disse kravene danner grunnlaget for evalueringskriteriene, og vil senere omformes til funksjonelle og ikke-funksjonelle krav i kravspesifikasjonsfasen. De forretningsmessige kravene finnes i tabell 1. ID Navn FM1 Komponenten skal ha et godt definert og dokumentert grensesnitt. FM2 Komponenten skal implementeres i Java. FM3 Komponenten skal visualisere ontologier som en graf. FM4 Komponenten skal kunne lese OWL Fullontologier. FM5 Komponenten skal bruke data fra et subsett av OWL Lite som utgangspunkt for visualisering. FM6 Responstid for brukeren skal være maksimalt ett minutt. FM7 Komponenten skal kunne visualisere en ontologi med 1000 begrep og 5000 relasjoner. Brukeren skal kunne samhandle med komponenten ved å kunne navigere i ontologien, samt å velge utsnitt i ontologien som er av interesse. FM8 Komponenten skal være plattformuavhengig. FM9 En prototyp av komponenten skal være ferdig FM10 Verktøy og andre komponenter som benyttes bør være så billige som mulig. FM11 Komponenten skal være stabil. FM12 Dokumenteringen skal være grundig og lett forståelig. FM13 Brukergrensesnittet skal være intuitivt. Tabell 1: Forretningsmessige krav 26

91 Forstudie 5 Evalueringskriterier Her følger de overordnede evalueringskriteriene som gruppen har valgt å legge til grunn for evalueringene. Disse følger i kapittel 6 til 9. Kriteriene har tatt utgangspunkt i de forretningsmessige kravene fra kapittel 4, og er oppsummert i tabell 2. For å vurdere de ulike kriteriene brukes en vekting for å angi grad av viktighet. Vekting av viktighetsgrad er satt fra 1 til 5, hvor 5 er høyest og 1 er lavest. De forskjellige komponentene og metodene som gruppen har sett på vil bli mer detaljevaluert i sammenheng med dem. Gruppen har gjort evalueringer ut fra evalueringskriterier. Et eksempel på dette er i tabell 4. For hvert evalueringskriterium som evalueres vil det bli gitt en karakter etter hvor godt evalueringskriteriet er oppfylt av det som evalueres. Karakterene vil bli gitt fra 0 til 5, hvor 0 er ikke-eksisterende grad, 1 er lavest grad og 5 er høyest grad av oppfyllelse. Verdien som regnes ut er vekt multiplisert med karakter. Summen av verdiene til hvert evalueringskriterium blir regnet ut til slutt og vil utgjøre endelig poengsum for evalueringen. ID Navn Vekting EK1 Plattformuavhengighet 5 EK2 Korrekt parsing av OWL 5 EK3 Responstid 4 EK4 Stabilitet 4 EK5 Grensesnitt 3 EK6 Dokumentasjon 2 EK7 Utviklingstid 4 EK8 Videreutvikling 4 EK9 Brukergrensesnitt 3 EK10 Kostnad 3 Tabell 2: Overordnede evalueringskriterier 27

92 Forstudie EK1 - Plattformuavhengighet: Java er satt som språk i forretningsmessig krav FM2 (se tabell 1) og én av grunnene til dette er plattformuavhengighet. Det er ønskelig at komponenten kan benyttes på så mange ulike operativsystemer som mulig. Microsoft Windows, MacOS og Linux er de viktigste, men enda bredere støtte må til for topp score. Årsaken til dette er at DiB skal kunne benytte komponenten i programmer som demonstreres hos deres kunder, og det er umulig å forutsi hvilket operativsystem de benytter. Plattformuavhengigheten er også et eget forretningsmessig krav; FM8. EK2 - Korrekt parsing av OWL: Komponenten må kunne lese OWL Full og vise riktig struktur og riktige relasjoner (FM4). Det er imidlertid bare et subsett av OWL Lite som skal danne grunnlaget for visualiseringen av ontologien. (FM5) EK3 - Responstid: Komponenten skal ha en responstid som er i henhold til de kravene som ble stilt av kunden (FM6). Da dette er for komponenten som helhet, er ett minutt for mye for enkeltbiblioteker og det er derfor ønskelig at de utfører sine arbeidsoppgaver så raskt som mulig. Responstid må følge kravene i FM6 også for tilfellene i FM7. EK4 - Stabilitet: Komponenten skal være stabil og ikke inneholde feil. (FM11). Lav stabilitet kan også påvirke ferdigstillelsen (FM9). Det er viktig at stabiliteten holder også ved grensetilfellene satt i FM7. EK5 - Grensesnitt: Det skal være lett å integrere den visuelle komponenten med andre, utenforstående komponenter (FM1). Merk at det her ikke er snakk om brukergrensesnittet. Med lett menes det at dokumentasjonen skal være grundig slik at en lett skal forstå hvordan komponenten er bygd opp, og hvordan den fungerer. EK6 - Dokumentasjon: Den visuelle komponenten skal være godt dokumentert. (FM1 og FM12) Dette gjelder både API-grensesnittet og bruken av komponenten. En midre applikasjon som benytter komponenten vil eksemplifisere dette. 28

93 Forstudie EK7 - Utviklingstid: Prosjektet har en fastsatt tidsfrist. Det må derfor tas hensyn til utviklingstid ved valg av løsning (FM9). EK8 - Videreutvikling: Det skal være enkelt å videreutvikle den visuelle komponenten etter at prosjektet er avsluttet (FM1). Med enkelt menes det at dokumentasjonen skal være grundig slik at en lett skal forstå hvordan komponenten er bygd opp, og hvordan den fungerer. Se forøvrig EK5 om grensesnitt og EK6 om dokumentasjon. For videreutvikling er det viktig at også interne deler av komponenten er godt dokumentert. EK9 - Brukergrensesnitt: Komponenten skal ha et forståelig og intuitivt brukergrensesnitt (FM13) og dette skal blant annet visualisere grafer (FM3). EK10 - Kostnad: Løsningen bør i utgangspunktet være kostnadsfri (FM10). Det vil si at det bør ikke være nødvendig å kjøpe komponenter eller lignende for å lage den visuelle komponenten. Skulle det likevel oppstå kostnader i denne forbindelse, er kunden åpen for dét. 29

94 Forstudie 6 Tolker for OWL I avsnitt 3.2 kom man fram til at komponenten trenger en tolker som kan generere en objektstruktur ut ifra en OWL-fil. Om man setter dette i perspektiv til figur 8 i kapittel 3 vil tolkeren befinne seg i boks B og lese data i OWL-format. Denne dataen befinner seg i boks A. Ettersom tolking er en viktig del av komponenten er det også viktig for prosjektet å finne det best egnede rammeverket for tolking av OWL-filer. Under følger beskrivelser og evalueringer av de aktuelle tolkerene for OWL. Evalueringskriteriene for tolkeren er også listet. 6.1 Evalueringskriterier for tolker I henhold til evalueringskriteriene gitt for systemet som helhet, og spesielt EK2 og EK4, er følgende kriterier satt for tolkeren. Disse er oppsummert i tabell 3. PAR1 - Tolking: Det er viktig at tolking av OWL-filer er korrekt (EK2). I tillegg bør tolking av OWL Full støttes, ettersom komponenten ikke skal gjøre feil hvis den skal visualisere en OWL Full-ontologi. Dette er ikke et absolutt krav, da det kun er ett subsett av OWL Lite som legger grunnlaget for visualiseringen. PAR2 - Dokumentasjon: Dokumentasjon er viktig for alle rammeverk. Jo mer oversiktlig og fullstendig den er, jo lettere vil det være å bruke APIet til tolkeren. PAR3 - Lisens: Det er et krav at APIet er så billig som mulig i bruk, og aller helst kostnadsfritt (EK11). Jo færre føringer som legges av lisensen for koden som bruker biblioteket, jo bedre er det også. PAR4 - Stabilitet: Stabilitet er et viktig krav til det endelige produktet (EK4), og er direkte avhengig av stabiliteten til benyttede rammeverk. Stabilitet er forbundet med hvor lenge et rammeverk har vært i bruk på markedet. 30

95 Forstudie PAR5 - Kompleksitet: Utviklingstiden forventes å øke dersom kompleksiteten til de brukte rammeverkene er høye (EK7). ID Navn Vekting PAR1 Tolking 5 PAR2 Dokumentasjon 3 PAR3 Lisens 4 PAR4 Stabilitet 4 PAR5 Kompleksitet 2 Tabell 3: Evalueringskriterier for tolker 6.2 Evaluering av tolkerene Under følger beskrivelser og evalueringer av de aktuelle tolkerene for OWL Jena Jena 6 er et Javarammeverk for å lage applikasjoner for semantisk web som inneholder en programmeringsomgivelse for RDF, RDFS og OWL. Jena har åpen kildekode som er lisensiert under BSD [4], og blitt utviklet i forbindelse med HP Labs Semantic Web Programme. Jena inneholder en generell ontologi-api som blant annet støtter OWL, og som tilbyr tolking av OWL Full-ontologier. Hver ontologimodell som blir lastet inn vil bli assosiert med en dokumentstyrer som sørger for prosessering og behandling av ontologimodellen. Det finnes veldig god dokumentasjon for ontologi-apiet utover vanlig JavaDoc. W3C lister Jena som eneste tolker for OWL, og det blir i tillegg brukt i Protègè OWL Plugin 7. Jena1 ble utgitt i 2000 og har hatt over 5000 nedlastninger. Dagens versjon Jena2 ble utgitt i 2003 og har hatt over 3500 nedlastninger. Jena er derfor et 6 Jena er et utviklingsprosjekt tilgjengelig fra 7 OWL Plugin er en tilleggskomponent til Protègè for behandling av OWL-ontologier utviklet av Stanford University og tilgjengelig fra 31

96 Forstudie modent bibliotek som både er utbredt og godt utprøvd. Ulempen er at det inneholder mye mer funksjonalitet enn det prosjektet egentlig har behov for. Evalueringen av Jena er oppsummert i tabell 4. EvalueringsID: EV-PAR-1 Krit-ID Vekting Vurdering Karakter Verdi PAR1 5 Støtter OWL Full 5 25 PAR2 3 Veldig god tilleggsdokumentasjon PAR3 4 Åpen kildekode, som er ønskelig PAR4 4 Godt utbredt og utprøvd 5 20 PAR5 2 Veldig komplekst 2 4 Sum 84 Tabell 4: Evaluering av Jena Hawk Hawk 8 er et Javarammeverk som støtter OWL, og som blant annet inneholder en tolker for OWL. Hawk har åpen kildekode som er lisensiert under GPL [19]. Det er bygget på toppen av Jena, noe som gjør at rammeverket blir mindre komplekst og lettere å få oversikt over. Foreløpig finnes bare en betaversjon tilgjengelig, noe som betyr at det kan være ting å utsette på stabiliteten til rammeverket. Utover JavaDoc eksisterer det lite dokumentasjon, og det kommer ikke klart fram i denne om OWL Full støttes. Evalueringen av Hawk er oppsummert i tabell OWL API OWL API 9 er et Javarammeverk for OWL som fokuserer på OWL Lite og OWL DL. OWL API har åpen kildekode som er lisensiert under LGPL [20]. 8 Hawk er utviklet av Zhengxiang Pan og er tilgjengelig fra 9 OWL API er et utviklingsprosjekt ledet av Raphael Volz og er tilgjengelig fra 32

97 Forstudie EvalueringsID: EV-PAR-2 Krit-ID Vekting Vurdering Karakter Verdi PAR1 5 Usikkerhet grunnet tynn dokumentasjon 3 15 PAR2 3 Lite tilleggsdokumentasjon 2 6 PAR3 4 GPL legger flere føringer enn LGPL og BSD 4 16 PAR4 4 Finnes kun i betaversjon 3 12 PAR5 2 Veldig bra 5 10 Sum 59 Tabell 5: Evaluering av Hawk Det inneholder blant annet en tolker for OWL. Arbeidet med APIet er under utvikling, og det finnes på nåværende tidspunkt kun en alfaversjon tilgjengelig. Stabiliteten til rammeverket vil derfor måtte anses å være dårlig. Det eksisterer lite dokumentasjon utover JavaDoc. Evalueringen av OWL API er oppsummert i tabell 6. EvalueringsID: EV-PAR-3 Krit-ID Vekting Vurdering Karakter Verdi PAR1 5 Støtter ikke OWL Full 2 10 PAR2 3 Lite tilleggsdokumentasjon 2 6 PAR3 4 Åpen kildekode, som er ønskelig 5 20 PAR4 4 Finnes kun i alfaversjon 3 12 PAR5 2 Bra 4 8 Sum 56 Tabell 6: Evaluering av OWL API 6.3 Konklusjon Gruppen har i dette kapittelet sett på tre ulike rammeverk for tolking av OWL-filer. Både Hawk og OWL API er mindre komplekse enn Jena, men det er derimot usikkert om de støtter OWL Full. Ettersom det er en stor fordel hvis rammeverket har støtte for OWL Full, vil valget av tolker falle 33

98 Forstudie på Jena. Man ser også at Jena scorer vesentlig høyere enn de to andre på evalueringen. Jena virker også som et mye sikrere valg da dette rammeverket har vært i bruk en god stund. Faren for feil i rammeverket er mye mindre, samtidig som det finnes god støttedokumentasjon. I tillegg finnes personell på IDI 10 som har erfaring med bruk av Jena. 10 Prosjektet er gjennomført under Institutt for Datateknikk og Informasjonsvitenskap (IDI) ved NTNU 34

99 Forstudie 7 Filtrering Gruppen har vurdert at filtrering er en så viktig del av visualiseringskomponenten at det er viet et eget kapittel til dette temaet. I figur 8 i kapittel 3 kan man se at filtrering kommer inn som en direkte del av hvordan ontologien visualiseres (boks E.1). Fokus i dette kapittelet vil være på å undersøke hvilke typer filter som eksisterer og hvordan man på en optimal måte kan bruke filter for å forenkle en visualisering. 7.1 Bruksområder for filtrering i forbindelse med prosjektet Visualiseringskomponenten som skal lages skal visualisere en ontologi. Språket som brukes for å representere ontologier er OWL, som har mange egenskaper. Mer informasjon om dette finnes i kapittel 2. Noen få av egenskapene er Class, subclassof og Property. Hvis en bruker ikke har behov for å få visualisert alle disse egenskapene i grafen, men heller et utvalg av disse er det et filter som kan gjøre denne jobben. Man kan spesifisere kriterier for å få et utvalg med bare den informasjonen man har bruk for. En tenkt situasjon kan være at brukeren har valgt seg ut en node i grafen hvor brukeren ønsker å se alt den noden har en relasjon til. Altså alle noder som er direkte relatert, mens noder som ikke direkte er i relasjon med valgt node er uvesentlig. Da kan en ønsket visning være bare disse nodene som er direkte relatert til den valgte noden. For en forklaring av hva en visning er se avsnitt En annen tenkt situasjon er at en bruker bare ønsker å se øverste nivå av Class uten noen form for subclassof. Dette kan et filter gjøre noe med og videre i dette kapittelet vil en studie av filter bli presentert. 7.2 Om filtre Filtre kan brukes til å redusere kompleksiteten til en modell. Det er i mange tilfeller ikke nødvendig å vise fram alle detaljer i en modell, men heller et detaljnivå som er tilpasset for en bruker. 35

100 Forstudie Forklaring av hva filter og visning er Modellen som ønskes forenklet er for dette prosjektet en grafrepresentasjon. Grafrepresentasjonen før den har gått igjennom et filter kan kalles den fulle spesifikasjonen. Et filter spesifiserer kriteriene for hvilke detaljer som skal utelates fra opphavsspesifikasjonen. Opphavsspesifikasjonen er nødvendigvis ikke den fulle spesifikasjonen, siden en spesifikasjon kan ha flere nivå. Hvis man har filtrert en gang fra den fulle spesifikasjonen får man en ny spesifikasjon. Denne blir opphavsspesifikasjonen hvis man skal filtrere videre ut fra denne. En visning er en abstraksjon av en spesifikasjon som ikke er den fulle spesifikasjonen, men en abstraksjon av en spesifikasjon som har gått igjennom et filter. En visning viser grafrepresentasjonen fra et bestemt perspektiv. De forskjellige visningene gir en som betrakter grafen muligheten til å betrakte grafen fra forskjellige perspektiv. Visningene vil inneholde forskjellig grad av detaljer og ved å gi en bruker omgivelser for å komme fram til en visning med ønskelig detaljnivå, kan brukeren betrakte grafen fra det perspektivet brukeren ønsker. Disse omgivelsene vil være å kunne spesifisere kriteriene som brukes ved filtreringen[17] Aspekter ved filtre Filtrene som eventuelt skal brukes er avhengig av modellen, grafrepresentasjonen, og er derfor domeneavhengig. Kriteriene som skal spesifiseres vil derfor bli domenespesifike. Viktige aspekter ved filtre er: Inkludering og utelukkelse: At man kan spesifisere kriterier for å inkludere og utelukke komponenter man ønsker å ha med i en visning. Determinisme og ikke-determinisme: Determinisme er at visningen blir den samme hver gang ut fra de samme kriteriene, mens ikke-determinisme er at hvilken visning som kommer ut fra et sett kriterier er uforutsigbart. Globale og lokale effekter: Lokale effekter er når det ikke er effekter utenfor den spesifikasjonen filteret opererer på. Globale effekter er når effektene berører andre spesifikasjoner. Et problem med globale effekter er 36

101 Forstudie hvordan man skal utbre effektene til de andre spesifikasjonene som effektene berører. Derfor har de fleste filtre bare lokale effekter. Projeksjon og tilnærming: Et filter kan generere en projeksjon eller en tilnærming av opphavsspesifikasjonen Brukerdefinerte og predefinerte filtre Man skiller mellom to ulike typer filtre, nemlig brukerdefinerte filtre og predefinerte filtre. Brukerdefinerte filtre blir manuelt laget av brukeren. Graden av kontroll brukeren skal ha for å definere filtre kan variere fra å gi brukeren full kontroll til å gi brukeren verktøy til å definere filtre på samme måte som man kan velge predefinerte filtre. Predefinerte filtre vil gi brukeren muligheten til å velge kriterier fra enkle valg. Dette kan for eksempel være nedtrekkslister eller glidebrytere. Grunnen for at man vil gi brukeren predefinerte filtre er at filtre kan være tidskrevende å lage selv. Noen filtre vil bli brukt mye og dermed gir predefinerte filtre bespart tid Sammensatte filtre Sammensatte filtre består av to eller flere enkle filtre som blir utført etter hverandre. Det som kommer ut av ett filter blir gitt som inndata til det neste. Dette kan være to eller flere predefinerte filtre eller en blanding mellom predefinerte filtre og brukerdefinerte filtre. Forutsetninger for dette er at filterene opererer på den samme spesifikasjonen og må ha et felles format Presentasjon av visninger Filtrering og presentasjon av visninger er sammenflettede prosesser. Visualisering av grafer kan gjøres ved automatiske utleggsalgoritmer. Mer informasjon om dette finnes i kapittel 8. Når man bruker filtre for å generere visniger fra en spesifikasjonen er det viktig å bevare den mentale modellen til brukeren. Å bevare den mentale modellen handler om at brukeren skal kunne kjenne seg igjen etter at en spesifikasjon har gått igjennom et filter. Den nye visningen bør gjenspeile det bildet brukeren har av opphavsspesifikasjonen. For at en bruker skal kunne kjenne seg igjen i en visning er det noen egenskaper som er viktige å ta vare på: 37

102 Forstudie Ortogonal anordning: Den ortogonale anordningen er ivaretatt hvis anordningen mellom noder i horisontal og vertikal retning er beholdt. Altså at de er plassert likt i forhold til hverandre i den nye visninger. Klynger: Å holde noder som var plassert nært i den orginale visningen nært i den nye visningen. Retthet av linjer: i den nye visningen. Å holde det som var rette i den orginale visningen rett Relativ størrelse av noder: De relative størrelsene på nodene i den nye visningen bør samsvare med størrelsene i den orginale visningen. 7.3 Eksisterende implementasjoner av filtering i graf En undersøkelse av eksisterende løsninger som bruker filter kan være viktig for å finne ut hvilken nytteverdi disse løsningene har. Hvordan løser de eksisterende løsningene filtrering av grafen og hvordan viser det oss hva som er viktig å fokusere på når man skal bruke ett filter. Dette er ting som er aktuelle å evaluere når man ser på eksisterende løsninger Evalueringskriterier ID Navn Vekting FLT1 Valgmuligheter 5 FLT2 Predefinerte eller brukerdefinerte 3 filtre FLT3 Determinisme 1 FLT4 Bevaring av den mentale modellen 4 FLT5 Forenkling 5 Tabell 7: Evalueringskriterier for filtrering 38

103 Forstudie Evalueringskriteriene som ble valgt er: FLT1 - Valgmuligheter: Tanken bak dette evalueringskriteriet er å se hvor viktig det er å la brukeren ha mange valgmuligheter. Hvilke valgmuligheter brukenen har i den aktuelle løsningen skal evalueres og i tillegg om disse valgmulighetene gir positive eller negative effekter. Her vil man også se på hvilke valgmuligheter som kunne vært nyttige. FLT2 - Predefinerte eller brukerdefinerte filtre: I dette kriteriet er tanken å se på hvordan brukeren kan velge hva som skal filtrere. Hvilke predefinerte filtere eksisterer det og om de er enkle i bruk. Man vil her også evaluere om løsningen gir brukeren muligheten til å lage brukerdefinerte filtre. Forskjellen på FLT2 og FLT1 er at i FLT1 evaluerer man hvilke valgmuligheter som er gitt, mens i FLT2 evaluerer man hvordan disse valgmulighetene er presentert. FLT2 kan knyttes opp mot EK10. FLT3 - Determinisme: visningene hver gang. Evaluere om de samme valg av kriterier gir den FLT4 - Bevaring av den mentale modellen: Som forklart tidligere er det viktig å la brukeren kjenne seg igjen i den nye visningen. Her skal det evalueres om egenskaper som ortogonal anordning, klynger, retthet av linjer og relativ størrelse er bevart og hvor viktig er det for løsningen at disse egenskapene er bevart. FLT4 kan knyttes opp mot EK10. FLT5 - Forenkling: I dette evalueringskriteriet vil det vurderes i hvor stor grad filteret forenkler grafen Evaluering av InFlow InFlow er en visualiseringskomponent som har mulighet for filtrering [15]. I denne løsningen kan man inkludere og utelukke kanter. Siden dette er fokuset for applikasjonen er det gitt mye valgmuligheter, hvor man enkelt kan inkludere og utelukke kanter etter behov. En annen mulighet er å kunne skjule alle noder som ikke har noen kanter inn eller ut til seg. Foruten dette er det 39

104 Forstudie få valgmuligheter. Nodene i denne løsningen skal representere forskjellige forretningsenheter som personer, team og prosjekt og kantene skal representere relasjoner eller flyt av informasjon mellom disse forretningsenhetene. Valgmuligheter som kunne vært nyttige er å kunne filtrere slik at man bare kunne se personene og bare se kantene som representerte flyt av informasjon. Brukeren kan velge hvilke kanter som skal vises ved å høyreklikke hver node. Disse predefinerte mulighetene gir på en enkel måte brukeren kontroll over hvilke kanter som skal vises til de forskjellige nodene. Det mangler muligheter for å spesifisere egne filtre. Løsningen oppfyller kravet om determinisme. Den mentale modellen ble godt bevart siden denne løsningen ikke omorganiserte grafen etter en filtrering, men bare skjulte kanter og noder som skulle filtreres vekk. Grafen som ble evaluert for denne løsningen hadde få noder og kanter som gjorde at visualiseringen kunne vise hele grafen. Når man skal visualisere større grafer vil det være nødvendig å gjøre et nytt grafutlegg for å samle informasjonen i den nye visningen. Denne løsningen er god på å filtrere vekk kanter og man kan helt klart se fordelene, hvis man ønsker å betrakte relasjonene mellom nodene. Ut over dette er det ikke forenklinger siden løsningen ikke gir andre valgmuligheter. I tabell 8 er evalueringen til InFlow oppsummert med karakterer. EvalueringsID: EV-FLT-1 Krit-ID Vekting Vurdering Karakter Verdi FLT1 5 Mange valgmuligheter for å inkludere og utelukke kanter, men lite andre valgmuligheter FLT2 3 God, men mangler brukerdefinerte filtre FLT3 1 Oppfylt 5 5 FLT4 4 Oppfylt, men denne løsningen kan skape problemer 3 12 FLT5 5 Forenkler det løsningen ønsker 3 15 å forenkle Sum 54 Tabell 8: Evaluering av InFlow 40

105 Forstudie Evaluering av TouchGraph GoogleBrowser TouchGraph 11 er en visualiseringskomponent som har mulighet for filtrering. Det filteret i denne løsningen fokuserer på er at en bruker er interessert i ulike noder i grafen. Ut fra den noden som velges kan man filtrere vekk unyttig informasjon. Den unyttige informasjonen kan for eksempel være noder som ikke har en kant direkte til den valgte noden eller noen av nabonodene. Utenom dette er det få valgmuligheter. Man kan velge ulike alternativer ut fra nedtrekksbokser. Det var vanskelig å kunne forutsi hva som ville skje når man valgte de ulike alternativene som viser hvor viktig det er å lage intuitive filtre der brukeren enkelt kan få fram ønsket visning. Det finnes ingen muligheter for brukerdefinerte filtre. Løsningen oppfyller kravet om determinisme. Retthet av linjer og relativ størrelse på noder er tatt vare på, men den ortogonale anordningen er ikke bevart. Man må derfor bruke tid for å kjenne seg igjen og dette viser viktigheten av bevaring av den mentale modellen. I uoversiktelige grafer hvor man ønsker å betrakte kun få noder fungerer filteret godt. Nodene i grafen som ble evaluert ligger over hverandre og det er mange kantkrysninger, noe som gjør at grafen blir forenklet kun når man velger få noder og kanter. I tabell 9 er evalueringen til TouchGraph GoogleBrowser oppsummert med karakterer. 7.4 Konklusjon I dette kapittelet har det kommet fram at man er avhengig av tilstrekkelige valgmuligheter i filtreringsomgivelsene for å kunne oppnå det ønskede detaljnivået på filtreringen. Dersom omgivelsene i applikasjonen ikke har muligheter for å vise informasjonen man ønsker, vil filtrering fort bli ubrukelig. Dette kom tydelig fram i avsnitt InFlow ble evaluert i avsnitt og hadde flere valgmuligheter. Allikevel var dette for få til at løsningen kunne gi et allsidig filter. Dette viser at man 11 TouchGraph er utviklet av Martin Spernau og er tilgjengelig fra 41

106 Forstudie må undersøke hvilke kriterier det er ønskelig at brukeren av en visualiseringskomponent skal kunne spesifisere. Uten en slik undersøkelse risikerer man å enten filtrere vekk ønskelig informasjon eller beholde uønsket informasjon. Det er ikke sikkert utviklerne av et system klarer å gi et predefinert filter for alle behov, og det er derfor ønskelig å gi brukerern en omgivelse for å egendefinere filtre. Omgivelsene for å velge predefinerte filtre og å definere egne filtre bør være mest mulig homogene. Evaluering i avsnitt viste viktigheten av å lage en brukervennlig måte å velge filtre på, siden det her var vansklig å få fram den ønskede visningen. Dette avsnittet viste også viktigheten av å bevare den mentale modellen slik at brukeren ikke behøver å bruke tid på å kjenne igjen grafen etter en filtrering. Det ble her også vist at å bruke et filter forenkler visualiseringen på det man ønsker å forenkle, bare brukeren blir gitt tilstrekkelige valgmuligheter. På bakgrunn av dette anbefales det at gruppen bruker tid på å gi brukeren gode omgivelser for filtrering. 42

107 Forstudie EvalueringsID: EV-FLT-2 Krit-ID Vekting Vurdering Karakter Verdi FLT1 5 Få valgmuligheter 1 5 FLT2 3 Lite intuitivt 1 3 FLT3 1 Oppfylt 5 5 FLT4 4 Den mentale modellen er dårlig bevart 2 8 FLT5 5 Lite forenklet 1 5 Sum 26 Tabell 9: Evaluering av TouchGraph GoogleBrowser 43

108 Forstudie 8 Graflayout Dette kapittelet omhandler representasjoner av og utlegg for grafer, samt tilgjengelige programbiblioteker som støtter utlegg, filtrering og visualisering av grafer. I henhold til figur 8 vil dette kapittelet se på løsninger for boks C og E. Det vil også vise seg at én mulig løsning innebærer et alternativ for boks B i tillegg. Forskjellige representasjoner av grafer og utleggsalgoritmer 12 vil vurderes. Deretter vurderes de tilgjengelige bibliotekene ut fra de best egnede representasjonene og utleggsalgoritmene, før endelig representasjon, algoritme og bibliotek velges. 8.1 Grafer Begrepet graf brukes i denne sammenhengen som betegnelse på et sett med punkter eller noder forbundet med kanter. En kant forbinder maksimalt to unike noder, og kan være rettet eller urettet. Kanter og noder kan også være vektet. Figurene 9 og 10 viser eksempler på ulike typer grafer. Figur 9: Urettet graf 12 En utleggsalgoritme er en metode for å legge ut grafer ut fra diverse kriterier. 44

109 Forstudie Figur 10: Rettet graf med vekter på kantene 8.2 Representasjoner av grafer Grafer kan representeres på mange måter, for eksempel som et grafisk bilde av punkter forbundet med streker, som en matrise eller i en eller annen tekstlig form. Måten man representerer en graf på påvirker systemet som grafen er en del av. Grafrepresentasjonen avgjør også hvilke verktøy som kan brukes, og indirekte hvordan strukturen i programmet blir. Det er derfor viktig å vurdere hvilken representasjon som er best egnet Evalueringskriterier For de tekstlige representasjonene er de nedenforstående kriteriene relevante. GR1 - Mulighet for konvertering fra OWL: Det bør være mulig å konvertere direkte fra OWL til formatet uten å miste for mye informasjon. GR2 - Ressurskrav (maskinkraft og lagringsplass): Representasjoner har varierende ressurskrav, som kan gi varierende betingelser avhengig av for eksempel størrelse på grafen. Ressurskravene påvirker blant annet responstid (se EK3 i de overordnede kravene). Det er derfor viktig at en grafrepresentasjon bruker minst mulig plass og prosessorkraft

110 Forstudie GR3 - Kompletthet i forhold til OWL: Det er viktig å kunne gi en representasjon som inneholder mest mulig komplett representasjon av det man skal visualisere. Ved å sikre en mest mulig komplett representasjon slipper man å operere med for mange datakilder, og man oppnår en enhetlig struktur. Evalueringskriteriene er gitt vekting og listet opp i tabell 10. ID Navn Vekting GR1 Mulighet for konvertering fra OWL 5 GR2 Ressurskrav (maskinkraft og lagringsplass) 3 GR3 Kompletthet i forhold til OWL 4 Tabell 10: Evalueringskriterier for grafrepresentasjoner Matematiske representasjoner De vanligste matematiske representasjonene av en graf er relativt like, og mye brukt i forbindelse med algoritmiske behandlinger av grafer, beregning av ulike resultater ut fra grafer eller som interne representasjoner i et program som behandler grafer. Nabomatrisen er en n n-matrise, der n er antall punkter eller noder i grafen. Elementene i matrisen kan for eksempel settes til 1 eller 0 for å beskrive om nodene er forbundet med en kant eller ikke. Et eksempel på en nabomatrise er vist i figur Figur 11: Nabomatrise-representasjon av en graf 46

111 Forstudie Nabolisten er en lignende representasjon som representerer grafen som en liste av kanter. Hver kant representeres som en 2-tuppel med nodene den kobler sammen. De to elementene i tuplen kan være en og samme node. Figur 12 viser et eksempel på en graf representert som en naboliste. Figur 12: Naboliste-representasjon av en graf Evalueringen av de matematiske representasjonene er vist i tabell 11. EvalueringsID: EV-GR-1 Krit-ID Vekting Vurdering Karakter Verdi GR1 5 Fins ikke, og er heller ikke egnet 0 0 GR2 3 Veldig små ressurskrav 5 15 GR3 4 Kan kun representere selve 1 4 grafen veldig begrenset Sum 19 Tabell 11: Evaluering av matematiske representasjoner GraphML GraphML er et språk for beskrivelse og spesifikasjon av grafer [3]. Det er basert på XML, og har støtte for rettede, urettede og blandede 13 grafer, hierarkiske grafer, grafiske representasjoner, referanser til eksterne data og integrering av applikasjons-spesifikke data. De viktigste elementene i GraphML er <graph>, <node> og <edge>. I tillegg kan ulike noder tilegnes attributter ved hjelp av <key>-elementet. Et eksempel på en graf skrevet i GraphML er vist i figur Blandede grafer har både rettede og urettede kanter. 47

112 Forstudie Figur 13: GraphML-representasjon av en graf Eksemplet over viser den samme grafen som nabomatrisen i figur 11. GraphML har den fordelen at man kan tilegne data til elementene i en graf ved hjelp av tagen <data>. Dette åpner for lagring av data og egenskaper ved grafen i selve representasjonen av den. GraphML er altså mer verbalt og ikke så godt egnet for matematiske beregninger som nabomatrisen er. Til gjengjeld er GraphML XML-basert, noe som kan åpne for en relativt enkel konvertering fra OWL til GraphML ved hjelp av extendable Stylesheet Language (XSL) 14. Et bibliotek som muliggjør denne konverteringen er evaluert i avsnitt Evalueringen av GraphML er vist i tabell The Graph Modelling Language (GML) GML er, i likhet med GraphML, et språk for beskrivelse av grafer. Det er utviklet av ved institutt for teoretisk informasjonsvitenskap ved fakultet for matematikk og informasjonsteknologi på universitetet i Passa. GML har en egen syntaks, men bruker de samme konseptene som GraphML, altså noder 14 XSL er et rammeverk for konvertering mellom ulike XML-formater. Mer om XSL finnes på [6]. 48

113 Forstudie EvalueringsID: EV-GR-2 Krit-ID Vekting Vurdering Karakter Verdi GR1 5 Mulig å konvertere ved hjelp av XSL GR2 3 Krever mye lagringsplass, og en del prosesseringskraft GR3 4 Krever ingen tilleggslagring 5 20 Sum 48 Tabell 12: Evaluering av GraphML og kanter. GML har mulighet for å tilegne enkelte forhåndsdefinerte attributter til elementene i grafen for å beskrive dens grafiske representasjon. Disse attributtene heter graphics, line og point. Point-attributten inneholder attributtene x og y (og alternativt også z). Line-attributten inneholder to point-attributter. Graphics-attributten beskriver bare en vilkårlig grafisk figur som ikke trenger å ha noe med selve grafen å gjøre. GML støtter også merking av grafer ved hjelp av nøkkelordet label. I tillegg kan man definere hva som er sentrum av et objekt ved hjelp av nøkkelordet center, som inneholder x, y og alternativt også z. Et eksempel på en graf skrevet i GML er vist i figur 14. GML er som GraphML også verbalt, men mangler GraphMLs fleksible rammeverk for å tilegne data eller egenskaper til elementer i grafer. Til gjengjeld har det innebygd en del nyttige attributter som er velegnede for bruk i forbindelse med utleggsalgoritmer, blant annet mulighetene for å beskrive punkter og linjer. I tillegg er muligheten for å beskrive sentrum av et objekt nyttig for algoritmer som baserer seg på fysiske ligninger, da denne kan brukes til å simulere et tyngdepunkt eller massesenter. Evalueringen av GML er vist i tabell Konvertering mellom OWL og GraphML Som nevnt i avsnitt 8.2.3, er det mulig å konvertere mellom OWL og GraphML ved hjelp av XSL. Denne muligheten for konvertering kan gjøre det langt lettere å lage en grafrepresentasjon. Med en tolker som Jena (se avsnitt vil man måtte konvertere fra en objektstruktur til enten GraphML eller en 49

114 Forstudie Figur 14: GML-representasjon av en graf EvalueringsID: EV-GR-3 Krit-ID Vekting Vurdering Karakter Verdi GR1 5 Fins ingenting ferdig, men burde være mulig 2 10 GR2 3 Krever en del lagringsplass 3 9 GR3 4 Noe støtte for beskrivelse, 2 8 men krever mye tilleggslagring Sum 27 Tabell 13: Evaluering av GML 50

115 Forstudie objektstruktur som kan leses av biblioteket for grafvisualisering. Ved å konvertere direkte til et format som sistnevnte bibliotek kan lese, vil man sannsynligvis spare en del utviklingstid og muligens også lette kravene til maskinkraft. En slik løsning vil innføre en ny boks i figur 8, som erstatter tolkeren. I kapittel 11 kan figuren med en slik erstatning sees. Xalan er et bibliotek implementert i Java som konverterer mellom XMLformater og andre formater ved hjelp av XSL, og dette skal evalueres i dette avsnittet Evalueringskriterier Følgende kriterier er viktige for konverteringsbibliotek: GK1 - Godt definerte grensesnitt: Biblioteket må ha et godt og klart definert grensesnitt som gjør det enkelt å benytte seg av det (se EK5 i de overordnede kriteriene). GK2 - Lisensbetingelser: Lisensen som biblioteket distributeres under må legge færrest mulig føringer for at man skal kunne benytte seg av det (se EK10 i de overordnede kriteriene). Evalueringskriteriene er vektet og oppsummert i tabell 14. ID Navn Vekting GK1 Godt definerte grensesnitt 4 GK2 Lisensbetingelser 4 Tabell 14: Evalueringskriterier for konverteringbibliotek Xalan Xalan 15 er et bibliotek for prosessering av XSL, som brukes til å konvertere et XML-format til et annet format. Xalan er mye brukt, og anses for å være 15 Xalan er utviklet av Apache Software Foundation og er tilgjengelig fra 51

116 Forstudie stabilt. Det har et godt definert grensesnitt og god dokumentasjon. Biblioteket er lisensiert under Apache Software Licence, som tillater fri bruk av biblioteket [8]. Evalueringen av Xalan er oppsummert i tabell 15. EvalueringsID: EV-GK-1 Krit-ID Vekting Vurdering Karakter Verdi GK1 4 Grensesnittet er godt definert og dokumentert GK2 4 Lisensen tillater fri bruk Sum 40 Tabell 15: Evaluering av Xalan 8.4 Algoritmer for grafutlegg Grafutlegg dreier seg om algoritmer som analyserer grafer og gir ut koordinater for hver node i grafen, og en kurve for hver kant slik at endepunktene i kanten er noder. De fleste grafalgoritmene behandler kantene og nodene i grafen, men noen kan også ta hensyn til en eller annen form for semantisk beskrivelse av grafen, for eksempel hvilken node som skal anses som rotnoden i et tre. Felles for alle algoritmene er at de på en eller annen måte forsøker å ta hensyn til følgende kriterier: Antall kryssende kanter Arealet grafen dekker Symmetri i grafen Bøyninger i kantene Disse kriteriene anses for å være et representativt utvalg av de kriteriene mennesker ubevisst bruker for å måle kvaliteten av den visuelle framstillingen av en graf. Problemet med disse kriteriene er at flere av de er NP-komplette. Som et eksempel tar det O(n) tid å sjekke om en graf er planar 16, mens det 16 En planar graf har ingen kryssende kanter. 52

117 Forstudie å minimere antall kryssende kanter er et NP-komplett problem [14]. Målene er også tildels gjensidig utelukkende. I mange tilfeller er det ikke mulig å optimere en graf med hensyn på både symmetri og færrest mulig kryssende kanter. Siden kjøretiden fort eskalerer for de fleste algoritmene, nøyer de seg gjerne med å finne et lokalt optimum i løsningsrommet i stedet for den optimale løsningen. De eksisterende algoritmene for grafutlegg kan deles inn i 3 hovedgrupper: Kraftrettede grafutlegg Hierarkisk grafutlegg Ortogonale grafutlegg Det neste avsnittet angir evalueringskriteriene for de ulike utleggsalgoritmene. Avsnittene deretter tar for seg hver av disse hovedgruppene og evaluerer de vanligste algoritmene innenfor disse gruppene i henhold til kriteriene Evalueringskriterier Følgende kriterier er viktige for valg av utleggsalgoritme: GA1 - Graftyper algoritmen kan visualisere: Siden ontologigrafer er uplanare, urettede grafer, må algoritmen som velges støtte denne typen. GA2 - Kjøretiden til algoritmen: Dersom algoritmen har for lang kjøretid, vil den ikke kunne brukes i en visualiseringskomponent, da responstiden vil bli for lang(ek3). Kjøretiden er derfor aktuell i evalueringen. GA3 - Anvendelighet for ontologivisualisering: Selv om algoritmen støtter typen grafer som ontologigrafer er et subsett av, er det ikke sikkert den er godt egnet til visualisering av ontologier. Ontologier har gjerne relasjoner som har ulik grad av tilknytning til hverandre, og de mest nært beslektede ontologiene bør komme tett sammen (EK9). Evalueringskriteriene er gitt vekting og listet opp i tabell

118 Forstudie ID Navn Vekting Graftyper algoritmen kan visualisere 4 GA1 Kjøretiden til algoritmen 3 GA2 Anvendelighet for ontologivisualisering 5 GA3 Tabell 16: Evalueringskriterier for utleggsalgoritmer Kraftrettede grafutlegg Kraftrettede grafutlegg bruker en energifunksjon 17 på alle kanter i grafen, og minimerer så denne funksjonen for å oppnå størst mulig harmoni i systemet. Slike algoritmer baserer seg på de fysiske lover og ligninger som finnes for fjærer og svingninger. Kraftrettede grafutlegg forsøker blant annet å minimere antall kryssende kanter, noe som er et NP-komplett problem. De har derfor generelt ikke god kjøretid, men flere av dem inneholder gode løsninger for å få kjøretiden ned på et akseptabelt nivå. Spring embedder Spring Embedder er en standard algoritme for kraftrettet utlegg [14]. Den erstatter alle kantene med fjærer og nodene med massepunkter, og prøver så å minimalisere energifunksjonen til systemet. Man kan velge hvor mange iterasjoner som skal utføres, altså hvor mange lokale minimum man skal forsøke å finne. Til slutt velger algoritmen det beste minimum og legger ut grafen i henhold til det. Siden Spring embedder støtter alle typer grafer, er den godt egnet til å legge ut ontologigrafer. Man ser også av eksempelfiguren at utlegget blir ryddig, men det kan bli noe trangt om plassen med tilstrekkelig mange ontologier. Dette er imidlertid et problem alle utleggsalgoritmer vil måtte slite med. En graf lagt ut med Spring embedder er vist i figur 15. Evalueringen av Spring embedder er vist i tabell En energifunksjon er en matematisk ligning som uttrykker summen av potensiell og kinetisk energi i en gjenstand som en funksjon av tiden. 54

119 Forstudie Figur 15: Graf lagt ut med Spring embedder-algoritmen EvalueringsID: EV-GA-1 Krit-ID Vekting Vurdering Karakter Verdi GA1 4 Støtter alle typer grafer GA2 3 Behandler NP-komplette problemer, varierer med størrelse på inndata. 1 3 GA3 5 Godt egnet for ontologivisualisering Sum 43 Tabell 17: Evaluering av Spring embedder 55

120 Forstudie Simulated annealing Simulated annealing baserer seg på idéen om å simulere det som skjer når en varmer opp metall og så kjøler det ned [11]. Når metallet er nedkjølt etter en oppvarming har det funnet sin minimale energifunksjon. Algoritmen tar inn en starttemperatur. Denne er vanligvis et høyt tall. Temperaturen reduseres med én grad for hver iterasjon algoritmen kjører, og algoritmen terminerer når temperaturen har nådd null grader. Algoritmen er NP-komplett, og finner dermed ikke nødvendigvis den optimale løsningen. For å begrense tiden det tar å kjøre Simulated annealing på en graf pleier man å legge til en sannsynlighetsfunksjon for å evaluere kvaliteten på resultatet av hver iterasjon. Dersom resultatet havner innenfor den godkjente delen av sannsynlighetsfunksjonen, terminerer algoritmen. Simulated annealing støtter i likhet med Spring embedder alle typer grafer, noe som gjør den godt egnet for ontologivisualisering. Den har imidlertid også det samme problemet som Spring embedder, nemlig estetikk i forhold til størrelse. Evalueringen av Simulated annealing er vist i tabell 18. EvalueringsID: EV-GA-2 Krit-ID Vekting Vurdering Karakter Verdi GA1 4 Støtter alle typer grafer 5 20 GA2 3 Behandler NP-komplette problemer, kjøretid varierer med inndata, men kan begrenses av sannsynlighetsfunksjoner 2 6 GA3 5 Godt egnet 4 20 Sum 46 Tabell 18: Evaluering av Simulated annealing Kamada-Kawai Kamada-Kawai baserer seg i likhet med Spring embedder på fjærkrefter, men den forsøker å tilegne fjærlengden slik at kantene i grafen får en lengde mest mulig lik deres grafteoretiske lengde, altså den lengden man forventer at de skal ha i grafen. For å oppnå dette settes fjærlengden lik den initielle lengden 56

121 Forstudie til kanten. Nodene plasseres tilfeldig. Algoritmen itererer så et gitt antall ganger før den terminerer. I likhet med de to foregående algoritmene kan også Kamada-Kawai vise alle typer grafer. Den lider imidlertid også av de samme svakhetene i forhold til antall noder i grafen som de to andre [14]. Evalueringen av Kamada-Kawai er vist i tabell 19. EvalueringsID: EV-GA-3 Krit-ID Vekting Vurdering Karakter Verdi GA1 4 Kan visualisere alle typer grafer GA2 3 Behandler NP-komplette problem, kjøretid varierer med størrelsen på inndata GA3 5 Godt egnet for ontologier 4 20 Sum 43 Tabell 19: Evaluering av Kamada-Kawai Hierarkisk utlegg Siden grafene som skal behandles i dette tilfellet ikke er hierarkiske, er ikke de eksisterende algoritmene for hierarkisk utlegg aktuelle. Det er derfor ikke lagt vekt på slike algoritmer i evalueringen Ortogonalt utlegg Et ortogonalt utlegg er et utlegg som bare inneholder horisontale og vertikale kanter. En kant kan også ha 90-graders vinkler. Hovedformålet med utlegget er, i tillegg til å skape en oversiktlig graf, å minimere antall kryssende kanter og arealet grafen benytter. Ortogonale utlegg er svært aktuelle ved for eksempel konstruksjon av PCBer PCB står for Printed Circuit Board, som er en type kretskort. 57

122 Forstudie GIOTTO GIOTTO bruker to steg for å lage et ortogonalt utlegg: 1. Gjør grafen planar 2. Minimér antall bøyde kanter GIOTTO-algoritmen er visualisert i figur 16. Algoritmen har en kjøretid på Figur 16: GIOTTO-algoritmen O((N + C) 2 logn), der N er antall noder i grafen og C er antall kanter [14]. Den er med andre ord en rask algoritme sett i forhold til de kraftrettede utleggsalgoritmene. GIOTTO forsøker å optimalisere topologien og kantformen i grafen, men den er dårlig til å tilpasse seg andre betingelser. For eksempel 58

123 Forstudie kan man ikke angi betingelser om kantlengde eller posisjon på noder og/eller kanter. Evalueringen av GIOTTO er vist i tabell 20. EvalueringsID: EV-GA-3 Krit-ID Vekting Vurdering Karakter Verdi GA1 4 Støtter kun planare grafer 2 8 GA2 3 Relativt god kjøretid 4 12 GA3 5 Uegnet, ontologigrafer er 1 5 sjelden planare Sum 25 Tabell 20: Evaluering av GIOTTO Konklusjon Siden ontologigrafer er generelle uplanare grafer, må man velge en form for kraftrettede utlegg, da disse er de eneste utleggsalgoritmene som støtter denne typen grafer. Det er imidlertid for tidlig å velge en av de kraftrettede utleggsalgoritmene på dette stadiet, da det stort sett er estetiske kriterier som avgjør hvilken av de som er den beste. Man bør derfor teste flest mulig av algoritmene før man velger en av dem. 8.5 Tilgjengelige grafbibliotek Det finnes flere implementasjoner av grafbibliotek for Java, med støtte for ulike representasjoner og ulike utleggsalgoritmer. For prosjektets del er det viktig å finne bibliotek som i størst mulig grad støtter de komponenter det er behov for i visualiseringskomponenten Evalueringskriterier Følgende evalueringskriterier er viktige for de tilgjengelige grafbibliotekene: 59

124 Forstudie GB1 - Støtte for utleggsalgoritmer: mulig av de aktuelle utleggsalgoritmene. Grafbiblioteket bør støtte flest GB2 - Støtte for aktuelle grafrepresentasjoner: støtte flest mulig av de aktuelle grafrepresentasjonene. Grafbiblioteket bør GB3 - Støtte for filtrering filtrering. Grafbiblioteket bør ha innebygd støtte for GB4 - Utbyggbarhet: For de aspektene ved behandling av grafer der det kreves funksjonalitet som grafbiblioteket ikke støtter, bør grafbiblioteket være enkelt å bygge ut gjennom godt definerte grensesnitt. Utbyggbarheten påvirker utviklingstiden (EK7), og kan også påvirke videreutviklingen og vedlikeholdsmuligheter(ek8). GB5 - Lisensbetingelser: Det må være mulig å videredistributere biblioteket. Det bør være mulig å inkludere det i annen software uten å måtte gi royalties til utviklere(ek10). GB6 - Stabilitet: Grafbiblioteket bør være velkjent og godt utprøvd. Det mest sentrale av funksjonalitet bør være bevist stabil(ek4). Evalueringskriteriene er gitt vekting og listet opp i tabell 21. ID Navn Vekting GB1 Støtte for utleggsalgoritmer 5 GB2 Støtte for aktuelle grafrepresentasjoner 5 GB3 Støtte for filtrering 5 GB4 Utbyggbarhet 4 GB5 Lisensbetingelser 4 GB6 Stabilitet 3 Tabell 21: Evalueringskriterier for grafbibliotek 60

125 Forstudie GraphViz GraphViz 19 er et mye brukt verktøy for tegning av grafer, som brukes av blant annet Doxygen 20 [7]. Det utvikler seg stadig, og anses for å være veldig stabilt. GraphViz støtter modifiserte versjoner av følgende algoritmer: Spring embedder (avsnitt 8.4.2). Kalles fdp i GraphViz. Kamada-Kawai (avsnitt 8.4.2). Kalles neato i GraphViz. GraphViz støtter også en mengde formater for utdata, for det meste bilder og vektorbilder. Det støtter ingen av de nevnte representasjonene i avsnitt 8.2, men har et eget enkelt tekstformat. GraphViz støtter ikke filtrering, men har et strømorientert design 21 som gjør det veldig enkelt å koble til filtre til utdataene som gir grunnlag for visualisering. Evalueringen av GraphViz er vist i tabell Java Universal Network/Graph Framework Java Universal Network/Graph Framework (JUNG) 22 er et stort bibliotek for arbeid med grafer i Java, utviklet av Scott White, Joshua O Madadhain, Danyel Fisher og Yan-Biao Boey. Det har fokus på utlegg og visualisering, og implementerer følgende utleggsalgoritmer: Spring embedder Kamada-Kawai 19 GraphViz er utviklet av AT&T Labs-Research og er tilgjengelig fra 20 Doxygen er et mye brukt verktøy for dokumentering av kildekode i bl.a Java og C++ 21 Strømmer er i denne forbindelse datastrømmer, altså sekvensielle rekker av bytes. Design med strømmer som man kan lese fra og skrive til gjør det ryddig og enkelt å koble sammen komponenter i sekvens eller parallell og prosessere data med ulike komponenter til man oppnår de utdata man vil ha. 22 JUNG er et utviklingsprosjekt tilgjengelig fra 61

126 Forstudie EvalueringsID: EV-GB-1 Krit-ID Vekting Vurdering Karakter Verdi GB1 5 Støtter to utleggsalgoritmer, i modifisert utgave. GB2 5 Støtter ingen av de aktuelle representasjonene. GB3 5 Støtter ikke filtrering, men er godt tilrettelagt for å kunne utvides med støtte for det. GB4 4 Relativt vanskelig å utvide med egne implementasjoner. GB5 4 AT&T-lisens [1]. Gir kostnadsfri bruksrett GB6 3 Veldig stabilt, brukes av 5 15 mange. Sum 60 Tabell 22: Evaluering av GraphViz JUNG støtter lesing av GraphML (avsnitt 8.2.3), og er dermed godt egnet for enkel innlesing av OWL-dokumenter. JUNG støtter også filtrering, og har implementert noen enkle filtreringsalgoritmer. Disse algoritmene er dog ikke dekkende for behovene kunden har, og det vil derfor måtte implementeres egne filteralgoritmer. Evalueringen av JUNG er vist i tabell JGraph JGraph er i likhet med JUNG (avsnitt 8.5.3) et bibliotek for arbeid med grafer i Java. APIet har ikke så mye fokus på utlegg som JUNG, men pakken JGraphAddons legger til støtte for en del utlegg. JGraph støtter følgende aktuelle utlegg, i tillegg til en del andre: Spring embedder Simulated annealing (avsnitt 8.4.2) 62

127 Forstudie EvalueringsID: EV-GB-2 Krit-ID Vekting Vurdering Karakter Verdi GB1 5 Støtter to av de aktuelle utleggsalgoritmene GB2 5 Støtter GraphML GB3 5 Støtter filtrering GB4 4 Har dokumenterte grensesnitt for utbygging. GB5 4 BSD-lisens [4]. Fri bruk hvis man krediterer prosjektet GB6 3 Relativt stabilt, har noen 3 9 problemer med Kamada- Kawai under visse betingelser. Sum 96 Tabell 23: Evaluering av JUNG I tillegg har JGraph klart definerte grensesnitt for å legge til andre utleggsalgoritmer. JGraph støtter ingen av representasjonene i avsnitt 8.2, men støtter GXL, som er veldig likt GraphML [13]. Det finnes metoder for å konvertere GraphML til GXL, og vise versa, ved hjelp av XSL [6]. JGraph støtter ikke filtrering, og ser heller ikke ut til å være klargjort for utbygging med filtre. Evalueringen av JGraph er vist i tabell yfiles yfiles 23 er nok et Java-bibliotek som støtter analyse, utlegg og visning av grafer. yfiles er et veldig modent bibliotek med støtte for en ulike utleggsalgoritmer. Av de aktuelle algoritmene støtter yfiles følgende: Spring embedder yfiles har støtte for lesing av GML (avsnitt 8.2.4). Biblioteket har ikke innebygd filterstøtte, men har greit dokumenterte grensesnitt for utbygging, og 23 yfiles er utviklet av yworks og er tilgjengelig fra 63

128 Forstudie EvalueringsID: EV-GB-3 Krit-ID Vekting Vurdering Karakter Verdi GB1 5 Støtter to av de aktuelle utleggsalgoritmene. GB2 5 Støtter GXL, som er veldig likt GraphML. Det er mulig å konvertere mellom disse språkene GB3 5 Støtter ikke filtrering. 0 0 GB4 4 Har noe dårlig dokumenterte grensesnitt for utbygging GB5 4 LGPL, tillater fri bruk [20] GB6 3 Anses som stabilt Sum 75 Tabell 24: Evaluering av JGraph støtter desuten en form for nøstede grafhierarkier som muligens kan anvendes som en form for filtrering. Evalueringen av yfiles er vist i tabell Konklusjon Det finnes ulike algoritmer for grafutlegg, og flere av disse ser ut til å være godt egnet for utlegg av ontologigrafer. Likevel er kriteriene som evaluerer det endelige utlegget for en stor del estetiske, og det er dermed vanskelig å kunne velge en endelig utleggsalgoritme på det nåværende tidspunkt. Det må rett og slett testes med de best egnede algoritmene for å kunne velge en endelig løsning. Av tilgjengelige bibliotek ønsker gruppen JUNG (avsnitt 8.5.3), som støtter to aktuelle utleggsalgoritmer, GraphML-representasjon og har gode lisensbetingelser. JUNG har også innebygd enkel filtreringsstøtte og er tilrettelagt for utvidelse med mer avanserte filtre. Siden JUNG ønskes som bibliotek, bør man bruke GraphML (se avsnitt 8.2.3) som grafrepresentasjon. Man bør vurdere å konvertere direkte fra OWL til 64

129 Forstudie EvalueringsID: EV-GB-4 Krit-ID Vekting Vurdering Karakter Verdi GB1 5 Støtter en av de aktuelle utleggsalgoritmene GB2 5 Støtter GML GB3 5 Støtter en form for filtrering GB4 4 Har dokumenterte grensesnitt for utbygging. GB5 4 Egen lisens [10]. 30-dagers gratis evaluering, deretter må man betale pr maskin GB6 3 Anses som stabilt Sum 67 Tabell 25: Evaluering av yfiles GraphML foran å lage en egen objektkonvertering mellom en OWL-tolker og JUNG, da dette vil spare utviklingstid og sannsynligvis også maskinkraft. Man bør teste algoritmene JUNG støtter (Spring embedder og Kamada- Kawai, se avsnitt og 8.4.2), og velge den som gir best visualisering av disse to. Dersom ingen gir tilfredsstillende resultat kan Simulated annealing implementeres og testes. 65

130 Forstudie 9 Java og grafikk Et av kravene til den endelige komponenten er at Java skal benyttes som utviklingsspråk, og gruppen har derfor valgt å vurdere ulike produkter som kan forbedre både utviklingsprosessen og det endelige produktet. Alle produktene som har blitt evaluert er knyttet til utviklingen av grafiske brukergrensesnitt i Java. I figur 8 i kapittel 3 hører hele dette kapittelet inn i boks F. Boks F.1 i den samme figuren dreier seg om grunnbiblioteker for GUI-utvikling. Java Foundation Classes/Swing(Swing) er et bibliotek som benyttes i stor grad for slik utvikling i Java. Det er dog andre alternativer å velge som grunnbibliotek, og gruppen har vurdert to av disse opp mot Swing. Etter dette følger en evaluering av hvordan brukergrensesnittet skal utvikles. Her er XML-definisjoner og fullstendige applikasjoner for utvikling av grafiske brukergrensesnitt to metoder som blir vurdert. Disse metodene går inn i boks F.2: tilleggsbibliotek i den overordnede figuren. Det siste elementet som blir vurdert er hvorvidt gruppen skal benytte eksterne biblioteker for å øke muligheten for at brukergrensesnittet får lav responstid. Begrunnelsen for hvorfor dette er nødvendig finnes i avsnitt 9.3. Disse bibliotekene hører også inn i boks F Biblioteker for grafiske brukergrensesnitt Swing er et bibliotek for å bygge grafiske brukergrensesnitt i Java. Dette biblioteket følger med standard-distribusjonen fra Sun 24, men det finnes også andre alternativer på markedet. I dette avsnittet vil Swing og to alternativer, Standard Widget Toolkit og Buoy, evalueres. Basert på denne evalueringen vil det blir foreslått ett bibliotek å bruke for videre utvikling Evalueringskriterier Under følger kriteriene som er lagt til grunn for evalueringen av de ulike bibliotekene. Disse er oppsummert i tabell Mer informasjon om Swing er å finne på websiden java.sun.com 66

131 Forstudie GUI1 - Fleksibilitet: Med fleksibilitet menes friheten man har ved bruk av APIet. Det er ønskelig at vinduselementene tilpasses operativsystemet det kjører på og er konfigurerbare. Dette vil påvirke EK10 GUI2 - Samhandling: Da et grafisk API ikke lever i sin egen verden, men er avhengig av å kunne samhandle med andre bibliotek, er dette noe som må tas hensyn til. Gode grensesnitt for utviklere er essensielt i denne sammenheng. Det er også ønskelig at bibliotekene enten dokumenterer å kunne enkelt samhandle med andre 3. parts biblioteker eller at biblioteket er så utbredt det fungerer som en standard for andre utviklere. GUI3 - Oversiktlig og fullstendig dokumentasjon: Dokumentasjon er viktig for alle bibliotek, og jo mer oversiktlig og fullstendig den er, jo lettere vil utviklingen mot APIet bli. GUI4 - Lisens: Det er ønskelig å benytte biblioteker som både er billige eller gratis i bruk og(ek11) og som legger få føringer for den endelige lisensen. GUI5 - Stabilitet: Stabilitet er et av de viktigste kravene til det endelige produktet (EK4) og er direkte avhengig av stabiliteten i underliggende biblioteker. Moden kodebase og stor brukergruppe brukes som indikasjoner på god stabilitet. GUI6 - Kompleksistet: Utviklingstiden forventes å øke dersom kompleksiteten til de brukte bibliotekene er høy. Da utviklingstid (EK7) har relativt lav vekting(2), blir vektingen tilsvarende lav for dette kriteriet. GUI7 - Plattformuavhengighet: vekting. Direkte knyttet til EK1 og med samme GUI8 - Ytelse: Ytelse er et viktig krav for systemet som helhet (EK7), og responstiden til GUIet vil påvirket dette, om enn ikke i så stor grad som metoder brukt for grafutlegg og filtrering. 67

132 Forstudie ID Navn Vekting GUI1 Fleksibilitet 3 GUI2 Samhandling 5 GUI3 Oversiktlig og fullstendig dokumentasjon 3 GUI4 Lisens 3 GUI5 Stabilitet 5 GUI6 Kompleksitet 2 GUI7 Plattformuavhengighet 5 GUI8 Ytelse 3 Tabell 26: Evalueringskriterier for API for grafiske brukergrensesnitt Swing Swing er et kraftig API, med store muligheter for tilpasninger. Det finnes ulike såkalte Look and Feels som tilpasser utseendet på hele Swingapplikasjonen til et nytt miljø. Utseender som i Windows XP, GTK+ eller Mac OS er eksempler på ulike Look and Feels. Det er også mulig å tilpasse applikasjonen slik at den har den lokale Look and Feel for OSet den kjøres på. Mulighetene for å lage nye Look and Feels er også tilstede, men er trolig uaktuelt for dette prosjektet. Når det gjelder andre deler av biblioteket er Swing også fleksibelt. Man er bundet opp når det gjelder hendelseshåndtering, men for andre aspekter av applikasjonen står en utvikler relativt fritt. Når det gjelder tråding støter man dog ofte på problemer. Grunnen til dette er at Swing-elementer kun kan bli oppdatert fra den originale Swing-tråden, og applikasjonsskrivere må derfor være påpasselige med å ikke belaste denne for mye. For en større diskusjon rundt dette, se avsnitt 9.3. Størrelsen på Swing er også noe som ofte kan føre til problemer. For mange av operasjonene man vil gjøre, som for eksempel å flytte et GUI-element, har man tilgang til en rekke ulike metoder i APIet. Dette gjør at utviklere ofte bruker unødvendig tid på å lete i dokumentasjonen etter riktig metodekall og det blir vanskelig for en større utviklingsgruppe å være enhetlig i bruk av Swing-metoder. Dette forverrer vedlikeholdsprosessen. 68

133 Forstudie Lisensen til Swing er uproblematisk. Den følger med som en del av Javadistribusjonen fra Sun og legger ingen føringer for applikasjoner som bruker biblioteket. Siden Swing er det klart mest brukte Java-APIet for GUI-utvikling i dag er stabiliteten fremragende. Det samme gjelder samhandling med andre biblioteker. De aller fleste Java-APIer som kan tenkes å kommunisere med et GUI er blitt skrevet med Swing i tankene. Ytelsen til Swing er ofte under kritikk. Grunnen til dette er at elementene ikke kjøres som OS-spesifikk kode, som for eksempel ved hjelp av C-biblioteker, men emuleres i Java. I tabell 27 er evalueringen til Swing oppsummert med karakterer. EvalueringsID: EV-GUI-1 Krit-ID Vekting Vurdering Karakter Verdi GUI1 3 Stor grad av frihet 4 12 GUI2 5 Kraftige grensesnitt og de facto standard for GUI GUI3 3 Fullstending, men størrelsen gjør den uoversiktlig GUI4 3 Helt åpen lisens 5 15 GUI5 5 Mange brukere, moden kodebase, mange utviklere GUI6 2 Unødig komplekst grensesnitt GUI7 5 Tilgjengelig på alle platformer som har moderne Javautgave GUI8 3 Mye emuleringer gir dårligere 2 6 ytelse Sum 119 Tabell 27: Evaluering av Swing 69

134 Forstudie Buoy Buoy 25 er et bibliotek som pakker inn 26 Swing. Dette gjøres for å hjelpe på kompleksitetsproblemene man har opplevd med Swing. Samtidig innfører Buoy en ny måte å håndtere hendelser på som gir utvikleren mer frihet. Buoy er i dag i versjon 1.2 etter omlag 1 1/2 år med utvikling, men da det kun er én utvikler på prosjektet anses stabiliteten ikke for å være like god som de andre alternavtivene. Kildekoden er public domain, noe som medfører at den kan benyttes fritt uten at noen restriksjoner legges. Dokumentasjon finnes i det vanlige JavaDoc-formatet og websiden til Buoy inneholder også en rekke tutorials for å komme raskt i gang. Alt i alt er dokumentasjonen meget god. Siden Buoy innfører et ekstra abstraksjonslag utenpå Swing har man noe svekket ytelse. Dette er dog så lite at det ikke har innvirkning på karakteren. Et problem med Buoy er at det er ingen dokumentasjon på hvor godt det vil samhandle med 3. parts biblioteker utviklet for Swing. Dette er et så stort problem at samhandlingen blir vurdert veldig lavt. I tabell 28 er evaluering oppsummert Standard Widget Toolkit Standard Widget Toolkit (SWT) er IBMs alternative bibliotek for GUIutvikling 27. Den mest kjente bruken av SWT er i utviklingsplattformen Eclipse, som er i vidstrakt bruk. Ellers like applikasjoner vil være raskere i SWT enn Swing på grunn av måten vinduselementene blir konstruert; direkte mot OS-lokale biblioteker i SWT og med Javakode i Swing. Fleksibiliteten er dog ikke like god som med Swing siden en utvikler er mer begrenset når det gjelder å bygge nye vinduselementer. Kompleksiteten til biblioteket er noe mindre. Lisensmessig er SWT som de andre kandidatene og kan benyttes fritt. Et 25 Buoy er utviklingsprosjekt tilgjengelig fra 26 Med innpakking i denne sammenheng menes at Buoy tilbyr samme funksjonelitet som Swing, men via et nytt grensesnitt 27 SWT er tilgjengelig fra 70

135 Forstudie EvalueringsID: EV-GUI-2 Krit-ID Vekting Vurdering Karakter Verdi GUI1 3 Noe begrenshet frihet, men fortsatt bra GUI2 5 Lite dokumentasjon om samhandling med andre GUI3 3 JavaDoc og tutorials tilgjengelig GUI4 3 Ingen føringer legges 5 15 GUI5 5 Swing i bunn med mange brukere, relativt moden kodebase 4 20 GUI6 2 Sterkt redusert kompleksitet 4 8 GUI7 5 Som for Swing 5 25 GUI8 3 Arver problemene fra Swing 2 6 Sum 108 Tabell 28: Evaluering av Buoy problem med at SWT kjøres ved hjelp av os-lokal kode er at man mister noe plattformuavhengighet. Dokumentasjonen til SWT er også noe mangelfull. Det er en fullstendig JavaDoc, men tutorials, bøker, og lignende er det lite av på markedet. Et uviklingsprosjekt må derfor forvente noe lengre oppstartstid for å lære seg biblioteket. Oppsummeringen av SWT-evalueringen er i tabell Forenklingsmetoder I dette avsnittet vil to metoder som påstås å forenkle utviklingen av grensesnitt skrevet med Swing bli vurdert. Den første av disse er å benytte et standard XML-format til å beskrive de grafiske komponentene for deretter å benytte en applikasjon til å generere skjelett-kode for de aktuelle klassene. Den andre metoden gruppen har sett på er grafiske editorer for å konstruere de samme brukergrensesnittene. Gruppens mål med å benytte slike hjelpemidler er todelt. For det første er det ønskelig å forkorte utviklingstiden, og for det andre ønsker man å sikre 71

136 Forstudie EvalueringsID: EV-GUI-3 Krit-ID Vekting Vurdering Karakter Verdi GUI1 3 Flere begrensninger lagt 2 6 GUI2 4 Krever spesielle biblioteker 3 12 GUI3 3 God JavaDoc, ellers manglende 3 9 GUI4 3 Fri bruk 5 15 GUI5 5 Mange brukere, brukes av Eclipse GUI6 2 Mindre komplekst enn Swing, men fortsatt relativt komplekst GUI7 5 Bra for de fleste plattformer, men problemer med enkelte mindre utbredte GUI8 3 Høy ytelse 5 18 Sum 106 Tabell 29: Evaluering av Standard Widget Toolkit seg at kildekoden er mest mulig homogent bygd opp. Evalueringskriteriene som er lagt til grunn, og hva som ligger i de ulike kriteriene er som følger under. I tabell 30 er disse oppsummert med vekting. De samme kriteriene er benyttet i avsnitt 9.3. GF1 - Fleksibilitet: Her vurderes det om uvikleren er bundet opp til spesifikke designstrategier. Dette gjelder både grafisk utseende og interne strategier for kildekode. GF2 - Kvalitet på generert kildekode: For dette kriteriet vil den genererte kildekoden analyseres, og det vil bli vurdert hvor lettlest den er for mennesker, hvor komplisert det er å benytte den sammen med andre bibliotek og hvor begrenset samhandlende kildekode blir når det gjelder valg av design- og implementasjonsstrategier. Stabiliteten til den genererte kildekoden vil også bli vurdert her. GF3 - Brukervennlighet: Her vil det bli vurdert hvor lett eller vanskelig hjelpemiddelet er å bruke. For å kunne få god nytte kreves det begrenset 72

137 Forstudie ID Navn Vekting GF1 Fleksibilitet 4 GF2 Kvalitet på generert kildekode 5 GF3 Brukervennlighet 1 GF4 Lisens 5 GF5 Stabilitet 2 Tabell 30: Evalueringskriterier for forenklingsmetoder for GUI-konstruksjon opplæringstid. God dokumentasjon vil virke positivt i denne evalueringen. For hjelpemidler er brukervennlighet mindre viktig, da det kun vil bli brukt av utviklere og ikke av sluttbrukere. GF4 - Lisens: Som for andre produkter som benyttes, er lisens viktig. Dette knyttes direkte opp mot EK11. Spesielt ønskelig at ekstrabibliotek ikke legger føringer for det endelige produktet eller er kostbare. GF5 - Stabilitet Dette går på stabiliteten til hjelpemiddelet, og kan dermed ikke knyttes opp mot EK4. Derimot vil det påvirke EK7 og EK XML for å beskrive GUI GUI-design er noe som med fordel kan overlates til andre enn programmerere, og å trekke beskrivelsen av det grafiske brukergrensesnittet ut av den vanlige kildekoden gjør det lettere for andre å utvikle denne delen. I dette forstudiet har gruppen sett på ett verktøy for dette; SwixML. Andre verktøy ble også vurdert, men forkastet tidlig i prosessen. Forkastningsårsaken var som regel umoden kodebase eller at utviklingen hadde stoppet på et tidlig tidspunkt. Krav om åpen kildekode har også ført til at produkter har blitt forkastet, da gruppen mener at dette ikke er en viktig nok del av det endelige produktet til å endre kreve endring i lisens. 73

138 Forstudie SwixML 28 har kun støtte for Swing, men har relativt moden kode og en moderat stor kundegruppe. Dokumentasjonen er i standard JavaDoc-format og også en tutorial-serie er tilgjengelig for å vise biblioteket i bruk. Brukervennligheten er lav med tanke på at XML-dokumentet må skrives for hånd, men den genererte kildekoden er av god kvalitet. Den er stabil, og har minimal overhead i forhold til å benytte Swing direkte. Lisensen til SwixML krever at biblioteket blir anerkjent i dokumentasjonen til den brukende applikasjonen. I tabell 31 er en oppsumeringen av evalueringen av SwixML. EvalueringsID: EV-GF-1 Krit-ID Vekting Vurdering Karakter Verdi GF1 4 Kan utnytte hele Swing. Bindes ikke opp til strategier 4 16 GF2 5 Bra generert kildekode 4 20 GF3 1 Må skrive XML for hånd 2 2 GF4 5 Uproblematisk lisens 4 20 GF5 2 Moden kildekode, middels 4 8 stor brukergruppe Sum 66 Tabell 31: Evaluering av SwixML GUI-design med grafiske hjelpemidler Det er en rekke GUI-editorer tilgjengelig på markedet, både kommersielle og gratis. Gruppen har valgt å ikke benytte seg av noen av disse. Begrunnelsen for dette er at det er en relativt liten del av den avsluttende komponenten som vil bestå av et på forhånd definert brukergrensesnitt. Brorparten av produktet som leveres fra dette prosjektet vil være utlegging av grafer, og enkelte dynamiske komponenter for å støtte dette. Det er prosjektgruppens mening at det ikke er nødvendig å benytte en egen editor for å designe et så begrenset brukergrensesnitt. 28 SwixML er utviklet av Wolf Paulus og er tilgjengelig fra 74

139 Forstudie 9.3 Tråding i Swing I motsetning til SWT tillater Swing at kun én tråd kommuniserer med GUIkomponentene 29. Ved tyngre og mer tidkrevende arbeidsoppgaver, som søk eller å opprette en grafstruktur, vil programmet som en helhet slutte å svare på brukerinnspill dersom GUI-tråden benyttes til dette. Ved slike situasjoner må man derfor innføre én eller flere nye tråder som tar seg av de tidkrevende oppgavene mens GUI-tråden kan fortsette å reagere på brukerinnspill. Det finnes flere ulike strategier for hvordan dette kan gjøres, og for å få et produkt som er bygd opp på en mest mulig enhetlig måte er det i dette avsnittet en evaluering av ulike produkter For Swing har Sun på sine internettsider en klasse kalt SwingWorker som forenkler bruken av flere tråder i Swing-applikasjoner. I tillegg til å se på denne klassen evalueres også Foxtrot og Spin, to komplette APIer som gjør det samme og mer Klassen SwingWorker SwingWorker 30 er en klasse utgitt fra Sun som lager nye tråder for hendelser skapt av brukergrensesnittet. Dette løser trådproblematikken beskrevet i avsnitt 9.3, men skaper samtidig nye problemer[5]. Det største av disse er at utførelsen ikke lenger er deterministisk. Et annet er at SwingWorker skalerer dårlig om applikasjonen får store mengder input fra brukerern gjennom GUIet. SwingWorker er nå i versjon 3, og flere tidligere feil har blitt rettet. I tabell 32 er det en oppsummering med vekting av evalueringen av SwingWorker Foxtrot Foxtrot 31 er et bibliotek som forenkler bruken av flere tråder i Swing-applikasjoner. Biblioteket er tilgjengelig med BSD-lisens. Denne har som eneste krav at 29 Det er kun synlige Swing-komponenter som ikke kan kommunisere med andre tråder, men i denne sammenheng vil problemene bli de samme. Tråden som må ta seg av denne kommuniksjonene er hendelsesavhentingstråden (Event Dispatching Thread) 30 SwingWorker er gratis tilgjengelig fra Sun Microsystems på 31 Foxtrot er utviklet av Simone Bordet og er tilgjengelig fra 75

140 Forstudie EvalueringsID: EV-GF-2 Krit-ID Vekting Vurdering Karakter Verdi GF1 4 Bundet opp til én strategi 2 8 GF2 5 Kildekoden er relativt uoversiktlig GF3 1 Lite grensesnitt, men må programmere mye selv GF4 5 Ingen lisens 5 25 GF5 2 Ingen problemer, men nylige 4 8 endringer Sum 59 Tabell 32: Evaluering av SwingWorker man inkluderer kopibeskyttelseinformasjonen for biblioteket i den ferdige applikasjonen[4]. Foxtrot inkluderer standard dokumentasjon i JavaDoc-format, men har ellers liten tilgjengelig dokumentasjon. Den store forskjellen på Foxtrot og Suns SwingWorker er at Foxtrot har en synkron modell. Tråden som starter håndteringen av en hendelse vil ikke returnere før hele hendelsenn er ferdig håndtert. Dette vil løse problemene med ikke-determinisme som SwingWorker har. Foxtrot tilbyr også et grensesnitt som gjør utviklingen lettere. Evalueringen av Foxtrot er å finne i tabell 33. EvalueringsID: EV-GF-3 Krit-ID Vekting Vurdering Karakter Verdi GF1 4 Flere muligheter, men noe begrenset GF2 5 Lite kildekode som må skrives. Lett å ha oversikt GF3 1 Gode grensesnitt 4 4 GF4 5 BSD-lisens 5 25 GF5 2 Relativt mye brukt 4 8 Sum 69 Tabell 33: Evaluering av Foxtrot 76

141 Forstudie Spin Spin 32 er et bibliotek som bygger på Foxtrot. Det tilbyr den samme synkrone modellen, men har mer funksjonalitet enn Foxtrot. Spin gir utviklere valget om å også benytte asynkrone tilbakekall, og gjør unntakshåndteringen langt mer gjennomsiktig. Spin har LGPL-lisens, noe som gjør at biblioteket kan benyttes uten at den brukende applikasjonens kildekode må være åpen[20]. Dokumentasjonsmessig er også Spin relativt bra. Det er fullstendig dokumentasjon i JavaDoc-format og også en kortere innføring med kildekodeesempler. I tabell 34 finnes evalueringen av Spin. EvalueringsID: EV-GF-4 Krit-ID Vekting Vurdering Karakter Verdi GF1 4 Flere designmuligheter for utviklere GF2 5 Relativt lett å ha oversikt over kildekoden GF3 1 Noe komplekst, men gode grensesnitt GF4 5 Lisens som ønsket 5 25 GF5 2 Mye brukt. God stabilitet 4 8 Sum 71 Tabell 34: Evaluering av Spin 9.4 Konklusjon Gruppen har i dette kapittelet sett på en rekke verktøy for å få best mulig kvalitet i selve Java-utviklingen. Det første som ble vurdert var ulike APIer for det grafiske brukergrensesnittet. Her kom Swing best ut og gruppen vil benytte dette som grunnbibliotek. Hovedgrunnen til valget er at det er ønskelig å benytte andre hjelpebiblioteker, både for grafgenerering og hendelseshåndtering, og samhandlingen med Swing vil føre til færre komplikasjoner 32 Spin er et utviklingsprosjekt under ledelse av Sven Meier og er tilgjengelig fra 77

142 Forstudie enn med de andre bibliotekene. Grunnet kompleksiteten på grensesnittene til Swing, må gruppen være oppmerksom på dette under utviklingen. Da storparten av grafikken i den endelige komponenten vil være grafene, noe som ligger utenfor dette delkapittelet, vil det være mindre behov for å benytte hjelpemidler for å konstruere brukergrensesnittet. Gruppen ønsker ikke å benytte slike hjelpemidler. Det vil være lite plassering av komponenter i GUIet, og større vekt på menyer og hendelseshåndtering. Derfor anbefales det at det blir tatt i bruk et bibliotek for å sikre effektiv trådhåndtering. Gruppen ønsker å benytte biblioteket Spin. 78

143 Forstudie 10 Eksisterende visualiseringsverktøy Her er en liste over eksisterende løsninger for visualisering av ontologier. Disse er interessante fordi de gir gode ideer om hvordan man kan lage visualiseringskomponenten Evalueringskriterier Ut i fra de overordnede kriteriene (se kapittel 5) har gruppen kommet fram til en del kriterier som finnes i tabell 35. VIS1 - Brukervenlighet: Med utseende menes det at verktøyet må være brukervennlig på en slik måte at man intuitivt forstår hva som menes med grafen. For å få dette til må grafen være enklest mulig uten å miste informasjon og kantene bør ikke krysse over noder. VIS2 - Representere flere typer relasjoner: Filtrering er viktig, da dette vil påvirke kompleksiteten av grafen. Hvis det er mulig å vise kun de relasjoner som er interessante vil dette kunne forenkle selve grafen. VIS3 - Navigering i grafen: Om man kan forstørre eller forminske grafen er viktig, da grafer med 1000 noder og 5000 relasjoner fort vil ta stor plass. Da trenger man god mulighet for navigering i grafen for at den skal være leselig. Et oversiktsvindu til å navigere i vil kunne gjøre dette enklere. VIS4 - Visualiserer ontologier: Om programmet viser en spesifikk eller generell ontologi er viktig, da en av kravene fra kunden er generelle ontologier. Spesielle ontologier kan være veldig gode innen et område, men vil gjøre det veldig dårlig i andre ontologier. Derfor trenger gruppen en generell ontologivisualiserer. 79

144 Forstudie ID Navn Vekting VIS1 Estetikk, utseende 4 VIS2 Representere flere typer relasjoner 4 VIS3 Navigering i grafen 3 VIS4 Visualiserer ontologier IsaViz Tabell 35: Evalueringskriterier for eksisterende løsninger IsaViz 33 er en visuell viser og redigerer av RDF-modeller i form av grafer. IsaViz gir oss et 2D-grensesnitt som gir muligheter for navigering i grafer, samt å kunne lage og redigere grafer ved å tegne disse manuelt. Med IsaViz kan man også importere grafer fra RDF/XML, Notation 3 og N-Tripple. I tillegg kan man eksportere grafer til RDF/XML, Notation 3 34, N-Tripple 35, Scalable Vector Graphics og Portable Network Graphics. IsaViz er implementert i Java og bruker GraphViz for grafutleggingen, for GraphViz (se avsnitt 8.5.2). Grafene i IsaViz har veldig fine buete kanter som er lette å følge med øyet. Nodene er tabeller, bilder eller firkanter. Kantene legger seg slik at de ikke krysser over noder, noe som gjør grafen oversiktlig og ryddig. Det er mulig å velge hvilke relasjoner som skal vises i grafen, og dette gjør at man kan filtrere vekk unødvendig informasjon. Man har imidlertid ikke mulighet til å velge en enkelt node og se kun den og de relasjonene som er knyttet til denne. Med navigering i graf menes det å kunne skalere grafen i tillegg til å flytte seg rundt i den. Til dette har IsaViz et oversiktsvindu som reflekterer grafen i hovedvinduet og viser et rektangel rundt det som vises i hovedvinduet. IsaViz er laget for å vise alle ontologier skrevet i RDF/XML. Et skjermbilde fra IsaViz er vist i figur 17. Evalueringen er oppsummert i tabell IsaViz er utviklet av Emmanuel Pietriga og er tilgjengelig fra 34 Notation 3 er lik RDF/XML-syntaks, men er enklere å lese, 35 N-Tripple er et tekstformat for å beskrive RDF-grafer. 80

145 Forstudie Figur 17: Skjermbilde fra IsaViz 10.3 Protégé Protégé 36 er et verktøy for å gi brukeren muligheter til å konstruere en domeneontologi. Programmet er en plattform som kan utvides med mange grafiske tilleggskomponenter for grafikk, tabeller, diagrammer og animasjon, for å gjøre det mulig å redigere og vise andre kunnskapsbaserte systemer Plugin: ezowl ezowl 37 er en tilleggskomponent for å visualisere ontologier i Protégé EzOWLs grafer har et fint og ryddig utseende, men en ting som trekker ned er at kantene går over nodene. Når det blir veldig mange kanter kan dette føre til at det vanskelig å lese grafen. Det er gode muligheter til å velge hvilke relasjoner som skal vises i ezowl. Dette gjør at overflødig informasjon kan velges vekk for å oppnå en renere graf. Det er også mulighet for å forstørre og 36 Protégé er utviklet ved Stanford University og er tilgjengelig fra 37 ezowl er utviklet ved Electronics and Telecommunications Research Institute i Korea og er tilgjengelig fra 81

146 Forstudie Figur 18: Skjermbilde 1 fra Protégé med ezowl-plugin forminske grafen, men det mangler et oversiktsvindu for å navigere i grafer som er større en skjermen. EzOWL viser generelle ontologier. Se figur 19, 18. Evalueringen er oppsummert i tabell FRODO RDFSViz Frodo RDFSViz 38 er et visualiseringsverktøy for ontologier representert i RDF-skjema. Denne bruker JAVA RDF API, Xerces XML parser og GraphViz fra AT&T og Lucent Bell Labs. Dette verktøyet lager grafer der klassene blir noder og subclassof blir kantene. Grafene til FRODO er fine, kantene svinger rundt noder og krysser hverandre minst mulig. Det mangler muligheter for å forstørre og forminske grafen siden den blir gitt ut som et gif-bilde. Man har heller ingen mulighet til å filtrere grafen da den er i bildeformat. Navigering blir dermed vanskelig. FRODO viser ikke generelle ontologier, og anbefaler andre verktøy for dette på hjemmesiden. Se figur 20. For evalueringen se tabell FRODO RDFSViz er utviklet ved German Research Center for Artificial Intelligence og er tilgjengelig fra 82

147 Forstudie Figur 19: Skjermbilde 2 fra Protégé med ezowl-plugin 10.5 Fractal Edge Fractal Edge er et firma som bruker fraktaler i sine gafer, noe som gir grafene et spesielt utseende. Et eksempel på en slik graf ser man i figur 21. Disse grafene har en tendens til å bli veldig uoversiktelige og lite brukervennlige i store ontologier, da man må forstørre veldig mye for å se laveste plan i ontologien. Siden Fractal Edge ikke er et visualiseringsprogram så er det heller ingen mulighet å navigere i grafen. Totalt kan man si at Fractal Edge er en alternativ måte å vise grafer på. Evalueringen av Fractal Edge er oppsummert i tabell Konklusjon Gruppen har i dette kapittelet sett på en rekke eksisterende verktøy for å visualisere ontologier. Dette er gjort for å få gode ideer til hva gruppen bør ha med i et slikt visualiseringsverktøy. Det ble vurdert hvordan grafene tar 83

148 Forstudie Figur 20: Skjermbilde fra FRODO RDFSViz seg ut og hvor store muligheter det er for å tilpasse grafene. Her kom IsaViz best ut, med ezowl-pluginen til Protégé rett etter. Begge programmene visualiserer grafer på en estetisk pen måte. Det ser ut til å hjelpe veldig med et oversiktsvindu som tilrettelegger for navigasjon i store grafer (se figur 17). Det bør bestrebes å unngå å få kryssende kanter i grafene, da dette lett kan lage veldig uoversiktlige grafer (se figur 18). 84

149 Forstudie Figur 21: Graf fra Fractal Edge EvalueringsID: EV-VIS-1 Krit-ID Vekting Vurdering Karakter Verdi VIS1 4 Grafen er fin og oversiktlig 4 16 VIS2 4 Det er noen muligheter til filtrering VIS3 3 Det er gode muligheter for å navigere i grafen VIS4 3 Generelle ontologier 5 15 Sum 59 Tabell 36: Evaluering av IsaViz 85

150 Forstudie EvalueringsID: EV-VIS-2 Krit-ID Vekting Vurdering Karakter Verdi VIS1 4 Grafene er fine, men man kan få kanter over nodene VIS2 4 Man kan filtrere grafen og velge hvilke relasjoner som skal vises VIS3 3 Kan forstørre og forminske grafer, mangler oversiktsboks for navigering i store grafer VIS4 3 Viser generelle ontologier 5 15 Sum 56 Tabell 37: Evaluering av Protégé med ezowl-plugin EvalueringsID: EV-VIS-3 Krit-ID Vekting Vurdering Karakter Verdi VIS1 4 Grafene er fine, nodene er firkanter eller tabeller og kantene buer fint 4 16 VIS2 4 Kan ikke filtrer grafen 1 4 VIS3 3 Få muligheter til å navigere i grafen 1 3 VIS4 3 Viser generelle ontologier 5 15 Sum 38 Tabell 38: Evaluering av FRODO RDFSViz EvalueringsID: EV-VIS-4 Krit-ID Vekting Vurdering Karakter Verdi VIS1 4 Grafene er fine, men hvis de er nøstet blir det veldig smått 3 12 VIS2 4 Kan ikke filtrer grafen 1 4 VIS3 3 Få muligheter til å navigere i grafen 1 3 VIS4 3 Viser generelle ontologier 5 15 Sum 34 Tabell 39: Evaluering av Fractal Edge 86

151 Forstudie 11 Valg av løsning I de foregående kapitlene har en rekke ulike produkter og teknikker blitt vurdert. I denne konklusjonen vil delkonklusjonene fra disse bli satt sammen for å foreta et valg av løsning. Det skal utvikles en komponent for visning av grafer. Denne komponenten skal ha et klart definert grensesnitt så det blir enkelt å bygge den inn i større applikasjoner. I tillegg skal det utvikles en mindre applikasjon som benytter seg av komponenten så man kan foreta brukbarhetstester. Dette vil også lette utviklingen av komponenten. Figur 22: Valg av komponenter for løsning Figur 8 i kapittel 3 viste hvilke deler visualiseringskomponenten skulle bestå av. Figur 22 er en modifisering av den samme figuren med gruppens valg av komponenter satt i sammenheng. For å oppnå en ønsket komponent ønsker gruppen å benytte biblioteket JUNG (avsnitt 8.5.3). Det er ønskelig å teste de to ulike algoritmene for 87

152 Forstudie grafutlegg som støttes av dette biblioteket og deretter, i samarbeid med DiB, velge den best egnede. Det må testes om løsningen med Xalan for å først oversette OWL til GraphML er god nok. Dersom dette ikke er tilfelle, vil gruppen benyttet biblioteket Jena (avsnitt 6.2.1) for å tolke OWL-filer. En løsning som benytter Jena, vil følge stien A-B-C i figur 22, mens en løsning som oversetter til GraphML vil følge A-G-C. I tillegg vil gruppen benytte seg av biblioteket Spin (avsnitt 9.3.3) for å sikre god håndtering av tråder. Gruppen ønsker ikke å benytte hjelpemidler til å konstruere det grafiske brukergrensesnittet. Gruppen vil benytte seg av idéer fra programmet IsaViz når det gjelder navigering i grafer. Dette gjelder spesielt et oversiktsvindu som forenkler navigering i komplekse ontologier. 88

153 Forstudie Referanser [1] AT&T. At&t graphviz source code agreement, [2] Tim Berners-Lee. The semantic web and research challenges, [3] Ulrik Brandes, Markus Eiglsperger, and Jürgen Lerner. Graphml primer, [4] Berkeley Software Distribution (BSD). The bsd license, [5] Yexin Chen. Customize swingworker to improve swing guis, [6] World Wide Web Consortium. Xsl, [7] John Ellson and Stephen North. Graphviz, [8] Apache Software Foundation. Apache license version 2.0, [9] The International DOI Foundation. The digital object identifier system handbook, [10] yworks GmbH. yfiles license types, [11] Martin Graesén. Developing layout algorithms for a graph visualisation framework, [12] Tom Gruber. What is an ontology?, [13] Ric Holt, Andy Schürr, Susan Elliot Sim, and Andreas Winter. Gxl: A graph-based standard exchange format for reengineering, [14] Roberto Tamassia Isabel F. Cruz. Graph drawing tutorial, [15] Valdis Krebs. Interactive organizational model, [16] Deborah L. McGuinness and Frank van Harmelen. Owl web ontology language overview, [17] Anne Helga Seltveit. Complexity reduction in information systems modelling, [18] Michael K. Smith, Chris Welty, and Deborah L. McGuinness. Owl web ontology language guide, [19] GNU (GNU s Not Unix). The gnu general public licence, [20] GNU (GNU s Not Unix). The gnu lesser general public licence,

154 Ontologidrevet dokumentforvaltning Kravspesifikasjon TDT4290 Kundestyrt prosjekt Institutt fra datateknikk og informasjonsvitenskap Fakultet for informasjonsteknologi, matematikk og elektroteknikk Norges teknisk-naturvitenskapelige universitet Gruppe 14 Espen Hansen Ole-Marius Moe-Helgesen Geir Storli Karl Hatteland Steinar Skjerven Håvard Stranden

155

156 Kravspesifikasjon Innhold 1 Innledning Formål Definisjoner Oversikt Overordnet beskrivelse Produktperspektiv Brukergrensesnitt OWL-grensesnitt Integrasjonsgrensesnitt Produktfunksjon Brukerkarakteristikk Avanserte brukere Enkle brukere Restriksjoner Funksjonelle krav Oppsummering Brukergrensesnitt Håndtering av OWL Navigasjon og skalering Søking Filtrering av graf Begrepshåndtering Filbehandling

157 Kravspesifikasjon 3.9 Integrasjonsgrensesnitt Use case Tolking av en OWL-fil Søking med fritekst i grafen som ligger i hovedvindu Oversiktsbildet Grafgenerering av begreper i en utvalgsliste Skjuling av begrep Ekspandering av symbol Velging av underbegrep til et markert begrep Visning av individer for et markert begrep Visning og utvelging av informasjon om markert begrep Lagring og åpning av en sesjon Egendefinerte filtre Mottak av begreper, relasjoner og tilleggsattributter Use case-estimering Ikke-funksjonelle krav Generelle krav Brukergrensesnitt Kapasitet og ytelse Dokumentasjon Konstruksjon og implementasjon Vekting og inkrementinndeling Første inkrement Andre inkrement

158 Kravspesifikasjon 6.4 Tredje inkrement Referanser 75 4

159 Kravspesifikasjon Tabeller 1 OWL Lite-egenskaper som er relevante for prosjektet OWL Lite-egenskaper som er ikke relevante for prosjektet Forretningsmessige krav Oppsummeringstabell for funksjonelle krav FK-BG1: Ontologi som graf FK-BG2: Manipulering av støttevinduer FK-BG3: Relasjoner FK-BG4: Navn på noder FK-BG5: Nodestørrelse FK-BG6: Meldinger FK-HA1: Håndtering av OWL-typer FK-HA2: Åpning av OWL-fil fra disk FK-HA3: Åpning av OWL-fil fra URL FK-HA4: Tolking av OWL-fil FK-HA5: Syntaksfeil i OWL-fil FK-HA6: Dataignorering i OWL-fil FK-HA7: OWL-type FK-NA1: Skalering av graf FK-NA2: Oversiktsbilde FK-NA3: Navigasjon i oversiktsvinduet FK-NA4: Ekspandering av symbol FK-NA5: Utvidelse i alle retninger FK-SE1: Søking i grafen FK-SE2: Søking med attributter i grafen

160 Kravspesifikasjon 25 FK-SE3: Behandling av resultater etter et søk FK-FI1: Predefinerte filtre FK-FI2: Egendefinerte filtre FK-FI3: Lagring av filtre FK-FI4: Åpning av filtre FK-BH1: Skjuling av begrep FK-BH2: Velging av begrep FK-BH3: Innsetting av begrep i utvalgsliste FK-BH4: Fjerning av begrep fra utvalgsliste FK-BH5: Grafgenerering av begrep i en utvalgsliste FK-BH6: Velging av underbegrep til et markert begrep FK-BH7: Visning av individer for et markert begrep FK-BH8: Visning av informasjon om markert begrep FK-BH9: Utvelging av informasjon om markert begrep FK-FB1: Lagring av sesjon FK-FB2: Åpning av sesjon FK-IG1: Mottak av begrep og relasjoner FK-IG2: Mottak av tilleggsattributter FK-IG3: Endring av søkestreng FK-IG4: Sending av begrep og relasjoner FK-IG5: Setting av ontologi UC1 - Tolking av en OWL-fil UC2 - Søking i grafen UC3 - Oversiktsbildet UC4 - Grafgenerering av begreper i en utvalgsliste UC5 - Skjuling av begrep

161 Kravspesifikasjon 51 UC6 - Ekspandering av symbol UC7 - Velging av underbegrep til et markert begrep UC8 - Visning av individer for et markert begrep UC9 - Visning og utvelging av informasjon om markert begrep UC10 - Lagring av en sesjon UC11 - Åpning av en sesjon UC12 - Egendefinerte filtre UC13 - Mottak av begreper, relasjoner og tilleggsattributter Oppsummering av usecase estimering Oppsummeringstabell for ikke-funksjonelle krav IFK-GK1: Implementasjonspråk IFK-GK2: Portabilitet IFK-GK3: Robusthet IFK-GK4: Skifte språk IFK-GK5: Implementasjon av egendefinerte filter IFK-BG1: Tilstandsfullt brukergrensesnitt IFK-BG2: Brukergrensesnittspråk IFK-BG3: Gjenkjennbarhet IFK-BG4: Navigasjon uten mus IFK-BG5: Spesialtegn IFK-BG6: Relasjonsnavn IFK-KY1: Responstid IFK-KY2: Ontologistørrelse IFK-KY3: Minstekrav til PC IFK-DOK1: Utvidbar kode IFK-DOK2: Installasjon

162 Kravspesifikasjon 77 IFK-DOK3: Installasjonsveiledning IFK-DOK4: JavaDoc De kravene som er med i 1. inkrement De kravene som er med i 2. inkrement De kravene som er med i 3. inkrement

163 Kravspesifikasjon Figurer 1 Ønsket situasjon hos DiB Prototyp av brukergrensesnittet Use case-estimat

164 Kravspesifikasjon 1 Innledning Dette dokumentet er basert på IEEEs anbefalte framgangsmåte for kravspesifikasjon [4], men med enkelte endringer der kravene og anbefalingene til gjennomføringen av dette prosjektet har veket fra IEEEs standard. 1.1 Formål Kravspesifikasjonen er utarbeidet i samarbeid med Doctors in Business, prosjektets kunde, og spesifiserer krav til visualiseringskomponenten som skal utvikles i prosjektet. Kravene til komponenten og omgivelsene er delt inn i funksjonelle og ikke-funksjonelle krav. Et funksjonelt krav spesifiserer en funksjon som et system eller en systemkomponenten skal kunne utføre. Ikkefunksjonelle krav beskriver rammene for komponenten. For eksempel kan disse være krav til ytelse, design og egenskaper. Under de ikke-funksjonelle kravene følger også krav om bruker-, programmerings- og installasjonsdokumentasjon. Alle kravene i kravspesifikasjonen er gitt en viktighetsvurdering (lav, middels eller høy). Formålet med denne viktighetsvurderingen er at gruppen da kan vektlegge noen krav mer enn andre i konstruksjons- og implementasjonsfasen. Dette dokumentet er hovedsaklig tilsiktet personer som er involvert i utviklingen av visualiseringskomponenten. Kravspesifikasjonen vil danne grunnlaget for videre design og implementasjon av visualiseringkomponenten, både for gruppen i dette prosjektet og for framtidig utvikling. 1.2 Definisjoner I dette avsnittet definerer gruppen en del termer, slik at alle som leser kravspesifikasjonen skal ha felles forståelse av dem. Dette er gruppens terminologi for ting som finnnes i OWL. Begrep: Er det samme som en Class i Web Ontology Language (OWL). En Class er en gruppe av Individual som hører sammen fordi de deler noen attributter. Individ: Et Individual er en instans av en Class. Attributter kan bli brukt til å relatere et Individual til et annet. 10

165 Kravspesifikasjon Attributt: Er det samme som DatatypeProperty i OWL. Relasjon: Er det samme som ObjectProperty i OWL. Det finnes tre typer relasjoner. Dette er relasjoner i et begrepshierarki, mellom begrep og mellom begrep og individ. Relasjonene vises som rettede kanter i grafen. 1.3 Oversikt Kapittel 2 ser på de overordnet kravene til komponenten. I kapittel 3 blir de funksjonelle kravene beskrevet. Kapittel 4 inneholder use case som gruppen har skrevet. I kapittel 6 har gruppen beskrevet hvilke krav som skal tilhøre de ulike inkrementene i utviklingsprosessen. Avslutningsvis er et kapittel viet de ikke-funksjonelle kravene. 11

166 Kravspesifikasjon 2 Overordnet beskrivelse Kapittelet ser på de overordnede kravene i forhold til komponenten. Dette består i å først sette komponenten i perspektiv med andre applikasjoner og deler av arbeidsbenken til Doctors in Business(DiB). I denne sammenheng vil grensesnittene som skal benyttes mellom komponenten og andre systemer bli identifisert og spesifisert. Videre vil hovedfunksjonaliteten til komponenten bli spesifisert. Deretter følger en beskrivelse av brukergruppene for komponenten før kapittelet avsluttes med å se på restriksjoner og avhengigheter. 2.1 Produktperspektiv Komponenten som utvikles i dette prosjektet skal visualisere ontologier som grafer, og tilby et brukergrensesnitt for å manipulere visualiseringen. Den skal kunne integreres som en del av arbeidsbenken til Doctors In Business og må derfor tilby et godt dokumentert integrasjonsgrensesnitt. Den vil benytte seg av ontologier i OWL-format som en ekstern ressurs. Ontologiene vil bli transformert til en graf, og fremvist i et grafisk brukergrensesnitt som skal tilby funksjonalitet for å manipulere visningen. For komponenten er det identifisert tre ulike grensesnitt: et brukergrensesnitt, et OWL-grensesnitt og et integrasjonsgrensesnitt. Figur 1, som er tatt fra dette prosjektets forstudium, viser kommunikasjonen til komponenten gjennom disse [3]. Brukergrensesnittet vil kommunisere med brukeren, OWL-grensesnittet ligger mellom komponenten og sirkelen merket indeks, og integrasjonsgrensesnittet ligger i de horisontale pilene. Både søk og andre DiB-applikasjoner vil kommunisere gjennom det samme grensesnittet Den overordnede funksjonaliteten til grensesnittene er beskrevet i de neste avsnittene Brukergrensesnitt Dette grensesnittet skal ta seg av interaksjonen med brukeren. Data som kommer fra brukeren må håndteres og sendes videre i komponenten, informasjon som blir generert i andre deler av komponenten må formidles videre 12

167 Kravspesifikasjon Figur 1: Ønsket situasjon hos DiB 13

168 Kravspesifikasjon til brukeren OWL-grensesnitt Dette grensesnittet skal ta seg av lesing av OWL-filer og deretter presentere disse i et format som komponenten kan benytte seg av videre. OWLgrensesnittet skal realiseres på en av to mulige måter: Gjennom bruk av Jena 1. Gjennom bruk av Xalan 2 og et extensible Stylesheet Language (XSL)- dokument for konvertering mellom OWL og GraphML. World Wide Web Consortium (W3C) har listet opp alle egenskapene som OWL Lite inneholder. Ikke alle disse er relevante for dette prosjektet. Gruppen har derfor sammen med kunden gjort et utvalg av hvilke egenskaper som bør være med. I forhold til forstudiet har denne listen blitt noe større. Med utgangspunkt i inndelingen som W3C bruker på sine sider 3 er følgende egenskaper tatt med. For mer informasjon om hva de forskjellige emnene og egenskapene omhandler henvises leseren til W3Cs sider. I tabell 1 vises hvilke egenskaper i OWL Lite som ble valgt ut som relevante for prosjektet. Egenskapene er gruppert i kolonner likt det som er gjort på W3Cs sider. I kolonnen RDF Schema Features er egenskapene fra forstudiet tatt med. Disse egenskapene vil danne basisen for det som visualiseres i grafen, og består av begrepene, individene og relasjonene mellom dem. Informasjon egenskapene fra de tre siste kolonnene gir, vil vises frem i informasjonsvinduet (se figur 2 i avsnitt 3.2). I OWL-filen er det tillegg til disse egenskapene headerinformasjon. Denne headerinformasjonen inneholder blant annet informasjon om forfatter av OWL-filen, og lignende. 1 Jena er en tolker som konverterer OWL til en definert objektstruktur. Jena er tilgjengelig fra 2 Xalan er et bibliotek for konvertering av XML-dokumenter ved hjelp av XSL, tilgjengelig fra

169 Kravspesifikasjon RDF Schema Features Equality Inequality and Property Restrictions Restricted Cardinality Class equivalentclass allvaluesfrom mincardinality rdfs:subclassof equivalentproperty somevaluesfrom maxcardinality rdf:property sameas cardinality rdfs:subpropertyof rdfs:domain rdfs:range Individual differentfrom AllDifferent Tabell 1: OWL Lite-egenskaper som er relevante for prosjektet I tabell 2 vises hvilke egenskaper i OWL Lite som ble valgt ut som ikke relevante for prosjektet. Property Characteristics inverseof TransitiveProperty SymmetricProperty functionalproperty InverseFunctionalProperty Class Intersection intersectionof Tabell 2: OWL Lite-egenskaper som er ikke relevante for prosjektet Integrasjonsgrensesnitt Integrasjonsgrensesnittet skal gi muligheter for integrering av komponenten i DiBs arbeidsbenk, samt muligheter for å utvide komponenten med ytterligere funksjonalitet. Grensesnittet skal definere hvordan data kommer inn til og ut fra komponenten. Komponenten skal også kunne motta en liste med begreper og/eller relasjoner fra et indekssystem sammen med en søkestreng. Dette søket skal danne grunnlag for en ny visning av grafen som visualiseres på det tidspunktet det mottas. 15

170 Kravspesifikasjon 2.2 Produktfunksjon Komponenten skal tolke ontologier i OWL-format. Ontologiene og relasjonene mellom dem skal så vises som en grafstruktur til brukeren. Brukergrensesnittet skal tilby følgende funksjoner til brukeren: Navigasjon i grafen. Søking etter begrep og/eller relasjoner i grafen. Skalering av grafen. Filtrering av grafelementer: Vise bare navn på ontologien eller vise forskjellige grupper av attributter i tillegg til navnet. Velge hvilke relasjonstyper som skal vises. Lagre innstillinger for filtrering. Oversiktsvindu/hjelpenavigasjonsvindu som viser en miniatyrutgave av grafen. 2.3 Brukerkarakteristikk Brukerne av komponenten kan deles i to grupper; avanserte og enkle brukere Avanserte brukere Denne gruppen kan forventes å ha relativt høy teknisk kompetanse, g forventes å være meget godt kjent med å benytte verktøy med brukergrensesnitt lignende det som skal utvikles i dette prosjektet. Typisk vil dette dreie seg om ansatte i DiB Enkle brukere Denne gruppen vil ha mer varierende kunnskap. De kan forventes å være meget kompetente innen fagområdet til den aktuelle ontologien, men teknisk kunnskap knyttet til bruk av komponenten forventes å være mer varierende. Kunder av DiB vil trolig falle i denne kategorien. 16

171 Kravspesifikasjon 2.4 Restriksjoner Komponenten vil ha følgende restriksjoner som det må tas hensyn til: Komponenten må utvikles i Java. Ontologiene skal være i OWL-format. 17

172 Kravspesifikasjon 3 Funksjonelle krav De funksjonelle kravene tar utgangspunkt i de forretningsmessige kravene i forstudiet, og har blitt utarbeidet i samarbeid med kunden. De forretningsmessige kravene som ble utarbeidet i forstudiet er gjengitt i tabell 3. ID Navn FM1 Komponenten skal ha et godt definert og dokumentert grensesnitt. FM2 Komponenten skal implementeres i Java. FM3 Komponenten skal visualisere ontologier som en graf. FM4 Komponenten skal kunne lese OWL Fullontologier. FM5 Komponenten skal bruke data fra et subsett av OWL Lite som utgangspunkt for visualisering. FM6 Responstid for brukeren skal være maksimalt ett minutt. FM7 Komponenten skal kunne visualisere en ontologi med 1000 begrep og 5000 relasjoner. Brukeren skal kunne samhandle med komponenten ved å kunne navigere i ontologien, samt å velge utsnitt i ontologien som er av interesse. FM8 Komponenten skal være plattformuavhengig. FM9 En prototyp av komponenten skal være ferdig FM10 Verktøy og andre komponenter som benyttes bør være så billige som mulig. FM11 Komponenten skal være stabil. FM12 Dokumenteringen skal være grundig og lett forståelig. FM13 Brukergrensesnittet skal være intuitivt. Tabell 3: Forretningsmessige krav 18

173 Kravspesifikasjon Hensikten med de funksjonelle kravene er å definere funksjonene til komponenten. De funksjonelle kravene skal si noe om hva komponenten skal gjøre, både ovenfor brukeren av komponenten og i samarbeid med omgivelsene til komponenten. Et viktig poeng i forbindelse med de funksjonelle kravene er at de skal være målbare og kunne testes. De skal altså formuleres slik at de er mest mulig helhetlige, konkrete og verifiserbare. Det er også viktig at man i formuleringene av kravene forsøker å unngå å fortelle hvordan noe skal løses. Dette for å slippe å binde seg til løsninger som senere kan vise seg å være vanskelige eller umulige å implementere. 3.1 Oppsummering Tabell 4 er en oppsummering over alle de funksjonelle kravene. Kravene i tabellen vil bli nærmere beskrevet i de påfølgende avsnittene. Kravene har blitt gruppert i følgende deler: Brukergrensesnitt (avsnitt 3.2) inneholder krav som omhandler brukergrensesnittet. Både hvordan det skal se ut og hvilke generelle funksjoner som finnes. Håndtering av OWL (avsnitt 3.3) inneholder krav som omhandler håndtering av OWL-filer. Navigasjon og skalering (avsnitt 3.4) inneholder krav som omhandler brukerens muligheter til navigasjon og skalering i grafen. Søking (avsnitt 3.5) inneholder krav som omhandler søking i grafen. Det er da snakk om søkemulighetene som ligger til rette for en bruker i komponenten, ikke en utenforstående søkemotor. Filtrering av graf (avsnitt 3.6) inneholder krav som omhandler filtrering. Begrepshåndtering (avsnitt 3.7) inneholder krav som tar for seg håndteringen av begrep i hovedvinduet, se figur 2. Filbehandling (avsnitt 3.8) inneholder krav som tar for seg filbehandling. 19

174 Kravspesifikasjon Integrasjonsgrensesnitt (avsnitt 3.9) innholder krav som omhandler komponentens grensesnitt til andre komponenter. Enkelte krav kan passe inn i flere deler avhengig av synsvinkelen. Gruppen har valgt å samle kravene slik at krav som hører sammen blir samme del. KravID Referanse Navn Viktighetsgrad FK-BG1 Tabell 5 Ontologi som graf Høy FK-BG2 Tabell 6 Manipulering av støttevinduer Middels FK-BG3 Tabell 7 Relasjoner Høy FK-BG4 Tabell 8 Navn på noder Høy FK-BG5 Tabell 9 Nodestørrelse Høy FK-BG6 Tabell 10 Meldinger Middels FK-HA1 Tabell 11 Håndtering av OWL-typer Høy FK-HA2 Tabell 12 Åpning av OWL-fil fra disk Høy FK-HA3 Tabell 13 Åpning av OWL-fil fra URL Høy FK-HA4 Tabell 14 Tolking av OWL-fil Høy FK-HA5 Tabell 15 Syntaksfeil i OWL-fil Lav FK-HA6 Tabell 16 Dataignorering i OWL-fil Lav FK-HA7 Tabell 17 OWL-type Lav FK-NA1 Tabell 18 Skalering av graf Høy FK-NA2 Tabell 19 Oversiktsbilde Høy FK-NA3 Tabell 20 Navigasjon i oversiktsvinduet Middels FK-NA4 Tabell 21 Ekspandering av symbol Høy FK-NA5 Tabell 22 Utvidelse i alle retninger Lav FK-SE1 Tabell 23 Søking i grafen Høy FK-SE2 Tabell 24 Søking med attributter i grafen Middels FK-SE3 Tabell 25 Behandling av resultater etter et søk Høy FK-FI1 Tabell 26 Predefinerte filtre Høy FK-FI2 Tabell 27 Egendefinerte filtre Middels FK-FI3 Tabell 28 Lagring av filtre Middels FK-FI4 Tabell 29 Åpning av filtre Middels FK-BH1 Tabell 30 Skjuling av begrep Høy FK-BH2 Tabell 31 Velging av begrep Høy FK-BH3 Tabell 32 Innsetting av begrep i utvalgsliste Lav/Middels FK-BH4 Tabell 33 Fjerning av begrep fra utvalgsliste Lav/Middels FK-BH5 Tabell 34 Grafgenerering av begrep i en utvalgsliste Høy 20

175 Kravspesifikasjon FK-BH6 Tabell 35 Velging av underbegrep til et markert begrep FK-BH7 Tabell 36 Visning av individer for et markert begrep FK-BH8 Tabell 37 Visning av informasjon om markert begrep FK-BH9 Tabell 38 Utvelging av informasjon om markert begrep Høy Høy Høy FK-FB1 Tabell 39 Lagring av sesjon Middels FK-FB2 Tabell 40 Åpning av sesjon Middels Lav FK-IG1 Tabell 41 Mottak av begrep og relasjoner Høy FK-IG2 Tabell 42 Mottak av tilleggsattributter Middels FK-IG3 Tabell 43 Endring av søkestreng Middels FK-IG4 Tabell 44 Sending av begrep og relasjoner Høy FK-IG5 Tabell 45 Setting av ontologi Høy Tabell 4: Oppsummeringstabell for funksjonelle krav. 21

176 Kravspesifikasjon 3.2 Brukergrensesnitt Kravene i dette avsnittet omhandler hvordan brukergrensesnittet til komponenten skal være. Dette gjelder både hvordan det skal være utseendemessig, samt hvilke generelle funksjoner som skal finnes i brukergrensesnittet. I samarbeid med kunden ble det satt opp en prototyp for brukergrensesnittet. Denne er illustrert i figur 2. Det viktigste å legge merke til i prototypen er hvilke fem vinduer komponenten skal inneholde. Disse er hovedvindu, oversiktsvindu, subklassevindu, utvalgsliste og informasjonsvindu. I enkelte av de påfølgende kravene i dette kapittelet vil det refereres til de forskjellige vinduene i prototypen. Figur 2: Prototyp av brukergrensesnittet Under følger en forklaring de forskjellige vinduene i figur 2. Hovedvindu: Dette er vinduet der grafen tegnes opp. Brukeren skal kunne navigere i denne grafen 22

177 Kravspesifikasjon Oversiktsvindu: Her vil komponenten til enhver tid kunne vise en oversikt over hele grafen. Denne oversikten skal være en miniatyrutgave av den nåværende grafen i hovedvinduet. Dette vil være nyttig når grafen er veldig stor og uoversiktelig. Brukeren vil kunne navigere i dette oversiktsvinduet og velge hvilke deler av grafen man ønsker å se. Kravene som omhandler oversiktsviduet er FK-NA2 og FK-NA3 og finnes i tabell 19 og 20 Subklassevindu: Brukeren kan velge et begrep i grafen, se krav FK- BH2. Dette begrepet vil da være markert. Det er da mulig for brukeren å se, i subklassevinduet, hvilke direkte underbegrep som hører til dette begrepet, se krav FK-BH6 i tabell 35. I tillegg kan brukeren se hvilke individer som hører til begrepet, se krav FK-BH7 i tabell 36. Utvalgsliste: En bruker kan velge å legge til eller fjerne begrep i en utvalgsliste, se krav FK-BH3 og FK-BH4 i tabell 32 og 33. Disse blir med andre ord lagt i vinduet Utvalgsliste. Det er da meningen at man skal kunne lage en ny graf basert kun på begrepene i utvalgslisten, se krav FK-BH5. I tillegg vil også søkeresultater fra en utenforstående søkemotor bli lagt her, se krav FK-IG1 og FK-IG2 i tabell 41 og 42. Informasjonsvindu: Dette vinduet vil inneholde endel nyttig informasjon tilknyttet et markert begrep, se krav FK-BH8 i tabell 37. Det forretningsmessige kravet FM7 (se tabell 3) danner grunnlaget for kravene i dette avsnittet. Kravene for dette avsnittet, FK-BG1 til FK-BG6, finnes i tabell 5 til 10. KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-BG1 Ontologi som graf Komponenten skal kunne vise ontologier som grafer. Dette er et forretningsmessig krav (FM7). Høy Tabell 5: FK-BG1: Ontologi som graf 23

178 Kravspesifikasjon KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-BG2 Manipulering av støttevinduer Alle støttevinduer skal kunne flyttes og skjules Det skal være mulig å se hele hovedvinduet (se figur 2), og da er det fordelaktig å kunne flytte på støttevinduene. Middels Tabell 6: FK-BG2: Manipulering av støttevinduer KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-BG3 Relasjoner Det skal skilles mellom forskjellige kanter i grafen, eksempelvis kanter for begrepshierarki, individer og relasjoner. Kantene kan skilles for eksempel ved hjelp av ulike farger. En enkel metode for å skille mellom kanter øker lesbarheten til grafen. Høy Tabell 7: FK-BG3: Relasjoner 24

179 Kravspesifikasjon KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-BG4 Navn på noder Navnet på en node skal skjules hvis det tar større plass enn figuren som representerer noden. Hele navnet vises da hvis man holder musepekeren over noden. Selektiv navnevisning gjør grafen mer ryddig og oversiktlig. Høy Tabell 8: FK-BG4: Navn på noder KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-BG5 Nodestørrelse Alle noder skal være like store. Lik nodestørrelse vil øke oversikten og lesbarheten av grafen. Høy Tabell 9: FK-BG5: Nodestørrelse KravID Navn Beskrivelse FK-BG6 Meldinger Brukeren skal få tilbakemelding fra komponenten ved en rekke anledninger. De ulike tilfellene er listet under: Feil skal varsles med en feilmelding Venting skal varsles, og tidsperspektivet skal hvis mulig visualiseres Kritiske operasjoner skal vise en advarsel Viktighetsvurdering Viktighetsgrad Ved lagring av sesjon Disse meldingene skal vises med forståelige ikoner og en tekstlig melding. Brukeren må varsles om tilstanden til komponenten. Middels Tabell 10: FK-BG6: Meldinger 25

180 Kravspesifikasjon 3.3 Håndtering av OWL Kravene i dette avsnittet omhandler håndtering av OWL-filer. De fleste av disse kravene er helt grunnleggende for komponenten siden det er ontologier skrevet på OWL-standarden som skal visualiseres. Det forretningsmessige kravet FM4 (se tabell 3) danner grunnlaget for disse kravene. Kravene for dette avsnittet, FK-HA1 til FK-HA7, finnes i tabellene 11 til 17. KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-HA1 Håndtering av OWL-typer Komponenten skal kunne håndtere alle OWL-typer (OWL Lite, OWL DL og OWL Full). Dette er et forretningsmessig krav (FM4). Høy Tabell 11: FK-HA1: Håndtering av OWL-typer KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-HA2 Åpning av OWL-fil fra disk Brukeren skal kunne åpne en OWL-fil fra lokal disk som skal tolkes av komponenten. Funksjonen er grunnleggende for visualiseringen. Høy Tabell 12: FK-HA2: Åpning av OWL-fil fra disk 26

181 Kravspesifikasjon KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-HA3 Åpning av OWL-fil fra URL Brukeren skal kunne åpne en OWL-fil fra en URLadresse som skal tolkes av komponenten. Funksjonen er på samme måte som FK-HA2 grunnleggende. Høy Tabell 13: FK-HA3: Åpning av OWL-fil fra URL KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-HA4 Tolking av OWL-fil Komponenten skal kunne tolke en OWL-fil, plukke ut relevante data i henhold til krav om OWL Lite, og konvertere disse til en grafrepresentasjon. Funksjonen er grunnleggende for visualiseringen Høy Tabell 14: FK-HA4: Tolking av OWL-fil KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-HA5 Syntaksfeil i OWL-fil Hvis det er syntaksfeil i OWL-filen som tolkes skal brukeren få beskjed om dette, og hvor i filen feilen ligger. Dette kan være nyttig ekstrafunksjonalitet for brukeren. Lav Tabell 15: FK-HA5: Syntaksfeil i OWL-fil KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-HA6 Dataignorering i OWL-fil Brukeren skal få beskjed om hvilke egenskaper som ignoreres når OWL-filen konverteres til en grafrepresentasjon. Dette kan være nyttig ekstrafunksjonalitet for brukeren. Lav Tabell 16: FK-HA6: Dataignorering i OWL-fil 27

182 Kravspesifikasjon KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-HA7 OWL-type Brukeren skal få beskjed om OWL-filen er av type OWL Lite, OWL DL, eller OWL Full. Dette kan være nyttig ekstrafunksjonalitet for brukeren. Lav Tabell 17: FK-HA7: OWL-type 28

183 Kravspesifikasjon 3.4 Navigasjon og skalering Kravene i dette avsnittet omhandler brukerens muligheter til navigasjon og skalering i grafen. Det forretningsmessige kravet FM7 tilsier at ontologiene kan komme opp i en størrelse på 1000 begrep og 5000 relasjoner. Grafiske fremstillinger av ontologier med en slik størrelse blir raskt uoversiktlige. Det er derfor veldig viktig å kunne navigere i grafen på en enkel og hensiktsmessig måte. Det forretningsmessige kravet FM7 danner grunnlaget for kravene i dette avsnittet. Kravene for dette avsnittet FK-NA1 til FK-NA5 finnes i tabellene 18 til 22. KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-NA1 Skalering av graf Brukeren skal kunne velge forskjellig skalering av grafen. Dette innebærer mulighet for både forminsking og forstørring. Kravet er meget viktig da det letter navigasjonen i grafen. Høy Tabell 18: FK-NA1: Skalering av graf KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-NA2 Oversiktsbilde Komponenten skal til enhver tid kunne vise en oversikt over hele grafen brukeren jobber med. Denne oversikten skal være en miniatyrutgave av den nåværende grafen i hovedvinduet (se figur 2). Kravet er meget viktig da grafene ofte blir veldig store. Et oversiktsbilde over grafen vil lette navigasjonen. Høy Tabell 19: FK-NA2: Oversiktsbilde 29

184 Kravspesifikasjon KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-NA3 Navigasjon i oversiktsvinduet Brukeren skal kunne navigere i oversiktsvinduet (se figur 2), og velge hvilke deler av grafen man vil se på. Dette realiseres ved at brukeren kan flytte et rektangel rundt i oversiktsvinduet. Det som befinner seg inne i rektangelet vil vises i hovedvinduet. Brukeren kan ikke forminske eller forstørre grafen i oversiktsvinduet. Kravet er meget viktig da grafene ofte blir veldig store. Et oversiktsbilde over grafen vil lette navigasjonen. Middels Tabell 20: FK-NA3: Navigasjon i oversiktsvinduet 30

185 Kravspesifikasjon KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-NA4 Ekspandering av symbol Brukeren skal kunne ekspandere et symbol som representerer skjulte deler av grafen (se FK-BH1). Ekspanderingen skal skje ett nivå av gangen, og resultatet skal være at man får fram et begrep og et nytt symbol som representerer den resterende skjulte delen av grafen. Kravet er meget viktig ettersom brukeren må kunne få tilbake de deler av grafen som er skjulte. Høy Tabell 21: FK-NA4: Ekspandering av symbol KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-NA5 Utvidelse i alle retninger Brukeren skal for et markert begrep kunne velge å ekspandere rundt dette begrepet et bestemt antall nivåer i alle retninger. Dette gjelder oppover og nedover i begrepshierarkiet, samt relasjoner. Kravet er meget viktig da det kan være vanskelig for brukeren å vite i hvilken retning nye interessante begrep ligger. Lav Tabell 22: FK-NA5: Utvidelse i alle retninger 31

186 Kravspesifikasjon 3.5 Søking Kravene i dette avsnittet omhandler brukerens muligheter til å søke i grafen. Merk at det ikke er snakk om noen utenforstående søkemotor i dette tilfellet, men brukerens søkemuligheter med den visuelle komponenten. Grafiske fremstillinger av ontologier blir raskt store og uoversiktlige. Det er derfor veldig viktig å kunne søke i grafen for enkelt å finne de begreper og individer som er av interesse. Det forretningsmessige kravet FM7 danner grunnlaget for kravene i dette avsnittet. Kravene for dette avsnittet, FK-SE1 til FK-SE3, finnes i tabell 23 til 25. KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-SE1 Søking i grafen Brukeren skal kunne søke med fritekst etter begrep og individer i grafen. Dette betyr at man kan søke etter deler av begreps- og individnavnet. For eksempel vil søk etter begrepet helse kunne gi helsesøster, helsekost, etc. som svar. Kravet er viktig ettersom man lettere kan finne igjen deler av interesse i en stor graf. Høy Tabell 23: FK-SE1: Søking i grafen KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-SE2 Søking med attributter i grafen Brukeren skal kunne søke etter begrep med angitte attributtnavn og attributtverdier. Denne funksjonaliten vil ikke være til like stor hjelp som FK-NA1. Middels Tabell 24: FK-SE2: Søking med attributter i grafen 32

187 Kravspesifikasjon KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-SE3 Behandling av resultater etter et søk. Resultatene etter et søk skal komme opp i en resultatliste. I denne listen skal det skilles mellom begrep og individer, og for hvert individ skal det komme klart fram hvilket begrep det tilhører. Fra resultatlisten skal brukeren kunne velge et innslag, og dette vil da sentreres i hovedvinduet (se figur 2). Ved valg av et individ skal fokus sentreres rundt begrepet. Kravet er viktig ettersom man lettere kan finne igjen deler av interesse i en stor graf. Høy Tabell 25: FK-SE3: Behandling av resultater etter et søk. 33

188 Kravspesifikasjon 3.6 Filtrering av graf Kravene i dette avsnittet omhandler filtreringen av grafen. Som i kravene i forrige avsnitt er disse kravene blitt til fordi ontologier raskt kan bli veldig store, noe som fører til at man raskt mister oversikten. I tillegg kan det være en del informasjon som er helt uvesentlig for det man vil se nærmere på. Det er da hensiktsmessig å ha en mekanisme for å filtrere bort alle elementene i en ontologi som ikke er av interesse. Det forretningsmessige kravet FM7 danner grunnlaget for kravene i dette avsnittet. Kravene for dette avsnittet, FK-FI1 til FK-FI4, finner man i tabell 26 til 29. KravID Navn Beskrivelse FK-FI1 Predefinerte filtre Komponenten skal ha en liste over predefinerte filtre som brukeren kan velge fra når man ønsker å filtrere grafen. Brukeren skal kunne velge mellom følgende tre filter: Slå av og på hierarktiske relasjoner (relasjoner av typen subclassof). Slå av og på andre relasjoner mellom begrepene (relasjoner av typen ObjectProperty). Valg av dybde som skal vises i begrepshierarkiet. Viktighetsvurdering Viktighetsgrad Grafene kan bli store og uoversiktlige og det vil derfor være veldig nyttig å kunne filtrere bort alt som ikke er av interesse på en rask måte. Høy Tabell 26: FK-FI1: Predefinerte filtre 34

189 Kravspesifikasjon KravID Navn Beskrivelse FK-FI2 Egendefinerte filtre Brukeren skal kunne lage egne filtre. Det vil si at brukeren skal kunne velge kriterier for filtrering. Brukeren skal i den sammenheng ha følgende valgmuligheter: Velge hvilke begrep skal vises eller skjules. Velge hvilke relasjoner skal vises eller skjules. Velge om begrep som har spesifikke attributtnavn og verdier skal vises eller skjules. Velge maksimal hierarkisk dybde for begrepene i grafen. Viktighetsvurdering Viktighetsgrad Samme som FK-FI1. Middels Tabell 27: FK-FI2: Egendefinerte filtre KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-FI3 Lagring av filtre Brukeren skal kunne lagre egendefinerte filter. Dette er viktig slik at brukeren kan benytte samme filter på forskjellige ontologier. Middels Tabell 28: FK-FI3: Lagring av filtre KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-FI4 Åpning av filtre Brukeren skal kunne åpne egendefinerte filter. Dette er viktig slik at brukeren kan benytte samme filter på forskjellige ontologier. Middels Tabell 29: FK-FI4: Åpning av filtre 35

190 Kravspesifikasjon 3.7 Begrepshåndtering Her har gruppen samlet alle krav som omhandler håndtering av begrep i hovedvinduet. Håndtering av begrep innebærer hva man kan gjøre med et begrep og hva som skjer når man velger ut et begrep i grafen. Det forretningsmessige kravet FM7 danner grunnlaget for kravene i dette avsnittet. Kravene i dette avsnittet, FK-BH1 til FK-BH9, finner man i tabell 30 til 38. KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-BH1 Skjuling av begrep Brukeren skal kunne skjule et begrep og alle underbegrep til dette. Når et begrep skjules skal det i den resterende grafen vises med et symbol at det finnes skjulte deler av grafen. Kravet er meget viktig ettersom det gir brukeren mulighet til å velge bort deler av grafen som ikke er av interesse. Høy Tabell 30: FK-BH1: Skjuling av begrep KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-BH2 Velging av begrep Brukeren skal kunne velge et begrep. Dette begrepet skal markeres slik at det tydelig kan skilles fra de andre begrepene. Etter at et begrep er valgt vil det benevnes i denne kravspesifikasjonen som et markert begrep. Kravet er meget viktig ettersom brukeren skal kunne gjøre forskjellige valg for et markert begrep. Høy Tabell 31: FK-BH2: Velging av begrep 36

191 Kravspesifikasjon KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-BH3 Innsetting av begrep i utvalgsliste Brukeren skal kunne legge det markerte begrepet inn i utvalgslisten (se figur 2). Kravet er meget viktig ettersom brukeren skal kunne plukke ut begrep av interesse og senere få en ny representasjon av disse. Lav/Middels Tabell 32: FK-BH3: Innsetting av begrep i utvalgsliste KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-BH4 Fjerning av begrep fra utvalgsliste Brukeren skal kunne fjerne et begrep fra utvalgslisten (se figur 2). Kravet er meget viktig, jamfør FK-BH3. Lav/Middels Tabell 33: FK-BH4: Fjerning av begrep fra utvalgsliste 37

192 Kravspesifikasjon KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-BH5 Grafgenerering av begrep i en utvalgsliste. Brukeren skal kunne velge å generere en graf av begrepene i en utvalgsliste (se figur 2). Det skal da bare være begrepene i listen som skal representeres i grafen. De delene som ikke er med skal representeres, jamfør FK-BH1. En viktig del av funksjonaliteten til komponenten skal være å kunne velge ut visse begrep og få en grafrepresentasjon av disse. Høy Tabell 34: FK-BH5: Grafgenerering av begrep i en utvalgsliste. KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-BH6 Velging av underbegrep til et markert begrep Brukeren skal kunne få opp en oversikt over hvilke direkte underbegrep som finnes for et markert begrep (se figur 2). Fra denne oversikten skal det kunne velges hvilke underbegrep man vil ha vist i forbindelse med det markerte begrepet i grafen. Her kan det bli store hierakier som det er viktig å kunne håndtere slik at grafen blir oversiktlig og det er de interessante delene som vises. Høy Tabell 35: FK-BH6: Velging av underbegrep til et markert begrep KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-BH7 Visning av individer for et markert begrep Brukeren skal kunne få opp en oversikt over hvilke individer som finnes for et markert begrep (se figur 2). Fra denne oversikten skal det kunne velges hvilke individer man vil ha vist i forbindelse med det markerte begrepet i grafen. Samme som i FK-BH6. Høy Tabell 36: FK-BH7: Visning av individer for et markert begrep 38

193 Kravspesifikasjon KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-BH8 Visning av informasjon om markert begrep Brukeren skal kunne få opp informasjon som gjelder et markert begrep (se figur 2). Denne informasjonen vil være hvilke attributter og relasjoner begrepet har, hvilket overbegrep begrepet tilhører og antall individer begrepet har. Det er meget viktig for brukeren å kunne se all informasjon om et begrep. Høy Tabell 37: FK-BH8: Visning av informasjon om markert begrep KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-BH9 Utvelging av informasjon om markert begrep Brukeren skal kunne velge hvilken type informasjon som skal vises om et markert begrep. Se FK-BH8 for hvilken type informasjon det er snakk om. Det er mindre viktig å kunne konfigurere hvilken type informasjon som skal vises. Lav Tabell 38: FK-BH9: Utvelging av informasjon om markert begrep 39

194 Kravspesifikasjon 3.8 Filbehandling Til disse kravene er det ingen direkte forretningsmessige krav. Kravene ble til under kundemøtene i forbindelse med kravspesifikasjonen. I en ontologi vil det være hensiktsmessig å kunne lagre hvor langt en er kommet i behandlingen av en graf. For eksempel hvis en jobber med en ontologi og skal spise lunsj, så kan man lagre det en jobber med. Etter lunsj hentes dette fram og det vil virke som man begynne der man sluttet. Kravene for dette avsnittet, FK-FB1 og FK-FB2, finner man i tabell 39 og 40. KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-FB1 Lagring av sesjon Brukeren skal kunne lagre de valg og innstillinger som er gjort i nåværende graf, slik at man senere kan få tilbake den samme grafen med de samme valgene og innstillingene. Kravet er viktig for å kunne få tilbake et interessant utsnitt av ontologien ved en senere anledning. Middels Tabell 39: FK-FB1: Lagring av sesjon KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-FB2 Åpning av sesjon Brukeren skal kunne åpne en sesjon for å få tilbake den samme grafen med de samme valgene og innstillingene. Kravet er viktig tilsvarende krav FK-FB1. Middels Tabell 40: FK-FB2: Åpning av sesjon 40

195 Kravspesifikasjon 3.9 Integrasjonsgrensesnitt Kravene omhandler komponentens grensesnitt til andre komponenter. Med tanke på ønskede situasjonen til DiB, og det forretningsmessige kravet FM1, må komponenten ha et veldefinert grensesnitt til omgivelsene sine. I disse kravene har det blitt spesielt tatt hensyn til en utenforstående søkemotor, se figur 1, som skal kommunisere med den visuelle komponenten. Kravene for dette avsnittet, FK-IG1 til FK-IG5, finner man i tabell 41 til 45. Søkemotoren vil på sin side søke igjennom en ontologi. Resultatene vil bli sendt og visualisert i den visuelle komponenten. I tillegg vil søkemotoren generere endel ekstrainformasjon, tilleggsattributter, som må kunne visualiseres i komponenten. KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-IG1 Mottak av begrep og relasjoner Komponenten skal kunne motta en liste av begrep og relasjoner fra en annen komponent som skal legges i utvalgslisten. Sammen med disse skal man også motta søkestrengen som ble brukt i søket. Kravet er meget viktig for at komponenten skal kunne fungere sammen med en søkekomponent. Høy Tabell 41: FK-IG1: Mottak av begrep og relasjoner KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-IG2 Mottak av tilleggsattributter Komponenten skal kunne motta tilleggsattributter sammen med de begrepene som mottas fra en annen komponent. Disse vil tilsammen være å finne i utvalgslisten og i informasjonsoversikten. Kravet er viktig for å kunne vise ekstrainformasjon om hvert enkelt begrep. Middels Tabell 42: FK-IG2: Mottak av tilleggsattributter 41

196 Kravspesifikasjon KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-IG3 Endring av søkestreng Brukeren skal kunne gjøre manuelle endringer i søkestrengen som ble mottatt. Kravet er viktig for at komponenten skal kunne fungere fleksibelt sammen med en søkekomponent. Middels Tabell 43: FK-IG3: Endring av søkestreng KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-IG4 Sending av begrep og relasjoner Komponenten skal kunne sende en liste av begrep og relasjoner, samt en ny søkestreng til en annen komponent. Kravet er meget viktig for at komponenten skal kunne fungere sammen med en søkekomponent. Høy Tabell 44: FK-IG4: Sending av begrep og relasjoner KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad FK-IG5 Setting av ontologi En utenforstående komponent må kunne sette hvilken ontologi (OWL-fil) den visuelle komponenten skal visualisere. Begge komponentene må behandle samme ontologi for at et samarbeid mellom dem skal kunne fungere. Høy Tabell 45: FK-IG5: Setting av ontologi 42

197 Kravspesifikasjon 4 Use case Et nyttig verktøy for å formidle innholdet i et funksjonelt krav er tekstlige use case. Sammen med de funksjonelle kravene skal use casene uttrykke kundens ønsker og systemavgrensninger. Formålet med tekstlige use case er å øke forståelsen av kravene kunden har. I tillegg er det et nyttig verktøy for å beskrive de funksjonelle kravene, uten å legge føringer på implementasjonen. Gruppen har også for hvert use case foretatt en use case-estimering. En forklaring av metoden brukt for use case-estimering er gitt i avsnitt Tolking av en OWL-fil Dette use caset, tabell 46, tar for seg kravene FK-HA2, FK-HA3 og FK-HA4 i de funksjonelle kravene. 43

198 Kravspesifikasjon Navn ID Sammendrag Primær aktør Pre-betingelser Post-betingelser Basis sti Tolking av en OWL-fil UC1 I dette steget åpner brukeren en OWL-fil. Denne blir deretter automatisk tolket og konvertert til en grafrepresentasjon. En bruker En OWL-fil eksisterer på lokal disk eller et sted angitt med en URL. OWL-filen er grafrepresentert. 1. Bruker åpner en OWL-fil fra lokal disk. 2. Komponent tolker filen. 3. Komponent utelater egenskaper som ikke skal tas med. 4. Komponent konverterer til grafrepresentasjon. 5. Komponent gir melding om: Hvilke egenskaper som ikke er tatt med, hvilket språk (Full, DL, Lite) OWL-filen var skrevet på og at filen er ferdig tolket/innlastet. Alternativ sti 1. a. Bruker åpner en OWL-fil fra URL. Estimert tid(timer) Aktører: 1 kompleks, Use case: Middels, Poengsum: 13 Tabell 46: UC1 - Tolking av en OWL-fil 44

199 Kravspesifikasjon 4.2 Søking med fritekst i grafen som ligger i hovedvindu. Dette use caset, tabell 47, tar for seg kravene FK-SE1, FK-SE2 og FK-SE3 i de funksjonelle kravene. 45

200 Kravspesifikasjon Navn ID Sammendrag Primær aktør Pre-betingelser Post-betingelser Basis sti Søking i grafen UC2 Brukeren søker med fritekst etter begrep og individer i grafen. Resultatene vises i en resultatliste. Brukeren kan velge hvilket resultat som skal sentreres i hovedvinduet. En bruker En graf foreligger. En resultatliste. 1. Brukeren skriver navnet på et begrep eller flere begrep i et søkefelt. 2. Komponenten viser en resultatliste med resultatene av søket, som inneholder: begrep individ, med referanse til begrep attributter, med referanse til begrep 3. Brukeren velger et begrep i resultatlisten. 4. Komponenten sentrerer begrepet i hovedvinduet. Alternativ sti 1. a. Brukeren skriver navnet på ett eller flere individ. 1. b. Brukeren skriver navnet på ett eller flere attributtnavn, med eller uten attributtverdier. 3. a. Brukeren velger et individ i resultatlisten. 4. a. Komponenten sentrerer begrepet individet tilhører, i hovedvinduet. 3. b. Brukeren velger et attributt i resultatlisten. 4. b. Komponenten sentrerer begrepet attributtet tilhører, i hovedvinduet. Estimert tid(timer) Aktører: 2 kompleks, Use case: Middels, Poengsum: 16 Tabell 47: UC2 - Søking i grafen 46

201 Kravspesifikasjon 4.3 Oversiktsbildet Dette use caset, tabell 48, tar for seg kravene FK-NA2 og FK-NA3 i de funksjonelle kravene. Her er det viktig å huske at oversiktsbildet alltid skal reflektere grafen i hovedvinduet. Navn ID Sammendrag Primær aktør Pre-betingelser Post-betingelser Basis sti Oversiktsbildet UC3 Komponenten skal til enhver tid vise en oversikt over grafen brukeren jobber med. Brukeren kan navigere i denne og velge hvilken deler av grafen brukeren vil se på. En bruker En graf foreligger. En oppdatert graf foreligger. 1. Brukeren velger å åpne oversiktsbildet av grafen. 2. Komponenten viser et oversiktsbilde. 3. Brukeren velger et utsnitt av oversiktsbildet. 4. Komponenten viser utsnittet i hovedvinduet. Alternativ sti 3. a. Brukeren skalerer grafen i hovedvinduet. 4. a. Utsnittet i oversiktsbildet endres til å reflektere grafen i hovedvinduet. Estimert tid(timer) Aktører: 2 kompleks, Use case: Middels, Poengsum: 16 Tabell 48: UC3 - Oversiktsbildet 47

202 Kravspesifikasjon 4.4 Grafgenerering av begreper i en utvalgsliste Dette use caset, tabell 49, tar for seg kravene FK-BH2, FK-BH3 og FK-BH5 i de funksjonelle kravene. Navn ID Sammendrag Primær aktør Pre-betingelser Post-betingelser Basis sti Grafgenerering av begreper i en utvalgsliste UC4 Brukeren legger til begreper i utvalgslisten. Komponenten genererer en graf av disse. En bruker En graf foreligger. En oppdatert graf foreligger. 1. Brukeren markerer et begrep og legger det til utvalgslisten. 2. Brukeren velger å lage en graf av begrepene i utvalgslisten. 3. Komponenten viser den nye grafen med kun begrepene fra utvalgslisten. 4. Komponenten representerer tydelig med et symbol de delene av den opprinnelige grafen som ikke er med i utvalgslisten. Alternativ sti Estimert tid(timer) Aktører: 2 kompleks, Use case: Middels, Poengsum: 16 Tabell 49: UC4 - Grafgenerering av begreper i en utvalgsliste 48

203 Kravspesifikasjon 4.5 Skjuling av begrep Dette use caset, tabell 50, tar for seg krav FK-BH1 i de funksjonelle kravene. Navn ID Sammendrag Primær aktør Pre-betingelser Post-betingelser Basis sti Skjuling av begrep UC5 Brukeren velger å skjule et begrep. En bruker En graf foreligger En oppdatert graf foreligger 1. Brukeren velger å skjule et begrep. 2. Komponenten skjuler begrepet og alle underbegrepene til det. Dette representeres tydelig med et symbol i grafen. 3. Komponenten viser en oppdateret graf med det skjulte begrep representert med et symbol. Alternativ sti Estimert tid(timer) Aktører: 1 kompleks, Use case: Enkelt, Poengsum: 8 Tabell 50: UC5 - Skjuling av begrep 49

204 Kravspesifikasjon 4.6 Ekspandering av symbol Dette use caset, tabell 51, tar for seg krav FK-NA4 i de funksjonelle kravene. Navn ID Sammendrag Primær aktør Pre-betingelser Post-betingelser Basis sti Ekspandering av symbol UC6 Brukeren velger å ekspandere skjulte deler av grafen. En bruker En skjult del av grafen, representert ved et symbol, foreligger En oppdatert graf foreligger 1. Brukeren velger å ekspandere et symbol/en skjult del av grafen. 2. Komponenten ekspanderer den skjulte delen med ett nivå. 3. Komponenten skjuler det resterende med det samme symbolet for skjult graf. Alternativ sti Estimert tid(timer) Aktører: 1 kompleks, Use case: Enkelt, Poengsum: 8 Tabell 51: UC6 - Ekspandering av symbol 50

205 Kravspesifikasjon 4.7 Velging av underbegrep til et markert begrep Dette use caset, tabell 52, tar for seg krav FK-BH6 i de funksjonelle kravene. Navn ID Sammendrag Primær aktør Pre-betingelser Post-betingelser Basis sti Velging av underbegrep til et markert begrep UC7 Brukeren velger hvilke direkte underbegrep, til et markert begrep, som skal vises i hovedvinduet. Dette utføres gjennom en oversikt over hvilke direkte underbegrep som finnes for et markert begrep. En bruker En oversikt over hvilke direkte underbegrep til et markert begrep foreligger. En oppdatert graf foreligger. 1. Brukeren velger hvilke direkte underbegrep, til et markert begrep, som skal vises. 2. Komponenten viser disse valgene i grafen i hovedvinduet. Alternativ sti Estimert tid(timer) Aktører: 1 kompleks, Use case: Enkel, Poengsum: 8 Tabell 52: UC7 - Velging av underbegrep til et markert begrep 51

206 Kravspesifikasjon 4.8 Visning av individer for et markert begrep Dette use caset, tabell 53, tar for seg krav FK-BH7 i de funksjonelle kravene. Viktig i dette use caset å være klar over at individer av underbegrep, også er individer av hovedbegrepet. Navn ID Sammendrag Primær aktør Pre-betingelser Post-betingelser Basis sti Visning av individer for et markert begrep UC8 Brukeren velger hvilke direkte individer til et markert begrep som skal vises. Vil brukeren ha individer av underbegrep til det markerte begrepet velger brukeren hvor mange nivå som skal vises. Dette gjøres gjennom en oversikt som viser alle individene til et markert begrep. En bruker En oversikt over individene til et markert begrep foreligger. En oppdatert graf foreligger. 1. Brukeren velger hvilke direkte individer til et markert begrep som skal vises. 2. Komponenten viser nå kun de valgte individene i grafen i hovedvinduet. Alternativ sti Estimert tid(timer) Aktører: 1 kompleks, Use case: Enkel, Poengsum: 8 Tabell 53: UC8 - Visning av individer for et markert begrep 52

207 Kravspesifikasjon 4.9 Visning og utvelging av informasjon om markert begrep Dette use caset, tabell 54, tar for seg kravene FK-BH8 og FK-BH9 i de funksjonelle kravene. Navn ID Sammendrag Primær aktør Pre-betingelser Post-betingelser Basis sti Visning og utvelging av informasjon om markert begrep. UC9 Brukeren kan få opp informasjon om et markert begrep. Denne informasjonen vises i en oversikt. Brukeren har mulighet til å velge hvilken informasjon som skal vises i oversikten. En bruker Et begrep er markert. En visning av informasjon om et begrep. 1. Brukeren velger å få opp informasjon om et begrep. 2. Komponenten viser denne informasjonen i en oversikt. Alternativ sti 3. Brukeren velger bort de informasjonselementene som ikke er interessante. 4. Komponenten viser utvalget. Estimert tid(timer) Aktører: 1 kompleks, Use case: Enkel, Poengsum: 8 Tabell 54: UC9 - Visning og utvelging av informasjon om markert begrep. 53

208 Kravspesifikasjon 4.10 Lagring og åpning av en sesjon Disse use casene, tabell 55 og tabell 56, tar for seg kravene FK-FB1 og FK- FB2 i de funksjonelle kravene. Ved lagring vil komponenten ta vare på de valg og innstillinger som er gjort i grensesnittet som tilbys av komponenten. Navn ID Sammendrag Primær aktør Pre-betingelser Post-betingelser Basis sti Lagring av en sesjon UC10 Brukeren kan lagre en sesjon; lagre de innstillinger og valg brukeren har gjort, samt grafen slik den er på det tidspunktet. En bruker En OWL-fil er åpnet. Lagret sesjon. 1. Brukeren lagrer en sesjon. 2. Komponenten tar vare på innstillingene og valgene til brukeren, samt grafen i hovedvinduet. Alternativ sti Estimert tid(timer) Aktører: 1 kompleks, Use case: Enkel, Poengsum: 8 Tabell 55: UC10 - Lagring av en sesjon 54

209 Kravspesifikasjon Navn ID Sammendrag Primær aktør Pre-betingelser Post-betingelser Basis sti Åpning av en sesjon UC11 Brukeren kan åpne en lagret sesjon, og det vil da virke som om brukeren begynner der brukeren slapp. En bruker En lagret sesjon, og OWL-filen knyttet til sesjonen er åpnet. En graf foreligger. 1. Brukeren åpner en lagret sesjon. 2. Komponenten henter fram innstillingene som var før sesjonen ble lagret, samt grafen slik den var, og viser for brukeren. Alternativ sti Estimert tid(timer) Aktører: 1 kompleks, Use case: Enkel, Poengsum: 8 Tabell 56: UC11 - Åpning av en sesjon 55

210 Kravspesifikasjon 4.11 Egendefinerte filtre Dette use caset, tabell 57, tar for seg kravene FK-FI2 og FK-FI3 i de funksjonelle kravene. Navn ID Sammendrag Primær aktør Pre-betingelser Post-betingelser Basis sti Egendefinerte filtre UC12 Brukeren kan lagre egne filtre ved å velge fra en oversikt hvilke elementer filteret skal filtrere på. En bruker En oversikt over elementer å filtrere på. Egendefinert filter. 1. Brukeren velger å lage et eget filter. 2. Komponenten viser en oversikt over hvilke elementer det kan filtreres på. 3. Brukeren velger hvilke elementer det skal filtreres på. 4. Brukeren velger å lagre filterinnstilllingene. 5. Brukeren filtrerer grafen med filteret. 6. Komponent viser filtrert graf. Alternativ sti 4. a. Brukeren lagrer ikke filterinnstillingene. Estimert tid(timer) Aktører: 3 kompleks, Use case: Middels, Poengsum: 19 Tabell 57: UC12 - Egendefinerte filtre 56

211 Kravspesifikasjon 4.12 Mottak av begreper, relasjoner og tilleggsattributter Dette use caset, tabell 58, tar for seg kravene FK-IG1 og FK-IG2 i de funksjonelle kravene. Navn ID Sammendrag Primær aktør Pre-betingelser Post-betingelser Basis sti Mottak av begreper, relasjoner og tilleggsattributter UC13 Komponenten kan motta data fra en annen komponent. Den visuelle komponenten. Dataen fra den utenforstående komponenten har riktig struktur, og er fra den samme OWL-filen som den visuelle komponenten har. En søkestreng foreligger. 1. En utenforstående komponent sender data til den visuelle komponenten. 2. Komponenten legger begreper og relasjoner i utvalgslisten. 3. Komponenten legger tilleggsattributtene normalfaktor og frekvens i utvalgslisten, bak de tilhørende begrepene. 4. Komponenten legger andre tilleggsattributter i informasjonsoversikten. 5. Søkestrengen som ble brukt i søket vises i et søkefelt. Alternativ sti Estimert tid(timer) Aktører: 1 middels, Use case: Middels, Poengsum: 12 Tabell 58: UC13 - Mottak av begreper, relasjoner og tilleggsattributter 57

212 Kravspesifikasjon 4.13 Use case-estimering Use case-modellene beskriver funksjonaliteten til komponenten. Attributter ved use case-modellen kan dermed brukes som et mål på størrelsen til komponenten som skal lages. For å estimere størrelsen til komponenten har gruppen brukt en metode Use Case Points Method [2]. Denne metoden ble anbefalt fra fagstaben i faget TDT Kundestyrt Prosjekt som dette prosjektet utføres under. For å gjennomføre utregningene som denne metoden krever har gruppen brukt regnearket som er gjort tilgjengelige på fagsidene i faget 4 [1]. Dette regnearket er vist i figur 3 med gruppens use case-estimering. Metoden for estimering krever at det skal være mulig å telle antall steg i hvert av use casene gruppen har laget. Metoden består av fire punkter. Det første punktet er å identifisere aktørene i de ulike use casene og kategorisere disse etter følgende kriterier: En enkel aktør er et annet system med et definert programmeringsgrensesnitt. En gjennomsnittlig aktør er enten at annet system som kommuniserer via en protokoll, f.eks. TCP/IP, eller en person som kommuniserer via et tekstbasert grensesnitt. En kompleks aktør er en person som kommuniserer via et grafisk grensesnitt. Antall aktører i hver kategori fra alle use casene føres inn i regnearket. Dette er vist i figur 3. Det andre punktet består i å kategorisere use casene gruppen har skrevet. Kategoriene er som følger: Et enkelt use case har 3 eller færre steg. Et gjennomsnittlig use case har 4 til 7 steg. Et komplekst use case har 8 eller flere steg. Hvor mange use case som havner i hver kategori er ført inn i regnearket i figur 3. 4 Fagsidene til TDT4290 er på 58

213 Kravspesifikasjon I tabell 59 finner man use case-poeng for hvert use case. Summen av use case-poengene for alle use casene kalles unadjusted use case points. Dette kan man også finne igjen i figur 3. ID Navn Referanse Estimert tid UC1 Tolking av OWL-fil Tabell UC2 Søking i grafen Tabell UC3 Oversiktsbilde Tabell UC4 Grafgenerering av begrep i utvalgsliste Tabell UC5 Skjuling av begrep Tabell 50 8 UC6 Ekspandering av begrep Tabell 51 8 UC7 Velging av underbegrep til et markert begrep Tabell 52 8 UC8 Vising av individer for markert begrep Tabell 53 8 UC9 Vising og utvelging av informasjon om markert begrep Tabell 54 8 UC10 Lagring av en sesjon Tabell 55 8 UC11 Åpning av en sesjon Tabell 56 8 UC12 Egendefinerte filter Tabell UC13 Mottak av begreper, relasjoner og tilleggsattributter Tabell Sum 148 Tabell 59: Oppsummering av usecase estimering I de to neste punktene ønsker man å justere unadjusted use case points ved å angi en verdi til en del kontekst- og miljøfaktorer. Disse faktorene kan man finne i figur 3 med angitt verdi. Etter en utregning av disse faktorene vil man få use case points. Deretter må man vurdere hvor mange persontimer som vil brukes per use case-poeng. Dette er i figur 3 satt til 20 timer. Metoden estimerer at gruppen kommer til å bruke 1941 timer totalt på implementasjon av funksjonalitet som dekker alle definerte use case. 59

214 Kravspesifikasjon Figur 3: Use case-estimat 60

215 Kravspesifikasjon 5 Ikke-funksjonelle krav Ikke-funksjonelle krav er alle krav som ikke går direkte på de spesifikke funksjonene til komponenten. Disse kravene skal være så målbare og konkrete som mulig, slik at det er lett å se om de er oppfylt i etterkant. KravID Referanse Navn Viktighetsgrad IFK-GK1 Tabell 61 Implementasjonspråk Høy IFK-GK2 Tabell 62 Portabilitet Middels IFK-GK3 Tabell 63 Robusthet Høy IFK-GK4 Tabell 64 Skifte språk Lav IFK-GK5 Tabell 65 Implementasjon av egendefinerte filter Høy IFK-BG1 Tabell 66 Tilstandsfullt brukergrensesnitt Høy IFK-BG2 Tabell 67 Applikasjonspråk Høy IFK-BG3 Tabell 68 Gjenkjennbarhet Middels IFK-BG4 Tabell 69 Navigering uten mus Lav IFK-BG5 Tabell 70 Spesialtegn Middels IFK-BG6 Tabell 71 Relasjonsnavn Høy IFK-KY1 Tabell 72 Responstid Middels IFK-KY2 Tabell 73 Ontologistørrelse Høy IFK-KY3 Tabell 74 Minstekrav til PC Høy IFK-DOK1 Tabell 75 Utvidbarkode Lav IFK-DOK2 Tabell 76 Installasjon Middels IFK-DOK3 Tabell 77 Installasjonsveiledning Lav IFK-DOK4 Tabell 78 JavaDoc Middels Tabell 60: Oppsummeringstabell for ikke-funksjonelle krav 5.1 Generelle krav Dette avsnittet inneholder de generelle kravene til komponenten. De forretningsmessige kravene De forretningsmessige kravene FM2, FM3, FM5, FM8 og FM11 danner grunnlaget for disse kravene. Generelle ikke-funskjonelle krav finnes i tabellene 61 til

216 Kravspesifikasjon KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad IFK-GK1 Implementasjonspråk Kildekoden til komponenten skal skrives i Java. Dette er et forretningsmessig krav (FM2). Høy Tabell 61: IFK-GK1: Implementasjonspråk KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad IFK-GK2 Portabilitet Kunden skal kunne vise programmet videre til sine kunder, og disse kan bruke forskjellige operativsystemer. Dette gjør at man må ha mulighet til å kjøre programmet i flere operativsystemer: Windows, Unix/Linux og MacOS. Mulighet for å kjøre komponenten på flere OS øker tilgjengeligheten. Middels Tabell 62: IFK-GK2: Portabilitet 62

217 Kravspesifikasjon KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad IFK-GK3 Robusthet Komponenten skal være robust. Med dette menes at komponenten skal kunne lese og vise ontologier større enn spesifisert i IFK-KY2 uten å feile. Det kan da aksepteres at det brukes lengre tid enn spesifisert i IFK-KY3. Ontologier er ofte mye større enn hva som er spesifisert i IFK-KY2. Høy Tabell 63: IFK-GK3: Robusthet KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad IFK-GK4 Skifte språk Språket i brukergrensesnittet skal være enkelt å skifte uten å måtte forandre kildekoden. Ikke alle brukerene er gode i engelsk. Lav Tabell 64: IFK-GK4: Skifte språk KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad IFK-GK5 Implementasjon av egendefinerte filter Det skal være mulig å implementere egne filter til komponenten. Det er veldig aktuelt for kunden å implementere egne filter. Høy Tabell 65: IFK-GK5: Implementasjon av egendefinerte filter 63

218 Kravspesifikasjon 5.2 Brukergrensesnitt Kravene under omhandler brukervennligheten til komponenten, med fokus på utseende og funksjonalitet. De forretningsmessige kravene FM1, FM7 og FM13 danner grunnlaget for kravene i dette avsnittet. Ikke-funksjonelle krav til brukergrensesnitt finnes i tabellene 66 til 71. KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad IFK-BG1 Tilstandsfullt brukergrensesnitt Brukergrensesnittet skal gjenspeile tilstanden til komponenten og skjule ugyldige funksjoner avhengig av denne. Som et eksempel kan funksjonen Lagre filter gjøres utilgjengelig dersom det aktive filteret ikke er endret. Det er viktig at komponenten er mest mulig brukbar og ikke gir brukeren feil inntrykk av tilstanden sin. Høy Tabell 66: IFK-BG1: Tilstandsfullt brukergrensesnitt KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad IFK-BG2 Brukergrensesnittspråk Standard applikasjonsspråk skal være engelsk. Engelsk forstås av flest i brukergruppen. Høy Tabell 67: IFK-BG2: Brukergrensesnittspråk 64

219 Kravspesifikasjon KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad IFK-BG3 Gjenkjennbarhet Brukergrensesnittet skal ved å bruke standard widgets (widgets er funksjoner/virkemåter som går igjen i de fleste applikasjoner.) som gjøre at brukeren enkelt vil gjenkjenne og forstå bruken av deler av komponenten. Reduserer tiden en bruker trenger for å lære å bruke programmet Middels Tabell 68: IFK-BG3: Gjenkjennbarhet KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad IFK-BG4 Navigasjon uten mus Det skal være mulig å navigere i komponenten uten bruk av mus. Det kan finnes situasjoner der mus ikke er tilgjengelig. Lav Tabell 69: IFK-BG4: Navigasjon uten mus KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad IFK-BG5 Spesialtegn Programmet skal kunne håndtere og vise tegn som æ,ø og å. Mange ontologier inneholder ord med disse tegnene. Medium Tabell 70: IFK-BG5: Spesialtegn KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad IFK-BG6 Relasjonsnavn Relasjoner skal inneholde beskrivende navn. Et beskrivende navn på relasjonen øker lesbarheten til grafen. Høy Tabell 71: IFK-BG6: Relasjonsnavn 65

220 Kravspesifikasjon 5.3 Kapasitet og ytelse Dette avsnittet behandler krav til reponstiden for komponenten og informasjonsmengden komponentet skal kunne håndtere, jamfør de forretningsmessige kravene FM6 og FM7. Ikke-funksjonelle krav til kapasitet og ytelse finnes i tabellene 72 til 74. KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad IFK-KY1 Responstid Den lengste tiden brukeren skal måtte vente på komponenten er ett minutt for innlasting av OWL-filer. Andre operasjoner skal ikke ta lengre enn 30 sekunder, så lenge komponenten kjøres på en PC jamfør IFK-KY3 og ontologien er like stor som eller mindre enn spesifisert i IFK-KY2. Dette er et forretningsmessig krav (FM6). Middels Tabell 72: IFK-KY1: Responstid KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad IFK-KY2 Ontologistørrelse Komponenten skal kunne visualisere en ontologi på 1000 begrep og 5000 relasjoner. Dette er et forretningsmessig krav (FM7). Høy Tabell 73: IFK-KY2: Ontologistørrelse 66

221 Kravspesifikasjon KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad IFK-KY3 Minstekrav til PC Komponenten skal kunne kjøres på en bærbar PC med 1.4Ghz prosessor og 512MB RAM, og følge responstidene nevnt i IFK-KY1. Det er viktig å kunne visualisere en graf innenfor de nevnte responstidene på en PC med de nevnte spesifikasjonene. Høy Tabell 74: IFK-KY3: Minstekrav til PC 67

222 Kravspesifikasjon 5.4 Dokumentasjon Dette avsnittet stiller krav til hvilken dokumentasjon som skal følge komponenten, og hva denne skal inneholde. Kravene dekker det forretningsmessige kravet FM12. Kravene i dette avsnittet er oppsummert i tabell 60. Ikkefunskjonelle krav til dokumentasjon finnes i tabellene 75 til 78. KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad IFK-DOK1 Utvidbar kode Dokumentasjonen for komponenten skal inneholde en prosedyral beskrivelse av hvordan man legger til ny funksjonalitet til de ulike delene av komponenten. God dokumentasjon gjør det noe enklere å legge til funksjonalitet. Lav Tabell 75: IFK-DOK1: Utvidbar kode KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad IFK-DOK2 Installasjon Det skal følge med en form for installsjonsveileder som gjør at programmet kan installeres på under 10 minutter. Komponenten skal være så enkel som mulig å installere. Middels Tabell 76: IFK-DOK2: Installasjon 68

223 Kravspesifikasjon KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad IFK-DOK3 Installasjonsveiledning Det skal følge med en installasjonsveiledning til komponenten. Denne skal punktvis og oversiktelig forklare hvordan man installerer komponenten. Det skal være mulig for en person uten særlig kunnskap om komponenten å installere den. Lav Tabell 77: IFK-DOK3: Installasjonsveiledning KravID Navn Beskrivelse Viktighetsvurdering Viktighetsgrad IFK-DOK4 JavaDoc Kildekoden til komponenten skal dokumenteres i henhold til JavaDoc-standarden. Komponenten skal videreutvikles av DiB. JavaDoc gjør det enklere for dem å gjøre dette. Middels Tabell 78: IFK-DOK4: JavaDoc 69

224 Kravspesifikasjon 6 Konstruksjon og implementasjon Etter å ha fått på plass alle de funksjonelle kravene har gruppen innsett at det vil ta mer tid enn tilgjengelig å få implementert alle kravene. Dette støttes av use case-estimeringen fra avsnitt Estimatet for å implementere use case-ene er langt større enn den tid gruppen har planlagt å bruke på implementasjonsfasen og ligger oppimot tiden tilgjengelig for prosjektet totalt. Gruppen har derfor bestemt, sammen med kunden, at inkrementelle konstruksjonsog implementasjonsfaser er hensiktsmessig. På den måten får gruppen i verste fall utviklet en enkel prototype med de mest grunnleggende av funksjonalitet. Deretter kan det legges til mer funksjonalitet i de etterfølgende inkrementene. De ikke-funksjonelle kravene er også fordelt på inkrementene. Enkelte av disse er gjeldende for alle inkrementene. Derfor anses ikke-funksjonelle krav som er med i tidlige inkrement å gjelde for alle inkrementene etter. 6.1 Vekting og inkrementinndeling Vektingen av kravene har foregått ved å se på ett og ett krav, og gi det en viktighetsvurdering og en viktighetsgrad høy, middels eller lav. Det har med andre ord ikke blitt sett på sammenhengen mellom kravene når vekting ble gjennomført. I inkrementinndelingen ble det fokusert på to ting: hvilke krav som henger sammen med tanke på funksjonalitet og som det dermed er naturlig å implementere samtidig viktighetsvurderingen av kravene. Siden få av kravene kan utvikles i isolasjon, men er avhengig av andre for å kunne gi nyttig funksjonalitet, vil enkelte krav med høy viktighetsvurdering havne i tredje inkrement, mens krav med lav viktighetsvurdering kan bli plassert allerede i første inkrement. 70

225 Kravspesifikasjon 6.2 Første inkrement I første inkrement er det blitt bestemt at gruppen skal konsentrere seg om de mest grunnleggende funksjonene til komponenten. Målet er å få på plass en komponent som kan tolke en OWL-fil, lage en grafrepresentasjon av de OWLegenskapene i OWL-Lite som er valgt ut (se avsnitt 2.1.2), og visualisere dette. I tillegg skal det være mulig å velge å få fram informasjon om et begrep. Den siste delen har blitt tatt med for å sørge for at komponenten får med alle egenskapene i OWL-Lite som er valgt ut. Komponenten skal gi tilbakemeldinger om hvilke egenskaper som ikke er med og hvilket språk OWL-filen er skrevet på (Lite, DL eller Full). Ved feil i lesingen skal det også gis tilbakemelding om det, og hva som var feil. Kravene som skal være med i første inkrement er oppsummert i tabell

226 Kravspesifikasjon KravID Navn Referanse FK-HA1 Håndtering av OWL-typer Tabell 11 FK-HA2 Åpning av OWL-fil fra disk Tabell 12 FK-HA3 Åpning av OWL-fil fra URL Tabell 13 FK-HA4 Tolking av OWL-fil Tabell 14 FK-HA5 Syntaksfeil i OWL-fil Tabell 15 FK-HA6 Dataignorering i OWL-fil Tabell 16 FK-HA7 OWL-type Tabell 17 FK-FI1 Predefinerte filtre Tabell 26 FK-BH2 Velging av begrep Tabell 31 FK-BH8 Visning av informasjon om markert begrep Tabell 37 FK-BG1 Ontologi som graf Tabell 5 FK-BG3 Relasjoner Tabell 7 FK-BG4 Navn på noder Tabell 8 FK-BG5 Nodestørrelse Tabell 9 IFK-GK1 Implementasjonsspråk Tabell 61 IFK-GK2 Portabilitet Tabell 62 IFK-GK3 Robusthet Tabell 63 IFK-GK4 Skifte språk Tabell 64 IFK-BG2 Brukergrensesnitt Tabell 67 IFK-BG3 Gjenkjennbarhet Tabell 68 IFK-BG5 Spesialtegn Tabell 70 IFK-KY1 Responstid Tabell 72 IFK-KY2 Ontologistørrelse Tabell 73 IFK-KY3 Minstekrav til PC Tabell 74 IFK-DOK4 JavaDoc Tabell 78 Tabell 79: De kravene som er med i 1. inkrement 72

227 Kravspesifikasjon 6.3 Andre inkrement I andre inkrement er det blitt bestemt at gruppen skal utvide komponenten med flere funksjoner angående navigasjon i graf. Målet er å få på plass muligheter til å søke i grafen og sentrere rundt valgte treff, navigasjon i grafen via oversiktsvindu, skalering i grafen, skjuling av deler av grafen, ekspansjon av skjulte deler av grafen, legge til eller fjerne begreper fra utvalgslisten og et vindu for å velge hvilke underbegrep og individer som skal vises i hovedvinduet. Kravene som skal være med i andre inkrement er oppsummert i tabell 80. KravID Navn Referanse FK-BG2 Manipulasjon av støttevinduer Tabell 6 FK-NA1 Skalering av graph Tabell 18 FK-NA2 Oversiktsbilde Tabell 19 FK-NA3 Navigasjon i oversiktsbilde Tabell 20 FK-NA4 Ekspansjon av symbol Tabell 21 FK-SE1 Søk i grafen Tabell 23 FK-SE3 Behandling i søkeresultat Tabell 25 FK-BH1 Skjuling av begrep Tabell 30 FK-BH3 Innsetting av begrep i utvalgsliste Tabell 32 FK-BH4 Fjerning av begrep fra utvalgsliste Tabell 33 FK-BH5 Grafgenerering av begrep i utvalgsliste Tabell 34 FK-BH6 Visning/velging av underbegrep til valgt begrep Tabell 35 FK-BH7 Visning/velging av individer til begrep Tabell 36 IFK-BG6 Relasjonsnavn Tabell 71 IFK-DOK1 Utvidbar kode Tabell 75 Tabell 80: De kravene som er med i 2. inkrement 6.4 Tredje inkrement I tredje inkremet skal de resterende kravene implementeres. Målet er å få ferdigstilt komponenten i henhold til kravene fra kunden. Kravene som skal være med i tredje inkrement er oppsummert i tabell

228 Kravspesifikasjon KravID Navn Referanse FK-BG6 Meldinger Tabell 10 FK-NA5 Utvidelse i alle retninger Tabell 22 FK-SE2 Søking med attributter i grafen Tabell 24 FK-FI2 Egendefinerte filtre Tabell 27 FK-FI3 Lagring av filtre Tabell 28 FK-FI4 Åpning av filtre Tabell 29 FK-BH9 Utvelging av informasjon om markert begrep Tabell 38 FK-FB1 Lagring av sesjon Tabell 39 FK-FB2 Åpning av sesjon Tabell 40 FK-IG1 Mottak av begrep og relasjoner Tabell 41 FK-IG2 Mottak av tilleggsattributter Tabell 42 FK-IG3 Endring av søkestreng Tabell 43 FK-IG4 Sending av begrep og relasjoner Tabell 44 FK-IG5 Setting av ontologi Tabell 45 IFK-GK5 Implementasjon av egendefinerte filter Tabell 65 IFK-BG1 Tilstandsfullt brukergrensesnitt Tabell 66 IFK-BG4 Navigasjon uten mus Tabell 69 IFK-DOK2 Installasjon Tabell 76 IFK-DOK3 Installasjonsveiledning Tabell 77 Tabell 81: De kravene som er med i 3. inkrement 74

229 Kravspesifikasjon Referanser [1] Bente Anda. Project estimation method (excel sheet), [2] Dag I.K. Sjøberg og Magne Jørgensen Bente Anda, Hege Dreiem. Estimating software development effort based on use cases - experiences from industry [3] Kundestyrt prosjekt, gruppe 14: Ontologidrevet dokumentforvaltning, forstudie, [4] Institute of Electrical and Inc. (IEEE) Electronic Engineers. Ieee recommended practice for software requirements specifications,

230 Ontologidrevet dokumentforvaltning Konstruksjon TDT4290 Kundestyrt prosjekt Institutt fra datateknikk og informasjonsvitenskap Fakultet for informasjonsteknologi, matematikk og elektroteknikk Norges teknisk-naturvitenskapelige universitet Gruppe 14 Espen Hansen Ole-Marius Moe-Helgesen Geir Storli Karl Hatteland Steinar Skjerven Håvard Stranden

231

232 Konstruksjon Innhold 1 Innledning Oversikt Definisjoner Overordnet systembeskrivelse Designstrategi Hendelser Modularisering Moduler graph-modul filter-modul io-modul event-modul gui-modul Avhengighetsbeskrivelse 15 4 Detaljert design for første inkrement Moduler Klasser i graph-modulen Klasser i filter-modulen Klasser i event-modulen Klasser i gui-modulen Klasser i io-modulen Sekvensdiagram Tolking av OWL-fil

233 Konstruksjon Vising av informasjon om markert begrep Filtrering Utlegg av graf Oppdatering av filtrert graf Referanser 41 3

234 Konstruksjon Figurer 1 Hvordan hendelser påvirker utførelsen av kildekoden Avhengigheten mellom modulene Avhengighet mellom modulene i første inkrement Klassene i graph-modulen Klassene i filter-modulen Klassene i event-modulen Klassene i gui-modulen Prototyp for menyen Prototyp for hovedvinduet Prototyp for informasjonsvinduet Klassen i io-modulen Tolking av OWL-fil Markering av begrep Filtrering av graf Utlegg av graf Oppdatering av filtrert graf

235

236 Konstruksjon 1 Innledning I henhold til kundens ønsker vil dette prosjektet produsere et bibliotek som tilbyr enkel implementasjon av visualisering av ontologier og ikke en selvstendig komponent som beskrevet i tidligere dokumenter i prosjektet. Konstruksjonsdokumentet skal legge grunnlaget for implementasjonen. Dette gjøres ved å beskrive hvordan biblioteket skal bygges opp for å oppfylle kravene i kravspesifikasjonen. Dokumentet er basert på dokumentstandarden IEEE 1016 [6]. 1.1 Oversikt Kapittel 2 omhandler den overordnede systembeskrivelsen. Denne tar for seg designstrategier og forklarer grensesnittene mellom modulene. Kapittel 3 beskriver avhengigheter mellom modulene. Kapittel 4 omhandler det detaljerte design hvor klassene og sekvensdiagrammene blir forklart på et slikt nivå at man er klar for implementasjon. 1.2 Definisjoner I biblioteket vil alle delvinduer som tilbys være klasser som arver fra Swingklasser slik at DiB kan benytte disse til å sette sammen en applikasjon slik de selv ønsker. Delvinduene som tilbys i biblioteket vil være de samme som ble omtalt i dette prosjektets kravspesifikasjon [4]. Gruppen vil også benytte disse klassene i en test-applikasjon. Hensikten med denne er å kunne vise resultatene fra implementasjons- og konstruksjonsfasene og for å forenkle utviklingen av biblioteket. Da denne applikasjonen ikke vil bli benyttet av eksterne brukere, vil brukbarhetstester ikke bli utført som en del av prosjektet. Definisjoner Under følger en liste over definisjoner av noen av ordene som brukes i dokumentet. Disk: Brukt i forbindelse med å laste inn OWL-fil fra disk. Disk betyr 6

237 Konstruksjon harddisk, cd eller annet lagringsmedium som finnes lokalt på datamaskinen. Bibliotek: En samling klasser som i fellesskap gir tilgang til én eller flere funksjoner. På engelsk kalles dette Application Programming Interface, og i dette prosjektets tilfelle vil biblioteket tilby vinduskomponenter og støttefunksjoner for disse. Moduler: Større komponenter som biblioteket deles opp i. Alle klasser ligger under én modul, og alle klasser i samme modul har nærliggende funksjoner. For eksempel vil alle klasser som omhandler hendelser ligge i modulen event. Grensesnittklasse: I moduler som har mye intern logikk eller mange klasser som kildekode utenfor ikke skal ha tilgang til, vil det bli tilbudt en grensesnittklasse. I slike tilfeller vil denne være eneste innfallspunkt til modulen og utenforliggende kildekode skal benytte denne for å få tilgang til, eller utføre operasjoner i, andre klasser i modulen. Avsnitt gir en nærmere beskrivelse av grensesnittklasser. 7

238 Konstruksjon 2 Overordnet systembeskrivelse Kapittelet gir en oversikt over de viktigste designbeslutningene som er tatt og begrunnelsene for disse. I avsnitt 2.2 følger også en overordnet beskrivelse av de ulike modulene biblioteket består av. Den overordnede systembeskrivelsen gjelder for alle inkrementene som ble bestemt i kravspesifikasjonen [4]. 2.1 Designstrategi Da gruppen la opp en overordnet designstrategi 1 for utviklingen av biblioteket, ble det lagt fokus på følgende: Kildekode utenfor biblioteket skal ha tilgang til hendelser som oppstår i biblioteket. Dette kan for eksempel dreie seg om når en ontologi er lastet fra fil, når en bruker har sentrert grafen på et nytt begrep eller om OWL-filen inneholder feil. Bruken av biblioteket skal være så enkelt som mulig og derfor må det unngås at grensesnittet utad blir for komplekst. Det skal legges til rette for enkelt vedlikehold og videreutvikling. De neste delavsnittene forklarer nærmere om bruk av hendelser og modularisering, de to overordnede designstrategiene gruppen har valgt Hendelser Designmønsteret for hendelser skal benyttes for å sende data både ut av biblioteket og internt på tvers av moduler. Å benytte hendelser innebærer at alle objekter som har tilgang til et objekt Kilde kan legge til lyttere til en hendelse som Kilde tilbyr. Kilde vil informere alle lytterne når en hendelse av den ønskede typen oppstår. I figur 1 kan man se et eksempel på hvordan hendelser påvirker utførelsen av kildekoden. En hendelse sendes inn til metoden handle() hos klassene som lytter på hendelsen. Disse utføres én etter én. Dette medfører at om flere klasser lytter på samme hendelse, utføres handle() på første lytter før den neste settes i gang. brukt. 1 Med designstrategi i denne sammenheng menes overordnede designmønstre som ønskes 8

239 Konstruksjon Figur 1: Hvordan hendelser påvirker utførelsen av kildekoden 9

240 Konstruksjon Modularisering For å forenkle konstruksjons- og implementasjonsfasene har gruppen valgt å dele biblioteket opp i mest mulig enkeltstående moduler. Kommunikasjon på tvers av moduler kan kun foregå på to måter. Den første av disse er hendelser, som beskrevet i forrige avsnitt, og den andre er å benytte seg av grensesnittsklassene for modulene. For mindre moduler, som io, er det ikke lagt opp til grensesnittklasser, men direkte kommunikasjon med klassene i modulen. En grensesnittklasse er en klasse som ligger i forkant av hver modul. Kommunikasjon inn til modulen skal gå gjennom denne. Begrunnelsen for et slikt design er å begrense antallet avhengigheter mellom modulene. Ved at andre moduler ikke er avhengig av hvordan en modul er implementert internt kan de betrakte den som en sort boks. Dette vil kraftig forenkle fremtidig vedlikehold. Feilsøking både under og etter utviklingen blir også lettere ettersom antall klasser som bruker en klasse begrenses. Grensesnittklassen er modellert etter designmønsteret Facade fra boken Design Patterns: Elements of Reusable Object-Oriented Software [3]. Alle grensesnittklassene skal i utgangspunktet være statiske klasser, men da enkelte av de vil kreve bruk av Spin 2 og dermed må være objekter, vil grensesnittklassene bli implementert som singleton-klasser. Disse følger designmønsteret Singleton fra boken nevnt over. 2.2 Moduler I tabell 1 er oppsummeringstabellen for de funksjonelle kravene fra kravspesifikasjonen gjengitt. De følgende avsnittene vil forklare hva som ligger i de ulike modulene i biblioteket, og hvilke krav fra kravspesifikasjonen de skal dekke. KravID Navn Viktighetsgrad FK-BG1 Ontologi som graf Høy FK-BG2 Manipulering av støttevinduer Middels FK-BG3 Relasjoner Høy FK-BG4 Navn på noder Høy FK-BG5 Nodestørrelse Høy 2 Se prosjektets forstudium for en beskrivelse av Spin. 10

241 Konstruksjon FK-BG6 Meldinger Middels FK-HA1 Håndtering av OWL-typer Høy FK-HA2 Åpning av OWL-fil fra disk Høy FK-HA3 Åpning av OWL-fil fra URL Høy FK-HA4 Tolking av OWL-fil Høy FK-HA5 Syntaksfeil i OWL-fil Lav FK-HA6 Dataignorering i OWL-fil Lav FK-HA7 OWL-type Lav FK-NA1 Skalering av graf Høy FK-NA2 Oversiktsbilde Høy FK-NA3 Navigering i oversiktsvinduet Middels FK-NA4 Ekspandering av symbol Høy FK-NA5 Utvidelse i alle retninger Lav FK-SE1 Søking i grafen Høy FK-SE2 Søking med attributter i grafen Middels FK-SE3 Behandling av resultater etter et søk Høy FK-FI1 Predefinerte filtre Høy FK-FI2 Egendefinerte filtre Middels FK-FI3 Lagring av filtre Middels FK-FI4 Åpning av filtre Middels FK-BH1 Skjuling av begrep Høy FK-BH2 Velging av begrep Høy FK-BH3 Innsetting av begrep i utvalgsliste Lav/Middels FK-BH4 Fjerning av begrep fra utvalgsliste Lav/Middels FK-BH5 Grafgenerering av begrep i en utvalgsliste Høy FK-BH6 Velging av underbegrep til et markert begrep Høy FK-BH7 Visning av individer for et markert begrep Høy FK-BH8 Visning av informasjon om markert begrep Høy FK-BH9 Utvelging av informasjon om markert begrep Lav FK-FB1 Lagring av sesjon Middels FK-FB2 Åpning av sesjon Middels FK-IG1 Mottak av begrep og relasjoner Høy FK-IG2 Mottak av tilleggsattributter Middels FK-IG3 Endring av søkestreng Middels FK-IG4 Sending av begrep og relasjoner Høy FK-IG5 Setting av ontologi Høy Tabell 1: Oppsummeringstabell for funksjonelle krav. 11

242 Konstruksjon graph-modul I denne modulen ligger representasjonen av grafen lagret. Modulen tar seg også av innlasting av ontologier. Kommunikasjon inn til denne modulen foregår gjennom grensesnittklassen GraphManager. GraphManager skal benytte seg av biblioteket Spin for å kunne gjøre lasting og filtrering av ontologier i en egen tråd og dermed holde brukergrensesnittet responsivt. Modulen vil gi gui-modulen data for å dekke brukergrensesnittkravene FG- BG1, FG-BG3, FK-BG4 og FG-BG6. Da lasting av OWL-filer også er en del av graph-modulen, er krav FK-HA1 til FK-HA7 også en del av denne. Navigasjons- og søkekravene vil dekkes delvis av datagrunnlaget fra denne modulen. Filtrering i krav FK-FI1 og FK-FI2 må utføres av graph-modulen, med hjelp av datagrunnlag fra filter. FK-BH5 skal også dekkes av denne modulen, og den skal også tilby datagrunnlag for de andre begrepshåndteringskravene filter-modul I filter-modulen ligger alle klasser som representerer ulike filtre. Dette dreier seg om predefinerte filtre, sammensatte filtre og kombinasjoner av disse. Filtrene legges i en liste representert ved klassen FilterList. Objekter av denne typen benyttes av graph-modulen for å utføre filtreringen. Kommunikasjon inn til denne modulen foregår gjennom grensesnittklassen FilterManager. I denne klassen vil instanser av FilterList som ikke er aktive for øyeblikket lagres slik at de kan hentes frem av brukeren. Listen under gjengir hvilke krav filter-modulen må dekke: Navigasjon og skalering: FK-NA4 og FK-NA5. Søking: FK-SE1 og FK-SE2. Filtrering av graf: FK-FI1, FK-FI2, FK-FI3, FK-FI4. Begrepshåndtering: FK-BH1 og FK-BH5. 12

243 Konstruksjon io-modul io-modulen tilbyr lesing og skriving av filer. gui-modulen og filter-modulen vil benytte denne for henholdsvis sesjons- og filterhåndtering. Modulen graph har også behov for lesing fra fil ved innlasting av ontologier, men Jenabiblioteket som benyttes av graph-modulen også inkluderer fillesing vil ikke io-modulen bli benyttet. Kravene som blir dekket av io-modulen er dermed FK-FI3 og FK-FI4 i samarbeid med filter-moduler for filterlesing og -skriving og FK-FB1 og FK-FB2 sammen med gui-modulen for lagring og åpning av sesjoner event-modul I event-modulen vil alle klasser av typen Event, EventProvider og EventListener samles. Klasser både i andre moduler internt i biblioteket og i annen kildekode vil arve fra Listener-grensesnittene for å kunne motta hendelser. Da kommunikasjonen ligger i de ulike Event-klassene vil det ikke være en egen grensesnittklasse inn til denne modulen. Denne modulen dekker funksjonalitet for de aller fleste funksjonelle krav gui-modul Denne modulen håndterer all interaksjon mellom bruker og bibliotek. Det vil si den representerer informasjonen for brukeren og reagerer med riktig respons på input fra bruker. Denne modulen består av en rekke Swing-paneler som kan benyttes for å sette sammen en fullstendig applikasjon. Disse er MiniGraphWindowController, GraphWindowController, SelectionWindowController, SubclassWindowController og ClassInfoWindowController. gui-modulen vil hente og lagre informasjon til og fra graph- og io-modulene samt benyttte filter-modulen for å instansiere Filter-objekter. Andre interne moduler vil ikke få tilgang til å kommunisere med gui-modulen utenom gjennom hendelser. Kravmessig vil gui-modulen delta i alle de funksjonelle kravene. For hvert krav vil modulen måtte tilby én eller flere måter for brukeren å utføre en 13

244 Konstruksjon funksjon som dekker det. FK-HA1 og FK-HA4 er dog dekket implisitt gjennom andre krav. 14

245 Konstruksjon 3 Avhengighetsbeskrivelse En avhengighet mellom to klasser finnes hvis [2]: en klasse sender en melding til en annen klasse en klasse har en annen klasse som endel av sin informasjon en klasse nevner en annen klasse som en parameter i en operasjon En avhengighet mellom to moduler finnes hvis det er en avhengighet mellom to klasser i modulene. Figur 2 viser designmodulene i biblioteket, og avhengighetene mellom dem. Hver avhengighet er merket med et nummer. Hva de forskjellige avhengighetene innebærer er forklart under. Figur 2: Avhengigheten mellom modulene 1: Modulen gui benytter seg av filter-modulen når en bruker ønsker å lage, oppdatere, aktivere eller slette et filter. For få tilgang til filterlistene vil guimodulen benytte seg av grensesnittklassen FilterManager i filter-modulen. 2: graph-modulen er også avhengig av å bruke filtrene som ligger i filtermodulen når en graf skal filtreres. Modulen vil holde på én aktiv filterliste som den skal få tak i via FilterManager-klassen. 15

246 Konstruksjon 3: gui-modulen kommuniserer med graph-modulen gjennom grensesnittet GraphManager. 4: Ved en rekke ulike anledninger vil graph-modulen sende ut hendelser, og har derfor en avhengighet til event-modulen. Modulen graph har også behov for å lytte etter hendelser. 5: gui-modulen har også en rekke avhengigheter til event-modulen. Dette fordi flere av klassene i modulen vil være tilbydere av hendelser, og lyttere på hendelser. 6: Lagring og åpning av sesjoner og filtre blir initialisert av gui-modulen og utføres av io-modulen. 7: Etter at gui-modulen har initialisert lagring eller åpning av en fil på iomodulen, så vil io-modulen ved hjelp av event-modulen sende ut hendelser. 16

247 Konstruksjon 4 Detaljert design for første inkrement Dette kapittelet beskriver det detaljerte designet for første inkrement. Det betyr at det bare er klasser for første inkrement som er beskrevet og vist i klassediagrammene. De ulike modulene vil bli beskrevet i detalj, klasse for klasse, og for hver modul vil det finnes et UML-klassediagram som beskriver klassene i modulen. I tillegg vil rollene og funksjonaliteten til klassene forklares, og det presenteres sekvensdiagram som beskriver sekvensflyt mellom klassene. Sekvensdiagrammene er laget ut fra use casene i kravspesifikasjonen [4]. I figur 3 vises en oversikt over modulene i første inkrement og avhengighetene mellom disse. Figur 3: Avhengighet mellom modulene i første inkrement 4.1 Moduler Dette avsnittet beskriver de ulike modulene biblioteket er delt inn i. Grensesnittklassen til hver modul og alle interne klasser i modulen beskrives. 17

248 Konstruksjon Klasser i graph-modulen Modulen graph og dens klasser er vist i et UML-klassediagram i figur 4. Modulens avhengigheter til andre moduler er vist i figur 3. Modulen graph sin oppgave skal være å hente, manipulere og tilby grafen som skal visualiseres. Modulen må derfor kunne lese ontologier fra filer og/eller URLer, konvertere disse til grafer, filtrere dem og tilby den resulterende grafen til andre moduler. Modulen skal være en tilbyder av hendelsene LayoutGraphEvent, FilterGraphEvent og OWLLoadEvent. Ettersom den skal være en tilbyder av OWLLoadEvent vil den også kunne sende ut OWLLoadErrorEvent. For beskrivelse av de ulike hendelsene se avsnitt om modulen event. GraphManager Modulens grensesnitt mot omverdenen vil være grensesnittet GraphManager. Grensesnittet skal tilby metoder for å laste inn ontologier, legge til hendelseslyttere og legge til og fjerne filtre. Selve implementasjonen vil finnes i GraphManagerImpl som implementerer grensesnittet GraphManager. Ettersom Spin skal benyttes må det gjøres på denne måten. GraphManagerImpl skal være en singleton-klasse som ikke kan instansieres utenfor klassen, men man skal kunne få en referanse til en instans av klassen ved å kalle den statiske metoden getinstance(). Hendelsesdelen av klassen skal implementeres gjennom realiserte grensesnitt fra modulen event. For innlasting av ontologier vil GraphManager benytte seg av klassen OWLLoader, som ligger i den samme modulen. Man skal kunne kalle loadfromfile() og loadfromurl() på GraphManager, og denne vil kalle tilsvarende metoder på OWLLoader som vil laste ontologien. OWLLoader er nærmere forklart senere i dette avsnittet. GraphManager skal sende ut en OWLLoadEvent før selve innlastingen av ontologien starter opp. Etter at grafen er lastet av OWLLoader har GraphManager fått et grafobjekt av typen Graph hvis alt gikk uten problemer. Da sender GraphManager ut en LayoutGraphEvent som sier at grafen er klar til å legges ut. Når et filter har blitt sendt til GraphManager, må GraphManager avgjøre om grafen må filtreres eller legges ut på nytt. Definisjonen på filtrering er at 18

249 Konstruksjon Figur 4: Klassene i graph-modulen 19

250 Konstruksjon grafen skal bli like stor eller mindre etter en filtrering. Blir grafen større må den legges ut på nytt. Se avsnitt for en beskrivelse av filter-modulen. Man skal kunne sette et filter med metoden setfilter(), noe som skal føre til en filtrering av den nåværende grafen. Man skal kunne fjerne et filter med metoden removefilter(), noe som skal føre til at grafen må legges ut på nytt. GraphManager skal samle filterene i en instans av FilterList. OWLLoader Denne klassen vil bare være synlig for klasser i graph-modulen og vil benyttes av GraphManager for å laste inn ontologier fra fil med metoden loadfromfile() eller URL med metoden loadfromurl(). Klassen skal benytte seg av biblioteket Jena for å laste ontologier [5]. Jena ble evaluert i forstudiet [1]. Jenas objektformat skal så bli konvertert til et grafobjekt av typen Graph som OWLLoader bygger opp. OWLLoader skal returnere dette grafobjektet når innlastingen og byggingen av ontologien er ferdig. Graph Dette er et grensesnitt fra biblioteket JUNG [7]. JUNG ble evaluert i forstudiet [1]. som egentlig ikke er med i denne modulen, men som er tatt med i figur 4 for å forenkle forståelsen av designet. Instanser av Graph representerer en graf med noder og kanter. GraphManager skal behandle grafobjekter som er instanser av dette grensesnittet. OWLVertex Denne klassen vil brukes av Graph for å representere en node i grafen. Den skal ha to medlemsvariable; name, som skal inneholde navnet til begrepet den representerer og ismarked, som skal angi om begrepet er markert eller ikke. Det vil finnes get- og set-metoder for disse medlemsvariablene. Klassen skal arve fra DirectedSparseVertex som finnes i biblioteket JUNG. OWLEdge Denne klassen skal representere en kant i grafen. OWLEdge er en generell klasse som er spesialisert for hver av de ulike typene kanter som skal visualiseres. Klassen skal arve fra DirectedSparseEdge som finnes i biblioteket JUNG. 20

251 Konstruksjon RelationEdge Denne klassen skal være en spesialisering av OWLEdge for kanter som representerer objectproperty-relasjoner i OWL. Relasjoner har et navn som skal kunne hentes ut med metoden getname(). SubClassEdge Denne klassen vil også være en spesialisering av OWLEdge. Den vil brukes for å vise at et begrep er et underbegrep av et annet begrep i OWL. 21

252 Konstruksjon Klasser i filter-modulen Dette avsnittet beskriver klassene som hører til modulen filter. Modulen og dens klasser er vist i et UML-klassediagram i figur 5. Modulens avhengigheter til andre moduler er vist i figur 3. Modulen filter skal inneholde all funksjonalitet for å representere filtre og lister av filtre. Hver type filter skal realiseres som en egen klasse som implementerer grensesnittet Filter, som er en del av biblioteket JUNG. Objekter av disse klassene skal sendes inn til GraphManager, som er grensesnittet til graph-modulen (se 4.1.1). GraphManager skal ta seg av å filtrere grafen med filtrene. filter-modulen skal ha en grensesnittklasse som heter FilterManager. FilterManager FilterManager skal holde oversikt over alle filterlister, og man skal kunne hente ut og sette nye filterlister på FilterManager. Til dette skal man kunne bruke metodene addfilterlist(), getfilterlist() og removefilterlist(). Det er tenkt at hver filterliste skal gis et navn slik at man kan skille mellom de forskjellige filterlistene. Ettersom det kun vil være behov for én FilterManager vil den bli implementert som en singleton-klasse som ikke kan instansieres utenfor klassen. Man skal kunne få en referanse til en instans av klassen ved å benytte metoden getinstance(). FilterList FilterList skal være en klasse som inneholder en liste av Filter-objekter. Klassen skal inneholde funksjonalitet for å legge til eller fjerne filtre fra listen. Til dette skal man benytte henholdsvis metodene addfilter() og removefilter(). For å hente ut alle filterobjekter fra listen skal man benytte metoden getfilters(). Alle objekter som skal legges i listen må være implementasjoner av grensesnittet Filter fra JUNG. Filter Filter er et grensesnitt fra JUNG, og alle forskjellige filter i denne modulen skal enten implementere dette grensesnittet direkte eller implementere det ved at de arver fra klasser i JUNG som implementerer grensesnittet. 22

253 Konstruksjon Figur 5: Klassene i filter-modulen 23

254 Konstruksjon Grensesnittet er egentlig ikke med i denne modulen, men er tatt med UMLdiagrammet siden dette øker forståelsen av designet. HierarchicFilter HierarchicFilter skal brukes til å velge antall nivåer av et begrepshierarki i en graf som skal vises. Alle begreper under det angitte nivået skal filtreres bort. Klassen skal inneholde variablen level som angir dette nivået. Klassen skal arve fra den abstrakte klassen GeneralVertexAcceptFilter fra JUNG. Dette innebærer at klassen må definere metodene acceptvertex() og getname(). RelationEdgeFilter RelationEdgeFilter skal inneholde funksjonalitet for å filtrere bort alle kanter i grafen av typen RelationEdge. Klassen skal arve fra den abstrakte klassen GeneralEdgeAcceptFilter fra JUNG. Dette innebærer at klassen må definere metodene acceptedge() og getname(). SubClassEdgeFilter SubClassEdgeFilter skal inneholde funksjonalitet for å filtrere bort alle kanter i grafen av typen SubClassEdge. Klassen skal arve fra den abstrakte klassen GeneralEdgeAcceptFilter fra JUNG. Dette innebærer at klassen må definere metodene acceptedge() og getname(). 24

255 Konstruksjon Klasser i event-modulen Dette avsnittet beskriver klassene som hører til modulen event. Modulen og dens klasser er vist i et UML-klassediagram i figur 6. Modulens avhengigheter til andre moduler er vist i figur 3. Event Event er baseklassen for alle hendelser som sendes i biblioteket. Den har kun én medlemsvariabel; source, som er en referanse til objektet der hendelsen oppsto. For lyttere som lytter på hendelser fra flere objekter kan det være essensielt å kunne identifisere kilden som skapte hendelsen. Kilden skal derfor kunne hentes ut med metoden getsource(). Error Dersom en operasjon som skulle ha sendt ut en hendelse feiler, skal den sende ut en hendelse som også implementerer grensesnittet Error. Dette designet medfører at alle objekter som lytter til en type hendelser fra et gitt objekt også vil få informasjon dersom det skjer en feil knyttet til denne typen hendelser i det samme objektet. Et eksempel på dette er klassen OWLLoadErrorEvent. En nærmere beskrivelse av denne klassen finnes lenger ned i dokumentet. Error-grensesnittet deklarerer metoden geterror(). Denne metoden skal returnere en tekstlig beskrivelse av feilen som oppsto. EventDispatcher Denne klassen har kun én statisk metode; dispatchevent(), som tar seg av selve utsendelsen av en hendelse. Av implementasjonshensyn 3 kan ikke kildekoden for å sende ut en hendelse ligge i tilbydergrensesnittene, og de tilbys derfor i denne klassen. LayoutGraphEvent Denne klassen arver fra Event. Når en ny graf er klar for utlegg vil det skapes en LayoutGraphEvent. Den har én medlemsvariabel, graph, som er en referanse til det nye grafobjektet. Grafen kan hentes ut med metoden getgraph(). 3 Siden Java ikke tilbyr arv fra flere klasser, kan ikke provider-grensesnittene inneholde annen kildekode enn grensesnittdeklarasjoner. 25

256 Konstruksjon Figur 6: Klassene i event-modulen 26

257 Konstruksjon LayoutGraphProvider Dette er et grensesnitt for klasser som ønsker å være en en tilbyder av hendelser av typen LayoutGraphEvent. Klasser som implementerer dette grensesnittet må implemetere metoden addlayoutgraphlistener(), som tar inn en LayoutGraphListener som argument. LayoutGraphListener Dette er et grensesnitt for klasser som ønsker å være en en lytter på hendelser av typen LayoutGraphEvent. Klasser som implementerer dette grensesnittet må implemetere metoden handle(), som tar inn en LayoutGraphEvent som argument. OWLLoadEvent Denne klassen arver fra Event. Når en ny ontologi enten skal lastes fra disk eller URL, vil det skapes en OWLLoadEvent. Den har én medlemsvariabel filename som beskriver hvor ontologien skal lastes fra. Filnavnet skal kunne hentes ut med metoden getfilename(). OWLLoadErrorEvent Denne klassen arver fra OWLLoadEvent og implementerer Error. Dette fører til at den må implementere metoden geterror(). Dersom det skjer en feil under innlasting av en OWL-fil, det være seg syntaksfeil, feil fra det underliggende I/O-systemet eller andre typer feil, skal klassen som laster OWL-filen sende ut en OWLLoadErrorEvent til alle registrerte lyttere. OWLLoadProvider Dette er et grensesnitt for klasser som ønsker å være en tilbyder av hendelser av typen OWLLoadEvent. Klasser som implementerer dette grensesnittet må implementere metoden addowlloadlistener(), som tar inn et argument av typen OWLLoadListener. OWLLoadListener Dette er et grensesnitt for klasser som ønsker å være en lytter på hendelser av typene OWLLoadEvent og OWLLoadErrorEvent. Klasser som implementerer dette grensesnittet må implemetere metoden handle(), som tar inn en OWLLoadEvent som argument. 27

258 Konstruksjon FilterGraphEvent Denne klassen arver fra Event. Når en graf har blitt filtrert skal det sendes ut en FilterGraphEvent. Den har én medlemsvariabel, graph, som er en referanse til den filtrerte grafen. Grafen skal kunne hentes ut med metoden getgraph(). FilterGraphProvider Dette er et grensesnitt for klasser som ønsker å være en tilbyder av hendelser av typen FilterGraphEvent. Klasser som implementerer dette grensesnittet må implementere metoden addfiltergraphlistener(), som tar inn en FilterGraphListener som argument. FilterGraphListener Dette er et grensesnitt for klasser som ønsker å være en lytter på hendelser av typen FilterGraphEvent. Klasser som implementerer dette grensesnittet må implemetere metoden handle(), som tar som tar inn en FilterGraphEvent som argument. FocusChangedEvent Denne klassen arver fra Event. Når et begrep i grafen markeres skal det sendes ut en FocusChangedEvent. Den har én medlemsvariabel, vertex. Dette skal være en referanse til den noden som ble markert. Noden skal kunne hentes ut med metoden getfocusedvertex(). FocusChangedProvider Dette er et grensesnitt for klasser som ønsker å være en tilbyder av hendelser av typen FocusChangedEvent. Klasser som implementerer dette grensesnittet må implementere metoden addfocuschangedlistener(), som tar inn en FocusChangedListener som argument. FocusChangedListener Dette er et grensesnitt for klasser som ønsker å være en lytter på hendelser av typen FocusChangedEvent. Klasser som implementerer dette grensesnittet må implementere metoden handle(), som tar inn en FocusChangedEvent som argument. 28

259 Konstruksjon Klasser i gui-modulen Dette avsnittet beskriver klassene som hører til i modulen gui. Modulen og dens klasser er vist i et UML-klassediagram i figur 7. Modulens avhengigheter til andre moduler er vist i figur 3. Modulen skal lage hendelser av typen FocusChangedEvent, og skal i tillegg selv lytte på hendelser av typen LayoutGraphEvent, OWLLoadEvent, FilterGraphEvent og FocusChangedEvent. For en beskrivelse av modulen event, se avsnitt OWLMenuBar Denne klassen skal representere en meny som kan tilbys brukeren og skal arve fra JMenuBar fra pakken javax.swing. Den skal lytte på hendelser av typen ActionEvent og ItemEvent fra pakken java.awt.event for å motta de valg brukeren foretar i menyen. Klassen vil derfor måtte implementere grensesnittene ActionListener og ItemListener, også fra pakken java.awt.event. I figur 8 finnes en prototyp for hvordan menyen skal være. Ettersom det ønskes å bruke avkrysningsbokser for å vise hvilke filtre som er aktive, er OWLMenuBar nødt til å lytte etter hendelser av typen ItemEvent. GraphWindowController Denne klassen skal være kontroller for alt som skal gjøres i grafen i hovedvinduet. GraphWindowController skal få hjelp av OWLGraphPanel, som skal stå for opptegning av grafen. GraphWindowController skal arve fra JScrollPane fra pakken javax.swing, og skal inneholde ett OWLGraphPanel. GraphWindowController vil implementere grensesnittet LayoutGraphListener og vil lytte etter hendelser av typen LayoutGraphEvent. Når en slik oppstår vil den kunne hente ut et objekt av typen Graph fra LayoutGraphEvent som den vil delegere videre til OWLGraphPanel med metoden setgraph(). Klassen skal også implementere grensesnittet FilterGraphListener og vil lytte etter hendelser av typen FilterGraphEvent. Når en slik hendelse oppstår vil den sette den filtrerte grafen på OWLGraphPanel ved å bruke metoden setfilteredgraph(). Når brukeren markerer et nytt begrep i grafen skal GraphWindowController sende ut en FocusChangedEvent til alle som lytter etter denne hendelsen. I figur 9 finnes en prototyp for hvordan hovedvinduet skal se ut. 29

260 Konstruksjon Figur 7: Klassene i gui-modulen 30

261 Konstruksjon Figur 8: Prototyp for menyen OWLGraphPanel Denne klassen skal stå for opptegning av grafen og skal lytte etter brukerinndata fra mus. Klassen skal benyttes av GraphWindowController og er ikke synlig utenfor modulen gui. Ettersom klassen skal stå for opptegning vil den arve fra JPanel fra pakken javax.swing. Ved å overlaste metoden paintcomponent() skal man selv kunne definere hva som tegnes opp på panelet. OWLGraphPanel vil ha en metode setgraph() som tar inn en referanse av typen Graph. Dette Graph-objektet vil inneholde informasjon som er nødvendig for å tegne opp grafen. Når en graf blir satt ved hjelp av denne metoden skal den bli lagt ut på nytt. Man kan bruke metoden setfilteredgraph() hvis man skal sette en filtrert versjon av grafen som allerede er tegnet opp. Grafen blir da ikke lagt ut på nytt men de delene som har blitt filtrert bort skal fjernes. OWLGraphPanel skal benytte klassen OWLRenderer til å tegne opp nodene og kantene i grafen. I tillegg vil OWLGraphPanel benytte en instans av Layout fra biblioteket JUNG til å legge ut grafen, det vil si å beregne posisjonene til nodene. OWLRenderer OWLRenderer spesialiserer AbstractRenderer fra JUNG. Metoden paintedge() skal stå for opptegning av kanter, mens metoden paintvertex() skal stå for opptegning av noder. Denne klassen skal heller ikke være synlig utenfor modulen gui. 31

262 Konstruksjon Figur 9: Prototyp for hovedvinduet ClassInfoWindowController ClassInfoWindowController er klassen for informasjonsvinduet og skal vise informasjon om et begrep. ClassInfoWindowController skal arve fra JPanel fra pakken javax.swing og skal stå for vising av informasjonen selv. I figur 10 finnes en prototyp for hvordan informasjonsvinduet skal være. ClassInfoWindowController skal være en FocusChangedListener. Når den får en FocusChangedEvent skal den vise informasjon om begrepet som ble markert. StatusBarController Denne klassen skal brukes til å vise status og reflektere tilstanden til biblioteket. I første inkrement vil den visualisere progresjonen gjennom en fremgangsindikator når en ontologi lastes inn. Klassen skal derfor implementerer grensesnittet OWLLoadListener. Det er tenkt at klassen skal kunne utvides til å vise annen tilstandsinformasjon man finner behov for å visualisere. 32

263 Konstruksjon Figur 10: Prototyp for informasjonsvinduet 33

264 Konstruksjon Klasser i io-modulen Dette avsnittet beskriver modulen io. Modulen inneholder klasser som behandler persistente data som skal være tilgjengelig over flere kjøringer av biblioteket. Modulen og klassen Language, som er den eneste klassen io skal inneholde i første inkrement, er vist i et UML-klassediagram i figur 11. Modulens avhengigheter til andre moduler er vist i figur 3. Figur 11: Klassen i io-modulen For dette inkrementet vil modulen inneholde en klasse Language, som skal inneholde funksjonalitet for å laste inn språkdefinisjoner fra disk og bruke dem i biblioteket. For å kunne hente ut strenger fra språkdefinisjonen skal klassen tilby en metode getstring(), som tar inn en oppslagsverdi som parameter og returnerer språkstrengen som er knyttet til denne oppslagsverdien i språkfilen. Oppslagsverdiene som skal benyttes i Language bør defineres som konstanter, slik at man får varsel om manglende eller ikke-eksisterende oppslag ved kompilering. Dette vil fortsatt ikke si fra om eventuelle mangler i språkdefinisjonen, som vil måtte behandles i kjøretid. Dette skal løses ved å returnere strengen MISSING når et slikt oppslag skjer. 34

265 Konstruksjon 4.2 Sekvensdiagram Sekvensdiagrammene viser objektinteraksjon for hendelsene som er beskrevet i use case-diagrammene, se kravspesifikasjonsdokumentet [4], og for andre sekvenser gruppen har oppfattet som viktige for konstruksjonen Tolking av OWL-fil Sekvensdiagrammet i figur 12 viser sekvensen for Use Case 1 - Tolking av en OWL-fil i kravspesifikasjonen. De tre prikkene i front av EventListener viser at dette er flere grensesnitt, og enda flere klasser som implementerer de. Første melding går fra brukeren til brukergrensesnittet ved at brukeren velger Open File fra menyen (se figur 8). Dette valget fører til at OWLMenuBar kaller metoden loadfromfile() på grensesnittet inn til graph-modulen; GraphManager. Det første som blir gjort av GraphManager er å gi alle objekter som lytter på OWLLoadEvent-hendelser informajon om at en OWL-fil skal lastes. Dette gjøres ved å kalle dispatchevent() på EventDispatcher. Dette kallet vil igjen kalle handle() på de interesserte lytterne. Etter at dette er utført vil GraphManager sette i gang selve fillastingen i en ny tråd slik at brukergrensesnittet forblir responsivt under lastingen. Fillastingen gjøres av OWLLoader og settes i gang med loadfromfile(). Når dette kallet er ferdig utført vil lyttere interessert i LayoutGraphEventhendelser bli informert, igjen gjennom EventDispatcher. Én av lytterne på denne hendelsen vil være brukgrensesnittet som gir informasjon om at filen er lastet til brukeren. 35

266 Konstruksjon Figur 12: Tolking av OWL-fil 36

267 Konstruksjon Vising av informasjon om markert begrep Sekvensdiagrammet i figur 13 viser hendelsesforløpet når en bruker ønsker å markere en node i graf-vinduet. I kravspesifikasjonen er ikke dette en use case i seg selv, men er premiss for Use Case 7 - Velging av underbegrep til et markert begrep, Use case 8 - Visning av individer for et markert begrep og Use Case 9 - Visning av individer for et markert begrep samt en del av Use Case 4 - Grafgenerering av begreper i utvalgslise. Musetrykket fra brukeren på en node i grafen tas i mot av OWLGraphPanel som implementerer MouseListener. Herfra sendes en FocusChangedEvent via EventDispatchers dispatchevent() til alle interesserte lyttere. For brukergrensesnittets del, vil ClassInfoWindowController være den av disse som tar i mot denne hendelsen og oppdaterer informasjonen i informasjonsvinduet. Før sekvensen avsluttes oppdaterer også OWLGraphPanel grafen for å indikere at en ny node er valgt. Dette gjøres ved å endre farge på noden. Figur 13: Markering av begrep Filtrering I figur 14 er sekvensdiagram for filtrering av en graf. I sekvensen er RelationEdgeFilter vist, men forløpet vil være likt for HierarchicFilter 37

268 Konstruksjon og SubClassEdgeFilter. Sammen vil disse tre filtrene oppfylle kravene til predefinerte filtre satt i FK-FI1 i kravspesifikasjonen. Sekvensen begynner med at brukeren velger Filter -> Relation edge filter fra menyen (se figur 8). Som i forrige avsnitt vil dette tas imot av OWLMenuBar. Herfra kalles setfilter() på GraphManager med en instans av RelationEdgeFilter som parameter. Etter å ha foretatt selve graf-filtreringen, sender GraphManager ut en ny FilterGraphEvent. Av klassene som skal implementere FilterGraphListener er det OWLGraphPanel som vil oppdatere grafen som tegnes idet en ny FilterGraphEvent blir håndtert. Figur 14: Filtrering av graf Utlegg av graf Sekvensdiagrammet i figur 15 viser hendelsesforløpet for utlegg av en graf. Dette bygger ikke på et eget use case i kravspesifikasjonen, men vil utdype hva som skal skje etter at en OWL-fil har blitt tolket (se avsnitt 4.2.1). Sekvensdiagrammet begynner med at GraphManager sender ut en hendelse av typen LayoutGraphEvent. EventDispatcher vil deretter kalle handle() på GraphWindowController, som er en lytter på den aktuelle hendelsen. GraphWindowController henter så referansen til grafen som skal legges ut fra LayoutGraphEvent-objektet, og kaller setgraph() på OWLGraphPanel. Denne vil så opprette en ny instans av Layout, og initialisere denne. Layoutinstansen vil legge ut grafen, noe som innebærer å beregne posisjoner til hver node i grafen. 38

269 Konstruksjon Figur 15: Utlegg av graf Oppdatering av filtrert graf I figur 16 er sekvensdiagram for oppdatering av en filtrert graf. Dette er ikke et eget use case, men vil vise i detalj hva som skal skje etter at en filtrering av en graf har funnet sted (se avsnitt 4.2.3). Sekvensdiagrammet begynner med at GraphManager sender ut en hendelse av typen FilterGraphEvent. EventDispatcher vil deretter kalle handle() på GraphWindowController, som er en lytter på den aktuelle hendelsen. GraphWindowController henter så referansen til grafen som har blitt filtrert fra FilterGraphEvent-objektet, og kaller setfilteredgraph() på OWLGraphPanel. Denne vil så kalle metoden applyfilter() på Layout, som vil fjerne de deler av den nåværende grafen som ikke finnes i den filtrerte versjonen av grafen. 39

270 Konstruksjon Figur 16: Oppdatering av filtrert graf 40

271 Konstruksjon Referanser [1] Kundestyrt prosjekt, gruppe 14: Ontologidrevet dokumentforvaltning, forstudie, [2] Martin Fowler. Uml distilled: A brief guide to the standard object modeling language, 3nd edition, [3] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design patterns: Elements of reusable object-oriented software, [4] Kundestyrt prosjekt, gruppe 14: Ontologidrevet dokumentforvaltning, kravspesifikasjon, [5] Hewlett-Packard Development Company LP. Jena semantic web framework, [6] Institute of Electrical and Inc. (IEEE) Electronic Engineers. Ieee recommended practice for software design descriptions, [7] Scott White, Joshua O Madadhain, Danyel Fisher, and Yan-Biao Boey. Jung,

272 Ontologidrevet dokumentforvaltning Implementasjon TDT4290 Kundestyrt prosjekt Institutt fra datateknikk og informasjonsvitenskap Fakultet for informasjonsteknologi, matematikk og elektroteknikk Norges teknisk-naturvitenskapelige universitet Gruppe 14 Espen Hansen Ole-Marius Moe-Helgesen Geir Storli Karl Hatteland Steinar Skjerven Håvard Stranden

273

274 Implementasjon Innhold 1 Innledning Formål Oversikt Kode- og dokumentasjonstandarder Språk Kommentarer Variable Metoder Klasser Formatering Kodestil Implementasjon av første inkrement Implementerte krav Implementasjonen av graph-modulen Endringer i forhold til konstruksjonsfasen Detaljerte metodebeskrivelser Implementasjonen av filter-modulen Endringer i forhold til konstruksjonsfasen Detaljerte metodebeskrivelser Implementasjonen av event-modulen Endringer i forhold til konstruksjonsfasen Detaljerte metodebeskrivelser Implementasjonen av io-modulen

275 Implementasjon Endringer i forhold til konstruksjonsfasen Detaljerte metodebeskrivelser Implementasjonen av gui-modulen Endringer i forhold til konstruksjonsfasen Detaljerte metodebeskrivelser Testapplikasjonen for biblioteket 34 5 Status på produktet 35 6 Informasjon til nye utviklere Kildekodetre Retningslinjer for videreutvikling Videre utvikling av biblioteket Endring av utleggsalgoritme Mer informasjon fra OWL-tolking Grafposisjon etter filtrering Installasjonsveiledning Lisenser Installasjon av Java Installasjon av biblioteket Installasjon for å benytte biblioteket i en applikasjon Installasjon for videreutvikling av biblioteket Referanser 42 3

276 Implementasjon 1 Innledning Implementasjonsdokumentet er en spesifisering hva som er blitt implementert, hva som ikke er blitt implementert og eventuellt hvorfor det ble avviket fra det som ble bestemt i konstruksjonsfasen. 1.1 Formål Formålet med implementasjonsdokumentet er å forklare implementasjonen av biblioteket. Dette oppnås ved å detaljforklare hvilke endringer som gjøres for hvert inkrement, samt å forklare viktige deler av kildekoden i detalj. Implementasjonsdokumentet skal i tillegg forklare hvordan biblioteket kan videreutvikles eller tas i bruk med den funksjonaliteten det tilbyr. 1.2 Oversikt Biblioteket er implementert med Java 2 Software Development Kit (SDK) Standard Edition Kapittel 2 omhandler standard for kildekode og dokumentasjon. Kapittel 3 omhandler implementasjonen av første inkrement. Kapittel 4 forklarer kort applikasjonen som er utviklet for å teste prosjektet. Kapittel 5 beskriver status for prosjektet med hensyn på implementasjonen, før kapittel 6 kort tar for seg noen retningslinjer for videreutvikling av biblioteket. Til slutt kommer en kort installasjonsveiledning i kapittel 7. 4

277 Implementasjon 2 Kode- og dokumentasjonstandarder Siden det er mange personer involvert i utviklingen av prosjektet, er det viktig å etablere en felles standard for kildekode. Standarden gruppen har valgt å bruke er ikke noen offisiell standard, men den er veldig nært beslektet med Suns offisielle kildekodestandard for Java, JavaDoc [1]. 2.1 Språk Kildekoden skal skrives på engelsk. Dette inkluderer, men er ikke begrenset til, alle klasse-, metode- og variabelnavn samt kommentarer. 2.2 Kommentarer Alle metoder og klasser skal kommenteres i henhold til JavaDoc-standarden. Metoder skal som et minimum for alle innargumenter for alle metoder som returnerer noe. Metoder og klasser som har public tilgjengelighet skal kommenteres mer utfyllende. Koden skal ikke inneholde personlig informasjon om utvikler(e) som navn eller epostadresse. Alle medlemsvariable skal kommenteres i henhold til JavaDoc-standarden. Alle lengre skop, som klasser og metoder, skal ha kommentar på avsluttende parentes som forteller hvilket skop som avsluttes. Et eksempel: class Foo { (...) } // class Foo Kildekoden skal i størst mulig grad være selvdokumenterende, men dersom det er behov for kommentarer, skal // og ikke /*... */ benyttes. Dette for å gjøre det enklere å fjerne større blokker ved å kommentere de ut. 5

278 Implementasjon 2.3 Variable Variable skal ha liten forbokstav. Dersom en variabel inneholder flere ord, skal etterfølgende ord ha stor forbokstav. Underscore (_) eller andre tegn skal ikke benyttes som ordskiller. 2.4 Metoder Metoder skal ha liten forbokstav Dersom en metode inneholder flere ord, skal etterfølgende ord ha stor forbokstav. Underscore (_) eller andre tegn skal ikke benyttes som ordskiller. Ved metoder som kun setter en medlemsvariabel skal set<variabel> brukes som navn. set-metoder skal ikke returnere en verdi. Ved metoder som kun returnerer en medlemsvariabel skal get<variabel> brukes som navn. Returverdien av get-metoder skal være et objekt av typen til den aktuelle variabel. 2.5 Klasser Klasser skal ha stor forbokstav Dersom en klasse inneholder flere ord, skal etterfølgende ord også ha stor forbokstav. Underscore (_) eller andre tegn skal ikke brukes for å skille ord i klassenavn. 6

279 Implementasjon 2.6 Formatering Ingen linjer skal overstige 100 tegn. Indentering skal være satt til fire tegn, og det skal benyttes mellomrom - ikke tabulator - til indentering. Linjeskift skal lagres som linefeed (ASCII 10), ikke carriage return (ASCII 13) og linefeed, eller carriage return alene. For windows- og mac-klienter kan dette innebære å velge lagring i Unix-format. 2.7 Kodestil Deklarasjon, implementasjon og kall av metoder og funksjoner skal ikke ha mellomrom mellom parenteser. F.eks: void foo(int bar){} obj.foo(1); Dersom () brukes i andre strukturer i språket, f.eks i if eller while skal mellomrom heller ikke benyttes. For klasser skal begynnende parentes på egen linje etter klassedefinisjonen, indentert på samme nivå som linjen over. Metoder, løkker og andre skop skal indentere skop på samme måte som klasser. public class Foo { public void bar() { if(baz) { (...) (og noen linjer til...) } // if(baz) } // bar() } // class Foo For skop som kun er på én kodelinje skal ikke parenteser benyttes for å vise skopet. 7

280 Implementasjon Importeringer skal ordnes alfabetisk på begynnelsen av filen. Et eksempel på kildekode som følger standarden gruppen ønsker å benytte er vist under. 1 package mypackage; 2 import java.util.arraylist; 3 4 /** 5 * This is where you write the class description 6 */ 7 public class Class 8 { 9 /** Number of foos */ 10 public int foo; private Class bar; /** 15 * Constructor description 16 */ 17 public Class() 18 { 19 // Add code here 20 } /** 23 * Get the bar 24 Reference to the bar object 25 */ 26 public Class getbar() 27 { 28 return this.bar; 29 } /** 32 * Set the local bar 33 bar The new bar 34 */ 35 public void setbar(class bar) 36 { 37 for(int i = 0; i < foo; i++) 38 { 39 dostuff(); 40 } 41 this.bar = bar; 42 } 8

281 Implementasjon private void dostuff() 45 { 46 System.out.println("Doing stuff..."); 47 } 48 } // class Class 9

282 Implementasjon 3 Implementasjon av første inkrement Dette kapittelet inneholder den detaljerte beskrivelsen av implementasjonen i første inkrement. Kapittelet starter med å fortelle hvilke krav som er implementert i inkrementet. Deretter diskuteres endringer som er gjort i forhold til det gruppen kom fram til i konstruksjonsfasen. Så følger en detaljert beskrivelse av alle sentrale algoritmer og metoder. 3.1 Implementerte krav Den opprinnelige listen med krav som skulle implementeres i første inkrement finnes i kravspesifikasjonen [4]. De funksjonelle kravene som har blitt implementert i første inkrement er oppsummert i tabell 1. ID FK-HA1 FK-HA2 FK-HA3 FK-HA4 FK-HA5 FK-FI1 FK-BH2 FK-BH8 FK-BG1 FK-BG3 FK-BG4 FK-BG5 Navn Håndtering av OWL-typer Åpning av OWL-fil fra disk Åpning av OWL-fil fra URL Tolking av OWL-fil Syntaksfeil i OWL-fil Predefinerte filtre Velging av begrep Visning av informasjo om markert begrep Ontologi som graf Relasjoner Navn på noder Nodestørrelse Tabell 1: Funksjonelle krav som er implementert i første inkrement Funksjonelle krav som var planlagt implementert i første inkrement, men som ikke er implementert, er oppsummert i tabell 2. Som man ser av tabellene, er alle krav unntatt to implementert. Disse kravene ble ikke implementert på grunn av en begrensning i Jena 1 : 1 Jena er biblioteket som brukes for å tolke OWL-filer. Mer informasjon finnes i prosjektets forstudium. 10

283 Implementasjon ID FK-HA6 FK-HA7 Navn Dataignorering i OWL-fil OWL-type Tabell 2: Funksjonelle krav som ikke er implementert i første inkrement Krav FK-HA6 kunne ikke implementeres på grunn av at Jena ikke kan liste opp hvilke OWL-egenskaper som ble ignorert under innlesing av OWL-filen. Krav FK-HA7 kunne ikke implementeres på grunn av at Jena ikke kan fortelle hvilken OWL-type filen som blir lastet inneholder. Siden begge kravene er vektet lavt ble det valgt å ikke bruke mer tid på å finne en løsning på dette. 3.2 Implementasjonen av graph-modulen Modulen graph tar seg av innlasting og manipulering av grafer. Grensesnittklassen dens er GraphManager Endringer i forhold til konstruksjonsfasen Dette avsnittet beskriver i detalj hvilke endringer som er gjort i graphmodulen. Klasser som ikke er endret er ikke nevnt i avsnittet. Figur 1 viser det oppdaterte klassediagrammet for modulen graph. OWLClassVertex Klassen OWLVertex er spesialisert til klassen OWLClassVertex, som inneholder medlemsvariable som er spesifikke for OWL-klasser. Denne spesialiseringen er gjort fordi det vil være naturlig å skille mellom ulike typer noder i grafen, for eksempel klassenoder og individnoder, i fremtidige utvidelser av biblioteket. Egenskaper som er felles for alle noder i en OWL-graf ligger i OWLVertex. EquivalentClassEdge Denne kanten representerer en ekvivalensrelasjon mellom to OWL-klasser. 11

284 Implementasjon Figur 1: Oppdatert klassediagram for graph-modulen 12

285 Implementasjon Kanten har blitt lagt til for å kunne skille denne relasjonen fra andre relasjoner. Denne kanten blir ikke visualisert, men brukes for å holde rede på hvilke klasser som er ekvivalente. GraphManager Filterlisten i GraphManager, som inneholder alle aktive filtre, kan maksimalt inneholde én instans av hver filterklasse. Dette fordi det ikke er mulig å ha flere aktive instanser av de filterklassene som er implementert. Det er også lagt til metoder for å hente ut ulike egenskaper ved en node i grafen. Nedenfor følger en liste over disse metodene og egenskapene de henter ut: getsubclassesof() henter ut en liste med OWLClassVertex-objekter som er subklassene av en gitt node. getsuperclassesof() henter ut en liste med OWLClassVertex-objekter som er superklassene av en gitt node. getequivalentclassesof() henter ut alle klasser som er ekvivalente med en gitt OWL-klasse som en liste av OWLClassVertex-objekter. getindividualsof() henter ut antall individer en gitt OWL-klasse har som en int. getobjectpropertiesof() henter ut alle objektegenskaper for en gitt OWL-klasse som en liste av strenger. getdatatypepropertiesof() henter ut alle datatype-egenskaper for en gitt OWL-klasse som en liste av 2-tupler 2 av String-objekter. 2- tuplen inneholder navnet til datatype-egenskapen som første element, og datatypen dens som andre element. Alle disse metodene tar inn en referanse til en OWLClassVertex som argument. Metodene var opprinnelig tenkt å ligge i OWLVertex-klassen, men siden denne ikke har noen referanse til grafen den tilhører, var det ikke mulig å hente ut alle egenskapene på denne måten uten å skape en kryssreferanse mellom GraphManager eller Graph og OWLVertex. Gruppen valgte derfor å lage én måte å hente egenskapene til en node på, gjennom GraphManager. 2 En liste med 2 elementer 13

286 Implementasjon Det er lagt til aksessormetoder for å kunne sette og hente ut en streng som beskriver status under innlasting av en ny ontologi. Disse metodene heter henholdsvis setloadprogress() og getloadprogress(). Den første tar inn en streng som argument, mens den andre returnerer en streng. Dersom noen av metodene kalles uten at en innlasting foregår, vil de kaste en NotLoadingException. NotLoadingException Denne klassen representerer unntaket som kastes dersom man prøver å hente ut statusbeskrivelse for innlasting uten at innlasting foregår Detaljerte metodebeskrivelser Dette avsnittet beskriver sentrale algoritmer og metoder i de ulike klassene i graph-modulen. GraphManager Metoden getinstance(), som returnerer referansen til singleton-instansen av GraphManager, kjører instansen gjennom Spin 3 før den returneres [2]. Dette gjør at alle kall til instansen blir kjørt i en egen tråd, noe som sikrer at klasser i gui-modulen som benytter seg av GraphManager vil kunne være responsive selv om kallet til GraphManager er et tidkrevende kall. Siden klassen er implementert som en singleton-klasse, er konstruktoren privat. Implementasjonen av getinstance() med privat konstruktor er vist under. private static GraphManager instance = null; /** * Method for fetching the instance of the graph manager. A reference to the graph manager. */ public static GraphManager getinstance() { if(instance == null) instance = (GraphManager)Spin.off(new GraphManagerImpl()); return instance; } /** 3 For en mer detaljert beskrivelse av Spin, se prosjektets forstudium. 14

287 Implementasjon * Default constructor. The graph manager is implemented as a singleton * class, so the constructor is private. Use getinstance() to get the * instance of the class. getinstance */ private GraphManagerImpl() { owlloader = new OWLLoader(); filterlist = new FilterList(); } En av metodene som henter ut en egenskap ved en OWL-klasse er getsubclassesof(), som returnerer subklassene til en gitt OWL-klasse, representert som en liste av OWLClassVertex. Implementasjonen av denne metoden er vist under. /** * Get the subclasses of a given vertex. v The vertex to check. An array of vertices that are subclasses of the given vertex. */ public OWLClassVertex[] getsubclassesof(owlclassvertex v) { ArrayList a = new ArrayList(); Iterator i = v.getinedges().iterator(); while(i.hasnext()) { OWLEdge e = (OWLEdge)i.next(); if(e instanceof SubClassEdge) a.add(e.getsource()); } OWLClassVertex[] ret = new OWLClassVertex[a.size()]; a.toarray(ret); return ret; } OWLLoader Metodene loadfromfile() og loadfromurl() har veldig mye til felles. Bortsett fra at de leser fra kilder som adresseres på forskjellig måte, er de identiske. Funksjonaliteten som er felles for begge er derfor skilt ut i en privat metode generategraph(), som tar inn en streng som representerer filen som er lastet inn, og OntModel 4. Klassen leser så ut all relevant informasjon fra ontologimodellen og genererer en graf. 4 Klassen OntModel er Jenas måte å representere innleste ontologier på. 15

288 Implementasjon Algoritmen for grafgenerering og resten av metoden generategraph() er vist under. /** * Generates a graph from an ontology model containing the data. * This method is used internally during the load process. file The file name or URL the ontology has been read from m The ontology model to generate the graph from. */ private Graph generategraph(string file, OntModel m) { // Construct a new graph and hashtable for vertices. // These are only used during this method, and are set to null before // the method returns. graph = new DirectedSparseGraph(); vertices = new Hashtable(); ExtendedIterator i = m.listnamedclasses(); if(!i.hasnext()) { // The ontology is empty. This means that there is some semantic // error in it, so throw an error event. // Also, set the progress to completed. setprogress(language.get(language.ls_failed)); fireowlloaderrorevent(new OWLLoadErrorEvent(file, Language.get( Language.ER_OWL_SEMANTIC))); return null; } setprogress(language.get(language.ls_classes)); // Iterate over the classes and create vertices and appropriate edges while(i.hasnext()) { OntClass cls = (OntClass)i.next(); // Adds the vertex if it s not already there OWLClassVertex v = addclassvertex(cls.getlocalname()); // Add subclasses of the vertex and edges between them to the graph ExtendedIterator j = cls.listsubclasses(true); while(j.hasnext()) addsubclassedge( addclassvertex(((ontclass)j.next()).getlocalname()), v); // Set the number of individuals this class has int n = 0; j = cls.listinstances(); while(j.hasnext()) { 16

289 Implementasjon ++n; j.next(); } v.setindividuals(n); } // Add equivalent classes of the vertex and edges between // them to the graph j = cls.listequivalentclasses(); while(j.hasnext()) { OntClass oc = (OntClass)j.next(); if(oc.getlocalname()!= null) { addequivalentclassedge(v, addclassvertex(oc.getlocalname())); } } setprogress(language.get(language.ls_object_properties)); // Add object properties to the graph as relation edges i = m.listobjectproperties(); while(i.hasnext()) { ObjectProperty op = (ObjectProperty)i.next(); OntResource domain = op.getdomain(); OntResource range = op.getrange(); if(domain == null range == null) continue; OWLClassVertex v1 = (OWLClassVertex)vertices.get(domain.getLocalName()); OWLClassVertex v2 = (OWLClassVertex)vertices.get(range.getLocalName()); if(v1!= null && v2!= null) addrelationedge(v1, v2, op.getlocalname()); } // Add data type properties to vertices i = m.listdatatypeproperties(); while(i.hasnext()) { OntProperty op = (OntProperty)i.next(); OntResource domain = op.getdomain(); OntResource range = op.getrange(); } if(domain == null range == null) continue; OWLClassVertex v = (OWLClassVertex)vertices.get(domain.getLocalName()); if(v!= null) v.adddatatypeproperty(op.getlocalname(), range.getlocalname()); 17

290 Implementasjon } setprogress(language.get(language.ls_done)); // Set the hashtable to null (we don t need it) // Since other people have references to the graph, there s no use // setting it to null, as the object will still live in memory. vertices = null; return graph; 3.3 Implementasjonen av filter-modulen Modulen filter inneholder de klassene som representerer ulike filtre, samt klasser for å sette sammen og holde oversikt over filtre Endringer i forhold til konstruksjonsfasen Det har ikke blitt gjort noen endringer i modulen filter siden konstruksjonsfasen Detaljerte metodebeskrivelser Dette avsnittet beskriver sentrale algoritmer og metoder i de ulike klassene i filter-modulen. HierarchicFilter For å beregne om en node er innenfor det angitte hierarktiske nivået for filteret benyttes den private metoden getminimallevelof() rekursivt. Man kaller metoden med atlevel=0, og for hver superklasse til noden blir den samme metoden kalt med ett nivå høyere. Når en node ikke lenger har noen superklasser returneres nivået den da har kommet til. Kildekoden for metoden getminimallevelof() er vist under. /** * Returns the least hierarchic level of the given vertex. * To get the level of a vertex, use getminimallevelof(vertex, 0). v The vertex to fetch the level of. atlevel The current level the given vertex is on (for recursion). */ private int getminimallevelof(owlclassvertex v, int atlevel) 18

291 Implementasjon { } GraphManager gm = GraphManagerImpl.getInstance(); OWLClassVertex[] vertices = gm.getsuperclassesof((owlclassvertex)v); if(vertices.length == 0) return atlevel; int l = getminimallevelof(vertices[0], atlevel + 1); for(int i = 1; i < vertices.length; ++i) { int m = getminimallevelof(vertices[i], atlevel + 1); if(m < l) l = m; } return l; 3.4 Implementasjonen av event-modulen Modulen event inneholder alle grensesnitt for tilbydere og lyttere av hendelser, samt alle hendelsesklassene Endringer i forhold til konstruksjonsfasen Dette avsnittet beskriver i detalj hvilke endringer som er gjort i eventmodulen. Klasser som ikke er endret er ikke nevnt i avsnittet. Figur 2 viser det oppdaterte klassediagrammet for modulen event. Event I konstruksjonsfasen ble det bestemt at enhver hendelse skulle inneholde kilden som sendte ut hendelsen. Etterhvert oppdaget man at det aldri ble aktuelt å kjenne til kilden som sendte ut en hendelse. Denne funksjonaliteten ble derfor valgt ikke implementert. Metoden getsource() har blitt fjernet fra klassen Event. LocaleChangedProvider Dette grensesnittet ble lagt til slik at Language i modulen io kan implementere det, og med det sende ut en LocaleChangedEvent når språket i brukergrensesnittet blir endret. 19

292 Implementasjon Figur 2: Oppdatert klassediagram for event-modulen 20

293 Implementasjon LocaleChangedListener De klassene som har interesse av å vite når språket i brukergrensesnittet har blitt endret, kan implementere grensesnittet LocalChangedListener, som har blitt lagt til i modulen. Hvis klassene viser fram tekststrenger må disse oppdateres når et nytt språk har blitt valgt. LocaleChangedEvent LocaleChangedEvent ble lagt til i sammenheng med grensesnittene nevnt over, og er selve hendelsen som blir sendt ut av en LocaleChangedProvider når språket i brukergrensesnittet har blitt endret Detaljerte metodebeskrivelser Dette avsnittet beskriver sentrale algoritmer og metoder i de ulike klassene i event-modulen. EventDispatcher Den statiske metoden dispatchevent() i EventDispatcher benyttes til å sende ut en hendelse til alle lyttere av denne hendelsen. Kildekode for metoden dispatchevent() er vist under. /** * Dispatch an event e The event to dispatch listeners List of listeners that shall receive the event */ public static void dispatchevent(event e, ArrayList listeners) { if(e instanceof OWLLoadEvent) { for(int i = 0; i < listeners.size(); ++i) ((OWLLoadListener)listeners.get(i)).handle((OWLLoadEvent)e); } else if(e instanceof FocusChangedEvent) { for(int i = 0; i < listeners.size(); ++i) ((FocusChangedListener)listeners.get(i)).handle((FocusChangedEvent)e); } else if(e instanceof FilterGraphEvent) { for(int i = 0; i < listeners.size(); ++i) ((FilterGraphListener)listeners.get(i)).handle((FilterGraphEvent)e); 21

294 Implementasjon } else if(e instanceof LayoutGraphEvent) { for(int i = 0; i < listeners.size(); ++i) ((LayoutGraphListener)listeners.get(i)).handle((LayoutGraphEvent)e); } else if(e instanceof LocaleChangedEvent) { for(int i = 0; i < listeners.size(); ++i) ((LocaleChangedListener)listeners.get(i)).handle((LocaleChangedEvent)e); } else { // Programming error if this block is ever reached System.err.println("Unknown event to dispatch. NOTE: This is a programming error and should never happen!"); } } //dispatchevent() 3.5 Implementasjonen av io-modulen Modulen io inneholder klasser som skal representere data som er persistente over flere kjøringer av biblioteket Endringer i forhold til konstruksjonsfasen Det har blitt gjort endringer i klassen Language, som er den eneste klassen i modulen. Endringene er beskrevet nedenfor. Figur 3 viser det oppdaterte klassediagrammet for modulen io. Language Krav IFK-GK4, som går på skifting av språk, ble i konstruksjonsfasen ikke tolket til å kreve at man skulle kunne skifte språk under kjøring. Da dette behovet ble oppdaget i implementasjonen, førte det til en del endringer i Language-klassen. For å kunne hente ut en liste over tilgjengelige språk har metoden getavailablelocales() blitt lagt til. Denne returnerer en liste med Localeobjekter 5. 5 Locale-klassen er en standard Java-klasse. 22

295 Implementasjon Figur 3: Oppdatert klassediagram for io-modulen 23

296 Implementasjon Klassen har blitt en tilbyder av hendelser av typen LocaleChangedEvent, som sendes ut når et nytt språk lastes inn. Denne hendelsen brukes til å be de ulike klassene som bruker språkspesifikke strenger om å oppdatere strengene sine. Det er lagt til en mengde statiske strenger i henhold til beskrivelsen i konstruksjonsfasen [3]. Klassen er implementert som en singleton-klasse. Opprinnelig var denne tenkt å være en statisk klasse, men på grunn av behovet for å kunne sende ut hendelser fra den var det ikke mulig. I likhet med GraphManager har den derfor fått en metode getinstance() som returnerer én og kun én instans av klassen. Implementasjonsdetaljer omkring denne metoden er vist med et kodeeksempel fra GraphManager i avsnitt For å kunne endre språk har metoden setlocale() blitt lagt til. Denne metoden tar inn et objekt av typen Locale, laster inn en ny språkfil basert på dette objektet, og sender så ut en LocaleChangedEvent for å indikere at språket har blitt endret. Figur 4 viser hendelsesforløpet når en bruker ønsker å bytte språk i brukergrensesnittet. Sekvensen begynner med at brukeren velger Options->Change Language (forutsatt engelsk brukergrensesnitt). Dette plukkes opp som en ActionEvent fra Swing i OWLMenuBars metode actionperformed(). Deretter kalles setlanguage() på den statiske klassen Language. Denne vil laste ny språkdefinisjonsfil for det valgte språket og lage en ny LocaleChangedEvent. Slike hendelser lyttes på av alle objekter som har tekstlig informasjon til brukeren som hentes fra Language før den benyttes. Figur 4: Endring av språk 24

297 Implementasjon Detaljerte metodebeskrivelser Det har blitt lagt til metoder i klassen Language under implementasjonen av første inkrement. Language Metodene som er lagt til i klassen er relativt enkle metoder som benytter seg av Javas ResourceBundle-klasse. For å vise hvordan ResourceBundleklassen brukes er metoden setlocale(), som setter et nytt språk, og get(), som henter ut en gitt streng fra den innlastede språkfilen, gjengitt nedenfor. /** * Set the display locale for ovibe. A properties file * must be available for the selected locale. <br> * This will fire a LocaleChangedEvent and all objects that display * data to the user, should listen for such and act accordingly. l The locale to use */ public static void setlocale(locale l) { selectedlocale = l; } // Load the resource file try { strings = ResourceBundle.getBundle(resourceName, l); EventDispatcher.dispatchEvent(new LocaleChangedEvent(l), listeners); } catch(missingresourceexception e) { // Fall back to the default ovibe locale strings = ResourceBundle.getBundle(resourceName, locales[default_locale]); EventDispatcher.dispatchEvent( new LocaleChangedEvent(locales[DEFAULT_LOCALE]), listeners); } /** * Returns the string associated with the given key in the current language. The key of the string to fetch. */ public static String get(string key) { if(selectedlocale == null) setlocale(getavailablelocales()[default_locale]); 25

298 Implementasjon } try { return strings.getstring(key); } catch(missingresourceexception e) { System.err.println("LANGUAGE KEY MISSING: " + e.getmessage()); return "MISSING"; } 3.6 Implementasjonen av gui-modulen Modulen gui inneholder alle de klasser som står for interaksjon mellom brukeren og biblioteket Endringer i forhold til konstruksjonsfasen Dette avsnittet beskriver i detalj hvilke endringer som er gjort i gui-modulen. Klasser som ikke er endret er ikke nevnt i avsnittet. Figur 5 viser det oppdaterte klassediagrammet for modulen gui. ClassInfoWindowController ClassInfoWindowController har blitt endret til også å være en lytter på hendelser av typen FilterGraphEvent og LayoutGraphEvent. Når en av disse hendelsene oppstår vil informasjonen som finnes i panelet bli fjernet. Dette gjøres fordi en markert node ikke nødvendigvis vil finnes i den nye grafen. I tillegg implementerer ClassInfoWindowController grensesnittet LocaleChangedListener, slik at den kan oppdatere språkstrengene når et nytt språk i brukergrensesnittet har blitt valgt. Til slutt har ClassInfoWindowController fått et ekstra felt som viser en liste over underbegrepene til et begrep. Dette er implementert fordi SubClassWindowController, som skal inneholde en liste over underbegrepene til et markert begrep, ikke er implementert i løpet av første inkrement. Figur 6 viser ClassInfoWindowController slik den er implementert i første inkrement. 26

299 Implementasjon Figur 5: Oppdatert klassediagram for gui-modulen 27

300 Implementasjon Figur 6: Implementasjonen av ClassInfoWindowController OWLGraphPanel Klassen OWLGraphPanel ble endret til også å implementere grensesnittet OWLLoadListener, slik at den kan la være å ta imot brukerdata fra mus mens grafen lastes. Dette for å unngå uheldige situasjoner der man markerer en node som ikke finnes i den nye grafen som lastes. Når en graf blir satt på OWLGraphPanel ved hjelp av metoden setgraph() eller setfilteredgraph() begynner den igjen å ta imot brukerdata fra mus. Gruppen oppdaget også at en MouseListener ikke var nok til å dekke det funksjonelle kravet FK-BG4, hvor hele navnet til ett begrep skal vises når musepekeren holdes over noden. Dette førte til at OWLGraphPanel også måtte implementere grensesnittet MouseMotionListener. GraphWindowController Ettersom OWLGraphPanel ble endret til å være en lytter på hendelser av typen OWLLoadEvent, måtte GraphWindowController også endres til å være en tilsvarende lytter. Dette fordi GraphWindowController er klassen som er synlig utenfor pakken, og det er denne som vil legges til som OWLLoadListener i GraphManager. Metoden handle(owlloadevent) vil derfor bare kalle tilsvarende metode på OWLGraphPanel. 28

301 Implementasjon Figur 7 viser GraphWindowController slik den er implementert i første inkrement. Figur 7: Implementasjonen av GraphWindowController OWLMenuBar Det ble lagt til funksjonalitet i OWLMenuBar da gruppen kom fram til at det burde være mulig å endre språk i brukergrensesnittet via en funksjon i brukergrensesnittet. Det ble derfor lagt til en ny meny som vist i figur 8. I tillegg ble det lagt til visning av hvilket nivå som er gjeldende for et hierarkisk filter. Figur 8: Meny for språkvalg 29

302 Implementasjon OWLMenuBar har også blitt endret til å implementere grensesnittet LocaleChangedListener. Dette for å kunne oppdatere språkstrengene når det har blitt valgt et nytt språk i brukergrensesnittet. StatusBarController Klassen StatusBarController lytter på hendelser av typen OWLLoadEvent, for å kunne vite når lastingen av en graf starter. Når den mottar en slik hendelse, spør den GraphManager jevnlig om status på innlastingen frem til innlastingen er ferdig eller avbrytes ved en feil. Detaljimplementasjonen av denne løsninge er vist i avsnitt Detaljerte metodebeskrivelser Dette avsnittet beskriver sentrale algoritmer og metoder i de ulike klassene i gui-modulen. ClassInfoWindowController I metoden handle(focuschangedevent) henter man ut noden som har blitt markert, og benytter GraphManager til å hente ut aktuell informasjon om denne noden. Hvordan denne informasjonen skulle hentes ut ble ikke avklart i konstruksjonsfasen, og det har derfor kommet til endel nye metoder i GraphManager. OWLGraphPanel Når en ny graf skal legges ut kalles metoden setgraph() på OWLGraphPanel. Ut ifra hvor mange noder som finnes i grafen beregnes et passende område hvor grafen skal legges ut. Man initialiserer så Layout 6 med hvor stort område den skal legge ut grafen på. Panelet vil få litt ekstra plass på kantene slik at man unngår at noder havner på utsiden av panelet. Til slutt vil man gi Layout en viss tid til å beregne utlegget av grafen. Dette resulterer i at Layout vil gi hver node en posisjon. Disse posisjonene brukes senere når grafen skal tegnes på panelet. Kildekoden for metoden setgraph() er vist under. 6 Layout er et grensesnitt fra biblioteket JUNG 30

303 Implementasjon /** * Method to set a new graph on the panel. * The layout of the graph will be redone. g The new graph to set. */ public void setgraph(graph g) { layout = new edu.uci.ics.jung.visualization.frlayout(g); //calculate new layout area int dimx = (int)math.sqrt(g.numvertices() * vertexarea); if(dimx < minpanelwidth) dimx = minpanelwidth; int dimy = (int)(dimx*ratio); layout.initialize(new Dimension(dimX, dimy)); this.setpreferredsize( new Dimension(dimX + extraspace * 2, dimy + extraspace * 2)); if(layout.isincremental()) { // then increment layout for one second long timenow = System.currentTimeMillis(); while (System.currentTimeMillis() - timenow < layouttime &&!layout.incrementsaredone()) { layout.advancepositions(); } } resetvariables(); handlemouseevents = true; } // setgraph() Når en graf har blitt filtrert og dette skal reflekteres i OWLGraphPanel, blir metoden setfilteredgraph() kalt. I metoden vil man sette den filtrerte grafen på Layout. Layout vil så fjerne de aktuelle nodene og kantene fra grafen som vises på dette tidspunktet, slik at den blir i samsvar med den filtrerte grafen. Koden for metoden setfilteredgraph() er vist under. /** * Method to set a filtered graph which will be applied to the layout. g The filtered graph. */ public void setfilteredgraph(graph g) { layout.applyfilter(g); resetvariables(); handlemouseevents = true; 31

304 Implementasjon } StatusBarController Når StatusBarController opprettes, lager den et Timer-objekt for å kunne spørre GraphManager om status hver PROGRESS_POLL_INTERVALL millisekunder når innlasting pågår. Når innlasting startes, mottas en OWLLoadEvent. Dette fører til at fremgangsindikatoren blir gjort synlig og at timeren startes. Timer-klassen spør så GraphManager om oppdatert status helt til enten en OWLLoadError mottas eller GraphManager kaster et NotLoadingException. Kildekoden som oppnår denne oppførselen er gjengitt nedenfor. /** * Constructor for the class */ public StatusBarController() { super(); // Add this class as a listener for OWL load events GraphManagerImpl.getInstance().addOWLLoadListener(this); progressbar = new JProgressBar(); progressbar.setindeterminate(true); progressbar.setvisible(false); status = new JLabel(); timer = new Timer(PROGRESS_POLL_INTERVAL, new ActionListener() { public void actionperformed(actionevent evt) { try { String s = GraphManagerImpl.getInstance().getLoadProgress(); status.settext(s); } catch(notloadingexception e) { status.settext(""); progressbar.setvisible(false); timer.stop(); } } }); } init(); /** 32

305 Implementasjon * Handle an OWLLoadEvent and start the timer which polls the load * progress description every PROGRESS_POLL_INTERVAL milliseconds, or * stop it if it s an OWLLoadErrorEvent. e The OWLLoadEvent */ public void handle(owlloadevent e) { if(e instanceof OWLLoadErrorEvent) { timer.stop(); if(progressbar.isvisible()) progressbar.setvisible(false); status.settext(language.get(language.ls_failed)); return; } progressbar.setvisible(true); timer.start(); } 33

306 Implementasjon 4 Testapplikasjonen for biblioteket For å kunne teste de ulike delene av biblioteket ble en liten testapplikasjon implementert. Denne applikasjonen benytter seg av alle panelene som er implementert i første inkrement, og er et eksempel på hvordan biblioteket kan brukes for å visualisere ontologier. Testapplikasjonen er brukt til å kjøre alle systemtester og akseptansetesten, og for å feilsøke eller bekrefte at nylig implementerte elementer fungerer. Den skal også brukes under presentasjonen av prosjektet. Testapplikasjonen er lagt i pakken demos. Klassen heter OvibeTest, og inneholder stort sett en JFrame som benytter seg av de ulike panelene biblioteket tilbyr, og lytter dessuten på OWLLoadEventer for å kunne vise en feilmelding hvis innlasting feiler. Et skjermbilde av testapplikasjonen er vist i figur 9. Figur 9: Testapplikasjon for biblioteket 34

307 Implementasjon 5 Status på produktet Gruppen har greid å fullføre ett inkrement innenfor de gitte tidsrammene. Første inkrement har resultert i et fungerende bibliotek for visualisering av ontologier. Biblioteket er imidlertid langt fra ferdig. Første inkrement dekker omtrent én tredel av kravene som er utarbeidet til biblioteket. Biblioteket mangler dermed en del funksjonalitet. Det er et potensiale for forbedringer av de implementerte kravene. To krav, FK-HA6 og FK-HA7, har ikke blitt implementert på grunn av begrensninger i ett av de underliggende bibliotekene som benyttes. Slik biblioteket er etter første inkrement, klarer det å visualisere ontologier, og å vise detaljert informasjon om begrep som velges. Et rammeverk for utsending av hendelser er på plass, noe som gjør biblioteket godt rustet for å kunne integreres i Doctors in Business (DiB) sitt system. En førsteutgave av fasadeklassene til de ulike modulene er implementert, og hovedaspektene i designet for hver enkelt modul er dermed på plass. Det er lagt mye vekt på å lage gode løsninger fremfor raske, og som et resultat av dette fokuset mener gruppen at de delene av biblioteket som er implementert totalt sett holder høy kvalitet. Kvaliteten på den utarbeidede kildekoden gir DiB et godt grunnlag for videre arbeid med biblioteket. 35

308 Implementasjon 6 Informasjon til nye utviklere Dette kapittelet inneholder et avsnitt om kildekodetreet i biblioteket, og et sett med retningslinjer for videreutvikling. 6.1 Kildekodetre Kildekoden i biblioteket er inndelt i kataloger som representerer modulene i biblioteket. Under hver katalog ligger kildekoden til klassene i modulen, stort sett som en fil per klasse. Klasser som kun brukes av én av klassene i modulen, og i tillegg er veldig sterkt knyttet mot denne klassen, ligger i samme fil som klassen. Figur 10 viser katalogstrukturen for kildekoden til biblioteket. Figur 10: Katalogstruktur for kildekoden til biblioteket 6.2 Retningslinjer for videreutvikling Biblioteket er implementert med fokus på modularisering og gjenbrukbar kildekode som skal være lett å videreutvikle. For at biblioteket skal holde den samme kvaliteten når det videreutvikles, legger gruppen her ned noen få retningslinjer for videreutvikling som bør følges: Kryssreferanser mellom moduler bør ikke forekomme. Dersom modulene benytter seg av hverandre på en måte som gir kryssreferanser, bør 36

309 Implementasjon modulene slås sammen på en eller annen måte, for eksempel ved å gjøre den ene om til en submodul av den andre. Eventuelt kan modulene kommunisere gjennom hendelser (se under). I tilfeller der informasjon skal sendes til flere moduler samtidig bør man bruke hendelser. Hendelser bør også benyttes hvis man skal sende informasjon til en eller flere mottakere som man ikke kjenner til. Antall fasadeklasser i en modul bør holdes på et absolutt minimum. Helst skal en modul bare ha én fasadeklasse. På denne måten holdes kompleksiteten så lav som mulig. Tidkrevende operasjoner som skal benyttes i moduler som trenger å være responsive bør kjøres i en egen tråd. I biblioteket som er implementert er dette så langt løst ved å bruke Spin. 6.3 Videre utvikling av biblioteket Under implementasjonen har det kommet fram flere aspekter som gruppen mener kan forandres innenfor rammene til første inkrement. Disse følger under i uprioritert rekkefølge Endring av utleggsalgoritme Utleggsalgoritmen som benyttes er Fruchterman-Reingold 7 som leveres med JUNG. Denne har flere svakheter. For det første har den store krav til utleggsområde. Dette fører til store områder i panelet grafen tegnes på der det ikke ligger informasjon. Om algoritmen gis mindre område for å tegne grafen, fører det til at noder overlapper hverandre. Videre krysser kanter hverandre relativt ofte, og de tegnes opp med lite hensyn til andre kanter. Dette medfører at kanter mellom noder kan ligge over hverandre. Da de andre utleggsalgoritmene som følger med JUNG er enda mindre egnet, burde det vurderes å utvikle en ny algoritme for utlegging av grafer, enten med utgangspunkt i en av de eksisterende eller fra bunnen av. 7 Fruchterman-Reingolds algoritme er en spesialisering av Spring embedder som ble evaluert i forstudiet. 37

310 Implementasjon Mer informasjon fra OWL-tolking Jena, biblioteket som er benyttet for tolking av OWL-filene, mangler funksjonalitet for å støtte krav FK-HA5 - Syntaksfeil i OWL og FK-HA7 - Dataignorering i OWL. Begge disse kravene dreier seg om å gi brukeren ekstrainformasjon om tolkingsprosessen. I tillegg er de eksisterende feilmeldingsmulighetene for lite finkornet. Linjenummeret til hvor en feil har blitt oppdaget er veldig nyttig for å raskt kunne rette feil i en OWL-fil, men denne informasjonen kan ikke hentes fra Jena. Da kildekoden til Jena er åpen og kan videreutvikles fritt, anbefaler gruppen at denne blir sett på for å kunne legge til den ønskede funksjonaliteten. Alternativt kan også andre bibliotek for OWL-tolking testes Grafposisjon etter filtrering En filtreringsoperasjon kan medføre at grafen tegnes på nytt fra bunn av, og dette kan medføre at grafens posisjon og utseende utenom de filtrerte dataene endres. Dersom en ny algoritme vurderes, burde den inkludere mulighet for å sentrere samme node som var sentrert før filtrering. Om ny utleggsalgoritme ikke vurderes, kan sentrering likevel implementeres. Gruppen mener at dette vil medføre en økning i brukbarheten til biblioteket. 38

311 Implementasjon 7 Installasjonsveiledning Dette kapittelet beskriver de lisenser som gjelder for å kunne benytte biblioteket, og installasjonsprosedyren for biblioteket. 7.1 Lisenser Biblioteket er avhengig av en del tredjeparts bibliotek for å kunne kjøre. Disse tredjepartsbibliotekene har egne lisenser, og for å kunne bruke biblioteket må man godta disse lisensene og betingelsene de gir. Under følger en liste over de tredjeparts bibliotekene biblioteket benytter seg av, og lisensene deres. Bibliotek Filer Lisens ANTLR antlr.jar ANTLR license 8 COLT colt.jar, concurrent.jar COLT license 9 ICU4J icu4j.jar ICU license 10 Jakarta jakarta-oro.jar, commonscollections-3.1.jar, Apache license v commons- logging.jar Jena jena.jar Jena license 12 JUNG jung.jar BSD license 13 JUnit junit.jar IBM Common Public License v log4j log4j.jar Apache license v Spin spin.jar GNU Lesser General Public License 16 Xerces xercesimpl.jar, xml-apis.jar Apache license v Tabell 3: Lisensoversikt for tredjepartsbibliotekene som kreves av biblioteket hoschek/colt/license.html 10 checkout /icu/license.html

312 Implementasjon 7.2 Installasjon av Java Java må lastes ned fra Sun Microsystems nettsider ( Nettsidene forklarer installasjonsprosessen steg for steg. 7.3 Installasjon av biblioteket Biblioteket, og alle biblioteker som kreves av det, er pakket i en zip-fil. Denne zip-filen inneholder altså alt man trenger for å bruke biblioteket. Installasjonsprosedyren avhenger noe av hva man skal gjøre med biblioteket; hvorvidt man skal benytte biblioteket eller videreutvikle det Installasjon for å benytte biblioteket i en applikasjon Denne installasjonsprosedyren skal følges av alle som skal benytte biblioteket i en eller annen applikasjon. 1. Installasjon Pakk ut zip-filen ovibe.zip til katalogen du ønsker å ha biblioteket installert i. 2. Test av biblioteket (valgfritt) For å demonstrere funksjonaliteten til biblioteket, foreligger det en enkel applikasjon. Denne kan kjøres ved å starte jar-filen til biblioteket: java -jar ovibe.jar Installasjon for videreutvikling av biblioteket Denne installasjonsprosedyren skal følges av de som ønsker å videreutvikle biblioteket. 1. Utpakking av filer Pakk ut filen ovibe_src.zip. 40

313 Implementasjon 2. Oppsett av biblioteket I katalogen ovibe_src.zip ble pakket ut til ligger en katalog lib og en katalog src. Alle bibliotekene (.jar-filene) i lib-katalogen må legges til i CLASSPATH. Det foreligger ikke noe byggesystem for biblioteket. Gruppen anbefaler å bruke Eclipse Test av biblioteket (valgfritt) For å demonstrere funksjonaliteten til biblioteket, foreligger det en enkel applikasjon. Denne kan kjøres ved å gjøre følgende fra katalogen ovibe_src.zip ble pakket ut til: java ovibe.demos.ovibetest Dette forutsetter at biblioteket er kompilert. 18 Eclipse er et utviklingsmiljø som støtter flere språk, blant annet Java. Se 41

314 Implementasjon Referanser [1] Code conventions for the java programming language, [2] Kundestyrt prosjekt, gruppe 14: Ontologidrevet dokumentforvaltning, forstudie, [3] Kundestyrt prosjekt, gruppe 14: Ontologidrevet dokumentforvaltning, konstruksjon, [4] Kundestyrt prosjekt, gruppe 14: Ontologidrevet dokumentforvaltning, kravspesifikasjon,

315 Ontologidrevet dokumentforvaltning Testdokument TDT4290 Kundestyrt prosjekt Institutt fra datateknikk og informasjonsvitenskap Fakultet for informasjonsteknologi, matematikk og elektroteknikk Norges teknisk-naturvitenskapelige universitet Gruppe 14 Espen Hansen Ole-Marius Moe-Helgesen Geir Storli Karl Hatteland Steinar Skjerven Håvard Stranden

316

317 Testdokument Innhold 1 Innledning Oversikt Overordnet testplan Testteknikker Black-box-testing White-box-testing Teststrategi Enhetstest Modultest Systemtest Integrasjonstest Brukbarhetstest Akseptansetest Utførelse av tester Detaljerte testbeskrivelser Ansvarsfordeling for utvikling av tester Ansvarsfordeling for testutførelse Utførelse av tester Godkjenning av tester Overordnet tidsplan Testmaler Testbeskrivelser og testresultat for første inkrement Enhetstester

318 Testdokument Testmodul: Event Testmodul: Graph Systemtester Systemtester for funksjonelle krav Systemtester for ikke-funksjonelle krav Akseptansetest Konklusjon 69 Referanser 70 3

319 Testdokument Tabeller 1 Mal for enhetstestene Mal for systemtestene Mal for resultattabellene Mal for feilrapportene Oversikt over tester Oversikt over feilrapporter Testbeskrivelse for ET Testresultatet for ET Testbeskrivelse for ET Testresultatet for ET Feilrapport for RT Testbeskrivelse for ET Testresultatet for ET Testbeskrivelse for ET Testresultatet for ET Testbeskrivelse for ET Testresultatet for ET Testbeskrivelse for krav FK-HA Testresultatet for ST Feilrapport for RT Testbeskrivelse for krav FK-HA2, FK-HA3, FK-HA4 og FK- BG Testresultatet for ST Testresultatet for ST Testbeskrivelse for krav FK-HA

320 Testdokument 25 Testresultatet for ST Feilrapport for RT Testbeskrivelse for krav FK-HA6 og FK-HA Testbeskrivelse for krav FK-BH2 og FK-BH Testresultatet for ST Testbeskrivelse for krav FK-BG3, FK-BG4 og FK-BG Testresultatet for ST Testbeskrivelse for krav FK-FI Testresultatet for ST Testbeskrivelse for krav IFK-GK Testresultatet for ST Feilrapport for RT Feilrapport for RT Feilrapport for RT Testbeskrivelse for krav IFK-GK Testresultatet for ST Feilrapport for RT Testbeskrivelse for krav IFK-GK Testresultatet for ST Testbeskrivelse for krav IFK-GK Testresultatet for ST Testbeskrivelse for krav IFK-BG Testresultatet for ST Testbeskrivelse for krav IFK-BG Testresultatet for ST Testbeskrivelse for krav IFK-BG

321 Testdokument 51 Testresultatet for ST Testbeskrivelse for krav IFK-KY1, IFK-KY2 og IFK-KY Testresultatet for ST Testresultatet for ST Testbeskrivelse for krav IFK-DOK Testresultatet for ST Feilrapport for RT Krav som skal sjekkes i akseptansetesten

322 Testdokument 1 Innledning Dette dokumentet inneholder all testdokumentasjon. Dette inkluderer den overordnede testplanen som gruppen har valgt å legge her i stedet for i prosjektdirektivet. De viktigste momentene i testfasen er å: 1. Sjekke at den spesifiserte funksjonaliteten er tilstede og at de krav som er satt er tilfredsstilt. 2. Finne feil og mangler. 3. Eventuelt oppdage nye sider som ikke er beskrevet i kravspesifikasjonen. Videre er det under utvikling av et bibliotek viktig å gjennomføre testing slik at man får foretatt verifisering og validering. Det er viktig å sørge for at biblioteket oppfører seg korrekt, og i den forbindelse vil man i testingen verifisere at kildekoden ikke inneholder feil. Det er også viktig at biblioteket inneholder den funksjonaliteten som brukeren ønsker det skal inneholde, og i den forbindelse vil man i testingen validere at kravene er dekket. 1.1 Oversikt I kapittel 2 finner man en overordnet testplan. Kapittel 3 inneholder testbeskrivelser og testresultat for første inkrement, samt feilrapport for feil som ble oppdaget under testgjennomføring. I dette kapittelet vil man også finne en akseptansetest. I kapittel 4 finner man en konklusjon for testfasen. 7

323 Testdokument 2 Overordnet testplan Dette kapittelet inneholder den overordnede testplanen som viser en oversikt over hvordan biblioteket skal testes. Testplanen inneholder ingen detaljerte testbeskrivelser, men en oversikt over strategier og rutiner som vil bli benyttet i testingen. 2.1 Testteknikker Det er vanlig å klassifisere testteknikker basert på hvilken kunnskap som ligger til grunn når man lager testdata. I de to neste avsnittene følger en beskrivelse av to testteknikker som heter black-box-testing og white-boxtesting[5] Black-box-testing I black-box-testing er den interne strukturen til det som skal testes ukjent for testeren. Den eneste kunnskapen testeren besitter er kunnskap om funksjonaliteten, og dette danner grunnlaget for testdataene som skal lages. Deretter vil man evaluere om gitte inndata gir forventede utdata. Denne testteknikken passer godt ved testing på høynivå, der man gjerne har veldefinerte krav som skal valideres. Testteknikken kan også passe på lavnivå, hvis testene er skrevet før kildekoden den skal teste. Figur 1 viser black-box-testing. Figur 1: Black-box-testing White-box-testing I white-box-testing vil eksplisitt kunnskap om den interne strukturen til det som skal testes brukes for å lage testdata. I motsetning til black-box-testing benyttes det her spesifikk kunnskap om programkoden til å vurdere utdata. 8

324 Testdokument Denne testteknikken passer godt ved testing på lavnivå, som for eksempel enhetstester, såfremt testene ikke er skrevet før kildekoden skrives. Forklaring av enhetstest finner man under avsnitt 2.2. Her er man gjerne interessert i å finne feil i implementasjonen, samt optimalisere kildekode og algoritmer. 2.2 Teststrategi Den teststrategien gruppen velger å bruke avhenger av hvilke testtyper gruppen ønsker å benytte seg av. Avsnittene som følger inneholder beskrivelser av testtyper [4], [5]. Det blir også i hvert avsnitt beskrevet om gruppen ønsker å benytte seg av den aktuelle testtypen Enhetstest Enhetstester er tester man kjører på de minste definerte kodeenhetene, som for eksempel metoder, klasser og grensesnitt. Målet med enhetstesting er å verifisere at alle kodeenheter fungerer som de skal hver for seg før de settes sammen. Gruppen ønsker å bruke enhetstester. Gruppen vil for de mest kritiske enhetene lage automatiske tester som blir beskrevet i formelle testtabeller. Disse testtabellene kan man finne i avsnitt 3.1. De automatiske testene vil bli skrevet før eller uavhengig av kildekoden. Disse går da under testteknikken black-box-testing som ble beskrevet tidligere i kapittelet, siden man ikke vil kjenne den interne strukturen. De enhetene som ikke skal testes automatisk vil testes underveis av gruppemedlemmet som utvikler kildekoden. Dette utføres som white-box-tester, da kunnskap om selve programkoden benyttes for å vurdere utdata. Disse testene vil ikke formaliseres i testtabeller, som det ble gjort for de kritiske enhetene Modultest De forskjellige kodeenhetene skal settes sammen til moduler. Modultester kjøres på de forskjellige modulene for å kontrollere at samspillet mellom kodeenhetene fungerer som de skal. Her skal man ideelt sett ikke oppdage feil som er relatert til kodeenheter, ettersom disse skulle vært oppdaget i enhetstesten. Gruppen ser for seg at biblioteket må deles opp i moduler, og det vil derfor 9

325 Testdokument være aktuelt med modultester. Disse testene vil eventuelt utføres som blackbox-tester. Gruppen vil ikke formalisere disse testene i testtabeller Systemtest De forskjellige modulene settes sammen som en helhet. Systemtestene skal kontrollere at de forskjellige modulene fungerer sammen på en korrekt måte, samtidig som det skal testes at kravene fra kravspesifikasjonen tilfredsstilles. Testene bruker black-box-teknikken i en kontrollert omgivelse. Gruppen ønsker å bruke denne testtypen. Testtabellene kan man finne i avsnitt 3.1. Biblioteket vil testes separat fra andre utenforstående komponenter i denne testen Integrasjonstest Integrasjonstesten vil være en komplett test av bibiloteket og dets grensesnitt til omgivelsene. Feil som ikke har blitt funnet tidligere skal avdekkes i denne testen, men ikke nødvendigvis alle feil. Man skal samtidig verifisere at biblioteket fungerer i henhold til de funksjonelle og ikke-funksjonelle kravene i kravspesifikasjonen. Biblioteket som gruppen skal utvikle vil testes sammen med andre komponenter i denne testen. Dette vil være komponenter som DiB har utviklet. Siden slike komponenter ennå ikke eksisterer vil gruppen ikke benytte seg av integrasjonstest Brukbarhetstest Brukbarhetstester skal teste interaksjon med bruker. Her ønsker man å få frem hvor brukervennlig det som man har laget er. Gruppen har valgt å ikke bruke brukbarhetstester. Dette fordi biblioteket gruppen skal lage ikke inneholder et ferdig brukergrensesnitt som behøver en brukbarhetstest. 10

326 Testdokument Akseptansetest Akseptansetesten skal avgjøre om biblioteket og dets grensesnitt til omgivelsene fungerer som forventet. Denne testen utføres av kunden. Her er det spesielt viktig at biblioteket er såpass godt testet på forhånd at kunden ikke blir heftet med tekniske feil. Resultatet av denne testen ligger til grunn når man skal avgjøre om biblioteket er godt nok til å tas i bruk. Gruppen ønsker å benytte seg av en akseptansetest. 2.3 Utførelse av tester Dette avsnittet inneholder informasjon om hvordan de forskjellige testene skal utføres Detaljerte testbeskrivelser En detaljert testbeskrivelse er en beskrivelse over hvordan en test skal utføres. Det finnes ingen fasit for hva som skal være med av informasjon i en detaljert testbeskrivelse, men følgende bør i alle fall være med: Testbeskrivelse: de operasjonene som skal gjennomføres. Forventet respons: forventet utdata fra testene. Prebetingelser: hva som skal være oppfylt før testen skal kunne gjennomføres. Godkjenningskriterier: Hva som må være oppfylt for at testen skal godkjennes. Ansvarlig: Ansvarlig for testen. Tidsestimat: Hvor lang tid man forventer å bruke på utførelsen av testen. Detaljerte testbeskrivelser skal bli skrevet for alle tester som skal formaliseres i form av testtabeller. 11

327 Testdokument 2.4 Ansvarsfordeling for utvikling av tester Testansvarlig har ansvaret for utvikling av tester, men kan delegere dette arbeidet til andre gruppemedlemmer. Tester hvor white-box-teknikken blir brukt må skrives av gruppemedlemmer som har kjennskap til den interne strukturen. 2.5 Ansvarsfordeling for testutførelse Dette avsnittet inneholder informasjon om hvem som skal utføre de forskjellige testene, og hvem som skal godkjenne dem Utførelse av tester Under følger en oversikt over hvem som har ansvaret for å utføre de forskjellige testene. Enhetstestene utføres av det gruppemedlemmet som har skrevet kildekoden til enheten som testes. Det er spesifisert i avsnitt 3.1 hvem som har ansvaret for de enhetstestene som har blitt formalisert. Modultestene utføres av den/de som er mest involvert i programmeringen av modulen. Systemtestene: Det er spesifisert i avsnitt 3.2 hvem som har ansvaret for systemtestene. Integrasjonstesten: Denne testtypen vil ikke bli benyttet. Brukbarhetstestene: Denne testtypen vil ikke bli benyttet. Akseptansetest utføres av kunden. Ansvaret for utførelse har testansvarlig Godkjenning av tester Under følger en oversikt over hvem som godkjenner de forskjellige testene som skal utføres. 12

328 Testdokument Enhetstestene godkjennes av gruppemedlemmet som utførte testen. Modultestene godkjennes av gruppemedlemmet/gruppemedlemmene som utførte testen. Systemtestene godkjennes av gruppemedlemmet som utførte testen. Akseptansetesten godkjennes av kunden Overordnet tidsplan Gruppen vil utvikle og utføre tester i både konstruksjons- og implementasjonsfasen. Dette betyr at utvikling og utføring av tester vil foregå i tidsrommmet mandag til torsdag Testmaler I dette avsnittet ønsker gruppen å vise malene til testtabellene og forklare hva hver rad innebærer. I tabell 1 og 2 finner man malene for enhetstestene og systemtestene som inneholder en beskrivelse av her rad. Videre i tabell 3 finner man mal for resultattabellene og en beskrivelse av hver rad. I tabell 4 finner man mal for feilrapportene og en beskrivelse av hver rad. TestID Dato skrevet Testansvarlig Estimert tid Testtype Beskrivelse Prebetingelser Forventet respons Godkjenningskriterier TestID til testen. Datoen testen ble laget. Personen som skrev testen og har ansvaret for at den blir gjennomført. Tid man tror testen vil ta. Type test. En beskrivelse av testen. Hvilke betingelser som må være sanne for at testen skal kunne utføres. Forventet respons for testen. En beskrivelse av hva som skal til for at testen godkjennes. Tabell 1: Mal for enhetstestene 13

329 Testdokument TestID Dato skrevet Testansvarlig Estimert tid Testtype Krav Beskrivelse Prebetingelser Teststeg Forventet respons Godkjenningskriterier TestID til testen. Datoen testen ble laget. Personen som skrev testen og har ansvaret for at den blir gjennomført. Tid man tror testen vil ta. Type test. Hvilket krav testen i hovedsak ønsker å undersøke. En beskrivelse av testen. Hvilke betingelser som må være sanne for at testen skal kunne utføres. Nummererte steg som forklarer hva den som utfører testen skal gjøre. Forventet respons for hvert steg over. En beskrivelse av hva som skal til for at testen skal godkjennes. Tabell 2: Mal for systemtestene ResultatID TestID Dato utført Testansvarlig Tidsbruk Feil (Avvik fra forventet respons) Kommentarer Godkjenning ResultatID til testen. TestID til test som ble utført. Datoen testen ble utført. Hvem som utførte testen. Hvor lang tid ble brukt på testen. Her skal det refereres til eventuelle feilrapport. Andre kommentarer til testen. Her skal det stå godkjent hvis testen godkjennes, hvis ikke skal det stå feilid. Man vil da måtte se om disse feilrapportene har fått godkjent om man vil vite om denne testen er godkjent. Tabell 3: Mal for resultattabellene 14

330 Testdokument FeilID ResultatID Alvorlig-hetsgrad Beskrivelse Rapportert av Ansvarlig for retting Dato rettet Tidsbruk Godkjenning FeilID ResultatID til tabellen feil oppstod. Hvor alvorlig feilen er. Lav, Middels eller Høy. Beskrivelse av feil og hva som må rettes. Hvem som rapporterte feilen. Hvem som har ansvaret for at feilen rettes. Når feilen ble rettet. Hvor lang tid ble brukt på retting av feil. Denne skal ha enten Godkjent eller Venter godkjenning Tabell 4: Mal for feilrapportene 15

331 Testdokument 3 Testbeskrivelser og testresultat for første inkrement Dette avsnittet inneholder testbeskrivelser og testresultat basert på kravene i kravspesifikasjonen for første inkrement[3]. Feil som blir avduket vil bli beskrevet i egne tabeller. Disse vil, om mulig, bli rettet opp før prosjektet overleveres kunden. Tabell 5 inneholder en oversikt over hvilke enhets- og systemtester som er gjennomført. Hvis testen ikke er godkjent vil man finne en referanse til ID for feilrapport i kolonnen godkjent. Videre i tabell 6 vises en oversikt over feilrapportene. 16

332 Testdokument TestID Referanse Krav Dato skrevet Dato utført Godkjent ET1 Tabell 7 Ingen Godkjent ET2 Tabell 9 Ingen FT1 ET3 Tabell 12 Ingen Godkjent ET4 Tabell 14 Ingen Godkjent ET5 Tabell 16 Ingen Godkjent ST1 Tabell 18 FK-HA FT2 ST2 Tabell 21 FK-HA2, FK-HA3, FK-HA4 og FK-BG Godkjent ST3 Tabell 24 FK-HA FT3 ST4 Tabell 27 FK-HA6 og FK-HA7 ST5 Tabell 28 FK-BH2 og FK-BH8 ST6 Tabell 30 FK-BG3, FK-BG4 og FK-BG Ikke utført Ikke godkjent Godkjent Godkjent ST7 Tabell 32 FK-FI Godkjent ST8 Tabell 34 FIK-GK FT4, FT5 og FT6 ST9 Tabell 39 IFK-GK FT7 ST10 Tabell 42 IFK-GK Godkjent ST11 Tabell 44 IFK-GK Godkjent ST12 Tabell 46 IFK-BG Godkjent ST13 Tabell 48 IFK-BG Godkjent ST14 Tabell 50 IFK-BG Godkjent ST15 Tabell 52 IFK-KY1, IFK-KY2 og IFK-KY Godkjent ST16 Tabell 55 IFK-DOK FT8 Tabell 5: Oversikt over tester 17

333 Testdokument TestID Referanse Test som feilet ret- Dato tet Alvorlighetsgrad Godkjent FT1 Tabell 11 ET2 Lav Rettes ikke Venter godkjenning FT2 Tabell 20 ST1 Lav Rettes ikke Venter godkjenning FT3 Tabell 26 ST5 Lav Rettes ikke Venter godkjenning FT4 Tabell 36 ST8 Lav Godkjent FT5 Tabell 37 ST8 Lav Godkjent FT6 Tabell 38 ST8 Lav Godkjent FT7 Tabell 41 ST9 Lav Rettes ikke Venter godkjenning FT8 Tabell 57 ST16 Lav Godkjent Tabell 6: Oversikt over feilrapporter 18

334 Testdokument 3.1 Enhetstester Enhetstesting er testing av de minste definerte kodeenhetene som finnes i biblioteket. Dette kan være grensesnitt, metoder, objekter, klasser og lignende. Gruppen har utført enhetstesting ved hjelp av biblioteket Junit 1. Dette biblioteket benyttes av en lang rekke Javaprosjekter, og passet godt til gruppens bruk. Ved hjelp av biblioteket kunne testene utvikles raskt, og resultater av testkjøringene kunne leses av i ett av de tre medfølgende brukergrensesnittene. Testene ble utviklet med samme krav til kildekode som resten av biblioteket. Disse er å finne i prosjektets implementasjonsdokumentasjon. Gruppen har laget enhetstester for de mest kritiske kodeenhetene i biblioteket. Disse testene er automatiske og heter EventTest.java, FilterTest.java og OWLLoadTest.java Testmodul: Event Dette avsnittet inneholder tester fra modulen Event. Klasser som blir testet er EventDispatcher, Event og Error. Testene beskrives i tabell 7 og 9. Enhetstest ET1 I tabell 7 vises beskrivelse av test ET1. Testresultatene fra ET1 vises i tabell 8. 1 Junit er et åpent utviklingsprosjekt og er tilgjengelig fra 19

335 Testdokument TestID ET1 Dato skrevet Testansvarlig Estimert tid Testtype Beskrivelse Prebetingelser Forventet respons Godkjenningskriterier Ole-Marius Ti minutter Enhetstest Skal teste metode dispatchevent() og kontrollere at en hendelse blir sendt til alle lyttere. Implementasjonen av første inkrement må være ferdig. Alle klasser som lytter etter hendelsen skal motta hendelsen når den avfyres. Testen godkjennes om alle lyttere mottar hendelsen. Tabell 7: Testbeskrivelse for ET1 ResultatID TestID RT1 ET1 Dato utført Testutfører Tidsbruk Feil (Avvik fra forventet respons) Kommentarer Godkjenning Ole-Marius Ca ett minutt Ingen feil eller avvik. Kompilerte filen EventTest.java og kjørte denne. Godkjent Tabell 8: Testresultatet for ET1 20

336 Testdokument Enhetstest ET2 I tabell 9 vises beskrivelse av test ET2. Testresultatene fra ET2 vises i tabell 10, med en feilrapport for feilen som ble funnet vist i tabell 11. TestID ET2 Dato skrevet Testansvarlig Estimert tid Testtype Ole-Marius Ti minutter Enhetstest Beskrivelse Skal teste om hendelseskilde blir satt. Metode getsource() kalles og skal returnere kilden. Prebetingelser Forventet respons Godkjenningskriterier Implementasjonen av første inkrement må være ferdig og enhetstest ET1 må være ferdig og godkjent. Alle hendelsene som sendes ut skal ha satt hendelsekilde. Testen godkjennes om alle hendelser som sendes ut har kilde. Tabell 9: Testbeskrivelse for ET2 ResultatID TestID RT2 ET2 Dato utført Testutfører Tidsbruk Feil (Avvik fra forventet respons) Kommentarer Godkjenning Ole-Marius Ca ett minutt Én feil funnet. Se tabell 11. Kompilerte filen EventTest.java og kjørte denne. FT1 Tabell 10: Testresultatet for ET2 21

337 Testdokument FeilID ResultatID Alvorlighetsgrad FT1 RT2 Beskrivelse Dette ble aldri implementert. Se implementasjonsdokumentet for begrunnelse [1]. Rapportert av Ansvarlig for retting Dato rettet Tidsbruk Godkjenning Lav Ole-Marius Ingen Ikke planlagt Ikke estimert Venter godkjenning Tabell 11: Feilrapport for RT2 22

338 Testdokument Testmodul: Graph Dette avsnittet handler om test av modulen Graph. Klasser som blir testet er GraphMananger; tabell 12 og OWLLoader; tabell 14 og 16. Enhetstest ET3 I tabell 12 vises beskrivelse av test ET3. Testresultatene fra ET3 vises i tabell 13. TestID ET3 Dato skrevet Testansvarlig Estimert tid Testtype Beskrivelse Prebetingelser Forventet respons Godkjenningskriterier Ole-Marius Ti minutter Enhetstest Skal teste metode setfilter() og kontrollere at filtreringen blir utført. Skal kunne oppdatere, sette nytt filter, og grafen skal bli filtrert igjen. I første inkrement skal det kun finnes tre filter, og kun ett aktivt om gangen. Disse tre er sub-klasse relasjoner av og på, andre relasjoner av og på og hierakisk hvor dypt som skal vises. Implementasjonen av første inkrement må være ferdig. Filtreringen blir utført. Testen godkjennes om filtreringen blir utført. Tabell 12: Testbeskrivelse for ET3 ResultatID TestID RT3 ET3 Dato utført Testutfører Tidsbruk Feil (Avvik fra forventet respons) Kommentarer Godkjenning Ole-Marius Ca ett minutt Ingen feil eller avvik. Kompilerte filen FilterTest.java og kjørte denne. Godkjent Tabell 13: Testresultatet for ET3 23

339 Testdokument Enhetstest ET4 I tabell 14 vises beskrivelse av test ET4. Testresultatene fra ET4 vises i tabell 15. TestID ET4 Dato skrevet Testansvarlig Estimert tid Testtype Beskrivelse Ole-Marius Ti minutt Enhetstest Skal teste metodene loadfromfile() og loadfromurl() med en rekke forskjellige input. 1. OWL-fil uten feil blir lastet korrekt. 2. OWL-fil med feil blir rapportert som feil. 3. OWL-fil uten feil men med redundant informasjon skal lastes korrekt. 4. Lasting av OWL-fil fra feil URL skal raporteres med feil. Prebetingelser Forventet respons Implementasjonen av første inkrement må være ferdig. Forventet respons er for hvert punkt: 1. Filen blir lastet og grafen blir lagt ut, uten feilmeldinger. 2. Fillastingen blir avbrutt og feilmelding vises på skjermen. 3. Filen blir lastet og grafen blir lagt ut, uten feilmeldinger. 4. Det skal komme opp en feilmelding som forklarer at filen ikke eksisterer på oppgitte URL Godkjenningskriterier Testen godkjennes om testingen gir samme resultat som forventet respons. Tabell 14: Testbeskrivelse for ET4 24

340 Testdokument ResultatID TestID RT4 ET4 Dato utført Testutfører Tidsbruk Feil (Avvik fra forventet respons) Kommentarer Godkjenning Ole-Marius Ca ett minutt Ingen feil eller avvik. Kompilerte filen OwlLoadTest.java og kjørte denne. Godkjent Tabell 15: Testresultatet for ET4 25

341 Testdokument Enhetstest ET5 I tabell 16 vises beskrivelse av test ET5. Testresultatene fra ET5 vises i tabell 17. TestID ET5 Dato skrevet Testansvarlig Estimert tid Testtype Beskrivelse Prebetingelser Forventet respons Godkjenningskriterier Ole-Marius Ti minutt Enhetstest Skal teste metoden loadfromfile() og kontrollere at den kjører i en annen tråd slik at framgangsindikator også går mens man holder på å åpne en OWL-fil. Implementasjonen av første inkrement må være ferdig. Når man åpner en OWL-fil skal statusbaren vise at noe skjer og ha en kort tekst som beskriver hva som skjer. Testen godkjennes om alle resultat av testen er lik forventet respons. Tabell 16: Testbeskrivelse for ET5 ResultatID TestID RT5 ET5 Dato utført Testutfører Tidsbruk Feil (Avvik fra forventet respons) Kommentarer Godkjenning Ole-Marius Ca ett minutt Ingen feil eller avvik. Kompilerte filen OwlLoadTest.java og kjørte denne. Godkjent Tabell 17: Testresultatet for ET5 26

342 Testdokument 3.2 Systemtester Dette avsnittet inneholder testbeskrivelser, resultattabeller og feilrapporter for systemtestene. Disse har tatt utgangspunkt i de funksjonelle og ikkefunksjonelle kravene som skal være dekket i første inkrement. Tester som omhandler funksjonelle krav vil man finne i avsnitt Tester som omhandler de ikke-funksjonelle kravene finner man i avsnitt Noen tester vil ta for seg flere krav i samme test. Det vil komme frem av tabellen hvilke tester dette er Systemtester for funksjonelle krav I dette avsnittet vil man finne tester som undersøker funksjonelle krav for første inkrement fra kravspesifikasjonen. Systemtest ST1 I tabell 18 vises beskrivelse av test ST1. Testresultatene fra ST1 vises i tabell 19. I tabell 20 beskrives feilen som dukket under kjøring av denne testen

343 Testdokument TestID ST1 Dato skrevet Testansvarlig Estimert tid Testtype Krav Beskrivelse Prebetingelser Teststeg Steinar 30 minutter Systemtest FK-HA1 For å se om biblioteket kan lese alle OWL-typer, vil denne testen gå igjennom alle funksjonene i OWL. Da kan man si at biblioteket håndterer alle OWL-typer. Test case for alle funksjoner hentes fra URL 2. Test cases i form av OWL-filer. For alle test case: 1. Åpne test case. Forventet respons 1. Ontologien representeres som en graf. Godkjenningskriterier Test godkjennes hvis biblioteket håndterer alle funksjonene. Tabell 18: Testbeskrivelse for krav FK-HA1 ResultatID TestID RT6 ST1 Dato utført Testutfører Tidsbruk Feil (Avvik fra forventet respons) Kommentarer Godkjenning Steinar 30 minutter Det ble funnet én feil. Denne kan man finne i FT2 i tabell 20. Når FT2 blir godkjent vil denne testen også bli godkjent. Den håndterte alle funksjonene, hvis spesialtilfellet beskrevet i FT2 ikke forekom. FT2 Tabell 19: Testresultatet for ST1 28

344 Testdokument FeilID ResultatID Alvorlighetsgrad Beskrivelse Rapportert av Ansvarlig for retting Dato rettet Tidsbruk Godkjenning FT2 RT6 Lav Når en OWL-fil ikke inneholdt noen klasser fikk man en feilmelding hvor det stod at OWL-filen var tom eller inneholdte feil. Denne feilmeldingen beskriver ikke situasjonen korrekt. Feilmeldingen må fortelle at det ikke er noe å visualisere i denne OWLfilen. På grunn av knapp tid, er det ikke planlagt å rette denne feilen. Steinar Ingen Ikke planlagt Ikke estimert Venter godkjenning Tabell 20: Feilrapport for RT6 29

345 Testdokument Systemtest ST2 I tabell 21 vises beskrivelse av test ST2. Denne testen gjennomføres to ganger. Den første gangen med åpning av OWL-fil fra lokal disk vist i resultattabell 22. Den andre gangen med åpning av OWL-fil fra URL vist i resultattabell 23. TestID ST2 Dato skrevet Testansvarlig Estimert tid Testtype Krav Beskrivelse Prebetingelser Teststeg Forventet respons Godkjenningskriterier Espen Ti minutter Systemtest FK-HA2, FK-HA3, FK-HA4 og FK-BG1 Testen skal sjekke at det er mulig å laste en ontologi representert av en OWL-fil fra disk/url. Denne ontologien skal så vises på skjermen. En OWL-fil må foreligge på lokal disk/url. Åpne en OWL-fil fra lokal disk/url. Ontologien representeres som en graf i hovedvinduet. Ontologien som er representert i OWL-filen vises som en graf i hovedvinduet og den grafiske representasjonen er korrekt. Tabell 21: Testbeskrivelse for krav FK-HA2, FK-HA3, FK-HA4 og FK-BG1 ResultatID TestID RT7 ST2 Dato utført Testutfører Tidsbruk Feil (Avvik fra forventet respons) Kommentarer Godkjenning Espen Fem minutter Ingen feil eller avvik. Åpnet en OWL-fil fra lokal disk. Godkjent Tabell 22: Testresultatet for ST2 30

346 Testdokument ResultatID TestID RT8 ST2 Dato utført Testutfører Tidsbruk Feil (Avvik fra forventet respons) Espen Fem minutter Ingen feil eller avvik. Kommentarer Åpnet en OWL-fil fra URL (ka.owl 3 ). Godkjenning Godkjent Tabell 23: Testresultatet for ST2 3 horrocks/owl/ontologies/ka.owl 31

347 Testdokument Systemtest ST3 I tabell 24 vises beskrivelse av test ST3. Testresultatene fra ST3 vises i tabell 25. I tabell 26 beskrives feilen som dukket under kjøring av denne testen. TestID ST3 Dato skrevet Testansvarlig Estimert tid Testtype Krav Beskrivelse Espen Ti minutter Systemtest FK-HA5 Testen skal sjekke om biblioteket: Oppdager syntaksfeil i en OWL-fil. Gir tilbakemelding til brukeren ved syntaksfeil. Angir hvor i filen feilen ligger. Prebetingelser Teststeg En OWL-fil med syntaksfeil foreligger. 1. Åpne OWL-filen med syntaksfeil. Forventet respons 1. En melding dukker opp som sier at en syntaksfeil i filen finnes, og hvor i filen den er. Godkjenningskriterier Biblioteket skal: Oppdage syntaksfeil. Gi tilbakemelding om at det finnes syntaksfeil. Angi hvor i filen feilen ligger. Tabell 24: Testbeskrivelse for krav FK-HA5 32

348 Testdokument ResultatID TestID RT9 ST3 Dato utført Testutfører Tidsbruk Feil (Avvik fra forventet respons) Kommentarer Godkjenning Espen Fem minutter Det ble funnet én feil. Denne kan man finne beskrevet i FT3 i tabell 26. Når FT3 blir godkjent vil denne testen også bli godkjent. Åpnet en OWL-fil som er skrevet med en annen standard (DAML 4 ). FT3 Tabell 25: Testresultatet for ST3 4 lopatena/cerif/cerif.daml 33

349 Testdokument FeilID ResultatID Alvorlighetsgrad Beskrivelse Rapportert av Ansvarlig for retting Dato rettet Tidsbruk Godkjenning FT3 RT9 Lav Man får en tilbakemelding, men den viser ikke hvor i filen syntaksfeilene ligger. Jena, som brukes til tolking, tilbyr ikke den funksjonaliteten som trengs for å spesifisere hvor i en fil en syntaksfeil ligger. Man må legge til funksjonalitet i Jena som gjør dette. Dette vil være en veldig tidkrevende prosess, og med tanke på den gjenværende tiden velger gruppen å ikke gjøre dette. Kravet som testes har lav viktighetsgrad. Espen Ingen Ikke planlagt Ikke estimert Venter godkjenning Tabell 26: Feilrapport for RT11 34

350 Testdokument Systemtest ST4 I tabell 27 vises beskrivelse av test ST4. Denne ble aldri gjennomført siden FK-HA6 og FK-HA7 aldri ble implementert. For en begrunnelse av hvorfor disse kravene ikke ble implementert se implementasjonsdokumentet[1]. TestID ST4 Dato skrevet Testansvarlig Estimert tid Testtype Krav Beskrivelse Prebetingelser Teststeg Espen 15 min Systemtest FK-HA6 og FK-HA7 Testen skal avklare om biblioteket gir tilbakemelding om hvilke egenskaper i OWL-filen som ikke ble tatt med i henhold til bestemte subsett og OWL-type. En OWL-fil med egenskaper utenfor subsettet foreligger. 1. Åpne OWL-filen. Forventet respons 1. Ontologien vises som en graf. 2. Det blir gitt tilbakemelding om hvilke egenskaper i OWL-filen som ikke er tatt med. 3. Det blir gitt tilbakemelding om OWL-filen er av type Full, DL eller Lite. Godkjenningskriterier Tilbakemelding om utelatte egenskaper blir gitt. Tilbakemeldingen skal inneholde hvilke egenskaper som har blitt utelatt. Tilbakemelding om OWL-type. Tabell 27: Testbeskrivelse for krav FK-HA6 og FK-HA7 35

351 Testdokument Systemtest ST5 I tabell 28 vises beskrivelse av test ST5. Testresultatene fra ST5 vises i tabell 29. TestID ST5 Dato skrevet Testansvarlig Estimert tid Testtype Krav Beskrivelse Prebetingelser Teststeg Forventet respons Espen Ti minutter Systemtest FK-BH2 og FK-BH8 Testen skal undersøke om det er mulig å velge et begrep i grafen i hovedvinduet, og om korrekt informasjon om det begrepet vises i informasjonsvinduet. En graf foreligger. Klikk på et begrep i grafen med musen. 1. Begrepet skifter farge. 2. Informasjon om begrepet vises i informasjonsvinduet. Godkjenningskriterier Begrepet skal skifte farge. Informasjon om begrepet skal vises i informasjonsvinduet. Informasjonen skal være korrekt. Tabell 28: Testbeskrivelse for krav FK-BH2 og FK-BH8 36

352 Testdokument ResultatID TestID RT10 ST5 Dato utført Testutfører Tidsbruk Feil (Avvik fra forventet respons) Kommentarer Godkjenning Espen Fem minutter Ingen feil eller avvik. Et markert begrep blir blått. Godkjent Tabell 29: Testresultatet for ST5 37

353 Testdokument Systemtest ST6 I tabell 30 vises beskrivelse av test ST6. Testresultatene fra ST6 vises i tabell 31. TestID ST6 Dato skrevet Testansvarlig Estimert tid Testtype Krav Espen Ti minutter Systemtest FK-BG3, FK-BG4 og FK-BG5 Beskrivelse I denne testen er det relasjonene i begrepshierakiet (subclassof ) og relasjonene mellom andre begrep (Object- Property) som er aktuelle. Testen skal undersøke om: 1. De forskjellige kantene er representert forskjellig. 2. Lange begrepsnavn blir skjult av størrelsen på noden. 3. Lange begrepsnavn som er skjult vises når musepekeren flyttes over noden. 4. Nodene er like store. Prebetingelser Teststeg En OWL-fil foreligger, og den må ha med minst ett lengre navn enn hva en node har plass til og den må ha både subclassof og ObjectProperty-relasjoner. 1. Åpne OWL-filen. 2. Se om det finnes to forskjellige kanter. 3. Flytt musepekeren over noden med for langt navn. 4. Sjekke at alle noder har samme størrelse. Forventet respons 1. Grafen vises i hovedvinduet. 2. To kanter med forskjellig farge finnes. 3. Hele navnet vises. 4. At alle noder er av samme størrelse. 38

354 Testdokument Godkjenningskriterier Forskjellige relasjoner er representert som kanter med forskjellig farge. Lange begrepsnavn skjules av størrelsen på noden. Hele navnet vises når musepekeren flyttes over noden. Nodene har samme størrelse. Tabell 30: Testbeskrivelse for krav FK-BG3, FK-BG4 og FK-BG5 ResultatID TestID RT11 ST6 Dato utført Testutfører Tidsbruk Feil (Avvik fra forventet respons) Kommentarer Godkjenning Espen Fem minutter Ingen feil eller avvik. Kanter i begrepshiearkiet, subclassof, er svarte. Relasjonskanter, ObjectProperty, er blå. Godkjent Tabell 31: Testresultatet for ST6 39

355 Testdokument Systemtest ST7 I tabell 32 vises beskrivelse av test ST7. Testresultatene fra ST7 vises i tabell 33. TestID ST7 Dato skrevet Testansvarlig Estimert tid Testtype Krav Beskrivelse Prebetingelser Teststeg Espen 20 minutter Systemtest FK-FI1 Testen skal undersøke om biblioteket har filtrene som er spesifisert i kravet, og at filtrene fungerer slik de skal. En graf foreligger 1. Velg å slå av begrepsrelasjonene; subclassof - relasjonene. 2. Velg å slå på begrepsrelasjonene; subclassof - relasjonene. 3. Velg å slå av de andre relasjonene mellom begreper; ObjectProperty-relasjonene. 4. Velg å slå på de andre relasjonene mellom begreper; ObjectProperty-relasjonene. 5. Velge dybde 1 i begrepshierakiet. 6. Velge dybde 2 i begrepshierakiet. 7. Velge dybde 3 i begrepshierakiet. 40

356 Testdokument Forventet respons 1. Kantene som viser relasjonene i begrepshierakiene forsvinner. 2. Kantene som skal vise relasjonene i begrepshierakiene vises. 3. Kantene som viser de andre relasjonene mellom begreper forsvinner. 4. Kantene som skal vise de andre relasjonene mellom begreper vises. 5. Kun nivå 1 og over vises, 2 og under skjules. Nivå 0 er toppnivået. 6. Kun nivå 2 og over vises, 3 og under skjules. 7. Kun nivå 3 og over vises, 4 og under skjules. Godkjenningskriterier Alle kantene som skal filtreres bort vises ikke når man har filtrert. Alle kantene som er filtrert bort skal kunne vises igjen hvis man velger vekk filteret. Alle begrep under et valgt nivå skal filtreres bort når en velger nivå. Alle begrep under et valgt nivå skal vises igjen når hierarkifilteret tas vekk. Tabell 32: Testbeskrivelse for krav FK-FI1 41

357 Testdokument ResultatID TestID RT12 ST7 Dato utført Testutfører Tidsbruk Feil (Avvik fra forventet respons) Kommentarer Godkjenning Espen Fem minutter Ingen feil eller avvik. Når man skrudde på et filter ble grafen filtrert og når en skrudde av dette filteret ble grafen lagt ut på nytt. Godkjent Tabell 33: Testresultatet for ST7 42

358 Testdokument Systemtester for ikke-funksjonelle krav I dette avsnittet vil man finne tester som vil undersøke de ikke-funksjonelle kravene fra første inkrement. Systemtest ST8 I tabell 34 vises beskrivelse av test ST8. Testresultatene fra ST8 vises i tabell 35. Feil som ble funnet under gjennomføring av testen er beskrevet i tabell 36, 37 og 38. TestID ST8 Dato skrevet Testansvarlig Estimert tid Testtype Krav Beskrivelse Prebetingelser Teststeg Steinar 30 minutter Systemtest IFK-GK1 Det skal sjekkes at kildekoden er skrevet i Java og følger standarden for kildekode for prosjektet[1]. Kildekoden er tilgjengelig og fullstendig. 1. Sjekke at klassene er lagret som Java-filer (.java). 2. Sjekke at kildekode er skrevet i Java-syntaks og mot prosjektets standard for kildekode. Forventet respons 1. Alle klasser er lagret som Java-filer. 2. Kildekode og syntaks følger standarden. Godkjenningskriterier Kildekoden skal være skrevet i Java. Tabell 34: Testbeskrivelse for krav IFK-GK1 43

359 Testdokument ResultatID TestID RT13 ST8 Dato utført Testutfører Tidsbruk Feil (Avvik fra forventet respons) Kommentarer Godkjenning FeilID ResultatID Alvorlighetsgrad Beskrivelse Rapportert av Ansvarlig for retting Steinar 30 minutter Det ble funnet tre avvik fra forventet respons. Disse er beskrevet i FT4, FT5 og FT6 som er vist i tabell 36, 37 og 38. Denne testen kan godkjennes når disse er rettet opp. Ingen FT4, FT5 og FT6. Tabell 35: Testresultatet for ST8 FT4 RT13 Lav Alle lengre skop, som klasser og metoder, skal ha kommentar på avsluttende parentes som forteller hvilket skop som avsluttes. Dette var ikke gjennomført i kildekoden. Steinar Geir Dato rettet Tidsbruk Godkjenning 30 minutter Godkjent Tabell 36: Feilrapport for RT13 FeilID ResultatID Alvorlighetsgrad Beskrivelse Rapportert av Ansvarlig for retting FT5 RT13 Lav Importeringer skal ordnes alfabetisk på begynnelsen av filen. Dette var ikke gjennomført i kildekoden. Steinar Geir Dato rettet Tidsbruk Godkjenning 20 minutter Godkjent Tabell 37: Feilrapport for RT13 44

360 Testdokument FeilID ResultatID Alvorlighetsgrad Beskrivelse Rapportert av Ansvarlig for retting FT6 RT13 Lav OWLRenderer inneholder personlig informasjon. Steinar Geir Dato rettet Tidsbruk Godkjenning Ett minutt Godkjent Tabell 38: Feilrapport for RT13 45

361 Testdokument Systemtest ST9 I tabell 39 vises beskrivelse av test ST9. Testresultatene fra ST9 vises i tabell 40, med en feilrapport for feil funnet under gjennomføring at test vist i tabell 41. TestID ST9 Dato skrevet Testansvarlig Estimert tid Testtype Krav Håvard 15 minutter Systemtest IFK-GK2 Beskrivelse Testen skal undersøke om biblioteket kan brukes på maskiner som bruker Windows-, Linux- og Macoperativsystemer. Prebetingelser Teststeg Har tilgang til maskiner med alle operativsystemene Kjør biblioteket gjennom testbrukergrensesnittet på maskiner med disse OS: Windows Linux MacOS Forventet respons Godkjenningskriterier På de tre operativsystemene oppfører biblioteket seg likt. Biblioteket skal kunne brukes på følgende operativsystemer: Windows Linux MacOS Tabell 39: Testbeskrivelse for krav IFK-GK2 46

362 Testdokument ResultatID TestID RT14 ST9 Dato utført Testutfører Tidsbruk Feil (Avvik fra forventet respons) Kommentarer Godkjenning Geir og Håvard 15 minutter Det ble funnet én feil. Se tabell 41. Fungerte likt på alle operativsystemene, bortsett fra feil i FT7. FT7 Tabell 40: Testresultatet for ST9 FeilID ResultatID Alvorlighetsgrad FT7 RT14 Beskrivelse Biblioteket hadde problemer når man avsluttet det i Linux. Rapportert av Ansvarlig for retting Dato rettet Tidsbruk Godkjenning Lav Geir og Håvard Ingen Ikke planlagt Ikke estimert Venter godkjenning Tabell 41: Feilrapport for RT14 47

363 Testdokument Systemtest ST10 I tabell 42 vises beskrivelse av test ST10. Testresultatene fra ST10 vises i tabell 43. TestID ST10 Dato skrevet Testansvarlig Estimert tid Testtype Krav Beskrivelse Steinar 30 minutter Systemtest IFK-GK3 Testen skal avgjøre om biblioteket kan lese og vise ontologier som er større enn hva krav IFK-KY2 tilsier, uten å feile. Prebetingelser Må ha tilgang på minst en OWL-fil som har flere enn 1000 begreper og 5000 relasjoner. Teststeg 1. Åpne en OWL-fil større enn 1000 begreper og 5000 relasjoner. Forventet respons 1. En OWL-fil større enn 1000 begreper og 5000 relasjoner ble vist frem uten å feile. Godkjenningskriterier Komponenten leser og viser ontologier større enn 1000 begreper og 5000 relasjoner uten å feile. Tabell 42: Testbeskrivelse for krav IFK-GK3 48

364 Testdokument ResultatID TestID RT15 ST10 Dato utført Testutfører Tidsbruk Feil (Avvik fra forventet respons) Kommentarer Godkjenning Steinar 30 minutter Ingen feil eller avvik. Lastet inn ontologien (galen.owl 5 ). Denne ontologien inneholder over 4000 begreper noe som er fire ganger flere enn det kravet krever. Godkjent Tabell 43: Testresultatet for ST horrocks/owl/ontologies/galen.owl 49

365 Testdokument Systemtest ST11 I tabell 44 vises beskrivelse av test ST11. Testresultatene fra ST11 vises i tabell 45. TestID ST11 Dato skrevet Testansvarlig Estimert tid Testtype Krav Beskrivelse Prebetingelser Teststeg Steinar Ti minutter Systemtest IFK-GK4 Testen skal finne ut om det er enkelt å skifte språket til brukergrensesnittet uten å forandre kildekoden. Testbrukergrensesnittet må være ferdig. 1. Endre språk i menyen. Forventet respons 1. Det skiftes til det språket som ble valgt. Godkjenningskriterier Det er mulig å skifte språket på brukergrensesnittet, uten å forandre kildekoden. Tabell 44: Testbeskrivelse for krav IFK-GK4 ResultatID TestID RT16 ST11 Dato utført Testutfører Tidsbruk Feil (Avvik fra forventet respons) Kommentarer Godkjenning Steinar Fem minutter Ingen feil eller avvik. Ingen Godkjent Tabell 45: Testresultatet for ST11 50

366 Testdokument Systemtest ST12 I tabell 46 vises beskrivelse av test ST12. Testresultatene fra ST12 vises i tabell 47. TestID ST12 Dato skrevet Testansvarlig Estimert tid Testtype Krav Beskrivelse Steinar Fem minutter Systemtest IFK-BG2 Testen skal undersøke om brukergrensesnittet er på engelsk. Prebetingelser Teststeg Brukergrensesnittet er ferdig. Brukeren har ikke endret språk tidligere for biblioteket. 1. Sjekk menylinjen. 2. Klikk på menyelementet for filbehandling i hovedmenylinjen. 3. Klikk på menyelementet som gir valg for åpning av OWL-fil. 4. Klikk på menyelementet for åpning fra fil. 5. Klikk på menyelementet for åpning fra URL. 6. Klikk på menyelementet for filtrering i hovedmenylinjen. 7. Klikk på menyelementet for valgmuligheter i hovedmenylinjen. 8. Sjekk etter forventet respons i informasjonsvinduet. 51

367 Testdokument Forventet respons 1. Elementene har engelske navn. 2. Elementene har engelske navn. 3. Elementene har engelske navn. 4. Inndataboksen som vises frem er på engelsk. 5. Inndataboksen som vises frem er på engelsk. 6. Elementene har engelske navn. 7. Elementene har engelske navn. 8. Beskrivelse av informasjon er på engelsk. Godkjenningskriterier Brukergrensesnittet er på engelsk. Tabell 46: Testbeskrivelse for krav IFK-BG2 ResultatID TestID RT17 ST12 Dato utført Testutfører Tidsbruk Feil (Avvik fra forventet respons) Kommentarer Godkjenning Steinar 30 minutter Ingen feil eller avvik. Ingen Godkjent Tabell 47: Testresultatet for ST12 52

368 Testdokument Systemtest ST13 I tabell 48 vises beskrivelse av test ST13. Testresultatene fra ST13 vises i tabell 49. TestID ST13 Dato skrevet Testansvarlig Estimert tid Testtype Krav Beskrivelse Prebetingelser Teststeg Steinar Fem minutter Systemtest IFK-BG3 Testen skal undersøke om standard vinduselementer er brukt, og om det er enkelt å gjenkjenne og forstå funksjonaliteten. Testbrukergrensesnittet er ferdig. 1. Sjekke om alle GUI-klasser arver fra Swing. 2. Sjekk meny. 3. Venstre museklikk markerer. Dette kan være noder. Forventet respons 1. Alle GUI-klasser arver fra Swing. 2. Menyen inneholder standard elementer som fil, åpne og lukk. 3. For eksempel noder blir markert. Godkjenningskriterier Hvis forventet respons er som ventet. Tabell 48: Testbeskrivelse for krav IFK-BG3 53

369 Testdokument ResultatID TestID RT18 ST13 Dato utført Testutfører Tidsbruk Feil (Avvik fra forventet respons) Kommentarer Godkjenning Steinar Fem minutter Ingen feil eller avvik. Ingen Godkjent Tabell 49: Testresultatet for ST13 54

370 Testdokument Systemtest ST14 I tabell 50 vises beskrivelse av test ST14. Testresultatene fra ST14 vises i tabell 51. TestID ST14 Dato skrevet Testansvarlig Estimert tid Testtype Krav Beskrivelse Prebetingelser Teststeg Steinar 30 minutter Systemtest IFK-BG5 Testen skal sjekke om biblioteket er i stand til å håndtere spesialtegn som æ, ø og å. En ontologi på OWL-format foreligger, som inneholder bokstavene æ, ø og å. 1. Last inn OWL-filen. 2. Sjekk om grafen bruker riktig symbol for æ, ø og å. Forventet respons 1. Ontologien visualiseres. 2. Grafen bruker riktig symbol for æ, ø og å. Godkjenningskriterier Spesialtegnene representeres riktig i grafen. Tabell 50: Testbeskrivelse for krav IFK-BG5 55

371 Testdokument ResultatID TestID RT19 ST14 Dato utført Testutfører Tidsbruk Feil (Avvik fra forventet respons) Kommentarer Godkjenning Steinar 30 minutter Ingen feil eller avvik. Siden det var vanskelig å finne en ferdig laget OWL-fil med norske spesialtegn, ble det skrevet en OWL-fil som inneholdt de norske spesialtegnene æ, ø og å. Hvis det ikke var spesifisert hvilket karaktersett XML-filen hadde, så ville ikke biblioteket lese inn OWL-filen. Når karaktersettet var spesifisert lastet biblioteket inn en OWL-fil med norske spesialtegn og brukte disse riktig i grafen. Godkjent Tabell 51: Testresultatet for ST14 56

372 Testdokument Systemtest ST15 I tabell 52 vises beskrivelse av test ST15. Denne testen måtte gjennomføres to ganger. Testresultatene fra lokal disk vises i resultattabell 53. Testresultatene fra URL vises i resultattabell 54. TestID ST15 Dato skrevet Testansvarlig Estimert tid Testtype Krav Beskrivelse Steinar 30 minutter Systemtest IFK-KY1, IFK-KY2 og IFK-KY3 Testen skal sjekke om: Innlastingen av OWL-filer tar under ett minutt. Prebetingelser Teststeg Andre operasjoner bruker under 30 sekunder å gjennomføre. Testen skal gjennomføres på en bærbar PC med 1.4 GHz prosessor og 512 MB RAM, jamfør krav IFK-KY3. Ontologi som benyttes i testen må være større enn 1000 begrep og 5000 relasjoner, jamfør krav IFK-KY2. Man tester også derfor disse to kravene i denne testen. Alle funksjoner fungerer. En OWL-fil med gitt størrelse på disk/url. Tilgang til pc som følger kravet. 1. Åpne en OWL-fil fra disk/url. 2. Velg et begrep. 3. Slå av hierarkiske relasjoner. 4. Slå på hierarkiske relasjoner. 5. Slå av andre relasjoner mellom begrep. 6. Slå på andre relasjoner mellom begrep. 7. Velg dybde til begrepshieraki. Gjentas fem ganger, med forskjellige dybder. 57

373 Testdokument Forventet respons 1. Filen lastes inn, tolkes, grafrepresenteres og grafen tegnes i hovedvinduet på under ett minutt. 2. Begrepet markeres ved å skifte farge på under 30 sekunder. 3. De hierarkiske relasjonene forsvinner på under 30 sekunder. 4. De hierarkiske relasjonene vises på under 30 sekunder. 5. Andre relasjoner enn de hierakiske forsvinner på under 30 sekunder. 6. Andre relasjoner enn de hierarkiske vises på under 30 sekunder. 7. Dybden i begrepshierakiet endres på under 30 sekunder. Godkjenningskriterier For både lokal disk og URL: Innlastingen tar under ett minutt. Andre operasjoner utføres på under 30 sekunder. Tabell 52: Testbeskrivelse for krav IFK-KY1, IFK-KY2 og IFK-KY

374 Testdokument ResultatID TestID RT20 ST15 Dato utført Testutfører Tidsbruk Feil (Avvik fra forventet respons) Kommentarer Steinar 30 minutter Ingen feil eller avvik. Den OWL-filen som ble brukt i denne testen er satt sammen av to OWL-filer for at den skal være over kravet på 1000 begrep og 5000 relasjoner. Den ene som ble brukt heter gams.owl 6 Den inneholder 782 begrep og 3128 relasjoner. Den andre som ble brukt heter openmath.owl 7 Denne inneholder 816 begrep og 2355 relasjoner. Tilsammen oppfyller disse to kravet om størrelse på OWL-fil. 1. Åpnet en OWL-filen fra disk. Responstiden var 15 sekunder. 2. Valgte et begrep. Responstiden ble under ett sekund. 3. Slo av hierarkiske relasjoner. Responstiden ble under ett sekund. 4. Slo på hierarkiske relasjoner. Responstiden ble cirka tre sekund. 5. Slo av andre relasjoner mellom begrep. Responstiden ble under ett sekund. 6. Slo på andre relasjoner mellom begrep. Responstiden ble cirka tre sekund. 7. Valgte forskjellige dybder i begrepshierarkiet fra en til fem. Filtrerte vekk nivåer på under ett sekund. Når man slo av filter tok det under fire sekund å få tilbake originalgrafen. Godkjenning Godkjent Tabell 53: Testresultatet for ST15 59

375 Testdokument ResultatID TestID RT21 ST15 Dato utført Testutfører Tidsbruk Feil (Avvik fra forventet respons) Kommentarer Steinar To timer Ingen feil eller avvik. Det ble brukt samme OWL-fil som i resultattabell RT19 fra tabell Åpnet en OWL-filen fra URL. Responstiden ble 30 sekund. 2. Valgte et begrep. Responstiden ble under ett sekund. 3. Slo av hierarkiske relasjoner. Responstiden ble under ett sekund. 4. Slo på hierarkiske relasjoner. Responstiden ble cirka tre sekund. 5. Slo av andre relasjoner mellom begrep. Responstiden ble under ett sekund. 6. Slo på andre relasjoner mellom begrep. Responstiden ble circa tre sekund. 7. Valgte forskjellige dybder i begrepshierarkiet fra en til fem. Filtrerte vekk nivåer på under ett sekund. Når man slo av filter tok det under fire sekund å få tilbake originalgrafen. Godkjenning Godkjent Tabell 54: Testresultatet for ST15 60

376 Testdokument Systemtest ST16 I tabell 55 vises beskrivelse av test ST16. Testresultatene fra ST16 vises i tabell 56. Tabell 57 viser feil som dukket opp under gjennomføring av testen. TestID ST16 Dato skrevet Testansvarlig Estimert tid Testtype Krav Beskrivelse Prebetingelser Teststeg Steinar 30 minutter Systemtest IFK-DOK4 Testen skal undersøke om kildekoden er dokumentert i henhold til JavaDoc-standarden [2]. Kildekoden foreligger. 1. Les gjennom alle Java-filer i prosjektet. Forventet respons 1. Java-filene følger standarden. Godkjenningskriterier Kildekoden er dokumentert, og følger JavaDoc-standarden. Tabell 55: Testbeskrivelse for krav IFK-DOK

377 Testdokument ResultatID TestID RT22 ST16 Dato utført Testutfører Tidsbruk Feil (Avvik fra forventet respons) Kommentarer Godkjenning Steinar 30 minutter Filer som ikke fulgte JavaDoc-standarden er vist i FT8 i tabell 57. Når FT8 får godkjent status vil denne testen også få godkjent status. Ingen FT8 Tabell 56: Testresultatet for ST16 FeilID ResultatID Alvorlighetsgrad Beskrivelse Rapportert av Ansvarlig for retting FT8 RT22 Lav Filen Error.java mangler JavaDoc. Filen Event.java mangler JavaDoc. Steinar Geir Dato rettet Tidsbruk Godkjenning Fem minutter Godkjent Tabell 57: Feilrapport for RT22 62

378 Testdokument 3.3 Akseptansetest En akseptansetest er en test hvor kunden går over biblioteket og sjekker det som er laget. Akseptansetest for første inkrement kan man finne i tabell 58. For å utføre akseptansetesten må flere ting være i orden. Det må foreligge: En bærbar PC som tilsvarer krav til PC. Kildekoden til biblioteket. En OWL Full-fil. En OWL DL-fil. En OWL Lite-fil. En OWL-fil på størrelse 1000 begrep og 5000 relasjoner. En OWL-fil større enn 1000 begrep og 5000 relasjoner. En OWL-fil med syntaksfeil. En OWL-fil med både subclassof og ObjectProperty-relasjoner. En OWL-fil på URL. En OWL-fil med norske spesialtegn. For flere av disse brukte gruppen OWL-filen beer.owl 8. For de andre ble egne OWL-filer spesiallaget for at man kunne teste kravene. Karl og Geir gjennomførte akseptansetesten med kunde. KravID Beskrivelse Godkjent Kommentar FK- HA1 FK- HA2 Komponenten skal kunne håndtere alle OWLtyper;Lite, DL og Full. Brukeren skal kunne åpne en OWL-fil fra lokal disk som skal tolkes av komponenten. Ja Ja OK OK

379 Testdokument FK- HA3 FK- HA4 FK- HA5 FK- HA6 FK- HA7 FK-FI1 Brukeren skal kunne åpne en OWL-fil fra en URL-adresse som skal tolkes av komponenten. Komponenten skal kunne tolke en OWL-fil, plukke ut relevante data i henhold til krav om OWL Lite, og konvertere disse til en grafrepresentasjon. Hvis det er syntaksfeil i OWL-filen som tolkes skal brukeren få beskjed om dette, og hvor i filen feilen ligger. Brukeren skal få beskjed om hvilke egenskaper som ignoreres når OWLfilen konverteres til en grafrepresentasjon. Brukeren skal få beskjed om OWL-filen er av type OWL Lite, OWL DL, eller OWL Full. Komponenten skal ha en liste over predefinerte filtre som brukeren kan velge fra når man ønsker å filtrere grafen. Brukeren skal kunne velge mellom følgende tre filter: Slå av og på hierarktiske relasjoner; relasjoner av typen subclassof. Slå av og på andre relasjoner mellom begrepene; relasjoner av typen ObjectProperty. Valg av dybde som skal vises i begrepshierarkiet. Ja Ja Ja OK OK OK Dette var et lavt vektet krav, og blir sett bort fra som avtalt Dette var et lavt vektet krav, og blir sett bort fra som avtalt Ja Om man har aktivert et filter, og åpner en ny graf, vises hele grafen. Det er som det skal være, men menyen blir ikke nullstilt, slik at det ser ut som om et filter er aktivt. 64

380 Testdokument FK- BH2 Brukeren skal kunne velge et begrep. Dette begrepet skal markeres slik at det tydelig kan skilles fra de andre begrepene. Etter at et begrep er valgt vil det benevnes i denne kravspesifikasjonen som et markert begrep. Ja OK FK- BH8 Brukeren skal kunne få opp informasjon som gjelder et markert begrep. Denne informasjonen vil være hvilke attributter og relasjoner begrepet har, hvilket overbegrep begrepet tilhører og antall individer begrepet har. Ja OK FK- BG1 Komponenten skal kunne vise ontologier som grafer. Ja OK FK- BG3 Det skal skilles mellom forskjellige kanter i grafen, eksempelvis kanter for begrepshierarki, individer og relasjoner. Kantene kan skilles for eksempel ved hjelp av ulike farger. Ja OK FK- BG4 Navnet på en node skal skjules hvis det tar større plass enn figuren som representerer noden. Hele navnet vises da hvis man holder musepekeren over noden. Ja OK FK- BG5 Alle noder skal være like store. Ja OK IFK- GK1 Koden til komponenten skal skrives i Java. Ja OK 65

381 Testdokument IFK- GK2 IFK- GK3 IFK- GK4 IFK- BG2 IFK- BG3 IFK- BG5 Kunden skal kunne vise programmet videre til sine kunder, og disse kan bruke forskjellige operativsystemer. Dette gjør at man må ha mulighet til å kjøre programmet i flere operativsystemer; Windows, Unix/Linux og MacOS. Komponenten skal være robust. Med dette menes at komponenten skal kunne lese og vise ontologier større enn spesifisert i IFK-KY2 uten å feile. Det kan da aksepteres at det brukes lengre tid enn spesifisert i IFK-KY3. Språket i brukergrensesnittet skal være enkelt å skifte uten å måtte forandre kildekoden. Standard applikasjonsspråk skal være engelsk. Brukergrensesnittet skal ved å bruke standard widgets (widgets er funksjoner/virkemåter som går igjen i de fleste applikasjoner. Programmet skal kunne håndtere og vise tegn som æ,ø og å. Ja Når en avslutter programmet i Linux henger det, i steden for å lukke normalt. Ja Testet ontologien galen (ca begrep) Ja Ja Ja Ja OK OK OK OK 66

382 Testdokument IFK- KY1 IFK- KY2 Komponenten skal kunne visualisere en ontologi på 1000 begrep og 5000 relasjoner. IFK- KY3 IFK- DOC4 Den lengste tiden brukeren skal måtte vente på komponenten er ett minutt for innlasting av OWL-filer. Andre operasjoner skal ikke ta lengre enn 30 sekunder, så lenge komponenten kjøres på en PC jamfør IFK- KY3 og ontologien er like stor som eller mindre enn spesifisert i IFK-KY2. Komponenten skal kunne kjøres på en bærbar PC med 1.4Ghz prosessor og 512MB RAM, og følge responstidene nevnt i IFK-KY1. Kildekoden til komponenten skal dokumenteres i henhold til JavaDocstandarden. Første inkrement godkjent? Ja. Tabell 58: Krav som skal sjekkes i akseptansetesten Ja Ja Ja Ja OK OK OK OK Gruppen inviterte kunden til akseptansetest 12. november 2004 klokken Kunden fikk utdelt en bærbar PC som tilfredstiller krav IFK-KY1. Se tabell 58 [3]. Testen startet klokken og varte til Kunden gikk gjennom tabell 58 punkt for punkt og noterte stikkord der det var noe å påpeke. Andre kommentarer fra kunden, som ikke kommer fram i tabellen, etter gjennomføring av akseptansetest var: Siden biblioteket bruker kun 15 sekund på å lese inn og legge ut en ontologi på 1000 begrep og 5000 relasjoner, kan det kanskje gis mer tid på grafutlegg, slik at store grafer blir lagt ut penere. Slik det er nå blir grafen spredt ut i klynger med mye tomrom mellom klyngene. Kunden ønsket mindre mellomrom mellom klyngene. 67

383 Testdokument Kantene krysser andre kanter veldig ofte. Dette er vanskelig å forhindre i store ontologier, men kan bli begrenset. Noder blir ofte lagt over hverandre. Utleggsalgoritmen fra JUNG ser nodene som punkter og legger av og til disse veldig tett sammen, slik at nodene overlapper hverandre. Når en graf filtreres blir tomrommet mellom nodene enda tydeligere. Enten burde biblioteket lagt grafen ut helt på nytt, eller så kunne det vært en funksjon som hadde gjort dette mulig i brukergrensesnittet. På grunn av Jena blir det ikke meldt hvor i filen syntaksfeilen ligger. Etter å ha utført akseptansetesten konkluderte kunden med at biblioteket var godkjent for første inkrement. Kunden var veldig fornøyd med oversiktelig og fin kildekode i biblioteket. 68

384 Testdokument 4 Konklusjon I konklusjonen ønsker gruppen å oppsummere resultatene fra de forskjellige testene. Bare én enhetstest påviste feil. Feilen ble vektet lav. Se tabell 11 for beskrivelse av feilen. De andre enhetstestene verifiserte enhetene som fungerende. Modultestene ble ikke formelt utført siden programmererene testet fortløpende under implementasjonen. Det ble kjørt systemtester på alle krav som er med i første inkrement. Testutførelsen viste hvilke krav som inneholder feil. ST1, ST5, ST8, ST9 og ST16 feilet på et eller flere punkter. Se tabell 18, 24, 34, 39 og 55. Beskrivelse og forklaring finner man i feilrapportene i tabellene 20, 26, 36, 37, 38, 41 og 57. Disse feilene er alle vektet lavt og er ikke kritiske for hovedfunksjonaliteten til biblioteket, som er å visualisere ontologier. Noen av disse feilene er ikke planlagt rettet opp, da man ikke har mer tid før prosjektet avsluttes. Integrasjonstest ble ikke utført siden eksterne komponenter fra DiB, som biblioteket skal integreres med, ennå ikke er laget. Brukbarhetstest ble ikke brukt siden biblioteket ikke har noe ferdig brukergrensesnitt som behøver brukbarhetstesting. Etter å ha utført akseptansetesten konkluderte kunden med at biblioteket var godkjent for første inkrement. Kunden var veldig fornøyd med oversiktelig og fin kildekode i biblioteket. De feil som ble påvist i systemtestene er ikke av avgjørende karakter for hovedfunksjonaliteten til biblioteket. Feilene har lav viktighetsvurdering og på grunn av tidsmangel er retting ikke planlagt før prosjektslutt. 69

385 Testdokument Referanser [1] Kundestyrt prosjekt, gruppe 14: Ontologidrevet dokumentforvaltning, implementasjon, [2] Sun microsystem, inc: How to write doc comments for the javadoc(tm) tool, [3] Kundestyrt prosjekt, gruppe 14: Ontologidrevet dokumentforvaltning, kravspesifikasjon, [4] Reidar Conradi og Jon Atle Gulla. Kompendium i fag tdt kundestyrt prosjekt [5] Hans van Vliet. Software engineering principles and practice

386 Ontologidrevet dokumentforvaltning Evaluering TDT4290 Kundestyrt prosjekt Institutt fra datateknikk og informasjonsvitenskap Fakultet for informasjonsteknologi, matematikk og elektroteknikk Norges teknisk-naturvitenskapelige universitet Gruppe 14 Espen Hansen Ole-Marius Moe-Helgesen Geir Storli Karl Hatteland Steinar Skjerven Håvard Stranden

387

388 Evaluering Innhold 1 Innledning Oversikt Gruppen Rollene Kommunikasjonen Samarbeidet Løsning av oppgaver Tidsbruk Planlegging Forstudie Kravspesifikasjon Konstruksjon Implementasjon Testing Avslutning Motivasjonen Konflikter Kunden Samarbeidet og kommunikasjonen Tilgjengelighet Kunden som ressurs Problemer Faget 19 2

389 Evaluering 4.1 Forventninger Overraskelser Seminarer Forelesninger Struktur og gjennomføring Informasjon Oppgaven Veiledere Risikomomenter som har slått til 23 6 Utnyttelse av ressursene 24 7 Deler gruppen er fornøyde med 25 8 Videre arbeid Gjenværende arbeid Estimert tid Referanser 28 3

390 Evaluering Tabeller 1 Planlagt slutt og faktisk slutt av fasene i prosjektet

391 Evaluering Figurer 1 Fagets estimerte belastning i timer og antall timer brukt hver uke Estimert og faktisk timebruk i gruppen

392 Evaluering 1 Innledning Underveis i et prosjekt er det ofte slik at gruppen blir oppslukt i oppgavene som skal gjennomføres der og da. I dette faget er det mye arbeid som skal gjennomføres og kort tid å gjøre det på. Evalueringfasen gir gruppen en mulighet til å få overblikk over hele prosjektet. Refleksjoner over forholdene som har hatt innvirkning på gruppemedlemmene og gjennomføringen av arbeidet, kan være svært verdifulle i senere prosjekter. Målet med evalueringen er med andre ord å avdekke positive og negative sider i prosjektet slik at man kan lære av dem og ta erfaringene med seg videre. Evalueringen er også verdifull fordi den redegjør for forhold som har hatt innvirkning på arbeidet som ikke kommer fram i de øvrige dokumentene i et prosjekt. Det er et viktig poeng i et evalueringsdokument at alle gruppemedlemmene er enig i hva som står der. Gruppen brukte derfor endel tid i begynnelsen av denne fasen til å diskutere hva som skulle være med i dokumentet. I tillegg er det viktig å få samlet alle erfaringene og tankene som gruppemedlemmene har om alle sidene ved prosjektet. 1.1 Oversikt Dokumentet har blitt delt inn i de delene som gruppen mente var mest hensiktsmessig. Kapittel 2 vil ta for seg gruppen og samarbeidet. I tillegg vil det bli fokusert litt på tidsbruken til gruppen. I kapittel 3 er det gruppens forhold til kunden som er hovedfokuset. Gruppens forhold og tanker til faget blir tatt opp i kapittel 4. Noen av risikoene som ble spesifisert i prosjektdirektivet [1], slo til, og disse vil bli tatt opp i kapittel 5, samt hvordan de ble håndtert. De ressursene som gruppen mener kunne vært utnyttet bedre blir tatt opp i kapittel 6. Kapittel 7 vil se på de resultatene vi er spesielt fornøyde med i prosjektet. Til slutt i kapittel 8 vil det bli redegjort for arbeidet som gjenstår, samt en estimeringen av tidsbehovet. 6

393 Evaluering 2 Gruppen Dette kapittelet vil dreie seg om gruppen og noen få gruppeprosessaspekter som motivasjon og konflikter. Hovedfokuset vil være på rollene, kommunikasjonen og samarbeidet i gruppen. I tillegg vil det bli sett endel på tidsbruken til gruppen. En kort faseevaluering med hensyn på tid vil bli gitt i den sammenhengen. 2.1 Rollene Gruppen skjønte tidlig at det var nødvendig å fordele roller innad i gruppen slik at spesielt den administrative delen av arbeidet skulle foregå med minst mulige problemer og usikkerheter. Rollene og innehaverne av dem er beskrevet i prosjektdirektivet [1]. Det ble foreslått å vente med dette til etter Teambuilding -seminaret med Luftkrigsskolen for å gi gruppen en mulighet til å bli bedre kjent, og dermed kunne avgjøre hvem som passet best til de ulike rollene. Til da hadde vi bare hatt en kort presentasjonsrunde av medlemmene der hver enkelt sa litt om seg selv, hva de mente de kunne bidra med i prosjektet og sine sterke og svake sider. Men siden dette seminaret fant sted såpass sent og gruppen dermed hadde hatt tre uker med usikkerhet spesielt tilknyttet møteinnkallinger og møteplaner ønsket vi ikke å vente så lenge. Alle rolleinnehaverne har utført sine roller meget tilfredstillende, og gruppen er veldig fornøyd med både dem og hvilke valg som ble gjort i denne sammenheng. Lederen i gruppen har i noen tilfeller ikke hatt mulighet til å delta i arbeidet på grunn av reise og annet faglig opplegg. Gruppen innser at det hadde vært nyttig i disse tilfellene å ha hatt en nestleder som kunne overtatt lederens arbeidsoppgaver. Dette har imidlertid ikke vært et problem da gruppen har hatt ansvarsfulle personer som har påtatt seg disse oppgavene når det har vært nødvendig. 2.2 Kommunikasjonen Gruppen har brukt følgende kommunikasjonsmedier: e-post 7

394 Evaluering IRC 1 MSN messenger 2 Telefon SMS 3 I tillegg har kommunikasjonen foregått gjennom møter og gruppearbeid. Pratesystemene som gruppen har brukt har vært meget praktiske når gruppemedlemmene har jobbet på forskjellige lokasjoner. Det er i hovedsak systemet IRC gruppen har benyttet seg av. Via disse systemene har gruppemedlemmene raskt fått svar på spørsmål og hatt mulighet til å avtale saker og ting hurtig. Det var sjelden at alle var logget på IRC samtidig. Erfaringsnivået med IRC var veldig varierende før prosjektet, og underveis var det ikke alle som logget seg på når de jobbet på en PC. Derfor hendte det at enkelte ikke alltid fikk med seg det som ble sagt og avgjort på IRC. Gruppen innser at den burde ha vært bedre til å sende e-post om viktige saker som ble avgjort på IRC, for eksempel innkallelse til møter, slik at alle fikk beskjed. I det store og det hele synes gruppen kommunikasjonen innad i gruppen har fungert bra. 2.3 Samarbeidet Gruppen satte av fredager fra til som arbeidsdager der hele gruppen jobbet samlet på datasal. Etterhvert som prosjektet nærmet seg slutten ble det flere fredager i uken. Gruppen har også jobbet endel i mindre grupper bestående av to til tre personer. Mandager fra til ble brukt til interne møter der det blant annet ble gjort opp for status og planlegging. Et problem har vært at gruppemedlemmene ikke har vært like flinke til å sette seg selv i arbeid når en har vært ferdig med én oppgave. Som regel har 1 Internet Relay Chat; et flerbruker pratesystem, der mennesker kommuniserer på kanaler 2 Microsoft Network; et pratesystem 3 Short Message Service; en tjeneste som gir deg mulighet til å sende tekstmeldinger med mobiltelefon 8

395 Evaluering en ventet til neste mandagsmøte for å få nye oppgaver, i stedet for å sjekke med noen andre om det er noe som skal gjøres Løsning av oppgaver Gruppen har hovedsaklig avgjort saker på en demokratisk måte. Vi har likevel hatt noen problemer i forbindelse med avgjørelser som har blitt tatt underveis. Det har ofte vært tilfelle at arbeidsoppgavene er blitt fordelt på medlemmene på møter. Deretter har medlemmene gått til sitt for å løse oppgaven sin, og dermed foretatt avgjørelser på egenhånd i forbindelse med gjennomføringen. Disse avgjørelsene har i noen tilfeller måttet bli omgjort eller modifisert, noe som igjen har kostet oss tid. Det er flere årsaker til dette problemet enn bare fordelingen og gjennomføringen av arbeidsoppgavene. Ett problem er at gruppemedlemmene ikke leste tilstrekkelig over det andre hadde gjort før på slutten av en fase, da avgjørelsene allerede var tatt. For å løse dette kunne gruppen ha jobbet mer sammen i begynnelsen av prosjektet. En annen løsning er at felles arbeidstid, mandagsmøter og fredager, kunne blitt utnyttet bedre. Det hendte at mandagsmøtene ikke varte mer enn én time, og da gikk folk til sitt. Denne tiden kunne blitt brukt til å ta avgjørelsene sammen. Det forutsetter at alle er kjent med og har satt seg inn i saken ved å lese det som ble produsert av dokumentasjon, slik at det ikke er bare én som sitter med spesialkunnskapen. Det siste punktet er noe som gruppen absolutt burde vært flinkere til. I de tilfellene der hele gruppen jobbet med en oppgave, for eksempel i konstruksjonen, var det ofte slik at det første forslaget var det som ble løsningen. Det er flere årsaker til dette. Én årsak er at gruppen har vært veldig progresjonsrettet og dermed ikke alltid tatt seg tid til å stoppe opp og vurdere flere løsninger på et problem. En annen årsak er at kunnskapsnivået i gruppen er forskjellig, og det er ikke alltid alle har noe å bidra med. Gruppen ser klart at den kunne hatt fordel av å stoppe opp ved flere anledninger og undersøkt flere løsninger på et problem. Dette kunne ha spart oss tiden det tok å rette opp tidligere avgjørelser. I implementasjonsfasen delte gruppen seg inn i to grupper; en implementasjonsgruppe som implementerte biblioteket og en dokumentasjonsgruppe. 9

396 Evaluering Sistenevnte gruppe ferdigstilte konstruksjonsdokumentet, begynte på implementasjonsdokumentet, skrev tester og jobbet med evalueringsdokumentet. Underveis var det noen kommunikasjonsproblemer mellom gruppene, spesielt i forbindelse med implementasjonsdokumentet. Implementasjonsgruppen var ikke alltid like flink til å oppdatere dokumentasjonsgruppen om endringer som ble gjort underveis, som førte til endel merarbeid. I tillegg var ikke dokumentgruppen like inneforstått med systemet og løsningene som implementasjonsgruppen. Resultatet av dette er at det har gått mye tid med på å rette opp feilene i implementasjonsdokumentet. Gruppen delte seg inn slik fordi det på det tidspunktet var mye som gjensto både av implementasjonen og dokumentproduksjonen, og liten tid å gjøre det på. Dette slo allikevel ikke like heldig ut for oss på grunn av kommunikasjonsproblemene. Hva som kunne vært gjort annerledes er vanskelig å si. Med tanke på tiden og arbeidet som var igjen var det den eneste løsningen vi så på det tidspunktet. Dokumentasjonsgruppen burde kanskje ha vært mer involvert i selve implementasjonen, enten ved å delvis delta i den, eller lese mer kildekode. En forbedring av kommunikasjonen hadde nok vært beste løsning. Implementasjonsgruppen kunne ha vært konsekvente og sagt fra straks en endring var gjort. Eller så kunne gruppene hatt hyppige møter der gruppene oppdaterte hverandre om hva som hadde blitt gjort. 2.4 Tidsbruk Gruppen har i hovedsak hatt faseavslutningene som milepæler i prosjektet. I tillegg kommer preleveransen av forstudiet og kravspesifikasjonen. Ellers er det korte interne frister gruppen har brukt ved behov, for å sørge for progresjon i arbeidet. Med tanke på faseavslutningene så har gruppen ligget etter tidsplanen helt fram til innleveringen av prosjektet. Tabell 1 viser en oversikt over de planlagte og faktiske faseavslutningene i prosjektet. Arbeidsinnsatsen og innstillingen har vært god i hele prosjektet, og ingen har meldt seg ut underveis. Årsaken til disse forsinkelsene mener gruppen for det meste ligger andre steder. Hovedårsaken har vært at den faglige belastningen utenom dette faget har vært stor. Alle gruppemedlemmene har blant annet hatt store tellende øvinger og midtsemestereksamen utenom. I disse periodene har dette gått mye 10

397 Evaluering Faser Planlagt avsluttet Faktisk avsluttet Planlegging Forstudie Kravspesifikasjon Konstruksjon Implementasjon Testing Avslutning Tabell 1: Planlagt slutt og faktisk slutt av fasene i prosjektet utover tiden som har blitt nedlagt i dette faget. Figur 1 sammenligner den estimerte belastningen, fra IDI sin side, med den faktiske timebruken. Figur 1: Fagets estimerte belastning i timer og antall timer brukt hver uke Av figuren ser man blant annet et lavt timebruk i faget i ukene 41 og 42. Uke 41 var tiltaksuke med mange tellende øvinger og midtsemestre. Disse øvingene og midtsemestrene foregikk også i uke 42. Merk at uke 47 i diagrammet hovedsaklig er en estimering av timene som ble brukt, da prosjektdokumentet ble levert til trykking tirsdag kl En annen årsak er at gruppen har liten erfaring med timeestimering. Faget og erfaringene med fasene i prosjektet var i større eller mindre grad nye for 11

398 Evaluering gruppemedlemmene. Det var derfor vanskelig å anslå korrekt hvor mange timer det ville bli behov for i de enkelte fasene. Figur 2 viser et søylediagram med vår estimering av timer, samt timene som faktisk ble brukt. Figur 2: Estimert og faktisk timebruk i gruppen Videre i dette avsnittet vil det bli gitt en kort faseevaluering med hensyn på tid. Disse har til hensikt å forklare avvikene i figur 1 og Planlegging I figur 1 ser man at gruppen brukte for få timer i forhold til det som er estimert. Den viktigste årsaken til dette er oppstartsproblemene som gjerne oppleves i begynnelsen av et prosjekt. Rutinene er ikke på plass, og når de er det så tar det litt tid før de er skikkelig innøvd. I tillegg mener gruppen det er vanlig at det tar litt tid å komme skikkelig igang med arbeidet i begynnelsen av et semester. 12