CampIT - Et administrationssystem. Gruppe E2-109 Aalborg Universitet

Transkript

1 CampIT - Et administrationssystem Gruppe E2-109 Aalborg Universitet 19. december 2002

2 Det Teknisk-Naturvidenskabelige Fakultet Aalborg universitet Titel: CampIT Et administrationssystem Tema: Udvikling af programmel Projektperiode: Informatik, 3. semester (Inf 1) 3. september 19. december 2002 Projektgruppe: E2-109 Synopsis: Deltagere: Trine Buus-Pedersen Jacob Jensen Mads Christensen Bo Thomassen Thomas Madsen John Persson Dette projekt omhandler udviklingen af et administrationssystem, til en campingplads i Løkken. I projektforløbet er der anvendt metoden Objektorienteret Analyse og Design. Rapporten indeholder analysen, designet, implementeringen og testen for det resulterende system. Systemet kan administrere arbejdsopgaver såsom reservation, check-ind, check-ud og udregne pris for ophold på campingpladsen. Til implementeringen er der anvendt det objekt orienterede programmeringssprog Java2. Systemet er afslutningsvist blevet black box testet, og usability testet. Søren Holm Vejleder: Simonas Saltenis Oplagstal: 10 Sideantal: 85 Bilagsantal og -art: én cd-rom Afsluttet: den

3 Forord Den følgende udviklingsrapport er udarbejdet i forbindelse med et INF 1 projekt, på Department of Computer Science, på Aalborg Universitet i perioden 3.september til 19.december Projektet omhandler udviklingen af et administrationssystem til en campingplads, som er beliggende i Nordjylland. Rapporten er udarbejdet på baggrund af udviklingsmetoden, Objektorienteret Analyse og Design, hvilket betyder, at der forefindes en udviklingsrapport bestående af et analysedokument, et designdokument samt en implementerings- og testdel. Derudover er der vedlagt en studierapport, som behandler de akademiske aspekter af projektforløbet. På den vedlagte cd-rom findes det resulterende program med dokumentation, kildekode samt den tilhørende database. 3

4 Indholdsfortegnelse Del I: Analyse Opgaven Formål Systemdefinition Omgivelser Problemområde Anvendelsesområde Struktur Klasser Plads Campingpasindehaver: Reservation: Aktiviteter Hændelser Anvendelsesområde Brug Oversigt Aktører Brugsmønstre Funktioner Komplet funktionsliste Specifikation af funktioner Brugergrænsefladen Dialogform Systemgrænseflader Den tekniske platform Del II: Design Opgaven Formål Rettelser til analysen Kvalitetsmål Teknisk platform Udstyr Basisprogrammel Systemgrænseflade Designsprog Arkitektur Komponentarkitektur Komponent Brugergrænseflade Komponent Funktion Komponent Model Komponent Teknisk platform Standarder Komponent Model Struktur Relationer Klasser

5 7.2.1 Plads Reservation Campingpasindehaver Pladsstatus Aktivitet Gæld Gældspost Betalingsgenstand Indbetaling Komponent Teknisk platform, DatabaseTolk Struktur Klasser DBForbindelse DatabaseTolke Komponent Teknisk platform, Systemgrænseflade Klasser MagnetkortlæserGrænseflade CompuSoftGrænseflade: Komponent Funktion Struktur Klasser CheckInd TildelPlads FindLedigePladser DagensBetalere Omsætning Operationsspecifikationer CheckInd TildelPlads FindLedigePladser DagensBetalere Omsætning Komponent Brugergrænseflade Struktur klasser HovedVindue Actions ForsideSide LedigePladserFaneblad DagensHændelserFaneblad DagensOmsætningFaneblad ReservationVindue CheckIndVindue PladsstatusVindue KundekartotekVindue AktiviteterVindue ØkonomiVindue IndstillingerVindue IndstilPriserFaneblad IndstilPladserFaneblad

6 Del III: Implementering og Test Implementering Afgrænsning Struktur Kodestandard Komponent Model Komponent DatabaseTolk Komponent Systemgrænseflade Komponent Brugergrænseflade Kodetest Kodetest Resultater Brugervenlighedstest Resultater Negative resultater Det videre arbejde Kildeliste Bøger Internetsider

7 Del I: Analyse 7

8 1 Opgaven 1.1 Formål Produktet, der skal udarbejdes, er et IT-system til at håndtere reservation- og administration for Action House Camping. Action House Camping er en endnu ikke åbnet campingplads. Beliggenheden for campingpladsen er en badeby i Nordjylland, og vil både være en familie- og en ungdomscampingplads. Campingpladsens ejere ønsker et IT-system, der er i stand til at understøtte den administrative hverdag, og som derfor dækker reservation af pladser, check ind og check ud samt oversigt over alle pladser på campingpladsen (både ledige og optagede) samt oversigt over både aktuelle og tidligere campingpasindehavere. Derudover vil de gerne have, at IT-systemet giver mulighed for at lave prisberegning. I forbindelse med de aktiviteter campingpladsen afholder, vil de gerne, at oversigt over disse og tilmelding dertil kan håndteres af systemet. Derudover vil det være brugbart for campingpladsen, at det er muligt at reservere en plads via Internettet, dels som en service til de der ønsker at benytte campingpladsen, og dels for at lette administrationens eget arbejde med at modtage reservationer via telefonen. 1.2 Systemdefinition Der ønskes et IT-system, hvor følgende gør sig gældende: Et IT-system til brug på en campingplads til at håndtere daglige arbejdsopgaver såsom oversigt over aktuelle og passive campingpasindehavere, booking og afbestilling af reservationer, check ind og check ud, oversigt over pladser på campingpladsen (både ledige og optagede pladser) samt prisberegning. Samt en web-del hvor det er muligt for campister at reservere pladser på campingpladsen. Det er væsentlig for systemet, at det både for de ansatte på campingpladsen, samt for de der reserverer via Internettet, er nemt at anvende. For de ansatte er det endvidere nødvendigt, at IT-systemet fungerer effektivt, således at det ikke bliver en barriere i dagligdagen. 8

9 For at udviklingsarbejdet skal fungere optimalt vil det kræve samarbejde med de, der skal anvende IT-systemet i hverdagen, eller de der skal undervise øvrigt personale i brug af systemet for at sikre, at det modsvarer personalets behov. Der skal være administratorrettigheder til funktioner, som ikke alle ansatte skal have mulighed for at anvende, fx tilføjelse og nedlæggelse af pladser. Filosofien bag IT-systemet er, at understøtte den daglige drift i administrationen af campingpladsen, således at de ved hjælp af systemet kan varetage, de arbejdsopgaver de dagligt møder, samt at gøre det lettere for administrationen på en campingplads at yde en god service for campisterne. Systemet bygges på en PC-baseret Java2 platform, og skal kunne køre på en standard pc med bredbåndsforbindelse. Diverse data i systemet skal gemmes i en SQL database, hvor det eventuelt kan være en MySQL eller en Postgresql server. For at hente campingpasindehaverinformationen ind eller oprette en campingpasindehaver i systemet, vil der blive brugt en magnetkortlæser til at læse deres data via sygesikringsbevis eller campingpas. 1.3 Omgivelser Problemområde Campingpladsen giver mulighed for at leje henholdsvis teltpladser, pladser til campingvogn samt hytter. Disse pladser, der udlejes, er samlet i et fælles areal, som er opdelt i mindre rondeller, hvortil der er tilknyttet toilet og badeforhold. Derudover vil der være et område, der indeholder kiosk og aktivitetsfaciliteter. Pladserne på Action House Camping vil være af varierende størrelse alt efter, om de er beregnet til telt eller campingvogn. På alle pladser vil der være mulighed for strøm. Placering af pladsen er ikke noget campingpasindehaverne, som udgangspunkt, kan have indflydelse på. De vil få tildelt en plads, der fra campingpladsens side er mest givtig at udleje. Forklaringen på dette er, at campingpladsen, hvis campingpasindehaverne selv kunne bestemme pladsens placering, vil risikere, at der var en spredning over hele arealet, selvom der kun var få mennesker på pladsen. Dette vil kræve et alt for stor arbejdsindsats fra de ansattes side i forhold til rengøring og vedligeholdelse. Derfor er der på størstedelen af eksisterende campingpladser kun mulighed for at reservere en plads til eksempelvis et telt, og ikke et bestemt pladsnummer, hvilket også bliver tilfældet her. 9

10 1.3.2 Anvendelsesområde Der er overordnet set to forskellige brugere, der kommer til at anvende IT-systemet. Den ene gruppe er de brugere, der ønsker at reservere en plads via Internettet dvs. campister, og den anden gruppe er de ansatte, der betjener IT-systemet på campingpladsen. Gruppen ansatte er kategoriseret som enten almindelige ansatte eller ansatte med administratorrettigheder. For at opfylde kravene fra de overordnede to grupper, vil der skulle laves to forskellige brugergrænseflader. De der vil bestille en plads via Internettet, skal have en brugergrænseflade, hvor der er lagt vægt på brugervenlighed. Derudover er effektivitet også et væsentligt aspekt, da arbejdsgangen ikke skal være langsom for campisten. Det væsentligste kriterium er dog brugervenlighed frem for effektivitet, hvis ikke begge kriterier kan opfyldes. Denne vægtning skyldes, at hvis interfacet bliver svært at finde rundt i, vil campister ikke anvende denne service. Den anden brugergrænseflade som bliver benyttet af personalet på campingpladsen, skal som i ovenstående ligge vægt på brugervenlighed. Denne vægtning skyldes at det primært er sæsonarbejdere, som anvender systemet. Det er derfor vigtigt at systemet ikke er krævende eller svært forståeligt at anvende. I højere grad end ved web-delen skal brugergrænsefladen til de ansatte ligge vægt på effektivitet. Det skal være en fordel for campingpladsen at benytte IT-systemet, hvis det besværliggør deres arbejdsdag, vil de ikke anvende IT-systemet. De hovedfunktioner som IT-systemet skal understøtte, for at effektivisere arbejdsopgaverne i campingpladsens administration vil blandt andet være: Reservation og afbestilling af pladser Systemet skal både kunne oprette og afbestille reservationer. Denne funktion kan tilgås af begge brugergrupper. Check ind og check ud af en plads Systemet skal både kunne checke campingpasindehavere ind og ud af campingpladsen. Disse funktionaliteter kan tilgås af personalet på campingpladsen Oversigt over optagede og ledige pladser Systemet skal kunne liste oplysninger om ledige pladser i en given periode. Denne information kan tilgås af begge brugergrupper. 10

11 Oversigt over indlogerede campingpasindehavere - Systemet skal indeholde en oversigt over, hvilke campingpasindehavere der er indlogerede på campingpladsen, og hvilke pladser de ligger på. Denne information kan tilgås af personalet på campingpladsen. Beregne pris Systemet skal kunne lave en beregning ud fra information om pris for pladsen samt antallet, der bor på pladsen. Eller ved aktiviteter en beregning af pris for denne samt for antallet af tilmeldte deltagere. Denne funktionalitet kan tilgås af de ansatte på campingpladsen 1.4 Struktur Systemet er bygget op omkring hovedklasserne Plads, Campingpasindehaver, Reservationer og Aktiviteter. Se Figur 1: Klassediagram. Klassen Plads indeholder et objekt for hver af de fysiske pladser på campingpladsen. De enkelte objekter i klassen skal have en af følgende pladstyper: telt, campingvogn eller hytte, hvoraf disse er til henholdsvis familie- eller ungdomscamping. Tildelingen af en specifik plads sker allerede ved reservation, men dette sker blot for, at den kan indgå i en oversigt over ledige eller optagede pladser. Det vil sige, at nummeret kun er vejledende og når campingpasindehaveren checker ind, tildeles det pladsnummer, hvorpå der skal checkes ind. Det vil være det næste ledige, hvorpå der ikke allerede er en check ind. Hvis der forefindes en reservation på dette næste pladsnummer, får reservationen et nyt vejledende pladsnummer og check ind sker på denne. For at bo på Action House Camping skal man have et af følgende campingpastyper, enten gruppepas, familliepas eller et personligt campingpas. Såfremt der skal indlogeres nogle på en ungdomsplads, skal alle disse være registreret med et personligt campingpas. Det er kun, hvis man ligger som ungdomscampist, at alle beboere på pladsen skal have et campingpas. En familie, der ligger på en familieplads, kan nøjes med at have ét campingpas. I sådanne situationer vil det kun være campingpasindehaveren, der bliver registreret med navn og adresse. Det vil derudover kun være muligt at se de resterende campister på pladsen som antallet af børn og voksne, der er tilknyttet den givne Campingpasindehaver. Det er ligeledes ved gruppepas kun den ansvarlige, der registreres med personoplysninger. Og det fungerer derfor på samme måde som familiepas. 11

12 Klassen Reservation skaber en aggregering mellem en Plads på campingpladsen og en eller flere Campingpasindehavere. Klassen Aktiviteter indeholder de nødvendige informationer til brug ved tilmeldinger til forskellige arrangementer hos Action House. Det er både gæster på campingpladsen samt øvrige, der ikke er tilknyttet til campingpladsen, der kan benytte disse aktiviteter. For alles vedkommende bliver de blot noteret med et antal. Figur 1: Klassediagram Diagrammet viser, at der kan være 1 plads tilknyttet hver reservation. Det skyldes, at der altid er tilknyttet en bestemt plads til reservationen, før campingpasindehaveren er checket ind. Pladsnummer ændrer sig dog i de fleste tilfælde ved check ind. Der kan ligeledes være 0 til n reservationer tilknyttet hver plads. 0 da der ikke nødvendigvis er en reservation tilknyttet pladsen og n da der kan være flere reservationer tilknyttet den samme plads, hvis ikke reservationerne er gældende i den samme tidsperiode. Der skal som minimum være tilknyttet en campingpasindehaver til hver plads, men der må gerne være flere campingpasindehavere end en tilknyttet. Dette vil eksempelvis være tilfældet på ungdomspladser, eller hvis mere end en familie camperer på samme plads. For at lave en reservation behøver man ikke være campingpasindehaver. Denne registrering sker først ved check ind, hvor en campingpasindehaver oprettes. Campingpasindehaveren bliver gemt, selvom han ikke længere er tilknyttet en enten aktiv eller passiv reservation. Klassen aktivitet har ikke nogen direkte tilknytning til de andre klasser i diagrammet. 12

13 1.5 Klasser Plads Definition: Klassen består af en række objekter, der beskriver hver enkelt plads på hele campingpladsen. Attributter: pladsnummer, pladstype, reserveret, optaget, pris. Beskrivelse: Et objekt af klassen Plads svarer til de fysiske pladser, der findes på en campingplads. Der vil være ca. 300 af disse på Action House Camping. Ved en reservation, der er enten passiv eller aktiv, er et objekt af klassen Plads tilknyttet. Adfærdsmønster: Klassen repræsenterer pladserne på campingpladsen. Det er disse pladser, der enten kan reserveres eller checkes direkte ind på. Figur 2 viser adfærdsmønstret for en plads, fra den bliver oprettet, til den bliver slettet. Figur 2: Tilstandsdiagram for klassen Plads Campingpasindehaver: Definition: I denne klasse oprettes de, der checker ind på campingpladsen, og som ikke allerede findes som et objekt i denne klasse. Beskrivelse: Denne klasse indeholder objekter af de, der har eller skal have tildelt et campingpas. Grunden til denne type campister eksisterer, er at Camping Rådet har vedtaget at campister skal registreres, enten som individer eller del af en gruppe. Hvis der checkes ind på campingpladsen som en gruppe eller familie, vil det blot være ét navn og antallet af voksne og børn, der bliver registreret i systemet. Ved ungdomscamping vil alle skulle oprettes som campingpasindehaver. Attributter: navn, adresse, fødselsdato, telefonnummer, adgangskortnummer, campingpasnummer, antal voksne, antal børn, campingpaspris, pladsnummer, blacklist. 13

14 Adfærdsmønster: Klassen repræsenterer oplysninger om Campingpasindehaveren. Figur 3 viser, adfærden for objektet Campingpasindehaver. Figur 3: Tilstandsdiagram for klassen Campingpasindehaver Reservation: Definition: Objekterne i denne klasse er reservationer til campingpladsens pladser. Beskrivelse: Klassen indeholder information om reservationer, hvem der har oprettet reservationerne, hvilke pladser der indtil check ind er tildelt, og hvornår reservationerne bliver aktive dvs. hvornår der checkes ind og dermed en tildeling af den mest optimale plads. Når der checkes ud slettes reservationen, og kun campingpasindehaverens info bliver gemt i klassen til dette, og pladsen bliver ledig. Attributter: Bekræftet (ved web), bekræftet senest (ved web), reservation start, reservation slut, antal pladser, pladsnumre, navn, adresse, fødselsdato, telefonnummer, aktiv (check ind). Adfærdsmønster: Klassen repræsenterer oplysninger om reservation, fra registrering til den pågældende Campingpasindehaver checker ud fra pladsen. Figur 4 viser, adfærden fra reservationen bliver oprettet, til den ophører. 14

