lecture 15 architecture and design patterns
play

Lecture 15: Architecture and Design Patterns . Software Modelling - PowerPoint PPT Presentation

Topic Area Architecture & Design: Content Content (Part I) Introduction and Vocabulary VL 11 Architecture Patterns Principles of Design Layered Architectures, (i) modularity Softwaretechnik / Software-Engineering


  1. Topic Area Architecture & Design: Content Content (Part I) • Introduction and Vocabulary VL 11 • Architecture Patterns • Principles of Design • Layered Architectures, (i) modularity Softwaretechnik / Software-Engineering • Pipe-Filter, (ii) separation of concerns • Model-View-Controller. (iii) information hiding and data encapsulation . (iv) abstract data types, object orientation . • Design Patterns Lecture 15: Architecture and Design Patterns . • Software Modelling • Strategy, (i) views and viewpoints, the 4+1 view • Observer, State, Mediator, (ii) model-driven/-based software engineering • Singleton, Memento. (iii) Unified Modelling Language (UML) VL 12 (iv) modelling structure • Inversion of control. 2015-07-04 . a) (simplified) class diagrams . . • Libraries and Frameworks b) (simplified) object diagrams c) (simplified) object constraint logic (OCL) • Quality Criteria on Architectures VL 13 Prof. Dr. Andreas Podelski, Dr. Bernd Westphal (v) modelling behaviour • Development Approaches, . a) communicating finite automata . – 15 – 2015-07-04 – Sblockcontent – . • Software Entropy. b) Uppaal query language – 15 – 2015-07-04 – Scontent – Albert-Ludwigs-Universität Freiburg, Germany – 15 – 2015-07-04 – main – VL 14 c) implementing CFA . . d) an outlook on UML State Machines . • Design Patterns VL 15 . . . • Testing : Introduction 2 /55 3 /55 Introduction Introduction Cont’d • Over decades of software engineering, architectural pattern — An architectural pattern expresses a fundamental many clever , proved and tested designs structural organization schema for software systems. of solutions for particular problems emerged. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them. • Question : can we generalise , document and re-use these designs? Buschmann et al. (1996) Architecture Patterns • Goals : • “ don’t re-invent the wheel ”, • Using an architectural pattern • benefit from “ clever ”, from “ proven and tested ”, and from “ solution ”. • 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. architectural pattern — An architectural pattern expresses a fundamental structural organization schema for software systems. • The information that (where, how, ...) a well-known architecture / design pattern It provides a set of predefined subsystems, specifies their responsibilities, and is used in a given software can includes rules and guidelines for organizing the relationships between them. – 15 – 2015-07-04 – Sarch – – 15 – 2015-07-04 – Sarch – – 15 – 2015-07-04 – main – • make comprehension and maintenance significantly easier, Buschmann et al. (1996) • avoid errors. 4 /55 5 /55 6 /55

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

  3. Example: Pipe-Filter Example : Compiler ASCII Tokens AST dAST Objectcode lexical analysis syntactical analysis semantical code (lexer) (parser) analysis generation Pipe-Filter Model-View-Controller 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 – main – – 15 – 2015-07-04 – Spipe – – 15 – 2015-07-04 – main – if the format is changed, or need to employ (costly) conversions. • filters do not use global data, in particular not to handle error conditions. 12 /55 13 /55 14 /55 Example: Model-View-Controller Example: Model-View-Controller uses sees uses sees change of change of visualisation visualisation https://commons.wikimedia.org/wiki/File:Maschinenleitstand_KWZ.jpg Dergenaue, CC-BY-SA-2.5 https://commons.wikimedia.org/wiki/File:Maschinenleitstand_KWZ.jpg Dergenaue, CC-BY-SA-2.5 controller view controller view notification of notification of updates updates Design Patterns access to access to manipulation manipulation data data of data of data model 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 – – 15 – 2015-07-04 – Smvc – • distributed implementation (more or less) easily. – 15 – 2015-07-04 – main – • Disadvantages : • if the view needs a lot of data , updating the view can be inefficient. 15 /55 15 /55 16 /55

Recommend


More recommend