Administrator

Transkript

1 Indholdsfortegnelse Synopsis Abstract Forord Læsevejledning Formål Gruppens mål Virksomhedens mål Virksomhedsbeskrivelse Mission Vision Problemformulering Nuværende situation Ønsket situation Standardsystemer Definition af et CMS-system Procesbeskrivelse Arbejdsdelingen i projektgruppen Overvejelser vedr. systemudviklingsmetode XP Scrum Systemudviklingsmetode Unified process (UP) Identifikation af behov/etabler krav Analyse og design fasen Opbygningen af interaktiv version Evaluer design Identifikation af Use Case Prioritering af Use Case Rollebeskrivelse af brugertyper og målgruppe

2 Administrator Super bruger Ansøger Vikar Web bruger Use case diagram Primære aktører Supporting aktører Offstage aktører Kravspecifikation Krav til funktionalitet Vikar og Ansøger Super bruger Administratoren Krav til brugervenlighed Krav til teknologiske komponenter Krav til teknologisk platform Krav til sikkerhed Krav til systemdokumentation og anden dokumentation Forandringsanalyse Forskel på hvor omfattende systemet er Modstand mod forandring Delkonklusion Brugervenlighed Definition af brugervenlighed Hvad lægger brugerne generelt vægt på ved en hjemmeside Web sidens struktur og elementer Ensartede elementer og layout Navigation Navigations strukturer Links Brugerens browser Del konklusion Arkitektur Domænemodel

3 Mønstre Lag-deling Singleton (GOF) Facade controller Interface Indkapsling Data transfer objects Server Session State Client Session State Optimistic Concurrency Inheritance Model View Controller Page Controller Template View Delkonklusion Stored Procedures Transaktioner Atomare transaktioner Konsistens Membership Generelt Trin Trin Trin Delkonklussion CMS- Content Management System Steder vi har brugt CMS Anvendelse af CMS Redigering af indhold Anvendelse af Interne Links FCKEditor Regler for brug af FCKEditoren Delkonklusion

4 Ajax Definition af Ajax Hvorfor gør vi brug af Ajax? Hvor vi gør brug af Ajax Hvordan gør vi brug af Ajax Flere Sprog Ressourcefiler Delkonklusion TEST Funktionalitets test Samtidighedstest Brugervenligheds test Fremgangsmåde Unit Test Andre test Cookies Transaktioner Del konklusion Udgivelse til server Konklusion Kilder Bøger Internet

5 Synopsis Denne rapport omhandler det arbejde der har været i forbindelse med at udarbejde det afsluttende hovedopgaveforløb på datamatikeruddannelsen. Den viser de faser som projektgruppen har gennemgået, samt hvilke problemstillinger der har været for at kunne lave et system der kan tjene som en inspirationskilde til LabVikar. LabVikar mangler et system der kan håndtere ansøgere, vikarer og kunder. Vores system er lavet som en webapplikation så det kan tilgås af adskillige ansatte såvel som andre web brugere. Abstract This report details the work that has been done for the final project in the study of Computer science. It shows the phases which the project group has gone through, and the issues that have arisen throughout the making of a computer system that shall serve as a source of inspiration to LabVikar. LabVikar needs a system that can manage applicants, temporary workers and customers. Our system has been made as a web application that can serve several employees as well as other web users. 5

6 Forord Denne rapport er udarbejdet i forbindelse med det afsluttende hovedopgaveforløb på datamatikeruddannelsen. Produktet er udviklet til vores opgavestiller Rikke Merton som er ejer af LabVikar. Denne rapport henvender sig hovedsageligt til eksaminator og censor. LabVikar får også en kopi heraf. Hovedopgaveforløbet har været et spændende forløb, hvor vi har haft mulighed for at beskæftige os med problemstillinger af større sværhedsgrad end vi tidligere har haft mulighed for. Vi er stødt på flere problemer i forbindelse med udarbejdelsen af vores produkt, som vi på bedste vis har forsøgt at løse. Vi har i forbindelse med dette projekt haft Peter Kjærsgaard som vejleder. Vi vil gerne rette en stor tak til Peter, samt en tak til Rikke Merton for deres hjælp med denne yderst spændende og udfordrende opgave. Læsevejledning Denne rapport er skrevet i kronologisk rækkefølge. Der er steder i rapporten, hvor man skal kende til noget af det som er skrevet tidligere i rapporten, for at få det fulde udbytte af kapitlet. Rapporten bør derfor læses fra start til slut. Rapporten er opdelt i 11 afsnit som vi her kort opridser. En mere detaljeret oversigt findes i indholdsfortegnelsen. 1. Indledning 2. Foranalyse 3. Brugervenlighed 4. Arkitektur 5. Membership 6. CMS- Content Management System 7. Transaktioner 8. Ajax 9. TEST 10. Udgivelse til server 11. Konklusion Kapitel 1 3 omhandler analysen, hvor kapitel 4 11 omhandler udarbejdelsen af produktet. Der er flere steder i rapporten hvor vi løbende har kildehenvisninger. I teksten vil der stå små tal som angiver hvilken note, som den tilhører og selve kilden vil så stå i fodnoten. Da der visse steder i rapporten kan være links til hjemmesider med lange navne, som er problematiske at få indtastet i en browser kan det anbefales at bruge den elektroniske rapport som medfølger på cd-rom. Til dokumentet følger kilder i en separat mappe. Derudover følger en bruger guide, som hovedsagelig henvender sig til Labvikars personale og IT-ansarlig 6

7 Formål Det overordnede formål med hovedopgaven er udarbejdelsen af en rapport, der kommer til at danne grundlag for den afsluttende eksamen for datamatikeruddannelsen. Denne rapport skal vise gruppemedlemmernes færdigheder, som de har opnået under hele datamatikeruddannelsen, ud fra en konkret og sammenhængende problemstilling. Herudover skal projektgruppen også vise, at den kan styre et projekt i samarbejde med den udvalgte opgavestiller. Gruppens mål Det er gruppens mål at få en dybere forståelse af nogle af de teknologier som ligger bag udarbejdelsen af en større web-applikation end vi har været vant til tidligere i vores uddannelse. Her kan bl.a. nævnes. ASP.NET Ajax MSSQL Stored procedures I den senere tid er virksomheder i større grad begyndt at søge efter personer som behersker disse kvalifikationer. Vi mener derfor at det vil hjælpe os med at komme ud på arbejdsmarkedet. Efter som at projektet forløber over en længere periode, ønsker gruppen at få afprøvet nogle af de projekt-styringsværktøjer som vi har lært i gennem vores uddannelse. Heriblandt kan nævnes. XP SCRUM UP Derudover ønsker vi at blive bedre at tidsestimere i et projekt som kommer til at forløbe over en længere periode, da dette er et vigtig egenskab som vi kan gøre brug af i vores fremtid i erhverslivet. Virksomhedens mål Rikke Merton har fra projektets start udtalt et stort ønske om, at få et produkt, der bl.a. kunne bidrage med følgende: En ny og flot hjemmeside Effektivisering af arbejdsgang Elektronisk håndtering af informationer Forbedret forhold til virksomhedens interessenter 7

8 Virksomhedsbeskrivelse LabVikar er Danmarks første specifikke vikarbureau for hele laboratorieverdenen, og blev stiftet den 1. juni Indehaver Rikke Merton er selv uddannet laborant og har arbejdet som bl.a. ledende laborant og laboratorietekniker indenfor biotek. Konceptet er at man, fra en hvilket som helst type laboratorium i Danmark, kan ringe til LabVikar hvis man har brug for en ekstra lab. LabVikar rummer over 20 laboratorierelaterede faggrupper, der udbyder deres arbejdskraft til både korterevarende og længerevarende vikariater, samt til fastansættelse. LabVikar har for nylig ansat 2 fuldtidsmedarbejdere, som er med til at administrere vikarer og kunder. Mission Vision LabVikar vil igennem en personlig og faglig udvælgelse levere den bedste og mest fleksible medarbejderløsning til virksomheder med mangel på arbejdskraft. LabVikar vil tilstræbe sig at administrere den mest alsidige kandidatbank, samt yde en målrettet indsats for at få så mange kandidater i vikariater og faste stillinger som muligt. LabVikar vil tilbyde de mest kompetente kandidater til markedets laveste priser. LabVikars kandidater skal være engagerede og efterlade et absolut positivt indtryk ved den virksomhed de gør tjeneste i. LabVikar skal løbende udvikles til at honorere alle kundekrav, og samtidig give kandidater de bedst mulige arbejds- og lønmæssige betingelser. Målrettet og differentieret markedsføringsindsats overfor kunder og vikarer er blandt LabVikars nøgleord. LabVikar skal opnå præference hos deres kunder, så der kan skabes langvarige relationer mellem LabVikar og kunder. I løbet af få år skal LabVikar være markedsleder inden for samtlige laboratoriespecifikke områder i og udenfor Danmark. 1 Problemformulering Nuværende situation Rikke startede sit landsdækkende vikarbureau for ca. 1 år siden med ca. 30 vikarer. I løbet af 1 år har hun fået over 700 vikarer. I og med at firmaet er vokset har det administrative arbejde taget overhånd. En ny vikar bliver registreret mindst 3 steder, på papir, i et Word dokument samt i Outlooks adressekartotek. Dette 1 8

9 giver ofte problemer når vikaren afmelder sig fra LabVikar så skal man huske at slette vedkommende alle 3 steder. Dette system medfører ofte fejl, hvor man kommer til at slette den forkerte i Outlooks adressekartoteket eller glemmer at slette en oplysning et eller anden sted. Når en kunde beder om en vikar med bestemte kvalifikationer, skal Rikke Merton, eller en af de ansatte, læse Word dokumentet igennem for at se om LabVikar har en vikar med de specifikke kvalifikationer. Rikke har selv lavet en hjemmeside i FrontPage hvor man kan finde diverse oplysninger om virksomheden. Ønsket situation Opgavestiller Rikke Merton ønsker at alle informationer om kunder, kontakter, vikarer og ansøgere bliver samlet ét sted elektronisk, i en tilgængelig og overskuelig form. For at lette det administrative arbejde, med nye vikarer, ønskes at en potentiel vikar kan ansøge om at blive optaget via en hjemmeside og derigennem oprette sit eget CV, samt tilføje personlige oplysninger mm. Herefter skal ansøgeren tildeles et brugernavn og password, så vedkommende kan få adgang til systemet og ændre sine oplysninger. Det skal være muligt for ansatte at administrere kunder, kontakter, vikarer og ansøgere. Ansatte skal have mulighed for at administrere distributionslister som indeholder oplysninger om kunder, kontakter, vikarer og ansøgere, som skal have s tilsendt i forskellige situationer. F.eks. Nyhedsbrev, beskeder til kunder om nye vikarer indenfor deres område, eller beskeder til vikarer om nye job opslag mm. Det skal via systemet være muligt, at åbne for den klient, som er sat til default på den ansattes computer. Modtager feltet i en skal automatisk være udfyldt, baseret på valg af modtagere foretaget i vores system. Det skal her være muligt at vælge mellem samtlige kunder, kontakter, vikarer, ansøgere og distributionslister, samt enhver tænkelig kombination heraf. Naturligvis ønsker LabVikar en hjemmeside der har et mere professionelt udseende end den nuværende. Det skal også fremover være muligt for de ansatte at ændre indholdet af hjemmesiden, som fx nyheder, job opslag mm. 9

10 Standardsystemer Vi fandt på Internettet et andet vikar bureau ( hvor man ud fra deres web side kunne tilmelde sig som vikar eller kunde. Vi kontaktede firmaet for at høre nærmere om deres web løsning og andre systemer de gjorde brug af. I bilag 2 side 9, kan man se interviewet med System-Vikar. Rikke Indelund fra System-Vikar gav os oplysninger om deres AXP standard system, som er lavet af firmaet Consendo. De havde også købt nogle ekstra moduler og er ved at få udviklet et lønsystem. Consendo er et firma der har specialiseret sig i standardløsninger til vikar-, konsulent- og rekrutterings virksomheder. Standardløsningen indeholder bl.a. følgende funktionalitet: Lade nye vikarer indtaste CV direkte over Internettet Udsende kampagne breve til udvalgte vikarer og kunder med ét tryk Udsende bekræftelser og beskeder på Finde de rigtige vikarer hurtigt Have styr på hvilke vikarer der er ledige Derudover tilbydes ekstra moduler og skræddersyede systemer som fx lønsystem. Vi kontaktede firmaet for af få yderligere oplysninger om priser mm. Interviewet kan ses i bilag 3 side 9. Ud fra samtalen og de informationer vi fandt på Consendo s web side ( mener vi at deres standardsystem fuldt ud kan dække LabVikars behov. Firmaet tilbyder også at domæne navnet kan hostes på deres egen server. Der foretages dagligt backup af deres server. Derudover sikres data vha. replikation, hvor de har 2 fysisk adskilte servere, som holdes synkrone. Dvs. hvis den ene server går ned pga. strømsvigt, brand mm. vil hjemmesiden stadig køre og virksomheder, som fx LabVikar, vil ikke blive påvirket heraf. Pga. den gode sikkerhed er det nærliggende at LabVikar også skulle vælge at købe server plads hos Consendo. Derudover har LabVikar s personale og Rikke Merton et begrænset IT kendskab. Hvis der skulle opstå problemer med systemet, hjemmesiden eller serveren, vil Rikke eller personalet vide nøjagtigt hvem de skal henvende sig til. Consendos pris for et system til LabVikar vil være ca kr. Vi har også kigget på andre standardløsninger, som kunne være interessante for LabVikar f.eks. Akazell ( se interview bilag 4 side 11). Væsentlige forskelle var, at Akazell ikke indeholdt en løsning, hvor LabVikars personale kunne ændre tekst og design af den del af hjemmesiden, som er offentlig tilgængelig. Akazell havde dog en standardløsning, hvor vikarer og kunder selv kunne tilmelde sig 10

11 via hjemmesiden. Derudover kunne vi via demoer og screenshots se, at deres løsning hovedsagligt var baseret på administration af kunder, hvorimod Consendo s løsning var specialiseret indenfor vikar og rekrutterings branchen. Efter nogle test af de forskellige demoer og samtaler, har vi vurderet at Consendo s standardløsning var den mest funktionelle og ville dække alle LabVikars behov. Den virkede mest sikker, mest fair i prisen og gav en god service. Definition af et CMS-system CMS eller Content Management System er et stykke software til organisering af dokumenter og andet information og hvorigennem enkeltpersoner eller grupper kan håndtere en mængde elektronisk indhold, f.eks. dokumenter, filer og billeder. Et CMS system består af en række komponenter til styring af f.eks. roller, rettigheder, indholdsskabeloner og arbejdsgange, der kan tilpasses efter behov. Et CMS kan udvikles som et standardsystem eller fremstilles specielt til konkrete behov. Sitecore og Catalyst CMS er standardsystemer, hvor man bl.a. kan ændre indholdet på en hjemmeside, sætte billeder ind eller oprette nye sider uden at have specialviden. En speciel form for CMS er Web Content Management (WCM), som fokuserer på online indhold på en fælles hjemmeside på internettet eller et intranet. Fordelen ved WCM er, at man kan redigere indholdet af en hjemmeside øjeblikkelig fra hvilken som helst computer med net adgang. Det eneste der skal bruges er en almindelig webbrowser som Internet Explorer, Mozilla, Firefox eller Opera. Vha. WCM kan brugere rediger indholdet i en hjemmeside uden at have programmeringserfaring

12 Procesbeskrivelse I bilag 1 side 4, kan man se projektetableringen, som vi lavede i starten af projektforløbet. Arbejdsdelingen i projektgruppen Fra starten af projektet har vi forsøgt at udnytte de fordele der er ved at arbejde i en gruppe. Det er kommet til udtryk ved at ide-generering, struktur, arkitektur, og andre fundamentale beslutninger, blev udarbejdet i fællesskab. Derudover har vi hele tiden søgt hjælp og vejledning hos de øvrige gruppemedlemmer. Vores fælles mål har fra starten været, at gruppemedlemmernes stærke sider og kompetencer blev udnyttet og samtidig at projektets mål blev opfyldt. Vi har udnyttet hinandens kompetencer ved at uddelegere arbejdet, bl.a. i programmeringsdelen. Nogle programmeringsområder, løsninger og problemer blev udarbejdet i fællesskab, mens andre opgaver blev uddelegeret til 1 eller 2 gruppemedlemmer, som blev ansvarlige for udarbejdelsen af en løsning. Det er vigtigt at fastslå, at selvom projektgruppen har valgt at uddelegere noget af arbejdet, har alle gruppemedlemmer gennemlæst hele dokumentationen og været med til at udarbejdelsen af den. Overvejelser vedr. systemudviklingsmetode Brugerindflydelse Efter vores første møde med opgavestiller Rikke Merton, vurderede vi nogle forskellige udviklingsmetoder, bl.a. XP, Scrum og UP (Unified Process ifølge Larman). Vores møde med Rikke Merton og slutbrugerne, som repræsenterer de ansatte i LabVikar, havde stor indflydelse på vores valg af udviklingsmetode. Vi fandt bl.a. hurtigt ud af at Rikke Merton og slutbrugerne havde et begrænset IT kendskab og at de umiddelbart ikke havde en klar ide eller forestilling om, hvad de havde brug for og hvilke muligheder der var. Denne begrænsede viden gjorde, at vi umiddelbart blev nødt til at optræde som konsulenter. Først og fremmest prøvede vi at få indsigt i LabVikars nuværende arbejdsgange og finde frem til, hvad der gav problemer og derefter komme med løsningsforslag. 12

13 XP For at kunne udføre et komplet XP projekt kræves der en tæt kontakt med kunden. Hermed sikrer man løbene, at produktet lever op til kundens forventninger. XP ligger op til mange delleverancer gennem projektforløbet, som så skal vurderes af kunden. Vi har i høj grad fuldt dette princip igennem projektets forløb. XP er kendetegnet ved forskellige principper, fx par programmering for at sikre en fælles forståelse, læring og sikring af projektet. XP appellerer også til, at man løbende kan ændre i kravspecifikationen mm. for at tilpasse de behov kunden har og for at få det bedst mulige produkt til kunden. Fra starten af projektforløbet mente vi, at par programmering kunne bruges på nogle områder. Netop de områder vi havde begrænset kendskab til og områder som havde en central rolle i programmet og som var en forudsætning for et vellykket projekt. Vi har gjort brug af par programmering i mange tilfælde og ved store dele af programmet. Parrene blev dannet på baggrund af foregående kendskab til opgaverne og for at sikre fælles indlæring, forståelse og hurtigere løsning af problemerne. I XP er prioritering af krav et vigtigt element og dette er kundens opgave. I løbet af projektet prøvede vi, at få så mange tilbagemeldinger fra slutbrugere og opgavestiler, som overhovedet muligt. I nogle tilfælde prioriterede opgavestiller de forskellige krav. Fx mente opgavestiller at distributionslister havde højere prioritet end kontrakter mellem kunder og vikar. XP har elementer, som vi har gjort brug af i projektforløbet. Dog kunne vi fra starten se, at vi ikke kunne bruge en rendyrket XP udviklingsmetode. Ved XP skal opgavestiller bl.a. lave User Stories, hvor vedkommende skriver få linjer om hvad produktet skal kunne. Da opgavestiller ikke havde mange idéer om, hvilke muligheder og behov et IT-system kunne dække, måtte vi i gruppen komme med nogle forskellige forslag til, hvad der kunne lette de daglige arbejdsgange. I starten af projektet besluttede vi også at vi individuelt skulle have mulighed for at sætte os ind i nogle emner og programmere efter arbejdstiden. Det medførte, at vi ikke kunne køre 100 % par programmering. Scrum Scrum er også kendetegnet ved en tæt kontakt med kunden og at kunden er en del af udviklingsgruppen. Derudover lægges der meget vægt på gennemsigtighed mellem gruppens medlemmer, så alle gruppemedlemmer ved, hvem der er ansvarlig for hvilken del af projektet. Der holdes også daglige korte møder, hvor følgende bliver taget op med alle gruppemedlemmer: 1) Hvor langt man er nået siden i går? 2) Hvad skal laves til i morgen? 13