15 Figur 4: Tilstandsdiagram for klassen Reservation Aktiviteter Definition: Objekterne i denne klasse er aktiviteter som Action House arrangerer. Beskrivelse: Klassen gør det muligt at registrere antallet af deltagere, der er tilmeldt aktiviteter hos Action House. Disse aktiviteter kan blandt andet være Pub crawl, ansigtsmaling eller lignende. Der vil også være registreret et tidspunkt for aktiviteten. Attributter: navn, højeste antal deltagere, antal deltagere, tidspunkt, type, pris voksen, pris barn. Adfærdsmønster: Figur 5 viser adfærden for aktiviteten, fra den bliver oprettet, til den er afviklet. Figur 5: Tilstandsdiagram for klassen Aktivitet 15

16 1.6 Hændelser Hændelse/ Klasse: Reservationsoplysninger afgivet (OK) Reservation afbestilt Reservation ændret Plads tilføjet Plads ophørt Plads reserveret Plads afbestilt Plads ændret Campingpasindehaver checket ind Campingpasindehaver checket ud Registrering af personoplysninger godkendt Personoplysninger ændret Deltager tilmeldt Aktivitet aflyst Alt optaget Aktivitet afholdt Plads Figur 6: Hændelsestabel illustrerer de hændelser, der påvirker livsforløbet for klasserne. Campingpasindehaver Reservation Aktiviteter Figur 6: Hændelsestabel Signatur: (+) Hændelsen opretter, påvirker eller anvender et objekt af klassen. 16

17 2 Anvendelsesområde 2.1 Brug Oversigt Det påtænkte IT-system har tre typer aktører, i form af det administrerende personale på campingpladsen, en overordnet administrator tilknyttet campingpladsen, samt personer der via Internettet ønsker at foretage online booking. Der er fundet frem til, at der er 13 relevante brugsmønstre for systemet. Aktører: Ansat Campist Administrator Klasser: Reservation Nedenstående er en aktørtabel over reservations- og administrationssystemet til campingpladsen. De 13 brugsmønstre falder i grupper, der alle er med til enten at opdatere, oprette, søge i egenskaber på pladser eller campingpasindehavere på campingpladsen. Campingpasindehaver Brugsmønster: Ændre reservation Afbestille reservation Checke ind Checke ud Registrere personoplysninger Ændre personoplysninger Reservere plads Tilføje ny plads + + Nedlægge plads + + Oprette en aktivitet Aflyse aktivitet Tilmelde deltagere (antal) Beregne omsætning Figur 7: Aktørtabel Plads Aktivitet 17

18 2.1.2 Aktører Ansat Formål: De ansattes opgaver er, at tage imod reservationer af pladser, checke fremmødte campingpasindehavere ind og ud, samt udregne pris for ophold. Aktøren ansat refererer til det almindelige administrative personale på campingpladsen. Karakteristik: IT-systemets brugere består af både fastansatte og sæsonarbejdere på campingpladsen. Derfor vil det være brugere med varieret kendskab, til campingpladsens organisationsstruktur og selve IT-systemet. Campist Formål: Campister skal kunne reservere sit campingophold via onlinebooking. Karakteristik: Campister der benytter websiden, kan være brugere med varierende erfaring med IT i almindelighed, men der forudsættes dog et jævnt kendskab til brug af Internettet, da denne reservationsmetode i de fleste tilfælde ellers ikke vil blive anvendt. Der skal dog tages højde for, at der også er novicer blandt de, der anvender onlinebooking. Administrator Formål: Administrator er den ansvarlige for driften af systemet, og har som den eneste adgang til at ændre overordnede egenskaber for campingpladsen. F.eks. rette i egenskaber for pladserne. Karakteristik: En leder på campingpladsen, der har det overordnede ansvar for, hvad der skal oprettes og slettes af egenskaber og klasser, eller det kunne være en ansat, som campingpladsens ledelse har givet ansvaret for den interne drift og opdatering af systemet Brugsmønstre Som nævnt I afsnit falder brugsmønstrene indenfor forskellige grupper, såsom opdatering, oprettelse eller søgning. De mest interessante indenfor disse områder vil blive uddybet ved hjælp af tilstandsdiagrammer. De resterende er forklaret ved hjælp af korte beskrivelser. Reservation via telefon (oprettelse) Figur 8 illustrerer situationen, hvor en campist ringer til campingpladsen for at reservere en plads i en given periode. 18

19 Figur 8: Tilstandsdiagram for "Reservation via telefon" Reservation via web-interface (oprettelse) Figur 9 adskiller sig fra Reservation via telefon ved, at campisten her skal igennem en bekræftelsesfase, som indebærer, at de skal bekræfte via mail på reservationen for at sikre reservationens validitet. 19

20 Figur 9: Reservation via "Web-interface" Ny/ret Campingpasindehaver (oprettelse og opdatering) Ny/ret Campingpasindehaver aktiveres af at en campingpasindehaver enten oprettes eller skal have ændret i sine oplysninger såsom navn, adresse, osv. Eller administrationspersonellet skal tilføje oplysninger til Campingpasindehaveren. I et campingpasindehaverkartotek kan der søges på eksisterende Campingpasindehavere, hvis der indtastes navn eller campingpasnummer og campingpasindehaveroplysningerne vises på skærmen. Når oplysningerne er på skærmen kan administrationspersonellet rette i disse og opdatere oplysningerne om Campingpasindehaveren i systemet. Ved oprettelse af en ny Campingpasindehaver indtastes og gemmes følgende oplysninger: navn, adresse, campingpasnummer, telefonnummer, fødselsdato og eventuelle øvrige oplysninger. Dette sker når, der checkes ind på campingpladsen. 20

21 Ny/ret plads (oprettelse og opdatering) Der kan tilføjes nye pladser i systemet og pladserne kan rettes. Pladstypen for campingvogn kan ændres til teltpladser, hvis der f.eks. er mange, der anvender telt i en given periode. Afbestilling (opdatering) Ved en afbestilling giver campisten reservationsnummer eller navn til den ansatte. Reservationen findes og slettes, systemet opdateres. Bekræftelse (Opdatering) Når der er foretaget en reservation via web, skal den person, der har lavet forespørgselen bekræftes. Han eller hun har ved reservationen oplyst navn og adresse, så systemet har de oplysninger, der er brug for. De ansatte på campingpladsen får besked via systemet, hvilke bekræftelser, der er lavet, disse opdateres i klassen reservation. Slet plads (Opdatering) Hvis en plads er beskadiget eller på anden vis er ubrugelig, kan den deaktiveres i systemet. Pladsen lokaliseres, pladsnummeret indtastes i systemet af en administrator, pladsen slettes fra systemet, og databasen over pladser opdateres. Tildeling af plads (Opdatering) Campingpasindehaveren skal have tildelt en plads enten allerede ved reservation, samt ved check ind eller først ved direkte check ind. Der tildeles en plads til Campingpasindehaveren, pladsen bliver listet, som optaget indtil campisten checker ud. Ved reservation bliver en vilkårlig plads tildelt. Pladsnummeret kan i løbet af den passive reservationsperiode ændres flere gange, hvis det tildelte pladsnummer skal anvendes til en check ind. Check ind (opdatering) Check ind finder sted på campingpladsen, når campingpasindehaveren møder op i receptionen. Under check ind får campingpasindehaveren tildelt et endeligt pladsnummer, som er til den næste ledige plads af typen. Derefter skal campingpasindehaveren betale forud for minimum en overnatning eller hele opholdet. 21

22 Figur 10: Tilstandsdiagram for "Check ind" 22

23 Check ud (opdatering) Efter endt ophold foretages check ud. Pladsen skal frigøres i systemet, således den igen kan enten tildeles en reservation eller et check ind. Se Figur 11. Figur 11: Tilstandsdiagram for "Check ud" Find Campingpasindehaver (søgning) Figur 12 viser, hvad der sker, når man skal finde en bestemt Campingpasindehaver, der bor på campingpladsen, og hvor denne er placeret. Dette vil forekomme, hvis der fx er beskeder til Campingpasindehaveren, eller gæster skal have oplyst pladsnummeret for at kunne besøge Campingpasindehaveren. 23

24 Figur 12: Tilstandsdiagram for "Find Campingpasindehaver" Find ledig plads (søgning) En campingpasindehaver eller en anden der ønsker at foretage en reservation eller en check ind skal have tildelt en plads på campingpladsen. Udover at systemet generer en ledig plads ved disse to tilfælde, kan der ydermere være behov for at få listet ledige pladser således, at man kan se oplysningerne for belægningen i en given periode. 2.2 Funktioner Komplet funktionsliste Nedenstående tabel illustrerer den funktionalitet, som systemet skal tilbyde, og af hvilken type de forskellige funktioner er grupperet i (opdater, aflæser, søger, beregner). Klasser: Funktion Opret Reservation 5 Opdater X X X Kompleksitet Type: Reservation (6750) Campingpasinde-haver (10000) Ret Reservation 5 Opdater X X X Slet Reservation 5 Opdater X X X Find Reservation 5 Aflæser X X X Plads (300) Aktivitet (90) 24

25 Vis reservationsinfo 5 Aflæser X X X Opret Campingpasindehaver 1 Opdater X Ret Campingpasindehaver 1 Opdater X Slet Campingpasindehaver 1 Opdater X Find Campingpasindehaver 1 Opdater X Bestil campingpas 1 Opdater X List Campingpasindehavere(plads 2 Aflæser X X nummer) List Alle Campingpasindehavere 2 Aflæser X X Aflæs magnetkort 1 Aflæser X Prisberegner 2 Beregner X X Beregn omsætning 3 Beregner X X X Registrer betaling 3 Beregner X X X Opret Plads 1 Opdater X Ret Plads 1 Opdater X Nedlæg Plads 1 Opdater X Tildel Plads 2 Beregner X X List Pladser 1 Aflæser X Opret Aktivitet 1 Opdater X Ret Aktivitet 1 Opdater X Slet Aktivitet 1 Opdater X Afmeld deltager 1 Opdater X Tilmeld deltager 1 Opdater X Annuller 1 Opdater Kompleksitetsvurderingen er baseret på, hvor mange klasser en given funktion berører, og hvor mange objekter den eventuelt skal søge igennem efter informationer. Antallet af objekter er et estimat baseret på 300 pladser udlejet i 4 dage af gangen over en periode på 90 dage. Med i gennemsnit 1.5 campingpasindehaver pr. plads. Og én aktivitet om dagen. Det vil sige, at vi tager (antallet af objekter * antal klasser)/ og afrunder til nærmeste heltal dog minimum 1. Tallene er drøftet med Action House Camping Specifikation af funktioner Opret Reservation: Funktionen opretter et objekt af klassen reservation. Ret Reservation: Funktionen ændrer attributterne for objekter af klassen Reservation Slet Reservation: Funktionen sletter objekter i klassen Reservation. 25

26 Find Reservation: Funktionen søger efter en given reservation på baggrund af en vilkårlig attribut i reservationen. Vis reservations info: Funktionen viser alle de attributter, der er i reservationen Opret Campingpasindehaver: Funktionen opretter objekter af typen campingpasindehaver. Ret Campingpasindehaver: Funktionen retter i attributterne for objekter i klassen Campingpasindehaver Slet Campingpasindehaver: Funktionen sletter en Campingpasindehaver. Eksempelvis hvis der ønskes en oprydning i kartoteket over Campingpasindehavere. Find Campingpasindehaver: Funktionen finder en Campingpasindehaver. Bestil campingpas: Funktionen bestiller et campingpas af én af de 3 typer gruppepas, familiepas eller personligt pas hos CompuSoft A/S 1 til campingpasindehaveren. Derudover udskriver den et midlertidigt campingpas. List Campingpasindehavere(Pladsnummer):Funktionen lister Campingpasindehavere, der er tilknyttet en given plads. List Campingpasindehavere: Funktionen lister alle Campingpasindehavere, der er på hele pladsen på et vilkårligt tidspunkt Aflæs magnetkort: Funktionen aflæser et magnetkort og formaterer data fra dette, således at det passer ind i vores formularer. Den vil f.eks. skulle aflæse informationer om Campingpasindehaverens navn, adresse og fødselsdato fra et sygesikringsbevis, for at minimere tastearbejde. Prisberegning: Funktionen beregner prisen på baggrund af antal overnatninger, antal voksne og børn samt pladstypen, som Campingpasindehaveren har frekventeret. Denne udregning skal sammenholdes med et eventuelt accontobeløb indbetalt af Campingpasindehaveren. Beregning af Omsætning: Funktionen angiver omsætningen over et angivet tidsinterval. Registrering af betaling: Funktionen registrerer en betaling for en plads, i objekter af klassen Plads. Opret plads: Funktionen opretter objekter af klassen Plads i systemet og gør dem persistente. Ret plads: Funktionen retter attributter i objekter af klassen Plads. Nedlæg Plads: Funktionen sletter et objekt under klassen Plads, således at denne ikke længere forefindes som en mulig reservation, samt den sletter også synligheden af pladsen på oversigtskortet. 1 Compusoft er et dansk firma, som udover produktion af campingpas, udbyder administrationssystemer til campingpladser. 26

27 Tildeling af plads: Funktionen finder den mest hensigtsmæssige plads ud fra et belægningsprocentmæssigt synspunkt, når reservationen bliver aktiv. Ved passiv reservation skal der blot tildeles et ledigt pladsnummer. List pladser: Funktionen fremviser en oversigt over, hvilke pladstyper der er ledige i en given periode. Registrering af adgangskort: Funktionen indlæser et adgangskort til brug af faciliteter på campingpladsen, til en given Campingpasindehaver. Opret Aktivitet: Funktionen opretter en given aktivitet, hvilket vil sige, at den opretter et objekt af klassen Aktivitet. Ret Aktivitet: Funktionen retter i attributter i objekter af klassen Aktivitet. Slet Aktivitet: Funktionen sletter et givent objekt af klassen Aktivitet. Tilmeld deltager: Funktionen tilmelder en deltager til en given aktivitet, hvilket vil sige, at den opdaterer en attribut under et objekt af klassen Aktivitet. Afmeld deltager: Funktionen afmelder et antal deltagere til en given aktivitet, hvilket vil sige at den opdaterer en attribut under et objekt af klassen Aktivitet. Annuller: Funktionen skal i forbindelse med alle funktioner give brugeren mulighed for at annullere en given interaktion med systemet. 27

28 3 Brugergrænsefladen 3.1 Dialogform Det er hensigten, at der er mulighed for at kunne interagere med reservations- og administrationssystemet, primært ved hjælp af skemaudfyldelse. Denne interaktionsform anvendes til indtastning af oplysninger i systemet såsom ved oprettelse af reservationer. Menuvalg tjener som alternative veje til at komme til et givent skærmbillede eller at anvende funktioner, som ikke skal anvendes så hyppigt. Nedenfor vil vi beskrive, hvordan hovedvinduet i systemet er opbygget. Hovedvinduet: Skærmbilledet skal bestå af nogle faste elementer, samt elementer der skifter alt efter, hvilken funktion i systemet, man vælger. Faste elementer TopBar: TopBaren indeholder en menu, hvorigennem der er tilgang til alle funktioner i systemet. Denne menu har et fast udseende gennem alle faser i programmet. Genvejsknapper: Der er placeret genvejsknapper til de ofte benyttede funktioner. Disse er placeret i venstre side af skærmbilledet. Baggrund: Baggrunden i systemet består af flere ting. Der er en række knapper der fungerer som genveje til de oftest benyttede funktioner i systemet. Disse er placeret yderst til venstre i skærmbilledet. Derudover er der tre faste funktioner: Ledige pladser, dagens hændelser og dagens omsætning. Disse funktioner er placeret på nogle faneblade og fylder hele baggrunden mellem TopBar og StatusBar. Skiftende elementer Når man ønsker at benytte en funktion, vælger man den på en af tre følgende måder: Man kan benytte menuen hvor der er adgang til samtlige funktioner i systemet. Man kan benytte genvejsknapperne yderst til venstre i brugergrænsefladen. Man kan benytte genvejstasterne. Når der bliver aktiveret en funktion, kommer der et nyt vindue frem, som dækker over en eksisterende baggrund. Dette vindue har man mulighed for at minimere, og dermed 28

