Dokument- og Sagsstyringssystem

Transkript

1 Dokument- og Sagsstyringssystem Mads Nissen Kongens Lyngby 2010 IMM-B.Eng

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

3 Abstract / Resumé Dette projekt er udført fordi IMM ønsker et Dokument- og Sagsstyringssystem der kan lette administration af studerendes praktikophold og eksamensprojekter. Den nuværende administration af praktik og eksamensprojekter foregår ved brug af Campusnet, der ikke er beregnet til denne administration. Dette resulterer i at administrationen ofte er langt mere besværlig end den ville være i et målrettet system. Projektet er udført efter en Unified Process model, hvor der har været fokus på use cases og iterativ udvikling. Der er anvendt udvalgte UML artefakter til at modellere systemet. Det udviklede system er implementeret som en Java webapplikation baseret på Apache Wicket. Det anvender en relationel model der er implementeret i en MySQL database og ORM frameworket Hibernate anvendes for at lette datatilgang til databasen fra webapplikationen. Det udviklede system opfylder de funktionelle krav for kerne-områderne i det ønskede system. Ikke alle use cases er integreret inden for projektets rammer, men systemets opbygning og dokumentation gør det nemt at fortsætte arbejdet. 3

4 Bilag Alle bilag er placeret på den vedlagte CD. CD en indeholder følgende bilag: Denne rapport som pdf-fil (Rapport.pdf) Applikationens kildekode m.v. (DSS mappe) Fil med MySQL kommandoer til oprettelse af relationel database (dbscripts.sql) Pakke til lokal afvikling af webapplikationen (dss.zip) Vejledning til lokal afvikling af webapplikationen (Vejledning.pdf) Program der unzipper dss.zip væsentligt hurtigere end windows std. (7-ZipPortable mappe) 4

5 Indhold 1 Indledning Afgrænsning Sprogbrug / ordvalg Inception Indledning Vision Use cases Use case diagram Aktører Oversigt over use cases Use case beskrivelser FURPS Risikoanalyse Analyse-dokument Detaljerede use cases Fælles for alle Studerende Praktikassistent Praktikkoordinator DTU Vejleder Fælles for Praktikassistent og Praktikkoordinator Fælles for Praktikassistent, Praktikkoordinator og DTU Vejleder Test cases Løsningsstrategi Domænemodel Design-dokument Package-diagram Designovervejelser Fildeling Status Standard dokumenter / Bruger dokumenter Find studerende Datamodellering

6 6.1 Designovervejelser Fildeling Forms Standard dokumenter Bruger dokumenter Registrering Tilknyt vejleder Status Begrebsmæssigt databasedesign Logisk databasedesign Mapping Normalisering Relationel model Constraints Systemarkitektur Design Patterns Lag-deling Implementering Generelt Apache Wicket Hibernate Test Strategi for test Udførelse af test Resultat af test Evaluering og konklusion Evaluering af proces Konklusion på system Integration af resterende use cases Mulige forbedringer Konklusion på projekt

7 Figurer Figur 1: Use case diagram, del Figur 2: Use case diagram, del Figur 3: Iterationsplan Figur 4: Domænemodel Figur 5: Package-diagram Figur 6: Entity Relation Diagram Figur 7: Lag-deling Figur 8: Eksempel - ModalWindow Tabeller Tabel 1: Use case - Registrer studerende Tabel 2: Use case - Behandl registrering Tabel 3: Use case - Opdater form data Tabel 4: Use case - Godkendelse af praktikplads Tabel 5: Use case - Godkend praktikvirksomhed Tabel 6: Use case - Upload standard dokument Tabel 7: Risici ved projektet Tabel 8: Detaljeret use case - Registrer studerende Tabel 9: Detaljeret use case - Opdater form data Tabel 10: Detaljeret use case - Behandl registrering Tabel 11: Detaljeret use case - Godkend praktikvirksomhed Tabel 12: Test case - Registrer studerende Tabel 13: Test case - Behandl registrering Tabel 14: Test case - Opdater form data Tabel 15: Test case - Godkend praktikvirksomhed

8 1 Indledning Dette projekt omhandler udviklingen af et Dokument- og Sagsstyringssystem til IMM, der ønsker en webportal til administration af studerendes praktikophold og eksamensprojekter. Til at styre udviklingsprocessen anvendes Unified Process, hvor projektarbejdet inddeles i iterationer og use cases er et centralt element. Ud over at anvende use cases til at beskrive systemets funktionelle krav, benyttes udvalgte UML artefakter til at modellere systemet. I projektet lægges størst vægt på analyse og design af systemets funktioner samt på datamodellering. Det ønskede system implementeres som en Java Webapplikation baseret på Apache Wicket. Denne rapport beskriver systemets overordnede rammer og krav, analyserer de funktionelle krav, indeholder en domænemodel for systemet, viser implementeringens overordnede struktur i et package-diagram og datamodel i et ER diagram. Desuden gøres der rede for de overvejelser der ligger bag designet, lige som der gennemgås relevante detaljer omkring implentationen. Endelig beskriver rapporten også hvordan de funktionelle krav til systemet er testet. 2 Afgrænsning Det system der udvikles er tænkt at skulle integreres med DTU s SSO, så authentication af brugere kan håndteres af SSO. Denne integration er dog uden for projektets scope, hvorfor det ikke vil være nogen egentlig authentication i applikationen - kun en dummy-udgave. I inceptionsdokumentet bestemmes krav til systemet i form af use cases. Det er dog ikke alle disse use cases der bliver arbejdet med inden for projektets tidsgrænse. Der vil i projektet ikke blive brugt mange resourcer på de æstetiske dele af webapplikationen. 2.1 Sprogbrug / ordvalg Her er listet en række sammenhænge der er væsentlige at huske for forståelsen af resten af rapporten: DSS Forkortelse af Dokument- og SagsstyringsSystem. Navnet på projektet og systemet. Registrering / ansøgning Er de oplysninger de studerende angiver for at blive optaget i systemet. Begge ord anvendes med samme betydning. SSO Forkortelse af Single-Sign-On. Std. dok. Forkortelse af Standard dokument. Dækker over filer der ofte benyttes i forbindelse med en studerendes sag, men hvis indhold ikke administreres af systemet. Sag Én sag hører til én studerende og omhandler administration, meddelelser og aktiviteter i forbindelse med praktik og eksamensprojekt. 8

9 3 Inception Dette afsnit beskriver det system der udvikles samt de krav der stilles. Systemet beskrives blandt andet ved et use case diagram og en gennemgang af de vigtigste use cases. 3.1 Indledning Formål Formålet med Inceptions-dokumentet er at indføre målgruppen i systemets omfang og de funktionelle krav der er opstillet for systemet. Derudover er det meningen at fremstille use cases der benyttes ved udviklingen af systemet. Målgruppe Målgruppen for dette dokument er IMM s praktikkoordinatorer, der har bestilt systemet beskrevet i afsnit 3.3. Projektmedlemmer Projektet er udarbejdet af: Mads Nissen, s Referencer Inceptionsdokumentet har ingen eksterne referencer. 3.2 Vision Institut for Matematisk Modellering på DTU har hvert semester studerende der er i ingeniørpraktik eller skriver eksamensprojekt. Til administration af de studerende, deres praktikpladser og deres eksamensprojekter, anvendes Campusnet, delte filer og andre systemer på DTU. Denne administration er beskrevet i en række business cases. De personer der står for denne administration ønsker at optimere processen 1 med en ny webapplikation. En målrettet applikation vil både betyde mindre manuelt arbejde og simplere business cases. Det er tanken at man med den nye applikation helt skal slippe for at anvende flere af de systemer og metoder der anvendes i dag, samt at der kan automatiseres en masse opgaver. Applikationens hovedpunkter ud fra kundens synspunkt: System der er simplere at anvende - både for studerende og ansatte Reducering af manuelt arbejde Simplere business cases Mindre risiko for fejl Mindre tidskrævende administration Det er bestemt at systemet opbygges som en web-applikation baseret på Java. 1 Med processen menes der det samlede arbejde for både ansatte og studerende, fra den studerende søger om optagelse i praktik-systemet til eksamensprojekt afsluttes. 9

10 System der er simplere at anvende Som processen er nu, skal både studerende og ansatte huske en del retningslinier for hvordan administration og kommunikation skal foregå. Desuden anvendes flere forskellige systemer til forskellige dele af processen. Et målrettet system vil kunne gøre denne proces enklere ved at reducere og forsimple retningslinier. Input-validering, fejlmeddelelser og bedre muligheder for at beskrive hvordan systemet skal anvendes vil hjælpe med til at give et system der er simplere at lære og simplere at anvende for både ansatte og studerende. Desuden kan flere af de opgaver der udføres i andre systemer nu, kombineres i det nye system, så processen kan udføres ved færre systemer totalt. Reducering af manuelt arbejde Da der til processen anvendes systemer der ikke er beregnet hertil, indebærer administrationen af praktik og eksamensprojekter en masse manuelt arbejde for alle parter. En stor del af dette manuelle arbejde kan sagtens undgås med et målrettet system. Simplere business cases De business cases der anvendes nu er temmelig volumiøse. Det er derfor tidskrævende både at udføre dem samt at vedligeholde dem. Et målrettet system vil betyde at business cases kan forsimples flere steder. Mindre risiko for fejl Et målrettet system kan foretage input-validering, samt have bedre mulighed for at beskrive hvordan systemet skal anvendes. Dette vil hjælpe med til at minimere risikoen for fejl i processen. Mindre tidskrævende administration De ovenstående punkter vil betyde at hele processen bliver mindre tidskrævende for alle parter. 3.3 Use cases Use cases bruges i stedet for en kravspecifikation og beskriver de handlinger der skal være mulige i systemet. De er ofte meget mere brugbare til at få afdækket brugernes reelle behov, frem for en stor liste af krav. Desuden kan de give en udvikler indsigt i hvilke funktionaliteter der er nødvendige og give denne mulighed at foreslå alternative løsninger som dækker samme behov. 10

11 3.3.1 Use case diagram Figur 1: Use case diagram, del 1 11

12 Figur 2: Use case diagram, del 2 12

13 3.3.2 Aktører Studerende Benytter systemet til at give relevante oplysninger om sig selv, praktikvirksomhed og eksamensprojekt til de øvrige aktører. Anvender desuden systemet til at kommunikere med de øvrige aktører. Der er mange af disse aktører. Praktikassistent Benytter systemet til at hente oplysninger om de studerende og til at administrere deres sager. Anvender desuden systemet til at kommunikere med studerende. Der er typisk én af disse aktører. Praktikkoordinator Benytter systemet til at hente oplysninger om de studerende samt til at administrere sager og godkendelser. Anvender desuden systemet til at kommunikere med studerende. Der er typisk to at disse aktører. DTU Vejleder Benytter systemet til at kommunikere med studerende om deres eksamensprojekt, samt til at hente informationer herom. Antallet af disse aktører kan variere Oversigt over use cases Fælles for alle aktører o (Login) Alle aktører foretager login med DTU s SSO. o (Udsend meddelelse) Udsend meddelelse tilknyttet en sag. o (Se mine meddelelser) Se alle meddelelser for sager brugeren er tilknyttet. o (Se vejledningsdokumenter) Se dokumentation om hvordan systemet skal bruges. o (Udskriv) Få udskrevet informationer og dokumenter. Studerende o (Registrer studerende) Studerende kan udfylde registreringsformular for at søge om optagelse i systemet. o (Opdater form) Der er mulighed for at udfylde og opdatere formularer i systemet. o (Upload std. dok.) Standard dokumenter der ikke kan laves med formularer kan uploades. o (Upload fil) Ikke-standard dokumenter kan uploades til fildeling. o (Godkendelse af praktikplads) Tilkendegiv at praktikplads er fundet og indtastet i systemet. o (Godkendelse af foreløbigt abstract) Tilkendegiv at foreløbigt abstract er udfyldt. o (Godkendelse af praktik) Anmod om godkendelse af praktik på baggrund af informationer i systemet. o (Godkendelse af abstract) Anmod om endelig godkendelse af abstract til eksamensprojekt. Praktikassistent o (Behandl registrering) Godkend indkomne anmodninger om optagelse i systemet. o (Behandl færdigt abstract) Tilknyt projektets løbenummer til sag. Praktikkoordinator o (Godkend praktikvirksomhed) Godkend praktikvirksomhed på baggrund af informationer i systemet. 13

14 o (Godkend foreløbigt abstract) Godkend foreløbigt abstract på baggrund af informationer i systemet. o (Godkend praktik) Godkend praktik på baggrund af informationer i systemet. DTU Vejleder o (Se mine studerende) En vejleder kan få listet alle studerende vedkommende er vejleder for. o (Søg mine studerende) En vejleder kan foretage søgninger efter studerende vedkommende er vejleder for. Fælles for Praktikassistent og Praktikkoordinator o (Se alle studerende) Få listet alle studerende i systemet. o (Søg alle studerende) Søg efter alle studerende i systemet. o (Tilknyt DTU Vejleder) Tilknyt en DTU Vejleder til den studerendes sag. o (Fjern DTU Vejleder) Fjern en tilknyttet DTU Vejleder fra en sag. o (Ændr status for studerende) Skift en studerendes status i systemet. o (Opret / rediger ansat) Opret eller rediger data på en ansat og tildel rolle(r). o (Slet ansat) Slet en ansat fra systemet. o (Opret / rediger form) Opret og bestem indholdet af de forms studerende anvender. o (Slet form) Fjern en form der ikke længere bruges. o (Skjul / vis form for studerende) Skjul en form for studerende uden at slette den. o (Opret / rediger std. dok.) Opret og bestem indholdet af de std. dok. studerende benytter. o (Slet std. dok.) Fjern std. doks. der ikke længere bruges. Fælles for Praktikassistent, Praktikkoordinator og DTU Vejleder o (Se studerendes forms) Se data de studerende har udfyldt forms med. o (Se studerendes std. doks.) Se filer studerende har uploadet under std. doks. o (Se studerendes fildeling) Se de filer studerende har uploadet under fildeling. o (Se studerendes meddelelser) Se meddelelser der er tilknyttet en studerendes sag Use case beskrivelser Følgende er beskrivelser af de use cases der vurderes at være kritiske for systemet. Det er disse use cases der vil blive arbejdet med først for at sikre at de ikke giver problemer der kan have betydning for projektes succes. Design og implementering af disse vil samtidig betyde at størsteparten af systemarkitekturen vil blive konstrueret. 14

