Lavet af Danni jensen og David Olsen

Transkript

1 Projekt Delfin Lavet af Danni jensen og David Olsen 19/5-2008

2 Indholdsfortegnelse. Side 1: Indholdsfortegnelse og forord. Side 2: Kravsliste. Side 3: Use Case Model. Side 4: Formandens aktørbeskrivelse og use case beskrivelser. o Side 5: Opret Medlem kommunikations- og klassediagram. o Side 6: Rediger Medlem kommunikations- og klassediagram. o Side 7: Slet Medlem kommunikations- og klassediagram. Side 8: Kassererens aktørbeskrivelse og use case beskrivelser. o Side 9: Registrer Betaling sekvens- og klassediagram. o Side 10: Udskriv Restance sekvens- og klassediagram. Side 11: Trænerens aktørbeskrivelse og use case beskrivelser. o Side 12: SeTop5 sekvens- og klassediagram. o Side 13: RegistrerStævneTider sekvens- og klassediagram. Side 14: Det samlede klassediagram og tilstandsmaskine. Side 15: Operationsspecifikation vha. aktivitetsdiagrammer. Side 16: Evaluering af SWK-delen af projektet. Side 17: Evaluering af SWD-delen af projektet. Side 18: Samarbejdsaftale. Forord. Hverken programmering eller systemdesign er begreber nogen af os havde gjort os meget i før vi startede på BEC Business. Derfor har det været en stor udfordring at dele de forskellige dele af opgaven i mellem os, hvert fald i et klart og adskilt mønster. Derfor er det ikke klart defineret hvem der har lavet hvad, vi har kigget på hinandens arbejde og foretaget rettelser i fællesskab hvor det har været nødvendigt. Dette gælder både SWD og SWK. Vi har kaldt vores system for Delfin version 1.0. Projektet afleveres d. 19/ Hele projektet er udarbejdet af David Olsen og Danni Jensen. 1

3 3. Requirements Model Kravsliste (Funktionelle og Non- funktionelle krav) Kravsnummer Funktionelt eller Non- Funktionelt 1 F 2 F 3 F 4 F 5 F 6 F 7 F 9 F 10 F 11 N-F 12 F Beskrivelse af kravet. Use Case(s). Aktør. Systemet skal kunne registrere medlemmer. Opret medlem. Formand Systemet skal kunne redigere allerede eksisterende medlemmer. Systemet skal gemme informationer om medlemmer permanent på harddisken. Systemet skal kunne registrere medlemmer som aktive og inaktive. Dette giver direkte indvirkning på SeTop5 og printkontigent. Systemet skal kunne slette information om en enkelt svømmer. Systemet skal kunne fremvise en liste over restance medlemmer. Rediger medlem. Registrer medlem og Rediger medlem. SætAktiv/SætIn-Aktiv. SletMedlem. SeOgUdskrivRestance. Formand Formand Formand Formand Kasserer Systemet skal kunne redigere i betalingsinformation. RegistrerBetaling. Kasserer Systemet skal kunne gemme information om stævnetider for den enkelte svømmer. RegistrerStævneTider. Træner Systemet skal kunne hente stævnetider for det enkelte medlem og vise en Top5. SeTop5. Træner Systemet skal have en let forståelig grafisk * * brugergrænseflade. Systemet skal være i stand til at gemme information om x * * antal svømmere, vha. et array. 13 N-F Systemet skal fungere så det er meget enkelt at udføre den opgave brugeren skal bruge det til. * * 2

4 Use case Model Vi starter på side 4 med en aktørbeskrivelse af formandens opgaver og går hernæst videre til use case beskrivelserne, kommunikations diagrammer og klassediagrammer. På side 5 går vi igennem kassererens aktørbeskrivelse og use case beskrivelser. På side 6 gennemgår vi trænerens aktørbeskrivelse og use case beskrivelser. 3

