Sags- og dokumentstyringssystem

Transkript

1 Sags- og dokumentstyringssystem Daniel Lingberg Winther Kongens Lyngby 2009 IMM-B.Sc

2 Technical University of Denmark Informatics and Mathematical Modelling Building 321, DK-2800 Kongens Lyngby, Denmark Phone , Fax

3 Resumé Målet med denne opgave er at udvikle et Sags- og dokumentstyringssystem til håndtering af praktikforløbet for IT-studerende på Danmarks Tekniske Universitets Diplomingeniøruddannelse. Systemet skal overskueliggøre arbejdet med de studerende set fra koordinators og vejleders synsvinkel, samt forenkle praktikoprettelses- og praktikgodkendelsesprocessen for den studerende.

4 ii

5 Forord Denne rapport og det tilhørende produkt er udviklet i samarbejde med Institut for Informatik og Matematisk Modellering på Danmarks Tekniske Universitet, og samlet udgør det resultatet af et bachelorprojekt udført i perioden 9. marts til 10. august Rapporten forudsætter, at læseren har kendskab til almene procedurer mht. softwareudvikling, samt viden omkring objektorienteret programmering. Lyngby, August 2009 Daniel Lingberg Winther

6 iv

7 Indhold Resumé Forord i iii 1 Indledning 1 2 Kravspecifikation Krav til systemet Usecases Indsnævring og fravalg Design Layers Database Sikkerhed Funktioner DeadlineManager Implementering Database, Data Controls og Databinding Login og rettigheder Kryptering Upload og download af filer Konstanter Dataset

8 vi INDHOLD 5 Test Betatest/brugervenlighedstest Ordered unittest Udvidelsesmuligheder 47 7 Konklusion 49 A Flowdiagrammer 51 B Brugermanual 57 B.1 Manual for bruger B.2 Manual for administrator B.3 Opsætning B.4 Diverse C Business Case 85

9 Kapitel 1 Indledning På DTUs IT-uddannelse for Diplomingeniører skal den studerende et halvt år i praktik i en virksomhed, inden det afsluttende projekt skal skrives. Før denne praktikperiode kan påbegyndes, skal den studerende først være godkendt til at komme i praktik, og derefter skal den ønskede praktikvirksomhed godkendes af en praktikkoordinator. I dag foregår denne godkendelsesprocedure gennem indscannede dokumenter og korrespondance mellem den studerende, praktikassistent og praktikkoordinator. Denne metode er langsommelig, besværlig og svær at overskue for både studerende og koordinatorer. Der ønskes derfor et nyt system udviklet, der bedre er i stand til at håndtere de studerende og deres data under praktikperioden. Systemet skal give mulighed for korrespondance de involverede parter imellem, samt via eventstyring sørge for, at deadlines osv. overholdes.

10 2 Indledning

11 Kapitel 2 Kravspecifikation Der var fra projektets start, ikke opstillet en specifik liste over, hvilke krav der var til systemets funktionalitet og udformning. Udarbejdelse af en kravspecifikation har derfor været stærkt præget af kommunikationen med projektets vejledere, og som ved mange andre udviklingsprojekter, har kravene til systemet forandret sig sideløbende med implementeringen af dette. Overordnet ønskes der udviklet et selvstændigt system til håndtering af Diplomingeniør-studerende under deres praktikperiode. Administrationen følger i dag en nøje beskrevet vejledning ( Business Case ) 1, som bl.a. gør brug af DTUs eget system Campusnet og en række Word-dokumenter til håndtering af de studerendes data, dokumenter osv. Det udarbejdede system skal, så vidt muligt, forenkle denne proces, ved bl.a. at automatisere tidskrævende opgaver samt give et let overblik over de respektive projekter. 1 Se bilag C

12 4 Kravspecifikation 2.1 Krav til systemet Selve systemet ønskes implementeret som en webapplikation, der kan eksekveres fra enten en lokal server eller et eksternt webhotel. Specifikt skal systemet give følgende muligheder: oprette/redigere brugere - forskellige brugergrupper/roller. oprette/redigere projekter - praktikvirksomhed, praktikperiode, emne, beskrivelse osv. tilknytte brugere til de enkelte projekter. håndtere kommunikation mellem brugerne tilknyttet en sag (beskeder). oprette/redigere standardbeskeder til brug for praktikassistenter og praktikkoordinatorer. downloade standarddokumenter og uploade dem i udfyldt/underskrevet stand. eventstyring (automatiseret) - nye events, overholdelse af deadlines osv. notifikationer ved overskredne deadlines. låsning af et projekt og dets dokumenter/data. godkendelse af data/dokumenter samt hele projektet. let oversigt over projekt - udfyldte og manglende dokumenter samt kommende deadlines. 2.2 Usecases Usecases er gode til at give et overblik over, hvordan det er tiltænkt, at den enkelte bruger skal udføre en specifik opgave. Det er selvfølgelig ikke muligt at opstille usecases for alle tænkelige scenarier, men de følgende afsnit giver et overblik over de mest essentielle funktioner i systemet. I bilag A er indsat en række flowdiagrammer, der ligeledes giver et overblik over, hvorledes det er tiltænkt, at flowet i systemet skal være. Da systemets brugere er opdelt i forskellige grupper med forskellige rettigheder, er det nødvendigt at skelne imellem, om det er en studerende eller en administrator (praktikassistent eller praktikkoordinator), der udfører opgaven.

13 2.2 Usecases Oprettelse og godkendelse i systemet Aktører: Studerende (STU) Praktikassistent (PA) Systemet (S) Ønsket resultat: Den studerende oprettes i systemet og bliver godkendt til praktik. Fremgangsmåde: 1. STU navigerer til forsiden (login-siden) af systemet. 2. STU vælger at oprette ny bruger. 3. STU indtaster oplysninger om studienummer og password. 4. S sender en validerings- til den studerendes studi . 5. STU klikker på linket i den sendte S godkender og aktiverer bruger som Ikke godkendt bruger. 7. STU logger ind. 8. STU klikker på Add/edit data. 9. STU udfylder data og vælger at sende det ind til godkendelse. 10. S opretter event til alle PA. 11. PA logger ind. 12. PA klikker på event i liste over events. 13. S genererer overblik over brugerens indtastede data. 14. PA vælger at acceptere data, vælger standardbesked til nye brugere og accepterer. (a) PA accepterer ikke data. STU modtager besked om dette. S låser data op. Gå til S fjerner event fra PA og flytter STU til gruppen af accepterede brugere. 16. STU modtager standardmeddelelse og kan forsætte med at bruge systemet.