15 Use case Registrer studerende. Aktør Studerende. Formål At registrere relevante oplysninger om studerende der ønsker optagelse i systemet. Oversigt Når en studerende skal i praktik næste semester indtastes relevante oplysninger i systemet. Når oplysningerne er gemt i systemet gives der besked til praktikassistenten om dette. Prækondition Den studerende har logget ind med SSO og er ikke registreret i systemet. Postkondition Systemet har godkendt og gemt oplysninger og har underrettet praktikassistenten herom. Frekvens Der registreres op til 50 studerende om dagen i peaks, men ellers under 1 om dagen. Typisk hændelsesforløb: Aktør System 1) Der klikkes på Ansøgning. 2) Systemet viser en formular til indtastning af oplysninger. 3) Der indtastes relevant data. 4) Der klikkes på Send. 5) Systemet validerer og gemmer data. 6) Systemet sender besked til praktikassistenten om ansøgningen. Tabel 1: Use case - Registrer studerende 15

16 Use case Behandl registrering. Aktør Praktikassistent. Formål At godkende en registrering og give en studerende adgang til systemet. Oversigt Når praktikassistenten modtager en besked om en ny registrering skal den behandles og godkendes, hvis alt er i orden. Prækondition Praktikassistenten har logget ind med SSO og der er en ny registrering. Postkondition Systemet har accepteret godkendelsen og underrettet den studerende herom. Frekvens Der godkendes op til 50 registreringer om dagen i peaks, men ellers under 1 om dagen. Typisk hændelsesforløb: Aktør System 1) Der klikkes på Anmodninger. 2) Systemet viser en liste over alle anmodninger. 3) Der klikkes på den studerende hvis registrering skal behandles. 5) Der klikkes på Ansøgning. 7) Der klikkes på Tilbage. 9) Der klikkes på Godkend. 4) Systemet viser en liste med muligheder for den studerendes sag. 6) Systemet viser den studerendes ansøgning. 8) Systemet viser igen listen med muligheder for den studerendes sag. 10) Systemet registrerer at ansøgningen er godkendt. 11) Systemet sender besked til den studerende om godkendelsen. Tabel 2: Use case - Behandl registrering 16

17 Use case Opdater form data. Aktør Studerende. Formål At udfylde / opdatere en formular i systemet med relevant data. Oversigt Den studerende er selv ansvarlig for at udfylde formularer med påkrævet data. Formularens felter udfyldes hvorefter data gemmes i systemet. Prækondition Den studerende er logget ind med SSO. Postkondition Systemet har godkendt og gemt oplysninger. Frekvens Der opdateres op til 50 formularer om dagen i peaks, men ellers under 1 om dagen. Typisk hændelsesforløb: Aktør System 1) Der klikkes på Forms. 2) Systemet viser tilgængelige forms. 3) Der klikkes på den form der skal udfyldes. 4) Systemet viser formularen. 5) Der indtastes relevant data. 6) Der klikkes på Gem. 7) Systemet validerer og gemmer data. Tabel 3: Use case - Opdater form data Use case Godkendelse af praktikplads. Aktør Studerende. Formål At registrere at informationerne om den studerendes praktikplads er klar til at blive godkendt. Oversigt Når en studerende har fundet en praktikplads skal denne godkendes. Den studerende tilkendegiver dette i systemet der sørger for at give besked til praktikkoordinator. Prækondition Den studerende har logget ind med SSO og har opdateret påkrævet data om praktik. Postkondition Systemet har accepteret meldingen og underrettet praktikkoordinator herom. Frekvens Der meldes op til 50 fundne praktikpladser om dagen i peaks, men ellers under 1 om dagen. Typisk hændelsesforløb: Aktør System 1) Der klikkes på Meld: Praktikplads fundet. 2) Systemet registrerer dette. 3) Systemet sender besked til praktikkoordinator om ny praktikvirksomhed. Tabel 4: Use case - Godkendelse af praktikplads 17

18 Use case Godkend praktikvirksomhed. Aktør Praktikkoordinator. Formål At godkende oplysninger om en studerendes praktik. Oversigt Når praktikkoordinatoren modtager en besked om en ny praktikvirksomhed, skal denne virksomhed godkendes. Prækondition Praktikkoordinatoren har logget ind med SSO og der findes en ny praktikvirksomhed. Postkondition Systemet har registreret at virksomheden er accepteret og underrettet den studerende herom. Frekvens Der godkendes op til 50 virksomheder om dagen i peaks, men eller under 1 om dagen. Typisk hændelsesforløb: Aktør System 1) Der klikkes på Anmodninger. 2) Systemet viser en liste over alle anmodninger. 3) Der klikkes på den studerende hvis praktikvirksomhed skal behandles. 5) Der navigeres til de data der beskriver praktikvirksomheden. 7) Der klikkes på Tilbage. 9) Der klikkes på Godkend. 4) Systemet viser en liste med muligheder for den studerendes sag. 6) Systemet viser den studerendes data. 8) Systemet viser igen listen med muligheder for den studerendes sag. 10) Systemet registrerer at praktikvirksomheden er godkendt. 11) Systemet sender besked til den studerende om godkendelsen. Tabel 5: Use case - Godkend praktikvirksomhed 18

19 Use case Upload standard dokument. Aktør Studerende. Formål At uploade et standard dokument i systemet. Oversigt Nogle data kan ikke holdes i formularer i systemet, men uploades i stedet som filer. Prækondition Den studerende har logget ind med SSO. Postkondition Systemet har gemt filen. Frekvens Der uploades op til 50 standard dokumenter om dagen i peaks, men ellers under 1 om dagen. Typisk hændelsesforløb: Aktør System 1) Der klikkes på Dokumenter. 2) Systemet viser tilgængelige standard dokumenter. 3) Der klikkes på det standard dokument der skal uploades en ny fil til. 5) Der klikkes på Upload ny fil. 4) Systemet viser muligheder for anvendelse af standard dokumentet. 6) Systemet viser form til fil-upload. 7) Den fil der skal uploades vælges i formularen. 8) Der klikkes på Gem. 9) Systemet gemmer filen. Tabel 6: Use case - Upload standard dokument 3.4 FURPS+ FURPS+ modellen benyttes til at beskrive de krav der stilles til systemet, som ikke fremgår af use cases. Functional Systemet skal tilgåes via et web-interface. Alle brugere af systemet skal identificere sig ved login inden systemet kan anvendes. Systemet skal kunne give en grafisk repræsentation af studerendes forløb. Systemet skal kunne udsende s ved forskellige hændelser. Usability Web-interfacet skal opbygges så systemet bliver simpelt og intuitivt at anvende. Det skal være nemt at få oplysninger om hvordan systemet kan/skal bruges. Det skal være muligt at benytte de fleste af systemets funktioner med få muse-klik og tastetryk. Reliability Da systemet ikke vil være i brug alle 24 timer i døgnet kan mindre nedetider tolereres, så længe det ikke er noget der sker for ofte. Hvis kun en enkelt web-server og database-server 19

20 anvendes er single-point-of-failure et problem. Ved nedbrud på en af serverne vil systemet være helt utilgængeligt. Længerevarende nedbrud kan ikke tolereres, så for at undgå dette skal en backupløsning findes. Det kan være en spejlet server der kan overtage automatisk, eller manuelt kan startes når det er nødvendigt. Performance Da systemet aldrig vil være tungt belastet af mange samtidige opgaver, er det rimeligt at kræve en hurtig respons-tid når systemet anvendes. Når en bruger sender en anmodning til systemet, skal denne behandles og et svar sendes tilbage, så brugeren har kortest mulig ventetid. For at opnå dette vil web-interfacet ikke indeholde en masse tung grafik. Brugen af database i systemet skal også foregå på en effektiv måde. Ved tidskrævende operationer kan Ajax anvendes for at mindske generne for brugeren. Supportability Administration af brugere og rettigheder kan udføres af praktikassistent og praktikkordinator. Det er også disse brugere der vedligeholder sager og opbygning af formularer. Systemet kan sættes op til automatisk at slette data der findes irrelevant efter en årrække. Yderligere vedligeholdelse og konfigurering foretages af en udvikler. Implementation Systemet opbygges som en Java web-applikation, og implementeringen vil bygge på et framework der hedder Apache Wicket. Databasen vil blive implementeret som en relationel database på en MySQL-server. Til at lette implementeringen af applikationens datatilgang anvendes desuden et ORM framework der hedder Hibernate. Interface Login via DTU s SSO foretages og er begrænset af et eksternt system. Packaging Der vil være en web-server til afvikling af web-applikationen, samt en database-server til håndtering af data. Legal Systemet udvikles til DTU. Alle rettigheder indehaves af DTU. 20

21 3.5 Risikoanalyse Her er beskrevet en række risici der kan få indflydelse på projektplanen. For hver problemstilling er risikoen beskrevet efter følgende skema: Sandsynlighed Konsekvens Faktor 10. Høj sandsynlighed 10. Stor konsekvens Sandsynlighed * Konsekvens 6. Mellem sandsynlighed 3. Mellem konsekvens 3. Lav sandsynlighed 1. Lille konsekvens 1. Meget lav sandsynlighed Ændring af kravspecifikation Sandsynligheden for at denne problemstilling bliver aktuel vurderes til 3, og konsekvensen også til 3. Problemet er altså en faktor 9. Konsekvens: Afhængig af ændringens størrelse kan det blive nødvendigt at gå tilbage i projektet for at tage højde for ændringerne. Kommer ændringerne på et sent tidspunkt kan det gå ud over kvaliteten. Forholdsregler: Det forsøges at sikre at alle krav er kendt, beskrevet og godkendt. Hvis det sker: Vurder hvilket omfang ændringen vil have på projektet. Tilpas tidsplan og revider ressourcefordeling. Deadline kan ikke overholdes Sandsynligheden for at denne problemstilling bliver aktuel vurderes til 3, og konsekvensen også til 3. Problemet er altså en faktor 9. Konsekvens: Overskridelse af deadlines / lavere kvalitet. Forholdsregler: Det tilstræbes at lave realistiske deadlines. Hvis det sker: Øg arbejdsindsatsen eller gå på kompromis med kvaliteten / omfanget. Problemer med udstyr Sandsynligheden for at denne problemstilling bliver aktuel vurderes til 1, og konsekvensen til 3. Problemet er altså en faktor 3. Konsekvens: Problemer med udstyr kan gøre det meget svært at arbejde på projektet. Forholdsregler: Der vil blive foretaget hyppige backups så udstyr kan erstattes uden for meget besvær. Hvis det sker: Hvis problemet ikke kan løses kan der arbejdes videre med andet udstyr. Problemer med SVN på DTU. Sandsynligheden for at denne problemstilling bliver aktuel vurderes til 1, og konsekvensen også til 1. Problemet er altså en faktor 1. Konsekvens: Foretrukken backup-facilitet er ikke tilgængelig. Backup og versionering bliver besværliggjort. Forholdsregler: Ingen. Hvis det sker: Foretag backup på ekstern disk manuelt. 21

22 Oversigt over risici Problem Sandsynlighed Konsekvens Faktor Ændring af kravspecifikation Deadline kan ikke overholdes Problemer med udstyr Problemer med SVN på DTU Tabel 7: Risici ved projektet 4 Analyse-dokument Dette afsnit går i dybden med de use cases der er opstillet i inceptions-dokumentet. De use cases der skal implementeres beskrives i detaljer og der opstilles test cases for enkelte use cases. Derudover beskrives løsningsstrategien for projektet og der udarbejdes en domænemodel. 4.1 Detaljerede use cases De use cases der implementeres i systemet beskrives i detaljer her. Der opstilles tabeller for nogle af de detaljerede use cases, men da de fleste use cases for systemet er temmelig simple, vil der ikke blive opstillet tabeller for dem alle. De vil i stedet blive beskrevet i tekst Fælles for alle Login Når en bruger forsøger at tilgå systemet skal der først logges ind. Systemet viser en form til indtastning af DTU id og password. Brugeren indtaster sine oplysninger og klikker OK, og hvis oplysningerne er korrekte, bliver brugeren logget ind. Hvis oplysningerne ikke er korrekte får brugeren vist en fejlmeddelelse og bliver ikke logget ind. Udsend meddelelse Når en bruger får vist meddelelser for en sag er det muligt at udsende en ny meddelelse til sagen. Ved at klikke på Udsend ny meddelelse -linket åbnes en dialog der lader brugeren indtaste en ny meddelelse. Felterne udfyldes og der klikkes på Send. Den nye meddelelse vises nu i oversigten. Hvis der er fejl bliver meddelelsen ikke gemt, og der vises en fejl-meddelelse. Hvis brugeren fortryder inden der klikkes Send, er det muligt at fortryde ved at klikke på krydset i øverste højre hjørne af dialog-boksen. Se mine meddelelser En bruger kan få vist alle meddelelser for alle sager brugeren har adgang til. Det gøres ved at klikke på linket Meddelelser. Se vejledningsdokumenter Alle brugere kan få vist det vejledningsdokument der beskriver hvordan praktik og eksamensprojekt skal forløbe. Det gøres ved at klikke på linket Information. 22

