1 / 29

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

Softwaretechnologie für Fortgeschrittene Teil Thaller Stunde IV: Software Engineering I. Köln 20. Januar 2011. Ein ernstes Problem …. Erfolg von IT Projekten laut Umfragen: 45,2 % aller Softwareprojekte erfolgreich. 19,4 % Zeit- und Kostenüberschreitungen. 35,4 % Fehlschläge.

cuyler
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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!

More Related