14 3) Er der nogen risici der kan have betydning for at nå dit mål? 3. Da vi fra starten af projektperioden blev enige om, at gruppens medlemmer kunne arbejde individuelt og udover arbejdstiden, anså vi gennemsigtighed og regulære møder/gennemgang af det der blev lavet, for nødvendigt for, at der kunne fastholdes en fælles forståelse, indlæring og sikring af projektet. Gruppens medlemmer blev enige om, at såfremt der blev lavet noget udover det aftalte i løbet af dagen, skulle det fremlægges overfor de øvrige gruppe medlemmer. I løbet af projektforløbet uddelegerede vi arbejdet og dermed også ansvaret til gruppens medlemmer. I og med at vi vidste hvem der havde ansvaret for hvilken del, holdt vi hinanden forpligtet til at arbejdet bliv udført. I forhold til vores projekt, hvor kunden ikke altid havde en klar ide om hvad der var behov for og hvad der ønskedes, mente vi at det var vigtigt at være fleksible og ændre kravene til systemet løbene i projektforløbet. I Scrum går man ind for at kunden ikke kan ændre kravene for den pågældende sprint, når først den er påbegyndt 4. Vi blev enige om at vi gerne vil være meget fleksible overfor kunden. Derfor vurderede vi fra projektstarten, at vi ikke kunne køre en rendyrket Scrum. Systemudviklingsmetode Unified process (UP) Da system udviklingen krævede meget interaktion med slutbrugerne og opgavestiller, var det naturligt at anvende en iterativ udviklingsmetode. Et af de mest centrale begreber i UP er den iterative struktur 5. I en iterativ udviklingsmetode splittes projektet op i en række af mindre tidsintervaller (iterationer), der hver især er en slags miniprojekt, der skal ende med et testet, integreret og eksekverbart system. Hvilket arbejde, der skal udføres i hvilken iteration, blev fastsat efter en prioritering, hvor risikoelementer og største værdi for kunden blev behandlet først, derefter tunge centrale systemkomponenter og til sidst det lette arbejde. Vi byggede vores eget projekt op efter den iterative udviklingsmetode, og havde således i slutningen af hver iteration en eksekverbar kodestruktur. Efter den første iteration bestod koden af et par klasser, der kunne skabe forbindelse til en database, samt den tilhørende GUI Side 40 5 Larman fremhæver faktisk at iterativ udvikling er den vigtigste ting indenfor UP. Larman, Side 14 14

15 De dele af systemet, der er relativt lette at udarbejde, skal man ifølge Larman udskyde til projektets sidste fase. Vi prioriterede alt det lette og det der havde mindst værdi for kunden til sidst, fx håndtering af kunder, kontrakter mm. Vores fremgangsmåde består af 5 punkter ( figur 1). Efter hver iteration evaluerede vi designet vha. brugervenlighedstest og funktionalitets test. Hvis opgavestiller eller slutbrugere ønskede ændringer eller hvis der var fejl og mangler, tog vi et tilbageblik i de foregående faser og ændrede det ønskede. Udgangspunkt Identificer behov Etabler krav Analyse Generer design Evaluer design Byg interaktiv version (Programering) Resultat: Endelig produkt Figur 1 Identifikation af behov/etabler krav Vi lavede nogle interviews med opgavestiller og slutbrugere, beskrev de målgrupper der benytter sig af systemet og fandt ud af hvilke krav og Use Cases der var til systemet. Krav der blev overvejet var funktionelle krav og brugervenlighedskrav mm. Analyse og design fasen Her blev der lavet UML-diagrammer, skitser og udkast til hvordan systemet skulle se ud og reagere når det anvendes. Arkitekturmæssige overvejelser blev også nævnt her, fx om vi skulle bruge interfaces eller ej, hvilken database vi skulle bruge mm. 15

16 Opbygningen af interaktiv version En top down softwareudviklingsmetode blev brugt, dvs. vi startede med at lave en grænseflade og derefter funktioner der blev implementeret i grænsefladen 6. Alternativet er en Bottom up udviklingsmetode, hvor man starter med at lave funktioner og derefter grænseflade. Grunden til at vi valgte en top down udviklingsmetode var, for at sikre at vi havde fat i de rigtige ting i forhold til hvad kunden og slutbrugerne ønskede. Vi mente denne form for udvikling var mest hensigtsmæssig i forhold til kundens og slutbrugernes begrænsede IT kendskab og viden om behov og ønsker. Det var meget mere nemt og overskueligt for dem, at forholde sig til grænseflader i sted for diagrammer, funktioner, kode mm. Vi mente at vi på den måde hurtigere, i løbet af projektet, kunne få feedback fra kunden og nemmere og hurtigere kunne ændre ting, da der ikke var skrevet særlig meget kode. Derudover sikrede vi også, at designet bliver centreret omkring kundens ønsker. Pga. top down udviklingsmetode blev grænsefladerne afgørende for, hvordan funktionerne så ud i det videre forløb. Man kan også sige at vi lavede prototyper: low fidelity high fidelity, dvs. fra simple til teknisk avanceret prototyper. Eksempel på fremgangsmåden kan ses af billederne nedenfor (Forstørret udgave ses i bilag 11 side 37): SuperUsers/VikarInfo.aspx OffentligWebsite/BlivVikarTrin3.aspx Vikarer/RedigerØvrigeOplysninger.aspx SuperUsers/VikarInfo.aspx ØvrigeOplysninger 1 * Kursus -Navn -Beskrivelse -Årstal -Varighed +ToString() +VikarNr +GeografiskØnske +Disponibel +Kursusliste +Kørekortsliste +Sprogkundskaber +ToString() +FromString() 1 * Sprogkundskab -Navn -Tale -Læse -Skrive +ToString() 1 * Kørekort -Navn * Kursus -Navn -Beskrivelse -Årstal -Varighed +ToString() 1 ØvrigeOplysninger +VikarNr +GeografiskØnske +Disponibel +Kursusliste +Kørekortsliste +Sprogkundskaber +ToString() +FromString() 1 * Sprogkundskab -Navn -Tale -Læse -Skrive +ToString() 1 * Kørekort -Navn

17 Evaluer design Bestod af funktionstest ( bilag 20 side 55) for at se om programmet opfyldte kravspecifikation. Derudover bestod den også af fejlretning. Og der blev lavet en tænke højt test med slutbrugerne, for at sikre kvaliteten af brugervenligheden ( bilag 21 side 69). Ved afslutning af evaluering blev der udgivet til server. Identifikation af Use Case Vi har udarbejdet kravspecifikationen løbene ved hjælp af Use Cases. Opgavestiller og slutbrugere blevet interviewet omkring deres arbejdsprocesser, for at sætte os i stand til at se hvad firmaets arbejdsgange gik ud på og hvordan firmaets ansatte skabte værdi. Ud fra de forskellige interviews har vi skabt Use Cases, som er gennemgange af de handlinger brugere skal udføre for at opfylde deres målsætninger indenfor forskellige scenarier. Et eksempel på en Use Case var, at telefonen ringede og en vikar ønskede at tilmelde sig hos LabVikar. Målet med Use Cases er at skabe en systematisk beskrivelse af, hvordan den tænkte software skal integreres med brugerne, men også at afdække hvilke handlinger brugeren overordnet skal gennemføre med softwaren, uden nogen overvejelser med interfaces, database, kodestruktur mm. Derudover har vi også brugt Use Cases som en ramme for kommunikationen mellem slutbrugerne og os. Vores første interviews hos LabVikar blev brugt til at finde ud af, hvilken type system der overordnet var behov for i virksomheden. De senere Use Cases bar præg af, at vi allerede havde lagt os fast på, hvilken type system der skulle udarbejdes, nemlig et web baseret system. Vha. Use Cases tog vi udgangspunkt i firmaets eksisterende arbejdsgange, men på samme tid ændrede vi disse en smule. Ved at skabe et softwareprodukt var vi nød til at ændre og systematisere nogle af LabVikars arbejdsgange. Resultatet er, at den enkelte medarbejder, ved hjælp af systemet er i stand til, at håndtere forskellige situationer hurtigere og nemmere end før. Fx er vikar oplysninger gemt ét sted og skal kun slettes ét sted, hvis opsigelse ønskes. Derudover kan vikarerne selv indtaste deres oplysninger og ændre dem vha. hjemmesiden, hvor det førhen skulle gøres af medarbejderne. Behovene og yderligere ønsker er vokset i applikationens levetid, hvilket i procesbeskrivelsen har betydet at vi løbene har tilrettet og prioriteret de forskellige Use Cases. En brief beskrivelse af de forskellige Use Cases kan ses i bilag 5 side

18 Prioritering af Use Case Vi prioriterer use cases efter hvad vi og opgavestiller Rikke Merton, vurderer som størst potentiel værditilvækst for LabVikar. Vi har først og fremmest vurderet at administration af Ansøgere, er en kernefunktion. Det kan danne grundlag for vækst i antallet af vikarer, hvis det kan blive nemmere og hurtigere for en potentiel vikar, at oprette en ansøgning via en hjemmeside. På nuværende tidspunkt er det meget tidskrævende for LabVikars personale og ansøgerne selv. En stigning i antallet af ansøgere skal medføre et stigende antal godkendte ansøgere (vikarer). Hvis kunderne får flere vikarer at vælge imellem, vil det forhåbentlig resultere i flere kontrakter, og dermed øge indtjeningsgrundlaget for LabVikar. En anden grund til at vi har prioriteret Ansøgere højt, er at det vil aflaste LabVikars personale med den daglige administration af nye ansøgere via telefon, og dokumentmæssigt. For at aflaste telefon samtaler og s yderligere, skal ansøgeren selv have mulighed for at logge sig ind på hjemmesiden og redigere sine oplysninger. For at LabVikars personale kan bevare et overblik over alle deres vikarer, skal der være detaljerede oplysninger om hver eneste vikar, samt søgefunktioner for at finde bestemte vikarer mm. Sekundært har vi i samarbejde med opgavestiller vurderet, at et CMS system er nødvendigt for LabVikar. LabVikar ønsker en helt ny hjemmeside, som stadig rummer de nuværende muligheder der er for at rette i sidernes indhold. Et CMS system er med til at sikre, at LabVikars personale kan rette indholdet og layouten af siderne, uden den store tekniske forståelse. Dermed sikres også at hjemmesiden kan holdes opdateret med nyheder mm. Dette er med til at give brugerne et indtryk af, at der sker noget i virksomheden. Vi har også prioriteret distributionslister (nyhedslister) højt. LabVikar har på nuværende tidspunkt store problemer med, at holde deres distributionslister opdaterede og synkroniserede på alle 3 computere. Kommunikationen med kunder og vikarer prioriterer LabVikar meget højt, hvilket også har haft stor betydning for den vedvarende vækst af antallet af vikarer og kunder. LabVikar ønsker at vikarer selv kan tilmelde sig forskellige kategorier af nyheder, så LabVikar slipper for alt arbejdet med at tilføje vikarerne til bestemte distributionslister. I løbet af projektet overvejede vi at lave kontrakter, hvor man kunne se hvilken vikar der var reserveret, til en given kunde, i en given periode. Vi konsulterede opgavestiller, Rikke Merton, med et udkast hertil, men opgavestiller mente ikke der var behov for dette. LabVikar har nemlig specialiseret sig indenfor laborant udannede, hvilket ifølge Rikke Merton er noget helt andet end almindelige vikar bureauer. De kunder der kontakter LabVikar har indtil nu ikke ønsket laboranter i mindre end 4 måneder, dvs. der indtil nu ikke har været tilfælde, hvor der kun ønskes en vikar i 2-3 dage. Ifølge Rikke 18

19 Merton vil det være utænkeligt, at kunder i fremtiden ønsker vikarer mindre end 4 måneder, fordi uanset hvilken kunde det drejer sig om, og vikarens kvalifikationer, vil der være en del indlærings tid og opgaverne hos virksomheden er tidkrævende. Dette betyder at det på nuværende tidspunkt ikke har været et problem for LabVikar eller personalet, at holde styr på de vikarer der er udsendt til de forskellige kunder. Opgavestiller mente at et felt, hvor man kunne indtaste om vikaren på nuværende tidspunkt var optaget, ville dække behovet. Opgavestiller mente at der var andre ting der var større behov for(bl.a. distributionslister), hvilket gjorde at vi prioriterede kontrakter blandt noget af det sidste. I Bilag 6 side 24 kan man se den samlede prioritering af alle use cases. Følgende use cases er listet i prioriteret rækkefølge: 1. iteration (Ansøgninger/vikar) 2. iteration (Vikar) Iterationen indeholder følgende use cases: Iterationen indeholder følgende use cases: Tilføj ansøger Rediger vikar Hent alle ansøgere Slet vikar Hent ansøger Find vikar Godkend ansøger Registrer opsigelse Slet ansøger Hent alle opsigelser Hent alle vikarer Login Vikar/Superbruger/ Administrator Hent vikar 3. iteration (CMS delen) 4. iteration ( Login delen) Iterationen indeholder følgende use cases: Iterationen indeholder følgende use cases: Rediger indholdet af web siderne Hent bruger Hent interne web links Tilføj bruger Tilføj Interne web link Rediger bruger Rediger Interne web link Slet bruger Slet Interne web link Tilsend ny password Vis eksempel med ændringerne af siderne Skift password Rediger autosvar 5. iteration (Distributionslister) 6. iteration (kunde) Iterationen indeholder følgende use cases: Iterationen indeholder følgende use cases: Hent alle distributionslister Hent alle kunder Hent distributionsliste Hent kunde Tilføj distributionsliste Tilføj kunde Rediger distributionsliste Rediger kunde Slet distributionsliste Slet kunde Tilføj vikar til distributionsliste 7. iteration (kontakter/diverse) Fjern vikar fra distributionsliste Iterationen indeholder følgende use cases: 19

20 Rediger vikar distributionsliste Rediger kunde distributionsliste Rediger kontakt distributionsliste Hent vikarside distributionslister Send Hent alle kontakter Hent kontakt Tilføj kontakt Rediger kontakt Slet kontakt Hent nærmeste fødselsdage Rollebeskrivelse af brugertyper og målgruppe Der er identificeret 5 forskellige aktører til LabVikar systemet. Navn: Administrator Super bruger Web bruger Ansøger Vikar Kort beskrivelse: Administrerer super brugere og kan alt, hvad super brugere kan. Ansatte i LabVikar, som har adgang til administration af alle ansøgere, vikarer, kunder, kontkakter, distributionslister m.m. samt redigering af hjemmesiden. Offentlige personer (anonyme bruger) som primært browser rundt på hjemmesiden og som ikke har adgang til nogen personlige data. Ansøgere er potentielle vikarer der har sendt en ansøgning til LabVikar. De er endnu ikke blevet godkendt af en super bruger. De kan dog logge ind i systemet og få adgang til deres egne oplysninger og redigere dem. Vikarer som er blevet oprettet i systemet og godkendt af en super bruger, kan logge ind i systemet og få adgang til deres egne oplysninger og redigere dem. Der gives i det følgende en kort rollebeskrivelse for de 5 brugerkategorier. Administrator Systemadministrator vil typisk repræsenteres af LabVikar s IT-Supporter og chefen, Rikke Merton. Udover at de har samme rettigheder som super brugerne, har de også mulighed for at administrere super brugere. Super bruger Super brugere repræsenter personalet i LabVikar. Disse brugeres primære opgaver er at administrere ansøgere, vikarer, kunder, kontakter og distributionslister mm. De har også fuld adgang til opdatering af hjemmesiden via et CMS system. Super brugerne har en begrænset viden inden for IT. Ansøger Ansøgere er personer som har sendt en ansøgning om at blive vikar. De er endnu ikke blevet godkendt af en super bruger. Ansøgere har adgang til at redigere deres egne oplysninger. 20

21 De mulige ansøgere kan have alle alderstrin og deres kompetencer inden for laborant faget er forskellige. De kan være studerede, nyuddannede eller personer der har arbejdet i branchen i flere år. De forskellige ansøgere kan have speciel ekspertise indenfor nogle områder. Vikar Vikarer er ansøgere som er blevet godkendt af en super bruger. De kan have forskellige faglige kompetencer med hensyn til uddannelser og erhvervserfaringer mm. De skal også have adgang til at redigere deres egne oplysninger løbene. Vikarerne har stor værdi for LabVikar, da disse er med til at give dem en indtægtskilde. LabVikar vil gerne tilfredsstille og servicere disse brugere så godt som muligt. Vikarer kommer til, at udgøre den største registrerede brugergruppe i systemet. Web bruger Web brugere omhandler personer der surfer rundt på nettet samt personer, der søger diverse oplysninger på hjemmesiden. Web brugere repræsenterer potentielle interessenter for LabVikar. F.eks. fremtidige vikarer, ansøgere, kunder mm. De har ikke adgang til nogen data udover de oplysninger der er på den offentlige side. Use case diagram På baggrund af use cases og rollebeskrivelser har vi fundet frem til følgende aktører, som gør brug af systemet: Primære aktører Super brugere - Administrerer kunder, vikarer, ansøger, kontakter og nyhedsbreve og sender s, opdaterer hjemmesiden mm. Vikarer - Rediger personlige oplysninger, CV mm. Administratorer - Har samme rettigheder som super brugere og kan herudover oprette og ændre informationer om super brugere. Supporting aktører Ansøgere - De web brugere der ansøger om at blive vikar. Offstage aktører Web brugere - De web brugere der kun browser for, at finde diverse oplysninger om virksomheden. 21

22 Ansøgninger: Vikar: Hent alle vikarer Tilføj ansøger Hent vikar Hent alle ansøgere Slet vikar Rediger vikar Hent ansøger Find vikar Ansøger Godkend ansøger Super bruger Vikar Registrer opsigelse Super bruger Slet ansøger Vis opsigelser Ansøger Hent alle opsigelser Hent nærmeste fødselsdage Login delen: Tilsend ny password / Skift password Kun hver enkelte bruger kan få tilsendt ny password og skift deres egen password Tilsend ny password brugerens login for ansøgeren eller vikaren bliver slettet når ansøgningen eller vikaren bliver slettet Skift password Vikar Slet bruger vikar/ansøger Tilføj bruger (vikar/ansøger) Super bruger Hent bruger Ansøgeren får oprettet et login når de sender en ansøgning. Brugernavnet bliver tildelt, password bestemmer de selv. Ansøger Rediger bruger Tilføj bruger (superbruger/administrator) Systemadministrator Slet bruger (superbruger/administrator) 22

