Sags- og dokumentstyringssystem

Transkript

1 Sags- og dokumentstyringssystem Bachelorprojekt Nawar Al-Mubaraki (s062412) Vejledere: Stig Høgh, Mads Nyborg Kongens Lyngby

2 Abstract Formålet med dette projekt er at udvikle et web-baseret system som håndterer diplom IT studerende i DTU som har Ingeniørpraktikken som et obligatorisk kursus. Den studerende skal udføre praktikken i en virksomhed i min. 20 uger hvorefter, skal den studerende også gennemføre et eksamensprojekt som også foregår i samme virksomhed som praktikken. System skal kunne håndtere både praktikkens og eksamens forløb som består af oprettelsen af sager med tilknytning af bruger og vejleder samt udfyldning og godkendelse af standard dokumenter. Der lægges vægt på at de skal være nemmere at kommunikere med de studerende via et meddelelsessystem samt autogeneret /selvdefineret . Systemet skal gøre det nemt at håndtere forløbet i alle aspekter. Igennem de 5 måneder der er sat til bachelorprojektet, har jeg udviklet et system som opfylder kravet til at drive og håndtere den ovennævnte periode. 1

3 Indholdsfortegnelse 1 Forord Indledning Opgavebeskrivelse og analyse Kravspecifikation Afgrænsning Optimering Planlægning Use cases Aktører Use cases diagram Design Design principper Model/view/controller Datalagring Flere lags arkitektur Undgå hårdkodning i modellen Klassefordeling Config DBConnection Resten af klasserne Database design Implementering Log ind/ud Bruger Dokumenter Oprettelsesdokument Bilag 5, 6 og Bilag Bilag Dokumenters notifikationer Meddelelser

4 5.4.1 Meddelelses notifikationer Sag Layout Fejlhåndtering Systemets kontrolpanel Brugere Dokumenter Sager Notifikationer Test Log ind Dokumenter Optagelsesdokument Bilag 5, 6 og Bilag Bilag Meddelelser Database test Evaluering Konklusion Forbedringer Generelle forbedringer AJAX Apache rewrite mod Portal siden Forum Grafiske elementer Specifikke forbedringer Meddelelser Brugere Sager

5 10 Referencer Bilag Tidsplan Use cases diagram Domænemodel Klassediagram ERM Layout opdeling Appendiks Use cases Oprette bruger Log ind Udfylde Oprettelsesdokument Udfylde bilag Udfylde bilag Oploade bilag 5, 6 eller Oprette tråd / meddelelse Administrations manual Brugere Dokumenter Sager Notifikationer Deployment Kode Database Online udgave

6 1 Forord Denne rapport og det tilhørende produkt er resultatet af bachelorprojektets arbejde, udført i DTU, softwareteknologi studieretning. Projektet tæller for 20 ECTS point og strækker sig over 5 måneder, startet den 9. marts og afsluttede 10. August Rapporten indeholder mange tekniske termer og begreber, derfor forventes at læseren skal have kendskab til de tekniske og softwaremæssig sprog. Projektet er udarbejdet ved stor hjælp, inspiration og vejledning af både Stig Høgh og Mads Nyborg, der rettes mange tak til dem, samt de personer der har hjulpet med test og forbedring af systemet. Nawar Al-Mubaraki s

7 2 Indledning Denne rapport omhandler projektarbejdet i softwareteknologisbachelorprojektet, rapporten er bygget omkring design og implementering af sags- og dokumentstyringssystem som er primært rettet mod diplomstuderende der udfører deres praktik og eksamensprojekt i DTU. Systemet bliver udviklet i programmeringssproget Java[Java1] og JSP[JSP1], samt med HTML[HTML1] og CSS[CSS1]. Rapporten vil indeholde analyse og præcisering af systemets omfang i form af hvilke opgaver og muligheder der kan udføres og håndteres i systemet. Analyse og præcisering af systemet vil give de færdigheder der skal bruges til at designe modellen hvor den også redegøres i rapporten. Rapporten vil også indeholde beskrivelse af sammenspillet mellem de forskellige dele af systemet samt med en detaljeret beskrivelse af hver del af dem. Et godt designet model vil give målretning til hvad der skal implementeres og det beskrives også i rapporten med begrundelser og forklaring på de valgte metoder. Der forklares også hvordan implementering er sket med hensyn til f.eks. hvilke datastrukturer der er blevet brugt og de forskellige algoritmer, som der er blevet designet. Rapporten indeholder test af både modellen og view et samt afprøvning af produktet og de eventuelle forbedringer som kan overvejes. Rapporten afsluttes med en konklusion som afspejler de væsentlige dele af rapporten. Udvikling af projektet er både time- & feature-driven. Udvikling af systemet har ikke bundet sig fast på en bestemt udviklingsmodel men Agile[Agile1] har stort set været modellen hvor udvikling efterfulgte, altså at udvikling har delte sig over flere iterationer. Formålet er at lette arbejdet for praktikkoordinatorerne for at håndtere praktik og eksamensprojekt forløbet på Diplomingeniør IT i DTU. Systemet skal give et bedre overblik af studerende og deres tilstand i praktik og eksamensprojekt forløbet, skal give bedre kommunikations platform med de studerende og lette arbejdet ved at automatiserer nogle af opgaverne. 6

8 3 Opgavebeskrivelse og analyse Problemet i det nuværende tidspunkt er CampusNet systemet som er bygget til at dele informationer om kurser og deres aktiviteter men ikke til at holde styre på deltagere og deres indsats. CampusNet er ikke egnet som sags- og dokumentstyringssystemet, da CampusNet mangler de funktionaliteter som praktikken og eksamensprojektet kræver. Problemet hel specifikt er, at det er uoverskueligt for både studerende og praktikkoordinatorerne. Det er meget svært for studerende at følge med og gøre hvad de skal mht. til de bilag og dokumenter der skal udarbejdes, på samme måde er det svært for praktikkoordinatorer at holde styre på studerende og deres opgaver og dokumenter. Løsning vil være et system der er udviklet specifikt til opgaven, at gøre det muligt at varsle studerende om tidsfrister og notifikationer samt med en tidslinje der viser udvikling i sagen. Ifølge projektbeskrivelse skal der designes og udvikles et web baseret system med en log ind adgang, således at bruger få adgang til systemet efter tilmelding. Systemet beskrives generelt som en CMS[CMS1] som lette samarbejdet i oprettelse af dokumenter og indholdet i dem. CMS systemer klassificeres som IM[IM1] hvor den primære fokus er at gøre det nemmere at udarbejde dokumenter af forskellige forme (artikler, reviews, debatter, webformular osv. ). Det vil sige at CMS begrebet er meget stort og rummer mange forskellige form af web applikationer der kan forskellige ting, derfor vil kravspecifikationsafsnit definere og præcisere systemets krav på en måde der mere tilpasset studerendes praktik og eksamensprojekts forløb. 3.1 Kravspecifikation Følgende krav er resultatet af projektbeskrivelse samt vejledningsmøder som jeg har haft med mine vejledere. Systemet som minimum skal kunne håndtere følgende funktionaliteter: 1. Log ind: brugere af forskellige roller (bruger, vejleder eller administrator) skal kunne logge på systemet og have adgang til egne dokumentere og meddelelser. 2. Brugere og brugergrupper: oprette af bruger, det skal være muligt både at en studerende kan selv registrere/oprette sin bruger og en administrator kan oprette andre bruger. Det skal være muligt at tildele forskellige brugerroller med forskellige rettigheder. 7

9 3. Sager: oprettelse af sager og knytte dem til brugere af forskellige roller (bruger og vejleder) 4. Meddelelser: sende af meddelelser til brugere som gemmes under sagen. 5. Dokumenter: består af to type dokumenter: a. Webformular: udfyldes af brugeren med versionsstyring som viser udvikling i webformularen. b. Oploade: oploade forskellige typer af dokumenter (.pdf,.doc, docx etc.) 6. Oversigtssider: generering af oversigtssider der viser udvikling i en sag. 7. Notifikationer: varsle brugere om fremtidige frister og deadlines. Sende til den studerende når en administrator fortager en handling i brugerens profil sag eller dokumenter. 8. Administration: Sager og bruger skal drives og kontrolleres af administratorer. Det skal være nemt at håndtere administrations opgaver, systemets kontrolpanel skal kunne: a. Godkende brugere der melder sig til systemet b. redigere brugere c. søge efter brugere d. vise en liste over brugere der er sorteret efter semester e. redigere sagens brugere f. redigere sager g. søge efter brugere h. vise en liste over sager der er sorteret efter semester i. redigere sagens dokumenter j. vise sagens dokumentere k. viser sagens dokumenters status l. godkende sagens dokumenter m. sende/vise sagens meddelelser 8

10 n. godkende udsendelsen af notifikationer, slette notifikationer og ændre på notifikationens tidsfrist. Udover de ovenstående funktionaliteter skal systemet integrere bussiness cases og automatisere de handlinger som administratorer skal foretage sig, såsom godkendelsen af oprettelsesdokument og udsendelse af bekræftelser. Systemet skal også betjene brugere hurtigt og effektivt, det betyder at systemet skal være i stand til at give den ønskede output/svar til brugerens forespørgsler/input. 3.2 Afgrænsning Det er kendt at webapplikationer kan videre udvikles og udvides med uendelig optimeringer og funktionaliteter, derfor er det nødvendigt at sætte grænser til projektet da projektet har udvidelses potentiale. Afgrænsningen skyldes naturligvis den begrænsede periode der er sat til projektet (5 måneder) Optimering Systemet kan optimeres på mange forskellige måder: Caching[Cache1]: for at sænke antal forespørgsler, kan caching være nyttigt (for både JSP filer og database), f.eks. i det tilfælde hvor de seneste data der blev læst eller skrevet skal læses igen. Database: databasen kan optimeres på følgende måder: o Normalization[Norm1]: som kan både spare lagringsplads og sikre overensstemmelse af data. o Forespørgsler: MySQL/SQL forespørgsler kan optimeres således at den kræver mindre tid og ressourcer for at udføre. Kode: som den først udgave af systemet, kan Java koden optimeres således at den bliver ekstra hurtig og effektiv. Dette kan gøres ved at analysere koden og dens effektivitet. Brugervenlighed / Usability: når det kommer til webapplikationer så brugervenlighed er en vigtig aspekt der kan resultere i applikationens succes eller fiasko. Det kræver stor indsats for at gøre webapplikationen så brugervenligst som muligt, derfor nøjes jeg med 9

