23.3. Objektorienteret design

Designets formål er at beskrive, hvordan programmet skal implementeres.

Her skal man bl.a. identificere de vigtigste klasser i systemet og lede efter ligheder mellem dem med henblik på nedarvning og genbrug.

23.3.1. Kollaborationsdiagrammer

Nyttige diagramformer under design er kollaborationsdiagrammer (samarbejdsdiagrammer), hvor man beskriver relationerne mellem klasserne eller objekterne på et overordnet plan.

Her er et eksempel:

Figur 23-8. Java

Har-relationer giver et vink om, at et objekt har en reference til (evt. ejer) et andet objekt. F.eks.:

Når spilleren tjekker regler, sker det gennem blok-objektet. Man kan forestille sig, at spilleren løber gennem alle blokkens regler og ser, om der er nogle, der passer, og han ikke har brugt endnu. Tjek af regler er altså ikke en har-relation, for spilleren har ikke en variabel, der refererer til reglerne.

Visse steder er der mange slags objekter, der kan indgå i samme rolle. Det gælder for eksempel Spillere i diagrammet ovenfor. Så kan man tegne et separat diagram, der viser rollerne.

Figur 23-9. Java

Er-en-relationer angiver generalisering eller specialisering (hvor nedarvning kan være en fordel). Det tegnes oftest med en hul pil.

Her er det lidt specielle, at én type spiller (nemlig Menneske) har et vindue tilknyttet. Dette vindue skal jo have adgang til at vise terningerne, så man skal huske at sørge for, at spillere har en reference til raflebægeret.

23.3.2. Klassediagrammer

Herefter kan skitseres klassediagrammer, hvor man fastlægger nedarvning (er-en-relationerne), de vigtigste variabler og referencerne mellem objekterne (har-relationer) og de vigtigste metoder.

Dette kan eventuelt tegnes med et UML-udviklingsværktøj (f.eks. TogetherJ der kan hentes på http://www.togethersoft.com), der samtidig kan generere kode til programmeringsfasen.

Figur 23-10. Java

Herunder ses, hvilke typer regler der kunne forekomme.

Figur 23-11. Java