14 6 Kravspecifikation Oprettelse og godkendelse af 2 pers. projekt Aktører: 2 godkendte studerende (STU1 og STU2) Praktikkoordinator (PK) Systemet (S) Ønsket resultat: Et nyt projekt med 2 studerende bliver oprettet og praktikkoordinatoren godkender projektet. Fremgangsmåde: 1. STU1 logger ind. 2. STU1 klikker på Projekter. 3. STU1 klikker på det projekt som han/hun er tilknyttet. 4. S fremviser overblik over det tomme projekt. 5. STU1 vælger at udfylde data ang. praktikperioden. 6. STU1 udfylder kendt data. 7. Fra oversigtssiden vælger STU1 at tilføje en bruger og vælger den ønskede bruger i listen over godkendte brugere. 8. S opretter invitation/event til den nye bruger. 9. STU2 logger ind. 10. STU2 klikker på invitationen og får detaljer om projektet. 11. STU2 accepterer invitationen. 12. S tilføjer brugeren til projektet 13. PA logger ind. 14. STU1 eller STU2 udfylder resten af data ang. praktikperioden, og sender den til godkendelse. 15. S opretter event til alle PK. 16. PK logger ind. 17. PK klikker på event i liste over events. 18. S genererer overblik over de 2 studerendes praktikperiode. 19. PK vælger at acceptere data, vælger standardbesked til begge de studerende og accepterer. (a) PK accepterer ikke data. STU og STU2 modtager besked om dette. S låser projektdata op Gå til S fjerner event fra PK, låser de godkendte data og genererer nye deadlines. 21. STU1 og STU2 modtager standardmeddelelse og får nu mulighed for at indtaste yderligere informationer.

15 2.2 Usecases Kommunikation mellem brugere tilknyttet projekt Aktører: Studerende (STU) Praktikkoordinator (PK) Systemet (S) Ønsket resultat: PK stiller et spørgsmål til STU og STU svarer tilbage til PK Fremgangsmåde: 1. PK logger ind. 2. PK finder det enkelte projekt i listen over projekter. 3. PK klikker på Beskeder og bliver dirigeret til en oversigt over tråde han/hun deltager i. 4. PK vælger at oprette ny tråd. 5. PK skriver en titel til tråden og skriver en besked eller vælger en standardbesked. 6. PK vælger STU i oversigten af brugere i projektet og sender. (a) Titlen er allerede i brug i projektet. S giver besked om dette. PK ændrer titel og sender Gå til S opretter tråden med beskeden som første besked og tilknytter STU til den. 8. S opretter en event til STU ang. ny besked. 9. STU logger ind. 10. STU klikker på event ang. ny besked. 11. STU ser den nye besked og skriver svar i boks nederst i tråden. 12. S opretter beskeden i tråden, samt en event til PK ang. ny besked. 13. PK klikker på event ang. ny besked. 14. PK ser svar.

16 8 Kravspecifikation Oversigt over projekt Aktører: Praktikassistent (PK) Systemet (S) Ønsket resultat: PK finder et overblik over, hvilke data der er udfyldt, og hvilke dokumenter der er uploaded for et specifikt projekt. Fremgangsmåde: 1. PK logger ind. 2. PK finder det enkelte projekt i listen over projekter. 3. På projektets forside kan PK se hvilke deadlines der er udført, og hvilke der mangler. 4. PK vælger en oversigt over projektet. 5. PK ser en enkelt side, der giver mulighed for at downloade projektdetaljerne samt evt. uploadede filer. 6. PK klikker på Projekt detaljer. 7. S genererer en pdf-fil indeholdende de indtastede data til PK. 8. PK klikker på Event history. 9. S viser en oversigt over de væsentligste events i projektet. 2.3 Indsnævring og fravalg Den åbne kravspecifikation har ført til mange tanker mht. hvilke funktioner og muligheder, der skulle være implementeret i det færdige system. Det har dog været nødvendigt at indsnævre dette til en mængde, der er realistisk at nå at implementere for en enkelt person, på den relativt korte tid. Det var en mulighed at lade systemet gøre brug af det Central Authentication Service (CAS), som bl.a. Campusnet benytter til at verificere brugere. Dette kan være en fordel, idet brugerne allerede er oprettet og godkendt, med en forholdsvis begrænset mængde brugerdata. Dette ville dog gå ud over systemets selvstændighed, hvilket man skal overveje fordele og ulemper ved. Hvor vidt ikke godkendte brugere, der endnu ikke er tilknyttet et projekt, skal have mulighed for at kommunikere med praktikkoordinatorerne og praktikas-

17 2.3 Indsnævring og fravalg 9 sistenterne gennem systemet, var også et spørgsmål. Resultatet blev, at det udelukkende er muligt for administratoren at sende en besked ved afslag eller godkendelse af brugerens data, hvorfor 2-vejs kommunikation derfor må foregå uden om systemet, f.eks. via . Sletning af brugere og projekter virker ved første tanke som en logisk mulighed, men dette indebærer en række problemer og risici, idet en sletning af et projekt ved en fejl, nemt kan resultere i tab af data og dokumenter. Det er derfor ikke muligt at slette, men i stedet at fjerne brugere fra et projekt. Det samme er gældende ved sletning af en bruger, idet alle referencer til brugeren i systemet vil blive ugyldige. En bruger kan derfor deaktiveres men ikke slettes. De standarddokumenter, som brugeren og praktikvirksomheden skal udfylde kunne let udfyldes online. Dette giver dog et problem, idet dokumentet skal være underskrevet af personen der udfylder, hvorfor upload af et indscannet dokument er nødvendigt. Tidligere har s været brugt hyppigt som kommunikation mellem praktikkoordinatorer, praktikassistenter og studerende. Det var et mål at reducere dette, og i stedet lade kommunikationen foregå via systemet, hvor samtalerne er sporbare gennem den enkelte sag. -beskeder ved nye events, nye beskeder osv. er derfor blevet fravalgt.

18 10 Kravspecifikation

19 Kapitel 3 Design Det var fra opgavestillers side defineret, at systemet enten skulle udarbejdes i Java eller i ASP.NET. Idet udvikler har større erfaring med sidstnævnte udviklingsplatform, faldt valget naturligt på ASP.NET og det er derfor en logisk konsekvens, at Microsofts SQL Server benyttes til database. Systemet er udviklet med henblik på brugen af Microsoft SQL Server 2005 eller nyere. Systemet er forsøgt udviklet på en måde, der giver administratorerne så frie muligheder som muligt, hvorimod den studerende skal guides gennem forløbet. På denne måde reduceres risikoen for, at den studerende foretager sig utilsigtede handlinger, der besværliggør og forlænger processen.

