Sags- og dokumentstyringssystem

Transkript

1 DIPLOMINGENIØR IT EKSAMENSPROJEKT Sags- og dokumentstyringssystem Jesper Christiansen Kongens Lyngby, juni 2008 IMM-B.Eng

2 Danmarks Tekniske Universitet Institut for Informatik og Matematisk Modellering Bygning 321, 2800 Kongens Lyngby Tlf , Fax Vejledere: Stigh Høgh - sh@imm.dtu.dk Mads Nyborg - mn@imm.dtu.dk IMM-B.Eng

3 Abstract This project, Case- and Documentmanagementsystem is developed as a web-application using ASP.NET 3.5 under Visual Studio 2008, with a Microsoft SQL Server 2005 to persist the systems data. It is developed as a prototype to help with the management of the internship- and examprojectperiod on the Diplomingeniør IT education (B.Sc) on The Technical University of Denmark. The goal of the system is to create a product that is suited to the above process. It is possible to create and define cases and their members. Create generic input forms for use in those cases, as a way to submit information to the system, regarding the specific case. Those forms are implemented using XML and XSLT. The systems includes a messaging part, where members of the case can publish public messages. A file-area where it is possible to upload and store files, which information cannot be handled using the forms. Each case has a timeline, where members of the case can see the progress of the case and what to do next. These timeline events can be defined in the system. It is possible to set up generic web-forms and assign them to cases, either as standard documents or to specified cases. There is also a small statistic section, where it is possible to see how many cases each supervisor in the system have had. The testing of the system is mainly done as a user-test, but there are also developed a small set of NUnit automated test-cases. It uses the membership provider in ASP.NET to handle the authorization and roles in the system.

4 Forord 1 Denne rapport er et produkt af det afsluttende eksamensprojekt for Diplomingeniør IT uddannelsen ved Danmarks Tekniske Universitet. Projektet tæller for 20 ECTS point. Rapporten er bygget op omkring implementeringen af et Sags- og Dokumentstyringssystem der skal skræddersyes til at varetage praktik- og eksamensprojektperioden for studerende ved Diplomingeniør IT retningen. Systemet ønskes udviklet som en web-applikation i ASP.NET 3.5, med en bagvedliggende database. Med denne rapport, medfølger 1 stk CD, som er at finde på bagerste side. CD en indeholder kildekode, diagrammer, samt en kopi af rapporten. Der rettes en stor tak til de personer, der har stillet opgaven - samt ydet support og vejledning i forbindelse med dette projekt. Heriblandt mine vejledere Stig Høgh og Mads Nyborg. Samtidig vil jeg gerne takke de personer, som har taget sig tid til at hjælpe med at læse denne rapport igennem, samt bidrage med test af systemet. Vil også gerne give en tak til mine venner og mine forældre, som har bakket mig op gennem tilblivelsen af dette projekt. Lyngby, juni 2008 Jesper Christiansen, s ii

5 Indholdsfortegnelse 1 Forord ii 2 Introduktion Indledning Formål Problembeskrivelse Udfordringer ASP.NET Generiske indtastningsformularer XSL og XSLT Filstruktur og versionsstyring Planlægningsfase 7 4 Metode Udviklingsmodel Tidsplan Test-strategi Analyse Risikovurdering Kravspecifikation Interessenter Afgrænsning Domænemodel Use cases Aktører Use case kontekstdiagram Prioritering af use cases Teknologier ASP.NET LINQ (Language Integrated Query) Design Arkitektur N-tier arkitektur Business-lag klassediagram Data-lag klassediagram Anvendte patterns Facade Page-controller

6 7.5.3 Singleton Database Valg af database Datamodel Stored procedures Sekvensdiagrammer Opret sag (use case 5) Godkend praktikoplysninger (use case 10) Brugerinterface Implementering Oprettelse af standarddata Roller Superbruger Events på tidslinie Identifikation af sager Code-behind filerne Fluidlayout Web.config Profiler Applikationsindstillinger Page Base Class Sikkerhed Roller Rettigheder på folderniveau Rettighedsfordelingen Håndtering af fejl Opret sag Godkend praktikoplysninger Notifikationer Opret indtastningsformular Oprettelse af indtastningsformularen Udfyld indtastningsformular Validering Visning af indtastningsformular Rediger indtastning Filstruktur Download af filer Stored procedures Datepicker Test Authentication Meddelelser Deltagerliste

7 9.4 Fildeling Administrér System administration Opret indtastningsformular Udfyld indtastningsformular Automatiseret test med NUnit Procesevaluering Konklusion Fremtidige udvidelser Referencer Appendiks i 1 Appendiks - Use cases i 1.1 Use case 1 - Opret indtastningsformular i 1.2 Use case 2 - Udfyld indtastningsformular iii 1.3 Use case 3 - Login iv 1.4 Use case 4 - Opret bruger v 1.5 Use case 5 - Opret sag vii 1.6 Use case 6 - Opret meddelelse viii 1.7 Use case 7 - Upload fil x 1.8 Use case 8 - Tilføj medlemmer xii 1.9 Use case 9 - Rediger sagsdata xiii 1.10 Use case 10 - Godkend praktikoplysninger xiv 1.11 Use case 11 - Godkend abstract xv 1.12 Use case 12 - Godkend praktikophold xvi 1.13 Use case 13 - Godkend eksamensprojekt xvii 1.14 Use case 14 - Tilknyt indtastningsformular xviii 1.15 Use case 15 - Opret ny standardmeddelelse xix 1.16 Use case 16 - Rediger events xx 2 Appendiks - Sekvensdiagrammer xxi 2.1 Opret indtastningsformular xxi 2.2 Udfyld indtastningsformular xxii 2.3 Opret bruger xxiii 2.4 Opret meddelelse xxiv 2.5 Upload fil xxv 2.6 Tilføj medlemmer xxvi 2.7 Rediger sagsdata xxvii 2.8 Godkend abstract xxviii 2.9 Godkend praktikophold xxix 2.10 Godkend eksamensprojekt xxx 2.11 Tilknyt indtastningsformular xxxi 2.12 Rediger events xxxii

8 2.13 Opret ny standardmeddelelse xxxiii 3 Appendiks - Opgaveformuleringen xxxiii 4 Appendiks - Database xxxv 5 Appendiks - Prøv systemet xxxvi 6 Appendiks - Brugervejledning xxxvii

9 Introduktion Indledning Denne rapport er skrevet i forbindelse med det afsluttende eksamensprojekt for Diplomingeniør IT uddannelsen, ved Danmarks Tekniske Universitet (DTU). Projektet er stillet af Mads Nyborg og Stig Høgh, Institut for Informatik og Matematisk Modellering (IMM), DTU. Det fulde projektforløb omhandler en rapport og en webapplikation, disse er udarbejdet i perioden 7. januar til 7. juni Der skal udvikles et "Sags- og dokumentstyringssystem", som en webapplikation i ASP.NET 3.5 med en bagved liggende MSSQL Server database. Det hele er udviklet i Microsoft Visual Studio Denne webapplikation skal gøre administrationen af praktik- og eksamensprojektdelen på Diplom IT retningen mere overskuelig og lettere at have med at gøre for de to praktikkoordinatorer. I øjeblikket anvendes DTU s CampusNet, men dette er ikke bygget til de opgaver der er i forbindelse med dette scenarie og kan derfor ikke give noget let tilgængeligt overblik over det hele. Ligeledes skal der indbygges en bedre statistik del, så det er muligt at holde styr på hver enkelt vejleder, samt hvor mange studerende denne har haft inden for en specificeret tidsramme. Rational Unified Process (RUP) er valgt som grundlag for udviklingsmodellen i dette projekt. Dette giver et iterationspræget udviklingsforløb, bestående af 4 iterationer, hver indeholdende: - Inception - Elaboration - Construction Normalt efterfølges hele forløbet af en transition fase, som er en deployment-fase hos kunden. Denne fase springes over, da dette er en prototype og derfor ikke skal deployes hos DTU inden for rammerne af dette projekt. 1

