Prosessrapport. Lars Martin Bredal Morten Byhring Tom Erik Iversen. Høgskolen i Oslo, avdeling for ingeniørutdanning 23. mai 2008

Transkript

1 Prosessrapport Lars Martin Bredal Morten Byhring Tom Erik Iversen Høgskolen i Oslo, avdeling for ingeniørutdanning 23. mai

2 1 Forord Dette dokumentet forteller om planleggingen og arbeidsmetodene som er brukt i hovedprosjektet. Rapporten er optimalisert for papir, og det kreves noe kompetanse innen matematikk og informatikk for å forstå innholdet. Vi ønsker å rette en stor takk til følgende personer som har hjulpet og veiledet oss i arbeidet med prosjektet: Simen Hagen - for konstruktiv kritikk og tilbakemeldinger Paul Anderson - for datamateriale 2

3 Innhold 1 Forord 2 2 Innledning Om oppdragsgiver Dagens situasjon Mål og rammebetingelser Mål Rammebetingelser Planlegging og metode Datagrunnlag Verktøy Faglige forutsetninger Hva måtte vi lære VRML og tredimensjonal geometri Visualiseringsteknikker Hva skal visualiseres? Utviklingsprosessen Utviklingsfasene Oppstart Planlegging Forstudie Prosessmodell Dokumentasjon Oppbygging av programmet Dataimporter XML-tolker Import til database Datavisualiserer Visualisering i praksis Brukergrensesnitt (GUI) Utfordringer Om kravspesifikasjonen Avslutning Oppsummering Hva kunne vært gjort annerledes? Ønsker for fremtiden

4 5.4 Konklusjon Appendix E-post fra Paul Anderson

5 2 Innledning 2.1 Om oppdragsgiver Oppdragsgiver er Høgskolen i Oslo, ved lektor Simen Hagen. Simen har tidligere hatt kontakt med Paul Anderson, professor ved University of Edinburgh. De har diskutert muligheten for et prosjekt som går ut på å visualisere konfigurasjonsfiler. 2.2 Dagens situasjon LCFG (Local ConFiGuration system) er et system som brukes for å administrere konfigurasjon av et stort antall UNIX-maskiner. Systemet er utviklet av blant annet Paul Anderson ved University of Edinburgh. Konfigurasjonsinnstillingene distribueres ved hjelp av XML-filer (extendible Markup Language) som hentes fra en webserver. Hver maskin har sin XMLfil med en unik konfigurasjon. Oppdragsgiver ønsker å få en grafisk oversikt over maskiner i nettverket, der disse er gruppert basert på hvor forskjellig maskinene er konfigurert. 2.3 Mål og rammebetingelser Mål Hovedmålet med prosjektet er å ekstrahere data og visualisere grupper av maskiner basert på konfigurasjons(u)likhet. Vårt system skal kunne: ˆ Lese inn spesifiserte data fra XML-filene og legge disse inn i en database. ˆ Hente ønskede data fra databasen. ˆ Visualisere data på en eller flere hensiktsmessige måter Rammebetingelser Oppgaven er løst formulert fra oppdragsgivers side. Det er ikke stilt spesifikke krav til hvilke data som skal visualiseres, eller hvilken visualiseringsmetode som skal brukes. Datamaterialet er svært stort, og det må beregnes at mye tid vil gå med til å få oversikt over dette. På grunn av den store datamengden vil det i første omgang være naturlig å velge ut noen få verdier som brukes til visualisering, men systemet bør være skalerbart. Vi har fått frie hender når det gjelder valg av utviklingsplattform og verktøy. 5

