Software Design Principles Michel R V Chaudron Software

Software Design Principles Michel R. V. Chaudron Software Architecture 2019 chaudron@chalmers. se | chaudron@cse. gu. se

Software Architecture Week 36 L 1 37 L 2 37 S 1 38 L 3 38 38 39 39 39 40 40 41 42 43 Time 13: 00 – 15: 00 13: 00 – 14: 30 10: 15 – 12: 00 13: 00 - 15: 00 Lecture Introduction & Organization Architecting Process & Views << Supervision/Assignment>> Requirements & Quality Attributes 19 sept S 3 20 sept 25 sept 26 sept 27 sept 2 Oct 13: 15 – 15: 00 10: 15 – 12: 00 13: 15 – 15: 00 S 4 3 Oct 4 Oct 9 Oct 10: 15 – 12: 00 13: 00 – 15: 00 13: 15 – 15: 00 Architectural Styles 1 Architectural Styles 2 << Supervision/Assignment>> (finish) Architectural Styles & Tactics The Human Factor in Software Architecting: Cognitive and Social Aspects << Supervision/Assignment>> skip Technical Debt (Terese Besker) S 5 10 Oct 10: 15 – 12: 00 << Supervision/Assignment>> S 6 L 10 L 11 L 12 16 Oct 17 Oct 18 Oct 23 Oct 24 Oct 13: 15 – 15: 00 10: 15 – 12: 00 13: 15 – 15: 00 L 13 25 Oct Design Principles / Tactics << Supervision/Assignment>> Architecture Evaluation / Tactics Reverse Engineering & Correspondence No lecture: Lindholmen Software Development Days Guest lecture Volvo Trucks L 4 L 5 L 6 L 7 L 8 L 9 13: 00 – 15: 00 Schedule S 2 41 42 42 43 43 43 Date 4 sept 11 sept 12 sept 18 sept 13: 00 – 15: 00 Reading Note Ch 1 & 2 Ch 3 & 4 << Supervision/Assignment>> Ch 13 Ch 18 Rodi Jolak UG UG Ph. D defence Ch 6, 7 check! Ch 21 Ch 20

Software Architecture Outline n Recap ¨ Architectural Styles Design Principles n Tactics n n Course representatives? Volunteers? MRV Chaudron Sheet 3 3

Software Architecture Learning Objectives Know principles n Apply Principles n Recognize violations of design principles n n Hint: try if you can think up a counterexample for each design principle MRV Chaudron Sheet 4 4

MRV Chaudron Advice on Design of Software • • Generic Design Principles for Architectural Design Principles for Design of Components Principles for collaboration amongst Components Design = trade-offs = gray area Principles are heuristics Not today: User Interface design, protocol design 5

Software Architecture General Software - Design Principles 1 Information Hiding: All information about a module should be private to the module unless required externally Minimize Coupling Every module should depend on as few others as possible Coherence: Keep things together that belong together Keep behaviour together with related data Keep information about one thing in one place 6

Software Architecture General Software Design Principles 2 Divide and Conquer Break a big problem into smaller ones Separation of Concerns Divide into different parts logic that addresses different issues Keep it Simple 7

Software Architecture Generic Design Principles n Decomposition Break problem into independent smaller parts Independent? MRV Chaudron Sheet 8 8

Software Architecture Design Principle : Divide and conquer n Trying to deal with something big all at once is harder than dealing with a set of smaller things ¨ Each individual component is smaller, and therefore easier to understand ¨ Parts can be replaced or changed without having to replace or extensively change other parts. ¨ Separate ¨ An individual software engineer can specialize MRV Chaudron Sheet 9 people can work on separate parts

Software Architecture Ways of dividing a software system A system is divided up into ¨ Layers ¨A & subsystems subsystem can be divided up into one or more packages ¨A package is divided up into classes ¨A class is divided up into methods MRV Chaudron Sheet 10 10

Software Architecture Layer 1 Layer 2 Layer 3 Abstraction/Implementation Dimension Sy aki st ng em Functional Dimension Br Ele Sy ctr st ica em l Pr o Sy pul st sio em n Sy Fue st l em Subsystems vs Layering

