Administration af computerparty & turneringsplanlægning

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

En Teknisk-Naturvidenskabelig rapport Aalborg University, Computer Science Fredrik Bajers vej 7, bygning E Telefon 96 35 80 80, Fax 98 15 97 57 http://www.cs.aau.dk 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. 21-09-06, 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.

Indhold Forord Indledning v vii 1 Analyse dokumentation 1 1.1 Situationen & opgaven............................... 1 1.1.1 Formål med systemet........................... 2 1.1.2 Systemdefinition.............................. 3 1.1.3 Systemomgivelser.............................. 3 1.2 Problemområdet.................................. 8 1.2.1 Klynger................................... 8 1.2.2 Struktur................................... 8 1.2.3 Klasser................................... 9 1.2.4 Hændelsestabel............................... 13 1.3 Anvendelsesområdet................................ 14 1.3.1 Brug..................................... 14 1.3.2 Funktioner................................. 20 1.3.3 Brugergrænseflade............................. 22 1.4 Anbefalinger.................................... 26 1.4.1 IT-systemets nytte og realiserbarhed................... 26 1.4.2 Strategi................................... 27 1.4.3 Udviklingsøkonomi og tidsplan...................... 27 1.5 Opsamling...................................... 28 2 Design dokumentation 29 2.1 Opgaven....................................... 29 2.1.1 Formål.................................... 29 2.1.2 Rettelser til analysen............................ 30 2.1.3 Kvalitetsmål................................. 31 2.2 Teknisk platform.................................. 33 2.2.1 Udstyr.................................... 33 2.2.2 Basisprogrammel.............................. 33 2.2.3 Designsprog................................. 33 2.3 Arkitektur...................................... 34 2.3.1 Faktorer i sammenhæng med designkriterier............... 34 2.3.2 Generiske design beslutninger....................... 36 2.3.3 Komponentarkitektur........................... 37 2.3.4 Eksemplariske design............................ 39 i

ii Indhold 2.4 Komponenter.................................... 47 2.4.1 Brugergrænsefladekomponenten...................... 47 2.4.2 Funktionskomponent............................ 51 2.4.3 Modelkomponenten............................. 52 2.4.4 Persistenskomponent............................ 54 2.5 Anbefalinger.................................... 55 2.5.1 Systemets nytte............................... 55 2.5.2 Plan for ibrugtagning........................... 55 2.5.3 Implementeringsplan............................ 55 2.6 Programmering................................... 56 2.6.1 Implementerbarhed............................. 56 2.6.2 Kodeeksempler............................... 56 2.7 Opsamling...................................... 58 3 Implementering 61 3.1 Fra Design til Implementering........................... 61 3.1.1 Rettelser fra Designdokumentet...................... 61 3.2 Værktøj....................................... 63 3.2.1 Microsoft Visual Studio &.NET..................... 63 3.2.2 Alternativer................................. 63 3.3 Kodeeksempler fra komponentlagene....................... 64 3.3.1 Brugergrænsefladelaget.......................... 64 3.3.2 Funktionslaget............................... 69 3.3.3 Modellaget................................. 70 3.3.4 Persistenslaget............................... 74 3.3.5 Sammenhæng mellem komponentlagene................. 76 3.4 Evaluering af implementationen.......................... 76 3.4.1 Multiple instanser af programmet..................... 76 3.5 Opsamling...................................... 77 4 Test & evaluering 79 4.1 Testtyper...................................... 80 4.1.1 Blackbox og whitebox test......................... 80 4.1.2 Unit-test.................................. 80 4.1.3 Integrationstest............................... 81 4.1.4 Tænk-højt-test............................... 81 4.1.5 Præ-Accepttest............................... 81 4.2 Testudførelse på systemet............................. 83 4.2.1 Udførelse af unit-test............................ 83 4.2.2 Udførelse af integrationstest........................ 83 4.2.3 Udførelse af tidlig tænk-højt-test..................... 83 4.2.4 Udførelse af præ-accepttest........................ 85 4.3 Evaluering...................................... 86 4.3.1 Systemopdatering som følge af tænk-højt-testen............. 87 4.4 Opsamling...................................... 87 5 Konklusion 89 Litteratur 91

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

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

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 2006. 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. e-mail eller telefon, hvor arrangørerne er nødt til at bruge tid på deltagernes ønsker om pladser. vii

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

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. 1.1.1 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.

1.1.2. Systemdefinition 3 1.1.2 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. 1.1.3 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.

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

Switch Backbone 1.1.3. 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

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

1.1.3. 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.

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. 1.2.1 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. 1.2.2 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

1.2.3. Klasser 9 Turnering Hold 1 2..* Turnering 1 1..* Runde Computerparty 0..* 1 1 1 2..* 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. 1.2.3 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

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

1.2.3. 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-

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 1.10. 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.

1.2.4. 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 1.11. 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. 1.2.4 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.

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. 1.3.1 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.

1.3.1. 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).

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

1.3.1. 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