Synopsis AALBORG UNIVERSITET DATALOGISK INSTITUT. Frederik Bajers vej 7E DK-9220 Aalborg Ø Telefon

Transkript

1 AALBORG UNIVERSITET DATALOGISK INSTITUT Frederik Bajers vej 7E DK-9220 Aalborg Ø Telefon TITEL: Hjælpetræneren TEMA: Udvikling af programmel PROJEKTPERIODE: Inf1, 3. semester, september 2004 til december 2004 PROJEKTGRUPPE: d102a DELTAGERE: Jesper Møller Minh Duc Phung Morten Holst Nam Ky Tran Niels Wittrup Andersen Ole Kallehave Rasmus Eriksen Synopsis Formålet med projektet er at udvikle et system, fra idé til brugbart program. Systemudviklingsmetoden er fra OOA&D og programmeringssproget er Java. Den grundlæggende idé er at lave et system der understøtter en fodboldtræneres administrative opgaver, og på sigt lette disse. Gennem to reviews er vores dokumenter og ideer til systemet blevet vurderet, hvorefter vi har lavet justeringer herefter. Den programelle udvikling er blevet udført i Eclipse, hvor vi også har kunnet lave JavaDoc, til dokumentation af koden. Endelig har vi udført en test af programmet, der har givet os et indblik i hvad en bruger tænker om brugen af systemet. Resultatet blev et næsten færdigudviklet program, der under testen viste sig at være brugbart. VEJLEDER: Kurt Nørmark OPLAGSTAL: 10 SIDEANTAL: 137 ANTAL BILAG: 14 sider og 1 cd AFSLUTTET: 21. december 2004 Denne rapport må ikke offentliggøres eller gengives uden tilladelse fra projektgruppen. Copyright c 2004, projektgruppe d102a, Aalborg Universitet.

2 2

3 Forord Dette er Inf1-projektet fra gruppe d102a udarbejdet efteråret Temaet for projektet er "udvikling af programmel med fokus på brugergrænsefladen". Projektet beskæftiger sig med udvikling af et hjælpetrænerprogram til en fodboldtræner der kan hjælpe med det administrative arbejde, samt være med til at mindske papirarbejdet for træneren. Projektet består af tre dele: projektrapporten, der beskriver udviklingen, et program skrevet i Java samt akademisk dokumentation. Projektrapporten består af fire dele: analysedokument, designdokument, implementering og test. Hele Java-kildekoden til systemet ligger på den medfølgende cd-rom. Her ligger også JavaDoc og rapporten i pdf-format. Henvisninger til litteratur er markeret ved firkantede parenteser og refererer til litteraturlisten bag i rapporten. Forståelse af rapporten forudsætter et grundlæggende kendskab til objekt-orienteret analyse & design samt objekt-orienteret programmering. Aalborg, 16. december

4 2

5 Indhold Del I - Analysedokument 7 1 Opgaven Formål Systemdefinition Systemdefinition BATOFF Omgivelser Problemområde Anvendelsesområde Problemområde Klynger Struktur Klasser Hændelser Anvendelsesområdet Brug Oversigt Aktører Brugsmønstre Funktioner Komplet funktionsliste Specifikation af funktioner Brugergrænsefladen Dialogform Oversigt Eksempler Anbefalinger IT-systemets nytte og realiserbarhed

6 INDHOLD 4.2 Strategi Del II - Designdokument 39 5 Opgaven Formål Rettelser til analysen Kvalitetsmål Kriterier Teknisk platform Udstyr Basisprogrammel Systemgrænseflade Designsproget Arkitektur Komponentarkitektur Komponenter Modelkomponent Struktur Klasser Funktionskomponent Struktur Klasser Grænsefladekomponent Struktur Interaction space model Anbefalinger Systemets nytte Plan for ibrugtagning Implementeringsplan Del III - Implementerings-dokument Opgaven Formål Rettelser til Design Fokusområde

7 INDHOLD 10.4 Afgrænsning De praktiske detaljer Udviklingsværktøjer Datastrukturer Implementering Kodestil Brugen af JavaDoc Implementering Implementering af Modelkomponenten Implementering af IO-komponent DBadministrator Filhaandtering Tabeller og DBinitialisator Databasen Implementering af grænsefladekomponenten ProgramBGF HoldBGF TraeningBGF TurneringBGF HoldopstillingBGF Design af Brugergrænsefladen Test JUnit test Blackbox Whitebox Konklusion på JUnittest Brugertest Hold Træning Turnering Holdopstilling Overordnet Konklusion på brugertest Del IV - Akademisk dokumentation Indledning 111 5

8 INDHOLD 14.1 Indledning Valg af emne Valg Reflektioner over metoden OOA&D - Objektorienteret Analyse og Design UML - Standardiseret Diagrammeringsteknik OOP - Objektorienteret programmering Forudsætninger ved projektstart Analysedokumentet Designdokumentet Kodeproces Test Junit test Brugertest Konklusion og perspektivering Konklusion Perspektivering A Bilag 123 A.1 Interview med Træner A.2 Brugertest A.3 Test spørgsmål A.4 Referat af test, Rasmus A.5 Referat af test, Niels B CD Bilag 137 6

9 Del I Analysedokument Denne del beskriver den forudgående analyse for systemet, der skal udvikles. 7

10