20 12 Design 3.1 Layers Systemet tager udgangspunkt i Model - View - Control (MVC) arkitekturen. Dette betyder at koden er delt op i tre lag, der hver især varetager deres seperate opgaver. Idet systemet er udviklet i Microsofts ASP.NET, er en stor del af denne opdeling foretaget på forhånd, idet selve præsentations-laget bliver behandlet i.aspxfilerne, mens kontrol-laget bliver varetaget af den enkelte.aspx-fils tilhørende.cs-fil. Modellen er implementeret i separate.cs filer i et separat projekt (Business Logic Layer), hvilket er smart, idet det giver mulighed for, at andre projekter kan have referencer til det, og bl.a. gøre brug af dets funktioner. Ud over disse tre lag er der også implementeret et fjerde lag (Data Access Layer), hvilket har til opgave at forbinde applikationen med den tilhørende database (fig. 3.1). Figur 3.1: Arkitektur i lag En stor fordel ved at følge denne struktur er, som sagt, at andre projekter kan referere til separate dele af systemet, men især også, at den enkelte del kan redigeres eller omskrives, uden at det influerer på resten af systemet.

21 3.1 Layers Opbygning (UML) På figur 3.2 ses et simplificeret UML-diagram, der giver et overblik over, hvordan de forskellige klasser/moduler er forbundet. De enkelte dele vil blive gennemgået yderligere i de kommende afsnit. Figur 3.2: UML-diagram over systemets opbygning

22 14 Design Data Access Layer (DAL) Dette lag har til opgave at håndtere kommunikationen til og fra databasen. Det består hovedsageligt af et Dataset 1, der indeholder de fornødne TableAdapters 2 (fig. 3.3). Figur 3.3: Data Access Layer - Dataset 1 Samling af tabeller og adaptere der kommunikerer med databasen (se afsnit 4) 2 Samling af prædefinerede SQL-kald, der kan kaldes, som funktioner med argumenter

23 3.1 Layers Business Logic Layer (BLL) Business Logic Layer er et separat namespace, med en klasse ved navn BLL, der indeholder en lang række af metoder. Disse metoder udgør størstedelen af rygraden i systemet, idet næsten alle handlinger medfører et metodekald til BLL. BLL har en reference direkte til de TableAdapters som er oprettet i DAL, og har derfor, gennem simple metodekald til den enkelte TableAdapter, let adgang til at skrive og hente data fra databasen. Metoderne er opdelt i 8 forskellige sektioner: Userdata User management Events Projects Reporting Exam projects Deadlines Messages Metoderne er ret specifikke, mht deres funktionalitet i systemet, og derfor forsøges metoderne navngivet så sigende som muligt. Dette ses bl.a. i eksempler som GetUserDataByUserID(...) og RequieredDocumentsHasBeenUploaded(...). Derudover er alle metoder i BLL oprettet med et lille summary, der af bl.a. Visual Studio vises, når man refererer til metoden, og som derved giver overblik over hvad den enkelte metode gør. En stor del af disse metoder videresender dog bare de data, som metoderne fra DAL returnerer, og fungerer dermed udelukkende som mellemstation mellem databasen og kontrol-laget. Andre metoder her derimod mange funktioner, hvilket bl.a. er situationen ved en metode som ApproveInternship(int pid), der, udover at godkende praktikperiodens data, også låser disse data, opretter events og redigerer deadlines i det pågældende projekt.

24 16 Design Application Layer (UI) Grafik og brugervenlighed Hvad angår sidens grafiske opbygning, så er det forsøgt at gøre den så enkel og brugervenlig som muligt. Man vil ved første øjekast let kunne se, at opbygningen ligger tæt op ad Campusnet, hvilket er et bevidst valg, idet dette er med til at skabe sammenhæng og fuldstændighed DTUs systemer imellem. Samtidig er det med til at forbedre brugerens oplevelse, idet siden ikke forekommer ham/hende uvant, hvilket især bør være en fordel for de studerende, idet de ikke på forhånd har kendskab til det nye system. Som udgangspunkt benyttes kun elementer, der bør virke genkendelige for brugeren. Her menes bl.a. en vandret menustruktur i toppen af siden, brug af knapper, tekstfelter, dropdownlists osv. ved udfyldning og redigering af data, hyperlinks til navigation på siden og visning af data i lister og tabeller. Der er dermed ikke blevet benyttet smart og original grafik eller lignende. Det skal dog siges, at den grafiske fremstilling i dele af systemet har været prioriteret væsentligt lavere end bl.a. driftsikkerhed osv., hvorfor fejl og mangler i grafikken, eller afvigelser fra det før beskrevne, kan forekomme. Dette skulle dog på ingen måde have konsekvenser for systemets funktionalitet Masterpages Selve opbygningen af siden bygger på et såkaldt Masterpage, som er et koncept, der blev introduceret sammen med ASP.NET 2.0. Masterpages gør det muligt at bygge skabelon-baserede websider, ved først at designe en overordnet skabelon for websiden. Det væsentligste element på siden er et element kaldet ContentPlaceHolder. Dette element er en ramme, hvori den enkelte websides indhold bliver indsat. Som det ses på figur 3.4, så er banner, menu og selve sidens ramme oprettet i skabelonen. Ved oprettelse af en ny webside, har man så muligheden for at benytte den oprettede masterpage som skabelon, hvorved siden adopterer designet og bliver indsat i elementet ContentPlaceHolder.

25 3.1 Layers 17 Hvad angår menuen, så varierer denne alt efter hvilken gruppe brugeren er medlem af. Derfor benyttes et såkaldt LoginView, som er et ASP.NET kontrolelement, der er i stand til at ændre sit indhold, alt efter hvilken bruger eller hvilken type bruger, der er logget ind. Figur 3.4: Global masterpage for systemet

26 18 Design 3.2 Database På figur 3.5 ses et ER-diagram over de databaser, som systemet gør brug af. Til styring af brugerne, deres login og roller, benyttes Microsofts brugerstyringsservice Membership, der er en del af ASP.NET. Membership kan enten benyttes til at tjekke for login gennem en ActiveDirectoryMembershipProvider, der validerer brugeren op imod Active Directory, eller via en SqlMembershipProvider, der validerer op imod en SQL server. For at undgå at skulle opsætte Active Directory, benytter systemet SqlMembershipProvider, hvilket kræver at databasen har en række prædefinerede tabeller, som kan benyttes til at håndtere brugerne. For at undgå forvirring, er disse tabeller samlet i en enkelt entity kaldet ASP.NET Membership and Role services i ER-diagrammet i figur 3.5. Ud over de prædefinerede tabeller, er nogle af de mest signifikante tabeller: UserData - Alle informationer om en godkendt bruger. Project - Alle informationer om selve praktikopholdet. ExamProject - Alle informationer og abstract vedrørende eksamensprojektet. De tre tabeller UsersThreads, UsersProjects og UsersEvents benyttes til at forbinde den enkelte bruger med tråde, projekter og events.