10 Kapitel 2. Introduktion Formål Formålet med dette projekt, er at udvikle en prototype af et "Sags- og Dokumentstyringssystem". Systemet skal udvikles, med det henblik at lette arbejdet for praktikkoordinatorene i forbindelse med den obligatoriske praktik og eksamensprojekt ordning på Diplomingeniør IT uddannelsen på DTU. Formålet med projektet er følgende: - Effektiviseret arbejdsproces i forbindelse med praktik og eksamensprojekt - Målrette meddelelser udsendt i systemet, så man er sikker på modtager ser dem - Bedre overblik - Effektivitet i form af udsendelse af standardbeskeder, baseret på situationen - Bedre helheldsoplevelse - Generisk konfigurerbare dele - Lille statistik del

11 Kapitel 2. Introduktion Problembeskrivelse Problemet i den nuværende CampusNet løsning, ligger hovedsageligt i, at CampusNet ikke er udviklet som et værktøj der skal holde styr på ting. CampusNet er bygget som en applikation hvor det er nemt og hurtigt at dele information med andre, om kurser, materiale til disse, se sine informationer osv. CampusNet er et glimrende og velfungerende system, til det formål det er lavet til. Men i forbindelse med håndtering af praktiksager og eksamensprojekter, har det en række mangler. Disse mangler gør, at hele processen hurtig bliver uoverskuelig for både praktikkoordinatorerne og de studerende. Dette råder Sags- og Dokumentstyringssystemet bod på, da det er udviklet til opgaven. I det nuværende CampusNet, foregår det på den måde, at den studerende har en række bilag som han/hun skal sørge for at holde ajour, med informationer om praktikplads, eksamensprojekt m.m. Disse bilag er word-dokumenter, som skal downloades fra systemet, opdateres og derefter uploades igen. Når et bilag er opdateret, er det op til den studerende at udsende en meddelelse i systemet, om at denne handling er foretaget og at man ønsker respons på dette. Denne meddelelse sendes igennem CampusNets meddelelsessystem. CampusNet er udarbejdet på den måde, at alle er tilmeldt nogle grupper. Når en meddelelse så sendes ud i den pågældende gruppe, så modtager alle deltagere i gruppen den meddelelse - uanset hvem den er henvendt til. Dette betyder, at hvis man som praktikkoordinator har 50 studerende der skriver eksamensprojekt, så er man indmeldt i 50 forskellige grupper - og modtager al kommunikation der bliver foretaget i disse grupper, uanset om det vedrører en eller ej. Dette gør, at praktikkoordinatorerne hurtigt kan miste overblikket i forbindelse med meddelelser udsendt til dem. Lige nu fungerer det ved, at alle de meddelelser udsendt i systemet, bliver sendt til en fælles -indbakke. Praktikkoordinatorerne går så ind i den indbakke og foretager den nødvendige handling, hvorefter en slettes. Det ville være mere praktisk, hvis praktikkoordinatorerne havde en oversigtsside når de loggede ind i systemet, hvor de kunne se hvilke beskeder der var til dem - og på den måde fik al unødvendig støj sorteret fra, i form af de andre meddelelser - medmindre de specifikt havde interesse i at se disse. Det samme gælder de studerende. Der ligger en række frister for hvornår de skal foretage sig noget i systemet. Når de starter i praktik, skal de senest 3 uger efter start, have udarbejdet et abstract til deres eksamensprojekt. Medmindre de er tidligere datamatikere, så skal abstract ligge klar, når de starter i praktik, da deres praktikperiode er kortere. Grunden til denne frist, er at DTU skal have tid til at finde en vejleder i forbindelse med deres projekt, inden starten på eksamensprojektet (typisk lige efter endt praktikforløb). Det kan dog til tider være svært for de studerende at overskue hvornår hvad skal ske. Der-

12 Kapitel 2. Introduktion 4 for skal de også have en oversigtsside i systemet, hvor de på en tidslinie kan se hele deres forløb, i takt med at tingene skal ske. De vil kunne se deres praktikforløb på en tidslinie, med nummerede uger. Samtidig vil de kunne se hvilken uge de befinder sig i, i forløbet, og hvornår de næste ting skal ske. Bilagene, word-dokumenterne, som blev nævnt tidligere, ønskes integreret i systemet. Der ønskes en mulighed, for at oprette generiske indtastningsformularer. Det skal være muligt for praktikkoordinatorerne at udarbejde disse formularer, udspecificere om visse felter er obligatoriske og evt. tilknytte regular expressions til et felt, i forbindelse med validering af data. Når en studerende har udfyldt en sådan formular, har han/hun mulighed for at "sende indholdet til godkendelse". Dette betyder, at praktikkoordinatorerne modtager en notifikation på deres notifikationsside, hvorfra de har mulighed for at gå til det pågældende input, godkende det eller afvise det, med en begrundelse, hvorefter den studerende modtager en meddelelse. Al kommunikation i forbindelse med praktik og eksamensprojekt skal foregå i systemet. Som det er nu, foregår det i CampusNets meddelelsessystem. For at effektivisere processen så meget som muligt, er der udarbejdet en række standardmeddelelser på givne situationer den studerende måtte stå i. Disse standardmeddelelser er gemt i et Excel ark. Dette betyder, at når praktikkoordinatorerne skal udsende et standardsvar, skal de først åbne et Excel ark, finde fanebladet med standardsvar og kopiere pågældende svar, hvorefter de skal sætte det ind i feltet på CampusNet. I dette nye system, ville det være meget mere hensigtsmæssigt hvis de blot kunne vælge svaret fra en dropdown menu, hvorefter dette svar ville blive udsendt til den studerende. Dette giver et bedre system, og gør det nemmere for både de administrative kræfter og de studerende. Samtidig ønskes en lille statistik del, hvor man har mulighed for at se en liste over DTU vejledere, samt hvor mange projekter de har været vejledere på.

