OO analyse og design
Bemærk at rytmen er anderledes i denne uge:
| mandag | tirsdag | onsdag | torsdag | fredag |
|---|---|---|---|---|
| Lektion | Lektion* | Lektion | Lektion |
- Alle lektioner denne uge er med fysisk fremmøde
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 af kode 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:
- statisk design (hvilke klasser skal vi bruge?)
- 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.
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.
NB! Fysisk fremmøde
- Vi skal blive enige om en domænemodel og se hvordan man kommer fra domænemodel til klassediagram. 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 hvordan systemet skal opføre sig.
- Finde kode vi kan genbruge, og tilpasse den, så den adlyder usecase 1 og 2.
Vi har etableret vores projektkode med noget genbrugt kode som har to ting, vi skal bruge: mekanismer til datapersistens og brugerdialog.
Bygge game loop: mekanisme til at skifte mellem spillere.
Kontoret er tomt, alle arbejder hjemme.
Se evt. video Coding with John: unit testing.
Test og find fejl i vores kode, og præsenter dem for afdelingen i morgen. Hvordan ? Se guide
I gang med at bygge spillepladen. Derefter i gang med sprint5 (use case 3) hvor spilleren kaster en terning og rykker frem på brættet.
Det første kollaborative sprint, som kræver opdateringer i fem forskellige klasser. Vi fordeler arbejdet mellem teams, og mødes bagefter til code review, hvor vi merger ændringer ind.
Spillere kan kaste terning og rykke rundt på brættet.
- Vi har fundamentet til et turbaseret spil og en objekt repræsentation af spillepladen