11 Opgaven Formål Formålet med dette projekt er at udvikle et system, som kan aflaste en fodboldtræner. Et planlægningssystem med hovedvægt på administration af spillere, kampe, træningsprogrammer og turneringer. Derudover skal systemet kunne bruges til fordeling af forskellige arbejdsopgaver i forbindelse med kampe, som holdopstilling. Systemet skal primært benyttes i hjemmet. Dataene indeholdt i systemet skal opdateres fra en database via Internettet. I vores udgave vil opdateringen dog være simuleret, da dette ikke er vores fokus. Systemet skal desuden være let at benytte, således en længere oplæringsperiode ikke er nødvendig. Vi har valgt at lave dette administrationssystem, for at give en fodboldtræner mulighed for at overføre hans arbejdsopgaver fra papir og blyant til elektroniske medier. Dette koncept bygger på assistance til træneren og ved hjælp af systemet, kan han dermed nemmere danne sig et overblik over sine arbejdsopgaver, og få lettet sit administrationsarbejde. Endvidere giver systemet ham bedre mulighed for at arkivere sine data og hente dem igen. Fordi systemet bygger over en online database, gør dette hans arbejde mere fleksibelt, da han kan arbejde med sine opgaver på en hvilken som helst pc, der har systemet installeret. De krav der er til den pc han arbejder på, er at der forefindes en internetforbindelse, det system som vi udvikler, samt den omgivelse der skal bruges, for at systemet kan køre. 1.2 Systemdefinition Systemdefinition Systemet skal benyttes af fodboldtrænere med varierende IT-kendskab, hvorfor det skal være let at lære. Desuden skal brugeren have erfaring med en træners administrative arbejdsopgaver. Brugerne interagerer med systemet ved planlægning af aktiviteter og administration af ressourcer for et fodboldhold. Systemet skal kunne fungere på en PC med Java 2 Runtime Environment der har forbindelse til en database via Internettet. Funktionerne skal give overblik over spillere, træningsaktiviteter, turneringsplan og kampe, og støtte til planlægning og styring af træning, kampe og holdopstilling. Filosofien bag er således at udvikle et planlægnings- og administrationsværktøj til en fodboldklub, som benyttes af de enkelte træ- 9

12 1.3 Omgivelser nere. Fælles data udveksles via en database, som en administrator har adgang til. Dermed vil vi gøre nogle af de trivielle opgaver for trænerne automatiserede BATOFF Betingelser: Systemet skal benyttes af trænere med varierende IT-kendskab, hvorfor det skal være let at lære. Anvendelsesområde: Brugerne interagerer med systemet ved planlægning af aktiviteter og administration af ressourcer for et fodboldhold. Teknologi: Computer med Java 2 Runtime Environment, forbindelse til database via Internettet. Objekter: Spillere, dommere, hold, faciliteter, turneringsplan, øvelser, kampe, træningsprogram, holdopstilling og hold. Funktioner: Overblik over spillere, træningsaktiviteter, turneringsplan og kampe. Støtte til planlægning og styring af træning, kampe og holdopstilling. Filosofi: At udvikle et planlægnings- og administrationsværktøj til en fodboldklub, som benyttes af de enkelte trænere. Fælles data udveksles via en database, som en administrator har adgang til. Dermed vil vi gøre nogle af de trivielle opgaver for trænerne automatiserede. 1.3 Omgivelser Brugeren af systemet vil være en træner, der er ansat i en fodboldklub eller træner på frivillig basis. For at systemet løbende er opdateret, er der tilknyttet en administrator. For at anskueliggøre de omgivelser systemet skal indgå i har vi tegnet et rigt billede, figur 1.1. I midten af det rige billede ses træneren. Administratoren, som er et uundværligt led i systemet, hvis træneren skal kunne bruge systemet, ses til højre for træneren. Opgaver som indtastning af spilleroplysninger og reservationer af facilitet, skal træneren f.eks. ikke bekymre sig om, da de er overladt til administratoren. Træneren har til ansvar at reservere en dommer til enhver kamp som spilles på hjemmebane. Det foregår ved, at træneren sidder med en liste, over alle dommer han har til rådighed, og ringer rundt indtil han har fundet en ledig dommer. Denne metode kan dog til tider være ret uhensigtmæssig, da træneren i værste tilfælde kan være nødt til at ringe til samtlige dommere på listen, hvis kun den sidste dommer er ledig. Vi har valgt at der kun skal reserveres en dommer og ikke linjevogtere når der skal spilles en kamp, da disse opgaver varetages af trænerne på serie 4 niveau, som vores system primært skal udvikles til. En af hovedfunktionerne i systemet er udarbejdelse af træningsprogrammet, som enten kan laves fra bunden eller træneren kan modificere i et 10

13 1.3 Omgivelser Figur 1.1: Rigt billede eksisterende. Der forefindes prædefinerede øvelser i systemet, men træneren vil få mulighed for at tilføje nye øvelser, som han kan gemme i databasen til senere brug. Når der skal spilles kamp skal træneren forberede en holdopstilling. Denne holdopstilling laves ud fra de spillere som træneren har til rådighed. Ved udarbejdelse af en holdopstilling kan træneren, ligesom ved træningsprogram, oprette en ny eller redigere i en eksisterende, hvis f.eks. den nye holdopstilling skal være magen til den gamle. For at man kan stille et hold til en kamp, skal der minimum være 11 spillere til rådighed, hvis dette ikke er tilfældet, er der en konflikt. De faciliteter der forefindes i klubben kan reserveres af træneren. Hvis faciliteterne allerede er optaget på de tidspunkter hvor træneren skal bruge dem, skaber det en konflikt. Til faciliteterne er der tilknyttet noget udstyr, det vil sige at hvis træneren en dag skal bruge et motionscenter, skal han ikke reserverer de udstyr som er tilknyttet til motionscenteret. Udstyret er derfor en del af faciliteterne og skal ikke reserveres separat. Træneren har kun 11