Software Architecture Layering Goals: Separation of Concerns, Abstraction, Modularity, Portability Partitioning in non-overlapping units that - provide a cohesive set of services at an abstraction level (while abstracting from their implementation) 3 2 1 0 - layer n is allowed to use services of layer n-1 (and not vice versa) alternative: bridging layers: layer n may use layers <n enhances efficiency but hampers portability MRV Chaudron Sheet 12 12

Software Architecture A Component-based Reference Architecture for Computer Games (E. Folmer, 2007) specific generic MRV Chaudron Sheet 15 15

Software Architecture Example «layer» Presentation and Dialogue Layer «subsystem» Client / Browser «subsystem» M C «subsystem» «layer» Common Elements «subsystem» Client Authentication «subsystem» P «subsystem» D «subsystem» S «subsystem» M «subsystem» F «subsystem» E «layer» Business Layer «subsystem» M C «subsystem» Data Security «subsystem» M C MRV Chaudron Sheet 16 «subsystem» JR «subsystem» P «subsystem» M «subsystem» D «subsystem» F «layer» «subsystem» RC Persistence Layer «subsystem» P «subsystem» D «subsystem» Apache «subsystem» M «subsystem» F PL «subsystem» 16

Software Architecture What is a dependency? A A depends on B B n Component A requires B for it to work Run-time ¨ Functional coupling n A change in module B requires a change in module A Development-time ¨ Implementation coupling ¨ Typically requires: re-testing A & B MRV Chaudron Sheet 17 17

Software Architecture Dependency/Coupling There is coupling between two classes A and B if: • A calls a service of an object B • A has a method which references B (via return type or parameter) • A has an attribute that refers to B • A is of type (inherits from) B • A is a subclass of (or implements) class B This is not an exhaustive definition A may depend on some assumption on another component B 18

Software Architecture Design Principles n Dependencies direct in the direction of stability A B is less likely to change than A B MRV Chaudron Sheet 19 19

Software Architecture Dependency: Coupling is the degree of interdependence between modules high coupling Chapter 9: Architecting and designing software low coupling 20

Software Architecture Coupling and Cohesion n Coupling is a measure of dependency between modules. n Cohesion is a measure of the coherence (‘togetherness’) of a module amongst the pieces of that module. n In a system design, one wants high cohesion and low coupling within components MRV Chaudron Sheet 21 between components 21

Cohesion is concerned with the relatedness within a module high cohesion low cohesion Heuristic: Keep things together that belong together High cohesion within a module is good 22 M. R. V. Chaudron – May 2011

Cohesion is concerned with the relatedness within a module FILTER SORT COUNT REVIEW PRINT GAME STORE high cohesion PLAY low cohesion Heuristic: Keep things together that belong together High cohesion within a module is good M. R. V. Chaudron – May 2011

Cohesion is concerned with the relatedness within a module Provide Ride Waiting Time Convert Q-length to Wait. Time Count People in Queue GPS M. R. V. Chaudron – May 2011

Software Architecture Benefits of Low Coupling/Dependencies 1. Modules are easier to replace 2. fewer interconnections between modules reduce time needed for understanding the modules and interactions 3. fewer interconnections between modules reduce the chance that changes in one module cause problems in other modules, which enhances reusability 4. fewer interconnections between modules reduce the chance that a fault in one module will cause a failure in other modules, which enhances robustness Page-Jones, M. 1980. The Practical Guide to Structured Systems Design. New York, Yourdon Press, 1980. Chapter 9: Architecting and designing software 25

Software Architecture Reducing Coupling: Information Hiding n Information Hiding: Try to localize future change ¨ Hide system details likely to change independently ¨ Separate parts that are likely to have a different rate of change ¨ In interfaces expose only assumptions unlikely to change ¨ n Why is information hiding a good idea? ¨ which types of coupling are prevented/reduced? MRV Chaudron Sheet 27 27

Software Architecture Information Hiding is a means of avoiding dependencies. n Minimize the information interfaces disclose about the inner-workings of components ¨ Balance with genericity n Information hiding aims at avoiding dependencies on implementation details n Corollary: ¨ Components typically encapsulate volatile technologies 28

