Sags og dokumentstyringssystem

Transkript

1 Sags og dokumentstyringssystem s Michael Højgaard Bojsen s Kristian Andersen Vejledere: Stig Høgh og Mads Nyborg Kongens Lyngby 2008 IMM-B.Sc

2 Technical University of Denmark Informatics and Mathematical Modelling Building 321, DK-2800 Kongens Lyngby, Denmark Phone , Fax IMM-B.Sc.: ISSN

3 Abstract Målet med denne opgave er at udvikle et system til håndtering af de studerende på DTUs diplom IT retnings praktikforløb. Systemet skal fungere som bindeled mellem de studerende og deres vejledere, samt dokumentere kommunikationen mellem parterne.

4 ii

5 Forord Denne rapport og tilhørende produkt, er resultatet af et bachelorprojekt, udført på Institut for Matematisk Modellering på Danmarks Tekniske Universitet i perioden 1/2-30/ Læseren af denne rapport forventes at have kendskab til softwareudvikling, samt basal viden om objekt-orienteret programmering.

6 iv

7 Indhold Abstract i Forord iii 1 Indledning 1 2 Kravspecifikation Definitioner Usecases Webudvikling Design Generelle designvalg Grafisk brugergrænseflade UML diagram Database design

8 vi INDHOLD 4 Implementering Namespaces Interaktion med eksterne systemer Signifikante klasser Test UnitTest Brugervenlighedstest Konklusion Forslag til udvidelser A Brugermanual 37 B Adminstratormanual 45 C Kildekode 53 C.1 App Code C.2 / C.3 Auth C.4 Cases C.5 Documents C.6 Errors C.7 Events C.8 Forms

9 INDHOLD vii C.9 Messages C.10 Test C.11 TriggerService C.12 UI C.13 User D Database 233

10 viii INDHOLD

11 Kapitel 1 Indledning På DTUs diplom-it uddannelse, skal de studerende på retningen igennem et halvt års praktikophold i en virksomhed. I løbet af det halve år er de studerende tilknyttet en vejleder fra DTU samt en vejleder i virksomheden. De studerende skal løbende i praktikperioden holde vejlederne opdaterede med hvordan praktikken forløber, ved hjælp af en række dokumenter der skal udfyldes. I øjeblikket gøres det ved hjælp af filupload funktionen på DTUs intranet - CampusNet. Den studerende downloader og udfylder et tekstdokument, for derefter at uploade det igen. Dette gør det til et meget omstændigt arbejde for vejlederne at holde styr på alle studerende og hvor langt de er i praktikforløbet. Der ønskes derfor et system hvor vejlederne kan definere en række formularer som de studerende kan udfylde. Når en studerende har udfyldt en formular, skal der sendes en besked til de relevante vejledere med information om at en formular er blevet udfyldt. Ydermere skal alt kommunikation mellem vejledere og studerende foregå gennem systemet, og det skal derfor være muligt at sende beskeder internt mellem brugerne, samt muligt for vejlederne at opsætte regler for at hvis en bestemt formular ikke er udfyldt inden et bestemt tidspunkt, skal der sendes en besked / / sms ud til den studerende.

12 2 Indledning

13 Kapitel 2 Kravspecifikation Der ønskes udviklet en webportal med følgende muligheder: oprette/redigere brugere - og brugergrupper, samt tildele rettigheder til disse oprette/redigere indtastningsformulartyper (html form templates) og definere indhold. oprette/redigere sager og definere sags-indhold i form af hvilke forms/- dokumenter sagen består af tilknytte brugere til sagen. sende meddelelser til medlemmer og grupper, som gemmes under sagen (sporbare). uploade generelle dokumenter til sagen oprette/redigere filstrukturer som dokumenter kan gemmes under arbejde på fælles dokumenter med versionsstyring, låsning og rettighedskontrol. generere oversigtssider der viser udviklingen i en sag

14 4 Kravspecifikation generere rapporter der viser sagens dokumenter unne varsle brugere om hændelser over (ændring af dokumenter, nye interne meddelelser og udløbne frister). opsætte meldesystemer som kan sende meddelelser til brugere via eller SMS. 2.1 Definitioner I dette projekt arbejder vi med en række begreber, der defineres således: Sag En sag er en studerende der er i praktikophold. Til hver sag er tilknyttet mindst en studerende, samt mindst en vejleder. Administratoren definerer på forhånd en række formularer der skal udfyldes af den studerende inden en fastsat deadline. Formular Et dokument administratoren kan oprette hvorefter brugeren kan udfylde dette med data. En formular kan blive defineret som en standardformular, og vil i så fald bliver indsat på alle nye sager. Felt Et delelement af en form. En form består af flere felter. Vi arbejder med 6 forskellige typer felter: YESNO - Ja eller Nej STEXT - (Short text) - En kort tekst (en linie) LTEXT - (Long text) - En lang tekst (flere linier) DROPDOWN - En dropdown-liste, valg-mulighederne indtastes i Data separeret med ;. Bedst til lister med mange muligheder. RADIO - En mængde radio-knapper, valg-mulighederne indtastes i Data separeret med ;. Bedst til lister med få muligheder.

15 2.2 Usecases Usecases Usecases giver en ide om hvordan systemet kan blive brugt af brugerne, samt hvordan systemet reagerer i visse situationer. Denne sektion indeholder usecases for de mest centrale funktioner i systemet.

16 6 Kravspecifikation Opret sag Før en studerende kan benytte systemet, skal der oprettes en sag på den studerende. Dette gøres af en administrator. Primær aktør: Administrator Beskrivelse: Administratoren ønsker at oprette en sag på en specifik studerende Succes scenarie: 1. Vælger Brugere Tilføj i topmenuen 2. Vælger studerende (a) Indtaster et studienummer (b) Uploader liste med studienumre 3. Klikker på Tilføj 4. Systemet validerer den indtastede data og opretter sagen Undtagelser 4a Den indtastede data kan ikke valideres 1. Gør bruger opmærksom på fejlen 2. Gå til succes scenarie: 2

17 2.2 Usecases Opret formular Til den oprettede sag skal der tilknyttes en række formularer. Disse oprettes af en administrator og tilknyttes enten en enkelt sag, eller markeres som standardformularer og vil derved blive tilknyttet samtlige sager i systemet. Primær aktør: Administrator Beskrivelse: Administratoren ønsker at oprette en formular der skal udfyldes af brugerene. Succes scenarie: 1. Vælger Formularer Ny i topmenuen 2. Indtaster navn på fomularen og antal felter der ønskes (kan ændres senere) 3. For hvert felt defineres navn, beskrivelse, type og evt. data 4. Aftjekkes standardformular checkboksen, gemmes formularen som en s- tandardformular - dvs. tilføjes samtlige sager 5. Systemet validerer den indtastede data og opretter formularen Undtagelser: 5a Den indtastede data kan ikke valideres 1. Gør bruger opmærksom på fejlen 2. Gå til succes scenarie: 3

