Hva gjøres i design? 19. september 2002, Tore Berg Hansen, TISIP

Hva gjøres i design? 19. september 2002, Tore Berg Hansen, TISIP Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker å bruke leksjonene til undervisning eller kursformål må ta kontakt med TISIP for nærmere avtale. Tore Berg Hansen

Innholdsfortegnelse Innledning...1 Aktivitetene i design...2 Modellene i design...2 Use case modeller...2 Interaksjonsmodeller...2 Patterns...2 Ekspert...3 Skaper...4 Løs kobling...5 Høy kohesjon...6 Kontroller...7 Klassediagrammene i design...7 Lesestoff...7 i

Innledning I en tidligere leksjon så vi på hva vi gjør i analysen. Et av poengene er at i objektorientert systemutvikling er skillet mellom analyse og design flytende. Vi illustrerte det som et kontinuum som vist i denne figuren. (Dere finner den igjen i Larman sin bok). Mer analyseorientert Mer designorientert hva krav undersøkelse av domenet hvordan logisk løsning Det er også slik at i et objektorientert utviklingsprosjekt vil vi kjøre flere runder med litt analyse, litt design og litt implementasjon. Dette var tema i en tidligere leksjon. I analysen finner man frem til de objekter (også kalt konsepter) som er typiske for problemdomenet. Dette er ikke programvareobjekter, men objekter som er i den virkelige verden. Dvs objekter fra problemområdet (også kalt problemdomenet). Under design finner man frem til programvareobjekter som kan realiseres i et programmeringsspråk og fortrinnsvis i et objektorientert programmeringsspråk som C++ eller Java. I design detaljerer vi klasser som skal inngå i programmet som skal utvikles. Mange av disse klassene henter vi fra problemdomenemodellen. Det er nettopp noe av poenget med objektorientering. Vi arbeider med de samme begreper i programmet som i den virkelige verden. Det gjør det lettere å forstå programmene fordi terskelen fra problem til program blir mindre. Men vi legger også til klasser som vi finner opp for å kunne lage en god løsning. Det kan også tenkes at konsepter fra problemområdet ikke vil bli brukt i programmet eller de kan bli attributter i klasser. I design arbeider vi altså med å finne frem til programvareklasser. Resultatet er en logisk løsning basert på det objektorienterte paradigme. Oppgaven er å fordele ansvar på samarbeidende objekter. Samarbeidet skjer ved at objektene sender meldinger til hverandre. Ansvaret som skal fordeles er uttrykt i use case og systemoperasjoner. Til støtte for arbeidet har vi god praksis nedfelt i såkalte mønstre (engelsk patterns). Interaksjonsdiagrammer er det viktigste arbeidsredskapet i design. Objektene defineres i klasser. Vi detaljerer klassene til et nivå hvorfra vi mer eller mindre rett frem kan skrive koden for klassene i det programmeringsspråket vi skal implementere i. Hvis vi bruker et verktøy som Rational Rose og legger våre modeller inn der, kan noe av koden genereres automatisk av verktøyet. I design lager vi designmodellen. Den består av interaksjonsdiagrammer og programvare klassediagrammer. Vi har i leksjon 2 og 3 sett innledningsvis på hva vi gjør i design. I denne leksjonen skal vi skal vi se på noen flere detaljer. 1