Software Architecture David Parnas We propose that one begins with a list of: ¨ difficult design decisions, or ¨ design decisions which are likely to change Each module is then designed to hide such a decision from the other modules. David Parnas 1941 -… n Goal: ISOLATE CHANGE n Means: Information hiding, minimizing dependencies n I advise students to pay more attention to the fundamental ideas rather than the latest technology. The technology will be out-of-date before they graduate. Fundamental ideas never get out of date. MRV Chaudron Sheet 29 29

Software Architecture Design Principle: Information Hiding ¨ what is inside, must stay inside. MRV Chaudron Sheet 30 30

Software Architecture WHAT versus HOW ‘WHAT’: think Responsibility, Declarative n Mechanisms are about ‘HOW’ n WHAT: Build a house HOW: stone, sticks, straw MRV Chaudron Sheet 31 31

Software Architecture Example: Change implementation Build_House() Builder Public Interface Sorter Database Bubble sort straw stone Store() Sort() Quick sort DB Cloud Suports evolution and platform-independence MRV Chaudron Sheet 32 32

Software Architecture Example 1 n n n IPrime. Encrypt(m, p) ICeasar. Encrypt(m, s) IEncrypt(m) Information hiding guides the design of the interface The interface should aim to be: n generic We can do this by stating ‘what’, but not ‘how’ ¨ We can do this by avoiding unnecessary parameters in the calling of the component ¨ MRV Chaudron Sheet 33 33

Software Architecture Example 2 n Steer a vehicle n Interface ¨ Option 1: Isteer = { Turn. Left, Turn. Right } ¨ Option 2: Isteer = { Press. Left, Press. Right } ¨ Option 3: Isteer = { Left, Right } MRV Chaudron Sheet 34 34

Software Architecture Alternative Interfaces n Traffic Light • Level of abstraction 35

Software Architecture Traffic Light - Alternative Interfaces Traffic Light 1 Traffic Light 2 Traffic Light 3 • Reset() • • • Halt() • Warn() • Drive() – Postcondition: RED • Run() – Red Green Orange Red • Set. Interval. Duration(t) ‘Secrets’ – Actual colours – Initial state – Order of lights (easy to change) – ‘On’ is Mutual exclusive Synchronization/Timing? Set. Red(On/Off): Exc Set. Orange(On/Off): Exc Set. Green(On/Off): Exc Blink/Disco() Get. State(…) ‘Secrets’ – Initial state – Order of states More Generic (lights not exclusive) ‘Secrets’ – Actual colours – Initial state – Order of states Higher Level of abstraction

Software Architecture What is Modularity? We can “see it” via a n Design Structure Matrix (DSM) Map n 38

Software Architecture Design Structure Matrix Map of a Laptop Computer 39

Software Architecture Design Structure Matrix Map of a Modular System 40

Software Architecture DSM of Mozilla before and after redesign number of files 2. 4 dependencies per KSLOC 1. 3 dependencies per KSLOC Formerly Mozilla was the commercial Netscape Navigator, then released into open source. From: Exploring the Structure of Complex Software Designs: An Empirical Study of Open Source and Proprietary Code, Alan Mac. Cormack, John Rusnak, Carliss Baldwin, Harvard Business School, draft October 1 st 2005 41

Software Architecture Chest of drawers by Droog Design Build from ‘modules’ But no stable architecture: many dependencies from all drawers on all other drawers

Software Architecture Single Responsibility n What is a responsibility? Depends on level of design ¨ Relates to Parnas Information Hiding: ¨ n The responsibility relates to the secret E. g. sorting ¨ Viewer: way of displaying information ¨ Model: storing & querying information ¨ ¨ Alternative n formulation (‘Uncle Bob’): A class should have only one reason to change MRV Chaudron Sheet 43 43

Software Architecture Generic Design Principle: Separation of Concerns n Decomposition / Divide and Conquer n Issues that are not related should be handled in separate parts n Single responsibility: Edsger W. Dijkstra ¨ Assign a single responsibility to a single component/class Typical responsibilities: to know something, to do something E. g. to know an algorithm (worker) to coordinate workers (coordination) to manage student-records (information holder) MRV Chaudron Sheet 46 46

