Projekt i OOAD og Databaser

Projekt i 02344 OOAD og Databaser Christian Høgh Pedersen (s125111) Christian Holm-Pedersen(s120036) Rasmus Lundsgaaard Christiansen (s123344) Anna Thideman(s124334) Philip Nicolas Adrian Velando Arosemena(s123301) 5. december 2013

Indhold 1 Introduction 1 1.1 Forord - Anna Thideman...................................... 1 1.2 Arbeidskontrakt - Anna Thideman................................. 1 1.3 Overordnet prosjektopgavebeskrivelse - Anna Thidema...................... 1 1.4 Vårt projekt - Anna Thideman og Christian Høgh Pedersen................... 2 1.4.1 Kunden............................................ 2 1.4.2 Kundens ønsker........................................ 2 1.5 Læsevejledning - Christian Høgh Pedersen............................. 3 2 Analyse 4 2.1 Vision - Christian Høgh Pedersen og Anna Thidemann...................... 4 2.1.1 Eksisterende system..................................... 4 2.1.2 Rigt billede.......................................... 5 2.1.3 Funktionelle krav....................................... 5 2.1.4 Ikke-funktionelle krav:.................................... 7 2.1.5 Rammer:........................................... 7 2.2 Aktører - Christian Høgh Pedersen, Christian Holm-Pedersen og Anna Thideman....... 7 2.2.1 Sammenhæng mellem krav og aktører........................... 8 2.3 Use Cases - Christian Høgh Pedersen, Anna Thideman, Rasmus, Christian Holm-Pedersen.. 8 2.3.1 Sammenhæng mellem krav og use cases.......................... 8 2.3.2 Kort udlægning af use case................................. 10 2.3.3 Uformel udlægning af use case............................... 10 2.3.4 Fuldstændigt use case.................................... 10 2.3.5 Navneordsanalyse...................................... 11 2.3.6 CRC Kort........................................... 12 2.4 Systemmodeller - Rasmus...................................... 12 2.4.1 Domænemodel........................................ 13 2.4.2 Systemopførsel........................................ 13 3 Design 15 3.1 Opbygning.............................................. 15 3.1.1 Klassediagram - Christian Høgh Pedersen......................... 15 3.1.2 Pakkediagram - Rasmus og Christian Holm-Pedersen................... 15 3.2 Opførsel - Christian Høgh Pedersen og Anna Thideman..................... 15 3.2.1 Tilstandsdiagram....................................... 15 3.2.2 Sekvensdiagram........................................ 16 3.2.3 Data flow - Philip Velando................................. 17 3.3 GRASP - Holm-Pedersen...................................... 17 3.3.1 Information Expert...................................... 17 3.3.2 Controller........................................... 18 3.3.3 Creator............................................ 18 3.3.4 High Cohesion........................................ 18 3.3.5 Low Coupling......................................... 19 3.4 Anvendelse af polymorfi - Philip Velando............................. 19

4 Database 20 4.1 Konceptuel - Anna Thideman og Christian Høgh Pedersen.................... 20 4.1.1 Transaktionsbekræftelse................................... 20 4.2 Logik - Anna Thideman og Christian Høgh Pedersen....................... 21 4.2.1 Transaktionsbekræftelse................................... 23 4.3 Fysisk - Christian Høgh Pedersen, Anna Thideman, Philip, Christian Holm-Petersen og Rasmus 23 4.3.1 DBMS............................................. 23 4.3.2 Tabeller............................................ 24 4.3.3 Triggers............................................ 24 4.3.4 Users............................................. 24 4.3.5 Stored Procedures...................................... 24 4.3.6 Views............................................. 24 4.3.7 Indexes............................................ 25 5 Implementation 26 5.1 Programmering - Christian Høgh Pedersen............................. 26 5.1.1 AdminConnector....................................... 26 5.2 Prototype - Christian Høgh Pedersen................................ 27 5.3 Installationsvejledning - Christian Høgh Pedersen og Rasmus.................. 27 5.3.1 Database........................................... 28 5.3.2 Program............................................ 28 6 Test - Christian Høgh Pedersen 29 6.1 AdminConnector........................................... 29 6.1.1 Testplan............................................ 29 6.1.2 Testresultater......................................... 29 7 Konklusion - Alle gruppemedlemmer 32 7.1 Reflektion............................................... 32 7.1.1 Tidsmåling.......................................... 32 7.1.2 Udviklingsprocesser - Anna og Rasmus........................... 32 7.1.3 Gruppearbejde........................................ 33 7.2 Videre udvikling - Christian Høgh Pedersen............................ 34 Bibliography 34 A Analyse 36 B Brugervejledning 37 B.1 Brugere................................................ 37 B.2 Administrator............................................. 37 C Database 41 C.1 Konceptuel.............................................. 41 C.2 Logik................................................. 43

Figurer 2.1 Rigt billede - person bliver medlem ved personlig oppmøde og utfyllelse af medlemskjema.. 5 2.2 Use Case Diagram. Administratorer har interesse i alle use cases................. 9 2.3 Domænemodel............................................. 13 2.4 Oprettelse af prøvemedlem - systemsekvensdiagram........................ 14 3.1 Udsnit af klassediagram der viser hvordan klasserne er delt op.................. 15 3.2 Pakkediagram............................................. 16 3.3 Tilstandsdiagram over Opdater information -use case...................... 16 3.4 Sekvensdiagram over Opret prøvemedlem -use case....................... 17 3.5 Dataflowdiagram med aktivitetsdiagram notation over Opret prøvemedlem -use case.... 18 4.1 EER-diagram for databasen...................................... 22 6.1 Resultat af test 1, AdminConnector................................ 31 6.2 Resultat af test 2, AdminConnector................................ 31 6.3 Resultat af test 1, AdminConnector................................ 31 A.1 Rigt billede - medlem ønsker å finde oplysninger om hold, træner og lokale på FSK nettside.. 36 B.1 Prototypens loginside........................................ 37 B.2 Prototypens medlemsvisning efter administratorlogin....................... 38 B.3 Prototypens holdvisning efter administratorlogin.......................... 38 B.4 Prototypens opret hold dialog.................................. 38 B.5 Prototypens slet hold dialog................................... 39 B.6 Prototypens edit hold dialog................................... 39 B.7 Prototypens side for aktivering af statistikside, tilgængelig som administrator.......... 40 B.8 Prototypens statistikvisningsdialog. Der er diverse statistikker i hver fane............ 40

Tabeller 2.1 Sammenhæng mellem krav og aktører................................ 8 2.2 Sammenhæng mellem krav og use cases............................... 9 2.3 CRC: Medlemskab.......................................... 12 2.4 CRC: Medlem............................................. 12 2.5 CRC: Administrator......................................... 12 2.6 CRC: Ansat.............................................. 12 2.7 CRC: Træner............................................. 12 2.8 CRC: Hold.............................................. 13 2.9 CRC: Lektion............................................. 13 4.1 Entiteter................................................ 21 C.1 Medlem-attributter.......................................... 42 C.2 Ansat/Administrator-attributter.................................. 42 C.3 Træner-attributter.......................................... 43 C.4 Hold-attributter........................................... 43 C.5 Lektion-attributter.......................................... 43 C.6 Besked-attributter.......................................... 43

Kapitel 1 Introduction 1.1 Forord - Anna Thideman (Anna Thideman) Denne rapport er udarbejdet i forbindelse med et eksamensprojekt i kurset 02344 OOAD og database, efteråret 2013. Gruppen har fem medlemmer, der alle studerer på diplomingeniør-retningen Teknologi og økonomi(it-retning) på Danmarks Teknisk Universitet, undtaget Christian Høgh Pedersen der er meritstuderende. Kurset 02344 afholdes normalt på 3. semester i studieforløbet, og eksamensprojektet er det formelle grundlag for bedømmelse af de studerendes indsats på kurset. Opgaven bygger på undervisning i ovenstående kursus, samt kurser på 1. semester, hvor størstedelen af vores viden og erfaringer med Java stammer fra, mens vi på 2. semester har modtaget undervisning i MySQL. Specificering af opgaven kan findes i filen: E13ProjektDTU.pdf som ligger på campusnet.dtu.dk under siden til kursus 02344 (OBS! Kræver login). 1.2 Arbeidskontrakt - Anna Thideman (Anna Thideman) Gruppemedlemmer: Anna Thideman Christian Holm-Pedersen Philip Nicolas Adrian Velando Arosemena Christian Høgh Pedersen Rasmus Lundsgaaard Christiansen Mødested: I aftalt lokale, se skema på campusnet. Bygning 325. Forberedelse: Læs SVN-commits for at forberede sig og vide hvad som er sket siden sidste møde, og hvor langt vi er nået. Forsinkelser: Hvis et gruppemedlem er mere end 15 minutter forsinket, skal de sende en SMS og orientere gruppen. Hvis ingen kontakt efter 30 min, kontaktes medlemmet telefonisk. Sanktioner: Sover man betydeligt (cirka 30 min) over sig, eller undlader man at anmelde væsentlige forsinkelser til gruppen, skal skyldige medlem give kage/kaffe/kakao/eller lignende. 1.3 Overordnet prosjektopgavebeskrivelse - Anna Thidema (Anna Thideman) Prosjektgruppene skal bli dannet av de studerende selv, og gruppene skal velge en case selv som de vil anvende i prosjektoppgaven. I oppgaven skal man belyse relevant teori og verktøyer fra kurset 02344. I prosjektet skal gruppene altså utvikle et kjørende databaseapplikasjon, som skal utvikles på bakgrunn av et konkret behov hos en organiasjon eller virksomhet. Det må gjerne være et behov hos en virkelig bedrift. Gruppene skal utvikle en prototype, der programmet skal være menustyret slik at man kan velge mellom 1

