D4 Books Et offline håndbogs system Esben Boe Nielsen Kongens Lyngby 2010 IMM-B.Eng-2010-07
Technical University of Denmark Informatics and Mathematical Modelling Building 321, DK-2800 Kongens Lyngby, Denmark Phone +45 45253351, Fax +45 45882673 reception@imm.dtu.dk www.imm.dtu.dk
Forord Denne rapport er resultatet af det afsluttende eksamensprojekt på Diplom IT på Danmarks Tekniske Universitet. Den er udført i tidrummet den 9. november 2009 til 22. marts 2010. Formålet med opgaven er at vise den studerendes kompetencer og færdigheder inden for softwareudvikling, herunder analyse, design, implementering og test. Projektet udføres i samarbejde med D4 Enterprise Solutions. Rapporten er underlagt DTUs standardaftale for Diplom- og Kandidateksamensprojekter. iii
Indhold Forord iii 1 Indledning 1 2 Projektbeskrivelse 3 2.1 Motivation................................... 3 2.2 D4 Books................................... 4 2.3 Arbejdsmetode................................ 4 Unified process................................ 4 Backup og versionering........................... 5 Tidsplan.................................... 5 3 Analyse 7 3.1 D4 InfoNet.................................. 7 D4 Handbooks................................ 7 Tilgang til data i D4 Handbooks...................... 9 3.2 Systemsammenhæng............................. 9 3.3 Use Cases................................... 11 3.4 Supplerende Kravspecifikation....................... 21 Generel Beskrivelse.............................. 21 Specifikke krav................................ 21 4 Design 23 4.1 Overordnet design.............................. 23 Format på håndbøger............................. 24 iv
INDHOLD v 4.2 Web Service.................................. 24 Hent håndbogsliste.............................. 25 Hent håndbog................................. 25 4.3 Klient...................................... 25 Softwarearkitektur.............................. 25 GUI....................................... 26 Forretningslogik................................ 28 Data....................................... 28 5 Implementering 31 5.1 Web Service.................................. 32 Hent håndbogsliste.............................. 33 Hent håndbog................................. 35 5.2 Klient...................................... 36 Softwarearkitektur.............................. 36 GUI....................................... 37 Forretningslogik................................ 41 Data....................................... 43 6 Test 45 6.1 Tilføj site.................................... 45 6.2 Håndbogsliste................................. 46 6.3 Hent Håndbog................................. 46 6.4 Åben en håndbog............................... 47 6.5 Supplerende Kravspecifikation....................... 47 Brugerkarakteristika............................. 47 Brugervenlighed............................... 47 Begrænsninger................................. 48 Fejlhåndtering................................. 48 Performance.................................. 48 7 Konklusion 49 7.1 Udviklingsmuligheder............................ 50 A Eksempler på lister 51 B Grafik 55 C Screenshots 57 D CD 65
KAPITEL 1 Indledning Mange virksomhedder har i dag et ønske om at samle virksomhedens kollektive viden ét sted. Dette gøres ud fra et ønske om let tilgang til viden om forskellige aspekter af virksomhedens forretningsområde. Ofte benytter virksomheder sig af en web baseret løsning, når de skal konsolidere denne viden. Men når mere og mere af en virksomheds viden bliver digitaliseret på virksomhedens interne netværk opstår der et problem for de medarbejdere, hvis arbejde består i at køre rundt til kunder. Det problem der opstår er, at medarbejderen ikke har mulighed for at tilgå de nødvendige informationer, hvis han ikke har adgang til virksomhedens netværk, når han eller hun er ude hos en kunde. En løsning på dette problem er at have papirversioner af de nødvendige dokumenter med ud til kunden. Det er dog ikke optimalt for en sælger eller konsulent at skulle holde styr på, om disse papirversioner er opdaterede i forhold til det online system, hvor dokumenter kan blive ændret flere gange om dagen. D4 Enterprise Solutions leverer et webbaseret system kaldet D4 InfoNet, der blandt andet kan udføre opgaven med at konsolidere en virksomheds viden. I dette system er det muligt for en virksomhed at oprette og vedligeholde f.eks. manualer, interne procedure eller produkt-kataloger. D4 Enterprise Solutions har fået flere forespørgelser fra nuværende og mulige kun- 1
2 KAPITEL 1. INDLEDNING der om muligheden for at lave offline udgaver af informationerne i systemet. Derfor ønsker D4 Enterprise Solutions at der implementeres en prototype på en application, der kan vise, at det kan lade sig gøre at generere offline udgaver af informationer i D4 InfoNet og fremstille disse for brugeren på en måde, der er både let og intuitativ. Den udviklede prototype viser, at det er muligt at lave en offline præsentation af informationerne i D4 InfoNet og endda vise dem på en måde,der ligner den oprindelige online udgave. Programmet er udviklet i Visual Studio 2008,.NET Framework 2.0 og det er skrevet i C#. Derudover er der implementeret en web service, der fungerer som en generator af informationerne til offline brug. Program og web service fremstår som en prototype og der mangler derfor en del udvikling inden disse er produktionsklar. Udover den implementerede funktionalitet har D4 Enterprise Solutions modtaget forslag fra interesserede kunder om funktioner, der ville være brugbare for dem i en produktionsklar udgave.
KAPITEL 2 Projektbeskrivelse 2.1 Motivation D4 Enterprise Solutions leverer web baserede kvalitetsstyrings og vidensdelings værktøjer til virksomheder, kommuner og regioner i Danmark. Hjertet i dette kvalitets system, kaldet D4 InfoNet, er et modul til opbygining og visning af håndbøger og manualer ved navn D4 Handbooks. I dette modul har mange af virksomhedens kunder samlet store dele af deres kollektive viden om deres forretning. Der er imidlertid opstået et behov for at kunne tilgå dele af disse informationer også når der ikke kan oprettes direkte kontakt til den server, hvor informationen befinder sig. Det kan være at en sælger eller en konsulent befinder sig et sted, hvor der ikke findes en internetforbindelse, eller at virksomheden slet ikke tillader forbindelse udefra til deres intranet. Eller det kan være, at en ansat kun har mulighed for at tilgå informationerne på en langsom og dyr mobil forbindelse. I disse tilfælde kan muligheden for at kunne hente disse informationer ned som en lokal version være til stor hjælp for D4 s kunder. Det er derfor blevet besluttet at lave en sådan løsning. Løsningen skal hedde "D4 Books"og ikke bare gøre det muligt at hente informationerne ned, men også vise dem på en sådan måde, at det ligner den online udgave. 3
4 KAPITEL 2. PROJEKTBESKRIVELSE 2.2 D4 Books Formålet med D4 Books er ikke at flytte den fulde funktionalitet af det eksisterende system, men at give virksomhedens kunder en alternativ indgang til visningen af informationer i systemet, når brugerne befinder sig uden for kundens eget net eller helt uden net. Det skal derfor være muligt at hente alt den information, som brugeren har adgang til online, ned i et lokalt format og vise det for brugeren, uden at denne skal holde styr på en masse filer selv. 2.3 Arbejdsmetode Udviklingen af virksomhedens produkter sker som regel på foranledning af ønsker fra kunder. Selv om virksomheden selv benytter den software der udvikles, er det som regel kunders ønsker, der danner grundlag for den udvikling der finder sted. Det gælder dog kun delvist for dette projekt, da der kun er tale om en prototype, som skal videreudvikles med input fra interesseret kunder. Derfor er det foreløbige produkt udtænkt af virksomheds vejlederen og den studerende. Selvom virksomheden ikke til dagligt benytter sig af en bestemt udviklings metode, er det alligevel valgt at benytte sig af den meget brugte metode Unified Process 1 (UP) til dette projekt. Unified process Unified Process (UP) er en meget brugt udviklingsmetode til objektorienteret softwareudvikling. UP benytter sproget Unified Modeling Language 2 (UML) til at beskrive hvordan en given ting skal udvikles. UP består af fire udviklingsfaser: Inception, Elaboration, Construction og Transition. Alle faser er iterative. I inceptionsfasen belyses de generelle ideer og krav til systemet. I denne fase udarbejdes use cases over de forskellige krav. Inceptionsfasen danner beslutningsgrundlag for, om der skal forsættes med projektet eller om det skal forkastes. Desuden er det grundlag for en løs tidsestimering. I elaborationsfasen fastlægges de endelige krav til systemet, og en arkitektur vælges. Herunder færdiggøres analyse og design af systemet. Der bør desuden udvikles de vigtigste dele af systemet, ud fra tidligere use cases, for at give et endeligt billede af, 1 http://da.wikipedia.org/wiki/unified_process 2 http://en.wikipedia.org/wiki/unified_modeling_language
2.3. ARBEJDSMETODE 5 om projektet stadigt er muligt at udføre. I konstruktionsfasen implementeres det endelige system. Det er i denne fase hvor mindre vigtig funktionallitet udvikles. Desuden udføres der løbende tests mens udviklingen foregår, så eventuelle fejl kan fanges. Dokumentation og manualer påbegyndes også i denne fase. Transitionen bruges til betatest samt aflevering til slutbrugeren. Enkelte fejl kan findes her og skal i såfald rettes i denne fase. Der bliver ikke tilføjet ny funktionallitet i denne fase. Backup og versionering Alt udvikling af løsningen gemmes i virksomhedens Microsoft Visual SourceSafe 3 versionerings løsning. Det er i denne løsning at samtlige af virksomhedens projekter bliver versioneret. Der bliver taget daglige offsite backups af projekterne i SourceSafe. Tidsplan UP principperne vil ikke bliver overholdt fuldt ud i dette projekt, da projektet har en så relativ kort tidsfrist og da det er et solo projekt. Der vil kun blive plads til én iteration i tidsplanen, hvor der normalt vil være flere. Der vil dog stadig være mulighed for at fange fejl og ændre disse undervejs, selvom der kun er en iteration. Tidsplanen er tidligt i projektet estimeret vha. en procentsats for hvert større område. Inddelingen kan ses i figur 2.1. Senere i projektet er der lagt en mere fast tidsplan. Til dette er der benyttet et Gantt diagram som kan ses i figur 2.2 og 2.3. 3 http://en.wikipedia.org/wiki/microsoft_visual_sourcesafe
6 KAPITEL 2. PROJEKTBESKRIVELSE Figur 2.1: Estimeret arbejdsbyrde per område Figur 2.2: Tidsplan - Gantt Figur 2.3: Tidsplan - Datoer
KAPITEL 3 Analyse 3.1 D4 InfoNet D4 InfoNet er et vidensstyringssystem udformet som en webløsning. Systemet består af 8 moduler, der hver især dække forskellige behov. Det er et af disse moduler, D4 Handbooks, som D4 Books gør brug af for at udføre sin funktion. Systemet er udviklet i asp og asp.net, og gør brug af Microsoft Internet Information Server (IIS). I denne rapport vil en installation af D4 InfoNet blive betegnet som et site. D4 Handbooks D4 Handbooks er et modul i før nævnte D4 InfoNet. Dette modul bruges til udarbejdelse og publicering af håndbøger. Disse håndbøger kan f.eks. være manualer, proces beskrivelser eller ligende. En håndbog består af dokumenter, der kan inddeles i kapitler og under kapitler. Disse dokumenter kan endvidere opdeles i niveauer, som f.eks. styrings-, processog værktøjs-niveau. 7
8 KAPITEL 3. ANALYSE Håndbog En Håndbog i D4 Handbooks består af en indholdsfortegnelse og en række dokumenter. Dokumenterne er i indholdsfortegnelsen indelt i kapitler og under kapitler. Et dokument kan indeholde tekst, billeder tabeller og flows, som laves i et andet modul i D4 InfoNet, og meget mere. Det også mulig et skrive at dokument i Microsoft Word og importere dette som et dokument i en håndbog, eller at redigere et dokument direkte i Microsoft Word. Der ud over er det muligt at tilføje bilag til et dokument i form af word- eller pdf-dokumenter eller andre fil typer. Et dokument kan desuden opdeles i sektioner, som kan redigeres enkeltvis. Det er også muligt at sætte et bilag på et dokument til at være et såkaldt "primær bilag", der gør at dette bilag bliver vist i stedet for selve dokumentet. Brugerne af en håndbog i systemet sættes på dokument niveau. Dvs, at en bruger godt kan have adgang til dele af en håndbog, men brugeren får ikke vist links til de dokumenter han eller hun ikke har adgang til. I toppen af hvert dokument findes en header med informationer om dokumentet. Disse informationer er: Overskrift: Dokumentets overskrift, som også vises i indholdsfortegnelsen. Dokumentansvarlige: Hvilke brugere af systemet, der er ansvarlige for at indholdet i dokumentet er korrekt. Det er også disse brugere, der modatager feedback om dokumentet. Dokumentbrugere: Hvilke brugere af systemet, som dokumentet er tiltænkt. Version: Et nummer, der viser hvilken version dokumentet er i. Dokumentnummer: Dokumentets nummer i indholdsfortegnelsen. Godkender: Den bruger, som har givet den endelige godkendelse af dokumentet. Niveau: Angiver hvilket niveau dokumentet befinder sig på. Når et dokument skal udgives i systemet kan det først sendes i høring hos andre brugere af systemet. Når hørings runden er overstået skal dokumentet til endelig godkendelse, inden det kan udgives til brug. Hjælpe funktioner For at gøre det muligt at hente en håndbog ned til offline brug, er der til et tidligere produkt lavet to funktioner til hjælp med dette. Disse to funktioner er lavet som to forskellige asp sider i håndbogs modulet. Den ene funktion generere en liste over håndbøger. Den anden generer en liste over dokumenter, formularer og bilag fra en bestemt håndbog.
3.2. SYSTEMSAMMENHÆNG 9 Håndbogsliste Listen af håndbøger indeholder både håndbogs id, håndbogens navn og dato for sidste opdatering. Listen er opbygget så der er en håndbog på hver linie og de forskellige informationer er opdelt med en pipe ( ). Informationerne om en håndbog er håndbogens id i håndbogs systemet, håndbogens navn, dato for sidste udgivelse af dokument og et tal, der indikerer om håndbogen er tvungen offline. Et eksempel på en håndbogsliste kan ses i bilag A.1 Dokumentliste Listen over dokumenter i en håndbog går ud fra samme princip som håndbogslisten (3.1). Hver linie indeholder informationer om entiteter i håndbogen opdelt med en pipe ( ). Informationerne om entiteterne i håndbogen er en dens adresse, id og sti til muligt primær bilag og en dato for sidste ændring. Denne liste indholder alle dokumenter, flows, billeder og bilag i håndbogen. Et eksempel på en dokumentliste kan ses i bilag A.2 Tilgang til data i D4 Handbooks Klient programmet skal ikke have direkte adgang til data i D4 Handbooks. Håndbøger der skal bruges i klient programmet vil blive genereret af en web service på server siden og hentet af klient programmet som en pakket fil. På den måde reduceres mængden af data, der skal sendes over netværket. Web servicen der benyttes til at generere håndbøger skal også udvikles. 3.2 Systemsammenhæng For at vise hvordan den overordnede systemsammenhæng skal se ud er figur 3.1 udviklet. Web serveren i figurer repræsenterer det oprindelige D4 Handbooks system. Selv om at web servicen kommer til at køre på den samme web server som det oprindelige system bliver de vist hver for sig, da web servicen skal kommunikerer med web serveren.
10 KAPITEL 3. ANALYSE Figur 3.1: Overordnet systemsammenhæng
3.3. USE CASES 11 3.3 Use Cases I dette afsnit vil Use Cases for D4 Books blive beskrevet, hvis programmet ønskes færdigudviklet bør der laves use cases for alle de funktionaliteter, der ønskes lavet. Endvidere bør de følgende usecases udvides med alternative forløb, så de på bedst mulig måde beskriver hvordan programmet skal udføre de opgaver det er tiltænkt. Tabel 3.1: Tilføj et site til programmet Use Case Navn Tilføj site At tilføje et site til programmet, som kan bruges til Mål at hente håndbøger fra Scope System Niveau Primær Prækonditioner Brugeren har startet programmet. Brugeren tilføjer et site til programmet og dette Success postkondition figuerer på listen over sites der kan benyttes. Programmet giver en fejlbesked og sitet tilføjes Fejl Postkondition ikke. Primær aktør Bruger Trigger En Bruger Handling. Trin Aktivitet 1 Brugeren vælger at tilføje et nyt site. 2 Programmet viser formen til at tilføje et site. 3 Brugeren indtaste informationer om sitet. Normalforløb 4 Programmet tilføjer sitet til databasen. 5 Programmet giver brugeren besked om at sitet er tilføjet. Trin Aktivitet Alternative Forløb Prioritet Høj Performance Max. 30 sekunder. Frekvens Middel Sekvensdiagram Figur C.6 5a Der opstår en fejl i programmet. 6a Programmet informerer brugeren om fejlen.
12 KAPITEL 3. ANALYSE Figur 3.2: Tilføj site til programmet Figur 3.3: Hent håndbogsliste sekvensdiagram
3.3. USE CASES 13 Tabel 3.2: Hent Håndbogsliste Use Case Navn Hent Håndbogsliste Mål Hente en liste over hvilke håndbøger brugeren kan hente fra sitet. Scope System Niveau Primær Prækonditioner Brugeren har startet programmet og har netværks adgang til det site ønskede site. Success postkondition Brugeren får vist en liste over de håndbøger der er tilgængelige på det ønskede site. Fejl Postkondition Programmet giver en fejlbesked og der vises ikke en liste med håndbøger. Primær aktør Bruger Trigger En Bruger Handling. Trin Aktivitet 1 Brugeren startet processen for at henter en håndbog. 2 Programmet viser en liste over sites i databasen. 3 Brugeren vælger det site, der ønskes benyttet. Normalforløb 4 Programmet forespørger webservicen på det pågældende site for en håndbogsliste. 5 Web servicen generere en håndbogsliste. 6 Web servicen retunere håndbogslisten til programmet. 7 Programmet viser håndbogslisten for brugeren. Trin Aktivitet 5a Web servicen kan ikke generer en håndbogsliste. Alternative Forløb 6a Web servicen meddeler programmet et der er opstået en fejl. 7a Programmet informerer brugeren om fejlen. Prioritet Høj Performance Max. 30 sekunder. Frekvens Middel Sekvensdiagram Figur 3.3
14 KAPITEL 3. ANALYSE Tabel 3.3: Hent Håndbog Use Case Navn Hent Håndbog Mål At hente en håndbog til brug i programmet. Scope System Niveau Primær Brugeren har startet programmet og har netværks Prækonditioner adgang til det site ønskede site. Brugeren får vist listen over håndbøger på sitet. Success postkondition Brugeren henter en håndbog som er tilpasset til burg i programmet. Fejl Postkondition Programmet viser en fejl besked til brugerne og håndbogen bliver ikke hentet. Primær aktør Bruger Trigger En Bruger Handling. Trin Aktivitet 1 Brugeren vælger den håndbog, der skal hentes, på listen med håndbøger. 2 Programmet forspørger web servicen om den Normalforløb vlagte håndbog. 3 Web servicen generer håndbogen. 4 Håndbogen retuneres til programmet. 5 Brugeren informeres om at håndbogen er hentet og klar til brug. Trin Aktivitet 3a Der opstår en fejl under når web servicen generer håndbogen. Alternative Forløb 4a Web servicen meddeler programmet et der er opstået en fejl. 5a Programmet informerer brugeren om fejlen. Prioritet Høj Performance Afhænger af størrelsen af den håndbog, der skal hentes. Frekvens Middel Sekvensdiagram Figur 3.4
3.3. USE CASES 15 Figur 3.4: Hent Håndbog sekvensdiagram Figur 3.5: Åben Håndbog sekvensdiagram
16 KAPITEL 3. ANALYSE Tabel 3.4: Åben Håndbog Use Case Navn Åben Håndbog Mål At åbne en håndbog i programmet. Scope System Niveau Primær Prækonditioner Brugeren har startet programmet, og har tidliger hentet en håndbog. Success postkondition Programmet åbner håndbogen korrekt så brugeren kan benytte de informationer den indeholder. Fejl Postkondition Programmet viser en fejl besked til brugerne og håndbogen bliver ikke åbnet. Primær aktør Bruger Trigger En Bruger Handling. Trin Aktivitet 1 Brugeren starter processen for at åbne en håndbog. 2 Programmet generer en liste af tilgængelige håndbøger. 3 Listen vises for brugeren. Normalforløb 4 Brugeren vælger den håndbog der skal åbnes. 5 Programmet klargør håndbogen. 6 Programmet viser håndbogen. 7 Programmet giver brugeren besked om, at håndbogen er klar til brug. Trin Aktivitet 2a Der opstår en fejl under en af programmets Alternative Forløb handlinger. 3a Programmet stopper handlinger og informerer brugeren om fejlen. Prioritet Høj Performance Afhænger af størrelsen af den håndbog, der skal hentes. Frekvens Ofte Sekvensdiaram Figur 3.5
3.3. USE CASES 17 Tabel 3.5: Slet Håndbog Use Case Navn Slet Håndbog Mål At slette en hentet håndbog i programmet. Scope System Niveau Primær Brugeren har startet programmet, og har tidliger Prækonditioner hentet en håndbog. Programmet sletter håndbogen asynkront, og Success postkondition informerer brugeren når processen er færdig. Programmet viser en fejl besked til brugerne og Fejl Postkondition håndbogen bliver ikke slettet. Primær aktør Bruger Trigger En Bruger Handling. Trin Aktivitet 1 Brugeren vælger den håndbog, der skal slettes. 2 Programmet sletter håndbogen. Normalforløb 3 Programmet giver brugeren besked om, at håndbogen er slettet. Trin Aktivitet 2a Der opstår en fejl under en af programmets handlinger. Alternative Forløb 3a Programmet stopper handlinger og informerer brugeren om fejlen. Prioritet Høj Performance <1 sekundt. Frekvens Lav Sekvensdiaram Figur 3.6 Figur 3.6: Slet Håndbog sekvensdiagram
18 KAPITEL 3. ANALYSE Tabel 3.6: Generer håndbogsliste (Web Service) Use Case Navn Generer håndbogsliste Mål At generer en liste af tilgængelige håndbøger på et site. Scope System Niveau Primær Prækonditioner Brugeren har startet programmet, og har forespurt et site om en håndbogsliste. Success postkondition Web Servicen generer en liste af tilgængelige håndbøger og retunerer den til programmet. Fejl Postkondition Web Servicen meddeler klienten at der er sket en fejl og brugeren får vist en fejlbesked. Primær aktør Bruger Trigger En Bruger Handling. Trin Aktivitet 1 Web Servicen får en forespørgelse om en håndbogsliste. 2 Web Servicen forespørger Web Serveren om sitet om listen af tilgængelige håndbøger. Normalforløb 3 Web Serveren svare Web Servicen med listen af tilgængelige håndbøger. 4 Web Servicen parser liste og opretter en liste af objekter. 5 Web Servicen retunerer listen af objekter til klienten. Trin Aktivitet 2a Der opstår en fejl endten ved Web Serveren eller Alternative Forløb Web Servicen. 3a Web Servicen retunerer en fejl besked. Prioritet Høj Performance 2-3 Sekunder. Afhænger af antallet af tilgængelige håndbøger. Frekvens Høj Sekvensdiaram Figur 3.7 Figur 3.7: Generer håndbogsliste
3.3. USE CASES 19 Tabel 3.7: Generer Håndbog (Web Service) Use Case Navn Generer Håndbog Mål At generer en håndbog som skal hentes. Scope System Niveau Primær Prækonditioner Brugeren har startet programmet, og har valgt en håndbog som skal hentes på en liste af håndbøger. Success postkondition Web Servicen generer generer håndbogen og retunerer den til programmet Fejl Postkondition Web Servicen meddeler programmet at der er sket en fejl og brugeren får vist en fejlbesked. Primær aktør Bruger Trigger En Bruger Handling. Trin Aktivitet 1 Web Servicen får en forespørgelse på en håndbog. 2 Web Servicen forespørger Web Serveren listen af dokumenter i håndbogen. 3 Web Serveren svare med listen af dokumenter. 4 Web Servicen parser liste. 5 Web Servicen forespørger Web Serveren om håndbogens indholdsfortegnelse. Normalforløb 6 Web Serveren retunerer indholdsfortegnelsen. 7 Web Servicen løber indholdsfortegnelsen igennem og ændre links. 8 Web Servicen forespørege Web Server om et dokument af gangen og løber svarene igennem. 9 Web Servicen henter CSS filer, Billeder og bilag. 10 Web Servicen pakker håndbogen til en fil og retunere denne til programmet. Trin Aktivitet 2a Der opstår en fejl endten ved Web Serveren. Alternative Forløb 3a Web Servicen forsætter med det næste element i håndbogen. Trin Aktivitet Alternative Forløb 2b Der opstår en fejl endten ved Web Servicen. 3b Web Servicen retunerer en fejl besked. Prioritet Høj Performance Afhænger af håndbogens størrelse. Frekvens Høj Sekvensdiaram Figur 3.8
20 KAPITEL 3. ANALYSE Figur 3.8: Generer en Håndbog
3.4. SUPPLERENDE KRAVSPECIFIKATION 21 3.4 Supplerende Kravspecifikation Den supplerende krav specifikation indeholder krav til produktet, som ikke er specificeret i use cases. Generel Beskrivelse Formålet med produktet er, at give bruger af D4 Handbooks muligheder for at kunne benytte vigtige informationer fra D4 Handbooks systemet, hvor de ikke har mulighed for at komme direkte i kontakt med den server, hvor D4 Handbooks løsningen er hosted på. Specifikke krav Brugerkarakteristika Brugeren af programmet er forventet at have kendskab til den online udgave af håndbøger i D4 Handbooks. Det er derfor vigtigt at programmets fremstilling af en håndbog afviger mindst muligt fra den online udgave af håndbogen. Brugervenlighed Da det ikke kan undgås at have funktioner i programmet, som ikke findes online, skal disse implementeres således, at de er intuative at bruge for brugeren. Bruger skal kunne benytte sig af det kendskab de har til D4 Handbooks, når de navigerer rundt i en håndbog i programmet. Begrænsninger Da programmet laver offline udgaver af online håndbøger, kan disse betegnes som øjebliks billeder af, hvordan håndbogen så ud på det tidspunkt hvor den blev hentet til offline brug. Det er derfor ikke ønskeligt at gøre det muligt for brugeren at redigere håndbøger offline, da dette kan kompromitere integriteten af data i håndbøger. Fejlhåndtering I programmet skal der være mulighed for at aktivere en log funktion. Denne funktion skal skrive relevante data om opstået fejl til et lokalt lager. Hver post i
22 KAPITEL 3. ANALYSE loggen skal være forsynet med et tidsstempel. Derudover skal loggen være forsynet med informationer om det system programmet kører på, samt versions nummer på evt. dll biblioteker programmet benytter sig af. Performance Afviklingen af programmet er ikke tidskritisk, fortsået på den måde, at lange svartider ikke ses som andet end et irritations moment. Ved visse operationer kan det dog ikke undgårs, at der forkommer lange svartider, da de vil afhænge kraftigt af størrelsen af den håndbog, som skal hentes eller åbnes. Programmeringsprog Program og web service udvikles i C# ved brug af.net Framework 2.0. Sproget er valgt ud fra tidligere erfaring og at programmeringsproget allerede benyttes i virksomheden. Systemkrav På brugerens pc Microsoft Windows XP eller nyere.net Framework 2.0 På serveren Windows Server 2000 eller nyere En installation af D4 Handbooks.Net Framework 2.0
KAPITEL 4 Design Designfasen tager udgangspunkt i analysen. Her vælges de endelige teknologier, som skal benyttes i projektet, og standarder for komponenter vælges. Da implementeringen har udgangspunkt i designfasen, er det vigtigt at designet er velovervejet og gennemarbejdet, så det kan gennemføres. 4.1 Overordnet design Da essensen af dette projekt er at lave en offline udgave af et web-site lægger det op til en klient-server løsning. For ikke at skulle opfinde den dybe tallerken igen, vælges det at server-siden skal være en web service, da en sådan kan hostes sammen med resten af det site, hvor der skal hentes data. 23
24 KAPITEL 4. DESIGN Format på håndbøger Det er valgt at "pakke"håndbøger til én fil af to grunde. Hovedsagen er, at det er langt lettere at holde styr på mange håndbøger hos klienten, hvis en fil svarer til en håndbog, da en håndbog potentielt kan indholde flere hunderede filer. Det samme gør sig gældende i processen for at hente håndbøger. Den anden grund er, at gøre størrelsen på en håndbog mindre, da det ikke er helt fjerntliggende, at en bruger kunne benytte sig af en mobil internet opkobling, hvor trafik betales pr. megabyte. Til sidst kan det tilføjes, at det samtidigt kan sænke tiden, det tager at hente en håndbog og dermed give en bedre brugeroplevelse. Det er valgt at håndbøgerne skal pakkes i cab formatet, som er en del af windows. 4.2 Web Service Web servicen skal stå for at gøre en håndbog klar til offline brug. Dette gøres ved at forespørge web serveren om hvert dokument i en håndbog og ændre den html kilde, der er i svaret fra web serveren. Ændringerne ligger hovedsageligt i at ændre referencen i link tags, så de ikke referer til web serveren, men i stedet til en fil, der ligger lokalt. Efter kilden er ændret, skal hvert dokument gemmes som en fil i en midlertidig folder på serveren, så hele håndbogen kan pakkes i en fil og sendes til klienten. Der skal benyttes Regular Expressions 1 (Regex) til at finde de forskellige tags i html kilden, der skal ændres. Det er vigtigt at links og f.eks. billed referencer bliver ændret på samme måde som de filer, der kommer ud af processen, bliver navngivet, da navigationen på klient-siden ellers ikke vil fungere. Grunden til at det er valgt at forespørge dokumenter på web serveren i stedet for at tilgå sitets database direkte, er dels at sitets udseende dermed kommer med, uden at det skal bygges op igen på klient-siden. Og dels at det dermed er muligt at udnytte den indbyggede brugerstyring i sitet, i stedet for at opbygge denne fra bunden igen. Dette gør også at klienten i bund og grund bliver til en specialiseret browser, hvor navigationen bliver bestemt af html filerne og ikke af procedure i klienten. For at web servicen kan finde de dokumenter som en håndbog indeholder, skal den hjælpefunktion i sitet (dokumentlisten), som blev beskrevet i analyseafsnit 3.1, benyttes. Web servicen skal også lave en liste over de håndbøger, som en bruger må hente. Til dette benyttes den anden hjælpefunktion i sitet (håndbogsliste). Web servicens to hoved opgaver er beskrevet i det følgende. 1 http://en.wikipedia.org/wiki/regular_expression
4.3. KLIENT 25 Hent håndbogsliste Denne funktion skal baseres på Generer håndbogsliste (Web Service) Use Casen 3.6. Det første der sker i processen for at hente en håndbog er, at klienten forespørger web servicen om en liste af tilgængelige håndbøger. Denne liste kan sitet generere for servicen med den førnævnte håndbogsliste 3.1. Til at dissekere denne liste skal der benyttes Regex. Da strukturen af denne liste er fast, kan der opbygges en Regex, der kan fange de forskellige informationer om en håndbog og sætte dem i en liste, som kan returneres til klienten. Hent håndbog Denne funktion skal baseres på Generer Håndbog (Web Service) Use Casen 3.7. Når brugeren af klienten har valgt den eller de håndbøger, der skal hentes, forespørger klienten web servicen om én håndbog ad gangen. Det første der skal ske, når web servicen får en forespørgsel på en håndbog er, at web servicen skal forespørge web serveren om dokument listen (3.1) for håndbogen. Denne liste skal også dissekeres med en Regex og informationerne om dokumenter i håndbogen skal gemmes i en liste, så de kan blive behandlet én ad gangen. Udover dokumenterne skal indholdsfortegnelsen for håndbogen også tages med. Hvert dokument, inklusiv indholdsfortegnelsen, skal hentes fra web serveren og løbes igennem med en række Regex s, for at ændre links, billed reference, CSS 2 og evt. bilag. Billeder, CSS og bilag skal tilføjes til en liste over filer, som skal med i håndbogen, ligesom links til dokumenter, der ikke er med i dokumentlisten bliver tilføjet. Alle disse elementer skal gemmes som filer midlertidigt på serveren indtil processen er færdig, hvorefter de pakkes i en fil, der skal sendes tilbage til klienten. 4.3 Klient Softwarearkitektur Det er valgt at opbygge klienten efter den klassiske 3-lags model, hvor softwaren inddeles i en lagstruktur, som skal muliggøre let udskiftning af enkelte komponenter. De tre lag er følgende: Graphical User Interface (GUI), Forretningslogik og Data. 2 Cascading style sheets: http://en.wikipedia.org/wiki/cascading_style_sheets
26 KAPITEL 4. DESIGN GUI - GUI laget skal indeholde alle visuelle elementer, der kan præsenteres for brugeren. Samtidigt skal eventuelle events, med forbindelse til det visuelle, inkluderes her. Forretningslogik - Forretningslogik laget skal indeholde al funktionalitet, der ikke har direkte indflydelse på GUI laget. Det er også forretningslogikken der sørger for kommunikation mellem data-laget og GUI laget. Det vil også være fra dette lag at kommunikationen til web servicen vil ske. Data - Data-laget vil indeholde forbindelsen til programmets lokale database. Når andre dele af programmet skal bruge data fra databasen vil disse data blive repræsenteret af objekter, der findes i data-laget. Denne inddeling af programmet i tydeligt adskilte lag vil lette udviklingen af programmet og gøre det lettere at overskue programmets struktur. Samtidigt kan dette også gøre det nemmere, hvis en anden udvikler skal overtage koden, da koden bør blive overskuelig. Et diagram over modellen kan ses i figur 4.1. Figur 4.1: Tre-Lags Model GUI Det er gennem den grafiske brugergrænseflade at brugeren interagerer med programmet. Interaktionen foregår gennem knapper, menuer, lister, tekstbokse osv. Det er vigtigt at brugergrænsefladen er så overskuelig som muligt og at den er intuitiv at bruge for brugeren. I det følgende vil de vigtigste dele af brugergrænsefladen blive fastlagt. De forskellige dele af brugergrænsefladen vil
4.3. KLIENT 27 blive udviklet i hver deres Windows Form. I.NET 2.0 er en Windows Form stadard for at lave et nyt vindue på skærmen. En Form er i sig selv et tomt vindue, hvor man kan tilføje forskellige komponenter som dem, der er nævnt tidligere. Ud fra de Use Cases der er beskrevet i analyseafsnit 3.3 er følgende Forms nødvendige. Main - Skal være hoved Formen i programmet. Det er denne Form, som vises for brugeren når programmet starter. Fra denne Form skal det være muligt at tilgå de fleste andre Forms i programmet. Derudover er det i denne Form, at en håndbog bliver åbnet, og navigeres i. Site-liste - Baseret på Use Case: 3.2 Denne Form vises, når brugeren vælger at hente en håndbog. Den viser en liste for brugeren over de sites, der er tilføjet til programmet. Det skal være muligt at vælge ét site og gå videre i processen eller annullere processen. Bog-liste - Baseret på Use Case: 3.2 Denne Form vises, når brugeren har valgt et site at hente håndbøger fra. Den viser en liste over hvilke håndbøger, det er muligt for brugeren at hente fra det valgte site. Det skal være muligt at vælge én eller flere håndbøger der skal hentes, eller at stoppe processen. Åben håndbog - Baseret på Use Case: 3.4 Denne Form vises, når brugeren har valgt at åbne en håndbog. Den viser en liste over de håndbøger, der allerede er hentet. Listen skal være opdelt, så håndbøger vises under det site, som de er hentet fra. Det skal være muligt, at vælge én håndbog der åbnes, eller at stoppe. Opsætning - Ikke baseret på en Use Case. I denne Form er det muligt at ændre opsætningen af programmet, blandt andet de brugerinformationer, der benyttes til at hente håndbøger med. Denne Form kan være opdelt med faner for at adskille de forskellige områder af opsætningen. Manager - Ikke baseret på en Use Case. Fra denne Form skal det være muligt at få et overblik over hvilke site der er tilføjet til programmet og hvilke håndbøger, der er hentet fra disse sites. Der skal være mulighed for at slette både individuelle håndbøger (se Use Case 3.5) og hele sites samt redigere i informationer om sites. Add site - Ikke Baseret på en Use Case. Denne Form bruges til at tilføje et nyt site til brug i programmet. Det skal være muligt at indtaste en url til et site og et tilhørende navn, som bruges til at vise brugeren. Det skal ikke være muligt at tilføje et site med en url, som allerede findes i databasen.
28 KAPITEL 4. DESIGN De nævnte Forms er de vigtigste i forhold til programmets funktionalitet. Hvor det er nødvendigt at vise status- eller fejlbeskeder til brugeren, skal der benyttes dialog bokse. Der findes i.net en funktion til at skabe en dialog boks med tekst, men hvis det ønskes at give andre former for information, er denne ikke tilstrækkelige. Der skal derfor også udvikles en dialog boks til de formål hvor standard dialog boksen ikke vil være nok. Forretningslogik I dette afsnit bliver de forskellige elementer af forretningslogikken beskrevet. Hvordan den bagvedliggende implementering skal udføres vil ikke blive beskrevet nærmere i dette afsnit, da afsnittet har til formål at beskrive de enkelte elementer og hvordan disse interagerer med hinanden. Funktionaliteten tager udagangspunkt i de Use Cases, der er beskrevet i analyse afsnit 3.3. Kommunikation med web service Da programmet skal kommunikere med en web service for at hente håndbøger og da denne web sevice også skal udvikles i.net Framework 2.0, er det oplagt at benytte den funktionalitet, som er indbygget i.net Frameworket, til kommunikationen. Denne funktionalitet fungerer på den måde, at der tilføjes en såkaldt "web reference 3 "i Visual Studio, som så sørger for at generere kode til, at kalde de metoder som en web service stiller til rådighed. Som udgangspunkt vil den genererede kode ikke køre asynkront, men da det kan være en fordel at have de processer, som kommunikerer med web servicen, til at køre asynkront, skal denne kode muligvis modificeres. Håndbog håndtering Da håndbøger i systemet har form som pakkede filer, skal der være et modul til at håndtere udpakning og evt. pakning af disse. Data Det er datalaget der søger for adgang til programmets egen database. aspx 3 Om Web References på MSDN: http://msdn.microsoft.com/en-us/library/tydxdyw9.
4.3. KLIENT 29 Databasen Det er valgt at benytte en let vægtsdatabase til programmet kaldet SQLite 4. Det er en fuld relationel fil baseret database, det vil sige at den ikke skal køre som en server ligesom f.eks. MySQL eller Microsoft SQL server. En anden ting, som gør denne database velegnet er, at den i modsætning til f.eks. Microsoft Access, der også er en fil baseret database, ikke kræver en dataprovider installeret på systemet, men tilgår databasen direkte. Der har også været kigget på Microsoft Access, både i 2003 og 2007 udgaverne. De er begge blevet fravalgt, da der kræves en dataprovider i styresystemet for at kunne tilgå dem. For 2003 udgaven er denne dataprovider en del af Microsoft Data Access Components 5. Det lader dog til at Microsoft er ved at udfase dette komponent, da det ikke supporteres på udgaver af Windows nyere end Windows XP. For 2007 udgaven er dataprovideren en del af Office System 2007 eller Microsoft Access Database Engine. I SQLite er dataprovideren en del af det namespace, som benyttes til at tilgå databasen. Der vil blive benyttet en udgave af SQLite, der kan integreres direkte ind i.net Frameworket 6. Database Design I databasen skal der være følgende tabeller. Sites - Skal indeholde informationer om sites, som er tilføjet til programmet. De informationer, der gemmes er navnet på sitet, sitets url, stien til hvor håndbøger fra sitet gemmes, og en boolean værdi, der indikerer om der automatisk skal updateres fra dette site. Derudover skal der være et integer felt, som er det interne id på et site i programmet. Dette integer felt er også tabellens primær nøgle. Books - Skal indeholde informationer om de håndbåger, der er hentet med programmet. Informationer om en håndbog skal være håndbogens id på sitet, håndbogens navn, dato for hvornår håndbogen blev ændret på sitet og navnet på den fil som indeholder håndbogen. Derudover skal der også være et integer felt, som er den interne id for håndbogen og et felt med en reference til hvilke site, håndbogen er hentet fra. Doks - Skal indholde informationer om de dokumenter, der er i de håndbøger, der er hentet ned. Informationerne skal være det id et dokument har på sitet og det filnavn som dokumentet har i den hentede udgave. Derudover skal der være et internt id og en reference til hvilken håndbog dokumentet tilhører. 4 SQLite: http://www.sqlite.org/ 5 MDAC: http://en.wikipedia.org/wiki/microsoft_data_access_components 6 http://sqlite.phxsoftware.com/
30 KAPITEL 4. DESIGN Config - Skal indholde key/value par, med konfigurationer i programmet. Key skal være unikke, da der ikke må forekomme flere ens konfigurationer. Et diagram af designet kan ses i figur 4.2. Figur 4.2: Database model DataAccess Der skal laves et modul til kommunikation med databasen. Dette modul skal være en Singleton 7, da dette vil gøre at der kun er én indgang til databasen og dermed er der mindre risiko for at beskadige data i databasen. Modulet skal indeholde metoder til at indsætte, opdatere og slette sites og håndbøger. Data Objekter Der skal udvikles objekter, som kan repræsentere data i programmet. Når en ny håndbog hentes og skal tilføjes til databasen, skal forretningslogikken oprette et dataobjekt med informationerne om den nye håndbog, som DataAccess modulet kan benytte til at tilføje informationerne om den nye håndbog til databasen. Samtidigt skal disse objekter også benyttes i GUI laget. Når der skal vises en liste af håndbøger eller sites, skal det være en liste af disse objekter. Det er en fordel, da den nødvendige data dermed er til stede for at udføre de opgaver, en given liste er en del af. 7 Wiki: http://en.wikipedia.org/wiki/singleton_pattern
KAPITEL 5 Implementering I dette afsnit gennemgås de mest interessante funktioner i projektet. Kildekoden til D4 Books kan findes på den vedlagte cd. For at gøre afsnittet lettere læseligt, vil der enkelte steder i teksten være indsat kildekode. Dermed slipper læseren for at have adgang til kildekoden på læse tidspunktet. D4Books er udviklet i Visual Studio 2008 og skrevet i C#.NET 2.0. Afsnittet følger den samme struktur som designafsnitet (4). Dette er valg for at gøre afsnittet mere overskueligt for læseren, som dermed kan se, hvor de enkelte dele af designet er blevet implementeret. Det er vigtigt at understrege, at den implementerede udgave ikke er klar til produktion. For at det kan tages i brug i en virksomhed, skal det videreudvikles og færdiggøres. 31
32 KAPITEL 5. IMPLEMENTERING 5.1 Web Service Web servicen er opbygget i.net 2.0 og har derfor de samme karakteristika som ASP.NET 1, hvor der en layout del, med sidens layout og en codebehind del, hvor dynamisk funktionalitet kan implementeres. Forskellen fra asp.net er, at det eneste, der står i layout delen, er en reference til hvilken codebehind klasse der skal køres. I selve codebehind klassen implementeres så den funktionalitet, som servicen skal have i metoder, som er sat til at være en "WebMethod"som i eksemplet på figur 5.1. Web servicen er opbygget så indgangen til den er i selve web servicen, hvor hver metode laver metode kald over til metoder, der er implementeret som sit eget dll bibliotek. Det er gjort på denne måde, for at det er muligt at lave server-delen om på et andet tidspunkt uden for meget arbejde. Listing 5.1: Eksempel på en web metode 1 [ WebMethod] 2 public S t r i n g HalloWorld ( ) 3 { 4 return " Hallo World " ; 5 } Kommunikationen mellem klienten og web servicen benytter Simple Object Access Protocol 2 (SOAP), som er en protokol der udnytter XML formatet til at sende beskeder mellem en web service og en klient. På server siden bliver dette klaret automatisk af den web server, som web servicen er hosted på. Der er blevet udviklet metoder til at håndtere forespørgsler mellem web servicen og selve sitet på web serveren. Til dette gøres der brug af HttpWebRequests og HttpWebResponses. I klassen HttpRequestClass findes de førnævnte metoder. Metoderne er: GetHttpWebRequest - Som opretter et HttpWebRequest objekt. Derefter bliver brugerens credentials tilføjet til requesten så brugeren kan autentificeres over for sitet. Til sidst sættes "UserAgent", "Accept"og "AcceptCharset"http-headers og requestet returneres. GetRedirectUrl - Denne metode bruges til at finde ud af, om et request bliver redirected af web serveren. Hvis dette er tilfældet returneres den URL som redirected peger på. Samtidigt bliver cookien sat i en reference streng. 1 http://en.wikipedia.org/wiki/asp.net 2 http://en.wikipedia.org/wiki/soap
5.1. WEB SERVICE 33 GetFinalResponse - Denne metode bruges hvis det første request er blevet redirected. Der oprettes et nyt HttpWebRequest objekt vha. GetHttpWebRequest metoden, hvor redirect cookien er med og der fås et svar fra serveren. Html strengen tages ud af svaret og returneres. ValidateUser - Denne metode bruges hvis sitet ikke benytter Windows Authentication 3. metoden modtager en URL til sitet, en cookie streng og brugerens credentials. Den opretter nu et HttpWebRequest til sitets defualt side med brugerens brugernavn og password. Derefter returnerer den den autentificerede cookie streng. Hent håndbogsliste Når en bruger forespørger en håndbogsliste fra et site, er det denne metode der bliver benyttet. Først forespørge denne metode sitet om listen over tilgængelige håndbøger. Dette gøres ved hjælp af et HttpWebRequests objekt, som oprettes vha. førnævnte metode. Et eksempel kan ses på figur 5.2. I svaret findes håndbogslisten som en html streng. Listing 5.2: Eksempel på oprettelese og brug af et HttpWebRequest 1 HttpWebRequest r e q u e s t = Generator. HttpRequestClass. GetHttpWebRequest ( p_url + "/D4Doc/book/ b o o k l i s t. asp ", p_url, cred, new System. C o l l e c t i o n s. S p e c i a l i z e d. NameValueCollection ( ) ) ; 2 3 request. AllowAutoRedirect = true ; 4 5 HttpWebResponse response = request. GetResponse ( ) as HttpWebResponse ; 6 7 StreamReader r e a d e r = new StreamReader ( response. GetResponseStream ( ), Encoding. UTF8) ; 8 9 S t r i n g htmlstring = reader. ReadToEnd ( ) ; Denne streng dissekteres med en Regex og informationerne om hver håndbog gemmes i structs, som tilføjes til en liste, som på figur 5.3. I forhold til at benytte streng operationer til at opdele strengen er en Regex meget mere effektiv, da, hvis regexen 3 http://en.wikipedia.org/wiki/integrated_windows_authentication
34 KAPITEL 5. IMPLEMENTERING er udformet rigtigt, da der kun kommer det med, der er brug for og output har de typer, som er defineret. Dermed kan det let parses over i andre datatyper, som f.eks. integers eller datetime. Når listen er parset igennem retuneres den til kliente. Listing 5.3: Eksempel på brug af Regex 1 // Create regex 2 Regex reg = new Regex (@" (?:\ < br \>) (? < bookid>\d+) \ (?< bookname >. *? ) \ (?< date >[\d\ \:\s ] * ) \ (?< req >\d ) ", RegexOptions. CultureInvariant RegexOptions. IgnoreCase ) ; 3 4 // Find matches in s t r i n g 5 Match match = reg. Match ( htmlstring ) ; 6 7 // While there are matches l e f t 8 while ( match. Success ) 9 { 10 // New BookData s t r u c t 11 BookData book = new BookData ( ) ; 12 13 // Add i n t 14 book. BookId = I nt32. Parse ( match. Groups [ " bookid " ]. Value ) ; 15 16 // Add s t r i n g 17 book. BookName = match. Groups [ " bookname " ]. Value ; 18 19 // Add DataTime 20 book. Modified = DateTime. Parse ( match. Groups [ " date " ]. Value ) ; 21 22 // Add book to book l i s t. 23 books. add ( book ) ; 24 25 // Go t o next match. 26 match = match. NextMatch ( ) ; 27 }
5.1. WEB SERVICE 35 Hent håndbog Når klienten forespørger en håndbog, starter denne funktion med at forespørge sitet om listen over indholdet i håndbogen. Når denne er modtaget løbes den igennem med en Regex og det indholdet gemmes i en variabel, som kan tilgårs fra andre metoder i web servicen. Når dette er gjort, bliver indholdsfortegnelsen hentet og links bliver ændret ved at løbe den igennem med en Regex. Dette gøres af den samme metode som også løber dokumenter igennem, for at ændre links, for at sørge for at links ændres på samme måde. Når indholdsfortegnelsen er færdig, hentes dokumenterne ét ad gangen og bliver gennem løbet med metoden til at ændre links, men også af metoder, som ændrer referencer til CSS filer, billeder og bilag. Hvis der findes links, css filer, billeder eller bilag i dokumenterne, som ikke findes i den oprindelige liste over dokumenter, tilføjes disse til listen og bliver taget med. Når alle dokumenterne er hentet bliver css filer, billeder og bilag hentet. Når dokumentet er gennemløbet bliver dette gemt i en midlertidig folder på serveren. Der er implementeret en metode til dette, som igen sørger for at dokumenter får navne, der stemmer overens med den måde som links til dokumentet blev ændret. Til sidst bliver det hele pakket sammen i en cab-fil, og flyttet til en bestemt mappe på serveren. Navnet på filen bliver returneret til programmet, der downloader filen. Denne ændring er foretaget, da det gør programmets memory footprint mindre, når en håndbog bliver hentet. Hvis dette var blevet implementeret på den måde det er beskrevet i design afsnittet 4.2, ville det betyde, at håndbogs filen skulle holdes i hukommelsen, indtil det hele var overført til programmet, hvor det så kunne skrives til harddisken. Da håndbøger med bilag kan blive relativt store, selv når de er pakkede, ville dette kræve, at der var store mængder hukommelse til rådighed hver gang, der skulle hentes en håndbog. Da dette ikke nødvendigvis kan garanteres, blev det valgt at ændre fremgangsmåden. Det er valgt at benytte et tredjeparts bibliotek ved navn CabLib.dll 4. Dette bibliotek er opensource og må bruges kommercielt. Det fungerer som en wrapper til Microsofts egen cab compression implementering, som er en del af windows, men som ikke er en del af.net Frameworket. Denne dll-fil vil være en del af både klienten og web servicen. 4 http://www.codeproject.com/kb/files/cabcompressextract.aspx
36 KAPITEL 5. IMPLEMENTERING 5.2 Klient Klienten er udviklet som et Windows Forms 5 program i.net Framework 2.0. Implementeringen af programmet er sket fra bunden af, forstået på den måde, at der er startet med at implementere det nederste lag (data-laget), da dette lag bliver brugt af de andre lag. Softwarearkitektur Programmet er opbygget efter 3-lags modellen. De tre lag er, som nævnt i design afsnittet 4.3, GUI, Forretningslogik og data. For at gøre disse tre lag mere tydelige i programmet er det valgt at give dem hver deres under namespace. I logiklaget er der endvidere lavet endnu et namespace for de klasser der bliver kørt som tråde i baggrunden, da de netop har dét til fælles. Det er forsøgt at vise, hvor de forskellige klasser befinder sig i lagdelingen på figur B.1. Singleton Det er valgt at implementere nogle moduler i programmet, hvor der kun må eksistere et ad gange, som Singleton. Det betyder, at man fra ethvert sted i programmet kan forespørge på en instans af objektet og få det samme som alle andre. En Singleton implementeres ved at have en offentlig statisk konstruktør og en privat dynamisk konstruktør. Desuden holdes en statisk reference til det dynamisk oprettede objekt. Når der senere forespørges efter objektet, returneres referencen til det samme objekt, som blev oprettet tidligere. Et eksempel på en Singleton kan ses i figur 5.4. Listing 5.4: Eksempel på en Singleton 1 // S t a t i c Constructor 2 public s t a t i c D4BControl ( ) 3 { 4 } 5 6 // P r i v a t e Constructor 7 private D4BControl ( ) 8 { 9 } 5 http://en.wikipedia.org/wiki/windows_forms
5.2. KLIENT 37 10 11 ///<summery> 12 /// Returns the i n s t a n c e of <see c r e f ="D4Books. D4BLogic. D4BControl " >. 13 ///</summery> 14 public s t a t i c D4BControl GetInstance ( ) 15 { 16 return m_instance ; 17 } 18 19 // Reference 20 private s t a t i c readonly D4BControl m_instance = new D4BControl ( ) ; Asynkrone opgaver Operationer som tager lang tid at køre kan få den grafiske brugerflade til at hænge. For at sørge for at dette ikke sker, er det valgt at sådan operationer skal køre asynkront. På den måde kan hovedtråden servicere den grafiske brugerflade mens de tunge operationer kører i baggrunden. Det er dermed også muligt at give information om, hvor langt en bagved liggende operation er nået. Til dette formål er det valgt at benytte et komponent i.net Frameworket ved navn BackgroundWorker 6. Det er valgt at benytte dette komponent, fordi det er let at integrere i en windows applikation, da komponentet benytter events til at håndtere asynkrone resultater og rapportere status. En BackgroundWorker vil altid rejse sin RunWorkerCompleted event, når den er færdig. Også selv om den bliver stoppet undervejs af en exception. Det er muligt at returnere objekter til den metode. som håndterer RunWorkerCompleted eventen vha. de EventArgs, der er i den rejste event. Udover Result propertien i disse EventArgs er der også en properti med evt. Exceptions og en som indikerer om Workeren blev annulleret ved navn Cancelled. Result og Cancelled skal sættes manuelt i koden i modsætning til Error, som bliver sat automatisk af Workeren når der forekommer en exception, der ikke bliver håndteret. GUI Den grafiske brugerflade er implementeret i Visual Studio 2008. Alle elementer, der bruges i den grafiske brugerflade, er standardkomponenter fra.net 2.0 Frameworket, med undtagelse af ét, som er blevet modificeret vha. nedarvning og at override 6 http://msdn.microsoft.com/en-us/library/8xs8549b.aspx
38 KAPITEL 5. IMPLEMENTERING de metoder, der skulle modificeres. Der er implementeret grafiske visninger (Forms), som følger den oversigt over GUI, der er beskrevet i designafsnit 4.3. Derudover er der implementeret en Form, som bruges til at vise brugeren hvor langt en bagvedliggende processor, f.eks. at åbne en håndbog, er nået. Alle grafiske visninger er udviklet vha. Visual Studios indbyggede drag and drop editor. Og alle interaktioner med brugeren foregår vha. events. En event kan udløses af en handlig, f.eks. et tryk på en knap eller et valg af et element i en liste. I forbindelse med fejl, vil der blive vist en fejlmeddelelse på engelsk, i fo rm af en MessageBox. Teksten i fejlmeddelelsen vil tydelig beskrive i hvilken process fejlen opstod, samt den meddelelse som fulgte med fejlen. De fleste fejl vil blive håndteret af programmet og vil blot afslutte den igangværende process eller give brugeren en valgmulighed. Da den nuværende implementering er en prototype, kan der dog opstå uforudsete og uhåndterede fejl. Disse kan få programmet til at afslutte helt og præsentere brugeren for en fejlmeddelelse fra operativsystemet. Denne meddelelse vil i så fald forekomme på det sprog, som operativsystemet nu engang bruger. For at holde størrelsen af hoved Formen (D4BMainForm) nede er det valgt at lade de events, som har med navigationen i og imellem de to WebBrowser komponenter at gøre, blive håndteret i en anden klasse som er en del af forretningslogikken (D4BWebBrowserNavigation). Det forventes at disse event handlers på sigt vil blive meget store, når der bliver tilføjet mere funktionalitet til programmet. En stor del af de implementerede Forms giver brugeren et valg. Dette valg bliver brugt i andre processor i programmet. Det er derfor vigtigt at disse valg bliver registeret ordentligt. Til dette benyttes en indbygget funktion i Forms, som gør at en Form returnere et DialogResult, når de lukkes. Ud fra dette DialogResult er det muligt for programmet at se udfaldet af det valg, brugeren er blivet stillet overfor. Dette gøres ved at sætte Formens DialogResult i event handlern på de forskellig knapper på en Form, som på figur 5.5. Listing 5.5: Eksempel på Ok knap event handler 1 /// <summary> 2 /// Handels the c l i c k event on the Ok <see c r e f =" System. Windows. Forms. Button "/ >. 3 /// </summary> 4 /// <param name=" p_sender ">The sender <see c r e f =" System. Object "/>.</param> 5 /// <param name=" p_eventargs">the <see c r e f =" System. EventArgs "/ >. </param>
5.2. KLIENT 39 6 private void OkButtonClick ( o b j e c t p_sender, EventArgs p_eventargs ) 7 { 8 // Set forms DialogResult 9 t h i s. DialogResult = DialogResult.OK; 10 // Close form 11 t h i s. Close ( ) ; 12 } I dette eksempel vil Formen lukke og returnere DialogResultet til det sted hvor den blev åbnet fra. Et eksempel på at håndtere et DialogResult når en Form lukker kan ses i figur 5.6. Listing 5.6: Eksempel på håndtering af DialogResult 1 i f ( form. ShowDialog ( t h i s ) == DialogResult.OK) 2 { 3 s t r i n g s i t e U r l = form. Controls [ " m_urltextbox " ]. Text ; 4 s t r i n g sitename = form. Controls [ "m_nametextbox" ]. Text ; D4BListBox Det førnævnte modificerede komponent er en ListBox. For at kunne vise en liste over alle sites i databasen og de tilhørende håndbøger i samme ListBox, var det nødvendigt at modificere den måde, som et ListBox komponent tegner sit indhold på. Måden som listen skal vises på er, at navnet på et site vises først med fed skrift og understreget. Derefter vises navnene på samtlige håndbøger der er hentet fra det site med normal skrift, men indrykket med en tabulator i forhold til sitet. Dette bliver gjort ved at lave en klasse som extender et normalt ListBox komponent. I denne klasse bliver ListBoxens metode til at tegne elementer overridet, som kan ses i figur 5.7. Listing 5.7: Override af ListBox OnDrawItem event handler 1 /// <summary> 2 /// Override of <see c r e f ="Sytem. Windows. Forms. ListBox "/> c o n t r o l s 3 /// OnDrawItem event. 4 /// </summary>
40 KAPITEL 5. IMPLEMENTERING 5 /// <param name=" p_eventargs">the <see c r e f =" System. Windows. Forms. DrawItemEventArgs"/ >. </param> 6 protected override void OnDrawItem ( DrawItemEventArgs p_eventargs ) 7 { 8 // Draw Background 9 p_eventargs. DrawBackground ( ) ; 10 11 // I f the ListBox has items to draw. 12 i f ( p_eventargs. Index >= 0 && t h i s. Items. Count > 0) 13 { 14 // Brush 15 Brush brush ; 16 17 // Pen 18 Pen pen ; 19 20 // I f the current item i s the s e l e c t e d item s e t t e x t c o l o r to white 21 i f ( ( p_eventargs. S t a t e & DrawItemState. S e l e c t e d ) == DrawItemState. S e l e c t e d ) 22 { 23 brush = new SolidBrush ( Color. White ) ; 24 pen = new Pen ( brush, 2) ; 25 } 26 // Else use black t e x t c o l o r 27 else 28 { 29 brush = new SolidBrush ( Color. Black ) ; 30 pen = new Pen ( brush, 2) ; 31 } 32 33 // I f the current item i s a S i t e 34 i f ( t h i s. Items [ p_eventargs. Index ] i s D4BData. D4BSiteData ) 35 { 36 // Set font to Bold and Underlined 37 using ( Font f o n t = new Font ( p_eventargs. Font, FontStyle. Bold FontStyle. Underline ) ) 38 { 39 // Draw Text. 40 p_eventargs. Graphics. DrawString ( ( t h i s. Items [ p_eventargs. Index ] as D4BData. D4BSiteData ).
5.2. KLIENT 41 ToString ( ), 41 font, brush, new PointF ( p_eventargs. Bounds. Left, p_eventargs. Bounds. Top ) ) ; 42 } 43 } 44 // Else i f the current item in a book 45 else i f ( t h i s. Items [ p_eventargs. Index ] i s D4BData. D4BBookData ) 46 { 47 // Draw t e x t with a unicode t a b u l a t o r value in f r o n t. 48 p_eventargs. Graphics. DrawString ( "\u3000 " + ( t h i s. Items [ p_eventargs. Index ] as D4BData. D4BBookData ). ToString ( ), 49 p_eventargs. Font, brush, new PointF ( p_eventargs. Bounds. Left, p_eventargs. Bounds. Top ) ) ; 50 } 51 } 52 // Draw Focus Retangle. 53 p_eventargs. DrawFocusRectangle ( ) ; 54 } Som det fremgår af figuren, vil denne ListBox kun tegne elementer hvis de er af typen D4BBookData eller D4BSiteData. Derfor er denne ListBox ikke anvendelig alle de steder, hvor der skal bruges en ListBox og det er derfor grunden til, at den kun bliver brugt på en Form, nemlig D4BOpenBookForm. På denne form er det nemlig nødvendigt at vise brugeren alle de håndbøger der er hentet og som kan åbnes og hvilke site de kommer fra. Forretningslogik Forretningslogikken i programmet ligger to steder. Dels i den kode fil som tilknyttes til hver Form, men hovedsageligt i klasserne i forretningslogik laget. Control Klassen D4BControl er hjertet i forretningslogikken. Det er denne klasse, der står for at håndtere det events fra GUI en, som starter de processor, der skal køre asynkront. Det er valgt at implementere denne klasse som en Singleton (se 5.2), da den gemmer referencer til de asynkrone processor, der bliver startet til forsekllige formål. Som eksempel, for at forklare hvad klassen foretager sig, benyttes processen
42 KAPITEL 5. IMPLEMENTERING til at åbne en håndbog, som kan ses i figur 5.8. Når brugeren har valgt en håndbog via GUI laget, rejses der en OpenBook event, der bliver håndteret af D4BControl klassen. Denne metode starte med at initialisere et objekt af klassen D4BOpenBookThread, som er den klasse, der indeholder koden til at åbne en bog. Derefter initialiseres det BackgroundWorker objekt, som håndterer det asynkrone arbjede. BackgroundWorker objektets DoWork, RunWorkerCompleted og ProgressChanged events får tildelt metoder til at håndtere disse events, når de bliver rejst. Når dette er gjort bliver workeren startet med et kald til RunWorkerAsync. Listing 5.8: OpenBook event handler 1 /// <summary> 2 /// Handles t h e open book evnet. 3 /// </summary> 4 /// <param name=" p_sender ">The sender <see c r e f =" System. Object "/>.</param> 5 /// <param name="p_book">the Book as a <see c r e f =" D4Books. D4BData. D4BBookData"/> o b j e c t </param> 6 public void OpenBook ( o b j e c t p_sender, D4BData. D4BBookData p_book ) 7 { 8 // Create an o b j e c t of the D4BOpenBookThread c l a s s. 9 D4BLogic. D4BThreading. D4BOpenBookThread threadobject = new D4Books. D4BLogic. D4BThreading. D4BOpenBookThread ( ) ; 10 11 // I n i t i l a l i z e the backgroundworker. 12 t h i s. m_openbookworker = new BackgroundWorker ( ) ; 13 14 // T e l l the worker i t can report progress. 15 t h i s. m_openbookworker. WorkerReportsProgress = true ; 16 17 // T e l l the worker i t can be cancled. 18 t h i s. m_openbookworker. WorkerSupportsCancellation = true ; 19 20 // Set the method the worker should execute. 21 t h i s. m_openbookworker. DoWork += new DoWorkEventHandler ( threadobject. Run) ; 22 23 // Set the method the worker executes when i t i s done. 24 t h i s. m_openbookworker. RunWorkerCompleted += new RunWorkerCompletedEventHandler ( ( p_sender as
5.2. KLIENT 43 D4BGui. D4BMainForm ). OpenBookThreadCompletedHandler ) ; 25 26 // Set the method t h a t the worker r e p o r t s progress to. 27 t h i s. m_openbookworker. ProgressChanged += new ProgressChangedEventHandler ( ( p_sender as D4BGui. D4BMainForm ). ThreadProgressChangeHandler ) ; 28 29 // S t a r t s the worker. 30 t h i s. m_openbookworker. RunWorkerAsync ( p_book ) ; 31 } Kommunikation med Web Servicen Til kommunikation med Web Servicen, benyttes en funktion i Visual Studio, som tilføjer en såkaldt Web Reference til projektet. Denne Web Reference er en reference til en web service, hvor Visual Studio læser beskrivelsen af denne og genererer et objekt, der kan bruges til at kalde de metoder, som findes i web servicen. Dette objekt har dog en statisk URL til den web service, som det har læst beskrivelsen fra, så det er nødvendigt at ændre denne dynamisk, når programmet skal tilgå en web service på et site. Det er valgt at implementers et modul ved navn D4BCommunication, som benytter Web Service objektet. Dette modul modtager URL en til det site, som brugeren har valgt eller den håndbog, som brugeren vil hente. Data I data-laget er der implementeret et DataAccess modul som står for kommunikation med databasen. Dette modul er opbygget som en Singleton, da det ønskes at alt tilgang til databasen sker på samme måde. Derudover giver dette mulighed for let at skifte databasen ud på et andet tidspunkt, da det bare er et modul, som skal skiftes. Selve databasens struktur er som det blev fastlagt i design afsnittet 4.3. Ud over DataAccess modulet er der blevet implementeret to data moduler som repræsenterer hhv. et site og en håndbog. Det er forsøgt at begrænse brugen af DataAccess modulet til disse to moduler, da det hovedsageligt er disse, der bliver brugt til at repræsentere data i programmet. Der er dog steder i forretningslogikken, hvor DataAccess modulet bliver tilgået direkte. Dette sker når en håndbog er blevet hentet og de dokumenter, som findes i håndbogen skal tilføjs til databasen. Der er ikke implementeret moduler til at repræsentere et dokument, da de ikke bruges
44 KAPITEL 5. IMPLEMENTERING nogle steder i programmet på nuværende tidspunkt. Det er dog valgt at have styr på hvilke dokumenter, der er hentet, da det forventes at blive brugt i funktionalitet, som bliver tilføjet på et senere tidspunkt. De to data moduler arver deres struktur fra en klasse i datalaget, ved navn D4BDataClass. Det er valgt at lave disse data moduler på denne måde, da det sikrer at data moduler i programmet kan benyttes på samme måde, uanset hvilke data de repræsenterer. Program konfiguration Da det er valgt at holde konfigurationen i databasen er der implementert et modul til at tilgå disse data. Dette modul er også implementeret som en Singleton. Modulet henter alle key-value par i databasens Config tabel og sætter dem ind i et Dictionary, når programmet starter. Det er så muligt at hente værdier ud af dette Dictionary ved at kende key en. Samtidigt kan der tilføjes nye key-value par til Dictionaryet dynamisk, så længe key en ikke findes allerede. Dette hjælper med til, at der ikke kommer dobbelt værdier for en konfiguration. Når der tilføjes et key-value par eller en value bliver opdateret, bliver disse gemt i databasen med det samme. På den måde er ændringer til konfigurationen i programmet gemt med det samme og konfigurationen skal ikke ændres igen, hvis programmet skulle lukkes ned af en alvorlig fejl.
KAPITEL 6 Test I dette afsnit udføres test af funktionaliteten i systemet. I denne test er det valgt at teste klienten og web servicen samlet. Testen udføres som en black box test og der noteres for hver test, hvad der testes, det forventede resultat og det faktiske resultat. For at en test kan anses som bestået, skal det forventede resultat og det faktiske resultat stemme overens. I slutningen af dette afsnit vil den supplerende kravspecifikation blive evalueret. Opstår der fejl vil disse blive beskrevet og forsøgt afklaret. Alle tests er udført på udviklingsmaskinen med Web Servicen kørende lokalt. Der skal derfor tages højde for, at overførsels hastigheden fra servicen til klienten ikke vil stemme overens med virkeligheden. 6.1 Tilføj site Test af at tilføje et site til programmet. 45
46 KAPITEL 6. TEST Tabel 6.1: Tilføj et site Test Handling Forventet resultat Faktisk resultat 1 Der tilføjes et site med en ikke før brugt URL og et navn. Sitet bliver tilføjet og kan ses på listen over sites. Som forventet 2 Der tilføjes et site uden URL, men med et navn. 3 Der tilføjes et site med URL, men uden et navn. 4 Der tilføjes et site uden navn og URL. 5 Der tilføjes et site, hvor der i forevejen findes et site med samme URL. Der vises en fejlbesked og sitet bliver ikke tilføjet. Der vises en fejlbesked og sitet bliver ikke tilføjet. Der vises en fejlbesked og sitet bliver ikke tilføjet. Der vises en fejlbesked og sitet bliver ikke tilføjet. Som forventet Som forventet Som forventet Som forventet 6.2 Håndbogsliste Test af at hente en håndbogsliste fra et site. Tabel 6.2: Hente en håndbogsliste Test Handling Forventet resultat Faktisk resultat 1 Der forsøges at hente Listen bliver hentet og Som forventet en håndbogsliste fra et vist. tilføjet site. 2 Der forsøges at hente en håndbogsliste fra et tilføjet site, men med forkerte bruger informationer. 3 Der forsøges at hente en håndbogsliste fra et tilføjet site, når der ikke er forbindelse til sitet. Der vises en fejlbesked og der bliver ikke vist en håndbogsliste. Der vises en fejlbesked og der bliver ikke vist en håndbogsliste. Som forventet Som forventet 6.3 Hent Håndbog Test af at hente en håndbog. Det er en forudsætning for denne test, at der er blevet hentet en håndbogsliste.
6.4. ÅBEN EN HÅNDBOG 47 Tabel 6.3: Hente en håndbog Test Handling Forventet resultat Faktisk resultat 1 Der forsøges at hente en håndbog. Håndbogen bliver hentet og programmet spørger, om brugeren vil åbne en Som forventet 2 Der forsøges at hente en håndbog, men forbindelsen til serveren forsvinder halvvejs. håndbog nu. Der vises en fejlbesked og håndbogen bliver ikke hentet. Som forventet 6.4 Åben en håndbog Test af at åbne en håndbog. Det er en forudsætning for denne test, at der er hentet en håndbog. Tabel 6.4: Åbne en håndbog Test Handling Forventet resultat Faktisk resultat 1 Der forsøges at åbne en Håndbogen bliver åbnet Som forventet håndbog. og håndbogen bliver vist. 2 Der forsøges at åbne en Der vises en fejlbesked Som forventet håndbog, hvis fil ikke og håndbogen bliver eksisterer længere. ikke åbnet. 6.5 Supplerende Kravspecifikation Brugerkarakteristika Punktet er opfyldt fuldt ud, da visningen af en offline håndbog sker alene med output fra det oprindelige håndbogs system. Brugervenlighed Selvom det er forsøgt at gøre programmet så brugervenligt som muligt, er der dog stadig undtagelser, som skal redesignes. En af disse er placeringen af funktionen til at tilføje et site.
48 KAPITEL 6. TEST Begrænsninger Dette punkt er overholdt fuldt ud. Der er ikke implementeret nogen funktionalitet, der gør det muligt for brugeren at redigere i håndbøger. Fejlhåndtering Dette punkt er delvist overholdt. Programmet giver fejlbeskeder, når fejl opstår, men der er ikke implementeret en log funktion i den nuværende version. Denne vil komme i en senerere version. Performance Dette punkt er overholdt, da lokale operationer forløber hurtigt. Der er dog stadig nogen ventetid, når der hentes håndbøger. Selv om dette ikke kan undgåes, kan det forsøges optimeret i senerer versioner.
KAPITEL 7 Konklusion Når en virksomhed benytter sig af digitale løsninger, for at konsolidere viden som manualer, procedure og produkt-kataloger, kan den havne i en situation, hvor medarbejdere, der udfører arbejdsopgaver hos virksomhedens kunder, ikke kan benytte sig af det digitale system. Derfor ønskede D4 Enterprise Solutions, at der blev udviklet en løsning, der kan benyttes til at hente information fra deres eksisterende vidensstyrings system og gemme lokalt til senere brug, når det ikke er muligt at komme i kontakt med det eksisterende system. Der er udviklet en prototype, der henter information fra D4 Handbooks, vha. en web service og gemmer det lokalt. Samtidig kan denne prototype også vise de gemte informationer på en måde, der ligner det oprindelige system. Prototypen fungerer efter hensigten og viser, at det er fuldt ud muligt at fremstille de ønskede informationer til offline brug. Samtidig er prototypen udviklet på en sådan måde, at den let kan videreudvikles. Testen viser at programmet fungerer og at det er muligt at arbejde videre på den nuværende model. 49
50 KAPITEL 7. KONKLUSION 7.1 Udviklingsmuligheder Da prototypen fungerer efter hensigten og de opstillede mål er nået, er det oplagt at undersøge, hvad der kræves for at færdigudvikle den. Følgende liste opsummerer nogle af de vigtigste punkter, der bør eller skal udvikles inden programmet er klar til brug. Optimering af web servicen - for at give en bedre brugeroplevelse skal det forsøges at optimere web servicen, så det tager kortere tid at hente en håndbog. Dette er vigtigt, da irritationsmomentet ved at vente på en håndbog bliver hentet, kan føre til utilfredshed med programmet og få brugere til at holde op med at bruge det. Implementering af søgefunktion - både i en enkelt håndbog og i alle hentede håndbøger, da dette er en meget anvendt måde at finde informationer i det online system. Implementering af Import/Export funktion - er et ønske fra flere af D4 s kunder. De ønsker at kunne generere en fælles håndbog og sende den til medarbejdere via mail. Samtidig skal modtageren have mulighed for at importere håndbogen i sin egen klient. Dybe links - Det er et ønske fra D4 s kunder, at have mulighed for at lave et link til et specifikt dokument i en håndbog i programmet. Kryptering af forbindelse - kryptering vha. standard https protokol vil kunne implementeres forholdsvis simpelt. Dette vil sikre data sendt mellem web servicen og klienten.
BILAG A Eksempler på lister Listing A.1: Eksempel på en håndbogsliste fra et site 1 <html> 2 <head> 3 < t i t l e >Håndbøger</ t i t l e > 4 </head> 5 <body> 6 Håndbøger 7 <br>20 A) Quality Manual 2007 10 07 1 9 : 1 2 : 5 8 0 8 <br>54 Auditplan 2009 09 21 1 6 : 1 2 : 1 7 0 9 <br>51 CARLO IKKE LÅST 2010 02 19 1 4 : 4 5 : 1 6 0 10 <br>45 CARLO VERSIONSLÅST 2010 03 17 1 1 : 3 9 : 3 3 0 11 <br>64 Helene Test 2010 02 18 1 2 : 2 0 : 2 0 0 12 <br>68 Helene Test A ( ikke l å s t ) 2010 03 18 1 2 : 0 1 : 1 3 0 13 <br>65 Helene Test uden k a p i t e l n r. 2010 01 25 1 4 : 5 6 : 5 4 0 14 <br>3 ISO Håndbog 2010 01 21 2 1 : 5 8 : 3 5 0 51
52 BILAG A. EKSEMPLER PÅ LISTER 15 <br>22 K l i n i k Ortopædkirurgisk 2009 01 17 2 1 : 4 3 : 0 6 0 16 <br>16 K v a l i t e t s s t y r i n g 2006 12 04 1 1 : 4 6 : 1 2 0 17 <br>24 Link Håndbog 2009 04 14 1 5 : 5 6 : 3 2 0 18 <br>4 Personalehåndbog 2010 01 23 2 3 : 3 5 : 5 3 0 19 <br>43 Production handbook 2010 02 10 1 0 : 5 4 : 2 6 0 20 <br>74 Savo_Håndbog_Øvelser 2010 03 11 1 0 : 3 2 : 1 0 0 21 <br>33 Simons Øvehåndbog 2010 01 11 1 5 : 0 9 : 5 6 0 22 <br>42 Test Visuel I d e n t i t e t 2009 04 07 1 3 : 5 9 : 4 0 0 23 <br>61 UK testbook 2009 12 21 1 3 : 4 2 : 4 5 0 24 <br>53 Øvehåndbog Dror 2009 09 21 1 0 : 5 2 : 1 2 0 25 </body> 26 </html>
53 Listing A.2: Eksempel på en dokumentliste fra et site 1 <html> 2 <head> 3 < t i t l e >content l i s t </ t i t l e > 4 </head> 5 <body> 6 <br>/d4doc/book/isodokument. asp?dokid=1 2004 05 17 1 4 : 1 3 : 3 6 7 <br>/d4doc/book/isodokument. asp?dokid=2 2004 05 17 1 4 : 1 3 : 3 6 8 <br>/d4doc/book/isodokument. asp?dokid=3 2004 05 17 1 4 : 1 3 : 3 6 9 <br>/d4doc/book/isodokument. asp?dokid=4 2004 05 17 1 4 : 1 3 : 3 6 10 <br>/d4doc/book/isodokument. asp?dokid=14 422: / d4doc/formularer/akos KALENDER 2006 PTRKMPHOK. x l s 2006 04 10 1 1 : 4 2 : 5 0 11 <br>/d4doc/book/isodokument. asp?dokid =15 2009 08 28 1 1 : 5 5 : 0 7 12 <br>/d4doc/book/isodokument. asp?dokid =16 2005 01 06 1 0 : 4 1 : 1 0 13 <br>/d4doc/book/isodokument. asp?dokid=17 405: / d4doc/formularer/d4 blokke. doc 2005 04 11 1 3 : 5 5 : 2 1 14 <br>/d4doc/book/isodokument. asp?dokid =18 2005 04 11 1 3 : 4 4 : 0 6 15 <br> 144: /D4Doc/formularer/GV/ L i s t e med r e l e v a n t l o v s t o f og standarder ver. 4. pdf 2000 03 14 0 0 : 0 0 : 0 0 16 <br> 145: /D4Doc/formularer/GV/ L i s t e med r e l e v a n t l o v s t o f og standarder ver. 4. pdf 2000 03 14 0 0 : 0 0 : 0 0 17 <br> 166: /d4doc/formularer/ a n s v a r s l i s t e. asp?bookid =3 2010 03 21 1 6 : 5 2 : 0 9 18 <br> 167: /d4doc/formularer/ v e r s i o n s l i s t e. asp 2010 03 21 1 6 : 5 2 : 0 9 19 <br> 172: /d4doc/formularer/ a n s v a r s l i s t e. asp?bookid =3 2010 03 21 1 6 : 5 2 : 0 9 20 <br> 176: /d4doc/formularer/forbedringsrapport ver. 1_2. pdf 21 <br> 187: /d4doc/formularer/ C h e c k l i s t e udd. af adm_2.doc
54 BILAG A. EKSEMPLER PÅ LISTER 22 <br> 191: /d4doc/formularer/ a n s v a r s l i s t e. asp?bookid =3 2010 03 21 1 6 : 5 2 : 0 9 23 <br> 192: /d4doc/formularer/forbedringsrapport ver. 1_2. pdf 24 <br> 193: /d4doc/formularer/testside1compact. pdf 25 <br> 276: /d4doc/formularer/ B i l l e d e ( 0 3 ) _c. jpg 26 <br> 277: /d4doc/formularer/ p s t e s t. pdf 27 <br> 279: /d4doc/formularer/ A n s t t e l s e s k o n t r a k t t i l s t i n e. doc 28 <br> 280: /d4doc/formularer/ B i l l e d e ( 0 3 ) _c. jpg 29 <br> 281: /d4doc/formularer/ p s t e s t. pdf 30 <br> 283: /d4doc/formularer/ p s t e s t. pdf 31 <br> 286: /d4doc/formularer/ B i l l e d e ( 0 3 ) _c_2. jpg 32 <br> 288: /d4doc/formularer/aktionsplan_1. doc 33 <br> 296: /d4doc/formularer/aktionsplan_1. doc 34 <br> : /d4doc/formularer/opdat_kort. asp?bookid=3& nye=0 2010 03 21 1 6 : 5 2 : 1 0 35 </body> 36 </html>
BILAG B Grafik 55
56 BILAG B. GRAFIK Figur B.1: Klient lagdeling
BILAG C Screenshots 57
58 BILAG C. SCREENSHOTS Figur C.1: Klient Hovedform
Figur C.2: Klient Hovedform når en håndbog er åben 59
60 BILAG C. SCREENSHOTS Figur C.3: BookManager form
Figur C.4: User options 61
62 BILAG C. SCREENSHOTS Figur C.5: Generalle options Figur C.6: Tilføj site form
63 Figur C.7: Progress form Figur C.8: Progress form når en bog åbnes Figur C.9: Håndbogs liste
64 BILAG C. SCREENSHOTS Figur C.10: Site liste Figur C.11: Liste af hentede håndbøger
BILAG D CD På vedlagte cd findes: Rapporten i pdf format Kildekode og eksekverbare filer til D4Books En test håndbog der kan åbnes i programmet Kildekode til D4BookGeneratorService 65