23 4.1.2 Studerende Registrer studerende Use case Registrer studerende. Aktør Studerende. Formål At registrere relevante oplysninger om studerende der ønsker optagelse i systemet. Oversigt Når en studerende skal i praktik næste semester indtastes relevante oplysninger i systemet. Når oplysningerne er gemt i systemet gives der besked til praktikassistenten om dette. Prækondition Den studerende har logget ind med SSO og er ikke registreret i systemet. Postkondition Systemet har godkendt og gemt oplysninger og har underrettet praktikassistenten herom. Frekvens Der registreres op til 50 studerende om dagen i peaks, men ellers under 1 om dagen. Typisk hændelsesforløb: Aktør System 1) Der klikkes på Ansøgning. 2) Systemet viser en formular til indtastning af oplysninger. 3) Der indtastes relevant data. 4) Der klikkes på Send. Alternativt: Fortsæt fra 3. Tabel 8: Detaljeret use case - Registrer studerende 5) Systemet validerer og gemmer data. 6) Systemet sender besked til praktikassistenten om ansøgningen. 5a) Systemet finder fejl ved validering. 5a1) Systemet viser fejlmeddelelser sammen med formularen. 23

24 Opdater form Use case Opdater form data. Aktør Studerende. Formål At udfylde / opdatere en formular i systemet med relevant data. Oversigt Den studerende er selv ansvarlig for at udfylde formularer med påkrævet data. Formularens felter udfyldes hvorefter data gemmes i systemet. Prækondition Den studerende er logget ind med SSO. Postkondition Systemet har godkendt og gemt oplysninger. Frekvens Der opdateres op til 50 formularer om dagen i peaks, men ellers under 1 om dagen. Typisk hændelsesforløb: Aktør System 1) Der klikkes på Forms. 2) Systemet viser tilgængelige forms. 3) Der klikkes på den form der skal udfyldes. 4) Systemet viser formularen. 5) Der indtastes relevant data. 6) Der klikkes på Gem. 7) Systemet validerer og gemmer data. Alternativt: 6a) Der klikkes på Reset. 6a1) Systemet viser oprindelig data. Fortsæt fra 5. 6b) Der klikkes på Fortryd. 6b1) Systemet går tilbage til forrige tilstand uden at gemme. 7a) Systemet finder fejl ved validering. 7a1) Systemet viser fejlmeddelelser sammen med formularen. Fortsæt fra 5. Tabel 9: Detaljeret use case - Opdater form data Upload std. dok. En studerende kan uploade en fil til et standard dokument der tillader dette. For at gøre dette klikkes først på linket Dokumenter. Derefter vælges det standard dokument der skal uploades en fil til. Systemet viser de muligheder man har for at anvende dokumentet, og der klikkes på Upload fil. En dialog åbner der lader den studerende vælge hvilken fil der skal uploades. Når en fil er valgt klikkes på Upload og files gemmes i systemet. Upload fil En studerende kan uploade en fil under fildeling. Først klikkes på linket Fildeling. Nu vises en oversigt over filer allerede i fildeling med flere valgmuligheder. En ny fil kan enten uploades selvstændigt eller som en ny version af en eksisterende fil. Klik på Upload ny fil eller Ny version. En dialog åbner der lader den studerende vælge hvilken fil der skal uploades. Når en fil er valgt klikkes på Upload og files gemmes i systemet. 24

25 Godkendelse af praktikplads Når en studerende vil have sin praktikplads godkendt og de påkrævede oplysninger findes i systemet, klikkes blot på knappen til dette der findes på startsiden. Godkendelse af foreløbigt abstract Når en studerende vil have sit foreløbige abstract godkendt og de påkrævede oplysninger findes i systemet, klikkes blot på knappen til dette der findes på startsiden. Godkendelse af praktik Når en studerende vil have sin praktik godkendt og de påkrævede oplysninger findes i systemet, klikkes blot på knappen til dette der findes på startsiden. Godkendelse af abstract Når en studerende vil have sit endelige abstract godkendt og de påkrævede oplysninger findes i systemet, klikkes blot på knappen til dette der findes på startsiden. 25

26 4.1.3 Praktikassistent Behandl registrering Use case Behandl registrering. Aktør Praktikassistent. Formål At godkende en registrering og give en studerende adgang til systemet. Oversigt Når praktikassistenten modtager en besked om en ny registrering skal den behandles og godkendes, hvis alt er i orden. Prækondition Praktikassistenten har logget ind med SSO og der er en ny registrering. Postkondition Systemet har accepteret godkendelsen og underrettet den studerende herom. Frekvens Der godkendes op til 50 registreringer om dagen i peaks, men ellers under 1 om dagen. Typisk hændelsesforløb: Aktør System 1) Der klikkes på Anmodninger. 2) Systemet viser en liste over alle anmodninger. 3) Der klikkes på den studerende hvis registrering skal behandles. 5) Der klikkes på Ansøgning. 7) Der klikkes på Tilbage. 9) Der klikkes på Godkend. Alternativt: 9a) Ansøgningen er mangelfuld så der indtastes en besked til den studerende. 9a1) Der klikkes på Afvis. 4) Systemet viser en liste med muligheder for den studerendes sag. 6) Systemet viser den studerendes ansøgning. 8) Systemet viser igen listen med muligheder for den studerendes sag. 10) Systemet registrerer at ansøgningen er godkendt. 11) Systemet sender besked til den studerende om godkendelsen. 9a2) Systemet gemmer data. 9a3) Systemet sender besked til den studerende om afvisningen. Tabel 10: Detaljeret use case - Behandl registrering 26

27 4.1.4 Praktikkoordinator Godkend praktikvirksomhed Use case Godkend praktikvirksomhed. Aktør Praktikkoordinator. Formål At godkende oplysninger om en studerendes praktik. Oversigt Når praktikkoordinatoren modtager en besked om en ny praktikvirksomhed, skal denne virksomhed godkendes. Prækondition Praktikkoordinatoren har logget ind med SSO og der findes en ny praktikvirksomhed. Postkondition Systemet har registreret at virksomheden er accepteret og underrettet den studerende herom. Frekvens Der godkendes op til 50 virksomheder om dagen i peaks, men eller under 1 om dagen. Typisk hændelsesforløb: Aktør System 1) Der klikkes på Anmodninger. 2) Systemet viser en liste over alle anmodninger. 3) Der klikkes på den studerende hvis praktikvirksomhed skal behandles. 5) Der navigeres til de data der beskriver praktikvirksomheden. 7) Der klikkes på Tilbage. 9) Der klikkes på Godkend. Alternativt: 9a) Oplysninger om praktikophold er mangelfuld så der indtastes en besked til den studerende. 9a1) Der klikkes på Afvis. 4) Systemet viser en liste med muligheder for den studerendes sag. 6) Systemet viser den studerendes data. 8) Systemet viser igen listen med muligheder for den studerendes sag. 10) Systemet registrerer at praktikvirksomheden er godkendt. 11) Systemet sender besked til den studerende om godkendelsen. 9a2) Systemet gemmer data. 9a3) Systemet sender besked til den studerende om afvisningen. Tabel 11: Detaljeret use case - Godkend praktikvirksomhed 27

28 Godkend foreløbigt abstract Når et foreløbigt abstract skal godkendes klikkes først på linket Anmodninger. Derefter vises en liste over anmodninger fra studerende, og den studerende hvis foreløbige abstract skal godkendes vælges fra listen. Nu vises en liste med muligheder for den studerendes sag. Herfra er det muligt at se den studerendes udfyldte forms, uploadede standard dokumenter og fildeling. Hvis alt er i orden klikkes på Godkend knappen. Hvis alt ikke er i orden indtastes eventuelt en meddelelse til den studerende og der klikkes på Afvis. Godkend praktik Når en afsluttet praktik skal godkendes klikkes først på linket Anmodninger. Derefter vises en liste over anmodninger fra studerende, og den studerende hvis praktik skal godkendes vælges fra listen. Nu vises en liste med muligheder for den studerendes sag. Herfra er det muligt at se den studerendes udfyldte forms, uploadede standard dokumenter og fildeling. Hvis alt er i orden klikkes på Godkend knappen. Hvis alt ikke er i orden indtastes eventuelt en meddelelse til den studerende og der klikkes på Afvis DTU Vejleder Se mine studerende En DTU Vejleder kan få vist en liste over de studerende denne er vejleder for. Dette gøres ved at klikke på linket Studerende. Søg mine studerende I listen over studerende er det også muligt at søge efter studerende. Siden indeholder en form der tillader søgning baseret på studerendes navn, studie-nummer samt status for praktik og eksamensprojekt. En DTU Vejleder kan kun fremsøge egne studerende Fælles for Praktikassistent og Praktikkoordinator Se alle studerende En liste over alle aktive studerende i systemet kan fås ved at klikke på linket Studerende. Søg alle studerende I listen over studerende er det også muligt at søge efter studerende. Siden indeholder en form der tillader søgning baseret på studerendes navn, studie-nummer samt status for praktik og eksamensprojekt. Tilknyt DTU Vejleder En studerende skal have tilknyttet en DTU Vejleder før der skrives eksamensprojekt. Fra listen over muligheder for den studerendes sag klikkes på Administrer. Systemet viser nu en række muligheder for at administrere sagen. Et tekstfelt tillader at der indtastes DTU id på den vejleder der skal tilknyttes og et tryk på Tilknyt -knappen gemmer data i systemet. Fjern DTU Vejleder Fra samme side som man tilføjer en DTU Vejleder til en sag, er det også muligt at fjerne en. Siden indeholder en liste af de DTU id er der er tilknyttet den studerendes sag, og et lille kryds gør det muligt at fjerne et tilknyttet DTU id igen. Ændr status for studerende Det er muligt manuelt at ændre en studerendes status i systemet. På samme side som nævnes i de forrige to use cases er to dropdowns der gør det muligt at ændre status for en studerendes praktik og eksamensprojekt. Når begge dropdowns er indstillet som ønsket klikkes på Gem. 28

29 Opret / rediger ansat Det er muligt manuelt at oprette og redigere DTU ansattes brugere, deres oplysninger og roller. Dette gøres ved at klikke på linket Administrer og derefter på Administrer ansatte. Systemet viser nu en liste over de ansatte der findes i systemet. Et link, Opret ny ansat, gør det muligt at oprette en ny bruger, indtaste oplysninger og tildele roller. Ved at klikke på en ansat i listen er det muligt at ændre en eksisterende bruger. Slet ansat Hvis det ikke længere er nødvendigt at have en ansat i systemet er det muligt at fjerne denne. Fra listen nævnt i forrige use case er det muligt at fjerne en ansat ved at klikke på et lille kryds ud for den ansattes navn. Opret / rediger form De forms der er tilgængelige for studerende, kan oprettes og redigeres via systemet. Først klikkes på Administrer og derefter på Administrer forms. Nu vises to lister der tilsammen viser alle forms i systemet. Den første liste er de forms der vises for studerende, den anden er de forms der er deaktiverede og ikke vises for studerende. Der kan klikkes på Opret ny form eller vælges en eksisterende form og klikkes på Rediger for denne. Systemet viser en ny side der gør det muligt at opbygge en form. En række knapper kan bruges til at tilføje elementer til formularen. Det er muligt at angive en titel til formularen, navne til hvert input element, samt at ændre rækkefølgen på de elementer der er tilføjet formularen. En Tilbage -knap kan bruges til at gå tilbage uden at gemme ændringer, og en Gem -knap til at gemme ændringerne. Slet form Forms der ikke længere skal bruges kan fjernes fra systemet. På Administrer forms siden vælges den form der skal fjernes og der klikkes på Slet. Skjul / vis form for studerende Hvis en form ikke skal være tilgængelig for studerende, men man ikke ønsker at slette den, kan den skjules for studerende. På Administrer forms siden vælges den form der skal fjernes og der klikkes på Deaktiver. En form der allerede er skjult for studerende vil have et Aktiver -link i stedet for. Opret / rediger std. dok. Det er muligt at oprette og redigere standard dokumenter og bestemme hvordan de kan bruges af studerende. Først klikkes på Administrer og så på Administrer standard dokumenter. Nu vises en liste over de standard dokumenter der er definerede i systemet. De eksisterende dokumenter kan redigeres ved at klikke på deres navn i listen, og et nyt dokument kan defineres ved at klikke på Opret nyt. Fra Opret / rediger dialogen er det muligt at vælge en skabelon for dokumentet som studerende kan downloade, og det er muligt at angive et navn for dokumentet samt at angive om studerende skal kunne uploade egne filer under dette dokument. Slet std. dok. Standard dokumenter der ikke længere skal bruges kan fjernes igen. Fra listen af dokumenter på siden Administrer standard dokumenter, er det muligt at fjerne et dokument ved at klikke på krydstet ud for navnet. 29

30 4.1.7 Fælles for Praktikassistent, Praktikkoordinator og DTU Vejleder Se studerendes forms Det er muligt at se alle de forms en studerende har udfyldt. Fra siden til visning af en studerendes sag klikkes på Forms. Dette giver en liste over de forms den studerende har anvendt. Vælg en form og systemet vil vise den. Se studerendes std. doks. Det er muligt at se alle de std. doks en studerende har anvendt. Fra siden til visning af en studerendes sag klikkes på Standard dokumenter. Dette giver en liste over standard dokumenter. Vælg et og systemet vil vise indholdet. Se studerendes fildeling Det er muligt at se en studerendes fildeling. Fra siden til visning af en studerendes sag klikkes på Fildeling. Systemet viser nu de filer den studerende har lagt under fildeling. Se studerendes meddelelser Det er muligt at se de meddelelser der er tilknyttet til en studerendes sag. Fra siden til visning af en studerendes sag klikkes på Meddelelser. Systemet viser nu de meddelelser der er udsendt under sagen. 4.2 Test cases For at kunne teste hvorvidt de funktionelle krav er opfyldt, er der udarbejdet nogle test cases. Der er kun opstillet test cases for de detaljerede use cases der er beskrevet i tabeller i forrige afsnit. Hvordan de øvrige use cases skal testes er beskrevet i afsnit 9. Test case Aktør Formål Prækondition Postkondition Testforløb: Aktør 2) Klik på Ansøgning. 4) Udfyld felter. 5) Klik på Send. Alternativt: Fortsæt fra 4. Registrer studerende. Studerende. At teste om det er muligt at registrere sig i systemet. Den studerende er logget ind med DTU SSO og er ikke registreret i forvejen. Relevant data er gemt og praktikassistenten er blevet underrettet. System 1) System viser en startside. Tabel 12: Test case - Registrer studerende 3) Systemet viser en formular til angivelse af oplysninger. 6) Systemet gemmer data uden valideringsfejl. 6a) Systemet viser fejlmeddelelser samt formularen. 30