27 3.2 Database 19 Figur 3.5: ER-diagram over databaser

28 20 Design 3.3 Sikkerhed Validering og filstruktur Som beskrevet i forrige afsnit, så valideres brugeren ved hjælp af Membershipklassen i ASP.NET. Denne klasse giver både mulighed for at oprette, redigere og validere brugere, og i kombination med Roles-klassen, som er en del af den samme service, kan brugere tilknyttes til en rolle/brugergruppe. Systemet bygger på 5 forskellige brugergrupper: Praktikkoordinator Praktikassistent Student Vejleder UnapprovedUser Derudover er der også en System -bruger, men denne er en del af systemet, og kan ikke gøres aktiv 3. Praktikkoordinator og Praktikassistent kan betragtes som værende i samme gruppe, idet disse har administrator-rettigheder, mens Student og Vejleder kun har almindelige bruger-rettigheder. En ikke godkendt bruger har derimod kun rettigheder til en brøkdel, idet denne bruger oprettes uden godkendelse, og alle studerende på DTU vil derfor kunne oprette en sådan bruger. Hvilke sider den enkelte bruger har tilladelse til at se, afhænger i høj grad af filstrukturen og en række web.config -filer, der definerer adgang baseret på brugerens rolle og login-status. På figur 3.6 kan ses et billede af filstrukturen, hvor mappernes navne tydeligt indikerer, hvilke rettigheder man minimum skal have for at få adgang. 3 Det er ikke muligt at logge ind med denne

29 3.3 Sikkerhed 21 Hvis en bruger forsøger at få adgang til en side som han/hun ikke har tilladelse til, vil personen automatisk blive sendt til loginsiden, der befinder sig i sidens rod. Figur 3.6: Filstruktur og sikkerhed

30 22 Design Uploadede dokumenter De uploadede dokumenter gemmes med specifikke navne i en undermappe, der har det enkelte projekts id som navn. Som udgangspunkt vil ethvert dokument, som befinder sig i en undermappe til websidens rod, være tilgængeligt som reference. Det vil sige, at man kan referere direkte til dokumentet gennem URL-adressen. Dette giver et sikkerhedsproblem, idet brugere derfor vil kunne tilgå andre brugeres dokumenter ved at udskifte id et, hvis de først kender adressen til deres egne. Id et bliver derfor først krypteret 4 inden mappen bliver navngivet, hvorved stien til et dokument kunne se således ud: /InternshipDocumentation.pdf Det var også en mulighed at lægge filerne uden for websidens rod, men dermed er det nødvendigt at kende den fysiske sti til mappen, hvorved den valgte metode er mere fleksibel, ved deploy til forskellige webhoteller eller servere. 4 Se afsnit 4.3 for mere information

31 3.4 Funktioner Funktioner I kravspecifikationen (afsnit 2) blev der opstillet en række krav til systemet. Opbygningen af disse krav og funktionaliteter vil, i de kommende afsnit, blive uddybet nærmere. For yderligere information om, hvorledes de enkelte funktioner benyttes, refereres til brugermanualen i bilag B Brugeroprettelse Oprettelse af en bruger kan ske på to forskellige måder: En administrator har tilladelse til at oprette og deaktivere brugere, samt redigere oplysninger om den enkelte bruger, også selvom oplysningerne er blevet godkendt og låst. Dette giver fleksibilitet til, at brugere f.eks. kan henvende sig til en administrator, hvis adresse, telefonnummer eller lignende ændrer sig under forløbet. Ligeledes har en administrator mulighed for at oprette andre administratorer eller tilføje en bruger til en specifik rolle/brugergruppe. Det er dog ikke tiltænkt at en administrator skal oprette studerende i systemet, idet denne selv har mulighed for at oprette sig ved hjælp af sin DTU studi . Personen indtaster sit studienummer og et ønsket password, hvorefter en bekræftelse sendes til dennes mailadresse. Når denne er bekræftet, er brugeren oprettet som UnapprovedUser, og har mulighed for at udfylde data og blive godkendt.

32 24 Design Projektstyring og godkendelse En bruger kan være tilknyttet et eller flere projekter. Et projekt er defineret ved et praktikophold og en tilhørende skriftlig opgave. Begge dele skal godkendes af en praktikkoordinator inden disse påbegyndes af den studerende. Når en studerende bliver godkendt, bliver han/hun automatisk tilknyttet et tomt projekt, som vil dukke op i vedkommendes liste over tilknyttede projekter. Den studerende har nu mulighed for at redigere data for projektet i en forudbestemt rækkefølge. De tre trin ser således ud: 1. Oplysninger om praktikvirksomhed, virksomhedsvejleder og praktikperiode. 2. Oplysninger om tilhørende eksamensprojekt og abstract. 3. Upload af dokumenter vedrørende praktikperioden. Den forudbestemte rækkefølge er med til at styre den studerende gennem projektet, samtidig med at den giver vejledere og praktikkoordinatorer et godt overblik over, hvor langt i forløbet de studerende er kommet. Før en studerende kan bevæge sig til næste trin, er det nødvendigt at sende de indtastede data ind til godkendelse. Hvis en praktikkoordinator godkender disse, bliver det næste trin tilgængeligt, og de indsendte data bliver låst. Det vil herefter kun være administratorer, der har tilladelse til at rette i de låste data. Så længe den studerende endnu ikke har fået godkendt sit første trin, har den studerende mulighed for at invitere en anden godkendt bruger til projektet, og herved gøre dette til et to-mands projekt. Den inviterede skal godkende invitationen, hvilket vil resultere i, at personen bliver fjernet fra det projekt, som han/hun er tilknyttet, og associeret med det nye. En administrator har også mulighed for at oprette et tomt projekt. Dette vil dog betyde, at en administrator skal tilføje de studerende manuelt, førend projektets forskellige trin vil kunne blive godkendt. Hvadend et projekt oprettes af en administrator eller automatisk, vil samtlige praktikassistenter og praktikkoordinatorer automatisk blive tilknyttet projektet. Hvis en af disse skulle ønske ikke at være tilknyttet, kan en administrator fjerne vedkommende fra projektet 5. 5 Den sidste administrator på et projekt kan ikke fjernes, da projektet ellers ikke vil kunne