11 at bruge de basale aspekter i brugervenligheden. Sikkerhed: sårbarheder findes i alle software-applikationer og specielt i webapplikationer der disse sårbarheder kan føre til adgang for private filer og administrative funktionaliteter og i det værste tilfælde adgang til serverens kontrolpanel. Systemet vil sikre at det er ikke muligt at få adgang til andre brugeres filer eller administrative funktionaliteter gennem testen. Systemet vil også sikre at forhindre SQL-Injection og CSS-Attacks, men dette skal testes i større skala for at være sikker på at der ikke er andre sårbarheder. Der vælges at ikke ligge vægt på de ovenstående, på grund af tidsbegrænsning, men der prøves at optimere de ovennævnte aspekter så meget som muligt. En vigtig ting er at bygge systemet således at det er nemt at udvide og optimere. Sikkerheden er også vigtig, derfor tages det til betragtning til en vis grad. 3.3 Planlægning Jeg påbegyndte arbejdet på projektet den 9. marts I starten fulgte jeg andre kurser som var en del af mit sidste semester i bachelor. På grund af presset i starten, som skyldes de andre kurser, afsat jeg 1-2 dag om ugen til at arbejde med projektet. Jeg startede med at bygge og designe datamodellen og derefter startede jeg på implementering. I starten gik det lidt langsomt på grund af travlheden med de andre kurser og først ved slutning af maj måned hvor jeg begyndte at beskæftige mig fuldtids med projektet. Jeg kunne ikke følge tidsplanen i starten derfor har lavet en anden tidsplan i starten af juni, som blev fremvist til vejledningsmøde og som kan ses på figur 4.1 (et større billede kan finde under bilag 1 tidsplan). Figur 3.1 Tidsplanen viser hvor meget der er nået til og med starten af juni 10

12 3.4 Use cases Aktører Følgende aktører er identificeret ved hjælp af opgave analyse og vejledningsmøder: 1. Tilmeldte brugere: Disse brugere er dem der tilmelder sig systemet og venter på godkendelse og tildeling af rettigheder. Tilmeldte brugere har ingen rettigheder indtil de bliver godkendt og tildelt en af de nedenstående aktørers rolle. 2. Studerende: Den studerende der skal udføre praktik og eksamensprojekt, den betegnes som almindelig brugere med de basale rettigheder. 3. Vejleder: Er en medarbejder fra DTU som bliver tilknyttet eksamensprojektet for at vejlede den studerende. Vejlederens rettigheder er det samme som almindelig brugere (studerende). 4. Praktikassistent: PA er assistenten for praktikkoordinatoren, som følger beslutninger og afgørelser mht. godkendelse af dokumenter og brugere. PA har adgang til systemets kontrol panel og kan administrer sager, dokumenter og bruger. 5. Praktikkoordinator: PK er personen som afgør beslutning med sagers indhold og tilstand. PK har adgang til systemets kontrol panel og kan administrer sager, dokumenter og bruger. 6. Administrator: Er oprettet alle først i systemet og bruges til at tildele rettigheder til både PK og PA. Rettighederne er det samme som PA og PK. 11

13 3.4.2 Use cases diagram Som vises på figur 4.2 (et større billede kan findes under bilag 2 use cases diagram) så har PK, PA og administrator de samme rettigheder som omfatter hele systemets funktionaliteter. Det skal siges at bilag 8 indeholde implicitte funktionaliteter og rettighederne til at godkende praktikophold og eksamensprojekts abstract osv. Neden i figuren vises de rettigheder som studerende og vejleder har, de er det samme rettigheder de har i sagen. For mere detaljeret use cases, se venligst appendiks 1 use cases. Figur 3.2 use cases diagram 12

14 4 Design Designet danner systemets grundlag og gøre det overskueligt at forstå hvordan systemet virker og hvordan det kan forbedres funktionelt, brugervenligt og hvordan den kan gøres mere sikkert. I denne afsnit vil jeg komme ind på de forskellige design principper og metoder som jeg valgte at anvende i systemet, samt designet på de forskellige dele som systemet består af. 4.1 Design principper Model/view/controller Systemet bliver udviklet i Java og JSP og vil benytte MVC[MVC1] modellen som det primære designprincip, hvor den grafiske overflade er separeret fra den grundlæggende model. Følgende figur 5.1 viser en forenklet klassediagram over modellen, view et og kontroller. Systemet Figur 4.1 Model-View-Controller er opdelt så al kode der håndterer systemets tilstand (modellen) er afkoblet fra koden der håndterer grafikken (view et). Der er en del fordele ved denne fremgangsmåde, at det er lettere at forstå hvordan systemet fungerer så man ikke behøver at koncentrere sig om model og view samtidigt. At modellen er uafhængig af view et gør at man kan ændre view et uden at det har konsekvenser for modellen. Kode der håndterer grafik, og kode der håndterer systemets tilstand skrives ret forskelligt, og hvis man har begge samlet et sted vil koden typisk blive rodet. 13

15 Model Målet er at designe modellen på en nem og overskuelig måde og at koble komponenterne fleksibelt sammen. Som visuel repræsentation af modellen vises følgende domænemodel i figur 5.2 (et større billede kan ses under bilag 3 domænemodel) som viser de konceptuelle dele og klasser samt at giver et overblik af systemet. System: det overordnede system, som består af alle de andre mindre dele af systemet. Det indeholder alle komponenter, struktureret som vises på figur 5.2. Systemet repræsenter hele systemets og rummer alt hvad der implementeres i det. Der er kun et system som indeholder en eller flere semestre. Semester: en overordnede liste som indeholder alle sager som er knyttet til det tilsvarende semester. Sager er sorteret efter hvilke semester de hører til. Systemet har flere semestre og hver semester har flere sager. Sag: består af flere dele der vedrører sagen. Den indeholder brugere, Figur 4.2 domænemodel meddelelser, notifikationer og dokumenter. En sag kan indeholde 1 eller flere brugere af forskellige roller, altså studerende eller vejleder. Sagen kan også indeholde 0 eller flere meddelelser. Sagen indeholder dokumenter som er enten webformular eller oploadede filer. Meddelelser: hører til sagen og kan tilføjes af sagens deltagere eller administratorer. Bruger: hver sag har en ejer og ekstra deltagere som kan være af forskellige roller (studerende eller vejleder). Dokumenter: kan enten være en fil eller Indtastningsformular. Fil: Fil dokument (.doc,.docx,.pdf osv.) som er knyttet til sagen og brugeren. Filen kan oploades og downloades. Indtastningsformular: en web-formular, hvor brugere kan indtaste/redigere i det. 14

16 View Brugergrænsefladen er meget vigtig når det kommer til webapplikationer, at præsentere outputtet på en logisk og moderne måde spiller en vigtig rolle i webapplikationens succes. Det mest logiske er at præsentere brugergrænseflade på den samme måde som DTUs Campus-Net, da de studerende er allerede vandt til den grafiske præsentation og vandt til hvordan systemet er struktureret. Jeg har valgt at gøre systemets brugergrænseflade ekstra fleksibelt ved at bygge den med CSS markup, som giver friheden til at ændre på farver, størrelser og strukturen. DTUs Campus-Net er bygget nemt og overskueligt, det er meget nemt at adaptere DTUs Campus-Net struktur. Campus-Net er delt som vises på følgende figur 5.3. Systemet vil følge denne struktur. Banner: indeholder visions billede og evt. links til profil eller andre sider i DTUs hjemmeside. Links: indeholder links til syste- Figur 4.3 den grafiske opdeling mets ekstra funktionaliteter, såsom webmail, kursus tilmelding osv. Sags links: indeholder de forskellige links der linker til de forskellige dele som sagen består af. En sag kan tænkes som et kursus, hvor fil deling, meddelelsessystem og deltagerliste er under den. Indholdet: indeholder indholdet af siden, hvis man eksempelvis lander på deltagere liste, vil man se en liste over deltagerne. Notifikationer: indeholder de sidste aktiviteter, såsom de sidste oploadede filer, de sidste meddelelser osv. 15

17 Denne struktur beholdes som udgangspunkt, men sigtes stadig efter at gøre det nemt at ændre på strukturen hvis det ønskes. Udover de grafiske elementer, spiller teksten i webapplikationen også en vigtig rolle, at outputtet skal være forståeligt. Derfor valgte jeg at gøre teksten i den grafiske brugergrænseflade om til statiske variabler i en separat Klasse. Dette gør det nemt at redigere i teksten uden at grave ind i JSP filer for at finder/redigerer de rigtig strenge. Dette gør det også muligt at udvide det, til en database tekst lagring, ved at gemme strenge i databasen hvor administrator kan rette i teksten igennem webapplikationen, da disser variabler kan hente teksten direkte fra databasen Controller Kontroller er opdelt både i view et og modellen. Det er naturligvis mere logisk at placere kontrolleren i view et for at kontrollerer brugerens input, det skyldes at brugeren interagerer med den grafiske grænsebrugerflade. Der vil stadigvæk være mulighed for at tilføje kontroller i modellen, i de tilfælde hvor kontrolleren har intet med brugerens input at gøre Datalagring Data vil primært gemmes i en database, de eneste data der ikke gemmes i database er de oploadede filer, da disse vil gemmes som fysisk filer på serveren. Som database bruges MySQL da det er OSS, hurtig og nem at brugere og på grund af min erfaring med databasen. Selvom MySQL er valgt som database, vil systems databases forespørgsler være generelle SQL forespørgsler for at gøre det nemmere at anvende en anden database hvis det ønskes senere Flere lags arkitektur MVC øger systemets fleksibilitet og sikkerhed. Systemet består af flere lag som kan vises på følgende figur 5.4. Et succesfuldt input vil gå igennem de 3 lag og hente outputtet direkte til den grafiske brugergrænseflade. Kontrol og tjek på inputtet kan tilføjes i hvert lag som beskrives herunder. Figur 4.4 flere lags arkitektur 16