31 Test case Aktør Formål Prækondition Postkondition Testforløb: Aktør 2) Klik på anmodninger. 4) Klik på den studerende hvis anmodning skal behandles. 6) Klik på Ansøgning. Behandl registrering. Praktikassistent. At teste om det er muligt at behandle en ny registrering. Praktikassistenten er logget ind med SSO og der er en ny registrering. Den studerende er optaget i systemet og har fået besked om det. System 1) Systemet viser en startside. 3) Systemet viser liste over brugere med ventende anmodninger. 5) Systemet viser en liste med muligheder for den studerendes sag. 7) Systemet viser den studerendes ansøgning. 8) Klik på Tilbage. 9) Systemet viser igen en liste med muligheder for den studerendes sag. 10) Klik på Godkend. Alternativt: 10a) Indtast besked til den studerende om hvorfor anmodningen afvises. 10a1) Klik på Afvis. Tabel 13: Test case - Behandl registrering 31

32 Test case Aktør Formål Prækondition Postkondition Testforløb: Aktør 2) Klik på Forms 4) Klik på den form der skal opdateres. 6) Rediger ønskede felter. 7) Klik på Gem. Alternativt: 7a) Klik på Reset. Fortsæt fra 6. 7b) Klik på Fortryd. Fortsæt fra 6. Opdater form data. Studerende. At teste om det er muligt at opdatere form data i systemet. Den studerende er logget ind med DTU SSO. Opdateret data er gemt. Tabel 14: Test case - Opdater form data System 1) Systemet viser en startside. 3) Systemet viser tilgængelige forms. 5) Systemet viser side til redigering af formularen. 8) Systemet gemmer data uden valideringsfejl. 7a1) Systemet viser oprindelig data. 7b1) Systemet går tilbage til forrige tilstand uden at gemme. 8a) Systemet viser fejlmeddelelser samt formular. 32

33 Test case Aktør Formål Prækondition Postkondition Testforløb: Aktør 2) Klik på anmodninger. 4) Klik på den studerende hvis anmodning skal behandles. 6) Naviger til de oplysninger den studerende har angivet om praktikopholdet. Godkend praktikvirksomhed. Praktikkoordinator. At teste om det er muligt at godkende en ny praktikvirksomhed. Praktikkoordinatoren er logget ind med SSO og der er en ny praktikvirksomhed. Den studerendes praktikvirksomhed er godkendt og den studerende har fået besked om dette. System 1) Systemet viser en startside. 3) Systemet viser liste over brugere med ventende anmodninger. 5) Systemet viser en liste med muligheder for den studerendes sag. 7) Systemet viser data. 8) Naviger tilbage til listen med muligheder. 9) Systemet viser igen en liste med muligheder for den studerendes sag. 10) Klik på Godkend. Alternativt: 10a) Indtast besked til den studerende om hvorfor anmodningen afvises. 10a1) Klik på Afvis. Tabel 15: Test case - Godkend praktikvirksomhed 4.3 Løsningsstrategi Udviklingen af dokument- og sagsstyringssystemet vil foregå efter Unified Process metoden. Denne model er iterativ og inkrementel og medfører blandt andet at der tidligt i forløbet findes et funktionelt system, der løser nogle use cases, og som projektet skrider frem løser flere og flere. Projektarbejdet vil tage udgangspunkt i use cases med fokus på at behandle risikoområder så tidligt i projektet som muligt. Projektet er indelt i timeboxes. Indelingen kan ses på Figur 3. Inceptionsfasen bliver brugt til at få overblik over projektet, samt til at skabe en plan for arbejdet ud fra kundens ønsker og behov. I denne fase arbejdes der med use cases af forretningsmæssig betydning for at opnå forståelse for kundens forretning og vision. Elaborationsfasen benyttes til at analysere forretningsmæssige og systemmæssige problemstillinger og til at designe systemet. I hver iteration af elaborationen vil der blive arbejdet med alle seks UP discipliner for nogle få use cases. Der arbejdes med use cases af betydning for både forretning og system og der fokuseres på høj-værdi- og høj-risiko-problemstillinger. I tidlige 33

34 iterationer vil der være mest arbejde med analyse og arkitektur, men som tiden går vil design fylde mere. I constructionfasen skal hovedparten af analyse og design være på plads, ligesom systemarkitekturen også gerne skal være nogenlunde fast. Derfor kan der i denne fase fokuseres på implementering af de resterende use cases. Transition er den sidste fase i UP. I denne fase arbejdes med at gøre systemet klar til produktion. Systemet vil blive modelleret ved hjælp af udvalgte UML artefakter. Figur 3: Iterationsplan 34

35 4.4 Domænemodel For at vise konceptet for det system der produceres er der udarbejdet en domænemodel. Domænemodellen kan ses på Figur 4. Figur 4: Domænemodel 35

36 5 Design-dokument Dette afsnit omhandler systemets design. Det indeholder package-diagram og en gennemgang af de overvejelser der er gjort i forbindelse med design af systemet. 5.1 Package-diagram Den overordnede struktur af systemets implementation modelleres med et package-diagram. Package-diagrammet kan ses på Figur 5. Figur 5: Package-diagram 36

37 5.2 Designovervejelser Mange af funktionerne i webapplikationen kan implementeres på flere forskellige måder. Beslutninger om hvilke løsningsmodeller der implementeres er taget ud fra en vurdering af metodernes muligheder og begrænsninger sammenholdt med brugernes behov. Dette afsnit beskriver de overvejelser og valg der er gjort i forbindelse med udvikling af webapplikationen. De overvejelser der er gjort i forbindelse med databasen er ikke medtaget her, men kan i stedet læses i afsnit Fildeling Det skal være muligt for brugere af applikationen at dele filer. Der er flere metoder at implementere denne fildeling på, og fordele og ulemper ved hver metode. Den første mulighed er at benytte filsystemet på den webserver applikationen deployes på. Denne metode virker ret oplagt at benytte da filsystemet jo er beregnet til at håndtere filer. Problemet ved denne løsning er at applikationens data nu er delt mellem databasen og webserveren. Dette vil gøre backup af data mere besværlig. Samtidig vil det kræve lidt mere arbejde at holde styr på hvilke filer der tilhører hvilke brugere, samt at understøtte versionering af filerne. En anden mulighed er at benytte databasen til at gemme filerne. På den måde vil alt data være samlet et sted, hvorved backup bliver nemmere. Ulempen her er at databasen ikke er beregnet til at håndtere filer, så det er lidt omstændigt at bruge den til dette. Til gengæld er det nemt at administrere ejerne af filerne samt versionering. Det er også muligt at benytte en blanding af filsystem og database ved for eksempel at gemme filerne på webserveren og holde stierne til filerne i databasen. På den måde får man effektiv håndtering af filerne med filsystemet, samtidig med at det er nemt at holde styr på versionering samt hvem der ejer filerne med databasen. Dette løser dog ikke problemet med backup da data stadig er delt mellem webserver og database. Endelig er det også en mulighed at købe en file-storing service hos en virksomhed der specialiserer i håndtering af filer Til denne applikation er det valgt at fildeling implementeres som en ren databaseløsning. Denne løsning er valgt da det forventes at der kun bliver uploadet rimelig små filer (på et par MB), at der ikke skal håndteres ekstremt mange filer samt at det vil være rart med en løsning der giver nem backup og versionering. Det er ikke kun fildelings-funktionen der får behov for at gemme filer - beslutningen om at anvende en database-løsning er taget på baggrund af systemets samlede behov for filhåndtering. Noget andet der skal tages stilling til er hvilke funktioner der skal være mulige under fildeling, samt hvilke rettigheder studerende skal have. Hvis det blot skal være en meget simpel fildeling, hvor brugere kan uploade filer til deres egen fildeling, vil implementeringen også blive meget simpel. Hvis systemet skal understøtte versionering, så der kan uploades nye versioner af eksisterende filer, bliver det lidt mere avanceret at implementere. Hvis der så også skal være mulighed for at organisere filerne yderligere (f.eks. ved at oprette mapper i fildeling), bliver systemet igen mere avanceret. Da fildeling vurderes at være en funktion der kun vil blive anvendt af få brugere, vil den helt avancerede løsning med mappe-strukturer ikke blive implementeret. I stedet vil der blive implementeret en flad fildeling med versioneringsmuligheder. Hvor vidt en bruger skal have lov til at fjerne filer fra fildeling afhænger af hvor sikker man vil være på ikke at miste vigtig data. Hvis brugere får lov at fjerne filer, kan de også fjerne filer man gerne vil beholde. 37

38 Hvis brugere ikke får lov at fjerne filer, kan de intet stille op hvis de kommer til at uploade en forkert fil. Sidstnævnte er nok den løsning der er nemmest at leve med, men det vil være bedre at finde en løsning midtimellem de to. En mulig bedre løsning er at anvende soft-delete og så give brugere lov til at fjerne filer. På den måde kan filerne beholdes i databasen, mens de kan skjules fra brugerens fildeling i applikationen. En anden løsning kunne være at anvende en låse -mekanisme, så visse brugere kan låse en fil og derved forhindre at den kan fjernes. Det er også muligt både at have soft-delete og lås, for endnu bedre styringsmuligheder. I dette system er det valgt at anvende soft-delete løsningen Status Gennem en studerendes praktik- og eksamensforløb anvendes forskellige statusser til at angive præcis hvor langt den studerende er i forløbet. Det er forsøgt at strømline dette forløb, og det beskrives nøje for de studerende hvordan praktik og eksamensprojekt normalt forløber. Dette betyder at for mange studerende er forløbet meget ens, og det kan umiddelbart virke som en god idé at have en enkelt status for hver studerende. Denne status kan så ændres hver gang den studerende kommer et skridt videre i forløbet. Dette kan fungere fint for studerende der følger normal-forløbet, men er samtidig meget ufleksibelt for studerende der ikke gør dette. Ved at skille den studerendes status i to - en for praktik og en for eksamensprojekt - kan man opnå større fleksibilitet for special-tilfælde, mens det stadig er muligt at have et strømlinet normalforløb. I dette system vil den sidste model blive implementeret Standard dokumenter / Bruger dokumenter Standard dokumenter og Bruger dokumenter er funktioner der kræver at systemet er i stand til at håndtere filer. Som tidligere beskrevet gemmes filer i databasen. Et standard dokument kan indeholde en fil, der kan downloades af brugere. Desuden kan et standard dokument tillade at brugerne uploader deres egne Bruger dokumenter knyttet til et Standard dokument. Med hensyn til Standard dokumenter skal der tages stilling til om systemet skal kunne versionere de skabelon -filer der tilknyttes. Hvis systemet håndterer tidligere versioner kan de aktører der administrerer Standard dokumenter altid se hele historikken for skabelon -filer. Hvis en fil ændres ofte kan det dog betyde at der hurtigt kommer mange versioner i systemet. Hvis filerne ikke versioneres betyder det at de aktører der administrerer dokumenter selv har ansvaret for at bevare tidligere versioner, hvis det ønskes. I dette system er det valgt at skabelon -filer ikke versioneres. For de Bruger dokumenter som studerende uploader, kan det imidlertid ikke forventes at DTU ansatte skal håndtere versionering, og da tidligere versioner af uploadede filer skal være let tilgængelige i systemet, vil der bliver implementeret versionering af disse filer. Med hensyn til om studerende skal have rettigheder til at fjerne deres uploadede filer fra Bruger dokumenter, er mange af de ting der skal overvejes de samme der blev overvejet for sletning i fildeling. Man ønsker ikke at de studerende helt kan fjerne vigtig data. Det er valgt at studerende ikke skal have lov at fjerne uploadede Bruger dokumenter - ikke engang med soft-delete. Denne beslutning tages ud fra en forestilling om at det skal være nemt at finde filer, den studerende måske ser som out-datede og gerne ville fjerne. 38