14 1.3 Omgivelser rettigheder til at ændre i en eksisterende spillers oplysning, men han har ikke mulighed for at oprettet en ny spiller da dette er administratorens opgave. Grunden til at administratoren har fået denne opgave er, at der skal følges nogle regler før en ny spiller må spille for den nye klub. Den nye spiller skal f.eks. aflevere et gyldigt spillercertifikat. Træneren kan også give hans spillere point efter hvor godt de har klaret sig til træning og kampe. Pointsystemet er udelukkende vejledende og bruges så træneren kan se hvilke spillere der gør det godt. Dette kan være en hjælp, når han f.eks skal udarbejde holdopstilling. Når en sæson startes op, får klubben tilsendt en turneringsplan. Denne turneringsplan bliver indtastet af administratoren, men kan hvis, der opstår problemer med kamptidspunkter, enten for trænerens hold eller modstanders hold, ændres disse punkter af træneren. Hvis træneren ønsker at flytte en kamp, skal han tage kontakt til den pågældende klub det vedrører og finde en løsning på, om de kan flytte kampen. Dette kan give en konflikt da det ikke er sikkert at de kan komme frem til en ny dato for afviklingen af kampen Problemområde På det rige billede figur 1.1 ses en træners arbejdsområder. Før træning udarbejder træneren et program der præcist beskriver, hvilke øvelser der skal udføres, hvor lang tid den enkelte øvelse tager, samt den samlede tid. Øvelserne findes blandt andet ved opslag i bøger, samt ved at udarbejde nye øvelser. De forskellige øvelser er desuden delt op i kategorierne opvarmning, kondition, teknik og fysisk. En anden opgave er at lave holdopstillinger forud for kampene. Dette kan gøres udfra en vurdering af, hvilke spillere der har klaret sig godt til træning, samt hvilke spillere der er klar, dvs. skadesfri, karantænefri og ikke på anden måde forhindrede. Som minimum skal der vælges 11 spillere til en opstilling, derudover kan der vælges et antal udskiftningsspillere. Til en holdopstilling vælges formationen der skal benyttes i den gældende kamp. Et eksempel på dette er en formation, der betyder at der stilles op med fire forsvarsspiller, fire midtbanespillere og to angribere. Op til en kamp reserverer træneren en dommer til kampen. Dette gøres ud fra en dommerliste hvor træneren ringer rundt, hvor de nærmeste kontaktes først. Reservation af baner foretages fra sæsonstart, altså kun én gang, mens andre faciliteter, såsom motionsrum, foretages løbende under sæsonen. På figuren ses også de områder der varetages af administratoren i klubben. Når en turnering starter, får klubben tilsendt en turneringsplan med datoer for kampene. Denne bliver efterfølgende videresendt til træneren. Et andet område administrator tager sig af er ind- og udmeldelse af spillere i klubben. Når en spiller er meldt ind i klubben tilføjes spilleren efterfølgende til et hold. Når en træner foretager en reservation af faciliteter, registrerer administrator dette. 12

15 1.3 Omgivelser Anvendelsesområde Brugerne af vores system er henholdsvis en træner samt en administrator. Disse skal kommunikere med systemet via en grafisk brugergrænseflade og på den måde få adgang til dele af problemområdet. Vi beskæftiger os kun med udarbejdelsen af brugergrænsefladen for træneren, og ikke administratorens del af systemet. Det er intentionen at afhjælpe træneren med de trivielle opgaver, der skal udføres gang på gang. Opgaver af denne karakteristik kan med fordel automatiseres og blive udført af systemet, eller hentes fra en database hvor dataene tidligere er blevet gemt fra en tidligere brugssituation. Systemet vil være klient/server baseret sådan, at man kan tilgå dataene fra en vilkårlig pc hvor systemet og Java 2 Runtime Environment er installeret. Serveren vil komme til at stå i klubben, hvorimod klienten formentlig vil befinde sig hjemme ved træneren. I afsnit 3 findes en analyse af hvilke specifikke arbejdsopgaver og brugsmønstre de enkelte aktøre har. 13

16 1.3 Omgivelser 14

17 Problemområde Klynger Vi har valgt at gruppere vores system i tre klynger: Træning, Turnering og Klub. Træning kan beskrives som en klynge af de elementer som træneren vil bruge i forbindelse med en træningsaften, klyngen indeholder klasserne: Træningsprogram og Øvelse. Klyngen Turnering indeholder de elementer, der bruges i forbindelse med den turnering, som fodboldholdet deltager i. Denne indeholder: Dommer, Turneringsplan, Kamp og Holdopstilling. Klyngen Klub omfatter de elementer, som kan forbindes med en fodboldklub. De klasser vi har valgt at klyngen skal indeholde er: Hold, Spiller, Facilitet og Reservation. 2.2 Struktur Vi har i klassestrukturdiagrammet, figur 2.1, forsøgt at strukturere systemet, så det ligner virkeligheden så godt som muligt. Vi har derfor valgt at have to generelle klasser, Turneringsplan og Træningsprogram. Træneren får fra administrationen tilsendt en turneringsplan, som består af en række kampe. Hver enkelt kamp består af to holdopstillinger, hvor kun den ene af dem er relevant i vores system, nemlig den holdopstilling tilknyttet det hold, som vores bruger er træner for. Holdopstillingen udgøres af et antal spillere fra holdet, som træneren vælger skal stille til en kamp, dvs. 11 mand til positionerne på banen, plus eventuelle udskiftningsspillere. Spillerne i holdopstillingen bliver taget fra klassen Hold. Denne klasse består af de spillere i klubben som træner sammen, f.eks. kan der i en klub være to serie 2 hold, de vil i vores system være repræsenteret som to objekter af klassen Hold. Et hold består af et antal spillere fra klubben. Den anden generelle klasse, Træningsprogram er et program, som træneren sammensætter før en træningsaften. Træningsprogrammet består af et antal øvelser, som træneren udvælger. De sidste to klasser på klassestrukturen er Facilitet og Reservation. Facilitet dækker over klubbens faciliteter, såsom baner, omklædningsrum, motionslokaler o.l. Til klassen Facilitet hører klassen Reservation, denne klasse er tænkt som den reservation man lægger på f.eks. en bane. Hvis træneren ønsker at reservere et træningslokale eller et omklædningsrum, sker dette ved at oprette et objekt af denne klasse. Grunden til at reservation har fået en klasse for sig selv er, at man får et bedre overblik over hvem der har reserveret faciliteterne hvis reservationerne er samlet i et objekt. 15

18 2.3 Klasser F.eks. hvis træneren har reserveret en bane og et omklædningsrum til et bestemt tidspunkt, kan man se det som en samlet reservation istedet for både at skulle kigge under baner og omklædningsrum. Figur 2.1: Klassestruktur for Hjælpetræneren 2.3 Klasser Spiller Definition: En person der er medlem af klubben og kan tilknyttes et hold. Beskrivelse af tilstandsdiagram: Et spillerobjekt oprettes når en spiller indmeldes i klubben. Spillerens attributter kan ændres så det ikke er nødvendigt at slette objektet når spilleren f.eks bliver skadet og derfor bliver meldt ikke-klar. Objektet slutter med at eksistere når spilleren slettes fra systemet. Attributter: Fornavn, Efternavn, Adresse, Postnr, Telefonnr, Mobil, , CPR, Point, Position, Sparkeben, Status, Hold. 16