33 3.4 Funktioner Beskeder Alle brugere der er tilknyttet et projekt, har mulighed for at kommunikere med hinanden ved hjælp af beskeder. Beskedsystemet er trådbaseret, hvilket betyder, at samtalerne er opdelt i en række tråde, der hver især kan indeholde en eller flere beskeder. Ved oprettelse af en tråd angives en titel/emne til tråden, og brugeren skal vælge, hvilke brugere fra projektet, der skal kunne læse og skrive i tråden. Samtidig skrives den første besked. De brugere der har adgang til tråden, vil så kunne se beskeden, hvorefter de har mulighed for at svare eller kommentere på denne. Både almindelige brugere og administratorer kan oprette tråde og skrive beskeder i dem, men en ikke accepteret bruger, kan kun læse beskeder fra administratorer, idet der ellers er risiko for, at ikke godkendte studerende spammer praktikkoordinatorer og praktikassistenter med ikke relevante spørgsmål, eller lignende. Når en administrator enten godkender eller afviser indsendt data, har denne mulighed for at sende en besked med. Denne besked oprettes også som en ny tråd, idet det giver mulighed for, at en evt. diskussion omkring disse data kan holdes i den samme tråd. En administrator har også mulighed for at oprette en række standard-beskeder med fast titel og indhold, der kan genbruges efter behov. Der er i systemet oprettet 9 specielle standard-beskeder, der ikke kan slettes men redigeres. Ideen med disse 9 beskeder er, at de skal benyttes ved hhv. godkendelse og afvisning af data og praktikophold, samt ved overskridelse af deadlines Eventstyring Systemet genererer automatisk events og tilknytter disse til relevante brugere. Et event bliver genereret ved enten en udført handling, hvor en eller flere brugere skal gøres opmærksom på handlingen, eller når det kræves, at en bruger udfører en specifik handling. Et eksempel på disse to forekommer når en student skal have godkendt nogle data. Den studerende sender da sine data til godkendelse, hvorved en event bliver oprettet og tilknyttet de korrekte administratorer. Administratoren ser, at der kræves en handling af ham/hende, og idet de administreres

34 26 Design indsendte data enten bliver godkendt eller afvist, oprettes endnu en event, der gør den studerende opmærksom på udfaldet. Forneden kan ses en liste over, hvornår der genereres events: Ny besked/tråd Godkendelse af brugerdata Godkendelse af detaljer vedr. praktikophold Godkendelse af detaljer vedr. eksamensprojekt Godkendelse af praktikophold Anmodning om godkendelse af brugerdata Anmodning om godkendelse af detaljer vedr. praktikophold Anmodning om godkendelse af detaljer vedr. eksamensprojekt Anmodning om godkendelse af praktikophold Ikke godtagelse af brugerdata Ikke godtagelse af detaljer vedr. praktikophold Ikke godtagelse af detaljer vedr. eksamensprojekt Ikke godtagelse af praktikophold Invitation af studerende til projekt Acceperet invitation til projekt Ikke accepteret invitation til projekt Deadline næsten overskredet Deadline overskredet Idet de genererede events er en stor del af systemets rygrad, er det nødvendigt at de er let tilgængelige. Den første side en bruger møder efter login er derfor en oversigt over, hvilke events der er tildelt brugeren. En studerende kan altså fra første færd danne sig et overblik over, hvorvidt indsendte data er blevet godkendt, om vedkommende har modtaget nogle nye beskeder eller lign. De forskellige events er sorteret efter oprettelsesdato med de ældste øverst, så administratorerne let kan behandle dem, i den rækkefølge de bliver genereret.

35 3.4 Funktioner Deadlines Der er i den i Kravspecifikationen (afsnit 2) omtalte Business Case 6, defineret en række deadlines/milestones, som skal overholdes af den studerende. Disse deadlines ligger meget tæt op af de tre trin, som blev beskrevet i kapitel 3.4.2: Indsendelse af detaljer vedr. praktikophold. Indsendelse af detaljer vedr. eksamensprojekt. Upload af dokumentation for praktikophold. Upload af den studerendes evaluering af praktikopholdet. Upload af firmaets evaluering af praktikopholdet. Upload af rapport over praktikforløb. Afslutning af praktikforløb. Disse deadlines har hver især en forfaldsdato, som løbende bliver beregnet ud fra på de indtastede data. Til at udføre denne beregning, benyttes nogle globale prædefinerede værdier for, hvor mange dage der må gå mellem de forskellige deadlines. Værdierne er givet ved, hvor mange dage der må gå fra: den studerende bliver godkendt, til detaljer vedr. praktikperioden bliver sendt ind. praktikopholdet starter, til detaljer vedr eksamensprojektet bliver sendt ind. praktikopholdet slutter, til de nødvendige dokumenter er blevet uploadet og den studerende har afsluttet praktikforløbet. De projektspecifikke deadlines kan til en hver tid ændres af en administrator. Dette gælder også for de globale værdier, men disse ændringer vil dog kun have indflydelse på nye beregninger, og de vil derfor ikke have betydning for de deadlines, som allerede oprettede projekter er underlagt. 6 Se bilag C

36 28 Design Upload af standarddokumenter Systemet giver mulighed for, at administratorer kan uploade en række standarddokumenter i PDF-format, som godkendte brugere kan downloade. Det er meningen, at denne sektion skal bruges til at uploade printfærdige skabeloner til de dokumenter, som den studerende skal uploade ved afslutningen af praktikperioden, samt diverse andre relevante dokumenter 7. Derudover vil det være en god ide at uploade en brugervejledning, der beskriver projektforløbet og anvendelsen af systemet for den studerende Generering af rapporter ASP.NET giver mulighed for, at man kan opstille en række skabeloner for rapporter (se figur 3.7), der kan genereres løbende med skiftende data. Når en studerende indsender data (brugerdata, detaljer om praktik eller detaljer om eksamensprojekt) genereres der en rapport, der bliver vist til administratoren. Ud fra denne rapport, burde administratoren have mulighed for at træffe afgørelse om, hvorvidt de enkelte data skal godkendes eller ej. Fordelen ved at generere en rapport frem for en almindelig html-side er, at man bl.a. har mulighed for at eksportere rapporten som et pdf-dokument. Denne funktion er smart, idet de godkendte data danner grundlag for bl.a. søgningen efter en vejleder til det enkelte projekt. Denne søgning går uden om det udarbejdede system, og ved at eksportere rapporten til pdf, bliver der mulighed for at denne kan sendes med s eller lign., så vejlederen får et indblik i projektet før han accepterer. Under det enkelte projekt er det også muligt at vælge Projekt oversigt, hvor der er let tilgang til rapporten i pdf-format samt de uploadede dokumenter. Der er også en oversigt over, hvilke events der er tilknyttet projektet. 7 læs: bilag 2-7 og 10 som beskrives i den udleverede Business Case (Bilag C)