Aktivitetene i design I design er vi opptatt av å få detaljert hvordan systemet som skal utvikles skal bygges. I Unified Process gjøres det vesentlige av designarbeidet i bearbeidingsfasen. Men noe design vil vi kunne gjøre i oppstartsfasen og også i senere faser. Under design får vi gjerne mer kunnskap som gjør at vi kan komme til å gjøre endringer på tidligere beslutninger. Jaccobson 1 skriver: I design utvikler vi en design modell. Det skjer i tre trinn. 1. Identifikasjon av implementasjonsmiljøet. 2. Ta hensyn til dette og utvikle en første versjon av design modellen. 3. Beskriv hvordan objektene samspiller i hver use case Hos Jacobson består Designmodellen av objekter som utgjør strukturen i systemet. Larman inkluderer to modeller i Designmodellen. De er programvare klassemodell og interaksjonsmodell. Begge disse illustreres i diagrammer med bruk av UML. I læreboken 2 poengterer forfatteren hvor viktig det er å arbeide med interaksjonsdiagrammer i design. Han sier at mesteparten av tiden i design vil man bruke på slike diagrammer. Vi kommer tilbake til dette. Men vi kommer også til å arbeide med andre modeller. Modellene i design I design arbeider vi mye med interaksjonsdiagrammer. Det er en smakssak hvilken type interaksjonsdiagram man velger sekvensdiagram eller samarbeidsdiagram. Sekvensdiagrammer viser best rekkefølgen av hendelser, mens samarbeidsdiagrammer bedre får frem mønstre i samarbeidet og hvordan ansvaret er fordelt. Arbeidet med interaksjonsdiagrammer tar en vesentlig del av tiden i designfasen. De andre modeller man arbeider med er use case modeller og design klassemodeller (programv are klassemodell). Use case modeller Man lager reelle (konkrete) use case under design. Dette er noe av det første man starter opp med i denne fasen. En reell use case viser hva som skjer i samspillet mellom systemet og aktører uttrykt i konkrete termer knyttet til en inn/ut teknologi. Hvis f.eks et grafisk brukergrensesnitt er en del av systemet vil use case inneholde detaljerte beskrivelser av vinduer og dialoger. Det er ikke nødvendig å lage brukergrensesnittet, det kan utstå til implementasjon. Men detaljerte skisser må i det minste foreligge. Egnede verktøy kan brukes til å utforme brukergrensesnittene. Interaksjonsmodeller Disse lages på basis av - den konseptuelle modell - eventuelt kontrakter for systemoperasjoner - reelle use case Interaksjonsdiagrammet skal vise utvekslingen av meldinger mellom instanser (objekter) av klasser i klassemodellen. UML definerer to slags interaksjonsdiagrammer. Det er samarbeidsdiagram og sekvensdiagram. Ikke alle har forstått betydningen av å legge arbeid i å lage interaksjonsdiagrammer. Men nøkkelen til suksess ligger i riktig fordeling av ansvar mellom objekter og i dette arbeidet er interaksjonsdiagrammer et uvurderlig hjelpemiddel. Interaksjonsdiagrammer er et av de mest verdifulle ting som lages i objektorientert design. En vesentlig del av tiden i prosjektet må brukes på disse. Patterns Pattern kan oversettes med mønster. Dette temaet har blitt viet stor oppmerksomhet i den senere tid. Vi vil i dette faget kun gi en introduksjon. Mønstre kunne vært et eget fag. Pattern må også sees i sammenheng med begrepet 1 Ivar Jacobson, Object-Oriented Software Engineering A Use Case Driven Approach, Addison-Wesley, 1992, ISBN 0-201-54435-0 2 Craig Larman, Applying UML and Patterns An Introduction to Object-Orientetd Analysis and Design and the Unified Process, Prentice Hall, 2001, andre utgave, ISBN 0-13-092569-1 2

arkitektur som vi skal se litt på i en senere leksjon. Arkitektur dreier seg om mønstre på et overordnet nivå, mens patterns i den sammenheng vi skal se på her dreier seg om hvordan man fornuftig detaljerer oppbygningen av programmer. Til alle tider har dyktige og erfarne programvareutviklere laget gode programmer. Noe av årsaken til suksessen har vært ubevisst og bevisst bruk av programvarestrukturer som erfaringsmessig har vist seg å gi gode resultater for bestemt e typer av applikasjoner. Erfarne utviklerne har gjerne en verktøykiste med både generelle prinsipper og anerkjent praksis. Det har etter hvert kommet en del litteratur på markedet hvor man har forsøkt å samle og kategorisere disse prinsipper og praksis. En klassiker er boken til Gamma 3 m.fl (kjent som the gang of four ). I denne boken blir begrepet definert. Boken inneholder en beskrivelse av 23 patterns. I boken er et pattern bl.a beskrevet ved sitt navn, hvilke typer av problemer det er tenkt å løse og eksempler på bruk. Et pattern dokumenteres også ved samarbeidsdiagrammer. I denne leksjonen vil jeg følge opplegget til Larman. Han har også en del andre patterns enn Gamma. Her følger noen av de nyttigste patterns som er beskrevet i boken til Larman. Ekspert Ekspert er et pattern som gir svaret på hva som er det grunnleggende prinsipp for tildeling av ansvar til objekter. Prinsippet sier: Ansvar gis til den klasse som har den nødvendige informasjon for å kunne oppfylle ansvaret. I vårt eksempel med reis eplanleggeren betyr det at det objektet som skal ha ansvaret for å legge opp en reise er det objektet som har den nødvendige kunnskap. Jeg lar det være en del av neste øving å finne ut av det. Eksemplet i neste figur er hentet fra Larman sin bok. Salg dato tidspunkt inneholder 1..* VareLinje kvantitet * beskrevetav Produktspesifikasjon beskrivelse pris UPC Eksemplet er hentet fra en problemstilling hvor man ønsker å plassere ansvaret for å finne det totale salgsbeløp. Legg merke til at man som kandidater har hentet klasser fra problemdomenemodellen. Her gis ansvaret til salg som har all nødvendig informasjon. Salg kjenner til alle varelinjer som inngår i salget. Hver varelinje kjenner til spesifikasjonene for varen som inngår. Her har vi tre eksperter som hver har kunnskap om deler av salget: Salg har ansvar for å finne den totale salgssum VareLinje har ansvar for å finne delbeløpet Produktspesifikasjon har ansvaret for produktprisen Det betyr at klassene får operasjoner som vist i neste figur. 3 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns Elements of Reuseable Object- Oriented Software", Addison-Wesley, 1995, ISBN 0-201-63361-2 3

