Lecture 15: Architecture and Design Patterns 2015-07-04 Prof. Dr. - PDF document

Softwaretechnik / Software-Engineering Lecture 15: Architecture and Design Patterns 2015-07-04 Prof. Dr. Andreas Podelski, Dr. Bernd Westphal Albert-Ludwigs-Universität Freiburg, Germany – 15 – 2015-07-04 – main – Topic Area Architecture & Design: Content • Introduction and Vocabulary VL 11 • Principles of Design (i) modularity (ii) separation of concerns (iii) information hiding and data encapsulation . (iv) abstract data types, object orientation . . • Software Modelling (i) views and viewpoints, the 4+1 view (ii) model-driven/-based software engineering (iii) Unified Modelling Language (UML) VL 12 (iv) modelling structure . a) (simplified) class diagrams . . b) (simplified) object diagrams c) (simplified) object constraint logic (OCL) VL 13 (v) modelling behaviour . a) communicating finite automata . – 15 – 2015-07-04 – Sblockcontent – . b) Uppaal query language VL 14 c) implementing CFA . d) an outlook on UML State Machines . . • Design Patterns VL 15 . . . • Testing : Introduction 2 /55

Content (Part I) • Architecture Patterns • Layered Architectures, • Pipe-Filter, • Model-View-Controller. • Design Patterns • Strategy, • Observer, State, Mediator, • Singleton, Memento. • Inversion of control. • Libraries and Frameworks • Quality Criteria on Architectures • Development Approaches, • Software Entropy. – 15 – 2015-07-04 – Scontent – 3 /55 Architecture Patterns – 15 – 2015-07-04 – main – 4 /55

Introduction • Over decades of software engineering, many clever , proved and tested designs of solutions for particular problems emerged. • Question : can we generalise , document and re-use these designs? • Goals : • “ don’t re-invent the wheel ”, • benefit from “ clever ”, from “ proven and tested ”, and from “ solution ”. architectural pattern — An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them. – 15 – 2015-07-04 – Sarch – Buschmann et al. (1996) 5 /55 Introduction Cont’d architectural pattern — An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them. Buschmann et al. (1996) • Using an architectural pattern • implies certain characteristics or properties of the software (construction, extendibility, communication, dependencies, etc.), • determines structures on a high level of the architecture, thus is typically a central and fundamental design decision. • The information that (where, how, ...) a well-known architecture / design pattern is used in a given software can – 15 – 2015-07-04 – Sarch – • make comprehension and maintenance significantly easier, • avoid errors. 6 /55

Layered Architectures – 15 – 2015-07-04 – main – 7 /55 Example: Layered Architectures • (Züllighoven, 2005): A layer whose components only interact with components of their direct neighbour layers is called protocol-based layer. A protocol-based layer hides all layers beneath it and defines a protocol which is (only) used by the layers directly above. • Example: The ISO/OSI reference model. data 7. Application 7. Application 6. Presentation 6. Presentation 5. Session 5. Session 4. Transport 4. Transport packets 3. Network 3. Network – 15 – 2015-07-04 – Slayered – frames 2. Data link 2. Data link bits 1. Physical 1. Physical 8 /55

Example: Layered Architectures Cont’d • Object-oriented layer : interacts with layers directly (and possibly further) above and below. • Rules : the components of a layer may use • only components of the protocol-based layer directly beneath, or • all components of layers further beneath. GNOME etc. Applications GTK+ Pango GDK ATK GIO Cairo GLib – 15 – 2015-07-04 – Slayered – 9 /55 Example: Layered Architectures Cont’d • Object-oriented layer : interacts with layers directly (and possibly further) above and below. • Rules : the components of a layer may use • only components of the protocol-based layer directly beneath, or • all components of layers further beneath. GNOME etc. Applications GTK+ Pango GDK ATK GIO – 15 – 2015-07-04 – Slayered – Cairo GLib 9 /55