13 Kapitel 2. Introduktion Udfordringer I dette afsnit vil jeg komme ind på de ting, jeg mener kan give mig problemer i forbindelse med udviklingen af dette projekt. Det værende både teknologiske udfordringer, men også dele i selve implementeringen ASP.NET Jeg har før stiftet bekendtskab med C#, både gennem et kursus på DTU (Windows Programmering) - men senere også i min fritid, da jeg så det som værende et interessant programmeringssprog der tiltalte mig en del - specielt fordi jeg kommer en verden der primært foregik i JAVA, var C# et nemt sprog at komme igang med. Mit kendskab til ASP.NET er dog minimalt. Jeg havde for mange år siden rodet med ASP, men det var inden.net kom på banen. Min primære interesse ligger indenfor webudvikling, dog har jeg mest beskæftiget mig med PHP, Ruby on Rails og J2EE med Serverfaces. Jeg har længe villet prøve at lave et større projekt i ASP.NET, men har ikke haft mulighed for at kaste mig ud i det. Derfor faldt det mig naturligt at prøve kræfter med ASP.NET i forbindelse med udviklingen af "Sags- og Dokumentstyringssystem". Jeg er samtidig godt klar over, at det vil komme til at koste en del mere blod, sved og tårer - end hvis jeg havde kastet mig over en af de teknologier jeg kendte. Men jeg læser til ingeniør, primært af den grund at jeg elsker teknologier, jeg elsker at lære og jeg elsker udfordringer Generiske indtastningsformularer Jeg forestiller mig at de generiske indtastningsformularer i dette projekt, må være en af de største hurdles. Jeg har en ide, om at den mest optimale måde at gribe det an, må være at gøre brug af XML. Mit kendskab til XML er ikke særlig stort, derfor kunne jeg forestille mig at det kan ende med at give en del problemer. Jeg ved dog at C# indeholder en god og effektiv XML parser og håber at dette vil hjælpe mig i forbindelse med dette XSL og XSLT For at omdanne min XML til formularer som vi kender dem, fra diverse hjemmesider, har jeg tænkt mig at gøre brug af XSL (EXTensible Stylesheet Language) og XSLT (XSL Transformations). XSLT er en del af XSL og bruges til at transformere XSL til en dokument type, i vores tilfælde XHTML. XSLT gør brug af XPath til at finde dele i XML-kilden, som matcher en eller flere definerede skabeloner. Hvis den finder noget som passer, transformerer den den matchende del til det resulterende dokument. Det er XML Stylesheets som definerer hvordan transformeringen skal foregå. Jeg har aldrig beskæftiget mig med XSL eller XSLT før - har kun læst kort om det, og det lyder som en teknologi jeg kan gøre brug af i dette projekt.

14 Kapitel 2. Introduktion Filstruktur og versionsstyring En stor del af systemet bliver filstrukturen. Hver sag skal have sin egen filstruktur tilknyttet og det skal være muligt at oprette nye mapper, som man herefter kan uploade filer til. Disse filer, formularer og indtastninger skal ligeledes versionsstyres. Det vil sige, at hvis man uploader en fil som allerede ligger i mappen - så uploader man en ny version, uden at overskrive den gamle. På samme måde fungerer det med indtastninger i formularen. Man overskriver ikke en gammel indtastning, men istedet gemmes der en ny version - dette er for at sikre sporbarhed i sagen.

15 Planlægningsfase 3 På grund af min minimale viden inden for ASP.NET, brugte jeg tiden i ugerne op til projektstart, på at erhverve mig bøger indenfor området, samt at sætte mig ind i hvordan ASP.NET fungerede. Bøgerne har jeg gjort meget brug af i løbet af tilblivelsen og disse kan klart anbefales for andre der skal igang med dette interessante sprog. Jeg brugte blandt andet Pro ASP.NET 3.5 in C# 2008[1] og bogen Introducing Microsoft LINQ[2]. Ligeledes brugte jeg tiden til at sætte IDE og database op på henholdsvis min stationære og bærbare computer. Jeg satte en subversion server op hos Dreamhost.com, så jeg havde et sted at checke min kode ind, når jeg var færdig med at implementere noget nyt. Dette gjorde at jeg hele tiden havde en backup, på en ekstern maskine - og samtidig lettede det min arbejdsproces, da det var nemt at hente ned til de forskellige maskiner jeg arbejdede på. Jeg gjorde brug af Trac 1, som er et web-baseret tracking system til software projekter. Det indeholder integration med subversion, så man hurtigt kan danne sig et overblik over de forskellige commits, samt hvilke versioner af filer man arbejder på. Samtidig med dette, har det en god milestone integration, så man hurtigt kan danne sig et overblik på timelines, over hvor mange af de specificerede features man har implementeret. Dette har hjulpet mig en del, gennem de enkelte iterationer, da jeg hurtigt kunne danne mig et overblik over hvor meget jeg manglede at implementere i henhold til planen

16 Metode Udviklingsmodel Dette projekt er delt op i 4 iterationer, der følger Rational Unified Process (RUP) modellen. Hver iteration gennemløber disse tre faser. - Inception har det formål at skabe overblik over den kommende iteration og projektet. Den indeholder minimal forundersøgelse/foranalyse. Man ønsker at finde visionen i forbindelse med projektet, samt identificere interessenter og værdien for dem i forbindelse med gennemførsel af den kommende iteration. Samtidig vurderer man gennemførbarheden af projektet, om man kan nå det inden for de stillede rammer, om det i det hele taget kan lade sig gøre at udvikle, så det giver den business værdi, som er ønsket. Man gennemfører en vurdering af hvilke dele, man synes er de mest centrale fra kundens perspektiv. Igennem møder med "kunden", forsøger man at fremdrive krav, gennem dialog og fremvisning af hvad man er kommet frem til. Man kan ikke forvente at kunden kender alle sine krav. De har en overordnet ide om hvad projektet skal kunne. Derfor er det udviklernes job at skabe en proces der forsøger at fremdrive disse krav. Man træffer, på baggrund af dette, en såkaldt GO/NO-GO beslutning, hvor det bestemmes om man fortsætter med projektet, eller stopper fuldstændig. - Elaboration har det formål at fastlægge hovedparten af kravene og man realiserer arkitekturen. Der arbejdes videre på domænemodel og use casene man fastlagde i inceptionsfasen, udvides med sekvensdiagrammer hvor dette er nødvendigt. Sekvensdiagrammerne udarbejdes for udvalgte scenarier, uden for komplekse beskrivelser. Når elaborationsfasen er ovre, skal man have tilstrækkelig viden om systemet og de opgaver der skal udføres, til at man kan starte på at programmere i Construction fasen. - Construction her går man igang med at udvikle systemet, så man kan ligge klar med første kørende prototype, som er klar til præsentation for kunden, efter denne fase. Tilsidst i forløbet, ligger en fase ved navn transition. Denne bliver sprunget over, da der her er tale om en prototype, der ikke som sådan skal deployes hos kunden. Til design og dokumentation af de enkelte dele af applikationen vil der blive anvendt dele af Unified Modelling Language (UML), heriblandt domænemodel, use cases og sekvensdiagrammer. Selvom jeg ikke skal igennem en egentlig transition fase, vil jeg dog alligevel deploye systemet til en ekstern webserver. Mit grundlag for dette er, at jer, som rapportlæsere, skal 8

17 Kapitel 4. Metode 9 have mulighed for at prøve systemet, hvis der er noget i er itvivl om. Samtidig vil deployment til en ekstern server kunne klargøre en masse fejl og ting der ikke er taget hånd om og på den måde sikrer man sig at systemet kan køre, når det deployes til et nyt miljø. 4.2 Tidsplan I dette afsnit kan tidsplanen over projektet ses (figur 4.2.1). Det er forsøgt at lave tidsplanen så overskuelig som mulig, uden hjælp af GANT-diagram, da jeg ikke havde adgang til et værktøj der kunne producere et sådant. Tidsplanen er listet op, iteration for iteration, med undersektioner for hver del af den givne iteration. Projektet gennemløber 4 iterationer. De første 3 iterationer, er på ca. 6 ugers længde - hvorimod den 4. og sidste iteration, kun er på 4 uger. Den 4. iteration, bliver i dette tilfælde, lidt imod UP brugt udelukkende til at gennemløbe systemet og sikre der er en sammenhæng - finde evt. fejl og udbedre disse.