39 5.2.4 Find studerende Det skal være muligt at få listet de studerende der findes i systemet, samt at søge efter studerende. Der er klart at aktører som praktikassistent og praktikkoordinator skal kunne se alle studerende på denne måde, men med hensyn til DTU vejledere skal der tages stilling til om de skal kunne se alle studerende eller kun de studerende de selv er vejleder for. Det er valgt at en vejleder kun skal kunne se egne studerende. På denne måde undgår man at studerendes data bliver tilgængeligt for uvedkomne, samt at systemet bliver mere overskueligt for vejledere. En anden ting der er værd at overveje er hvordan studerende der har afsluttet eksamensprojekt skal håndteres. Hvis der ikke skelnes mellem aktive og færdige studerende vil der hurtigt blive mange færdige studerende i listen. Da det kun sjældent er nødvendigt at finde en sag for en studerende der har afsluttet eksamensprojekt vil disse studerende blive filtreret fra i liste-visning og søgning af studerende, med mindre der eksplicit angives at færdige studerende skal vises. 6 Datamodellering Dette afsnit omhandler den datamodel der anvendes i systemet. De overvejelser der er gjort i forbindelse med datamodellen gennemgåes, og det beskrives hvordan en relationel model er blevet til ud fra domænemodellen. 6.1 Designovervejelser Her beskrives de overvejelser og valg der er foretaget i forbindelse med design af datamodellen Fildeling Det er besluttet at fildeling skal implementeres som en databaseløsning. Den database der anvendes har ikke nogen fil -datatype, men det er muligt at gemme en fil i et blob-felt (Binary Large OBject). En fil uploadet under fildeling skal være knyttet til en bestemt bruger, der så ejer filen. For at opnå dette kan man oprette en enkelt tabel der både indeholder et blob-felt til filen, samt en fremmednøgle til en bruger. Da der ønskes versionering af de filer der uploades under fildeling bliver det dog et problem, at nøjes med en enkelt tabel til fildeling. Hvis der tilføjes et versions-felt til fil-tabellen vil det ikke være muligt at skelne hvilke filer der hører sammen, og hvis der tilføjes endnu et felt til at skabe denne gruppering har vi pludselig en tabel med redundant data og mulig opdateringsanomali. En bedre løsning vil være at have en tabel der kun holder en fil, en tabel der beskriver en gruppering af filer, samt en tabel med en version-attribut til at beskrive relationen mellem filtabellen og gruppe-tabellen. Det sidste løsningsforslag er implementeret da der ønskes versioneringsmuligheder. Desuden giver denne løsning en fordel da fil-tabellen kan genbruges på andre områder der kræver mulighed for at gemme en fil i databasen Forms Én use case beskriver hvordan det skal være muligt for visse aktører at redigere opbygningen af de forms som studerende kan udfylde. Det skal kunne gøres i en browser via webapplikationen, så der skal designes en datamodel der tillader dette. Opbygningen af en form kunne holdes i xml og det samme kunne de data de studerende indtaster i forms. Dette vil kun kræve en meget simpel datamodel, og medføre at ændringer i hvad en form 39

40 kan opbygges af og indholde, ikke vil betyde nogen ændring i databasen. Samtidig vil det betyde at applikationen skal være mere avanceret for at kunne håndtere informationerne i xml-format. En anden mulighed er at lave type-inddelte tabeller i databasen, hvor én tabel i databasen svarer til ét element i en form. På den måde kan en form opbygges af forskellige typer af elementer. I dette system vil der ikke være nogle store fordele eller ulemper ved at vælge den ene løsning frem for den anden, så metoden med type-inddelte tabeller er valgt ud fra en vurdering af at det vil være simplest at implementere. Det skal være muligt for visse aktører at fjerne forms der ikke længere er aktuelle. Da det skal være muligt at se studerendes indtastede data selv efter en form er fjernet vil sletning af en form give problemer. I stedet kan anvendes soft-delete - et felt introduceres til angivelse af om en form er slettet eller ej. Ud over dette delete -felt kan der også introduceres et felt til angivelse af om en form er aktiv eller ej. Meningen med dette er at visse aktører kan deaktivere en form, så den ikke vises for studerende, men heller ikke er angivet som slettet. På den måde kan en form nu enten vises for alle, skjules udelukkende for studerende, eller skjules for alle. Dette kan også opnås med et enkelt felt i databasen der kan antage 3 værdier (f.eks. en ENUM). Det er valgt at implementere denne sletning / visning med to BOOL felter i databasen. Når en form der er i brug af studerende ændres må dette ikke kunne give problemer med allerede gemt data. Derfor skal en form der er i brug, gemmes som en ny form når der foretages ændringer i opbygningen, og den tidligere udgave skal soft-deletes Standard dokumenter Et standard dokument bruges til at ensrette brugen af ofte anvendte filer. Et standard dokument har et navn, kan have en fil som skabelon, og kan tillade brugere at uploade filer der knyttes til standard dokumentet. Den fil-tabel der allerede findes til fildeling, kan med fordel anvendes her. Ved at oprette en std.dok.-tabel med en fremmednøgle til en fil i fil-tabellen, kan der knyttes en skabelon-fil til et standard dokument. Ved at undlade at gøre denne fremmednøgle obligatorisk kan et standard dokument eksistere uden en skabelon. Da skabelonerne til et standard dokument ikke skal kunne versioneres, er der ikke behov for andet end en enkelt ny tabel for at datamodellen understøtter standard dokuenter Bruger dokumenter Bruger dokumenter er en gruppering af versionerede filer der er knyttet til et standard dokument. Bruger dokumenter er meget lig fildelingsdokumenter, blot med en relation til et standard dokument. De kan derfor også implementeres på samme måde. Filerne holdes i fil-tabellen, grupperingen beskrives i en ny tabel, og relationen mellem fil og gruppe beskrives i en tabel med version-attribut Registrering En studerende bliver optaget i systemet ved at udfylde en registrerings-form. Da det er muligt at definere forms via systemet, kunne man også vælge at lade registrerings-formularen være en form der var defineret på denne måde. Fordelen ved dette vil være at registrerings-formularen kan ændres via systemet, samt at der ikke skal findes en specifik tabel til at holde de udfyldte registreringer. Ulempen er at datamodellen for forms skal udvides for at kunne understøtte dette, samt at man skal være sikker på at der altid er præcis én aktiv registrerings-formular i systemet. 40

41 Ved at have en tabel specielt beregnet til registreringer, undgår man at gøre datamodellen for forms mere avanceret for alle de forms der ikke er registreringer, samtidig med at man undgår at skulle tage højde for om registrerings-formularen bliver slettet eller om der bliver oprettet flere end én. Løsningsmodellen med en tabel specifikt til registreringer er valgt. Et andet spørgsmål vedrørende registreringer er hvordan de angivne kurser skal gemmes. En registrering skal indeholde informationer om hvilke kurser de studerende følger ved ansøgningen, samt hvilke kurser de planlægger at tage. Det ønskes at der vises både kursus-nr., kursus-navn, sidste undervisningsdag, frist for karaktergivning og point for alle angivne kurser. Disse informationer bør være ens når et kursus refereres flere gange. Dette kan for eksempel opnås ved at studerende kun angiver kursus-nr. og de resterende oplysninger hentes fra DTU s kursus-base. Alternativt kan det opnås ved at alle informationerne bliver gemt én gang i databasen for hvert kursus-nr., men så opstår spørgsmålet om hvem der skal vedligeholde disse data. En anden måde at komme omkring de studerendes kurser er ved at lade alle studerende indtaste alle kursus-oplysninger og gemme alle data for hver studerende der udfylder en registrering. Den optimale løsning vil helt klart være at hente kursus-oplysninger fra DTU s kursus-base. Det vil betyde at studerende kun skal indtaste kursus-nr., der skal gemmes mindre data i databasen, man undgår redundant data og minimerer risikoen for forkerte kursus-oplysninger. Denne løsning vil dog ikke blive implementeret i dette projekt, men i stedet vil de studerende selv skulle indtaste alle oplysninger og alle oplysninger blive gemt Tilknyt vejleder Det skal være muligt at tilknytte en eller flere DTU Vejledere til en studerende. Den umiddelbare løsning ville være at oprette en tabel med to fremmednøgler, begge til bruger-tabellen. Den ene fremmednøgle ville angive den studerende, og den anden en vejleder. Dette vil kræve at både studerende og vejleder eksisterer som brugere af systemet. Da det ikke er tanken at praktikassistent eller praktikkoordinator skal være ansvarlig for at oprette vejledere i systemet, kan det give problemer hvis der skal tilknyttes en vejleder der endnu ikke er oprettet i systemet. Ved at droppe fremmednøglen for vejlederen og i stedet blot gemme vejlederens DTU id, kan der sagtens tilknyttes vejledere der endnu ikke findes i systemet. Problemet med dette er at der indføres redundant data, at det kan betyde opdateringsanomali, samt at det bryder normalisering af datamodellen. En bedre løsning kunne være at lade systemet oprette en ny bruger, når der indtastes et vejleder DTU id der ikke findes i systemet. På denne måde kan en tabel med to fremmednøgler stadig benyttes til at knytte vejledere til studerende - og så kan systemet for eksempel bede vejlederen om manglende bruger-oplysninger ved dennes førstkommende login. Den nuværende datamodel anvender tabellen med kun én fremmednøgle samt vejlederens DTU id. Dette er ikke tænkt som den endelige løsning og bør helt sikkert ændres ved videre udvikling Status Da det allerede i afsnit er besluttet at status for praktik og eksamensprojekt skal være adskilt af hensyn til fleksibilitet, skal datamodellen designes så dette lader sig gøre. Der er flere mulige løsninger til dette. Da en status, hvad enten det er for praktik eller eksamensprojekt, blot er en kort tekst, kan alle statusser i systemet sagtens holdes i en enkelt tabel. Men det er også muligt at oprette to tabeller 41

42 - én for praktikstatus og én for projektstatus. Ved at have alle statusser i en tabel kan man spare en tabel, et par tupler og få en lidt simplere datamodel. Ved at dele status i to tabeller bliver det enklere at skelne de to typer for udviklere og man undgår risikoen for at en brugers praktikstatus kan referere til en projektstatus og omvendt. Til dette projekt et det valgt at oprette to tabeller til status. 6.2 Begrebsmæssigt databasedesign Her vil de enkelte entiteter og deres berettigelse blive forklaret. Deres interne relationer vil blive forklaret første gang de optræder. Ansøgning - Indeholder informationer om studerende der skal eller er igang med praktik eller eksamensprojekt. Relationer: Bruger, for at knytte en bestemt bruger i systemet til registreringen. Forløb, for at indikere hvilket studieforløb ejeren af ansøgningen følger. Kursus, for at knytte beskrivelser af brugerens nuværende og planlagte kurser til ansøgningen. Forløb - Indeholder informationer om forskellige studieforløb. Kursus - Indeholder informationer om studerendes kurser. Fil - Indeholder en fil, hvis indhold ikke administreres af systemet. Relationer: Standard dokument, for at knytte et Standard dokument til en bestemt Fil. Bruger dokument, for at knytte et Bruger dokument til en bestemt Fil. Fildelingsdokument, for at knytte et Fildelingsdokument til en bestemt Fil. Standard dokument - Beskriver en måde at downloade / uploade ofte anvendte filer på. Relationer: Bruger dokument, for at knytte et Bruger dokument til et bestemt Standard dokument. Bruger dokument - Beskriver de filer en bruger har uploadet til et standard dokument. Relationer: Bruger, for at knytte dokumentet til en bestemt bruger. Fildelingsdokument - Beskriver de filer en bruger har uploadet, der ikke er standard dokumenter. Relationer: Bruger, for at knytte dokumentet til en bestemt bruger. Formular - Beskriver en formular i systemet som studerende kan udfylde. En formular består af mange paneler. Relationer: Panel, for at knytte bestemte Paneler til en bestemt formular. Formdata, for at knytte Formdata til en bestemt formular. Panel - Beskriver en måde hvorpå den studerende kan angive oplysninger. Et panel er en del af en formular. Relationer: Paneldata, for at knytte et Paneldata til et bestemt Panel. Datopanel / panel / Telefonpanel / Tekstpanel, mandatory or relation fordi et Panel skal være en af de fire specialiseringer. Datopanel - Et panel der lader en bruger angive en dato. panel - Et panel der lader en bruger angive en adresse. 42

43 Telefonpanel - Et panel der lader en bruger angive et telefon nummer. Tekstpanel - Et panel der lader en bruger angive en tekst. Formdata - Beskriver data der hører til en bestemt formular og tilhører en bestemt bruger. En formdata består af mange paneldata. Relationer: Bruger, for at knytte en Formdata til den bruger der ejer den. Paneldata, for at knytte bestemte Paneldata til en bestemt Formdata. Paneldata - Beskriver data. En Paneldata hører til et Panel. Relationer: Datodata / data / Telefondata / Tekstdata, mandatory or relation fordi et Paneldata skal være en af de fire specialiseringer. Datodata - Indeholder en dato. data - Indeholder en . Telefondata - Indeholder et telefonnummer. Tekstdata - Indeholder noget tekst. Praktikstatus - Beskriver de statusser der findes for studerendes praktikforløb. Hver status har et navn. Relationer: Bruger, for at knytte en bestemt praktikstatus til en bruger. Projektstatus - Beskriver de statusser der findes for studerendes eksamensprojekter. Hver status har et navn. Relationer: Bruger, for at knytte en bestemt projektstatus til en bruger. Vejleder - Indeholder et DTU id på en bruger der skal tilknyttes en sag. Relationer: Bruger, for at knytte en Vejleder til en bruger. Meddelelse - En meddelelse indeholder et emne og en brødtekst. Relationer: Bruger, for at knytte en meddelelse til en brugers sag, samt for at angive afsender af meddelelsen. Bruger - Indeholder informationer om brugerne af systemet. Hver bruger har et dtu-id og et navn. Relationer: Role, for at knytte en eller flere roller til brugeren. Role - Indeholder informationer om mulige roller i systemet. Hver rolle har et navn. 6.3 Logisk databasedesign Mapping Den begrebsmæssige datamodel (ER-diagrammet) mappes til en relationel model, da der anvendes en relationel database. Valget af primærnøgler i entiteterne gøres lidt specielt da der anvendes Hibernate til database-tilgang - der introduceres nemlig et id-felt i alle tabeller der skabes ud fra mappingen. Dette id-felt benyttes altid som primærnøgle. Herunder vil jeg gennemgå nogle eksempler på hvordan mappingen er blevet gjort. Det er ikke en komplet gennemgang - sammenhold eventuelt domænemodellen (Figur 4, side 35) med den relationelle model (Figur 6, side 46) for at se hvordan mappingen er foretaget. 43