forskjellige muligheter. Det skal også være minimum tre ulike brukere i programmet, med ulike rettigheter og muligheter. Endvidere skal det utarbeides analyse- og designdokumentasjon til prototypen, og programmet skal implementeres i programmeringsspråket Java. Også prosjektplanlegning skal utføres, dokumenteres og vurderes. 1.4 Vårt projekt - Anna Thideman og Christian Høgh Pedersen (Anna Thideman og Christian Høgh Pedersen) Udvikling af et databasebaseret system til medlemsstyring, med videre, til en sportsklub. Kunden ønsker et system der kan strømline indmeldelsen af medlemmer, samt gøre det lettere at holde styr på dem. Desuden vil de gerne have at medlemmer skal kunne bruge systemet til forskellige ting (Tilmeldning til hold, upload af billeder) 1.4.1 Kunden Fightsport Køge er en kampsportsklub i Køge [1]. Det er en forholdsvis lille klub, som har brug for yderligere redskaber til at at forøge og håndtere fremtidig vækst. Deres Hjemmeside bliver admnistreret af virksomheden Noke ApS [2], og de vil sandsynligvis også overtage driften af dette projekts produkt, såfremt det bliver taget i brug. 1.4.2 Kundens ønsker Der er brug for en medlemsdatabase, hvor de oplysninger medlemmerne lægger ind den allerførste gang vi ser dem i klubben løbende kan udbygges, så vi ikke skal have flere formularer og database, regneark osv. men har en samlet medlemsdatabase, hvor det hele er samlet samme sted. Medlemmerne taster oplysninger ind over flere gange, hvilket giver flere forskellige steder de er samlet. Det er et ønske at dette i meget højere grad bliver automatiseret. Desuden er der et øsnke om at systemet i fremtiden vil kunne udføre en række andre opgaver, som er beskrevet herunder. * Automatik på flere punkter -eks. meddelelse om manglende informationer tastet ind, betalingsstatus, kontakt foretaget/ skal foretages. * mulighed for at PBS databasen med betalinger ikke betalinger kan overføres nemt, så man ikke skal taste manuelt på alle. på den måde kan man se hvem der ikke har betalt på PBS, som der så kan få noget automatisk besked. * Mulighed for at kunne grupperer folk eks. alle nye prøvemedlemmer mhp. at de automatisk får mail/sms beskeder om de forskellige faser i indmeldelsen eks. kvitteringer * Oversigt over de forskellige hold. Folk krydser af ved oprettelsen hvad hold de går på og selv får mulighed for at holde det ved lige * Et personaleblad på hvert medlem, hvor de selv kan logge ind og rette oplysninger, lægge billeder osv. * Integration med en sms service, så der kan sendes gruppe sms er afsted til de grupper der er behov for eks. ved aflysning at alle på holdet kl. 1700 får besked * En mulighed for at kunne tilmelde sig forskellige hold, så andre kan se hvor mange deltagere der er (klik på websitet) og vi kan aflyse/ informerer ved under eks. 3 deltagere * En login skærm til at melde sig tilstede i klubben - noget man kan klikke på når man kommer ind, så vi kan følge hvor mange der kommer og træner på hvilke tidspunkter * En app til telefoner, der melder en tilstede/ forladt igen når man forlader klubben, så man ikke manuelt skal melde sig til og fra, men man har sagt ja til at gps trackeren må melde en til. 2

1.5 Læsevejledning - Christian Høgh Pedersen (Christian Høgh Pedersen) Ved hver sektion i denne rapport er det beskrevet hvilke gruppemedlemmer der har arbejdet på den givne sektion. Dette er angivet i kursiv i starten af sektionen. Står det intet under en sektion, så kan du regne med det er skrevet av det navnet/navnene som står på oversåtende sektion. E.g. kan det ses at denne sektion er skrevet af Christian Høgh Pedersen. Den fastlagte grænse for sideantallet på 30 normalsier er overholdt, såfremt man påregner at eksempelvis billeder såsom diagrammer og figurer svarer til 700 ansalg per styk. Derudover er der mange steder meget ubrugt plads. Eksempelvis har denne dette kapitel meget spildplads for at holde rapporten pæn. 3

Kapitel 2 Analyse 2.1 Vision - Christian Høgh Pedersen og Anna Thidemann Christian Høgh Pedersen og Anna Thidemann Vi, gruppe 13, er kommet i kontakt sportsklub FightSport Køge, og har lavet en aftale om at designe et produkt til dem i forbindelse med projektarbejdet i kurset 02344 - OOAD og databaser - efteråret 2013. Vi har givet opgaven navnet Medlemskartoktek til Sportklub i Køge. Produktet som ønskes fra sportsklubbens side er et database-basert program som skal hjelpe dem til å administrere og styre klubben. De ønsker en medlemsdatabase, hvor oplysninger kan registreres, ændres, slettes, tilføjes undervejs etcetera. Information skal altså løbende udbygges, således at vores kunde(fightsport Køge) ikke skal være nødt til at have flere forskellige formularer, databaser, regneark og papirer som de har den dag i dag. Hovedformålet med dette planlagte program vil, fra kundens side, være at registrere nye medlemmer. Da dette i dag gøres over flere trin, så ønskes det at denne funktionalitet også findes i det planlagte program, men at information ikke lagres de i forskellige medier, men lagrer det et enkelt, centralt sted. 2.1.1 Eksisterende system I dag taster medlemmene opplysninger inn flere ganger, som registreres på forskjellige steder(i ulike databaser), og dette ønskes samlet i EN felles database ved hjelp av den nye program. I disse trinnene blir ulike informasjoner registrert: 1. Kundene starter med å opprette seg som prøvemedlemmer. Her får klubben noen grunnleggende opplysninger, som navn, telefonnummer, email, fødselsdato og informasjon om hva slags trening de er interessert i. Denne informasjonen er rettet mot at klubben skal kunne kontakte dem ved et senere tidspunkt. Dette lagres i en database. 2. Hvis et medlem etter prøvetiden beslutter seg for å melde seg inn, skal de utfylle et nytt formular. Her skal de gjenta en del av opplysningene, som navn, telefonnummer og email, men nå registreres det også CPR-nummer, opplysninger om hvor de bor og bankopplysninger. Denne informasjonen ender så i en helt annen database. 3. Når dette er gjort, foregår det en tredje registrering, hvor alle opplysningene blir samlet på et felles regneark. Her er det også felter som kan krysses av, så sportsklubben kan se om fakturaene er betalt, om de ønskes å kontaktes per mail eller SMS, om det er annen informasjon som er nyttig for klubben å vite om deres medlem etc. Altså de ønsker at dette i høyere grad enn nå blir automatisert, slik at medlemmene bare skriver videre på opplysningene fra prøvemedlemsregistreringen(punkt 1), når de fyller inn opplysningene som medlemmer(punkt 2). Så den siste delen med å samle opplysningene kan droppes(punkt 3). Alt for å optimere prosessen. 4

2.1.2 Rigt billede Et rigt billede brukes ofte til å få overblikk, og til å udtrykke problematiske forhold. Det skal gi insigt i situasjonen, så en løsning kan defineres og utvikles. Figur 2.1: Rigt billede - person bliver medlem ved personlig oppmøde og utfyllelse af medlemskjema Vores rige billede på Figur 2.1 viser hvordan situasjonen var hos FightSport Køge før vi begynte vårt samarbeid med dem. Billede viser hvordan det foregikk når en person ønsket at blive medlem i sportsklubben. Det hele foregikk ved at medlemmet skulle fylde ut et skjema i hånden eller online, og vedlegge det i en mail eller give det personligt til en admin i sportsklubben, hvorefter denne admin skulle skrive inn alle opplysningene i et excel-ark. Dette var en omstendig måte at gøre det på, og svært at endre i og vedligeholde. Vores program skal derfor løse dette problemet ved at et medlem skal kunne melde seg inn ved å skrive alle informationene direkte inn på nettsiden, og informationen så lagres i en database. Denne databasen kan selvfølgelig admin se og endre i. På denne måten slipper Fightsport Køge en masse arbeide og blir kvitt de uoversiktelige excel-arkene. Et annet rigt billede kan findes i bilag A.1. 2.1.3 Funktionelle krav Christian Høgh Pedersen og Anna Thidemann Beskriver krav til systemets funktion. Kravene er herunder skrevet op i en liste, og efter listen er der uddybninger af hvert krav. 1. Gemme medlemsoplysninger 2. Gemme holdoplysninger. 3. CRUD medlemsoplysninger. 4. CRUD holdoplysninger. 5. Funktionalitet skal kunne tilgås gennem en GUI. 5