18 8 Kravspecifikation Tilføj formular til sag Når en administrator har oprettet en sag, skal der defineres hvilke formularer sagen består af. Formularer der er markeret som standardformularer, bliver automatisk tilknyttet sagen, men skal der tilføjes ekstra specifikke formularer til sagen, skal det gøres manuelt. Primær aktør: Administrator Beskrivelse: Administrator ønsker at tilføje en formular til en sag. Succes scenarie: 1. Vælger Sager Vis alle i topmenu 2. Vælger den pågældende sag 3. Vælg Formular i dropdown menu under de tilknyttede formularer 4. Klik Tilføj formular

19 2.2 Usecases Udfyld formular De studerende skal udfylde formularer der er defineret af en administrator. Primær aktør: Bruger Beskrivelse: Brugeren ønsker at udfylde en på forhånd defineret formular Succes scenarie: 1. Brugeren vælger formularen og klikker på udfyld 2. Brugeren udfylder formularen 3. Brugeren vælger om formularen skal gemmes som kladde eller sendes til administratoren 4. Bruger klikker på Send 5. Validering Hvis Gem som kladde er valgt, gemmer systemet data uden validering Hvis Gem som kladde ikke er valgt, tjekker systemet at data er korrekt udfyldt, og sender en besked til administratoren om at formularen er udfyldt Undtagelser: 5b: Felterne er ikke korrekt udfyldt. 1. Gør brugeren ommærksom på fejl 2. Gå til succes scenarie: 2.

20 10 Kravspecifikation 2.3 Webudvikling Kort om webudvikling Efter internettet blev udbredt til den brede befolkning, ville flere og flere virksomheder og private brugere have deres egen hjemmeside. De første hjemmesider blev udviklet udelukkende i HTML. Det var såkaldte statiske websider, der blot viser den samme data til alle der ønsker at se siden. Brugeren havde ikke mulighed for at interagere med siden. Dette kan for så vidt være fint nok, hvis man fx er en virksomhed der skal vise et billede af et produkt samt adressen på virksomheden. Det er dog ikke særlig praktisk, hvis man skal forsøge at have en vis interaktion med brugeren. Det kan for eksempel være at billeder eller tekst skal skifte alt efter hvilken type bruger der ser på siden. En side hvor indholdet ændres udfra udefrakommende faktorer, kaldes en dynamisk webside. Der er 2 forskellige typer dynamiske websider Client-side scripting Alt alle ændringer på siden sker på klient siden, dvs. I brugerens browser. Hjemmesider der benytter client-side scripting er for det meste lavet i html, med brug af et client-side scripting sprog, som fx. Javascript eller flash. Server-side scripting Ved server-side scripting, sker alt behandlig af brugerens indtastede data på serveren. Dvs.at hver gang brugeren foretager ændringer på siden, sendes den tilbage til serveren, der så processerer siden og sender den tilbage til brugeren. Hjemmesider der benytter server-side scripting, benytter html til det grundlæggende layout, og et server-side scripting sprob som fx. PHP, ASP eller ASP.NET.

21 Kapitel 3 Design 3.1 Generelle designvalg I udviklingen af dette projekt har vi valgt at benytte ASP.NET som teknologi. Dette har vi gjort da ASP.NET meget nemt tillader at man bruger Model-View- Control (MVC) konceptet. MVC betyder at al præsentation af information ligger i.aspx-filerne, kontrol-aspektet ligger i de tilknyttede.cs-filer med samme navn, og at modellen ligger i særskilte.cs-filer. Dette valg forbedrer mulighederne for at ændre den visuelle fremtoning uden at der er fare for at den bagvedliggende model ændrer funktionalitet. Til datalagring har vi valgt en MySQL database, da det er den eneste database vores webhotel understøtter. Vi har dog været påpasselige med ikke at bruge MySQL specifikke nøgleord i vores forespørgsler så vi uden problemer kan skifte til en anden type SQL-database. Dette er blandt andet hjulpet vha. DBdata klassen.

22 12 Design 3.2 Grafisk brugergrænseflade Vi har valgt at holde designet på den grafiske brugergrænsefladen så simpelt som muligt. Vi har forsøgt at holde vores system i samme stil som CampusNet, da dette vil give brugerne en følelse af tryghed MasterPage I ASP.NET kan man når man skal definere layoutet på et websted benytte en såkaldt masterpage. På siden definerer man de elementer der skal vises på hver enkelt side. Det er her sidens størrelse, menuernes opbygning, topbanner osv. bestemmes. Et af de væsentligste elementer på masterpagen er en ContentPlaceHolder, der placeres der på siden hvor man vil have det sidespecifikke indhold placeret. Når man opretter en ny side, henvises der til at man vil benytte en masterpage, og at indholdet skal vises i en af sidens ContentPlaceHolders. Det grundlæggende layout af siden er defineret i filen UI/MasterPage.master.

23 3.2 Grafisk brugergrænseflade Topmenu Topmenuens opbygning afhænger af brugerens status. Menuen indeholder følgende elementer (Er elementet kun vist for administrator (A) eller både administrator og studerende(a,s)). Formularer Ny (A) Opretter ny formular Vis alle (A) Lister alle formularer Beskeder Ny (A) Opret ny besked Indbakke(A,S) Liste over alle beskeder til bruger/administrator Sendt(A,S) Liste over alle beskeder sendt af bruger/administrator Brugere Vis alle(a) Liste over alle brugere Tilføj(A) Tilføj en ny bruger til systemet Min profil(a,s) Vis info om bruger/administrator i systemet Opret ekstern (A) Sager Vis alle (A,S) Liste over alle sager Log ud(a,s) Log ud af systemet

24 Design UML diagram Herunder ses et UML diagram for systemet.

25 3.4 Database design Database design Alle entiteter i databasen, kan umiddelbart identificeres udfra kravsspecifikationen Relationer Herunder følger vores relationer, efterfulgt af en kort beskrivelse af hvad relationen gør: AssociationCaseForm(CaseID,FormID,Deadline,Triggered) Kæder en sag sammen med en formular. Holder også styr på hvornår formularen skal være udfyldt, samt hvornår der er blevet sendt sms/ varsel ud til brugeren om en snarlig deadline. AssociationCaseUser(UserID,CaseID) Kæder brugere sammen med sager. Cases(CaseID,OwnerID,Comment) Indeholder samtlige sager. En sag indeholder et unikt ID, ID på ejeren af sagen, samt en kommentar tilknyttet sagen (Casens navn) Datasets(DatasetID,UserID,CaseID,Draft) Et Dataset beskriver det data en bruger har indtastet i en formular. Det indeholder også en boolean værdi der angiver om brugeren er færdig med at indtaste data, eller om det endnu er en klade der ikke skal ses af andre end brugeren selv Documents(DocumentID,DocumentName,OwnerID,CaseID,PredesesoorID,FolderID, Public,Locked,Mime,LastModified,Data) En fil, der er blevet uploaded til sagen, gemmes i databasen sammen med info om hvem der har uploaded det, I hvilken case, om der er andre versioner af dokumentet, hvilken folder dokumentet ligger I, om det er et offentligt eller privat document, om dokumentet er låst, dokumentets mime type, hvornår dokumentet blev uploaded, samt selve filen som en BLOB 1 Events(EventID,CaseID,UserID,EventType,EventMessage,VisibleFor, LastModified) Enhver event har et unikt ID, en sag den er tilknyttet, en type, en besked, info om hvem der skal se eventen, samt tidspunktet hvor eventen skete. 1 Binary Large OBject