Example: Three-Tier Architecture • presentation layer (or tier ): Desktop Host user interface; presents information obtained from the logic layer to the user, controls interaction with presentation tier the user, i.e. requests actions at the logic layer ac- cording to user inputs. • logic layer : Application Server core system functionality; layer is designed without (business) logic tier information about the presentation layer, may only data tier read/write data according to data layer interface. • data layer : persistent data storage; hides information about Database Server how data is organised, read, and written, offers par- DBMS ticular chunks of information in a form useful for the logic layer. (Ludewig and Lichter, 2013) – 15 – 2015-07-04 – Slayered – • Examples : Web-shop, business software (enterprise resource planning), etc. 10 /55 Layered Architectures: Discussion Desktop Host data GNOME etc. 7. Application 7. Application Applications presentation tier 6. Presentation 6. Presentation Application Server 5. Session 5. Session GTK+ (business) logic tier 4. Transport 4. Transport data tier packets 3. Network 3. Network Pango GDK ATK GIO frames Database Server 2. Data link 2. Data link DBMS bits 1. Physical 1. Physical Cairo GLib (Ludewig and Lichter, 2013) • Advantages : • protocol-based : only neighouring layers are coupled, i.e. components of these layers interact, • coupling is low, data usually encapsulated, • changes have local effect (only neighbouring layers affected), • protocol-based : distributed implementation often easy. • Disadvantages : – 15 – 2015-07-04 – Slayered – • performance (as usual) — nowadays often not a problem. 11 /55

Pipe-Filter – 15 – 2015-07-04 – main – 12 /55 Example: Pipe-Filter Example : Compiler ASCII Tokens AST dAST Objectcode lexical analysis syntactical analysis semantical code (lexer) (parser) analysis generation Sourcecode Errormessages Example : UNIX Pipes ls -l | grep Sarch.tex | awk ’{ print $5 }’ • Disadvantages : • if the filters use a common data exchange format, all filters may need changes – 15 – 2015-07-04 – Spipe – if the format is changed, or need to employ (costly) conversions. • filters do not use global data, in particular not to handle error conditions. 13 /55

Model-View-Controller – 15 – 2015-07-04 – main – 14 /55 Example: Model-View-Controller uses sees change of visualisation https://commons.wikimedia.org/wiki/File:Maschinenleitstand_KWZ.jpg Dergenaue, CC-BY-SA-2.5 controller view notification of updates access to manipulation data of data model – 15 – 2015-07-04 – Smvc – 15 /55

Example: Model-View-Controller uses sees change of visualisation https://commons.wikimedia.org/wiki/File:Maschinenleitstand_KWZ.jpg Dergenaue, CC-BY-SA-2.5 controller view notification of updates access to manipulation data of data model • Advantages : • one model can serve multiple view/controller pairs; • view/controller pairs can be added and removed at runtime; • model visualisation always up-to-date in all views; – 15 – 2015-07-04 – Smvc – • distributed implementation (more or less) easily. • Disadvantages : • if the view needs a lot of data , updating the view can be inefficient. 15 /55 Design Patterns – 15 – 2015-07-04 – main – 16 /55

Design Patterns • In a sense the same as architectural patterns , but on a lower scale. • Often traced back to (Alexander et al., 1977; Alexander, 1979). Design patterns ... are descriptions of communicating objects and classes that are cus- tomized to solve a general design problem in a particular context. – 15 – 2015-07-04 – Sdespat – A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. (Gamma et al., 1995) 17 /55 Example: Pattern Usage and Documentation Strategy: Strategy Strategy: ConcreteStrategy Painter SimpleUpdateStrategy Mediator: Colleague DrawingView Tool State: State Strategy: ConcreteContext Observer: Observer Mediator: Colleague State: StateContext DrawingEditor CreationTool SelectionTool Mediator: Mediator State: ConcreteState State: ConcreteState Observer: Subject Drawing Figure Mediator: Colleague Pattern usage in JHotDraw framework (JHotDraw, 2007) (Diagram: (Ludewig and Lichter, 2013)) – 15 – 2015-07-04 – Sdespat – 18 /55