6. Systemet skal kunne skelne mellem forskellige brugertyper. 7. Systemet skal benytte MySQL til at gemme data. Gemme medlemsoplysninger - Oplysninger skal gemmes centralt. - Hvert medlem skal have login info, kontaktinfo og betalingsoplysninger. Gemme holdoplysninger - Oplysninger skal gemmes centralt. - Hold skal kunne identificeres og der skal kunne skelnes mellem forskellige niveauer inden for samme type hold. e.g. skal der MMA-begynderholdet, og MMA-sparringsholdet være forskellige. CRUD medlemsoplysninger - Medlemmer skal kunne se/ændre i deres egne oplysninger, administratorer ansat af klubben skal kunne se/ændre alle medlemmers oplysninger. Klubbens trænere og andre ansatte skal have begrænset adgang til medlemsinformation. - Systemet skal give besked gennem brugergrænsefladen såfremt der er opstået en form for fejl eller inkonsistens når information indtastes. - Systemet skal indikere om medlemmer har betalt deres kontingent. Hver gang betalingsdatoer nås skal systemet checke om der er gyldige betalinger fra alle medlemmer. CRUD hold - Medlemmer skal kunne melde sig til/fra hold som de vil gå på. - Alle brugere skal kunne se hvor mange der er meldt til et givet hold. - Trænere og administratorer skal kunne give tilladelse til at folk må melde sig til de avancerede hold. - Administratorer skal kunne oprette nye hold, slette eksisterende og ændre i holdinformation. - Trænere skal kunne ændre i lektionplanen for hold de er ansvarlige for. Funktionalitet skal kunne tilgås gennem en GUI. - Brugere skal have fuld funktionalitet gennem et enkelt program. Systemet skal kunne skelne mellem forskellige brugertyper. - Når programmet starter op skal brugeren identificere sig via et login system. - En administrator har tilgang til alt og kan ændre alt. - En træner kan kontrollere adgang til avancerede hold, og oprette ekstra lektioner til hold - En ansat kan kontrollere al ikke-kritisk information. Kan e.g. se medlemmers betalinger og kontaktinformation, men ikke deres betalingsoplysninger. - Medlemmer kan se alle deres egne informationer og lave ændringer der involverer dem personligt(e.g. ændre deres egen betalingsplan, melde sig til/fra hold), men har kun begrænset adgang til resten af systemets data. Systemet skal benytte MySQL til at gemme data. - Som et krav fra Noke ApS, der vil overtage driften af systemet når det bliver taget i brug, skal oplysninger lagres gennem DBMS et MySQL, for at kunne samarbejde med deres webteknologier. 6

2.1.4 Ikke-funktionelle krav: Svartid skal være ubelastende. Systemet skal kunne bruges af personer uden særlige IT-fagligheder. Systemet skal kunne udvides i fremtiden. Svartid skal være ubelastende. - Systemet skal kunne køre på en moderne computer, uden at der opstår ventetider som vil være bemærkelsesværdige for brugeren. Systemet skal kunne bruges af personer uden særlige IT-fagligheder. - FSKs medlemmer og ansatte er ikke et IT-uddannet udsnit af befolkningen, og vil ikke bruge systemet medmindre det er meget brugervenligt. Systemet skal kunne udvides i fremtiden. - Der er en del ønsker fra FSK der ligger uden for dette projekts rammer. Disse skal kunne tilføjes af andre udviklere i fremtiden. - Databasen som udvikles i dette projekt skal understøtte disse fremtidige udvidelser, uden at der skal tilføjes nye tabeller. 2.1.5 Rammer: Aflevering Aflevering - Projektet afleveres d. 29/11/2013. På denne dato skal der være en prototype af systemet klar, og denne skal afleveres sammen med denne rapport i tre fysiske og en digital kopi. 2.2 Aktører - Christian Høgh Pedersen, Christian Holm-Pedersen og Anna Thideman Christian Høgh Pedersen, Christian Holm-Pedersen og Anna Thideman Aktører er roller brugere udfylder i forbindelse med deres brug af systemet. I dette tilfælde vil aktørens rolle i systemet typisk repræsentere deres forhold til klubben. Medlem: Person der er meldt ind i klubben. Prøvemedlem: Person der er meldt ind i klubben som prøvemedlem. Gæst: Person der ikke er meldt ind i klubben, men i gang med indmeldelsesforløb. Træner: Ansat i klubben der varetager træning på et eller flere hold Administrator Ansat i klubben der håndterer andre rolle end varetagning af hold. Medlem: Vil gerne have information omkring hold. Deres egen medlemskabsstatus. Deltager i hold. Vil kunne ændre deres egen information. Oprette sig i systemet. Gæst: Vil gerne have information omkring klubben. Vil gerne kunne udføre sit eget indmeldelsesforløb Prøvemedlem: Vil gerne have holdinformation. Vil gerne se hvilket prøvetimer de har igen. Vil gerne færdiggøre deres indmelding. 7

Ansat: Vil gerne kunne kontrollere medlemmers kontaktinformation, og at de har udført deres betalinger. Træner: Vil gerne se hvor mange der er tilmeldt hvert hold. Lave programmer for holdene. Vil kunne Give tilladelse til at medlemmer kan tilmelde sig avancerede hold. Administrator: Vil kunne se al information. Vil kunne CRUD medlemmer/ansatte/hold. 2.2.1 Sammenhæng mellem krav og aktører Se Tabel 2.1 for en oversigt over sammenhængen mellem krav og aktører. Gæst Medlem Ansat Træner Administrator Krav 1 X X X Krav 2 X Krav 3 X X X X X Krav 4 X X X Krav 5 X X X X X Krav 6 X X X X X Krav 7 Tabel 2.1: Sammenhæng mellem krav og aktører. 2.3 Use Cases - Christian Høgh Pedersen, Anna Thideman, Rasmus, Christian Holm-Pedersen Christian Høgh Pedersen, Anna Thideman, Rasmus, Christian Holm-Pedersen Vi har identificeret en række grundlæggende use cases for systemet. Disse er i denne sektion opridset, sammen med deres forhold til aktører og funktionelle krav. Use cases er summeret i den herunder følgende liste. Enkelte use cases er yderligere uddybet i kommende sektioner. Se Figur 2.2 for en oversigt over hvilke aktører der deltager i hvilke use cases. Oprettelse af prøvemedlem. Oprettelse af medlem. Kontrol af medlemsinfo. Opdatering af medlemsinfo. Se holdinfo. Kontrol af opmøde. Udmeldelse af medlem. 2.3.1 Sammenhæng mellem krav og use cases I Tabel 2.2 kan læseren se sammenhængen mellem krav og use cases Imellem krav og use cases er der tale om mange-til-mange relationer; Et krav kan forekomme i flere use cases, mens en use case kan dække over flere funktionelle krav. 8

Figur 2.2: Use Case Diagram. Administratorer har interesse i alle use cases. U1 U2 U3 U4 U5 U6 U7 U8 Krav 1 X X X X Krav 2 X X Krav 3 X X X Krav 4 X X X X Krav 5 X X X X X X X X Krav 6 X X X X X X X X Krav 7 X X X X X X X X Tabel 2.2: Sammenhæng mellem krav og use cases. 9

2.3.2 Kort udlægning af use case Et use case beskrevet i tekst. Oprettelse af Prøvemedlem Interesseret person henvises til FSK-program. Aktiverer prøvemedlemsoprettelse. Program viser en GUI hvor der kan indtastes den nødvendige information. Når information er indtastet, trykker bruger videre, og bliver præsenteret med en side hvor informationen står og de bliver bedt om at bekræfte dens korrekthed. Brugeren bekræfter, og programmet opretter en ny Medlem-tuple i databasen med den indtastede information. 2.3.3 Uformel udlægning af use case Mere detaljeret beskrivelse af et use case. Detaljerer forskellige slutresultater af use casen. Oprettelse af Prøvemedlem Main success scenario: Interesseret person henvises til FSK-program. Aktiverer prøvemedlemsoprettelse. Program viser en GUI hvor der kan indtastes den nødvendige information. Når information er indtastet, trykker bruger videre, og bliver præsenteret med en side hvor informationen står og de bliver bedt om at bekræfte dens korrekthed. Brugeren bekræfter, og programmet opretter en ny Medlem-tuple i databasen med den indtastede information. Alternate scenario:...bruger opdager fejl i information. Trykker lav ændringer. Bruger præsenteres for samme informationsside, med den information de har indtastet allerede udfyldt. Bruger laver ændringer. Bruger godkender Alternate scenario:...bruger fortryder indmeldelse. Afbryder indmeldelse ved at lukke program, eller at trykke afbryd indmeldelse. Program sletter eventuel indtastet information og lukker. Alternate scenario:...bruger standser indtastning. Efter at bruger ikke har interageret med programmet i tidsmængde laver program en besked om at indtastingstid er løbet ud. Program sletter indtastet information og vender tilbage til startside. 2.3.4 Fuldstændigt use case Opret Prøvemedlem Omfang: Niveau: Fightsport Køge(FSK) Klubstyringsprogram Brugermål Primære aktør: Gæst. Interessenter og andre aktører: Gæst: Vil gerne have sin information korrekt til klubben hurtigt og smertefrit. FSK: Vil gerne have medlemsinformation på en overskuelig måde. Vil have at brugere har en behagelig oplevelse. Administrator: Vil gerne have at det er let nok for medlemmer at oprette sig til at de ikke spørger om hjælp. Påkrævet grundlag: Ingen. 10

