Kirsten Ribu HiO 20051 Ansvarsdrevet design og bruk av design-mønstre 04.11.2005 Kirsten Ribu.

Presentasjon om: "Kirsten Ribu HiO 20051 Ansvarsdrevet design og bruk av design-mønstre 04.11.2005 Kirsten Ribu."— Utskrift av presentasjonen:

1 Kirsten Ribu HiO 20051 Ansvarsdrevet design og bruk av design-mønstre 04.11.2005 Kirsten Ribu

2 Kirsten Ribu HiO 20052 I dag Design = klassediagram Mønstre – Patterns

3 Kirsten Ribu HiO 20053 Opprinnelsen til begrepet mønstre Ideene bak design patterns stammer fra arkitektfaget, hvor Christopher Alexander utviklet et stort antall designmønstre Professor i arkitektur ved University of California, Berkeley Har skrevet en rekke bøker, som viser 'en ny vei' til bedre design Tar et oppgjør med det tradisjonelle designparadigmet, som er basert på en faseoppdelt framgangsmåte:  Analyse leder til spesifikasjon, som er grunnlag for konstruksjon (fossefall)

4 Kirsten Ribu HiO 20054 Klasser og objekter I UML er klasser og objekter illustrert på samme grafiske måte, men navnet er understreket i objektene. Spørsmål:Spørsmåls1:Spørsmål klasseobjektnavngitt objekt

5 Kirsten Ribu HiO 20055 Designmodell

6 Kirsten Ribu HiO 20056 Objektdesign: Ansvarstilordning UML definerer ansvar som en ’kontrakt’ i en klasse Ansvar er knyttet til objektet i form av dets oppførsel  Handling: Opprette objekt, beregning  Kunnskap: Vite om private data, vite om relaterte objekter Ansvar er ikke det samme som metoder, men metoder implementeres for å oppfylle ansvaret Ansvarstilordning: En utfordring under utforming av sekvens-diagrammer

7 Kirsten Ribu HiO 20057 Objektdesign Ekspertprinsippet: La det objektet som har kunnskapen (dataene) også behandle den (Eksempel ’Spørreskjema’) Kontrollobjektprinsippet: Velg objekt som håndterer systemhendelser (Eksempel: ’SpørreskjemaHåndterer’ – use case kontrollobjekt) Skaperprinsippet: Legg ansvar for å opprette et nytt objekt i klassen som må vite om det nye objektet (Eksempel: ’SpørreskjemaGenerator’)

8 Kirsten Ribu HiO 20058

9 9 Kontrollobjekter Hver use case kan ha et kontrollobjekt som styrer flyten i use caset Kontrollobjektet er et grensesnitt- objekt Kontrollobjekter delegerer oppgaver til andre objekter

10 Kirsten Ribu HiO 200510 Designmønstre = oppskrifter

11 Kirsten Ribu HiO 200511 Hvorfor bruke mønstre (patterns) for informasjonssystemer? Mye av vårt daglige virke består i å lete etter strukturer (mønstre) i omgivelsene Mønstre er vanlige løsninger på vanlige problemer Det samme gjelder utvikling av informasjonssystemer Mange systemer har grunnleggende fellestrekk Det finnes mange mønstre (patterns) som er blitt utviklet gjennom systemutviklingens historie

12 Kirsten Ribu HiO 200512 Produksjon og konsumpsjon Påstand: Mennesker er:  Produsenter av varer og tjenester  Konsumenter av varer og tjenester Mange av våre aktiviteter er former for ’kjøp/salg’ og produksjon Informasjonssytemer gjenspeiler og styrer våre aktiviteter Vi kan derfor (grovt) betrakte informasjonssystemer som varianter av kjøp/salg/produksjons-systemer

13 Kirsten Ribu HiO 200513 Tilbake til use case modell for ’Ordrebehandlingssystem’

14 Kirsten Ribu HiO 200514 Fellestrekk ved informasjonssystemer Kan et kjøp/salg/produksjon system kan danne et grunnlag – mønster – for andre informasjonssystemer ? I et hvilket som helst system, hva er det som tilsvarer  Ordrene  Varene  Regnskap  Leverandøren  Kunden etc.

15 Kirsten Ribu HiO 200515 Gjenkjennelige trekk Vi finner igjen salgssituasjonen i mange sammenhenger Det er ofte nok til å komme i gang med en use case modell Og deretter et klassediagram. Vanlige klasser i et slikt system kan f.eks være:  Ordre  Lager  Leverandør  Kunde  Produkt  Faktura

16 Kirsten Ribu HiO 200516 Use casemodell for ’Kjøp/salgsystem’

17 Kirsten Ribu HiO 200517 Mønster for klassediagram

18 Kirsten Ribu HiO 200518 Problem/løsning - par Kritiske designspørsmål:  Hvordan allokere ansvar til klasser?  Hvordan skal objekter samarbeide?  Hvilke klasser skal gjøre hva? Noen utprøvde løsninger på designproblemer = best-practice prinsipper (mønstre) = patterns: eksemplifiserte kodeløsninger på design-prinsipper

19 Kirsten Ribu HiO 200519 Gjenbruk av løsninger Hensikt: å omsette eksisterende design kunnskap til et kodeskjelett Man trenger ikke finne opp hjulet på nytt hver gang …. Å navngi mønstrene letter kommunikasjonen mellom utviklerne