37 3.4 Funktioner 29 Figur 3.7: Skabelon over rapport med 1 studerende

38 30 Design 3.5 DeadlineManager DeadlineManager er i sig selv en del af Sags- og dokumentstyrings systemet, men den er udviklet som et separat projekt. DeadlineManager er ikke en web-applikation, men i stedet en konsol-applikation, der er beregnet til at blive eksekveret på en Windows Server der kører.net Framework 3.5. Ideen med DeadlineManager er, at serveren, der hoster selve web-applikationen eller den tilhørende database, via Task Scheduler 8 skal eksekvere applikationen, på et tidspunkt hvor der er lav aktivitet på systemet (f.eks. om natten). Når DeadlineManager eksekveres, forbindes der til databasen, hvorefter tabellen med deadlines gennemløbes. Hvis en deadline bliver overskredet den pågældende dag, vil der blive oprettet events til de relevante brugere. Der skelnes mellem to typer af overskridelser: En deadline er ved at blive overskredet. En deadline er blevet overskredet. Hvis en deadline er ved at blive overskredet, vil der udelukkende blive oprettet en påmindelses-event til de studerende, som er associeret med projektet. Hvis en deadline derimod er blevet overskredet, vil der både blive oprettet events til de studerende og de praktikkoordinatorer, der er tilknyttet projektet. Det er muligt for en administrator at ændre, hvor lang tid før eller efter en deadline, første og anden notifikation skal oprettes. Ved overskridelse af en event, får en praktikkoordinator mulighed for at skrive en besked til de studerende, samt ændre datoen for den pågældende deadline 9, hvis det skulle være nødvendigt. DeadlineManager benytter sig af både Data Access Layer og Business Logic Layer for at få adgang til deadlines og eventstyring. 8 En Windows Service, der via en række.job-filer sørger for at eksekvere filer eller scripts på specifikke tidspunkter 9 Dette er også muligt selvom den endnu ikke er blevet overskredet.

39 Kapitel 4 Implementering Systemet er implementeret i ASP.NET, som er en programmeringsplatform (framework) til web-applikationer udviklet af Microsoft. Udvikling til denne platform kan ske i flere forskellige sprog, der bl.a. omfatter Visual Basic, Visual C++ og Visual C#. Til udvikling af dette system er det sidstnævnte C# blevet benyttet. ASP.NET platformen indeholder en lang række af udviklingsværktøjer, hvoraf flere af disse fungerer som rygrad i det udviklede Sags- og dokumentstyringssystem. Hvordan de mest essentielle af disse værktøjer er blevet benyttet, vil blive beskrevet nærmere i de kommende afsnit.

40 32 Implementering 4.1 Database, Data Controls og Databinding Databasen må nok siges at være systemets vigtigste komponent, idet alle data, hvad enten de omhandler de oprettede projekter eller de tilknyttede brugere, er lagret i separate tabeller oprettet i denne (se afsnit 3.2). Selve kommunikationen varetages af de såkaldte TableAdapters 1, der kan returnere tabeller med data eller sende opdateringer til databasen, men til at præsentere et simpelt bruger interface benyttes en række Data Controls : GridView ListView Formview ObjectDataSource De tre første controls gør det muligt for programmøren at designe en grafisk brugerflade, der let kan modtage en eller flere records 2 fra databasen og vise dem for brugeren. GridView fungerer som en tabel, der automatisk kan generere rækker og kolonner afhængig af, hvilke datafelter den enkelte record indeholder, og samtidig kan den selv generere knapper til redigering og sletning af records. ListView er lidt mere fleksibel, idet den giver brugeren mulighed for selv at opsætte en skabelon for, hvordan en record skal behandles, samt hvilke specifikke datafelter der skal vises og hvor. I et ListView kan der genereres uafhængige skabeloner for både visning, redigering og indsætning af data. FormView er kun beregnet til at håndtere én record ad gangen, men til gengæld har programmøren fri mulighed for at generere forms med labels, tekstbokse osv., og ligesom med ListView kan der genereres skabeloner for både visning, redigering og indsætning af data. ObjectDataSource har intet med brugerfladen at gøre, men fungerer som et kontrolelement, der indeholder de metoder som skal kaldes ved hhv. hentning af records, opdatering af eksisterende records, sletning af et en specifik record osv. På næste side ses et eksempel på, hvordan ListView kan benyttes til at vise records. Eksemplet stammer fra oversigten over events i sags- og dokumentstyringssystemet. 1 Se afsnit Række med data fra en tabel i en database

41 4.1 Database, Data Controls og Databinding 33 1 <asp : ListView ID= EventSummaryListView runat= s e r v e r DataSourceID= EventSummaryDataSource 3 ItemPlaceholderID= I t e m P l a c e h o l d e r > 5 <LayoutTemplate> <t a b l e runat= s e r v e r i d= EventSummaryTable > 7 <t r i d= I t e m P l a c e h o l d e r runat= s e r v e r /> </ t a b l e> 9 </ LayoutTemplate> 11 <ItemTemplate> <t r runat= s e r v e r > 13 <td i d= TDAction runat= s e r v e r > <asp : LinkButton ID= ItemActionButton runat= s e r v e r 15 Text= View /> </ td> 17 <td i d= TDDescription runat= s e r v e r > <asp : Label ID= D e s c r i p t i o n L a b e l runat= s e r v e r 19 Text= <%# Eval ( Text ) %> /> </ td> 21 <td i d= TDDetails runat= s e r v e r > <asp : Label ID= D e t a i l s L a b e l runat= s e r v e r /> 23 </ td> </ t r> 25 </ ItemTemplate> 27 <EmptyDataTemplate> <asp : Label ID= NoEventsLabel runat= s e r v e r 29 Text= No e v e n t s! /> </ EmptyDataTemplate> 31 </ asp : ListView> 33 <asp : ObjectDataSource ID= EventSummaryDataSource runat= s e r v e r 35 SelectMethod= GetEventsByUserId TypeName= B u s i n e s s L o g i c L a y e r. BLL > 37 <S e l e c t P a r a m e t e r s> 39 <asp : Parameter Name= u s e r I d /> </ S e l e c t P a r a m e t e r s> 41 </ asp : ObjectDataSource> Der skal lægges mærke til den LayoutTemplate, der via ItemPlaceHolder definerer, hvor databasens records skal indsættes. ItemTemplate definerer designet for den enkelte record, hvor <%# Eval("Text") %> fortæller, hvor værdien af cellen Text fra databasen skal indsættes. Der er også en Empty- DataTemplate, der angiver hvad der skal ske, hvis der ingen data returneres. ListView et er bundet til den ObjectDataSource, der ses i bunden og som benytter funktionen GetEventsByUserId fra BusinessLogicLayer.BLL til at hente data, med userid som parameter.