26 16 Design FieldData(FieldDataID,DatasetID,FieldID,Value,Lastmodified) Data indtastet I et felt gemmes som FieldData. Enhver indtastning har et unikt ID, ID på det korresponderende DataSet, ID på det pågældende felt, en værdi (brugerens indtastede data), samt info om hvornår indtastningen skete. Fields(FieldID,FormID,FieldName,FieldDesc,FieldType,FieldData) Et felt har et unikt ID, ID på den form feltet tilgører, et navn, en beskrivelse, en type, samt evt data man kan vælge imellem, hvis feltet er en DropDownMenu eller en RadioButtonList Folder(ID,Name,PredecessorID,CaseID,Public,OwnerID) En mappe bruges I filupload funktionen. Den indeholder et unikt ID, ID på dens forgænger (den mappe, mappen er en undermappe af), info om mappen er privat eller offentlig, samt ID på ejeren af folderen. Forms(FormID,FormName,OwnerID,Standard,Lastmodified) En formular indeholder et unikt ID, et navn, ID på ejeren af formen, en Boolean der fortæller om det er en standardformular, samt info om hvornår formularen blev oprettet Messages(MessageID,CaseID,FromID,ToID,DateTime,Message) En besked indeholder et unikt ID, ID på den case beskeden blev sendt til, ID på modtager og afsender, tidspunktet beskeden blev sendt på, samt beskeden. Users(UserID,DTUID,Password,FirstName,LastName, ,SMSPhone,UserStatus) En bruger af systemet identificeres ved et unikt ID. Ydermere indeholder tabellen info om brugerens studienummer, kodeord (hvis ikke brugeren har et DTU login), fornavn, efternavn, adresse, mobiltelefonnummer og brugerstatus.

27 3.4 Database design ER-Diagram Databaseoptimering Databasen er, som den ser ud nu absolut ikke optimal når der skal trækkes store mængder data ud. Man kunne meget vel normalisere databasen. Dette ville give færre tabeller, og hurtigere svar fra databasen. Vi er dog i den heldige situation at vi aldrig har brug for at trække så store datamængder ud, eller lave så beregningskrævende forespørgsler at det tidsmæssigt kan betale sig for os at optimere databasen.

28 18 Design

29 Kapitel 4 Implementering 4.1 Namespaces Vi har valgt at dele programmet op i følgende namespaces for overskuelighedens skyld. Dette gør det nemmere fx at videreudvikle eller fejlfinde i systemet. Cadoc Indeholder hjælpeobjektet DBdata og interfacet DBobject. Disse hjælper med at kommunikere med databasen og sørger for at vi holder vores objekter opdaterede til en hver tid. Cadoc.Cases Indeholder Case, der et en af de meget centrale klasser i programmet, da den indeholder data om hele sagen, heriblandt hvilke brugere der er tilknyttet, hvilke formularer og det data brugerne har indtastet i formularerne. Cadoc.Data Indeholder klasserne DataSet og FieldData. Hvor DataSet refererer til sagen og brugeren der har udfyldt en given formular. FieldData refererer til DataSet og Field. Cadoc.Documents

30 20 Implementering Indeholder klassen Document, der repræsenterer en uploadet fil i en sag. Kan være en hvilken som helst fil, da klassen indeholder information om hvilken MIME-type filen har. Cadoc.Events Indeholder klassen Event og enumeratoren EventType. Ved hver væsentlig hændelse i systemet vil der blive oprettet en Event indeholdende hvilken sag hændelsen skete i, brugeren der var årsag til hændelsen, hvilken type hændelse, en beskrivende meddelelse og hvilket brugerniveau man skal have for at kunne se hændelsen. Cadoc.Forms Indeholder klasserne Form og Field samt enumeratoren FieldType. En formular (Form) indeholder et eller flere Fields. Field kan være af flere forskellige typer som defineret i FieldType. Cadoc.Messages Indeholder klassen Message, der repræsenterer en besked sendt fra en bruger til en anden. Under oprettelsen har man samtidig mulighed for at få udsendt beskeden som SMS og . Cadoc.Services Indeholder webservicen TriggerService, der bliver kaldt af windowsservicen af samme navn. Webservicen checker om det er nødvendigt at udsende påmindelser til brugere der ikke har indsendt deres formularer. Cadoc.Users Indeholder klasserne SiteIdentity og SitePrincipal samt enumeratoren UserStatus. SiteIdentity og SitePrincipal er udvidelser af ASP.NETs indbyggede IIdentity og IPrincipal interfaces. Dette bevirker at så snart brugeren er blevet godkendt af systemet, så sørger ASP.NET selv for at opretholde objekterne korrekt. Også her nedarver objekterne fra DBobject således at vi sørger for at vi altid arbejder med opdateret data og at evt. ændringer lavet run-time vil blive skrevet til databasen Cadoc.UI Indeholder alt hvad der har med den grafiske brugerflade at gøre. Cadoc.UI.MasterPage Vores primære masterpage, der sørger for at alle vores sider ligner hinanden og at vores design nemt kan ændres.

31 4.1 Namespaces 21 Cadoc.UI.EmptyMaster I fx pop-up vinduer ønsker vi en meget simpel side, hvor brugeren ikke ser andet end det væsentlige indhold Cadoc.UI.Auth Cadoc.UI.Auth.AccessDenied Den side brugeren bliver henvist til, hvis vedkomne forsøger at foretage en handling den pågældende bruger ikke har rettigheder til. Cadoc.UI.Auth.External Log ind side til eksterne brugere. Bliver brugt af brugere udenfor DTU, da disse ikke ligger i DTUs brugerdatabase. Cadoc.UI.Auth.Login Håndterer data DTUs brugerdatabase, og tjekker med denne om den pågældende session stadig eksisterer. Cadoc.UI.Auth.Logout Afslutter sessionen i vores system og beder DTUs system om at gøre det samme. Hvis DTUs system ikke afslutter sessionen korrekt, vil brugeren få oprettet en ny session i vores system og kan fortsætte med at bruge det Cadoc.UI.Cases Cadoc.UI.Cases.Default En oversigtsside med tilknyttede sager, sager brugeren ejer og for administratorer en liste med samtlige sager i systemet. Cadoc.UI.Cases.EditCase Dette er standardsiden for de studerende. Her bliver man præsenteret for de tilknyttede brugere, formularer, dokumenter og hændelser. Det er samtidigt muligt at sende besked til gruppen, udfylde formularer, udskrive en oversigt over sagen og uploade dokumenter. Administratorer har derudover mulighed for at tilføje og fjerne brugere og formularer. Cadoc.UI.Cases.ShowCase Genererer en komplet oversigt over sagen. Herunder tilknyttede brugere, hændelser og data fra udfyldte formularer.