6 3 Planlegging og metode 3.1 Datagrunnlag Datagrunnlaget for prosjektet er et sett XML-filer, der hver fil representerer konfigurasjonen til en maskin på et gitt tidspunkt. Første datasett bestod av 1060 XML-filer med en gjennomsnittlig størrelse på 1 MB. Første fase av prosjektet gikk i stor grad ut på å få en oversikt over strukturen på disse filene og hvilke data som var tilgjengelige. Oppdragsgiver hadde gitt en viss pekepinn på hvilke data som var mindre interessante, blant annet feilsøkingsinformasjon. Dette ble fjernet, noe som halverte filstørrelsen og gjorde det lettere å lese filene manuelt. Neste trinn i prosessen var å velge ut hvilke data vi ville jobbe videre med. I dette arbeidet ble dokumentasjonen [2] til LCFG brukt for å finne ut hva de enkelte verdiene representerte. Denne dokumentasjonen dekket ikke alle områder, men var likevel til stor hjelp. Det viste seg for eksempel at en del potensielt interessante datafelt hadde en annen betydning enn først antatt. Oppbyggingen til XML-filene kan oppsummeres slik: Profilen består av to hovedseksjoner: components og packages. Seksjonen components inneholder en rekke underseksjoner som representerer konfigurasjonen av et program, eller tjeneste (komponent), på maskinen. En komponent kan ha både andre underseksjoner og bladnoder som inneholder informasjon. Det er mer enn 100 forskjellige components i datamaterialet. Kun profile-komponenten er obligatorisk i components-seksjonen. 3.2 Verktøy Tidlig i prosjektprosessen hadde vi et møte med veileder hvor det ble diskutert hvilke teknologier som burde brukes til å gjennomføre prosjektet. Det var nødvendig med et programmeringsspråk som raskt kunne tolke XMLdata, kommunisere med en database og generere tekstfiler, i tillegg til et språk som egner seg for å visualisere et stort antall noder i et tredimensjonalt rom. Da XML-filene er svært store, er det ønskelig å lagre informasjon i en database, både for å spare lagringsplass og tid ved henting av data. Etter å ha lest om forskjellige teknologier og vurdert alternativene, falt valget på Perl og VRML (Virtual Reality Modeling Language) som programmeringsspråk og mysql som databasemotor. Perl ble valgt på grunn av sin gode evne til å manipulere tekst. I tillegg er mye av LCFG skrevet i Perl, så gruppa mente dette var et naturlig valg. 6

7 VRML er et Markup-Language for 3D-modellering. Syntaksen ligner på HTML (HyperText Markup Language) og XML. Dette ble valgt blant annet fordi veileder har god kjennskap til dette språket. MySQL (My Structured Query Language) er valgt som databasemotor fordi vi er kjent med syntaksen, den er plattformuavhengig og tilgjengelig som åpen kildekode. Eclipse, med tilleggsmodulene EPIC (Eclipse Perl Integration) og Subclipse for versjonskontroll (Subversion) er brukt som utviklingsmiljø. Dette ble valgt fordi det er et godt utviklingsmiljø til Perl, med integrert støtte for subversion. L A TEX er dokumentasjonsverktøyet brukt i prosjektperioden. Begrunnelsen for dette var at det skulle bli lettere å fokusere kun på skriving, ikke formattering av tekst. Da L A TEX-dokumenter kun består av ren tekst, er det også enklere å synkronisere dokumenter med Subversion. 3.3 Faglige forutsetninger Vi har hatt behov for å tilegne oss ny kunnskap om språkene og modulene som brukes i prosjektet, og lære oss ny syntaks raskt. Tidligere programmeringsfag har gitt oss erfaring med flere typer språk, og gitt oss god forståelse for programmering generelt. Dette grunnlaget har gjort det enklere å ta i bruk Perl, VRML og de respektive modulene. Fagene Operativsystemer og Unix og Nettverks- og Systemadministrasjon har gitt oss innblikk i Perl-programmering og administrasjon av Unix-tjenester. Dette har hjulpet oss i programmeringen, samt til å forstå mange av konfigurasjonsparametrene som forekommer i profilene. Dermed har det blitt lettere å velge ut komponenter til visualisering. For eksempel forteller noen av profilene at en maskin er Apache- eller PostgreSQL-server, og uten disse fagene hadde vi hatt liten kunnskap om dette. Relasjonsdatabasefaget har gitt oss grunnleggende kunnskap om databaser. For å komme fram til bedre algoritmer for vektor- og posisjonsberegning har fagene Lineær Algebra og Algoritmer og datastrukturer vært til stor hjelp. I systemutviklingsfaget har vi lært om forskjellige systemutviklingsmetodikker, som har gitt oss bedre forståelse for planlegging og strukturering av prosjektet. 7