5 Formanden: Formanden for svømmeklubben står med ansvaret for at optage nye medlemmer. Derfor skal han gennem systemet have mulighed for at registrere information om nye medlemmer. Han skal også kunne redigere i allerede oprettede medlemmer. Ligeledes skal han kunne slette medlemmer. Han skal kunne skifte deres status i svømmeklubben fra aktiv til inaktiv eller vice versa. Use case beskrivelse Opret Medlem: Formand System 1. Vælg opret medlem i forsidemenuen 2. Vis skærm for opret medlem 3. Indtast stamoplysninger, vælg aktivitetsform, afslut med gem oplysninger, 4. Vis dialog for gemte oplysninger. Alternative scenarier Formanden har tastet bogstaver i fødselsår Systemet giver besked og beder om en ny indtastning. Use case beskrivelse Rediger Medlem: Formand System 1. Vælg rediger medlem i forside menuen 2. Vis drop down liste over gemte medlemmer 3. Vælg medlemmet 4. Vis info for valgt medlem 5. Ret info der ønskes ændret, afslut med gem 6. Vis dialog med info om det nye der gemmes Alternative scenarier Formanden har tastet bogstaver i fødselsår Der trykkes rediger medlem, på trods af medlemlisten er tom. Systemet giver besked og beder om en ny indtastning. Systemet giver besked om at der skal oprettes et medlem før der kan redigeres. Use case beskrivelse Slet Medlem: Formand System 1. Vælg medlem 2. Vis medlem 3. Slet medlem 4. Send oplysninger til kasserer; gemoplysninger 4

6 Opret Medlem kommunikationsdiagram: Opret Medlem klassediagram: 5

7 Rediger Medlem kommunikationsdiagram: Rediger Medlem klassediagram: 6

8 Slet Medlem kommunikationsdiagram: Slet Medlem klassediagram: 7

9 Kassereren: Kassereren skal kunne printe kommende kontingent for alle aktive medlemmer. Han skal også kunne printe en liste over manglende betalere, eventuelt med henblik på at sætte dem som inaktive vha. formanden. Kassereren skal desuden kunne registrere betalinger i systemet, således at det er registreret hvem der har betalt. Use case Se Restance: Kasserer System 1. Kassereren vælger se restance medlemmer 2. Systemet finder og viser skyldige medlemmer. 3. Kassereren vælger udskriv regning 4. Systemet skriver regning ud og gemmer information om udskriftsdato. Use case Registrer Indbetaling: Kasserer System 1. Kassereren vælger registrer indbetaling 2. Systemet giver en liste over medlemmer 3. Kassereren vælger det pågældende medlem 4. Systemet viser information om medlemmet og dettes betalinginformation 5. Kassereren indtaster betaling og trykker på gem. 6. Systemet gemmer og kommer med en meddelelse om at alt er gemt Use case Udskriv Kontigent: Kasserer System 1. Kassereren vælger udskriv kontigent 2. Systemet finder medlemmer der ikke er registreret til at have betalt og udskriver regninger. 8

10 Registrer Betaling sekvensdiagram: Registrer Betaling klassediagram 9

11 Udskriv Restance sekvensdiagram: Udskriv Restance klassediagram: 10

12 Træneren: Træneren står for alt hvad der har med medlemmets stævnetider at gøre. Ud fra en top 5 som systemet genererer, udtager han hold til stævner. Træneren er ansvarlig for at indtaste tider osv. i systemet. Use case beskrivelse SeTop5: Træneren Systemet 1. Træneren vælger se top5 2. Systemet lister mulige aldersgrupper 3. Træneren vælger alder 4. Systemet lister mulige discipliner 5. Træneren vælger disciplin 6. Systemet lister de 5 bedste svømmere ud fra valgte kriterier Use case beskrivelse registrer stævnetider: Træneren Systemet 1. Træneren vælger registrer stævnetider 2. Systemet lister aldersgrupper 3. Træneren vælger alder 4. Systemet lister discipliner 5. Træneren vælger disciplin 6. Systemet lister svømmere ud fra valgte kriterier 7. Træneren vælger svømmer 8. Systemet giver mulighed for at indtaste tid, resultat og stævne- og træningstider 9. Træneren indskriver tid og resultat trykker ok 10. Systemet giver meddelelse om at alt er gemt 11

13 SeTop5 sekvensdiagram: SeTop5 klassediagram: 12

14 RegistrerStævneTider sekvensdiagram: RegistrerStævneTider klassediagram: 13

15 Det samlede klassediagram: Tilstandsmaskine: 14

16 Operationsspecifikation af opret medlem: Operationsspecifikation af RegistrerStævneTider eller SeTop5 15