32 22 Implementering Cadoc.UI.Documents Cadoc.UI.Documents.CreateFolder Giver brugeren mulighed for at oprette en ny mappe i en given sag. Cadoc.UI.Documents.ShowVersions Viser en liste med gamle versioner af et givent dokument. Cadoc.UI.Documents.UploadDocument Giver brugeren mulighed for at uploade et nyt dokument. Cadoc.UI.Documents.ViewDocument Præsenterer et uploadet dokument for brugeren Cadoc.UI.Events Cadoc.UI.Events.EventPopup Præsenterer en given hændelse for brugeren Cadoc.UI.Forms Cadoc.UI.Forms.Default Viser en liste med tilgængelige formularer. Cadoc.UI.Forms.EditForm Giver mulighed for at ændre en formular. Cadoc.UI.Forms.FillForm Her kan brugeren indtaste data i en given formular. Cadoc.UI.Forms.NewForm Her kan der oprettes en ny formular. Lige efter oprettelse bliver brugeren sendt videre til EditForm. Cadoc.UI.Forms.ShowData Viser en liste med brugere der har indtastet data i en given formular. Cadoc.UI.Forms.ShowInput Viser en given brugeres indtastning i en given formular.

33 4.1 Namespaces Cadoc.UI.Messages Cadoc.UI.Messages.NewMessage Giver brugeren mulighed for at sende en ny besked, enten til en enkelt bruger, til alle brugere i en sag eller til alle brugere. Cadoc.UI.Messages.SentMessages Viser alle beskeder den pågældende bruger har sendt. Cadoc.UI.Messages.ShowMessages Viser alle beskeder den pågældende bruger har modtaget Cadoc.UI.User Cadoc.UI.User.AddUser Her kan administratoren tilføje brugere til systemet ud fra studienummer. Det er muligt at tilføje eller slette en bruger af gangen eller uploade en tekst-fil indeholdende studienumrene på de pågældende. Cadoc.UI.User.Default Viser en given brugers informationer samt et billede. Administratorer kan ændre brugerens status. Cadoc.UI.User.EditUser Viser en brugers informationer samt et billede. Her er det også muligt at sende en besked til brugeren. Cadoc.UI.User.ListUsers Viser en liste med alle brugere. Listen er farvekodet i forhold til brugerens status.

34 24 Implementering 4.2 Interaktion med eksterne systemer DTUbasen Vi anvender DTUbasen til at hente informationer om vores brugere ud fra deres DTU-brugernavn. Dette gøres via en HTTP- baseret SOAP løsning stillet til rådighed af Arcanic 1. Da SOAP er platformsuafhængigt er det et oplagt valg så flest mulige systemer kan interagere med DTUbasen. Dog er ulempen at der grundet HTTP protokollen bliver sendt meget ekstra data med hver forespørgsel og svar. Dette har vi valgt at acceptere da det i forvejen er begrænsede mængder data vi overfører. For at undgå at vores system går ned ved et evt. nedbrud af DTUbasen cacher vi nogle felter. Disse inkluderer fornavne, efternavn, -adresse og mobiltelefon-nummer. Vi har også valgt kun at synkronisere disse felter ved indlogning for at undgå at lægge for stort et pres på DTUbasen. Da DTUbasen indeholder personlige data er adgangen begrænset ligesom dokumentationen kun gøres tilgængeligt for personer der har adgang til DTUbasen. Vi kontaktede Arcanic og DTUs IT-chef Steen Pedersen for at søge om adgang til DTUbasen i vores projekt periode. Vi fik relativt hurtigt en positiv tilbagemelding og blev bedt om at melde tilbage hvilken type data vi havde brug for og hvilke IP-adresser vi ville have åbnet for i deres firewall. Vi valgte at få åbnet for vores webserver (ude i byen) og vores private maskiner. Vores adgang bliver tidligst lukket d. 4/ Central Authentication Service For at undgå at brugere allerede tilknyttet DTU (langt størstedelen) skal huske på flere brugernavne og adgangskoder end højst nødvendigt bruger vi Central Authentication Service (CAS) udviklet af JA-SIG.org. Dette system anvender DTU til brugergodkendelse til CampusNet, webmail osv. JA-SIG.org stiller et ASP.NET interface til rådighed. Dette har vi anvendt og tilpasset vores system. Udover DTU anvendes CAS af mange universiteter over hele verdenen til sikker brugergodkendelse. Når en bruger vil ind i vores system kontrollerer vi om brugeren er logget ind. Hvis dette ikke er tilfældet sender vi brugeren til DTU s CAS log ind side sam- 1 System ansvarlige for bl.a. CampusNet, DTU s Learning Management System

35 4.2 Interaktion med eksterne systemer 25 men med oplysning om hvilken side vi ønsker at brugeren skal returneres til. Brugeren indtaster nu sit brugernavn og adgangskode og hvis CAS kan godkende oplysningerne bliver der oprettet en ticket på CAS-serveren og brugeren bliver sendt til den ønskede side sammen med et ticket-id. Herefter forespørger vores webserver CAS-serveren om det modtagede ticket-id er gyldigt og i så fald hvilken bruger der er blevet godkendt i denne ticket. Når vi har modtaget information om at brugeren er godkendt og dennes brugernavn oprettes der en session på vores webserver indeholdende oplysninger om at brugeren også er logget ind i vores system og brugeren bliver nu præsenteret for den ønskede side SMS-service For at udsende SMS-beskeder (Short Message Service) til vores brugere benytter vi en Webservice fra Igen anvendes der SOAP over HTTP til udveksling af data. SMS er en del af GSM-protokollen udviklet til mobile terminaler, også kendt som mobiltelefoner. Normalt kan en SMS-besked maksimalt indeholde 160 tegn. Dette kan omgås ved at bruge kædede beskeder som webservicen understøtter uden problemer. Dog ønsker vi normalt ikke at sende mere end ca tegn af gangen, svarende til to SMS-beskeder. Dette er valgt både ud fra et økonomisk synspunkt og for brugervenligheden, da vi ikke ønsker at vores brugere skal blive overdænget af SMS-beskeder i det tilfælde at en administrator udsender en meget lang besked. Webservicen giver os mulighed for selv at bestemme hvad der skal stå som afsender på SMS-beskederne. Vi har valgt at undlade at bruge et telefonnummer som afsender, men derimod teksten Cadoc.dk. Hvis en bruger prøver at svare på en sms besked fra systemet, vil modtagerens telefonnummer være blankt.

