Indhold:
Analyse: Finde vigtige ord, brugsmønstre, aktivitetsdiagrammer og skærmbilleder
Design: Kollaborationsdiagrammer og klassediagrammer
Eksempel: Skitse til et yatzy-spil
Kapitlet giver idéer til, hvordan en problemstilling kan analyseres, før man går i gang med at programmere.
Forudsætter kapitel 5, Nedarvning.
Når et program udvikles, sker det normalt i fem faser:
Kravene til programmet bliver afdækket.
Analyse - hvad det er for ting og begreber, programmet handler om.
Design - hvordan programmet skal laves.
Programmering.
Afprøvning.
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 selv1.
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.
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.
Analysen skal beskrive, hvad det er for ting og begreber, programmet handler om. Analyse-fasens formål er at afspejle virkeligheden mest muligt.
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.
Yatzyspil - antal spillere
Terning - værdi, kaste, holde
Raflebæger - kombination, ryste, holde
Blok - skrive spillernavn på, skrive point på
Spiller - navn, type (computer/menneske)
Computerspiller - strategi (dum/tilfældig, grådig, strategisk)
Menneskespiller
Regel (kunne også kaldes en mulighed eller et kriterium) - opfyldt, brugt, antal point
Lager - hiscore
Brugsmønstre (eng.: Use Case) beskriver en samling af aktører, og hvilke brugsmønstre de deltager i. Man starter helt overordnet og går mere og mere i detaljer omkring hvert brugsmønster.
Man kan hævde, at Yatzy-spillet er på grænsen til at være for simpelt til at lave brugsmønstre. Herunder to brugsmønstre. Til venstre ses et meget overordnet, der beskriver to spillere og lageret som aktører. Til højre ses brugsmønstret omkring en tur.
Aktivitetsdiagrammer beskriver den rækkefølge, som adfærdsmønstre og aktiviteter foregår i. Eksempel: Aktiviteten "definere deltagere i spillet":
Herunder ses et diagram for spillets gang, "en tur":
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:
TilfoejSpillervindue
Under selve spillet skiftes spillerne til at få tur.
For menneske-spillerne dukker dette billede op:
Turvindue
Man kan holde på terningerne ved at klikke på afkrydsningsfelterne.
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:
Blokvindue
Designets formål er at beskrive, hvordan programmet skal implementeres.
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.
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.
Navneord (substantiver) i ental bliver ofte til klasser
Klassenavne skal altid være i ental
Udsagnsord (verber) bliver ofte til metoder
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.
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å.
Blokkens 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 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.
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.
Herunder ses, hvilke typer regler der kunne forekomme.
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.