OO analyse og design

Bemærk at rytmen er anderledes i denne uge:

Over de næste to uger forvandler klassen sig til en udviklingsafdeling i et spilfirma. Vi har fået til opgave at kode spil-logikken til brætspillet Matador. Vi skal arbejde i sprints og i teams vil i levere hver jeres del af koden, som vi så sætter sammen efter hvert sprint.

NB! Din mødestabilitet er (som på enhver anden arbejdsplads) vigtig for at opnå kontinuitet i din forståelse og for hele holdets produktivitet.

I denne uge er målet at blive enige om et design som vi alle kan kode efter. Der er to dele i et design:

1. Statisk design (hvilke klasser skal vi bruge?)
2. Dynamisk design (Hvilke metoder skal der være og hvordan skal de kommunikere?)

Vi vil også tage hul på de første sprints så vi ender med at have kode der kan bruges i et turbaseret spil.

Læringsmål for ugen

Vi foretager objektanalyse på kundekrav til Matadorspillet og tegner en domænemodel. Senere vil domænemodellen udvikle sig til et klassediagram og fungere som en slags aftaledokument i implementeringsfasen.

• Fælles forståelse og vokabular for entiteterne i systemet.
• Vi skal blive enige om en domænemodel og se hvordan man kommer fra domænemodel til klassediagram.

1. Sæt dig godt ind i Matador spillets regler. Her er en dansk udgave og her er på engelsk. Det er godt at læse begge, da vi kommer til at bruge engelske termer i vores design.
2. Se videoer om UML domænemodeller (video 6 + 7)
3. Valgfrit: Læs artikel om historien bag Matador spillet

For at nå frem til det dynamiske design, skal vi bryde opgaven mere ned med use cases.

Den systemansvarlige har skrevet nogle på forhånd, som vi skal kigge nærmere på.

• Vi starter projektet op ved at klone Game

• Fælles forståelse for det hvordan systemet skal opføre sig.
• Finde kode vi kan genbruge, og tilpasse den, så den adlyder usecase 1 og 2.

læs use cases:

Kontoret er tomt, alle arbejder hjemme. Vi mødes over Zoom. Alt efter hvor langt vi er nået de foregående dage, arbejder vi videre med use case 1 og 2.