36 26 Implementering 4.3 Signifikante klasser Cadoc.Cases.Case Case(int CaseID) Henter sagen med CaseID fra databasen. public Case(int OwnerID, string Comment) Opretter en ny sag i database. public List<Cadoc.Users.SiteIdentity> Users Returnerer en liste med brugerne der er tilknyttet sagen. public void AddUser(Cadoc.Users.SiteIdentity User) Tilføjer brugeren User til sagen. public void RemoveUser(Cadoc.Users.SiteIdentity User) Fjerner brugeren User fra sagen public List<Cadoc.Forms.Form> Forms Returnerer en liste med formularerne der er tilknyttet sagen. public void AddForm(Cadoc.Forms.Form Form, DateTime deadline) Tilføjer formularen Form til sagen og angiver at den skal være udfyldt af alle studerende i sagen senest deadline. public void RemoveForm(Cadoc.Forms.Form Form) Fjerner formularen Form fra sagen. public List<Cadoc.Events.Event> Events Returnerer en liste med hændelserne der er tilknyttet sagen. public void AddEvent(Events.EventType Type, string Message, Users.UserStatus VisibleFor) Tilføjer en hændelse til sagen, med typen Type, beskeden Message og angiver at den kun skal være synlig for brugere med status VisibleFor eller højere. public List<Cadoc.Documents.Document> Documents Returnerer en liste med sagens dokumenter. public void AddDocument(string Name, int FolderID, int Public, int Locked,string Mime, byte[] Data)

37 4.3 Signifikante klasser 27 Tilføjer et dokument til sagen med navn Name, mappe-id FolderID, mimetype Mine og indholdet Data. Public og Locked angiver om dokumentet skal være hhv. offentligt og låst. public void Delete() Sletter sagen og alle tilhørende datasæt, dokumenter, mapper, beskeder og referencer til og fra brugere og formularer DBdata og DBobject For at simplificere håndteringen af synkroniseringen af data i run-time objekter og vores database har vi valgt at alle klasser der direkte relaterer til databasen skal implementere interfacet DBobject. Dette sikrer os at vi har metoderne Delete() og Update(). Delete() sletter objektet og alle dets underobjekter fra databasen. Update() opdaterer databasen med det nyeste data. Derfor er det vigtigt at kalde Update() hver gang der bliver ændret noget i objektet man ønsker at gemme i databasen TriggerService Da vi via ASP.NET ikke kan køre kommandoer baseret på tid og vi ikke kan garantere at vi har besøgende ofte nok (til at udløse kommandoer) har vi udviklet en Windows Service der sørger for at udløse vores tidskritiske hændelser. Her tænkes der især på udsendelse af s og SMSer som påmindelse om at en bruger ikke har udfyldt en formular inden en given deadline. Som standard udløses hændelserne to gange i døgnet (hvert sekund) ved at kontakte en webservice og eksekvere metoden ExecuteRules(guid). Guid bliver sendt med for at sikre sig at ikke alle og en hver kan invoke servicen.

38 28 Implementering

39 Kapitel 5 Test Løbende igennem udviklingsforløbet har vi udført funktionelle tests af de enkelte funktioner, efterhånden som de blev implementeret. Vi har også efter den endelige implementering af det samlede system udført en funktionel test af systemet. Ydermere har vi lavet en unit test af en af de centrale klasser i systemet - Cadoc.Case.Case klassen, samt en brugervenlighedstest af hele systemet.

40 30 Test 5.1 UnitTest Cadoc.Cases.Case Da Case er en meget central klasse har vi valgt at udføre en unit test på denne. Testen kan findes på Vi har valgt at man skal være logget ind da testen bruger mange system-ressourcer på webserveren. På den måde undgår vi at fx søgemaskiner kører testen. I et reelt produktionsmiljø ville man fjerne adgangen til testen fuldstændig for at undgå fejl i databasen og overbelastning af database-serveren. For at undgå at have test-data tilbage i databasen efter testen har vi lavet listen Garbage der indeholder objekter der implementerer DBobject. Undervejs i testen tilføjes midlertidige objekter til listen. Efter testen skal metoden CleanUp() køres. Metoden løber listen Garbage igennem og beder systemet om at slette objekterne igen. For at testen skal forløbe korrekt der er visse forhold der skal være opfyldt i systemet: Ingen standard formularer. Flg. brugernavne skal eksistere i DTUbasen: s s Testen indeholder en metode pr. metode der skal testes. Test-metoderne indeholder alt det data de selv skal bruge og test-metoderne er derfor fuldstændig uafhængige af hinanden.

41 5.2 Brugervenlighedstest Brugervenlighedstest For at undersøge hvordan brugere oplever siden, og hvilke forbedringer man eventuelt kan lave på siden i fremtiden, har vi udført en brugervenlighedstest af systemet Metoden Vi har udført testen efter samme model som der blev undervist i, i kurset Usability Engineering på DTU. Metoden er den alment anerkendte tænke-højt metode, der bl.a. er beskrivet i bogen Brugervenligt webdesign, skrevet af Rolf Molich. Metoden går ud på at lade en række testdeltagere udføre nogle på forhånd definerede opgaver ved hjælp af webstedet. Mens deltagerne løste opgaverne, blev de bedt om at tænke højt således at vi kunne følge med i hvordan brugeren tænker når de navigerer rundt på siden. Til sidst bliver testpersonernes løsninger på opgaverne sammenlignet, for at give en indikation om hvor brugervenlig webstedet er Testopgaver Administratorer af systemet forventes at have læst Administrator vejledningen til systemet, og vi har derfor valgt at fokusere på opgaver som en studerende kan komme ud for. Der er kun brugt 3 forskellige opgaver, der tester 3 af de vigtigste funktioner på siden, set fra en studerendes synsvinkel. Du skal lige til at starte i praktik og har fået at vide at før du kan starte, skal du logge ind på og udfylde Bilag08. Du har nu skrevet første udkast af din praktik rapport, og gemt den på skrivebordet/praktikrapport.doc. Find en måde at vise den til dine vejledere Du har et spørgsmål til din eksterne vejleder i virksomheden og har hverken hans telefonnummer eller adresse. Hvad gør du?