44 1. Stærke entiteter Stærke entiteter er entiteter der har deres egen nøgle og kan eksistere uafhængigt af andre. For hver stærk entitet oprettes en tabel. Eksempler på stærke entiteter er: Rolle, Forløb og Projektstatus. 2. Svage entiteter Der oprettes en tabel med alle attributter fra entiteten. Svage entiteter er afhængige af andre entiteter for at kunne identificeres unikt. Normalt dannes primærnøglen i en svag entitet af attributter fra både entiteten selv og en relateret entitet, men da der anvendes Hibernate introduceres i stedet et id-felt i de svage attributter. Eksempler på svage entiteter er: Ansøgning, Meddelelse og Kursus. 3. Binære 1:n relationer Ved binære 1:n relationer kopieres primærnøglen fra 1 -siden over som fremmednøgle på mange -siden. Et eksempel er relationen Forløb 1:n Ansøgning. Primærnøglen fra Forløb kopieres over i Ansøgning, så en Ansøgning kan have 1 Forløb og et Forløb kan anvendes i mange Ansøgninger. 4. Binære 1:1 relationer Ved binære 1:1 relationer afhænger mappingen af hvorvidt der er obligatorisk deltagelse på begge sider eller ej. Et eksempel er relationen Standard dokument 1:1 Fil. Et Standard dokument kan have en fil, men behøver det ikke. Relationen mappes ved at kopiere primærnøglen fra Fil over i Standard dokument som fremmednøgle. 5. Rekursive 1:1 og 1:n relationer Findes ikke i systemet. 6. Specialisering / generalisering Hvordan en specialisering mappes afhænger af flere ting. Det afhænger blandt andet af hvilke krav der stilles til deltagelse for entiteterne, hvordan entiteterne er involveret i andre relationer, samt hvor mange forekomster der findes af de involverede entiteter. Dette system indeholder to specialiseringer der begge mappes på samme måde. Specialiseringerne af Panel er Datopanel, panel, Telefonpanel og Tekstpanel. Relationen mellem super- og sub-entiteter er en mandatory or. Dette betyder at der kan oprettes en tabel hvor hver entitet hvor primærnøglen fra super-entiteten også kan benyttes som primærnøgle i sub-entiteterne. 7. Binære n:m relationer En n:m relation mappes ved at der oprettes en selvstændig tabel for relationen. Et eksempel er relationen Bruger n:m Rolle. En bruger kan have flere roller og en rolle kan haves af flere brugere. Der oprettes en tabel der indeholder primærnøgler fra begge de to entiteter i relationen. 8. Komplekse relationer Nogle relationer er komplekse og falder ikke umiddelbart i ovennævnte kategorier. Et eksempler er relationen Anmodning 1:n Kursus. I en Ansøgning skelnes der mellem kurser den studerende følger nu og kurser den studerende har planlagt at tage. For at kunne skelne på denne måde er det ikke godt nok at kopiere primærnøglen fra 1 -siden over som fremmednøgle på mange -siden, som det ellers er blevet gjort for 1:n relationer. I stedet oprettes der to 44

45 selvstændige tabeller til at beskrive relationerne mellem en Ansøgning, de igangværende Kurser og de planlagte Kurser. 9. Flerværdiattributter Findes ikke i systemet Normalisering For at undgå problemer med redundans og anomali er det vigtigt at den relationelle model er normaliseret til 3. normalform eller derover. Den relationelle model gennemgås for at sikre at den opfylder kravene til 3. normalform. 1. normalform, kræver at tabellerne har en entydig nøgle, at de ikke indeholder repeterende grupper samt at attributter skal være udelelige. 2. normalform, kræver at der ikke findes nogen attributter der er afhængige af en del af en sammensat primærnøgle. 3. normalform, kræver at der ikke findes nogle ikke-primærnøgle-attributter der er transitivt afhængige af en sammensat primærnøgle. Den nuværende relationelle model er ikke fuldt normaliseret. Tabellen student_vejl indeholder redundant data i form af vejlederes DTU id, der også kan findes i user -tabellen. En løsning der vil fjerne dette problem og gøre den relationelle model fuldt normaliseret er beskrevet i afsnit Ud over denne tabel er databasen normaliseret Relationel model Den relationelle model er vist som et ER diagram, og kan ses på Figur 6 herunder. 45

46 Figur 6: Entity Relation Diagram 46

47 6.3.4 Constraints Der kan oprettes forskellige constraints for bedst muligt at undgå at fejl udefra påvirker databasen. Disse constraints kan oprettes i databasen, men når der anvendes Hibernate kan constraints også defineres i applikationen. I dette projekt er kun constraints på obligatorisk data oprettet i databasen. Constraints vedrørende referentiel integritet implementeres ved hjælp af Hibernate, da dette er væsentligt nemmere at anvende mens systemet udvikles. 7 Systemarkitektur Dette afsnit beskriver hvordan systemet er struktureret samt hvilke overvejelser der er gjort i den forbindelse. 7.1 Design Patterns Factory Forsiden i applikationen skal, for studerende, kunne vise forskelligt indhold afhængig af brugeres praktik- og eksamensprojekt-status. For hver status er der en Wicket Panel-komponent der indeholder tekst og funktionalitet der svarer til statussen. Forsiden anvender en StatusPanelFactory-klasse der er ansvarlig for at instantiere og returnere de rigtige panels afhængig af brugerens status. Data Access Object Al tilgang til databasen er samlet i Data Access Objects - Dao s. Dao s er de eneste objekter der må tilgå databasen, men til gengæld er det så også det eneste de må. Ved at samle brug af databasen på denne måde, får man et systemt der er mere overskueligt og lettere at vedligeholde. Ud over at samle al data-tilgang i et lag er data-laget delt i en controller-del og en Dao-del. Controller-delen har ansvaret for at håndtere transactions, exceptions og for at klargøre objecter til Dao-delen. Dao-delen har så kun ansvaret for forespørgsler til databasen. Wicket er ikke et MVC-framework! Hvor mange webapplikationer er opbygget efter en Model-View-Control-model, er Wicket applikationer lidt anderledes idet der ikke er en egentlig controller og et view, til henholdsvis at behandle requesten og vise responsen. Wicket er komponent-baseret og der kan være mange komponenter involveret i behandlingen af en request og renderingen af en respons. En Wicket komponent består af en Java-klasse og en HTML-template hvor Java-koden er ansvarlig for at behandle requesten og får at rendere det HTML der skal vises ud fra templaten. På den måde kan en Wicket komponent ses som både controller og view, og da en komponent kan indeholde andre komponenter er der altså mange del-controllere og del-views involveret i behandlingen af enhver request. Model-delen af MVC kan stadig holdes separeret fra View og Controller. 47

48 7.2 Lag-deling Det implementerede system inddeles i lag. Da systemet ikke indeholder meget eller avanceret forretningslogik vil der ikke være et specifikt lag kun til dette. Forretningslogik vil være inkluderet i præsentationslaget. Alt data-tilgang samles i et datalag, der internt er delt i to lag - et controllerlag (Service-lag) og et data access-lag (Dao-lag). Arkitekturen skal være lukket, så der kun kan benyttes funktionel i et tilstødende lag, og den skal være streng så der kun kan benyttes funktioner i et underliggende lag. 8 Implementering Figur 7: Lag-deling Dette afsnit omhandler implementering af systemet. Relevante dele af den implementerede kode gennemgås. 8.1 Generelt BlobDownloadLink BlobDownloadLink er den komponent der gør det muligt for applikationen at sende filer, der er gemt som Blobs i databasen. Det er kode fundet på internettet, skrevet af Dane Laverty, og derefter tilpasset systemets behov. Nedenstående kode er onclick-metoden fra BlobDownloadLink. Den kan give et indblik i hvordan en fil fra databasen leveres til en bruger. 48

