Design Patterns - mønstre. Kirsten Ribu

Transkript

1 Design Patterns - mønstre Kirsten Ribu

2 I dag Om estimeringseksperimentet Mer om use case estimering, fortsetter fra i går Verktøy Visual Paradigm Mønstre Patterns Mari Mæhlen kommer kl 1500 for å snakke om statistikkfaget 2

3 Eksperimentet 11 deltakere 5 fikk oppgitt 50 timer 6 fikk oppgitt 200 timer Hvordan gikk det.? 3

4 Resultat: Lavt anker - 50 timer: Svar: 40, 64,70,70,120 Gjennomsnitt: 72,8 timer Høyt anker timer: Svar: 78,100,100,190,250,700 Gjennomsnitt: 236,3 timer (minus høyeste og laveste: 160 timer) 4

5 Use case estimering - oppsummering Tell antall aktører, klassifiser som enkel, middels eller kompleks Tell antall use case, klassifiser som enkel, middels, kompleks Legg sammen til Ujusterte use case poeng UUCP Bestem omgivelsesfaktorer på en skal fra 1-5 for å få E- Faktor (E = Environment) Formelen: Omgivelsesfaktoren (environmental factor) EF =1.4+(-0.03*EFactor) Sum use case poeng: UCP = UUCP*EF 5

6 Use case estimering eksempel: Regnearket 6

7 Mønstre 7

8 Hva er et mønster (pattern)? Begrepet pattern ble definert av Christopher Alexander et al. i 1977, der det var snakk om mønstre i arkitektur Bruken av mønstre i en systemdesign kontekst er relativt ny Mesteparten av arbeidet på dette området er gjort etter Et mønster (pattern) er en formalisering av et problem med løsning. Et mønster skisser et par (problem + løsning) Brukes til å ta en beslutning om designet. Et mønster kan være nyttig for mange slags problemstillinger som har grunnleggende likhetstrekk 8

9 Patterns - gjenbruk av kunnskap om utforming (design). Historikk Standardalgoritmer (1971 Knuth) Abstrakte datatyper- trær, stakk, lister (1987 Booch) Utformingsmønstre (1995) fra Christopher Alexander(1977) mønstre i bygningsutforming Mønster beskriver et problem og dets generelle løsning ikke detaljert basert på erfaring 9

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

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) betrakte informasjonssystemer som varianter av kjøp/salg/produksjons-systemer 11

12 Tilbake til use case modell for Ordrebehandlingssystem 12

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

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 14

15 Use casemodell for Kjøp/salgsystem 15

16 Mønster for klassediagram 16

17 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 17

18 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 18

19 Patterns har navn Bruk av patterns blir stadig mer populært GoF patterns (Gang of Four) -> Creator, Factory, Singleton 19

20 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 20

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 21

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 22

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 23

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

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

26 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 26

27 Gang of Four (GoF) Erich Gamma Richard Helm Ralph Johnson John 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. 27

28 GoF Patterns Behavioral Oppførsel Creational Skaper Structural - Struktur 28

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

30 Creational patterns Abstract factory Builder Factory method Prototype Singleton 30

31 Structural patterns Adapter Bridge Composite Decorator Facade Flyweight Proxy 31

32 Patterns (Gamma 1995) 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 32

33 Eksempel: Singleton (GoF) Brukes når kun en instans av klassen forekommer: Class Depot { public static getinstance() //Get instance of the single depot { return instance; } private static Depot instance = new Depot(); private Depot() { } } 33

34 Patterns (Gamma 1995) 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 34

35 Eksempel på et mønster Navn Observer (Observatør) Beskrivelse Skiller visning av en objekttilstand fra selve objektet Problem beskrivelse Brukes når tilstanden skal vises i flere former Løsningsbeskrivelse Se neste side Konsekvenser Vanskelig å optimalisere visningsytelsen. 35

36 Multippel framvisning C D B A A B C D Subject Observer 1 A: 40 B: 25 C: 15 D: 20 Observer 2 36

37 The Observer pattern = Observatørmønsteret Subject Observer Attach (Observer) Detach (Observer) Notify () for all o in observers o -> Update () Update () ConcreteSubject ConcreteObserver GetState () subjectstate return subjectstate Update () observerstate observerstate = subject -> GetState () 37

38 Oversikt over patterns i boka Se side 270 i G&H for beskrivelser av kjente patterns 38

39 Ressurser: JAVA Patterns patterns/patterns/index.html catalog.html 39

40 40

41 Neste gang Arkitektur Model-view-controller MVC 41