42 32 Test Testpersoner Vi havde 3 testpersoner til at teste systemet. Man kunne med fordel have ladet flere brugere teste siden, men grundet tidspres med testen, valgte vi at nøjes med 3 deltagere. Alle testdeltagere var i alderen år og bachelorstuderende på DTU. Ingen af de studerende læser civil software, eller diplom IT, så det skal understreges at de reelt ikke er i målgruppen for det system der testes. Alligevel er de repræsentative for brugere af systemet, da man antages at have en hvis erfaring med at benytte internettet når man er studerende på DTU Testresultater Testdeltagernes evne til at løse opgaven blev vurderet på en skala fra 1-3: 1. Opgaven løst uden problemer 2. Opgaven løst efter utilfredsstillende lang tid (vurderet af testleder) 3. Opgaven ikke løst. Bruger gav op Opgave/deltager Udfyld bilag Upload praktikrapport Send besked Vurdering af testresultater Det viser sig at de studerende har sværere ved at udføre opgaverne, end godt er. Det største problem virker generelt som manglen på logik, i forbindelse med upload af filer, og besked afsendelse. Filupload For at uploade filer, skal man markere den mappe man ønsker at uploade filen til, og derefter klikke på upload fil. Dette gør brugeren irriteret fordi siden loader. Problemet kunne løses ved evt. At lave en højreklik menu på hver mappe. Dette forekommer brugerne meget mere intuitivt, end at vælge en mappe og derefter vælge at uploade en fil til den pågældende mappe.

43 5.2 Brugervenlighedstest 33 Send meddelelse Det tog mange af testpersonerne lang tid at finde ud af at de skulle vælge en bruger, før de blev præsenteret for muligheden for at sende en meddelelse til brugeren. Her kunne problemet løses ved at lave en send meddelelse knap til højre for brugernavnet i listen og hvilke brugere der er tilknyttet den aktuelle sag. På den måde gør man brugeren opmærksom på at det er muligt at sende en besked til en bruger, før de selv finder ud af at klikke på en bruger og se muligheden. Disse 2 punkter er ikke kritiske fejl, idet brugerne var istand til at udføre opgaven. Det ville dog hjælpe på brugernes oplevelse af stedet hvis de foreslåede ændringer blev implementeret.

44 34 Test

45 Kapitel 6 Konklusion Det udviklede system, endte med at opfylde kravene fra kravspecifikationen. Vi har igennem projektperioden fulgt udviklingen af et stykke software, fra de indledende diskussioner med kunden, over design,implementering og integrering med eksisterende systemet, til dokumentation af det endelige produkt. Systemet er blevet testet i en vis udstrækning, men som med alle andre programmer, vil der stadig være fejl, der først opdages når programmet bliver brugt i produktion. Brugervenlighedstesten gav os desværre først sent i forløbet nogle punkter der skulle forbedres, så forbedringerne er ikke blevet implementeret. Resultaterne af testen vil selvfølgelig være at finde på listen over forslag til udvidelser Alt i alt er kravspecifikationen overholdt, og vi er godt tilfredse med det endelige system. 6.1 Forslag til udvidelser Hvis der skal videreudvikles på systemet, ville følgende udvidelser være oplagte:

46 36 Konklusion Mere logisk filupload - højrekliksmenu Mere dynamik - Evt. brug af AJAX

47 Bilag A Brugermanual Generelt tilrådes det at sørge for at din browser ikke vil blokere pop-up s fra Denne manual findes også online, på

48 38 Brugermanual Indlogning Brugere tilknyttet DTU Du får adgang til systemet ved at åbne din favoritbrowser, fx Firefox eller Internet Explorer, og gå ind på adressen: Her vil du blive mødt med en indlogningsskærm: Her indtaster du dit DTU login og tilhørende adgangskode. Dvs. samme brugernavn og adgangskode som til fx CampusNet.

49 39 Eksterne brugere Du får adgang til systemet ved at åbne din favoritbrowser, fx Firefox eller Internet Explorer, og gå ind på adressen: Her vil du blive mødt med en indlogningsskærm: Her indtaster du det udleverede brugernavn og tilhørende adgangskode. Kontakt Praktik Koordinatoreren hvis du ikke har modtaget disse informationer.

50 40 Brugermanual Sagsoversigt Efter korrekt indlogning vil du blive præsenteret for den sag du er tilknyttet: Siden er delt op i fire sektioner: Brugere, Formularer, Dokumenter og Hændelser. Under brugere kan du se hvilke brugere der er tilknyttet sagen. Under formularer kan du se hvilke formularer der er tilknyttet sagen. Her har

51 41 du også mulighed for at udfylde formularerne. Under dokumenter kan du se og oprette private filer. Disse filer kan kun ses i din sag. Hvis du derimod ønsker at dele en fil med alle brugere i systemet, kan filer uploades til Public mappen. I begge tilfælde kan du oprette mapper til at putte dokumenterne i. Se bruger information Hvis du fra Sagsoversigten ønsker mere information om en bruger i sagen, k- likkes der med musen på personens navn. Herefter vil du blive præsenteret for et skærmbillede lignende dette: Her kan du se et billede af den pågældende bruger, samt finde mobil-nummer.

52 42 Brugermanual Send besked Hvis du ønsker at sende en besked til brugeren klikkes på Send meddelelse til bruger. Her skrives din besked i feltet og trykkes send. Herefter bliver der sendt en intern besked til den pågældende bruger. Hvis du ønsker at brugeren skal have en med oplysning om at du har sendt en besked sættes der kryds i Send som inden der trykkes på Send. Du får herefter bekræftelse på at beskeden er sendt. Læs besked Ved at holde musen over Beskeder i menuen får du mulighed for at vælge Indbakke. Herunder vil du kunne se alle beskeder der er sendt til dig.

53 43 Udfyld formular På Sagsoversigtssiden vælges Udfyld ud for den formular der skal udfyldes. Her bliver du præsenteret for de forskellige felter i formularen. Du kan nu udfylde formularen og vælge om formularen skal gemmes som kladde eller ej. Når du er færdig trykkes på Submit.

54 44 Brugermanual Upload dokument Fra Sagsoversigtssiden vælger du først hvilken mappe du vil uploade dit dokument til. Herefter trykkes på Upload dokument. Så trykkes på Gennemse... eller Browse... og filen vælges. Herefter trykkes på Upload dokument. Vent herefter til teksten Upload gennemført! vises. Dette kan godt tage lidt tid alt efter hvor stor en fil du uploader.

55 Bilag B Adminstratormanual Denne manual findes også online, på

56 46 Adminstratormanual Tilføj/fjern bruger (opret/slet sag) Hold musen over Brugere og vælg Tilføj. Du kan enten oprette en enkelt sag ud fra et studienummer eller en hel række sager ud fra en fil med studienumre. Hvis du ønsker at oprette en enkelt sag, indtastes den studerendes studienummer i Studienummer og der trykkes på Tilføj. Hvis du derimod ønsker at slette sagen trykkes på Slet. Hvis du ønsker at oprette mange sager på en gang, trykkes på Gennemse... / Browse... og der vælges en fil indeholdende studienumre. Studienumrene skal være adskilt med et af flg. tegn:, ; : -

57 47 Tilføj bruger til sag På Sagsoversigtsiden i brugersektionen vælges den ønskede bruger på dropdown-listen. Herefter trykkes på Tilføj bruger til sagen. Fjern bruger fra sag På Sagsoversigtsiden i brugersektionen trykkes på Fjern ud fra den ønskede bruger. Opret formular Hold musen over Formularer i menuen. Herefter trykkes på Ny Herefter har du mulighed for at tilføje felter til formularen:

58 48 Adminstratormanual For hvert felt skal der indtastes flg. oplysninger: Feltnavn Det navn brugeren skal præsenteres for ved udfyldelse. Beskrivelse En beskrivelse af feltet. Heri kan også indtastes evt. hjælp til brugeren. Type Her kan vælges mellem flg. typer: YESNO - Ja eller Nej STEXT - (Short text) - En kort tekst (en linie) LTEXT - (Long text) - En lang tekst (flere linier) DROPDOWN - En dropdown-liste, valg-mulighederne indtastes i Data separeret med ;. Bedst til lister med mange muligheder.

59 49 RADIO - En mængde radio-knapper, valg-mulighederne indtastes i Data separeret med ;. Bedst til lister med få muligheder. FIRSTNAME - Indsætter automatisk den studerendes fornavn. LASTNAME - Indsætter automatisk den studerendes efternavn. FULLNAME - Indsætter automatisk den studerendes fulde navn. Standard-formular Hvis der sættes kryds i denne boks, vil formularen blive automatisk tilføjet til nye sager nå r de oprettes. Tilføj antal felter Hvis du ønsker at tilføje flere felter til formularen indtastes det ønskede antal her. Felterne oprettes næste gang der trykkes Gem. Når du har udfyldt alle felter trykkes Gem. Tilføj formular til sag På Sagsoversigtsiden i formularsektionen vælges den ønskede formular på dropdown-listen. Herefter trykkes på Tilfø j formular til sagen. Fjern formular fra sag På Sagsoversigtsiden i formularsektionen trykkes på Fjern ud fra den ønskede formular. Ændre brugerinformation Hvis du fra Sagsoversigten ønsker at ændre en brugers rettigheder, klikkes der med musen på personens navn. Herefter vil du blive præsenteret for et skærmbillede lignende dette:

60 50 Adminstratormanual Ved status ønskes den nye status brugeren skal have. Herefter trykkes på Updater.

61 51 Send SMS-besked til bruger Hvis du fra Sagsoversigten ønsker at sende en SMS-besked til en bruger, klikkes der med musen på personens navn. Klik herefter på Send meddelelse til bruger. Her skrives din besked i feltet og Send som SMS krydses af. Herefter trykkes send.

62 52 Adminstratormanual

63 Bilag C Kildekode C.1 App Code C.1.1 Cases/Case.cs 1 using System ; using System. Data ; 3 using System. Configuration ; using System. Web ; 5 using System. Web. Security ; using System. Web. UI ; 7 using System. Web. UI. WebControls ; using System. Web. UI. WebControls. WebParts ; 9 using System. Web. UI. HtmlControls ; using System. Collections. Generic ; 11 namespace Cadoc. Cases 13 public class Case : DBobject 15 #region Vars private int _CaseID ; 17 private Users. SiteIdentity _Owner ; private string _Comment ; 19 #endregion 21 #region Constructors

64 54 Kildekode public Case ( int CaseID ) 23 DBdata data = new DBdata ( " SELECT * FROM Cases WHERE CaseID = " + CaseID ) ; 25 init ( data ) ; 27 public Case ( int OwnerID, string Comment ) 29 DBdata data = new DBdata ( " INSERT INTO Cases ( OwnerID, Comment ) values (" + OwnerID + ", " + Comment + " ) ; SELECT * FROM Cases WHERE CaseID = LAST_INSERT_ID ()" ) ; DataRow t = data. GetDataSet ( ). Tables [ 0 ]. Rows [ 0 ] ; 31 this. _CaseID = ( int ) t [ " CaseID " ] ; new Cadoc. Events. Event ( this, new Cadoc. Users. SiteIdentity ( OwnerID ), Cadoc. Events. EventType. INFORMATION, " Sagen blev oprettet!", Cadoc. Users. UserStatus. DISABLED ) ; 33 init ( data ) ; 35 private void init ( DBdata data ) 37 DataRow t = data. GetDataSet ( ). Tables [ 0 ]. Rows [ 0 ] ; this. _CaseID = ( int ) t [ " CaseID " ] ; 39 this. _Owner = new Cadoc. Users. SiteIdentity ( ( int ) t [ " OwnerID " ] ) ; this. _Comment = t [ " Comment " ]. ToString ( ) ; 41 #endregion 43 #region Getters n setters 45 # region Users public List < Cadoc. Users. SiteIdentity > Users 47 get 49 List < Cadoc. Users. SiteIdentity > list = new List < Cadoc. Users. SiteIdentity >() ; 51 DBdata data = new DBdata (" SELECT * FROM AssociationCaseUser WHERE CaseID = " + CaseID ); foreach ( DataRow dr in data. GetDataSet (). Tables [0]. Rows ) 53 list. Add ( new Cadoc. Users. SiteIdentity (( int )dr [" UserID "]) ); 55 return list ; public void AddUser ( Cadoc. Users. SiteIdentity User ) 61 new DBdata (" INSERT INTO AssociationCaseUser ( CaseID, UserID ) values (" + this. _CaseID + ", " + User. UserID + "); SELECT 1") ;

65 C.1 App Code 55 this. AddEvent ( Cadoc. Events. EventType. INFORMATION, " Tilføjede brugeren " + User. FullName + " til sagen ", Cadoc. Users. UserStatus. DISABLED ); 63 public void RemoveUser ( Cadoc. Users. SiteIdentity User ) 65 new DBdata (" DELETE FROM AssociationCaseUser WHERE CaseID = " + this. _CaseID + " AND UserID = " + User. UserID + " LIMIT 1") ; 67 this. AddEvent ( Cadoc. Events. EventType. INFORMATION, " Fjernede brugeren " + User. FullName + " fra sagen ", Cadoc. Users. UserStatus. DISABLED ); 69 # endregion 71 # region Forms public List < Cadoc. Forms.Form > Forms 73 get 75 List < Cadoc. Forms.Form > list = new List < Cadoc. Forms. Form >() ; 77 DBdata data = new DBdata (" SELECT * FROM AssociationCaseForm WHERE CaseID = " + CaseID ); foreach ( DataRow dr in data. GetDataSet (). Tables [0]. Rows ) 79 list. Add ( new Cadoc. Forms. Form (( int )dr [" FormID "]) ); 81 return list ; public void AddForm ( Cadoc. Forms. Form Form, DateTime deadline ) 87 new DBdata (" INSERT INTO AssociationCaseForm ( CaseID, FormID, Deadline ) values (" + this. _CaseID + ", " + Form. FormID + ", " + deadline. Ticks + ") "); this. AddEvent ( Cadoc. Events. EventType. INFORMATION, " Tilføjede formularen " + Form. FormName + " til sagen ", Cadoc. Users. UserStatus. DISABLED ); 89 public void RemoveForm ( Cadoc. Forms. Form Form ) 91 new DBdata (" DELETE FROM AssociationCaseForm WHERE CaseID = " + this. _CaseID + " AND FormID = " + Form. FormID + " LIMIT 1") ; 93 this. AddEvent ( Cadoc. Events. EventType. INFORMATION, " Fjernede formularen " + Form. FormName + " fra sagen ", Cadoc. Users. UserStatus. DISABLED ); 95 # endregion 97 # region Events