49 @Override public void onclick() { // Get the file as inputstream from database InputStream inputstream = new FileService().getFileInputStream(file.getId()); IResourceStream resourcestream = new InputStreamResourceStream(inputStream); getrequestcycle().setrequesttarget( new ResourceStreamRequestTarget(resourceStream){ public String getfilename(){ return file.getfullname(); ); public void respond(requestcycle requestcycle){ super.respond(requestcycle); try { inputstream.close(); catch (IOException ioe) { Først hentes filen som en InputStream fra databasen. Derefter wrappes streamen i en IResourceStream implementation, der igen bruges ved oprettelsen af en ResourceStreamRequestTarget. Et RequestTarget objekt er blandt andet ansvarlig for at genere en respons til en request, og et ResourceStreamRequestTarget objekt er et RequestTarget der kan tilføje en IResourceStream til den genererede respons. 8.2 Apache Wicket Hvad er Apache Wicket (en meget kort introduktion) Apache Wicket er et open source framework til Java Web Applikationer. Wicket adskiller sig på mange måder fra tradionelle web app. frameworks. Nogle af hovedpunkterne ved Wicket er: Fuldstændig separation of concerns mellem Java og HTML En Wicket komponent består af en Java-klasse og en HTML template. Der er kun meget få Wicket-tags og attributter der kan anvendes i templaten, hvilket giver markup der er meget tæt på ren HTML. Wicket anvender ikke en masse tag-libraries, og det er ikke muligt at skrive scriptlets og lignende i markup. Alt logik og dynamisk generering gøres i Java. Objektorienteret komponent-model I en Wicket applikation er komponent-begrebet centralt. En web-side bliver betragtet som én komponent. Web-side-komponenten kan så indeholde flere andre komponenter, der igen kan bestå af komponenter. Automatisk håndtering af state I en Wicket applikation er det ikke nødvendigt at tænke på at bevare state over flere requests. Frameworket håndterer selv tilstanden af de komponenter der bliver anvendt når brugere anvender applikationen. Abstraktion væk fra Servlet API og HTTP detaljer En Wicket applikation er en Servlet, men frameworket er designet så detaljer omkring brug af Servlet API et samt request/response håndtering er abstraheret væk fra udvikleren. 49

50 Ingen XML konfigurationsfiler Mange andre web app. frameworks benytter XML filer til at konfigurere forskellige dele af en webapplikation. Wicket anvender konvention over konfiguration og kræver ikke nogle XML filer overhovedet. Nemt at lave genanvendelige komponenter Wickets komponentmodel gør det nemt at lave og anvende genanvendelige komponenter. Komponentet Her vises lidt kode taget fra RegistrationPage.java, og den tilsvarende template RegistrationPage.html: Registration r = new RegistrationService().getRegistration(usr); Form form = new Form("form", new CompoundPropertyModel(r)); add(form); form.add(new TextField<String>("name")); form.add(new TextField<String>("studentNo")); <form wicket:id="form">... <input wicket:id="name" type="text" /> <input wicket:id="studentno" type="text"/>... </form> Hvis vi først ser på Java koden kan vi se at der bliver instantieret et Form objekt og at dette bliver tilføjet til RegistrationPage-komponenten. Til formen bliver der derefter tilføjet to TextFieldkomponenter. Markup en viser de HTML tags som de tilføjede komponenter bliver knyttet til. En wicket:id attribut anvendes i templaten. Denne attribut skal så matche det id-argument der gives i komponentens constructor. Den enkelte komponent er selv ansvarlig for at rendere indholdet af det tag den er tilknyttet. Det er desuden vigtigt at komponent-hierarkiet i koden matcher hierarkiet i templaten. Models Models er et meget vigtigt koncept i en Wicket applikation. Models bruges til at binde data til komponenter. Den simpleste model, Model, wrapper et object så komponenter har en standard måde at tilgå objectet på, men gør så heller ikke meget mere. Hvordan modellen anvendes er helt op til komponenten. En mere avanceret model, PropertyModel, gør det muligt at binde en komponent til en bestemt property i det wrappede object. For eksempel kan et tekstfelt bindes til en propertien navn, i et object User, hvis det wrappes i en Propertymodel. Tekstfeltet vil da blive renderet med et indhold der svarer til navne-propertien. Hvis tekstfelter er en del af en form vil den underliggende model automatisk blive opdateret ved submit. Den sidste type model der nævnes er er CompoundPropertyModel. Denne type model anvendes mange steder i applikationen - blandt andet i den allerede viste kode-snip fra RegistrationPagekomponenten: 50

51 Registration r = new RegistrationService().getRegistration(usr); Form form = new Form("form", new CompoundPropertyModel(r)); add(form); form.add(new TextField<String>("name")); form.add(new TextField<String>("studentNo")); <form wicket:id="form">... <input wicket:id="name" type="text" /> <input wicket:id="studentno" type="text"/>... </form> I Java-koden bliver et Registration domæne-objekt wrappet i en CompoundPropertyModel og givet til Form-constructoren. Når denne type model anvendes vil Wicket automatisk binde alle komponenter til den property hvis navn matcher komponentens id. I koden herover vil det TextField der har id name blive bundet til name -propertien i Registration (og naturligvis også til det input-tag det har samme id). Det andet TextField bliver så bundet til propertien studentno. Markup inheritance Wicket giver mulighed for såkaldt markup inheritance. Dette kan bruges til at give flere sider det samme layout. Det er muligt at oprette en web-side med et layout, og så lade andre web-sider arve dette layout. Et par kode-snippets kan vise hvordan det er blevet anvendt i det implementerede system: public class DefaultPage extends WebPage {... <html>... <body>... <wicket:child /> </body> </html> DefaultPage er navnet på den komponent der anvendes til standard layout i applikationen. Det er en web-side da den arver fra Wicket komponenten WebPage, men ellers er der ikke noget specielt ved Java-koden. I HTML templaten derimod er der et specielt tag, wicket:child. Dette tag angiver hvor sub-siden skal indsættes. public class IndexPage extends DefaultPage {... <wicket:extend>... </ wicket:extend> 51

52 IndexPage er en side der følger standardlayoutet ved at arve fra DefaultPage. Den del af templaten der er indeholdt i wicket:extend-tagget bliver indsat i stedet for det wicket:child-tag der findes i super-templaten. Annonymous subclasses Noget der anvendes utroligt meget i enhver Wicket applikation er annonyme subklasser. Dette anvendes til at specialisere genanvendelige komponenter på en nem måde. Følgende er et eksempel fra ManageFormsPage.java: add(new public void onclick() { setresponsepage(editformpage.class class); ); Koden viser hvordan der skabes en annonym subklasse af Link-klassen, hvor onclick-metoden bliver overskrevet. Her er endnu et eksempel: WebMarkupContainer container = new public boolean isvisible() { if (flist == null) return false; return (!flist.isempty()); ; Her bliver der skabt en annonym subklasse af en WebMarkupContainer. Metoden isvisible bliver overskrevet således at containeren kun bliver renderet under visse omstændigheder. ListView Flere steder i applikationen anvendes ListViews. Et ListView kan anvendes til at generere noget HTML for hvert element i en liste. Dette er et eksempel på hvordan ListView anvendes i RegistrationPage-komponenten: ListView<Forloeb> fview = new ListView<Forloeb>("fView", protected void populateitem(listitem<forloeb> item) { item.add(new Label("fname",item.getModelObject().getName())); item.add(...); ; <div wicket:id="fview"> <span wicket:id="fname" /> <input wicket:id="fid" type="radio" /> </div> Her bliver en ListView-komponent knyttet til et div-tag i templaten, og der gives desuden en liste som argument til constructoren. Metoden populateitem overskrives for at angive hvad der skal gøres for hvert element i listen. Den markup der findes inde i det div-tag der er knyttet til ListView et bliver renderet for hvert element i listen. 52

53 Validering af dynamiske forms De dynamiske forms i systemet opbygges af forskellige elementer, kaldet FormPanels. Et element der tillader en bruger at angive , er implementeret i klassen Panel der ses herunder: public class Panel extends FormPanel { public Panel(String id, IModel<?> model) { super(id, model); Data modelobject = ( Data) model.getobject(); add(new TextField<String>("content").setRequired(true true).setlabel(new Model<String>(modelObject.getPanelBean().getLabel())).add( AddressValidator.getInstance())); Wicket indeholder en del indbygget funktionalitet til validering af brugerinput. I koden ses det at der tilføjes et normalt tekstfelt hvor brugeren kan angive en . Feltet markeres som påkrævet, og Wickets indbyggede -validator tilføjes. I tilfælde af at brugerinput ikke er en gyldig eller helt mangler vil der blive vist en fejlmeddelelse. Kaldet til setlabel anvendes til at angive hvilket navn feltet får i en fejlmeddelelse. Med disse få liniers kode vil alle Panels i alle dynamiske forms bliver valideret på samme måde. Herunder vises PhonePanel, der ved hjælp af Wickets PatternValidator kan få valideret at input matcher et bestemt mønster bestemt af et regular expression: public class PhonePanel extends FormPanel { public PhonePanel(String id, IModel<?> model) { super(id, model); String phoneregex = "^(\\(?\\Q+45\\E\\)?( )?)?[0-9]{8$"; PhoneData modelobject = (PhoneData) model.getobject(); add(new TextField<String>("content").setRequired(true true).add(new PatternValidator(phoneRegex)).setLabel(new Model<String>(modelObject.getPanelBean().getLabel()))); Genanvendelige selv-validerende komponenter Da det skal være muligt at angive DTU id flere steder i applikationen og at disse gerne skal valideres ens, er der udviklet en komponent specielt til dette - DTUIdTextField: public class DTUIdTextField extends TextField<String> { public DTUIdTextField(String id) { super(id); add(new PatternValidator("^[a-zA-Z]{1[0-9]{6$")); Som det ses er komponenten er utrolig simpel. Den arver fra TextField, kalder super-constructor og tilføjer en PatternValidator til sig selv. Komponenten kan nu anvendes i alle forms hvor det skal være muligt at indtaste et DTU id, med den fordel at man aldrig skal bekymre sig om hvordan 53

54 feltet skal valideres samt at man kan være sikker på at valideringen er konsistent for alle disse tekstfelter. Wicket-auth-roles Systemet indeholder rolle-baseret authorization. Dette er opnået ved anvendelse af Wicket-authroles - en del af Wicket framework et det tilbyder sikkerhedsmekanismer ved brug af annotations. For at anvende Wicket-auth-roles skal der først impementeres en custom session-klasse: public class DssSession extends AuthenticatedWebSession { public User getuser() { return user; public void setuser(user user) { this.user = public boolean authenticate(string dtuid, String password) public Roles getroles() {... Den brugerdefinerede session skal arve fra AuthenticatedWebSession for at Wicket-auth-roles kan anvendes. Metoderne authenticate og getroles skal implementeres. Desuden gemmes et Userobjekt for den aktuelle bruger også i session, da dette objekt indeholder brugerens roller til brug i getroles-metoden. Nu er applikationen klar til at der kan anvendes Wicket-auth-roles annotations til Roles.STUD, Roles.PK, Roles.PA, Roles.VEJL, Roles.UNREG) public class DefaultPage extends WebPage {.. Dette eksempel viser kan anvendes til at begrænse hvem der kan instantiere en komponent. Her er annotation en anvendt på DefaultPage som alle andre sider arver fra. Herved kræver alle sider (på nær login-siden) at brugeren har en af de angivne = Action.RENDER, roles = {Roles.PK, Roles.PA) private class AdminLink extends Link<Object> { public AdminLink(String id) { public void onclick() { setresponsepage(adminpage.class class); 54

55 Dette eksempel viser kan anvendes til begrænse hvem der kan få vist en komponent. Her vil et AdminLink kun blive renderet hvis den aktuelle bruger er enten praktikkoordinator eller praktikassistent. Ud over Action.RENDER, der anvendes her, findes også Action.ENABLE der vil vise, men disable komponenten for alle der ikke har en af de angivne roller. Ajax Wicket indeholder en del Ajax-komponenter der gør det super nemt at tilføje Ajax til en webapplikation. I det implementerede system er der anvendt nogle af disse komponenter. Systemet indeholder blandt andet en side til søgning efter studerende. Denne side består af en søgeform og nogle søgeresultater. På siden andvendes Ajax til at submitte søgeformen og til at opdatere søgeresultaterne. Følgende kode viser hvor nemt det er at tilføje Ajax til en ellers helt almindelig søgeside: Form form = new Form("form",...); add(form);... final WebMarkupContainer results = new WebMarkupContainer("results"); add(results); results.setoutputmarkupid(true true);... form.add(new AjaxButton("submit", form) protected void onsubmit(ajaxrequesttarget target, Form<?> form) {... //redraw results on page target.addcomponent(results); ); Koden viser at siden indeholder en ganske normal form, samt en markup-container til søgeresultater. På containeren kaldes setoutputmarkupid(true). Dette instruerer Wicket i at generere en id-attribut på det tag containeren svarer til i markup. Dette id er nødvendigt for at tag et kan opdateres af Wickets Ajax-engine. Det næste interessante i koden er at der anvendes en AjaxButton-komponent i stedet for en normal Button-komponent. I modsætning til den normale Button skal en AjaxButton vide hvilken form den skal submitte - derfor gives en Form som argument i constructoren. Dernest har onsubmit-metoden (og også andre metoder) en lidt anden signatur end den har i en Button. Ved at kalde AjaxRequestTarget.addComponent-metoden kan man angive hvilke komponenter der skal opdateres på websiden. En anden Ajax-komponent der anvendes i implementeringen er ModalWindow. Et ModalWindow er et vindue der vises oven på det eksisterende indhold på en side. Det kan vise et Wicket Panel eller WebPage i et JavaScript-styret vindue. Et eksempel på et ModalWindow kan ses på Figur 8. Kode-stumpen herunder viser hvordan et ModalWindow anvendes. En AjaxLink-komponent benyttes til at åbne vinduet, når brugeren klikker på et link på websiden. 55

56 // Add modal window for uploading new files final ModalWindow modal = new ModalWindow("modal"); add(modal);... modal.settitle("upload fil"); modal.setresizable(false false); modal.setcssclassname(modalwindow.css_class_gray); modal.setinitialheight(100); modal.setinitialwidth(300); add(new AjaxLink("showModal") public void onclick(ajaxrequesttarget target) { modal.setcontent(new new FileShare(...)); modal.show(target); ); Figur 8: Eksempel - ModalWindow 8.3 Hibernate Hvad er Hibernate Hibernate er et ORM 2 framework der kan gøre det nemmere at tilgå en relationel database fra en objekt-orienteret applikation. For at hibernate kan hjælpe med database-tilgang, behøver frameworket nogle informationer om hvad domæneobjekterne svarer til i databasen, samt hvordan de er mappet. Når man har brugt lidt tid på at give denne metadata, har man til gengæld et framework der konstruerer alt SQL og håndterer al databasetilgang, så man ikke længere skal tænke på at der ligger en relationel database under applikationen. 2 Object Relational Mapping 56

57 Mapping metadata Normalt angives mapping metadata i xml-filer, men med Hibernate Annotations kan mapping metadata defineres direkte i domæne-objekterne. Følgende udsnit af User domæne-objektet viser mange af de annotations der public class User implements public int getid() { return public String getdtuid() { = Role.class name = "user_role", joincolumns = {@JoinColumn(name = "user_id"), inversejoincolumns = {@JoinColumn(name = "role_id")) public List<Role> getroles() { public InternStatus getintstatus() { return = "student") public List<StudentSupervisor> getsupervisor() { return public boolean hasadminrole() { Den første skal findes på et hver domæne-objekt Hibernate skal kunne bruges til at angive hvilken database-tabel objectet svarer bruges til at angive hvilken property der er primærnøgle, til at angive hvordan id skal genereres. Simple properties som f.eks. integers og strings kan hibernate mappe automatisk hvis bare propertien hedder det samme som feltet i databasen. Gør den ikke det bruges til at angive navnet på feltet i databasen. En mange-til-mange relation angiver hvilken tabel der beskriver relationen. Desuden anvendes til at angive at en brugers roller ikke skal lazy-loades. En mange-til-en relation mappes Når denne annotation anvendes sammen fortæller det Hibernate at relationen er bestemt af en fremmednøgle i denne tabel. 57

58 @OneToMany benyttes til en en-til-mange relation. Attributten mappedby fortæller Hibernate at relationen er bestemt af en fremmednøgle i den anden tabel, samt hvilken property på den anden side af relationen der indeholder fremmednøglen. Har man behov for at Hibernate ignorerer en metode, kan dette opnås Ud over dette er det også værd at medtage at Hibernate kan styre referentielle constraints public User getuser() { return user; Nogle af de data en ny bruger indtaster i sin ansøgning gemmes ikke i registration-tabellen, men i user-tabellen. Hvis for eksempel en ændres i en allerede gemt ansøgning sørger CascadeType.SAVE_UPDATE for at ændringen bliver cascadet til User når Registration gemmes. Da en ansøgning er knyttet til og afhængig af en bruger, skal der ved en ny ansøgning først oprettes en ny bruger i user-tabellen inden der kan oprettes en ny ansøgning i registration-tabellen. Dette sørger CascadeType.PERSIST for. Controller / Dao pattern Som nævnt i afsnit 7.1 implementeres data-tilgang via et Controller / Dao pattern. Et Dao er kun ansvarlig for at hente og gemme data, hvorimod en controller er ansvarlig for at håndtere transaktioner, ved hvordan Dao er skal anvendes og eventuelt gør domæne-objekter klar til Dao erne. Et Dao kan således indeholde meget simple metoder: public void edituser(user usr) { session.saveorupdate(usr); Mens en controller indeholder metoder der er klarer lidt mere: public void edituser(user usr) { try { HibernateUtil.getSessionFactory().getCurrentSession().beginTransaction(); userdao.edituser(usr); HibernateUtil.getSessionFactory().getCurrentSession().getTransaction().commit(); catch (RuntimeException re) { try { HibernateUtil.getSessionFactory().getCurrentSession().getTransaction().rollback(); catch (RuntimeException re2) { Transactions Det er vigtigt at der anvendes transaktionsstyring ved tilgang til databasen. Hvis man ser på koden i forrige afsnit kan det ses hvordan controller-objectet sørger for at begynde en ny transaktion inden data-tilgang, og sørger for at afslutte transaktionen efter data-tilgangen er afsluttet 58

59 succesfuldt. Selv om det i eksemplet ser ud som om der kun opdateres et enkelt domæne-objekt, kan det sagtens være at hibernate genererer flere update statements. Hvis brugeren for eksempel har fået ændret både roller og er 2 update statements nødvendige da er et felt i usertabellen mens rollerne er beskrevet i en join-tabel. 9 Test Dette afsnit beskriver hvordan systemet testes, og hvad resultaterne af de udførste tests er. 9.1 Strategi for test Formålet med denne test er at undersøge om systemet opfører sig som forventet. Det er altså de funktionelle krav der skal testes. Der er allerede produceret nogle test cases i afsnit 4.2, der beskriver hvordan de funktionelle krav for en use case kan testes. Hvis systemet opfører sig som forventet gennem både normal-forløb og alle alternative forløb, betragtes de funktionelle krav som opfyldt. Alle use cases testes efter denne metode, ved at opstille tests der bør betyde at alle forløb bliver afprøvet. De use cases der er fælles for flere aktører, testes for hver aktør. 9.2 Udførelse af test Fælles for alle aktører Login Klargøring: Tilgå webapplikationen uden at være logget ind. Normal: Indtast korrekt DTU id og password. Klik på Login. Fejl: Indtast forkert DTU id og password. Klik på Login. Udsend meddelelse Klargøring: For studerende: Klik på Meddelelser - For øvrige: Naviger til en studerendes meddelelser. Normal: Klik på Udsend ny meddelelse. Udfyld form korrekt og klik på Send. Fejl: Lad både emne og indhold stå tomt og klik på Send. Fortryd: Klik på krydset i øverste højre hjørne. Se mine meddelelser Normal: Klik på Meddelelser i menuen. Se vejledningsdokumenter Normal: Klik på Information i menuen. Studerende Registrer studerende Klargøring: Klik på Ansøgning i menuen. Normal: Indtast korrekt data og klik på Send. Fejl: Indtast fejl-formet data (f.eks. en og klik Send. Opdater form Klargøring: Klik på Forms i menuen, og derefter en af de tilgængelige forms. 59

60 Normal: Indtast korrekt data og klik på Send. Fejl: Indtast fejl-formet data og klik Send. Upload std. dok. Klargøring: Klik på Dokumenter i menuen, og derefter på en af de tilgængelige std. doks der tillader upload. Normal: Vælg den rigtige fil og klik Upload. Fejl: Unlad at vælge en fil og klik Upload. Upload fil Klargøring: Klik på Fildeling i menuen, og derefter på Upload ny fil (eller Ny version på en eksisterende fil). Normal: Vælg den rigtige fil og klik Upload. Fejl: Unlad at vælge en fil og klik Upload. Fortryd: Klik på krydset i øverste højre hjørne. Godkendelse af praktikplads Klargøring: Denne test kræver at der logges ind på en studerende der har en bestemt status. Normal: Klik på knappen Giv besked i Praktik-kassen på startsiden. Godkendelse af foreløbigt abstract Klargøring: Denne test kræver at der logges ind på en studerende der har en bestemt status. Normal: Klik på knappen Giv besked i Eksamensprojekt-kassen på startsiden. Godkendelse af praktik Klargøring: Denne test kræver at der logges ind på en studerende der har en bestemt status. Normal: Klik på knappen Giv besked i Praktik-kassen på startsiden. Godkendelse af abstract Klargøring: Denne test kræver at der logges ind på en studerende der har en bestemt status. Normal: Klik på knappen Giv besked i Eksamensprojekt-kassen på startsiden. Praktikassistent Behandl registrering Klargøring: Klik på Anmodninger, og derefter på studie-nummeret for registrering der skal behandles. Normal: Klik på Godkend. Godkend m/besked: Indtast besked og klik på Godkend. Afvis: Klik på Afvis. Afvis m/besked: Indtast besked og klik på Afvis. Behandl færdigt abstract Klargøring: Klik på Anmodninger, og derefter på studie-nummeret for den studerende hvis abstract skal behandles. Herefter benyttes samme fremgangsmåde som beskrevet ovenfor i Behandl registrering. 60

61 Praktikkoordinator Godkend praktikvirksomhed Klargøring: Klik på Anmodninger, og derefter på studie-nummeret for den studerende hvis praktikvirksomhed skal godkendes. Herefter benyttes samme fremgangsmåde som beskrevet ovenfor i Behandl registrering. Godkend foreløbigt abstract Klargøring: Klik på Anmodninger, og derefter på studie-nummeret for den studerende hvis foreløbige abstract skal godkendes. Herefter benyttes samme fremgangsmåde som beskrevet ovenfor i Behandl registrering. Godkend praktik Klargøring: Klik på Anmodninger, og derefter på studie-nummeret for den studerende hvis praktik skal godkendes. Herefter benyttes samme fremgangsmåde som beskrevet ovenfor i Behandl registrering. DTU Vejleder Se mine studerende Normal: Klik på Studerende i menuen. Søg mine studerende Klargøring: Klik på Studerende i menuen. Normal: Indtast søgekriterier (f.eks. 04 i studie-nr, og praktik godkendt i praktikstatus). Klik på Søg. Fælles for Praktikassistent og Praktikkoordinator Se alle studerende Samme fremgangsmåde som Se mine studerende ovenfor. Søg alle studerende Samme fremgangsmåde som Søg mine studerende ovenfor. Tilknyt DTU Vejleder Klargøring: Naviger til oversigten for den studerende (f.eks. ved at klikke på studie-nr under Studerende -menupunktet). Klik på administrer. Normal: Indtast et DTU id på en vejleder i feltet DTU id. Klik på Tilknyt. Fejl i id: Udfyld feltet DTU id med tekst der ikke er et DTU id på en vejleder. Klik på Tilknyt. Intet id: Klik på Tilknyt uden at udfylde feltet DTU id. Fjern DTU Vejleder Klargøring: Naviger til oversigten for den studerende (f.eks. ved at klikke på studie-nr under Studerende -menupunktet). Klik på administrer. Normal: Klik på krydset til højre for vejlederens DTU id i listen over tilknyttede vejledere. 61

62 Ændr status for studerende Klargøring: Naviger til oversigten for den studerende (f.eks. ved at klikke på studie-nr under Studerende -menupunktet). Klik på administrer. Normal: Vælg status i de to dropdown-bokse. Klik på Gem. Opret / rediger ansat Klargøring: Klik på Administrer i menuen, og derefter på Administrer ansatte. Normal: Klik på Opret ny bruger eller på navnet for en eksisterende bruger. Udfyldt alle felter korrekt. Klik Send. Intet navn: Lad feltet Navn være tomt. Klik Send. Intet DTU id: Lad feltet DTU ID være tomt. Klik Send. Fejl i DTU id: Udfyld feltet DTU ID med tekst der ikke er et korrekt id. Klik Send. Fortryd: Klik på krydset i øverste højre hjørne. Slet ansat Klargøring: Klik på Administrer i menuen, og derefter på Administrer ansatte. Normal: Klik på krydset til højre for den ansatte i listen. Opret / rediger form Klargøring: Klik på Administrer i menuen, og derefter på Administrer formularer. Klik enten på Opret ny form eller klik på en eksisterende form og derefter på Rediger. Normal: Opbyg en form og udfyld felt-navnene. Klik på Gem. Form uden navn: Lad formen være uden navn. Klik på Gem. Form uden felt: Lad formen være uden tilføjede felter. Klik på Gem. Felt uden navn: Lad et felt være uden navn. Klik på Gem. Nulstil: Klik på Nulstil. Fortryd: Klik på Tilbage. Slet form Klargøring: Klik på Administrer i menuen, og derefter på Administrer formularer. Normal: Klik på den form der skal slettes, og derefter på Slet. Skjul / vis form for studerende Klargøring: Klik på Administrer i menuen, og derefter på Administrer formularer. Normal: Klik på den form der skal skjules / vises og derefter på Gør inaktiv / Gør aktiv. Opret / rediger std. dok. Klargøring: Klik på Administrer i menuen, og derefter på Administrer standard dokumenter. Klik på Opret nyt standard dokument eller klik på et eksisterende. Normal: Udfyld felterne som ønsket. Klik på Send. Intet navn: Undlad at indtaste et navn. Klik på Send. Fortryd: Klik på krydset i øverste højre hjørne. Slet std. dok. Klargøring: Klik på Administrer i menuen, og derefter på Administrer standard dokumenter. 62

63 Normal: Klik på krydset til højre for det dokument der skal slettes. Fælles for Praktikassistent, Praktikkoordinator og DTU Vejleder Se studerendes forms Normal: Naviger til oversigten for den studerende (f.eks. ved at klikke på studie-nr under Studerende -menupunktet). Klik på Formularer. Klik på den form der skal vises. Se studerendes std. doks. Normal: Naviger til oversigten for den studerende (f.eks. ved at klikke på studie-nr under Studerende -menupunktet). Klik på Standard dokumenter. Klik på det dokument der skal vises. Se studerendes fildeling Normal: Naviger til oversigten for den studerende (f.eks. ved at klikke på studie-nr under Studerende -menupunktet). Klik på Fildeling. Se studerendes meddelelser Normal: Naviger til oversigten for den studerende (f.eks. ved at klikke på studie-nr under Studerende -menupunktet). Klik på Meddelelser. 9.3 Resultat af test Alle testresultater er opstillet i tabeller. For hver use case er der en test af normal-forløbet, samt en test af hver af de alternative forløb. For hver test er angivet to resultater. Visuelt angiver om brugergrænsefladen opfører sig som forventet, mens Data angiver om datamodellen bliver anvendt og påvirket som forventet. Fælles for alle aktører Test Studerende PA PK Vejleder Visuelt Data Visuelt Data Visuelt Data Visuelt Data Login Normal Fejl n/a n/a n/a n/a n/a n/a n/a n/a Udsend meddelelse Normal Fejl Fortryd Se mine meddelelser Normal Se vejledningsdokumenter Normal Fejl-forløbet for Login er ikke anført, da der ikke kan skabes en fejlsituation i den nuværende implementation. Authentication er tænkt til at anvende DTU SSO, men da dette ikke er integreret i systemet, foretages der ingen authentication og man vil altid blive lukket gennem login. 63

64 Studerende Test Visuelt Data Registrer studerende Normal + + Fejl + + Opdater form Normal + + Fejl + + Upload std. dok Normal + + Fejl + + Upload fil Normal + + Fejl + + Fortryd + + Godkendelse af praktikplads Normal + + Godkendelse af foreløbigt abstract Normal + + Godkendelse af praktik Normal + + Godkendelse af abstract Normal + + Praktikassistent Test Visuelt Data Behandl registrering Normal + + Godkend + besked + -/ + Afvis + + Afvis + besked + -/ + Behandl færdigt abstract Normal + + Godkend + besked + -/ + Afvis + + Afvis + besked + -/ + Årsagen til at alle de tests der indeholder en besked har både - og + er at beskeden ikke gemmes, så de funktionelle krav er ikke opfyldt. Men da dette skyldes at implementationen ikke understøtter at gemme meddelelser, og ikke sker som følge af en bug, er det stadig den forventede opførsel. 64

65 Praktikkoordinator Test Visuelt Data Godkend praktikvirksomhed Normal + + Godkend + besked + -/ + Afvis + + Afvis + besked + -/ + Godkend foreløbigt abstract Normal + + Godkend + besked + -/ + Afvis + + Afvis + besked + -/ + Godkend praktik Normal + + Godkend + besked + -/ + Afvis + + Afvis + besked + -/ + DTU Vejleder Test Visuelt Data Se mine studerende Normal + + Søg mine studerende Normal

66 Fælles for Praktikassistent og Praktikkoordinator Test PA PK Visuelt Data Visuelt Data Se alle studerende Normal Se alle studerende Normal Tilknyt DTU Vejleder Normal Fejl i id Intet id Fjern DTU Vejleder Normal Ændr status for studerende Normal Opret / rediger ansat Normal Intet navn Intet DTU id Fejl i DTU id Fortryd Slet ansat Normal Opret / rediger form Normal Form uden navn Form uden felt Felt uden navn Nulstil Fortryd Slet form Normal Skjul / vis form for studerende Normal Opret / rediger std. dok. Normal Intet navn Fortryd Slet std. dok. Normal

67 Fælles for Praktikassistent, Praktikkoordinator og DTU Vejleder Test PA PK Vejleder Visuelt Data Visuelt Data Visuelt Data Se studerendes forms Normal Se studerendes std. doks. Normal Se studerendes fildeling Normal Se studerendes meddelelser Normal Evaluering og konklusion Dette sidste afsnit er en opsamling på projektet Evaluering af proces Anvendelsen af Unified Process og det iterative udviklingsarbejde er forløbet som planlagt i iterationsplanen. I den første del af projektet er der blevet arbejdet meget med analyse og design, og senere hen er der brugt mere tid på implementering og datamodellering. Ved at fokusere på høj-risiko- og høj-værdi-områder fra starten af projektet har det været muligt at få skabt en grundlæggende arkitektur og overblik over systemets omfang tidligt i forløbet. Ved at anvende få udvalgte UML artefakter har det kun krævet få ressourcer at vedligeholde disse når en ny iteration har medført ændringer i designet Konklusion på system I det udviklede system er der lagt mest vægt på at opfylde de funktionelle krav. Der er udviklet en Java applikation med web-interface og en underliggende MySQL database. Applikationen der er baseret på Apache Wicket, er komponent-baseret med flere genanvendelige komponenter der kan benyttes uanset kontekst. Systemet anvender rolle-baseret authorization til at styre brugernes rettigheder, og flere steder benyttes Ajax for at give en bedre brugeroplevelse. Brugen af ORM framework et Hibernate har gjort det nemt at anvende en relationel database under en objektorienteret applikation. Den udviklede applikation er ikke en fuldstændig implementering af det tænkte system - der er plads til masser af udvidelser og forbedringer. Systemet er udviklet så det understøtter de funktioner der vurderes at være kerne-funktioner - altså de funktioner der er kritiske for om det endelige system kan blive en succes. Databasen er udviklet til applikationen i sin nuværende form. Integrering af yderligere use cases kan komme til at betyde at datamodellen skal udvides eller omstruktureres. Jævnfør rapportens testafsnit opfylder systemet, med enkelte undtagelser, de funktionelle krav for de indarbejdede use cases Integration af resterende use cases Det bør være forholdsvis enkelt at integrere flere use cases i systemet. Da der er blevet fokuseret på kerneområder er systemets overordnede rammer på plads, hvorfor der kan implementeres yderligere use cases med meget få ændringer til det eksisterende system. 67

68 Det bør dog bemærkes, at da der anvendes dynamiske forms, vil det kræve lidt arbejde at få systemet til f.eks. at generere påmindelser ud fra studerendes gemte oplysninger Mulige forbedringer Da projektet primært har omhandlet systemets kerne-områder, er der mange forbedringer og udvidelser der kan gøre systemet bedre. Det kan gøres muligt at samle flere studerende der skriver eksamensprojekt sammen, at administrere eksamensprojekters løbe-numre på en god måde, samt at versionere studerendes form-data. Herudover kunne en kalender-funktion være nyttig lige som mulighed for forskellige typer af påmindelser, eller en grafisk oversigt af studerendes sager. Statistik udtræk kunne muligvis også være nyttigt at have, og mulighed for pæn udskrift af forskellig data kunne helt sikkert være det. Sidst men ikke mindst, kunne systemet også udvides til at hjælpe med de øvrige opgaver som praktikassistenten og praktikkoordinatorerne har i forbindelse med studerendes praktik og eksamensprojekter - f.eks. kommunikation med Konklusion på projekt Ved at udføre dette projekt er der blevet produceret en webapplikation med tilhørende datamodel samt dokumentation herom. Anvendelsen af Unified Proces og metodens iterative udviklingsmodel har medført at både software og dokumentation er blevet udviklet løbende gennem flere mindre udvidelser, samt at det vil være nemt at fortsætte med at udvikle systemet. 68