8 3.4 Hva måtte vi lære Gruppa hadde på forhånd svært liten erfaring med visualisering generelt, og ingen erfaring med 3D-modellering. Derfor måtte vi bruke mye tid på å lære VRML og 3D-tankegang, samt få en bedre forståelse av visualiseringsteknikker og utnytte dette i prosjektet. Vi har heller ikke brukt L A TEX som dokumentasjonsverktøy tidligere, og ser på prosjektperioden som en god anledning til å lære oss dette VRML og tredimensjonal geometri En verden i VRML har en struktur der alle objekter er plassert i et globalt koordinatsystem. I tillegg kan det defineres transformasjonsobjekter, som danner lokale koordinatsystemer for de objektene som tilhører dette. Den globale posisjonen til et objekt kan dermed avhenge av plasseringen i flere lokale koordinatsystemer. Muligheten til å bruke lokale referanser gjør det enklere å plassere grupper av objekter i forhold til hverandre. Objekter som hører sammen i forhold til hverandre kan grupperes, for deretter å plassere gruppen globalt. Et eksempel er laget i figur 1. Her er trekanten plassert i Figur 1: VRML-koordinater posisjon (0,0,0) globalt. Boksen er satt i (-10, 5, 0), og ballen og sylinderen er en egen gruppe som er plassert i posisjon ( 10, -5, 0). Sylinderen har i tillegg en lokal plassering (0,-2,0) inne i denne gruppen. 8

9 3.4.2 Visualiseringsteknikker En av oppgavene vi hadde var å prøve ut ulike visualiseringsteknikker, for å se hvilke som kunne passe til forskjellige data. Målet er å visualisere grupper (clustere) av datamaskiner, heretter kalt noder, der nodenes konfigurasjons(u)likhet kommer klart frem. Dette kan for eksempel uttrykkes ved nodenes form, farge og posisjoner i et tredimensjonalt rom. For å få litt inspirasjon, viste vår veileder en masteroppgave [3] som presenterte mange forskjellige måter å visualisere data på. Noen teknikker vi ønsket å prøve var blant annet: Informasjonspyramider (figur 2 ) Her vises informasjon i flere lag som et hierarki. Eksempelvis kan man tegne opp et lag nederst som representerer alle noder (A), trinn 2 består av noder fra A som oppfyller et bestemt kriterium B, slik at Trinn 2 = A B. Det er da mulig å få et inntrykk av hvor mange noder som oppfyller forskjellige kriterier. Figur 2: Informasjonspyramide Punktdiagram Dette består av noder som er spredt rundt i et område. Posisjonen til en node kan fortelle noe om nodens egenskaper, på samme måte som en graf. Et eksempel vises i figur 3. 9

10 Figur 3: Punktdiagram Fargekodete kart Ved å legge noder i et plan, og deretter fargelegge de delene som oppfyller et kriterie, vil man kunne få noe som minner om et kart, der interessante områder blir uthevet. Eksempelet i figur 4 viser gjennomsnittlig kvadratmeterpris i forskjellige bydeler i New York [1]. Figur 4: Fargekodet kart 10

11 Tre-visualisering Kan vise nodens indre struktur og gjør det mulig å sammenligne to eller flere trær. Jamført nodenes struktur, vil ikke dette være et typisk binærtre. En mulighet vil også være å forsøke å visualisere en eller flere standardnoder basert på statistisk analyse av dataene, og så sammenligne enkeltnoder opp mot standarden. Vi ønsker å kombinere flere av disse teknikkene der dette er mulig, for å kunne trekke ut informasjon og sammenhenger som ellers er vanskelige å finne. 3.5 Hva skal visualiseres? For det første var det nødvendig å få oversikt over dataene, for å se hva de representerte. Etter hvert ble det klart at for å avgrense oppgaven, begrenset vi oss til components-seksjonen i filene. Til å hjelpe oss med analysen, laget vi et Perl-script som gikk gjennom alle profil-filene, og fant antallet forskjellige komponenter, samt hvor mange maskiner som hadde disse. Dette gjorde det enklere å få oversikt over hvilke komponenter som var i bruk. Etter å ha lest gjennom dokumentasjonen over komponentene og sett hvilke parametere som var vanlige, ble det satt opp en liste over aktuelle felter i samarbeid med oppdragsgiver/veileder. Eksempler på komponenter: ˆ inv/os -> Operativsystem ˆ inv/location -> Fysisk lokasjon ˆ apache -> Betyr at maskinen kjører en webservertjeneste. ˆ network/gateway -> maskinens standard gateway Siden oppgaven var relativt løst formulert, hadde vi vanskeligheter med å slå oss til ro med de komponentene vi hadde valgt. Derfor konsentrerte vi oss heller om å lage generiske visualiseringer som kunne brukes til alle slags datafelter. 4 Utviklingsprosessen Her vil vi forklare hvilke utviklingsfaser prosjektet har vært gjennom, utfordringer vi møtte underveis, og begrunnelser for valgene som ble tatt. 4.1 Utviklingsfasene Oppstart Gruppen ble samlet i oktober 2007, bestående av tre personer som tidligere har jobbet sammen i forskjellige skoleprosjekter. 11