29 arbejde videre med andre funktioner samtidig med, at det er nemt at vende tilbage til det oprindelige valgte vindue. Denne funktionalitet gør det muligt at håndtere en forespørgsel på noget andet, end det der arbejdes med, uden at skulle lukke det ned imens. Grunden til at layoutet er struktureret på denne måde er, at kunden ønsker et fast holdepunkt med nogle grundlæggende funktioner. StatusBar: Statusbaren benyttes til at vise resultater på hændelserne i programmet. F.eks. hvis en bruger opretter en ny plads i systemet, skal der komme et output i statusbaren, der giver respons på resultatet af hændelsen opret plads. Det kan være en besked som: Plads nr. 316 er oprettet korrekt. eller Husk at oplyse typen på pladsen. Dialogen ændrer sig afhængig af, hvor i programmet man befinder sig. Nedenstående illustrerer opbygningen af det skærmbillede, man møder indledningsvist i programmet. Figur 13: Brugergrænseflade 29

30 De efterfølgende skærmbilleder vil som nævnt øverst have samme faste elementer, og derudover have layout efter den valgte funktionalitet, med primær brug af skemaudfyldelse eller afkrydsning. En væsentlig ting for disse skærmbilleder er, at der ikke forekommer for megen information pr. side, da det skal være overskueligt for brugeren af systemet Systemgrænseflader Den information, systemet skal sende til andre systemer, er information til at oprette campingpasset. Systemet skal sende det til CompuSoft A/S, der administrerer campingpassystemet. Systemet skal kunne læse informationen fra sygesikringsbeviset og campingpasset. Det skal benyttes til at lette arbejdsgangens for campingpladsens administration, da det er væsentligt hurtigere at køre et kort igennem en magnetlæser, end det er at indtaste informationer om, navn, adresse og fødselsdato. 3.2 Den tekniske platform Som nævnt i afsnit 1.2. skal systemet kunne køre på en standard pc med bredbåndsforbindelse. Systemet skal kunne virke sammen med en ekstern magnetkortlæser, og kunne kommunikere med eksterne databaser. Systemet skal kodes i Java2. 30

31 Del II: Design 31

32 4 Opgaven 4.1 Formål Det designede system skal kunne håndtere administrative arbejdsopgaver på Action House Camping. Det skal anvendes ved styring af reservation, check ind og check ud, og give overblik over pladsbelægning og kundekartotek. Derudover skal systemet kunne lave prisberegning pr plads for campisternes forbrug, samt en samlet omsætning for en given periode. Det skal være muligt at få listet de campister, der skal betale dags dato, altså de der ikke er tjekket ud og derfor ønsker endnu en overnatning. Systemet skal i brug kunne anvendes af øvede som uøvede. Designet skal derfor opbygges med vægt på brugervenlighed for ikke at risikere en lang indlæringskurve. Det skal også være mulighed for funktionstaster og brug af tabulator og enter, hvilket samtidig gør det effektivt at bruge systemet og letter arbejdsgangen for de øvede brugere. Samlet set skal systemet være en hjælp for campingpladsen til, at have overblik over campingpladsens beboere samt ledige og optagede pladser og understøtte arbejdsgangen i forbindelse med reservation og brug af campingpladsen faciliteter. Web-interfacet til systemet vil ikke blive designet i dette dokument, da vi allerede på nuværende tidspunkt har valgt implementeringen af dette fra. 4.2 Rettelser til analysen Den primære ændring i forhold til analysen er, at klassediagrammet er blevet væsentlig udvidet. En del attributter under klassen Reservation er blevet flyttet til en ny klasse, der hedder PladsStatus, og denne nye klasse fungerer nu som et bindeled mellem Plads, Reservation og Campingpasindehaver. Derudover er der kommet fire nye klasser, der indgår som økonomi- og betalingsdelen. Disse er navngivet Gæld, Gældspost, Betalingsgenstand og Indbetaling. I analysen ansås betalingsdelen som en mindre væsentlig del, der kunne ligge som attributter i klasserne i det oprindelige klassediagram. Designmæssigt har dette dog vist sig at være nødvendigt at udvide. 32

33 4.3 Kvalitetsmål Nedenstående figur viser prioriteringen af designkriterierne for systemet. Kriterium Meget vigtigt Vigtigt Mindre vigtigt Irrelevant Trivielt opfyldt Brugbart X Sikkert X Effektivt X Korrekt X Pålideligt X Vedligeholdbart X Testbart X Fleksibelt X Forståeligt X Genbrugbart X Flytbart X Integrerbart X Meget vigtigt Brugbart er valgt som meget vigtigt, da det er væsentligt for campingpladsen, at systemet opfylder brugerens behov. Funktionaliteten skal altså opbygges således, at det er passer til den organisatoriske fremgangsmåde, som arbejdsopgaverne udføres efter. Derudover vurderes brugervenligheden højt fra kundens side for at minimere fejlmulighederne i brugen af systemet. Samkørende med at systemet skal være brugbart, er det også meget vigtigt, at systemet er effektivt. Effektivitet er valgt for, at brugerne, i så høj grad det er muligt, kan minimere tidsspild i forbindelse med udførelsen af arbejdsopgaverne. Effektivt vurderes altså ud fra den arbejdsgang personalet skal gennemgå. Systemet er derfor effektivt, hvis arbejdsgangen er nem og tilgængelig for personalet, samt ved at systemets opbygning ikke sinker dem. Effektivt er derfor ikke set i forhold til, hvor optimale de algoritmer, der ligger bag funktionaliteten i systemet, er. Vigtigt Korrekt og pålideligt er valgt som vigtigt. Hvis systemet ofte går ned ved interaktion, vil dette medføre en ekstra byrde for personalet i form af, at skulle gentage den allerede 33

34 foretagne interaktion, derudover vil der også opstå en mistillid til systemet. Samtidig støtter disse to punkter op om brugbart og effektivt. Testbart er valgt som vigtigt for at sikre de to ovenstående kriterier, korrekt og pålideligt. For at vurdere om disse to kriterier opfyldes, er det nødvendigt at teste systemet, hvilket er baggrunden for, at dette kvalitetsmål er sat til vigtigt. Mindre vigtigt Sikkerheden i systemet er mindre vigtig. Et reservationssystem til en campingplads vurderes ikke som et system, der indeholder oplysninger, der skal sikres i høj grad mod indtrængning, i modsætning til eksempelvis en bank. Der gøres derfor ikke specielle tiltag såsom kryptering og lignende. Vi definerer forståelig som indsatsen for at opnå forståelighed over den bagvedliggende struktur i systemet. Da det primære fokus ligger på brugbarheden af systemet ved interaktion med brugergrænsefladen, prioriteres forståeligheden i opbygningen af den bagvedliggende struktur som mindre vigtig. Fleksibiliteten af systemet kategoriseres ligeledes som mindre vigtig. Det forventes ikke, at der i anvendelsen af systemet, forekommer de store ændringer i forhold til de arbejdsopgaver, der er på campingpladsen. Vedligeholdbart og integrerbart prioriteres som mindre vigtig, og tillægges derfor ikke et stort fokus under design af systemet. Irrelevant Genbrugbart prioriteres som irrelevant i udviklingen af systemet. Trivielt opfyldt Flytbart er trivielt opfyldt, da systemet bliver udviklet i Java, hvilket er platformsuafhængig. 34

35 5 Teknisk platform 5.1 Udstyr IT-systemet vil blive udviklet til pc med operativsystemet Microsoft Windows 2000 eller nyere. Microsoft anbefaler følgende minimumskonfiguration 2 : Processor: 133 MHz eller hurtigere Pentium-kompatibel CPU Hukommelse: 64 MB RAM anbefales som minimum. Hard Disk: 2GB harddisk med minimum 650 MB fri plads. For at benytte funktionen til automatisk indlæsning af persondata, kræves der en tilsluttet magnetkortlæser. Den tilsluttede skærm skal kunne køre mindst 1024x768 pixels. 5.2 Basisprogrammel IT-systemet vil blive udviklet ved hjælp af følgende programmel: Java2 SE samt tilhørende standard biblioteker BlueJ vil blive anvendt til generel programmering i Java2 JUnit vil blive anvendt til test af systemet MySQL database Microsoft Windows 2000 eller nyere vil blive anvendt under udvikling og afvikling af systemet. 5.3 Systemgrænseflade Systemet vil have grænseflader til følgende apparatur og systemer: Mus og tastatur: Mus og tastatur vil blive anvendt til betjening af systemet. I al interaktion med systemet kan mus og tastatur benyttes. Både musens og tastaturets grænseflader vil blive håndteret af operativsystemet samt Java

36 Magnetkortlæser: Magnetkortlæseren kan anvendes ved udvalgte interaktioner med systemet, såsom til at hente personoplysninger fra sygesikringskort og oplysninger fra adgangskort. Grænsefladen vil blive håndteret af operativsystemet i og med, at denne tilkobles en ps2 port, samme type port som tastaturet. Der vil være et ekstra lag, en tolk mellem vores system og operativsystemet. Printer: Printer skal bruges til udskrift af midlertidige campingpas samt kvitteringer. Grænsefladen vil blive håndteret af operativsystemet. CompuSoft: Systemet skal kunne sende de nødvendige oplysninger, der skal bruges ved bestilling af et campingpas, til en anden systemgrænseflade, der er tilknyttet firmaet CompuSoft A/S. 5.4 Designsprog Designdokumentet vil være baseret på UML standarden. Ændret notation ses ved klassediagrammerne, hvor der er anvendt det matematiske udtryk n i stedet for * for mange. 36

37 6 Arkitektur 6.1 Komponentarkitektur Som overordnet design af systemet vil der blive benyttet en lagdelt arkitektur med fire hovedkomponenter. Disse hovedkomponenter benævnes som henholdsvis komponent Brugergrænseflade, komponent Funktion, komponent Model og komponent Teknisk platform. Figur 14: Komponentarkitektur Komponent Brugergrænseflade Komponent Brugergrænseflade indeholder det synlige layout. Pil 1, 2 og 6 fra komponent Brugergrænseflade kalder ned i henholdsvis komponent Funktion, komponent Model og komponent Systemgrænseflade. Derudover kalder komponent Brugergrænseflade sig selv ved åbning af vinduer, eller i det hele taget når skærmbillederne skifter. 37

38 Eksempel på pil 1: Når der i brugergrænsefladen klikkes på eksempelvis Ok i Check ind, sker der et kald ned i komponent Funktion. Eksempel på pil 2: Der sker et kald fra komponent Brugergrænseflade til komponent Model, når der eksempelvis klikkes på Opret reservation. Eksempel på pil 6: Ved check ind skal der udfyldes felter med navn og adresse for at oprette en campingpasindehaver. For at lette arbejdsgangen kan dette gøres ved hjælp af et magnetkort, således at felterne udfyldes automatisk. Klasser: HovedVindue, Actions, ForsideSide, LedigePladserFaneblad, DagensHændelserFaneblad, DagensOmsætningFaneblad, ReservationVindue, ReservationsForside- Faneblad, PersonInfoFaneblad, ReservationsPeriodeFaneblad, CheckIndVindue, CheckIndForsideFaneblad, CampingpasindehaverFaneblad, VælgPeriodeFaneblad, PladsstatusVindue, FindPladsstatusSide, PladsstatusForsideFaneblad, KundekartotekVindue, AktiviteterVindue, ØkonomiVindue, IndstillingerVindue, IndstilPriserFaneblad og IndstilPladserFaneblad Komponent Funktion Komponent Funktionen indeholder funktioner, der hver især anvender flere operationer fra komponent Model. Pil 3 og 4 viser, at der fra komponent Funktion er adgang til komponent Systemgrænseflade og komponent Model. Eksempel på pil 3: Når der checkes nye campingpasindehavere ind på campingpladsen skal der oprettes et antal objekter af typen campingpasindehavere. Dette foregår via komponent Model. Eksempel på pil 4: Når der skal videregives informationer til Compusoft om nye campingpasindehavere, henter komponent Funktion disse i komponent Model. Komponent Funktion videregiver efterfølgende disse til komponent Systemgrænseflade, der skal afgive informationen til Compusoft. Klasser: CheckInd, TildelPlads, Omsætning, DagensBetalere, FindLedigePladser. 38

39 6.1.3 Komponent Model Komponent Model indeholder en repræsentation problemområdet i form af et revideret klassediagram. Komponenten har alle gængse operationer tilknyttet. Komponenten bruges til at levere data til Komponent Funktion og komponent Brugergrænseflade. Pil 5 viser, at der fra komponent Model er adgang til databasetolken. Eksempel på pil 5: Der skal hentes oplysninger i komponent DatabaseTolk, når der skal findes en given campingpasindehaver. Klasser: Plads, Reservation, Campingpasindehaver, Pladsstatus, Aktivitet, Gæld, Gældspost, Betalingsgenstand, Indbetaling Komponent Teknisk platform Komponent Teknisk platform indeholder to underkomponenter: komponent Database- Tolk og komponent Systemgrænseflade. Komponent DatabaseTolk har til opgave at forbinde Komponent Model med databasen, sådan at de indbyrdes kan kommunikere. Komponent Systemgrænseflade har til opgave henholdsvis at håndtere magnetkortlæseren, samt oplysninger, der skal formidles til Compusoft. Klasser i komponent Systemgrænseflade: MagnetkortlæserGrænseflade, CompusoftGrænseflade Klasser i Komponent DatabaseTolk: PladsTolk,, ReservationTolk, CampingpasindehaverTolk,, PladsstatusTolk, AktivitetTolk, GældTolk, GældspostTolk,, BetalingsgenstandTolk, IndbetalingTolk, DBForbindelse. 6.2 Standarder Følgende Microsoft Windows standarder skal følges: mulighed for at benytte genvejstaster, minimere vinduer og lukning via et kryds i vinduets højre hjørne. 39

40 7 Komponent Model Komponent Model viser oversigt over modellen og størstedelen af operationerne. Alle trivielle og let tilgængelige operationer ligger her, og kun enkelte mere komplekse operationer er placeret i komponent Funktion. 7.1 Struktur I forhold til modellen af problemområdet i analysedokumentet, er der tilføjet nye klasser for de iterative hændelser. Se Figur Relationer Pladsstatus sammenbinder informationer fra plads, campingpasindehaver og reservation. Klassen samler oplysninger fra de eksisterende klasser nævnt ovenfor og er nødvendig i forbindelse med udregning af gælden. Klassediagrammet skal derfor læses som, at Pladsstatus indeholder informationer om en Plads, hvor en reservation, campingpasindehaver, og en gæld tilknyttet kan være tilknyttet. Når en Pladsstatus er aktiv, er der en reel check ind og dermed også en gæld, der enten kan være positiv, ingenting eller negativ tilknyttet. Hvis ikke en pladsstatus er aktiv, er der ikke nogen checket ind på pladsen. En aktiv Pladsstatus, skal minimum have en campingpasindehaver tilknyttet. Når der checkes ind på en plads, sendes der besked via gæld om at oprette gældsposter for denne Pladsstatus. For hver campingpasindehaver tilknyttet den pågældende Pladsstatus bliver der oprettet en eller flere gældsposter, der hver indeholder en af de valgte betalingsgenstande til denne Pladsstatus. Gældsposten modtager information fra Betalingsgenstand om priserne på de valgte attributter. Når der bliver indbetalt til den pågældende Pladsstatus, sender denne besked til klassen Gæld, der indhenter de gældsposter, der er tilknyttet Pladsstatus, og beregner disse til et samlet beløb. Når gælden sættes til betalt oprettes en indbetaling i Indbetalingsklassen. 40

41 I og med at en indbetaling i klassen Indbetaling først bliver oprettet ved fysisk betaling til campingpladsen, er der ingen fast binding mellem gæld og indbetaling. Der er dog en relation mellem Betalingsgenstand og Indbetaling, da ved en oprettet Indbetaling indeholder denne attributter fra Betalingsgenstand. Disse attributter skal klassen Indbetaling bruge, når der eksempelvis skal beregnes en omsætning, hvor betalingsgenstandene figurerer. Når der checkes ind, betales der som minimum for den første nat, da der skal forudbetales på pladsen. Efterfølgende indhenter systemet information om de aktive pladsstatuser. Her bliver der lavet en gældspost, og denne venter på at blive aktiveret ved en indbetaling, der igen sætter saldoen i nul. I modsætning til betaling for ovenstående bliver der ved køb af en aktivitet direkte genereret en indbetaling, da disse skal betales med det samme. Og der forekommer derfor en direkte relation mellem disse. Figur 15 Viser det resulterende klassediagram 41

