Softwaretechnologie für Fortgeschrittene Teil Thaller Stunde IV: Software Engineering I

1. Softwaretechnologie für FortgeschritteneTeil ThallerStunde IV: Software Engineering I Köln 20. Januar 2011

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

3. Ein ernstes Problem …

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

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

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

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

8. Why design patterns in SA? • If you’re 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

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

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

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

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

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

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

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

16. Façade (2) • Example: graph interface to a simulation engine SchematicEditor Graph Director 2 0..* Relation Port Entity BufferedRelation AtomicEntity CompositeEntity Token Actor

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

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

19. 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 Subject Observer attach(Observer) detach(Observer) notify() update() forall o in observers o.update() ConcreteSubject ConcreteObserver getState() update() state=subject.getState();

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

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

22. Chain of Responsibility • 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 Client Handler ContextInterface() handleRequest() ConcreteHandler2 ConcreteHandler1 handleRequest() handleRequest()

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

24. 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”

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

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

27. Online resources • Pattern FAQ • http://g.oswego.edu/dl/pd-FAQ/pd-FAQ.html • Patterns home page • http://hillside.net/patterns/ • Beispieleiner (GUI) “Pattern Library” • http://www.welie.com/patterns/showPattern.php

28. 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!

29. Herzlichen Dank!