1 Ansvarsdrevet design og bruk av design-mønstre Utforming av klassediagrammer

2 I dag Om estimeringseksperimentet Design - klassediagram Mønstre – Patterns

3 Estimeringsksperimentet 22 deltakere 11 fikk oppgitt 50 timer 11 fikk oppgitt 400 timer Hvordan gikk det…….?

4 Resultat: Lavt anker - 50 timer: Svar: 30,50,60,60,70,70,75,80,100, 100,150 Gjennomsnitt: 76,8 timer Høyt anker timer: Svar: 100,150,190,200,200, 250,300,350, 400,400,400+ Gjennomsnitt: 267,3 timer

5 Designmønstre = oppskrifter

6 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

7 Hvordan finne objekter Ta først utgangspunkt i ” språket” til domenet (problemområdet) F.eks. ” produkt”, ”ingrediens”, ”kunde”, ”student”, ”konto”, ”innskudd” Bruk use case beskrivelsene Ansvar:  Hva objektet må vite  Hva objektet skal gjøre

8 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)

9

10 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’)

11 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

12 Kontrollobjektprinsippet (Controller) Hvem er ansvarlig for å håndtere systemhendelser (en hendelse som genereres av en ekstern aktør)? Løsning: Tilordne ansvar for å håndtere en systemhendelse til en av følgende klasser:  En klasse som representerer systemet eller subsystemet (fasadekontroller)  En klasse som representerer et use case scenario der systemhendelsen forkommer ofte Navn: Håndterer Eksempel: ’SpørreskjemaHåndterer’

13 Designmodellen Lag design-klassediagram parallelt med sekvensdiagrammer Lag noen sekvensdiagrammer, oppdater klassediagrammet, utvid sekvensdiagrammet etc. Designklassene er systemklasser, ikke konseptuelle klasser som i domenemodellen

14 Framgangsmåte for designmodellering Identifiser klasser ved å gå gjennom alle sekvensdiagrammene Klassenavnene er inspirert av navn i domenemodellen Legg til metodenavn ved å analysere sekvensdiagrammene Eks: Meldingen leggTilTekst() sendes til Spørsmåls-objektet. Objektet må derfor inneholde en leggTilTekst() metode

15 Ansvar og sekvensdiagrammer Ansvaret utdypes under utforming av sekvensdiagrammene Et SpørreskjemaGenerator- objekt har ansvaret for å opprette et nytt spørreskjema

16 Retningslinjer for assosiasjoner Klasse A og Klasse B er assosiert hvis  Et objekt av klasse A sender en beskjed til et objekt av klasse B  Et objekt av klasse A oppretter et objekt av klasse B  Et objekt av klasse A har attributter hvis verdier er objekter av klasse B eller mengder av objekter av klasse B  Et objekt av klasse A mottar en beskjed med et objekt av klasse B som parameter

17 Designmodell

18 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

19 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

20 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

21 Tilbake til use case modell for ’Ordrebehandlingssystem’

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

23 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

24 Use casemodell for ’Kjøp/salgsystem’

25 Mønster for klassediagram

26 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

27 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

28 Fire essensielle deler  Meningsfullt navn på mønsteret.  En beskrivelse av problemet mønsteret kan brukes på.  En løsningsbeskrivelse. Ikke konkret Ofte grafisk framstilt  Beskrivelse av konsekvensene resultater kompromisser

29 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

30 Oppsummering Bruk av patterns (mønstre) kan lette og forbedre designarbeidet Use case realisering: Designklasser og metoder finnes ved å analysere sekvensdiagrammene

31 Hva har vi sett på før: GRASP - General Responsibility Assignment Software Patterns.  Information Expert (Eksperprinsippet)  Creator (skaperprinsippet)  Controller (kontrollprinsippet)  Høy kohesjon  Lav kobling

32 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

33 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

34 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

35 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

36 ’Generer spørreskjema’ igjen visSpørreskjema()

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

38 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

39 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?  Se etter mulige systemklasser i domenemodellen

40 Eksempel Se i domenemodellen etter en klasse som kan brukes eller utvides til å lage en designklasse, for eksempel klassen ’Svar’ Lag en systemklasse ’Svar’ og gi den ansvaret for kunnskap om antall svar med metoden ’visAntallSvar()’

41 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

42 Finn systemklasse Se i domenemodellen etter mulige klasser Vi trenger en ’SpørreskjemaGenerator’ klasse for å opprette nye skjemaer

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

44 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:

45 GoF Patterns Behavioral – Oppførsel Creational – Skaper Structural - Struktur

46 Behavioral patterns Chain of responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template method Visitor

47 Creational patterns Abstract factory Builder Factory method Prototype Singleton

48 Structural patterns Adapter Bridge Composite Decorator Facade Flyweight Proxy

49 Neste gang Arkitektur