66 56 Kildekode public List < Cadoc. Events. Event > Events 99 get 101 List < Cadoc. Events. Event > list = new List < Cadoc. Events. Event >() ; 103 DBdata data = new DBdata (" SELECT * FROM Events WHERE VisibleFor <= " + ( int )(( Cadoc. Users. SiteIdentity ) HttpContext. Current. User. Identity ). UserStatus + " AND CaseID = " + CaseID + " ORDER BY LastModified DESC "); foreach ( DataRow dr in data. GetDataSet (). Tables [0]. Rows ) 105 list. Add ( new Cadoc. Events. Event (( int )dr [" EventID "]) ); 107 return list ; public DataSet EventsDS 113 get 115 DataSet ds = new DataSet (); ds. Tables. Add (); 117 ds. Tables [0]. Columns. Add (" EventID "); ds. Tables [0]. Columns. Add (" EventMessage "); 119 ds. Tables [0]. Columns. Add (" EventType "); foreach ( Cadoc. Events. Event e in this. Events ) 121 ds. Tables [0]. Rows. Add (e. EventID, e. EventMessage, ( int )e. EventType ); 123 return ds; public void AddEvent ( Events. EventType Type, string Message, Users. UserStatus VisibleFor ) 129 new Events. Event (this, ( Cadoc. Users. SiteIdentity ) HttpContext. Current. User. Identity, Type, Message, VisibleFor ); 131 # endregion 133 # region Documents 135 public List < Cadoc. Documents. Document > Documents 137 get 139 List < Cadoc. Documents. Document > list = new List < Cadoc. Documents. Document >() ;

67 C.1 App Code DBdata data = new DBdata (" SELECT * FROM Documents WHERE CaseID = " + CaseID ); foreach ( DataRow dr in data. GetDataSet (). Tables [0]. Rows ) 143 list. Add ( new Cadoc. Documents. Document (( int )dr [" DocumentID "]) ); 145 return list ; public DataSet DocumentsDS 151 get 153 DataSet ds = new DataSet (); ds. Tables. Add (); 155 ds. Tables [0]. Columns. Add (" DocumentID "); ds. Tables [0]. Columns. Add (" DocumentName "); 157 foreach ( Cadoc. Documents. Document d in this. Documents ) 159 ds. Tables [0]. Rows. Add (d. DocumentID, d. DocumentName ); 161 return ds; public void AddDocument ( string Name, int FolderID, int Public, int Locked, string Mime, byte [] Data ) 167 new Documents. Document ( Name, (( Cadoc. Users. SiteIdentity ) HttpContext. Current. User. Identity ), this, null, FolderID, Public, Locked,Mime, Data ); 169 # endregion 171 public int CaseID 173 get 175 return _CaseID ; public string Comment 181 get 183 return _Comment ; 185 public Users. SiteIdentity Owner 187

68 58 Kildekode get 189 return _Owner ; # endregion 195 # region DBobject Members 197 public void Delete () 199 DBdata d = new DBdata (" DELETE FROM Cases WHERE CaseID =" + this. _CaseID + "; SELECT 1;") ; 201 d = new DBdata (" SELECT * FROM Datasets WHERE CaseID =" + this. _CaseID ); foreach ( DataRow dr in d. GetDataSet (). Tables [0]. Rows ) 203 new Data. DataSet (( int )dr [" DatasetID "]). Delete (); 205 d = new DBdata (" DELETE FROM Folder WHERE CaseID =" + this. _CaseID + "; SELECT 1;") ; 207 d = new DBdata (" DELETE FROM Messages WHERE CaseID =" + this. _CaseID + "; SELECT 1;") ; Cadoc. Users. SiteIdentity. RemoveUnassociatedUsers (); 209 foreach ( Cadoc. Events. Event e in this. Events ) 211 e. Delete (); 213 foreach ( Cadoc. Documents. Document doc in this. Documents ) 215 doc. Delete (); 217 foreach ( Cadoc. Users. SiteIdentity s in this. Users ) 219 this. RemoveUser (s); 221 foreach ( Cadoc. Forms. Form f in this. Forms ) 223 this. RemoveForm (f); public bool Update () 229 new DBdata (" UPDATE Cases SET Comment = " + this. Comment + ", OwnerID = " + this. Owner. UserID ); 231 return true ; 233 # endregion 235

69 C.1 App Code 59 C.1.2 Data/DataSet.cs using System ; 2 using System. Data ; using System. Configuration ; 4 using System. Web ; using System. Web. Security ; 6 using System. Web. UI ; using System. Web. UI. WebControls ; 8 using System. Web. UI. WebControls. WebParts ; using System. Web. UI. HtmlControls ; 10 using System. Collections. Generic ; 12 namespace Cadoc. Data 14 public class DataSet : DBobject 16 private int _DatasetID ; private Users. SiteIdentity _User ; 18 public DataSet ( int DataSetID ) 20 DBdata data = new DBdata ( " SELECT * FROM Datasets WHERE DatasetID = " + DataSetID ) ; DataRow t = data. GetDataSet ( ). Tables [ 0 ]. Rows [ 0 ] ; 22 this. _DatasetID = ( int ) t [ " DatasetID " ] ; this. _User = new Cadoc. Users. SiteIdentity ( ( int ) t [ " UserID " ] ) ; 24 public DataSet ( System. Collections. Specialized. NameValueCollection FormElements, int UserID ) 26 int CaseID = Convert. ToInt16 ( FormElements [ " ctl00$maincontent$caseid " ] ) ; 28 int Draft = ( FormElements [ " ctl00$maincontent$isdraft " ] == "on" )? 1 : 0 ; DataRow t ; 30 try 32 DBdata data = new DBdata ( " SELECT * FROM Datasets WHERE UserID = " + UserID + " AND CaseID = " + CaseID + "" ) ; data = new DBdata ( " UPDATE Datasets SET Draft = " + Draft + " WHERE UserID = " + UserID + " AND CaseID = " + CaseID + "; SELECT * FROM Datasets WHERE UserID = " + UserID + " AND CaseID = " + CaseID ) ; 34 t = data. GetDataSet ( ). Tables [ 0 ]. Rows [ 0 ] ; 36 catch ( Exception ) 38 DBdata data = new DBdata ( " INSERT INTO Datasets ( UserID, CaseID, Draft ) values (" + UserID + ", " + CaseID + ", " + Draft + "); SELECT * FROM Datasets WHERE DatasetID = LAST_INSERT_ID ()" ) ; t = data. GetDataSet ( ). Tables [ 0 ]. Rows [ 0 ] ;