Administration af computerparty & turneringsplanlægning

Transkript

1 Administration af computerparty & turneringsplanlægning Turnering System til brugeradministration og turneringsplanlægning af et computerparty Dat1-projekt af - Gruppe d105a - Aalborg Universitet, d. 21. Dec, 2006

2

3 En Teknisk-Naturvidenskabelig rapport Aalborg University, Computer Science Fredrik Bajers vej 7, bygning E Telefon , Fax Titel: Administration af computerparty & turneringsplanlægning - System til brugeradministration og turneringsplanlægning af et computerparty Tema: Udvikling af programmel Projektperiode: DAT1, efterårssemesteret 2006 Projektgruppe: d105a Deltagere: Markus Krogh Thomas Justesen Jais B. Heslegrave Daniel Korsgård Morten Bøgh Michael S. Knudsen Anders Ejlersen Vejleder: Kim Christensen Oplagstal: 9 Sidetal: 95 Bilagsantal og art: Et kapitel samt en cd med kode og program Afsluttet & underskrevet den d , Aalborg universitet Synopsis: Bag et computerparty ligger der meget administrationsarbejde, og da dette er et førstegangsprojekt fra arrangørernes side, kan dette gå hen og blive en kompliceret og tidskrævende opgave. Til et computerparty er der opgaver som administration af deltagere, hvilket ofte også indebærer pladsreservation. Foruden deltagere kan der være turneringer i diverse spil, som arrangørerne står for at afholde. Dette medfører også en del administrationsarbejde, idet der skal lægges turneringsplaner, som løbende skal opdateres med kampresultater. Disse er blot enkelte administrationsopgaver der ligger bag et computerparty, men opgaver er meget tidskrævende for arrangørerne. Denne rapport behandler ønsket om at nedbringe administrationsarbejdet ved at udvikle et administrationsværktøj, der er i stand til at hjælpe arrangørerne med administrationsprocesserne til et computerparty. Administrationsværktøjet er et system, der er i stand til at administrere deltagere, planlægge turneringer og bringe informationer til deltagere og crew, ved hjælp af en form for fremviser eller storskærm. Da systemet er et administrationsværktøj, er det præsenteret med en brugervenlig og intuitiv grafisk brugergrænseflade. Derudover kan deltagerne anvende administrationsværktøjet til at tilmelde sig computerpartyet, reservere en plads og kreere et hold til en turnering sammen med sine venner. Rapportens indhold er frit tilgængeligt, men offentliggørelse (med kildeangivelse) må kun ske efter aftale med forfatterne.

4

5 Indhold Forord Indledning v vii 1 Analyse dokumentation Situationen & opgaven Formål med systemet Systemdefinition Systemomgivelser Problemområdet Klynger Struktur Klasser Hændelsestabel Anvendelsesområdet Brug Funktioner Brugergrænseflade Anbefalinger IT-systemets nytte og realiserbarhed Strategi Udviklingsøkonomi og tidsplan Opsamling Design dokumentation Opgaven Formål Rettelser til analysen Kvalitetsmål Teknisk platform Udstyr Basisprogrammel Designsprog Arkitektur Faktorer i sammenhæng med designkriterier Generiske design beslutninger Komponentarkitektur Eksemplariske design i

6 ii Indhold 2.4 Komponenter Brugergrænsefladekomponenten Funktionskomponent Modelkomponenten Persistenskomponent Anbefalinger Systemets nytte Plan for ibrugtagning Implementeringsplan Programmering Implementerbarhed Kodeeksempler Opsamling Implementering Fra Design til Implementering Rettelser fra Designdokumentet Værktøj Microsoft Visual Studio &.NET Alternativer Kodeeksempler fra komponentlagene Brugergrænsefladelaget Funktionslaget Modellaget Persistenslaget Sammenhæng mellem komponentlagene Evaluering af implementationen Multiple instanser af programmet Opsamling Test & evaluering Testtyper Blackbox og whitebox test Unit-test Integrationstest Tænk-højt-test Præ-Accepttest Testudførelse på systemet Udførelse af unit-test Udførelse af integrationstest Udførelse af tidlig tænk-højt-test Udførelse af præ-accepttest Evaluering Systemopdatering som følge af tænk-højt-testen Opsamling Konklusion 89 Litteratur 91

7 iii 5.1 Kildekritik Kriterier for den kvalitative kilde Den enkelte kildes kvalitet A Bilag 95 A.1 Generel interaktionsrum

8

