Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

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

Liknende presentasjoner


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 Ansvarsdrevet design og bruk av design-mønstre Kirsten Ribu

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

3 Kirsten Ribu HiO 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 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 Designmodell

6 Kirsten Ribu HiO 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 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 Designmønstre = oppskrifter

11 Kirsten Ribu HiO 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 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 Tilbake til use case modell for ’Ordrebehandlingssystem’

14 Kirsten Ribu HiO 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 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 Use casemodell for ’Kjøp/salgsystem’

17 Kirsten Ribu HiO Mønster for klassediagram

18 Kirsten Ribu HiO 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 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 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 GRASP?  Information Expert (Eksperprinsippet)  Creator (skaperprinsippet)  Controller (kontrollprinsippet)  Høy kohesjon  Lav kobling

22 Kirsten Ribu HiO 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 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 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 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 ’Generer spørreskjema’ igjen visSpørreskjema()

27 Kirsten Ribu HiO 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 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 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 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 Finn systemklasse Vi trenger en ’SpørreskjemaGenerator’ klasse for å opprette nye skjemaer

32 Kirsten Ribu HiO Mer om Patterns GOF etc….

33 Kirsten Ribu HiO 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 , derfor ’firerbanden’. Deres mønstre er kjent som GoF patterns.

34 Kirsten Ribu HiO 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:

35 Kirsten Ribu HiO GoF Patterns Behavioral – Oppførsel Creational – Skaper Structural - Struktur


Laste ned ppt "Kirsten Ribu HiO 20051 Ansvarsdrevet design og bruk av design-mønstre 04.11.2005 Kirsten Ribu."

Liknende presentasjoner


Annonser fra Google