19 2.3 Klasser Figur 2.2: Tilstandsdiagram for Spiller Dommer Definition: En person der reserveres af træneren og som dømmer kampe. Træneren forsøger at få den dommer, som bor tættest på hvor kampen skal spilles, til at dømme kampen, derfor er det nødvendigt at kende dommerens kontaktoplysninger. Attributter: Navn, Efternavn, Adresse, Postnr, Telefonnr, Mobil, , Reservation. Hold Definition: Et hold består af spillere. Holdene er identificeret med et holdnavn. Desuden er holdene delt ind i division, alt efter hvilket niveau der spilles på. Attributter: Spillere, Holdnavn, Division. Facilitet Definition: Klassen facilitet dækker over de faciliteter som er tilknyttet klubben, som eksempelvis baner, omklædningsrum, motionsrum osv. Faciliteterne kan reserveres. Attributter: Type, Facilitetnavn, Reservation. Turneringsplan Definition: En plan der viser hvornår holdet skal spille. Bliver udarbejdet eksternt, og redigeres i tilfældet at kampe flyttes eller annulleres. Beskrivelse af tilstandsdiagram: Objektet bliver oprettet når sæsonen starter og træneren får tilsendt turneringsplanen. Objektet gemmes når sæsonen er afsluttet. Objektet slutter med at eksistere hvis turneringsplanen bliver kasseret. Attributter: Kampe, Lokation, Tidspunkt. 17

20 2.3 Klasser Figur 2.3: Tilstandsdiagram for Turneringsplan Øvelse Definition: Træneren bruger disse til at lave træningsprogrammet, som under træning udføres af holdet. F.eks. konditionstræning, styrketræning. Er fastsat på forhånd, men træneren kan tilføje eller fjerne øvelser. Attributter: Øvelsenavn, Type, Varighed, Sværhedsgrad, Facilitet. Kamp Definition: Kamp består af én holdopstililng og det hold de skal kæmpe imod, altså modstanderen. Er kampen en hjemmekamp er der mulighed for at tilføje faciliteter til kampen. Kampen indeholder desuden tidspunkt, lokation og resultat. Figur 2.4: Tilstandsdiagram for Kamp Beskrivelse af tilstandsdiagram: Objektet kamp bliver oprettet når en kamp oprettets i turneringsplanen. Kampobjektets attributer kan ændres, så der kan tilføjes eller fjernes en dommer, faciliteter og holdopstilling, uden at slette objektet for at lave ændringer og så oprette et nyt bagefter. Objektet slutter med at eksistere, hvis kampen slettes fra turneringsplanen. Attributter: Holdopstilling, Tidspunkt, Lokation, Modstander, Facilitet, Resultat, Dommer. Træningsprogram Definition: Består af øvelser. 18

21 2.4 Hændelser Figur 2.5: Tilstandsdiagram for Træningsprogram Beskrivelse af tilstandsdiagram: Objektet oprettes når træneren opretter et nyt træningsprogram. Objektets attribut kan tilføje og fjerne en øvelse. Objektet slutter med at eksistere når træneren kasserer træningsprogrammet. Attributter: Tidsperiode, Øvelser. Holdopstilling Definition: Holdopstillingen består af de spillere fra holdet der skal deltage i kamp samt evt. lånte spillere fra andre hold. Attributter: Spillere, Formation. Kamp Definition: Kamp består af én holdopstililng og det hold de skal kæmpe imod, altså modstanderen. Er kampen en hjemmekamp er der mulighed for at tilføje faciliteter til kampen. Kampen indeholder desuden tidspunkt, lokation og resultat. Attributter: Holdopstilling, Tidspunkt, Lokation, Modstander, Facilitet, Resultat, Dommer. Reservation Definition: Reservation af faciliteter foretages af træner. Attributter: Tidspunkt, Dato, ForetagetAf, Faciliteter. 2.4 Hændelser Her opsummeres de forskellige hændelser for de ovenstående klassers objekter. Til dette benyttes en hændelsestabel, tabel 2.1, hvor klasserne er listet horisontalt og hændelserne vertikalt. Tabellen er med til at vise hændelsernes indbyrdes påvirkning på objekterne, y- dermere tydeliggøres de tilfælde hvor én hændelse påvirker flere objekter. Hændelser der indtræder flere gange er markeret med en stjerne, mens hændelser der kun indtræder en enkelt gang er markeret med et plus. 19

22 2.4 Hændelser Tabel 2.1: Hændelsesdiagram Generelt ses det at ingen klasser knytter sig til mere end 11 hændelser ud af de i alt 28. Dette tyder på høj samhørighed, hvilket vil sige en god sammenhæng mellem klasserne. Ved hændelserne "Kamp aflyst" og "Flytte kamp" impliceres syv af de ti klasser, hvilket kunne give anledning til høj kobling. Kobling vil sige hvor tæt klasser eller komponenter er knyttet til hinanden. Her er det dog kobling udefra der er tale om, da der alle steder refereres til offentlige attributter i de andre klasser. Således holdes koblingen lav, hvilket også tilstræbes. [Mathiasen et al. 2001] 20

23 Anvendelsesområdet 3 For at et system er brugbart skal det passe til anvendelsesområdet. I dette afsnit kigger vi på de aktører og brugsmønstrer der er med til skabe sammenhæng mellem systemet og anvendelsesområdet, ud fra en forståelse af nogle forud definerede arbejdsopgaver. Desuden udarbejdes en komplet funktionsliste hvor de komplekse funktioner uddybes. Ved at gennemløbe denne proces øges overblikket og det giver et bedre grundlag for udarbejdelsen af grænsefladerne. [Mathiasen et al. 2001] 3.1 Brug Det system vi udvikler skal bruges af to aktører, en fodboldtræner samt en administrator Oversigt Aktørtabellen, tabel 3.1, viser brugsmønstre samt hvilke aktører der bliver berørt af de forskellige brugssituationer. 21