Resultater: Prøvemedlem er oprettet. Data er gemt i database. Kvittering er genereret til bruger. Primære succes-scenarie: 1. Gæst tilkendegiver interesse. Bliver dirigeret til program af administrator. 2. System viser muligheder for ikke-registrerede brugere. PM vælger Opret prøvemedlem mulighed. 3. System viser indmeldelsesformular. 4. Gæst indtaster information. 5. Gæst trykker Fortsæt. 6. System viser information som den er registreret, spørger om bekræftelse. 7. Gæst bekræfter. 8. System lagrer et prøvemedlem med den indtastede information i databasen. 9. System viser kvittering. 10. Gæst lukker program. Alternative forløb: *a: Any time. PM fortryder indmeldelse PM trykker afbryd indmeldelse. System sletter indtastet information. Viser startside. *b: Any time. PM standser indtasting. System venter tidsmængde. System sletter indtastet information. Viser startside og timeout-besked. 6a: Gæst opdager fejl i information. PM trykker lav ændringer. System viser information som blev indtastet. PM indtaster information og trykker gå videre. GOTO Main Success Scenario tring 7. Særlige krav: Kørende database med relevante tabeller. Variationer i teknologi: Ingen. Hyppighed: Daglig/Ugentlig. 2.3.5 Navneordsanalyse På baggrund af use cases, krav og aktører, har vi udarbejdet følgende kandidater til klasser: Medlem. Ansat. Træner. Administrator. Hold. 11

Lektion. Betaling. Medlemskab. 2.3.6 CRC Kort Som et led i designet har vi lavet flere CRC (Class-Responsibility-Collaboration)-kort. CRC Metodens formål kan minde om et Sekvensdiagram, blot lettere fordøjeligt for mennesker uden UML indsigt. Formålet med CRC-kort er at man på et tidligt tidspunkt i forløbet kan gøre brug af kortene til at udlægge et basalt sekvensdiagram, uden at være fanget af et diagrams restriktioner mens man udvikler programmet. Tabel 2.3: CRC: Medlemskab Medlemskab Medlem Medlemskabstype Betalingsplan Kender Betalingplanens pris Tabel 2.4: CRC: Medlem Medlem Medlemskab Person info Besked Event info Hold Tilmeldte lektioner Lektion Beskeder Hold Betalinger Bankinfo Tabel 2.5: CRC: Administrator Administrator Medlem Har fuld adgang til systemet Ansat Kan ændre i Ansatte og medlemmero Træner Tabel 2.6: CRC: Ansat Ansat Medlem Person info Lektion Træner Tabel 2.7: CRC: Træner Træner Hold Personinfo Lektion Ansvarlig for hold/lektioner 2.4 Systemmodeller - Rasmus (Rasmus) Indeholder domænemodel for hele systemet, og andre modeller for dele af systemet. 12

Tabel 2.8: CRC: Hold Hold Medlem Kender tilmeldte medlemmer Lektion Kender holdets lektioner Træner kender Træneren som er ansvarlig for holdet Tabel 2.9: CRC: Lektion Lektion Medlem Kender tilmeldte medlemmer Træner Info for lektionen Kender Træneren som er ansvarlig for holdet 2.4.1 Domænemodel En domænemodel beskriver problemstillinger i den konceptuelle del af analysen. Der fremgår således i modellen bud på entiteter samt deres relationer, roller og begrænsninger (constraints). Figur 2.3: Domænemodel. 2.4.2 Systemopførsel Indeholder systemsekvensdiagram og operationskontrakter for kernefunktionalitet i systemet. Kontrakt: indtastinformation Operation: confirminformationnavn: String, email: String, tlf: String, cpr: String. Krydsreference: Use Case: Opret prøvemedlem. Forudantagelser: Gæst er ved at melde sig som prøvemedlem. Resultater: - tlf konverteres til int. - MedlemData objekt oprettes. - Databaseforbindelse oprettes. - Række med medleminformation indsættes i Medlem-tabel, med information svarende til medlemd oprettet med data fra MedlemData-objekt. 13

Figur 2.4: Oprettelse af prøvemedlem - systemsekvensdiagram. 14

Figur 3.1: Udsnit af klassediagram der viser hvordan klasserne er delt op Kapitel 3 Design 3.1 Opbygning Denne sektion detaljerer hvordan systemet er bygget op. 3.1.1 Klassediagram - Christian Høgh Pedersen (Christian Høgh Pedersen) Designklassediagrammet er i store udtræk ækvivalent med analyseklassediagrammet. Det gælder dog for de klasser der er repræsenteret designklassediagrammet, at de typisk er blevet delt op i tre klasser, der udfylder forskellige roller i forhold til klassens funktionalitet. Et eksempel på denne opdeling kan ses i Figur 3.1, hvor det kan ses hvordan Admin-klassen er delt op. 3.1.2 Pakkediagram - Rasmus og Christian Holm-Pedersen (Rasmus og Holm-Pedersen) Pakkediagrammer er utrolig brugbart til at visualisere opdelingen af software klasserne i lag. Et lag er en gruppering af flere klasser, pakker eller undersystemer der har en høj sammenhørighed gennem deres funktion inden for systemet, og vil ikke ændre sig i løbet af et projekt med mindre der bliver ændret i klasseopbygningen. Disse lag er rangeret efter en top-down metode hvor de øverste lag kalder de lag under sig. D.v.s. at højere lag har mulighed for at bede lavere rangerede lag håndtere data og sende svar tilbage, mens lavere rangerende lag ikke kan kalde på højere lag(generelt). Når man ser på alle disse lag sammen på et diagram taler man om den logiske arkitektur. 3.2 Opførsel - Christian Høgh Pedersen og Anna Thideman Christian Høgh Pedersen og Anna Thideman Denne sektion detaljerer hvordan nogle dele af systemet opfører sig. 3.2.1 Tilstandsdiagram Et tilstandsdiagram er en grafisk repræsentation af en del af systemet, der viser hvilke tilstande systemet går ind i som reaktion på hændelser. De oblonge elementer er de tilstande systemet går ind i som resultat 15

Figur 3.2: Pakkediagram af de transitioner, som er pilene, der opstår. Teksten på pilene navngiver den hændelse der forårsager transitionen. Systemets opførsel er bundet op i at der er en bruger der interagerer med det gennem en GUI. Systemet fungerer derfor primært som en række af reaktioner på brugerens input. Som eksempel kan ses Opdater information -use casen, hvor et klubmedlem vil ændre sine personlige informationer v.h.a. systemet. Systemets opførsel i denne situation er illustreret i et tilstandsdiagram i Figur 3.3. Figur 3.3: Tilstandsdiagram over Opdater information -use case 3.2.2 Sekvensdiagram Sekvensdiagrammet er en udvidet version af systemsekvensdiagrammet, der også viser hvordan systemets interne komponenter reagerer opfører sig i sekvensen. Et sekvensdiagram kan sees på figur 3.4 nedenunder. 16

Figur 3.4: Sekvensdiagram over Opret prøvemedlem -use case 3.2.3 Data flow - Philip Velando (Philip Velando) Data flow diagrammet med aktivitetsdiagram notation viser flowet i use casen oprettelse af prøvemedlem og de aktiviteter henholdsvis en gæst of systemet foretager sig ved denne operation. 3.3 GRASP - Holm-Pedersen (Holm-Pedersen) Information Expert, Controller og Creator er en del af GRASP(General Responsibility Assignment Software Patterns) principperne. Disse pricipper bruges i software programmering og har til formål at strømline og optimere de forskellige dele af programmet. 3.3.1 Information Expert Princippet i designeringen af en information expert klasse er at samle al information i en enkelt klasse for dermed at lade denne klasse overtage det fulde ansvar for en specifik funktion. fx ville en klasse der indeholdte al information omkring alle medlemmer være en information expert klasse i relation til medlemmer. Dette 17