23 Distributionsliste delen: Kunde/Kontakt delen/cms delen: Kun super brugere og administrator kan tilgå disse. Hent alle distributionslister Hent distributionsliste Rediger indholdet af web siderne Vikar Tilføj distributionsliste Rediger distributionsliste Slet distributionsliste Tilføj vikar til distributionsliste Fjern vikar fra distributionsliste Rediger vikar distributionsliste Super bruger Super bruger Hent alle kunder Hent kunde Rediger kunde Tilføj kunde Hent alle kontrakter Hent kontrakt Tilføj kontrakt Rediger kontrakt Hent interne web links Tilføj Interne web link Rediger Interne web link Slet Interne web link Vis eksempel med ændringerne af siderne Rediger kunde distributionsliste Slet kunde Slet kontrakt Rediger autosvar Ansøger Rediger kontakt distributionsliste Hent vikarside distributionslister Send 23

24 Kravspecifikation Her er en kort gennemgang af de basale funktioner vi tilbyder i vores system. Krav til funktionalitet Vi har valgt at opdele de funktionelle krav til alle brugertyper og målgrupper af systemet. Vikar og Ansøger LabVikars hjemmeside skal rumme mulighed for, at brugere kan ansøge om at blive optaget som fremtidige vikarer. Begrundelse: For at afhjælpe og telefon henvendelser. Ved oprettelse af en ansøgning skal systemet validere de indtastede felter. Begrundelse: For at sikre, at LabVikar får de nødvendige oplysninger i et korrekt format. Ved oprettelse af en ansøgning, skal systemet sende en velkomst til ansøgeren med brugernavn og password. Begrundelse: For at afhjælpe og telefon henvendelser og sikre, at ansøgerne får tilsendt velkomst med de nødvendige oplysninger der kræves til login. Ansøgere og vikarer skal have mulighed for at få tilsendt nye password. Begrundelse: Hvis en ansøger eller vikar glemmer sit password, skal vedkommende have mulighed for, at få tilsendt et nyt for at kunne logge ind. Ansøgere og vikarer skal have mulighed for at ændre deres password. Begrundelse: Hvis en ansøger eller vikar fortryder sit valg af password, skal vedkommende have mulighed for at ændre det. Egne oplysninger skal kunne redigeres. Begrundelse: Man kan ikke antage at brugerne dels indtaster alt rigtigt hver gang, og de kan tillære sig nye kompetencer, som kan være vigtige at få oplyst. Derfor skal det være muligt for dem, at redigere og tilføje oplysninger, så de ikke skal kontakte LabVikar personligt, for at få lavet ændringerne. Super bruger Administrering af alle kunder. Administrering af alle kontakter. Administrering af alle vikarer. Administrering af alle ansøgere. Administrering af distributionslister. Adgang til opdatering af hjemmesiden via en browser (CMS) 24

25 Administration af indhold i automatiske s. Mulighed for valg af kontakter, kunder, vikarer, ansøgere og distributionslister ved afsendelse af s. Administratoren Administratoren skal have samme adgangs- og brugerrettigheder til systemet som super brugere og ydermere: Adgang til administration af alle super brugere. Krav til brugervenlighed Må ikke kræve mange brugerfærdigheder. Adgang til hjemmesiden skal ikke kræve nogen plugins fra klientens side. Navigationen mellem de enkelte sider skal forekomme logisk. Krav til teknologiske komponenter LabVikar systemet skal anvendes på Internettet. LabVikar systemet skal indeholde en web-baseret brugergrænseflade, som skal kunne afvikles i Microsoft Internet Explorer og Mozilla Firefox. Vedligeholdelse af hjemmesiden skal være nem. Krav til teknologisk platform Serveren skal supportere følgende: ASP.NET 2.0, Ajax Extensions, MSSQL Oppetiden på serveren skal være optimal. Krav til sikkerhed Der skal være hemmeligholdelse af data. Nogle data og personlige oplysninger skal ikke kunne læses af uautoriserede brugere. Der skal gøres brug af autentifikation, så der er vished for at brugeren er den vedkommende udgiver sig for. Der skal gøres brug af autorisation (roller), hvormed brugeren har ret til at få adgang til specifikke data. Data må ikke ændres på uautoriseret vis. Krav til systemdokumentation og anden dokumentation Der skal være relevant og tilstrækkelig system dokumentation til at LabVikars IT-ansvarlige kan videreudvikle programmet. Der skal laves brugervejledning til hele systemet. 25

26 Forandringsanalyse En implementering af et nyt IT-system er mere end blot et teknisk projekt. Med udgangspunkt i Leavitts organisationsmodel 7 ( figur 2) kan man se at implementering af et nyt IT-system involverer andre dele af virksomheden, nemlig opgaver, struktur og mennesker. Leavitts organisationsmodel siger, at hvis der ændres på modellens elementer, vil der ske ændringer i de andre. Derfor skal man tænke på de andre aspekter, når der indføres et nyt IT-system. Mennesker Teknik Struktur Opgaver Figur 2: Leavitts organisationsmodel Ifølge Leavitt, hvis man laver noget om på den tekniske side, bliver LabVikars personale nød til at lave om på deres organisationsstruktur og måden hvorpå de udfører de forskellige opgaver. Omfanget af hvor meget strukturen, arbejdsgangen mm. skal ændres afhænger af, hvor omfattende det nye IT-system er. Forskel på hvor omfattende systemet er Hvis der fx kun er tale om opgraderinger, forbedringer eller udbygning af et eksisterende ITsystem, vil det kun have meget lidt indflydelse på medarbejdernes og organisationens funktioner. Hvis der fx er tale om implementering af et nyt system eller en anden ny funktion, i et eksisterende system, vil det have større indvirkning på organisationen og arbejdsgangende. Når der er tale om implementering af et helt nyt IT-system, som vi er i gang med, vil det have stor indflydelse på arbejdsgangene og organisationens funktioner. For at det kan blive en succes skal der nøje planlægges, hvordan indførelsen af et nyt IT-system skal foregå. Modstand mod forandring Alt efter hvor omfattende et IT-system er, vil det kræve at medarbejderne skal sætte sig ind i nye ting, tilegne sig nye kompetencer og acceptere forandringerne. Afhængig af forandringernes omfang, håndteringen af implementeringsprocessen og medarbejdernes stress-niveau, vil forandringerne påvirke medarbejderne i højere eller mindre grad. 7 Leavitt HJ. Applied organizational change in industry 26

27 En implementering af et nyt IT-system kan medføre modstand mod forandring, fra dele af medarbejderne. Grunden til at medarbejderne reagerer med modstand, kan have mange årsager. Det er ofte ikke bare fordi man har en generel modvilje mod alt nyt, det kan være pga. engagement, surhed og modvilje, dårlig stemning på arbejdspladsen m.m. 8 Rosabeth Moss Kanter 9 påpeger følgende grunde til modvilje mod forandring blandt nogle medarbejdere: Man bliver hele tiden overrasket (ingen forberedelse eller baggrundsorientering). For stor usikkerhed (manglende informationer). Man taber ansigt (for meget forandring på samme tid). Man bliver usikker på sine kompetence (kan man nu leve op til de nye krav?) Mere arbejde (ændringer kræver energi, tid, møder, mere at læse etc.) Bølgevirkning (ændringer påvirker andre aktiviteter, som ikke altid har nogen direkte forbindelse med forandringen). Opsparet vrede/uvilje (mistillid grundet tidligere uindfriede løfter, som gør det svært at være positiv). Reelle trusler (forandring kan bringe smerte og tab med sig). Vi vil prøve at håndtere modstanden mod forandring, ved at inddrage slutbrugerne så meget som muligt i udviklingen af systemet. Vores mål er, at udføre brugervenlighedstest med alle slutbrugere og prøve at inddrage dem i beslutningsprocesser mht. ændringer og prøve at imødekomme deres ønsker. Derigennem håber vi at usikkerheder, overraskelser m.m. vil blive begrænset. Delkonklusion Det var fra starten af projektet vigtigt for os at tage hensyn til slutbrugerne og deres ønsker og behov. I starten af projektet udarbejdede vi et spørgeskema, for at få et bedre indblik i slutbrugernes og opgavestillers holdninger til et nyt IT-system. Besvaret spørgeskema kan ses i bilag 30 side 93. Besvarelserne viser generelt, at der er stor usikkerhed om et nyt IT system vil forbedre og have en positiv indflydelse på Labvikars arbejdsgange. Efter vores sidste accepttest og en fremlæggelse af systemet, udformede vi et nyt spørgeskema for at få et indtryk af om inddragelse af slutbrugerne i projektet havde hjulpet med usikkerheden mm. Besvaret spørgeskema kan ses i bilag 31 side 94. Ud fra den kan man se at slutbrugerne mener, at indførelse af det nye IT system, vil have en positivt effekt på arbejdsgangene og at slutbrugerne generelt er tilfredse og mindre usikre på om det vil få en positiv indflydelse. 8 Bakka JF, Fivelsdal E. Organisationsteori, Struktur, kultur, processer København. Side Rosabet Moss Kanter, B.A Stein &T.D Jick:The challenge of organizational change. New York: The Free Press, Side

28 I løbet af projektet har det pga. tidsmangel hos Labvikars personale, ikke altid været muligt at inddrage alle slutbrugere i alle brugervenlighedstest osv. Dog mener vi at vi har formået, at inddrage dem i en tilstrækkelig grad til, at have et mere positiv indtryk af IT systemet. Brugervenlighed [Users] make their credibility-based decisions about the people or organization behind the site based upon the site's overall visual appeal. Stanford Persuasive Technology Lab, 2002 Definition af brugervenlighed Brugervenlighed opstår mellem den enkelte bruger og systemet. Man kan sige at hvis brugeren løser opgaverne i systemet uden forhindringer er der en god brugervenlighed. Brugere reagerer ud fra den viden og de vaner der er velkendte og trygge. Når vi designer et system må vi som udviklere tilpasse løsningen til brugernes præferencer, forudsætninger og behov. Internettet har i dag overflod af informationer. Derfor er det vigtigt at en web side kan bevare brugernes opmærksomhed. Når vi taler om brugervenlighed af web sider sættes der også fokus på at formidle og kommunikere, dvs. om informationerne og funktionerne giver mening for brugeren. Vi mener det er vigtigt at brugerne har en følelse af overblik og kontrol over siden. Derudover er det vigtigt at web sidens indhold hurtigt afspejler relevans, aktualitet og troværdighed overfor brugerne. Den funktionelle og visuelle appel er også afgørende for om brugerne vender tilbage til siden. Rolf Molich definerer brugervenlighed således 10 Brugervenlighed = Nytteværdi + Nemhed Rolf Molich fremhæver at nytteværdi og nemhed er blot 2 kvalitetsegenskaber, hvor der er flere vigtige kvalitetsegenskaber som et web side skal indeholde. Alt efter hvem målgruppen er og hvilken slags system man skal lave, vil de undernævnte punkter have forskellige prioriteter. Kvalitetsegenskaberne er: Rolf Molich s kvalitetsegenskaberne: Hvilken former for test vi vil udført for at imødekomme disse kvalitetsegenskaberne: Nytteværdi: Kan det løse mine opgaver? Brugervenlighedstest ( Tænke højt test ) / Funktionalitets test Nemhed: Er det nemt at arbejde med? Brugervenlighedstest ( Tænke højt test ) Korrekthed: Gør det som jeg vil? Funktionalitets test Pålidelighed: Virker det korrekt hver gang Funktionalitets test/ Scenarier test Effektivitet: Løser det mine opgaver hurtigt? Effektivitets test? ingen lavet Tilgængelighed: Kan jeg komme til det når jeg vil? Scenarier test 10 Brugervenligt webdesign, Rolf Molich, 2. udgave, 1. oplag, Side 21 28

29 En web side skal være stabil og fejlfri. Fejl kan svække brugernes tillid, og i værste tilfælde miste vikarens og kundens data. Data som vikaren og kunden har tiltro til bliver opbevaret og behandlet sikkert og beskyttet, så ingen uvedkommende kan tilgå dem. Hos LabVikar er dette meget vigtigt fordi de lover anonymitet og beskyttelse af data overfor vikarer og kunder. Hvis vikarer og kunder ikke føler det er tilfældet kan det medføre et dårligt ry, tab af vikarer og kunder og i værste tilfælde en retssag. For LabVikar er det også vigtigt at hjemmesiden kan hjælpe med at løse de daglige opgaver. Pga. den begrænsede IT viden LabVikar s personale besidder, er det også vigtigt at det er nemt at arbejde med. Derudover er det også vigtigt, at hjemmesiden er tilgængelig (online) når brugeren ønsker det. For den offentlige bruger, der ikke er registreret som vikar eller kunde, er det vigtigt at brugerne kan finde de oplysninger de søger, at web siderne er tiltrækkende og at brugerne hurtigt kan få et overblik over web siden. Hvis en bruger vælger at ansøge om at blive vikar, skal tilmeldingen foregå uden problemer. Der bør ikke opstå tvivlsspørgsmål ved de felter, hvor informationer skal indtastes og systemet skal gøre som brugeren forventer. For de ansatte hos LabVikar vil løsning af opgaver, pålidelighed, tilgængelighed og sikkerhed have stor betydning. Hvad lægger brugerne generelt vægt på ved en hjemmeside Da det er en hjemmeside hvor fremtidige vikarer og kunder også er interessenter, skal hjemmesiden være attraktiv for nye og besøgende bruger. Afhængig hvad formålet med hjemmesiden er, er der nogle helt generelle ting som spiller en afgørende faktor. Disse faktorer kan have stor betydning for om brugeren vender tilbage til hjemmesiden og om de ønsker at ansøge om at blive optaget som vikarer eller kunder. Hjemmesiden er LabVikars profil udadtil og det er derfor er vigtigt at den ser professionel ud, så man får et professionelt førstegangsindtryk af LabVikar. De ting en bruger generelt lægger vægt på er: Hjemmesiden skal være pæn Professionel Stilren Troværdig Hurtig Overskueligt Moderne Spændende Derudover er det også vigtigt at hjemmesiden er behovsorienteret og troværdig overfor kunder, vikarer og andre bruger. For LabVikar er personlig service og nærvær overfor vikarer og kunder vigtig. Det har været én af grundende til den store succes for virksomheden og at der er blevet 29

30 tilmeldt så mange vikarer i løbet af det sidste år. Derfor er der også vigtigt at personlighed og nærvær bliver afspejlet i hjemmesiden. Web sidens struktur og elementer Jakob Nielsen starter sin bog Godt webdesign med et kapitel om udnyttelse af web siden 11. Mange web sider bruger mere skærmplads til andet end den information, som besøgende kommer og besøger siden for. Web siden burde derfor være dominerende med det indhold der interesserer brugeren. w3schools.com 12 lavede i januar 2007 en statistik over brugernes skærmopløsning. Statistik viser at 54% anvender 1024x768, 14% 800x600, 26% højere end 1024x768 og 6% uvisse. Dvs. over halvdelen bruger en skærmopløsning på 1024x768 og ca. 1/7 bruger en skærmoplysning på 800x600. Dvs. at web siden skal kunne ses i en 800x600 opløsning i en tilfredsstillende grad. Den sorte tykke linje viser dét brugere med 800x600pixels ser i modsætning til brugere med 1024x768 eller derover. Udover indhold og reel information kan luft og blanke områder også være nyttige, det leder øjet og hjælper de besøgende med at forstå, hvad der er vigtigt på siden og forvirrer ikke brugeren med en masse andre ting. Jakob Nielsen pointerer også at luft intet fylder og derved gør siden hurtigere at hente. Et grundlæggende princip for vores web side har været at gennemgå samtlige elementer og fjerne de designelementer der ikke gjorde nogen forskel på sidens indhold. Enkelthed vinder altid over kompleksitet, især på nettet, hvor fem sparede bytes kan medføre et millisekund kortere downloadtid. 13 Vores web side er delt op I 4 forskellige kategorier. Opdelingen ser således ud: Kategorier er: 1 Overskrift 2 Login 3 Menu 4 Indhold Denne tegning er en afbildning af vores web side. Den sorte linje viser hvordan web siden ser ud i en 800x600 skærmopløsning og tegningen i sin helhed ses i en 1024x768 skærmopløsning. 11 Godt webdesign, Jakob Nielsen, IDG Danmark, 1. udgave, 1. oplag, Side Godt webdesign, Jakob Nielsen, IDG Danmark, 1. udgave, 1. oplag, Side 28 30

31 Alle de offentlige sider, som brugerne kan tilgå, med undtagelse af siderne hvor man ansøger om at blive vikar, vil tilpasse sig selv til en skærmopløsning på 800x600 pixel. Dvs. teksten vil tilpasse sig nedad så brugeren ikke skal scrolle sidelæns for at se resten af teksten. Dette skyldes at vi bruger Label til at vise teksten i, som tilpasser sig til skærmopløsningen. Derudover har vi givet tilstrækkelig luft til venstre på siderne, for at brugeren også kan se alt i en 800x600 pixel skærmopløsning. På de sider hvor man ansøger om at blive vikar, gør vi brug af gridview. I en 800x600 pixel skærmopløsning, hvor der er udfyldt med tilstrækkelig tekst i gridviews, bliver brugeren nød til at scrolle sidelæns for at se hele indholdet. Hos LabVikar bruger de ansatte en 1024x768pixel skærmopløsning, hvilket har betydet at vi har optimeret administrationsdelen til dette. Ensartede elementer og layout Under udviklingen af vores web løsning har vi prøvet at lave en ensartet struktur for at sikre, at brud på strukturen ikke skulle give problemer eller forvirre brugeren. Vi gør brug af 2 Masterpages. Disse er med til at give hjemmesiden ensartet struktur og layout: MasterPage.master bliver brugt på de fleste sider. EditMode.master bliver brugt når brugerne tilføjer eller redigerer i oplysninger. På MasterPage.master har vi bl.a. placeret menu og login linket ( se bilag 7 side 26 ), fordi brugerne skal kunne tilgå disse funktioner, uanset hvor de befinder sig på siden. Fra MasterPage.master kalder vi også StyleSheet.css: <link href="~/app_themes/stylesheet.css" rel="stylesheet" type="text/css" /> I StyleSheet erklærer vi bl.a. hvad baggrundsbilledet skal være: 31

32 body background-image: url(../image/bg_lysblaaabsolut.gif); I og med at vi kalder Stylesheetet fra masterpagen, behøver vi ikke at kalde Stylessheetet fra andre sider, da de arver fra masterpagen. Dvs. baggrundsbilledet på alle sider er ens og hvis man ønsker at ændre det skal det blot gøres ét sted. I EditMode.master har vi fjernet de generelle funktioner, som menu og login linket ( Se Bilag 8 side 26). På alle sider hvor man skal tilføje eller redigere noget, har vi valgt at bruge EditMode.master, for at tvinge brugeren til at vælge mellem Tilføj, Opdater eller Annuller. Brugervenlighedstesten afslørede nemlig, at man blev forvirret hvis der var ekstra funktionalitet, som man ikke skulle bruge og hvor man skulle vælge enten Tilføj, Opdater eller Annuller. For ikke at forvirre brugeren har vi valgt at genbruge mange af siderne. Når en vikar fx logger sig ind på systemet og ønsker at rediger personlige oplysninger vil han se, at siden (RedigerPersonligeOplysninger.aspx) ligner den han engang havde brugt, da han ansøgte om at blive vikar (BlivVikarTrin1.aspx) Eksempel: RedigerPersonligeOplysninger.aspx: ( se en forstørret udgave i bilag 9 side 27 ) BlivVikarTrin1.aspx: ( se en forstørret udgave i bilag 9 side 27 ) Det eneste der adskiller sig er knapperne Næste trin, Opdater og Annuller. Selvom brugeren ikke bevidst genkender sidens layout, vil det altid være nemmere for vedkomme at håndtere og bruge noget man engang har set og har en ubevidst fornemmelse af. De sider hvor der ikke er forskel på knapperne, fx når en vikar ønsker at tilføje yderligere erhvervserfaring, gør vi brug af nøjagtig samme side. Disse sider bliver genbrugt : Genbrug af siderne sikrer at vi holder et ensartet layout igennem hele web løsningen. Derudover skal man kun rette i én side, hvis der skulle være ønsker om ændringer i layoutet eller specifikke elementer. 32

