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 VL 11 • Introduction and Vocabulary • 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 . b) Uppaal query language VL 14 c) implementing CFA . d) an outlook on UML State Machines . VL 15 • Design Patterns . • Testing: Introduction – 15 – 2015-07-04 – Sblockcontent – 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. Itprovidesasetofpredefinedsubsystems, specifiestheirresponsibilities, and includes rules and guidelines for organizing the relationships between them. Buschmann et al. (1996) – 15 – 2015-07-04 – Sarch – 5/55 Introduction Cont’d architectural pattern — An architectural pattern expresses a fundamental structural organization schema for software systems. Itprovidesasetofpredefinedsubsystems, specifiestheirresponsibilities, 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 • make comprehension and maintenance significantly easier, • avoid errors. – 15 – 2015-07-04 – Sarch – 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 frames 2. Data link 2. Data link bits 1. Physical 1. Physical – 15 – 2015-07-04 – Slayered – 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. GN ME etc. Applications G012 Pango G31 A01 G8 Cairo G6ib – 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. GN ME etc. Applications G012 Pango G31 A01 G8 Cairo G6ib – 15 – 2015-07-04 – Slayered – 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 read/write data according to data layer interface. data tier • data layer: persistent data storage; hides information about Database Server how data is organised, read, and written, offers par- ticular chunks of information in a form useful for the DBMS logic layer. (Ludewig and Lichter, 2013) • Examples: Web-shop, business software (enterprise resource planning), etc. – 15 – 2015-07-04 – Slayered – 10/55 Layered Architectures: Discussion data GNOME etc. Desktop Host 7. Application 7. Application Applications presentation tier 6. Presentation 6. Presentation 5. Session 5. Session Application Server G012 (business) logic tier 4. Transport 4. Transport data tier packets 3. Network 3. Network Pango G31 A01 G8 frames 2. Data link 2. Data link Database Server bits DBMS 1. Physical 1. Physical Cairo G6ib (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: • performance (as usual) — nowadays often not a problem. – 15 – 2015-07-04 – Slayered – 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 if the format is changed, or need to employ (costly) conversions. • filters do not use global data, in particular not to handle error conditions. – 15 – 2015-07-04 – Spipe – 13/55 Model-View-Controller – 15 – 2015-07-04 – main – 14/55 Example: Model-View-Controller uses sees change of visualisation controller view notification of updates manipulation access to data of data model tand_KWZ.jpg Dergenaue, CC-BY-SA-2.5 https://commons.wikimedia.org/wiki/File:Maschinenleits – 15 – 2015-07-04 – Smvc – 15/55 Example: Model-View-Controller uses sees change of visualisation controller view notification of updates manipulation access to data of data model tand_KWZ.jpg Dergenaue, CC-BY-SA-2.5 • 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; https://commons.wikimedia.org/wiki/File:Maschinenleits • distributed implementation (more or less) easily. • Disadvantages: • if the view needs a lot of data, updating the view can be inefficient. – 15 – 2015-07-04 – Smvc – 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. 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) – 15 – 2015-07-04 – Sdespat – 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 Mediator: Colleague Drawing Figure Pattern usage in JHotDraw framework (JHotDraw, 2007) (Diagram: (Ludewig and Lichter, 2013)) – 15 – 2015-07-04 – Sdespat – 18/55 Example: Strategy Strategy Problem The only difference between similar classes is that they solve the same problem by different algorithms. • Have one class StrategyContext with all common operations. • Another class Strategy provides signatures for all operations to be implemented differently. Solution • From Strategy, derive one sub-class ConcreteStrategy for each implementation alternative. • StrategyContext uses concrete Strategy-objects to execute the different implementations via delegation. StrategyContext Strategy + contextInterface() + algorithm() Structure ConcreteStrategy1 ConcreteStrategy2 + algorithm() + algorithm() – 15 – 2015-07-04 – Sdespat – 19/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