42 34 Implementering 4.2 Login og rettigheder Al login til systemet foregår gennem loginsiden i Login.aspx. På denne side er der indsat en såkaldt login-control, der benytter Membership-klassen til at validere indtastede data op imod databasen, ved at kalde funktionen ValidateUser. Hvis brugeren bliver godkendt, oprettes en ticket i form af en cookie, der bl.a. indeholder informationer omkring brugernavn, roller osv. Hvorvidt en bruger har rettigheder til en given side, bestemmes ud fra den web-config fil, der befinder sig i samme mappe som siden 3. F.eks. er alle administrator-sider placeret i en mappe sammen med en web.config fil, der ser således ud: <?xml v e r s i o n= 1. 0 encoding= utf 8?> 2 <c o n f i g u r a t i o n> <system. web> 4 <a u t h o r i z a t i o n> <deny u s e r s=? /> 6 <a l l o w r o l e s= P r a k t i k a s s i s t e n t /> <a l l o w r o l e s= P r a k t i k k o o r d i n a t o r /> 8 <deny u s e r s= /> </ a u t h o r i z a t i o n> 10 </ system. web> </ c o n f i g u r a t i o n> Den første linie <deny users="?" /> fortæller, at brugere der ikke er logget ind ikke har tilladelse til at se siderne i denne mappe. De to næste linier tillader alle brugere fra rollerne Praktikassistent og Praktikkoordinator at få adgang, mens den sidste linie <deny users="*" /> nægter adgang til alle andre brugere, der ikke er omfattet af af de forrige linier. Når en bruger bliver nægtet adgang, bliver han/hun videresendt til loginsiden. Hvad angår oprettelse af nye brugere foretages dette ved at kalde CreateUser(brugernavn, password) i Membership-klassen. Når en administrator opretter en bruger, bliver denne oprettet med et tilfældigt password, der er blevet genereret ved hjælp af metoden GeneratePassword(), der ud fra en række parametre, genererer et password, der er i overensstemmelse med systemets krav. En bruger bliver tildelt en rolle ved at kalde AddUserToRole(brugernavn, rolle) i Roles -klassen. 3 Se figur 3.6 for overblik over filstruktur

43 4.2 Login og rettigheder 35 For at kunne benytte Membership og Roles funktionaliteterne, er det nødvendigt først at have specificeret en Membership- og Roleprovider samt en connectionstring, der refererer til den benyttede database. Dette gøres i sidens globale Web.config-fil 4 : Connectionstring: 1 <c o n n e c t i o n S t r i n g s> <add name= DataAccessLayer. P r o p e r t i e s. S e t t i n g s. MyConnectionString 3 c o n n e c t i o n S t r i n g= Data Source=msdbb3. surftown. dk ; I n i t i a l Catalog=XXXXXX; P e r s i s t S e c u r i t y I n f o=true ; 5 User ID=XXXXXX; Password=XXXXXX providername= System. Data. S q l C l i e n t /> 7 </ c o n n e c t i o n S t r i n g s> Membershipprovider: 1 <membership> <p r o v i d e r s> 3 <c l e a r /> <! Membership p r o v i d e r s e t t i n g s START > 5 <add name= AspNetSqlMembershipProvider type= System.Web. S e c u r i t y. SqlMembershipProvider, 7 System.Web, Version = , Culture=n e u t r a l, PublicKeyToken=b 0 3 f 5 f 7 f 1 1 d 5 0 a 3 a 9 connectionstringname= DataAccessLayer. P r o p e r t i e s. S e t t i n g s. MyConnectionString 11 e n a b l e P a s s w o r d R e t r i e v a l= f a l s e enablepasswordreset= t r u e 13 requiresquestionandanswer= f a l s e applicationname= / 15 requiresunique = f a l s e passwordformat= Hashed 17 maxinvalidpasswordattempts= 5 minrequiredpasswordlength= 4 19 minrequirednonalphanumericcharacters= 0 passwordattemptwindow= passwordstrengthregularexpression= /> <! Membership p r o v i d e r s e t t i n g s END > 23 </ p r o v i d e r s> </ membership> Som det ses er en lang række af indstillinger mht. password og login styret direkte fra web.config-filen, hvorved disse er lette at rette i. Man skal dog være sikker på, at databasen ikke allerede indeholder brugere osv. hvis man vælger at ændre f.eks. minrequiredpasswordlength, da dette ellers kan kollidere. 4 Da DeadlineManager er en Windows applikation defineres dette i den tilhørende App.config, men ellers på samme måde.

44 36 Implementering 4.3 Kryptering Idet store dele af kommunikationen siderne imellem foregår ved at sende informationer gennem URL-adressen som querystrings, er der en sikkerhedsrisiko, idet en querysting let kan manipuleres af en bruger. F.eks. ville en bruger kunne ændre id et for det projekt, som han/hun er tilknyttet, og dermed pludselig have adgang til en anden persons projekt. Alle følsomme data, der transporteres via URL-adressen, bliver derfor krypteret inden de bliver sendt til browseren og igen dekrypteret når de behandles på serveren. Krypteringen foregår i en implementeret hjælpeklasse kaldet StringEncrypter, og som er en del af Business Logic Layer. Klassen har to metoder Encrypt(string) og Decrypt(string), hvis funktioner er givet ved deres respektive navne. Klassen benytter sig af en anden klasse RijndaelManaged, der er en del af ASP.NET platformens værktøjer til kryptering. I Encrypt() bliver den aktuelle tekst-streng splittet op i bytes, hvorefter den, gennem en såkaldt CryptoStream, bliver krypteret og returneret som en tekst-streng igen. Decrypt foretager den samme operation, bare omvendt. Som krypteringsnøgle benyttes et prædefineret tilfældigt genereret 128 bits byte array og en tilsvarende 128 bit inititialization vector. Ud over querystrings bliver mappenavnene for de uploadede filer også krypterede, så direkte referencer til filerne ikke er mulige gennem URL en.