24 3.1 Brug Aktørtabel Aktør Træner Administrator Brugsmønster Lav holdopstilling X Lav træningsprogram X Lav øvelse X Tilføj spiller X Ændre spilleroplysninger X X Slet spiller X Tilføj facilitet X Slet facilitet X Tilføj turneringsplan X Ændre turneringsplan X X Tabel 3.1: Aktørtabel Aktører Som det fremgår af tabel 3.1 er der to aktører i vores system, som her vil blive udspecificeret. Træner Formål: Trænerens primære opgaver er at stå for træning, samt at stå for forberedelser til kampe. Desuden har han mulighed for at administrere spilleroplysninger, så længe de er tilknyttet det hold han står for. Karakteristik: Træneren vil have varierende kendskab til IT. Administrator Formål: Administratorens primære opgaver er at ind- og udmelde spillere, at tildele disse til hold, samt at tilføje turneringsplaner til systemet. Desuden har han muligheden for at ændre spilleroplysninger. Dette vil dog først og fremmest blive foretaget af træneren for det hold, spilleren er tilknyttet. Karakteristik: Administratoren vil have varierende kendskab til IT Brugsmønstre Vi har valgt at udspecificere de mest komplekse brugsmønstre med diagrammer og ibundgående beskrivelser og kun kort forklare de mindre komplekse. De tre mest komplekse brugsmønstre i forhold til vores system er listet herunder: Lav holdopstilling 22

25 3.1 Brug Lav træningsprogram Tilføj spiller Lav holdopstilling som brugsmønster På figur 3.1 ses brugsmønsteret for hvordan træneren laver en holdopstilling, som indgår i planlægningen af en kamp. Figur 3.1: Brugsmønster for lav holdopstilling Når træneren vil arbejde med en holdopstilling, skal der trykkes på fanebladet der hedder "Holdopstilling". Derefter kommer der følgende valgmuligheder: opret eller åben. Vælges opret en ny holdopstilling skal der først vælges hvilke spillere der ønskes benyttet i den givne holdopstilling. Derefter skal der vælges hvilken formation holdet skal stille op i. Når disse to trin er overstået skal træneren vælge hvilke spillere der skal spille på hvilke positio- 23

26 3.1 Brug ner i den valgte formation. Dette gøres ved at vælge en spiller og trække denne ind på den ønskede plads i formationen. Handlingen gentages indtil alle positioner er besat, spillerne der ikke er tildelt en plads, er således sat på bænken. Via menuen i venstre side er der under arbejdet hele tiden mulighed for at åbne eller slette en eksisterende opstilling samt gemme og udskrive den aktuelle. I samme menu er der mulighed for at redigere spillerlisten, altså tilføje og fjerne spillere fra listen. Tilføj spiller som brugsmønster Nedenunder ses brugsmønsteret for hvordan en træner kan se og rette i oplysningerne om de spillere han har til rådighed. Ligeledes kan han give spillerne point alt efter hvor godt de har klaret sig til træning og kamp. Figur 3.2: Brugsmønster for Tilføj spiller Træneren vedligeholder spilleroplysninger for egne spillere og giver point efter træning. Dette gøres under fanebladet "Hold", hvor spillerne er listet med navn og point fra tidligere træninger. Som standard vises trænerens eget hold, men via en combo-box i menuen til venstre er der mulighed for at se klubbens andre hold. For at se yderligere oplysninger for den enkelte spiller trykkes på navnet, hvorefter oplysningerne vises i et vindue. Der er her mulighed for at redigere og når ændringerne er lavet godkendes de og vinduet kan lukkes igen. Ønsker træneren at give point, vælges det valgte antal point ud for hver spiller og pointene kan efterfølgende gemmes. Ønskes det at ændre tidligere afgivne point, rettes dette under spillerens oplysninger som beskrevet tidligere. 24

27 3.1 Brug Lav træningsprogram som brugsmønster På figur 3.3 ses brugsmønsteret for hvordan en træner laver et træningsprogram. Træningsprogrammet omfatter også valg og oprettelse af nye øvelser. Når en træner skal lave et træningsprogram trykker han på fanebladet "Træning". Derefter Figur 3.3: Brugsmønster for Lav træningsprogram han har to valgmulighed, han kan oprette et nyt træningsprogram eller han kan åbne og slette et træningsprogram. Eksisterende øvelser er vist i oversigten til højre, mens træneren har mulighed for at tilføje nye øvelser ved at trykke på Opret øvelse. Programmet venter på at han indtaster de data, der skal stå i øvelsen. Når han er færdig med at indtaste, har han mulighed for, at lave en annullering af det indtastede eller gemme det. Begge valg fører tilbage til, at systemet står og venter på valg af øvelser. Under arbejdet med træningsprogrammet, er det via menuen i venstre side muligt at åbne eller slette et eksisterende program samt gemme og udskrive det aktuelle. Muligheden for at slette eksisterende øvelser fra databasen foreligger også. På figurerne er tilbagegang ikke synliggjort alle steder, da vi mener det mindsker overskueligheden, dette er dog altid muligt. Det er endvidere også muligt at afslutte brugsmønsteret 25

28 3.1 Brug på alle stadier, men det er kun vist i de situationer, hvor vi antager det er typisk at forlade det, igen for at bevare overblikket. Herunder har vi kort beskrevet de mindre komplekse funktioner, der ikke kræver så meget forklaring. Ændre spilleroplysninger som brugsmønster Som beskrevet under Tilføj spiller brugsmønstret, vil det altid være muligt for træneren og administratoren at ændre en spillers oplysninger. Dette gøres når en spiller er flyttet o.l. Lav øvelse som brugsmønster Træneren har mulighed for at oprette en ny øvelse, som ikke findes i øvelsesdatabasen i forvejen. Herefter kan han vælge mellem at gemme den nye øvelse eller annullere sin handling. Slet spiller som brugsmønster En spiller bliver slettet fra systemet enten fordi han holder op, bliver smidt ud eller flytter fra klubben. Denne handling kan kun udføres af administratoren. Når der trykkes "Slet spiller"bliver spillerens oplysninger slettet for bestandigt og her er der ingen mulighed for at fortryde. Der bliver derfor spurgt om godkendelse af valget, hvorefter spilleren bliver slettet fra databasen. Tilføj facilitet som brugsmønster Når nye faciliteter oprettes, tilføjes disse til listen over faciliteter der er mulige at reservere for træneren. Denne tilføjelse foretages af administratoren. Slet facilitet som brugsmønster Handling er kun tildelt administratoren, hvor denne har mulighed for at fjerne en facilitet fra systemet, når den ikke længere kan bruges eller er tilgængelig for klubben. Herefter bekræftes sletningen ellers annulleres handlingen. Tilføj turneringsplan som brugsmønster I starten af en sæson får administratoren tilsendt en turneringsplan fra fodboldforbundet, som denne indtaster i systemet. Det vil derefter være muligt for træneren at se denne plan i systemet og foretage ændringer. 26