18 Kapitel 4. Metode 10 Figur 4.2.1: Projektets tidsplan

19 Kapitel 4. Metode Test-strategi I dette afsnit beskrives den strategi jeg har tænkt mig at anvende i forbindelse med gennemtestning og fejlfinding i min implementering af prototypen. Mål og risici Det er klart at en gennemtestning af et program er nødvendig, både hver gang en ny funktion er implementeret men også til slut når man sidder med den endelige implementering. Dog er man nødt til at gøre sig visse overvejelser i forbindelse med de tests man udfører, for at sikre at testen afspejler den reelle anvendelse af programmet så vidt muligt. Derfor har jeg i dette delafsnit listet mine mål samt evt. risici der måtte opstå i forbindelse med gennemtestningen af dette system. - Grundig gennemgang og udarbejdelse af test-cases - når test-cases skal udarbejdes, er det vigtigt man sætter sig ned og kigger programmets funktionalitet igennem. Ud fra denne funktionalitet udarbejdes en række test-cases. Dette kan være fra de mest simple ting, til det mest avancerede. Det vigtige er, at alle test-casene tilsammen underbygger implementeringens ønskede funktionalitet, så man sikrer at programmet virker efter hensigten. Hvis man sløser i forbindelse med udarbejdelsen af test-cases, kan der opstå situationer hvor man ikke fanger fejl - hvilket kan være fatalt for systemets kørsel. - Virkeligt miljø med respektive data - når en test foretages er det vigtigt, specielt hvis det er en mere krævende implementering, at testen udføres på maskinel svarende til det som gennemsnitsbrugeren - som skal anvende systemet - sidder med. Ligeledes, hvis man har mulighed for det, kan det være en god ide at afvige fra at benytte karakterer 1, som test data. Derfor er det vigtigt, så vidt det er muligt, at tage udgangspunkt i levende mennesker og inkludere disse i ens tests. Dette giver en mere virkelighedstro form for test og sikrer liv og samspil i testen. Forskellen i at anvende karakterer og levende personer er [3]: Karakterer - en fiktiv karakter kan ikke give feedback på systemet. Det hele er styret af udvikleren, som tit - efter noget tid - opnår en form for snæversyn i forbindelse med implementeringen af et projekt. De kan ikke svare på de spørgsmål man evt. måtte have ang. deres syn på hvordan tingene virker. De kan ikke påpege hvis noget virker ulogisk, eller en sætning ikke giver mening for en ny bruger. Fiktive karakterer er fejlfri, og kan derfor ikke introducere nye fejl - som herefter kan udbedres, i dit system. Levende personer - levende mennesker kan give respons. De kan fortælle dig hvornår noget ikke føles rigtigt. De opdager hvis noget ikke giver mening. De er mennesker og er derfor ikke fejlfri - derfor kan de påpege eventuelle fejl de er støt 1 Karakterer er fiktive "personer"i ens program, som repræsenterer de respektive brugertyper som kunne tænkes at benytte ens system. Se mere på flg. adresse:

20 Kapitel 4. Metode 12 på. Fejl som du måske ikke selv har tænkt over kunne opstå, i udarbejdelsen af dine test-cases. - Flere personer - hvis man har mulighed for det, så få testen spredt ud på så mange personer som muligt. Dette kan tildels løses ved at anvende levende mennesker i forbindelse med systemet, som beskrevet herover. Jo flere uafhængige testere der er på systemet, jo større chance er der for at fejl bliver opdaget. Fejl som udvikleren ikke selv ville opdage, da test af systemet hurtigt kan gå hen og blive rutinearbejde. - Ressourcer - det er vigtigt at man sætter nok tid af til at udføre ens test. Tit hører man at der er fejl i et program fordi man simpelthen ikke har fokuseret nok på testen af dette. Derfor er det vigtigt at sætte rigeligt med tid af, så testen ikke går hen og bliver hullet og mangelfuld. Valgte testmetoder Her vil jeg beskrive de forskellige testmetoder, som jeg har valgt, i forbindelse med dette projekt. - Unittest - denne metode er valgt, til at teste metoderne i klasserne. Man specificerer argumenterne til den enkelte metode, samt det output man forventer at få. Hvis det aktuelle output stemmer overens med det forventede, efter endt gennemkørsel, betragtes testen som værende en succes. Formålet er, at jo længere man kommer i projektet, jo flere unittests eksisterer der. Dette sikrer, at man altid kan køre en automatiseret test, på de gamle metoder i systemet, for at sikre at disse stadig kan køre fejlfrit. - Brugertest - dette er brugt til at sikre at brugerinterfacet er logisk opbygget, samt at det gør det forventede ud fra brugerens interaktion med systemet. Samtidig udarbejdes der detaljerede use-cases som tager højde for de forskellige anvendelsesmuligheder i systemet. Dette skulle gerne sikre at systemet bliver gennemtestet og alle muligheder inddækkes.

21 Analyse Risikovurdering I dette afsnit beskrives de risici, som evt. kan opstå i forbindelse med udarbejdelsen af dette projekt. Jeg har valgt kun at medtage to kategorier i forbindelse med identifikationen af disse risici. De valgte kategorier er: - Teknik - dette omhandler de risici jeg ikke selv er herre over. Dette kan være strømsvigt, tab af data, hardwarefejl eller andet. - Udvikling - dette er de risici, som påvirker udviklingen i den ene eller den anden grad. Dette kan være sygdom, manglende kompetencer til anvendte teknologier, frafald af personer osv. Risici Konsekvens Forebyggelse Løsning Udvikling Sygdom Tid mistet i Ingen forebyggelse Hvis muligt, kom forbindelse med foran i forhold til tidsplanen tidsplan Datatab Projektet sættes Backup til ekstern Data genskabes tilbage både server fra backup tids- og udviklingsmæssigt Kravene Kravspecifikation - ekstra tid afsættes ændres opdateres. Nye til udvikling use-cases udarbejdes. Manglende Sætter sig ind i Ekstra tid afsættes Tidsplan ændres, kompetencevikling nye teknologier til ud- der må arbejdes mere Person frafald Projekt annulleres - Projektet udsættes eller udsættes Teknisk Strømsvigt Minimalt datatab - Arbejde fortsættes fra bærbar Hardwarefejl Datatab, PC ikke - Der arbejdes brugbar fra en anden computer 13