12 For å komme fram til en passende oppgave, søkte vi etter potensielle prosjekter, og diskuterte hva som ville egne seg best for oss. Vi bestemte oss for dette prosjektet av flere grunner, men i hovedsak fordi det ville bli en veldig lærerik prosess å jobbe med nye emner vi har liten erfaring med Planlegging Etter at oppgaven var tildelt fra arbeidsgiver, begynte planleggingen av prosjektet. Sammen med veileder satte vi opp en midlertidig kravspesifikasjon og rådførte oss om hvilke teknologier og verktøy som bør brukes Forstudie Bygging av kompetanse har vært vesentlig i dette prosjektet, og det ble satt av god tid til dette i denne fasen. Temaene som ble studert og prøvd ut var blant annet XML, Perl, og VRML Prosessmodell Gruppa bestemte seg tidlig for å benytte seg av en smidig utviklingsprosess. Kravspesifikasjonene vil være i konstant utvikling, og derfor er det ønskelig å dra nytte av en iterativ utviklingsprosess. Selve programutviklingen vil iterere fire faser; innledning, utforming, bygging og testing. Disse fasene kan overlappe hverandre. Siden gruppen hadde liten forkunnskap om teknologiene i prosjektet, var det viktig å komme straks i gang med programmeringen i prosjektet, og så bli kjent med språkene og verktøyene underveis. I innledningsfasen planla og designet vi ny funksjonalitet på papir. I utformingsfasen lagde vi en prototyp over ny funksjonalitet, og denne ble designet digitalt. Dette ble vanligvis gjort ved å redigere en VRML-fil for hånd. I byggingsfasen integrerte vi generisk funksjonalitet for prototypen i systemet. I testfasen ble den nye funksjonaliteten testet. Ved eventuelle feil eller mangler gikk vi tilbake til utformingsfasen. Disse fire fasene var spesielt viktige i utformingen av de forskjellige visualiseringsteknikkene våre Dokumentasjon Etter at utviklingstiden var slutt, startet arbeidet med å ferdigstille dokumentasjonen. Mye av prosessdokumentasjonen har blitt fylt ut underveis, mens den resterende sluttdokumentasjon måtte skrives. 12

13 4.2 Oppbygging av programmet Programmet består av to hoveddeler: dataimport og datavisualiserer. Vi har valgt å implementere en 3-lagstruktur med DAL (Data Access Layer) for database-tilkobling, BLL (Business Logic Layer) for generering av VRML, og GUI (Graphical User Interface) for kommunikasjon/presentasjon for sluttbruker. Dette er gjort for å gjøre systemet utvidbart og generisk - eksempelvis vil det være mulig å gå over til en annen databasemotor ved kun å endre/bytte ut DAL. Videre har vi valgt å implementere løsningen som en web-applikasjon, da kombinasjonen AMP (Apache, MySQL, Perl) er en god og plattformuavhengig kombinasjon, samt at det ikke stiller store krav til klienten, som egentlig kun trenger å kunne vise HTML, Javascript og VRML. 4.3 Dataimporter Importdelen er ansvarlig for å lese inn nye datasett i form av XML-filer, trekke ut ønskede felter og legge disse inn i databasen XML-tolker For å tolke XML-filene, trenger Perl moduler for å forstå XML-struktur på en hensiktsmessig måte. Vi valgte først å bruke XML::DOM (Document Object Model) til å tolke disse filene. Da vi ble godt kjent med syntaksen lagde vi et testskript i Perl, og testet modulen på et lite sett med filer, og ekstrahering av informasjon fungerte godt. Ved tolking av et helt datasett, viste DOM seg å være veldig treg, og minneforbruket ble så stort at testmaskinene kræsjet. Vi løste midlertidig dette problemet ved å kalle en doc->dispose() metode for hver fil vi hadde lest inn, fordi Perls Garbage Collector ikke selv gjorde dette. Minneforbruket forholdt seg stabilt, men tolkingen tok fortsatt for lang tid. Vi søkte etter en ny modul, og fant LibXML som innfridde de forventninger vi har til en XML-tolker. Dette er en XML tolker til Gnome biblioteket (et Linuxgrensenitt), og viste seg å være utrolig rask. Syntaksen på XML-spørringene er litt annerledes fra DOM, så noe omskriving måtte til. Som nevnt må vi tolke et stort antall XML-filer, og LibXML viste seg å være raskere og mer effektiv enn DOM. Vi testet de to modulene opp mot hverandre, og fant ut at DOM forsyner seg av alt tilgjengelig systemminne mens LibXML har et stabilt og lavt minneforbruk. I tillegg viste tester at LibXML omtrent ti ganger kjappere. 13