18 Brugergrænseflade: den grafiske præsentation, hvor brugerne kan interagerer med de grafiske elementer, sender input og modtager output i form af tekst og grafik. Logiske operationer: de operationer som bestemmer hvad der skal vises på den grafiske brugergrænseflade f.eks. at tager brugerens interaktioner som input og behandler dem inden de sendes til data-kontrollen. Data-kontrol: efter inputtet passerer logikken vil data-kontrollen kontrollere udføre de metoder der skriver til og læser fra databasen. Databasen: MySQL databasen hvor data gemmes til og læses fra. Kontrol og sikkerhed kan tilføjes for hvert lag, f.eks. XSS-attacks kan undgås i brugergrænseflade ved at sikre at forkert input behandles rigtigt og ikke resulterer i visning af brugerens private data. SQL-injection kan både tilføjes i logiske operationer og data-kontrol, at tjekke om inputtet indeholder uforventet tegn som kan resultere i udførelsen af ekstra SQL forespørgsler. Databasen kan også dele de rigtige rettigheder til database-brugeren således at den ikke har adgang til super administrative oprationer såsom at slette hele databasen eller tabellen osv Undgå hårdkodning i modellen Det er tiltænkt som en del af kravet at det skal være muligt at udvide systemet. Dette forsøges at overholde ved at beskrive systemet som objekter af klasser, som er modtagelig for udvidelser og ændringer. Dette betyder at designet af modellen er noget mere kompliceret end ellers, men det giver et system der let kan videreudvikles. 4.2 Klassefordeling Systemet deles i forskellige klasser, hver klasse vil være ansvarlig for at udføre disse operationer der tilhører komponent, det betyder at User klasse vil udføre alle operationer som vedrører brugere, såsom log ind, tilmelding, udsendelsen osv. Hver klasse har en statisk variable som er tilgængelig i hele projektet og vil tilgås via klassenavn.objektet, dette kan spare serveren for at genere nye objekter hver gang en JSP side loades. Det betyder at klassernes objekter vil hente data fra databasen direkte i stedet for at gemme det i felter, altså at klasserne/objekter ikke har felter, men getters i stedet. Det betyder også at systemet nøjes med den statiske variabel hver klasse har for at få adgang til klassens funktioner. For at beskrive systemets struktur ved at vise følgende klassediagram på figur 5.5 (et større billede kan ses under bilag 4 klassediagram) som 17

19 viser klassernes attributter og relationer mellem hinanden. Figur 4.5 klassediagram Som ses på diagrammet så har alle klasserne en statisk variabler der er bundet til sig selv, dette betyder at klasserne er ikke afhængig af hvor mange objekter der må være mellem klasserne, men domænemodellen overholdes stadigvæk Config Config klassen indeholder kun statiske variabler som andre klasser er afhængig af. Klassen indeholder f.eks. brugernavn og adgangskode til databasen og stien til at oploade og downloade filerne. Klassen indeholder også alle de strenge der skal præsenteres i den grafiske brugergrænseflade. Det er nemmere at redigere i Config klassen end at rode rundt i de andre klasser og JSP filer. Formålet med klassen er at gøre det nemmere at ændre på vigtige variabler således at den passer i den server man ønske at køre systemet på. 18

20 4.2.2 DBConnection DBConnection er en vigtig klasse som andre klasser er afhængige af. Klassen opretter forbindelsen til databasen. DBConnection klasse er afhængig af Config klasse til at forbinde sig med databasen. Dette gør det nemmere at forbinde sig til forskellige databaser uden at ændre i selve koden i klasserne Resten af klasserne Resten af klasserne repræsentere sig selv, da klassernes navne er tydelige og lige til. F.eks. Document klasse tager sig af alle de operationer der skal udføres og behandles i dokumenterne, både som webindtastningsformular og oploadede filer. Klasserne indeholder primært SQL forespørgsler 4.3 Database design Databasen er designet primært efter modellen for at opfylde dens behøv. Tabeller i database følger nogen lunde modellens klasser, for hver tabel bærer det samme navn på klassen. Det er overskueligt er opdele det på den måde, så man ved hvilke klasser høre til hvilke tabeller i databasen. Felter i tabellerne repræsenterer de variabler de indeholder, primært i form af int, string eller date objekter, dette gør det lige til at hente data fra databasen uden at kaste eller konvertere det til en anden type af objekter. Alle tabeller indeholder en ID variabel der gør felterne unikke. Studie nr. er den nøgle som bruges til at identificere hvilke data høre til hvilke brugere, dette er sikkert fordi systemets henter students nr. efter en succesfuld log ind og dette kan ikke manipuleres véd input eller lignede. Databases design diagram kan vises som ER[ERM1] model, databasemodellen kan ses på følgende figur 5.6 (et større billede findes under bilag 5 ERM). Som ses på figur 5.6, så ligner databasens struktur den struktur som domænemodel har i figur 4 hvilket betyder at der er overensstemmelse i systemets design. 19

21 Figur 4.6 database ERM Semester: tabellen indeholder et felt med navnet på semester. Case: er knyttet til et semester og en bruger som ejer. Sagen kan have flere brugere ved at tilføje et nyt felt som indeholder studie nr. på det ekstra medlem i extramember feltet. User: indeholder navn, studie nr. password, og hvilke rolle skal brugeren have. Messenger: indeholder både tråde og meddelelser, de er knyttet til både brugeren og sagen. Event: indeholder ejeren, startdato og slutdato. Slut datoen vil bruges til at tjekke om den studerende har udfyldt bilag 8 trin 3 og derefter bestemmer om en event skal sendes i form af eller ej. 20

22 Regdoc: er oprettelsesdokuments tabel som indeholder alle felterne der skal være i dokumentet. Feltet er knyttet til brugeren via studie nr. Doc8: er bilags 8 tabel, som også indeholder alle de felter i bilaget. Felterne er knyttet til sagen og sagens ejer. Doc5-6-7:er bilag5, 6 og 7, som indeholder ejeren af bilagene, datoen på sidste ændring og filens navn og type. Da disse bilag er fysiske filer der skal oploades til server, er der ikke brug for at gemme indholdet i databasen. Felterne er knyttet til sagen og sagens ejer. Doc10: er bilag 10, som indeholder de 4 felter og knyttet til sagen og sagens ejer. 21

23 5 Implementering I denne afsnit vil jeg komme ind på implementeringen af systemets vigtige komponenter og hvordan de fungere. Systemet findes online på følgende hjemmeside i tilfælde at der ønskes afprøvning. Log ind data kan findes under appendiks online udgave. Systemets er implementeret ved hjælp af Eclipse WTP, både til skrivning og testning af Java kode. Til database brugte jeg phpmyadmin[phpmyadmin1] til at designe og oprette tabeller og felter i databasen samt at udføre SQL test forespørgsler. Jeg brugte engelske ord og termer til at beskrive variabler og funktioner i koden. Som sagt er systemet delt i MVC, hvor modellen ligger i en Java pakke kaldt Core. View et er JSP filerne. Kontrollen som sagt er fordelt men findes primært i JSP filerne. JSP filer få adgang til modellens funktioner via de statiske variabler som findes i hver klasse. JSP kan få adgang til de forskellige funktioner som følgende: Case.thisCase.functionName(); Document.thisDoc.functionName(); Messenger.thisMsg.functionName(); User.thisUser.functionName(); Hvor thiscase, thisdoc, thismsh og thisuser er statiske objekter. Systemet er delt i to dele, den ene for brugere, og den anden for administratorer, betragtes som kontrolpanel. 5.1 Log ind/ud Studerende kan melder sig ind i systemet, men de skal godkendes inden de kan få lov til at fortsætte videre i systemet. Registreringsside vil kræve at den studerende indsætter DTUs studie nr., navn password og DTUs student . Når en brugere forsøger at logge ind via log ind siden login.jsp tjekker siden om brugeren findes i systemet og om brugeren er godkendt af administrator. Der vises en fejlmeddelelse som informerer brugeren om hvilken fejl der er sket ved log ind. Hvis brugeren logger ind korrekt ved at tjekke i databasen om brugeren og koden findes, så gemmes brugernavn og adgangskode i session variabler og tjekkes løbende i systemet om oplys- 22