33 Vi har prøvet at overholde reglerne indenfor gestaltloven 14. Vi har bl.a. været opmærksomme på loven om lukkethed. Vi har sat rammer om ting der hører sammen. Fx i BlivVikarTrin2.aspx og BlivVikarTrin3.aspx bruger vi tabelrammer. Dette er med til at tydeliggøre sammenhængen mellem overskriften og de felter der skal bruges til indtastning. Andre steder i programmet skulle vi have været mere opmærksomme på loven om lukkethed. F.eks. på administration siden kunne vi have indrammet tingene bedre. 14 Brugervelige edb systemer, Rolf Molich, Teknisk Forlag, 2. Udagve, 2. Opslag Side 76 33

34 Navigation Problems with visual design can turn users off so quickly that they never discover all the smart choices you made with navigation or interaction design. - Jesse James Garrett, 2002 Indholdet af hjemmesiden kan være nok så relevant og interessant for brugerne, men hvis de ikke kan finde disse oplysninger, kan de ligeså godt ikke eksistere. Hvis brugerne har svært ved, at navigere rundt på hjemmesiden, eller de ikke kan finde ud af at betjene de tilstedeværende funktioner, vil brugerne give hjemmesiden skylden, uanset om hjemmesiden virkelig er fuld af fejl eller det rent faktisk er brugeren der begår fejlene. Det er os som web udviklere der har ansvaret for, at tilpasse hjemmesiden til brugernes krav, færdigheder og behov. Webben er et navigationssystem. Den grundlæggende brugerinteraktion består i at klikke på hyperlinks for at hoppe rundt i et enormt informations-rum med millioner af sider. 15 Vi ønsker at vedholde de besøgendes interesse ved at gøre det nemt, hurtigt og overskueligt at navigere rundt på web siden. Navigations strukturer For brugernes skyld er det vigtigt at systematisere sit materiale. Da alle web sider er forskellige vil der ikke være én type navigation der passer til alle. Vi gør bl.a. brug af hierarkisk og sekvensstruktur. Hierarkistruktur Overordnet gør vi brug af en hierarkistruktur, hvor forsiden er hovedstammen. Denne type struktur er nem at navigere i, uden at fare vild, idet vi har delt det op i forskellige kategorier. Eksempel: 15 Godt webdesign, Jakob Nielsen, IDG Danmark, 1. udgave, 1. oplag, Side

35 Tilføj kunde Menu Klik på Kunde Kunder Klik på Ny kunde Klik på Tilføj eller Annuller Klik på Vis overfor den ønskede kunde Klik på Tilbage til oversigt Kunde info Klik på Rediger Klik på Opdater eller Annuller Rediger kunde Sekvensstruktur Sekvensstruktur bruger vi bl.a. i bliv vikar hvor man skal følge et lineært forløb, for at få lov til at ansøge om at blive vikar. Her skal man igennem 3 trin, hvor man skal udfylde navn, adresse osv. Sekvensstruktur ses også ofte i salgsweb når man ønsker at betale. Eksempel: Bliv Vikar Trin 2 Menu Klik på Bliv vikar Bliv Vikar Trin 1 Klik på Næste Trin Klik på Gå til trin 1" Klik på Gå til trin 3" Klik på Gå til trin 2" Bliv Vikar Trin 3 Klik på Send Ansøger Registreret Vores samlede navigationsdiagram kan ses i bilag 10 side 28 Links Jakob Nielsen fremhæver at man ikke skal bruge klik her 16 som link. Ordene Klik og her er stort set ikke informative. Jakob Nielsen uddyber sin mening med følgende eksempel: I stedet for at sige.. Klik her for baggrundsinformation om den blånæsede honningbi. Er det bedre at sige: Vi har ekstra baggrundsinformation om den blånæsede honningbi. Vi har forsøgt at bruge ord, som har betydning som links, eksempel: 16 Godt webdesign, Jakob Nielsen, IDG Danmark, 1. udgave, 1. oplag, Side 61 35

36 LabVikar gør brug af mange interne links, dvs. links som ikke kan findes ud fra forsiden men undersiderne. Det er vigtigt for LabVikar at beholde funktionaliteten, når der skabes ekstra undersider. Derfor gjorde vi det muligt via CMS systemet at lave interne links. For at brugerne ikke bliver forvirrede, og de kan bevare overblikket, er det vigtigt at LabVikars personale også kalder disse links for noget der har betydning. Brugerens browser Ifølge W3Schools statistik 17 har det vist sig, at FireFox er den næstmest anvendte browser. I løbet af vores projekt har vi derfor valgt, at web sidens funktionalitet skal fungere optimalt i såvel Firefox som Internet Explorer. Del konklusion I løbet af projektet opdagede vi, at vi gjorde brug af forskellige fonte m.m. til overskrifter og generelle tekster på web siden. Selvom vi fra starten af projektet ville have en ensartet struktur, mente vi på daværende tidspunkt ikke, at fonte m.m. ville være et problem. Vi besluttede at fonte skulle defineres i et stylesheet, så man fremover kun skulle ændre dem ét sted og på en nem måde. Senere i forløbet mente vi at en bedre løsning ville have været, hvis Labvikar personale selv kunne ændre fonte m.m. via CMS systemet. I fremtiden vil vi i starten af et projekt tage stilling til, hvordan fonte m.m. skal defineres og hvorfra det skal styres, for netop at lette den videre udvikling af brugervenligheden. For at opnå god brugervenlighed har vi lavet brugervenlighedstest som har hjulpet os frem til et bedre resultat

37 Arkitektur En endegyldig definition af begrebet software arkitektur findes ikke. Men der har gennem tiderne været utallige bud herpå. Her er blot et par eksempler 18 : The structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time. Garlan 1995 Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled. Eoin Woods Ligesom der findes mange definitioner på arkitektur, findes der også mange måder, at beskrive de konkrete arkitekturer på. Vi har koncentreret os om følgende: Domænemodel Begrebsmæssig illustration af de objekter vores projekt beskæftiger sig med. Klassediagram Klassediagram for systemet kan ses i bilag 28 side 91. En oversigt over de anvendte notationer kan ses i bilag 27 side 90. Redegørelse for valg af opbygning følger i afsnittet om mønstre. Databasediagram - Et diagram over vores database kan ses i bilag 29 side 92. Sekvensdiagrammer Vi mener sekvensdiagrammer er særdeles velegnede til fremvisning af komplicerede scenarier. Man kan hermed nemmere vise andre folk, hvad der foregår. Vi har lavet et eksempel på et sekvensdiagram, som kan ses i bilag 12 side 41. Mønstre Arkitektoniske kendetegn. Opbygning der genkendes fra anden software. Domænemodel Domain Model is a conceptual perspective of objects in a real situation of the world, not a software perspective. Craig Larman Domænemodellen er altså en begrebsmæssig illustration af de objekter i virkelighedens verden, som vi beskæftiger os med Ikke software objekter. 18 Yderligere definitioner kan ses på: 37

38 Larman gør dog opmærksom på 19, at domænemodel ikke må forveksles med domæne lag. Et domæne lag er det lag af software objekter, under brugergrænsefladens lag, som indeholder domæne objekter. Domænemodellen kan ses i bilag 14 side 44. Mønstre Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. Christopher Alexander Lag-deling A layered system is organized hierarchically, each layer providing service to the layer above it and serving as a client to the layer below. This description can also be articulated as a conditions imposed on the relations between layer and any entity in the program as follows: Each entity belongs to exactly one layer; Each entity may depend (invoke, inherit, or make some other explicit dependency) only on entities of same or lower layers. David Garlan, Mary Shaw. An Introduction to Software Architecture. Lag kan være fysiske lag som f.eks. klient og server. Eller det kan være logiske lag som f.eks. exe filer, DLLs, website projekter m.m. Lag-deling er organiseret hierarkisk. Hvert lag tilbyder services til laget ovenover og anvender services fra lag nedenunder. Objekter i ét lag må kun kalde objekter i samme lag eller underliggende lag. Der må ikke være cirkulære referencer mellem lag. Hvis lag A har en reference til lag B, så kan B ikke have en reference til A. Følgende diagram viser opbygningen af vores logiske lag. Lag markeret med stiplede linier er fra tredje part. 19 Applying UML and Patterns, side

39 WebControls (WebControls.DLL) Presentation (LabVikar) Andre assemblies FCKEditor FredCK.FCKeditorV2.dll Ajax Control Toolkit AjaxControlToolkit.dll Domæne (Domæne.DLL) Data Source (DBManagement.DLL) Presentation Brugergrænseflade. Data source Objekter der holder databasen ajour med ændringer i domæne laget. Domæne Domæne objekter. WebControls Custom Controls: Arver fra eksisterende kontroller og tilføjer funktionalitet. Singleton (GOF) Singleton instanser er kendetegnet ved følgende: Privat konstruktør så de ikke kan kaldes udefra En statisk attribut der holder på en reference til en instans af samme klasse. En public static property, der returnerer denne attribut. class VikarDBManager private VikarDBManager() static VikarDBManager instans = new VikarDBManager(); internal static VikarDBManager Instans get return instans; Alle klasser i data source laget gør brug af Singleton mønstret. Vi illustrerer en singleton klasse således: 1 SingletonKlasse 1 39

40 Facade controller En facade kontroller fungerer som ét enkelt tilgangspunkt til et subsystem af services 20. Kontrolleren i data source laget håndterer forespørgsler fra brugergrænsefladen. Derefter delegerer den kaldet videre til den eller de DBManager objekter der skal hente eller ændre informationer i databasen. Følgende illustration viser et par af de DBManagers den laver kald til: Controller ØvrigeOplysningerDBManager * CVDBManager 1 1 Interface Vores formål med brug af interfaces er først og fremmest at understrege, hvilke brugertyper der har adgang til de forskellige metoder på kontrolleren. For hver brugertype er der lavet et interface. IOffentligController Indeholder de metoder offentlige brugere må anvende. IVikarController Indeholder de metoder som vikarer må anvende IAdminController Indeholder de metoder som administratorerne må anvende. En del af systemet ser så således ud --> 20 Craig Larman Applying UML and patterns, side

41 Kontrolleren implementerer disse interfaces (arver fra dem). namespace DBManagement public class Controller: IAdminController, IOffentligController, IVikarController static Controller instans = new Controller(); public static IAdminController AdminController get return instans as IAdminController; public static IVikarController VikarController get return instans as IVikarController; public static IOffentligController OffentligController get return instans as IOffentligController; private Controller(). Når man vil lave kald til kontrolleren foregår det f.eks. således: Controller.OffentligController.TilføjAnsøger(vikar, cv, øvrigeoplysninger, password); Kontrolleren indeholder samtlige metoder, som er defineret i disse interfaces. Indkapsling Vi styrer synligheden af klasser og deres medlemmer med nøgleord. Der er 3 niveauer af synlighed. Private Inden for klassen. Internal Inden for namespacet. Public Alle. En klasses medlemmer er private, såfremt de ikke må kaldes fra andre objekter. De klasser som må kaldes af objekter indenfor samme namespace, men som ikke må kaldes af objekter fra andre namespaces er angivet som internal. Objekterne i data source laget indeholder en lang række metoder, som er internal. Hermed er disse metoder ikke tilgængelige fra præsentationslaget. Formålet med indkapslingen er, at skjule 41

42 kompleksitet, som ikke er relevant for det overliggende lag. Endvidere sørger indkapslingen for, at der ikke kan laves uhensigtsmæssige kald til data source laget. F.eks. må der ikke tilføjes en vikar uden, at der også bliver tilføjet et CV. Så disse metoder er internal. Kun facade kontrolleren har public metoder, der tillader oprettelse af en ny vikar, såfremt den også modtager CV mm. Facade kontrolleren vil herefter delegere kaldet videre til de rette DBManager objekter. Data transfer objects Mange DBManagers i data source laget har et tilhørende data transfer objekt 21 (bilag 13 side 43). Hvis f.eks. CVDBManager en bliver bedt om, at hente et bestemt CV, vil den skabe et nyt CV objekt og udfylde det med informationer fra følgende tabeller: CV, Uddannelse, Erhvervserfaring og AndenErfaring. Herefter returnerer den DTO objektet til præsentationslaget via kontrolleren. Præsentationslaget kan også skabe DTO er og udfylde dem med informationer fra skærmbilledet. Herefter kan den sende DTO en videre til kontrolleren som så sørger for, at kalde DBManager en for dette DTO. DBManager en vil så opdatere databasen med informationerne fra DTO objektet. Alle DTO klasser er public. Og alle deres properties er public. Mange kontroller i præsentationslaget binder til DTO objekter. Databinding er kun muligt via properties. Ikke via attributter uanset om de er public. Nedenfor ses et eksempel på et DTO objekt. namespace Domæne [Serializable] public class Distributionsliste int nr = 0; string emne = string.empty; bool synligpåvikarside = false; public Distributionsliste() public int Nr get return nr; set nr = value; public string Emne get return emne; set emne = value; public bool SynligPåVikarside get return synligpåvikarside; set synligpåvikarside = value; 21 Martin Fowler Patterns of Enterprise Application Architecture, side

43 Server Session State Server Session State 22 omhandler bevaring af informationer på serveren. Cache objektet Man kan gemme informationer på serveren via HashListen Cache, som er en property på Page objektet. Man kan f.eks. vælge at læse alle vikarer og kunder m.m. ind i denne Cache. Når en klient så forespørger på vikaroplysninger, vil informationerne blive hentet fra Cache objektet. Så længe der ikke sker ændringer i vikar objekterne, vil det ikke være nødvendigt, at opdatere databasen. Det vil gøre serveren i stand til at betjene mange forespørgsler hurtigt. Langt de fleste kald til en server drejer sig om, at hente data. Det er betydeligt hurtigere for serveren, at hente informationer fra RAM end det er at hente informationer fra harddisk. Man kan gemme informationer i Cache objektet således: Cache["Vikarer"] = vikarer; Man kan hente informationerne igen således: List<Vikar> vikarer = (List<Vikar>)Cache["Vikarer"]; Dog må det siges at være endnu mere effektivt at gemme informationerne på F.eks. en Facade Controller, hvis man gør brug heraf. Så kan man undgå Type Casting. Session objektet Hver gang en klient forespørger på en webside sker følgende: Browser en tjekker om klienten har cookies liggende, som henviser til den pågældende URL. Hvis det er tilfældet sendes disse cookies til serveren sammen med forespørgslen. Hvis ikke serveren modtager en cookie med navnet SessionID, så opretter serveren et nyt objekt med navnet Session. Serveren har en liste med Session objekter; ét objekt for hver klient. Hvis en klient ikke udfører handlinger, der medfører post back til serveren, indenfor et givet tidsrum, bliver det pågældende Session objekt slettet igen. Session objektet tildeles et unikt nummer, som bruges til at genkende klienten. Når den forespurgte webside sendes ud til klienten, medfølger et tilsvarende nummer via en cookie: SessionID. Når klienten næste gang henvender sig til serveren bliver denne cookie sendt med. Nu vil klienten blive genkendt af serveren, medmindre der er gået så lang tid, at serveren har slettet Session objektet. Hvis sidstnævnte er tilfældet bliver der så oprettet et nyt Session objekt igen. 22 Martin Fowler Patterns of Enterprise Application Architecture, side

44 Session objektet kan bruges til, at gemme oplysninger for hver enkelt klient. På nøjagtigt samme måde som det blev gjort i Cache objektet ovenfor. En server der gemmer oplysninger for sine klienter, er en såkaldt Statefull server. Det er dejligt nemt, men ikke særlig skalerbart. Såfremt mange klienter besøger serveren indenfor et kort tidsrum, vil serveren få tilsvarende mange Session objekter. Hvis klienterne gemmer mange informationer i disse Session objekter, vil det kræve endnu mere hukommelse på serveren. Hvis serveren bliver genstartet, eller hjemmesiden bliver udgivet med nye ændringer, vil en masse klienter få fejlmeddelelser, hvis de antager at visse informationer bliver husket af serveren. Client Session State Såfremt man kan undgå, at gemme informationer i serverens hukommelse, kan man øge hjemmesidens skalerbarhed. En mulighed er, at sende informationerne videre til klienten. Dette gøres ved at man vedhæfter informationerne til Page objektet (som er den webside man sender afsted). Når klienten så sender siden retur til serveren (post back), er informationerne stadigvæk vedhæftet. Og serveren har i mellemtiden undgået brug af ressourcer på, at huske disse informationer for klienten. ViewState Såfremt et DTO objekt skal kunne gemmes i ViewState på den webside, der sendes til en klient, skal det være serialiserbart. Derfor anvender flere af disse DTO klasser Serializeable attributten: [Serializable] public class CV Ligeledes skal de objekter CV et indeholder være serialiserbare. F.eks. har CV et en liste med uddannelser: [Serializable] public class Uddannelse Herefter kan vi gemme CV et i ViewState således: ViewState["CV"] = cv; Når klienten sender siden tilbage til serveren (post-back), kan serveren hente det CV, som den i sin tid sendte ud til klienten: CV cv = (CV)ViewState["CV"]; Cookies På et tidspunkt gemte vi objekter ned i cookies. Dette er kun muligt såfremt objektet kan omdannes til en string værdi. Derfor måtte vi lave en ToString() metode på disse objekter. På CV et ser metoden således ud: 44

45 public override string ToString() string cvstring = vikarnr.tostring() + " " + titel + " " + levnedsbeskrivelse + " " + interesser + " " + arbejdssituationnu + " "; foreach (AndenErfaring andenerfaring in andreerfaringer) cvstring += "AndenErfaring" + " " + andenerfaring.tostring(); foreach (Erhvervserfaring erhvervserfaring in erhvervserfaringsliste) cvstring += "Erhvervserfaring" + " " + erhvervserfaring.tostring(); foreach (Uddannelse uddannelse in uddannelsesliste) cvstring += "Uddannelse" + " " + uddannelse.tostring(); return cvstring; Og ligeledes en statisk FromString() metode: public static CV FromString(string cvstring) CV cv = new CV(); int i = 0; string[] elementer = cvstring.split(" ".ToCharArray()); cv.vikarnr = int.parse(elementer[i++]); cv.titel = elementer[i++]; cv.levnedsbeskrivelse = elementer[i++]; cv.interesser = elementer[i++]; cv.arbejdssituationnu = elementer[i++]; while (true) if (elementer[i++] == "AndenErfaring") cv.andreerfaringer.add(new AndenErfaring(elementer[i++], elementer[i++], elementer[i++], elementer[i++], elementer[i++])); else i--; break; while (true) if (elementer[i++] == "Erhvervserfaring") cv.erhvervserfaringsliste.add(new Erhvervserfaring(elementer[i++], elementer[i++], elementer[i++], elementer[i++], elementer[i++])); else i--; break; while (true) if (elementer[i++] == "Uddannelse") cv.uddannelsesliste.add(new Uddannelse(elementer[i++], elementer[i++], elementer[i++])); else i--; break; return cv; 45