Software Architecture Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: Complexity sells better. Source: Edsger W. Dijkstra EWD 896 - On the nature of Computing Science Sheet 47 Turing Award (1972) 47

Software Architecture Edsger Wybe Dijkstra n n 1930 -2002 Ph. D. in Physics Leiden University, Netherlands Contributions to: Algorithms, Concurrency, Distributed Systems, Program Correctness, Discipline of Design: Structured Programming (Go To considered Harmful) Separation of Concerns Turing Award (1972) O. -J. Dahl, E. W. Dijkstra, C. A. R. Hoare, Structured Programming, Academic Press, London, 1972 48

Software Architecture Example Separation of Concern Principle Telecom Domain: Telecom protocol: n decode 1 ; handle 1 ; decode 2 ; handle 2 ; decode 3 Separate the encoding/decoding of a message from the handling of a message: decode 1 ; decode 2 ; decode 3 ; handle 1 ; handle 2 MRV Chaudron Sheet 49 handle & encode/ decode handle encode/ decode 49

Software Architecture Separation of Concerns in Interface Design n Separate What from How n The interface of a component exposes what it do, but not how it does this. The ‘how’ is the information-hiding ‘secret’ n - Details of the data representation - Details of the algorithm MRV Chaudron Sheet 50 50

Software Architecture Reference Architecture n Generic (i. e. not applicationspecific) Design. Generally believed for Information Systems n Not so very different for embedded systems n n From: Microsoft Application Architecture Guide, 2 nd Edition http: //msdn. microsoft. com/en-us/library/ff 650706. aspx MRV Chaudron Sheet 51 51

Software Architecture Design Principles n Keep things that belong together at a single place e. g. in OO: n data and the operations on that data Don’t replicate functionality, storage of data MRV Chaudron Sheet 52 52

Software Architecture From Analysis to Initial Design The OO paradigm has been designed such that Analysis and Design models look ‘alike’: Classes that appear in a domain model, can also appear in a design model Descriptive Models Problem Space/Domain Solution Space/Domain Component/Class Diagram These are elements of analysis: What is there? Components/Classes & their behaviour These are elements of construction: How will it work?

Software Architecture Features According to FODA: A prominent and user-visible aspect, quality or characteristic of a system. ODM: A distinguishable characteristic of a system that is relevant to a stakeholder of the system In mobile telephones: - polyphonic ringtones - SMS, MMS - dual, tri-band, -… In cars: - airco - power-steering - remote key-lock -… 56

Software Architecture Feature models Types of features Mandatory: All systems must have it e. g. A car must have an engine Alternative: A system must have one out of multiple options e. g. Transmission may be manual or automatic Optional: A system may have a feature e. g. A car may have air-conditioning 57

Software Architecture Feature Diagram A hierarchical decomposition of features. A concept higher in the tree consists of its children car wheels mandatory (default) engine optional steering transmission wheel manual airco alternative automatic Additional annotations that may be used in the feature diagram: - mutually exclusive features - rationale for chosing between alternatives - composition rules: airco may be used if horsepower>100 58

Software Architecture 59

Software Architecture Feature Solution Diagrams Feature space Solution space 60 From de Bruin & Van Vliet, 2001

Software Architecture Feature-Solution Graph Example from Hans de Bruin, Hans van Vliet 61

Software Architecture Summary n Design Principles Information Hiding Minimize Coupling Know them, Apply them Divide and Conquer Recognize violations Separation of Concerns Keep it Simple n Design Structure Matrix ¨ can you read it? make it? MRV Chaudron Sheet 62 62

Software Architecture Questions? MRV Chaudron Sheet 63 63

Software Architecture Summary of key architecting practices n Understand the drivers for the project (business, politics) n Get stakeholder involvement early and often n Understand the requirements incl. quality properties ¨ SMART & prioritized n Develop iteratively and incrementally n Describe architecture using multiple views ¨ abstract, but precise, design decisions & rationale n Design for change (modularity, low coupling, inform. hiding) n Analyze in an early stage (use maths! and scenarios) n Simplify, simplify n Regularly update planning and risk analysis n Monitor that architecture is implemented n Get good people, make them happy set them loose 64