Figur 3.5: Dataflowdiagram med aktivitetsdiagram notation over Opret prøvemedlem -use case gør at man kan samle information et sted og derved samle overblikket over programmet og gøre det nemmere at tilgå efter en eventuel videregivelse af kode til programmørere eller kunden. En sammenligning ville fx. være med en chef for en afdeling eller en ekspert inden for et felt. 3.3.2 Controller En Controller klasse er brugt til at samle de forskellige kommandoer der er mulighed for i programmet for på den måde at skabe lavere kobling. Denne klasse vil lægge lige under GUI en og har det overordnede ansvar for at håndtere system operationer. Vores Statistik klasse er fx. en Controller klasse der håndterer alle statistik operationer der forekommer i programmet. Sådanne klasser bruges specifikt til at klumpe flere ens handlinger sammen, såsom oprettelsen og opdatering af bruger oplysninger. 3.3.3 Creator En Creator klasse vil have ansvaret for instancieringen af objekter der bruges af en anden klasse og ligger sig derved op af denne klasse. Ofte vil dette svare til at en Creator klasse vil lægge sig op af en Information Expert klasse som den kan hive data ud fra for at instanciere objektet A. 3.3.4 High Cohesion Høj samhørighed i en klasse er en analyse af hvor fokuseret klassens formål er. D.v.s. at hvis klassen kun har et formål, selv hvis der er flere andre klasser der gør brug af den, har den stadig høj samhørighed(kan også siges som der er mange tilnærmelsesvis end metoder der udfører sammenlignelige opgaver). Derimod vil en klasse med metoder der udfører mange forskellige opgaver skabe lav samhørighed i klassen Fordelen ved høj samhørighed i klasser udbunder i en nemmere forståelse af programmet og muliggør et hurtigere udviklings- og overdragelsesforløb, da man kan isolere ændringer i koden og skabe mere overksuelighed. 18

3.3.5 Low Coupling lav kobling i et system betyder at komponenterne i et system ikke er direkte bekendte med hinanden, fx. kalder en direkte, men kalder metoder i stedet. Ved lav kobling er det fx. muligt at skabe udvidelser hurtigt da man så kan skære ned på antallet af korrektioner der skal gøres. I vores program er det sammenhøngen mellem GUI en og databasen der er adskilt ved hjælp af logicklasserne. Hvis vi i stedet havde sat GUI en direkte i forbindelse med databasen ville vi se en meget højkobling der besværliggjorde ændringer i softwaren. 3.4 Anvendelse af polymorfi - Philip Velando (Philip Velando) Vi kan med fordel benytte os af polymorfi i vores system, da flere af funktionaliteterne går igen hos de forskellige brugere, dog med lidt forskellige restriktioner. Admin brugeren har, som det fremgår af vores databaseopbygning, adgang til alle funktionaliteter, mens de andre brugere har adgang til brudstykker af disse. Eksempelvis har et Medlem adgang til at se andre brugeres profilsider, altså en samling ikkepersonfølsomme informationer som eksempelvis navn, alder og fødselsdato. Samtidig har en Ansat bruger adgang til at se flere informationer hos de forskellige brugere, såsom betalingsinformationer, telefonnummer, e-mail og adresse. 19

Kapitel 4 Database Dette kapitel dokumenterer udarbejdelsen af databasen. Det er inddelt i flere sektioner, hver indeholdende et led i udviklingen. Første sektion detaljerer den konceptuelle model, anden sektion den logiske model. Tredje sektion detaljerer udviklingen af den fysiske model. 4.1 Konceptuel - Anna Thideman og Christian Høgh Pedersen (Anna Thideman og Christian Høgh Pedersen) På baggrund af de ønsker Fightsport Køge har til databasens funktionalitet, har vi udarbejdet en række entiteter, som kan ses i Tabel 4.1. Entiteternes attributter er dokumenteret i Tabel C.1 til C.6, som er at finde i Bilag C.1. For en illustration af forholdene mellem disse entiteter, henvises til Figur 4.1, som er et EER-diagram over databasen. Vi designer ikke specifikke domæner til nogen attributter, da databasen ønskes implementeret i MySQL, som ikke understøtter oprettelsen af domæner. 4.1.1 Transaktionsbekræftelse Eksempler på transaktioner som modellen skal kunne udføre er opskrevet i den følgende liste. Der er ikke listet transaktioner for Data-indtastning/opdatering/sletning, da de kan ses at være overholdt ved eksistensen af relevante entiteter. 1. List et givent medlems navn. 2. List hvornår et givent medlem foretog en betaling. 3. List navnet på træneren der er ansvarlig for et givent hold. 4. List hvem der er ansvarlig for at betale for et givet medlem 5. List hvilke medlemmer der er tilmeldt et givent hold 6. List hvilke dage på ugen et givet hold har lektion Det kan ses ud fra EER-diagrammet at disse transaktioner kan udføres af modellen, ved eksempelvis de følgende fremgangsmåder. Nummerering tilsvarende transaktionsliste: 1. Medlemmers navne er givet i medlem-entiteten, og kan findes kun ved brug af dette. 2. Medlem-entiteten har den komplekse attribut betalinger, som indeholder alle betalinger medlemmet har foretaget. Hver af disse har en dato som kan hentes. Hent den højeste. 3. Træner-entiteten har træneres navn. Gennem forholdet ErAnsvarligFor kan vi finde træneren der er ansvarlig for et givet hold. 4. Medlemmer kan have forholdet DelerHusstand. Hvis de er en del af dette forhold med rollen husstandsmedlem er medlemmet der deltager i forholdet som betaler ansvarlig for at betale for det givne medlem. 5. Kan ses ud fra forholdes MeldtTil. 20

6. Gennem forholdet ErDelAf kan det ses hvilket hold hver lektion deltager, og det kan derved bruges til at danne en liste over alle lektioner der er del af et givet hold. Fra denne liste kan man så hente dagene. 1. Hent alt information omkring et givent medlem. 2. List træneren der er ansvarlig for et givent hold. 3. List hvem der er ansvarlig for at betale for et givet medlem 4. List hvilke medlemmer der er godkendt til et givet hold 5. List hvilke medlemmer der er tilmeldt et givent hold 6. List hvilke dage på ugen et givet hold har lektion Entitet Beskrivelse Aliaser Fremkomst Medlem Medlem af FSK Intet alias Medlemmer kan deltage i forskellige lektioner, og være godkendt til/deltage i forskellige hold Ansat Person ansat hos FSK. Mindre administrativt ansvar Medarbejder Ansatte kan kontrollere basal information i databasen og kontakte medlemmer. Træner Træner ansat af FSK Instruktør Trænere kan have ansvar for flere hold og dele ansvar for lektioner. Hold Administrator Generelt udtryk for de forskellige kampsportshold udbudt af FSK FSK ansat der er betroet med større administrativt ansvar. Intet alias Leder Hvert hold varetages af én træner. Flere medlemmer kan deltage i hvert hold. Administratoren er ansvarlig for at vedligeholde informationen i databasen, og at hjælpe medlemmer/ansatte der har problemer. Lektion Instanser af hold. Time I hver lektion deltager op til flere medlemmer og trænere. Besked Besked sendt fra FSK ansat til Email/SMS Beskeder sendt fra ansatte medlem. til medlemmer lagres i databasen, for at gøre kontrol mulig. Tabel 4.1: Entiteter. 4.2 Logik - Anna Thideman og Christian Høgh Pedersen (Anna Thideman og Christian Høgh Pedersen) Denne sektion detaljerer den logiske model for databasen, som er bygget ud fra den konceptuelle, efter metodologien i [3]. Relationer er normaliseret til trejde normalform efter betingelserne for denne, som beskrevet i [3, 4]. Der er ingen delvise afhængigheder (2NF) og alle transitive afhængigheder er fra kandidatnøgler(e.g. i Medlem) eller supermængder af primærnøglen for den givne relation(e.g. i Lektion), som kan ses herunder. De resterende relationer er at finde i Bilag C.2. 21

Figur 4.1: EER-diagram for databasen. (Medlem-entity) Medlem (medlemid, navn, adresse, telefon, email, kaldenavn, adgangskode, basisopprettelsesdato, fuldopprettelsesdato, betalinger, betalingsform, pbs, magnetfarve, bemærkninger, cpr, bankreg, bankkonto, ansatid, betalerid, medlemskabstype) Udledt attribut godbetaler Primærnøgle medlemid Fremmednøgle ansatid henviser til Administrator(ansatID) ON UPDATE CASCADE ON DELETE SET NULL Fremmednøgle betalerid henviser til Medlem(medlemID) ON UPDATE CASCADE ON DELETE SET NULL Fremmednøgle medlemskabstype henviser til Medlemskaber(medlemskabstype) ON UPDATE CAS- CADE ON DELETE SET NULL (Lektion-entity) Lektion (dag, tidspunkt, varighed, lokale, holdid) Primærnøgle (dag, tidspunkt, lokale) Fremmednøgle holdid henviser til Hold(holdID) ON UPDATE CASCADE ON DELETE NO ACTION 22