46 Herefter er det muligt at gemme CV et ned i en cookie: Response.Cookies["CV"].Value = cv.tostring(); Når klienten sender siden tilbage til serveren (post-back), sendes cookien med. Serveren kan så hente CV et frem fra cookien igen via FromString() metoden: CV cv = CV.FromString(Response.Cookies["CV"].Value); CookieHelper klassen: Vi har i flere tilfælde brug for, at gemme lister med heltal (f.eks. vikarnumre) ned i cookies. Derfor har vi lavet en klasse der kan hjælpe os med dette: public class CookieHelper public static List<int> HentNumre(HttpCookie cookie) List<int> numre = new List<int>(); if (cookie == null) return numre; else string[] array = cookie.value.split(' '); foreach (string value in array) if (value!= string.empty) numre.add(int.parse(value)); return numre; public static void GemNumre(List<int> numre, HttpCookie cookie) cookie.value = string.empty; numre.foreach(delegate(int nummer) cookie.value += nummer.tostring() + " "; ); Et af de steder, hvorfra vi anvender denne CookieHelper klasse, er fra det skærmbillede, hvor vi tilføjer og fjerner ansøgere, vikarer, kunder og kontakter til/fra en distributionsliste. Det er en af de mere komplekse dele af vores program. Det der gør opgaven besværlig er, at vi ønsker en Stateless server. Vi vil helst ikke cache nogen som helst værdier på serveren. Vi ønsker endvidere, at det skal være muligt, at fortryde de ændringer man laver i distributionslisten. Og andre brugere må først se ændringerne når brugeren er færdig med redigeringen og trykker Opdater. Så vi må altså ikke opdatere databasen før brugeren er færdig og bekræfter ændringerne. 46

47 Der skal holdes styr på 8 forskellige midlertidige lister: Listen over nuværende vikarer i distributionslisten og listen over vikarer der ikke er med i distributionslisten. Samt tilsvarende for ansøgere, kunder og kontakter. Vi kunne selvfølgelig gemme disse lister i ViewState. Men det vil gøre siden utrolig langsom, hvis der sammenlagt er flere tusinde ansøgere, vikarer, kunder og kontakter. Vi kunne også gemme listerne med disse objekter ned i cookies. Men cookies bliver ligesom ViewState også sendt frem og tilbage mellem klient og server, ved hvert post back. Så det vil også gøre siden langsom. Vi kunne reducere omfanget af informationer i cookies markant, hvis vi kun gemte vikarnumre og kundenumre osv. ned i cookies. Men vi kan reducere mængden af informationer endnu mere, hvis vi kun gemmer numrene ned på de tilføjede/ fjernede ansøgere, vikarer, kunder og kontakter. Når brugeren så bekræfter sine ændringer vil følgende metode blive anvendt: protected void btnopdater_click(object sender, EventArgs e) Distributionsliste distributionsliste = new Distributionsliste(); distributionsliste.nr = int.parse(lblnr.text); distributionsliste.emne = tbxemne.text; distributionsliste.synligpåvikarside = CheckBoxSynligPåVikarside.Checked; List<int> tilføjedevikarnumre = CookieHelper.HentNumre(Request.Cookies["TilføjedeVikarNumre"]); List<int> fjernedevikarnumre = CookieHelper.HentNumre(Request.Cookies["FjernedeVikarNumre"]); List<int> tilføjedeansøgernumre = CookieHelper.HentNumre(Request.Cookies["TilføjedeAnsøgerNumre"]); List<int> fjernedeansøgernumre = CookieHelper.HentNumre(Request.Cookies["FjernedeAnsøgerNumre"]); List<int> tilføjedekundenumre = CookieHelper.HentNumre(Request.Cookies["TilføjedeKundeNumre"]); List<int> fjernedekundenumre = CookieHelper.HentNumre(Request.Cookies["FjernedeKundeNumre"]); List<int> tilføjedekontaktnumre = CookieHelper.HentNumre(Request.Cookies["TilføjedeKontaktNumre"]); List<int> fjernedekontaktnumre = CookieHelper.HentNumre(Request.Cookies["FjernedeKontaktNumre"]); admincontroller.redigerdistributionsliste(distributionsliste, tilføjedevikarnumre, fjernedevikarnumre, tilføjedeansøgernumre, fjernedeansøgernumre, tilføjedekundenumre, fjernedekundenumre, tilføjedekontaktnumre, fjernedekontaktnumre); Response.Redirect("VisDistributionsliste.aspx?Nr=" + lblnr.text); 47

48 Optimistic Concurrency I ovenstående eksempel er der stadigvæk nogle problemstillinger. Hver gang der trykkes på i browseren, vil enhver bruger forvente at lister over ansøgere, vikarer, kunder og kontakter, bliver opdateret i forhold til andre brugeres ændringer. Hvis bruger2 gør bruger1 opmærksom på, at der lige er blevet slettet en vikar fra databasen, vil bruger1 per intuition trykke på ovennævnte knap. Han vil så forvente at hans liste med vikarer bliver opdateret herefter. Og han vil samtidig også forvente, at de midlertidige ændringer han har lavet i distributionslisten, ikke bliver nulstillet. For at få alt dette til at lykkes, skal listen over vikarer m.m. hentes fra databasen igen og synkroniseres med de ændringer, der er blevet registreret i cookies. Hvis en vikar f.eks. er blevet slettet af en anden bruger, skal vikaren ikke længere være synlig på hans skærmbillede. Metoderne, der synkroniserer de midlertidige ændringer, som bruger1 har foretaget, med de ændringer bruger2 har lavet i databasen, ser således ud (forenklet): void opdatervikargridviews() int distributionslistenr = int.parse(lblnr.text); List<Vikar> muligevikarer = new List<Vikar>(); List<Vikar> distributionslistensvikarer = new List<Vikar>(); new DistributionsGuiHelper().HentVikarer(Page, distributionslistenr, out muligevikarer, out distributionslistensvikarer); GridViewMuligeVikarer.DataSource = muligevikarer; GridViewMuligeVikarer.DataBind(); GridViewDistributionslisteVikarer.DataSource = distributionslistensvikarer; GridViewDistributionslisteVikarer.DataBind(); Som det fremgår af denne metode kaldes der videre til en anden metode HentVikarer( ), som er placeret i en helt anden klasse. Det skyldes at 2 forskellige sider har brug for, at kalde den samme metode. Metoden HentVikarer( ) ser i en forenklet version således ud: public void HentVikarer(Page page, int distributionslistenr, out List<Vikar> muligevikarer, out List<Vikar> distributionslistensvikarer) // Hent fra database og synkroniser med ændringer registreret i cookies... // Denne lock skal FJERNES og udskiftes med en transaktion... lock (admincontroller) muligevikarer = admincontroller.hentallevikarer(); distributionslistensvikarer = admincontroller.hentvikarerfradistributionsliste(distributionslistenr); // Fra listen over mulige vikarer fjernes de vikarer som også er med i // distributionslisten: foreach (Vikar vikar in distributionslistensvikarer) 48

49 Vikar vikaridistributionsliste = muligevikarer.find(delegate(vikar muligvikar) return muligvikar.nr == vikar.nr; ); muligevikarer.remove(vikaridistributionsliste); // Hent vores midlertidige tilføjelser til distributionslisten. List<int> tilføjedevikarnumre = CookieHelper.HentNumre(page.Request.Cookies["TilføjedeVikarNumre"]); // Tjek om vores midlertidige ændringer stadigvæk giver mening i forhold til // den opdaterede database: for (int i = tilføjedevikarnumre.count - 1; i >= 0; i--) int vikarnr = tilføjedevikarnumre[i]; // Hvis en anden bruger i mellemtiden har tilføjet den samme vikar til den // samme distibutionsliste, fjerner vi vikaren fra listen over // vores egen tilføjelser if (distributionslistensvikarer.exists(delegate(vikar vikar) return vikar.nr == vikarnr; )) tilføjedevikarnumre.removeat(i); else if (!muligevikarer.exists(delegate(vikar vikar) return vikar.nr == vikarnr; )) // Vikaren eksisterer altså ikke i den opdaterede distributionsliste. // Hvis vikaren heller ikke eksisterer i den opdaterede liste med mulige // vikarer må en anden bruger have slettet den. // Vi ønsker ikke at cookie med tilføjede vikarer skal henvise til et // vikarnr, der ikke længere eksisterer tilføjedevikarnumre.removeat(i); else // Hvis vi når hertil er der ikke tale om nogen samtidighedskonflikt. Vikar vikar = muligevikarer.find(delegate(vikar muligvikar) return muligvikar.nr == vikarnr; ); // Den midlertidigt tilføjede vikar, tilføjes til distributionslisten // og fjernes fra listen over mulige vikarer distributionslistensvikarer.add(vikar); muligevikarer.remove(vikar); CookieHelper.GemNumre(tilføjedeVikarNumre, page.response.cookies["tilføjedevikarnumre"]); // Herefter synkroniseres ligeledes med cookie der indeholder fjernede // vikarnumre Metodens udgående parametre muligevikarer og distributionslistevikarer, er nu synkroniseret i forhold til databasen, og reflekterer brugerens ikke-bekræftede ændringsforslag. 49

50 Inheritance Vi bruger arv i forbindelse af vores egen implementering af MembershipProvider og RoleProvider klasserne. F.eks.: MedlemskabManager arver fra MembershipProvider og tvinges hermed til, at implementere en lang række abstrakte metoder fra MembershipProvider en. En mere udførlig illustration af disse klasser fremgår af vores klassediagram. MembershipProvider RoleProvider 1 MedlemskabsManager 1 RolleManager 1 1 Vi bruger også arv i forbindelse med vores WebCustomControls: public class RegExpValidator RegularExpressionValidator Yderligere beskrivelse herom følger i et senere kapitel. Model View Controller Web applikationer med dynamisk indhold, anvender ofte anden kode end HTML. F.eks. JavaScript. Ifølge Martin Fowler følger samspillet mellem HTML og anden kode et mønster, som han kalder MVC (Model View Controller) 23. View HTML kode Controller JavaScript, C# o.l. Model Dataset eller andre domæne objekter. Her tager kontrolleren imod input fra brugeren, manipulerer modellen og får View et til at opdatere. Page Controller Page Controller mønstret 24, er en bestemt variation af ovennævnte MVC mønster. Her er der nøjagtigt én Controller per View. En ASP.NET side indeholder én View klasse og én Controller klasse. Controller klassen er den vi kender som Code-behind. View klassen arver fra Codebehind klassen og indeholder HTML kode. 23 Martin Fowler - Patterns of Enterprise Application Architecture, side Martin Fowler Patterns of Enterprise Application Architecture, side

51 Martin Fowler siger følgende 25 : To sum up, the object that acts as both the controller and the view is the aspx ASP.NET page. To keep the controller code out of a scriptlet, you define a separate code behind class. Herefter viser han hvordan den såkaldte scriptlet arver fra code behind klassen: <%@ Page Language="C#" CodeFile="Default.aspx.cs" Inherits="OffentligWebsite_Default" AutoEventWireup="true"%> Template View Database drevne hjemmesider gør ofte brug af mønstret Template View 26. Det sker f.eks. når vi anvender kontroller som GridView og DataList mm. Disse kontroller er skabeloner, som indeholder varierende data. Delkonklusion Brugen af en top-down udviklingsstrategi viste sig, at få stor indflydelse på den grundlæggende opbygning af vores arkitektur. Ideen med, at lade websidernes indhold bestemme sammensætningen af vores data transfer objekter, gjorde udviklingsarbejdet nemt. For hver DTO lavede vi en DBManager, der kunne udføre CRUD operationer I databasen. Men da vi ud fra Fowlers beskrivelser af grundlæggende mønstre I enterprise applikationer, skulle udpege, hvilket mønster vi havde anvendt, fik vi et problem. Det lod ikke til, at vi havde anvendt hverken domain model, transaction script eller table module i rendyrket format. Heldigvis kom Larman os til undsætning med hans bredere definition af façade controller mønstret og dets brug af subsystemer. Vi vil i fremtidige projekter have I bagtanke, at der nok på dette område bør anvendes en mere klart defineret arkitektur. Der er taget hensyn til offline samtidighed i store dele af applikationen. Det har I mange situationer vist sig, at være medvirkende til, at forholdsvis simple operationer blev yderst komplekse. Vi kunne have skrevet meget mere herom, men vil i stedet henvise interesserede til vedlagte program. Vi har stiftet bekendtskab med flere nye mønstre i kategorien web presentation patterns. Vi fik i denne anledning sat på plads, at MVC mønstret ikke har noget som helst, at gøre med lagdeling, da det bryder loven om cirkulære referencer mellem lag. Og at det I stedet var nøjagtigt, hvad det påstod at være: Et web præsentations mønster. 25 Martin Fowler Patterns of Enterprise Application Architecture, side Martin Fowler Patterns of Enterprise Application Architecture, side

52 Stored Procedures Man bør vægte fordele og ulemper ved Stored Procedures før man tager dem i brug. Af fordele kan nævnes: 1.Perfomance. Stored Procedures ligger i databasen, og bliver kompileret ved opstarten. Derefter er de klar til brug, og er meget responsive når de kaldes. 2. Seperation of Concerns. Logik der har med data at gøre, holdes i databasen. Det bør ikke være muligt, at manipulere dens data direkte fra koden. Af ulemper kan nævnes: 1. Vedligeholdelsesvenlighed. Hvis der laves ændringer i databasen, skal der både ændres i stored procedures og koden. 2. Det er sværere at skifte databasen ud senere, da Stored Procedures ikke migrerer mellem forskellige DBMS er uden problemer. Vi har valgt at bruge Stored Procedures til vores database af forskellige årsager. Først og fremmest på grund af performance. Sekundært fordi vi ikke er glade for spaghetti kode. Vi kan godt lide at holde Sql-sætninger adskilt fra C# kode. Derudover regner LabVikar ikke med at skifte database. Transaktioner En transaktion er en handling eller en række af handlinger, udført af en enkelt bruger eller program, som læser eller opdaterer indholdet af en database 27. Transaktioner skal stille følgende faciliteter til rådighed 28 : Atomare transaktioner, hvilket betyder, at en ændring enten skal gennemføres helt, eller også skal der ryddes så godt op, at det ser ud som om ændringen ikke er forsøgt gennemført. Konsistens De atomare transaktioner skal føre databasen fra en sammenhængende tilstand til en anden. Dette kræver, at de enkelte transaktioner (deltransaktioner) er designet korrekt, hvilket afhænger af programmøren. 27 Database Systems af Thomas Connolly og Carolyn Begg, side

53 Isolation To eller flere programmer, der bruger samme database, må ikke kunne se hinandens ændringer, før de er helt gennemførte. Der anvendes dog forskellige grader af isolation. Varighed Det skal sikres, at data ikke bare forsvinder. Det stiller krav til den anvendte hardware og krav om at skrivninger til disk laves, så data ikke kun lander i hukommelsen. På engelsk kaldes disse krav om bestemte egenskaber for ACID-properties efter forbogstaverne i de engelske betegnelser atomicy, consistency, isolation og durability. Transaktioner, der kun omfatter læsning, vil altid kunne startes forfra. Der er ingen grund til at rulle læsninger tilbage, såfremt de mislykkes. Det er heller ikke nødvendigt at bekræfte læsninger med Commit. Beskrivelse af isolation og varighed kan læses i bilag 15 side 45. Vi har i projektet hovedsageligt arbejdet med begreberne atomare transaktioner og konsistens. Atomare transaktioner Et DBMS (Database Management System) såsom MSSQL, skal sikre, at enhver skrivning i databasen enten bliver udført totalt (atomart), eller slet ikke bliver udført. Dette gøres ved hjælp af en skriv-foran-log (write ahead log). Førend noget som helst bliver ændret i databasen skal DBMS en skrive i loggen, hvad den vil gøre. Loggen skal være anbragt på et persistent medium f.eks. en harddisk. Såfremt systemet går ned mens der bliver skrevet i databasen, vil det hermed være muligt, ud fra informationerne i loggen, at rulle ufuldstændige ændringer tilbage og dermed sikre, at databasen er i en konsistent tilstand. Såfremt loggen indeholder alle informationer om den transaktion som mislykkedes, kan den herefter forsøge, at udføre transaktionen igen. Transaktioner, som kun består af et enkelt kald til databasen (f.eks. én stored procedure), udføres implicit. Programmøren behøver ikke foretage sig noget i sådanne situationer. DBMS en vil garantere, at ændringen enten bliver udført helt, eller slet ikke. Konsistens Transaktioner kan dog også bestå af adskillige kald til databasen. F.eks. når vi tilføjer en ansøger til vores system, kræves følgende: 1. Der skal findes et ledigt vikarnummer (LabVikar ønsker ikke autonummerering). 2. Der skal tilføjes en post i Vikar tabellen. 3. Der skal tilføjes en post i CV tabellen. 4. Der skal muligvis tilføjes én eller flere poster i Uddannelse tabellen. 5. Der skal muligvis tilføjes én eller flere poster i Erhvervserfaring tabellen. 6. Der skal muligvis tilføjes én eller flere poster i AndenErfaring tabellen. 7. Der skal tilføjes en post i ØvrigeOplysniger tabellen. 8. Der skal muligvis tilføjes én eller flere poster i Kørekort tabellen. 53

54 9. Der skal muligvis tilføjes én eller flere poster i Kursus tabellen. 10. Der skal muligvis tilføjes én eller flere poster i Sprogkundskab tabellen. 11. Der skal tilføjes en post i AdminVikarInfo tabellen. 12. Der skal tilføjes en post i User tabellen (MembershipProvider). 13. Der skal tilføjes en post i UsersInRoles tabellen (RoleProvider). Disse deltransaktioner ønsker vi at opfatte som én samlet transaktion. Systemet vil blive efterladt i en inkonsistent tilstand, såfremt der f.eks. bliver tilføjet en post i Vikar tabellen, men ikke bliver tilføjet en post i CV tabellen. Hver gang vi fremover vil bede om, at se CV et for den pågældende vikar, vil systemet gå ned. Der forventes jo, at være et CV på samtlige vikarer. Og den eneste måde, hvorpå vi kan skabe et nyt CV er ved at tilføje en ny vikar. Så for at genskabe konsistensen i systemet vil det kræve, at de gennemførte deltransaktioner bliver slettet fra systemet, hvorefter vikaren bliver oprettet på ny. Det vil altså være klart at foretrække, at såfremt samtlige deltransaktioner ikke lykkes, så bliver de gennemførte deltransaktioner rullet tilbage. En totalt mislykket række af ændringer er bedre end en inkonsistent database. Sekvensdiagrammet nedenfor, viser i grove træk, hvorledes tilføjelsen af en ny ansøger foregår. Det må dog anbefales at se på sekvensdiagrammet i bilag 12 side 41, som viser den samme transaktion med flere detaljer. Controller VikarDBManager CVDBManager ØvrigeOplysningerDBManager AdminVikarInfoDBManager MedlemskabsManager RolleManager Kontrolleren laver adskillige kald til forskellige tabelhåndteringsobjekter. Disse sørger så hver især for, at de medsendte informationer bliver gemt ned i tabeller på databasen. Namespace et System.Data.SqlClient, stiller et objekt til rådighed, som kan hjælpe os med at sikre, at samtlige deltransaktioner bliver rullet tilbage, såfremt de ikke alle sammen bliver gennemført. Navnet på dette objekt er SqlTransaction. Objektet har ikke defineret nogen konstruktør. Den eneste måde, hvorpå man kan skabe en instans af det, er som følgende: SqlConnection connection = new SqlConnection(connectionString); connection.open(); SqlTransaction transaction = connection.begintransaction(); // Udfør transaktioner connection.close(); 54