14 4.3.2 Import til database Planlegging Da vi planla hvordan import til databasen skulle foregå, tenkte vi å lage egne Perl-moduler som inneholder spesifikasjon av hvilke komponenter som skal bli ekstrahert fra XML-filene, og definisjoner på hvordan de skal legges inn i databasen. Produktet vil bli levert med noen standard moduler, og det skal være mulig for brukeren å lage egne. Disse modulene er en god løsning for å trekke ut data, og de vil gi brukeren god konfigurasjonsfrihet. Disse Perl-modulene var en idé som måtte forkastes. Det vil bli for mye jobb for brukeren å skreddersy Perl-moduler etter behov. Derfor innføres heller en sentral konfigurasjonsfil, hvor det viktigste av konfigurasjon av programmet skal bli satt. Denne konfigurasjonsfilen vil inneholde informasjon om databasetilkoblingen, XML-filene og hvilke felter som skal importeres og visualiseres. Implementasjon og metode Perl-scriptet XML_to_DB er programmet som blir brukt til å importere XML-verdier til databasen. Det leser informasjon fra konfigurasjonsfilen, oppretter databasetilkobling, ekstraherer ønsket komponentinformasjon fra XML-filene, og sender XML-verdier til databasen via DAL. Databasestruktur Etter å ha analysert XML-filene, kom vi fram til at det ville være hensiktsmessig å opprette en tabell for hver konfigurasjonsdel som vi ønsker å importere. Et eksempel: i XML-filene har vi som oftest en konfigurasjonsdel <network>. En barnenode av network er <gateway>, og dersom det ønskes å importere denne taggen, oppretter vi en tabell network, med et felt gateway. Primærnøkkelen blir satt til navnet på XML-fila (som tilsvarer maskinnavnet), og som standard opprettes alle felt som VARCHAR(200). Nye datasett Etter at halve prosjektperioden var gått fikk vi tildelt nye datasett fra oppdragsgiver. Disse nye datasettene var tatt gjennom et tidsløp på nesten tre måneder, og vi måtte oppdatere våre metoder for å legge til nye verdier til databasen. Med nye datasett spiller dato en viktig rolle for visualisering. Primærnøkkelen i tabellene vil nå være maskinnavn kombinert med datoen 14