22 Kapitel 5. Analyse Kravspecifikation Prioritet Del Beskrivelse Høj System Der skal udvikles en webapplikation, som skaber større overblik i praktik- og eksamensprojektprocessen på Diplomingeniør IT retningen på DTU. Høj Alle Brugere der er godkendt i forbindelse med praktik, skal kunne logge ind i systemet. Høj Admin Oprettede administratorer skal kunne logge ind i systemet. Høj Stud. Brugere skal kunne oprette nye meddelelser og specificere hvem disse er henvendt til. Høj Stud. Brugere skal kunne uploade dokumenter til systemet. Høj Stud. Brugere skal kunne oprette/redigere filstruktur til at gemme dokumenter og filer i. Høj Stud. Brugeres filer skal versionsstyres, så der altid gemmes en kopi af gamle versioner (sporbarhed). Høj Stud. Brugere skal kunne udfylde allerede oprettede web indtastningsformularer med data. Høj Stud. Brugere skal kunne se meddelelser henvendt til ham/hende. Lav Stud. Brugere skal kunne se en tidslinie, med ting der er foretaget, samt fremtidige frister og deadlines. Høj Admin Skal kunne oprette/redigere brugere. Høj Admin Skal kunne oprette/redigere nye sager. Høj Admin Skal kunne tilføje brugere til en oprettet sag. Høj Admin Skal kunne oprette/redigere generiske indtastningsformularer. Høj Admin Skal kunne tildele/fjerne indtastningsformularer samt standarddokumenter til en sag. Høj Admin Skal kunne uploade dokumenter. Høj Admin Skal kunne sende meddelelser til sager, som gemmes (sporbarhed). Her skal man samtidig kunne vælge allerede oprettede standardmeddelelser. Høj Admin Skal kunne oprette/redigere standardmeddelelser. Høj Admin Skal kunne godkende praktiksted. Høj Admin Skal kunne godkende abstract Høj Admin Skal kunne tildele en eller flere DTU vejledere Lav Admin Skal kunne godkende eksamensprojekt og indtaste karakter

23 Kapitel 5. Analyse 15 Høj Admin Skal kunne definere hvor lang tid der skal gå mellem de enkelte handlinger i forbindelse med et forløb. Høj System Skal oprette folder struktur ved oprettelse af ny sag. Høj System Skal oprette en skjult folder ved navn "DTU Interne", som kun PK og PA kan se Lav System Skal tildele formularer mærket med standard, til en sag ved oprettelse. Lav System Skal oprette roller, ved deployment til ny server Høj System Skal oprette superuser-bruger, ved deployment til ny server Lav System Skal oprette liste med standard-events, ved deployment til ny server Lav Admin Se statistik over hvor mange sager en DTU-vejleder har haft Høj System Udsende en notifikation ved udsendelse af meddelelse til praktikkoordinator Høj System Udsende en notifikation, når formular er udfyldt og input sendes til godkendelse Høj Admin Skal kunne tilgå et input via en notifikation Høj Admin Skal kunne svare på en meddelelse via en notifikation Lav Admin Hvis han kommer fra en notifikation, skal han præsenteres for den meddelelse han svarer på, øverst på siden. Med mulighed for at svare på meddelelsen på samme side. Lav System Udsende en til en række brugere, når en meddelelse udsendes i systemet Lav System Udsende en , hvis en PK/PA godkender/afviser indtastet input Lav Admin Skal kunne ændre i tidsfrister, på events i tidslinie Lav Admin Skal oprette roller, ved deployment til ny server Lav Admin Skal kunne se en liste over sager, med mulighed for at sortere efter semester og få vist afsluttede sager Lav System Sager skal markeres som afsluttede, når karakteren er indberettet 5.3 Interessenter Herunder har jeg identificeret interessenterne i forbindelse med dette projekt.

24 Kapitel 5. Analyse 16 Beslutningstagere Rolle Succes kriterie Inddragelse Stig Høgh Kravstiller Hurtig og effektiv betjening af systemet Mads Nyborg Kravstiller Hurtig og effektiv betjening af systemet Reviews og møder Reviews og møder Direkte interessenter Rolle Succes kriterie Inddragelse Praktikkoordinator Bruger Hurtig betjening med maksimalt overblik Praktikassistent Bruger Hurtig betjening og forøgelse af effektivitet Studerende Bruger Hurtigere respons på ens handlinger Projektets interessenter Rolle Succes kriterie Inddragelse Stig Høgh Vejleder Færdigt og effektivt produkt Mads Nyborg Vejleder Færdigt og effektivt produkt Jesper Christiansen Udvikler Eksamensprojekt. Opnå kundens tilfredshed Tabel 5.3.1: Interessenter i forbindelse med projektet Løbende gennem projektet Løbende gennem projektet Hele projektet

25 Kapitel 5. Analyse Afgrænsning Jeg vil nu komme ind på hvilke dele der ligger uden for dette projekt. Da projektet er at betegne som en prototype, og det er udviklet med henblik på, om et sådan system kan lette arbejdsopgaverne for praktikkoordinatorerne og praktikassisten, er der dele af projekter jeg har valgt ikke at tage højde for. - Optimering. Nogle ting kunne sikkert gøres hurtigere ved at anvende en form for caching eller andet i den stil. Dette er der heller ikke lagt vægt på. - Optimering af databasen. Jeg har valgt ikke at lægge så meget vægt på optimering af databasen i form af stored procedures og indexes. Dog har jeg implementeret et par stored procedures, for at vise jeg kan gøre dette. Men at lave systemet fuldt ud med stored procedures til de mest brugte kald, har jeg valgt at se bort fra i denne omgang. - Udtræk af dokumenter. Udtræk af sagsoplysninger i form af en genereret.pdf eller andet dokument, har jeg også valgt at se bort fra, da jeg mente det var vigtigere at få lavet så megen funktionalitet, som havde med arbejdsgange at gøre, fremfor at fokusere på.pdf generering. - Versionsstyring af filer. Jeg har primært valgt at fokusere på versionsstyringen af indtastninger. Versionsstyring af filer har jeg ikke implementeret, da jeg mener der var vigtigere funktionalitet der kom først. Dog ville en enkel form for versionsstyring kunne klares med, at hver fil gemmes i en mappe under den pågældende folder den er uploadet i, som nu. Den bliver så gemt i en mappe, som svarer til filens navn - og hver version bliver gemt i undermapper, der svarer til hvilken revision af filen der er tale om.

26 Kapitel 5. Analyse Domænemodel Domænemodellen, som kan ses i figur 5.5.1, er en visuel repræsentation af de konceptuelle klasser i et domæne. Denne er lavet med det henblik, at give et godt overblik over systemet, samt lette arbejdet med at identificere use cases, krav m.m. Figur 5.5.1: Domænemodel for systemet

27 Kapitel 5. Analyse Use cases Aktører Følgende aktører er identificeret i forbindelse med dette projekt, disse er: Bruger Dette er den studerende, eller den almindelige bruger, uden nogen specielle rettigheder. Praktikkoordinator Praktikkoordinator (PK), er personerne som træffer den afgørende beslutning i forbindelse med de sager der er i en praktik/eksamensprojekt sag. Praktikassistent Praktikassistent (PA), er assistenten til praktikkoordinatorerne, det er primært denne bruger som foretager godkendelserne i systemet, baseret på PK s beslutninger. DTU vejleder DTU vejleder (VEJL) er den ansatte ved DTU, som er blevet tilknyttet som vejleder til et eksamensprojekt. Han har rettigheder på lige fod med brugeren. Superbruger Superbruger, kan ligesom PK og PA alt i systemet. Forskellen er dog, at hvis der ingen andre brugere er i systemet, så bliver superbrugeren oprettet, med en auto-genereret adgangskode, så man altid har adgang til, og mulighed for at oprette brugere i systemet.

28 Kapitel 5. Analyse Use case kontekstdiagram I dette afsnit ses use case kontekstdiagrammet (figur 5.6.1), som giver et perfekt billede over systemets kontekst. Det viser systemets afgrænsning, hvad der ligger udenfor, samt hvordan aktører og dele af systemet interagerer med hinanden. Figur 5.6.1: Systemets use case kontekstdiagram