9 Forord Denne rapport er udarbejdet gennem Dat1 projektforløbet af datalogigruppen d105a ved Aalborg Universitet. Semestrets tema er Udvikling af programmel, og som baggrund for dette projekt er der inddraget viden fra undervisning i kurserne Algoritmik og Datastrukturer, Objekt-Orienteret Programmering, Design, Implementering og Evaluering af Brugergrænseflader og Systemanalyse og Design. Rapporten henvender sig til medstuderende, vejledere og andre der måtte være interesserede i emnet. Den er skrevet med henblik på, at læseren har kendskab til basale computertekniske begreber, og derfor kan disse forekomme uden nærmere forklaring. Hele rapporten er skrevet på dansk, men der kan forekomme engelske ord, hvor det anses nødvendigt. Forkortelser og akronymer vil ved første optræden være skrevet ud i en efterfølgende parentes, for at undgå ophold i læsningen. Idet der er specificeret hankøn i rapporten, er det ikke et udtryk for undertrykkelse eller anden form for politisk/religiøs indstilling. Det aktuelle valg er taget for at forsimple skriveprocessen for forfatterne. Referencer til kilder markeres med [#], hvor # refererer til den tilhørende litteratur fra litteraturlisten. Bilagene hørende til denne rapport findes i sidste kapitel i rapporten og på en cd, som er påsat sidste side i rapporten. Kildekoden til applikationerne er også at finde på cd en; ligeledes en køreklar udgave af applikationerne. Rapporten er typesat i L A TEX. Den vil være disponibel i PDF-format, som kan læses med Adobe Acrobat Reader. Underskrifter: v

10

11 Indledning I forbindelse med sociale og sportslige aktiviteter opstår der ofte en større mængde administrativt og planlægningsmæssigt arbejde. I de fleste tilfælde består dette arbejde af en langsommelig og besværlig proces, med en større mængde papirarbejde. Blandt andet skal der både administreres medlemmer, turneringer, kampe og formidling af information. De fleste klubber, foreninger og organisationer, der består af faste medlemmer, kender til situationen. En uafhængig initiativtager, som ønsker at samle en mængde af mere eller mindre uafhængige personer til et enkeltstående arrangement, kan også støde på mange af de samme problemer. I et sådant tilfælde kan det være besværligt at holde styr på, hvem der er tilmeldt, og om personen har betalt osv. Ud fra disse problemstillinger opstår motivationen for at udvikle et system, som er i stand til at lette den administrative proces for arrangørerne, og samtidigt forsimple informationsformidlingen til deltagerne. Et konkret arrangement der har en del af disse problemstillinger, er et såkaldt computerparty. Et computerparty er et midlertidigt, og nogle gange spontant arrangement, hvor computerinteresserede mødes med ligesindede, hovedsageligt med det formål at spille computerspil mod hinanden. Til et sådant arrangement er der rigeligt med administrative problemstillinger, der skal løses, derfor tager dette projekt udgangspunkt i netop computerparties. Arrangørerne af et computerparty er ofte enten en ungdomsklub eller en selvstændig organisation/forening. Antallet af deltagere kan variere fra ganske få til flere tusinde, f.eks. holdte Dreamhack [1] et arrangement med 7752 betalende deltagere i vinteren Deltagernes alder varierer alt efter hvem der arrangerer computerpartyet. Hvis det er en ungdomsklub, der står for computerpartyet, så vil deltagerne primært komme fra 7. til 10. klasse, mens der til andre arrangementer typisk vil være personer i alderen fra 14 år til 30 år. Det er bl.a. derfor relevant med en overskuelig brugerhåndtering til at administrere de mange personer. Til computerparties er der ofte en række forskellige turneringer i forskellige spil. Det er derfor også oplagt at give mulighed for at administrere disse turneringer og turneringernes kampe. Det vil samtidig mindske det administrative arbejde, hvis arrangørerne ikke skal indblandes i tilmeldingen af deltagerne, som det er tilfældet ved tilmelding pr. eller telefon, hvor arrangørerne er nødt til at bruge tid på deltagernes ønsker om pladser. vii

12

13 Kapitel 1 Analyse dokumentation Der er forholdsvis mange forskellige muligheder til udvikling af et administrationsværktøj, derfor er det nødvendigt at få specificeret nogle retningslinier for udviklingen og design af systemet. For at sikre udviklingsprocessen ikke løber af sporet, er det nødvendigt at opbygge en forståelse af de forskellige problemstillinger og opgaver, som systemet skal håndtere. Til det formål anvendes denne analyse. Dokumentet indeholder mange forskellige dele, som alle kendetegner en analyseproces. Den skal hjælpe med til, at specificere hvilke krav, der er stillet til udviklingen af systemet, samt systemets funktioner. Det er vigtigt at formulere en systemdefinition i starten af analysedokumentet, da denne danner grundlaget for det videre analyse- og designarbejde. Systemdefinitionen beskriver i korte og præcise træk systemets fundamentale egenskaber i et naturligt sprog. Ud fra systemdefinitionen er det muligt, at opstille en række BATOFF-kriterier, hvor BATOFF står for Betingelserne for systemets udvikling og brug, systemets Anvendelsesområde, Teknologi, Objekter i problemområdet og systemets Funktioner samt den grundlæggende Filosofi for samspillet mellem systemet og brugerorganisationen [2]. Det videre arbejde indebærer en undersøgelse af det aktuelle problemområde, som systemet skal behandle. Problemområdet skal beskrive den virkelighed, de kommende brugere kommer til at se. Når problemområdet er defineret, giver det mening at undersøge anvendelsesområdet, som består af de organisationer og systemer, der skal anvende systemet. Analysedokumentet afsluttes med en række anbefalinger til den videre udvikling af systemet, det er også her det vurderes, hvorvidt det er muligt, at realisere systemet. Afsnittet er formuleret med støtte fra sideløbende forelæsninger i Systemanalyse og Design (SAD) og Design, Implementering & Evaluering af Brugergrænseflader (DIEB), samt bøgerne fra de to kurser hhv. bogen fra SAD Objektorienteret analyse & design [2] og bogen fra DIEB Interaction design, Beyond human-computer interaction [3]. 1.1 Situationen & opgaven Denne rapport omhandler situationen, hvor en initiativtager eller forening, skal afholde et computerparty. Til dette computerparty kan der komme et varierende antal deltagere, der alle betaler et tilmeldingsgebyr til at dække omkostningerne for computerpartyet. Derfor skal de tilmeldte deltagere registreres med henblik på, hvem der har betalt og hvem der er tilmeldt. 1

14 2 Kapitel 1. Analyse dokumentation Til computerpartyet vil der være en række turneringer i diverse computerspil. Til turneringerne findes der forskellige typer af turneringsformer, hvor der her i rapporten fokuseres på single-elimination, double-elimination og puljekampe. Fælles for alle turneringstyperne er, at de består af en række kampe, der hver udkæmpes af to eller flere hold. Disse hold er en samling af deltagere, som ønsker at deltage i en turnering sammen. Vinderen af turneringen får eventuelt tildelt en præmie. Der skal derfor administreres og planlægges turneringer i et eller flere computerspil. Udviklingsopgaven Målet med denne analyse er, at få en klarere forståelse af hvad der skal til, i et IT-system, for at dække de administrative og planlægningsmæssige behov i sammenhæng med et computerparty. Administrationsarbejdet udføres ofte manuelt af crew med papir og blyant -metoden, hvilket bevirker, at crew skal bruge meget tid på blandt andet planlægning, administration og styring af turneringerne mellem kampene, hvilket i visse tilfælde har de konsekvenser, at crew ikke selv har tid til at deltage i turneringerne. Derfor vil det være interessant at kunne nedbringe tidsforbruget for denne proces. Arbejdet op til computerpartyet kan også være en besværlig proces, både med registrering af tilmeldingerne og med at finde ud af hvor deltagerne skal sidde, især når der i nogle tilfælde skal tages højde for deltagere, der vil sidde sammen. Dette arbejde kan have konsekvenser for både crews tid, men også for selve deltagerne, da de skal kontakte crew og finde en løsning på plads-situationen. Derfor er det også ønskværdigt at undersøge, hvilke muligheder der kræves, for at kunne registrere tilmeldinger, pladsreservationer samt hvilke deltagere der har betalt Formål med systemet I dette projekt er formålet at udvikle et IT-system til brug ved computerparties. Formålet med systemet er, at skulle hjælpe crew til at holde styr på de vigtigste administrative aspekter af arrangementet. Overordnet har systemet to funktionsområder, der her vil blive beskrevet nærmere, mens hele analysedokumentet vil konkretisere og udpensle disse områder yderligere. Turneringsplanlægning er systemets primære funktion. Det skal være muligt for crew at oprette forskellige typer af turneringer med forskellige egenskaber. Endvidere skal deltagerne kunne tilmelde hold til de oprettede turneringer. Når deltagerne har tilmeldt sig, skal det være muligt for crew at aktivere en funktion i programmet, der automatisk genererer en turneringsplan, over hvilke hold der skal dyste imod hinanden. Turneringsplanen skal være mulig at vise på en storskærmsprojektor (eller lignende) i lokalet, hvor computerpartyet finder sted. Ud fra turneringsplanen skal holdene kunne se, hvem de skal spille imod. Når kampe er spillet, skal holdene kunne indmelde deres resultater i systemet, hvorefter turneringsplanen automatisk bliver opdateret. Når en finale er spillet og turneringen derved er slut, skal vinderen automatisk annonceres på storskærmsprojektoren. Administration af deltagere er systemets sekundære funktion. Ved hjælp af et webinterface skal det være muligt for interesserede at tilmelde sig computerpartyet, samt at reservere en plads til arrangementet. Hvis en tilmeldt person ønsker at framelde sig computerpartyet, skal dette også være muligt via web-interfacet. Når de tilmeldte ankommer til arrangementet, skal det være muligt for crew at kunne registrere, at den enkelte deltager er ankommet, ved at deltageren fortæller systemet at vedkommende er ankommet.

15 Systemdefinition Systemdefinition Systemdefinitionen anvendes til at beskrive systemet, og hjælper derfor til at give overblik over systemet. Til at beskrive systemdefinitionen er BATOFF blevet anvendt til at fremhæve og forklare de kriterier, der stilles til IT-løsningen. Betingelser: Frivilligt personel (også kaldet crew) med stor entusiasme og med middel til høje computerkundskaber. Anvendelsesområde: Hjælpe crew med administration af et computerparty, planlægning af turneringer, styring af deltagere og visning af information til deltagerne via en fremviser. Teknologi: En standard pc med.net framework 2.0 og en form for fremviser (eksempelvis projektor). Objekter: Deltagere, crew, turneringer, hold, pladser, runder og kampe. Funktioner: Administration af deltagernes tilmeldinger til computerpartyet og turneringer, samt planlægning af diverse turneringer igennem en klient. Desuden formidling af information til deltagerne omkring turneringer og kampe, ved hjælp af en fremviser. Formidling af information til crew om deltagerne og status omkring computerpartyet, turneringer og deltagernes kampe igennem en klient. Deltagerne skal kunne tilmelde sig computerpartyet gennem en hjemmeside. Filosofi: Hjælpe crew med at planlægge turneringer og holde styr på deltagerne og om de har betalt. Derudover skal det være muligt for deltagerne at tilmelde sig til computerpartyet via en hjemmeside. Ud fra BATOFF-kriterierne kan systemdefinitionen til IT-løsningen opskrives som følgende: Et IT-system der bliver benyttet af frivilligt crew med stor entusiasme, som har middel til høje computerkundskaber. Entusiasmen afspejles i, at crew bruger ekstra tid og kræfter på at gøre computerpartyet bedre. IT-systemet bruges til at administrere et computerparty med turneringer i diverse spil. Endvidere skal IT-systemet kunne hjælpe deltagerne med at tilmelde sig selve computerpartyet og turneringer. IT-systemet skal kunne formidle information om diverse tilmeldinger, pladsreservationer, kampresultater og turneringer ved hjælp af en fremviser. IT-systemet skal have en brugergrænseflade, der kan køre på en standard pc og være programmeret til.net framework 2.0. Endvidere skal IT-systemet kunne arbejde sammen med en fremviser, til at formidle informationer i et lokale med et stort antal deltagere Systemomgivelser De omgivelser, systemet er en del af, kan opdeles i to områder: Problemområdet og anvendelsesområdet. Problemområdet beskriver den del af problemet, der skal styres, administreres og overvåges af et system. Anvendelsesområdet er brugerorganisationer som administrerer, overvåger eller styrer en del af problemområdet. En måde hvorpå opfattelsen af et system og dets omgivelser kan beskrives, er ved hjælp af rige billeder.

16 4 Kapitel 1. Analyse dokumentation Rige Billeder For at beskrive problemområdet ud fra forfatternes synspunkt, er der blevet udarbejdet et fælles rigt billede. Billedet kan ses på figur 1.1. Det har til formål at danne en fælles forståelse af, hvad et computerparty er, for at støtte det videre arbejde med projektet og analysen. Det rige billede er med i rapporten for at give et eksplicit billede af, hvilken opfattelse der er af et computerparty. I det rige billede eksistere der mange forskellige elementer, der kan associeres til et computerparty. Alle disse elementer har mere eller mindre relevans for projektet, men alligevel er de inkluderet for at give et fyldestgørende billede. De overflødige bestanddele bliver sorteret fra i problemområdet. På det rige billede findes bygningen som computerpartyet finder sted i. Der kan være stor forskel på omgivelserne til et computerparty. Der afholdes private computerparties i private hjem, hvor det mest går ud på, at have det sjovt med nogle kammerater. Så er der meget store arrangementer, med tusinde deltagere, hvor der afholdes prestigefyldte turneringer med mange og store præmier. Til et computerparty kan der afholdes små events/turneringer i forskellige ting, der ikke har noget med computere at gøre. Dette er symboliseret i det rige billede, hvor der udenfor bygningen findes fysiske aktiviteter, for at holde deltagerne i gang på anderledes måder end der normalt er ved computerparties. Inde i bygningen findes deltagerne med deres computere ved deres pladser. Til computerparties medbringer deltagerne ofte diverse gadgets (gadgets er genstande der indeholder en egenskab omhyldet af et mere usædvanligt og gennemtænkt design), og andre underlige genstande, som de kan bruge til at underholde hinanden med. Deltagerne medbringer også mad og drikkelse til computerpartyet, ofte i form af fastfood, slik, pizza og sodavand. Længden af et computerparty varierer fra arrangement til arrangement. Ofte vil deltagerne prøve at holde sig vågne igennem hele arrangementet, men vil så til sidst falde i søvn ved deres pladser eller de dertil-indrettede sovepladser. Dette medfører, at deltagerne nogle gange sover, når de skal deltage i turneringer eller andre events. Endnu en bestanddel af et computerparty er servere, netværk, switches, internetadgang og strøm. Det er meget vigtigt at disse ting fungerer, da det ellers kan være til irritation for deltagerne. Hvis en turnering eksempelvis er i gang, og spillet pludselig stopper, kan det skabe store konflikter imellem deltagerne, da kampen skal starte forfra, selvom en deltager måske var ved at vinde. Storskærme (projektorer) er ofte en del af større computerparties. Disse bruges til informationsformidling til deltagerne om eksempelvis tids- og turneringsplaner. Udover at deltagerne spiller mod hinanden for sjovs skyld, er der også turneringer i diverse spil, hvor der ofte er præmier til vinderne af turneringerne. Dette rige billede og tilhørende beskrivelse er på ingen måde en komplet liste, over alt hvad der kan forekomme af aktiviteter og elementer til et computerparty. Det er forfatternes synspunkter over de mest generelle egenskaber ved et computerparty. Billedet er derfor fuldstændig nok, til at danne grundlag for en videre analyse af problemområdet. Problemområdet Ved ankomst til et computerparty, skal deltageren finde en plads, hvor han vil sidde. Pladserne bliver fordelt efter først til mølle -princippet. Denne fremgangsmåde kan resultere i kaos, da forskellige pladser bliver betragtet bedre end andre, og da en gruppe af deltagere måske gerne vil sidde sammen. Ved et computerparty bliver der holdt turneringer i forskellige typer af spil, og der uddeles præmier til den/de som har klaret sig bedst ved turneringerne. En

17 Switch Backbone Systemomgivelser 5 Computerparty Server Counter-strike Turnering Power Internet Figur 1.1: Rigt billede over problemområdet turnering består af et antal deltagere, som enten deltager i hold eller hver for sig, afhængigt af hvilket spil der konkurreres i. Turneringernes forløb er også afhængig af, hvilket spil der skal spilles, da der findes forskellige typer af turneringer. Turneringstyperne til et computerparty er blandt andet single-elimination (også kendt som knockout), double-elimination og puljespil. Single-elimination: I denne turneringstype opstilles en række af hold med det formål, at hvert par af to hold udkæmper en kamp imod hinanden. Vinderen af kampen fortsætter til næste runde, mens taberen bliver elimineret. De resterende hold opstilles igen i par af to hold, og udkæmper endnu en kamp imod hinanden. Dette fortsættes indtil runden, hvor der kun er ét par af to hold tilbage. Den kamp med de to resterende hold kaldes også for finalen. Vinderen af denne kamp har vundet hele turneringen. Double-elimination: Double hentyder til at hvert hold får minimum to kampe. Turneringstypen opstilles på samme måde som to single-elimination turneringer, der bliver kaldt for Upper og Lower (også kendt som Winners og Losers ). Alle hold starter i Upper, og den udkæmpes på samme måde som single-elimination af et par af to hold i hver kamp. I stedet for at taberne af kampene bliver elimineret, ryger de ned i Lower. I Lower kommer alle tabere fra Upper ned, hvor holdene får deres anden chance. Hvis et hold taber i Lower bliver de elimineret fra turneringen, og kan ikke længere deltage. Finalen fra single-elimination er nu kun semi-finalen, da finalen

18 6 Kapitel 1. Analyse dokumentation består af vinderen af Upper og vinderen af Lower, dermed kan et hold, som har tabt i Upper vinde hele turneringen pga. Lower. Puljespil: Ordet pulje bruges til denne turneringstype, da alle hold placeres i én eller flere puljer, hvor holdene mødes i kampe. I puljen mødes alle hold minimum én gang. Vinderen af én kamp får point og taberen får ingen point, uafgjort kan blive belønnet med et antal point mindre end pointtallet for en vundet kamp. Det hold, der har fået flest point, vinder turneringen. Sammensætninger: I visse tilfælde sættes flere turneringstyper sammen til at udgøre én samlet turnering. Eksempelvis kan turneringstyperne single-elimination (eller doubleelimination) sættes sammen med puljespil, hvor alle hold opdeles i et antal puljer, hvor første og anden pladsen går videre til elimination. Dette kunne eksempelvis være tilfældet, hvis et stort antal hold har tilmeldt sig en turnering, men hvor overskueligheden ville være gået tabt, hvis alle hold startede med single- eller double-elimination. Desuden ville puljespil og elimination give mulighed for et større antal kampe for hvert hold, i stedet for at hold i single-elimination kun ville få én kamp. Eksempel: For at give et konkret eksempel tages der udgangspunkt i double-elimination, puljespil og 16 hold, hvor der gives en gennemgående beskrivelse af, hvordan disse to turneringstyper kunne fungere sammen i praksis. I starten af turneringen deles holdene op i fire puljer á fire hold, hvor kun otte hold går videre til double-elimination. I puljespillet får hvert hold tildelt 3 point for en vundet kamp, 1 point for uafgjort og 0 point for en tabt kamp. Her tages der udgangspunkt i pulje 1, se figur 1.2. Navn Pulje 1 Point Hold 1 0 Hold 2 0 Hold 3 0 Hold 4 0 = Navn Pulje 1 Point Hold 1 3 Hold 2 1 Hold 3 1 Hold 4 0 = Navn Pulje 1 Point Hold 1 6 Hold 4 6 Hold 2 4 Hold 3 1 (a) (b) (c) Figur 1.2: Gennemgang af pulje 1. Når puljen startes (a), så har ingen af holdene point, men i (b), hvor hvert hold har spillet én kamp hver, ses det, at holdene har fået tildelt point. Hold 1 vandt over hold 4 og fik 3 point, mens hold 2 og hold 3 hver fik 1 point for uafgjort. I (c) har alle hold spillet hver tre kampe. Her går hold 1 og hold 4 videre med to vundne kampe, mens hold 2 og hold 3 ikke går videre, da de begge har færre point. Fra hver af de fire puljer går to hold videre til double-elimination, hvor de alle starter i upper i en tilfældig rækkefølge, som kan ses nedenfor i figur 1.3. I (a) har alle hold spillet deres første kampe i upper. Her ses det, at de hold som tabte i upper er blevet flyttet ned i lower (hold med stiplet linje omkring, er hold som har tabt kampen), hvor de skal spille imod hinanden. I (b) har holdene i upper spillet deres kvartfinale, hvor taberne ryger ned i lower. I lower har holdene spillet deres første runde, men her elimineres taberen fra turneringen, og kan ikke længere deltage. I

19 Systemomgivelser 7 HOLD 1 HOLD 5 HOLD 6 HOLD 9 HOLD 10 HOLD 13 HOLD 4 HOLD 14 (a) U P P E R (b) HOLD 1 HOLD 9 HOLD 9 HOLD 10 HOLD 10 (c) HOLD 4 Finale (d) HOLD 9 vs HOLD 5 HOLD 5 HOLD 13 L O W E R HOLD 5 HOLD 10 HOLD 13 HOLD 1 HOLD 5 HOLD 13 HOLD 4 HOLD 5 HOLD 6 HOLD 13 HOLD 14 Figur 1.3: Double-elimination, hvor otte hold fra puljerne er gået videre. (c) har upper spillet deres semifinale, her ryger holdet, som tabte, ned i lower, men i lower er der nu tre hold. I dette eksempel spiller det hold, som tabte i semifinalen, i upper en ekstra kamp i lower, mens det tredje hold i lower slipper for en ekstra kamp. I (d) mødes vinderen fra upper og lower i én kamp. hvis vinderen fra upper taber kampen, så spilles en kamp mere, da vinderen fra lower skal vinde to kampe, mens vinderen fra upper kun skal vinde én kamp. Dette gøres da holdet i upper ikke har været nede i lower, dermed har dette hold stadig en ekstra chance. Arrangørerne skal opstille en turneringsplan for det aktuelle spil, og skal sørge for, at det hele går op i en højere enhed, så alle deltagere, der vil deltage i turneringen, kan være med. Deltagerne skal tilmelde sig til turneringer hos arrangørerne, som også bogfører/registrerer resultatet af alle kampene. Anvendelsesområdet Anvendelsesområdet for IT-systemet består af primære stakeholders 1 som crew (systemets administratorer) og deltagere (potentielle tilmeldte). Crew er primære stakeholders, da de anvender systemet til styring af turneringer og pladser, mens Deltager er primær stakeholder, da deltagere har adgang til en hjemmeside, hvor de kan tilmelde sig computerpartyet og reservere en plads. Derudover er en form for fremviser en del af anvendelsesområdet, da fremviseren skal sørge for, at brugerne har mulighed for at se de informationer som ITsystemet genererer. IT-systemets opgave er overordnet at administrere et computerparty. Herunder indgår: Registrere brugernes tilmeldinger/afmeldinger, samt fremmødte personer. Således at det er nemt at skabe et overblik over, hvem der er kommet, og hvem der burde komme. Administrere brugernes pladser. Dette gøres for at holde styr på, hvem der sidder hvor, for både at kunne finde en given person, men også for at brugerne kan se, hvilke pladser der allerede er optaget. Administration af pladser hjælper til, at grupper af personer kan finde pladser, der grænser op mod hinanden, hvis de gerne vil sidde samlet. 1 En primær stakeholder er en som primært skal benytte sig af systemet.

20 8 Kapitel 1. Analyse dokumentation Tilmelding til turnering, afmelding og visning af turneringer, kampstart, samt præmier til turneringer. Dermed kan brugerne gå ind i systemet, og tilmelde sig diverse turneringer, samt se hvornår hvilke personer skal spille, og mod hvem. 1.2 Problemområdet Problemområdet er Den del af omgivelserne, der administreres, overvåges eller styres ved hjælp af et system, ifølge forfatterne til bogen Objekt Orienteret Analyse & Design [2]. Formålet med at undersøge problemområdet er at finde ud af, hvilke informationer systemet skal behandle. Ved at undersøge problemområdet udvikles en begrebsverden, som gør det muligt at opstille en række relevante krav til systemet. Til undersøgelsen af problemområdet er det nødvendigt, at undersøge hvilke klasser, der skal bruges til at beskrive de objekter, samt deres adfærd og hændelser, som eksisterer i problemområdet. For at sikre et overblik vil klasserne blive placeret i klynger. Når klasserne er defineret, er det nødvendigt at undersøge hvordan de forskellige klasser er relateret til hinanden Klynger Klynger bliver brugt til at strukturere og give overblik over problemområdet. Dette system vil bestå af to klynger: Person og Turnering. Klyngerne vil få følgende opbygning: Person: Klyngen vil bestå af den generelle klasse Person, som har to specialiseringer: Crew og Deltager. Turnering: Klyngen vil omfatte klasserne: Turnering, Kamp, Runde og Hold. Derudover eksisterer der to klasser udenfor klyngerne, disse klasser er: Computerparty og Plads. Disse klynger og to klasser illustreres i figur 1.4, og kan ses med klasser i figur 1.5. Klasserne er tegnet i en sky, som skal indikere, at det er klasser der ikke er i klynger, men frie enkeltstående klasser. Person Turnering Plads Computerparty Figur 1.4: Model af klyngerne i systemet Struktur For at danne overblik over strukturen af klasserne, som er fundet ud fra problemområdet, er alle klasserne indsat i et klassediagram på figur 1.5. Sammenhængen mellem klasserne bliver beskrevet ved hjælp af strukturer, der passer ind i den givne situation. Klasserne, der anvendes, er: Computerparty, Turnering, Runde, Kamp, Hold, Crew, Deltager, Person og Plads. Deres indbyrdes strukturer er beskrevet via aggregeringer, associeringer, generaliseringer og for at give et større overblik anvendes klynger. En person er en generel klasse, som har specialiseringerne deltager og crew. Denne person kan deltage i ét computerparty, og kun have én plads. Et computerparty er associeret med

21 Klasser 9 Turnering Hold 1 2..* Turnering 1 1..* Runde Computerparty 0..* * Plads 1 1..* 2..* 1 1..* 1 Kamp Person 1..* 1 Person 2..* Crew Deltager Figur 1.5: Klassediagram pladser og personer. Det er muligt for en person at deltage i ét eller flere hold, hvor et hold består af én eller flere personer. Dog kan en person kun deltage i ét hold per turnering. Hvert hold kan deltage i én turnering, og en turnering skal have to eller flere hold. En turnering består af én eller flere runder der hører til en enkelt turnering. I hver runde er der et antal kampe, der hver er associeret til mindst to hold. Desuden er hver turnering associeret til et computerparty Klasser I problemområdet er der fundet en samling klasser, der repræsenterer det omfang af problemområdet, som systemet skal omhandle. Disse klasser vil, i dette afsnit, blive forklaret dybere med en gennemgang af hver enkelt klasse. Yderst til venstre i figurerne for hver klasse vises et klassediagram for den enkelte klasse. I klassediagrammet er det muligt at se, hvilke attributter der er tilknyttet klassen. Adfærdsmønstrene til højre i figurerne læses ved at begynde i den fyldte sorte cirkel og følge pilene rundt i diagrammet. Pilene udgør de handlinger, der kan forekomme i tilstanden. Noter som er repræsenteret i adfærdsmønstrene, skal opfattes som attributændringer. Computerparty Computerparty er en abstrakt klasse, da den er systemets overordnede objekt, og der kun er ét system. Klassen er associeret med Turnering og Person, dette er gjort for at sikre, at en

22 10 Kapitel 1. Analyse dokumentation deltager kun kan være del af et hold pr. turnering. Endvidere består et computerparty af et antal pladser. Person Den generelle klasse Person har to specialiseringer: Crew og Deltager. Disse to specialiseringer er opdelt, fordi det skal kunne registreres, om en deltager har betalt for at deltage i computerpartyet, hvilket ikke er nødvendigt at vide om en crew. En Person kan kun være med i ét hold pr. turnering, og kun være associeret med ét computerparty. For både Crew og Deltager er de fleste af attributterne de samme. De fælles attributter dækker over en beskrivelse af, hvem personen er. Derudover har Deltager attributten Betalt, som Crew ikke har. Reservér plads Deltager -Navn -Betalt -Div. brugeroplysninger Tilmeld computerparty Navn Betalt Div. brugeroplysninger Afmeld computerparty Tilmeldt Registrér resultat Tilmeldt hold Afmeld plads Tilmeld hold Plads reserveret Tildel plads Plads besat Afmeld hold Figur 1.6: Adfærdsmønster i form af tilstandsdiagram for Deltager. Adfærdsmønsteret for klassen Deltager kan ses på figur 1.6. Dette objekt bliver oprettet ved hændelsen Tilmeld computerparty, hvorefter deltageren er tilmeldt. Efter tilmelding kan personen reservere en plads, og hvis personen har fortrudt reservationen, kan vedkommende afmelde sin plads og eventuelt reservere en ny plads. Når det registreres, at personen er mødt op til computerpartyet, bliver personen tildelt den reserverede plads. Herefter kan personen tilmelde sig forskellige turneringer. Det er muligt at afmelde et hold fra en turnering, hvis turneringen ikke er gået i gang. Når en deltager er tilmeldt en turnering, har deltageren mulighed for at indrapportere resultater af kampe. Så snart personen er tilmeldt et computerparty, er det muligt for vedkomne at afmelde sig. Crew s adfærdsmønster er nøjagtig det samme som en deltagers, med undtagelse af attributten betalt som en crew ikke har. Plads Plads er den klasse, der beskriver en given plads i computerpartyet. En deltager kan reservere en plads under tilmeldingen til computerpartyet. Klassen Plads kan kun associeres til én deltager, og hver deltager kan kun have én plads. Plads indeholder attributter, der beskriver hvor pladsen befinder sig, det vil sige hvilket bord den er ved, og hvilken plads ved bordet det er. Adfærdsmønsteret for klassen Plads kan ses på figur 1.7. Den hændelse der medfører at objektet plads oprettes, er når én fra crew tilføjer en plads i systemet. Når pladsen er

23 Klasser 11 Plads -Optaget -Pladsnummer -Bordnummer Opret plads Pladsnummer Bordnummer Fjern plads Plads oprettet Reservér plads Plads reserveret Tildel plads Optaget Plads optaget Afmeld plads Optaget Figur 1.7: Adfærdsmønster i form af tilstandsdiagram for klassen Plads oprettet, kan den reserveres, og herefter kan pladsen tildeles deltageren, når vedkommende møder op til computerpartyet. Hvis pladsen er reserveret eller tildelt en deltager, kan pladsen afmeldes. I så fald pladsen hverken er reserveret eller tildelt en deltager, kan pladsen fjernes fra systemet, hvilket medfører objektets død. Hold Klassen Hold er en aggregering af én til flere deltagere, med henblik på at kunne deltage i én turnering. Holdet er associeret med én til flere kampe, imod et antal af andre hold. Hvis det samme hold vil deltage i flere turneringer, skal holdet oprettes for hver turnering. Klassen Hold indeholder informationer om, hvilke deltagere der er med på holdet, hvad holdet hedder og hvor mange point holdet har. Hold -Deltagere -Navn -Point Tilmeld hold Deltagere Navn Afmeld hold Associér hold og kamp Oprettet Klar til kamp Registrér resultat Associér hold og kamp [Regler for turneringstypen] Point Turnering slut Seneste resultat registreret Figur 1.8: Adfærdsmønster i form af tilstandsdiagram for klassen Hold Adfærdsmønsteret for klassen Hold, kan ses på figur 1.8. Hændelsen der medfører at objektet hold oprettes, forekommer når et antal deltagere tilmelder et hold til en turnering, hvilket bringer objektet i tilstanden Oprettet. Holdet kan afmeldes, indtil turneringen begynder. Når turneringen begynder, bliver et hold associeret til en kamp, der bringer objektet i tilstanden Klar til kamp. Når kampen er færdig, registrerer deltagerne resultatet, og til-

24 12 Kapitel 1. Analyse dokumentation standen er nu Seneste resultat registreret. Hvis holdet skal spille flere kampe, bliver holdet associeret til en ny kamp og cyklussen fortsætter. Når turneringen er slut, dør holdet. Kamp Kamp er en klasse i systemet, der repræsenterer en kamp i en turnering. En kamp aggregerer én runde i én turnering. Hver kamp er associeret med et varierende antal hold. Der skal dog mindst være to hold associeret med hver kamp, før den er gyldig. Kamp -Bane -Resultat Opret kamp Bane Kamp oprettet Associér hold og kamp Ét hold tildelt Associér hold og kamp Registrér resultat Resultat Kamp klar Associér hold og kamp Figur 1.9: Adfærdsmønster i form af tilstandsdiagram for klassen Kamp Adfærdsmønsteret for klassen Kamp, kan ses på figur 1.9. Den hændelse der gør at objektet Kamp oprettes, er den samme hændelse, som resulterer i, at der bliver genereret en turneringsplan. Kampe er et produkt af en turneringsplan. Når det er bestemt at en kamp skal spilles, skal der bagefter tages stilling til, hvem der skal spille mod hvem, ud fra nogle turneringstypespecifikke regler; eksempelvis hvem der har vundet i tidligere kampe i turneringen. Det kan ses i diagrammet, at det kræves at mindst to hold skal tildeles en kamp. Det skyldes, at der mindst skal to hold til en turnering for at spille en kamp. Afhængig af turneringstypen, kan der godt være flere end to hold i en kamp. Når kampen er klar til at blive spillet, er det næste blot, at den bliver spillet. Derudfra kommer der et resultat som registreres, da dette resultat er hele essensen i kampen og idéen med turneringen. Efter kampens udfald er blevet registreret, sker der ikke mere for en kamp, og objektet er dødt. Runde Klassen Runde aggregerer klassen Turnering, så en turnering nødvendigvis vil bestå af én eller flere runder. Runde er også en aggregering af Kamp, hvilket betyder, at en runde består af en eller flere kampe. Denne klasse skal beskrive den enkelte runde i turneringen, hvor en mængde kampe skal spilles, før næste runde kan startes. Adfærdsmønsteret for klassen Runde, kan ses på figur Rundeobjektet bliver oprettet som en del af turneringen, og det eneste rundeobjektet kommer ud for er, at der bliver oprettet en mængde kampe i runden. Objektet dør, når runden er afsluttet, hvilket sker når alle kampe i runden er spillet. Turnering Turnering er en aggregering af Runde, Hold og Kampe. Et hold kan kun deltage i én turnering og derigennem flere kampe. Ønsker et hold at deltage i flere turneringer, skal de oprettes igen som et nyt hold, i en ny turnering.

25 Hændelsestabel 13 Opret kamp Runde -Nummer -Antal kampe -Baner -Starttid Opret runde Nummer Antal kampe Baner Starttid Runde slut Runde oprettet Figur 1.10: Adfærdsmønster i form af tilstandsdiagram for klassen Runde Afmeld hold Turnering -Type -StartTid -SlutTid -Præmier -Spil -Baner Opret turnering Start turneringsplanlægning Oprettet Type Opret runde StartTid SlutTid Tilmeld hold Præmier Turneringsplanlægning påbegyndt Spil Associér hold og kamp Baner Start turnering Opret kamp Turnering slut [Finale spillet] Turnering i gang Registrér resultat Figur 1.11: Adfærdsmønster i form af tilstandsdiagram for klassen Turnering Adfærdsmønstret for klassen Turnering, kan ses på figur Klassen Turnering bliver oprettet ved hændelsen Opret turnering, hvilket bringer objektet til tilstanden Oprettet. I denne tilstand kan hold afmelde og tilmelde sig turneringen. Crew har i forvejen en idé om, hvor lang tid hver runde tager at spille, samt hvor lang tid turneringen maksimalt må vare. Derfor kan der på forhånd regnes ud, hvor mange deltagere der maksimalt kan nå at spille i en given turnering. Efter at alle som vil være med i turneringen, har tilmeldt sig, starter turneringsplanlægningen. Herefter bliver der oprettet et antal runder og kampe, alt efter mængden af hold, der er tilmeldt turneringen. Turneringen begynder herefter, hvilket bevirker, at tilstanden skifter fra Turneringsplanlægning påbegyndt til Turnering i gang. Herefter bliver de tilmeldte hold associeret til den næste runde der skal spilles, alt efter hvilke resultater hvert af holdene har indmeldt, som følge af tidligere kampe. Efter at resultatet for finalen er blevet registreret, er turneringen slut, og objektet dør Hændelsestabel Hændelsestabellen benyttes til at give et overblik over, hvilke klasser og hændelser der kan forekomme i problemområdet. Tabellen giver et godt overblik over, hvilke klasser der hænger sammen og hvilke hændelser de hænger sammen med. Hændelsestabellen er et værktøj til at samle et klassediagram til senere brug, i sammenhæng med udvikling af et egentlig system.

26 14 Kapitel 1. Analyse dokumentation Person: Deltager Person: Crew Turnering Kamp Hold Plads Runde Computerparty Tilmeld computerparty + + Tilmeld hold + Registrér resultat + Turnering slut + + Reservér plads Afmeld computerparty + + Afmeld hold + Opret turnering + Tildel plads + + Afmeld plads Opret runde + Opret kamp + Opret plads + Fjern plads + Associér hold og kamp Runde slut + Start turnering + Start turneringsplanlægning + Tabel 1.1: Hændelsestabel - Sammenhæng mellem hændelser og klasser. I hændelsestabellen i tabel 1.1 er klasser listet horisontalt, og hændelser vertikalt. Sammenhæng mellem klasser og hændelser er indikeret med stjerner og plusser. En stjerne betyder, at en hændelse kan forekomme flere gange i et objekts levetid, mens et plus + betyder, at en hændelse kun kan forekomme èn gang. 1.3 Anvendelsesområdet I dette afsnit analyseres det tidligere definerede anvendelsesområde. Herunder gennemgang af brug, funktioner, brugergrænseflader samt andre krav, til blandt andet den tekniske platform. Formålet med afsnittet er, at fastlægge kravene til brugen af systemet og at få udarbejdet en liste over krav til brugen af IT-systemet Brug I dette afsnit fastlægges, hvordan aktører skal interagere med systemet. Dette gøres ved at fastlægge anvendelsesområdets brugsmønstre, og hvilke aktører der interagerer med systemet.

27 Brug 15 Fjern bruger fra systemet Tilføj plads Ret plads informationer Fjern plads Tildel plads Opret turnering Ret turneringsoplysninger Fjern turnering Generer turnering Ret i tilmeldt hold Ret kampresultat Log Ind Tilmeld til computerparty Afmeld fra computerparty Opret bruger i systemet Ret brugeroplysninger Reservér plads Afmeld plads Tilmeld hold til turnering Afmeld hold fra turnering Registrer kampresultat Vis turnering i fuldskærm Crew Deltager Projektor Tabel 1.2: Aktørtabel for systemet. Resultatet af disse analyser er en beskrivelse af brugsmønstre, samt hvem aktørerne er og hvordan de interagerer med et system. Oversigt Her følger en oversigt over, hvilke aktører der har med systemet at gøre. Tabel 1.2 udtrykker også, hvilke områder de enkelte aktører har med at gøre. Aktører Det er vigtigt at vide hvilke aktører, der interagerer med systemet, og på hvilken måde de interagerer med systemet. De følgende aktører i tabel 1.3 og 1.4 er fundet ud fra analysen af problemområdet. På de to figurer er aktørerne opskrevet med specifikationer indenfor formål, karakteristik og tilsidst et eksempel. Eksemplerne er over fiktive personer, der kunne være typiske brugere af systemet (også kaldet personas).

28 16 Kapitel 1. Analyse dokumentation Aktør: Deltager. Formål: En person som deltager i et computerparty, uden at være en del af crew. Deltagerens basale behov er, at kunne tilmelde sig computerparty via et webbaseret system, samt tilmelde sig turneringer under computerpartyet på en opstillet klient. Karakteristik: Deltagerne har forskellige grader af computererfaring, men har den basale viden indenfor brugen af computer som et underholdningsredskab. Eksempel: Christoffer er folkeskoleelev og går i 8. klasse. Han har ikke så meget erfaring med computere, da han for det meste kun bruger computeren til at spille forskellige spil. Et par gange om året deltager Christoffer i et stort computerparty sammen med sine venner. Da Christoffer ikke har så meget erfaring med computere, har han ofte brug for hjælp til eksempelvis opsætning af netværk og installation af spil. Tabel 1.3: Aktørspecifikation for deltager. Aktør: Crew. Formål: En person som administrerer et computerparty, heriblandt turneringerne. Crew s behov er et program, hvor de kan styre og holde øje med turneringerne og deltagernes tilmeldinger. Karakteristik: Personer fra crew har forskellig grader af computererfaring, men antages at have en administrativ forståelse af turneringsplanlægning. Eksempel: Jens er 20 år gammel, og er matematisk studerende på et gymnasium, hvor han klarer sig rimeligt. Han interesserer sig for IT og computere, og det afspejler sig både i hans valgfag og hans fritid. I fritiden laver han nogle gange webdesign for små firmaer, der ønsker brugervenlige hjemmesider. Nogle gange om året er han med som crew til et omfattende computerparty, med ca. 200 deltagere. Til disse computerparties er han ansvarlig for at holde styr på de forskellige turneringer, der skal afvikles. Tabel 1.4: Aktørspecifikation for crew. Scenarier Der findes forskellige scenarier mellem aktørerne og systemet. Scenarierne sammenfatter et antal brugsmønstre for aktørerne og bliver her beskrevet nedenfor. Scenarie 1 - Deltageren Christoffer registrerer sig til et computerparty igennem en hjemmeside, hvor han herefter kan reservere en plads til arrangementet. Til computerpartyet møder Christoffer op, og han får tildelt sin reserverede plads af én fra crew. Under computerpartyet vælger Christoffer at deltage i en turnering sammen med nogle venner. Derfor opretter han et hold ved at indskrive sine kammeraters navne. Tilmeldingen til turneringen sker igennem et klientprogram på en opstillet pc. I løbet af turneringen møder Christoffers hold en række modstandere. Efter endt kamp indtaster han resultatet på den opstillede pc, og resultatet kommer op på en

29 Brug 17 storskærm. Holdet går til sidst hen og vinder turneringen, og får dermed tildelt en præmie for deres indsats. Scenarie 2 - Crew Til computerpartyet sidder Jens ved indgangen og tildeler de fremmødte deltagere en plads igennem systemet. Jens vælger at der skal afholdes en turnering i et computerspil, og begynder at oprette en turnering via systemet. Inden turneringens start udfører Jens en række operationer igennem systemet, hvor han vælger turneringstype, antal spillere pr. hold, spil, baner og præmie. Herefter bliver tilmeldingen sat i gang, hvorefter deltagerne, i hold, tilmelder sig turneringen. Når Jens ser, at der er nok tilmeldte, sættes turneringen i gang. Når turneringen sættes i gang, vælger Jens at generere kampe til turneringen igennem systemet. Efter finalen, tildeles det vindende hold en præmie, hvorefter turneringen stoppes. Brugsmønstre For at forstå de enkelte brugsmønstre i anvendelsesområdet, beskrives de her nærmere. Dette gøres for at give et indblik i, hvordan aktørerne anvender systemet, som styrer en del af anvendelsesområdet. Fælles for de følgende brugsmønstre er, at brugeren skal være logget ind for at kunne tilgå de forskellige funktioner. Brugeren har samtidig, under hele forløbet, mulighed for at fortryde alle ændringer ved at trykke annuller. Oprettelse af turnering På figur 1.12 ses et brugsmønster for oprettelse af en turnering. Brugeren, som er en del af crew, bliver præsenteret for en formular, hvorpå der findes nogle felter, som skal udfyldes. Dette er eksempelvis; hvilket spil og hvilken bane der skal spilles, hvilken turneringstype, hvornår turneringen skal spilles og hvor mange hold der hhv. min- og maksimalt må deltage i turneringen. Når brugeren har indtastet de relevante data, vælges kontrollér, og systemet vil validere dataene. Hvis dataene ikke er valide, afvises de, og formen med de indtastede data vises nu sammen med en beskrivelse af fejlen, så brugeren kan rette det indtastede. Brugeren kan nu igen vælge kontrollér for at validere dataene endnu en gang. Er dataene valide, godkender systemet dem og viser en oversigt over de indtastede data. Her kan brugeren dog ikke rette i dataene, men skulle brugeren have lavet en indtastningsfejl, kan brugeren vælge at afvise det indtastede, og formularen kommer nu tilbage, så brugeren kan rette i dataene. Hvis brugeren derimod er tilfreds med dataene i oversigten, vælger brugeren at gemme dataene, hvilket systemet gør, og oprettelsen af en turnering er nu fuldført. Redigering af turnering På figur 1.13 ses et brugsmønster for redigering af en turnering. Brugeren bliver her præsenteret for en liste over de forskellige turneringer, som forefindes i systemet. Her vælger brugeren den turnering, som der ønskes at redigere, og vælger Rediger turnering. Brugeren bliver nu præsenteret for en oversigt over alle relevante turneringsdata og kan ændre dem efter ønske. Når brugeren er færdig med at ændre i dataene, vælges knappen kontrollér og systemet validerer dataene. Hvis dataene ikke er valide, afvises de og formularen med de indtastede data vises nu med en beskrivelse af fejlen. Brugeren kan nu rette det indtastede data, og når fejlene er rettet trykkes på kontrollér igen og dataene valideres igen. Hvis dataene er valide, godkender systemet dem og viser en oversigt over de indtastede data. Hvis brugeren finder

30 18 Kapitel 1. Analyse dokumentation / Opret ny turnering Interaktions rum Interaktions elementer Afvent indtastning / Indtast relevante data Indtaste data Data indtastet Form / Kontrollér data / Ret data / Afvis Data kontrolleret Afvent rettelse (vis fejl) Annuller / Godkend / Afvis Gem Data valideret, Bekræft indtastning / Godkend Oversigt Ret data / Annuller Figur 1.12: Brugsmønster for oprettelse af turnering en fejl i de indtastede data, vælger han at afvise de indtastede data og kommer nu tilbage til indtastningsformularen. Brugeren kan også vælge at gemme sine ændringer, og dataene gemmes af systemet. Registrering af kampresultat Tilstandsdiagrammet på figur 1.14 viser brugsmønstret for registrering af kampresultat for en given kamp. Brugeren bliver præsenteret for en oversigt over de forskellige turneringer, og den aktuelle turnering kan markeres, hvorefter der trykkes på registrér kampresultat. Systemet præsenterer nu brugeren for en skærm, som viser den kamp brugerens hold lige har spillet. Dette valg træffer systemet ud fra de tidligere kampe, som brugerens hold har spillet. Dette betyder, at når et kampresultat er indtastet, er det ikke muligt at indtaste et nyt resultat, før næste runde i turneringen startes. Dog kan crew rette i resultaterne, hvis det er nødvendigt. Dette sker først, når alle kampene i runden er indrapporteret. Brugeren har mulighed for at indsende resultatet for den aktuelle kamp ved at vælge indrapporter. Nu kontrollerer systemet om dataene kan valideres, hvis resultatet ikke findes validt, bliver brugeren præsenteret for en fejlbesked, samt det tidligere indskrevne resultat. Brugeren har nu mulighed for at rette fejlen og forsøge igen. Hvis det indtastede derimod kan godkendes, gemmes dataene. Bliver det indtastede resultat fundet validt, bekræfter systemet, at det indskrevne nu er gemt, og brugeren kan trykke ok for at afslutte handlingen.

31 Brug 19 / Vælg turnering Interaktions rum Interaktions elementer Turnering valgt / Vælg rediger turnering Turnerings Browser Rediger hold Afvent redigering af turnerings data / Rediger data Indtast Data redigeret / Kontroller data / Ret data Form Annullér Data kontrolleret / Godkend / Afvis Afvent rettelse (vis fejl) / Afvis Ok Data valideret, Bekræft redigering / Godkend Oversigt Annullér / Annullér Ret Ok Figur 1.13: Brugsmønster for redigering af turnering Tilmeld hold til turnering Brugsmønstret for handlingen kaldet Tilmeld hold til turnering, kan ses på figur Når en bruger ønsker at tilmelde sit hold til en turnering, præsenteres brugeren for en liste over de turneringer, som det er muligt at tilmelde sig. Brugeren markerer herefter den turnering, som brugeren ønsker at melde sit hold til og trykker på knappen tilmeld hold, hvorefter brugeren får vist en tilmeldingsformular. På denne formular skal der indtastes et holdnavn og brugernavn, samt password på alle de brugere, der er med på holdet. Antallet af brugere pr. hold er bestemt af turneringsinformationerne og kan variere fra én til uendeligt mange. Efter informationerne er blevet indtastet, kan brugeren trykke på Kontrollér for at godkende de indtastede informationer. Hvis dataene ikke er valide, afvises de og formularen med de indtastede data vises nu igen, men denne gang med en beskrivelse af fejlen, så brugeren kan rette det indtastede. Er dataene imidlertid valide, godkender systemet dem og viser en oversigt over de indtastede data. Her kan brugeren ikke rette i dataene, men han kan vælge at afvise det indtastede for derved at komme tilbage til indtastningsformularen. Brugeren kan også vælge at tilmelde holdet og herved gemmes dataene i systemet, og holdet er tilmeldt.

32 20 Kapitel 1. Analyse dokumentation / Vælg turnering Interaktions rum Interaktions elementer Turnering valgt / Vælg Indrapporter resultat Turnerings Browser Klikke på kamp Kampinfomation vises, Afvent indtast af resultat / Indtast data Indtaste data Data indtastet / Kontrollér data / Ret data Form Annuller Data kontrolleret / Godkend / Afvis Afvent rettelse / Afvis Ok Data valideret, Bekræft indtastning / Godkend Oversigt Ret data / Annuller Ok Figur 1.14: Brugsmønster for registrering af kampresultat Afmeld hold fra turnering Brugsmønstret for afmelding af hold fra turnering kan ses på figur I turneringslisten kan brugeren vælge mellem de turneringer, som brugeren, og de hold brugeren er medlem af, deltager i. Brugeren begynder med at markere den turnering, som brugeren ønsker at afmelde sit hold fra. Efter at turneringen er blevet markeret, kan brugeren trykke på afmeld hold. En dialogboks kommer frem på skærmen, hvor brugeren bliver bedt om at bekræfte afmeldingen af holdet. Brugeren kan vælge at trykke på Ok, hvilket resulterer i, at holdet afmeldes og brugeren bliver sendt tilbage til turneringslisten. Hvis brugeren derimod vælger at trykke på Annullér, bliver brugeren også sendt tilbage til turneringslisten, men uden at holdet bliver afmeldt Funktioner Tidligere i rapporten er det blevet beskrevet med brugsmønstre, hvorledes systemet skal anvendes. Nu flyttes fokus over på, hvad systemet skal kunne gøre, og dette gøres ved at angive hvilke funktioner, systemet skal kunne udføre. Der vil blive udarbejdet en komplet funktionsliste, og de mest komplekse funktioner vil blive beskrevet i nærmere detaljer.

33 Funktioner 21 / Vælg turnering Interaktions rum Interaktions elementer Turnering valgt / Vælg tilmeld turnering Turnerings Browser Tilmeld hold Afvent indtastning af holddata / Indtast data Indtast Data indtastet / Kontroller data / Ret data Form Annullér Data kontrolleret / Godkend / Afvis Afvent rettelse (vis fejl) / Afvis Ok Data valideret, Bekræft oprettelse / Godkend Oversigt Annullér / Annullér Ret Ok Figur 1.15: Brugsmønster for tilmeld hold til turnering Komplet funktionsliste I tabel 1.5 er der opstillet en liste over samtlige funktioner, systemet skal understøtte. For hver funktion er der angivet, hvor kompleks den er, og hvilken type funktion det er. Funktionslisten bruges til at skabe et overblik, over hvilke funktioner der skal laves til systemet, og dermed hvilke funktionaliteter, der er til rådighed for systemets brugere. Nærmere krav til funktionerne findes i prioritetstabellen i tabel 1.6. Specifikation af funktioner I systemet eksisterer der én kompleks funktion, som er generér turneringsplan. Denne funktion skal generere skelettet af turneringsplanen. Skelettet er måden, hvorpå alle kampe er forbundet i turneringen, hvem der skal møde hinanden, og hvem der skal møde hinanden i efterfølgende kampe. Hvordan skelettet ser ud for en given turnering afhænger af turneringstypen og antallet af deltagende hold. Ud fra antallet af tilmeldte hold fastsættes de kampe, der skal spilles igennem hele turneringen. Til kampene i første runde tilføjes de deltagende hold tilfældigt.

34 22 Kapitel 1. Analyse dokumentation Interaktions rum Interaktions elementer / Vælg turnering Turnering valgt / Annullér/ Vælg afmeld hold fra turnering Turnerings Browser Vælg turnering Afmeld hold Bekræftelsesbox / Godkend Dialogbox Bekræft Figur 1.16: Brugsmønster for afmeld hold fra turnering Brugergrænseflade Dette afsnit samler op på hvilke krav, der er til IT-systemet med hensyn til brugergrænsefladen. Dette giver indblik i, hvilke præsentationsformer brugerfladen skal bestå af, og giver en liste over de elementer, der skal være til stede for aktørerne i systemet, som er deltager, crew og projektor. Mål for brugergrænsefladen Formålet med prioriteringstabellen i tabel 1.6 er at vise, hvorledes forskellige elementer af systemets brugergrænseflade prioriteres. Dette er væsentligt at definere i starten af analysefasen, da det vil have en stor indflydelse i det videre udviklingsforløb af programmet. Begrebsmæssig model For at give en grundlæggende karakteristik af, hvordan brugeren interagerer med systemet, gøres der brug af begrebsmæssige modeller. Disse begrebsmæssige modeller har til formål, at give en mere konkret beskrivelse af de interaktionsformer, som en bruger interagerer med systemet på. Dette indebærer blandt andet overvejelser om, hvilke rettigheder en bruger skal have, hvor meget feedback systemet skal give på instruktioner, og hvorledes brugere skal tilgå information i systemet. Dette kan laves ud fra modeller baseret på aktiviteter, men også på objekter. Her er der valgt at benytte en begrebsmæssig model baseret på aktiviteter. Der er fire forskellige grundlæggende interaktionsformer, som systemet kan designes ud fra. Disse interaktionsformer er: - Instruktion: Brugeren aktiverer en funktion, systemet udfører denne funktion og returnerer et output. - Konversation: Brugeren og systemet fører en dialog for at nå frem til et resultat.

35 Brugergrænseflade 23 Funktion Kompleksitet Type List pladser Simpel Aflæsning Hent pladsoplysninger Simpel Aflæsning Opret, redigér & slet plads Simpel Opdatering List deltagere Simpel Aflæsning Hent deltageroplysninger Simpel Aflæsning Opret, redigér & slet deltager Simpel Opdatering Reservér & afmeld plads Simpel Opdatering Tildel plads Simpel Opdatering List turneringer Simpel Aflæsning Hent turneringsoplysninger Simpel Aflæsning Opret, redigér & slet turnering Simpel Opdatering List hold Simpel Aflæsning Hent holdoplysninger Simpel Aflæsning Opret & slet hold Simpel Opdatering Generér turneringsplan Kompleks Beregning List kampe Simpel Aflæsning Opret kamp Simpel Opdatering Tildel hold til kamp Simpel Opdatering Indrapporter kampresultat Middel Opdatering Vis turneringsplan Simpel Aflæsning Tabel 1.5: Komplet funktionsliste for systemet. - Manipulation og navigering: Brugeren manipulerer virtuelle objekter og navigerer rundt i en virtuel verden. - Udforskning og browsing: Brugeren bevæger sig igennem en samling af informationer og udvælger dele af informationerne. Administrationsdelen af systemet vil benytte sig af Udforskning og browsing, da det bl.a. vil bestå af browservinduer, hvor der kan rulles gennem kampe og turneringer. Når en kamp eller turnering er valgt er det muligt at benytte knapper til at interagere med det valgte objekt. Denne form for interaktion er Instruktions -formen, dette er i sammenhæng med at der klikkes på en knap i vinduet og det medfører en handling fra systemet. Dette er også kendt som aktion/reaktion; at der er en reaktion til hver aktion, der udføres. Når der klikkes på en knap med en given kommando, bliver den kommando udført. Der kan eventuelt åbne sig en række nye muligheder, men systemet vil ikke umiddelbart foreslå, hvilken af disse, der skal benyttes, det er op til brugeren selv. De sidste to interaktionsformer, som er konversation og manipulation og navigering, er ikke benyttet i sammenhæng med dette system.

36 24 Kapitel 1. Analyse dokumentation Usability Effectiveness Efficiency Safety Utility Learnability Memorability Meget vigtigt Vigtigt Mindre vigtigt Irrelevant Satisfying Enjoyable Fun Experience Entertaining Helpful Motivating Aesthetically pleasing Supportive of creativity Rewarding Emotionally fulfilling Tabel 1.6: Prioritetstabel Interaktionsform For at understøtte forståelsen af den begrebsmæssige model, suppleres der med beskrivelser af forskellige interaktionsformer. Disse interaktionsformer har til formål at fastlægge de centrale egenskaber i selve interaktionen. Der er mange forskellige måder, hvorpå denne interaktion kan foregå, og nogle af dem er listet herunder: - Kommando: Brugeren ser intet på forhånd og skal interagere med systemet ved brug af kommandoer efter et bestemt format. Eksempler på dette kan være Unix eller DOS. - Menu: Ved denne interaktionsform findes der en menu, hvor brugeren kan vælge mellem mange forskellige muligheder. Dette kan f.eks. være dropdown-menuer, eller menuer der vises ved klik på et objekt. - Dialog: Med denne form vil brugeren i givne situationer få en dialogboks frem på skærmen, hvor der vil være forskellige muligheder, såsom OK eller Annuller. - Skema/Formular: Brugeren skal her interagere med et skema, der kræver en række informationer udfyldt, og på baggrund af disse informationer kan systemet give feedback. - WIMP: Denne interaktionsform er blandt andet kendt fra Microsoft Windows. Betegnelsen WIMP står for: Windows, Icons, Menus and Pointers.

37 Brugergrænseflade 25 I systemet gøres der brug af nogle af disse interaktionsformer, dette gøres for at skabe en interaktion mellem system og bruger. Menu: Bruges til at vælge forskellige valgmuligheder for et givet objekt. Dialog: Anvendes til de tilfælde, hvor f.eks. brugeren færdiggør en handling til systemet, hvor systemet derefter kontrollere om brugeren vil fuldføre handlingen. Skema: Bruges til at udfylde og indsende input til systemet, f.eks. når en turnering skal oprettes. WIMP: Anvendes til generel brug og navigering rundt i systemet, hvor pointeren (musen) bruges til at vælge elementer i systemet, og menupunkter til at interagere med dem. Generel interaktionsmodel Turnerings Browser Tilmeld hold til Turnering Turnerings View Afmeld fra Turnering Kamp View Forespørg Næste Kamp Registrer Resultat Bruger View Find modstander Ret Bruger Plads Browser Tilmeld til Computerparty Figur 1.17: Oversigt over det generelle interaktionsrum for Deltagere. For at få et overblik over de forskellige interaktionsrum, der er knyttet til brugergrænsefladen, opstilles en generel interaktionsmodel for de forskellige aktører. I dette system er der således tale om to forskellige aktører, hhv. deltagere og crew. Hver især har de adgang til forskellige dele af systemet, men samtidig har de en række fælles interaktionsrum, da det skal være muligt for crew at se de samme data, som deltageren kan se. På figur 1.17 ses det generelle interaktionsrum for deltagerne, og en tilsvarende oversigt for crew kan ses på figur A.1, som er vedlagt som bilag (A.1).

38 26 Kapitel 1. Analyse dokumentation Den tekniske platform Den tekniske platform for systemet er en standard pc med internetadgang. Pc en skal kunne eksekvere programmel, udviklet til.net Framework 2.0. Internetadgangen skal bruges sammen med en webserver med eksempelvis ASP.net, for at tillade potentielle deltagere at tilmelde sig partyet via internettet. Pc en skal have et grafikkort, der understøtter tilkobling af flere skærme, så der kan sluttes en projektor. Projektoren kan fungere som storskærm, der viser status over turneringer og andre aktuelle informationer til et computerparty. 1.4 Anbefalinger I dette afsnit gives et overblik over anbefalinger, til det videre udviklingsarbejde med systemet. Dette indebærer en vurdering af IT-systemets nytte og realiserbarhed, en anbefaling til en udviklingsstrategi og en vurdering af udviklingsøkonomien. Det er vigtigt at opsummere, om det er aktuelt at udvikle systemet, taget de, i analysen, overvejede elementer i betragtning. Når dette er undersøgt, er det klart, om systemet stadig skal udvikles, eller om det ikke er aktuelt. Det er en vigtig overvejelse, da der kunne være risiko for, at bruge en masse ressourcer på at udvikle et system, som ikke er brugbart, og dette skal vurderes tidligst muligt i udviklingsprocessen IT-systemets nytte og realiserbarhed En del af arbejdet med analysen til udviklingen af et IT-system, består i, at overveje dets aktualitet og nytte. Spørgsmålene der skal besvares er; har systemet en egentlig fremtid? Er det nyttigt? Og kan det realiseres? Nytte: Da systemet er et administrationsværktøj, er det vigtigt, at det er nyttigt. Det er meningen med et administrationsværktøj, at det skal forsimple, forbedre samt optimere den proces, det er beregnet til at udføre. I dette projekts tilfælde er administrationsprocessen at administrere deltagere, hold samt at lægge turneringsplaner med tilhørende kampe. Endeligt skal det kunne holde styr på stillinger i turneringer og formidle generel information. For at undersøge om det nye system er bedre end den gamle administrationsmetode, sammenlignes arbejdsprocesserne i det nye og i det gamle system. I det gamle system forløber arbejdsprocesserne, almindeligvis, mere eller mindre manuelt, det vil sige med papir og blyant eller regneark. Her skal der eksempelvis redigeres i papirerne, hvis et hold framelder sig, og crew et skal løbende, efter hver kamp, opdatere en turneringsoversigt, så deltagerne kan se, hvem de skal spille imod og hvornår. Det nye system vil være fuldt ud IT-styret og klarer de fleste af de opgaver, som crew tidligere skulle bruge meget tid på. Derfor må det nye system siges at lette arbejdsprocessen med de enkelte arbejdsopgaver. Når systemet lever op til formålet med at forenkle arbejdsprocesserne for crew et, må det siges at være nyttigt til administration af computerparty og turneringsplanlægning. Realiserbarhed: Spørgsmålet om hvorvidt systemet kan realiseres, kan besvares ved at overveje, hvilke ressourcer der er til rådighed i udviklingsøjemed, samt hvilke teknologier der kræves for at udvikle administrationssystemet.

39 Strategi 27 Det der kræves i udviklingen, er, udover udviklerne (forfatterne), tid til programmering, hvilket er til rådighed imellem studiets forelæsninger. Udviklingsværktøjer og dokumentation til at udvikle applikationer til.net framework 2.0 bliver stillet til rådighed igennem Microsoft Developer Network Academic Alliance og Microsoft Developer Network. Systemet kræver én pc med en projektor (eller anden form for fremviser) tilkoblet og en internetforbindelse, med tilhørende webservice. Disse krav er ikke svære at opfylde, da disse ressourcer betragtes som relativt nemme at rekvirere. En projektor kan være dyr at anskaffe, men en anden fremviser kan i så fald bruges (eksempelvis en computerskærm). Opsamlingsvis kan det konkluderes at systemet kan realiseres Strategi I strategien for videreudvikling af systemet tages der udgangspunkt i analysedokumentet. Strategien for det videre forløb tager udgangspunkt i en iterativ faseopdelt udviklingsmodel, hvor hver fase udarbejdes grundigt, før der fortsættes til næste fase. Endvidere tager strategien fat i OOA&D-metoden at videreudvikle et system efter analysen. Hermed påbegyndes arbejdet på designdokumentet efter analysens afslutning og dernæst implementationen samt test af systemet. Figur 1.18 viser en oversigt over de forskellige faser, der skal benyttes i løbet af den videreudvikling. Tiden er afbilledet vandret, mens de forskellige opgaver er vist lodrette. Foranalyse Systemvalg Analyse Analyse P.O. Analyse A.O. Design Design af arkitektur Design af komponenter Design af BM Programmering Test/Kvalitetssikring Fase 1 Fase 2 Fase x Figur 1.18: Oversigt over strategien for projektet, med idé fra slides [4] Udviklingsøkonomi og tidsplan Da dette er en rapport i studieøjemed, er der ingen økonomisk horisont, udover det hardware, som skal benyttes i sammenhæng med systemet. Udviklingsteamet består af 7 ulønnede personer (forfatterne af denne rapport). Analysedokumentet forventes færdig d. 18. oktober 2006, desuden forventes designdokumentet færdigt d. 13. november 2006 og derefter følger selve udviklingen, samt test af systemet frem til d. 21. december 2006, hvor projekt- og studierapporten skal afleveres.

40 28 Kapitel 1. Analyse dokumentation 1.5 Opsamling Opsamlingsvis diskuteres situationen og opgaven i analysedokumentet. Herunder beskrives hvad det egentlige formål med systemet er, hvilket leder videre til en klart formuleret systemdefinition, der danner rammerne for det efterfølgende udviklingsarbejde. Systemdefinitionen indeholder de første og mest generelle retningslinjer for systemets virke og eksistens. Endeligt bliver systemomgivelserne analyseret, for at give et grundlag for hvilke elementer der interagerer med og omkring systemet. Systemomgivelserne bliver herefter udpenslet til hvilke dele der hører ind under det egentlige problemområde. For at få overblik og struktur over problemområdet, bliver det delt op i klasser og i hændelsestabeller. Hændelsestabellen giver et indblik i hvilke hændelser brugeren af systemet forventes at skulle udføre. Efter problemområdet er fast defineret, er anvendelsesområdet næste del. Under anvendelsesområdet beskrives hvordan brugen af systemet vil foregå, samt hvilke funktionaliteter der skal være til rådighed for brugeren af systemet. Dette afrundes med at overveje hvilken brugergrænseflade, der skal være i systemet. Analysedokumentet afsluttes med en overvejelse over, om systemet overhovedet er realiserbart, om det stadig har et grundlag for at blive udviklet, om det er muligt at lave og om det kan være nyttigt for brugeren i anvendelsesområdet. Der ligges en strategi for det videre udviklingsarbejde, og udviklingsomkostninger overvejes for at sikre om det stadig kan svare sig ren økonomisk at udvikle systemet.

41 Kapitel 2 Design dokumentation Dette kapitel samler indledningsvis op på fejl og mangler fra analysedokumentet. Dette leder videre til den overordnede hensigt med kapitlet som er, at formulere et designdokument over, hvordan systemet skal struktureres og hvordan det skal interagere med brugeren. Designdokumentet indebærer en kortfattet beskrivelse af selve opgaven, hvor kvalitetsmålene bliver samlet op. Dette afsnit støtter op om udviklingen i den henseende, at det sikrer at designet overholder de mål og/eller krav til kvaliteten af systemet, som er opstillet gennem analysen. Beskrivelsen af opgaven leder videre til en uddybning af det overordnede formål med udviklingsopgaven. Designdokumentet indeholder ydermere en uddybet opsamling, af den overordnede tekniske platform for systemet. Dette indebærer valg af diverse sprog (som eksempelvis designsprog og programmeringssprog), samt udstyr. Arkitekturafsnittet beskriver strukturen af diverse komponenter i systemet. Disse komponenter findes senere præciseret og uddybet hver for sig i komponentafsnittet. Endeligt samles designdokumentet op, ved at overveje og diskutere hvilke anbefalinger der benyttes til selve udviklingsarbejdet. Strukturering af design og arkitektur af systemet, er formuleret og beskrevet med støtte fra bogen Applying UML and Patterns [5] og Objekt Orienteret Analyse & Design [2], som beskriver og eksemplificerer nyttige teknikker til strukturering og arkitektur. Til opbygning af brugergrænseflade anvendes bogen Windows Forms 2.0 [6], som er god i sammenhæng med opbygning, layout og strukturering af forms. 2.1 Opgaven Dette afsnit giver en kortfattet beskrivelse af opgaven og de opstillede kvalitetsmål. Dette gøres ved, at uddybe det overordnede formål med systemudviklingsprojektet. Endvidere samles op på, hvilke rettelser eller forbedringer, der måtte være til analysedokumentet. Endeligt gives en oversigt over kvalitetsmålene for udviklingsopgaven Formål Det designede system skal lette opgaven med administration af pladser, hvilket betyder reservation og tildeling af pladserne. Derudover skal det også lette administrationen af turneringer, hvilket indebærer planlægning og afvikling af disse. Systemet skal kunne bruges til admin- 29

42 30 Kapitel 2. Design dokumentation istration af deltagerne, og samtidigt hjælpe deltagerne med at reservere pladser og danne hold til turneringer. I systemet skal der være mulighed for forskellige brugerniveauer, så når en fra crew logger ind, vil der være ekstra administrationsmuligheder. Der skal også være en speciel brugerkonto, som er beregnet til computere, der er tilkoblet en storskærm Rettelser til analysen For at samle op på fejl og mangler fra analysedokumentet, bliver der i de følgende overskrifter, diskuteret nye overvejelser om diverse rettelser fra analysen. Dette gøres for at forbedre den endelige udvikling med nye tiltag og forbedringer af gamle. Rettelserne har ført til et revideret klassediagram, som kan ses på figur 2.1. Turnering Turnering Computerparty 0..* * 1 2..* Hold 2..* 1..* 1 Runde 1 1..* 1 1..* 1 2..* Turneringstype Plads 1 Kamp Single Elemination Double Elemination Pulje 1 2..* Deltager 1..* Figur 2.1: Opdateret klassediagram Rettelse af klassen Hold Når en deltager tilmelder et hold til en turnering, vil deltageren automatisk blive registreret som holdleder for holdet. Når et hold har spillet en kamp og resultatet skal indrapporteres til systemet, er det kun holdlederen der har mulighed for dette. Der er således kun en deltager pr. deltagende hold i en kamp, der har mulighed for at indrapportere resultatet for kampen. Derved undgås det, at mange deltagere vil indtaste samme resultat for en kamp på samme tid. Ændringen vil kræve, at der til klassen Hold tilføjes en attribut, der angiver, hvem der er holdleder på det pågældende hold. Rettelse af klassen Person Der er fundet en forbedring til struktureringen af systemets klasser. Der er tale om den måde, hvorpå Deltager og Crew er repræsenteret. Fra analysedokumentet ses det, at begge klasser findes i hændelsestabellen1.1 med de samme hændelser. Det betyder, at begge klasser skal kunne det samme, og behandles på nogenlunde samme måde, af den grund er det mere hensigtsmæssigt at de to klasser blot samles til én klasse. Da forskellen mellem klasserne Deltager og Crew (i diagrammet fra designdokumentet: Figur 1.5) kun var attributter, blev de slået sammen til klassen Deltager (i det rettede diagram: Figur 2.1) som ud over attributten Betalt også indeholder en attribut om hvilke rettigheder brugeren har. Klyngen om generaliseringen af Person og dens specialiseringer Deltager og Crew er fjernet, da den ikke længere bidrager med noget.

43 Kvalitetsmål 31 Kriterium Meget vigtigt Vigtigt Mindre vigtigt Irrelevant Trivielt opfyldt Brugbart Sikkert Effektivt Korrekt Pålideligt Vedligeholdbart Testbart Fleksibelt Forståeligt Genbrugbart Flytbart Integrerbart Tabel 2.1: Prioritering af designkriterier Rettelse til brugsmønster for Tilmeld hold til turnering Denne rettelse er relateret til figuren 1.15 fra side 21 i analysen. Rettelsen beligger i, at der kun skal indtastes brugernavn på de øvrige holdmedlemmer. Dette forsimpler processen; at tilmelde et hold til en turnering, da alle holdmedlemmerne ikke behøver at stå ved tilmeldingscomputeren. For at forsimple det yderligere for holdkaptajnen (ham der tilmelder holdet til en turnering), så har han mulighed for at søge sig frem til de øvrige holdmedlemmers brugernavne. Dette tiltag gør det til gengæld muligt at tilmelde andre folk til ens hold, som ikke ønsker at være med på holdet. I sådanne tilfælde må crew gribe ind og fjerne den ufrivillige deltager fra det givne hold. Rettelse til struktureringen af turnering I klassediagrammet fra analysedokumentet (figur 1.5 på side 9) blev klassen Turnering opstillet som en helhed, for både selve turneringen, men også alle turneringstyper. Dette konstrueres nu ved at opdele Turnering, så den kan holde styr på flere forskellige turneringstyper, for på den måde at have en sammensat turnering. Turneringstyper bliver struktureret ved at lave en superklasse Turneringstype, hvoraf de forskellige turneringstyper er subklasser af. Dermed kan klassen Turnering bestå af flere forskellige turneringstyper pga. superklassen Turneringstype. Som følge af dette, er det mere hensigtsmæssigt at Runder aggregerer Turneringstype, da Turneringstype er tænkt som værende en selvstændig turnering Kvalitetsmål For at give et overblik over de designmål der er sat for kvaliteten af systemet, er det nødvendigt at opstille en overskuelig, prioriteret liste over de forskellige designkriterier og deres vigtighed, i forhold til det aktuelle system. Denne prioriteringstabel er vist som tabel 2.1 på side 31. Grundlaget for den valgte prioritering af kriterierne er som følger:

44 32 Kapitel 2. Design dokumentation Brugbarhed: Brugbarhed er prioriteret som meget vigtig, da det er specielt vigtigt, at sørge for at systemet er tilpasset de omgivelser det skal benyttes i, og dermed sikre at systemet kan udføre de opgaver brugerne ønsker løst. Sikkerhed: Sikkerhed er prioriteret som mindre vigtig, da der ikke er tale om beskyttelse af meget værdifulde brugerdata i systemet. Det er vurderet at det er mere vigtigt, at opfylde andre designkriterier frem for dette, eftersom det kan være et helt system i sig selv (f.eks. Anti-Virus, Firewalls) at sikre mod uønsket adgang. Effektivt: Dette punkt er trivielt opfyldt, da systemet ikke vil komme til at belaste den valgte tekniske platform. Denne vurdering er baseret ud fra, at programmet ikke skal lave store intense beregninger, koordinere store mængder af data eller anden form for ressourcekrævende behandling af data. Dette gør sig gældende, hvis programmet bliver programmeret korrekt. Korrekthed: Det er vigtigt at systemet har korrekthed, da der kan komme unødige konflikter mellem deltagere, som kan ødelægge tilliden til systemet og dermed fjerne grundlaget for at bruge systemet. Dette kunne eksempelvis ske, hvis resultater og pladsbestillinger ikke stemmer overens med det brugerne har indtastet/valgt. Pålidelighed: Pålidelighed er prioriteret som vigtig, da systemet skal udføre den valgte funktion og afvikle den præcist hver gang. Hvis brugerne af systemet ikke finder systemet pålideligt, vil de ikke bruge systemet, til at behandle data med, og derfor søge alternative metoder. Vedligeholdelsen: Vedligeholdelsen af systemet er prioriteret som vigtig, da det er meningen, at systemet skal kunne rettes for fejl, uden større problemer. Desuden skal det også være muligt, at kunne opdatere systemet med nye udvidelser. Dette kunne eksempelvis være at bruge en ny metode til datalagring eller understøttelse af nye turneringsformer. Testbarhed: Dette punkt er mindre vigtigt, da omkostninger ved at finde ud af om kravene er opfyldt, ikke har en betydning, men at der stadig skal være mulighed for at undersøge, om kravene er opfyldt. Dette er heller ikke et krav der skal fokuseres på under udviklingen, men det er selvfølgelig altid relevant at kunne teste det udviklede system. Fleksibilitet: Fleksibiliteten er mindre vigtig, da der ikke vil blive lagt vægt på videreudvikling af systemet. Desuden vil systemets omfang betyde, at der ved opdateringer, blot skal ligges en ny version tilgængelig til download, som kan overskrive den gamle. Forståelighed: Dette er prioriteret som meget vigtigt, da en forståelse af systemet giver grundlag for korrekt brug af systemet. Genbrugbarhed: Genbrugbarhed af systemet er vurderet som mindre vigtigt, på grund af at det ikke er en af hovedvægtene at sørge for, at systemets dele kan bruges i/af andre systemer. Flytbarhed: I første omgang er flytbarheden af systemet markeret som irrelevant, da det er irrelevant om systemet kan bruges på andre platforme (som eksempelvis linux eller Mac OS), end det er beregnet til. Dette er således, eftersom der i det valgte problemområde altid vil være en computer tilstede, som vil kunne køre programmet, på den valgte tekniske platform. Der kan måske være tale om, ved eventuel senere opdatering, at udvide systemet til andre platforme, for at skabe en forbedring. Dog er det ikke alle

45 2.2. Teknisk platform 33 former for systemer der kan blive relevante til dette. I første omgang bliver systemet kun udviklet til den valgte tekniske platform. Integrerbarhed: Integrerbarheden er prioriteret som værende mindre vigtigt, da integrerbarhed ikke er det område der vil blive lagt vægt på under design og implementering af systemet. Det er ikke meningen at systemet for eksempel skal kunne importere/modtage deltagerlister fra andre systemer eller tilmeldte hold, for at bruge dem selv. En videreudvikling af systemet, kan eventuelt indeholde denne mulighed. 2.2 Teknisk platform Dette afsnit giver en kortfattet beskrivelse af designsproget og af udstyr, basisprogrammel og andre systemer, som systemet udvikles og realiseres ud fra. Dette indebærer en beskrivelse af relevant udstyr, basisprogrammel, systemgrænsefladen og designsproget. Meningen med afsnittet er, at give et billede af de udviklingsmæssige krav, der stilles af systemet. Det giver en idé om en udviklingsplan som forsimpler selve udviklingsprocessen for udviklerne, i den forstand at udvikleren får informationer om hvilke standarder systemet skal overholde. Ydermere giver det læseren en fornemmelse af hvilken grænseflade systemet vil fungere til og hvordan Udstyr Systemet har behov for en standard pc med.net framework 2.0. Deltagerne skal have adgang til en webgrænseflade, som kan vises i de mest udbredte browsere, som Internet Explorer og Firefox [7], hvorpå de kan tilmelde sig computerpartyet og reservere en plads. Derudover skal deltagerne have adgang til en WIMP (window, icon, menu, pointing device), som er implementeret i C#, hvorpå de kan tilmelde sig turneringer og indmelde kampresultater. Crew skal både have adgang til webgrænsefladen, men også til en WIMP udgave, hvorpå de kan administrere hele computerpartyet. Desuden skal der være mulighed for, at turneringen skal kunne vises via en storskærmsprojektor Basisprogrammel Til udviklingen af systemet vil programmeringssproget C# blive brugt. Der udvikles et klientprogram til kørsel på enkeltstående computere, og en webside der skal køre på en webserver. Klientprogrammet vil blive udviklet i C#, der er en del af.net framework. Websiden til webserveren vil blive udviklet i ASP.NET, der ligeledes er en del af.net framework. Ved at begge programmer er udviklet i.net framework, kan programmet og websiden benytte de samme klasser, så klasserne kun skal programmeres en gang. Begge programmer har brug for at udveksle data, dette sker enten vha. filer med serialiseret data eller en fælles database. Til at udvikle programmerne bruges udviklingsværktøjet Microsoft Visual Studio [8] Designsprog Til designdokumentet er der anvendt standarden UML, som står for Unified Modeling Language, der er blevet bekendtgjort i SAD forelæsningerne, hvor bogen OOA&D [2] var en del af undervisningsmaterialet. Denne standard anvendes til at beskrive systemet og dermed

46 34 Kapitel 2. Design dokumentation få en forståelse for selve systemet, uden reelt at programmere systemet. Dermed giver det mulighed for at give andre læsere en forståelse af hele systemet, uden reelt at se på koden. 2.3 Arkitektur Arkitekturen af systemet giver en beskrivelse af systemets strukturering i komponenter og processer, samt en beskrivelse af standarder for arkitekturdesignet. Struktureringen er vigtig for den videre udvikling af systemet, da den giver et begreb om hvordan komponenterne skal hænge sammen og hvordan de arbejder sammen i helheden. Begge afsnit indeholder hvert et kommenteret diagram over henholdsvis komponenter og processer. Endeligt forekommer en oversigt over standarder der anvendes i designøjemed Faktorer i sammenhæng med designkriterier I sammenhæng med de tidligere nævnte designkriterier og prioriteringen af disse (tabel 2.1), er der valgt nogle faktorer, som spiller ind, i mere eller mindre vigtig grad, i udviklingen og implementeringen af systemet. En af argumenterne for at vælge en faktor er, at den bærer en potentiel risiko for problemer, enten i udviklingsøjemed eller i brugen af systemet. Dette skal der tages højde for tidligst muligt i udviklingsfasen. Faktorerne er arrangeret i tabel 2.2, og afspejler overvejelser om de nævnte faktorer. Tabellens hensigt er, at give indblik i hvilke faktorer der kommer til at spille ind i udviklingen og brugen af systemet, for at modvirke eventuelt kommende problemer og ulejligheder. Første søjle i tabellen navngiver faktoren, mens anden søjle opsamler de kvalitetskriterier der måtte være og som skal overholdes, før systemet kan betegnes som succesrigt. Tredje søjle indikerer hvorvidt kriterierne er fleksible, mens fjerde søjle diskuterer, hvilken virkning det vil have for brugen af systemet, hvis målet ikke er opnået. Dette leder videre til den egentlige vigtighed af faktoren og hvor stor risikoen eller sværhedsgraden er i sammenhæng med implementation. I de to sidstnævnte søjler, er hver faktor angivet med enten et H (Høj), et M (Medium) eller et L (Lav). Årsagen til at alle faktorer er markeret med høj vigtighed i faktortabellen er, at det er de vigtigste faktorer der er bragt med i tabellen, hvilket selvsagt bevirker, at de markeres med høj vigtighed. Med hensyn til risiko/sværhedsgraden er det en overvejelse om, hvad risikoen er i udviklingen af den enkelte faktor, i sammenhæng med hvor svært det er at implementere. Begrundelsen for at to af faktorerne er markeret med M/H og L/M er, at den generelle udvikling af den enkelte faktor har en vis sværhedsgrad, hvis det er et almindeligt arbejdsområde for udvikleren, eller at udvikleren har erfaring med det. I dette projekts tilfælde er det imidlertid således, at der ikke forefindes erfaring inden for de pågældende områder; Persistens og grafisk brugergrænsefladeprogrammering. Udover faktortabellen opskrives en teknisk memo. Denne består af reflektioner og undersøgelser af mulige alternative løsninger og beslutninger, om korrekt generering af turneringsplaner. Den tekniske memo bruges til opstilling af vigtige problematikker og beslutninger. Den tekniske memo om Korrekt generering af turneringsplaner kan ses i nedenstående tabel

47 Faktorer i sammenhæng med designkriterier 35 Tabel 2.2: Tabel over faktorer, overvejet i sammenhæng med udvikling eller implementering af systemet. Faktor Mål og kvalitetsscenarie Fleksibilitet Virkning Vigtighed Risiko / Sværhedsgrad Korrekt turneringsplan Når systemet testes: - Et hold kan ikke møde sig selv. - Alle hold skal have mulighed for at komme i finalen. - Regler for turneringstyperne overholdes. - Et hold kan kun spille en kamp pr. runde. - Automatisk turneringsplanlægning. Persistens Hvis systemet lukkes ned med vilje eller ved en fejl, må systemets data ikke gå tabt. Når programmet startes igen, skal dataene stadig være tilgængelige for programmet. Brugbart Målet er at systemet har en grafisk brugergrænseflade med ensartet forståelse af de enkelte begreber, såsom ( Ok -, Annuller -knapper og lign.) Kravene skal gælde for alle turneringstyper. Det skal være nemt at udvikle understøttelse for nye datakilder, som eksempelvis databaser. I tilfældet med databaser, er det vigtigt at håndtere dataene atomart. Brugergrænsefladen skal være fleksibel i den forstand, at der skal være mulighed for at tilføje nye elementer til formen, ved ønske om opdatering af systemet. Hvis turneringsplanen ikke er korrekt er programmet ikke brugbart, og det skaber utilfredshed blandt deltagerne og crew. Hvis ikke der er automatisk planlægning, så er formålet med systemet tabt. Hvis der ikke er persistens og programmet går ned, mistes alt data. Hvis ikke der er en GUI er det svært for brugeren at betjene systemet. Det er endvidere svært at få et ordentligt og overskueligt overblik over turneringsplanen. H H H M/H H L/M

48 36 Kapitel 2. Design dokumentation Teknisk Memo: Korrekt generering af turneringsplaner Opsummering af løsning: Superklassen turnering genererer turneringsplanen for den givne type, ud fra hvilken subklasse turneringstypen er defineret til at være. Hvis reglerne for den givne turneringstype ikke kan overholdes, returnere subklassen ikke en turneringsplan, men kaster derimod en exception/fejl. Faktorer der indgår: 1. Korrekt Turneringsplanlægning. Løsning: Der skal laves en superklasse, som indeholder de generelle regler, der gør sig gældende for alle turneringsformer. Nogle af de regler som er fælles for alle turneringer er, at et hold ikke kan møde sig selv, og ikke kan deltage i mere end én kamp pr. runde. Udover superklassen skal der laves en række subklasser, som kan generere en turneringsplan ud fra de generelle og specialiserede regler. Motivation/Begrundelse: Grunden til at have en superklasse, som samler alle turneringstyperne, er at samle de generelle regler, som gælder for alle turneringstyper. Ved at samle de generelle regler i en superklasse, og specifikke turneringstyper i individuelle subklasser, bliver klasserne mere simple og overskuelige, samtidigt bliver det lettere at implementere flere turneringsformer. Uløste problemer: Der er ingen uløste problemer i denne sammenhæng. Alternativer, der har været overvejet: En anden mulighed er at benytte en klasse som håndterer alle turneringerne og som indeholder alle de forskellige turneringstyper. En sådan klasse ville blive ualmindeligt stor og uoverskuelig, samtidigt ville der blive en del variabler, som ville blive instantieret, uden at blive brugt. Endnu en mulighed er at have reglerne for de forskellige turneringstyper liggende i eksterne filer, og så inkludere dem når de skal bruges, denne løsning giver dog en del ekstra læsning fra persistenslaget, endvidere stiger risikoen for program fejl, hvis en given fil ikke findes, eller den på en eller anden måde er blevet beskadiget Generiske design beslutninger Generiske design beslutninger er en form for generelle beslutninger omkring design af systemer, der går igen igennem forskellige ensartede systemer. Disse generiske beslutninger anvendes over hele systemet. I det aktuelle system er der en række generiske designbeslutninger der gør sig gældende. Disse bliver beskrevet som følger: Tekstinput: I systemet er der nogle situationer, som kræver at brugeren skal udfylde tekstfelter for enten at oprette eller opdatere noget. Dette kunne f.eks. være når brugeren ønsker at oprette sig i systemet, så skal der indtastes navn, brugernavn, og kodeord. Der vil i disse situationer altid blive benyttet tekstbokse, til at modtage denne input fra brugeren. Trykknap: Her er der tale om designet af knapperne i formene, der vil være placeret på samme måde. En Annuller -knap vil være at finde nederst til venstre på forms, mens der nederst i højre hjørne vil være en eller to andre knapper. Disse ændrer sig alt

49 Komponentarkitektur 37 afhængigt af om systemet befinder sig i en kæde af forms, hvis brugeren skal kunne returnere til den forrige form, vil der findes en Tilbage -knap, hvis det er muligt at gå videre, efter en indtastning, vil der være en næste -knap. Endeligt, hvis brugeren befinder sig på den sidste form i en kæde, inden der gemmes data til systemet, vil Næste -knappen, i stedet være en Gem -knap, hvis systemet har valideret det indtastede til at være korrekt data. Bekræftelse: Hver gang der er tale om at en bruger skal gemme, ændre eller slette data i systemet, vil systemet altid spørge efter en bekræftelse. Alt afhængigt af hvilken type manipulation der er i gang, vil systemet bede brugeren om at checke de indtastede data og bekræfte, eller spørge om brugeren er sikker i sin sag, før der ændres eller slettes. Browsing: Måden at finde frem til den ønskede turnering, er ved at browse sig igennem de oprettede turneringer, hvor der herefter er mulighed for at tilmelde sit hold, eller hvis en crew er logget ind, er der mulighed for at redigere eller oprette en ny turnering Komponentarkitektur Systemets komponentarkitektur er lagdelt, og består af fire hovedkomponenter. Disse hovedkomponenter udgør hver især brugergrænseflade, funktion, model og persistens. Brugergrænsefladekomponenten udgør klasserne i brugergrænsefladen. I brugergrænsefladen er det muligt at foretage metodekald ned i grundarkitekturen til funktionskomponenten. Metoderne bliver kaldt, når brugeren foretager sig noget i programmet. Funktionskomponenten modtager metodekald fra brugergrænsefladen, og sørger for at behandle denne forespørgsel. Dette omfatter at foretage de rigtige metodekald til modellaget og persistenslaget på de rigtige tidspunkter. Funktionslaget kan opfattes som det lag, der styrer flow et i systemets brugsmønstre. Funktionslaget kan kalde persistenslaget, hvis en hel samling af objekter skal indlæses fra persistenslaget. Modelkomponenten bruges til at modellere systemets problemområde, og kald til denne komponent kommer fra funktionskomponenten. Metoderne der kan kaldes på modelkomponenten sørger for at gemme, hente eller validere data. Når komponentents data er blevet opdateret, kan komponenten sende et metodekald til persistensen, om at modellen skal gemmes. Til lagring af data bruges persistenskomponenten. Denne kan modtage metodekald fra funktions- og modellaget, men kan ikke sende metodekald til andre komponenter. Persistenskomponenten kan sende data til en datakilde, der eksempelvis kan være en database eller én til flere filer. Denne lagdelte arkitektur er illustreret i figur 2.2. Komponentlagene er uddybet med, hvilke klasser de hver især indeholder i afsnit 2.4. SubTournament -klassen kan indeholde flere forskellige typer af turneringer, f.eks. single- eller double-elimination, alt efter hvilke plugins der er loadet. Det samme gør sig gældende med Persistence -klassen, hvor der alt efter hvilke plugins der er loadet, er forskellige persistensmetoder til rådighed. I samme afsnit er det også uddybet, hvilke funktioner de enkelte komponenter har ansvar for at udføre. De fire lag er vidt forskellige og har hver deres funktioner, derfor er de opdelt i de fire forskellige komponenter. Brugergrænsefladen er programmet udadtil og under udviklingen af denne, benyttes hovedsageligt.nets kontrolelementer. Funktionslaget sørger for at de tidligere nævnte brugsmønstre bliver fulgt rigtigt, ved at foretage de rigtige kald til modelog persistenslaget på de rigtigt tidspunkter. Modellaget bruges til at håndtere de data, der kun bruges til at repræsentere det problemområde der administreres. Til at gemme modellaget og senere indlæse det igen, benyttes persistenslaget.

50 38 Kapitel 2. Design dokumentation Brugergrænseflade SubscribeUser Login TournamentDetails Browser FindPlayer SubscribeTeam Funktion UserController TournamentController Plugins TeamController SeatController Random Config Model UserCollection SeatCollection TournamentCollection MatchCollection RoundCollection SubTournamentCollection User Seat Tournament Match Round SubTournament Persistence Persistens Database Fil Fil Filer Figur 2.2: Grundkomponentarkitektur for system.

51 Eksemplariske design 39 Der eksisterer forskellige variationer af den lagdelte arkitektur, disse variationer består i, at der kan være en åben eller lukket arkitektur, eller en streng eller løs arkitektur. Her kan ses en beskrivelse af de fire: Åben eller lukket: En åben arkitektur betyder, at et givet lag kan anvende operationer fra alle lagene i systemet. En lukket arkitektur er derimod, at et givet lag, kun kan anvende operationer fra tilstødende lag i systemet. Streng eller løs: Ved en streng arkitektur kan et givet lag kun anvende operationer fra et underliggende lag. Med en løs arkitektur kan et givet lag anvende operationer fra både over- og underliggende lag. Ud fra disse fire kan der opstilles fire variationer af den lagdelte arkitektur, ud fra disse ønskes en lukket og streng arkitektur. Dette ønskes for at holde en simpel struktur, hvor hver komponent kun modtager og sender metodekald til én anden komponent. Dette gør det nemmere at udvikle systemet, og senere vedligeholde det. Rettes der i en komponent er det kun nabokomponenterne, der eventuelt skal ændres. Der er dog en enkelt undtagelse, og det er funktionskomponenten, der har mulighed for at kalde persistenskomponenten. Dette medfører at den anvendte arkitektur bliver til en åben og streng arkitektur Eksemplariske design Eksemplariske design indebærer en række eksempler på design fra systemet, både i form af beskrivende tekst (Hvordan designet bruges) og i form af billeder (screendumps) for at give et klart indtryk af den grafiske brugergrænseflade i systemet. Afsnittet indeholder udover brugsmønstre og screendumps også sekvensdiagrammer, som er den tekniske udgave af et brugsmønster. Først er mulighederne beskrevet i to tabeller med brugsmønsterbeskrivelser, for at give et klart indtryk af, hvilke muligheder der er i den grafiske brugerflade. Den beskriver både brugerens muligheder, men også hvilke handlinger systemet udfører, som funktion og respons på brugerens handling. Den uddybende forklaring af brugsmønstrene læses ved, at starte øverst i bruger-søjlen, og derefter læse teksten der står overfor, under system-søjlen. Derudover eksisterer der alternative handlinger fra brugeren og det systemet gør, dette står også overfor teksten ved den alternative handling fra brugeren. Dermed læses en handling fra brugeren over mod handlingen fra systemet, dette flow vil blive brugt igennem alle uddybende beskrivelser af brugsmønstrene som fremgår i rapporten. Efterfølgende findes screendumps af designet. Det er dermed idéen at skabe et overblik over brugerens interageringsmuligheder og hvordan systemet svarer på brugerens input. Screendumps hjælper samtidigt med at give et overblik over et givent brugsmønster. Endeligt forefindes et sekvensdiagram, som bringer det fulde overblik. Det giver den klare sammenhæng mellem brugsmønsterbeskrivelserne og de tilhørende screendumps. Ydermere bruges sekvensdiagrammet også, til at sammenkoble designet med funktioner og modeller, under systemets overflade. Det supplerer også med et overblik over, hvilke funktioner der kalder hvilke funktioner, for at finde det ønskede resultat. Eksempel på Tilmeld til computerparty Screendumps tilhørende brugsmønsterbeskrivelsen ses i figur 2.3. Figuren er delt op i skærmbillede (A), (B) og (C). Sammenhængen mellem de enkelte skærmbilleder vises ved hjælp af

52 40 Kapitel 2. Design dokumentation pile. En pil fra en knap til et vindue betyder, at vinduet kommer frem når der klikkes på knappen. Eksemplet som dækker over situationen, hvor en deltager ønsker at tilmelde sig computerpartyet. Kan enten ske over internettet, eller ved at vedkommende går hen til en af de opstillede computere, som kører systemet. I denne situation er det første brugeren ser, en login-skærm (A). På denne skærm skal der indtastes brugernavn og kode, men da deltageren i dette eksempel endnu ikke har en bruger i systemet, skal han først oprettes. Dette gøres ved at trykke på Tilmeld, og brugeren bliver bragt videre til et skærmbillede (B) med mulighed for indtastning af oplysninger, som er aktuelle for oprettelse af bruger. Her har brugeren også mulighed for at reservere en plads i systemet. Systemet kontrollerer, i henhold til en standard der er prædefineret, at felterne er korrekt udfyldt. Hvis dette er tilfældet, bliver brugeren præsenteret for et nyt skærmbillede (C) med de indtastede informationer. Hvis brugeren ønsker det, har han mulighed for at gå tilbage for at rette i de indtastede data. Accepterer systemet ikke det indtastede i alle felterne, bliver brugeren informeret om hvilke felter, der ikke er korrekt udfyldt, og har så mulighed for at rette i de tidligere indtastede data. Dette skærmbillede fremgår ikke som screendump i figuren 2.3, men er magen til (B) med en fejlmarkering udfor de felter med fejlindtastning som måtte forekomme. Brugsmønsterbeskrivelser for en deltager, som tilmelder sig et computerparty, ses i tabel 2.3. Bruger Brugeren klikker på knappen Tilmeld, der er placeret ved siden af knappen Login på loginskærmen, som illustreret på figur 2.3 (A). Udfylder formelementerne med de informationer der kræves. Deltageren kan tabbe sig igennem formelementerne. Klikker på knappen Næste, men man kommer kun videre hvis alle felter er udfyldt korrekt, ellers kommer der beskrivende fejl over hvad der mangler. System Viser en tilmeldingsformular, der er illustreret på screendump (B). Tilmeldingsformularen består af nogle formelementer, der skal udfyldes. Navn, brugernavn, adgangskoder og indtastes som en tekststreng i et tekstfelt, mens plads skal vælges i en dropdown-boks. I formelementet til at vælge plads er det muligt at vælge, at der ikke ønskes at reservere en plads. Nederst i skærmbilledet forefindes knapperne Annuller og Næste. Viser en bekræftelsesskærm, der er illustreret på screendumpet (C). Bekræftelsesskærmen består af tekstbokse, som ikke er mulige at skrive i, med de oplysninger som deltageren tidligere har indtastet. Desuden forefindes knapperne Annuller, Tilbage og Gem. Fortsættes på næste side...

53 Eksemplariske design 41 (A) (B) (C) Figur 2.3: Screendump tilhørende brugsmønsteret Tilmeld til computerparty Tabel 2.3 Fortsættelse fra forrige side. Bruger System Alternativ: Hvis de indtastede oplysninger ikke kan godkendes af systemet (eksempelvis to deltagere med samme brugernavn), vises tilmeldingsformularen igen, hvor de forkerte oplysninger er markeret med et rødt ikon. Desuden vil der forefindes en fejlbeskrivelse, hvis man holder musemarkøren over ikonet. Fortsættes på næste side...

54 42 Kapitel 2. Design dokumentation Tabel 2.3 Fortsættelse fra forrige side. Bruger Alternativ: Vælger Annuller. Klikker på knappen Gem. Alternativ: Klikker på knappen Tilbage. Alternativ: Klikker på knappen Annuller. Viser login-skærmen. System Tilmelder deltager til computerparty ved at gemme de indtastede oplysninger i systemets persistens. Viser tilmeldingsformularen med de tidligere indtastede oplysninger, så der kan rettes i dem. Viser login-skærmen. Tabel 2.3: Uddybende brugsmønsterbeskrivelse for Tilmeld til computerparty. På figur 2.4 er der opstillet et sekvensdiagram for brugsmønstret i tabel 2.3. Første søjle viser livslinjen for brugergrænsefladen. Denne sender en forespørgsel validateuserdata() til UserController en i funktionslaget, denne funktion bruges til at validere de indtastede data. UserController en starter med at bede persistenslaget kontrollere om det indtastede brugernavn allerede eksisterer med funktionen exist(), og derefter henter UserController en den ønskede plads fra persistensen med funktionen load(). Hvis brugeren ikke eksisterer i forvejen, valideres brugerdataene, det er f.eks. med hensyn til længder på strenge og tilladte tegn. For at validere userdataene kalder usercontroller en nogle statiske valideringsfunktioner i klassen User, det skyldes at klassen User har styr på, hvad en gyldig bruger skal indeholde. Desuden undersøges den hentede plads for, om den allerede er optaget. Resultatet af valideringen returneres i form af en bool, som indeholder status for valideringen. Eventuelle fejlmeddelelser er blevet tilføjet til et ErrorProviding objekt, til brugergrænsefladen, hvor der vises en bekræftelsesskærm eller en fejlskærm med fejlmeddelelser. Vælger brugeren at bekræfte de indtastede data, så kaldes funktionen createuser(). Funktionen createuser() starter med at undersøge om brugernavnet er blevet taget, dette gøres fordi en bruger med samme brugernavn kan være oprettet i mellemtiden. Hvis brugernavnet ikke er optaget, oprettes et nyt objekt af klassen User. Hvis brugeren har ønsket at reservere en plads, bliver pladsen og brugeren associeret med hinanden. Det nye User -objekt og det ændrede Seat -objekt bliver gemt i persistensen med funktionen save(). Eksempel på Tilmelding af hold til turnering I dette eksempel opleves situationen, hvor en bruger skal tilmelde sit hold til en turnering. Screendumps af design kan ses på figur 2.5. Det er en forudsætning at brugeren er logget ind i systemet. Det første brugeren bliver præsenteret for, efter login, er en turneringsbrowser (A). I denne browser vælges den ønskede turnering og brugeren trykker på knappen Tilmeld, hvilket åbner et nyt vindue (B). I det nye vindue skal holdnavnet samt brugernavnene på alle holddeltagerne udfyldes. Hvis brugeren, der nu er blevet holdkaptajn, ikke kan huske et brugernavn, kan vedkommende trykke på knappen med en lup, hvilket åbner et nyt vindue (C) hvor brugeren kan fremsøge et deltagernavn. Når det ønskede deltagernavn er fundet, kan det vælges, og brugeren trykker på Gem for at lukke søgevinduet og tilføje deltagernavnet til feltet. Efter holdkaptajnen har tilføjet holdnavn og samtlige holddeltagere, trykker han på næste, hvilket medfører åbningen af et nyt vindue, i form af en bekræftelsesdialog. Hvis systemet ikke accepterer det indtastede, eller hvis et eller flere felter ikke er korrekt udfyldt,

55 Eksemplariske design 43 Brugergrænseflade Funktion Model Persistens SubscribeUser:Form usercontroller:usercontroller :User :Persistence validateuserdata(...) exist(user, username) Bool load(out seat_obj, seat_id) Objekt validateuserdata(...) Bool ValidFeedback createuser() exist(user, username) Bool load(out seat_obj, seat_id) Objekt create(...) save(user, username) Bool save(seat, seat_id) Figur 2.4: Sekvensdiagram for brugsmønsteret Tilmeld til computerparty bliver holdkaptajnen igen præsenteret for indtastningsvinduet, denne gang med fejlmarkering ud for de felter der er fejl i. Brugsmønsterbeskrivelse for tilmelding af hold til en turnering, ses i tabel 2.4. Bruger Indtast loginoplysninger. Brugeren klikker på en turnering, som er åben for tilmeldinger. Der klikkes på knappen Tilmeld. System Logger deltageren ind i systemet. Viser en liste over turneringer, hvis status og nærmere oplysninger er beskrevet i en tabel. Turneringen bliver highlightet og en knap med teksten Tilmeld bliver tilgængelig. En tilmeld til turnering formular bliver vist på skærmen. Denne formular indeholder et tekstfelt, hvori brugeren indtaster et ønsket holdnavn, et tekstfelt hvori brugerens brugernavn står som værende holdleder, samt et antal tekstfelter til brugernavnene på yderligere hold medlemmer. Antallet af tekstfelter er bestemt ud fra det maksimale antal spillere på et hold. Fortsættes på næste side...

56 44 Kapitel 2. Design dokumentation (a) (b) (D) Bekræftelsesdialog (c) Figur 2.5: Screendump tilhørende brugsmønsteret Tilmeld hold til turnering Tabel 2.4 Fortsættelse fra forrige side. Bruger System Hvis der, ifølge indstillinger ved oprettelse af den givne turnering, er specificeret et interval for antallet af deltagere per hold, vil der blive vist asterisks ved de felter, som skal udfyldes, resterende felter må udfyldes efter ønske. Da det kan være svært for holdlederen at huske alle holdmedlemmernes brugernavne, kan holdlederen søge efter disse ved at klikke på knappen med luppen ud for det tekstfelt som ønskes udfyldt. Yderligere vil der blive vist en Annuller knap og en Næste knap. Fortsættes på næste side...

57 Eksemplariske design 45 Tabel 2.4 Fortsættelse fra forrige side. Bruger Alternativt: Der trykkes på Detaljer. Brugeren udfylder holdnavnfeltet med et ønsket holdnavn, samt udfylder andre obligatoriske felter med brugernavne på holdmedlemmer (efter aftale med disse deltagere), hvorefter der trykkes på Næste. Alternativt: Der trykkes på Annuller. Alternativt: Brugeren tilføjer et eller flere holdmedlemmer ved hjælp af lup - knappen. Der bliver altså trykket på lup - knappen udfor et givent tekstfelt. System En form med detaljer omkring turneringen bliver vist på skærmen. I formen kan man trykke på knappen Tilmeld, som gør det muligt at tilmelde turneringen fra to forskellige steder i programmet. Hvis Næste : Systemet kontrollerer først om alle de skrevne brugernavne eksisterer i systemet og om holdnavnet allerede er i brug, hvis enten brugernavnene ikke findes eller holdnavnet allerede er taget, vil det blive vist på formularen med en rød fejlmeddelelse(errorprovider). Dernæst kontrolleres at antallet af udfyldte felter svarer til det antal deltagere, som der kræves på et hold i denne turnering. Hvis ikke dette er tilfældet, vil det markeres for brugeren, at der kræves mindst et givent antal hold medlemmer. Hvis alt var som det skulle være, præsenteres brugeren for en oversigt over alle indtastede data (brugeren har ikke mulighed for at ændre i tekstfelterne på denne formular). Der tilføjes en Tilbage knap til formularen ud over Næste og Annuller. Hvis Annuller : Systemet glemmer alt hvad brugeren lavede siden brugeren klikkede på Tilmeld. Hvis tryk på lup -knap: En søgedialogboks kommer frem. I denne dialogboks er der øverst et søgefelt, hvori der kan indtastes en given streng, en Søg -knap til højre for søgefeltet og en resultattabel i midten af dialogboksen. Resultattabellen indeholder kun deltagere som ikke er tilmeldt turneringen. Nederst er der en Annuller - og en Gem -knap. Fortsættes på næste side...

58 46 Kapitel 2. Design dokumentation Tabel 2.4 Fortsættelse fra forrige side. Bruger System Brugeren indtaster et søgeord, som kan være et navn eller brugernavn, hvorefter der trykkes/klikkes på enter eller Søg -knappen. Alternativt: Brugeren trykker på Annuller - knappen. Efter at søgeresultaterne er blevet listet, kan brugeren nu vælge et af dem, ved et klik på rækken og tryk på Gem. Brugeren vælger en række og trykker Gem. Brugeren klikker på Næste - knappen. Hvis fejl: Brugeren udbedrer fejl og mangler i formularen, og trykker igen Næste og systemet kontrollerer på ny. Hvis ingen fejl: Brugeren beslutter om vedkommende er tilfreds med de tidligere indtastede oplysninger. Hvis dette ikke er tilfældet trykkes nu på Tilbage. Hvis brugeren er tilfreds med alle indtastede brugernavne, trykkes på Gem. Ønsker brugeren alligevel ikke at oprette et hold til turneringen trykkes på Annuller. Hvis Søg : Alle de brugere hvori søgestrengen findes, enten i navnet eller brugernavnet, vil blive vist usorteret i resultattabellen. Hvis Annuller : Et tryk på Annuller -knappen i søgedialogen vil blot lukke dialogen, hvilket leder brugeren tilbage til tilmeld til turnering -formularen, uden at have ændret i den. Systemet lukker omgående søgedialogboksen, og indsætter den valgte rækkes brugernavn i tekstboksen ud for lup -knappen, som der blev trykket på i screendumpet (B). Hvis Tilbage. Systemet fjerner knappen Tilbage, og gør det muligt for brugeren, igen at rette i felterne. Hvis Gem. Systemet opretter holdet persistent, og vender tilbage til listen over turneringer. Tabel 2.4: Uddybende brugsmønsterbeskrivelse for Tilmelding af hold til turnering. Sekvensdiagrammet for brugsmønstret i tabel 2.4 ses på figur 2.6. Diagrammet starter efter holdkaptajnen har valgt, hvilken turnering holdet skal tilmeldes og trykket på Tilmeld - knappen. Når holdkaptajnen har valgt en turnering, som holdet skal deltage i, præsenteres han for en række indtastningsfelter. Disse indtastningsfelter skal indeholde holdets navn og brugernavnene på holdmedlemmerne. Til indtastning af brugernavnene er der mulighed for at søge efter holdmedlemmerne. Af diagrammet ses det at brugergrænsefladen kalder FindPlayer() fra funktionslaget. Holdkaptajnen har mulighed for at søge efter et brugernavn, hvis han ikke er i stand til at huske det ønskede navn. Navnesøgningen foregår ved, at brugergrænsefladelaget sender en forespørgsel til funktionslaget med findusersfortournament(). Denne funktion sørger for, at

59 2.4. Komponenter 47 hente alle brugere fra persistensen og gemme dem i en UserCollection. Derefter fjerner den de brugere som allerede deltager i turneringen fra UserCollection en, og dem som ikke stemmer overens med søgeordet. Denne returneres så til findplayerscr formularen. Holdkaptajnen kan så vælge en deltager, som skal tilføjes til holdet og deltageren returneres til subscribescr formularen i form af en string. Når holdkaptajnen er færdig med at tilføje deltagere til sit hold og ønsker at oprette selve holdet, bliver funktionen validateteamplayers(), som tjekker om de indtastede holddeltagere eksisterer, ikke er på andre hold i samme turnering og lignende. Denne funktion returnerer en bool og en fejlmeddelelse, hvis der er sket en fejl. Så bliver funktionen validateteam- Name() fra TeamController en kørt uafhængigt af resultatet af validateteamplayers. Denne forespørger TournamentController en om at hente en bestemt turnering fra persistensen. Derefter bliver alle hold, der er med i turneringen hentet fra persistensen, for at tjekke om det valgte holdnavn allerede er taget i turneringen. Funktionen returnerer en bool og en fejlmeddelelse, hvis der er sket en fejl. Hvis der ingen fejl er forekommet, kalder brugergrænsefladen funktionen createteam() fra funktionslaget. Først bliver validateteamplayers() og validateteamname() kørt igen for at tjekke at deltagerne og holdnavnet ikke er blevet optaget i mellemtiden. Hvis dette er okay, bliver holdet oprettet og gemt i persistensen med funktionen save(), derefter bliver turneringen loadet og associeret med holdet. 2.4 Komponenter I dette afsnit gives en beskrivelse af model-, funktions-, persistens- og brugergrænsefladekomponenterne. Afsnittet fungerer som en liste af alle systemets komponenter. Listen indeholder, for hver komponent, hvilken struktur komponenten har, hvilke klasser der er berørt og en række aktuelle beskrivende informationer om selve den enkelte komponent Brugergrænsefladekomponenten Som beskrevet i komponentarkitekturen består det øverste lag i systemet af brugergrænsefladekomponenten. Til udviklingen af systemet benyttes.net framework et, og dette har stor betydning for brugergrænsefladen i programmet. I.NET er der udviklet klasser, der er beregnet til at skabe brugergrænseflader til programmer. Nogle af disse klasser vil blive brugt til at lave systemet. Der vil ikke blive udviklet nye klasser til brugergrænsefladekomponenten, kun de allerede eksisterende vil blive benyttet. De klasser, der vil blive brugt i brugergrænsefladen, ligger i klassebiblioteket til.net under navnerummet System.Windows.Forms. Dette klassebibliotek indeholder eksempelvis klasser til at lave vinduer, dialogbokse og mange andre kontrolelementer. Disse klasser med deres metoder bliver ikke listet her, da de ikke er programmeret og lavet specifikt til dette system, men derimod konstrueret til alle former for systemer, som ønsker at benytte en grafisk brugergrænseflade. Derudover kan Windows.Form s ses i en komplet og velbeskrevet opstilling hos Microsoft R Developer Networks (MSDN R ) [9].

60 48 Kapitel 2. Design dokumentation Brugergrænseflade Funktion Model Persistens subscribescr:form findplayerscr:form :TeamController :TournamentController :UserController :Team tournament:tournament :Persistence new FindPlayer(...) findusersfortournament(...) gettournament(id) load(out Tournament, tournament_id) Tournament :Tournament loadallusers() loadall(usercollection) UserCollection UserCollection load(out Team, team_id) foreach(team_id in Tournament) :Team :UserCollection string validateteamplayers(...) bool validateteamname(...) bool createteam(...) loadallusers() UserCollection gettournament(id) Tournament foreach(team_id in Tournament) validateteamplayers(...) validateteamname(...) new Team(...) Team gettournament(id) Tournament loadall(usercollection) UserCollection load(out Tournament, tournament_id) :Tournament load(out Team, team_id) :Team save(team) team_id load(out Tournament, tournament_id) :Tournament Team_list.Add(team_id) savetournament(...) bool save(tournament, tournament_id) Figur 2.6: Sekvensdiagram for brugsmønsteret Tilmeld hold til turnering Præsentationsmodel Her er præsentationsmodellen for systemet beskrevet. Præsentationsmodellen giver et indblik i hvilke interaktionsmodeller/klasser, der er i systemet og indikerer hvad den enkelte klasse indeholder af muligheder for brugeren. Herunder ses en liste over forms i systemet: - Login: Giver mulighed for at logge ind i systemet via brugernavn og adgangskode. - Browser: Viser en oversigt over eksisterende turneringer. - SubscribeUser: Bruges ved oprettelse af nye brugere.

61 Brugergrænsefladekomponenten 49 - SubscribeTeam: Gør det muligt at specificere et hold, og tilmelde det til en given turnering. - FindPlayer: Viser en liste over eksisterende brugere i systemet. - TournamentDetails: Viser detaljerede oplysningerne om den valgte turnering. - StringEditor: En lille editor der kan bruges til at redigere i en samling af teksstreng. - StringMultilineEditor: Bruges til at ændre en tekststreng hvis denne indeholder linjeskift. - TeamDetails: Giver brugerne et overblik over et hold, eksempelvis hvilke spillere der er på holdet. - TournamentDetails: En form der viser alle nødvendige informationer om en given turnering. - Draw: Indeholder funktionalitet til at lave et slideshow over igangværende turneringer. Dette kan eksempelvis vises på en form for fremviser. I hver form er der en række forskellige interaktionselementer, som knapper, inputfields og lign. I diagrammet med systemets komponentarkitektur (figur 2.2), ses sammenhængen mellem de forskellige forms. Interaktionselementer Her er det enkelte interaktionselement beskrevet, med en kort information om, hvordan de fungerer og hvad de gør samt information om hvilke brugsmønstre elementet bruges i. Herunder følger en oversigt over de interaktionselementer, som kan findes systemet. Button Interaktionsform: Klik med musen, eller markeres via [Tab] og aktiveres via [Enter] eller [Space]. Udseende: Standard knap udseende. Bruges i brugsmønstrene: Alle. TextBox Interaktionsform: Markeres ved klik med musen, og input skrives med tastaturet, eller indsættes fra udklipsbogen. Udseende: Hvidt rektangel med en sort kant. Bruges i brugsmønstrene: Alle.

62 50 Kapitel 2. Design dokumentation DataGridView Interaktionsform: Rækker, søjler eller celler markeres med musen eller piletaster. I tilfælde af at der kan ændres i det markerede felt, kan dette gøres ved at taste de ønskede data ind. Udseende: Tabel med søjler. Bruges i brugsmønstrene: Tilmeld hold til turnering. TabControl Interaktionsform: Et ønsket faneblad vælges med klik på fanebladet. Udseende: Panel indeholdende andre interaktionselementer med faneblade. Bruges i brugsmønstrene: Tilmeld hold til turnering. ComboBox Interaktionsform: Der kan vælges et element i en liste, ved at klikke på pilen til højre for det hvide felt, hvorefter det ønskede element, kan vælges. Alternativt kan feltet markeres og piltasterne kan frembringe det ønskede element. Udseende: TextBox lignende felt, med en pil der peger ned. Bruges i brugsmønstrene: Tilmeld til computerparty. ContextMenu Interaktionsform: Steder hvor en contextmenu findes, kan den frembringes ved at højreklikke med musen, i den del af formen der et tildelt en contextmenu. Udseende: Menu der kommer frem, hvor musenarkøren er, når der højreklikkes. Bruges i brugsmønstrene: Tilmeld hold til turnering. DomainUpDown Interaktionsform: Ved hjælp af to knapper er det muligt at forøge eller forminske den numeriske værdi i tekstfeltet. Udseende: Et tekstfelt med to knapper. Bruges i brugsmønstrene: Opret turnering (til at vælge antal spillere der kan gå videre fra hver delturnering).

63 Funktionskomponent 51 ErrorProvider Interaktionsform: Elementet fremkommer ved andre kontrolelementer, hvis indholdet er forsøgt gemt, og det ikke har været gyldig. Fejlbeskrivelse kan ses ved at føre musen over objektet. Udseende: En rød cirkel med et hvidt udråbstegn i. Bruges i brugsmønstrene: Alle hvor data skal kunne gemmes Funktionskomponent Funktionskomponenten er placeret mellem brugergrænsefladekomponenten og modelkomponenten, dette er illustreret på figur 2.2. Funktionskomponenten er en samling af klasser med operationer, der ikke umiddelbart kan integreres i modelkomponentensklasser. Dermed er funktionskomponentens centrale egenskab at skabe funktionalitet til modellen ved ikke at sammensætte funktion- og modeldelen. Disse operationer behandler enten selv funktionskaldene fra brugergrænsefladekomponenten eller sender dem videre til modelkomponenten eller persistenskomponenten. Klasser Funktionskomponenten består af forskellige klasser, som udfører funktioner til modellaget, disse klasser er listet nedenunder med tilhørende beskrivelse af formål, attributter og operationer: UserController Formål: At håndtere oprettelse af brugere, herunder kontrollere de indtastede data, logge brugere ind i systemet, hente/gemme UserCollections. Attributter: Ingen attributter. Operationer: login, validateuserdata, createuser, validateusername, validateseat, load- User, saveuser, loadallusers, updateuser. SeatController Formål: At håndtere opdatering af pladserne, hente/gemme SeatCollections og hente/gemme Seats. Attributter: Ingen attributter. Operationer: loadseat, saveseat, loadallseats, saveallseats.

64 52 Kapitel 2. Design dokumentation TeamController Formål: At håndtere oprettelse af hold, herunder kontrollere de indtastede data, tilmelde til turneringer og hente/gemme TeamCollections. Attributter: Ingen attributter. Operationer: validateteamplayers, validateteamname, createteam, getteam, saveteam. TournamentController Formål: At håndtere oprettelse og generering af turneringer, herunder kontrollere de indtastede data, hente/gemme turneringer. Attributter: Ingen attributter. Operationer: createtournament, subscribeteam, unsubscribeteam, addsubtournament, removesubtournament, generatetournament, starttournament, isteamactive, gettournament, getalltournaments, savetournament, reportresult. ValidFeedback Formål: En generisk type, der fortæller om en funktion bliver udført succesfuldt, yderligere indeholder typen også en beskrivelse af hvad der gik godt eller dårligt. Attributter: bool status_value, string status_message. Operationer: Status, Message. Random Formål: At generere et tilfældigt tal og blande en liste. Attributter: Random random, Random thisinstance. Operationer: Instance, Next ScrambleCollection<T>. Plugins Formål: At indlæse plugins, så de kan bruges i systemet. Attributter: List<Type> type_list. Operationer: getplugins<t>, loadassemblies Modelkomponenten Modelkomponenten er en samling af de klasser, som udgør de objekter og data, som systemet har til formål at holde styr på. Designklassediagrammet kan findes på den vedlagte CD under: Rapport rightarrow Bilag rightarrow Design_Klassediagram.pdf. Designklasse-

65 Modelkomponenten 53 diagrammet over modelkomponenten er baseret på klassediagrammet og adfærdsmønstrene fra analysedokumentet. Som nævnt i beskrivelsen af komponentarkitekturen er det muligt at bruge plugins i systemet. Denne funktionalitet bliver brugt i modelkomponenten, idet det er muligt at lave nye turneringsformer til systemet. User Formål: Indkapsler brugerdata, som brugernavn, navn og -addresse. holder også informationer om hvad et valid brugernavn er, ligeså med . Attributter: string username, string name, string , string password, userlevel type, bool paid, int reserved_seat. Operationer: reserveseat, validateusername, validatename, validate . Seat Formål: Udtrykker eksistensen af en plads i problemområdet, indeholder information om hvilket bord, hvilken plads ved bordet, og hvilken bruger der har reserveret pladsen. Attributter: int table, int seat, string username. Operationer: reserveseat, Reserved. Tournament Formål: Holder styr på alle data omkring en turnering samt referencer til tilmeldte hold og genererede runder. Attributter: int tournament_id, int next_subtournament_to_run, int max_teams, min_teams, int max_teamplayers, min_teamplayers, DateTime start_time, Date- Time end_time, int round_time, string tournament_name, string game, string description, Collection<String> prizes, Collection<String> maps, Collection<int> team_list, Collection<int> subtournament_list, bool team_subscription_closed. Operationer: isteamsubscribed, istournamentfull, subscribeteam, unsubscribeteam, isusersubscribed, existsubtournament, addsubtournament, removesubtournament, starttournament, commitresult, startnextsubtournament, initsubtournaments, is- TeamActive, IsCaptainOnTeam, closeteamsubscription. Team Formål: Grupperer en række brugere sammen, for derefter at kunne linke holdobjekter til turneringen. Attributter: string team_name, string team_leader_name, ICollection<string> team_members, int max_members, int min_members. Operationer: validateteammember, insertuser, replaceuser, removeuser, Team_members, Team_name, Team_leader_name.

66 54 Kapitel 2. Design dokumentation Round Formål: Holder styr på planlagte kampobjekter. Attributter: string map, Collection<int> matches. Operationer: indexofteam, addmatch, removematches, getmatch. Match Formål: Refererer til to eller flere hold, og giver udtryk for en kamp mellem disse hold. Attributter: Dictionary<int, int?> teams, int? team_id_of_winner. Operationer: indexofteam, removeteams, getteam. Collections Formål: At indkapsle objekter af sammetype. Typer: TeamCollection, UserCollection, RoundCollection, SeatCollection, Tournament- Collection, MatchCollection. Operationer: add, remove, TryGetValue Persistenskomponent Under afsnit 2.2 omhandlende komponentarkitektur er der i figuren for grundarkitekturen vist, at systemet skal have en persistenskomponent. Denne komponent ligger mellem modelkomponenten og den egentlige persistens, hvad enten dette er serialiserbare filer, en databaseløsning eller noget helt tredje. Det er meningen at persistenskomponenten skal sørge for at kunne give modellen persistens, og det skal være forholdsvist simpelt, at kunne udskifte hvordan data reelt bliver gemt. Det er derfor vigtigt at have en lav kobling mellem persistenskomponenten og den reelle måde hvorpå data gemmes. Persistenskomponenten skal derfor indeholde alle de komponenter, der har med handlingen; at gemme data, at gøre. De klasser, der indeholdes her, har derfor ikke andre funktioner end at gemme eller hente data fra enten en database, serializables eller en helt tredje måde at lave persistens på. Det er klart den mest optimale løsning, at benytte sig af en database, til at lagre data i, men systemet vil blive implementeret således, at det benytter plugins til at afgøre, hvordan data skal lagres. Det plugin, der bliver implementeret til dette system, benytter en fil-serializer. Dette betyder, at systemet gemmer og læser til og fra filer. En senere videreudvikling af systemet, kan resultere i et nyt database-plugin, der kan lagre data i eksempelvis en MySQL database. Persistence Formål: At være persistenslagets interface udadtil til andre lag der vil kalde persistenslaget. Denne delkomponent sørger for at andre lag kan kalde gemme- og hentefunktioner, der håndterer det videre forløb for data i persistenslaget. Attributter: string root_path. Operationer: save, saveall, load, loadall, exist, remove, serialize, deserialize.

67 2.5. Anbefalinger 55 Ideen er så, at der kan udvides med andre metoder, som Persistence kan kalde alt afhængigt af hvilke persistensmuligheder, der findes og der er integreret i systemet. For at skifte til en anden form for persistens, skal der kodes et plugin, som implementerer interfacet ISerializer. 2.5 Anbefalinger Opsamlingsvis indeholder dette afsnit anbefalinger til det efterfølgende udviklingsarbejde. Afsnittet indeholder en begrundet plan for det videre udviklingsarbejde. Dette indbefatter en sammenfattende vurdering af designets relation til omgivelserne, baseret på de opstillede kvalitetsmål. Ydermere forefindes en anbefalet plan for ibrugtagning af systemet. Denne plan leder videre til en egentlig implementeringsplan. Implementeringsplanen estimerer ressourceog tidsforbruget for udviklingsarbejdet Systemets nytte De elementer, der er prioriteret vigtigst i kvalitetsmålene er, at systemet skal være brugbart, korrekt, pålideligt og forståeligt, som ses i tabel 2.1. Disse kvalitetsmål skal overholdes under udviklingen af systemet, for at opretholde dets nytte. Under hele systemudviklingen er det vigtigt at holde det sammen med hele tabellen for kvalitetsmålene, for at sikre systemets nytte og holdbarhed. Ved at sikre at kvalitetsmålene er overholdt, sikres systemet også i henhold til omgivelserne, eftersom kvalitetsmålene er overvejet i henhold til hvilke krav der stilles til systemet, af omgivelserne Plan for ibrugtagning Med hensyn til ibrugtagning af systemet, er det planlagt, at der efter systemudviklingen, bliver afholdt et computerparty der strækker sig over et par dage. Herudover er det frit tilgængeligt, hvis der senere er et ønske om ibrugtagning. For at bruge systemet er det blot nødvendigt at have en computer, inklusiv tastatur og mus, med en form for storskærm tilsluttet, for at få fuldt udbytte af systemet Implementeringsplan Opsamlingsvis er det aktuelt med en implementeringsplan, til at give et overblik over aspekter der er overvejet i analyse- og designdokumentationen. Implementeringsplanen er derfor de anbefalinger til implementationen, som er fremkommet gennem overvejelser igennem afsnittene. En af de vigtigste overvejelser til implementationen, er de faktorer som har indflydelse på systemet. Faktortabellen (tabel 2.2 indeholder overvejelser om risici og sværhedsgrad i implementationsøjemed. Den udtrykker også vigtigheden af at den enkelte faktors mål og krav bliver opfyldt. Faktortabellen giver dermed klart udtryk for hvilke faktorer, der kommer til at have et højt ressourceforbrug i implementeringen. Med hensyn til tidsforbruget af implementationen, er det på forhånd fastlagt hvornår projektet skal afleveres, dermed er der en klar deadline som skal overholdes, denne deadline gælder også for implementationen. Deadline for projektet er d. 21. december 2006, og det betyder at implementationen skal være færdig i god tid, så der er mulighed for de nødvendige tests af det implementerede system.

68 56 Kapitel 2. Design dokumentation 2.6 Programmering Dette afsnit behandler problematikken om, hvorvidt design/arkitektur er implementerbart. Der er vedlagt udvalgte kodeeksempler svarende til dele af designet, så sammenhængen mellem design og implementering kan vurderes, for at eftervise realiserbarheden af designstrukturen Implementerbarhed Systemet vurderes til at være implementerbart, da der ikke er stillet hverken urimelige eller urealistiske krav til udviklingen, eller systemets virke. Det skal fungere til en standard pc, med et tastatur og mus tilsluttet, samt en form for fremviser. Disse krav er alle realistiske at opfylde. Hvad selve udviklingen af systemet angår, er der ingen større krav til det og alle delene kan mere eller mindre enkelt blive udviklet i det objektorienterede programmeringssprog, C#, som er valgt til udviklingen. For at give eksempler på, at det er implementerbart kodemæssigt, forefindes der her et par kodeeksempler fra implementeringsprocessen Kodeeksempler Her forefindes implementerbare kodeeksempler til at underbygge implementerbarheden. De stammer fra persistenslaget og er en del af den plugin-løsning der er i systemet. Persistens, Serialize I kodeeksempel 2.1 ses et eksempel på kode fra systemet, der viser hvordan persistensens serialize funktion virker. 1 public s t a t i c void serialize <T>(T obj, string id ) 2 { 3 string path = ".\\ " + typeof ( T ). Name + " \\ " + id + ". dat " ; 4 FileStream fs = new FileStream ( path, FileMode. Create ) ; 6 try 7 { 8 BinaryFormatter bf = new BinaryFormatter ( ) ; 9 bf. S e r i a l i z e ( fs, obj ) ; 10 } 12 catch ( S e r i a l i z a t i o n E x c e p t i o n e ) 13 { 14 C o n s o l e. W r i t e L i n e ( " Failed to serialize. Reason : " + e. M e s s a g e ) ; 15 throw ; 16 } 18 f i n a l l y 19 { 20 fs. C l o s e ( ) ; 21 } 22 } Kodeeksempel 2.1: Kodeeksempel på at gemme i persistenslaget Linje 1-2: Metoden laves public, da alle controller-klasser skal have mulighed for at kunne gemme data. For at gøre metoden nem at bruge, uden at den overordnede klasse først skal initialiseres, gøres metoden statisk. Eventuel fejlhåndtering foregår, ved at teste, om der har været en exception, så derfor returneres der ikke nogen statusbesked. Metoden kan tage et hvilket som helst input af typen object. Ydermere modtager den et argument id i form af en tekststreng.

69 Kodeeksempler 57 Linje 3: Der oprettes en path (dansk: sti), hvor filen skal gemmes. Denne sti findes ud fra navnet på typen af det modtagne objekt, med.dat som filtypen. Linje 4: Der åbnes en FileStream, der skal bruges til, at gemme det modtagne objekt på den oprettede sti. Hvis filen ikke eksisterer, skal filen oprettes. Linje 6-10: Der oprettes et objekt af typen BinaryFormatter, der bruges til at skrive binært til en fil. Metoden Serialize kaldes, og den tager to parametre: FileStream der gør det muligt at skrive en fil til disken, og det objekt der skal gemmes. Linje 12-16: Der kontrolleres om der er opstået en fejl, og hvis dette sker, udskrives der en fejlbesked. Denne fejlbesked bruges kun til debugging, da den ikke er mulig at se i brugergrænsefladen. Fejlen sendes videre, så andre kan håndtere denne og vise en fejlbesked til brugeren. Linje 18-21: Uanset om der opstår en fejl eller ej, skal FileStream ikke længere bruges og den lukkes derfor. Funktioner, Random I kodeeksempel 2.2 kan ses et eksempel fra klassen Random, som kan generere tilfældige heltal, samt blande elementerne i en Collection. Klassen er en singleton, hvilket vil sige at klassen er konstrueret efter et designmønster, der gør at klassen højest kan instantieres én gang, hvilket er en fordel når man vil have tilfældige tal. Hvis man kunne instantiere flere Random klasser, ville de alle komme med den samme tilfældige talfølge, hvilket er meget uhensigtsmæssigt. 1 public c l a s s R a n d o m 2 { 3 private System. Random random ; 4 private s t a t i c R a n d o m t h i s I n s t a n c e = null ; 6 private Random ( ) 7 { 8 t h i s. r a n d o m = new S y s t e m. R a n d o m ( ( int ) D a t e T i m e. Now. T i c k s ) ; 9 } 11 public s t a t i c R a n d o m I n s t a n c e ( ) 12 { 13 i f ( t h i s I n s t a n c e == null ) 14 Random. thisinstance = new Random ( ) ; 15 return thisinstance ; 16 } 18 public int Next ( int lower, int u p p e r ) 19 { 20 return this. random. Next ( lower, upper ) ; 21 } 23 public s t a t i c Collection <T> ScrambleCollection <T>( Collection <T> collection ) 24 { 25 Collection <T> collection_ copy = new Collection <T >() ; 26 C o l l e c t i o n <T> s c r a m b l e d _ c o l l e c t i o n = new C o l l e c t i o n <T >() ; 27 foreach ( T item in c o l l e c t i o n ) 28 { 29 collection_ copy. Add ( item ) ; 30 } 31 while ( collection_ copy. Count > 0) 32 { 33 int r a n d o m _ n u m b e r = I n s t a n c e ( ). Next ( 0, c o l l e c t i o n _ c o p y. C o u n t ) ; 34 s c r a m b l e d _ c o l l e c t i o n. Add ( c o l l e c t i o n _ c o p y [ r a n d o m _ n u m b e r ] ) ; 35 c o l l e c t i o n _ c o p y. R e m o v e A t ( r a n d o m _ n u m b e r ) ; 36 } 37 return s c r a m b l e d _ c o l l e c t i o n ; 38 } 39 }

70 58 Kapitel 2. Design dokumentation Kodeeksempel 2.2: Kodeeksempel for Random klassen Linje 1-2: Klassen laves offentlig, da alle andre klasser skal have muligheden for, at kunne kalde metoderne i den. Linje 3-4: Members som henholdsvis skal indeholde en instans af frameworkets indbyggede Random klasse, og indeholde en instans af denne klasse. Linje 6-9: Private constructor som instantierer frameworkets Random klasse. Randomklassen bliver seedet med antal ticks (en lille tidsenhed) siden programmet blev startet. Metoden er privat da det kun er klassen selv, der må lave en instans af sig selv. Linje 11-16: Denne offentlige statiske metode returnerer en instans af klassen. Ideen er her, at hvis klassen ikke er blevet instantieret, så gør denne metode det, og gemmer instansen. Når metoden senere kaldes, er det den samme instans der bliver returneret. Så der vil aldrig blive lavet to instanser af denne klasse. Linje 18-21: Denne offentlige metode benytter referencen til den indbyggede Randomklasse, til at generere et heltal mellem lower og upper inklusiv lower. Hvis man vil have et tal i intervallet 1 til 10 inklusiv enderne, skal man kalde metoden next(1, 11). Linje 23: ScrambleCollection er en generisk metode som tager en Collection<T> ind og returnerer en Collection<T>. T er her en såkaldt generisk type hvilket vil sige at den i metoden, bliver brugt præcist som var det en kendt type, eksempelvis typen string. Denne type kan selv gættes af programmet, ment således at hvis man giver metoden en Collection<int> som argument, vil metoden selv gætte at T skal substitueres med int. Dette tillader metoden at operere på alle forekomster af Collection<...> Linje 27-30: Kopierer elementerne/referencerne fra den modtagede collection over i en intern collection, for ikke at ændre på den modtagede collection. Linje 31-36: Så længe der er elementer i kopien af den modtagede collection, tag et tilfældigt element ud, og indsæt den i scrambled_collection<t> og fjern derefter elementet fra kopien. Linje 36: Returnerer scrambled_collection<t>, som nu indeholder alle elementerne i den modtagede collection, men i tilfældig rækkefølge. 2.7 Opsamling Formålet med dette afsnit har været at videreudvikle den viden, der er indsamlet under analysen, til et design. Grundlæggende er det blevet beskrevet: hvad formålet er med selve designfasen, hvilke designkriterier der gør sig gældende for systemet der skal udvikles, hvilken prioritering disse tolv kriterier har, samt hvilke rettelser og mangler der blev fundet i analysen, og hvordan disse er blevet udbedret. Desuden er den tekniske platform, som systemet tænkes udviklet til, blevet beskrevet mere detaljeret og udførligt. Dette indebærer blandt andet hvilket udstyr der er nødvendigt, og hvilket designsprog og platform der skal benyttes. Det designsprog der anvendes til dokumentation af programmet, er også blevet uddybet.

71 2.7. Opsamling 59 I afsnittet er der også, på baggrund af designkriterierne, beskrevet systemets arkitektur, samt hvilke faktorer der indgår i den. Faktorerne er opstillet i en tabel med yderligere beskrivelser, vurderinger, samt en uddybning af en faktor i et teknisk memo. Derudover er der beskrevet generiske designbeslutninger, der skal gå igen i designet af systemet. Herefter er der givet to eksempler på eksemplariske design af systemet, med en detaljeret beskrivelse af brugerens og systemets tænkte interaktion mellem hinanden. Dette indeholder også en grafisk afbildning af denne interaktion ved hjælp af screendumps. En grundig beskrivelse af systemets komponenter er at finde i dette afsnit. Denne forklarer først systemets grundarkitektur via komponentlag og komponentarkitektur. De enkelte komponenter er efterfølgende beskrevet i detaljer, hvor hver enkelt komponent, herunder brugergrænseflade-, funktions, model- og persistenskomponenterne, er listet med detaljer om, hvilke klasser de hver især indeholder, samt hvilke attributter og metoder disse klasser har. Endelig har afsnittet en vurdering af, hvordan det videre projektarbejde bør foregå. Disse anbefalinger er beskrevet i delafsnittene nytteværdi, ibrugtagningsplan, implementeringsplan og implementerbarhed. Selve implementerbarheden af systemet er yderligere understreget i udvalgte kodeeksempler fra det designede system.

72

73 Kapitel 3 Implementering Implementeringskapitlet indeholder informationer om, hvordan de enkelte komponenter integreres og implementeres til et endeligt system. Processen, der er påbegyndt i analysen ER videreudviklet og uddybet ved i designdokumentet, er nu klar til at blive behandlet i implementatiosnsfasen, hvor systemet skal færdigudvikles. Normalt begynder denne fase først, når en eventuel kunde har godkendt de fremstillede brugsmønstre og de idéer, der blev udviklet under designfasen, eftersom disse ting danner grundlag for en videreudvikling og færdiggørelse af systemet. Indledningsvis indeholder dette kapitel nogle rettelser til designdokumentet, som først er blevet opdaget sent i designfasen. Herefter beskrives de værktøjer der er brugt i udviklingsprocessen og implementeringen. Implementeringsafsnittet behandler forskellige dele af programmet fra forskellige komponentlag. Dette gøres for at give et klart indtryk af opbygningen og sammenhængen af klasserne, samt de enkelte komponentlag. Opbygningen er tidligere beskrevet i designdokumentet, men de konkrete kodeeksempler, som gives i dette kapitel, er med til at underbygge denne. Grundlaget for implementeringen har primært været forelæsninger i OOP (Objekt Orienteret Programmering) samt enkelte forelæsninger om grafisk brugergrænseflade i DIEB (Design Implementering og Evaluering af Brugergrænseflader). 3.1 Fra Design til Implementering Nu da analyse- og designprocessen er afsluttet, er det muligt at påbegynde en egentlig implementering. Implementationsfasen består primært af udvikling af programmel, og derfor vil dette kapitel primært indeholde udsnit af den endelige programkode, samt en forklaring af den kontekst eksemplerne bliver brugt i Rettelser fra Designdokumentet Før systemet implementeres, bør det overvejes, om der fra designdokumentationen er nyovervejede rettelser til udviklingsprocessen. Dette gøres for at sikre den gennemgående kvalitet i den iterative faseopdelte udviklings model, som denne rapport er udviklet over. 61

74 62 Kapitel 3. Implementering Rettelser til generiske design beslutninger I designdokumentet blev der fremsat nogle generiske design beslutninger, disse beslutninger blev implementeret i nogle af de første brugsmønstre, men det viste sig dog, at nogle af disse beslutninger skabte forvirring og til tider kunne opfattes som direkte tvetydige. Derfor er der visse design beslutninger som ændres, disse er: Gem -knap: Knappens tekst ændres til mere sigende tekst, som passer til selve konteksten af handlingen. Dermed ændres teksten i knappen bl.a. til Tilmeld eller mere sigende som Tilmeld hold. Ved at gøre dette opnås entydighed af knappens tekst og selve konteksten. Annuller -knap i søge-formen: Oprindeligt var meningen med denne knap, at brugerene altid skulle kunne afbryde det brugsmønster, de var i gang med, og dermed blive sendt tilbage til hovedvinduet uden at gemme. Selve beslutningen gik på, at knapperne Annuller og Tilbage altid skulle optræde i alle skærmbilleder. Desværre har dette til tider givet problemer, f.eks. i Tilmeld hold til turnering når brugeren søger efter spillere til sit hold. Hvis brugeren vælger at trykke på Annuller afbrydes hele tilmeldingsprocessen. Derfor er det i nogle tilfælde mere hensigtsmæssigt, at knappen Annuller, ændres til Tilbage -knappens funktion, og Tilbage -knappen fjernes fra formen. Afgrænsning fra web-interface En systemdel der afgrænses fra, er udvikling af en ASP.NET-udgave til tilmelding til computerparty og reservering af plads. Årsagen til dette i første omgang ikke implementeres, er at det ikke ses som væsentligt, da deltagerne kan tilmeldes og reservere pladser via det selvstændige C#-administrationsprogram. I sammenhæng med afgrænsningen af muligheden for tilmelding via. internettet, afgrænses systemet også fra at skulle holde styr på indbetalinger fra deltagere. Dette afgrænses, da det ikke ses som en vigtig del at implementere i sammenhæng med denne projektperiode. Afgrænsning fra at kunne registrere ankomne deltagere En af mulighederne med systemet skulle være, at deltagere kunne registreres, når de ankom til computerpartyet. Da denne funktion ikke er så væsentlig for programmet i sin helhed, er det valgt ikke at implementere denne funktion. Programmet fungerer fint uden denne funktion, og kan sagtens bruges til et konkret computerparty uden. Til en senere videreudvikling af programmet er det dog en funktion, der kunne være en nyttig feature at implementere. Afgrænsning fra at implementere mere end en turneringstype Der afgrænses fra at implementere flere turneringstyper end Single-elemination. Dette valg er foretaget, eftersom det implementerede system kun er en prototype. Problemet er dog ikke stort, da det kun er et spørgsmål om at udvikle de nødvendige plugins ved tilføjelse af nye turneringstyper. Ændring af måden hvorpå data i systemet ændres Tidligere i rapporten er det blevet beskrevet, hvordan blandt andet en turnering redigeres. Det er forsøgt at ændre denne måde at ændre data på, så alt data skal kunne ændres i

75 3.2. Værktøj 63 en og samme editor. Denne editor skal kun bruges af crew og ikke deltagere, da den ikke er særlig brugervenlig for personer uden høje computerkundskaber. Editoren vil blive lavet med et DataGridView, hvor hver kolonne repræsenterer noget data på et objekt, og hver række repræsenterer et objekt. 3.2 Værktøj I følgende afsnit vil der blive set nærmere på det værktøj, der er benyttet i forbindelse med implementeringen og udviklingen af systemet. Værktøjet har gjort arbejdet lettere og mere overskueligt, og i nogle tilfælde været en uundværlig del af implementering- og kodningsprocessen Microsoft Visual Studio &.NET Det program der er blevet anvendt til at udvikle hovedparten af systemet i, er Microsoft Visual Studio [8]. Dette program indeholder værktøjet Visual C#, der er yderst nyttigt til programmering i C#. Det er udviklet af Microsoft i forlængelse af.net framework et og er derfor meget integreret i netop.net og C#, hvilket gør det til et oplagt valg, som det foretrukne værktøj til dette projekt. Visual C# indeholder en række funktioner, som gør det nemmere og mere effektivt at programmere. Eksempelvis har Visual C# en autocompletefunktion, som kan hjælpe en med at huske de metoder eller egenskaber en klasse har. Værktøjet indeholder også en designer, som kan bruges til at opbygge den grafiske brugergrænseflade. Designeren er en såkaldt WYSIWYG (W hat you see is what you get) editor, hvilket hjælper med til at danne et overblik, der gør det lettere at kombinere det underliggende system med brugergrænsefladen. Endvidere er Microsofts.NET opslagsværk; MSDN Library, integreret i Visual Studio og fungerer som en hjælpefunktion. Visual Studio indeholder også en kompilerfunktion, der kan kompilere koden for programmet og brugergrænsefladen til en brugbar applikation. Desuden indeholder den en debugger der kan finde fejl i programmet, både på compile- og runtime Alternativer Der var andre mulige programmer der kunne have været benyttet til udvikling af programmet, men som ikke blev brugt. Nogen af disse nævnes her. Sharp Develop SharpDevelop [10] er et open-source udviklingsværktøj til C#. Grundlæggende kan Sharp- Develop meget af det samme som Visual C#-delen af Visual Studio kan. Eksempelvis har SharpDevelop også en debugger og en designer. Det er dog ikke så simpelt, at designe brugergrænseflader i SharpDevelop, som det er i Visual C#. Mono Mono [11] er et platformsuafhængigt open source-projekt, som udgør et alternativ til.net framework et, hvilket gør det muligt at udvikle C# programmer der ikke kun kan afvikles under Windows, men også under Linux og Mac OS X. Mono har ligesom.net et runtimeenvironment som står for afvikling af C#-kode oversat af Monos kompiler. Til selve ud-

76 64 Kapitel 3. Implementering viklingen af C# programmer i Mono findes MonoDevelop, som er en videreudvikling af SharpDevelop, der er tilpasset udvikling af C# programmer i Mono. 3.3 Kodeeksempler fra komponentlagene Her er der udvalgte eksempler på kørende kode, fra det implementerede system. Der er eksempler fra alle komponentlagene, og de er opdelt efter, hvilket lag koden hører ind under. Eksemplerne er valgt, fordi de giver et fyldestgørende indblik i det enkelte komponentlag, dvs. ikke-triviel kode. For at få hele kildekoden, refereres der til bilag på vedlagt cd, med det kørende program. Der vil kun blive kommenteret på det interessante i kodeeksemplerne, dvs. kommentarer til simple operationer, vil blive udladt. Til slut i afsnittet er der nogle eksempler på samspil mellem komponentlagene Brugergrænsefladelaget Brugergrænsefladelaget er den del af systemet brugeren interagerer direkte med. Det meste af koden herunder er genereret af udviklingsværktøjet brugt i denne sammenhæng (Visual Studio). Resten af koden er skrevet af udviklerne, og det er kode der eksekveres ved events i brugergrænsefladen. Et eksempel på et event, er eksempelvis et tryk på en knap, eller en form der åbnes. Udregninger til tegneområdet Til visning af turneringsplaner på storskærmen er der blevet anvendt en grafisk løsning. Løsningen anvender klassen Graphics i.net. For at bruge denne funktionalitet, har det været nødvendigt at opstille nogle regnemetoder til løsning af problemerne; hvordan kasserne skulle placeres i henhold til hinanden, og hvordan det skulle placeres på skærmen. Disse formler bliver opstillet i figur 3.1, og vises sammen med en grafisk opstilling af selve turneringen. Selve tegnemetoden foregår ved at gå fra højre mod venstre og nedefra og op på skærmen. Den sidste runde i turneringen tegnes først, hvorefter den næstsidste runde tegnes og så videre. Endvidere vil det sige, at finalekampen tegnes først, hvorefter den nederste af semifinalerne tegnes, og så den øverste semifinalekamp. Sådan fortsættes indtil den første kamp i turneringen og dermed alle kampe er tegnet. I figuren ses at der er opstillet en række variabler, som både anvendes i formlerne, men som også bare er listet. Disse variabler er ikke kun opstillet til anvendelse i formlerne, men også som forslag til navne i selve systemet. De forskellige formler til udregning af variablerne vil her blive listet, med beskrivelse over hvad de anvendes til: Midten af tegningen i horisontalretning: Dette udregnes for at kunne centrere tegningen, men sættes til 0, da tegningen skal centreres i (0, 0). Hc = , dog sættes den lig 0. Midten af tegningen i vertikalretning: Dette udregnes også for at kunne centrere tegningen, og sættes også til 0, da tegningen skal centreres i (0, 0). V c = 768 2, dog sættes den lig 0.

77 Brugergrænsefladelaget 65 Legend: nrnd - Nr. of rounds dnrnd - Drawn nr. of rounds Vc - Vertical center Hpos - Horizontical position (1. team) KH - Height of team KB - Width of team Xpos - Position on X FSp - First space (vert.) Sp - Space (vertical) Dteams - Drawn teams Vc = 768/2 (Koordinate X=0) (Is set to 0 - zero - for better centering) FSp KB Xpos Sp KB Xpos 1024 Hc = 1024/2 (Koordinat Y = 0) General formulars: Team-placing -X.: Hpos - dnrnd * Xpos -Y.: Vc + ( ( ( 2^(dnrnd) * Sp - Sp ) ) - KH ) / 2 ) - dteams * Sp SP: 2^(nrnd dnrnd) * FSp Sp KB Xpos KH KH ( Hpos ; Vc - ( (Sp - KH ) / 2 ) ) KB KH 768 Hpos ( ( (nrnd - 1) Xpos + KB ) / 2 ) - KB Figur 3.1: Formlerne til udregning af placeringen af kampe. Horisontal afstand mellem holdnavne: Udregner den horisontale afstand mellem kasserne med holdnavne, der er afstanden mellem øverst venstre hjørne af kasserne. Sp = 2 nrnd 1 dnrnd F Sp Horisontal placering af hold: Placering af kassen der indeholder holdnavnet (x-koordinat). X = Hpos dnrnd Xpos Vertikal placering af hold: Placering af kassen der indeholder holdnavnet (y-koordinat). Y = V c + (2dnrnd Sp Sp) KH 2 dteams Sp Formler der ikke er med på tegningen, men anvendes i systemet, er formlerne til udregning af bredden og højden af tegneområdet. Disse to værdier bruges til at placere tegneområdet korrekt ved skalering. Et kodeeksempel på dette vises senere. Eksempel på udregninger For at give et bedre indblik i beregningsmetoderne vises nu et eksempel på at tegne en singleelimination med fire hold. Tegneprocessen gennemgås med udregninger, som de foregår i systemet. Der gennemgås også formler, som ikke er nævnt i listen ovenfor.

78 66 Kapitel 3. Implementering Den første beregning der foretages er, at udregne antal hold der skal placeres i første runde. Dette inkluderer også såkaldte dummy -hold. Disse hold bliver ikke vist, men bruges blandt andet til udregning af antal runder, højden af det tegnede område og placering af hold i runden. Til udregning af antal hold der skal være i turneringen, for at udfylde første runde, bruges følgende beregningsmetode: sizeofsingle = 2 ln(nroft eams) = 4hold Da det nu vides hvor mange hold der skal til for at udfylde første runde, kan der nu beregnes, hvor mange runder der er i alt i turneringen: maxnrofrounds = ln(sizeofsingle) + 1 = 3runder Inden første tegnerunde påbegyndes, skal der huskes på, at følgende værdier på forhånd er sat: KB = 100, KH = 18, Xpos = 150, F Sp = 20. Herefter udregnes placeringen af tegningen. Dette gøres ved at udregne start for vertikal og horisontal tegneposition, det vil sige at Vpos er det midterste punkt i vertikal retning, mens Hpos er den horisontale startposition der tegnes i. Det vil sige finalens kasses tegneposition beregnes som: V pos = 0px, Hpos = (maxnrofrounds 1) Xpos + KB 2 KB = 100px Nu køres der igennem den første runde der skal tegnes, hvilket er finalen. Først udregnes mellemrummet der skal være vertikalt mellem kassernes tegneposition: Sp = 2 nrnd dnrnd 1 F Sp = 80px Så udregnes hvilken x- og y-position kassen skal tegnes i: X = Hpos drounds Xpos = 100px; Y = V pos+ (2drounds Sp Sp) KH (dteams Sp) = 9px 2 Da der kun eksisterer et hold i finalen, forsættes til næste runde som skal tegnes. Denne runde er i dette tilfælde semifinalen, hvilket også er 2. runde. Det første der udregnes er det vertikale mellemrum mellem kasserne: Sp = 2 nrnd dnrnd 1 F Sp = 40px Derefter udregnes den første kasses x- og y-position: X = 100px 1 150px = 50px; Y = 0px + (21 40px 40px) 18px 2 (0 40px) = 11px Da der stadig er et enkelt hold der skal placeres udregnes også x- og y-positionen for denne:

79 Brugergrænsefladelaget (-200; -39) (-200; -19) (-200; 1) (-200; 21) 40 (-50; -29) (-50; 11) (0; 0) 80 (100; -9) Figur 3.2: Eksempel med koordinatresultater. X = 100px 1 150px = 50px; Y = 0px + (21 40px 40px) 18px 2 (1 40px) = 29px Nu er alle hold placeret i 2. runde/semifinalen, hvilket kan ses i figur 3.2: Det sidste der skal udregnes bruges til at placere og skalere det tegnede område i midten af skærmen. Et konkret kodeeksempel for dette ses i kodeeksempel 3.1. Der tages udgangspunkt i, at storskærmen bruger en opløsning på 1024x768, hvilket skal bruges i beregningerne for skalering. Først udregnes hvilken vej den skal skalere, så den passer helt ud til kanten. Dette gøres ud fra beregningerne: width = (3 1) 150px + 100px = 400px; height = (4 1) 20px + 18px = 78px Nu kan skaleringsværdierne udregnes: Bredde: 1024px 400px 768px = 2, 56; Højde: 78px = 9, 85 Da bredde har den mindste værdi, er det den som skal bruges til skalering. Hvis højden var blevet brugt, ville det gøre billedet næsten fire gange bredere end skærmens bredde på 1024px. Inden billedet skaleres, flyttes billedet ved at flytte billedet i følgende retning: X : ; Y : Derefter skaleres billedet med den fundne skaleringsværdi i både x- og y-retningen med den samme skaleringsværdi. Skalering af tegneområdet til visning på storskærm Dette kodeeksempel er fra single-elimination plugin et, som anvendes ved turneringer der bruger den. Plugin ets tegnefunktion anvendes af formen Draw.cs, som er selve storskærmsfremviserens form, til visning af turneringer. Selve kodeeksemplet anvendes af tegnefunktionen, og bruges til at skalere tegningen, så den passer med skærmens dimensioner. Dermed kan enhver turnering, uanset hvor mange deltagere der er, være indenfor skærmens dimensioner.

80 68 Kapitel 3. Implementering For at aktivere selve funktionen, skal brugeren være logget ind som rettighedshaver til storskærmsfremviserens funktioner. Brugeren kan vælge hvilken af de tilsluttede (Hvis flere) skærme, informationerne skal vises på, og om tegne-formen skal tændes eller slukkes. Hvis brugeren trykker på tænd, så anvendes funktionen sammen med tegnefunktionen. 1 public void s c a l e T o F i t ( G r a p h i c s g, int nrofteams, Form form ) 2 { 3 f l o a t width, height, s c a l e ; 5 w i d t h = ( c a l c u l a t e M a x R o u n d s ( c h e c k _ n r O f T e a m s ( n r O f T e a m s ) ) 1) xpos + r e c t _ w i d t h ; 7 h e i g h t = ( c h e c k _ n r O f T e a m s ( n r O f T e a m s ) 1) f i r s t S p a c e + r e c t _ h e i g h t ; 9 i f ( ( screen_ width / width ) <= ( screen_ height / height ) ) 10 { 11 scale = screen_ width / width ; 12 } 13 e l s e 14 { 15 scale = ( screen_ height 30) / height ; 16 } 18 g. T r a n s l a t e T r a n s f o r m ( ( f l o a t ) form. C l i e n t S i z e. W i d t h / 2, ( f l o a t ) ( form. C l i e n t S i z e. H e i g h t / 2) + 15) ; 20 g. ScaleTransform ( scale, scale ) ; 21 } Kodeeksempel 3.1: Skalering af tegneområdet til visning på storskærm Linje 1-2: Metoden defineres. Den returnerer Void, da den ikke har nogen reel værdi at returnere. Den modtager et graphics-objekt, antal hold i turneringen og et form objekt. Linje 3: Opretter nogle variabler til anvendelse senere i metoden. Linje 5: Udregner bredden ud fra følgende: antal runder minus én multipliceret med afstanden mellem kassernes afstand fra hinandens øverste venstre hjørne, samt den sidste kasses bredde. (rounds 1) Xpos + KB Linje 7: Udregner højden af turneringen ud fra antal hold minus én, multipliceret med runden som altid er den højeste, nemlig første runde, afstand fra kassens øverste venstre hjørne adderet med den sidste kasses højde. (sizeoft ournament 1) F Sp + KH Linje 9-12: Tester hvilken skaleringsværdi af skærmdimensionerne divideret med turneringsdimensionerne er mindst, hvis skaleringen er mindst for turneringsbredde, så sættes skalering til dette. Linje 13-16: Hvis skaleringen er mindst for turneringshøjden, så sættes skalering til dette minus 30 pixels, da turneringsteksten i toppen skal trækkes fra. Linje 18: Da grafikken tegnes med midten af turneringen i koordinaterne (0, 0), så flyttes midtpunktet i x-retning til skærmens bredde divideret med to, og flyttes i y-retning til skærmens højde divideret med to adderet med halvdelen af turneringstekstens højde. Linje 20: Til sidst skaleres grafikken i både x- og y-retning med den fundne skaleringsværdi.

81 Funktionslaget Funktionslaget Funktionslaget er det lag, som holder styr på sammenhængen mellem de andre lag i systemets arkitektur. Det er hovedsageligt controllerne som eksisterer i funktionslaget. Controllerne bliver kaldt som følge af instruktioner fra brugergrænsefladelaget. Dette kunne eksempelvis være som følge af at brugeren klikker på en knap i brugergrænsefladen. Derudover indeholder funktionslaget også klasser og metoder som ikke hører hjemme i et af de tre øvrige lag. Plugins Klassen Plugins er vist i kodeeksemplet 3.2. Klassens formål er at håndtere plugins til systemet. Den indeholder en funktion, der henter alle plugins i form af dll-filer fra en given sti og returnerer dem i en liste. 1 c l a s s P l u g i n s 2 { 3 private s t a t i c List<Type> t y p e _ l i s t = new List<Type >() ; 5 public s t a t i c List<Type> getplugins <T>( string plugin_ folder ) 6 { 7 i f ( Plugins. type_ list. Count == 0) 8 { 9 string [ ] f i l e _ n a m e s = D i r e c t o r y. G e t F i l e s ( p l u g i n _ f o l d e r, " *. dll " ) ; 10 List<Type> t y p e _ l i s t = new List<Type >() ; 12 foreach ( string file in f i l e _ n a m e s ) 13 { 14 A s s e m b l y a s s e m b l y = A s s e m b l y. L o a d F i l e ( file ) ; 15 foreach ( Type type in assembly. GetTypes ( ) ) 16 { 17 i f (! type. I s C l a s s type. I s N o t P u b l i c ) continue ; 18 Type [ ] interfaces = type. GetInterfaces ( ) ; 19 i f ( ( ( I L i s t ) i n t e r f a c e s ). C o n t a i n s ( typeof ( T ) ) ) 20 { 21 t y p e _ l i s t. Add ( type ) ; 22 } 23 } 24 } 25 Plugins. type_ list = type_ list ; 26 } 27 return Plugins. type_ list ; 28 } 29 } Kodeeksempel 3.2: Klassen Plugins Linje 1-2: Klassen Plugins initialiseres og scopet for klassen begynder. Linje 3: Et nyt element af typen List bliver initialiseret og kaldt type_list. Listen sættes til private da den kun skal være tilgængelig i klassen Plugins. Linje 5-6: En public funktion initialiseres med navnet getplugins. Den modtager en streng som argument, der bindes til variabelnavnet plugin_folder. Denne streng er stien til plugin-filen. Linje 7-8: En if -kontrolstruktur, der efterprøver om der er nul plugins i listen. Hvis det er sandt, køres linje Linje 9: Et array af strenge initialiseres til at hedde file_names. Dette array indeholder alle stier til alle plugins der er i den medsendte sti plugin_folder. Linje 10: En ny liste initialiseres til at hedde type_list, som indeholder typen af plugins.

82 70 Kapitel 3. Implementering Linje 12-13: Foreach -løkken køres for hver fil der er i arrayet file_names. Linje 14: Her laves en ny variabel kaldet assembly af samme type. Denne loader indholdet af den aktuelle fil file som er fra arrayet file_names. Linje 15-16: Endnu en foreach -løkke gennemkøres, som henter hver enkelt type i assemblyen. Linje 17: If -kontrolstrukturen tester om typen ikke er af typen klasse eller om typen ikke er med public synlighed. Hvis udtrykket er sandt, så afbrydes foreach -løkken med den enkelte type, og kører samme foreach -løkke med næste type. Linje 18: Her hentes alle typens interfaces som lagres i et type-array kaldet interfaces. Linje 19-20: If -kontrolstrukturen tester om arrayet interfaces indeholder objekter af typen T. Hvis udtrykket er sandt køres indholdet af kontrolstrukturen. Linje 21-24: Værdien af type bliver tilføjet til listen type_list med kommandoen Add. If -kontrolstrukturen og de to foreach -løkker afsluttes. Linje 25-26: Plugins.type_list bliver tildelt indholdet af listen type_list og if -kontrolstrukturen bliver afsluttet. Linje 27-29: Listen Plugins.type_list bliver returneret og den statiske funktion getplugins bliver afsluttet og det samme gør klassen Plugins Modellaget Modellaget indeholder alt det data, som programmet skal holde styr på fra problemområdet, samt de metoder der manipulerer systemets data. Alt i modellaget kan gemmes i persistensen, hvilket muliggør præservation af data fra en programeksekvering til en anden. Single-elimination plugin Kodeeksemplerne 3.3 og 3.4 er fra samme underturnerings-plugin. Dette plugin hedder Sub- TournamentSingleElimination og gør det muligt at oprette en single-elimination turnering. Underturnerings-plugins kan udvikles uafhængigt af programmet, og kan loades af programmet, hvis man kompilerer det til et program modul (dll-fil). Det kræves dog at plugin et implementerer et bestemt interface ISubTournament. Disse kodeeksempler er eksempler på implementering af to af de mest essentielle metoder, som kræves for at lave et underturneringsplugin til programmet. Det første af kodeudsnittene 3.3 starter/initialiserer underturneringen med runder og kampe, således at plugin et er klar til at modtage indmeldelser af resultater. Andet kodeudsnit 3.4 kaldes, når et hold ønsker at indmelde resultatet fra en kamp, og har til ansvar at føre det vindende hold videre i den interne struktur af runder og kampe. I kodeeksemplet vil der forekomme kald til private metoder i plugin et. Hvad hver af metoderne gør, vil kun blive beskrevet overfladisk. 1 public void runtournament ( Collection <int> ranked_ team_ list, Collection <string> map_array, int m a p s _ s t a r t _ i n d e x, s t a r t N e x t S u b T o u r n a m e n t r u n _ o n _ w i n ) 2 { 3 t h i s. t e a m _ c o l l e c t i o n = r a n k e d _ t e a m _ l i s t ; 4 this. map_ collection = map_ array ; 5 t h i s. m a p _ i n d e x = m a p s _ s t a r t _ i n d e x ;

83 Modellaget 71 6 t h i s. r u n _ o n _ w i n = r u n _ o n _ w i n ; 8 Collection <int?> playing_ teams = new Collection <int? >() ; 9 for ( int i = 0 ; i < t h i s. n u m _ s t a r t i n g _ t e a m s ; i++) 10 { 11 p l a y i n g _ t e a m s. Add ( ( int? ) t h i s. t e a m _ c o l l e c t i o n [ i ] ) ; 12 } 14 int d u m m y _ t e a m _ c o u n t = t h i s. d u m m y T e a m C o u n t ( t h i s. n u m _ s t a r t i n g _ t e a m s ) ; 15 for ( int i = 0 ; i < dumm y _ team_ count ; i++) 16 { 17 p l a y i n g _ t e a m s. Add ( null ) ; 18 } 20 int round_ count = this. roundcount ( playing_ teams. Count ) this. roundcount ( this. n u m _ a d v a n c i n g _ t e a m s ) + 1 ; 21 for ( int i = 0 ; i < round_ count ; i++) 22 { 23 Round round = new Round ( this. map_ collection [ this. Map_ index ++]) ; 24 int round_ id = AdminCP_ gui. Program. Serializer. save ( round ) ; 25 t h i s. r o u n d _ c o l l e c t i o n. Add ( r o u n d _ i d ) ; 26 } 28 Round initial_ round ; 29 A d m i n C P _ g u i. P r o g r a m. S e r i a l i z e r. load ( out i n i t i a l _ r o u n d, t h i s. r o u n d _ c o l l e c t i o n [ 0 ] ) ; 31 int m a t c h _ c o u n t = ( d u m m y _ t e a m _ c o u n t + t h i s. n u m _ s t a r t i n g _ t e a m s ) / 2 ; 32 int m a t c h _ t o _ i n i t = 0 ; 34 for ( int i = 0 ; i < match_ count ; i++) 35 { 36 Match match = new Match ( ) ; 38 m a t c h. a d d T e a m ( 0, p l a y i n g _ t e a m s [ i ] ) ; 39 m a t c h. a d d T e a m ( 1, p l a y i n g _ t e a m s [ m a t c h _ c o u n t 2 i 1 ] ) ; 41 int match_ id = AdminCP_ gui. Program. Serializer. save ( match ) ; 42 i n i t i a l _ r o u n d. a d d M a t c h ( m a t c h _ t o _ i n i t, m a t c h _ i d ) ; 44 i f ( null == playing_ teams [ match_ count 2 i 1 ] ) 45 { 46 A d m i n C P _ g u i. P r o g r a m. S e r i a l i z e r. save ( i n i t i a l _ r o u n d, r o u n d _ c o l l e c t i o n [ 0 ] ) ; 47 t h i s. a d v a n c e T e a m ( ( int ) p l a y i n g _ t e a m s [ i ] ) ; 48 } 50 m a t c h _ t o _ i n i t = this. n e x t M a t c h T o I n i t ( m a t c h _ t o _ i n i t, m a t c h _ c o u n t ) ; 51 } 53 A d m i n C P _ g u i. P r o g r a m. S e r i a l i z e r. save ( i n i t i a l _ r o u n d, r o u n d _ c o l l e c t i o n [ 0 ] ) ; 54 return ; 55 } Kodeeksempel 3.3: Initialisering af single elimination plugin Linje 1-2: Modtager en collection af hold-id er, hvor hold med lavt index er bedst, en collection af strenge som siger noget om, hvilke baner der skal spilles, herefter et index for hvilket map der er blevet spillet sidst, og til sidst en delegate, som skal kaldes når den kørende underturnering er slut. Underturneringen er slut, når der kun er det antal hold tilbage, som næste underturnering forventer. Disse værdier kender objektet allerede på nuværende tidspunkt. Linje 3-6: Sørger for at værdierne er tilgængelige for fremtidige kald af metoder. Linje 8-12: Kopierer de startende hold over i playing_teams. Objektet ved allerede hvor mange hold der skal starte. Linje 14-18: Metoden: dummyteamcount() returnerer antallet af krævede dummy teams til turneringen. Antallet af startende hold skal kunne faktoriseres af tallet 2. Hvis det startende antal hold er 5, vil dummyteamcount() returnere 3 da 5+3 = 8 = = 2 3. I det tilfælde vil der blive tilføjet 3 dummy hold til playing teams.

84 72 Kapitel 3. Implementering Linje 20-26: Metoden: roundcount() returnerer antal runder som skal spilles, for at der kun er et hold tilbage. Disse linjer opretter det antal runder, som skal spilles, for at finde de videregående hold. Yderligere bliver der tilføjet en ekstra runde til fordel for visning af hvilke hold der går videre. Den sidste runde spilles altså ikke. Linje 28-29: Loader den første runde fra persistenslaget, da der nu skal indsættes kampe i den. Linje 31-32: Initialiserer variabler, til brug ved indsættelse og seedning af kampe og hold. Variablen match_to_init anvendes sammen med metoden nextmatchtoinit() på linje 50. nextmatchtoinit() returnerer indexet på den næste kamp, som skal indsættes. I tilfælde af at der skal spilles fire kampe, vil variablen match_to_init antage værdierne 0, 3, 1, 2 i den nævnte rækkefølge. Linje 36-42: Laver en kamp fra holdet øverst på listen (som ikke allerede er i en kamp) og holdet nederst på listen (som heller ikke er i en kamp), hvorefter kampen bliver gemt. Linje 44-48: Hvis der er et dummy team i kampen, avancér det eksisterende hold med metoden advanceteam(). Linje 53-54: Gemmer rundeobjektet. 1 public V a l i d F e e d b a c k c o m m i t R e s u l t ( int m y _ t e a m _ i d ) 2 { 3 int? [ ] c o o r d i n a t e = new int? [ 3 ] ; 4 c o o r d i n a t e = this. i n d e x O f T e a m ( m y _ t e a m _ i d ) ; 6 i f ( t h i s. r o u n d _ c o l l e c t i o n. C o u n t 1 == c o o r d i n a t e [ 0 ] ) 7 return new V a l i d F e e d b a c k ( f a l s e, " Du kan ikke i n d m e l d e r e s u l t a t før n æ s t e underturnering er begyndt " ) ; 9 int r o u n d _ i d = t h i s. r o u n d _ c o l l e c t i o n [ ( int ) c o o r d i n a t e [ 0 ] ] ; 10 Round round ; 11 AdminCP_ gui. Program. Serializer. load ( out round, round_ id ) ; 12 int m a t c h _ i d = ( int ) r o u n d. g e t M a t c h ( ( int ) c o o r d i n a t e [ 1 ] ) ; 13 Match match ; 14 AdminCP_ gui. Program. Serializer. load ( out match, match_ id ) ; 16 int? o p p o n e n t _ t e a m _ i d ; 17 i f ( c o o r d i n a t e [ 2 ] == 0) 18 { 19 o p p o n e n t _ t e a m _ i d = m a t c h. g e t T e a m ( 1 ) ; 20 } 21 e l s e 22 { 23 o p p o n e n t _ t e a m _ i d = m a t c h. g e t T e a m ( 0 ) ; 24 } 26 i f ( o p p o n e n t _ t e a m _ i d == null ) 27 return new V a l i d F e e d b a c k ( false, " Du har ikke spillet denne kamp endnu, da din modstander ikke er bestemt endnu. " ) ; 29 Team opponent_ team ; 30 A d m i n C P _ g u i. P r o g r a m. S e r i a l i z e r. load ( out o p p o n e n t _ t e a m, ( int ) o p p o n e n t _ t e a m _ i d ) ; 31 Team my_ team ; 32 AdminCP_ gui. Program. Serializer. load ( out my_team, my_ team_ id ) ; 34 S u b T o u r n a m e n t S i n g l e E l i m i n a t i o n R e s u l t D i a l o g d i a l o g = new S u b T o u r n a m e n t S i n g l e E l i m i n a t i o n R e s u l t D i a l o g ( m y _ t e a m. Team_name, o p p o n e n t _ t e a m. T e a m _ n a m e ) ; 35 string result = dialog. getresult ( ) ; 36 i f ( r e s u l t == null ) 37 { 38 return new V a l i d F e e d b a c k ( true, " Alt er godt " ) ; 39 } 41 AdminCP_ gui. Program. Serializer. load ( out match, match_ id ) ; 42 i f ( match. Match_ winner_ id!= null )

85 Modellaget return new V a l i d F e e d b a c k ( true, " R e s u l t a t e t for d e n n e kamp er b l e v e t i n d m e l d t via en anden klient " ) ; 45 i f ( r e s u l t == " V u n d e t " ) 46 { 47 this. a d v a n c e T e a m ( m y _ t e a m _ i d ) ; 48 t h i s. d r o p T e a m O u t ( ( int ) o p p o n e n t _ t e a m _ i d ) ; 49 } 50 e l s e 51 { 52 t h i s. a d v a n c e T e a m ( ( int ) o p p o n e n t _ t e a m _ i d ) ; 53 this. d r o p T e a m O u t ( m y _ t e a m _ i d ) ; 54 } 56 i f ( t e a m _ c o l l e c t i o n. C o u n t t h i s. t e a m s _ d r o p p e d _ o u t == t h i s. n u m _ a d v a n c i n g _ t e a m s ) 57 { 58 t h i s. r u n _ o n _ w i n ( t h i s. t e a m _ c o l l e c t i o n, t h i s. m a p _ i n d e x ) ; 59 } 61 return new V a l i d F e e d b a c k ( true, " Alt er godt " ) ; 62 } Kodeeksempel 3.4: indrapportering af resultat til single elimination plugin Linje 1-2: Modtager et hold-id, som svarer til id et på det hold som ønsker at indmelde resultat. Linje 3-4: Metoden: indexofteam() søger runde/kamp strukturen igennem for at finde koordinatet for den seneste kamp som holdet har spillet, hvorefter koordinatet returneres som et array af tre nullable integers. Første element er runden, andet element er kampen, og tredje element er holdets placering i kampen. Eksempelvis vil et returneret array: 4, 1, 0, betyde at holdet senest spillede i runde 5, i kamp 2, samt har første pladsen i kampen. Linje 6-7: Tester efter om holdet befinder sig i den sidste runde, hvis dette er tilfældet bliver en fejlmeddelelse returneret (den sidste runde skal ikke spilles, men holder blot på vinderne af turneringen). Linje 9-14: Indlæser runden og derefter kampen, som holdet ønsker at indmelde resultat for. Linje 16-24: Finder modstanderens hold-id. Linje 26-27: Tester om holdet, som ønsker at indmelde resultat, rent faktisk har en modstander. Hvis det ikke er tilfældet bliver en fejlmeddelelse returneret. Linje 29-32: Indlæs eget hold, samt modstanderens. Linje 34-39: Viser en indmeld resultat -form, hvorpå ens eget holdnavn, samt ens modstanders holdnavn figurerer. Hvis brugeren klikker Annullér returnerer metoden. Linje 41-43: Tester om der i mellemtiden er blevet fundet en vinder til den pågældende kamp. Hvis det er tilfældet bliver en fejlbesked returneret. Linje 45-54: Metoden: dropteamout() tæller variablen teams_dropped_out en op, samt flytter teamet nederst på listen over hold. Hvis resultatet er Vundet bliver det pågældende hold avanceret til næste runde, og modstanderen bliver droppet ud. Ellers bliver det pågældende hold droppet ud, og modstanderen bliver avanceret.

86 74 Kapitel 3. Implementering Linje 56-59: Tester om antallet af tilbageværende hold i underturneringen, er det samme som antallet af hold, som skal gå videre til næste underturnering. Hvis dette er tilfældet, bliver delegaten run_on_win kaldt med relevante data. Dette kald resulterer i, at næste underturnering sættes i gang Persistenslaget Persistenslaget i systemet, er det lag der håndterer datalagring. Det er et vigtigt lag, da det sørger for, at dataene bliver lagret og gemt forsvarligt til senere brug. Der findes mange forskellige metoder til at lagre data, og derfor er det ikke umiddelbart muligt at understøtte dem alle. En måde at imødekomme de forskellige lagringsmetoder er, ved at lade persistenslaget bestå af plugins. Ved at benytte plugins, til at styre persistensen, har brugerne mulighed for at vælge netop den løsning, der passer til deres behov. Det er således muligt at benytte en database frem for serialiserede filer, blot ved at udvikle et plugin der kommunikerer med en database i stedet. Måden hvorved persistenslaget i dette system lagrer data, afhænger selvfølgelig af, hvilke plugins der er tilgængelige, men det plugin, der følger med programmet, gør det muligt at gemme til filer vha. serialisering. Interface-ISerializer For at kunne bruge plugins til at gemme data i forskellige datakilder, er det et krav, at alle disse plugins implementerer det samme interface, så programmet ved, hvilke metoder der kan kaldes på plugin et, når data skal indlæses eller gemmes. Koden fra interfacet ISerializer er vist i kodeeksempel 3.5, sammen med en forklarende tekst til hver metode. Det udviklede plugin til at gemme data i filer, er udviklet ved hjælp af dette interface. 1 public interface I S e r i a l i z e r 2 { 3 int save<t>(t Obj ) ; 4 void save<t>(t Obj, int id ) ; 5 void save<t>(t Obj, string id ) ; 7 void saveall<k, V>( IDictionary <K, V> dictionary ) ; 9 void load<tout >(out TOut Obj, int id ) ; 10 void load<tout >(out TOut Obj, string id ) ; 12 void loadall<v>( IDictionary <string, V> dictionary ) ; 13 void loadall<v>( IDictionary <int, V> dictionary ) ; 14 void loadall<v>( IDictionary <int, V> dictionary, Collection <int> Collection ) ; 15 void loadall<v>( IDictionary <string, V> dictionary, Collection <string> Collection ) ; 17 void remove ( string object_ type, int id ) ; 18 void remove ( string object_ type, string id ) ; 20 bool exist ( string object_ type, int id ) ; 21 bool exist ( string object_ type, string id ) ; 22 } Kodeeksempel 3.5: Klassen Plugins Linje 1: Der laves et interface til brug i programmet. Navnet på denne er ISerializer, I et i starten af navnet angiver, at det er et interface og ikke en almindelig klasse. Linje 3: Denne metode bruges til, at gøre et nyoprettet objekt persistent. Alle typer af objekter kan sendes som en parameter, hvorefter det vil blive gjort persistent. Når

87 Persistenslaget 75 objektet er gjort persistent, returneres det unikke id som identificerer objektet i persistensen. Linje 4-5: Disse to metoder bruges til at opdatere allerede oprettede objekter i persistensen. Alle typer af objekter kan sendes som en parameter, hvorefter objektet opdateres. Sammen med objektet skal metoden have en parameter, der angiver det unikke id på det objekt i persistensen, der skal opdateres. I systemet kan string s og int s benyttes som unikke id er, så derfor er funktionen overloaded. Linje 7: Hvis der i systemet er flere objekter af samme type der skal opdateres, kan denne metode bruges. Parameteren der skal sendes til metoden, skal være en IDictionary. Denne skal bestå af de to datatyper: key = Unikt id, value = Objektet der skal gøres persistent. Linje 9-10: For at indlæse et eksisterende objekt fra persistensen, kan disse to metoder benyttes. Den første parameter i metoden skal være et objekt, af den type der ønskes indlæst. Anden parameter er det unikke id. Metoden er overloaded, for at kunne bruge både int s og string s. Linje 12-13: Ønskes det at indlæse alle eksisterende objekter af en bestemt type fra persistensen, er denne metode lavet til dette formål. Parameteren denne metode skal have er en IDictionary, hvor den første datatype (key) er et unikt id (string eller int), og anden datatype er et objekt af den type der ønskes indlæst. Linje 14-15: De to metoder i disse linjer virker som de to metoder i linje 12-13, men med en lille udvidelse. Metoden har en ekstra parameter, der skal være en Collection af enten int s eller string s. Denne Collection skal indeholde en liste over unikke id er, på de eksisterende objekter i persistensen der ønskes indlæst. Linje 17-18: Skal et objekt slettes fra persistensen, bruges en af disse metoder. Første parameter skal være en string med navnet på typen af det objekt der ønskes slettet. Anden parameter skal være det unikke id på et eksisterende objekt i persistensen. Metoden er overloaded til de to id typer. Linje 20-21: Til at kontrollere om et givent objekt eksisterer i persistensen, bruges denne metode. Metoden skal bruge de samme parametre som metoderne i linje Hvis objektet findes, returneres værdien true, ellers returneres false. Konfiguration For at gøre systemet mere fleksibelt, er det nødvendigt at kunne konfigurere forskellige aspekter af programmet, uden at skulle rette direkte i programkoden. Da systemets persistens er styret af et plugin, ville det være muligt at inkludere konfigurationen af persistensen i dette plugin, men oftest er det kun ganske få ting, der skal kunne ændres via. konfiguration fra brugerens side. Den udviklede fil med serialiseringsplugin skal f.eks. kun bruge en sti til den mappe, hvor den skal læse og skrive data fra. På grund af det begrænsede behov for konfiguration, blev det valgt at konfigurationer til systemet skal læses fra en konfigurationsfil, der ligger i samme mappe som programmet. Konfigurationsfilen er opbygget med en konfiguration per linje, linjer der starter med ; er kommentar linjer. Hver konfigurations linje består af en nøgle og en værdi, som er separeret

88 76 Kapitel 3. Implementering med =. Når systemet under opstart henter konfigurationerne ind, gemmes de i en collection, som bruger nøgleværdierne til at indeksere værdierne. Ved at opbygge konfigurationen på denne måde, er det muligt for et udviklet plugin at benytte konfigurationsfilen, f.eks. ved udvikling af et databaseplugin, vil det være muligt at hente databaseoplysninger fra konfigurationsfilen Sammenhæng mellem komponentlagene De enkelte komponentlag, er opdelt i filer hver for sig, for overskuelighedens skyld. Endvidere er det en fordel i projektarbejde, når der er flere udviklere på samme system, i sammenhæng med versionsstyring. Sammenkoblingen af de enkelte kodefiler, som alle udgør fragmenter af systemet, er meget enkel. Det foregår ved at der oprettes et nyt projekt i Microsoft Visual Studio, hvortil de enkelte fragmenter, eller kodefiler, kan tilføjes nemt og hurtigt. Ud fra designdokumentet kan den enkelte udvikler se, hvilke funktioner og klasser, der skal være synlige mellem lagene. Efter alle moduler er blevet samlet, kan der udføres en integrationstest. For at kunne udføre en integrationstest er det vigtigt, at hvert modul forinden, er blevet gennemtestet i en unit-test. I testafsnittet følges der op på både integrationstest og unit-test, samt en række andre testmetoder. 3.4 Evaluering af implementationen Gennem en implementationsfase kan det ske, at der opstår komplikationer, som ikke har været overvejet gennem analysen- og designfasen. Hvis komplikationerne opdages på et tidligt tidspunkt i implementationsfasen, kan det oftest betale sig, at gå tilbage og revurdere sit design. I tilfælde af, at det først er sent i implementeringen komplikationerne opdages, er det nødvendigt at se på omkostningerne ved at skulle tilbage og revurdere designet. Det vil oftest bedre kunne betale sig at lave enkelte modifikationer i designet, frem for at skulle redesigne hele programmet. Dette afsnit behandler enkeltdele af implementationen, som er revideret eller tilføjet, og som ikke tidligere har været overvejet Multiple instanser af programmet I starten af designfasen, blev det besluttet at systemet skulle køre på flere computere simultant. Denne beslutning medførte, at alt data skulle synkroniseres mellem computerne, derfor blev det valgt at systemet skulle læse og skrive til et Windows Share (WS). Valget af et WS, og ikke en database, blev taget på baggrund af beslutningen om, at udvikle et filserialiseringsplugin, som senere kunne udskiftes til et databaseplugin. Fordelen ved et WS er, at det er let at sætte op, da alle Windows computere har mulighed for at oprette et sådan share. Desværre er der flere ulemper ved at benytte et WS, bl.a. har alle, der befinder sig på det samme netværk, mulighed for at ændre i filerne, dette kan dog løses ved at benytte Windows indbyggede advanceret fildeling. Et andet problem er samtidighed, samtidighedsproblemer kan opstå når to instanser af applikationen tilgår samme fil på samme tid, f.eks. med den intention at foretage ændringer. I dette system kan der opstå samtidighedsproblemer, når en instans af systemet først læser fra en fil i persistensen, derefter læser en anden instans af systemet fra samme fil. Den første instans ændrer noget i filen, imidlertid havde den anden instans ændret noget andet, herved overskriver anden instans det, den første instans havde ændret.

89 3.5. Opsamling 77 Der findes to indfaldsvinkler til samtidighedsproblemet, en optimistisk og en pessimistisk. Den pessimistiske indfaldsvinkel til problemet involverer oftest en form for locks, som har den virkning, at den pågældende instans, som har låst filen, har eksklusiv adgang til den. Det betyder, at andre processer, som ønsker adgang til filen, ikke kan opnå dette. Det kaldes for en pessimistisk tilgang, da det at låse filerne svarer til at tage højde for det værst tænkelige scenarie. I kontrast til den pessimistiske fildeling er den optimistiske, som f.eks. kunne være en form for versionsstyring, hvor der kontrolleres for ændringer, før der gemmes. Dette er ikke lige så sikkert, som den pessimistiske, men det nedsætter frekvensen af problemer betydeligt. I dette projekt er der valgt en optimistisk tilgang til problemet, da der, når der gemmes, kontrolleres om, der er sket ændringer. For at mindske problemerne med samtidighed, blev det valgt, at systemet skulle gemme data så atomart som muligt, for at modvirke at objektstrukturen skulle gå i stykker. Set i kontrast til at gemme større klumper med relaterede data, giver det en del fordele at gemme atomart. Eksempelvis kunne alle brugere være gemt i en fil. Dette ville give problemer, hvis bare to brugere er i gang med at redigere deres profildata. Ved en atomar opdeling af gemt data, er det kun hvis to brugere er ved at redigere i præcis det samme data, at der kan opstå problemer. Ulempen ved den atomare opdeling er, at der bliver genereret mange filer, hvilket giver meget overhead over et WS, og kan derfor give en betydelig performance degradering. At gemme så atomart som muligt vil i øvrigt give stor fordel, ved brug af et evt. databaseplugin. På den måde kan hver record i databasen bestå af et objekt, hvilket vil give stor fordel ved søgning efter et bestemt objekt. Selvom den valgte løsning ikke er optimal, så blev der under den generelle kørsel af systmet, med et bruger load på 2-5 personer ad gangen, ikke fundet nogen alvorlige problemer. 3.5 Opsamling Indledningsvis samler implementationsafsnittet op på de rettelser og overvejelser, der er fra designdokumentet. Dette medfører nogle rettelser til de generiske designbeslutninger, eftersom beslutningerne virkede upassende, og det indebærer en afgrænsning fra at implementere en web-side. Herefter beskrives det værktøj, som bliver brugt til udviklingen af systemet, hvilket er Microsoft Visual Studio. Dette gav anledning til kort at beskrive de alternativer, der var, i sammenhæng med udviklingen. Kodeeksemplerne behandler og beskriver enkelte dele fra de forskellige komponentlag i systemet. Det giver et dybere indblik i, hvordan det objektorienterede programmeringssprog C# bliver brugt i sammenhæng med implementationen. De kodeeksempler er delt op efter hvilket komponentlag, som de hører under. Brugergrænsefladelaget indeholder endvidere en beskrivelse af, hvordan placeringerne på de forskellige elementer i en turneringstegning bliver beregnet. Endeligt i implementationen beskrives løsningen på problemet med, at have flere instanser af programmet kørende samtidig på flere maskiner, og dets brug af persistensen på filer. Det giver indblik i hvordan det virker, er sammensat og om hvilke problemer, der er i sammenhæng med den løsning, der er valgt til implementering.

90

91 Kapitel 4 Test & evaluering For at sikre at systemet overholder de indledende krav, som blev specificeret i analyse- og designdokumentationen, er det nødvendigt at udføre en række tests. En anden grund til at udføre tests på et system, er at sikre, at systemet fungerer og ikke laver fejl under afviklingen. Det er således nødvendigt at udføre både systemtest og brugertest. Der eksisterer flere forskellige metoder/former at udføre systemtests på, disse metoder er delt op i to overordnede testformer; Whitebox og Blackbox -testing. Whitebox- og Blackboxtests er testmetoder, de enkelte overordnede tests kan blive udført på. Eftersom systemet udvikles af flere udviklere, og dermed er opdelt imellem flere personer, er det vigtigt, at hver enkelt del virker korrekt. En måde at sikre dette, er ved at udføre unittest eller modultest. Unit-test udføres almindeligvis som runtime-test, for at efterprøve om der er deciderede kørselsfejl i en enkelt funktion eller klasse. Efter modultesten, afprøves systemet med en integrationstest, som der udføres efter de enkelte moduler er samlet til en helhed. Denne test er nødvendig for at sikre om systemet i sammenhæng, kører som det skal. Efter at have testet systemet rent teknisk, kan systemet afprøves af udefrakommende personer, for at undersøge om der opstår usability -problemer. En anerkendt metode til at finde usability -problemer med er Tænk-højt-test, som oftest udføres i et specielt indrettet test-laboratorium. Den sidste afprøvning ligger hos kunden, hvis der eksisterer en sådan, og kendes som en Accept-test. I Accept-testen afprøver kunden systemet, og ser dermed om systemet gør som kunden og udvikleren havde tænkt og ønsket. Denne test er en god idé at udføre selv, før den udføres af kunden, hvilket betyder at det er op til udvikleren, at forestille sig hvilke tests kunden kunne tænkes at udføre. Dette gøres for at komme kunden i forkøbet, i sammenhæng med at finde potentielle, mere eller mindre, graverende fejl eller mangler. Alle testformerne bliver udført i højere eller mindre grad på systemet og afslutningsvis evalueres systemets præstation i forhold til ønskede mål. Testafsnittet er skrevet og udført ud fra bøgerne Kvalitetsstyring i systemudvikling af Stig Bang m.fl. [12] og DIEB bogen Interaction design [3], derudover er der hentet hjælp fra slides i forelæsningerne SAD [4], OOP [13] og DIEB [14]. 79

92 80 Kapitel 4. Test & evaluering 4.1 Testtyper Her gennemgås de forskellige testtyper før de tages i brug, testtyperne beskrives i følgende rækkefølge: Unit-test: Unit-test anvendes til at finde fejl og mangler i selve systemets struktur og kode. Integrationstest: Integrationstests bruges til at undersøge samspillet mellem moduler og deres helhed i systemet. Tænk-højt-test: I denne test gennemgår testdeltagere en opgaveliste, som er opstillet af udviklerne, for at finde usability -problemer. Præ-Accepttest: En test som udføres af udviklerne efter systemet er færdigt, med det formål at finde åbenlyse problemer, som de mener brugerne vil finde Blackbox og whitebox test Blackbox og whitebox testning er to forskellige metoder at udføre test på. Herunder er de to testmetoder opstillet: Blackbox: Inputdata til en blackboxtest vælges ud fra testobjektets interface, der testes både valide og invalide inputdata. Der testes dermed både sandsynlige og usandsynlige input. En blackbox test bruges til at verificere at testobjektet altid producerer et korrekt output. Whitebox: Specificeret mængde af sandsynlige og valide inputdata der skal testes igennem systemet, med det formål at gennemteste alle veje og knudepunkter igennem systemet for derved at verificere systemet. Ved udførelse af en blackboxtest vælges en række valide og invalide inputdata, som anvendes på testobjektet. På forhånd har testlederen ud fra hvert af de valgte inputs, bestemt hvad et validt output er. Selve testformens formål er, at finde ud af om der er fejl i funktioner, f.eks. hvis en funktion ikke returnerer det forventede output på et givet input, men ikke hvor i funktionerne fejlen er. Det er dog ikke realistisk at prøve alle tænkelige input på testobjektet, derfor er det vigtigt at benytte inputdata der er dækkende. Hvis et testobjekt f.eks. tager en collection som input, er det vigtigt både at teste med en tom og en fyldt collection, men også med et objekt der ikke er en collection. For at udføre en komplet whitebox test, gennemtestes alle logiske veje, knudepunkter og instruktioner for derefter at gennemteste alle variabler der ændres, både før og efter hver udførelse af en instruktion. Fordelen med whiteboxtest er at alle veje og knudepunkter testes, men ved at gennemteste alle veje og knudepunkter kan der hurtigt opstå et stort antal variationsmuligheder. Da begge testmetoder er generelle måder at teste på, kan de derfor anvendes til både unit-test og integrationstest Unit-test Unit-testing består i at teste et bestemt modul igennem, hvormed det sikres at modulet virker som specificeret. Hver enkelt af disse unit-tests er uafhængig fra andre tests, dermed tester hver unit-test kun det specifikke område, som modulet består af. I denne testform er

93 Integrationstest 81 det ideelt at gennemteste alle stier for modulet, dermed sikres validiteten for modulet, og kan dermed også nemt gennemtestes på et senere tidspunkt, hvis der ændres i koden. Dette kan blandt andet gøres ved at teste alle modulets muligheder, dermed gennemkøres tests for hver metode og funktion i modulet. Et godt værktøj til at udføre en unit-test, er NUnit [15], som er et testværktøj til C#. NUnit vil imidlertid ikke blive anvendt i denne sammenhæng, da det kræver en del ekstraarbejde, i stedet udføres unit-tests ved at den udvikler der skriver en klasse eller en funktion, selv tester funktionen eller klassen, for at sikre at de opfører sig efter hensigten. Dette er gjort ved at udvikleren selv har opstillet nogle testcases og sat breakpoints i koden, for så at se, om variablerne har haft de korrekte værdier Integrationstest Integrationstesten anvendes til at teste samspillet mellem de enkelte moduler, dette gøres ved at vise at modulerne er koordineret i forhold til designet. Selve testen omhandler at teste og finde fejl i systemets moduler. Testen udføres ved at give systemet et kendt input, hvor det vides hvilket output systemet skal levere, for at systemet kan vurderes til at være korrekt. Hvis dette ikke stemmer overens, må der nødvendigvis være fejl i et eller flere af systemets moduler. Til udførelse af integrationstesten eksisterer der to metoder til udførelse af testen, disse to metoder er: Inkrementaltest: Der tilføjes et nyt modul til systemet ad gangen, og systemet testes på ny, hver gang der tilføjes et nyt modul. Totaltest: Alle moduler samles på én gang og hele systemet testes med alle modulerne. Til udførelse af integrationstesten har inkrementaltesten en vigtig fordel i forhold til totaltesten, da der ud fra testen og de tilføjede moduler, kan lokaliseres en fejl forholdsvis simpelt, da der er afgrænset til et bestemt antal moduler. Dette har totaltesten ikke, da alle moduler samles og hele systemet testes, dermed mistes fordelen for hurtigt at kunne lokalisere fejlen, da der ingen afgrænsning er. Til gengæld er totaltesten ikke så ressourceog tidskrævende som inkrementaltesten Tænk-højt-test Tænk-højt-testen, er en test udført med én eller flere udefrakommende personer, som stilles en række foruddefinerede opgaver. Idéen er, at testpersonerne hver især siger, hvad det er de gør og hvordan de forventer systemet reagerer på det de gør, dermed deres tanker. Denne type test, giver et klart og tydeligt indblik i, om systemet er tilstrækkeligt brugervenligt for testpersonen eller personerne. Det betyder imidlertid, at denne test ikke er så meget til for at efterprøve om der er fejl i systemet, men nærmere om systemet er brugbart for den aktuelle målgruppe. Det er i den sammenhæng vigtigt at finde sine testpersoner fra samme målgruppe som systemet udvikles til, for at give et realistisk billede af brugbarheden/brugervenligheden. Herudover er det en god idé, at udføre testen på så mange personer som muligt, for at få det bedst mulige indblik i problemer Præ-Accepttest En normal accepttest er almindeligvis udført af en eventuel kunde, eller den tiltænkte bruger af systemet. Testen er beregnet til, at efterprøve om kunden/brugeren kan acceptere sys-

94 82 Kapitel 4. Test & evaluering temet, og om det virker, som kunden havde forventet det. Dette gøres oftest ved, i et begrænset omfang, at tage systemet i brug i de omgivelser, det var tiltænkt. En præ-accepttest er udført af udvikleren, for at efterprøve systemet i sin helhed, og teste efter fejl, mangler eller bare problemer, som kunden ville kunne finde på at prøve i sin accepttest. Hermed følger navnet; Præ-Accepttest. Eftersom en komplet test af hele systemet, er meget omfattende og tidskrævende, er det en god idé, at sortere de ting fra, som kunden formodentligt ikke vil teste. Hvis der er tvivl om dette, er det en god indfaldsvinkel, at teste systemet i relation til de krav, der blev specificeret i løbet af analysen (heriblandt prioritetstabellen, figur 1.6 på side 24). Idéen er her at udvælge de punkter, som er markeret som vigtigt eller meget vigtigt, og efterprøve om systemet kan overholde de krav. De områder, der kan udvælges iblandt, er: - Funktionalitetstest Denne test er også kendt som brugsmønstertest, hvor de beskrevne brugsmønstre gennemløbes. - Volumen test Er en test, hvor der efterprøves om systemet kan klare større mængder data. - Stress test Her testes systemet med en høj load, hvor der er mange brugere af systemet på én gang. - Brugbarhedstest Tester om systemet er brugbart, dvs. om systemet indeholder de funktioner, som er listet i tabel Sikkerhedstest Tester sikkerheden i systemet, dvs. om det er muligt at omgå sikkerhedsforanstaltningerne. Dette skal sammenholdes med kriterierne til systemet. - Lager test Der efterprøves om persistensen håndterer lagring og læsning af data korrekt. - Præstationstest Tester systemets svartider, generelt om systemet bruger uacceptabelt lang tid på nogen opgaver. - Konfigurationstest Denne test undersøger om systemet fungerer i den hardware konfiguration, som blev specificeret. - Genopretningstest Test af systemets backup-rutiner og evne til at starte korrekt efter et nedbrud, dette kan f.eks. være systemnedbrud eller strømsvigt. - Dokumentationstest Om manualer, vejledninger og kodedokumentation er forståelige og brugbare i forhold til systemets brugere og deres uddannelsesniveau.

95 4.2. Testudførelse på systemet 83 Det er, som nævnt, ikke altid muligt eller nødvendigt at gennemføre samtlige tests i dybden. Derfor er det vigtigt først, at fastslå, hvilke punkter der er de vigtigste. Årsagen til, at der ikke er en egentlig accepttest i denne sammenhæng er, at der ikke er en kunde, der skal acceptere systemet. 4.2 Testudførelse på systemet Denne del af testafsnittet, udgør de egentlige tests som er udført på systemet, med fyldestgørende beskrivelse af både metoderne og af resultaterne. Til slut i hvert testafsnit bliver der beskrevet, hvilke former for fejl der er fundet i løbet af testen. Disse fejl bliver beskrevet opsamlingsvis senere i evalueringsafsnittet samt hvilke løsninger der er fundet til fejlene. Opsamlingen af resultaterne skal benyttes til, at vurdere hvilke problemer der skal løses i systemet, og hvilke der kan gemmes til senere opdatering af systemet, og endeligt vil der forekomme testresultater, der vurderes som uvæsentlige Udførelse af unit-test Løbende mens der udvikles nye klasser og funktioner, bliver de testet i så små dele som muligt. Det foregår primært ved, at den enkelte funktion eller klasse kaldes fra et simpelt program, som giver nogle statisk definerede variabler og argumenter med, ved kaldet af funktionen eller klassen. Det testes med flere forskellige sandsynlige og usandsynlige argumenter, for at efterprøve om det opfører sig efter hensigten. Måden det vises at enheden opfører sig korrekt er, at vurdere outputtet i henhold til inputtet, med henblik på en foruddefineret opfattelse af, hvordan koden skulle opføre sig. Forskellen på om udvikleren tester klassen selv eller bruger NUnit, er ikke så stor. Med NUnit er det ønskede output fra en metode specificeret på forhånd, så en simpel sammenligning kan bekræfte, om outputtet er korrekt. Ved den anvendte metode med tests undervejs i programmeringsforløbet, er det udvikleren selv, der skal tage stilling til, om outputtet svarer til det ønskede og dermed er korrekt. Eftersom testen udføres for hver lille del af systemet og enheden rettes med det samme fejl opstår, er der ikke nogen konkret problemliste eller rettelser hertil. En udvidelse af denne test kunne være at bruge programmet NUnit Udførelse af integrationstest Der er ikke udført nogen decideret integrationstest under programmeringen af systemet, men alligevel er systemet blevet testet. Den form for integrationstest der er blevet udført på systemet er, at efter et modul eller en klasse er blevet integreret i systemet, blev det meste af systemet testet i henhold til det nye modul. Dette blev gjort efter integrationstestens præmisser, ved at give systemet et input og observere om det giver det korrekte output. Som ved Unit-testen, blev de fejl der blev fundet under denne form for tests, rettet eller udbedret umiddelbart efter de blev fundet Udførelse af tidlig tænk-højt-test For at få et begreb om, hvordan en udefrakommende person, opfatter den generelle brugervenlighed i systemet, er der udført en enkelt tænk-højt-test på en enkelt testperson. Testen er udført på en kørende prototype, for tidligst muligt, at finde problemer med brugervenligheden. Årsagen til testen kun er udført på en enkelt person er, at testens formål, blot er at

96 84 Kapitel 4. Test & evaluering give et begreb om, hvorvidt systemet synes at være lige til for udefrakommende personer. Herudover er brugervenligheden af systemet, ikke blevet prioriteret tilstrækkeligt højt, til at udføre en mere omfattende test. Den mere omfattende test, vil blive udført efter systemet er udviklet færdigt, og vil være en del af Præ-accept -testen. Før testen er blevet udført, er der blevet formuleret en enkel og kort testplan, der er som følger: Testplan - Tænk-højt-test. Formål: At teste om systemet kan bruges af målgruppen. Hovedspørgsmål: Kan målgruppen til systemet, finde ud af at bruge det? Brugerprofil: Mand på 20 år, datalogistuderende på Dat1. Har deltaget i flere computerparties. Metode: Afprøve et kørende program, i form af en prototype. Opgaveliste: Opgaver som testpersonen skal udføre: 1. Opret en ny bruger og reservér en plads. 2. Login med den nyoprettede bruger. 3. Vælg en turnering, og tilmeld et hold med to spillere. a. Fremsøg en deltager og tilføj vedkommende til holdet. 4. Logud. Omgivelser og udstyr: Denne test udføres i et testlaboratorie. Testlederrolle: At sidde ved testpersonen og stille opgaverne, mens testen forløber. Testlederen må først hjælpe, når/hvis testpersonen går helt i stå. Måling: Data der indsamles er notater og en videooptagelse til analyse. Rapport af test: Der foreligger en problemliste over denne test, der beskriver de usabilityproblemer, som testpersonen kom ud for. Testens forløb var forholdsvis kort, eftersom testpersonen ikke havde de store problemer med at gennemskue de forskellige opgaver. Det betyder imidlertid ikke testen ikke har givet et udbytte, for testen gav indblik i en række mangler og problemer. Resultatet er opgjort i problemlisten i tabel 4.1. Usabilityproblemer kan deles ind i én af tre kategorier: kritisk, alvorligt eller kosmetisk. For at et problem får fastsat en kategori, så skal testdeltageren komme ud for følgende: Kritisk: Testdeltageren forhindres i at løse opgaven, og forstår ikke hvordan informationer i systemet bruges i løsningen af opgaven. Alvorligt: Forsinkes i adskillige sekunder, og forstår ikke hvordan en bestemt funktionalitet fungerer eller aktiveres. Kosmetisk: Forsinkes i nogle få sekunder, og testdeltageren gør ting som ikke kan forklares.

97 Udførelse af præ-accepttest 85 Nr Problem Kategori 1. Pladsreservation: Når testpersonen skal vælge plads, virker det som om han går lidt i stå. Det kan betyde, enten at metoden til at vælge en plads ikke er logisk, eller fordi han ikke kan bestemme sig for en plads. 2. Opret bruger: Testpersonen giver udtryk for forvirring i sammenhæng med om de indtastede data er gemt. Han påpeger at han havde forventet en tydeliggørelse af en bekræftigelse. 3. Vælg en turnering: Idet testpersonen prøver at åbne en valgt turnering, prøver han at dobbeltklikke på rækken, men der sker ikke noget. Han finder dog hurtigt ud af at trykke på knappen, som åbner tilmeldingen. 4. Tilmeld hold: Testpersonen bruger knappen tab til at løbe gennem felterne, og er overrasket over rækkefølgen. 5. Tilmeld hold: Testpersonen er i tvivl om, hvorvidt han som holdleder, selv skal skrive sig til holdet. 6. Tilmeld hold: Efter deltagerne er udfyldt, er testpersonen igen i tvivl om hvordan bekræftelsen fungerer. Tabel 4.1: Problemliste fra tænk-højt-test. Kosmetisk Alvorligt Kosmetisk Kosmetisk Alvorligt Alvorligt Herudfra ses det, at der i problemlisten er nul kritiske, tre alvorlige og tre kosmetiske problemer. At der ikke forekom kritiske problemer er positivt, men da der kun var én testperson er det ikke en fuldt ud tilfredsstillende test. Testdeltageren fandt dog tre alvorlige problemer, som skal rettes, da de kan få en testdeltager, til at gå i stå i flere sekunder. Til sidst eksisterer der tre kosmetiske problemer, som ikke nødvendigvis behøver at blive rettet, men det kan være en god ide, da de kan gøre helhedsindtrykket af designet mere positivt Udførelse af præ-accepttest For at teste systemet i en kontekst, hvor det hører hjemme, blev der afholdt et lille computerparty, da udviklingen af systemet var ovre, som det blev foreslået i afsnittet om Plan for ibrugtagning på side 55. Computerpartyet blev afholdt i grupperum E3-112 og alle 7 udviklere deltog. Hver deltager havde den endelig version af administrationsprogrammet, og en stationær computer i grupperummet blev brugt som storskærm, og var samtidigt den maskine, hvorpå det anvendte windowsshare befandt sig. Under opsætningen af gruppecomputeren blev der oprettet en bruger med administratorrettigheder. Denne bruger blev brugt til at oprette de turneringer, som blev afholdt til computerpartyet. De områder som blev vurderet som vigtige i forbindelse med denne præ-accepttest var: Funktionalitets test af Opret Turnering, Tilmeld Computerparty, Tilmeld Hold til Turnering, Indmeld Resultat og Vis storskærm. Volumen test af bruger- og turneringskapacitet. Præstations test af systemet, for at undersøge om systemet kører hurtig nok.

98 86 Kapitel 4. Test & evaluering Det første brugsmønster Opret Turnering var det første der blev testet, og uden de store problemer, blev en ny single elimination -turnering i Tetron (Tetron er en klon af Tetris, som understøtter multiplayer) oprettet. Minimum antal hold blev sat til fem, og min og max antal spillere blev sat til en per hold. Herefter tilmeldte alle en ny deltager til computerpartyet, og tilmeldte sig herefter Tetron turneringen. For at sikre, at en turnering ikke starter før betingelsen minimum antal hold er opnået, holdt den første der tilmeldte sig turneringen øje med knappen der starter turneringen. Da der var blevet tilmeldt fem hold, blev knappen aktiv som den skulle. Da alle syv var tilmeldt turneringen, blev den startet, og på storskærmen kunne alle se, hvem de skulle spille imod. Efterhånden som kampene i 1. runde blev spillet færdige, blev resultaterne indmeldt, og på storskærmen var det muligt at følge med i turneringens progression. Turneringen foregik uden nogle problemer. Den anden turnering der blev oprettet, var en turnering i TrackMania Nations, som er et arkadeagtigt racerbilsspil. Denne gang blev minimum antal hold sat til 7, og da alle havde tilmeldt sig, blev turneringen startet. Indtil slutningen af 2. runde forløb alt planmæssigt, men da det sidste resultat for runden skulle indmeldes, opstod en fejl. Ham der tabte anden runde indmeldte at han havde tabt, men samtidigt var vinderen ved at indmelde resultatet. Taberen fik indmeldt sit resultat først, hvilket sendte vinderen videre til næste runde, hvortil han indmeldte at han havde vundet kampen, og han røg derfor direkte i finalen. Fejlen opstod fordi systemet ikke kontrollerede, om den kamp brugeren fik vist, også var den som han endte med at indmelde resultat for. Dette problem blev rettet med det samme. Den sidste turnering der blev oprettet men ikke spillet, var Battlefield 2 som er et First Person Shooter krigs spil. Turneringen blev ikke spillet, da denne del af testen gik ud på at oprette en større mængde brugere, og tilmelde dem på forskellige hold. Der blev oprettet ca. 100 deltagere. Med de originale brugere som holdkaptajner, blev der oprettet syv hold, hvor hvert hold skulle bestå af minimum 12 spillere. De eneste komplikationer under tilmeldingen af holdene var, at nogle af de deltagere, som var blevet valgt til et hold, imidlertid var blevet tilmeldt af en anden holdleder, hvilket betød, at der skulle findes nye utilmeldte brugere. Problemet med at brugere pludselig er tilmeldt på et andet hold, er ikke noget som normalt vil ske til et computerparty, da folk normalt snakker sammen om at spille med hinanden, og derfor ikke aftaler at være med på mere end et hold. Indmeldingen af resultater gik smertefrit, efter koden var blevet opdateret, så systemet kontrollerede om den kamp brugeren rapporterer resultatet til er den rigtige. Efter den sidste test blev systemets reaktionstid diskuteret, og alle var enige om, at systemet, når det køres over netværk, er langsommere end hvis det kører lokalt. Dog er det ikke så langsomt, at det er ubrugeligt, og det virker heller ikke som om programmet hænger på noget tidspunkt. Gennem denne præ-accepttest blev der fundet en alvorlig fejl, som blev rettet. Udover fejlen virkede programmet til at køre stabilt, om end det til tider virkede tungt. Ved springet fra otte brugere til de lidt over 100 brugere, kan mærkes når der søges efter holdmedlemmer, hvilket giver et delay på omkring 1 sekund. 4.3 Evaluering Evalueringen af de udførte tests, er en vigtig del af udviklingsprocessen, eftersom det er her testresultaterne samles op. De vigtigste eller mest graverende fejl rettes i systemet for at højne kvaliteten og brugbarheden af systemet.

99 Systemopdatering som følge af tænk-højt-testen 87 Alle de tests, der er udført, har deres egen overskrift, hvorunder der henvises til den givne fejl og gives en aktuel løsningsmodel Systemopdatering som følge af tænk-højt-testen Her er opsamlingen på de problemer, der blev fundet i sammenhæng med tænk-højt-testen, der blev udført på et tidligt stadie i udviklingsprocessen. Fejlene og problemerne er listet i en problemliste, som tabel 4.1 på side 84. Hvert problem har et Nr., som denne evaluering henviser til. Løsning på problemer - Tænk-højt-test. Nr. 1 Dette problem vil blive udbedret, hvis der bliver udviklet en webbaseret løsning med grafik pladsreservation. Nr. 2 Dette problem ved oprettelse af bruger, er blevet rettet ved at tilføje beskrivende tekst i formen hvor brugeren opretter sig i systemet. Rettelse af dette problem løser også problem nr. 6. Nr. 3 Problemet i denne situation, hvor brugeren forsøger at dobbeltklikke på en turnering, er rettet. Nu åbner et dobbeltklik på en turnering detaljerne for denne turnering. Nr. 4 Tabrækkefølgen er blevet rettet i alle systemets vinduer, så kontrolelementerne kommer i en, efter udviklernes synspunkt, logisk rækkefølge. Nr. 5 Dette problem løses med to ting: Den første er at der på formen fremgår en label der fortæller brugeren, at holdlederen allerede er tilskrevet holdlisten som udgangspunkt. Den anden ting er, at hvis holdlederen skriver sit navn til holdlisten og trykker Næste, kommer der en fejl om, at holdlederen allerede står på holdlisten. 4.4 Opsamling Under og efter udviklingen af systemet er der, for at finde forskellige typer af fejl og forslag til forbedring, blevet udført forskellige black- og whitebox-tests. Om disse tests er der i dette afsnit beskrevet, hvad de går ud på, og hvordan de er blevet udført under udviklingen af systemet. Gennem dette afsnit er en række testmetoder blevet undersøgt her er en hurtig gennem gang af dem. En unit-test bruges til at teste om de enkelte klasser opfører sig efter hensigten. En integrationstest bruges til at teste, om klasserne fungerer sammen. Tænke-højt-tests bruges til at teste om der forefindes usability -problemer i systemet. Testdeltagerne er ikke tilknyttet udviklerstaben og kender ikke til systemets udviklingsproces. Den sidste testmetode, som er gennemgået i denne rapport, er præ-accepttest, hvor udviklerne tester systemet, sådan som de regner med brugerne vil bruge det. Det er forskelligt fra test til test, om de fundne fejl er dokumenteret i rapporten, men fælles for dem alle er, at de er blevet rettet på bedst mulige måde i systemet. Selvom tænkehøjt-testen blev udført på en meget tidlig prototype af programmet, har den blandt andet givet et godt indblik i, hvordan en udefrakommende person opfatter systemets brugergrænseflade, og hvilke fejlfortolkningsmuligheder der er i denne. Disse fejl er svære at finde for udviklerne, da de kender programmet ud og ind.

100

101 Kapitel 5 Konklusion Den endelige opsamling vurderer og diskuterer det komplette udviklingsarbejde i sin helhed. Den indeholder afrundingsvis, om systemet lever op til de krav der er blevet stillet som udgangspunkt. Konklusionen behandler både udviklingens mangler, såvel som tilkommende idéer gennem udviklingsperioden. En metode til at efterprøve om det udviklede system lever op til de retningslinjer der er for det, er ved at sammenholde det med systemdefinitionen fra analysen på side 3. En hurtig opsamling af BATOFF-kriterierne i systemdefinition, giver overordnet et klart billede af at systemet skulle kunne administrere deltagere og deres tilmeldinger, planlægge turneringer, samt kunne formidle nyttige informationer, eksempelvis via en storskærm, til et computerparty. Disse funktionaliteter og krav må siges alle at være opfyldt, så overordnet følger systemet systemdefinitionen. Der er enkelte ting der er blevet afgrænset igennem udviklingsfasen, hertil nævnes web-siden med mulighed for tilmelding. Idéen med websiden blev afgrænset, da en tilmelding og simpel pladsreservation i forvejen var mulig i systemet. Dette betød at tilmelding og pladsreservation blev nedprioriteret og dermed afgrænset. Endeligt var det idéen at systemet skulle kunne holde styr på betalinger, hvem der havde betalt og hvem der ikke havde, men dette er også afgrænset, da det blev set som unødvendigt i sammenhæng med dette projekt. Herudover var det et krav, at der skulle være mulighed for flere klienter der kører systemet simultant. Denne mulighed er implementeret, men ikke optimalt. Problemet er, i klientsammenhæng, at som systemets persistenslag er udviklet, vil der være risiko for, at to instanser af programmet læser eller skriver til den samme fil på samme tid. En mulig løsning på dette problem er, at implementere en låsemekanisme, som låser de filer en instans af systemet benytter, så andre instanser ikke kan få adgang på samme tid. En anden løsning er, at implementere et andet persistensplugin, som f.eks. benytter sig af en database, hvilket giver meget større sikkerhed i persistens-lagringssammenhæng. Klient-delen er muliggjort, ved implementation af en indstilling i en AdminCP.ini-fil ved systemets rod (i samme sti som den eksekverbare fil). Denne ini-fil skal indeholde en path som sættes lig den sti, hvor alle de nødvendige data befinder sig. For eksempelvis at køre systemet over netværk, skal der sættes en netværksdeling op, med de aktuelle filer, og stien i ini-filen sættes til denne sti. Når programmet køres med denne ini-fil, hentes persistensen fra den sti der er defineret i stien. Uden ini-filen hentes persistens fra den lokale sti. Systemets primære stakeholders er crew-medlemmer og deltagere. Dette betyder, at det er crew der primært skal kunne operere med systemet, mens den enkelte deltager ligeledes 89

102 90 Kapitel 5. Konklusion også skal kunne arbejde med systemet. Systemets betingelser kræver, at crew er frivillig personel og at de har stor entusiasme, samt middel til høj computerkundskaber, hvilket enkelt sagt betyder, at systemet skal overholde de generiske designbeslutninger, for at have en gennemgående og selvsigende brugergrænseflade. En sammenligning mellem brugergrænsefladen og designbeslutningerne viser, at systemet stort set følger beslutningerne, med enkelte undtagelser. Brugertests af systemet skal vise om systemet er tilstrækkeligt brugervenligt. Foruden BATOFF-kriterierne er der også fastlagt en prioritetstabel (tabel 1.6 på side 24), som fastlægger hvilke dele af systemet, der skal lægges mest vægt på. Det er derfor en god idé, at eftergå disse prioriteringer, og se om de passer sammen med det implementerede system. De dele der er prioriteret Meget Vigtigt er Effectiveness, Efficiency, Utility og Helpful. I og med, det er et administrationsværktøj som virker, må systemet siges at være Helpful, derfor konkluderes det at være opfyldt til en tilfredsstillende grad. Herudover er der Utility, som også er opfyldt i en tilfredsstillende grad. Efficiency og Effectiveness synes dog godt at kunne forbedres yderligere. En årsag til at disse ikke menes tilstrækkeligt opfyldt er, at systemet kunne være mere effektivt på flere områder, her bl.a. i sammenhæng med persistensen, hvor systemet kan optimeres ved f.eks. at lagre og læse fra en database. Gennem udviklingsperioden er der kommet nye tiltag, som viste sig at være til fordel for systemudviklingen, systemet, eller brugen af samme. En af disse tilføjelser var implementationen af plugin-konceptet. Idéen har vist sig fordelagtig i flere sammenhænge, som muligheden for at tilføje turneringstyper efter ønske, og muligheden for at ændre persistensen til at lagre og læse data via andre metoder end serialisering af filer. Idéen kommer særligt til sin ret i sammenhæng med videreudvikling, hvor det er nemt at udskifte gamle plugins med nogle nye, eller bare tilføje nye. Dette betyder også at systemet er mere eller mindre fremtidssikret, i og med der blot skal udvikles nye plugins, hvis der kommer ny teknologi eller nye turneringstyper. Endeligt kan det tilføjes, at de tests der er blevet udført på systemet, har givet en god kritik og har vist en stor del mangler og fejl, både programmeringsmæssigt og i brugssammenhæng. Resultater på unittests og integrationsstests er taget til efterretning som systemets units er udviklet og samlet til en helhed. Hvilket har medført at eventuelle fejl ikke er blevet glemt, imidlertid har det også den betydning, at der ikke er nogen problemliste, eller fejlrapport over disse tests. Opsamlingsvis viser det sig, at det er lykkedes, at lave et system der overholder de vigtigste krav og ønsker. Det er i stand til at generere turneringer og vise dem på en storskærm, herudover er der mulighed for administration og tilmelding af samtlige deltagere. Systemet har en enkel grafisk brugergrænseflade, og kan give deltagere en god og indholdsrig information om turneringer, kampe, hold og deltagere.

103 Litteratur [1] Dreamhack. Dreamhack - The World s Largest Computer Festival, Besøgt d. 14/12/06. [2] Lars Mathiassen, Andreas Munk-Madsen, Peter Axel Nielsen & Jan Stage. Objektorienteret analyse & design Forlaget Marko ApS, Aalborg., 3. udgave, [3] Jennifer Preece, Yvonne Rogers & Helen Sharp. Interaction design, Beyond humancomputer interaction John Wiley & Sons, Inc., 1. udgave, [4] Gitte Tjørnehøj. Systemanalyse og Design, Efterårssemesteret 2006, Slides, Besøgt d. 28/11/06. [5] Craig Larman. Applying UML and Patterns. John Wait, 3. udgave, [6] Chris Sells & Michael Weinhardt. Windows Forms 2.0 Programming. Addison Wesley Professional, 2. udgave, [7] Steve Chapel m.fl. Usage share of web browsers, Besøgt d. 24/10/06. [8] Microsoft Developer Network (MSDN). Microsoft Visual Studio Developer Center, Besøgt d. 15/11/06. [9] Microsoft Developer Network (MSDN)..NET Framework Class Library, Besøgt d. 08/11/06. [10] IC#Code. Sharp Develop Homepage, Besøgt d. 22/11/06. [11] Novell Mono Group. Mono-project Homepage, Besøgt d. 22/11/06. [12] Stig Bang, Stig Efsen, Peter Hundborg, Henrik Janum, Lars Mathiassen & Christian Schultz. Kvalitetsstyring i systemudvikling. Teknisk forlag, 1. udgave, [13] Kurt Nørmark. OOP, Efterårssemesteret 2006, Slides, Besøgt d. 28/11/06. [14] Jan Stage. DIEB, Efterårssemesteret 2006, Slides, Besøgt d. 30/11/06. [15] NUnit.org. NUnit, Besøgt d. 28/11/06. 91

104 92 Litteratur 5.1 Kildekritik Igennem rapporten er der anvendt kilder til at understøtte indholdet og konteksten af rapporten. Dermed er kildernes kvalitet, faglighed og korrekthed et vigtigt element for troværdigheden af rapporten. Kvaliteten af disse må dermed ikke undervurderes, da de er fundamentet for rapporten Kriterier for den kvalitative kilde Til sikring af en kildes kvalitet opstilles kriterier, som en kilde kan opfylde i mere eller mindre grad. Dermed sagt at en god kilde godt kan have enkelte kriterier, som ikke er opfyldt, men dermed ikke sagt at en god kilde kan undvære alle eller størstedelen af kriterierne. Kriterierne er hermed følgende for en god kilde: - Oplyst forfatter/forfattere på kilden? - Hvor mange/hvilke kontaktoplysninger er der til forfatteren? - Hvordan har forfatteren formuleret kilden (f.eks. datalogisk, politisk)? - Hvilken forfatningsdato er der opgivet? Er den ny eller gammel? - Hvem har publiceret kilden? - Hvorfor er kilden blevet skrevet? - Er der lavet revisioner af kilden? Hvilken revision er brugt? - Er forfatteren subjektiv eller objektiv? Den enkelte kildes kvalitet Her opstilles de mest bærende kilder og sættes op imod de opstillede kriterier for at validere kilderne. Kilderne, i form af de bøger og slides fra kurser og forelæsninger, der har været anvendt sideløbende med udviklingsforløbet, bliver alle vurderet til at være kvalitative kilder, i og med de er anbefalet af forelæserne i fagene. Enkelte af kilderne er endda forfattet af forelæserne. Årsagen til at forelæserne vurderes som kvalitative, er at udviklingsperioden har fulgt forelæsningerne, og det er dermed forelæsningerne, der har lagt dagsordenen for udviklingens faser et langt stykke igennem rapporten. De kilder er dermed også de vigtigste og mest betydningsfulde. De her omtalte kvalitative kilder er bogen Objektorienteret analyse & design [2], som er brugt i SAD-kurset, der giver gode teknikker og eksempler til objektorienteret analyse og design. Denne bog er støttet op med bogen Kvalitetsstyring i systemudvikling [12]. Herudover er der bogen Interaction design, Beyond human-computer interaction [3], som er brugt i sammenhæng med DIEB-kurset, der ligeledes indeholder teknikker og eksempler i sammenhæng med Human-computer Interaction eller HCI. Ydermere har der været gode eksempler til strukturering i UML fra bogen Applying UML and Patterns [5]. Udover bøger er der brugt slides fra de enkelte kurser og forelæsninger, hertil nævnes slides fra SAD [4] og fra DIEB [14]. Til de mere tekniske dele er der brugt fagtekniske bøger, opbakket af slides, fra kurset OOP [13]. En bog, der er brugt i denne sammenhæng, er Windows Forms 2.0 Programming [6], som har givet indblik i, hvordan brugergrænsefladeprogrammering fungerer.

105 Den enkelte kildes kvalitet 93 Af kilder, der ikke er støttet op om i kurserne, er der en kilde der bruges til at få statistik ud, om størrelsen på computerpaties, det er kilden [1]. Kilden har ingen henvisning til en egentlig forfatter, men det må forventes, at crew bag Dreamhack har styr på hvor mange deltagere, der egentligt har været. Det kan dog betvivles om hvorvidt de har skrevet et større tal, for at få computerpartyet til at virke større. Det ses dog bort fra her, da erfaringer siger, at tallet synes realistisk. En anden statistik kilde fortæller om, hvor mange brugere der er af de forskellige browsere. Kilden er Wikipedia, der giver hvem-som-helst mulighed for at skrive informationer om emnet på siden. Det betyder, at sikkerheden for, at informationerne er valide, består i, at forfatteren skal opgive fulde navn og adresse, så der er mulighed for at kontakte ham. Dette betyder at forfatteren mere eller mindre må stå ved det skrevne. Den omtalte kilde er [7]. Til de programmeringsmæssige dele af udviklingen, er der løbende brugt hjælp fra Microsoft Developer Network (MSDN) [9], som vurderes til at være en kvalitativ kilde, da det er Microsofts.NET udviklernetværk der står bag MSDN. Det er hjælpesider, der fortæller, hvad de enkelte klasser i C#.NET framework et indeholder af funktioner. Endeligt er der i rapporten beskrevet en række værktøjer, som er muligheder i sammenhæng med udvikling af programmet. Til at finde informationer om disse værktøjer, er udviklerens hjemmeside blevet konsulteret. Kilderne i denne sammenhæng er Microsoft Developer Network (MSDN) [8], NUnit.org [15], Sharp Develop Homepage [10] og Mono [11].

106

107 Bilag A Bilag Dette kapitel samler op på alle bilag der hører til rapporten. Bilag hjælper med til at opnå forståelse for et givent problemområde og/eller giver et bedre indblik i en generel situation eller sammenhæng. Bilagene er listet og beskrevet hver for sig i dette kapitel. A.1 Generel interaktionsrum På figur A.1, ses det generelle interationsrum for crew. 95

108 96 Bilag A. Bilag Turnerings browser Opret Turnering Slet Turnering Ret Turnering Turnerings View Tilmeld Hold til Turnering Afmeld hold Kamp Browser Generer turnering Kamp View Kamp Resultat Find hold Plads Browser Tildel Plads Opret Plads Slet Plads Hold Browser Ret hold Deltager Browser Ret Bruger Figur A.1: Oversigt over det generelle interaktionsrum for crew.