OOSU 21.sept 2011 PATTERNS (mønstre)  Hva er et Pattern – opprinnelsen  Mal for en Patternbeskrivelse  Hva er et Pattern Language ?  Ulike typer Pattern vi anvender innen systemutvikling Dagens Pensum :  (kursorisk litteratur : kopier fra C.Alexander og andre under fagstoff i Fronterrom)  ArtSaml : Brad Appleton : ”Patterns and Software : Essensial Concepts and Terminology”

Pattern – har sin opprinnelse innen arkitektur (byplanlegging / bygninger)  Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. (Christopher Alexander e.a. 1977)  Opererer med flere nivåer av patterns som samlet utgjør en helhet ( 253 i alt )  Region og by  (Community of 7000, Ring roads, Nine per cent parking )  Nabolag og bygningsgrupper  (Pedestrian street)  Enkeltbygninger og rom  (Main enterance, The flow through rooms, Cooking layout)

Hvordan ser en Patternbeskrivelse ut ? Et Pattern er en beskrivelse. Det skal alltid være veldokumentert. Det har dannet seg en viss uniformitet, dog ingen standard for hvordan beskrivelsene bør være. Lista i artikkelen til Appleton viser sentrale elementer i oppbygningen av et pattern, og er mer detaljert enn den vi finner hos Larman : Name :Skal inneholde “betydningen”. Viktig i kommunikasjon Problem :Forteller om hva vi vil oppnå med Patternet - hensikten Context :I hvilken sammenheng er dette relevant å anvende Forces :Forklaring på kompleksiteten i problemets natur. Det gis en beskrivelse av sentrale krefter og rammer i omgivelsene. Solution :Beskrivelse på hvordan vi realiserer et design som løser problemet. Angir struktur, samarbeidsforhold og deltagere i løsningen.

forts. Examples :Viser eksempler på sammenhenger, anvendelse og |virkning av patternet i en eller flere situasjoner Resulting Context : Forteller om tilstanden, positive og negative etter anvendelse av Pattern’et Rationale :Gir en forklaring på hvordan patternet i detalj virker Related Patterns :Samhandling med andre patterns innen samme språk, evt. andre navn det kan gå under etc. Known Uses :Kjent bruk av patternet. (Det er ikke et pattern før man har vist dets styrker gjennom konkret anvendelse)

Patterns i praksis Bruk av Pattern fungerer bare godt hvis du etterhvert på en rimelig enkel måte kan:  tolke den sammenheng du står overfor  identifisere et Pattern som tilbyr løsning på dette  ut fra Pattern-beskrivelsen være i stand til å realisere løsningen i det miljøet du utvikler systemet (ved å finne ferdigdefinerte idioms eller ved å kode selv ut fra løsningsskissen)

Hva er et Pattern Language ? En samling av Patterns i en helhetlig struktur er et Pattern Language. “ Each pattern can exist in the world, only to the extent that is supported by other patterns: the larger patterns in which it is embedded, the pattern of the same size that surround it, and the smaller patterns which are embedded in it.” (Alexander, 1977) Dette skal gi deg en helhet du har å velge i når du skal komme frem til en helhetlig oppbygning av en løsning. Språket skal utover beskrivelsen av det enkelte pattern, gi deg retningslinjer i anvendelsen, og en beskrivelse av sammenhengen mellom de enkelte Pattern. Du må likevel ha frihet i dine valg og muligheter for tilpasninger for at språket skal være godt.

Hvilke typer Patterns har vi innen systemutvikling ? Patterns – et eksempel på at fagfeltet systemutvikling har lært mye fra andre fagfelt, og ut fra dette laget sine fagspesifikke beskrivelser. Men det er tildels en “hype” rundt patterns. Listen under viser noen kategorier som er omtalt i litteraturen med navn på nøkkelpersoner. Benytt dem, men gjør det kritisk.  Organizational Patterns (Jim Couplien)  Process Patterns (Scott Ambler)  Analysis Patterns(Martin Fowler)  Architecture Patterns (Frank Buschmann)  Design Patterns (Eric Gamma)  HCI / GUI Patterns (Jenifer Tidwell)  Software Anti-Patterns(Andrew Koenig)  Idioms

Kjennetegn ved et Pattern (Jim Couplien)  It solves a problem. Patterns capture solutions, not just abstract principles or strategies.  It is a proven concept. Patterns capture solutions with a track record.  The solution isn’t obvious.  It describes a relationship. Patterns don’t just describe modules, but describe deeper system structures and mechanisms.  The best patterns explicitly appeal to aesthetics and utility. (

Patterns – i teorien I OOSU jobber vi ikke med å implementere Patterns, men dere skal :  få en forståelse av ideene bak og nytten i Patterns  kjenne oppbygningen i et Pattern  kunne lese og sette dere inn i ulike Design Pattern  bli innstilt på å søke i ekspertenes generelle løsningsskisser fremfor å “finne opp hjulet på nytt” når dere utvikler programvare

Software Pattern  A design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem in object-oriented systems. It describes the problem, the solution, when to apply the solution, and its consequences. It also gives implementation hints and examples. The solution is a general arrangement of objects and classes that solve the problem. The solution is customized and implemented to solve the problem in a particular context (Gang of Four, 1995)

Design Patterns vi gjennomgår i OOSU : Gang of Four :  Creational : Singleton  Structural : Adapter, Facade, Decorator  Behavioral : Observer, Strategy POSA-boka :  Model-View Controller - arkitekturpattern

Design Patterns sin relevans innen Objektorientert Design ObjektOrientert Design = Bevissthet i tildeling/fordeling av ansvar til softwareklasser for å ivareta systemoperasjonene (realisere brukernes krav).  Hva gjør dere pr. i dag ?  Hva har dere lært om dette i Programmering og Systemutvikling?  Grunnleggende prinsipper for ansvarstildeling  Modelleringsteknikker for å fremme, diskutere og dokumentere plassering av ansvar på softwareklasser. (RDD – Responsibility Driven Design)

Ansvarsformer : Handling og Kunnskap Handling (Doing) :  Doing something itself, such as creating an object or doing calculation  Initiating action in other objects  Controlling and coordination activities in other objects Kunnskap (Knowing):  Knowing about private encapsulated data  Knowing about related objects  Knowing about things it can derive or calculate Craig Larman, Det er objektene som ivaretar selve ansvaret. Ansvarsformene implementerer man i form av metoder som defineres av klassene. I vårt emne er målet å øke bevissthet rundt plassering av ansvar på klasser innen Applikasjons- og Domenelaget. Vi tar i mindre grad for oss Presentasjons- og Databaselaget (jfr. en fire-lags arkitektur).