24 ninger er rigtigt og om session variabler eksisterer stadigt. Følgende kode viser hvordan log ind siden fungere: if((request.getparameter("username")!= null) && (request. getparameter("password")!= null) ){ String user = request.getparameter("username"); String password = request.getparameter("password"); Boolean success = User.thisUser.checkLogin(user, password); Boolean active = User.thisUser.isActive(user); if(success && active){ session.setattribute("uid", user); session.setattribute("password", password); session.setmaxinactiveinterval (Config.maxInactiveInterval); } Log ind siden indeholder to HTML tekst felter som hedder username og password i en HTML form som sender disse variabler videre. Først i line 1 kontrolleres at disse felter er udfyldt og sendt til siden, derefter gemmes både username og password og tjekkes om log ind lykkes med disse felter. Metoden checklogin i line 6 tager bruger og kode i form af streng og tjekke i databasen om de findes, hvis de gør så returneres sand, ellers falsk. Metoden isactive i line 7 tjekker i databasen om bruger er godkendt, hvis begge metoder returnerer sand så gemmes brugernavn og adgangskode i en session variabel som kan ses på line 9 og 10. Til sidst i line 12 kontrollers hvor lang tid skal sessionen eksistere i serveren inden den slettes, denne variabel hentes fra Config klasse som er sat til 3600 sekunder som standard, hvor burgeren kan fortsat blive logget ind i systemet. At logge ud virker på samme måde, men bare ved at fjerne session variablerne fra serveren if(request.getparameter("action")!= null && request. getparameter("action").equals("logout") ){ session.removeattribute("uid"); session.removeattribute("password"); } Line 2 og 3 viser hvordan systemet fjerne de tilsvarende session variabler (som er sat ved log 23

25 ind) fra serveren. Som ses på de ovenstående kode, så gemmes adgangskoden i databasen og sessions variabel uden kryptering, da i test fasen havde jeg bruge for at fejlfinde om log ind mekanismen virkede korrekt. Som ekstra sikkerhed kan systemet kryptere adgangskode med md5 kryptering + salt værdi som gør det ekstra besværligt at knække: md5(md5(password). salt) Efter en succesfuld log ind, bliver brugeren omstillet videre til at udfylde oprettelsesdokument hvis det ikke er udfyldt eller godkendt, eller til sagen hvis oprettelsesdokument er godkendt if(!document.thisdoc.isregdocvarified(user) && User.thisUser.isUser(user) &&!Case.thisCase.isCaseExtraMember((String)session.getAttribute("UID"))) response.sendredirect("regdoc.jsp"); else response.sendredirect("cn.jsp"); Line 1 tjekker om brugeren fik godkendt sit oprettelsesdokument, om brugeren er studerende (ikke vejleder eller administrator) og om brugeren er ikke en ekstra medlem I sagen, da kun sagens ejer skal udfylde oprettelsesdokument. 5.2 Bruger Brugere kan have forskellige roller, som vises i aktører under use cases. brugere være en af den nedenstående: Ikke godkendt værdien (-1 ) Studerende (0) Vejledere (1) praktikassistent (2) praktikkoordinator (3) systems administrator (4) Selv om der er 6 forskellige roller betragtes de foreløbig som 3 forskellige grupper da dette kan 24

26 udvides meget enkelt. De tre grupper består af: Ingen rettigheder: det er disse brugere der ikke er godkendt endnu Bruger rettigheder: det er studerende og vejleder, med de basale rettigheder til egen sag. Administrator rettigheder: det er PK, PA og admin, med ekstra administrations rettigheder og adgang til systemets kontrol panel. Grunden til at brugere delt i 6 grupper er, at gør det muligt at tildele forskellige roller ved udvidelsen. Når en bruger gemmes i databasen, så gemmes rollens værdi med i user tabellen. Brugeres primære nøgle er studie nr. der bruges som brugernavn i systemet, den sammen med en da begge skal være unikke, det vil sige andre brugere med det samme studie nr. eller e- mail må ikke registreres i systemet. Studie nr. bruges til at genkende brugeren og tilknytte de andre dele i systemet såsom meddelelser og dokumenter, til brugeren. Brugerens blev begrænset til at være en student der ender denne begrænsning er gemt i Config klassen som allowed host, variablen kan ændres for at tillade et andet domæne, eller lades blank som wildcard til at tillade alle typer af s. 5.3 Dokumenter Dokumenterne er delt i to dele, som webformular og som fysiske filer. Oprettelsesdokument samt bilag 8 og 10 er webformular mens bilag 5, 6 og 7 er fysiske filer som kan oploades. Som sagt, bruges de engelske ord i koden, derfor blev dokumenterne navngivet på engelsk som følgende: Dokumentnavn på dansk Oprettelsesdokument Dokumentnavn på engelske regdoc (registering document) Bilag 5 Doc5 (document 5) Bilag 6 Doc6 (document 6) Bilag 7 Doc7 (document 7) 25

27 Bilag 8 Doc8 (document 8) Bilag 10 Doc10 (document 10) De dokumenter der er lavet som webformular fik den samme struktur og de samme farver som de var oprindeligt på word dokumenterne. Opdeling er bygget via en HTML tabel som indeholder både indtastningsfelter og beskrivelser. Dokumenterne findes under fil deling, fil delings side file.jsp findes under sagen og indeholder en liste over dokumenterne som vises på følgende figur 6.1: Figur 5.1 fil delings side Brugere kan klikke på det ønskede dokument for at udfylde, redigere eller oploade. Opdeling er opdelt efter vejledning i bilag Oprettelsesdokument Dette dokument er det første som den studerende bliver omstillet til (efter en succesfuld tilmelding, godkendelse og log ind). Det er nemlig log ind mekanismen som tjekker om den studerende er ny og ikke fik oprettelsesdokument godkendt endnu, hvis det er sandt, bliver den studerende automatiske omstillet til oprettelesdokuments side (regdoc.jsp). Den automatiske omstilling vil hjælpe den studerende med at gøre hvad der skal gøres. Oprettelsesdokument har mange felter og nogle af dem er valgfri felter, derfor er det ulogiske at kræve udfyldelsen af dem alle. Jeg har valgt at kontrollere om de indtastede værdier er korrekte vil være begrænsede for de nedennævnte felter. Ved fejlindtastning vil systemet informere brugeren om hvor fejlen opstå ved at markere den tilsvarende felt med rød baggrund som vises på følgende figur

28 Figur 5.2 oprettelsesdokument fejlfinding Dette er implementeret ved alle obligatoriske felter. Systemet vil tjekke om inputtet er forkert eller tom, hvis det er tilfælde vil den give feltet en anden CSS klasse som har den røde baggrund: <td class="opretdoctd<% if(request.getparameter("studentphone")!= null && request.getparameter("studentphone").equals("")){ %>alert<% } %>">Kontakt telefonnummer mobil</td> Hvor opretdoctdalert CSS klassen er som følgende:.opretdoctdalert{ border: 1px solid #C0C0C0; background-color: red; width: 190px; } Baggrundsfarve kan ændres ved at blot ændre på background-color i CSS klassen. Administratorer kan godkende oprettelsesdokument, hvorefter en vil blive sendt til den studerende for at informerer om godkendelsen, herefter oprettes sagen automatisk. I følgende afsnitte vil jeg uddybe de obligatoriske felter og hvordan de behandles og parses Navn og studienummer Disse felter er kun læseligt, da brugeren allerede har indgivet navn og studienummer ved tilmelding. Det betyder at brugeren ikke kan ændre på navnet eller studienummeret. Grunden er at systemet ikke skal tjekke om navnet og studienummeret er i overensstemmelse med den før indgivet information. Disse felter er som sagt readonly og få værdien automatisk fra systemet. 1 <input name="fullname" type="text" class="opretdocfield" value="<%= User. thisuser.getusersname((string)session.getattribute("uid")) %>" readonly="readonly" /> 27

29 Metoden getusername tager brugerens studienummer som parameter og returnerer brugerens fuld navn som streng. Hvis de lykkes brugere at ændrer i HTML kode og sætter readonly attribut til falsk, vil dokumentet ikke påvirkes, da værdien hentes stadig fra systemet og ikke fra feltets variable, det vil sige at navnet og studienummeret vil altid være i overensstemmelse og brugerens input vil ikke kunne ændre på det Resten af de obligatoriske felter Resten af de obligatoriske felter er åben for brugerens input, men kontrolleres naturligvis om de er korrekte. Orienteringsmøde(r): dette felt skal indeholde datoer på orienteringsmøder. Der nøjes med at gemme feltet som streng selvom det er datoer der skal indsættes, det skyldes at der er flere datoer der skal indsættes som gør det risikabelt at parse datoerne korrekt. Det er også ikke nødvendigt at gemme datoerne som date objekt da disse ikke bruges senere i forløbet til tjek eller advarsler. Studie retning / Standardstudieforløb / Datamatiker: disse felter er radio felter hvor brugeren skal vælge et af de allerede definerede valg. Dette gemmes i databasen som TINYINT, hvor 1 er det første valg og 0 er den anden. Antal point: dette felt betragtes som numerisk værdi og ved indtastning af tekst i stedet for tal, vil systemet klage og markere feltet Uobligatoriske felter Disse felter er ikke nødvendige at udfylde, brugeren kan selv vælge om at udfylde eller ej, det betyder at det eneste tjek er om værdierne er numeriske eller blot tekst inden de indsættes i database. Der er ingen fejlfinding eller informering i disse felter. 28

30 5.3.2 Bilag 5, 6 og 7 Bilag 5, 6 og 7 gemmes som fysisk filer der skal oploades til systemet, derfor er de ens i hvordan de behandles. Jeg har valgt at håndtere de 3 bilag i en enkel JSP side (uddoc.jsp - UploadDownloadDocument). Det er doctype GET variablen der kontrollerer hvilke dokument der skal vises, downloades eller oploades. Variablen doctype skal enten være 5, 6 eller 7, systemet acceptere ikke andre variabler som vises i følgende kode: if(request.getparameter("doctype")!= null &&!request. getparameter("doctype").equals("")){ if( request.getparameter("doctype").equals("5") request.getparameter("doctype").equals("6") request.getparameter("doctype").equals("7") ) doctype = request.getparameter("doctype"); else response.sendredirect("file.jsp"); } Filerne kan oploades til serveren ved at indgive hvilken sti filerne skal gemmes under, dette er defineret i Config klassen: public static String docdownloadpath = "C:\\Documents and Settings \\Nawar\\workspace\\SysDoc\\WebContent\\downloads\\"; Brugere er kun tilladt at oploade doc, docx, pdf, gif og jpg filer som standard. Filen oploades til serveren ved at tilkalde Document.uploadDoc(DataInputStream in, int formdatalength, int lastindex, String boundary, String owner, String doctype), metoden læser filens bytes igennem via en løkke og skriver den til serveren. Filens navn gemmes som følgende: Studienummer-sagsnavn-dokumentstype.filenstype Hvor studienummer er studentens studienummer, sags navn er navnet på sagen der som standard er det samme som studienummeret, dokumenttype er doc5, doc6 eller doc7 som repræsenterer hvilket bilag. Filtypen er en af de filtyper der er tilladt som vist ovenfor. Et eksampel på en oploadede fil kan være: s s doc5.doc Filerne kan også downloades fra den samme uddoc.jsp side da den har inkluderet getfile.jsp der læser filen fra serveren, og skriver den til ServletOutputStream således at brugere ikke ved hvor filen ligger i serveren og ikke har direkte adgang til filer, dette sikrer at brugere kun har adgang 29

31 til deres bilag. Dokumentet kan opdateres ved at oploades igen, da systemet vil overskrive den eksisterende fil automatisk. Når et dokument oploades, gemmes der i databasen hvornår det er oploadet for at vise administrator den seneste aktivitet i bilaget, som vises på følgende figur 6.3. Figur 5.3 Opload/download bilag 5 Bilag 5, 6 og 7 data bliver gemt i en separat tabel doc5-6-7 og systemet vil kunne identificere forskel på bilagene ved attributtet doctype Bilag 8 Bilag 8 er en webformular der stort set virker på samme måde som oprettelsesdokument. Bilag 8 indeholder mange felter som skal udfyldes hen ad vejen, det betyder at det ikke er nødvendigt at udfylde alle felter fra starten af. Felterne er delt i 3 sektioner: Studerende Praktikvirksomhed og praktikophold Eksamensprojekt Det første som brugere skal udfylde efter oprettelsesdokument er sektion 1 i bilag 8, det vil sige at kun disse felter er obligatoriske og kun dem der skal være udfyldt før det gemmes i databasen. Bilag 8 er versionsstyret hvor hver gang brugere ændrer i bilaget, gemmes det som separat version som kan vises af både brugeren og administratorer. Et meget vigtig felt, er datoen for praktikstart, dette gemmes som Date objekt da dette bruges til at notificere brugeren om tidsfrister senere i forløbet. Godkendelse af bilag 8 sker delvis, administratorer har brug for at godkende de 3 sektioner igennem hele forløbet men én sektion ad gangen. Hver sektion af de ovenstående kan godkendes separat som vises på følgende figur

32 Figur 5.4 bilag 8 godkendelse af sektion 1 Efter godkendelsen af hver sektion, vil systemet sørge for at de tilsvarende felter bliver vist som readonly. Bilag 8 data bliver gemt i en separat tabel doc8 hver gang brugeren ændrer i det bliver det gemt som en separat version som er tilgængelig nederst i siden som vises på figur 6.5. Hver version kan vises ved at trykke på det tilsvarende link i listen. Det er ikke muligt at redigere i gamle versioner af bilag 8, da redigering vil resultere i at bilag 8 gemmes som en ny version. Det betyder at alt hvad der udfyldes, gemmes som en separat kopi i databasen og den sidste udfyldte vil altid være den der vises automatisk når man lander på bilags 8 side. Figur 5.5 verions liste Bilag 10 Bilag 10 er også en webformular og virker på samme måde som oprettelsesdokument. Der er kun 4 streng felter i bilaget og må udfyldes med hvad som helst uden kontrol eller fejlfinding. Bilag 10 bliver gem i en separat tabel doc Dokumenters notifikationer Notifikationerne informerer brugeren om hvad der skal fortages i sagen. Notifikationer kan være i for af link til bilag 5, 6, 7, 8 eller 10 hvis de ikke er udfyldt eller oploadet endnu. Dette Figur 5.6 notifikationer 31

33 bliver vist i sagens forside, og vil forsvinde hvis den pågældende aktivitet er overholdt. Figur 6.6 viser notifikationer på en sag der er lige oprettet. Lige så snart bilag 5 er oploadet, vil notifikationen Opload bilag 5 forsvinde, det samme med de andre notifikationer. 5.4 Meddelelser Meddelelses system er tråd baseret, således at meddelelser er delt efter den tråd de hører til. Alle meddelelser bliver gemt i messenger tabellen. Meddelelser vil betragtes som selvstændig tråd hvis de ekstra felter i tabellen er udfyldt, ellers er det bare meddelelser som vises på følgende figur 6.7: Figur 5.7 meddelelsestabel Som vises på figuren, så er de første 5 felter er tråde, da de både har topictitle (tråd titel) og topic sat til 1. Felt 8 er en meddelelse der hører til tråd 2, for de har det samme topicid, det samme med felt 9, det hører til felt 3 osv. Det vil sige at meddelelser vil grupperes under tråd vha. tråds id som vises på følgende kode: <% String[] replies = Messenger.thisMsg. gettopicreply(integer.parseint(request.getparameter("topicid"))); <ul> <% for(int i=0; i < replies.length; i=i+2){%> <li><b><%=replies[i] %>:</b> <br /><%= replies[i+1] %></li> <%}%> </ul> Metoden gettopicreply i line 1 får en topicid som GET variabel (dette er automatisk sat i tråd li- 32

34 ste links) og returnere en liste af meddelelser der indeholder ejer og teksten på hver meddelelse. Line 3 til 5 kører en løkke der består af hvor mange meddelelser der er i listen, og printer både meddelelsens ejer replies[i] og tekst replies[i+1]. Listen vil blive vist i punktform vha. <ul> <il> som kan ændres til hvad som helst, da disse tags kan manipuleres via CSS til at opnå de ønskede format. Som en vigtig sikkerheds tjek, bliver meddelelserne knyttet til sagen, og ejeren af meddelelsen, dette sikrer at brugere kun har adgang til deres egne meddelelser Meddelelses notifikationer Disse notifikationer bliver også vist på sagens forside og vil indeholde de sidste 3 indlæg i de sidste 3 tråde som vises på følgende figur 6.8. I figuren vises de sidste meddelelser i sagen, noteret med tråd titel og meddelelsens ejer. Sagens brugere Figur 5.8 meddelelses notifikationer kan klikke på linket og falde direkte i tråden. I figuren vises sagens ejer (s062412) og sagens vejleder (mbo). 5.5 Sag En sag samler alle de førnævnte elementer under sig. Det er vigtigt at notere at alle elementerne knytter sig til sagen og sagens ejer, dette vil sikrer at når SQL forespørgslerne udføres, så returneres kun de elementer, man er ejer for. Sagens forside indeholder links til de forskellige elementer som vises på følgende figur 6.9: Figur 5.9 sagens forside På højre side i figuren vises den statiske menu som er den samme for alle brugere. I miden vises 33

35 de dokumenternes notifikationer som tidligere beskrevet, sagen vil sørge for at tjekke dokumenternes tilstand og dermed bestemme om at notificere brugere. Og til venstre er den allerede beskrevet meddelelses notifikationer. 5.6 Layout Layoutet som er nævnt under design vil følge DTUs standard struktur. Layoutet blev delt ved at anvender div tags i stedet for table, for det er mere moderne at anvende det, da tabeller i html er beregnet kun til data. Layoutet er delt som står i figur 5.3 under design. De forskellige sektioner i figur 5.3 blev delt med div tags som vises på følgende figur 6.10: Figur 5.10 layout opdeling Sidens brede er 784 pixel, dette er rettet efter banners størrelse. Sektion 1: indeholder banneret i form af 784px * 150px i en div som rummer det. Den har en CSS klasse logo og kan tilrettes via CSS. Sektion 2: Indeholder den vandrette menu i en div som har CSS klassen menu. Sektion 3: Indeholder dokumenternes notifikationer i en div som har CSS klassen quickinfo Sektion 4: indeholder den lodrette menu som er også i en div med CSS klassen leftmenu Sektion 5: indeholder den sidste meddelelser i en div med css klassen leftinfo Sektion 6: indeholder sektion 3, 4 og 5 i en div med CSS klassen content 34

36 Alle siderne vil have de samme sektioner undtagen sektion 5 da den kun vises på sagens forside. De faste elementer blev delt op i forskellige filer, formålet er at inkludere disse filer i alle JSP filer således at koden ikke behøver at bliver gentaget i alle siderne. Layoutet er delt i: Header: indeholder banneret og findes i header.jsp Footer: indeholder slut tags på header og findes i footer.jsp Vandret menu: Indeholder links til forskellige dele i systemet. Kode findes menu.jsp som tjekker om man er almindelig brugere eller administrator og derefter bestemmes hvilke links der skal vises. Venstre lodret menu: Indeholder sagens links og findes i leftusermenu.jsp. Det ovenstående opdeling gøre det nemmere at ændre i sektionerne, for det er en enkelt fil der skal ændres i stedet for at ændre i alle JSP filer. HTML koden er kodet efter w3c[w3c1] webstandard, således at de virker lige i både Internet Explorer og FireFox. Jeg har heldigvis har videnskabsteori kursus hvor projektet var webbrowser. Det betyder at jeg har lavet masse undersøgelse af webstandarder i de forskellige browsere. Systemets layout virker korrekt på både IE og FF Systemet sender en del s frem til de studerende, derfor er det vigtigt at anvende en metode der er sikkert at sende. Systemet anvender SMTP server som er sikkert og hurtigt. I systemet anvendes Gmails SMTP, som har adgang til via en ny konto der er oprettet til systemet praktiksystem@gmail.com. Systemet kan anvende andre SMTP serverer, det er blot at ændre SMTP serveren samt brugernavn og adgangskode hvis det er krævet til at forbinde til den pågældende SMTP server. 5.8 Fejlhåndtering Klasserne består af mange SQL forespørgsler, og de er alle sammen dækket med try&catch i tilfælde at der sker en exception så vil den fanges og printes til stakken. Jeg valgte at printe exceptions til stakken på grund af testning og fejlfinding, for tomcat[tomcat1] serveren vil selv sørge for at udskrives exceptions til log filen, som kan brugeres til at finde fejl. JSP bruger speciel attri- 35

37 but errorpage som viser en fejl side i stedet for at vise selve fejlen i koden, til brugeren, dette vil inkluderes i alle JSP filer for at sikre at brugere ikke få mærkelige fejl og ikke se en del af koden. 5.9 Systemets kontrolpanel Der blev brugt mange timer og masser af kræfter for at bygge et kontrolpanel som er tilgængelige for administratorerne. findes i en separat mappe, kaldt admin som standard, men kan ændres vha. Config klassen. Kontrolpanelets omfang er større end selve sagen system som er tilgængelige kun for brugere, det skyldes at der er mange ting der skal holdes styre på igennem kontrolpanelet. Kontrolpanelet er delt efter sagens elementer som følge i de kommende afsnitte: Brugere Administratorer har brug for at administrere brugere, derfor har systemet et kontrolpanel dedikeret til at behandle brugere. Det hele er implementeret i users.jsp Redigere brugere Brugere redigering giver administrator muligheder for at ændre i brugeres profil. Det er muligt at redigere alt, fra fuldnavn, adgangskode til den rolle en brugere skal spille i systemet. For at redigere en bruger skal systemet først søge efter brugeren i databasen, via brugernavn, , fuldnavn eller alle tre, hvorefter vil siden vise brugerens informationer i redigerings felter som vises på følgende figur 6.11 Figur 5.11 bruger redigering Det er finduser() metoden der søger efter en bruger med de angivet felter og returnere en liste der indeholder brugerens informationer som parses ind i felterne i figur

38 Administrator kan ændre brugernavnet, fuldnavnet, adgangskode, og rolle Oprette brugere Administrator kan oprette ny brugere på samme måde som brugere tilmeldingsside. Det sker ved at udfylde de nødvendige felter som vises på følgende figur 6.12 Figur 5.12 bruger oprettelse Mekanismen er det samme som er i register.jsp derfor er det op til administrator om oprettelse kan ske igennem kontrolpanelet eller tilmeldingsside. Det er userregister() metoden der tager de udfyldte felter og indsætter brugeren i databasen hvis brugernavnet og en ikke eksisterer i user tabellen Godkende brugere Administrator skal godkende brugere når de tilmelde sig for at de kan fortsætte i systemet. Det kan gøres ved at gå ind i godkend brugere sektion i kontrolpanelet. Systemet vil søge i user databasen efter de brugere der har rolle sat til -1, og ved at godkende dem gives værdien 0 automatisk som betyder almindelig studerende. Det er metoden verifyuser der godkender en brugere via brugernavnet Vis brugere Det er vigtigt for administrator at have overblik for de brugere der findes i systemet, derfor viser systemet en liste over brugerne ved at gruppere dem til det semester de tilhører. Brugere der ikke hører til et semester vises i en separat liste som vises på følgende figur

39 Figur 5.13 brugere liste Dokumenter Administrator har brug for at administrere dokumenter som brugere skal udfylde og oploade. Kontrolpanelet har en dedikeret sektion til at behandler dokumenterne Vis dokumenter Det er vigtigt at have overblik for studerendes dokumenter. Systemet grupperer dokumenterne efter sager og viser dem i lister. Administrator kan vise sagens dokumenter ved at klikke på den ønskede sag i listen som vises i følgende figur Figur 5.14 dokumenters liste Ved at klikke på den ønskede sag, vil administratoren lande i sagens fil deling, som kan vises ved at trykke på det ønskede dokument Godkende dokumenter Godkendelse af dokumenter er en vigtig dele af praktikkens forløb, derfor har systemet gjort det meget nemt at godkende de udfyldte dokumenter. Systemet vil automatisk vise de udfyldte dokumenter i lister grupperet efter typen, hvor administrator kan vise dokumenter og vælger at godkende den hvis det er i orden. 38

40 5.9.3 Sager Administrator kan behandle og administrere sager samt med at holde styre på hvilke sager er der oprettet i systemet og hvad er deres tilstand i forhold til de udfyldte dokumenter og de tilknyttede brugere Vise sager Sagerne bliver grupperet efter semesteret i separate lister, hvor administratoren kan vise sagerne for et givet semester og vise sagen ved at klikke på den ønskede sag. Administrator vil automatisk falde i sagens forside og se notifikationerne fra brugerens perspektiv. Det er også muligt at tilgå de forskellige dele i sagen, så som dokumenter, meddelelser, deltager liste osv Redigere sager Det er muligt at redigere sager for at tilføje nye medlemmer af forskellige roller til sagen eller ændrer i sagens navn som vises på følgende figur 6.15: Figur 5.15 sags redigering Vise status Sagens status er baseret på hvilke dokumenter der er udfyldt og oploadet, derfor vises dokumenternes status for hver eneste sag markeret med rødt hvis det tilsvarende dokument ikke er udfyldt, med gult hvis det er udfyldt men ikke godkendt og med grønt hvis det er godkendt. Som eksampel vises følgende figur 6.16: 39

41 Figur 5.16sagens status baseret på dokumenterne De er også muligt at vise statussen på et enkelt dokument, ved at vælge hvilket dokument man ønske at vise i toppen Notifikationer Notifikationerne er baseret på bilag 8, eksamens projekts felter. Disse felter skal være udfyldt senest 3 uger efter praktikstart som er angivet under praktikophold i bilag 8. Administrator kan vise en liste over disse brugere der ikke har udfyldt eksamens projekts felter under bilag 8 6 dage før tidsfristen, dette vil give administrator muligheden for at behandle notifikationen inden de sendes. Figur 6.17 viser hvilke muligheder administrator har, det er muligt at udsætte notifikationen med antal dage, det er muligt at slette notifikationen ved at markere den sent, eller sender notifikationen med det samme. Figur 5.17 bilags 8 notifikationer Ud over det så tjekker systemet selv om der skal sendes nogle notifikationer i form af s, ved at klike på send alle. Denne side kan sættes i en job liste i Linux eller Windows, således at det gøres en gang om dagen. Jeg har eksperimenteret med at opsætte en job liste og det virkede fint. Det er vigtigt at sige, at man skal have rettigheder til at opsætte en job list i den server man ønsker at køre systemet på. Som alternativt har jeg gjort det muligt at administratoren kan selv sende de automatiske notifikationer til alle, blot ved at gå ind i siden manuelt. 40

42 6 Test Modellen er kodet samtidigt med view et, hvor testen for begge har været løbende i udviklingsforløbet. Testen består primært af funktionelle tests af hver funktion implementeret i de forskellige klasser. Disse er de vigtige test da de bekræfter om funktionen virker som forventet. Der har også været test for hele systemet, for at teste sammenspillet af de forskellige dele af det. Testen har primært været manuel test som nævnt før, og ikke så mange automatiseret tests, da manuel test er lang mere effektiv i webapplikationer. I de følgende afsnitte vil jeg komme ind på testen af systemet. 6.1 Log ind Følgende test forgår i log ind siden login.jsp Handling Forventet resultat Udførelsen Indtast gyldigt aktiveret brugernavn og adgangskode Indtast gyldigt ikke aktiveret brugernavn og adgangskode Indtast ugyldigt brugernavn eller adgangskode Log ind som alm. bruger eller vejleder. Log ind som Administrator (admin, PK eller PA) Logger ind i systemet og bliver omstillet videre Bliver på log ind siden. Fremvises en fejlmeddelelse at brugeren ikke aktiveret endnu Bliver på log ind siden. Fremvises en fejlmeddelelse at brugeren ikke findes i systemet samt link til tilmeldingssiden. Logger ind succesfuldt i systemet Logger ind succesfuldt i kontrol panelet. Udføres korrekt Udføres korrekt Udføres korrekt Udføres korrekt Udføres korrekt Log ud efter log ind. Logger ud af systemet Udføres korrekt 41

43 6.2 Dokumenter Bilagene er en meget vigtig del af systemet og det er nødvendigt at teste hver enkelt del af hver bilag og sikrer at det fungerer som designet Optagelsesdokument Følgende test forgår i regdoc.jsp Handling Forventet resultat Udførelsen Et af de obligatoriske felter er ikke udfyldt Flere af de obligatoriske felter er ikke udfyldt Udfyld kun de obligatoriske felter Udfyld alle de obligatoriske samt nogle/alle af de ikke obligatoriske felter Skriv bogstaver i telefon nr. feltet/antal point Godkend Forbliver i oprettelsesdokument siden og markerer det manglede felt med rød baggrund. Forbliver i oprettelsesdokument siden og markerer de manglede felt med rød baggrund. Gemmer data i databasen og sender brugeren til log ind siden med bemærkning af oprettelsesdokument venter på godkendelse Gemmer data i databasen og sender brugeren til log ind siden med bemærkning af oprettelsesdokument venter på godkendelse Forbliver i siden og markere felterne med rød baggrund. Markerer dokumentet som godkendt og låser den for Udføres korrekt Udføres korrekt Udføres korrekt Udføres korrekt Udføres korrekt Udføres korrekt 42

44 yderligere redigering Send til den studerende en sendes korrekt Udføres korrekt Bilag 5, 6 og 7 Da bilag 5, 6 og 7 er implementeret på samme måde og i det samme side uddoc.jsp er testen det samme, derfor undlades at vise testen for alle 3 bilagene, selvom de blev testet i virkeligheden. Handling Forventet resultat Udførelsen Opload en ikke tilladt fil (fil der er ikke er (.pdf.doc(x) osv) Opload en tilladt fil Opload en filen igen Forbliver i siden samt med at vise fejlmeddelelse at filtypen ikke er tilladt. Forbliver i siden samt med at vise linket til filen (hvor filen kan downloades) og datoen på filens oploading. Forbliver i siden samt med at overskriver den eksisterende fil. Udføres korrekt Udføres korrekt Udføres korrekt Download en oploadede fil Downloader den rigtig fil. Udføres korrekt Godkend Markerer dokumentet som godkendt og låser den for yderligere redigering Udføres korrekt 43

45 6.2.3 Bilag 8 Bilag 8 er den vigtigste, for den indeholder nogle vigtige felter der er nødvendige for praktik og eksamensprojekt forløbet. Der ligges lidt ekstra vægt på test af bilag 8 på grund af antallet og vigtigheden af felterne. Testen udføres i bilag 8 doc8.jsp Handling Forventet resultat Udførelsen Ikke udfyld de obligatoriske felter Udfyld de obligatoriske felter Udfyld de obligatoriske felter sammen med de ikke obligatoriske Indsæt forkert datoformat Indsæt bogstaver i numeriske felter Ret på eksisterende udfyldt bilag Naviger rundt i de forskellige versioner Godkend hele dokumentet Godkend sektion 1 Forbliver i siden indtil disse felter er udfyldt Gemmer data i databasen som en ny version. Gemmer data i databasen som en ny version. Forbliver i siden indtil der indsættes det rigtig datoformat Forbliver i siden indtil der indsættes det tal Gemmer data i databasen som en ny version. Viser de rigtige data der er knyttet til versionen. Markerer dokumentet som godkendt og låser den for yderligere redigering Markerer sektion 1 som godkendt og låser den for yderligere redigering Udføres korrekt Udføres korrekt Udføres korrekt Udføres korrekt Udføres korrekt Udføres korrekt Udføres korrekt Udføres korrekt Udføres korrekt 44

46 Godkend sektion 2 Godkend sektion 3 Lås sektion 3 op Lås sektion 2 op Lås sektion 1 op Markerer sektion 2 som godkendt og låser den for yderligere redigering Markerer sektion 3 som godkendt og låser den for yderligere redigering Markerer sektion 1 som ikke godkendt og oplåser den Markerer sektion 2 som ikke godkendt og oplåser den Markerer sektion 1 som ikke godkendt og oplåser den Udføres korrekt Udføres korrekt Udføres korrekt Udføres korrekt Udføres korrekt Bilag 10 Bilag 10 er den simpleste for den kræver ikke nogen tjek eller fejlfinding. Testen udføres i bilag 10 doc10.jsp Handling Forventet resultat Udførelsen Ikke udfyld alle felter Gemmer data i databasen Udføres korrekt Udfyld alle felter Gemmer data i databasen Udføres korrekt Godkend Markerer dokumentet som godkendt og låser den for yderligere redigering Udføres korrekt 45

47 6.3 Meddelelser Testen udføres i meddelelsesside messenger.jsp Handling Forventet resultat Udførelsen Starter ny tråd Opretter tråd Udføres korrekt Sender svar i en allerede eksisterende tråd Går in på meddelelsessiden Opretter svar under tråden Ser en liste over de oprettede tråd Udføres korrekt Udføres korrekt Går ind på en tråd Ser en liste over trådens svare Udføres korrekt 6.4 Database test Systemet består af mange funktioner som udfører SQL forespørgsler til at udtrække og indsætte data fra og til databasen. Disse SQL forespørgsler blev testet eksternt via en MySQL webapplikation phpmyadmin for at sikre at kommandoerne er skrevet rigtigt og at de udtrækker/indsætter de rigtige data. 46

48 7 Evaluering Projektforløbet har været spændende og udfordrende specielt igennem implementeringsfase, jeg har lært masse og fik styrkede min allerede eksisterende viden og erfaring med webudvikling. Det har været lærerigt at udvikle systemet og meget hjælpsomt at få vejledning fra mine vejledere. Møder med min vejleder som er også kravstillende fik mig til at overveje flere krav og forbedringer til systemet, hvilket er meget godt og positivt. Jeg føler at jeg har gjort god indsats og min udvikling har været på de rette spore. Selvom jeg begyndte lidt sent med at beskæftige mig fuldtid med projektet (på grund at jeg fulgte andre kurser), har jeg stadig nået mere end kravet på selve projektbeskrivelsen. Jeg har brugte mere tid på implementering end jeg skulle, hvilket gik lidt over rapportskrivning, men alt i alt synes at det har været en rigtig god oplevelse og jeg mener at hvis produktet videre udvikles vil den passer perfekt som løsning til opgaven. Jeg er positiv indstillet over for de resultater jeg har opnået og håber at det system jeg har udviklet kan bruges som et værktøj hos praktikkoordinatorer. 47

49 8 Konklusion Det har været interessant at uddybe min erfaring at designe og implementere hele systemet alene. Jeg har tit været med til at bidrage med kode (primært PHP) til OSS webapplikationer, men aldrig til at bygge et helt system på dette omfang alene. Det gik meget godt med at designe og implementere produktet der er tilpasset specielt til praktik og eksamensprojekt periode. Systemet som nu indeholder de vigtigste dele som gør det i stand til at håndtere opgaven. Det har været hjælpsomt at anvende eclipse WTP (web tool platform) og phpmyadmin, sammen med de andre værktøjer og færdigheder som jeg har lært i DTU de senste 3 år, begge gjorde det nemmere at fremskynde implementations proces. Resultatet er prototype af produktet som er omfattende og funktionelt på sin nuværende fase, produktet fungere som designet, systemet gør det nemmere at udføre praktik og eksamensprojekt forløbet for både de studerende og praktikkoordinatorerne. 48

50 9 Forbedringer Systemet på sin nuværende tilstand og kode er fleksibelt til at udvides på en stor plan. Der er både generelle forbedringer som retter sig imod hele systemet og specifikke forbedringer der vedrører enkelte dele af systemet. Det er vigtigt at sige, disse forbedringer vedrører ikke designet men det er mere som udvidelser jeg ikke kunne implementere på grund tidspres. 9.1 Generelle forbedringer Disse forbedringer kan føres på hele systemet, de giver det ekstra funktionaliteter og brugervenlighed AJAX AJAX teknologien som vi kender fra masse kendte web applikation, så som googles Gmail, Facebook og andre forum platforme (vbulletin & IPS). AJAX gør det nemmere at udfylde og navigere rundt på siden. Det er muligt at anvende AJAX til at vise advarsler, bemærkninger og andet. AJAX kan f.eks. til at kontroller bilagenes felter. Det kan gøres således at siden kontrollerer om de udfyldte felter er korrekte og varsler brugeren om fejl hvis der indsættes bogstaver i et numerisk felt. Idéen kan generaliseres således at den omfatter alle indtastningsfelter og fejlmeddelelser, hvor AJAX teknologien anvendes Apache rewrite mod Apaches rewrite mod er en teknologi der gør det muligt at omskriver URL. URL kan omskrives således at GET variablerne skjules fra URL en. Rewrite mod kan også tælles som SEO (search engine optimization), for google og andre søg-maskiner kan bedre lide statiske URL er. En eksampel på hvordan URL en kan omskrives er at omskriver følgende URL: til etc. 49

51 Som vises, så kan filens type gemmes (om det er JSP, HTM eller andet) sammen med at GET variablen topicid kan skjules eller omdøbes. Dette øger både sikkerheden og brugervenligheden da URL en bliver kortere og mere overskuelig Portal siden Det er meget anvendt at selv de lukkede systemer indeholder en portal/cms side der viser generelle oplysninger om både systemet, offentlige meddelelser og informationer som kan vises af alle. Portal siden kan f.eks. bruges til at forklar hvad siden er og hvem er den rettet mod, samt med at forklare praktikforløbet. Dette kan være hjælpsomt for de studerende på tidligere årgang til at forstå systemet og forløbet og være forberedt. Portal siden kan også indeholde How-To-Do / Knowldege-Base system som forklarer hvordan systemet kan anvendes Forum Fora princippet er meget udbredt og kendt. Idéen er at lade brugere hjælpe hinanden når de kan. Jeg finder det som en god idé at lade studerende udveksle erfaring og viden om både praktikken og eksamensprojekt. De studerende kan anvende forummet til at finde praktikplads, på samme måde kan virksomhederne også anvende forummet til at finde praktikanter Grafiske elementer Systemets udsigende kan fin pustes ved at bruge professionelle billeder. Det nuværende banner er resultatet af et hurtigt forsøg. Banneret kan naturligvis forbedres. Grafiske ikoner er meget forklarende, det gør dem hjælpsomt da bruger tit ikke læser hele fejlmeddelelsen. Grafiske ikoner er med at øge systemets brugervenlighed. I systemet har brugt farver til at markere tilstanden, f.eks. i oversigtens side vises de forskellige bilag og deres tilstand markeret med rød hvis de ikke er udfyldt endnu, med gul hvis de er udfyldt men ikke godkendt og med grøn hvis de er både udfyldt og godkendt. Disse farver kan erstattes med billeder ikoner der er nemmere at forstå budskabet af. 50

52 9.2 Specifikke forbedringer Følgende forbedringer er rettet mod de specifikke dele af systemet, det er muligt at udvide systemet således an den kan: Meddelelser Lige nu er det kun muligt at skrive meddelelser med bare tekst uden formatering. Det er en god idé at udvide det således at det er muligt at anvende farver, links og andet. Den meget populær WSISYG virker fint på alle de nye browsere. Tilføje flere oplysninger til meddelelsen, såsom datoen, nummeret på meddelelsens rækkefølge og markering på hvor vigtig meddelelsen er. Redigere i meddelelser, således at meddelelsens ejer kan redigere i de. Slette meddelelser/tråde, således at sagens ejer kan vælge at slette meddelelser/tråde Sende en generel meddelelse, da nu sendes meddelelsen til hver sag fordi sagens medlemmer kun har adgang til deres meddelelser. Det betyder at den samme meddelelse skal sendes til alle sager som vil bare fylde ekstra plads i databasen, i stedet kan der laves en generel meddelelse som er læseligt af alle sagers brugere i et specifikt semester. Notificere brugere via om nye meddelelser. Vise antal svare og visninger i en tråd. Rulle ned til den seneste meddelelse automatisk. Sammenflette flere meddelelser/tråde. Skjule meddelelser og tråde. Markere tråde som sticky 51

53 9.2.2 Brugere Slette brugere og alle de tilknyttede data, såsom dokumenter, sag og meddelelser. Tilføje profils side for brugere og give mulighed for at personalisere profilen ved at give flere informationer og evt. oploade billede. Give brugeren muligheden at ændre på sine egne informationer, såsom adgangskode og andet. Integrere brugere med CN database Sager Slette sager og alle de tilknyttede data, såsom dokumenter, bruger og meddelelser. Låse sager for yderligere handlinger, således at det er ikke muligt at skrive meddelelser eller vise/redigere dokumenterne, men i stedet vises en fejlmeddelelser der informerer sagens brugere at denne sag er låst for evigt eller evt. midlertidigt. Muligheden for at invitere andre brugere (studerende eller vejleder) til en sag. 52

54 10 Referencer [Java1] Java [Online]. Tilgængeligt: [JSP1] JavaServer Pages [Online]. Tilgængeligt: [CSS1] Cascading Style Sheets [Online]. Tilgængeligt: [HTML1] Hypertext Markup Language [Online]. Tilgængeligt: [Agile1] Agile software development [Online]. Tilgængeligt: [IM1] Information Management [Online]. Tilgængeligt: og [CMS1] Content Management System [Online]. Tilgængeligt: og [Cache1] Database caching [Online]. Tilgængeligt: [Norm1] database normalization [Online]. Tilgængeligt: [MVC1] Model view controller [Online]. Tilgængeligt: view controller [ERM1] Entity-Relationship Model [Online]. Tilgængeligt: [TOMCAT1] Apache Tomcat [Online]. Tilgængeligt: [phpmyadmin1] PHP MyAdmin [Online]. Tilgængeligt: [w3c1] The World Wide Web Consortium [Online]. Tilgængeligt: 53

55 11 Bilag 11.1 Tidsplan 54

56 11.2 Use cases diagram 55

57 11.3 Domænemodel 56

58 11.4 Klassediagram 57

59 11.5 ERM 58

60 11.6 Layout opdeling 59

61 12 Appendiks 12.1 Use cases Dette afsnit vil indeholde en mere detaljeret beskrivelse af de forskellige use cases Oprette bruger Figur 12.1 use case oprette bruger Formål Scope & level Forudsætning Succes betingelse Mislykkes betingelse Primær Aktører Trigger Use case 1 oprette brugere Oprette ny bruger Primær Brugeren (af forskellige roller) er ikke oprettet i forvejen Brugeren (af forskellige roller) oprettes Brugeren (af forskellige roller) kan ikke oprettes Ikke tilmeldte og administratorer Bruger ønsker tilmelding i systemet Beskrivelse Trin Handling 1 Ikke tilmeldte bruger eller administrator indtaster navn, brugernavn og adgangskode og , derefter trykker på opret knappen. Extensions 1a Den oprettet brugers brugernavn eller findes i systemet 60

62 Log ind Formål Scope & level Forudsætning Succes betingelse Mislykkes betingelse Primær Aktører Trigger Figur 12.2 log ind Use case 2 log ind Logge ind i systemet Primær Brugeren (af forskellige roller) er oprettet og godkendt i systemet. Alle server (tomcat og mysql) virker. Brugeren (af forskellige roller) logger ind Brugeren (af forskellige roller) kan ikke logge ind Bruger (af forskellige roller) Ønske at anvende systemet Beskrivelse Trin Handling 1 Bruger (af forskellige roller) indtaster brugernavn og adgangskode og trykker på log ind knappen. Extensions 1a Brugeren (af forskellige roller) indtaster forkerte brugernavn/password. 61

63 Udfylde Oprettelsesdokument Formål Scope & level Forudsætning Succes betingelse Mislykkes betingelse Primær Aktører Sekundære aktører Trigger Figur 12.3 Udfylder oprettelsesdokument Use case 3 Udfylder oprettelsesdokument Udfylde oprettelsesdokument Primær Den studerende skal være godkendt og logget ind Brugeren (af forskellige roller) udfylder oprettelsesdokument og logger af. Brugeren (af forskellige roller) kan ikke gemme det udfyldte oprettelsesdokument Studerende. Vejleder, PK, PA og administrator Ønske at udfylde oprettelsesdokument Beskrivelse Trin Handling 1 Studerende udfylder de obligatoriske felter i oprettelsesdokumentet og trykker på gem og send til godkendelse knappen. Extensions 1a Studerende ikke udfylder de obligatoriske felter 62

64 Udfylde bilag 8 Figur 12.4 Udfylder bilag 8 Use case 4 Udfylder bilag 8 Formål Udfylde bilag 8 Scope & level Primær Forudsætning Den studerende skal være godkendt og logget ind Succes betingelse Brugeren (af forskellige roller) udfylder bilag 8 Mislykkes betingelse Brugeren (af forskellige roller) kan ikke gemme det udfyldte bilag 8 Primær Aktører Sekundære aktører Studerende. Vejleder, PK, PA og administrator Trigger Ønske at udfylde bilag 8 Beskrivelse Trin Handling 1 Studerende udfylder de obligatoriske felter i bilag 8 og trykker på gem og send til godkendelse knappen. Extensions 1a Studerende ikke udfylder de obligatoriske felter 63

65 Udfylde bilag 10 Figur 12.5 Udfylder bilag 10 Use case 5 Udfylder bilag 10 Formål Udfylde bilag 10 Scope & level Primær Forudsætning Den studerende skal være godkendt og logget ind Succes betingelse Brugeren (af forskellige roller) udfylder bilag 10 Mislykkes betingelse Primær Aktører Sekundære aktører Studerende. Vejleder, PK, PA og administrator Trigger Ønske at udfylde bilag 10 Beskrivelse Trin Handling 1 Studerende udfylder de ønskede felter i bilag 10 64

66 Oploade bilag 5, 6 eller 7 Figur 12.6 opload bilag 5, 6 eller 7 Use case 6 Oploade bilag 5, 6 eller 7 Formål Oploade bilag 5, 6 eller 7 Scope & level Primær Forudsætning Den studerende skal være godkendt og logget ind Succes betingelse Brugeren (af forskellige roller) oploade filen til serveren Mislykkes betingelse Primær Aktører Sekundære aktører Studerende. Vejleder, PK, PA og administrator Trigger Ønske at oploade bilag 5, 6 eller 7 Beskrivelse Trin Handling 1 Studerende oploader filen Extensions 1a Studerende oploader en ikke tilladt fil. 65

67 Oprette tråd / meddelelse Formål Scope & level Forudsætning Succes betingelse Mislykkes betingelse Primær Aktører Trigger Figur 12.7 opretter tråd / meddelelse Use case 7 Oprette tråd / meddelelse Oprette tråd / meddelelse Primær Den studerende skal være godkendt og logget ind Brugeren (af forskellige roller) tilføjer tråd eller meddelelse i sagen Studerende, vejleder, PK, PA og administrator Ønske at tilføje en meddelelse under sagen Beskrivelse Trin Handling 1 Studerende opretter en meddelelse 66

68 12.2 Administrations manual Følgende manual kræver at man er logget ind i systemets kontrolpanel Brugere Brugere kontrolpanel kan nås ved at klikke på brugere i den vandrette menu under banneret Opret brugere Klike på oprette under brugere Udfyld felterne Klik tilmeld Figur 12.8 oprette bruger Rediger brugere Klik på redigere Udfyld felter for at søge efter brugeren Tryk på find Hvis brugeren findes vil du lande i redigeringsside Redigere i brugerens felter Tryk gem 67

69 Figur 12.9 redigere bruger Godkend brugere Klik på godkende Klik godkend knappen under den ønskede bruger Figur godkende brugere 68

70 Vis brugere Klik på vis brugere Klik på det ønskede semester Klik på brugeren for at redigere Figur vise brugere Dokumenter Dokumenters kontrolpanel kan nås ved at klikke på dokumentere i den vandrette menu under banneret Vis dokumenter Klik på vis Klik på det ønskede semester Tryk på den ønskede bruger Figur vis dokumenter 69

71 Godkend dokumenter Klike på godkende Klik på dokument type Klik på studie nr. for at vise dokumentet Klik godkend for at godkende Figur godkende dokumenter Figur godkende bilag 5 70

72 Sager Sagernes kontrolpanel kan nås ved at klikke på sager i den vandrette menu under banneret Vis sager Klik på vis Klik på det ønskede semester Klik på sagens navn for at redigere, eller klik på pilen for at vise sagens forside Figur vise sager Rediger sager Klik rediger Skriv sagens navn Klik find Redigere i felterne Klik gem 71

73 Figur finde en sag Figur redigere en sag Vis status Klik på vis status Klik på det ønskede semester Klik på det ønskede dokument 72

74 Figur vise sagens status Notifikationer Notifikationers kontrolpanel kan nås ved at klikke på notifikationer i den vandrette menu under banneret Vis notifikationer Klik på vis Klik på udsæt hvis du vil udsætte notifikationen, huske at skrive antal dage i feltet der står ved siden af Klik på slet hvis du vil markere notifikationen som sendt Klik på send hvis du vil sende notifikationen nu Figur vise notifikationer 73