55 Når vi ønsker, at starte en ny transaktion skaber vi et SqlConnection objekt. Når forbindelsen til databasen er åben kan vi skabe et SqlTransaction objekt via returværdien fra kaldet: connection.begintransaction(). Man skal huske at kalde metoden connection.close()når man er færdig. Så vil SqlConnection objektet automatisk blive ryddet af vejen. Glemmer man at lukke forbindelsen vil der med tiden blive flere og flere ubrugte SqlConnection objekter, som fylder op i hukommelsen. Et alternativ til connection.close() er brug af en using erklæring: using (SqlConnection connection = new SqlConnection(connectionString)) connection.open(); SqlTransaction transaction = connection.begintransaction(); // Udfør transaktioner Hermed bliver forbindelsen automatisk lukket ned efter den afsluttende bølgeparentes. Transaktioner skal altid placeres i en try blok. Hvis alle transaktionerne lykkes skal de efterfølgende bekræftes via et kald til transaction.commit(). try // Udfør alle transaktioner transaction.commit(); Går der noget galt undervejs, skal alle gennemførte transaktioner rulles tilbage. Det gøres ved hjælp af en catch blok med et kald til transaction.rollback(): catch transaction.rollback(); Såfremt der forekommer gentagne fejl i systemet bør programmøren have mulighed for, at se en fejlmeddelelse. Man bør derfor altid fange fejlen og fremvise den på brugerens skærm. Det gøres således: catch (Exception e) transaction.rollback(); throw e; Inden vi går videre, vil vi lige sammenfatte ovenstående brudstykker. using (SqlConnection connection = new SqlConnection(connectionString)) connection.open(); SqlTransaction transaction = connection.begintransaction(); 55

56 try // Udfør alle transaktioner transaction.commit(); catch (Exception e) transaction.rollback(); throw e; Vi anvender to forskellige connectionstrings afhængig af om vi tester applikationen via databaser, på vores lokale computere eller via en server. Den ene hedder ConnectionString og den anden hedder ConnectionString1. Når vi ønsker at bruge databasen på vores SQL Server (læs mere herom i tillægget Udgivelse ), så bytter vi om på de to navne i konfigurationsfilen. <connectionstrings> <add name="connectionstring" connectionstring="data Source=mssql.jespermejrup.dk,1433; Initial Catalog = jespermejrupdk; User ID=jespermejrupdk; Password=far5m49c; Network Library = DBMSSOCN" providername="system.data.sqlclient"/> <add name="connectionstring1" connectionstring="data Source=.\SQLEXPRESS;AttachDbFilename= DataDirectory \ASPNETDB.MDF;Integrated Security=True;User Instance=True" providername="system.data.sqlclient"/> </connectionstrings> For at kunne hente en connectionstring fra konfigurationsfilen, skal der i programmet tilføjes en reference til System.Configuration. Herefter får vi adgang til et objekt med navnet: ConfigurationManager. Via dette objekt kan vi hente vores connectionstring med følgende kald: string connectionstring = ConfigurationManager.ConnectionStrings["ConnectionString"]. ConnectionString.ToString(); Vi har adskillige klasser med metoder der gør brug af samme connectionstring. Altid med det formål, at skabe nye SqlConnection objekter. Derfor har vi lavet en klasse med navnet ConnectionManager, som ikke foretager sig andet end at returnere nye SqlConnection objekter. Det gør den via en statisk property, som vi kalder Connection. Klassen ser således ud: public class ConnectionManager public static SqlConnection Connection get return new SqlConnection(ConfigurationManager.ConnectionStrings ["ConnectionString"].ConnectionString.ToString()); 56

57 Følgelig kan vi fremover få fat i et nyt SqlConnection objekt via dette kald: SqlConnection connection = ConnectionManager.Connection; Hermed har vi en ramme om vores transaktioner der ser således ud: using (SqlConnection connection = ConnectionManager.Connection) connection.open(); SqlTransaction transaction = connection.begintransaction(); try // Udfør alle transaktioner transaction.commit(); catch (Exception e) transaction.rollback(); throw e; På kontrolleren har vi en metode, der tilføjer en ny ansøger (en ansøger er en vikar med attributten eransøgninggodkendt = false). Hver gang kontrolleren kalder en metode på en DBManager, så sender den transaktionen med som argument. Hvis en DBManager genererer en undtagelse, så vil kontrolleren opfange det og kalde metoden transaction.rollback(). public void TilføjAnsøger(Vikar vikar, CV cv, ØvrigeOplysninger string password) using (SqlConnection connection = ConnectionManager.Connection) connection.open(); SqlTransaction transaction = connection.begintransaction(); try VikarDBManager.Instans.TilføjAnsøger(vikar, transaction); cv.vikarnr = vikar.nr; CVDBManager.Instans.TilføjCV(cv, transaction); øvrigeoplysninger.vikarnr = vikar.nr; ØvrigeOplysningerDBManager.Instans.TilføjØvrigeOplysninger( øvrigeoplysninger, transaction); AdminVikarInfoDBManager.Instans.TilføjAdminVikarInfo(vikar.Nr, transaction); string brugernavn = vikar.nr.tostring(); string passwordspørgsmål = "Hvem er du?"; string passwordsvar = "Jeg er " + vikar.nr.tostring(); MembershipCreateStatus status = new MembershipCreateStatus(); MedlemskabsManager.Instans.CreateUser(brugerNavn, password, vikar. , passwordspørgsmål, passwordsvar, true, null, out status, transaction); RolleManager.Instans.AddUserToRole(brugerNavn, "Vikar", transaction); transaction.commit(); catch (Exception e) 57

58 transaction.rollback(); throw e; Den første metode som kontrolleren sender transaktionen videre til, er VikarDBManager ens TilføjAnsøger(..). Herfra kaldes så en anden metode findledigtvikarnr(..), hvor transaktionen igen sendes med som argument. internal void TilføjAnsøger(Vikar vikar, SqlTransaction transaction) vikar.nr = FindLedigtVikarNr(transaction); SqlCommand command = transaction.connection.createcommand(); command.transaction = transaction; command.commandtype = CommandType.StoredProcedure; command.commandtext = "Vikar_TilføjAnsøger"; command.parameters.add(new SqlParameter("@Nr", vikar.nr)); // En masse andre parametre tilføjes command.executenonquery(); Når man bruger stored procedures kan man skabe et nyt SqlCommand objekt via returværdien fra metoden transaction.connection.createcommand(). Herefter skal man angive, at kommandoen er en del af den medsendte transaktion: command.transaction = transaction; Der må naturligvis ikke være try/catch blokke i disse metoder. Såfremt der sker en undtagelse, skal den fanges af kontrolleren, som så vil rulle alle andre deltransaktioner tilbage. For alle de øvrige kald der foregår i kontrollerens metode TilføjAnsøger (...), gentages samme procedure. Det har dog været særdeles tidskrævende, at få de to sidste metoder gjort til en del af den samme transaktion: MedlemskabsManager.Instans.CreateUser(brugerNavn, password, vikar. , passwordspørgsmål, passwordsvar, true, null, out status, transaction); RolleManager.Instans.AddUserToRole(brugerNavn, "Vikar", transaction); Som udgangspunkt anvendte vi nemlig Microsofts egen SqlMembershipProvider og SqlRoleProvider. Men da ingen af metoderne hertil kunne tage transaktionen med som parameter, var vi i et dilemma: Hvis systemet går ned umiddelbart efter medlemskab og rolle er tildelt men før transaktionen er bekræftet (transaction.commit()).. så ville oprettelsen af medlemskab og rolle blive gennemført. Men de øvrige deltransaktioner ville blive rullet tilbage. Og vi vil dermed have en inkonsistent database. Vi besluttede derfor, at lave vores egen MembershipProvider såvel som RoleProvider. 58

59 Membership Med Microsofts Membership API kan man på en nem måde lave autorisation af brugere, så kun bestemte brugere kan få adgang til bestemte sider 29. Grundlægende kan man dele Membership API i 4 områder 30 : 1) Sikkerhedskontroller- login kontroller, password kontroller, wizard til oprettelse af bruger og bruger status kontrol. 2) Membership API selv Membership klassen, som udviklerne primært gør brug af, indeholder metoder for at oprettelse af brugerne password m.m. MembershipUser klassen, som indeholder alle informationer om en bruger. 3) Membership providers SQL server Providers eller ens egen provider m.m. 4) Membership Data Store SQL database eller ens egen. Membership API er designet til at virke uafhængigt af en database, dvs. man kan bruge MySQL, Oracle eller andet. Membership API gør brug af Membership provider, som forbinder adgangen til den database som man ønsker at bruge. Alternativet er at lave sin egen Membership API, med tilhørende Membership klasse, MembershipUser klasse etc. Vi valgte meget tidligt i projektets forløb, at vi ville gøre brug af Microsofts Membership API, da vi anså det for at være mest sikre. Generelt Asp.net membership og rolle provider er pr. default SqlMembershipProvider og SqlRoleProvider. Information der vedrører membership, som fx brugernavn, bliver gemt I en autogenereret database, som hedder ASPNETDB.MDF og gemmes I App_Data folderen, med tilhørende tabeller, stored procedures m.m. Hvis man ikke ændrer noget, vil default membership provideren bruge ASPNETDB.MDF databasen. Hvis man allerede har lavet en database, med egne tabeller, vil der være to databaser. De ting der er relateret til membership provideren, fx roller, autentifikation af brugere, oprettelse af nye brugere etc., vil benytte ASPNETDB.MDF databasen, mens resten vil gøre brug af ens egen database Membership-API-Part-1-of-2.aspx 59

60 ASPNETDB.MDF Server Egne tabeller + Stored procedures Da Labvikar kun har én database til rådighed på deres server, valgte vi fra starten af projektet at få alt database trafik til at køre på én database. I praksis gjorde vi det ved at lave vores egne tabeller osv. på ASPNETDB.MDF databasen. Dermed kom det til at se således ud: Server ASPNETDB.MDF s stored procedures, tabeller + Ens egne tabeller, stored procedures m.m. Autogenererede tabeller Vores tabeller Vores udgangspunkt for håndtering af medlemskab var, at det skulle være så simpelt som muligt, og tilbyde grundlæggende funktionalitet såsom tilføjelse af vikarer og superbrugere via hjemmesiden. Vores medlemskabsstyring blev udviklet løbene og kan deles op i 3 trin: 1. Trin Simpel udvikling, få de mest basale funktioner til at virke. 2. Trin Integrering med resten af arkitekturen. 3. Trin Integrering med transaktioner. Nedenfor er der en beskrivelse af de 3 trin: Trin 1 I det første trin opretter vi klasser i App_Code. På ASP.Net siden gør vi brug af en ObjectDataSource, som kalder metoden Insert på vores MembershipUserODS. Vha. Membership objektet kan vi fx få fat på metoden Createuser : namespace MembershipUtilities public class MembershipUserODS [DataObjectMethod(DataObjectMethodType.Insert, true)] 60

61 static public void Insert(string username, bool isapproved,string ) Membership.CreateUser(userName, password, ,passwordquestion..) MembershipUser memebershipuser = Membership.GetUser(userName); Membership.UpdateUser(memebershipUser); I ObjectDataSource bruger man Configure Data Source hvor man vælger MembershipUserODS, og herefter insert metoden Ud fra ASP.Net siden bruger ObjectDataSource til at insætte parameterne: protected void BtnTilføjNySuperbruger_Click(object sender, EventArgs e) ObjectDataSourceMembershipUser.InsertParameter s["username"].defaultvalue = textboxusername.text; ObjectDataSourceMembershipUser.InsertParameter s["password"].defaultvalue = TextBoxPassword.Text; 61

62 Trin 2 I trin 2 integrerede vi hele medlemskabsstyringen med resten af arkitekturen. Oprettelse af fx vikarer og superbrugere blev nu håndteret af kontrolleren: protected void btntilføjnysuperbruger_click(object sender, EventArgs e) string username = TextBoxUserName.Text; string password = TextBoxPassword.Text; Controller.AdminController.TilføjMedlem(userName, , password, passwordquestion, passwordanswer, "SuperUser"); I Controller finder man TilføjMedlem, ud fra kontrolleren bliver MembershipDBManager kaldt: public void TilføjMedlem(string brugernavn, string , string password, string passwordspørgsmål, string passwordsvar, string rolle) MembershipDBManager.Instans.TilføjMedlem(brugerNavn, , password, passwordspørgsmål, passwordsvar, rolle); I MembershipDBManager gør vi via Membership objektet brug af metoden CreateUser : internal void TilføjMedlem(string brugernavn, string , string password, string passwordspørgsmål, string passwordsvar, string rolle) Membership.CreateUser(brugerNavn, password, ,passwordspørgsmål, passwordsvar, isapproved, out status); Roles.AddUserToRole(brugerNavn, rolle); Trin 3 Trin 3 gik ud på, at koble transaktioner på metoderne, så når man opretter en bruger og såfremt noget går galt, sker der en rollback. Vi startede med at koble transaktioner på Tilføj Ansøger. I kontrolleren starter transaktionen og bliver sendt med VikarDBManager i metoden TilføjAnsøger: public class Controller: IAdminController, IOffentligController, IVikarController public void TilføjAnsøger(Vikar vikar, CV cv, ØvrigeOplysninger øvrigeoplysninger, string password) using (SqlConnection connection = ConnectionManager.Connection) connection.open(); SqlTransaction transaction = connection.begintransaction(); try VikarDBManager.Instans.TilføjAnsøger(vikar, transaction); transaction.commit(); 62

63 catch (Exception e) transaction.rollback(); throw e; Ved kaldet til VikarDBManager kommer transaktionen med som parameter, så hvis der går noget galt med skrivning til databasen vil der ske en rollback: class VikarDBManager internal void TilføjAnsøger(Vikar vikar, SqlTransaction transaction) vikar.nr = findledigtvikarnr(transaction); SqlCommand command = transaction.connection.createcommand(); command.transaction = transaction; command.commandtype = CommandType.StoredProcedure; command.commandtext = "Vikar_TilføjAnsøger"; command.parameters.add(new SqlParameter("@Nr", vikar.nr)); command.parameters.add(new SqlParameter("@Fornavn", vikar.fornavn)); command.executenonquery(); Først prøvede vi at gøre brug at de autogenerede stored prodecudes i ASPNETDB.MDF og koble transaktioner derpå. Dog mislykkes det, da vi fandt ud af at MembershipUser CreateUser gør brug af en masse service funktioner, som ligger i Microsofts Membership, som fx EncodePassword. Hvis vi skulle have mulighed for at gøre brug af Microsofts autogenererede Stored procedues og overskrive metoden CreateUser, blev vi nødt til at vide hvilke service metoder og opbygning der skulle til for, at bruge MembershipUser CreateUser. På fandt vi et eksempel på hvordan man kunne lave sin egen Membership Provider med en Access database 31. Med inspiration fra den valgte vi selv at lave vores membership provider, for at få en bedre forståelse for de forskellige service metoder og opbygning af membership provideren. Ud fra ASP siden hvor man opretter en ny ansøger kalder vi kontrolleren protected void btnsend_click(object sender, EventArgs e) ØvrigeOplysninger øvrigeoplysninger = (ØvrigeOplysninger) ViewState ["ØvrigeOplysninger"]; Vikar vikar = (Vikar)ViewState["Vikar"]; CV cv = (CV)ViewState["CV"]; string password = tbxpassword.text;

64 IOffentligController offentligcontroller = Controller.OffentligController; offentligcontroller.tilføjansøger(vikar,cv,øvrigeoplysninger,password); På Controller finder man metoden TilføjAnsøger, hvor vi kalder MedlemskabsManager,som implementerer MembershipProvider klassens metoder til fx oprettelse af brugere. public void TilføjAnsøger(Vikar vikar,cv cv,øvrigeoplysninger øvrigeoplysninger, string password) using (SqlConnection connection = ConnectionManager.Connection) connection.open(); SqlTransaction transaction = connection.begintransaction(); try VikarDBManager.Instans.TilføjAnsøger(vikar, transaction); MedlemskabsManager.Instans.CreateUser(vikar.Nr.ToString(), password, vikar. , passwordspørgsmål, passwordsvar, true, null, out status, transaction); RolleManager.Instans.AddUserToRole(vikar.Nr.ToString(),"Vikar", transaction); transaction.commit(); catch (Exception e) transaction.rollback();throw e; I MedlemskabsManager finder man 2 metoder der hedder CreateUser. For hver metode der er implementeret, er der en tilsvarende metode som har transaktioner. De metoder der ikke gør brug af transaktioner bliver brugt, når man opretter brugere via ASP.Net konfigurationen, mens de metoder der har transaktioner bliver brugt, hvis man opretter brugere via hjemmesiden. ( I Bruger-Guide bilag 2 side 5 kan man se en guide til hvordan man opretter bruger via ASP.NET konfigurations værktøjet) MedlemskabsManager arver fra MembershipProvider og vi implementerer alle dens abstrakte metoder. I Bilag 25 side 84 kan man se koden til metoden MembershipUser CreateUser hvor transaktioner bliver understøttet. Ud fra bilaget kan man også se at vi har lavet vores egne Stored Procedures og tilhørende tabeller i databasen. Opbygningen af disse er mere simple i forhold til Microsofts autogeneredere Stored Procedures m.m. Delkonklussion Vi er klar over at vores udgave af membership provideren ikke er helt så sikker som Microsofts egen. Vores udgave indeholder ikke PasswordSalt. Microsofts default password format er Hash, som gør brug af passwordsalt. I web.config filen kan man erklære om password formaten skal være, Clear, Hash eller Encrypted : 64

65 <membership defaultprovider="medlemskabsmanager"> <providers> <clear/> <add connectionstringname="connectionstring" passwordformat="encrypted" </providers> </membership> Password salt bliver genreret i.net Frameworks RNGCryptoServiceProvider klassen. Når brugeren taster sit password ind i login formen, hentes passwordsalten fra databasen og adderes til det password brugeren har tastet ind. Det bliver så hashed og sammenlignet med det password, der er i databasen. Ifølge Microsoft, er passwords i databaser der er hashed, mindre sårbare overfor angreb 32, end passwords som er encrypted. Vores passwords er encrypted. I bilag 25 side 84 kan man se at vi gør brug en ekstra service metoder, EncodePassword. Grunden til at vi kan bruge den er, at vi fra MedlemskabsManager arver fra membershipprovider: MedlemskabsManager: MembershipProvider Ud fra vores udvikling af membership provideren, har vi fået et bedre indtryk af dens opbygning. Det næste skridt i udviklingen af membership provideren bør være, enten at lave passwordsalt, eller gå tilbage til, at bruge de autogenerede stored prodecudes i default provideren og koble transaktioner på dér, ved brug af de ekstra service funktioner. CMS- Content Management System Vi har lavet et WCM (Web Content Management) system, som LabVikar kan bruge til, at styre indholdet af hjemmesiden. De behøver ikke nogen særlige programmer udover en browser. For at det skal være nemt for LabVikar, skal det ligne noget som de er vant til. Vi har valgt en Rich Text Editor (FCKEditor) til at redigere indholdet. Den ligner til forveksling andre kendte programmer som f.eks. Word. Dette er med til at gøre det grafisk nemt for LabVikars ansatte, at designe siderne. Steder vi har brugt CMS Vi gjort det muligt for LabVikars personale, at redigere i alle offentlige sider, undtagen Bliv vikar. De offentlige sider skal ofte opdateres, fx sider med nyheder, jobopslag m.m. Vi kunne også have gjort det muligt, at ændre beskrivelserne i Bliv vikar, ud for de forskellige felter, men det er sjældent at man ville have brug for det, så det er blevet fraprioriteret. Anvendelse af CMS Når man ser på disse sider, indeholder de ikke andet end en Label