42 7.2 Klasser Nedenstående er en grundigere beskrivelse af de klasser, der indgår i det reviderede klassediagram. For hver klasse illustrerer tabellerne attributterne. Derudover viser de typen af denne, samt hvorvidt de kan sættes og hentes fra andre klasser. For hver klasse gælder det, at de har følgende operationer: opret(), find(), slet(). Som den eneste undtagelse har klassen Indbetaling dog ikke en slet operation, da fjernelse af en allerede lavet indbetaling vil have betydning for omsætningen. For find operationerne kan alle attributter indgå som søgekriterier Plads Formål og ansvar: Klassen Plads har til ansvar at registrere antallet af pladser samt holde styr på de forskellige pladstyper, der findes på campingpladsen. Den vil altså indeholde en nummerering og en inddeling af de fysiske pladser i typer. Hvert objekt af klassen Plads indeholder en af følgende pladstyper: teltungdom, teltfamile, campingvognungdom, campingvognfamilie, hytteungdom eller hyttefamilie. For at oprette og slette en plads kræves det, at man har administratorrettigheder. Attributter: Attributnavn: Type: Hent: Sæt: Pladsnummer String X X Pladstype String X X Strøm Boolean X X Aktiv Boolean X X Figur 16: Tabel over attributter samt sæt og hent metoder for Plads Operationer: tildeling() Reservation Formål og ansvar: Klassen Reservation har til ansvar at registrere nuværende reservationer af pladser på campingpladsen. Den vil altså indeholde de reservationer, der endnu ikke er afviklet. Det er kun muligt at reservere en plads per reservation. 42

43 Når der er checket ind på campingpladsen, eller hvis reservationen afbestilles, slettes objektet. Attributter: Attributnavn: Type: Hent: Sæt: Bekræftet Boolean X X Bekræftet senest Long X X Oprettelsesdato Long X Navn String X X Efternavn String X X Adresse String X X Fødselsdato String X X Telefonnummer String X X Figur 17: Tabel over attributter samt sæt og hent metoder for Reservation Campingpasindehaver Formål og ansvar: Klassen Campingpasindehaver har til ansvar at registrere de campingpasindehavere, der bor og/eller har boet på Campingpladsen. Den vil altså indeholde alle de campingpasindehavere, der på et givent tidspunkt, har været tilknyttet campingpladsen. Attributter: Attributnavn: Type: Hent: Sæt: Pladsstatushenvisning Long X X Fornavn String X X Efternavn String X X Adresse String X X Postnummer String X X Fødselsdato String X X Telefonnummer String X X Adgangskortnummer String X X Bemærkninger String X X Blacklistet Boolean X X Figur 18: Tabel over attributter samt sæt og hent metoder for Campingpasindehaver 43

44 7.2.4 Pladsstatus Formål og ansvar: Klassen Pladsstatus er tilknyttet til pladser hvor, der er en reservation tilknyttet. Derudover er der aktiv pladsstatus, når der er checket ind på campingpladsen. På den enkelte campingpasindehaver, der er checket ind på campingpladsen, vil der være en pladsstatus tilknyttet. Pladsstatus vil også vise information om saldoen. Ydermere er klassen nødvendig for at gælden for den enkelte plads, bliver udregnet. Hvert objekt af klassen Pladsstatus indeholder altså én pladsstatus med tilknytning fra eller til Plads, Reservation, Campingpasindehaver og Gæld. Attributter: Attributnavn: Type: Hent: Sæt: Check ind dato Long X X Check ud dato Long X X Antal voksne Int X X Antal børn Int X X Strøm Boolean X Saldo Double X X Reservationshenvisning Long X X Pladshenvisning Long X X Pladstype String X Fast plads Boolean X X Aktiv Boolean X X Figur 19: Tabel over attributter samt sæt og hent metoder for Pladsstatus Operationer: betal(), find ledig plads() Aktivitet Formål og ansvar: Klassen Aktivitet har til ansvar at registrere de aktiviteter, der afholdes gennem campingpladsen samt registrere antallet af deltagerne. Den vil altså indeholde de aktiviteter, der er aktuelle samt deltagerantal. Deltagere meldt til aktiviteter kan både være folk, der bor på campingpladsen eller andre interesserede uden tilknytning til campingpladsen. Hvert objekt af klassen Aktivitet indeholder én aktivitet. 44

45 Attributter: Attributnavn: Type: Hent: Sæt: Højeste antal deltagere Int X X Antal deltagere Int X X Tidspunkt Long X X Type String X X Titel String X X Pris Double X X Figur 20: Tabel over attributter samt sæt og hent metoder for aktivitet Operationer: betal(), find aktuelle aktiviteter(), find dagens aktiviteter() Gæld Formål og ansvar: Klassen Gæld har til ansvar at beregne beløb, der skal betales for en plads, samt videregive information fra Pladsstatus, for at der kan oprettes gældsposter. Den vil altså indeholde det beløb, der skal betales for pladsen den givne dag eller periode. Når gælden er betalt sættes saldoen under Pladsstatus til indbetalt beløb gæld, og attributten betalt i Gæld sættes til sand. Hvert objekt af klassen Gæld indeholder en samlet gæld for én Pladsstatus. Attributter: Attributnavn: Type: Hent: Sæt: Betalt Boolean X Er betalt String X Pladsstatushenvisning Long X Gældsposter Array af gældsposter X Figur 21: Tabel over attributter samt sæt og hent metoder for Gæld Operationer: betal gæld(), beregn gæld() Gældspost Formål og ansvar: Klassen Gældspost har til ansvar at oprette én post per betalingsgenstand. Der er derfor som oftest, flere gældsposter tilknyttet en Pladsstatus afhængig af de valgte attributter. 45

46 Klassen Gældspost modtager information fra klassen Gæld om, at der skal oprettes en eller flere gældsposter indeholdende priser, som Gældspost indhenter fra klassen Betalingsgenstand. Ved to campingpasindehavere tilknyttet en Pladsstatus, oprettes der altså minimum to gældsposter, der efterfølgende bregnes i klassen Gæld. Attributter: Attributnavn: Type: Hent: Sæt: Betalingsgenstands navn String X Antal Int X Betalingsgenstandshenvisning Long X Gældshenvisning Long X Pris Double X Figur 22: Tabel over attributter samt sæt og hent metoder for Gældspost Betalingsgenstand Formål og ansvar: Klassen Betalingsgenstand har til ansvar at registrere de forskellige enheder, hvortil en pris er tilknyttet. De enkelte betalingsgenstande kan ses som dele af en samlet liste over de priser, der eksisterer på campingpladsen. Den har altså til formål at give information til gældspost om pris pr. enhed, således at Gæld kan udregne det beløb, der skal betales. Det er de betalingsgenstande, hvor gyldig til ikke er sat til en dato, der er de aktuelle. Hvert objekt af klassen betalingsgenstand indeholder én pris på en enhed. For at oprette og slette en betalingsgenstand kræves det, at man har administratorrettigheder. Attributter: Attributnavn: Type: Hent: Sæt: Gyldig fra Long X Gyldig til Long X Navn String X Pris Double X X Figur 23: Tabel over attributter samt sæt og hent metoder for Betalingsgenstand 46

47 7.2.9 Indbetaling Formål og ansvar: Klassen Indbetaling har til ansvar at registrere de indbetalinger, der indbetales til campingpladsen. Den vil først blive genereret, når en gæld til en given Pladsstatus bliver betalt. Disse indbetalinger vil blive gemt i databasen, og efterfølgende blive anvendt til vise omsætning for en given periode. Ved tilmelding til aktivitet, bliver klassen Gæld ikke aktiveret, da der for disse betales samtidig med tilmelding, og der bliver derfor direkte genereret en indbetaling. Attributter: Attributnavn: Type: Hent: Sæt: Betalingsgenstand navn String X Antal Int X Betalingsgenstandshenvisning Long X Pris Double X Figur 24: Tabel over attributter samt sæt og hent metoder for Indbetaling 47

48 8 Komponent Teknisk platform, DatabaseTolk 8.1 Struktur Komponent Database er som nævnt under arkitekturen en underkomponent til komponent Teknisk platform. For at forbinde komponenten Model med komponent Database skal der implementeres en tolk for hver klasse i denne. De vil blive benævnt som BetalingsgenstandTolk, GældspostTolk, IndbetalingTolk, GældTolk, AktivitetTolk, DeltagerTolk, PladsTolk, ReservationTolk, PladsstatusTolk og CampingpasindehaverTolk. Disse tolke skal oversætte fra Java2 til SQL og omvendt. Der er kun behov for et af hvert objekt, og samtlige tolke implementeres derfor som singletons. Hver af disse klasser skal implementere fire interfaces, der kan henholdsvis oprette, slette, opdatere og finde. Det er de basisoperationer, alle tolkene kan udføre. Ved at klasserne implementerer disse interfaces, kan det sikres et minimum af ændringer ved, at der på et senere tidspunkt ønskes at anvende en anden database. Derudover skal der tilføjes en databaseforbindelse kaldet DBforbindelse, hvis opgave består i at administrere forbindelsen til databasen. DBForbindelse indeholder oplysninger om, hvilken driver, der skal benyttes for at få forbindelse til SQL databasen. Der skal endvidere heri placeres oplysninger om navnet på databasen, hvor den er placeret, samt hvilket brugernavn og password der skal benyttes for at få adgang til databasen. I og med at disse oplysninger er samlet et sted, behøver vi ikke at ændre i samtlige klasser, der benytter databasen, hvis vi f.eks. beslutter os for at benytte en anden driver til databasen, eller skifte til den anden SQL database. Der er ingen fast forbindelse mellem DBforbindelse og tolkene for klasserne, da denne bliver oprettet ved en forespørgsel og lukket umiddelbart efter. Nedenstående klassediagram viser strukturen for tolkene, DBforbindelse og de fire interfaces. 48

49 Figur 25: Klassediagram for databasekomponenten 8.2 Klasser DBForbindelse Formål: Klassen fungerer som et mellemled mellem tolkene og SQL databasen. Ansvar: Klassens ansvar er at skabe forbindelse til databasen. Attributter: Forbindelse, Resultat, Forespørgsel. Operationer: opdater, hent DatabaseTolke For alle databasetolkene gør følgende sig gældende: Ansvar: Klassernes ansvar er at omdanne et objekt til en SQL-sætning, når der skal skrives til databasen og omdanne et resultat til objekter, når der læses fra databasen. Formål: Klassernes formål er at fungere som et mellemled (tolk) mellem de respektive klasser og SQL databasen Attributter: forespørgsel: String, resultat: array, forbindelse: Dbforbindelse. For resultat: Array er et array af objekter af den type, som tolken er oversætter for. Det vil sige, at for eksempelvis BetalingsgenstandeTolk er det et array af betalingsgenstande. 49

50 Operationer: Som nævnt i ovenstående implementerer hver tolk fire interfaces. Hvert interface forpligtiger den pågældende tolk til at indeholde en bestemt metode, der returnerer en bestemt type udfra en bestemt inputtype. Disse retningslinjer for operationerne er som følger: Opret: opret(string[]) => void Opdater: opdater(string[]) => void Find: find (String[]) => Resultat Slet: slet(string[])=>void Ydermere er der følgende operationer i nedenstående tolke: AktivitetTolk Operation: find(string); PladsstatusTolk Operation: findledigplads(string) 50

51 9 Komponent Teknisk platform, Systemgrænseflade Komponent Systemgrænseflade er som nævnt under arkitekturen en underkomponent til komponent Teknisk platform. Den tager sig af den udveksling af data, systemet har med andre systemer eller enheder. De andre dele systemet har kontakt med er en magnetkortlæser, samt dataoverførsel til Compusoft. Disse to er placeret i hver sin klasse. For begge klasser gør det sig gældende, at de ikke har egne attributter. Derudover tilgås begge via operationer, der ligger i klasser i andre komponenter. 9.1 Klasser MagnetkortlæserGrænseflade Formål og ansvar: Klassen MagnetkortlæserGrænseflade har til ansvar at håndtere information mellem magnetkortlæseren og brugergrænsefladen. Den har til formål at opdele strengen som systemet modtager fra magnetkortlæseren, så det bliver muligt at anvende de data, der findes på kortet. Den fysiske magnetkortlæser kan anvendes ved indlæsning af data i brugergrænseflade og skal aflaste brugeren med indtastning af personoplysninger CompuSoftGrænseflade: Formål og ansvar: Klassen CompusoftGrænseflade har til ansvar at håndtere den information, der skal afgives til CompuSoft om nye campingpasindehavere. Formålet med denne grænseflade er, at systemet håndterer videregivelsen af oplysninger, således at de der indlogerer på campingpladsen uden campingpas bliver optaget som medlem af Dansk Camping Union, og dermed får tilsendt et campingpas fra Compusoft. Dette sparer altså personalet for manuelt, at skulle distribuere campinpasindehaver info. 51

52 10 Komponent Funktion Komponent Funktion indeholder de komplekse operationer. Operationerne, der er placeret i denne komponent, inddrager alle nogle af de trivielle operationer, der er placeret i komponent Model, hvilket også er argumentet for deres kompleksitet Struktur Komponent Funktion er bygget op over fem klasser: CheckInd, TildelPlads, FindLedigePladser, Omsætning og DagensBetalere. CheckInd er den funktion, hvorunder al check ind foregår, dvs. både de der ønsker en plads med det samme, og de der inden har reserveret en plads. Når en Campingpasindehaver checker ind på Campingpladsen, skal der tildeles en plads. Dette vil også forekomme, når en reservation bliver oprettet. Her vil det blot være et tilfældigt pladsnummer, der bliver tildelt, og det vil ikke nødvendigvis være det, der bliver anvendt under opholdet. Efterfølgende ved check ind vil en ny plads blive tildelt, denne gang den næste ledige plads i rækken. At der sker en tilfældig tildeling af pladser til reservationerne skyldes, at man kan se belægningen på campingpladsen i en fremtidig periode. FindLedigePladser generer en liste over de ledige pladser i et givent tidspunkt. Denne funktion skal skabe overblik over belægningen på campingpladsen. Dagens betalere skal generere en oversigt over de, der skal betale den aktuelle dag. I og med, at der betales forud, vil alle de, der ikke har checket ud inden et givent tidspunkt være at finde under DagensBetalere, forudsat at de ikke har betalt forud for mere end en dag. Omsætningen vil som nævnt under modelkomponenten blive genereret ud fra de indbetalinger, der har været i den angivne periode. 52

53 10.2 Klasser Nedenstående viser en nærmere beskrivelse af klasserne i funktionskomponenten CheckInd Formål og ansvar: Klassen CheckInd har til ansvar at registrere check ind af en campingpasindehaver. For at den kan gøre dette, skal den have input fra de oplysninger, der bliver afgivet i check ind vinduet. Den videregiver efterfølgende input til klasserne Campingpasindehaver og Pladsstatus. Når Check ind er foretaget, er campingpasindehaveren på campingpladsen indtil, vedkommende bliver checket ud, og pladsstatusen ikke længere er aktiv.. Objektet af klassen CheckInd indeholder en aktiv Pladsstatus med de valgte attributter. Operationer: Se operationsspecifikation TildelPlads Formål og ansvar: Klassen TildelPlads har til ansvar at tildele en plads. Når der laves en reservation af en plads i en given periode, tildeles den en tilfældig ledig plads. Når der checkes ind på campingpladsen findes det første ledige pladsnummer. Det vil sige den første ledige plads, der ikke har en aktiv pladsstatus. Derfor kan der på en plads, der har en reservation tilknyttet, godt checkes ind. Reservationen får i så fald tildelt et andet nummer, der ikke har en aktiv pladsstatus tilknyttet. Den eneste undtagelse herfor er ved tildeling af en fast plads, hvor det ikke vil være muligt at checke andre ind på den pågældende plads, hvis der bliver et sammenfald i periode. Operationer: Se operationsspecifikation FindLedigePladser Formål og ansvar: Klassen FindLedigePladser har til ansvar at finde ledige pladser i en valgt periode. Den vil blive anvendt, hvis campingpladsen ønsker en generel oversigt over, de ledige pladser. Klassen vil altså have til formål at vise beliggenheden på campingpladsen. For at finde ledige pladser, vil den skulle tjekke om, der er en aktiv Pladsstatus tilknyttet. 53

54 Operationer: Se operationsspecifikation DagensBetalere Formål og ansvar: Klassen DagensBetalere har til ansvar at vise en oversigt over de pladser på campingpladsen, der skal betale deres gæld den aktuelle dag. Den indhenter information fra Pladsstatus om saldoen, der er beregnet i klassen Gæld fra komponent Model og, hvis denne angiver et negativt beløb, vil den tilhørende plads blive hentet frem. Når en af dagens betalere henvender sig for at lave en indbetaling, vil dette kunne aktiveres direkte fra listen over Dagens betalere. Operationer: Se operationsspecifikation Omsætning Formål og ansvar: Klassen Omsætning har til ansvar at vise omsætningen for en valgt periode. Den skal anvende de indbetalinger, der ligger i klassen Indbetaling i komponent Model. Derudover vil den returnere, hvad det er for betalingsgenstande, der er omsat i den pågældende periode. Operationer: Se operationsspecifikation Operationsspecifikationer For alle klasser i funktionskomponenten er der lavet operationsspecifikationer, grundet kompleksiteten her. Nedenstående viser disse: CheckInd Navn: Kategori: CheckInd _ Aktiv X Passiv X Opdatering _ Aflæsning _ Beregning _ Signalering Formål: Inddata: At checke en campist ind på pladsen. reservationsnummer, campingpasindehaver info, antal voksne, antal børn, fra dato, til dato, strøm true/false, saldo. Betingelser: At der findes en passiv pladsstatus. 54

