Design Principle 10: Design for Vragen Testability Testability - PowerPoint PPT Presentation

Design Principle 10: Design for Vragen Testability Testability • Waarom is design noodzakelijk? • Take steps to make testing easier g j g • Design a program to automatically test the software • Is design hetzelfde als programmeren? − Discussed more in Chapter 13 • Waarom is low coupling en high cohesion goed? − Ensure that all the functionality of the code can by E th t ll th f ti lit f th d b • Is code cloning een goede vorm van re-use ? driven by an external program, bypassing a graphical user interface • In Java, you can create a main() method in each class in order to exercise the other methods / Faculteit Wiskunde en Informatica / Faculteit Wiskunde en Informatica 4-3-2011 PAGE 0 4-3-2011 PAGE 1 Design Principle 11: Design defensively Design principles • Never trust how others will try to use a component • Abstraction y you are designing • Modularity, coupling and cohesion • Handle all cases where other code might attempt to use • Information hiding your component inappropriately your component inappropriately • Limit complexity • Check that all of the inputs to your component are • Hierarchical structure valid: the preconditions − Unfortunately, over-zealous defensive design can result in unnecessarily repetitive checking − Example: 75% of the code is used to parameter p p checking / Faculteit Wiskunde en Informatica 4-3-2011 PAGE 2 / Faculteit Wiskunde en Informatica 4-3-2011 PAGE 3

Abstraction Modularity • Procedural abstraction • Structural criteria which tell us something about g • individual modules and their interconnections natural consequence of stepwise refinement − name of procedure denotes sequence of actions • Modern programming languages support modularity M d i l t d l it • Data abstraction • • • Cohesion and coupling • Cohesion and coupling aimed at finding a hierarchy in the data aimed at finding a hierarchy in the data • cohesion: the glue that keeps a module together • coupling: the strength of the connection between modules • keep track of this via measuring! / Faculteit Wiskunde en Informatica / Faculteit Wiskunde en Informatica 4-3-2011 PAGE 4 4-3-2011 PAGE 5 Modularity Types of cohesion • Calculating quality metrics on the source code • Coincidental cohesion g y • Fan Out (# modules called) elements are grouped into components in a random manner, no relation between components • Logical cohesion Logical cohesion • elements realize logical related tasks, for instance all procedures dealing with the processing of input • Temporal cohesion T l h i • elements are independent but are active at the same moment in time, for instance everything related to initialization • Procedural cohesion • elements are executed in a given order Fan In (called by # modules) / Department of Mathematics and Computer Science 4-3-2011 / Faculteit Wiskunde en Informatica 4-3-2011 PAGE 7

Types of cohesion Types of coupling • Communicational cohesion • Content coupling • change of data by another component • elements operate on the same (external) data • Common coupling • Sequential cohesion • shared data • sequence of elements where output of one is input for other f l t h t t f i i t f th • External coupling • Functional cohesion • files • elements contribute to a single function g • Control coupling Control coupling • flags • Stamp coupling • Data cohesion (for abstract data types) • • shared knowledge on data formats shared knowledge on data formats • Data coupling • simple data / Faculteit Wiskunde en Informatica / Faculteit Wiskunde en Informatica 4-3-2011 PAGE 8 4-3-2011 PAGE 9 strong cohesion & weak coupling  Information hiding simple interfaces  simple interfaces  • simpler communication • Design involves a series of decision: for each such g decision, wonder who needs to know and who can • simpler correctness proofs be kept in the dark • changes influence other modules less often • Information hiding is strongly related to • Information hiding is strongly related to • reusability increases • abstraction: if you hide something, the user may • comprehensibility improves abstract from that fact • coupling: the secret decreases coupling between a module and its environment • cohesion: the secret is what binds the parts of the cohesion: the secret is what binds the parts of the module together / Faculteit Wiskunde en Informatica 4-3-2011 PAGE 10 / Faculteit Wiskunde en Informatica 4-3-2011 PAGE 11

Complexity Modularity • Measure certain aspects of the software (lines of • Calculating quality metrics on the source code ( g y code, # of if-statements, depth of nesting, …) Fan Out (# modules called) • Use these numbers as a criterion to assess a design or to guide the design design, or to guide the design • Interpretation: higher value  higher complexity  more effort required (= worse design) q ( g ) • Two kinds: • intra-modular: inside one module • inter-modular: between modules Fan In (called by # modules) / Faculteit Wiskunde en Informatica / Department of Mathematics and Computer Science 4-3-2011 PAGE 12 4-3-2011