66 Når den enkelte side bliver kaldt, henter serveren indholdet af den enkelte side op fra databasen og lægger den ind i labellen. Det indhold, som ligger i databasen, er HTML-kode, og vil blive vist grafisk når den kommer over på klienten. Forsiden ser således ud: <%@ Page Language="C#" MasterPageFile="~/Masterpages/MasterPage.master" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="OffentligWebsite_Default" Title="Untitled Page" %> <asp:content ID="Content1" ContentPlaceHolderID="ContentPlaceHolder1" Runat="Server"> <asp:label ID="lblTekst" runat="server" Text="Label"></asp:Label> </asp:content> Når Forsiden indlæses, eksekveres følgende kode: public partial class OffentligWebsite_Default : System.Web.UI.Page protected void Page_Load(object sender, EventArgs e) IOffentligCMSController offentligcmscontroller = CMSController.Instans; this.lbltekst.text = offentligcmscontroller.hentside("forside"); Dette stykke kode gør ikke andet end, at bede CMSController om at kalde metoden Hentside(string side) og returnere en streng ud fra parameteren Forside. Vi får nu indholdet af den HTML-kode, som skal vises på forsiden. Det lægges ind i labellen. Når det kommer over til klientens browser, vil labellen være blevet lavet til <span></span>, hvor indholdet fungerer som almindelig HTML-kode. De andre sider ser ud på samme måde. Det er bare en anden parameter vi bruger når HentSide(string side) kaldes. På den her måde har vi en tabel i databasen, hvor hver side er en post. Hver side har et nummer, et navn, og så selve HTML-koden. Tabellen ser således ud: 66

67 For at kunne hente noget fra databasen skal man igennem en CMSController og en CMSDBManager. Metoder på CMSControleren kaldes igennem et interface. Alt efter om man er en offentlig bruger eller en administrator bruges et bestemt interface. Det eneste man kan som offentlig bruger er, at hente sider og interne links. Herudover kan administrator også redigere, tilføje og fjerne interne links. CMSDBManager sørger for alt, hvad der har med databasen at gøre. CMSControler delegerer kald videre til CMSDBManager. Når CMSDBManager skal hente eller skrive i databasen, bruger den ikke sql-sætninger. Vi har en række Stored Procedures som CMSDBManager gør brug af. Den skal så bare sørge for at anvende de rigtige parametre. Når forsiden skal hentes op fra databasen, kaldes Hentside(string side) som ser således ud: public string HentSide(string side) return CMSDBManager.Instans.HentSide(side); Som det kan ses kalder den videre til CMSDBManager og sørger for at den HTML kode, som man får fra CMSDBManager, returneres tilbage til brugergrænsefladen. HentSide(string side) på CMSDBManager ser således ud: class CMSDBManager SqlConnection connection = ConnectionManager.Instans.Connection; SqlDataReader datareader; internal string HentSide(string side) 67

68 SqlCommand command = connection.createcommand(); command.commandtype = CommandType.StoredProcedure; command.commandtext = "CMS_HentSide"; string tekst = ""; command.parameters.add(new SqlParameter("@Side", side)); lock (instans) try connection.open(); datareader = command.executereader(); while (datareader.read()) tekst = datareader["tekst"].tostring() ; catch finally datareader.close(); connection.close(); return tekst; Her sættes først kommandotypen på SqlCommand objektet til at være en Stored Procedure, og derefter hvilken Stored Procedure den skal gøre brug af. sættes så ud fra parameteren side. Vi bruger så DataReader til at eksekvere vores Stored Procedure, og teksten hentes. Til sidst returneres teksten. ALTER PROCEDURE dbo.cms_hentside varchar(50) ) AS Select Tekst from CMS Where Side RETURN En skitse af hvordan koden eksekveres kan ses i bilag 16 side 46. Måden tingene foregår på er den samme, uanset om man skal hente, redigere, tilføje eller slette sider eller interne links. 68

69 Redigering af indhold For at kunne ændre i det indhold, som er på de enkelte sider, har vi lavet siden AdministrerSider.aspx, som ser således ud: Når denne side indlæses, sker der følgende: protected void Page_Load(object sender, EventArgs e) if (!Page.IsPostBack) this.editor.value = admincmscontroller.hentside("forside"); ddlsider.datasource = admincmscontroller.hentalleoverskrifter(); ddlsider.databind(); ddllink.datasource = admincmscontroller.hentalletitler(); ddllink.datatextfield = "Titel"; ddllink.datavaluefield = "Nr"; ddllink.databind(); this.tbxnr.text = ddllink.items[0].value; Her er det i første omgang kun de øverste linier, som er interessante. Først sikrer vi os, at koden kun kører, hvis der ikke er tale om postback. Som før henter vi så indholdet af forsiden og sætter det ind i FCKEditoren. Da der er flere sider at vælge i mellem, vises disse i en dropdownlist. Dette gøres ved, at vi kalder metoden HentAlleOverskrifter() på CMSController, som giver os en liste med de forskellige siders overskrifter. Dropdownlisten databinder så til denne liste. 69

70 Hvis man vil arbejde på andre sider end Forsiden, vælger man en anden side i dropdownlisten, hvorefter følgende kode køres. protected void ddlsider_selectedindexchanged(object sender, EventArgs e) opdatereditor(); private void opdatereditor() this.editor.value = admincmscontroller.hentside(this.ddlsider.selectedvalue.tostring()); Her sættes indholdet ind i FCKEditoren som før. Parameteren sættes ud fra, hvad man der er valgt i dropdownlisten. Når så indholdet er som det skal være, trykker man på Gem og følgende metode kaldes. protected void btngem_click(object sender, EventArgs e) admincmscontroller.redigerside(this.ddlsider.selectedvalue, rettekst(this.editor.value)); opdatereditor(); Her kaldes metoden RedigerSide(string side, string tekst). Siden som skal gemmes er angivet i dropdownlisten, og teksten kommer først igennem metoden rettekst(string tekst), inden den gemmes. Metoden rettekst vender vi tilbage til senere. Derefter opdateres siden igen. For at man kan se hvad man har lavet, uden at gemme ændringerne, har vi lavet en knap til dette Vis Eksempel. protected void btnviseksempel_click(object sender, EventArgs e) Session["Eksempel"] = rettekst(editor.value); Response.Write("<script type='text/javascript'> detailedresults=window.open('eksempel.aspx'); </script>"); Denne metode gemmer det som står i FCKEditoren i sessionen. Derefter åbnes siden Eksempel.aspx i et nyt vindue. Siden indlæses så fra sessionen i stedet for databasen. Anvendelse af Interne Links Vi fandt ud af at LabVikars personale ofte anvender interne links, på deres nuværende hjemmeside. For stadig at give LabVikars personale mulighed herfor, har vi lavet en side, hvorfra man kan administrere de forskellige interne links. 70

71 Her ses hvordan det ser ud (Se en forstørret udgave bilag 17 side 54): For at få vist en liste med de forskellige interne links, beder vi CMSControlleren om en liste med Info objekter, som ser således ud: public class Info private int nr = 0; private string titel = ""; private string tekst = ""; public Info() public int Nr get return this.nr; set this.nr = value; public string Titel get return this.titel; set this.titel = value; public string Tekst get return this.tekst; set this.tekst = value; CMSDBManager sørger for at hente den nødvendige data fra databasen og lave en liste af Info objekter, som returneres til brugergrænsefladen via CMSControlleren. Dette betyder at når siden loades, skal følgende metode kaldes: private void opdaterdatalist() IAdminCMSController admin = CMSController.Instans; DLInfo.DataSource = admin.hentalleinfo(); DLInfo.DataBind(); Denne liste bliver lagt ind i Datalisten DLInfo som ser således ud (Se forstørret udgave af billedet bilag 18 side 54): 71

72 Koden til dette ser således ud. <asp:datalist ID="DLInfo" runat="server" OnEditCommand="DLInfo_EditCommand" OnDeleteCommand="DLInfo_DeleteCommand"> <ItemTemplate> <table border="1" width="500"><tr> <td style="width: 100px"> <asp:label ID="lblNr" runat="server" Text="Nr:"></asp:Label> <asp:label ID="NrLabel" runat="server" Text='<%# Eval("Nr") %>'></asp:label></td> <td style="width: 400px"> <asp:label ID="lblTitel" runat="server" Text="Titel:"></asp:Label> <asp:label ID="TitelLabel" runat="server" Text='<%# Eval("Titel") %>'></asp:label></td></tr><tr> <td colspan="2" style="height: 100px; background-color: #ffffff"> <asp:label ID="TekstLabel" runat="server" Text='<%# Eval("Tekst") %>'></asp:label></td></tr>tr> <td colspan="2" style="height: 26px"> <asp:button ID="btnRediger" runat="server" CommandName="Edit" Text="Rediger" Width="60px" /> <asp:button ID="btnSlet" runat="server" Text="Slet" Width="60px" CommandName="Delete" /></td></tr> </table> <cc1:confirmbuttonextender ID="ConfirmButtonExtender1" runat="server" TargetControlID="btnSlet" ConfirmText="Er du sikker på at denne post skal slettes?" > </cc1:confirmbuttonextender> </ItemTemplate> </asp:datalist> For ikke at miste overskueligheden, kan man vælge at fjerne indholdet af de interne links, fra datalisten. I stedet kan man så have en Vis-knap ud for hvert link, hvor et tryk medfører at man kommer ind på en ny side hvor indholdet vises. For at redigere indholdet af et link, har vi fået knappen btnrediger til at generere en Edit event på følgende måde: : CommandName="Edit". (Property på knappen) OnEditCommand="DLInfo_EditCommand" (Property på datalisten) 72

73 Det samme gælder også for slet-knappen. Denne event opfanger Datalisten og kører så følgende metode: protected void DLInfo_EditCommand(object source, DataListCommandEventArgs e) IAdminCMSController admin = CMSController.Instans; Info info = (admin.hentalleinfo())[e.item.itemindex]; Session["linkstatus"] = "Rediger"; Session["linknr"] = info.nr; Session["linktitel"] = info.titel; Response.Redirect("AdministrerIndhold.aspx"); Her hentes en ny liste med alle Info objekter. Vi bruger det objekt i infolisten, som har et index svarende til det fra datalisten. Da vi bruger den samme side til både at redigere eksisterende links og lave nye, er vi nødt til at sende strengen Rediger videre til næste side via Session objektet. Ligeledes sendes nummer og titel med videre til siden AdministrerIndhold.aspx. Når denne side loades sker følgende: protected void Page_Load(object sender, EventArgs e) if (!Page.IsPostBack) if (Session["linkstatus"].ToString() == "Ny") Editor.Value = ""; this.tbxtitel.text = ""; this.lblnr.visible = false; this.tbxnr.visible = false; if (Session["linkstatus"].ToString() == "Rediger") Editor.Value = CMSController.Instans.HentInfo( int.parse(session["linknr"].tostring())); this.tbxnr.text = Session["linknr"].ToString(); this.tbxtitel.text = Session["linktitel"].ToString(); this.lblnr.visible = true; this.tbxnr.visible = true; 73

74 Da vi ikke skal lave et nyt link, men kun redigere dets indhold, er det kun den nederste del af koden, som udføres. Først bruger vi CMSControlleren til at få indholdet vist i FCKEditoren. Dette gøres med metoden HentInfo(int nr). Derefter trækkes nummeret og titlen ud af sessionen og bliver vist på siden. Nummeret vil kun blive vist, hvis man redigerer indholdet af et link. Dette skyldes at linket først får et nummer, når man trykker på Gem. Gem knappen ser således ud: protected void btngem_click(object sender, EventArgs e) if (Session["linkstatus"].ToString() == "Ny") CMSController.Instans.TilføjInfo(this.tbxTitel.Text, Editor.Value); Response.Redirect("AdministrerInterneLinks.aspx"); if (Session["linkstatus"].ToString() == "Rediger") CMSController.Instans.RedigerInfo( int.parse(session["linknr"].tostring()), Session["linktitel"].ToString(), this.tbxtitel.text, this.editor.value); Response.Redirect("AdministrerInterneLinks.aspx"); Her undersøges først, om man er ved at lave et nyt link, eller om man er I gang med at redigere et. Hvis det drejer sig om et nyt link, kalder vi metoden TilføjInfo(string titel, string tekst) på CMSControlleren, som sørger for, at det kommer i databasen, samt at der bliver tildelt et nummer til linket. Hvis man redigerer et link kaldes metoden RedigerInfo(string nr, string gammeltitel, string nytitel, string tekst) på CMSControlleren, som sørger for, at posten med linket i databasen bliver rettet til de nye værdier. Hvis man annullerer, bliver man bare dirigeret tilbage til siden AdministrerInterneLinks.aspx Hvis man så vil gøre brug af disse interne links, skal man gå tilbage til siden AdministerSider.aspx. I dropdownlisten kan man vælge et internt link. Man får så vist dets nr. nedenfor (se billede til højre). 74

75 protected void ddllink_selectedindexchanged(object sender, EventArgs e) this.tbxnr.text = this.ddllink.selectedvalue; Man kan så i FCKEditoren skrive -#7;Laborant søges#-, på samme måde som beskrevet på siden. Når man trykker på Gem kommer teksten fra FCKEditoren igennem metoden rettekst(string tekst) som beskrevet tidligere. Rettekst(), er den metode, som omdanner de link koder, der står i FCKEditoren, til reelle links. private string rettekst(string tekst) string start = tekst; try int første = start.indexof("-#"); if (første!= -1) int semikolon = start.indexof(";", første); int slut = start.indexof("#-", første); int tal = int.parse(start.substring(første + 2, (semikolon - første - 2))); string indhold = start.substring(semikolon + 1, slut - semikolon - 1); string del1 = start.substring(0, første); string del2 = "<a href=\"../offentligwebsite/indhold.aspx? nr=" + tal + "\">" + indhold + "</a>"; string del3 = this.rettekst(start.substring(slut + 2)); return del1 + del2 + del3; catch return tekst; Først tjekkes der for om -# findes i teksten og hvilket indeks det har i teksten. Hvis det eksisterer, finder man herefter indekset af det første ;, som kommer efter -#, og derefter indekset for første gang #- findes efter -#. Linknummeret tages nu ud af teksten, der ligger mellem -# og ;. Og derefter indholdet som er teksten der ligger mellem ; og #-. Teksten deles nu op i tre dele. DEL1: alt tekst før linket. DEL2: selve linket. DEL3: alt tekst efter linket. 75

76 Del2 bliver nu udskiftet med et HTML link hvor tallet før ; skrives i url en og teksten efter ; skrives i selve linket. Da der kan være flere af denne slags links i samme tekst, køres metoden igen på del3. Derefter bliver delene sat sammen igen og returneret. Dette giver problemer, hvis der er flere links, hvor der mangler et ; i det første af linkene. Så vil resten af teksten ikke blive tjekket igennem for flere links. Derfor valgte vi at ændre på metoden så den nu ser således ud: private string rettekst(string tekst) string start = tekst; try int første = start.indexof("-#"); if (første!= -1) int semikolon = start.indexof(";", første); int slut = start.indexof("#-", første); string del1 = start.substring(0, første); string del2 = start.substring(første, slut + 2- første); ; string del3 = this.rettekst(start.substring(slut + 2)); if (semikolon!= -1 && semikolon < slut) int tal = int.parse(start.substring(første + 2, (semikolon - første - 2))); string indhold = start.substring(semikolon + 1, slut - semikolon - 1); del1 = start.substring(0, første); del2 = "<a href=\"../offentligwebsite/indhold.aspx? nr=" + tal + "\">" + indhold + "</a>"; return del1 + del2 + del3; catch return tekst; Forskellen her er, at vi tidligt laver de 3 dele, uden at indholdet af dem er ændret til nye værdier. Derefter tjekker vi om der er ;, og kun hvis der er det, og det vel og mærket kommer før #-, så vil der bliver lavet et HTML-link. Ellers forbliver det uændret. FCKEditor FCKEditor er en web-baseret text editor, som ikke kræver noget installeret på klienten, udover en nyere browser 33. Den minder meget om et almindeligt tekstbehandlingsprogram, som f.eks. Word,

77 hvilket LabVikars personale har kendskab til. Dette er med til at gøre overgangen fra FrontPage til FCKEditoren nemmere. Derfor er det en smart løsning til dem, som ikke har det store kendskab til IT. Det er også med til, at give dem mulighed for, at ændre indholdet på hjemmesiden løbende. (FCKEditor). Der er nogle steder, hvor vi har været nødt til at ændre lidt ved FCKEditoren. (Microsoft Word). I fckconfig.js FCKConfig.ToolbarSets, hvor man har mulighed for at ændre de ikoner som der bliver vist. _FileBrowserLanguage, hvor vi har sat den til aspx. _QuickUploadLanguage, hvor vi også har sat den til aspx. Dette er gjort da det bliver brugt på en aspx side. Som man kan se i Bruger-Guide i bilag 5 side 71, er det en meget let og overskuelig måde, at håndtere indholdet af hjemmesiden på. 77

78 Regler for brug af FCKEditoren FCKEditoren er gjort tilgængelig via: Open Source License. Commercial License. Open Source License Her gøres brug af tre forskellige licenser, nemlig GPL 34, LGPL 35 og MPL 36. Disse giver mulighed for, at gøre brug af editoren gratis, så længe man overholder de regler, som editoren er blevet udsendt under. Commercial License Her gøres brug af CDL 37, som giver virksomheden mulighed for: At ændre FCKEditoren, uden at skulle udgive den under Open Source License. Man slipper for at vedlægge LGPL license. Man behøver ikke at referere til FCKEditor. Man må udgive den uden kilde kode. Man må fjerne hvilken som helst fil fra FCKEditoren 38. Der er flere grunde til, at man skal vide, hvilken licens der skal gøres brug af: Man ønsker ikke at blive sagsøgt for at bryde rettighederne til programmet. Man har undersøgt cost / benefit. Der kan komme opdateringer til FCKEditoren, som bør installeres. Dette kan være rettelser til kritiske områder af programmet. Derfor bør man på forhånd have gjort op med sig selv, om man selv vil stå for opdatering, eller om man vil betale sig fra det. Man har dog også mulighed for, at videreudvikle på programmet, hvis man ønsker det, da man har fuld adgang til kildekoden. Dette kræver dog, at man enten selv skal gøre det, betale sig fra det, eller følge med i hvad der sker i forbindelse med videre udvikling af programmet. Delkonklusion Vi synes vi har fået lavet en løsning til LabVikar, som gør det nemt for dem, at ændre indholdet af de forskellige sider, hvor det er relevant. Man bør overveje om LabVikars personale, skal have mulighed for, at ændre teksten, eller beskrivelserne ud for de forskellige tekstfelter, i forbindelse