15 spesifisert i filens <last_modified>-tag, da konfigurasjonen kan endres over tid og vi trenger å ta vare på endringer i konfigurasjon. Siden det skal være mulig å legge til nye datafelter for import, vil databasen vår bli utvidet med flere tabeller og/eller nye felt etter behov. Den obligatoriske komponenten <last_modified> forteller når filen sist ble endret, men det betyr ikke at verdiene vi skal ha inn i databasen har fått ny verdi siden siste import. Derfor måtte det også implementeres en kryssjekk, som ser om det er redundant data som vil bli lagt til. Hvis det er blitt noen forandringer, vil det opprettes en ny rad med nye data. Når XML-verdier blir sendt fra XML_to_DB til DAL, har det blitt opprettet en databasetilkobling for hver eneste spørring. Dette vil si at det har blitt gjort omtrent 2000 databasetilkoblinger for et datasett. Siden ekstrahering og import av data tar forholdsvis lang tid, ville vi minske tidsforbruket. Løsningen ble å gjøre DAL objektorientert, slik at tilkoblingen til databasen er åpen så lenge programmet kjører. De nye datasettene innførte flere spesielle tegn i komponentenes verdier, for eksempel ;. Disse tegnene ødelegger SQL-spørringene fra importskript til DAL. For å løse dette ble det laget en metode som bruker substitusjon og regulære uttrykk for å fjerne disse tegnene. 4.4 Datavisualiserer Datavisualisererdelen har ansvaret for å hente data fra databasen og generere VRML som så blir presentert for brukeren Visualisering i praksis Mye av prosjekttiden har blitt brukt til å lære om og prøve ut forskjellige teknikker, og utvikle egne algoritmer gjennom eksperimentering. Til å begynne med resulterte dette i enkle visualiseringer av noder, der et kriterium bestemmer utseendet til noden. Etter hvert kunne flere av disse metodene settes sammen, og dermed danne mer komplekse visualiseringer ved å kombinere eksisterende metoder. Det var også interessant å finne algoritmer som hensiktsmessig plassererer objekter i et tredimensjonalt rom. Da det ikke er mulig å forutsi hvor mange noder eller grupper som kan forekomme i en visualisering, måtte det utvikles generiske metoder Brukergrensesnitt (GUI) Vi ble enige om at vi ville ha et brukergrensesnitt som er enkelt og funksjonelt, hvor hovedfokuset skal være på visualiseringsfilen. Med en web-løsning har 15

16 vi muligheten til å gi brukeren et enkelt grensesnitt, og VRML-fila kan legges inn og oppdateres kontinuerlig. Vi valgte å bruke en av Perl s moduler, CGI (Common Gateway Interface), til å lage dette. CGI kommuniserer med Perl og Apache på en god måte, og siden det er laget i Perl trenger vi ikke introdusere nye språk/teknologier i brukergrensesnittet. Hendelsesforløpet ved å få fram en visualisering i GUI er tenkt slik: ˆ Velge visualiseringsteknikk ˆ Velge tabeller og kriterier ˆ VRML-filen blir lagt til, og kommer opp på siden Selve VRML-fila (.wrl) som ble lagt til i websiden ble ikke oppdatert i nettleseren. Ved første kjøring av websiden fungerte det å hente opp den genererte VRML-fila, men ved neste kjøring (med helt andre kriterier), ble fortsatt den gamle VRML-fila vist. Tømming av maskinens hurtigminne hjalp ikke. Etter mye testing viste det seg at nevnte feil er nettleserrelatert. Ved omstart av nettleseren blir riktig VRML-fil lastet opp på websiden. Løsningen ble å lage en lenke til den genererte fila, slik at brukeren manuelt kan åpne den nyeste visualiseringen. 4.5 Utfordringer Det har utvilsomt vært utfordringer underveis. Først og fremst har det vært problematisk å tilegne seg kunnskap om VRML97. Det er et litt eldre språk, og det er mye utdatert stoff både i bøker og på Internett. Dette omhandlet ofte gamle spesifikasjoner eller gjaldt for utdaterte VRML-lesere, som gjorde det vanskelig å finne ut hva som gjelder nå. I tillegg har det vært en bratt læreingskurve for å beherske det. De ulike VRML-leserne fulgte ikke nødvendigvis de samme spesifikasjonene, slik at gyldig VRML-kode kunne oppføre seg forskjellig i to programmer. Derfor valgte vi å standardisere etter Octaga Player, siden den virker mest robust og ferdig. Beregning av 3D-posisjoner En viktig del av visualiseringen har vært å finne algoritmer som kan brukes til beregning av posisjoner i det tredimensjonale rommet. Siden posisjonene i VRML er oppgitt i kartesiske koordinater, har det vært hensiktsmessig å benytte vektorer for å beregne plasseringen av objektene. I visualiseringene har vi funnet det nødvendig å bruke to metoder for å generere vilkårlige koordinater. Den ene genererer en vilkårlig posisjon innenfor en boks med 16

