OO analyse og design
Rytmen i denne uge:
| tirsdag | onsdag | torsdag | fredag |
|---|---|---|---|
| Lektion | Lektion | Lektion |
Bemærk: 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.
NB! Fysisk fremmøde
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. 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.
Kontoret er tomt, alle arbejder hjemme.
Hvis man ikke var med til at arbejde med use cases onsdag, kan man fylde hullerne ved at sætte sig ned og læse de første 5 use cases grundigt. læs use cases
Hvis du vil teste om du forstår use-cases godt, så skal du lave et use-case diagram. Hvis du har styr på de use-cases vil du meget hurtigt kunne svare på spørgsmålet: hvilke dele af use-case 1 understøtter vores kode IKKE?
Vi har etableret fået etableret vores projektkode med noget genbrugt kode som har to ting, vi skal bruge: mekanismer til datapersistens og brugerdialog. Men vi er ikke helt i mål med persisteringen. Vi vil også bygge mekanismen der skifter mellem spillere.
Bygge game loop: mekanisme til at skifte mellem spillere.