29 Kapitel 5. Analyse Prioritering af use cases De enkelte use cases bliver i nedenstående tabel prioriteret i henhold til hvilke der skal implementeres først, ud fra business-værdi (B), samt hvilke der indeholder den største teknologiske udfordring (T). Prioritering B T Opret meddelelse 4 1 Opret standardmeddelelse 1 1 Upload filer 3 2 Opret indtastningsformular 5 5 Udfyld indtastningsformular 5 5 Opret sag 5 2 Opret bruger 4 1 Rediger sagsdata 3 1 Godkend praktikoplysninger 3 1 Godkend abstract 3 1 Godkend praktikophold 3 1 Godkend eksamensprojekt 3 1 Tilføj medlemmer 4 1 Tilknyt indtastningsformularer 2 1 Rediger events 2 1 B = Business værdi T = Teknologisk udfordring Business værdien er den værdi, som den enkelte use case bidrager med - det vil sige hvor vigtig den er for systemet. Den teknologiske udfordring er hvor svær den kan forventes at være at implementere, f.eks grundet man ikke har stort kendskab til de teknologier der anvendes. Ud fra disse værdier, bestemmer jeg hvilke use cases jeg vil forsøge at implementere så tidligt som muligt. Det kan ses fra ovenstående tabel at Opret indtastningsformular og Udfyld indtastningsformular er to af de sværere use cases at implementere og derfor bliver disse naturligt valgt som de første.

30 Teknologier 6 Dette kapitel vil komme ind på, hvilke teknologier jeg har tænkt mig at benytte i forbindelse med tilblivesen af dette projekt, samt implementeringen af prototypen. 6.1 ASP.NET 3.5 For at gøre implementeringen så tidssvarende som muligt, hvilket vil gøre den nemmere at bygge videre på, har jeg valgt, i samråd med vejledere, at implementeringen skal foretages med ASP.NET 3.5. Det der ligger til grund for min beslutning, er at dette er det nyeste skud på stammen 1 i Microsofts ASP.NET serie. 6.2 LINQ (Language Integrated Query) Vel nok en af de største tilføjelser til ASP.NET 3.5 er tilføjelsen af LINQ. LINQ bidrager med en masse nyt, men en af de smarteste ting og nok også den som der bliver mest fokus på i forbindelse med dette projekt, er dets SQL lignende syntax til brug ved tilgang af collections. Ligemeget hvilken collection du ønsker at tilgå - hvad end det er enumerable classes, arrays, XML, databaser eller andre tredje parts kilder - til dette anvendes den samme syntaks. På grund af dette, kan dele af systemet nemt kan skiftes ud, hvis det viser sig at det senere hen er mere optimalt at anvende en anden type database end den som systemet var udviklet til. Ud fra de LINQ expressions som er skrevet i koden, genereres et expression-træ dette træ bliver herefter analyseret og transformeret til det optimale query sprog for den pågældende database. Derfor behøver man at fokusere mindre på tilgang til databasen og optimering af den bagved-liggende SQL, fremfor hvad det er man egentlig ønsker at opnå. Ovenstående lyder meget godt, men man må selvfølgelig betale en pris for den funktionalitet. Det er klart at genereringen af et expression-træ, analyseringen af dette og genereringen af en optimal query ud fra denne analyse, giver et performance fald. Hvis man kigger på performance tests af beta-versionen af LINQ, ser det ud til at den er næsten dobbelt så lang tid om at fetche data end det gamle velkendte ADO.NET [4, 5]. Det kan så diskuteres hvorvidt dette er til gene for brugerne af systemet, da det stadig er milisekunder vi snakker om, samtidig kan det tænkes at LINQ har fået bedre performance i den endeligt udgivne version. 1 ASP.NET 3.5 blev udgivet den 19. november 2007, sammen med Visual Studio

31 Design Arkitektur I forbindelse med implementeringen af dette projekt, har jeg valgt at benytte en lagdelt arkitektur for at holde de enkelte dele af implementeringen adskilt. Dette gør det nemmere at vedligeholde senere hen, da man kan udskifte de enkelte lag, som man ønsker det. Skulle man på et tidspunkt ønske at lave en selvstændig applikation er det f.eks muligt at udskifte præsentationslaget med windows forms, bare for at tage et eksempel. Et typisk anvendt designmønster i forbindelse med lagdeling er N-tier arkitektur, derfor har jeg valgt at gøre brug af dette. Læs mere i afsnit 7.2, hvor jeg kommer ind på brugen af denne arkitektur 7.2 N-tier arkitektur Den simpleste måde at opbygge en webapplikation på, ville være at have sider der tog data direkte fra databasen. Det ville uden tvivl være en hurtig måde at udvikle på, men samtidig ville den have en række ulemper. Blandt andet ville din business logik og data logik blive mixet sammen i en fil. Man ville opnå en enorm mængde duplikeret kode, hvilket ville gøre det svært at vedligeholde applikationen - samtidig ville det være umuligt at skille ens frontend fra ens backend. Jeg har valgt at opbygge denne web applikation, delt op i 4 separate lag. - Præsentation - Business logik - Data adgang - Data Arkitekturen vil derfor se ud som i figur Det er dog vigtigt at jeg gør det klart, hvilke ansvarsområder hvert lag har. Så man ikke mister fokus i forbindelse med implementeringen, og hele tiden sikre sig at de kun varetager det de skal. Disse anvarsområder lister jeg op herunder: - Præsentation - indeholder brugergrænsefladen i projektet - Business - indeholder logik 23

32 Kapitel 7. Design 24 Figur 7.2.1: Systemets n-tier arkitektur - Data adgang - indeholder metoder til at skrive til databasen og læse fra databasen - Database - Persisterer data i systemet Interaktionen mellem de forskellie lag, sker fra top til bund. Det vil sige, at præsentationslaget ikke kan snakke med data-laget og omvendt, men det foregår tilgengæld ned og op igennem lagene. Dataadgangen bliver implementeret ved at gøre brug af LINQ-to-SQL, som tager sig af object-relationel mapning fra tabellerne i databasen til entitetsobjekterne.

33 Kapitel 7. Design Business-lag klassediagram Figur 7.3, er klassediagrammet for laget mellem præsentations- og datalaget. Størstedelen af disse controller klasser, tilgår datafacaden i datalaget. Jeg har dog valgt ikke at tegne dem på, for at gøre det knapt så komplekst. Figur 7.3.1: Klassediagram for businesslaget

34 Kapitel 7. Design Data-lag klassediagram Figur 7.4, er klassediagrammet for laget mellem businesslaget og databasen. Størstedelen af disse controller klasser, tilgår datafacaden i datalaget. Har dog valgt ikke at tegne dem på, for at mindske kompleksiteten i diagrammet samt gøre det mere overskueligt. Figur 7.4.1: Klassediagram for datalaget