29 3.2 Funktioner Ændre turneringsplan som brugsmønster Administratoren kan ændre den allerede indtastede turneringsplan, hvorefter dette også bliver ændret i trænerens del af systemet. 3.2 Funktioner Komplet funktionsliste På tabel 3.2 ses en komplet funktionsliste over de funktioner vi har valgt at systemet skal indeholde Specifikation af funktioner Vi har valgt at udspecificere de funktioner vi finder komplekse i funktionslisten. Opret holdopstilling som funktion Under opret holdopstilling giver programmet mulighed for at udarbejde en holdopstilling, som den skal se ud til en given kamp. Dette gøres ved først at udvælge de spillere der skal være med i holdopstillingen, udfra hele holdet. Det er desuden, under denne udvælgelse, også muligt at se hvem der har karantæne og hvem der er skadet, så der ikke bliver tilmeldt spillere til opstillingen der ikke er klar på kampdagen. Når spillerne er udvalgt vil det være muligt at vælge hvilken formation holdet skal stille op med. Dette gøres ud fra en liste med formationer, hvor der desuden også være mulighed for at træneren selv kan oprette en ny formation. Træneren "trækker" derefter spillerne ind på deres respektive pladser i henhold til den valgte formation. Opret træningsprogram som funktion I "Træning"har træneren mulighed for at planlægge er program for hele holdet. Et træningsprogram for spillerne varer mellem en time til halvanden. Programmet er som regel delt op i fire sessioner fordelt udover tiden. Træneren kan her tilføje allerede oprettede øvelser og lave en liste over hvilke aktiviteter der skal udføres til træning. Disse aktiviteter er øvelser der f.eks kan være forskellige former for taktikøvelser, konditionsøvelser m.m... Træningsprogrammet skal efterfølgende kunne udskrives samt gemmes. Under Træning skal der også være mulighed for at åbne eksisterende træningsprogrammer og derved hente inspiration til fremtidige programmer. 27

30 3.2 Funktioner Funktion Kompleksitet Type Rediger spilleroplysninger Simpel Opdater Aflæs spilleroplysning Simpel Aflæs Giv point til spiller Simpel Opdater Redigering af point Medium Opdater Opret holdopstilling Kompleks Opdater Slet holdopstilling Simpel Opdater Åben holdopstilling Simpel Aflæs Rediger holdopstilling Medium Opdater Gem holdopstilling Simpel Opdater Vælg spiller Simpel Opdater Vælg formation Simpel Opdater Vælg position Simpel Opdater Opret træningsprogram Kompleks Opdater Slet træningsprogram Simpel Opdater Åben træningsprogram Simpel Aflæs Rediger træningsprogram Medium Opdater Opret øvelse(r) Medium Opdater Slet øvelse(r) Simpel Opdater Rediger øvelse Medium Opdater Tilføj øvelse(r) Simpel Opdater Gem spilleroplysninger Simpel Opdater Godkend valg af spiller Simpel Opdater Rediger spillerliste Medium Opdater Fortryd valg af spiller Simpel Opdater Rediger formation Medium Opdater Rediger position Medium Opdater Slet holdopstilling Simpel Opdater Udskriv Medium Aflæs Vælg eksisterende øvelse Simpel Aflæs Indtast data Simpel Opdater Annuller indtastning Simpel Opdater Gem data Medium Opdater Gem Træningsprogram Medium Opdater Tabel 3.2: Funktionsliste 28

31 3.3 Brugergrænsefladen 3.3 Brugergrænsefladen Det har stået klart fra starten, at en velfungerende brugergrænseflade til kunden er en vital og bærende del af systemet. Brugergrænsefladen skal virke intuitiv og letforståelig, hvilket er vigtigt for en fodboldtræner der ikke bruger systemet så ofte. En brugergrænseflade, der er opbygget som de kendte grafiske systemer f.eks Windows med menustrukturer, værktøjsbjælker, faneblade og scrollbar, vil være en stor fordel både i relation til indlæring og anvendelighed da næsten alle har haft kontakt med systemerne Dialogform Grundlæggende står valget mellem funktionsorienteret og objektorienteret dialogform, men i vores tilfælde skal vi ned på et mere detaljeret niveau. Vi skal finde en passende blanding, hvor balanceringen mellem de fire dialogformer, der opfylder de fire kriterier som er at: Dialogen skal være enkel, naturlig og konsistens. Krav til brugeren hukommelse skal være minimale. Feedback skal være informativ og konstruktiv. Fejl skal forebygges Vi vil primært benytte dialogformen Direkte Manipulation, som kommer til udtryk ved at man bl.a. kan trække en spiller fra holdopstilling til hans placering på banen og at man kan trække en øvelse over i et træningsprogram. Denne dialogform er valgt fordi, vores brugere ikke benytter systemet så meget. Derfor skal det være intuitivt, hvilket vil sige: Let at lære Let at huske Det andet dialogmønster, der også indgår i vores system er Menuvalg. Det kommer til udtryk ved diverse lister af valgmuligheder f.eks. ved brugergrænsefladen for Spiller, hvor det er muligt at give point til hver enkelt spiller, og for at vælge hvilken del af systemet der ønskes at arbejde med. Som sidste dialogform bruger vi Skemaudfyldelse. Denne form bliver brugt når administrateren tilføjer en ny spiller til systemet. De to sidste nævnte dialogformer bliver ikke brugt i så høj grad, som Direkte Manipulation. [Mathiasen et al. 2001] 29

32 3.3 Brugergrænsefladen Oversigt Figur 3.4: Navigationsdiagram for opret træningsprogram 30

33 3.3 Brugergrænsefladen Figur 3.5: Navigationsdiagram for lav holdopstilling 31