4.2.1 Transaktionsbekræftelse Eksempler på transaktioner som modellen skal kunne udføre er opskrevet i den følgende liste. Der er ikke listet transaktioner for Data-indtastning/opdatering/sletning, da de kan ses at være overholdt ved eksistensen af relevante relationer. 1. List et givent medlems navn. 2. List hvornår et givent medlem foretog en betaling. 3. List navnet på træneren der er ansvarlig for et givent hold. 4. List hvem der er ansvarlig for at betale for et givet medlem 5. List hvilke medlemmer der er tilmeldt et givent hold 6. List hvilke dage på ugen et givet hold har lektion 1. Navn er en attribut i Medlem-relationen 2. Betaling-relationen har en attribut medlemid, som er en fremmednøgle der peger på en medlemrelation. Ved at finde betalingen med den højeste dato, som har en medlemid svarende til et givet medlem, kan transaktionen udføres. 3. trænerid er en fremmednøgle i hold-relationen, som peger på træneren der er ansvarlig for holdet. Gennem denne kan man finde trænerens navn. 4. medlem-relationen har en fremmednøgle betalerid der peger på det medlem som er ansvarlig for at betale for medlemmet. 5. Holdtilmeldelse-relationen har holdid og medlemid og ved at tælle antallet af medlemid er for et givent holdid kan man udføre transaktionen. 6. Med fremmednøglen holdid i lektion-relationen, kan man finde alle lektioner der tilhører et givet hold. hvis man lister dagene for disse lektioner er transaktionen udført. 4.3 Fysisk - Christian Høgh Pedersen, Anna Thideman, Philip, Christian Holm-Petersen og Rasmus Christian Høgh Pedersen, Anna Thideman, Philip, Christian Holm-Petersen og Rasmus I denne fasen kommer SQL på banen, og det er her man f.eks oversetter den logiske model til valgt DBMS, og man opretter sikkerhetsmekanisker som ulike brukere og stored procedures, da disse ikke ikke repræsenteret af den logiske model. 4.3.1 DBMS Vi har valgt at benytte MySQL af flere årsager. En af de mere luksoriøse årsager, var at vi alle har arbejdet med DBMSen før, og derfor også havde den installeret ved projektets begyndelse. Den primære årsag er dog at vores kunde Fightsport Køge og deres IT leverandør NOKE.dk, allerede benytter MySQL som DBMS i deres nuværende web stack/hjemmesidesystem, hvorfor de har adgang til de ressourcer der skal bruges til DBMS drift på sigt. Der er mange DBMSer at vælge imellem; vi har kort overvejet at benytte PostgreSQL eller IBMs DB2 i stedet, desværre nåede vi aldrig at få mulighed for at benytte DB2 og til trods for ekstra godbidder som brug af eksempelvis de mere avancerede WITH-queries eller funktionen check som kan benyttes til referentiel integritet, som både Postgres, DB2 og mange andre modne DBMSere understøtter. Vi har gangske kort også undersøgt de mere moderne datastores der populært kaldes NoSQL. Mange mennesker mener at NoSQL systemer (der hver især også varierer og adskiller sig fra hinanden en hel del i 23

metode og funktionalitet) ikke kan kaldes databaser, idet de ikke følger den relationelle tankegang vi kender fra gængse databaser (de er derfor bevist benævnt som datastores ) men i stedet har en meget løs (ofte ikke-eksisterende) struktur og anderledes metoder til at få fat i den ønskede data. Eksempelvis benytter CouchDB sig udelukkende af views (en funktionalitet der også findes i de fleste relationsdatabaser), som skal skrives på forhånd (f.eks. getuserbyuserid-viewet) hvor MongoDB benytter en mere SQL-lignende struktur. Fælles for NoSQL databaserne er at de er gode/hurtige/effektive til enten at hente eller skrive data (READ- S/WRITES) men kan være mindre robuste og sikre (data integritet) end traditionelle relationsdatabaser. Da det ikke er den nye Facebook eller Twitter (der begge er store på Big Data-tjenester) vi skal lave, er der ingen oplagt årsag til at benytte en NoSQL datastore, desuden modtog vi aldrig undervisning i NoSQL, som det ellers var planen. 4.3.2 Tabeller Se vedlagte fil CreateTables.sql Relationer implemerenteret. Enkelte værdityper ændret, e.g. INT til BIGINT eller UNSIGNED INT fordi værdier blev opdaget der overskred INT grænsen. 4.3.3 Triggers Se vedlagte fil CreateTriggers.sql Triggers er blevet brugt til at opretholde constraints der ikke dækkes af fremmednøgler. Eksempelvis at medlemmer der er tilmeldt/fravalgt et hold, også tilmeldes/frameldes holdets lektioner. 4.3.4 Users Se vedlagte fil CreateUsers.sql Der oprettes brugere svarende til de forskellige brugertyper (Admin, Træner, Ansat og Medlem) samt en bruger der vil kunne bruges til oprettelse af basismedlemmer. Brugere er tildelt forskellige rettigheder på FSK-schemaet afhængigt af type, se GRANT-statements i vedlagte fil for en uddybning. Da databasen i sidste ende vil blive oprettet i et DBMS indeholdende andre databaser med privat indhold, er det ikke sikkert at give brugere adgang til DBMS ens stored procedure tabel v.h.a. grants. Rettigheder til brug af stored procedures skal derfor håndteres på applikationsniveau. 4.3.5 Stored Procedures Se vedlagte fil CreateStoredProcedures.sql Der er oprettet en række stored procedures der returnerer et udvalg af statistiske informationer omkring databasen, til opfyldelse af projektkrav. 4.3.6 Views Se vedlagte fil CreateViews.sql Der er oprettet ét view, ud fra medlemmer, beregnet til at give ansatte adgang til en delmængde af de tilgængelige medlemsinformationer. Der oprettes views til at afgrænse den information trænere og ansatte har adgang til. Administratoren vil have adgang til den fulde database, og der er ikke tilstrækkelig grund til at lave et view til denne bruger. Medlemmer og trænere vil have adgang til forskellig information afhængigt af den specifikke bruger, og vil blive håndteret på application-niveau. 24

4.3.7 Indexes MySQL laver automatisk indekser på primærnøgler og fremmednøgler. Vi gennemgik indekseringsovervejelserne som beskrevet i [3], kapitel 18. Resultatet af dette er givet i næste paragraf. De fleste af relationerne er ikke store nok til at retfærdiggøre tilføjelsen af sekundære indekser. Medlem er den eneste relation som har tilstrækkelig størrelse, men da de fleste af dens interessante attributter er enten primærnøgler, unikke, eller fremmednøgler, har MySQL automatisk oprettet indekser på dem. Vi har tilføjet sekundære indekser over medlemmets, attributter basisoprettelsesdato og fuldoprettelsesdato med henblik på brug i statistikfunktionalitet. 25

