OOSU 21.sept 2011

1. OOSU 21.sept 2011 PATTERNS (mønstre) • Hva er et Pattern – opprinnelsen • Mal for en Patternbeskrivelse • Hva er et PatternLanguage ? • 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 : EssensialConcepts and Terminology”

2. Pattern – har sin opprinnelse innen arkitektur (byplanlegging / bygninger) • Eachpatterndescribes a problem whichoccurs over and over again in ourenvironment, and thendescribesthecoreofthesolution to that problem, in such a waythatyoucanusethissolution a million times over, without ever doing it the same waytwice. (Christopher Alexander e.a. 1977) • Opererer med flere nivåer av patterns som samlet utgjør en helhet ( 253 i alt ) • Region og by • (Communityof 7000, Ring roads, Nine per cent parking ) • Nabolag og bygningsgrupper • (Pedestrianstreet) • Enkeltbygninger og rom • (Main enterance, The flowthroughrooms, Cooking layout)

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

4. 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)

5. 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)

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

7. Hvilke typer Patterns har vi innen systemutvikling ? Patterns – et eksempelpå at fagfeltetsystemutviklingharlærtmyefraandrefagfelt, ogutfradettelaget sine fagspesifikkebeskrivelser. Men detertildels en “hype” rundt patterns. Listen under visernoenkategoriersomeromtaltilitteraturen med navnpånøkkelpersoner. Benyttdem, men gjørdetkritisk. • 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

8. Kjennetegnved 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. (http://hillside.net/patterns/definition.html)

9. Patterns – i teorien I OOSU jobber vi ikke med å implementere Patterns, men dereskal : • få en forståelseavideenebakognytteni Patterns • kjenneoppbygningeni et Pattern • kunneleseogsettedere inn iulike Design Pattern • bliinnstiltpå å søkeiekspertenesgenerelleløsningsskisserfremfor å “finneopphjuletpånytt” nårdereutviklerprogramvare

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

11. Design Patterns vi gjennomgåri OOSU : Gang of Four : • Creational : Singleton • Structural : Adapter, Facade, Decorator • Behavioral : Observer, Strategy POSA-boka : • Model-View Controller - arkitekturpattern

12. 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)

13. Ansvarsformer : Handling og Kunnskap Handling (Doing) : • Doingsomethingitself, such as creating an object or doingcalculation • Initiating action in otherobjects • Controlling and coordinationactivities in otherobjects Kunnskap (Knowing): • Knowingabout private encapsulated data • Knowingaboutrelatedobjects • Knowingaboutthings it canderive 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).