Salg dato tidspunkt total() VareLinje kvantitet Produktspesifikasjon beskrivelse pris UPC pris() Vi summerer opp: Ekspert er det mest brukte pattern Informasjon kan være fordelt på flere klasser Vi får programvareobjekter som har en parallell til de tingene de representerer Gir innkapsling (et viktig objektorientert prinsipp) Støtter løs kobling Vi får lettvektsklasser med høy kohesjon De to siste begrepene skal vi komme tilbake til. Skaper Skaper (engelsk Creator). Dette mønsteret skal gi svar på hvilket objekt som skal ha ansvaret for å instansiere klasser (dvs skape objekter i et program). Kandidatene er karakterisert ved at de aggregerer et objektet inneholder objektet lagrer instanser av objektet er brukere av objektet har initialiseringsdata som objektet trenger når det skapes Samme eksempel som foran er vist i neste figur. 4

Salg dato tidspunkt inneholder 1..* Produktspesifikasjon VareLinje kvantitet * beskrevetav beskrivelse pris UPC Vi gir ansvaret for å skape VareLinje til Salg fordi Salg inneholder eller faktisk aggregerer mange VareLinje. Det betyr at vi har situasjonen som vist i neste figur. skapvarelinje(kvantitet) 1: create(kvantitet) :Salg Salg dato tidspunkt :VareLinje total() skapvarelinje() Løs kobling Løs kobling er et design prinsipp som skal sørge for at de objektene vi lager skal være egnet for gjenbruk samtidig som programmene blir lettere å forstå, vedlikeholde og utvide. Figuren viser to mulige design av samme problem 5

betal() :Kasseterminal 1: create() b:betaling 2: leggtilbetaling(b) :Salg betal() :Kasseterminal 1: betal() :Salg 1.1: create() :Betaling Eksemplet er kyttet til betaling i en kasseterminal. Den nederste løsningen er bedre enn den øverste. Årsaken ar at den fordeler ansvaret for å ta betaling på flere objekter. Det legger færre oppgaver på klassen Kasseterminal. Den får færre koblinger. I dette enkle eksemplet er ikke antallet koblinger noe problem i noen av løsningene. Men man skal når man designer alltid ha i bakhodet at man bruker prinsippet for å evaluere sin design. Hvis man oppdager at noen klasser har fått mange koblinger til andre objekter bør man se etter om det ikke er mulig å delegere til flere objekter. To klasser X og Y er koblet hvis X har et attributt som refererer til en instans av Y X har en metode som referer en instans av Y X er direkte eller indirekte en subklasse av Y (arv) Y er et grensesnitt og X implementerer grensesnittet Bruk av prinsippet fører til uavhengige klasser. Arv skal bukes med forsiktighet. Det fører nemlig til sterk kobling mellom klasser. Arv var i objektorienteringens barndom nærmest et hellig prinsipp. Det skulle føre til gjenbruk av kode ved at man enten kunne bruke et objekt som det var, eller man kunne gjøre små endringer ved å lage subklasser. Et av problemene med arv er at de bryter med prinsippet om løs kobling. Særlig i dype arvhierarkier kan man etter hvert miste oversikten. Og hvis man oppdager at ting i superklassen må forandres for at et nedarvet objekt skal kunne brukes er man ille ute. Da må alle klasser som bruker superklassen endres! Og det fremmer ikke gjenbruk. Altså: Bruk arv med forsiktighet. Hvis du kan unngå bruk av arv så gjør du det! Høy kohesjon Prinsippet om høy kohesjon er tett koblet til prinsippet om løs kobling. Begge har sin opprinnelse i tidligere tiders strukturerte metoder. Her er poenget å bygge programmer ved hjelp av moduler som er løst koblet og som hver ideelt gjør bare en ting. Modulene skal være enfoldige. En enfoldig modul som bare gjør en ting har høy kohesjon. Prinsippet er overført til objektorientering. Man skal altså tilstrebe klasser med høy kohesjon. Da får man systemer som er lette å forstå består av gjenbrukbare komponenter lette å vedlikeholde og endre I eksemplet foran om løs kobling representerte den nederste design det beste valg. Også når vi anvender prinsippet om høy kohesjon er dette valget det beste. Vi konkluderer: Løs kobling og høy kohesjon må ses i sammenheng. De er prinsipper for design man alltid skal ha i bakhodet når man designer. En klasse med høy kohesjon er kjennetegnet ved: 6