45 4.4 Upload og download af filer Upload og download af filer Alle upload af filer benytter FileUpload værktøjet, der består af en Filvælger og en række metoder til at håndtere valgte filer. Hvis en fil er blevet valgt, giver FileUpload mulighed for, at man kan kalde SaveAs(path)-metoden, der uploader og gemmer den valgte fil et specifikt sted på serveren. Det kræves dog, at den fysiske sti til biblioteket bliver angivet, hvorfor metoden Server.MapPath() benyttes til at finde den fysiske sti ud fra en virtuel. Her er det dog nødvendigt at mappen er en undermappe til roden af siden. // I f a f i l e has been chosen 2 i f ( FileUpload1. HasFile ) { 4 // Save f i l e on s e r v e r FileUpload1. SaveAs ( S e r v e r. MapPath ( dirpath + / + FileUpload1. FileName ) ) ; 6 } Download af filerne foregår ved, at serveren skriver filens indhold direkte til browseren gennem en HTTP output stream : // Download the uploaded f i l e 2 Response. ContentType = a p p l i c a t i o n / pdf ; Response. AppendHeader ( Content D i s p o s i t i o n, attachment ; f i l e n a m e= + filename ) ; 4 Response. TransmitFile ( dirpath + / + filename ) ; Response. End ( ) ; Da det er en pdf-fil der downloades sættes ContentType til application/pdf og filnavnet bliver skrevet til headeren før filen skrives til stream en Til afsendelse af s benyttes en hjælpeklasse . Denne klasse tager afsender, modtager, emne og brødtekst som argumenter, hvorefter den ved hjælp af værktøjet SmtpClient opretter en forbindelse til en SMTP-server. Klassen MailMessage benyttes til at oprette mailen i Htmlformat, og ved at kalde metoden Send(), afsendes mailen til den ønskede modtager.

46 38 Implementering 4.6 Konstanter Systemet benytter sig af en række konstanter, som det vil være nødvendigt at kunne ændre ved f.eks. flytning af server, udskiftning af domæne eller lignende. Idet samtlige klasser, ved kompilering, bliver samlet i dll-filer, er det ikke længere muligt at rette i de data som defineres i disse. Derfor er alle konstanter defineret i den globale web.config fil, under appsettings. Her er det muligt at sætte værdier for bl.a. SMTPServer, domæne og filernes placering på serveren. 1 <a p p S e t t i n g s> <add key= smtpserverdns value= mailoutb1. s u r f town. net /> 3 <add key= student extension d a l i w i. dk /> <add key= stdmailaddress value= siden@sds. d a l i w i. dk /> 5 <add key= pagerooturl value= h t t p : // sds. d a l i w i. dk/ /><! h t t p : // sub. domain. dk/ > <add key= f i l e s R o o t value= / F i l e s /> 7 </ a p p S e t t i n g s> Ligeledes kan connectionstrings og lign. også ændres direkte i Web.config-filen, uden systemet skal recompiles. 4.7 Dataset Data Access Layer består hovedsageligt af et Dataset, der indeholder en række DataTables og TableAdapters (se figur 3.3). En TableAdapter kan bedst beskrives som en samling af SQL-kald, hvoraf hvert kald kan foretages ved at kalde en tilhørende funktion, der kan modtage et eller flere argumenter hvis nødvendigt.

47 4.7 Dataset 39 Nedenstående kode viser et meget forenklet eksempel på, hvordan XML-koden ser ud for en TableAdapter, der har én funktion GetAllEventTypes der eksekverer et Select kald til databasen: 1 <TableAdapter BaseClass= System. ComponentModel. Component DataAccessorModifier= AutoLayout, AnsiClass, Class, Public 3 DataAccessorName= EventTypesTableAdapter GeneratorDataComponentClassName= EventTypesTableAdapter 5 Name= EventTypes UserDataComponentName= EventTypesTableAdapter > 7 <MainSource> 9 <DbSource ConnectionRef= MyConnectionString ( S e t t i n g s ) DbObjectName= [ sds. dk ]. dbo. EventTypes 11 DbObjectType= Table GenerateMethods= Get GenerateShortCommands= f a l s e 13 GeneratorGetMethodName= GetAllEventTypes GetMethodModifier= Public 15 GetMethodName= GetAllEventTypes QueryType= Rowset 17 S c a l a r C a l l R e t v a l= System. Object, mscorlib, Version = , Culture=n e u t r a l, 19 PublicKeyToken=b77a5c561934e089 UseOptimisticConcurrency= f a l s e 21 UserGetMethodName= GetAllEventTypes UserSourceName= GetAllEventTypes > 23 <SelectCommand> 25 <DbCommand CommandType= Text ModifiedByUser= t r u e > <CommandText> 27 SELECT EventType, Text FROM dbo. EventTypes </CommandText> 29 </DbCommand> </ SelectCommand> 31 </ DbSource> 33 </ MainSource> 35 <Mappings> <Mapping SourceColumn= EventType DataSetColumn= EventType /> 37 <Mapping SourceColumn= Text DataSetColumn= Text /> </ Mappings> 39 </ TableAdapter> Først defineres TableAdapteren og derefter forbindelsen til databasen gennem MyConnectionString (Settings). GetMethodName navngiver den enkelte metode, og under SelectCommand findes CommandText, hvori selve SQL-kaldet defineres. Mappings delen i bunden sammenkæder navnene på databasens celler med navnene i det DataTable som TableAdapteren er tilknyttet.

48 40 Implementering Det dataset, der benyttes i systemets Data Access Layer hedder SDSDataSet, og for at kalde den ovenstående funktion fra Business Logic Layer, benyttes følgende syntaks: 1 u s i n g DataAccessLayer. SDSDataSetTableAdapters ; EventTypesTableAdapter e t t a = new EventTypesTableAdapter ( ) ; e t t a. GetAllEventTypes ( ) ;

49 Kapitel 5 Test Under implementeringen af systemet er der løbende blevet udført funktionelle tests af de implementerede klasser og metoder, hvilket bl.a. har været med til at fremprovokere uovervejede situationer, hvor systemet ikke reagerede på den ønskede måde. Dette har bl.a. været med til at forme implementeringen, og flere gange har det været nødvendigt at gå helt tilbage til den indledende designfase, for at overveje og udføre ændringer, der ville kunne forebygge flere af denne type fejl. Efter implementeringen af systemet var færdigt, blev samtlige usecases og flowdiagrammer gennemløbet, for at sikre at der ikke var uoverensstemmelse mellem disse og det endelige system, samt for at finde eventuelle fejl. Idet dette blev gennemført uden problemer, blev en lang række af alternative forløb forsøgt gennemløbet for at komme så bredt rundt i systemet som muligt. Dette førte heller ikke til nogle uovervejede situationer.