Forord Dette er produktdokumentasjonen skrevet i forbindelse med hovedprosjekt ved Høgskolen i Oslo våren 2010.

Transkript

1 PRODUKTDOKUMENTSJON

2 Forord Dette er produktdokumentasjonen skrevet i forbindelse med hovedprosjekt ved Høgskolen i Oslo våren Dokumentet beskriver applikasjonen vi har laget med fokus på den tekniske utførelsen. Dokumentet er beregnet for sensor, vår veileder og andre skulle ha interesse for applikasjonen. Vi prøver med dette dokumentet å illustrere applikasjonens omfang og vanskelighetsgrad. Produktdokumentasjonen er skrevet for lesere med grunnleggende kunnskap innen datateknologi og systemutvikling. Om leser søker utfyllende dokumentasjon om prosessen, testing og bruk av produktet henviser vi til prosess-, produkt- og brukerdokumentasjon.

3 Detaljert innholdsfortegnelse for produktdokumentasjonen Innhold Detaljert innholdsfortegnelse for produktdokumentasjonen Presentasjon av applikasjonen Kort beskrivelse av produktet Systemkrav Programflyt Loggfilene Parser Applikasjonsstruktur Overordnet struktur Datalaget DAL Business Logic Layer BLL Presentasjonslaget Brukergrensesnitt Database Relasjonsdiagram Tabellbeskrivelse Bruk av tråder Videreutvikling av applikasjonen Kildekode Utviklingsplattform Forslag til videreutvikling... 34

4 2.1 Presentasjon av applikasjonen Kort beskrivelse av produktet Denne applikasjonen er laget for å kunne visualisere brukerhistorikk fra et automasjonssystem som ABB bruker for å overvåke et gass- og oljeanlegg ut i industrien. For informasjon om selve automasjonsanlegget, henvises til prosessdokumentasjonen kapitel Applikasjonen har følgende funksjonalitet: Åpne loggfiler: Bruker av applikasjonen kan laste inn loggfiler. Loggfilen kjøres gjennom en parser, som henter ut verdier som legges inn i en database. Velge grupper: Ut fra innholdet i databasen blir det opprettet en liste over tilgjengelige bildegrupper og over hvilke bilder som ligger under gruppene. Bruker kan her velge hvilke bildegrupper og underliggende bilder som ønskes å visualisere. Velge eventer: Bildene forekommer gjennom forskjellige eventer. Bruker velger her hvilke eventer som ønskes visualisert. Disse eventene forteller hvordan selve navigeringen har foregått under bruk av automasjonssystemet. Bruker kan her velge mellom 9 forskjellige eventer: ContentChange, Right mouseclick on tab, Right mouseclick on detail tab, Clicked on empty tab, Clicked on empty detail tab, Clicked on selected tab, Clicked on selected detail tab, Tab used for navigation to og Detail Tab used for navigation to. Dato og klokkeslett: Bruker kan velge hvilke dato og klokkeslett som ønskes visualisert. Her velges dato fra og dato til. Utgangspunktet for brukeren er at hele loggperiode er valgt, så dette er et velg som kan gjøres om denne perioden ønskes mindre. Utfør: Dette er en knapp som bekrefter alle valgene som er gjort av bruker, og lager en visualisering ut fra verdiene som ligger under de utførte valgene Systemkrav Applikasjonen er moderat ressurskrevende, og bør derfor ikke brukes på operativsystemer som får en lavere rate enn 3.0 på Windows Performance Rating. Det anbefales en skjermoppløsning på 1250 x 800 piksler, eller høyere, på grunn av at det er mange detaljer som skal vises på skjermen.

5 .Net Framework Applikasjonen er bygget opp med Visual Studio 2008 som inkluderer.net Framework..Net Framework er et rammeverks som har gikk oss tilgang til et stort bibliotek med programkodeløsninger. Med grunnlag i at applikasjonen er bygget opp rundt denne rammen, kreves det også at den PC-en som skal kjøre applikasjonen har.net Framework installert. Microsoft SQL server 2005 For å kunne legge alle verdiene som er ønsket ut fra loggfilene i en database, har vi installert Microsoft SQL server 2005, som lagringsenhet. For å kunne kjøre applikasjonen er det et krav at PC-en har installert SQL server Windows update Det er et systemkrav at Windows er oppdatert med de siste oppdateringer fra Microsoft Windows Update Programflyt Applikasjonen har 2 hovedmønster. Den ene er nå databasen er tom og den andre når databasen innholder det den skal av verdier. For en få en bedre forståelse av hvordan applikasjonen fungerer har vi valgt å illustrere dette ved hjelp av 2 figuren. Figuren under viser hvordan flyten i applikasjonen er når databasen er tom, eller at brukeren ønsker å legge til en ny logg:

6 Brukeren velger en logg som skal visualiseres. Denne loggen kjøres igjennom en parser som henter ut verdiene som skal legges inn i databasen. Disse verdiene blir brukt når grafen tegnes. Grafen blir så synelig for brukeren. Den andre flyten er når bruker ønsker å bruke de verdiene som allerede ligger i databasen. Figuren under viser denne flyten:

7 Brukeren spesifiserer det som skal visualiseres. Verdiene som trengs hentes ut av databasen, og grafen blir tegnet. 2.2 Loggfilene Gjennom navigasjon i systemet dannes det en logg, som forteller hvordan brukeren av systemet har kommet seg frem til det punktet i systemet som var ønsket. Disse loggene danner grunnlaget for verdiene som visualiseres i applikasjonen. Loggene blir skrevet ut og sendt til ABB sin avdeling for videre analyse. Loggfilene inneholder æ, ø og å, som gjør at de må være lagret i UTF8 - og.txt format. Loggene kan åpnes i de fleste testeditorer. Figuren under viser et eksempel på en loggfil: En hendelse i loggen tilsvarer 4 linjer med informasjon. Det vil si at utdraget fra loggen over viser til sammen 7 hendelser som er utført av bruker. Det vi trenger av informasjon fra denne loggen er: Dato og klokkeslett viser hvilke dato og klokkeslett hendelsen er gjort: :06:54:465 Maskinnavn viser hvilke maskin hendelsen kommer fra: TBO-OWP01 ProsessID viser hvilke prosess identitet denne hendelsen hadde: PID: 6188 Tråd viser hvilke tråd denne hendelsen hadde:

8 Thread: 2676 Hendelse viser hvilke navigasjonsform som er tatt i bruk: Tag = ContentChange Bilde forteller hvilke bilde som er vist som et resultat av navigasjonen: RØYKGASSKANAL Dette viser den informasjon som er hentet ut fra den øverste hendelsen i loggen på figuren over. Når brukeren så navigerer videre i systemet vil verdiene gjenspeile handlingen som er utført, som vist i neste hendelse. Bilder inndelt i grupper Alle bildene i loggen er inndelt i til sammen 21 grupper Figuren under viser en tabell med oversikt over alle gruppene i automasjonssystemet. Gruppene er nummerert fra 1 til 21 under kolonnene Group_ID, som er gruppens idnummer og Group_name, som er gruppens navn. 2.3 Parser For å kunne analysere loggene og hente ut de verdiene som ønskes visualisert, er det implementert en parser i applikasjonen. Parseren tar for seg en hendelse, hvor den leser en linje om gangen. Figuren under viser flyten i parseren:

9 Figuren illustrerer metoden public void readfromfile(string filename). Når en logg er åpnet vil parseren ta for seg den første linjen i loggen. Dette er den første av fire linjer, som til sammen utgjør det vi tidligere har omtalt som en hendelse. La oss ta utgangspunkt i hendelsen under som også viser hendelsen med linjenummer: Det første parseren gjør er å sjekke om vi er på linje 1 i hendelsen. Dersom vi er det, vil den hente ut den informasjonen som er interessant i denne linjen. Dette utføres ved å kalle på metodene:

10 Når disse metodene er gjennomført vil variabelen som informerer om hvilken linje parseren er på, få verdien 2, som betyr at parseren nå befinner seg på linje 2 i hendelsen. På denne linje er det ingen informasjon vi trenger så metoden fortsetter videre. Variabelen som teller linjer har nå fått verdien 3. Det første parseren gjør på denne linjen er å sjekke om linjen inneholder det vi har kalt støy. Dette er verdier ABB ikke vet hva er eller kommer av. Om det er slik av parseren finner en slik forekomst, vil den hoppe over denne hendelsen og starte på nytt på linje 1 på neste hendelse. Om parseren ikke finner støy, vil den hente ut den informasjonen som er interessant. Dette utføres ved å kalle på metodene: I tillegg til å utføre disse to metodene går også parseren inn og finner ut hvilke gruppe bildet i linje 3 tilhører. Dette gjennomføres ved å kalle på metoden: Parseren har da hentet ut det den skal i linje 3 og variabelen som teller linjer har nå fått verdien 4. Som vi ser av figuren med hendelen over, så ser vi at det ikke er noen innhold i linje 4. Det som skjer her er at all informasjonen som er hentet ut fra loggen blir lagt i et array, som