et lite antall operasjoner som gjør lite arbeid lette å forstå lette å vedlikeholde at de samtidig fører til løs kobling Kontroller Dette er det siste pattern vi skal se på i denne modulen. En kontroller skal håndtere systemmeldinger. I leksjon 5 så vi at en systemmelding er en ekstern melding til systemet. Kilden til meldingen er utenfor systemet og sendes av aktører. Systemmeldinger gir opphav til systemoperasjoner i programsystemet som er under design. Prinsippet sier at systemmeldinger skal håndteres av klasser med en av disse egenskapene: Representerer hele systemet (fasade kontroller) Representerer en hel virksomhet eller organisasjon (fasade kontroller) Representerer noe i den virkelige verden som er aktivt, f.eks rollen til en person (rolle kontroller) Representerer en kunstig håndterer for alle systemhendelser i en use case (use case controller) Med kunstig mener vi at vi lager klassen spesielt for formålet og at den ikke finnes igjen i problemdomenet til programmet vi skal utvikle. Hvis man har en klasse Reiseplanlegger eller Reise i løsningen av vår øvingsoppgave, så er de eksempler på klasser som representerer hele systemet. Hvis man har en klasse Reiseplanlegger så er det et eksempel på en rolle. De er kandidater til å håndtere meldinger som planleggreise() eller legginnstrekning() osv. Valg av kontrollerklasser må også ses i sammenheng med prinsippene om løs kobling og høy kohesjon. Dvs man må ikke legge for mye ansvar på noen få klasser. God objektorientert design tilsier delegering. Rollekontrollere kan lett føre til inkohesive klasser. Dvs at de ikke vil være enfoldige. Og husk at kontrollerklasser ikke skal ligge i brukergrensesnittet (Se side 243 246 i læreboken). Hvis man gjør det binder man systemoperasjonene til et bestemt brukergrensesnitt. Det reduserer muligheten for gjenbruk og gjør det vanskeligere å bytte brukergrensesnitt. Klassediagrammene i design Når alt ansvar er fordelt på klasser, lager vi designets klassemodell. Utgangspunktet er interaksjonsdiagrammene som er laget når vi har brukt de forskjellige design patterns for fordeling av ansvar og oppfyllelse av postbetingelsene i kontraktene for hver systemhendelse. Design klassemodellen er gjerne en videreutvikling av den konseptuelle modellen. Mange av klassene har paralleller i den modellen. Design klassemodellen inneholder programvareklasser. Dvs programvareenheter. Vi husker at i den konseptuelle modellen (også kalt problemdomenemodellen) er det konsepter fra den virkelige verden som inngår. Design klassemodellen gir informasjon om klasser, assosiasjoner mellom klasser og attributter grensesnitt med operasjoner og konstanter operasjoner med angivelse av parametere, typen til parametere, returverdier og typen til returverdier typen til attributter navigerbarhet avhengigheter Gir vi all denne informasjonen til et verktøy, kan dette generere en god del av koden for oss. Lesestoff I tilknytning til denne leksjonen kan dere lese disse kapitlene: 14, 15, 16, 17 7