34 3.3 Brugergrænsefladen Eksempler I dette afsnit vil kigge nærmere på grafisk brugergrænsefladerne, der benyttes i systemet. Indtil videre er systemet delt op i fire hoveddele: Hold, Træning, Turnering og Holdopstilling. Vi vil komme nærmere ind på hvad de forskellige dele dækker over og hvordan funktionaliteten er tænkt. De data som fremkommer på eksemplerne er ikke valide. Figur 3.6: Eksempel på brugergrænseflade for Hold Systemet er bygget op omkring faneblade og hvert faneblad har fået et navn, der angiver hvad man kan forvente at finde oplysninger om. Trykker man på fanebladet Hold, dukker en spillerliste op, delt op med relevante oplysninger for de enkelte spillere. Yderligere oplysninger kan findes ved at trykke på spillernavn. Derved kommer et skærmbillede frem hvor træneren kan se spillerens position på banen, navn, adresse, telefonnummer og andre relevante oplysninger. Hvis træneren ønsker at ændre i oplysningerne så trykker han på Rediger oplysninger og indtaster de nye oplysninger. Når de er gemt eller handlingen annulleret, kommer han tilbage til ovennævnte vindue igen. Træneren kan give de forskellige spillere point efter hvor godt de har klaret sig til træning, og pointene kan efterfølgende gemmes i databasen. Træneren har mulighed for at udskrive 32

35 3.3 Brugergrænsefladen kontaktoplysninger fra hele sin spillerliste, men også markere de ønskede spillere og så få dem udskrevet. Figur 3.7: Eksempel på brugergrænseflade for Træningsprogram Det næste faneblad omhandler træningprogram. Hver gang der er træning skal træneren have lavet et træningsprogram, som han kan følge. En træner har mulighed for at åbne et eksisterende træningsprogram eller lave et nyt. En træning er opdelt i fire sessioner, opvarmning, fysik, kondition og teknik. Til hver session tilhører der nogle øvelser som træneren selv har oprettet i systemet. Træneren kan sammensætte et program ud fra tidligere indtastede øvelser, men han har også mulighed for at oprettet en ny øvelse til de træningsprogram han er i gang med at lave. Til de forskellige øvelser er der angivet et ca. minuttal sådan at han kan følge med i hvor lang tid hver øvelse tager. Træneren kan ved hjælp af Drag & Drop trække de øvelse han ønsker at benytte til træningsprogrammet. Når øvelserne bliver ført over kan han se den samlede tid som træningsprogrammet tager. Når han har lavet det ønskede træningsprogram kan han udskrive og gemme det. 33

36 3.3 Brugergrænsefladen Figur 3.8: Eksempel på brugergrænseflade for Turneringsplan Fanebladet turnering indeholder turneringsplan, som bliver indtastet af en administrator. Træneren har nogle forskellige muligheder med turneringsplanen. Han kan vælge at udskrive hele turneringsplanen men han kan også afkrydse nogle enkelte kampe. Når kampen er blevet spillet kan han indtaste resultatet af kampen og gemme disse i en database. Selvom turneringsplanen bliver indtastet af administratoren har træneren stadig mulighed for, at ændre i den hvis det nu bliver aktuelt at en kamp skal flyttes. Dette gøres ved at markere den kamp det drejer sig om og dernæst trykke på ret kamp. Så kommer skærmbillede på figur 3.9 frem. 34

37 3.3 Brugergrænsefladen Figur 3.9: Eksempel på brugergrænseflade for Ret en kamp På dette skærmbillede kan træneren ændre spillestedet, tidspunktet og datoen for kampen. Når de nye informationer er indtastet kan han gemme eller annullere. Uanset hvilken en af knapperne han vælger kommer han tilbage til turneringsplanen igen med eller uden ændringer. 35

38 3.3 Brugergrænsefladen Figur 3.10: Eksempel på brugergrænseflade for holdopstilling Når der skal spilles en kamp skal træneren have lavet en holdopstilling. Dette gøres under fanebladet "holdopstilling". Træneren har mulighed for at åbne en eksisterende holdopstilling eller oprette en ny. Det første træneren bliver mødt med, er en liste over hvilke spillere han har til rådighed på de forskellige pladser. Hvis der er en spiller som ikke er på spillerlisten, kan træneren tilføje en spiller til listen og derved får han mulighed for at benytte spilleren i holdopstillingen. Til en holdopstilling skal træneren benytte 11 spillere og et antal udskiftningsspillere. Når træneren ved hvilke spillere der skal indgå i hans trup, vælger han hvilken formation han ønsker at holdet skal have den pågældende kamp med. Dernæst vælger han en position og begynder at tilføje de ønskede spillere, til banen i venstre side af skærmbilledet. Selvom spillerne er delt op i fire kolonner så har træneren stadig mulighed for at sætte, for eksempel en forsvarspiller ind i angrebet. Så kolonnerne er til for at danne et overblik. Når træneren har færdiggjort sin holdopstilling, kan han udskrive denne og gemme den. 36

39 Anbefalinger IT-systemets nytte og realiserbarhed Flere af en fodboldtræners opgaver består af arbitrært mange trivielle handlinger, der tidsmæssigt kræver mange ressourcer. Med vores system søger vi at automatisere disse opgaver, således at trænerens administrative arbejde gøres lettere, da alle informationer om holdet er samlet i systemet. Umiddelbart foreligger der ikke nogle hindringer for at realisere systemet. 4.2 Strategi Da vi i dette projekt vil koncentrere os om trænerens del af systemet, vil vi benytte os af en simuleret internetopkobling til en database. Databasen vil ikke blive udviklet i det omfang, den i det endelige system vil have, men kun omfatte den begrænsede del der er nødvendig for at vise funktionaliteten af systemet. 37

40 4.2 Strategi 38

41 Del II Designdokument I dette afsnit vil vi starte på at designe vores system. Systemet bliver designet ved hjælp af forskellige metoder der er beskrevet i OOA&D. 39

42

