Linux - Friheden til at programmere i Java: Version 0.7.20040516 - 2020-12-31 | ||
---|---|---|
forrige | Kapitel 23. Objektorienteret analyse og design | næste |
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.
Nyttige diagramformer under design er kollaborationsdiagrammer (samarbejdsdiagrammer), hvor man beskriver relationerne mellem klasserne eller objekterne på et overordnet plan.
Her er et eksempel:
Har-relationer giver et vink om, at et objekt har en reference til (evt. ejer) et andet objekt. F.eks.:
Raflebægeret har en reference til terningerne, ellers kan det ikke kaste dem. Terningerne kender ikke til raflebægerets eksistens.
Blokken har nogle regler (en for hver række). Reglerne kender ikke til blokkens eller spillerens eksistens.
Blokken har nogle spillere (en for hver søjle), og spillerne ved de hører til en blok hvor deres resultater skal skrives ind på.
lokkens data skal vises i et vindue. Der er brug for, at blokken kender til Blokvindue, vinduet, der viser blokken på skærmen, så det kan gentegnes, når blokken ændrer sig. Men vinduet har også brug for at kende til blokken, som indeholder de data, det skal vise.
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.
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.
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.
Herunder ses, hvilke typer regler der kunne forekomme.