1. Softwaretechnologie für Fortgeschrittene Teil Thaller Stunde IV: Software Engineering I Köln 21. Januar 2010

2. Systemdesign / Systemplanung 2 (1)Entsteht Software, entstehen Informationssysteme als Ergebnis eines künstlerischen Prozesses? (2)Oder sind sie planbar?

3. Ein ernstes Problem … 3 Erfolg von IT Projekten laut Umfragen: 45,2 % aller Softwareprojekte erfolgreich. 19,4 % Zeit- und Kostenüberschreitungen. 35,4 % Fehlschläge.

4. Ein ernstes Problem … 4 In Abhängigkeit von der Teamgröße. Erfolgreiche Projekte bei einer Teamgröße von: Bis 4 Personen 60 % 4 – 8 Personen 38 % 8 – 20 Personen 32 % Mehr als 20 Personen 18 %

5. Ein ernstes Problem … 5

6. Design Patterns 6 (1)Eine Kunstlehre, die auf der Objektorientierung aufsetzt... (2)… so verbreitet, dass ich mir erlaubt habe, zwei sehr geringfügig modifizierte Vorlesungsfolien auswärtiger Kollegen zu benutzen.

7. Design Patterns John Reekie john.reekie@uts.edu.auohn.reekie@uts.edu.au Software Architecture 48433 21 st August 2003

8. Background Gamma, Helm, Johnson, and Vlissides (the Gang of Four) – Design Patterns, Elements of Reusable Object-Oriented Software This book solidified thinking about patterns and became the seminal Design Patterns text Software design patterns are based (somewhat) on work by the architect Christopher Alexander

9. Purpose A design pattern captures design expertise – patterns are not created from thin air, but abstracted from existing design examples Using design patterns is reuse of design expertise Studying design patterns is a way of studying how the experts do design Design patterns provide a vocabulary for talking about design

10. Why design patterns in SA? If youre a software engineer, you should know about them anyway There are many architectural patterns published, and the GoF Design Patterns is a prerequisite to understanding these: Mowbray and Malveau – CORBA Design Patterns Schmidt et al – Pattern-Oriented Software Architecture Design Patterns help you break out of first- generation OO thought patterns

11. The seven layers of architecture * Global architecture Enterprise architecture System architecture Application architecture Macro-architecture Micro-architecture Objects * Mowbray and Malveau ORB OO architecture Frameworks Subsystem Design patterns OO programming

12. How patterns arise Problem Context Solution Benefits Related Patterns Consequences Forces

13. Structure of a pattern Name Intent Motivation Applicability Structure Consequences Implementation Known Uses Related Patterns

14. Key patterns The following patterns are what I consider to be a good basic set of design patterns Competence in recognizing and applying these patterns will improve your low-level design skills (The slides are necessarily brief and do not follow the structure just given above!)

15. Composite Component Operation() Add(Component) Remove(Component) Composite Operation() Add(Component) Remove(Component) Leaf Operation() Client children 0..* For all c in children c.Operation(); Construct part-whole hierarchy Simplify client interface to leaves/composites Easier to add new kinds of components

16. Composite (2) Figure paint() translate() getBounds() CompositeFigure paint() addFigure(Figure)) removeFigure(Figure)) BasicFigure paint() View children 0..* For all c in children c.paint(); Example: figures in a structured graphics toolkit LabelFigure paint() 0..* Controller parent

17. Facade Provide unified interface to interfaces within a subsystem Shield clients from subsystem components Promote weak coupling between client and subsystem components Facade Client

18. Façade (2) Entity CompositeEntityAtomicEntity PortRelation BufferedRelation Graph SchematicEditor Example: graph interface to a simulation engine Actor Director 0..* 2 Token

19. Strategy Operation() ConcreteStrategy2 Operation() Context Make algorithms interchangeable---changing the guts Alternative to subclassing Choice of implementation at run-time Increases run-time complexity ContextInterface() ConcreteStrategy1 Operation()

20. Strategy (2) ConnectorRouter Shape recalculate(Pt, Pt) ArcRouter Shape recalculate(Pt, Pt) Connector route() StraightRouter Shape recalculate(Pt, Pt) ManhattanRouter Shape recalculate(Pt, Pt) shape=router.recalculate(start,end); redraw(shape); Example: drawing different connector styles

21. Observer Many-to-one dependency between objects Use when there are two or more views on the same data aka Publish and subscribe mechanism Choice of push or pull notification styles Observer update() Subject attach(Observer) detach(Observer) notify() ConcreteObserver update() ConcreteSubject getState() state=subject.getState(); forall o in observers o.update()

22. Factory Method Creator Product createProduct() Product Defer object instantiation to subclasses Eliminates binding of application-specific subclasses Connects parallel class hierarchies A related pattern is AbstractFactory operation() ConcreteCreator Product createProduct() ConcreteProduct operation() return new ConcreteProduct();

23. Factory Method (2) Example: creating manipulators on connectors Figure createManipulator() 0..1 Manipulator attach(Figure) ArcManipulator attach(Figure) BoundsManipulator attach(Figure) Connector createManipulator() RectFigure createManipulator() manip = new BoundsManipulator(); manip = new ArcManipulator(); Interactor

24. Chain of Responsibility Handler handleRequest() ConcreteHandler2 handleRequest() Client ContextInterface() ConcreteHandler1 handleRequest() Decouple sender of a request from receiver Give more than one object a chance to handle Flexibility in assigning responsibility Often applied with Composite successor

25. Chain of Responsibility (2) Figure handleEvent(Event) CompositeFigure Interactor children 0..* If interactor != null interactor.handle(event,this) else parent.handleEvent(event) 0..1 parent Example: handling events in a graphical hierarchy handle(Event,Figure) 0..*

26. Patterns vs Design Patterns are design But: patterns transcend the identify classes and associations approach to design Instead: learn to recognize patterns in the problem space and translate to the solution Patterns can capture OO design principles within a specific domain Patterns provide structure to design

27. Patterns vs Frameworks Patterns are lower-level than frameworks Frameworks typically employ many patterns: Factory Strategy Composite Observer Done well, patterns are the plumbing of a framework

28. Patterns vs Architecture Design Patterns (GoF) represent a lower level of system structure than architecture (cf: seven levels of A) Patterns can be applied to architecture: Mowbray and Malveau Buschmann et al Schmidt et al Architectural patterns tend to be focussed on middleware. They are good at capturing: Concurrency Distribution Synchronization

29. Online resources Pattern FAQ http://g.oswego.edu/dl/pd-FAQ/pd-FAQ.html Patterns home page http://hillside.net/patterns/ Beispiel einer (GUI) Pattern Library http://www.welie.com/patterns/showPattern.php

30. Concluding remarks Design Patterns (GoF) provide a foundation for further understanding of: Object-Oriented design Software Architecture Understanding patterns can take some time Re-reading them over time helps As does applying them in your own designs!

31. 31 Herzlichen Dank!