Chapter 13: Designing applications

LÆRINGSMÅL:

• Kan bruke verb/substantiv metoden til å finne ut
• Hvilke klasser du trenger for å løse et problem og hvilke metoder klassene skal ha
• Kan bruke scenarier (evt. med CRC kort) til å sjekke at du har funnet klassene og metodene du trenger
• Vet hva et design pattern er

 

 

VERB/SUBSTANTIV – METODE:

I virkelighetens liv er det vanskelig å finne ut av hvilke klasser vi trenger for å lage et prosjekt. Trinnene som brukes for å laget er Software-system kalles for analyse og design. Mer forklarende analyserer vi problemet, og designer en løsning.

Men for å kunne lage et Software-system må vi finne ut av hvilke klasser vi trenger, og hva klassene må inneholde for å kunne løse vårt problem.

For å oppdage og finne klasser, bruker vi verb-subjektiv-metoden. Deretter bruker vi noe som kalles for CRC-kort for å utføre designet.

Ved å ta i bruk kjennbare definisjoner som verb og substantiv ser vi at vi kan få hjelp til å løse programmeringsproblemet.

I en skildring av Software-programmet vil subjektivene referere til klasser og objekter, mens verbene vil referere til objektenes metoder (handlinger).

 

Her er en forklaring av et av mine prosjekt, som er et parkeringssystem:

Parkeringssystemet kan brukes i flere systemer og sammenhenger.  En bil skal kunne sjekkes inn i dette systemet. Hvert parkeringssystem har et sett med parkeringsplasser som er organisert etter felt- og plassnummer. Kunden kan parkere sin bil på flere selvvalgte og ledige parkeringsplasser.

 

Det som primært blir brukt som informasjonskapsel er kundens skiltnummer, men flere parameter må legges inn: bilmerke, bilmodell, farge, skiltnummer.

Parkeringsplassen skal være synlig – og en skal også har muligheten til å se om plassen allerede er reservert eller eid av en kunde. Når det er ønskelig skal kunden ha muligheten til å fjerne sin bil fra plassen, og sjekke ut av den.

 

 

 

Deretter må vi sortere verbene og subjektivene i klasser for seg selv.

 

VERB:                                                                          SUBJEKTIV:

Parkere                                                                       Parkeringssystem

Reservere                                                                   Bil

Eie                                                                               Parkeringsplasser

Fjerne                                                                         Plassnummer

Sjekke ut                                                                    Kunde

Skiltnummer

Bilmerke

Bilmodell

Farge

 

Det vil se ut som om vi har mange kandidater for klasser og metoder. Foreløpig bruker vi alle, og ekskluderer ikke noen kandidater. Akkurat nå er vi i en tidlig fase av utviklingen, og vi vet ikke hva vi har bruk for, og hva vi ikke har bruk for.

 

CRC-KORT og SCENARIOER:

Neste punkt er å ta i bruk CRC-kort. Disse kortene skal hjelpe oss med å  lage interaksjoner og forbindelser mellom klasser.

Det beste er å lage fysiske kort, og ikke lage illustrasjoner på PC  eller tegne useriøse tegninger på ark når du skal bruke CRC-kort.

Strukturen er følgende:

Tre ruter i ett kort; et areal i øverste, venstre rute som inneholder class name; et areal under første areal som inneholder responsibilities; en rute på høyre side langs rute én og to som inneholder collaborations (classer som denne bruker);

 

En ting som også er sentral i modul 5 er scenarioer. Et scenario er et eksempel på en oppgave som systemet skal kunne takle.

For eksempel:

En kunde sjekker bilen inn på parkeringssystemet, og finner en ledig plass. Kunden ser at plassen ikke eies av noen, men at den er reservert til en annen kunde. Kunden kjører videre til h*n finner en ledig plass.

 

Vi spør oss selv følgende: Hvordan kan du løse dette problemet?

Vi kan tenke slik: Det er i klassen ParkeringsSystem hele handlinger primært foregår. Før vi kan sjekke inn en bil er det viktig å lage et bil-objekt ut i fra klasse Bil: her legger vi inn nødvendige parameter. Når bilen da skal sjekkes inn, velger vi hvilken parkeringsplass bil-objektet skal plasseres på i klasse plass. Deretter får vi beskjed om at plassen i klasse plass er opptatt: dette kom fram ved å sammenlikne skiltnummeret til bi l- objektet og skiltnummeret som var lagret i plassen. Bilen går videre og finner en ledig plass.

Slike brukerscenarioer er vanlig å gjøre sammen i grupper, og hvert medlem har en egen «klasse», og forteller høyt hva den gjør, hva den mangler og hva den burde ha med.

Å lage scenarioer tar ofte veldig lang tid, men en får igjen for det.

Som nybegynner er det viktig at jeg tar meg tid til å fullføre og øve meg på slike scenarioer, og også se på hver eneste detalj – uansett om jeg mener den er viktig eller ikke.

Neste fase er å gå fra CRC-kort og scenario til å designe Java-klassene

Jeg har nå tre klasser som jeg bruker: ParkeringSystem, Plass og Bil. Hver av disse inneholder constructors, metoder, og felt.  Å bruke CRC-kortene en gang til vil være til hjelp – denne gangen kan du spesifisere litt mer hva klassen skal inneholde, og så skrive det litt mer nøyaktig og etter programmerings-skikk. Dette vil føre til at du vil ha en mindre jobb å gjøre når disse klassene skal skrives i Java. På denne måten kan du tidlig unngå unødvendige feil.

 

DESIGN PATTERN:

Et design pattern er en beskrivelse av et felles eller gjentatt problem som ofte oppstår under programmering, og en beskrivelse av en løsning på dette problemet. Løsningen kan ofte brukes på flere forskjellige måter.

Løsningen er ofte beskrevet i en liten sammensetning av klasser og deres interaksjoner.

 

Design pattern dokumenterer for gode løsninger for problemer, så disse kan bli gjenbrukt av andre.

Design pattern har også egne navn slik at det ikke er vanskelig å bruke eller snakke om det.
Disse patterns er vanligvis laget slik at de inneholder et minimun-set av informasjon. Ikke bare om struktur av klasser, men også informasjon om problemet som blir adressert

En forklaring av patterns inneholder som oftest:

• Et navn som kan bli brukt for å snakke om patternet.  For eksempel: Singleton
• Et problem som patternet adresserer for. Dette er ofte delt opp i mindre seksjoner som: hensikt, motivasjon og egnethet.
• En forklaring på løsningen. Ofte listet opp i struktur, deltakere og samarbeid.
• Konsekvenser av å bruke patternet, inkludert resultater og kompromisser.