javabog.dk - - Objektorienteret analyse og design

Kapitlet giver idéer til, hvordan en problemstilling kan analyseres, før man går i gang med at programmere.

I traditionel systemudvikling er idealet, at de fem faser udføres en efter en, sådan at en ny fase først påbegyndes, når den forrige er afsluttet. Hver fase udmøntes i et dokument, som senere kan bruges til dokumentation af systemet.

Dette er i skarp modsætning til den måde, som en selvlært umiddelbart ville programmere. Her blandes faserne sammen i hovedet på programmøren, som skifter mellem dem, mens han programmerer. Resultatet er ofte et program, der bærer præg af ad-hoc-udbygninger og som er svært at overskue og vedligeholde - selv for programmøren selv¹.

Den bedste udviklingsmetode findes nok et sted mellem de to ekstremer. Der dukker f.eks. altid nye ting op under programmeringen, som gør, at man må ændre sit design. Omvendt er det svært at programmere uden et gennemtænkt design.

Derfor er det ikke en god ide at bruge alt for lang tid på at lave fine tegninger og diagrammer - en blyantskitse er lige så god. Det er indholdet, der tæller, og ofte laver man om i sit design flere gange, inden programmet er færdigt. Dette gælder især, hvis man er i gang med at lære at programmere.

Dette kapitel viser gennem et eksempel (et Yatzy-spil) en grov skitse til objektorienteret analyse og design (forkortet OOAD). Det er tænkt som inspiration til, hvordan man kunne gribe sit eget projekt an, ved at følge de samme trin.

22.1 Krav til programmet

Vi skal lave et Yatzy-spil for flere spillere. Der kan være et variabelt antal spillere, hvoraf nogle kan være styret af computeren. Computerspillerne skal have forskellige strategier (dum/tilfældig, grådig, strategisk), der vælges tilfældigt.

Efter at spillet er afsluttet, huskes resultatet i et lager, hvorfra man kan generere en hiscore-liste.

22.2 Objektorienteret analyse

Analysen skal beskrive, hvad det er for ting og begreber, programmet handler om. Analyse-fasens formål er, at afspejle virkeligheden mest muligt.

22.2.1 Skrive vigtige ord op

Det kan være en hjælp først at skrive alle de navneord (i ental) eller ting op, man kan komme i tanke om ved problemet. Ud for hver ting kan man notere eventuelle egenskaber (ofte tillægsord) og handlinger (ofte udsagnsord), der knytter sig til tingen.

22.2.2 Brugssituationer

Brugssituationer (eng.: Use Case) beskriver en samling af aktører og hvilke brugssituationer de deltager i. Man starter helt overordnet og går mere og mere i detaljer omkring hver brugssituation.

Man kan hævde, at Yatzy-spillet er på grænsen til at være for simpelt til at lave brugsmønstre. Herunder to brugssituationer. Til venstre ses et meget overordnet, der beskriver to spillere og lageret som aktører. Til højre ses brugssituationen omkring en tur.

I stedet for at tegne flotte diagrammer kan man også blot beskrive hver brugssituation med almindelig tekst.

22.2.3 Aktivitetsdiagrammer

Aktivitetsdiagrammer beskriver den rækkefølge, som adfærdsmønstre og aktiviteter foregår i. Eksempel: Aktiviteten "definere deltagere i spillet":

22.2.4 Skærmbilleder

Hvis skærmbilleder er en væsentlig del af ens program, er det en god hjælp at tegne de væsentligste, for at gøre sig klart, hvilke elementer programmet skal indeholde.

Disse kan med fordel designes direkte med et Java-udviklingsværktøj. Herved opnår man en ide om, hvad der er muligt, samtidig med at den genererede kode ofte (men ikke altid!) kan genbruges i programmeringsfasen.

Normalt kommer der en klasse for hvert skærmbillede, så man kan også med det samme give dem sigende navne.

Når programmet startes, skal vælges 2-6 spillere, hvoraf nogle kan være computerspillere:

Når spilleren er færdig (efter max 3 kast), skal han/hun vælge, hvilken regel der skal bruges, ved at klikke på den i blok-vinduet:

22.3 Objektorienteret design

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

22.3.1 Design af klasser

Et udgangspunkt for, hvordan man designer klasserne og objekterne i sit program, er at objekterne i programmet skal svare nogenlunde til de virkelige, oftest fysiske objekter fra problemstillingen.

Det er vigtigt at huske, at dette kun er tommelfingerregler, som man ikke kan tage alt for bogstaveligt. Man bliver ofte nødt til at dreje tankegangen lidt for at få den til at passe i sit eget program.

F.eks. er en blyant eller et andet skriveredskab uundværlig i et virkeligt, fysisk Yatzy-spil (ellers kan man ikke skrive på blokken), men ingen erfarne programmører kunne drømme om at lave en Blyant-klasse og oprette Blyant-objekter, da blyanter slet ikke er vigtige for logikken i spillet.

22.3.2 Kollaborationsdiagrammer

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

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, som 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 Spiller 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.

22.3.3 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. købeudgaven af JBuilder eller TogetherJ, der kan hentes i en gratis prøveudgave på http://www.togethersoft.com ), der samtidig kan generere kode til programmeringsfasen.