35 Kapitel 7. Design Anvendte patterns Facade At dele et større system ind i mindre systemer, hjælper med at reducere kompleksiteten i systemet. For at mindske kommunikationen og afhængighederne mellem de mindre systemer, kan man introducere et facade objekt, som bidrager med et enkelt, simplificeret interface [6]. Figur 7.5.1: Facade pattern Dette projekt er delt ind i et præsentations-, business- og datalag. Præsentation tilgår dele i business og business tilgår dele i data. For at mindske koblingen mellem disse, har jeg henholdsvis en Facade-klasse i mit businesslag og en DataFacade-klasse i mit datalag, dette giver mig en lavere kobling som det kan ses i figur Page-controller Når der er kode som går igen på flere sider, anvender man Page-Controller pattern for at mindske kode duplikering. Dette gøres ved at oprette en særskilt klasse, som nedarver fra System.Web.UI.Page og så lader man alle siderne i ens web-applikation nedarve fra denne PageBaseClass, dette kan ses i figur Singleton Jeg havde planer om at gøre brug af singleton-pattern i dette projekt. Singleton er et meget anvendt pattern og anvendes når man ønsker at brugeren skal få fat i samme instans af en klasse. Jeg havde planlagt at bruge den i forbindelse med mit Datalag, så jeg sikrede mig at brugeren fik fat i samme database-connection. Men det viste sig, at det DataContext man anvender i forbindelse med LINQ, tager sig af denne funktionalitet og selv sørger for at lukke forbindelsen til databasen - så derfor ville singleton blive overflødigt. 7.6 Database Valg af database Der er ikke lagt så megen vægt på performance eller andet ved den database jeg har valgt at gøre brug af til dette projekt. Grundlaget for dette er, at denne webapplikation skal ses som værende en prototype. Samtidig anvendes LINQ fra den nyeste version af.net, som

36 Kapitel 7. Design 28 Figur 7.5.2: Page-Controller pattern er lavet til at arbejde sammen med forskellige collections. Det hele bliver udviklet på en sådan måde, at det vil være nemt senere hen, at skifte datalaget ud og gøre brug af en anden database, hvis der skulle være et ønske om dette. Valget af database er faldet på SQL Server 2005, dette skyldes blandt andet at Visual Studio 2008, der bliver anvendt til at udvikle i, har en god integration af SQL Server 2005 og derfor er nem at benytte i den sammenhæng.

37 Kapitel 7. Design 29 Figur 7.6.1: ER-model Datamodel Datamodellen for databasen er udarbejdet som en ER-model 1, dog er der funktionalitet i Visual Studio der giver mulighed for at lave en datamodel, men jeg føler mig mere hjemme i ER-model og føler derfor at dette skaber et bedre overblik over databasen Stored procedures Der er oprettet et par stored procedures, som de kald der foretages flest gange til databasen. Fordelen ved at gøre brug af stored procedures er som følger: - Der opnåes et større abstraktionsniveau, da selve SQL kaldet ligger i databasen. - Eksekveringen af stored procedures foregår hurtigere end med alm. LINQ kald. Grunden til dette, er at stored procedures ligger pre-kompileret i selve databasen og derfor ikke skal kompileres hver gang et kald skal foretages. 1 Entity-Relationship-model

38 Kapitel 7. Design Sekvensdiagrammer Her viser jeg de sekvensdiagrammer jeg har udvalgt for de vigtigste use cases, resten kan ses i appendiks Opret sag (use case 5) Sekvensdiagrammet i figur 7.7.1, viser rækkefølgen af de kald som foregår når man opretter en ny sag i systemet. PK eller PA udfylder en række oplysninger på hjemmesiden og trykker på en knap. Metoden CreateCase bliver herefter kaldt ovre i controlleren. Her kalder den en metode i datalaget, som returnerer caseid, hvis sagen bliver oprettet. Der bliver nu kaldt en metode, som opretter standard-mapper under den nye sag (CreateDefaultFolderStructure(caseId)). Når dette er gjort, skal der tilknyttes en tidslinie til sagen. Dette sker ved at kalde metoden i datalaget, CreateNewTimeline(caseId), som opretter en tidslinie for den pågældende sag og returnerer dennes id. Denne tidslinie skal indeholde sagens forløb og derfor kaldes CreateMilestoneFromEvents(timelineId), som opretter milestones svarende til de events der er defineret i EventList-tabellen. Det sidste der sker, er at der bliver udsendt en velkomst besked, under den pågælgende sag ved at kalde CreateMessage-metoden. Figur 7.7.1: Sekvensdiagram for opret sag (use case 5)

39 Kapitel 7. Design Godkend praktikoplysninger (use case 10) Sekvensdiagrammet i figur 7.7.2, viser rækkefølgen af de kald der bliver foretaget når man opdaterer praktikoplysninger i en sag. Datoerne for praktikstart og slut indtastes på hjemmesiden. Herefter kaldes en metode i controlleren. UpdateInternshipMilestones De 2 milestones for henholdsvis abstract og praktikrapport hentes fra databasen og datoerne opdateres med de korrekte informationer (hentet fra EventList-tabellen). Ovenstående metode kaldes nu i datalaget, med datoer for de 5 milestones der skal opdateres. Herefter opdaterer den data i disse milestones. Figur 7.7.2: Sekvensdiagram for godkend praktikoplysninger (use case 10)

40 Kapitel 7. Design Brugerinterface Selve interfacet som brugerne skal anvende i denne webapplikation, er besluttet at skulle ligne DTU s CampusNet så meget som muligt. Beslutningen der ligger til grundlag for dette er, at alle brugerne der skal gøre brug af systemet, er fra DTU og derfor kender de Campus- Net og måden dette virker på - samt hvor man kan finde de enkelte ting og hvordan dette fungerer. Der er ingen grund til at tænke i en ny løsning i form af hvordan designet skal opbygges, da man så kan risikere at ramme forbi målet og ikke opnå samme effektivitet, som der ligger i en løsning der allerede er kendt. Størstedelen af personerne som skal anvende systemet er IT-kyndige, i og med de studerer på en IT-retning - disse brugere vil nok ikke have ligeså lang en omstillingstid, til et anderledes system, som f.eks. praktikassistenten vil have det, som er en af de personer der anvender systemet mest. Derfor er et interface, der minder om CampusNet i design og funktionalitet, valgt til dette projekt. Dette vil skabe en følelse af man anvender det samme system hele vejen igennem, selvom det er to forskellige systemer, nemlig CampusNet og denne webapplikation.

41 Implementering 8 Jeg vil i det følgende kapitel, komme nærmere ind på implementeringen af de vigtige dele af projektet - eller de dele, som har skabt problemer i forbindelse med dette system. Hvis man ønsker at afprøve applikationen i trit med man læser dette kapitel, kan man i appendiks 5 finde vejledning til hvordan man får adgang til den version der kører på Ligeledes kan der i appendiks 6, findes en vejledning til brug af de mest essentielle dele af systemet. 8.1 Oprettelse af standarddata Når systemet bliver deployet på en ny server, med en tom database, så er der nogle ting der skal oprettes, før det hele kommer til at fungere. Dette sker i Global.asax filen, ved hjælp af metoden Application_Start som kaldes når applikationen starter Roller Før man overhovedet kan oprette standard brugeren, beskrevet i afsnit Så er man nødt til at have oprettet de 5 standardroller; PK, PA, BRUGER, VEJL og SUPERUSER. Inde fra Global.asax, kaldes metoden CreateDefaultRolesIfNotExists() Den sørger for at oprette de 5 roller, hvis ikke allerede de forefindes i databasen. 1 / / C r e a t e BRUGER r o l e 2 i f (! Roles. RoleExists ( "BRUGER" ) ) 3 { 4 Roles. CreateRole ( "BRUGER" ) ; 5 } 6 7 / / C r e a t e PK r o l e 8 i f (! Roles. RoleExists ( "PK" ) ) 9 { 10 Roles. CreateRole ( "PK" ) ; 11 } / / C r e a t e PA r o l e 14 i f (! Roles. RoleExists ( "PA" ) ) 15 { 16 Roles. CreateRole ( "PA" ) ; 17 } / / C r e a t e VEJL r o l e 20 i f (! Roles. RoleExists ( " VEJL " ) ) 33