55 Effekt: Opretter objekter af klassen Campingpasindehaver, sætter Pladsstatus for en tildelt plads til aktiv. Algoritme: CheckInd(String pladsnummer, ArrayList al(cpi info), int antalv, int antalb, long fra, long til, boolean strøm, double saldo) lav ny Pladsstatus. for hver campingpasindehaver infor i al{ lav ny Campingpasindehaver; } Placering: Involverede objekter: Udløsende hændelser: CheckInd Plads, Reservation, Pladsstatus, Campingpasindehaver Check ind TildelPlads Navn: TildelPlads Kategori: _ Aktiv X Passiv X Opdatering _ Aflæsning _ Beregning _ Signalering Formål: Inddata: Betingelser: Effekt: Tildeler en plads til klassen Pladsstatus Campingpasindehaver, pladstype At der findes en passiv pladsstatus. Den tilføjer et pladsnummer til pladsstatus, for at denne enten kan tildeles et reservationsnummer, eller der kan foretages en check ind Algoritme: TildelPlads (String pladstype): pladsliste = alle pladser med ønskede pladstype. for hver Plads i pladstype{ se om den er tilknyttet en aktiv Pladsstatus; hvis nej{ returner Plads } } Placering: Involverede objekter: TildelPlads Plads, Pladsstatus, Reservation 55

56 Udløsende hændelser: Check ind valgt Reservation valgt FindLedigePladser Navn: FindLedigePladser Kategori: _ Aktiv X Passiv _ Opdatering X Aflæsning _ Beregning _ Signalering Formål: At oprette en liste over de pladser, der er ledige i en valgt periode. Inddata: Betingelser: Effekt: Pladsstatus At der er passive objekter af typen Pladsstatus Returnerer en liste med en oversigt med ledige pladser i den valgte periode Algoritme: FindLedigePladser(String pladstype): pladsliste = alle pladser med ønskede pladstype. for hver Plads i pladstype{ se om den er tilknyttet en aktiv Pladsstatus; hvis nej{ tilføj Plads til resultat } } returner resultat Placering: Involverede objekter: Udløsende hændelser: FindLedigePladser Pladsstatus Oversigt over ledige pladser DagensBetalere Navn: DagensBetalere Kategori: _ Aktiv X Passiv X Opdatering _ Aflæsning _ Beregning _ Signalering Formål: At oprette en liste over de pladser, der skal betale den pågældende dag 56

57 Inddata: Betingelser: Effekt: Pladsstatus Der skal eksistere en gæld. Returnerer en liste til brugergrænsefladen med pladsnummer og navne på campingpasindehavere på pladsen. Algoritme: Dagensbetalere(): gældliste = alle Gæld som ikke er betalt; for hver Gæld i gældliste{ lav en resultatpost; Gældsum = hent alle Gældspost tilknyttet gæld og beregn summen af disse; pladsstatus = find pladsstatus som gæld er tilknyttet; gæld = pladsstatus.saldo - Gældsum hvis gæld < 0{ pladsnummer = find plads tilknyttet pladsstatus; campingpasindehaverliste = alle Campingpasindehavere tilknyttet pladsstatus; tilføj gæld, pladsnummer, campingpasindehaverliste pladsstatus til resultatpost; tilføj resultatpost til resultatliste; } } returner resultatliste; Placering: Involverede objekter: Udløsende hændelser: DagensBetalere Pladsstatus, Gæld Dagens hændelser valgt Dagens betalere valgt Omsætning Navn: Omsætning() Kategori: _ Aktiv X Passiv _ Opdatering _ Aflæsning X Beregning _ Signalering Formål: Den skal vise omsætningen i en valgt periode. 57

58 Inddata: Betingelser: Effekt: Algoritme: starttidspunkt: dato & klokken, sluttidspunkt: dato & klokken sluttidspunkt <= aktuelle dag, starttidspunkt < sluttidspunkt Returnerer en liste med indbetalinger i den valgte periode. Omsætning(fra dato, til dato): Placering: Involverede objekter: Udløsende hændelser: indbetalingsliste = alle indbetalinger som er oprettet mellem fra dato og til dato; for hver Indbetaling i indbetalingsliste{ sum = beregn sum af Indbetaling. resultatpost = Indbetaling.dato, Indbetaling.betalingsgenstand, Indbetaling.antal, sum; samletomsætning = samletomsætning + sum; tilføj resultatpost til resultatliste } returner resultatliste, samletomsætning. Omsætning Indbetaling Dagens omsætning eller Omsætning valgt 58

59 11 Komponent Brugergrænseflade Komponent Brugergrænseflade håndterer brugernes interaktion med systemet. Dets grænseflade er bygget op som et vinduesbaseret system. Det er muligt for brugeren at interagere med systemet henholdsvis via mus, tastatur og magnetkortlæser Struktur Klasserne er navngivet med henholdsvis Vindue, Faneblad og Side, hvilket betyder at klassen henholdsvis håndterer et vindue, et faneblad eller en side. Brugergrænsefladen er bygget op omkring klassen HovedVindue. Denne klasse samler alle delene af brugergrænsefladen. Den har en aggregering til klasserne ForsideSide, KundekartotekVindue, CheckIndVindue, PladsstatusVindue, AktivitetVindue, ReservationVindue og IndstillingerVindue. Fra klassen ForsideSide er der en aggregering til klasserne LedigePladserFaneblad, DagensHændelserFaneblad og DagensOmsætningFaneblad. De er alle tre faneblade, der er placeret i hver sin klasse. Dataene i disse bliver genereret når, der sker en interaktion, dvs., når der bliver klikket på fanebladet. Klasserne KundekartotekVindue, CheckIndVindue, PladsstatusVindue, AktivitetVindue, ReservationVindue og IndstillingerVindue hentes ind i hovedvinduet, når de bliver aktiveret via ForsideVindue af referenceknapper eller via menulinje. Klassen ØkonomiVindue hentes kun ind i HovedVindue, når den bliver aktiveret via menulinjen. De referenceknapper, der er på forsiden eller menulinjen, der henter klasserne ind ved interaktion, håndteres af Klassen Actions. Denne klasse hentes både ind i HovedVindue og ForsideSide. Klasserne ReservationVindue, CheckIndVindue og PladsstatusVindue kalder nogle underklasser, hvori de faneblade, der skal vises under disse, er placeret. Nedenstående figur viser klassediagrammet for komponent Brugergrænseflade. 59

60 11.2 klasser Ikke alle klasser understøtter hver af interaktionsmulighederne, mus, tastatur og magnetkortlæser. De første seks klasser i nedenstående er alle med til at opbygge HovedVindue og/eller ForsideVindue HovedVindue Formål og ansvar: Klassen HovedVindue har til ansvar at hente de andre vinduesklasser i komponent Brugergrænseflade, når de aktiveres. Dvs. at hovedvinduet er en beholder for al øvrig indhold i systemet. Den har et statisk indhold, som er en menubar og ForsideSide. Operationskald: ny komponentbrugergrænseflade. vinduesklassenavn (). 60

61 Actions Formål og ansvar: Klassen Actions håndterer interaktion, og sørger bl.a. for at indsætte menubar i HovedVindue og referenceknapper i ForsideSide, når disse aktiveres. Operationskald: komponent.brugergrænseflade.actions() ForsideSide Formål og ansvar: Klassen ForsideSide er et statisk vindue, der bliver kaldt af HovedVindue, og indeholder faneblade samt referenceknapper. Faneblade ligger i klasser, der bliver indsat heri. Referenceknapperne indhentes fra klassen Actions. Figur 26: ForsideSide LedigePladserFaneblad Formål og ansvar: Klassen LedigePladserFaneblad viser ledige pladser for en given periode. Den kalder ned i komponent Funktion, for at få listet oplysningerne. Operationskald: komponentfunktion.findledigepladser.() 61

62 DagensHændelserFaneblad Formål og ansvar: Klassen DagensHændelserFaneblad viser dagens betalere og dagens aktiviteter på det givne tidspunkt, fanebladet aktiveres. Operationskald: komponentfunktion.dagensbetalere.hentskyldnere(), komponentmodel.aktivitet.finddagensaktiviteter(). Figur 27: DagensHændelserFaneblad DagensOmsætningFaneblad Formål og ansvar: Klassen DagensOmsætningFaneblad viser den omsætning, der er den pågældende dag, på det tidspunkt fanebladet aktiveres. På fanebladet listes de betalingsgenstande der er blevet solgt og de enkelte beløb, samt en samlet omsætning. Operationskald: komponentfunktion.omsætning.hentindbetaling() De følgende klasser er de, der bliver aktiveret via referenceknapperne eller menulinjen, samt de tilhørende faneblade. 62

63 ReservationVindue Formål og ansvar: Klassen ReservationVindue har til ansvar, at der kan gennemføres en reservation. Den indsætter ReservationsForsideFaneblad, PersonInfoFaneblad og ReservationsPeriodeFaneblad, der skal benyttes for at oprette reservationen. Operationskald: ny komponentbrugergrænseflade.forsidefaneblad(), ny komponentbrugergænseflade.personinfofaneblad(), ny komponentbrugergrænseflade.reservationsperiodefaneblad() ReservationsForsideFaneblad Formål og ansvar: Klassen ReservationsForsideFaneblad har til ansvar at oprette fanebladet, hvori der skal registreres information om pladstype til den pågældende reservation. Ydermere skal allerede oprettede reservationer kunne åbnes her. Inputmuligheder: pladstype, reservationsnummer(ved afbestilling) Figur 28: ReservationsForsideFaneblad 63

64 PersonInfoFaneblad Formål og ansvar: Klassen PersonInfoFaneblad har til ansvar at oprette et faneblad, hvori der kan indtastes personoplysninger, som skal bruges for at reservationen kan oprettes. Inputmuligheder: fornavn, efternavn, postnummer, telefonnummer Figur 29: PersonInfoFaneblad ReservationsPeriodeFaneblad Formål og ansvar: Klassen ReservationsPeriodeFaneblad har til ansvar at oprette et faneblad, hvor det er muligt at vælge periode for reservationen. Der anvendes en kalender til valg af periode. Inputmuligheder: reservation start, reservation slut, pladsnummer, fast plads, tildel plads, Operationskald: komponentmodel.reservation.opret(), komponentmodel.pladsstatus.opret() 64

65 Figur 30: ReservationsPeriodeFaneblad CheckIndVindue Formål og ansvar: Klassen CheckIndVindue har til ansvar, at der kan gennemføres check ind. Check ind kan enten foregå ved, at der er en forudgående reservation eller ved direkte henvendelse. Operationskald: ny komponentbrugergrænseflade.checkindforsidefaneblad(), ny komponentbrugergrænseflade.campingpasindehaverfaneblad(), ny komponentbrugergrænseflade,vælgperiodefaneblad() CheckIndForsideFaneblad Formål og ansvar: klassen CheckIndForsideFaneblad har til ansvar, at tilbyde valg af pladstype, antal campingpasindehavere, antal voksne og antal børn. Inputmuligheder: reservationsnummer, pladstype, antal campingpasindehavere, antal voksne, antal børn, strøm 65

66 Figur 31: CheckIndForsideFaneblad CampingpasindehaverFaneblad Formål og ansvar: klassen CampingpasindehaverFaneblad indeholder de respektive faneblade, der er blevet genereret via CheckIndForside. Der genereres et faneblad pr valgt antal campingpasindehaver. Det samme faneblad bliver hentet ind af klassen PladsstatusVindue, se beskrivelse om PladsstatusVindue. Inputmuligheder: fornavn, efternavn, adresse, postnummer, telefonnummer, fødselsdato, adgangskortnummer Operationskald: komponentmodel.campinpasindehaver.opret() 66

67 Figur 32: CampingpasindehaverFaneblad VælgPeriodeFaneblad Formål og ansvar: Klassen VælgPeriodeFaneblad har til ansvar at oprette fanebladet, hvori der skal registreres den periode, der vælges check ind for. Der anvendes en kalender til valg af periode. Inputmuligheder: fast pladsnummer, check ind dato, check ud dato. Operationskald: komponentmodel.pladsstatus.opret(), komponentmodel.pladsstatus.opdater(), komponentmodel.pladsstatus.findledigplads() 67

68 Figur 33: VælgPeriodeFaneblad PladsstatusVindue Formål og ansvar: Klassen PladsstatusVindue har til ansvar at indhente henholdsvis en side og et faneblad fra klasserne FindPladsstatusSide og PladsstatusForsideFaneblad, for at kunne lave en søgning efter en given pladsstatus. PladsstatusForside- Faneblad indhenter CampingpasindehaverFaneblad, der er beskrevet under CheckIndVindue, og det allerede udfyldte indhold vises heri. Operationskald: ny komponentbrugergrænseflade.findpladsstatusside(), ny komponentbrugergrænseflade.pladsstatusforsidefaneblad() Inputmuligheder: pladsnummer, campingpasindehaver FindPladsstatusSide Formål og ansvar: Klassen FindPladsstatus har til ansvar at oprette et faneblad, hvor det er muligt at søge efter campingpasindehavere. Det anvendes, hvis ikke man kender det ønskede pladsstatus id, ellers kommer man direkte ind på PladsstatusForsideFaneblad. 68

69 Inputmuligheder: navn, adresse, telefonnummer, campingpasnummer Operationskald: komponentmodel.campingpasindehaver.find(), komponentmodel.pladsstatus.find() Figur 34: FindPladsstatusSide PladsstatusForsideFaneblad Formål og ansvar: Klassen PladsstatusForsideFaneblad har til ansvar at liste de campingpasindehavere, fra klassen CampingpasindehaverFaneblad, der er tilknyttet en given pladsstatus. Det er via PladsstatusForsideFaneblad, at betalingen foretages. Inputmuligheder: betal, antal voksne, antal børn Operationskald: komponentmodel.pladsstatus.find(), komponentmodel.pladsstatus.sæt(), komponentmodel.indbetaling.opret() Se CampingpasindehaverFaneblad for illustration. 69

70 KundekartotekVindue Formål og ansvar: Klassen KundekartotekVindue har til ansvar at liste de campingpasindehavere, der er eller har været tilknyttet campingpladsen. Det skal gøres udfra valgte kriterier. Inputmuligheder: navn, adresse, postnummer, fødselsdato, telefonnummer, blacklistet. Operationskald: komponentmodel.campingpasindehaver.find(), komponentmodel.campingpasindehaver.sæt() Figur 35: KundekartotekVindue AktiviteterVindue Formål og ansvar: Klassen AktivitetVindue har til ansvar at kunne oprette, slette eller ændre en aktivitet. Derudover skal den ansatte via denne klasse kunne tilmelde deltagerantal til en aktivitet. I forbindelse med tilmelding vil der blive lavet en indbetaling. Inputmuligheder: navn, pris, tidspunkt, antal deltagere, højeste antal deltagere. 70

71 Operationskald: komponentmodel.aktivitet.opret(), komponentmodel.aktivitet.sæt(), komponentmodel.aktivitet.find(), komponentmodel.aktivitet.slet(), komponentmodel.indbetaling.opret() Figur 36:AktiviteterVindue Nedenstående klasse bliver kun aktiveret via menulinjen ØkonomiVindue Formål og ansvar: Klassen ØkonomiVindue har til ansvar at vise statistik indenfor betalingsdelen. Den vil skulle vise sammenligningen af omsætning på en given dato med den samme dato året før. Inputmuligheder: fra dato, til dato. Operationskald: komponentmodel.indbetaling.find() ØkonomiVindue er ikke afbilledet. 71

72 Nedenstående klasser skal håndtere administratordelen, som er der, hvor man kan lave indstillinger for henholdsvis Plads og Betalingsgenstand IndstillingerVindue Formål og ansvar: Klassen IndstillingerVindue har til ansvar at hente IndstilPriser- Faneblad eller IndstilPladserFaneblad, samt at håndtere tilgangen til disse ved brug af adgangsbeskyttelse. Inputmuligheder: password IndstilPriserFaneblad Formål og ansvar: Klassen IndstilPriserFaneblad har til ansvar, at der kan ændres på prisen for betalingsgenstandene. Inputmuligheder: pris Operationskald: komponentmodel.betalingsgenstand.find(), komponentmodel.betalingsgenstand.sæt() Figur 37: IndstilPriserFaneblad 72

