1 / 35

Ansvarsdrevet design og bruk av design-mønstre

Ansvarsdrevet design og bruk av design-mønstre. 04.11.2005 Kirsten Ribu. I dag. Design = klassediagram Mønstre – Patterns. Opprinnelsen til begrepet mønstre. Ideene bak design patterns stammer fra arkitektfaget, hvor Christopher Alexander utviklet et stort antall designmønstre

hayes-travis
Télécharger la présentation

Ansvarsdrevet design og bruk av design-mønstre

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Ansvarsdrevet design ogbruk av design-mønstre 04.11.2005Kirsten Ribu

  2. I dag • Design = klassediagram • Mønstre – Patterns

  3. Opprinnelsen til begrepet mønstre • Ideene bak designpatterns 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. 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ål s1:Spørsmål klasse objekt navngitt objekt

  5. Designmodell

  6. 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. 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. Kontrollobjekter • Hver use case kan ha et kontrollobjekt som styrer flyten i use caset • Kontrollobjektet er et grensesnitt-objekt • Kontrollobjekter delegereroppgaver til andre objekter

  9. Designmønstre = oppskrifter

  10. 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 grunnleggendefellestrekk • Det finnes mange mønstre (patterns) som er blitt utviklet gjennom systemutviklingens historie

  11. 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) betrakteinformasjonssystemersom varianter av kjøp/salg/produksjons-systemer

  12. Tilbake til use case modell for ’Ordrebehandlingssystem’

  13. 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.

  14. 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

  15. Use casemodell for ’Kjøp/salgsystem’

  16. Mønster for klassediagram

  17. Problem/løsning - par • Kritiske designspørsmål: • Hvordan allokere ansvar til klasser? • Hvordan skal objekter samarbeide? • Hvilke klasser skal gjørehva? • Noen utprøvde løsninger på designproblemer =best-practice prinsipper (mønstre) = patterns: eksemplifiserte kodeløsninger på design-prinsipper

  18. Gjenbruk av løsninger • Hensikt: å omsette eksisterende design kunnskap til et kodeskjelett • Man trenger ikke finne opp hjulet på nytt hver gang …. • Å navngimønstrene letter kommunikasjonen mellom utviklerne

  19. 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

  20. GRASP? • InformationExpert (Eksperprinsippet) • Creator (skaperprinsippet) • Controller (kontrollprinsippet) • Høykohesjon • Lavkobling

  21. 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

  22. 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

  23. 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

  24. 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 jobbenselv, men mottar og fordeler oppgaver – er en slags administrator • Delegereroppgaver og styrer use case. • Er et bindeledd mellom brukergrensesnittet og applikasjonslaget

  25. ’Generer spørreskjema’ igjen visSpørreskjema()

  26. Controller eksempel GUI • Fordel: Lett å bytte ut klassene over og under kontrollklassen, spesielt gernesesnitt • Styrer hendelsesforløpet i et use case Controller Kunde kundedatabase fasade

  27. 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

  28. 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 å viteom det totale antall svar på undersøkelsen?

  29. 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

  30. Finn systemklasse • Vi trenger en ’SpørreskjemaGenerator’ klasse for å opprette nye skjemaer

  31. Mer om Patterns • GOF etc….

  32. Gang of Four (GoF) Erich GammaRichard 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.

  33. 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

  34. GoF Patterns http://www.tml.hut.fi/~pnr/GoF-models/html/ • Behavioral – Oppførsel • Creational – Skaper • Structural - Struktur

More Related