Kapitel 5 Implementation 5.1 Programmering - Christian Høgh Pedersen (Christian Høgh Pedersen) Denne sektion indeholder et uddrag af enkelte mere interessante kodesegmenter. 5.1.1 AdminConnector Der er to metoder fra klassen AdminConnector som vi vil inddrage som interessante. I Kodeblokken 5.1 Er AdminConnector.connectDB(), som bliver kaldt hver gang der skal forbindes til databasen. Den bruger databasebrugeren fskadmin, som er oprettet sammen med databasen, til forbindelsen. For at gøre det muligt for AdminConnector at benytte lagrede procedurer i databasen, uden at give den adgang til proceduretabellen for hele vores DBMS, er det nødvendigt at bruge denne listede version af MySQL JDBC s getconnection()-metode. AdminConnector bruger ikke lagrede procedurer på dette tidspunkt, men en anden klasse, StatististikConnector, gør. AdminConnector.connectDB() behøver ikke at returnere noget for at bevare sin funktionalitet, men returværdien bliver brugt i tests. I Kodeblok 5.2 kan det ses hvordan AdminConnector.editHold() henter holddata ud af databasen. Først forbindes via ConnectDB(). Derefter lagres de resulterende værdier i en lokal variabel, som kan bruges af andre systemklasser som er ansvarlige for at operere på dataen, og vise den til brugeren. Listing 5.1: AdminConnector.connectDB() private boolean connectdb ( ) { try { connection = DriverManager. getconnection ( jdbc : mysql : / / l o c a l h o s t / fskdb? noaccesstoprocedurebodies=true, fskadmin, adminpass ) ; } } catch ( SQLException e ) { // TODO Auto generated catch b l o c k e. printstacktrace ( ) ; return f a l s e ; } return true ; Listing 5.2: AdminConnector.editHold() public boolean edithold ( S t r i n g orgid, S t r i n g nyid, 26

S t r i n g nytnavn, S t r i n g nytniveau ) { connectdb ( ) ; // TODO Auto generated method s t u b try { preparedstatement = connection. preparestatement ( UPDATE hold SET holdid =?, navn =?, niveau =? WHERE holdid =? ) ; preparedstatement. s e t S t r i n g ( 1, nyid ) ; preparedstatement. s e t S t r i n g ( 2, nytnavn ) ; preparedstatement. s e t S t r i n g ( 3, nytniveau ) ; preparedstatement. s e t S t r i n g ( 4, orgid ) ; } preparedstatement. execute ( ) ; } catch ( SQLException e ) { // TODO Auto generated catch b l o c k e. printstacktrace ( ) ; return f a l s e ; } return true ; 5.2 Prototype - Christian Høgh Pedersen (Christian Høgh Pedersen) Prototypen demonstrerer at det er muligt at logge ind med forskellige brugertyper, og at lave ændringer i databasen gennem en GUI. Der er dog en del funktionalitet der ikke er færdiggjort. Herundet er der listet en række begrænsninger for prototypen: Træner/Ansat profiler er ikke implementeret Fejl i forbindelse med eksevering af SQL-kommandoer, e.g. INSERT der duplikerer eksisterende værdier, bliver ikke håndteret. Medlemmer kan hente deres egen information, men kan ikke ændre den. Administratorer, har fuld CRUD på hold-tabel via brugergrænsefladen, men begrænset på andre tabeller. Prototype kun beregnet til lokal demonstration. Alle databasebrugere er begrænset til @localhost. Der er ikke taget højde for sikkerhedshensyn såsom at hashe strings i programmet. Grundet tidspres i at få en prototype sat op, er der utilstrækkelig observans af objektorientede principper i koden, og afvigelser fra designet. E.g. er der variabler og metoder der ikke burde være public. 5.3 Installationsvejledning - Christian Høgh Pedersen og Rasmus (Christian Høgh Pedersen og Rasmus) Denne installtionsvejledning er udarbejdet med henblik på at gøre databasen og programmet klar til funktionalitetsdemonstration. Der tilføjes derfor noget testdata som ikke nødvendigvis bør være endeligt med. 27

5.3.1 Database Vejledning for opsætning af database. Forudsætninger: Installeret MySQL database som kan tilgås som root, eller med rettigheder tilsvarende root. Kør script filen komplet data.sql gennem konsol/cmd (i filens mappe): mysql u root p < komplet data. s q l Listing 5.3: AdminConnector.editHold(), eller benyt en grafisk klient såsom MySQL Workbench. Får du fejl eller behov for at installere database strukturen manuelt, indeholder FSKDBSScripts.zip filer der skal installeres i følgende rækkefølge: 1. CreateDatabase.sql 2. CreateTables.sql 3. CreateViews.sql 4. CreateTriggers.sql 5. CreateUsers.sql 6. CreateStoredProcedures.sql 7. TestData.sql 5.3.2 Program Inden programmet kan køres skal det sikres at en korrekt database er sat op, som anført ovenstående og DBMSen (MySQLd) kører. Herudover skal Java (JRE) være 7 (1.7), da der er benyttet funktionalitet i programmet der kun findes i Java (7) 1.7 eksempelvis automatisk garbage-collection og lukning af eksempelvis streams og mulighed for at bruge switch() på en String. Java/JRE skal ydermere være opsat med JDBC udvidelsen, for at kunne forbinde til databaseserveren. Uddybende brugervejledning kan findes i Bilag B. 28

Kapitel 6 Test - Christian Høgh Pedersen (Christian Høgh Pedersen) Testing er begrænset til unit/accept tests der kontrollerer resultaterne af programmets funktioner og kommunikation med databasen. Da det endelige resultat af dette projekt er en funktionel database, men med en meget begrænset brugergrænseflade, har vi ikke fundet det traktabelt at have yderligere testforløb. Produktet vil ikke blive implementeret som det ser ud ved projektafslutning, og tidshorisonten taget i betragtning, vil der ikke kunne udføres nyttige korrektioner på baggrund af brugertests. Det i mente har vi kun benyttet os af tests til at sikre at systemets metoder udfører korrekte handlinger. Oprindeligt var der en ambition om at forsøge sig med principperne fra Test Driven Development men grundet tidspres kunne dette ikke følges til bunds. Vi har oprettet unit tests der kontrollerer om systemets funktioner giver forventede returværdier, givet bestemte inputs, og vi har vist at testede klasser fungerer korrekt. 6.1 AdminConnector odenne sektion omhandler unit/acceptesting af klassen AdminConnector, som er implementeret i java-filen AdminConnector.java, testene er at finde i den vedlagte fil AdminConnectorTest.java. 6.1.1 Testplan Der er foretaget tre planlagte tests: 1. Alting er sat op så test burde lykkes. 2. Databasen er sat forkert op/slukket. Alle tests der involverer en databaseforbindelse burde fejle. 3. Tests udføres med forventning om forkerte resultater. Alle tests burde fejle. Begrænsninger for test: Grundet tidspres er tests der sammenligner resultater af SELECT statements ikke sat op til at sammenligne alle resultaterne. Der sammenlignes kun på første resultat af hvert ResultSet. Dette betyder at der strengt taget kunne være fejl i de andre værdier, men metodens funktionalitet taget i betragtning er det særdeles usandsynligt. 6.1.2 Testresultater Test 1 se resultater i Figur 6.1. Som det kan ses ud fra disse testresultater, fungerer AdminConnectors metoder korrekt når de gives parametre der burde medføre succes. 29

Test 2 se resultater i Figur 6.2. Det kan ses at alle metoder der involverer et kald til databasen fejler. Den eneste metode der kan kaldes er AdminConnector(). Programmet ville teknisk set kunne køre selvom forbindelsen til databasen blev tabt, men da det i skrivende stund ikke har en offline -mode ville det have meget begrænset funktionalitet. Test 3 se resultater i Figur 6.3. Denne test har mere interessante resultater. henthold() fejler når den forsøger at sammenligne værdier der ikke eksisterer i den tabel den henvender sig til. Det samme gør hentmedlemmer(). Men edithold() og slethold(). Giver ikke noget fejlresultat til trods for at deres parametre var fejljusterede i en sådan grad at de var meningsløse. Dette er på den ene side forståeligt; Der returneres kun fejl hvis SQL-statementet ikke kan eksekveres. Men på den anden side betyder det også at der er metoder som det er muligt for brugeren at give forkerte parametre, uden at der er en mulighed for at systemet kan opdage det. Dette vil muligvis være fornuftigt at forbedre i fremtidige udviklingsiterationer. 30

Figur 6.1: Resultat af test 1, AdminConnector Figur 6.2: Resultat af test 2, AdminConnector Figur 6.3: Resultat af test 1, AdminConnector 31

Kapitel 7 Konklusion - Alle gruppemedlemmer (Alle gruppemedlemmer) Der er udviklet en prototype af programmet til Fightsport Køge, samt scripts der kan sætte en MySQL database op der opfylder kravene fra kunden. Prototypen kan demonstrere forskellige bruger-logins, og begrænset adgang til databasens CRUD-muligheder. Prototypen kan desuden vise begrænset statistik omkring databasens indhold. 7.1 Reflektion Reflektion over processen 7.1.1 Tidsmåling Forbrugt tid beregnet som: Skemalagt: 3 timer om ugen per person (5) i 8 uger(før efterårsferie, så kun OOAD-opgaveregningstid plus løs databaseopgaveregningstid). Skemalagt: 8 timer om ugen per person (5) i 4 uger(efter efterårsferien) Desuden er der brugt ca. 50 timer udover den skemalagte. I alt: 330 LoC: Omkring 1367, ikke medregnende GUI. Da der er meget autogenereret kode i den. Dokumentsider: omkring 42, inklusive bilag. Målinger Beregninger Personer i gruppen 5 Persontimer(timer) 66 Use cases, der er implementeret 82.5 analyseklasser svarende til use cases 82.5 Implementerede klasser svarende til analyseklasser 3.5 lines of code(loc) 4.1 341.75 341.75 Dokumentsider 7.86 7.1.2 Udviklingsprocesser - Anna og Rasmus (Anna og Rasmus) I den innledende fase av prosjektet, så er det veldig viktig at hele gruppen enes om om hvordan prosessen skal være fra start til slutt i prosjektet. Dette er viktig så alle i gruppen vet hva som skal lages til et hvert tidspunkt, men også for at man skal unngå misforståelser og oppnå høyest mulig kvalitet. Et gjennomtenkt og planlagt prosessforløp kan også give større produktivitet. 32

Det finnes flere forskjellige typer av modeller innfor softwareudvikling. Og før dette kursus har de fleste af os allerede stiftet bekendtskab med udviklingsprocesserne UP (Unified Process) samt XP (Extreme Programming) i tidligere kurser. Begge disse processer er Agile hvor man, altså modsat eksempelvis vandfalds modellen, der man udvikler iterativt og inkrementelt i korte stræk. Vi er i dette kursus blevet præsenteret for processen Scrum både af vores forelæsere men også eksterne talere har advokeret for brugen af Scrum. Scrum er ligeledes en Agil-process og har mange fællesnævnere med de andre metoder. Et (stræk) i Scrum kaldes en Sprint og varierer i længde. Ofte benytter Scrum-teams to eller fire ugers perioder per sprint - Det er oplagt at have flere, eksempelvis to, udgivelser per sprint. Grundlæggende er Scrum meget punktlig omkring dens ceremonier hvilket ofte betyder at udviklingshold der tror de bruger Scrum, ofte ikke gør det, fordi processen er så punktlig. Vi har forsøgt at benytte os af de delelementer vi syntes gav mest mening i vores projekt og har ligeledes fravalgt delelementer vi anså som problematiske i vores gruppe. Eksempelvis har vi fra start valgt ikke at indføre Scrum-rollerne PO (Project Owner) og Scrum-Master i vores gruppe, da vi var under opfattelsen at disse roller ikke helt fungerede efter hensigten i dette prosjektet idet alle skulle ha ansvar for dele af opgaven i både OOAD og database. Derudover var der personer i gruppen der fra ikke ønskede at indtage en lederrolle og derved skabe hieraki/diktatur i gruppen. I retrospekt var dette en utrolig dårlig beslutning der resulterede i at flere medlemmer ofte følte at de ikke havde noget at lave, medmindre der på egen hånd traf en beslutning der potentielt kunne overlappe resten af gruppens arbejde. Vi har fra starten gjort meget brug af pair programming, som er et af kendetegnene ved XP. Pair programming er både elsket og forhadt af mange. Især argumentet men vil I få lavet lige så meget sammen, som hver for sig gør mange brug af - Denne sammenligning er dog ikke gyldig i vores optik, særligt da god kode oftest fylder mindre en dårlig. Større problemstillinger løses oftest også bedre med en sparringspartner. Et hold med en øvet og nybegynder kunne ligeledes lyde kedsommelig (for den øvede) og måske stressende for nybegynderen - denne metode har dog også vist sig at være brugbar både for nybegynder (man lærer åbenlyst meget med fingrende på tastaturet tips i venstre øre) og øvede (man lærer også meget ved at lære fra sig.) Vi har også brukt UML(Unified modelling language), som er et verktøy meget brukt i UP til å strukturere og beskrive det forløp som gjennomgår i utviklingen av et softwaresystem. Vannsfallsmodellen vs UP: I UP kalles fasene for inception, elaboration, construction og transistion, hvor de i vannfallsmodellen kalles requirements, design, implementation, vertification, maintenance. Hovedforskjellen på disse to, er at i UP kan begynne på flere faser samtidig, hvor man i vannfallsmodellen gjør en fase ferdig, før man begynner på den neste. Man pleier derfor å si at i UP så kan man ta høyde for alle de problemer som er ved den tradtionelle vannfallsmodellen. Dette gjør at man i UP kan ta høyde for endringer under, da det er svært å definere alle krav fra begynnelsen. Scrum og XP vs UP: Disse minner litt om hinanden, ved at man her arbeider med flere faser på samme tid. Felles for Scrum og XP er at kunden står sentral i prosessen og er innblandet hele tiden, dog i SCRUM represenrt som en product owner. Scrum skiller seg ut ved at det er bygger meget på cermonier og sprints, og i XP står test og kollektivt eierskap sentralt. Men det som er likt for begge to er at dokumentasjonen er mindre viktig enn i UP der dokumentastion utgjør en stor del av prosessen. Omfattende dokumentasjon kan være meget tidskrevende, noe som kan være negativt om man tenker på at time is money, men dokumentasjon kan også spare masse tid ved at de kan gjøre det nemmere å identifisere problemet dersom det oppstår problemer/feil. Scrum og XP egner seg til små prosjekter, mens UP er god i store prosjekter. 7.1.3 Gruppearbejde Der har været problemer med at koordinere gruppearbejdet, og uddelegere opgaver mellem medlemmer. Vi har haft problemer med at den udarbejdede arbejdskontrakt ikke blev respekteret, og ikke blev håndhævet. 33

Vi har forsøgt os med forskellige softwareværktøjer, eksempelvis [5] til at styrke gruppens evne til at koordinere sit arbejde, men der har det til trods været tilbagevendende problemer med at gruppemedlemmer ikke har kommunikeret, eller undladt at udføre opgaver de havde påtaget sig. Under forløbet har vi gjort brug af værktøjerne SVN og Google Drive til at samle vores arbejde og for at være opdateret konstant. Google Drive fungerer som et online samlingssted for office dokumenter som alle kan redigere i samtidig. I vores tilfælde har det været brugt som et samlingssted for notater og ideas-pitching inden SVN blev taget i brug under udformningen af rapporten. SubVersion er et program brugt til at udføre versions og revisions kontrol af kode. Programmet er især brugbart til at holde styr på kode og lade flere personer arbejde på dele af programmer for derefter at føre dem sammen(merge) delene. Fordelen ved brugen af det, er at hvis der opstår fejl i koden er det muligt at føre koden tilbage til et tidligere tidspunkt, fx. hvis man støder på uforudsete problemer man ikke kan løse. Ligeledes er det en god mulighed for at man kan se hvem der har tilføjet til et program og referere til personen hvis man har problemer med koden. I vores tilfælde gjorde vi brug af TortoiseSVN da vi tidligere har arbejdet med det på andet semester og derfor var bekendte med det. Vi gjorde dog ikke brug af det før end midten af forløbet da vi begyndte at kode programmet og under rapportskrivningen viste det sig meget nyttigt da der var mulighed for at arbejde samtidig i Latex. 7.2 Videre udvikling - Christian Høgh Pedersen Der mangler dele af funktionaliteten for nogle af programmets klasser. Admin-klassegruppen har e.g. kun fuld CRUD på databasens hold-tabel via programmet. Denne skal udvides til hele databasen. Medlemmer kan kun læse deres personlige information gennem programmet. De skal desuden have adgang til holdtilmelding, lektiontilmelding, mulighed for at se deres betalinger og mulighed for at ændre deres personlige information. Ansat/Træner klassegrupperne har ingen funktionalitet udover mulighed for at logge ind. Desuden gælder det generelt at der skal gøres overvejelser omkring brugergrænsefladen, for at gøre den til noget der er virkelig brugbart. Data-adgang og login bør muligvis splittes op i forskellige databaser, af sikkerhedshensyn. Desuden vil det være nødvendigt at oprette et serversystem der kan bruges til at implementere den mere vidtrækkende ønskede funktion. Eksempelvis et beskedsystem der sender medlemmer beskeder omkring betaling hver måned. Java-programmet vil blive erstattet af en web-baseret løsning når vi overdrager projektet til Noke ApS. 34

Litteratur [1] Fightsport Koege. Mma, muay thai og brasiliansk jiu-jitsu i fightsport kã ge, November 2013. [2] Noke Aps. Virtualisering, hosting og outsourcing, November 2013. [3] Thomas Connoly and Carolyn Begg. Database Systems: A Practical Approach to Design, Implementation and Management. Pearson Education Inc., fifth edition, 2010. [4] Abraham Silberschatz, Henry F. Korth, and S. Sudarshan. Database System Concepts. McGraw-Hill, sixth edition, 2011. [5] Trello. Trello, November 2013. 35

Bilag A Analyse i dette bilag er der listet ting fra analyse-kapitlet, som ikke er relevant nok til at have i selve afsnittet. Figur A.1: Rigt billede - medlem ønsker å finde oplysninger om hold, træner og lokale på FSK nettside. 36

Bilag B Brugervejledning Vejledning for brug af prototype. Det forudsættes at databasen kører. Filen FSKclient.jar kan placeres et vilkårligt sted. Ved dobbeltklik startes den grafikse brugergrænseflade. Alternativt kan programmet også køres fra konsol/cmd med kommandoen: java j a r FSKclient. j a r Listing B.1: Kør program fra konsol/cmd B.1 Brugere Der eksisterer effektivt set en bruger for hvert medlem, ansat, træner og administrator registreret i databasen, herunder er eksempler på gyldige login: Admin: 3/kode Træner: 2/kode Ansat: 7/kode Medlem: 10000003/kode B.2 Administrator Herunder er der en række opgaver administratoren kan udføre, og hvordan de udføres. Se medlemmers info: 1. Kør FSKclient.jar, enten dobbelt klik med mus, eller gennem konsol. 2. Skriv id/password i de relevante felter og tryk OK. Se Figur B.1 3. Vælg fanen medlemmer i det åbnede vindue. Se Figur B.2. Figur B.1: Prototypens loginside Se hold: 1. Kør FSKclient.jar 2. Skriv id/password i de relevante felter og tryk OK 3. Vælg fanen Hold i det åbnede vindue. Se Figur B.3. 37

Figur B.2: Prototypens medlemsvisning efter administratorlogin. Figur B.3: Prototypens holdvisning efter administratorlogin. Figur B.4: Prototypens opret hold dialog 38

Figur B.5: Prototypens slet hold dialog Figur B.6: Prototypens edit hold dialog Opret hold: 1. Udfør trin 1-3 for Se hold 2. Klik på Opret Hold 3. Skriv ønsket information i felterne i det åbnede vindue. Se Figur B.4. 4. Tryk Gem Hold Slet hold: 1. Udfør trin 1-3 for Se hold 2. Klik på Slet Hold 3. Skriv holdid for det hold der ønskes slettet i det åbnede vindue. Se Figur B.5 4. Tryk Slet Hold 39