73 IndstilPladserFaneblad Formål og ansvar: Klassen IndstilPladserFaneblad har til ansvar at tilføje nye pladser, slette gamle pladser, eller ændre pladstypen på et givent pladsnummer. Inputmuligheder: pladsnummer, pladstype. Operationskald: komponentmodel.plads.find(), komponentmodel.plads.slet() komponentmodel.plads.opret(), komponentmodel.plads.sæt() Figur 38: IndstilPladserFaneblad 73

74 Del III: Implementering og Test 74

75 12 Implementering 12.1 Afgrænsning I det følgende beskrives udvalgte dele af det implementerede design. Systemet er implementeret i Java 2. Der er oprettet en tilhørende database, som er implementeret i MySQL. Der er under udviklingen blevet lagt vægt på, at systemet skal indeholde den funktionalitet, som er beskrevet i designdokumentet. Dog er der lavet en afgrænsning for, hvad der er blevet implementeret. Hovedvægten er blevet lagt på den mest grundlæggende funktionalitet såsom reservation, check ind, check ud samt betaling. De dele af systemet, der ikke er blevet implementeret, men som vil være en del af et færdigt system, omfatter administratordelen til indstillinger i forbindelse med pladser og betalingsgenstande. Funktionen til at oprette campingpas hos CompuSoft A/S er heller ikke implementeret i systemet, grundet manglende information om, hvilke data firmaet skal have, og hvordan det skal formidles til dem Struktur Under implementeringen af systemet er dets klasser blevet organiseret i en komponentstruktur, som bygger på komponentarkitekturen fra designdokumentet. Der er derfor følgende komponenter i implementeringen af systemet: Komponent Brugergrænseflade, komponent Model, komponent Funktion, komponent System herunder komponent DatabaseTolk og komponent Systemgrænseflade Kodestandard Variablerne i klasserne er så vidt muligt navngivet på baggrund af navnene i designdokumentet. Til notation er Kamelnotationen anvendt. Det vil sige, at alle mellemrum i navnene er fjernet og i stedet har ordene efter mellemrummet fået store begyndelsesbogstaver, og alle variablerne har fået små begyndelsesbogstaver. Her følger et eksempel på et variabelnavn fra klassen Aktivet: højesteantaldeltagere. 75

76 Klasserne er navngivet på næsten samme måde, blot med store begyndelsesbogstaver. Eksempelvis DagensBetalere, som er placeret i Funktionskomponenten. Definitionen af variabler er sket så tæt på operationerne, der anvender dem, som muligt, for at øge kodens læsbarhed. De forskellige blokke i koden er struktureret som eksemplificeret herunder: public metodensnavn(){ int i = 40; int gæld = Bank.hentGæld(inputData); if(i< gæld){ gøretellerandet(); } } Blokstart-parantesen er placeret i samme linie som operationskaldet, og blokkens instruktioner er rykket fire karakterer til højre for at øge overskueligheden, og dermed gøre det lettere at se, hvornår en blok starter og slutter. Blokslut-parantesen er placeret lodret under det første tegn i metodekaldet Komponent Model For at undgå at metodekald fra klasser udenfor komponent Model ændrer attributterne til noget forkert, er alle attributter lavet private. For at kunne ændre attributterne, er der oprettet metoder for hver attribut, der kan ændre disse, hvis de får et input af den korrekte type. Denne indkapsling sikrer kontrol og konsistens i variablerne. Herunder følger et eksempel på to operationer, der henholdsvis sætter og henter attributten titel: public void sættitel(string tit){ this.titel = tit; AktivitetDB.hentAktivitetDB().opdater(this); } public String henttitel(){ return(titel); } 76

77 Alle klasserne indeholder to konstruktører. Den ene anvendes til at oprette nye objekter, og den anden benyttes til at gendanne objekter, som hentes fra databasen. Den umiddelbare forskel er at konstruktøren, der opretter nye objekter tildeler objektet et unikt id. De objekter som hentes i databasen vil allerede være tildelt et id, så derfor er der denne forskel. Id et er af den primitive datatype long og sættes til antallet af millisekunder siden 1. januar 1970(Unix Epoch format) Komponent DatabaseTolk DatabaseTolkene kaldes fra operationer i Komponent Model, som opretter et StringArray med de ønskede parametre. De returnerer en SQL-streng, der anvendes til kald i databasen. Denne SQL-streng sendes til klassen DBForbindelse, som sørger for at oprette forbindelse til databasen, sende SQL-strengen, lukke forbindelsen til databasen og fange eventuelle fejl, der måtte opstå, når der skrives til eller hentes fra databasen Komponent Systemgrænseflade Denne komponent indeholder klassen KortTilJava, hvis formål er at opdele strengen, som systemet modtager fra magnetkortlæseren. Strengen, som systemet modtager, er inddelt i nogle faste index er. Kodeeksemplet viser, at operationen benytter disse index er til at opdele strengen i mindre dele, som hver indeholder data, der kan anvendes i systemet. Kodeeksemplet viser også, hvordan ø og å bliver indsat i strengen i stedet for \ og. navne = inp.substring(1,34); splitpkt = navne.indexof('&'); fornavne= navne.substring(splitpkt+1,33).trim().replace('\"','ø').replace(' ','Å'); efternavne=navne.substring(0,splitpkt).trim().replace('\"','ø').replace(' ','Å'); 77

78 12.7 Komponent Brugergrænseflade Komponent Brugergrænseflade er opbygget således, at hvert vindue ligger i egne klasser. Indholdet i disse vinduer er opdelt i klasser, der hver især indeholder genbrugelige elementer. Når de øvrige klasser skal bruge et sådant element, kalder de ned i klassen, hvor elementet befinder sig. Knapper eller indstillinger, der anvendes i flere klasser, er også samlet i klasser for sig, hvor de øvrige kalder til ved brug. Ovenstående øger muligheden for kun at ændre et samlet sted, og ændringerne træder i kraft i alle de klasser, der anvender derfra. Derudover skal opbygningen være med til at gøre koden mere overskuelig. De standardbiblioteker, der er anvendt, som er specielle for komponent brugergrænseflade, er henholdsvis java.awt og java.swing. 78

79 13 Kodetest Der er gennemført black box test på de tre klasser DBForbindelse, Pladsstatus og DagensBetalere. Grunden til at valget er faldet på netop disse tre klasser er at, DBForbindelse bliver benyttet meget ofte i systemet. Stort set alle funktioner i systemet enten læser eller henter fra databasen. Dermed blev det vurderet at, det er en klasse der er vigtigt at få testet. Endvidere blev det valgt at teste de mest komplekse funktioner i systemet, som er placeret i DagensBetalere og Pladsstatus. Systemets klasser skjuler så meget information som overhovedet muligt for andre klasser, ved hjælp af private metoder, derved er det begrænset, hvad der er mulighed for at teste med black box test. Det er vurderet at, ved at teste de nævnte klasser, bliver kerneområderne af systemet testet. Der er testet public metoder i de to klasser. I DagensBetalere klassen drejer det sig om metoden hentskyldnere(), og i DBForbindelse er det metoderne hent() og updt(), der er testet. I Pladsstatus blev konstruktørerne testet. I klassen DagensBetalere er en funktion hentskyldnere(), der søger igennem databasen efter gældsobjekter, der ikke er blevet betalt. Hvis funktionen finder et ubetalt gældsobjekt, kæder den denne sammen med en campingpasindehaver, og tilføjer denne manglende betaling til en arrayliste over dagens manglende betalinger, og efterfølgende skriver den listen ud på skærmen. Måden hentskyldnere() metoden er testet på, er ved gennem et assertnotnull udtryk at kontrollere, om det er muligt at oprette en arrayliste af skyldnere fra databasen. Hvis det er muligt at oprette denne liste, fungerer funktionen efter hensigten. Klassen DBForbindelse er klassen der opretter forbindelse til databasen, og udfører de SQL-sætninger specificeret i programmet, hvorefter klassen også har ansvaret for at lukke forbindelsen til databasen igen. For at kontrollere om hent() metoden i DBForbindelse virker efter hensigten, er denne metode testet, ved at se om det er muligt at hente alt gæld ud af databasen. Med en SQL-sætning konstrueret til formålet. Der oprettes et result set med de forekomster i tabellen gæld i databasen hvor betalt = false, altså de gældsobjekter der ikke er ble- 79

80 vet betalt. Efter der er hentet dette result set, benyttes en lykke til at løbe samtlige objekter igennem, og tester på om det er korrekt, at disse ikke er blevet betalt. Metoden updt() i klassen DBForbindelse testes ved at indlægge en test række i tabellen betalingsgenstand i databasen, som benyttes til at skrive og hente data fra. Der er lavet en test der opdatere en pris i tabellen betalingsgenstand. Det gøres ved at sætte prisen til det nuværende tidspunkt i millisekunder ved hjælp af updt() metoden. Derefter kontrolleres at det er sket, ved at sammenligne det tidspunkt sendt af sted i SQLsætningen med den værdi der rent faktisk ligger i databasen. Hvis de to indeholder den samme værdi, fungerer funktionen som ønsket. Der benyttes et asserttrue udtryk til at teste dette. De to konstruktører testet i Pladsstatus er dem der opretter en helt ny Pladsstatus i systemet, og den der henter data fra databasen, og genkonstruerer et objekt at typen pladsstatus. For at teste om der kan oprettes en ny Pladsstatus, er der oprettet et objekt med nogle testdata, som sendes til Pladsstatus, hvorefter objektet hentes ud af databasen igen, og det kontrolleres hvorvidt det er de korrekte data, der er gemt. Konstruktøreren i Pladsstatus kaldes igen, denne gang bare med et parameter mere nemlig id et på den pågældende Pladsstatus der ønskes hentet ud af databasen. Denne gang benyttes hent-metoderne i Pladsstatus til at kontrollere at der er overensstemmelse med det objekt der ønskes hentet ud fra databasen, og det der rent faktisk er hentet Kodetest Resultater Under testes af DBForbindelse klassen blev der fundet en fejl databaseforbindelsen blev ikke lukket efter brug, hvis denne fejl ikke var blevet opdaget til det resultere i at MySQL serveren på et tidspunkt vil overskride det antal forbindelser, det er muligt for databasen at håndtere på en gang. Denne fejl i programmet blev fundet ved at benytte asserttrue på om connection.isclosed() == true hvis den var lukket ville testen forløbe uden fejl. Dette var ikke tilfældet. Som et resultat af dette er koden omstruktureret sådan at det ikke kan lade sig gøre at oprette en databaseforbindelse uden at den også bliver afsluttet. Som koden er struktureret nu, er det ikke muligt at black box teste på, om forbindelsen bliver 80

81 lukket efter brug, da den nu er private. Derfor indgår den ikke i den nuværende black box test. Den nuværende black box test af de tre klasser førte ikke til belysning af nogen fejl i systemet, det skyldes, at de fleste data er lagret i databasen som datatyperne long, string og bool. Dette medfører at der i mange tilfælde ikke opstår nogen direkte fejl, da systemet ikke er særlig følsom over de input der bliver givet. 14 Brugervenlighedstest Der er foretaget en brugervenligheds test hvor der blev benyttet tænke højt metoden, testen blev gennemført i Aalborg Universitets Usability Lab. Testen blev gennemført mandag den 9/ Testen er foretaget ved at bede tre testpersoner løse fire opgaver med systemet overvåget og guidet af en testleder. Opgaverne omhandler de tre hovedfunktioner i systemet, check ind, check ud og reservation. Desuden blev der stillet spørgsmål om hvordan en betalings situation kunne gennemføres, og hvordan adgangen til funktionen på grænsefladen kunne se ud, og hvilken betegnelse knappen kunne have Resultater Her listes de væsentligste punkter, hvor der var positiv feedback. Kalender: Kalenderfunktionen fungerede godt, alle testpersonerne fandt forholdsvis hurtig ud af at vælge den rette reservationsperiode. Menu knapper: Menu knapperne på brugergrænsefladen fungerede godt, det eneste, der kunne skabe tvivl om forståelighed var at en testperson ville oprette en kunde før at en reservation foretages. Tvivlen opstod på grund af testpersonens manglende forståelse for, hvordan det specifikke administrationssystem fungerer. Da testpersonen blev guidet på rette vej, kunne han godt se det logiske i det. Check ud og check ind funktionen: Funktionerne virkede overraskende godt der var så godt som ingen problemer med at vælge pladstype, indtastning af oplysninger og vælge reservationsperiode. 81

82 Negative resultater Her listes de væsentligste, hvor der var negativ feedback. Placering af markør i fornavnfelt: Når magnetkortlæseren skal bruges til indlæsning af persondata skulle markøren placeres i fornavnfeltet. Manglende bekræftelse af udførte handlinger: Der manglede bekræftelser på udførte handlinger, testpersonerne var i tvivl om deres fx reservation var gemt i systemet. Testpersonen havde egentligt gennemført opgaven men var ikke sikker på at systemet havde registreret det. Manglende Betalings knap: Testpersonerne eftersøgte en knap der hed betaling, hvor det var muligt at gennemføre en betaling for en dag frem Det videre arbejde Det videre arbejde på systemet skal koncentrere sig om, at eliminere den tvivl der var, om en handling var udført samt arbejde på at placere markøren i fornavnfeltet idet at personoplysningsfeltet åbner. Det videre arbejde i prioriteret rækkefølge: Der skal laves bekræftelsesvinduer, der fortæller brugeren hvilken handling, der er ved at blive gennemført, og først ved et tryk på ok er handlingen gennemført. Der skal laves en knap med en beskrivende betegnelse så brugerne kan gennemføre en betaling. Testpersonernes forslag var at knappen skulle have betegnelsen Betaling. Egentlig skulle en betaling gennemføres under den eksisterende knap Pladsstatus. 82

83 15 Kildeliste 15.1 Bøger Titel: Objektorienteret analyse og design (3. udgave). Forfatter: Mathiassen, Lars et al. ISBN: Forlag/år: Forlaget Marko ApS, Aalborg Titel: Thinking in Java (2nd ed.) Forfatter: Eckel, Bruce ISBN: Forlag/år: Prentice-Hall Inc, Upper Saddle River, New Jersey Titel: User Interface Design, A Software Engineering perspective Forfatter: Lauesen, Søren ISBN: ingen (Kompendium) Forlag/år: ingen Titel: Brugervenligt webdesign Forfatter: Molich, Rolf ISBN: Forlag/år: Ingeniøren bøger, Københaven Titel: Java: how to program (3rd ed.) Forfatter: Deitel, Harvey M. et al. ISBN: Forlag/år: Prentice-Hall Inc, Upper Saddle River, New Jersey Titel: Objektorienteret programmering i Java, 2. udgave Forfatter: Nordfalk, Jacob ISBN: Forlag/år: Forlaget Globe, Nærum

84 Titel: Beginning Java 2 (JDK 1.3 Edition) Forfatter: Horton, Ivor ISBN: Forlag/år: Wrox Press Ltd, Birmingham Titel: Beginning Java Databases Forfatter: Mukhar, Kevin et al. ISBN: Forlag/år: Wrox Press Ltd, Birmingham Internetsider Titel: Java dokumentation Adresse: Set: 17. december 2002 Titel: JUnit dokumentation Adresse: Set: 17. december 2002 Titel: Microsoft Windows 2000 systemkrav Adresse: Set: 17. december 2002 Titel: Dialogdesignrapporter vedr. tænke højt tests Adresse: Set: 17. december

85 Studierapport Gruppe E2-109 Aalborg Universitet 19. december 2002

86 2

87 Indholdsfortegnelse 1 Indledning Valg af emne Etablering af kundekontakt Interview Første interview med Action House Camping Formål Fremgangsmåde Resultat Andet interview med Action House Camping Formål Fremgangsmåde Resultat Analyseforløbet Refleksion Designdokument Refleksion Implementering Programtest Refleksion Brugervenlighedstest Test-metode Formål Fremgangsmåde Refleksion Konklusion Appendiks Appendiks 1: Prototyper Appendiks 2: Testopgaver Appendiks 3: Testdeltagere Appendiks 4: Testforløb Appendiks 5: Testresultater

88 4