42 Kapitel 8. Implementering { 22 Roles. CreateRole ( " VEJL " ) ; 23 } / / C r e a t e SUPERUSER r o l e 26 i f (! Roles. RoleExists ( "SUPERUSER" ) ) 27 { 28 Roles. CreateRole ( "SUPERUSER" ) ; 29 } Listing 8.1: global.asax - Opret roller Superbruger Systemet kan ikke anvendes, uden man har en eller flere brugere som har adgang til dette. Hvis der skulle ske det, at hele databasen bliver slettet, så man mister sine brugere - så har man ingen mulighed for at logge ind og oprette nye brugere på serveren. Dette er der taget hånd om, ved at oprette en bruger ved start af web-applikationen. 1 private s t a t i c void CreateDefaultUserIfNotExists ( ) 2 { 3 Business. Controller controller = new Business. Controller ( ) ; 4 Util. Password pwd = new Util. Password ( ) ; 5 const string DefaultUser = " superuser " ; 6 string DefaultPassword = pwd. GetRandomPasswordUsingGUID ( 6 ) ; 7 string Default = ConfigurationManager. AppSettings [ " SuperUser " ] ; i f ( Membership. GetUser ( DefaultUser )!= null ) return ; 11 MembershipUser user = Membership. CreateUser ( DefaultUser, DefaultPassword, Default ) ; / / Add u s e r t o r o l e s 14 i f ( user!= null ) 15 { 16 Roles. AddUserToRole ( DefaultUser, "SUPERUSER" ) ; 17 } ProfileCommon profile = ( ProfileCommon ) ProfileCommon. Create ( user. UserName, true ) ; 20 profile. FirstName = " Super " ; 21 profile. LastName = " User " ; 22 controller. SendNewUser ( Default , DefaultUser, DefaultPassword ) ; 23 } Listing 8.2: global.asax - Opret superuser Denne metode går ind og ser om der findes en bruger med navn = "superuser", hvis dette ikke er tilfældet, så bliver denne bruger oprettet med en auto-genereret adgangskode på 6 tegn. Efter brugeren er oprettet, er det vigtigt at han får rettigheder til at bruge systemet. Derfor bliver han tildelt rollen SUPERUSER. Brugernavn og adgangskode bliver derefter sendt til den SuperUser , som man har angivet i web.config-filen, hørende til projektet. Dette sikrer, at der altid vil være en bruger oprettet i systemet, som de rette personer kan logge ind med og oprette andre brugere ved hjælp af.

43 Kapitel 8. Implementering Events på tidslinie For at man ikke skal oprette det hele på ny, bliver der ligeledes oprettet events, som skal bruges i forbindelse med tidslinien i en brugers sag. Hvis ingen events er defineret, og en sag oprettes, så eksisterer der ingen events på brugerens tidslinie og hele ideen forsvinder med at have en sådan. Derfor bliver disse også forud defineret og kan så altid rettes til. 1 Business. Facade facade = new Business. Facade ( ) ; 2 i f ( facade. GetEventListItemByType ( "SYSTEM_START" ) == null ) 3 { 4 i n t first = facade. CreateEventListItem ( 0, " Sag begyndt ", "SYSTEM_START", 0, 0, null, true ) ; 5 i n t second = facade. CreateEventListItem ( first, " Stamdata ", "FORM_UDFYLD", 7, 7, null, true ) ; 6 i n t third = facade. CreateEventListItem ( second, " Praktikoplysninger ", "FORM_PRAKTIKDATA", 14, 14, null, true ) ; 7 i n t fourth = facade. CreateEventListItem ( third, " Praktik s t a r t ", "PRAKTIK_START", 0, 0, null, false ) ; 8 i n t fifth = facade. CreateEventListItem ( fourth, " Abstract ", "PRAKTIK_ABSTRACT", 21, 0, null, false ) ; 9 i n t sixth = facade. CreateEventListItem ( fifth, " Praktik s l u t ", "PRAKTIK_SLUT", 126, 42, null, false ) ; 10 i n t seventh = facade. CreateEventListItem ( sixth, " Praktik rapport ", "PRAKTIK_RAPPORT", 7, 7, null, false ) ; 11 i n t eight = facade. CreateEventListItem ( seventh, " Eksamensprojekt s t a r t ", "EKSPROJ_START ", 0, 0, null, false ) ; 12 facade. CreateEventListItem ( eight, " Eksamensprojekt s l u t ", " EKSPROJ_SLUT", 0, 0, null, false ) ; 13 } Listing 8.3: global.asax - Opret events til tidslinie 8.2 Identifikation af sager Jeg har taget lidt inspiration i det nuværende CampusNet, hvad sager angår. Hver gang en bruger klikker på et link, bliver der automatisk sat en QueryString på linket, svarende til brugerens sag aktuelle sag (ElementId=SagsNummer). Brugerens aktuelle sag er specificeret i brugerens profil og har navnet case, dette betyder at brugeren kan starte ud under en sag, men hvis han senere bliver skiftet over i en anden, så ændres hans Profile.Case sig. Hvis man er logget ind som praktikkoordinator (PK), praktikassistent (PA) eller DTU-vejleder (Vejl) afhænger ElementId af den sag man har klikket sig ind under. Når man derefter bevæger sig rundt under en specifik sag, så hænger ElementId et ved, indtil man skifter over til en anden sag. 8.3 Code-behind filerne Code-behind filernes rolle (.aspx.cs), er at modtage objekter fra de forskellige controllere i Business-laget. Disse bliver derefter behandlet og vist på selve præsentationssiden (.aspx).

44 Kapitel 8. Implementering Fluidlayout Selve layoutet i web-applikationen er implementeret i en master-page. Alle webforms anvender denne master-page, og tilgår de områder i denne template, de såkaldte contentpanes, hvor de må vise deres output. Hele designet er implementeret med xhtml og css, hvilket gør det nemt senere hen at ændre udseende på hele systemet. Det består af en topbar, hvor informationer om den bruger der er logget ind bliver vist. Under denne topbar, kommer en header, som indeholdet navnet på applikationen. Herefter kommer en horizontal menubjælke, som er forbeholdt rollerne PK, PA, SUPERUSER og VE- JL - denne ser brugeren altså ikke. Det resterende af siden, består af en sidebar til venstre, som indeholder navigation baseret på den sag man er under - samt en maincontent-afdeling til højre, som indeholder indholdet af siden og det er her man ser al data vedrørende sager. Sidebar og maincontent er implementeret som et såkaldt fluid-layout. Det betyder at det tilpasser sig browservinduets størrelse. Opbygningen af siden kan ses i figur 8.4 Figur 8.4.1: De enkelte <div> i hovedopbygningen af designet Sidebar er en <div> med en fixed bredde på 180px, samt en padding rundt i kanterne, så indholdet ikke kommer for tæt på skærmens kant. Samtidig er float sat til left, for at sikre at denne altid vil befinde sig i venstre side af skærmen, se listing #subnav 2 { 3 width : 180px ; 4 f l o a t : left ; 5 padding : 20px 20px 20px 10px ; 6 }