17 gitte dimensjoner, og den andre genererer en posisjon mellom to sfærer som begge har sentrum i origo. Begge metodene returnerer en array på tre elementer som representerer en tredimensjonal vektor. Metoden for beregning av posisjon innenfor en boks returnerer en array med vilkårlige verdier mellom null og angitt maksimalverdi for henholdsvis bredde, høyde og dybde. Metoden for beregning av koordinater mellom to sfærer er litt mer komplisert. Den trenger to parametere som angir radius på den indre og den ytre sfæren. I tillegg tar den en parameter som angir hvilken avstand som kan brukes til å gi en skalering av avstanden mellom to posisjoner. Metoden genererer først en tilfeldig vektorlengde som ligger mellom de to grensene angitt ved de to første parametrene delt på avstandsparameteren. Denne vektorlengden representerer radius r i likningen for en kule med senter i origo der x, y og z er aksene: r 2 = x 2 + y 2 + z 2 (1) X-verdien settes først til et tilfeldig tall slik at x [ 0, r ]. Deretter settes y tilfeldig slik at y [ 0, r 2 x 2 ] før z-verdien til slutt beregnes ut fra r, x og y: z = r 2 (x 2 + y 2 ) (2) De tre beregnede verdiene for henholdsvis x, y og z er alle positive flyttall. De representerer derfor kun punkter i første kvadrant. For å få negative verdier, og dermed kunne fylle en hel sfære, blir hver av verdiene tilfeldig multiplisert med 1 eller -1. I tillegg multipliseres hver av verdiene med avstandsparameteren for å få tilbake ønsket skalering, og verdiene konverteres til heltall før de returneres som en array på tre elementer. Generering av farger VRML krever at en farge beskrives som en tredimensjonal vektor, der hver komponent i vektoren er et tall x [0, 1]. Komponentene x 1, x 2 og x 3 representerer primærfargene rød, grønn og blå, og ved å endre verdiene på en eller flere av disse kan man generere ulike farger fra [0, 0, 0] (svart) til [1, 1, 1] (hvit). I en visualisering er det ofte naturlig å fargelegge ulike komponenter eller grupper for å markere hva som hører sammen. Da er det en fordel om fargene på forskjellige gruppene ikke er altfor like. Dette blir vanskeligere hvis det er svært mange grupper, så fra et visst punkt er det ikke lenger praktisk å bruke farger for å vise forskjeller. Ved å prøve oss fram med forskjellige teknikker, har vi endt opp med å bruke en metode som genererer opp til 17

18 36 ulike farger. Dette er også kombinert med å gi sluttbruker mulighet til å filtrere ut grupper helt for å øke lesbarheten. 4.6 Om kravspesifikasjonen I begynnelsen av prosjektperioden hadde prosjektet en svært løs kravspesifikasjon, blant annet basert på samtaler med veileder og oppdragsgiver (se 6.1). Underveis i prosjektperioden ble disse kravene raffinert, og nye krav ble lagt til. Dette ble gjort fordi vi trengte kunnskap om både verktøy og konfigurasjonsfiler for å kunne sette realistiske krav. Kravspesifikasjonen har dermed vært i konstant utvikling gjennom hele prosjektperioden, og det er gruppemedlemmene selv som har utarbeidet denne. Dette har gjort arbeidet spennende, fordi gruppen har fått stor grad av frihet til å selv velge ut interessante oppgaver og bestemme hvordan disse skal løses. Arbeidet uten en tydelig kravspesifikasjon har også gjort det til en større utfordring. I motsetning til et prosjekt med strenge krav, har vi måttet bruke mye tid på å finne ut hva vi skal gjøre, i tillegg til hvordan det best kan løses. En ulempe med dette, var at det var vanskelig å legge langsiktige planer, samt å vite hvordan vi lå an i forhold til tid. Vi følte også mange ganger at det faktiske arbeidet vi gjorde, var langt mer omfattende enn det endelige produktet skulle tilsi. 5 Avslutning 5.1 Oppsummering Prosjektperioden har vært utfordrende og lærerik. Ved prosjektstart hadde vi bare en vag ide om hva vi skulle gjøre og hvordan, og fra dette har vi kommet et stort skritt videre. Gjennom arbeidet har vi lært mye, spesielt om visualisering, 3D og Perl, og føler at dette grunnlaget kan komme godt med i mange sammenhenger. Vi synes også at det har vært gøy å jobbe med et litt annerledes prosjekt, med stor grad av frihet og mulighet til å utforme løsninger selv. 5.2 Hva kunne vært gjort annerledes? Under utviklingen ble det lagt vekt på å lage ting så generisk som mulig, samt at visualiseringene skal fungere godt. Punkter til forbedring i en neste iterasjon, er blant annet datastrukturen: Databasen skulle vært redesignet, for å få den normalisert og mer hensiktsmessig bygget opp. Det hadde også vært bra å få utvidet visualiseringsteknikkene til å inkludere muligheten for å 18