43 Opgaven Formål Formålet med designdokumentet er at strukturere systemet. Der vil blive udarbejdet en arkitektur over systemets komponenter, således at der bliver sat rammer for den videre udvikling af systemet. Udarbejdelsen af designdokumentet sker ud fra de overvejelser vi har gjort i analysedokumentet. Designdokumentet ender op med en beskrivelse af, hvordan vi ønsker systemet designet og ligger derved op til den næste fase i projektet, som bliver at programmere selve produktet Rettelser til analysen Der er siden analysen blevet tilføjet klassen Formation, for at aflaste klassen Holdopstilling. DBAdministrator er ligeledes tilføjet for at mindske antallet af funktionskald fra brugergrænsefladen til modelkomponenten Kvalitetsmål For at prioritere vores designmål har vi opsat kriterier for systemet og beskrevet hvordan vi vægter de forskellige kriterier i henhold til systemet. Nedenfor ses en beskrivelse af disse kriterier og der er vurderet, hvilke af disse der er relevante for systemet og i hvilken grad. For at anskueliggøre kriterierne og deres vigtighed er de opstillet i tabel 5.1, der giver et overordnet billede af hvor designmålene er lagt. [Mathiasen et al. 2001] Kriterier Brugbart Dette kriterium er vægtet som værende vigtigt, da træneren skal kunne finde rundt i systemet uden de store problemer. Vi kan ikke med sikkerhed sige noget om trænerens it-kvalifikationer og derfor skal systemet være brugervenligt. 41

44 5.1 Formål Sikkert Da systemet bliver klient/server baseret, og derved skal kunne kommunikere over Internettet, burde sikkerheden være høj prioriteret, især fordi transmissionen indeholder personlige data om spillere som cpr-nr.. Men da vi kun arbejder med en lokal database i dette projekt, vil sikkerheden derfor få en mindre betydning i dette projekt, end ellers. Sikkerhed er vægtet som værende vigtig. Effektivt Da systemet ikke skal udføre store og avancerede udregninger har vi ikke lagt meget vægt på effektiviteten. Systemets størrelse taget i betragtning samt de kvalitetskrav der er opsat har vi vurderet effektiviteten som værende mindre vigtig. Korrekt Det vurderes vigtigt at systemet udvikles korrekt i forhold til de opstillede krav i systemdefinitionen og derved fungerer efter hensigten, da en træneren ellers ikke ville finde systemet nyttigt i fremtiden hvis systemet besværliggører hans arbejdsopgaver. Pålideligt Systemets pålidelighed er bestemt ud fra om systemet udfører handlingerne præcist og tilstrækkeligt, sådan det kan fungerer som et værktøj der hjælper med at løse brugerens opgaver. Derfor er pålideligheden vægtet som værende vigtigt. Vedligeholdbart Vi vurderer vedligeholdelsen af systemet som værende meget vigtig, da dette er et system der ligger op til udbygning af andre komponenter, hvis dette på et senere tidspunkt ønskes. Testbart Det er hensigten at vi vil gennemføre tests af systemet med potentielle brugere. På den måde, vil systemets korrekthed til en vis grad kunne måles efter testen. Opgaver som afspejler en træners sædvanlige arbejdsopgaver, vil kunne vise hvor godt programmet assisterer dennes arbejdsgange. Det er dog vigtig at teste om systemet virker som det skal, hvilken kan løses ved at afholde en brugbarhedstest og en systemtest. Testbart vurderes som meget vigtig. Fleksibelt Fleksibilitet i systemet anses for at være meget vigtig, da der skal være mulighed 42

45 5.1 Formål for ændringer, hvis der findes mangler eller systemet skal opdateres. Når vedligeholdbart anses som vigtigt, er fleksibilitet også en væsentlig faktor, da dette hjælper til at ændringer er lettere at foretage. Forståeligt Systemet skal være forståeligt og dette er vigtigt hvis man ønsker et overskueligt program. Forståeligheden skulle gerne have indvirkning på et større udbytte samt et mindre indviklet program. Genbrugbart Vi ingen planer har, om at bruge dele af systemet til andre systemer af samme art. Derfor er Genbrugbart irrelevant for vores projekt. Flytbart Systemets flytbarhed tages ikke i betragtning i dette projekt, da systemet udvikles i Java der er platformsuafhængig. Flytbart har vi derfor valgt at kategorisere som værende trivielt opfyldt. Integrerbart Da vores system ikke skal integreres med andre systemer, har vi ikke taget højde for dette i vores udviklingsproces. integrerbart er trivielt opfyldt. Kriterium Meget vigtigt Vigtigt Mindre vigtigt Irrelevant Trivielt opfyldt Brugbart x Sikkert x Effektivt x Korrekt x Pålideligt x Vedligeholdbart x Testbart x Fleksibelt x Forståeligt x Genbrugbart x Flytbart x Intergrerbart x Tabel 5.1: Tabel for vægtningen af designmålene 43

46 5.1 Formål 44

47 Teknisk platform 6 I dette kapitel vil vi beskæftige os med den tekniske del af vores system, og hvilke valg vi har truffet med hensyn til designet af systemet. 6.1 Udstyr Vores system skal bruges af bl.a. frivillige trænere, og vi mener derfor ikke at kunne kræve specialudstyr til at køre programmet på. Vi har derfor valgt at følge Java s egen minimumskrav til maskinel. Som på en computer med windows styresystem er, en pentium 166mhz med 125mb harddisk og 32Mb ram [Sun 2004a]. Programmet kræver i sin færdige udgave, at der skal være internetforbindelse, så opkobling til en server kan finde sted, og trænerens maskine kan blive opdateret med de ændringer administratoren måtte have lavet. 6.2 Basisprogrammel Udviklingsplatformen vi har valgt at programmere i, er Java 2 og den specifikke udgave er Java 2 Standard Edition - Software Development Kit Fordelen ved at programmere i Java er, at det kan køre på en hvilken som helst maskine hvor Java 2 Runtime Environment er installeret. Det vil dermed sige, at der kun skal laves ét program, som er uafhængig af hvilket styresystem der er installeret. [Sun 2004b] Til at holde styr på data i systemet har vi valgt database systemet Apache Derby. Begrundelse for dette valg er taget på baggrund af, at vi har mest kendskab og erfaring med dette system, samt at der er blevet undervist i denne database i kursuset Persistens. 6.3 Systemgrænseflade Vores system har én væsentlig grænseflade til andre systemer. Da vi har valgt opdatering over Internettet, forekommer der en grænseflade mellem systemet hjemme ved træneren, og systemet der står i klubben og benyttes af administratoren. 45