89 1 Indledning I studierapporten vil de processer, som er gennemløbet under analyse, design, implementering og test blive behandlet ud fra de valg, der er blevet truffet og disses argumenter. Derudover vil der være yderligere fokus på brugergrænseflader, da det er et ønske fra Action House side. 2 Valg af emne Efter brainstorm over forskellige projektforslag faldt valget på et reservationssystem til en campingplads i Løkken, hvor der var mulighed for et tæt samarbejde med de mulige brugere af det system, der skulle udvikles. Dog er den påtænkte campingplads ikke anlagt, hvilket betød at der ikke var mulighed for at tage ud i felten og undersøge arbejdsgangen på den specifikke campingplads. Dette ville dog heller ikke have været hensigtsmæssigt på grund af årstiden, da aktiviteten på en campingplads er meget sæsonpræget og størst om sommeren. 3 Etablering af kundekontakt Et af gruppens medlemmer havde kendskab til, at der skulle åbnes en ny campingplads i Løkken, hvilket var en oplagt mulighed for at etablere en ekstern kontakt. Der blev rettet henvendelse til de personer, der stod for etableringen af campingpladsen. Efter en telefonisk samtale hvor formålet med projektet blev opridset, udviste de stor interesse for et samarbejde, og der blev aftalt et møde. Gennem projektforløbet blev campingpladsen benævnt som Action House Camping. Det skyldes, at folkene bag campingpladsen ejer et aktivitetshus, der netop hedder Action House. Vi gav den et fiktivt navn, da campingpladsen ikke er navngivet. Systemet der udvikles, har vi navngivet CampIT. 4 Interview Nedenstående afsnit beskriver de to interview, der blev afholdt med Action House Camping under udviklingsperioden. 5

90 De blev begge afholdt under udarbejdelsen af analysedokumentet. Det andet interview dannede dog også baggrund for dele af designdokumentet. 4.1 Første interview med Action House Camping Formål Formålet med det første interview med Action House Camping var, at belyse problemområdet og anvendelsesområdet således at, der kunne udarbejdes et virkelighedsnært analysedokument, og en kravspecifikation til systemet. Derudover skulle de rammer, det videre samarbejde skulle foregå under, fastlægges, for løbende at verificere at projektet forblev i overensstemmelse med deres ønsker Fremgangsmåde Opbygningen af interviewet, var planlagt således at gruppens eksterne kontaktperson fremlagde vores ideer til systemet og planerne til det videre samarbejde for Tommy Jensen 1 ved Action House. Grunden til at der kun var et gruppemedlem til interviewet, som desuden kendte Tommy Jensen, var for at undgå at presse vores ideer igennem, og i stedet skabe en åben dialog Resultat Interviewet gav følgende output i form af krav til systemet: 1. Det skal være muligt at udskrive en liste over campister på alle pladser. Det skal herunder også være muligt at se, hvem der har modtaget advarsler mm. 2. Systemet skal kunne håndtere adgangskort/betalingskort til anvendelse på pladsen. 3. Som administrator skal man selv kunne flytte rundt på pladser. Det kunne f.eks. ske ved hjælp af drag and drop på oversigtskortet over pladsen. 1 Tommy Jensen er én af fire brødre, som ejer Action House i et anpartsselskab, han har ydermere den kvalifikation, at han tidligere har forpagtet en campingplads 6

91 4. Administrationen skal også kunne tildele en specifik plads til en reservation, men ellers vil genereringen af pladser være vilkårlig, således at den næste ledige plads bliver tildelt. På baggrund af disse resultater, samt research om andre eksisterende campingpladser, blev der udarbejdet et analysedokument. For at verificere at projektet stadig fulgte kundens ønsker, skulle der udføres endnu et interview. 4.2 Andet interview med Action House Camping Formål Formålet med det andet interview var, at følge op på hvorvidt projektet stadig fulgte Action Houses ønsker. Det blev gjort ved at undersøge følgende: Arbejdsgangene beskrevet i Analysedokumentet, stemmer de overens med deres ønsker. Hvilke funktioner de finder væsentlig i systemet Hvilke funktioner skal der være på samme skærmbillede Fremgangsmåde Interviewet blev afholdt i Aalborg Universitets Usability Laboratorium, og resultaterne blev dokumenteret på video. Dette skyldes, at alle gruppemedlemmerne dermed får mulighed for at overvære interviewet, hvilket kunne hjælpe til en fælles forståelse af de ønsker, Action House Camping havde til systemet. For at verificere analysedokumentet blev kravspecifikation tilsendt brugerne på forhånd, hvorefter det så blev diskuteret hvorvidt, det var hvad de havde forestillet sig. Beskrivelsen af anvendelsesområdet, som også skulle verificeres, blev beskrevet for dem i form af et mundtligt resume. For at få belyst hvilke ønsker der var til brugergrænsefladen, blev der i samarbejde med brugerne, udarbejdet skitser af hvordan de kunne forestille sig, det kunne se ud. Dertil blev der så diskuteret hvilken funktionalitet, de enkelte elementer i brugergrænseflade skulle dække over. Denne tilgangsvinkel blev benyttet for at skabe et så brugervenligt system som muligt, ved at formidle deres billede, af hvordan der skulle interageres med systemet, ned på papir. Oprindeligt var det planlagt, at det kun var gruppemedlemmet, som havde udført det første interview, der skulle deltage, for at skabe vante rammer for kunden, og for at undgå at kunden ikke følte sig presset af et flertal. Eftersom der var to repræsentan- 7

92 ter fra Action House Camping, der mødte op, deltog et ekstra gruppemedlem, således der var to til at koordinere og forstå Resultat Interviewet medførte en sidste iteration af analysedokumentet, ud fra kommentarerne de havde til de dele af analysedokumentet, der var blevet diskuteret. Skitserne som var blevet udviklet under interviewet, fungerede som prototyper for hvordan brugergrænsefladen skulle designes (Se Appendiks 1: Prototyper). Flere af kundens kommentarer svarede også på problemstillinger, som opstod under udarbejdelsen af designdokumentet, hvor der så var mulighed for at henvise til dokumentationen af interviewet, som var på video. 5 Analyseforløbet I en lang periode blev analysedokumentet revideret op til flere gange, hvilket resulterede i ændringer i både klassediagram, tilstandsdiagram og funktionslister. Samtidig blev det konkluderet, ud fra første interview, at det var et administrationssystem, der skulle udvikles. Klassediagrammet var som udgangspunkt mere komplekst end det endelige. Plads var inddelt i fysisk plads og pladstype, herunder telt, campingvogn og hytte. Samtidig var der en campistklasse, der var opdelt yderligere i campingpasindehaver og øvrige beboere. Måden at opdele plads på blev forkastet, da det ikke var nødvendigt, og det var mere logisk med attributter under en hovedklasse, der hed Plads. Efter andet interview med Action House Camping blev delen med campister revideret. Det viste sig, at de eneste informationer, der var nødvendige for campingpladsen var campingpasindehaveren, og de der ikke var noteret som en sådan, kun skulle noteres som et antal. Øvrigebeboere var derfor nu en klasse uden egentlige attributter, hvilket gjorde den irrelevant. Campist og øvrige beboere blev af ovenstående årsager fjernet fra klassediagrammet, hvilket efterlod klassen Campingpasindehaver. Den klasse indeholdt oplysninger om den enkelte campingpasindehaver. 8

93 Funktionslisten ændrede sig primært på grund af, at systemet skulle håndtere flere ting end oprindelig tænkt, efterhånden som analysen skred frem. Det vil sige, at den primære ændring her var tilføjelser af funktioner, for at systemet kunne leve op til de krav, vi og Action House Camping endte med at have til systemet efter andet interview. Efter første review, hvor der blev fremsat nogle brugbare kommentarer, blev der lavet de sidste generelle ændringer i dokumentet, og det blev besluttet at stoppe processen indenfor dette område. Ændringer, der kommer set i forhold til dette dokument, indsættes i designdokument under Rettelser til analysen. Der skulle på dette tidspunkt ikke komme gennemgribende ændringer, der har betydning for den måde analysen hidtil har været anskuet. 5.1 Refleksion Efter endt analyseforløb må det konkluderes, at det tidsmæssigt har været en omkostningsfuld proces. Der er gennemløbet en del iterationer, der hver især har medført store ændringer for hele analysedokumentet. Dette har medført et system, der favner bredt og indeholder en stor del funktionalitet. Det har løbende gjort processen mere spændende men også mere kompleks. Hvilket medførte, at der måtte nedprioriteres at implementere dele af programmet, hvilke er belyst under afsnittet designforløbet. Derudover ville det muligvis have været en hjælp at afholde andet interview på et tidligere tidspunkt, da vi her fik det primære input, for at gennemskue henholdsvis problem- og anvendelsesområde. Omvendt skyldes dette måske netop, at vi selv havde gjort os så mange tanker, at vi derfor i andet interview havde baggrund for at spørge bedre ind til områderne. 9

94 6 Designdokument I forbindelse med udvikling af designdokumentet er der sket mindre ændringer i forhold til anskuelse af analysedokumentet. Klassediagrammet har under designforløbet ændret sig meget. Under arbejdet med modelkomponenten, har flere klasser vist sig nødvendige. Især på betalingsdelen har det vist sig fornuftigt at udspecificere dette mere grundigt, end i det oprindelige klassediagram. Der var også større fokus på denne del under designforløbet, end under analyseforløbet. Hvor der, som udgangspunkt slet ikke var fokus på dette område. Det var Action House Camping der fandt økonomidelen væsentlig, hvilket danner den primære grund til det øgede fokus på dette område. I design forløbet havde vi haft svært ved at danne overblik over, hvordan arkitekturen skulle opbygges. Primært hvornår brugergrænsefladen skulle benytte funktionskomponenten eller modelkomponenten, hvis den altså skulle have adgang til begge dele. Efter først at have lavet en modelkomponent uden operationer, blev dette ændret til at den også skulle indeholde operationer. Hvis det ikke var gennemført, ville det betyde, at alle operationer skulle ligge i funktionskomponenten, men det blev ikke fundet hensigtsmæssigt for trivielle operationer. Det blev derfor valgt, at alle trivielle operationer skulle kaldes fra modelkomponenten, og kun de mere komplekse operationer, der også benyttede sig af andre operationer, skulle ligge i funktionskomponenten. Dette resulterede i et klassediagram over modelkomponenten, hvor klassens navn, attributter og operationer blev beskrevet, og det indbyrdes forhold blev illustreret, samt et klassediagram over funktionskomponenten, der indeholdt attributter og operationer til disse. Derudover blev der lavet en operationsspecifikation til hver af de 4 metoder i funktionskomponenten, hvori formålet, betingelser, effekt, algoritme, placering og udløsende hændelser blev beskrevet. Alle 4 klasser blev beskrevet, da de alle blev anset som værende komplekse, hvilket medførte placeringen i funktionskomponenten. Det blev valgt at anvende en database, som systemet anvender til lagring af de objekter, der forekommer. Til dette blev der valgt MySQL, da databasen levede op til de behov, der var i forbindelse med udviklingen af systemet. 10

95 Brugergrænsefladen blev i store træk designet ud fra andet interview sammen med Action House Camping. Designet blev dog efterfølgende testet i en brugervenlighedstest, som vil blive behandlet i et senere afsnit. Webdelen har vi valgt ikke at fokusere på i designdokumentet, da det allerede under analyseforløbet blev besluttet, ikke at implementere denne del af systemet, da den adskiller sig meget fra den øvrige del af systemet. Efter andet review, hvor designdokumentet blev evalueret, viste det sig, at der stadig manglede en del arbejde på dokumentet. I alle afsnittene i dokumentet var der større eller mindre problematikker, som medførte følgende ændringer: Arkitekturen blev justeret således, at den blev mere tilrettet vores system i forhold til, hvordan de enkelte komponenter er bundet sammen. Modelkomponentens klassediagram blev ændret og simplificeret, hvor det var muligt. Ansvar og formål blev beskrevet for hver af klasserne. Attributter og operationer for hver af disse blev rykket ned under disse, således at alt om klassernes indhold var samlet et sted. Struktur og sammenhænge blev beskrevet for at tydeliggøre, hvad der sker i denne komponent, samt hvordan de forskellige klasser har indflydelse på hinanden. Funktionskomponentens klassediagram valgte vi at fjerne fra dokumentet, da der ikke var nogle bindinger mellem de forskellige klasser. Klassediagrammet havde derfor ikke en egentlig berettigelse eller nytte i dokumentet. Som i modelkomponenten er der for hver klasse skrevet formål og ansvar. Også her blev attributter og operationer placeret under disse i deres respektive klasser. Brugergrænsefladekomponent og Teknisk platform komponenten blev for begges vedkommende ændret i høj grad således, at også deres opbygning er som henholdsvis model- og funktionskomponenten. Efter implementering af forslagene fra andet review, blev arbejdet med designdokumentet midlertidigt afsluttet. Designdokumentet er bygget op således at det giver læseren størst mulig chance for at kunne forstå systemet. Opbygningen er som følger: Komponentmodel, Databasetolk, komponent teknisk platform, komponentfunktion, komponentbrugergrænseflade. 11

96 6.1 Refleksion Efter færdiggørelsen af designdokumentet måtte det erkendes at en del af de problemer, der opstod i tilknytning til dette afsnit, skyldes manglende overblik over denne del af udviklingsforløbet. Det har resulteret i forholdsvis lang tid på at diskutere og fastlægge opbygningen af denne proces uden, at det har givet direkte resultater. Derfor er væsentligheden i at udarbejde en struktur og danne sig et samlet overblik, over de bestanddele et givent område har, efterfølgende blevet diskuteret inden det blev påbegyndt. Nogle af de ting, der blev informeret om under andet review såsom konsistens, burde ikke have været nødvendigt, at få kommentarer på, da dette allerede var noget, der blev kommenteret under første review, hvor analysedokumentet blev gennemgået. 7 Implementering Relativt sent i projektforløbet blev programmeringen af systemet påbegyndt. Først efter udarbejdelse af første udkast til designdokumentet er der kommet hul til denne del. Dog allerede efter andet interview blev der arbejdet på brugergrænsefladen i og med, at udkastet til dele af denne var blevet tegnet. Der blev stiftet bekendtskab med nogle af de WYSIWYG programmer, der findes til at lave grafiske brugergrænseflader (VisualMust, Sun One Studio og BuildIT). På grund af manglende fleksibilitet og varierende kvalitet af koden, med hensyn til overskuelighed, blev disse værktøjer forkastet. Dette medførte at programmering af brugergrænsefladen blev skrevet fra bunden. I forbindelse med programmeringen af databasetolkene forekom der store vanskeligheder, som sænkede meget af det øvrige arbejde. Grunden til dette var, at mange af de andre komponenter skulle bruge netop databasen for, at der kunne arbejdes videre med disse. Efter at der kom hul til databasen viste det sig, at der skulle laves ændringer i de forskellige klasser i modelkomponenten for at de kunne fungere sammen. Magnetkortlæseren kom relativt hurtigt til at fungere, således at data fra et sygesikringsbevis kunne indlæses i systemet. Denne viste sig at være et effektivt værktøj til input af data til systemet. 12

97 7.1 Programtest Efter diskussion om, hvordan programkoden skulle testes, var der enighed om black box test. Baggrunden for denne beslutning er, at der dels under forelæsningen om test af koden var rådet til denne testform, dels at vi fandt den mest overskuelig set i forhold til det tidspres, koden skulle laves under. Argumentationen for fordelen ved en white box test opvejede ikke det ekstra arbejde, som det ville kræve. Følgende vil kort opridse de to testforme for yderligere at kunne argumentere for vores valg. White box test Udgangspunktet for en white box test er, at testeren kender programmets interne struktur. Kildekoden bliver således udgangspunkt for en white box test. Ved anvendelse af white box test skal hver enkelt sti i systemet afprøves mindst en gang. Derudover skal alle forgreninger af boolske udtryk afprøves. Ved randtilfælde findes fejl og de skal testes. Black box test Det der ønskes testet ved en black box test, er udelukkende afpassede og velvalgte input. Formålet med testen er primært at tjekke for funktionalitetsfejl, dvs. om der opnås de rigtige resultater på de givne input eller ej. Der kontrolleres også om, der er fejl ved en enheds grænseflade til en anden enhed. Sekundært afslører testen andre ting, såsom effektivitet. Det problematiske ved en black box test er, at udvælge de input, der skal afprøves. Som ovenstående viser vil en white box test kræve, at man skal ende op med et fuldstændig gennemtestet system. Det vil som udgangspunkt også være logisk at stræbe efter, men dette blev vurderet som problematisk at gennemføre i vores tilfælde. Men også grundet at store dele af systemet er trivielle, hvilket ikke modsvarer, at der skal forelægge testarbejde i den grad, som en white box test dikterer. Testene skulle også have været skrevet sideløbende eller før koden, da det ellers bliver meget uoverskueligt. 7.2 Refleksion Resultaterne af black box testen for klasserne DBForbindelse, DagensBetalere og Pladsstatus var som forventet. Databaseforbindelsen opretter og lukker forbindelsen til databasen som den skal. Det er ligeledes muligt at finde frem til en liste over 13