79 med BlivVikar-siderne. Her kunne man have brugt en løsning med nogle tekstfelter, hvori man kunne skrive, hvad der skulle stå ved de enkelte felter. Det som der mangler i forbindelse med CMS systemet, er muligheden for at tilføje nye sider. Som det er nu, er der et bestemt antal sider, som LabVikar kan styre indholdet af, men de har hverken mulighed for at tilføje eller fjerne eksisterende sider. Hvis de vil have en ekstra side, er de nødt til at lave den som et internt link, og linke til den fra en af de andre sider. Vi ser FCKeditoren som en ideel løsning til LabVikar, da der ikke er nogle juridiske problemer i forhold til, at gøre brug af den under Open Source Licensen, som vi har valgt at gøre brug af. Den hjælper i overgangen fra en Frontpage- til en CMS baseret hjemmeside, da de to programmer minder meget om hinanden i den grafiske opbygning. Ajax Definition af Ajax Websites baseret på ASP.NET er traditionelt serverbaserede. Det betyder at alt funktionaliteten ligger på serversiden. Hver gang der skal være en form for behandling af data, af den ene eller anden art, bliver data sendt til serveren, hvor den bliver behandlet og derefter returneret. Denne form for web-applikation er synkron. Det betyder, at når en klient har sendt en forespørgsel til serveren, kører klienten ikke videre før den har fået et svar. Det ser således ud: Når man gør brug af Ajax-teknologien gør man klienten mindre afhængig af serveren. Dette gøres ved at flytte noget af håndteringen over på klientsiden. Og lade kommunikationen mellem klient og server være asynkron. Dette betyder at når klienten laver en forespørgsel til serveren, behøver klienten ikke at vente på svar for at kunne arbejde videre. Man kan lade enkelte kontroller opdatere, når svaret kommer retur, i stedet for at opdaterer hele siden. 79

80 Når der er et kald fra brugeren sker det i første omgang lokalt. Ajax enginen tager så stilling til, om det kræver et kald til serveren, eller om det er noget den kan håndtere lokalt. AJAX står for Asynchronous JavaScript and XML. Ajax gør brug af en række andre teknologier, som har hver deres funktion. Disse er: XHTML og CSS som udgør markup DOM som udgør præsentation og interaktion XML og XSLT håndterer dataudveksling og manipulation JSON håndterer marshalling af objekter XMLHttpRequest håndterer den asynkrone kommunikation JavaScript er kittet som holder det hele sammen. Fordelen ved at køre asynkront i forhold til synkront mærkes tydeligt ved, at man ikke skal vente på svar fra serveren. 80

81 Brugeren kan sende en forespørgsel om eksempelvis at få opdateret en liste med navne. Man sender så en forespørgsel til ajax engine, hvor den bedømmer om det kan gøres lokalt eller om den skal have fat i serveren. I dette tilfælde vil ajax engine lave et kald til serveren. Imens ajax engine venter på at få listen returneret af serveren, vil den vise brugeren at kaldet er sendt og man venter på svar. Dette kan gøres ved at vise brugeren et billede. Når så svaret kommer tilbage fra serveren, sørger ajax engine automatisk for at det bliver vist for brugeren. Det kan så såleds ud: 81

82 Det betyder at man får: En bedre oplevelse af interaktion En større funktionalitet på serversiden En forbedret integration af webtjenester på klientsiden En brugeroplevelse som ligger tæt på det man kender fra Windows-applikationer Hvorfor gør vi brug af Ajax? Ajax er på ingen måde en nødvendighed for, at vi kan lave et website, som opfylder LabVikars krav til hvad sitet skal kunne. Det har altså ikke indflydelse på hvad serveren kan. Grunden til at vi gør brug af Ajax-teknologien er på grund af brugeroplevelse. Et af LabVikars krav er at siden skal være meget brugervenlig. Ajax er med til at gøre det nemmere for os, at tilføje websitet grafiske elementer uden at det går ud over brugervenligheden. I det hele taget giver Ajax websitet et løft, der gør brugeroplevelsen bedre. Hvor vi gør brug af Ajax Vores Accordion Panel er fra Ajax Control Toolkittet. Vi bruger Accordion Panel når vi vil have vist en bestemt ansøgning som er blevet oprettet. Accordion Panel gør det nemmere for os, at bevare overblikket over ansøgningen da det nemt vil komme til at fylde meget, hvis både Ansøgers oplysninger og Ansøgers CV skal vises samtidigt. På denne måde kan kun se enten almindelige oplysninger eller cv, ikke begge dele på en gang. 82

83 Hvordan gør vi brug af Ajax Der hvor man vil have sin accordion trækker man den bare ind fra toolboxen. For at lave Panes (de paneler som skal vises) vælger man i første omgang Collection ved Panes og tilføjer dem man vil have. På grund af en fejl i toolkittet laves disse panes ikke ordenligt i Sourcen. De to tag s <Panes> og </Panes> kommer ikke med, så dem skal man selv lave for at Accordion forstår hvad en AccordionPane er. Problemet er at hver gang man laver noget der har med Accordion at gøre i Design Mode forsvinder de 2 tag s igen. <cc1:accordion ID="Accordion1" runat="server" Height="88px" Width="229px"> <Panes> <cc1:accordionpane ID="InfoPane" runat="server" ContentCssClass="" HeaderCssClass=""> </cc1:accordionpane> <cc1:accordionpane ID="CVPane" runat="server" ContentCssClass="" HeaderCssClass=""> </cc1:accordionpane> </Panes> </cc1:accordion> 83

84 For at gøre brug af de panes man laver skal man så tilføje Header og Content tags: <cc1:accordionpane ID="InfoPane" runat="server"> <Header> Overskrift </Header> <Content> Indhold </Content> </cc1:accordionpane> Accordion Pane henviser til en StyleSheet, hvor vi har defineret dens design. <cc1:accordion ID="Accordion1" runat="server" SelectedIndex="0" Visible="false" HeaderCssClass="accordionHeader" ContentCssClass="accordionContent" FadeTransitions="false" FramesPerSecond="80" TransitionDuration="100" Width="100%" AutoSize="None" RequireOpenedPane="false" SuppressHeaderPostbacks="true"> Installations vejledning til Ajax kan ses i Bruger guide side 2. Flere Sprog LabVikar har flere udenlandske vikarer og vil gerne ekspandere yderligere. Derfor ønsker de en hjemmeside, hvor er mulighed for at have flere sprog. Dette har vi dog ikke lavet, men vi har et forslag til hvordan det kan gøres. I databasen vil vi i stedet for en tabel, hvor der kun er nr., Side og Tekst, vil vi nu også have en kolonne som angiver hvilket sprog de forskellige sider er skrevet i. Tabellen kunne se således ud: 84

85 I stedet for kun at hente eller redigere sider, med sidens navn som parameter, vil det også være muligt at angive hvilket sprog siden skal bruge. På MasterPagen kan der være et sted, hvor man har mulighed for at vælge hvilket sprog man foretrækker. Dette sprog kan så gemmes i en cookie, så serveren altid ved, hvilket sprog der skal anvendes, uanset hvilken side man er på. På denne måde er det dog ikke alt indhold på siderne som ændrer sprog. Inde på siden Bliv Vikar vil teksten på kontrollerne forblive på dansk. En måde at løse dette problem på er ved at bruge lokale ressource filer. Ressourcefiler Vi vil vise hvordan man kan få serveren til selv at skrive teksten ud for de to første felter i blivvikar1.aspx enten på dansk eller engelsk alt efter hvilket sproget ens browser er sat op til at køre med. Nu ser det således ud: Det er disse to labels som vi vil ændre: <asp:label ID="Label1" runat="server" Text="Fornavn og mellemnavne *" Width="114px" CssClass="Overskrift2" ></asp:label> <asp:label ID="Label2" runat="server" Font-Bold="True" Text="Efternavn *" CssClass="Overskrift2"></asp:Label> Som det første vil vi lave en asp-mappe kaldet App_LocalResources. Denne mappe lægges i mappen OffentligWebsite da det er her siden BlivVikarTrin1.aspx ligger. Her i laver vi 2 ressourcefiler kaldet henholdsvis: BlivVikarTrin1.aspx.resx BlivVikarTrin1.aspx.en.resx BlivVikarTrin1.aspx.resx indeholder den danske tekst og er den fil som vil blive læst per default. BlivVikarTrin1.aspx.en.resx indeholder den engelske tekst. Den internationale forkortelse for sproget engelsk er en, hvilket er tilføjet til ressourcefilens navn. 85

86 BlivVikarTrin1.aspx.resx ser således ud: Og BlivVikarTrin1.aspx.en.resx ser således ud: I Sorcekoden vil vi nu tilføje henholdsvis meta:resourcekey="label1" og meta:resourcekey="label2" til de to labels. Vi har her fortalt de to labels hvilken række de skal hente teksten fra. <%@ Page Language="C#" MasterPageFile="~/Masterpages/MasterPage.master" AutoEventWireup="true" CodeFile="BlivVikarTrin1.aspx.cs" Inherits="OffentligWebsite_BlivVikarTrin1" Title="Bliv vikar trin 1" Culture="auto:da-DK" UICulture="auto"%> Vi ændrer nu den øverste linie på siden til at se således ud. Det jeg har gjort er at sætte værdier på de to properties Culture og UICulture. UICulture bestemmer hvilket sprog klientens browser skal bruge. Her sætter vi den til at hente det automatisk fra klienten. Culture bestemmer hvilken ressourcefil der skal bruges. Den sættes til automatisk, at bruge den som passer med det sprog som UICulture er sat til, samt at default er dansk. De betyder at hvis man bruger et andet sprog end engelsk i det her tilfælde, vil sproget være dansk. Vi sætter nu Browserens sprog til at være Engelsk og de 2 første felters beskrivelse ser nu således ud. Dette skal selvfølgelig gøres med alle de andre labels men det kan også bruges til at ændre teksten på knapper, links eller andre ting. Og så er det ellers bare at lave ressourcefiler for de sprog som man gerne vil have med. 86

87 Delkonklusion Hvis vi skulle have gjort brug af nogle af de ovennævnte metoder til, at lave et website med flere sprog, skulle det have været gjort fra start af. Som det er nu, hvor hele websittet mere eller mindre er færdiglavet vil der være en del arbejde i at lave flere sprog, da der vil være en del klasser som vi skulle lave om. Havde vi gjort det fra start af, ville der ikke være ret meget ekstra arbejde i, at tage flere sprog med. 87

88 TEST "At teste er processen at vurdere et system, manuelt eller maskinelt, for at afgøre om det opfylder specifikationerne, og hvis ikke, dokumentere forskellene" -IEEE's ordbog For at kunne være sikker på at programmet virker som forventet, er det vigtigt at udføre relevante tests på programmet. Vi har udført en funktionel og brugervenlighedstest. Det er i praksis ikke muligt at bevise, at et program er fejlfrit. De forskellige test kan blot påvise at programmet virker som ønsket også i mere usædvanlige situationer. Funktionalitets test Målet er at teste, om systemet virker efter hensigten og se om systemet opfylder kravspecifikation. I praksis har vi gjort det ved at gennemgå systemets enkelte funktioner for hver gang vi fik programmeret ny funktionalitet og en samlet test til sidst. I starten gennemførte vi testene på vores egne computere, men anså resultaterne for at være ubrugelige, fordi vi ikke kunne være sikker på om funktionaliteten også vil fungere på tilsvarende måde når det kom ud på en server. Vi valgte derfor at købe en webhotel som svarer til det Labviar har 39 og gennemførte testene via det. For de enkelte funktioner( fx Tilføj, Opdater mm) så vi om indput og output svarede til det forventede. Denne test er også kendt som blackbox testing, da man er ligeglad med selve implementeringen af koden, men kun interesserer sig for om programmet opfører sig som forventet i GUI en. Ved nogle andre dele af testen brugte vi Gray Box Testing, hvor vi gik ind i koden, tilføjede eller fjernede noget at den og så om indput/output svarede til det forventede. Fx fjernede vi expression valideringen og tastede tegn ind, som vi anså for at være invalide. Resultatet af den funktionelle test kan ses på bilag 20 side

89 Samtidighedstest Udover funktionalitets test har vi også opstillet forskellige scenarier som vi gik igennem for at teste samtidighed. Et af scenarierne bestod i at vi alle loggede os ind i systemet og redigerede i fx den samme kunde. Resultatet af dette var, at hvis en anden person i mellemtiden havde redigeret en bestemt kunde, fik den sidste person der prøvede at redigere, en besked på, at der var sket en ændring i mellemtiden, og fik valget med at overskrive med en egne oplysninger, eller beholde den forrige ændring: Se en forstørret udgave i bilag 32 side 95: Brugervenligheds test It's really hard to design products by focus groups. A lot of times, people don't know what they want until you show it to them. - Jesse James Garrett, Steve Jobs, 1998 Det er svært at lave en præcis test for brugervenlighed, da der ikke er nogle værdier, man kan måle på. Vi har valgt at teste brugervenlighed ved at observere slutbrugerne - Jesse og James få kommentarer Garrett, 2002 fra dem, mens de benyttede programmet. I brugervenlighedstesten interviewede vi brugeren om deres opfattelse af programmet og benyttede tænke højt Stanford test. Testen Persuasive foregår Technology ved at brugerne Lab, 2002 skal løse nogle specifikke opgaver, fx ansøge om at blive vikar, og prøve at beskrive deres tanker og deres erfaringer mens de bruger programmet. Resultatet af testen af 1. iteration, kan læses i bilag 21 side

90 Fremgangsmåde For at sikre at brugervenligheds-succeskriterierne blev opfyldt i så stort omfang som muligt, har vi arbejdet med forskellige faser inden for brugervenlighed. Da kunden ikke havde et klart ønske om funktioner, informationer og lignende, brugte vi en fase kaldet koncepttest Her blev der lavet en prototype af skærmbillederne hvor vi visuelt kunne få noget feedback fra kunden og se om vi havde fat i de rigtige ting og for at se om det kunne dække kundens behov. Vi prioriterede meget højt, at vi løbende tilpassede web-løsningen til kundens og brugernes forudsætninger, forventninger, behov og ønsker. Derfor vendte vi tilbage til nogle faser når brugervenligheds testen fx afslørede tvivlsspørgsmål. Når der forekom tvivlsspørgsmål fremlagde vi nogle konkrete løsninger til kunden. Hvis løsningen blev accepteret blev den implementeret i web-løsningen og vi gennemførte en ny brugervenlighedstest eller accepttest. Brugervenlighedsarbejdets faser Bruger venligheds krav Bruger venligheds test Koncepttest Accepttest Drift Brugervenligheds krav: Brugerne blev interviewet hvor vi fik et indtryk af målgruppens forudsætninger, ønsker og behov. Koncepttest: Under udviklingsprojektet blev der udviklet en prototype af skærmbillederne, for at fjerne oplagte problemer i brugergrænsefladen. Herved kunne vi afgøre om brugerne accepterede skærmbillederne (herunder illustrationer, eksempler, indhold og navigation mm). I denne fase var det nemmere og mere tids besparende, at fjerne og finde problematiske elementer end når først iterationen var færdig kodet. Brugervenligheds test: Når vi vurderede, at iterationen var færdig, lavede vi en tænke højt test med slutbrugerne. Her fik vi afklaret om de kunne finde rundt på siden og om funktionalitet, tekst og indhold var forståeligt, samt om deres behov og ønsker var blevet afdækket. 90

91 Accepttest: Efter brugervenlighedstesten var gennemført, lavede vi om nødvendigt yderligere ændringer, i den givne iteration. Herefter lavede vi en accepttest med kunden, hvor vi fremlagde de eventuelle ændringer. Til sidst i projektperioden lavede vi endnu en accepttest, ud fra det samlede resultat. I bilag 26 side 86, kan ses et eksempel ud fra iteration 1, hvordan vi gennemførte denne fremgangsmåde. Unit Test Vi har valgt ikke at sætte fokus på unit test. En af de vigtigste grunde til at indarbejde automatiserede testrutiner, er den effektivitetsforøgelse man opnår. Hvis man som udvikler skal rette fejl i en applikation, kan det have stor betydning, om det er kode man lige har lavet, eller om det er noget man har lavet for flere år siden. Med den gamle kode, som umiddelbart ikke ligger i erindringen, kan det tage lang tid, at finde fejl. Udover den øgede effektivitet ved fejlfinding, kan Unit Test også være med til at begrænse antallet af fejl i koden. Når et system er stort og kompliceret og man skal udbygge det med yderligere funktionalitet, kan man nemmere via Unit Test se om det ekstra funktionalitet har nogle sideffekter på de andre funktioner. Selv med kraftig anvendelse af Unit Test vil det nok være umuligt at garantere, at ens kode er fejlfri. Den kan selvfølgelig sagtens være fejlfri i den forstand, at den udfører et stykke arbejde uden fejl. Andre test Cookies Ved nogle funktioner forventede vi at informationerne bliver gemt i midlertidige cookies. Midlertidlige cookes bliver fjernet fra computeren så snart brugeren lukker for browseren. De bruges kun på sider hvor der skal gemmes midlertidige oplysninger. I Firefox installerede vi et plugin View Cookie, hvor vi kunne se om oplysningerne blev gemt som forventet. 91

92 Transaktioner Det er svært at teste alle transaktioner og om der vil ske en rollback i alle tænkelige situationer. Vi har testet transaktionerne ved at tilføje en Exception. Ved hver enkelt metode tilføjede vi følgende kode linje: throw new Exception("Der skal ske en rollback ved xxxxxx"); Vi tilføjede ovennævnte kodelinie i nogle metoder og afprøvede dem derefter. Eksempel: I VikarDBManager: internal Vikar TilføjAnsøger(Vikar vikar, SqlTransaction transaction) vikar.nr = findledigtvikarnr(transaction); SqlCommand command = transaction.connection.createcommand(); command.transaction = transaction; command.commandtype = CommandType.StoredProcedure; command.commandtext = "TilføjAnsøger"; command.parameters.add(new SqlParameter("@Nr", vikar.nr)); command.parameters.add(new SqlParameter("@Fornavn", vikar.fornavn)); command.parameters.add(new SqlParameter("@Efternavn", vikar.efternavn)); command.executenonquery(); throw new Exception("Der skal ske en rollback ved TilføjAnsøger"); return vikar; Når vi genererede en Exception i en metode, kørte programmet og f.eks. tilføjede en ny vikar, gik systemet i Debug mode, hvor vi kunne se at der blev lavet en rollback. 92

93 Herefter kunne vi konkludere at transaktionen fungerede som forventet. Hvis der fx skulle ske en strømafbrydelse midt i en handling vil der ske rollback. Del konklusion Selvom test var en naturlig integreret del af vores daglige programmering, mener vi at vi burde have integreret Unit Test i vores arbejdsgange. Vi mener at vi kunne have sparet en del tid, hvis vi fra starten af projektet havde valgt at bruge Unit Test. Vi kunne have undgået at udføre de samme funktionalitets test mange gange, hvilket vi gjorde næsten hver gang vi implementerede noget nyt. 93