Engelsk-dansk ordliste

Stikordsregister

I de sidste år har jeg samlet på rettelser, kommentarer og forslag til bogen og derudover selv undervist i den. Rettelserne og forbedringerne er næsten alle ført ind i tredje udgave

Selvom der er kommet meget stof til, er sidetallet ikke øget. I stedet er de eksisterende sider blevet bedre udnyttet.

ArrayList i stedet for Vector, HashMap i stedet for Hashtable, Iterator i stedet for Enumeration (OK?)

Brug at generics (f.eks. ArrayList<String>, dvs ArrayList der KUN kan indeholde strenge) (OK?)

den sidste printf-sætning formateres et Date-objekt (dato og tid). Her er nogle af typerne:

xxx Husk at sætte linjenummerering i typografi "kode m linienr." før ny udgave udgives

1En helt anden arbejdsform, der prøver at gå med den umiddelbare impuls til at programmere med det samme, er ekstremprogrammering. I denne form beskriver man først kodens ønskede opførsel i form af testtilfælde, der kan afprøves automatisk gennem hele forløbet. Så programmerer man to og to foran samme tastatur, indtil testene er opfyldt. Til sidst lægger man sig fast på et fornuftigt design og omstrukturerer programmet til at passe med det valgte design.

access	adgang, tilgang
applet	applet miniprogram der kan køre i en netlæser, f.eks. Netscape
array	tabel, række, array
assignment	tildeling a=5; er en tildeling af værdien 5 til variablen a
backslash	bagstreg ( \ - angives som '\\' i kildeteksten)
backspace	bak-tegnet ('\b')
block (statement)	blok en gruppering af kommandoer. Starter med { og slutter med }
boolean	logisk (boolsk) værdi sand (true) eller falsk (false).
browser	netlæser (f.eks. Netscape, Opera eller Internet Explorer)
bytecode	mellemkode binær kode i en .class-fil, genereret af Java-oversætteren fra en .java-kildetekst.
carriage return	vognretur ('\r')
cast	typekonvertering f.eks a = (int) f; konverterer værdien af f til et heltal før det tildeles a
character	tegn f.eks 'b', '9', '?'
character set	tegnsæt
checked exception	undtagelse med tvungen håndtering
class	klasse beskrivelsen af en objekttype
comment	kommentar tekst der forklarer programmet. Ignoreres af maskinen. En linje der starter med // bliver opfattet som en kommentar
compiler	oversætter f.eks fra Java-kildetekst til bytekode
concatenation	sammensætning (af tegnstrenge) f.eks "Hej " + "verden" sammensætter to strenge
condition	betingelse a>5 er betingelsen i sætningen: if (a>5) System.out.println("a er 6 eller derover");
constructor	konstruktør
debugging	fejlfinding/aflusning af et program f.eks med trinvis gennemgang
declaration	erklæring int a; er en erklæring af, at a er et heltal.
decrement	nedtælling
deprecated	frarådet, forældet
digit	ciffer
encapsulation	indkapsling
enumeration	opremsning (af nogle elementer)
event	hændelse
event driven	hændelsesstyret
exception	undtagelse
expression	udtryk f.eks (a*5)/7
file	fil
floating-point number	kommatal i Java er kommatalstyperne float og double.
graphical user interface	grafisk brugergrænseflade
hardware	maskinel
host	værtsmaskine
identifier	navn f.eks a, public, class, int
increment	optælling
indentation	indrykning
inheritance	nedarvning
instance	instans, forekomst en forekomst af en klasse er et objekt, f.eks er "Hej" en forekomst af String
integer	heltal i Java er heltalstyperne int, long, short og byte.
interface	grænseflade
interpreter	fortolker
label	etikette
library	bibliotek
listener	lytter (efter hændelser)
location (in memory)	plads (i lager)
loop	løkke
memory	lager
method	metode f.eks har System.out metoden println()
nested	indlejret
newline	linjeskift ('\n')
open source	åben kildekode/kildetekst at kildeteksten er frit tilgængelig for forbedringer
overloading	overlæsning, navnesammenfald af metoder
override	tilsidesætte/omdefinere/overstyre/overskrive metode i en nedarvet klasse
package	pakke
parse	analysere, fortolke
pointer	reference/peger/hægte til et objekt et sted i lageret
polymorphism	polymorfi
reference	reference/peger/hægte til et objekt et sted i lageret
rounding	afrunding
scope	virkefelt
service	tjeneste
software	programmel
source code	kildetekst, kildekode
statement	sætning, ordre, kommando f.eks System.out.println("Hej"); eller a = 5;
stack trace	stakspor
stream	strøm
string	tekststreng
subclass	underklasse, subklasse, afledt klasse, nedarvet klasse
test	afprøvning
thread	tråd
token	brik, bid
truncation	nedrunding (3.7 bliver rundet ned til 3.0)
typecast	typekonvertering f.eks a = (int) f; konverterer værdien af f til et heltal før det tildeles a
underscore	understreg ('_' )
unchecked exception	undtagelse uden tvungen håndtering
variable	variabel
visibility	synlighed
whitespace	blanktegn mellemrum, tabulatortegn og linjeskift er blanktegn

22 Objektorienteret analyse og design