98 dagens betalere. Der kan oprettes et pladsstatusobjekt, som kan gemmes i databasen. Disse oplysninger kan hentes fra databasen og objektet kan genetableres. Da systemet er forholdsvis overskueligt og ikke indeholder funktioner, der er særlig komplekse eller omfattende, fik vi ikke meget ud af at teste vores program. Hvis der tidligere i projektforløbet var benyttet en anden strategi til at udvikle systemet, nemlig at skrive testen først og efterfølgende skrive selve programkoden ville vi have fået et andet udbytte af testen. Hvis testen havde været skrevet, før vi havde et funktionsdygtigt program, ville pointen ved at skrive tests også være blevet tydeligere. For implementeringsdelen er den generelle problemstilling dog, at der som udgangspunkt i gruppen en ringe programmeringserfaring, hvilket selvfølgeligt afspejler sig under denne proces. Det vil muligvis have været givtigt for os at starte denne proces tidligere, således at der havde været tid til at sætte sig grundigere ind i sproget som udgangspunkt. Den endelige variabelnavngivningen til operationerne i systemet er afsluttende blevet vurderet som uhensigtsmæssige, eftersom disse har fået usigende navne. Dette er problematisk eftersom disse benyttes til klassernes interfaces. 8 Brugervenlighedstest Eftersom fokus for studierapporten er på brugergrænseflade og specielt brugervenligheden, er der for at teste hvorvidt dette er opnået, blevet udført en Tænke højt test. Action house Camping har under hele forløbet selv pointeret væsentligheden af brugervenlighed i systemet, netop grundet at indlæringskurven ikke må være lang. Opbygningen skulle være ligetil og logisk opbygget sådan, at den svarer til, hvordan man løser en opgave i den rækkefølge delelementerne af opgaven kommer i Test-metode For at teste brugervenligheden af systemet, blev det, som nævnt i ovenstående, valgt at lave en tænke højt test. Valget faldt på netop denne testform, da vi mener, at den kan give en brugbar tilbagemelding på, hvordan brugervenligheden er for programmet. Det vil sige, hvorvidt brugeren har nemt ved at anvende programmet, og om opbygningen er 14

99 logisk for udførelsen af arbejdsopgaverne. Den skulle fungere som et værktøj til at teste, om de mål, der var opsat for brugergrænsefladen, var opnået og i hvor høj grad. Der blev kategoriseret ting, vi observerede, samt de ting der verbalt blev givet udtryk for, som værende enten kosmetisk, alvorligt eller kritisk. Kosmetisk skal ses som det mindst vigtige, og kritisk skal ses som det mest vigtige. Vigtigt defineres som, det mest væsentlige, der skulle ændres efter brugervenlighedstesten. Opgaverne (Se Appendiks 2: Testopgaver) var forsøgt bygget op sådan, at de i så høj grad, det var muligt, minder om de arbejdsopgaver, et administrativt personale på en campingplads har. Som udgangspunkt var det væsentligt, at den første opgave, de møder, er relativ simpel at udføre, netop for ikke at tage gejsten fra testpersonerne. Dog stræbtes der generelt set efter en ligetil og let opbygget opgavestruktur Formål Formålet med brugervenlighedstesten var at afsløre eventuelle punkter, hvor programmet var problematisk for brugerne at forstå eller anvende, samt hvor det er ueffektivt at anvende, dvs. at det er en for tidskrævende procedure Fremgangsmåde Brugervenlighedstesten blev afholdt i Usability Laboratoriet på AAU, for at opsamle så mange indput som muligt, til brug i den senere analyse. Der blev benyttet tre testdeltagere (Se Appendiks 3: Testdeltagere). En vil være for lidt til at danne sig et billede af nogle tendenser. Derimod måtte det erkendes at der ikke var tidsmæssigt overskud til mere end tre testdeltagere. Dette var til trods for at jo flere brugere der medvirker i en brugervenlighedstest, over flere iterationer, jo flere brugervenligheds problemer, kan der blive belyst. Der skulle for hver del af systemet, som skulle testes, være opgaver, som brugerne skal løse. Det vil sige en arbejdsrelateret opgave, der vil føre dem igennem nogle af de procedurer, systemet understøtter (Se Appendiks 4: Testforløb). Det primære fokus var her check ind/ud og reservation, da disse vil være nogle af de mest benyttede funktioner i systemet. 15

100 8.1.4 Refleksion Tænke højt testen, gav en række brugbare indput til designet af systemet (Se Appendiks 5: Testresultater), som dog var begrænsede. For yderligere at belyse brugervenligheden af systemet kunne der først og fremmest være opstillet flere opgaver samt inddraget flere testpersoner i tænke højt testen. En anden indgangsvinkel til undersøgelse af brugervenlighedsproblemer, kunne være at supplere tænke højt forsøget med andre metoder som eksempelvis heuristisk inspektion og diskussions grupper. Disse metoder blev fravalgt grundet tidsmæssigt pres, samt at det vurderede udbytte af disse metoder ikke overgik tænke højt metoden, så i tilfælde af flere brugervenlighedstests ville den samme metode blive benyttet. Mangel på pilottest gav sig også til udtryk under testen i form af systemnedbrud, hvilket også påvirkede testen, da testlederen i disse situationer greb ind, og forklarede hvad der ville have sket hvis systemet ikke havde fejlet på det punkt. I de tilfælde hvor et resterende område af systemet, som skulle benyttes til at løse den givne opgave ikke fungerede, blev også de belyst i form af spørgsmål fra testlederen om hvad brugeren havde forventet at finde på den pågældende side. Disse resultater er dog ikke helt så pålidelige, som de øvrige udarbejdet under normale forhold, da de disse ikke afspejler den reelle interagering brugeren har med systemet. 16

101 9 Konklusion Analyseforløbet i projektperioden blev tidsmæssigt omfangsrigt, da der blev gennemgået mange iterationer af analysedokumentet. Flere af iterationerne skyldes ændringer i de krav, der blev stillet af campingpladsen. Samtidig blev der fundet mere hensigtsmæssige løsningsmetoder, der også krævede ændringer i analysedokumentet. Flere af ændringerne medførte, at systemet fik mere funktionalitet end først antaget. Dette resulterede i, at vi allerede inden påbegyndelsen af designdokumentet fravalgte at designe og dermed også implementere web-delen. Implementeringen blev prioriteret således, at der blev lagt størst vægt på de mest anvendte funktioner, såsom reservation, check ind, check ud, betaling og tilmelding til aktiviteter. Dele af designdokumentet blev ikke implementeret. De problemer, vi stødte på under anvendelsen af Objektorienteret Analyse og Design, var, hvordan enkelte elementer i metoden kunne tilpasses vores behov. Det viste sig især under udarbejdelsen af klassediagrammerne. Derudover har vi fundet metoden sammenhængende og brugbar i forbindelse med den efterfølgende implementering. Der har ikke været stor programmeringserfaring i gruppen, og det kunne derfor have været givtigt, hvis implementeringen var påbegyndt tidligere i projektforløbet. Da vi startede relativt sent, har dette haft betydning for de mangler, der forekom under brugervenlighedstesten, hvilket kan have været udslagsgivende for testresultaterne eller manglen på samme. 17

102 10 Appendiks 10.1 Appendiks 1: Prototyper Forside: Valg af type: Periode: Personinformation: 18

103 10.2 Appendiks 2: Testopgaver Opgave 1: Information: Telefonen ringer. Det er en kvinde, der gerne vil reservere en plads. Du får følgende informationer fra hende: Hendes navn er Trine Jensen, hun bor på Plantagen 15, 9530 Støvring. Den periode hun gerne vil reservere, er fra den 14/07-03 til den 21/07-03, og det skal være en teltplads. Du skal oprette en reservation til Trine Jensen Opgave 2: Information: Følgende person kommer dagsdato ind i administrationen og ønsker at checke ind på campingpladsen. Han ønsker at bo i et telt. Check ham ind på campingpladsen. Opgave 3: Information: Søren Christensen ønsker efter et 3 dages ophold på campingpladsen at tage videre. Du skal checke Søren Christensen ud fra pladsen. Opgave 4: Information: Christina Svensson, en campingpasindehaver, der forrige dag checkede ind på campingpladsen og betalte for en overnatning, kommer ind i administrationen og ønsker at betale for endnu en overnatning. Sørg for at Christina Svensson betaler for denne dag. 19

104 10.3 Appendiks 3: Testdeltagere Testperson Nr. 1 Alder: 41 Beskæftigelse: Anpartshaver i Action House Relevans: Da han er en af anpartshaverne i Action House Camping og senere skal arbejde med systemet i praksis, blev det fundet relevant, at han deltog i testen. Han var deltager i begge interviews og har indblik i systemets funktioner, og derfor forudses det, at hans mening om systemet er relevant. Testperson Nr. 2 Alder: 21 Beskæftigelse: På lønningslisten ved Action House Relevans: Han er en af de fremtidige brugere af systemet. Testperson Nr.3 Alder: 26 Beskæftigelse: Økonomielev Relevans: Testperson nr. 3 deltager i testen som en del af målgruppen for systemets brugere. 20

105 10.4 Appendiks 4: Testforløb Testperson nr. 1 Testpersonen har tidligere arbejdet med et campingadministrationssystem, og har derfor en forudindtaget indstilling til systemets funktioner. Opgave 1: Han forstod den stillede opgave og fandt med det samme reservations knappen. Han havde lidt problemer med menuen vedrørende, at vælge pladstype og antal og blev hjulpet til gennemførelse. Ingen problemer med indtastningen af personoplysninger. Der var lidt tvivl om hvordan reservationsperioden indstilles, men han fandt hurtigt ud af hvordan kalenderen fungerede. Tid: 4 min 17 sek. Opgave 2: Han forstod den stillede opgave og åbnede hurtigt check ind via knapperne på grænsefladen. Ved indlæsning af personoplysninger via magnetkort var der et problem, med at markøren skulle placeres i navnefeltet før kortet blev kørt igennem magnetkortlæseren. Denne gang var der ingen problemer med at vælge periode. Tid: 2 min 9 sek. Opgave 3: Han forstod opgaven og åbnede hurtigt check ud via knapperne på grænsefladen. Fandt hurtigt ud af at der skulle søges på personen med de givne data, og checkede ham ud. Han havde forventet en bekræftelse på at person var checket ud fra pladsen. Tid: 56 sek. Opgave 4: Han forstod opgaven. Han forestillede sig en knap Betaling, under denne skulle der være mulighed for at betale for en eller flere dage. Overordnede kommentarer: Testpersonens generelle mening om systemet var, at det levede op til hans forventninger. Det der skulle ændres var, at markøren skulle placere sig i fornavn med det samme, når vinduet med personoplysninger åbnede. 21

106 Testperson nr. 2 Testpersonen har ikke tidligere arbejdet med et campingadministrationssystem, men han har været med til det andet interview og har derfor et indblik i hvad systemet kan. Hans umiddelbare forventninger til systemet var at det skulle være hurtigt og nemt. Opgave 1: Han forstod opgaven. Åbnede reservations vinduet hurtigt via knapperne på grænsefladen. Der var ingen problemer med at vælge pladstype. Ingen problemer med indtastningen af personoplysninger. Testpersonen havde svært ved at benytte kalenderen til at vælge periode. Han havde specielt svært ved at vælge måned. Efter nogle klik på knapperne i kalender lykkes det testpersonen, at få valgt den rette periode for reservationen. Tid: 4 min 16 sek. Opgave 2: Han forstod opgaven. Åbnede check ind vinduet via knapperne på grænsefladen. Der var ingen problemer med at vælge pladstype og antal. Testpersonen var først begyndt manuelt at indtaste personoplysninger, men blev korrigeret af testlederen til at bruge magnetkortlæseren. Markøren var placeret i fornavnfeltet. Der var denne gang ingen problemer med at vælge periode. Tid: 1 min 23 sek. Opgave 3: Han forstod opgaven. Åbnede check ud vinduet via knapperne på grænsefladen. Han fandt hurtigt ud af at indtaste data i navnesøgefeltet. Der var ingen problemer. Tid: 26 sek. Opgave 4: Testpersonen havde forstillet sig en betalingsknap på grænsefladen. Overordnede kommentarer: Umiddelbart kunne testpersonen godt forestille sig at programmet kunne bruges til formålet. Programmet var nemt at overskue og rimelig hurtigt at bruge. Havde en forestilling om at hvis man lukkede vinduerne med krydset i højre hjørne, at så ville den udførte handling blive slettet. Der mangler en bekræftelse hver gang en handling er udført, og ved tryk på en ok knap på bekræftelsen skulle vinduet lukke ned. 22

107 Testperson nr. 3 Testpersonen har ikke tidligere arbejdet med et Campingreservationssystem, og havde ikke nogen indblik i systemet på forhånd. Hun forestillede sig at det var et system, hvor man kunne reservere en plads via Internettet. Han fik en mere grundig forklaring om, at systemet var til brug i administrationen på selve campingpladsen, og at det ikke var et system, at campingpladsens kunder skulle bruge. Opgave 1: Han forstod opgaven. Umiddelbart ville han gå ind under kundekartotek og oprette kunden først. Han blev hjulpet til at bruge reservationsknappen. Der var ingen problemer med at vælge pladstype og antal. Der var ingen problemer med at indtastning personoplysninger. Han fandt hurtigt ud af at bruge kalenderen, og fik også tildelt en plads til kunden. Tid: 5 min 19 sek. Opgave 2: Han forstod opgaven. Vinduet fra forrige opgave var åben ved opgavens start, han havde lidt problemer med at lukke det, men han fik hjælp til at lukke det. Indlæsning af personoplysninger gik nemt. Valg af periode i kalenderen gik uden problemer. Tid: 2 min 15 sek. Opgave 3: Han forstod opgaven. Han havde ingen problemer med at checke personen ud. Han skrev ikke de opgivne data ind, men trykkede straks på Find person og fik ham checket ud på den måde. Tid: 32 sek. Opgave 4: Umiddelbart ville han bruge Dagens betalere til at udføre en betaling. Han havde en forestilling om, at der kom et vindue, hvor der var mulighed for at søge efter en person på campingpladsen, da personen stadig er checket ind på campingpladsen og på den måde gennemføre en betaling. Overordnede kommentarer: Systemet levede op til testpersonens forventninger, og det var nemt at overskue. 23

108 10.5 Appendiks 5: Testresultater Problemer De tre testdeltagere stødte på følgende problemer, problemerne er kategoriseret efter Rolf Molichs tre kategorier 2. Kosmetisk problem. Testdeltagerne gik i stå et kort øjeblik. Alvorligt problem. Problemet forsinkede testdeltagerne i 1-5 minutter, men testdeltagerne kom videre af sig selv. Gav lejlighedsvis anledning til katastrofer. Kritisk problem. Gav anledning til hyppige katastrofer. En katastrofe er en situation, hvor systemet forhindrede testdeltagerne i at løse en rimelig arbejdsopgave i systemet, eller som irriterede testdeltagerne voldsomt. Testlederen har, hvor det er fundet påkrævet, knyttet en yderligere kommentar til et problem. Problem 1. Manglende bekræftelse af udførte handlinger. Dette problem kategoriseres som værende alvorligt, da to testpersoner oplevede det. Testperson nr. 1 var i tvivl om den udførte handling var blevet gemt i systemet. Problem 2. At markøren ikke automatisk placeres i fornavnfeltet ved indlæsning af persondata via magnetkortlæser. Det problem kategoriseres som værende alvorligt, da testperson nr. 1 ikke kunne gennemføre opgaven uden hjælp. 2 Brugervenligt Webdesign, Rolf Molich, Ingeniøren Bøger, 2000, 1. udgave. 24

109 Problem 3. Lukning af vinduer efter udført handling. Det problem kategoriseres som værende kosmetisk. Problemet skyldes en programfejl som gjorde at vinduet ikke blev lukket automatisk. Problem 4. Manglende betalings knap. Kategoriseres som værende kosmetisk. Formålet med opgaven var at teste hvordan testpersonerne forstod grænsefladen. Problem 5 Kunne ikke finde reservationsknappen i grænsefladen, men ville oprette kunden under kundekartotek. Dette problem kategoriseres som værende kosmetisk, da det kun var en testperson, der havde dette problem. Testperson 1 & 2 havde overhovedhovedet ingen problemer med at bruge reservation. Testperson 3. overså ganske enkelt knappen, det var den første opgave i testen, så testpersonen havde sandsynligtvist været lidt nervøs. Problem 6 Kunne ikke forstå notationen ved de toggleknapper, der er under reservation pladstype. Dette problem betegnes som kosmetisk, da testpersonen med sparsom vejledning forstod notationen. 25

110 Positive ting ved systemet Efter at alle opgaverne var gennemført, blev testdeltagerne spurgt til deres oplevelse af programmet samt, om det levede op til deres forventninger. Generelt gav alle testdeltagerne udtryk for at systemet var nemt at overskue. Generelt var testpersonerne tilfredse med systemet. Specielt var det nemt at foretage et check ud ind. Det er erfaret under testen at systemet har en kort læringskurve, alle testpersonerne kunne fx benytte kalenderen til at vælge periode efter opgave 1. 26