19 visualisere utvikling over tid, i nåværende versjon er det kun en teknikk som gjør dette. Vi ville også ha forsøkt å finne ut hvordan vi kunne ha produsert VRML-kode som virker feilfritt i andre VRML-browsere. Mot slutten av prosjektperioden kunne vi begynne å høste fruktene av alt vi hadde gjort og lært, så det var lettere å utvikle ny funksjonalitet og se mulighetene. Aller helst skulle vi ha vært på det stadiet litt tidligere, så kanskje vi burde ha prioritert å arbeide mindre med dataene og mer med VRML til å begynne med. 5.3 Ønsker for fremtiden Ved å skreddersy DAL-laget i vår applikasjon til å passe en annen databasestruktur, bør det være mulig å visualisere andre data enn de vi selv har brukt. Det hadde vært spennende om programmet kunne utvides til at man enkelt kunne tilpasse visualiseringsmodulen til å visualisere hva som helst. Vi håper også at vår oppdragsgiver blir fornøyd med arbeidet vi har gjort og at han kan dra nytte av produktet vårt. 5.4 Konklusjon Referanser [1] 08 heatmap.jpg. [2] Paul Anderson. The complete guide to lcfg. [3] Werner Putz. The hierarchical visualization system. Master s thesis, Graz University of Technology, Appendix 6.1 E-post fra Paul Anderson I m enclosing one XML "profile" which is the entire configuration spec for one machine (my desktop in this case). We have about 1500 of these for the whole of our real installation, and we could probably also extract a few years worth of historical ones from the CVS. As I said, this should provide a fairly explicit format for extracting data which we could visualise, but there will probably be some wrinkles in practice. In case you feel like looking it over, here are a few 19

20 random initial comments... (*) the <components> section is probably all you want to look at. (*) This has a list of configuration components - eg. the first one called "LPRng" (*) Each component has a list of key/value pairs ("resources") - eg. buildperms = /usr/sbin/build-print-perms (*) You can throw away the "derivation" attribute - this tells you where in the source it is generated from (for debugging) (*) Some resource values are compound structures called "tag lists" which are like ordered records In this case, the "name" attribute gives the "tag" (record name). Eg. conf.printcap = printcap_path= -\$ /usr/bin/pcap-query conf.nonprintable = check_for_nonprintable@ Etc... (*) These structures can be nested - the XML for this probably looks a bit odd. (*) You can throw away the "template" attribute - this is used for serialising these structures and forming variable names. (*) I suspect that these structures will cause the most trouble in practice, because sometimes the tags are significant and their values are used by the component. Other times, the tags are arbitrary and it is only the values and the order which are significant. This is a consequence of using a single data structure ("tag list") to represent both lists and records. This is historical, and I m not sure whether it is still a good idea or not! In practice, we could probably create a kind of schema file for each component type saying which things were significant. (*) I d be very interested in trying to visualise how "different" the machines are. The metric for this would presumably be something simple to start with like the number of resources which were different between two machines. Once we see what this looks like, we would probably want to refine this, for example with weightings. We might even want to play 20

21 with this dynamically. (*) I suspect that a large number of the resource values never vary at all for machines at our site - it would be interesting to know what proportion - but these can probably just be thrown away (once they have been identified). (*) The values are nearly all going to be strings. Even when they are numeric, I don t think it will make any sense to treat them as numbers when computing any kind of metric. (*) Some resource - eg. conserver.servers specify the names of other machines. It should be possible to identify these resources and use (only) those to identify dependencies between clients and servers (for different services). This might make another interesting visualisation! Paul fremhever spesiellt to ting han er interessert i å visualisere: 1) Dependencies - elements in the configuration for one machine reference other machines - this forms a dependency network. 2) Clustering - it would be nice to be able to compare the configuration resources for machines and group the machines by how "similar" their resources were, and then visualise the resulting clusters