11 fungerer som en mellomlagring av dataene som skal inn i databasen. Dette arrayet av data blir så lagt inn i databasen ved kalle på denne metoden: Bruk av Regulære Uttrykk (RegEx.). For å hente ut alle verdiene vi ønsker fra en linje bruker vi regulære uttrykk. Regulære uttrykk er et verktøy for å jobbe med strenger, og som gjøre det mulig for applikasjonen å hente ut de verdiene som skal legges i databasen. Figuren under viser metoden som henter ut datoen fra linje 1: Som vi ser tar vi imot en streng som parameter, hvor vi deretter kjører et RegEx-uttrykk på strengen. Vi bruker dette verktøyet til å hente ut verdier fra alle linjene i hendelsen. 2.4 Applikasjonsstruktur Overordnet struktur Applikasjonen har en trelagsarkitektur, hvor hovedideen er å abstrahere systemdelene på en logisk måte slik at de mer eller mindre kan virke uavhengig av hverandre. Det vi har ønsket her er å skille GUI, logikk og database fra hverandre, for på denne måten å kunne forenkle vedlikehold og videreutvikling av applikasjonen. Figuren under viser en grafisk fremstilling av arkitekturen i applikasjonen, samt hvilke teknologi som er brukt i de forskjellige lagene:

12 Figuren under viser hvordan vi delte inn koden i prosjekter, som var tilhørende de forskjellige lagene: Prosjektene har fått navnene BLL (Business Logic Layer), DAL (Data Access Layer) og GUI (Gaphical User Interface). BLL utgjør logikken, DAL utgjør kommunikasjon med databasen, og GUI utgjør visualiseringen. Vi valgte å gjøre det på denne måte så det skulle være lett å gjennomføre systematisering og vedlikehold av kode Datalaget DAL Generelt Som i de andre lagene er datalaget laget slik at det skal være mulig å bytte det ut. Dette laget er definert under mappen DAL. Laget er ansvarlig for å kunne kommunisere med databasen og for å hente ut alle verdiene vi trenger for å opprette en fullstendig database. Koden i dette prosjektet er forsøkt skrevet så selvforklarende som mulig gjennom bruk av forklarende funksjonsnavn, som gir et inntrykk av hva funksjonen gjør. For å oppnå dette har vi refaktorert kode gjennom hele utviklingen. Figuren under viser eksempel på selvforklarende funksjonsnavn i datalaget:

13 Det har vært et ønske fra ABB om å kunne videreutvikle applikasjonen etter behov. Vi har derfor fokusert på å lage så selvforklarende kode som mulig. LINQ - Language Integrated Query For å opprette et LINQ-lag er de relevante tabellene lagt over i en visuell designer som er integrert i Visual Studio For å gjennomføre dette trekkes alle databasetabellene inn i dette diagrammet, som i praksis betyr at LINQ lager et ORM-objekt av tabellen. ORM (Object Relational Mapping), er en teknikk som muliggjør bruk av valgfri database, hvor det tillates konvertering mellom datatyper fra databasen til objekter. Objektene som skapes bygger på de opprinnelige tabellradene med data. Ved å bruke dette håndterer vi databaseinformasjonen direkte som objekter. Figuren under viser applikasjonens entitetsmodell, som illustrerer relasjonen i databasen opprettet gjennom den visuelle LINQ To SQL-designeren:

14 Ved å opprette LINQ-laget, som består av objekter og metoder, kan vi aksessere databasen via dette laget. Når LINQ-laget ble opprettet ble det generert en databaseklasse, -.dbml. LINQlaget i prosjektet heter LinqDB.dbml. Det blir på denne måten mulig å håndtere databasestyring i applikasjonen gjennom objekter. Måten vi gjør dette på er å bruke Lambdauttrykk, som muliggjør uthenting og sletting av data i databasen. Bruk av LINQ i applikasjonen LINQ-laget blir benyttet i vår databaseklasse DB.cs, og det er 3 aspekter som blir utført mot databasen. Disse er å legge inn -, hente ut - og slette data. Disse tre handlingene gjenspeiler handlinger som brukeren utførere. Når brukeren ønsker å legge til en logg i databasen blir metoden legge-til metoden benyttet. Deretter når brukeren har gjort sine valg for visualiseringen, benyttes hent-ut-verdier metoden. Når brukeren ønske å legge til en ny logg, benyttes først slett-database metoden og deretter legge-til metoden. Vi skal nå se på hver av disse metodene. Figuren under viser innholdet i metoden settinnhandling:

15 Her opprettes et eget objekt av typen LinqDBDataContext, som lager et view inn i databasen. Denne instansen har fått navnet nyhandlingrad. Videre legger denne metoden verdiene inn i databasen under hver kolonne. Bildet under viser hvordan databasen blir seende ut etter at metoden er utført: I de tilfeller hvor brukeren ønsker å legge inn en ny logg, skal de dataene som ligger i databasen slettes. Det blir da gjort en kall på metoden slettdatabasen. Metodens innhold vises i bildet under:

16 I likhet med leggtillogg metoden blir det også her opprettet et view inn til databasen. Deretter kjøres uttrykk som sletter alle kolonnene i databasen. Etter at brukeren har gjort sine valg for hva som skal visualiseres, blir det gjort kall på flere hent-ut-verdier metoder. Disse er liste opp i bildet fra DB.cs klassen under: Om vi tar for oss metoden som henter ut gruppenavn. Denne metoden lager som nevnt tidligere for view inn i databasen, og basert på gruppe - id som parameter og ved hjelp av et Lambda-uttrykk får vi returnert gruppenavn. Dette er altså et eksempel på hvordan hent-utverdier metodene i applikasjonen ser ut og bruk av Lambda-uttrykk Business Logic Layer BLL. Generelt Business Logic Layer er det laget som skille presentasjonslaget fra datalaget og datalaget fra presentasjonslaget. Alt som skjer av kommunikasjon mellom disse to lagene skjer gjennom logikklaget. Ved å ha implementert dette laget vil det være enkelt for ABB å bytte ut de lagene som skulle være ønskelig å bytte ut. Figuren under viser hvilke klasser og metoder som er inkluder i prosjektet BLL:

17 Funksjonaliteten i dette laget I Logikk-klassen blir det gjort kall på metoder i DB.cs - og parser.cs klassen som returnerer det som ønskes av verdier fra databasen og for å kunne kjøre parseren. Måten dette blir gjort på er at det blir laget instanser av begge klassene. Bildet under viser hvordan dette blir opprettet: Videre brukes disse to instansene i returmetodene som ligger i klassen. Eksempel på en slik metode vises i bildet under, som er en metode som returnerer gruppenavnet til bildet: Det er på denne måten dette laget blir et mellomledd for all kommunikasjon som skjer mellom lagene. Når presentasjonslaget skal spør om en tjeneste i databasen, blir spørringen gjort til logikklaget. Logikklaget gjør så en spørring til databasen gjennom de returmetodene som er implementer i logikk-klassen. På denne måten er det ingen dirkekte kommunikasjon. For å lette forståelsen av hvordan dette fungere kan vi ta for oss eksemplet, hvor bruker ønsker å åpne en ny logg. Når brukeren klikker på den loggen som ønskes å laste inn, blir det gjort et kall på metoden som heter readfromfile som ligger i klassen Parser.cs. Dette kallet

18 blir da altså ikke gjort direkte fra presentasjonslaget ned til datalaget. Kallet blir gjort fra presentasjonslaget i applikasjonen og videre ned til logikklaget. Dette skjer i metoden menybox_selectionchanged, hvor instansen som er opprettet i logikklaget (DB data = new DB), blir brukt for å nå tak i metoden. Bildet viser denne handlingen: Deretter blir det så gjort et nytt kall fra logikklaget ned til datalaget via denne metoden. Bildet under viser metodens innhold: Presentasjonslaget Generelt Dette laget tar for seg den visuelle delen av applikasjonen og inngår som det øverste laget i strukturen. I likhet med de andre lagene er dette implementert slik at det er mulig å skifte det ut. Kommunikasjon mellom de andre lagene skjer via Business Logic Layer, som igjen kommuniserer videre med Data Access Layer. For å få den grafiske visualiseringen i applikasjonen bruker vi et verktøy som heter WPF - Windows Presentasjon Fundation, som er et verktøy som gir tilgang til en samling WPF klasser og metoder utenfor den vanlige.net Framework syklusen. Vi bruker ikke alle disse i applikasjonen. Bildet under viser hvilke klasser og metoder som inngår i prosjektet GUI:

19 For å lage alt som ligger rundt vinduet som viser grafen, har vi brukt Microsoft Expression Blend. Dette er et designverktøy som har hjulpet oss med å lage det vi var ute etter.

20 Funksjonaliteten i laget Bildet viser hvordan GUI-en i applikasjonen ser ut. Den er delt opp i 7 felt: 1. Combobox - hvor brukeren kan velge å åpne ny eller legg til logg. 2. Checkbox - grafisk visning i prosent. 3. Treeview - som en liste over grupper og bilder. 4. Listbox - som inneholder en liste over logger som er lastet inn. 5. Listbox - som inneholder en liste over eventene som brukeren kan velge. 6. Dato-time-picker - valg av dato. 7. Button - for å tegne grafen som skal visualiseres. 8. Grafvinduet - viser grafen. 1. Combobox Denne delen av applikasjonen tar for seg funksjonaliteten der brukeren har mulighet og åpne en ny eller legge til en logg. Metoden som tar for seg dette er avbildet under:

21 Måten denne metoden jobber på, er at hvert valg i comboboxen er knyttet opp mot en indeks som går fra 0 til 2. De forskjellige valgene er avbildet under: Om bruker velger New log, vil metoden utføre det som ligger i scopet under indeks 0. Som vist i bildet har vi også et valg som heter Print. I denne indeksen, indeks 1, ligger det ingen funksjonalitet, men som er ment til bruk for videreutvikling av applikasjonen. Se kapittel 9. Videre utvikling av applikasjonen. 2. Precentage view I denne delen av applikasjonen får brukeren mulighet til å velge om grafen skal tegnes i prosent eller i antall forekomster. Ved å huke av denne boksen, tegnes grafen i prosent. Prosentvisning er implementert basert på antallet av den valgte forekomsten i forhold til Content Change. Som beskrevet i kapittel 2.1, er Content Change en event hvor det er et bildeskifte basert på en handling som brukeren har gjort for å navigere seg frem til ønsket område. Denne funksjonaliteten er implementert fordi ABB ønsket å kunne se hvordan de andre eventen ble brukt i forhold til Content Change. Metoden som håndterer denne visninger er vist på bildet under:

22 Variabelen, percentage, er i utgangspunket satt til å være false. Når brukeren huker av checkboxen, blir variabelen satt til true, og kode i scopet vil bli utført. Utregningen blir lagt i variabelen percent, som videre blir lagt til hver gruppe som ligger i arrayet grouplist []. 3. Treeview Denne delen av applikasjonen tar for seg brukerens valg av grupper og underliggende bilder som ønskes visualisert. Her har vi valgt å bruke en treeview med checkboxer. Bildet under viser hvordan treeviewen ser ut for gruppe 02 og gruppens underliggende bilder: Implementering av treeview Treeview implementeres ved at det blir laget en tomt view, som blir bundet til et datasett. View uten innhold er vist på bildet under: Deretter lages det et datasett som blir bundet til den tomme viewet. Utførelsen av dette er vist i metodeforeløpet under. Tree er navnet vi har gikk viewet. DataSet grupperbilder;

23 grupperbilder = lagetreeviewinnhold(); Tree.DataContext = grupperbilder; Her blir det først opprettet et datasett. Deretter legges det innholdet som befinner seg i metoden lagetreeviewinnhold, til dette datasettet. Helt til slutt legges dette datasettet inn i viewet. Metodegangen i dette krever at applikasjonen henter ut oppsettet som kommer fra DB.cs klassen sin metode getgruppetable. Bildet under viser hvordan dette er utført: Business Logikk Layer

24 I metoden getgruppetable, lages det datasettet som viewet blir bundet til. Her blir først gruppetabellen laget, parent table, og deretter bildetabellen laget, child table. For å skape relasjon mellom hvilke bilder som tilhører hvilken gruppe, blir de bundet sammen ved hjelp av gruppe ID-en. Treeviewen er implementert med checkboxer for å visualisere hvilket valg som er utført. Her er det 4 metoder som er involvert i om boksene er checked eller uncheck. Disse er listet opp i bilder under: Treeviewen oppdaterer seg ved å lytte til verdien huketav i datasettet. Dette blir kontrollert fra UserControl som befinner seg i XAML filen til klassen ColumnsWithColor.caml.cs. UserControl er en egendefinert kontroller som bestemmer treeviewen sitt utseende og oppførsler. Under viser et utsnitt fra kodens som lytter til verdien huketav i UserControl:

25 Når brukeren klikker på en av checkboxene blir det gjort en kall på metoden checkbox_checked som håndterer handlingen som skal utføres. Bildet under viser innhold i denne metoden: Metoden jobber opp mot en indeks på 3 verdier som er definert i metoden getgruppetable, og setter indeksen i plass 3 til true. Indeksen vises i bildet under: Når brukeren velger gruppe 02 vil alle bildene som er tilhører gruppen også bli huket av. 4. Listbox - logger Denne delen av applikasjonen gir en oversikt over hvilke logger som er lastet inn i databasen. Metoden som ligger bak denne funksjonaliteten vises i bildet under:

26 Hver gang brukeren velger og enten åpne en ny logg eller legge til en ny logg, blir det gjort et kall på denne metoden. Metoden sletter først alt som er listet opp av logger, for deretter å lage en ny liste som inneholder det som er av logger i databasen. 5. Listbox - eventer Dette vinduet inneholder en liste over eventer som brukeren velger for visualiseringen. Alle disse er definert i et array, som vist i bildet under: Alle disse elementene i eventarrayet blir knyttet opp mot en indeks som forteller om de er markert eller ikke. Som default er denne indeksen satt til markert. Hver gang et av eventene blir klikket på, blir det gjort et kall på denne metoden: Metoden løper igjennom listen av eventer og oppdaterer indeksen til eventen når brukeren utfører et valg. 6. Dato-time-picker For at brukeren skal kunne velge hvilke tidspunkt som skal visualiseres er det implementert en datovelger. For å oppnå dette har vi benyttes oss av AvalonControlsLibrary, som er et sett med WPF kontroller for valg av dato og tidspunkt. Bildet under viser hvordan denne komponenten ser ut:

27 Den metoden som håndterer det som er valgt av dato, er metoden som er vist under. Den lagerer dato til i variablen datotil, og dato fra i variablen datofra. Når brukene trykker på Draw graph - knappen, blir det gjort en kall på settvalgtdato metoden, som resulterer i et intervall for visualiseringen. 7. Button - "Draw Graph Dette er en knapp som bekrefter det som er gjort av valg i applikasjonen. Når knappen blir trykket på er det to metoder som blir valgt: I disse to metodene blir det gjort kall på de verdiene som skal bli visualisert i grafvindet. Dette inneholder hvilke grupper og bilder som er valgt, eventer og tidsintervall. Det blir også gjort kall på metoden vist under: Denne metoden sjekker jevnlig om metoden spreadamountcontentchangetogroup er ferdig med å legge verdier i de forskjellige gruppene. Om den ikke er ferdig vil den vise et vindu, som informerer om at brukeren må vente, Please wait. 8. Grafvinduet Denne delen av applikasjonen tar for seg tegning av graf. Vinduet er bygget opp ved hjelp av WPF toolkit, som gir oss tilgang til forskjellig forhåndsdefinerte visualiseringer. I denne

28 applikasjonen har vi benyttet av oss av en av klassene som heter ColumnsWithColor, som gir oss en grafisk fremstilling av verdiene i form av histogrammer. Det er to metoder som er involvert i tegning av grafen. Den ene definerer grafens utseende og den andre hvilke verdi/høyde grafen skal ha. Innholdet i metoden som definerer grafen er vist i bildet under: Som vi det ut av metoden får hvert histogram tildelt et gruppenavn og en farge. Om vi ser på den første linjen, får det første histogrammet gruppenavnet 02 med farge brun. Alle disse gruppene blir lagt i en dynamisk kolleksjon med navn ObservableCollection. Bildet under viser hvordan denne er opprettet: Innholdet i metoden som henter ut verdiene som skal representerer hvert histogram, er vist i bildet under:

29 Denne metoden går igjennom den dynamiske kolleksjonen og legger til det som er av eventens forekomst. 2.5 Brukergrensesnitt Applikasjonen inneholder mye funksjonalitet, som gjør at det kreves en nok så høy oppløsning for å unngå scrolling. Anbefalt oppløsning er på 1250 x 800 piksler og et perspektiv på 16:9. For å unngå at brukeren av applikasjonen skal bli sliten i øynene har vi brukt så få farger som mulig. Brukergrensesnittet gjenspeiler det som er av funksjonalitet i applikasjonen. Det er lett å forstå hva som er mulig å utføre og hvordan dette gjøres med knapper og vinduer som har forklarende navn. For lettere og kunne forstå hva som er av funksjonalitet under hver komponent i applikasjonen, er det implementert en tooltip. Denne gjør at brukeren kan legge musepilen over en komponent, hvor det da vil komme opp et lite vindu som forklarer hva som er funksjonaliteten. Under vises et bilde av et av de informasjonsvinduene som vises for brukeren:

30 Bilder viser informasjonsvinduet som dukker opp når brukeren legger musepilen over vinduet med listen av grupper og underliggende bilder. Det kan være vanskelig å se hvilken verdi som kommer from av grafen som tegnes. For å øke brukergrensesnittet er det også her implementert tooltip. Bruker kan legge musepilen over et av histogrammene som resulterer i at en nøyaktig verdi dukker opp i et nytt vindu. Bildet under viser hvordan dette blir synlig for brukeren: Applikasjonen gir også tilbakemeldinger på hva som utføres, med vinduer som forklarer hva som skjer. Vi har valgt å bruke dette da det kan ta lang tid å laste inn en stor logg og å tegne grafen. Figuren under viser hvordan vi har valgt å gjøre dette:

31 2.6 Database Relasjonsdiagram Tabellbeskrivelse Informasjon fra loggen Denne tabellen blir brukt til å lagre all informasjon som blir hentet ut fra loggfilen. Datatypene for de forsjellige attributtene vises i figuren under:

32 Informasjon om gruppene Tabellen brukes til å lagre informasjon om de forskjellige gruppene. Datatypene til de forskjellige attributtene er vist i figuren under: Bilde og gruppe identifisering Tabellen brukes til å koble bildet med sin tilhørende gruppe. Datatypene til de forskjellige attributtene er vist i figuren under: 2.7 Bruk av tråder I applikasjonen har vi tatt i bruk tråder for å kunne fordele ressurser på oppgaver som kjøres samtidig. Dette er implementert for å kunne åpne en ny fil, for at verdier skal fordeles i hvert histogram og for å slette alle verdiene i databasen. Når brukeren åpner ny logg medfører dette at databasen må slettes før ny data skal fordeles i de forskjellige kolonnene. Her blir det opprettet tre tråden i tillegg til hovedtråden. Hovedtråden er den tråden som applikasjonen kjører som default. Den ene tråden håndterer metoden som sletter databasen, den andre metoden som skal lese den nye loggfilen og den siste metoden legger verdier i de forskjellige gruppene. Bildet under viser hvilke metoder de tre trådene setter i gang:

33 Disse tre metodene befinner seg i hver sin klasse. deletedatabasen () befinner seg i klassen DB.cs, readfromfile (string filename) befinner seg i klassen Parser.cs og spreadamountcontetchangetogroups () befinner seg i klassen ColumnsWithColor.cs. Trådene blir opprettet i klassen ColumnsWithColor.xaml.cs. Bildet av kode under viser hvordan vi oppretter tråden som håndterer metoden readfromfile : Denne metoden tar i mot en parameter i form av en streng som inneholder navnet på loggen som skal leses av parseren. Bildet under viser hvordan den andre tråden opprettes: Når denne tråden aktiveres håndterer den sletting av databasen. For å kunne legge inn nye verdier i databasen er metoden avhengig av at databasen er tom. Her er det ikke et behov å ta hensyn til at slettråden ikke blir ferdig før leseloggtråden er ferdig, fordi slettetråden har en meget kort utføringstid og leseloggtråden har en veldig lang utføringstid. Den siste tråden som er implementert er tråden som håndterer metoden som legger til det antallet verdier som skal ligges i de forskjellige histogrammene. Bildet under viser hvordan denne tråden opprettes:

34 2.8 Videreutvikling av applikasjonen Kildekode Kildekoden er pakket i en.zip fil som inneholder alle nødvendige prosjektfiler. Kildekoden til applikasjonen eies av ABB Norway Utviklingsplattform Applikasjonen er utviklet i Visual Studio 2008, så det kreves at videreutviklingen blir implementert på denne utviklingsplattformen på en PC som kjører Microsoft Windows operativsystem. Det kreves også at Visual Studio Service Pack 1 er installert. Dette fordi applikasjonen krever oppkobling til en server. Databasen er krever en SQL databasemotor Forslag til videreutvikling Flere grafiske fremstillinger Ved å utvide presentasjonslaget og utnytte seg av flere av de ferdigutviklende klassene i WPF toolkit, kan applikasjonen implementeres med flere visuelle fremstillinger av verdiene som befinner seg i databasen. Det kan være lettere å finne det brukeren av applikasjonen er ute etter, ved å få en annen grafisk fremstilling av verdiene enn det som er implementert. Vi har faner med 2 forslag til andre grafiske fremstillinger. Bildet under viser denne fanen: Som bilder viser er det her to ekstra visualiseringer som vi mener er et godt alternativ til den visualiseringen som allerede er implementert. Disse to er Inverted Axis og TreeMap Introduction. Bildet under viser Inverted Axis fanens innhold:

35 Grunnen til at vi har foreslått denne for fremtidig utvikling er at den er god å bruke til å se hvordan en gruppe eller et bilde utvikler seg over tid. Om forekomsten har en økende, synkende eller lik utvikling. Bildet under viser det andre forslaget vi foreslår, TreeMap Introduction :

36 Dette forslaget er tatt med på det grunnlag av at det er enkelt å se hva som er den mest fremtredene forekomsten. Vi mener at denne visualiseringen hovedsakelig gjelder for fremstillinger som inneholder mange elementer. Valg av logg Applikasjonen er laget med en liste som informerer hvilke logger som ligger i databasen, slik bildet viser under: Her hadde det vært en god funksjonalitet å kunne velge de loggene som brukeren skulle ønske å visualisere. Slik applikasjonen er implementert i dag, er visualiseringen et resultat av samtlige logger som ligger i databasen. Printing av grafvinduet Det ville vært en god funksjonalitet at brukeren kunne skrevet ut grafen som ble tegnet, så applikasjonen er laget med dette valget i comboboxen. Bildet under viser dette valget: Ved å trykke på dette valgalternativet kommer det frem et vindu som ber brukeren velge hvilke printer og egenskaper for utskriften. Bildet under viser dette vinduet:

37 Dette er så lagt applikasjonen er implementert, da det ikke er blitt beskrevet i kode hva som skal skrives ut. Vi mener dette hadde vært en god kvalitet for brukeren å kunne skrive ut grafen, for lettere og kunne diskutere det som befinner seg av innhold i utskriften. Lagre til fil Ved videre utvikling kan det være ønskelig å kunne lagre grafen og de verdiene som ligger i vært histogram. Slider og checkboxer Per dags dato er det implementert datobokser hvor bruker velger perioden som ønskes å visualisere. Her kan en fremtidig utvikling forbedre brukervennligheten ved at lengden av perioden kan velges i form av en slider, og at det blir brukt checkboxer for om perioden skal vises i minutter, timer, dager, uker, måneder og år. Vi har laget en modell av denne ideen som vises i bildet under: Bruk av farger En faktor som kan gjør visualiseringen enkel er ved bruk av farger. Om det som er visualisert har samme farge som for eksempel checkboxen til gruppen eller bildet, vil det være enkelt å

38 se hva som hører til hva. Videre er det en ide å knytte hyppigheten til forekomsten i for av prosent eller antall. Vi har laget en modell som viser denne ideen som videreutvikling av applikasjonen. Bildet under viser denne modellen: I denne modellen kan brukeren enkelt se hva som er visualisert og forekomstene, ved bruk av farger. Spesifisere søket Databasen er bygget opp med flere kolonner enn det applikasjonen per dags dato bruker. Baktanken med disse feltene er mulighetene for å kunne spesifisere visualiseringen. De kolonnene som gjør dette mulig ligger i tabellen Actions, og har navnet maskin, pid og thread. Ved å legge inn flere valgmuligheter for brukeren, kan søket spesifiseres ned vil hvilken maskin, pid og thread visualiseringen skal vise. Tidsdifferanse i databasen Det er en kolonne til som ikke er i bruk slik applikasjonen er implementert i dag. Denne er tatt med etter ønsker fra ABB, som er interessert i å finne brukermønstre og navigeringsstier til brukeren. Ved å benytte seg av andre visualiseringer enn den som er implementert i dag, kan

39 denne kolonnen tas i bruk. Den kan for eksempel knyttes opp mot den visualiseringen som heter Inverted Axis som legger i fane 2.