System design Chair of Softw are Engineering Software Engineering � 1 Overview Prof. Dr. Bertrand Meyer � 2 Subsystem decomposition March 2007 – June 2007 � 3 Assessing O-O architectures � 4 Architectural styles Lecture 10: � 5 Advanced issues System Design Based on material by Prof. Peter Müller; includes elements from course “Software Engineering I” by Prof. Bernd Brügge, TU München. ETH Software Engineering, lecture 10: System Design (after Peter Müller) 2 Simplicity System design: scope • There are two ways of constructing a software Problem � Bridge the gap between a design: One way is to make it so simple that there are obviously no deficiencies and the other way is to problem and an existing system make it so complicated that there are no obvious � Divide and conquer: model new New deficiencies. system as a set of subsystems System • C.A.R. Hoare The Emperor’s Old Clothe s • 1980 Turing Award lecture Existing • http://tinyurl.com/3yk3v2 System Tony Hoare ETH Software Engineering, lecture 10: System Design (after Peter Müller) 3 ETH Software Engineering, lecture 10: System Design (after Peter Müller) 4 Goals and tasks The “ilities” of software engineering Correctness Maintainability Design goals Identify design goals � Qualities to be optimized Performance Verifiability Robustness Understandability Design initial Software architecture Scalability Reusability subsystem � Subsystem responsibilities decomposition � Subsystems dependencies Reliability Evolvability � Subsystem mapping to Usability Portability hardware Refine subsystem � Policy decisions: control flow, decomposition to Security Repairability access control, data storage… address design goals Interoperability ETH Software Engineering, lecture 10: System Design (after Peter Müller) 5 ETH Software Engineering, lecture 10: System Design (after Peter Müller) 6 1
Typical design trade-offs System design Functionality Usability � 1 Overview Cost Robustness � 2 Subsystem decomposition � 3 Assessing O-O architectures Performance Portability � 4 Architectural styles � 5 Advanced issues Rapid development Functionality Cost Reusability Backward Compatibility Understandability ETH Software Engineering, lecture 10: System Design (after Peter Müller) 7 ETH Software Engineering, lecture 10: System Design (after Peter Müller) 8 Why decompose a system? Subsystems � Management � Collection of closely interrelated classes - Partition effort � Deduced from natural groupings in analysis - Clear assignment of requirements to modules � Modification � Eiffel: clusters P - Decouple parts so that changes to one don’t affect others � Understanding � In UML: packages - Allow understanding system one chunk at a time � Other programming languages: modules, packages (Java), or conventions, e.g. directories ETH Software Engineering, lecture 10: System Design (after Peter Müller) 9 ETH Software Engineering, lecture 10: System Design (after Peter Müller) 10 Services and Subsystem Interfaces Decomposition Example: Compiler Traditional distinction: Lexer Parser Service: Service: � Service: Set of related operations � Parse token stream and build � Scan input file and provide � Provided by one subsystem abstract syntax tree stream of tokens � Enter symbol table information � Share a common purpose � Initialize symbol table � Report syntax errors � Report lexical errors � Inputs, outputs & high-level behavior defined in Features: Features : � AST( File, ST ) system design � next_token (File, ST ) � Subsystem interface: Set of fully-typed operations � Specifies interaction and information flow from and Static Analyzer Code Generator to subsystem boundaries (not inside subsystem) Service: Service: � Perform semantic analysis � Refinement of services � Generate target code from � Fill symbol table analyzed syntax tree � Defined in detailed design � Report type errors Features : Features : � generate_code( AST, ST ) In object-oriented design, the distinction fades out � perform_analysis (AST, ST ) ETH Software Engineering, lecture 10: System Design (after Peter Müller) 11 ETH Software Engineering, lecture 10: System Design (after Peter Müller) 12 2
Cohesion and coupling Modularity: increase cohesion, decrease coupling � Cohesion: interdependence of elements of one Favored by architectural techniques tending to ensure module decentralization of modules � Coupling: interdependence between different modules � Goal: high cohesion and low coupling Low cohesion High Low High coupling coupling cohesion 14 ETH Software Engineering, lecture 10: System Design (after Peter Müller) 13 Decomposability Top-down functional design Decompose complex systems into subsystems Topmost functional abstraction COROLLARY: Division of labor. A � Example: Top-down design method (see next). � Counter-example: General initialization module. Sequence B D C Conditional Loop C1 I I1 C2 I2 15 16 Composability Direct mapping Build software elements so that they may be freely combined with Maintain a close connection between the structure of the others to produce new software. design and the structure of the analysis model 17 18 3
Few interfaces principle Small interfaces principle Every module communicates with as few others as possible. If two modules communicate, they exchange as little information as possible. x, y z (A) (B) (C) 19 20 Explicit interfaces principle Continuity Whenever two modules A and B communicate, this is Ensure that small changes in specifications yield small obvious from the text of A or B or both. changes in architecture. Design method : Specification → Architecture Module A Module B Modifies Accesses Data item Example: Principle of Uniform Access (see next) x Counter-example: Programs with patterns after the physical implementation of data structures. 21 22 Uniform Access: An example Uniform Access Principle A module’s facilities are accessible to its clients in the balance = list_of_deposits . total – list_of_withdrawals . total same way whether implemented by computation or storage. list_of_deposits (A1) list_of_withdrawals balance list_of_deposits (A2) list_of_withdrawals Not uniform access: Uniform access: a . balance a . balance balance ( a ) a . balance () 23 24 4
Uniform access principle Information hiding (Parnas, 1972) Underlying question: how does one “advertise” the It doesn‘t matter to the client capabilities of a module? whether you look up or compute Every module should be known to the outside world through an official, “public” interface. A call such as The rest of the module’s your_account . balance properties comprises its “secrets”. It should be impossible to access could use an attribute or a function the secrets from the outside. David Parnas 25 26 Information hiding Information Hiding Principle The designer of every module must select a subset of the Public module’s properties as the official information about the module, to be made available to authors of client modules. Secret 27 28 Information hiding System design Justifications: � Continuity � 1 Overview � Decomposability � 2 Subsystem decomposition � 3 Assessing O-O architectures � 4 Architectural styles � 5 Advanced issues 29 ETH Software Engineering, lecture 10: System Design (after Peter Müller) 30 5
Good architecture The five secrets of good architecture � Result of a consistent set of principles and � Simplicity of design techniques , applied consistently through all � Consistency of design phases of a project � Ease of learning of the APIs � Resilient in the face of (inevitable) changes � Support for change � Source of guidance throughout the product lifetime � Support for reuse � Reuse of established engineering knowledge - Application of architectural styles - Analogous to design patterns in detailed design ETH Software Engineering, lecture 10: System Design (after Peter Müller) 31 ETH Software Engineering, lecture 10: System Design (after Peter Müller) 32 The contribution of object technology O-O is for high cohesion and low coupling � Single decomposition criterion: ADT � Cohesion � Low coupling � Precision of specification: contracts � Features work on same data � Small interfaces � Clear client-supplier separation, information hiding � Implement one ADT � Information hiding � Organize abstractions in hierarchies: inheritance � No global data � Polymorphism and dynamic binding � Interactions are within � Easily add new types subsystem rather than across subsystem � Parameterize classes: genericity boundaries � Abstract behaviors into objects: agents, delegates � Support for reuse, libraries � Known, published collections of design patterns ETH Software Engineering, lecture 10: System Design (after Peter Müller) 33 ETH Software Engineering, lecture 10: System Design (after Peter Müller) 34 The key task in O-O Judging good and bad architectures � Finding the right data abstractions � This is the basis of “refactoring” � Never take a design for granted � But: don’t delay good design (GIGO) ETH Software Engineering, lecture 10: System Design (after Peter Müller) 35 ETH Software Engineering, lecture 10: System Design (after Peter Müller) 36 6
Recommend
More recommend