17 Evaluering af projektet: SWK-delen af projektet: Projektet har været en hård nyser. Det har været super hårdt at skulle tage alle elementer med i sine betragtninger. Og ikke mindst at prøve at programmere objektorienteret. Alt hvad der skal laves griber om sig og der skulle afsættes mere tid til hver enkelt del end vi havde forestillet os. Det har mest af alt været en trial-and-error fremgangsmåde. Vi er begge glade for at vores gruppe ikke har været større, det har været nemmere at koordinere indsatsen til at udbedre fejl i programmeringen, da vi begge har haft stort indblik i hvad den anden lavede og hvordan det blev implementeret. Vi lagde ud med at programmere use casen Opret Medlem, men vi måtte omstrukturere i løbet af projektet da det vi havde programmeret ikke ville kunne hænge ordentligt sammen med at programmere vores use case nummer 2, Rediger Medlem. Det må siges at være vores egen skyld, men som sagt, trial-and-error. Og vi lærte da at være mere objektorienterede af det. Efter omstruktureringen er vi blevet godt tilfredse med det resultat vi er kommet frem til. Systemet læser og gemmer fint, altså har vi opnået persistens og kan endda vise det ved at hente og redigere de medlemmer der oprettes og gemme dem oven i det hentede medlem. Set i bakspejlet har vi fået for tæt kobling mellem vores GUI og metoder til at få input ved oprettelse, det er for svært at oprette test klasser til vores blandede klasser, så vi har i stedet lavet tests til medlemsklassen og medlemregistret. Necessity is the mother of invention 16

18 Evaluering af projektet: SWD-delen af projektet: Vi valgte at gå i gang med at lave en masse SWD inden vi gik i gang med at kode, det tog meget længere tid end vi havde regnet med. Det hjalp ikke at vi tilmed ikke anede hvordan det vi sad og designede skulle programmeres. Derfor må det i sandhed siges at have været en itterativ proces at lave SWD-delen af projektet. Vi har måttet gå igennem alt hvad vi havde lavet efter vi var færdige med at kode og lave en masse arbejde. Der er i sandhed ingen af os der havde forudset hvor meget arbejde der egentlig skulle laves, vi måtte sige stop og gå i gang med at kode for at få et overblik over situationen. Vi havde jo en deadline. Med alle de begreber der er i SWD har det taget en del snakken frem og tilbage at designe noget som helst. Vi har haft mange vanskeligheder ved at identificere alle klasser der skulle indgå i systemet, vi er overbeviste om at SWD-delen af projektet godt kunne have været mere omfattende, men det har været svært at overskue omfanget af det hele. Vi har prøvet at få hele billedet med, men den del vi har programmeret har været noget lettere at beskrive og designe. Tydeligvis havde vi undervurderet den tid der skal bruges på SWD og det kunne mærkes da vi var færdige med at programmere. Hvis man skal sammenfatte hvad det er der står foroven kan det nemt gøres: Øvelse gør (forhåbentlig) mester. 17

19 Samarbejdsaftale Som grundlag for udarbejdelse af en samarbejdsaftale kan I evt. inddrage følgende spørgsmål i jeres gruppediskussion: 1.Hvad vil I gøre, hvis ambitionsniveau, forventninger, arbejdsindsats er forskellig i gruppen? Så afholder vi et gruppemøde. 2.Hvad vil I gøre, hvis der i gruppen er en person, der ikke lever op til aftalte forpligtigelser? Tage et gruppemøde. 3.Hvad vil I gøre, hvis gruppemiljøet præges af generel ligegyldighed og manglende motivation? Så vil vi prøve at identificere årsagen, vha et gruppemøde. 4.Hvordan vil I udnytte jeres forskellige faglige og personlige kompetencer? Bedst muligt. 5.Efter hvilke regler vil I uddelegere arbejdsopgaver? Vi vil løbende beslutte os for hvem der tager hvilke opgaver. 6.Hvordan vil I sikre frie og åbne gruppediskussioner, der ikke bygger på manipulation og magtspil? Hvis vi havde været mere end to i gruppen ville vi havde lavet et system med en ordstyrer. 7.Hvordan vil I organisere jeres gruppemøder? Vi aftaler løbende nye gruppemøder hos en af os. 8.Hvordan vil I holde styr på jeres arbejdsdokumenter? Ved at uploade og dokumentere på code.google.com 9.Hvordan vil I sikre at I rent faktisk overholder ovennævnte punkter gennem projektforløbet? Vha. et bødesystem. 18