20 Kirsten Ribu HiO 200520 Retningslinjer for god objektdesign ’Design patterns’ er navngitte retningslinjer for hvordan ansvar skal fordeles i ulike situasjoner GRASP – ’Patterns of General Principles in Assigning Responsibilites’: Mønster for problem/løsning

21 Kirsten Ribu HiO 200521 GRASP?  Information Expert (Eksperprinsippet)  Creator (skaperprinsippet)  Controller (kontrollprinsippet)  Høy kohesjon  Lav kobling

22 Kirsten Ribu HiO 200522 Objektdesign Ekspertprinsippet: La det objektet som har kunnskapen (dataene) også behandle den Kontrollobjektprinsippet: To typer kontrollere:  Fasadekontroller: En kontrollklasse har ansvar for alt (brukes i et lite system)  Use case kontroller: Styrer ett use case (brukes i større systemer. Et kontrollobjekt for hvert use case). Skaperprinsippet: Legg ansvar for å opprette et nytt objekt i klassen som må vite om det nye objektet

23 Kirsten Ribu HiO 200523 Information Expert Tildel ansvar til den klassen som har tilgang til den nødvendige informasjonen for å gjøre jobben Eksempel: I et salgssystem: Metoden ’hentKundenummer()’ legges i klassen som har variabelen ’kundenr.’ Fordel:  Oppnår på denne måten lav kobling og høy kohesjon Ulemper:  Kan få for store klasser ved at for mye ansvar puttes inn i en klasse.  Løsning: Fordel ansvaret på to klasser

24 Kirsten Ribu HiO 200524 Creator Problem: Hvilken klasse er ansvarlig for å opprette nye objekter? Løsning: La det objektet som må vite om de nye objektene lage dem Hvordan: Gi klasse B ansvaret for å opprette et objekt av klasse A dersom ett av følgende er sant:  B inneholder A-objekter  B bruker A-objekter  B har data som sendes til A-objektet når det opprettes Eksempel:  KlasseB objektA = new KLasseB() Ulempe: Klasse A og B har høy kobling

25 Kirsten Ribu HiO 200525 Controller Hvilken klasse skal behandle en systemhendelse/melding?  Kontrolleren ligger gjerne på klienten  Kontrolleren har bare metoder, få eller ingen variabler.  Kontrolleren gjør ikke jobben selv, men mottar og fordeler oppgaver – er en slags administrator  Delegerer oppgaver og styrer use case.  Er et bindeledd mellom brukergrensesnittet og applikasjonslaget

26 Kirsten Ribu HiO 200526 ’Generer spørreskjema’ igjen visSpørreskjema()

27 Kirsten Ribu HiO 200527 Controller eksempel Fordel: Lett å bytte ut klassene over og under kontrollklassen, spesielt gernesesnitt Styrer hendelsesforløpet i et use case GUI Controller Kunde fasade kundedatabase

28 Kirsten Ribu HiO 200528 Controller forts. Ulemper:  Mange metodekall sinker systemet  Mye koding  Flere klasser  Kontrollere får for mye ansvar = mangel på kohesjon: Kontrolleren har for mange jobber å gjøre. Ansvaret og attributtene skulle vært distribuert

29 Kirsten Ribu HiO 200529 Ekspertprinsippet (Information Expert) Problem: Hva er det generelle prinsipp for å tilordne ansvar til objekter? Løsning: La det objektet som har kunnskapen (dataene) også behandle den Hvordan:  Begynn med å formulere ansvarsområdet: Hvilket objekt har ansvar for å vite om det totale antall svar på undersøkelsen?

30 Kirsten Ribu HiO 200530 Skaperprinsippet (Creator) Problem: Hvem er ansvarlig for å opprette nye objekter? Løsning: La det objektet som må vite om de nye objektene lage dem Hvordan: Gi klasse B ansvaret for å opprette et objekt av klasse A dersom ett av følgende er sant:  B inneholder A-objekter  B bruker A-objekter  B har data som sendes til A-objektet når det opprettes

31 Kirsten Ribu HiO 200531 Finn systemklasse Vi trenger en ’SpørreskjemaGenerator’ klasse for å opprette nye skjemaer

32 Kirsten Ribu HiO 200532 Mer om Patterns GOF etc….

33 Kirsten Ribu HiO 200533 Gang of Four (GoF) Erich GammaErich Gamma Richard Helm Ralph Johnson John Vlissides –Richard HelmRalph JohnsonJohn Vlissides forfatterne av boka ’Design Patterns, Elements of Reusable Object-oriented Software’ ble kjent som Gang of Four. Navnet var for langt til å brukes i e-mail, derfor ’firerbanden’. Deres mønstre er kjent som GoF patterns.

34 Kirsten Ribu HiO 200534 GOF (Gang of Four) 23 Mønstre Creational Patterns (5)  Abstract Factory, Builder, Factory Method, Prototype, Singleton Structural Patterns (7)  Adapter, Bridge, Composite, Decorator, Façade, Flyweight, Proxy Behavioural Patterns (11)  Chain of responsibility, Command, Interpreter, Iterator, Mediator,  Memento, Observer, State, Strategy, Template method, Visitor Bok: Design Patterns av Erich Gamma (Author), Richard Helm (Author), Ralph Johnson (Author), John Vlissides (Author), Publisher: Addison-Wesley Pub Co; 1st edition (January 15, 1995) ISBN: 0201633612

35 Kirsten Ribu HiO 200535 GoF Patterns http://www.tml.hut.fi/~pnr/GoF-models/html/ Behavioral – Oppførsel Creational – Skaper Structural - Struktur