Presentation is loading. Please wait.

Presentation is loading. Please wait.

Chapter 8 Design Characteristics and Metrics Fall 2011.

Similar presentations

Presentation on theme: "Chapter 8 Design Characteristics and Metrics Fall 2011."— Presentation transcript:

1 Chapter 8 Design Characteristics and Metrics Fall 2011

2 Characterizing Good Design Besides the obvious - - - design should match the requirements - - - there are two fundamental characteristics: – Consistency across design: Common UI –looks –Logical flow Common error processing Common reports Common system interfaces Common help All design carried to the same depth level –Completeness of the design All requirements are accounted for All parts of the design are carried to their completion, to the same depth level

3 Intuitively Complexity is related to “Good” Design Some Legacy Characterization of Design Complexity –Halstead Complexity metrics –McCabe’s Cyclomatic Complexity metric –Henry-Kafura Information flow metrics –Card and Glass design complexity metrcis

4 Halstead Metrics Developed by Maurice Halstead of Purdue in the 1970’s to mostly analyze program source code complexity. Used 4 fundamental units of measurements from code: –n1 = number of distinct operators –n2 = number of distinct operands –N1 = sum of all occurrences of n1 –N2 = sum of all occurrences of n2 Program vocabulary, n = n1 + n2 Program length, N = N1 + N2 Using these, he defined 4 metrics: –Volume, V = N * (Log 2 n) –Potential volume, V @ = (2 + n2 @ ) log 2 (2+n2 @ ) –Program Implementation Level, L = V @ / V –Effort, E = V / L Halstead metrics really only measures the lexical complexity, rather than structural complexity of source code. Volume of a function should be >20 &<1000 Volume of a parameterless one-line function that is not empty is about 20; a volume >1000 tells that the function probably does too many things The volume of a file should >100 & < 8000

5 01 public class Class1 { 02 public void x(boolean v) { 03 int i; 04 if (v) {i = 1;} 05 else {i = 2;} 06 switch(i){ 07 case 1: 08 case 2: 09 default:; 10 } 11 try { 12 while(v){ 13 v = false; 14 int r = 1; 15 Boolean b = new Boolean(true); 16 i = i*i+r; 17 break; 18 } 19 } catch (Exception e) { 20 throw e; 21 } 22 } 23 } LineN1n1N2n2 04if, = v, i, 1 05=i, 22 06switch i 12loop v 13=v, falsefalse 14=1 15=,newnewtrue 16=, *, +*, +i, i, i, rr 20throw ee Total138168 Halstead Metrics -- Example N1: Each time the same operator occurs n1: The first time the operator appears N2: Each time the same operand occurs n2:: The first time the operand appears

6 T.J. McCabe’s Cyclomatic complexity metric is based on the belief that program quality is related to the complexity of the program control flow. n1 n2 n3 n5 n6 n4 e1 e2 e7 e3 e4 e5 e6 Region 1 Region 2 Cyclomatic complexity = E - N + 2p where E = number of edges N= number of nodes p = number of connected components (usually 1) So, for this control flow : 7 edges – 6 nodes + 2 = 3 Cyclomatic comlexity number can also be computed as follows: - number of binary decision +1 - number of closed regions + 1 McCabe’s Cyclomatic Complexity

7 Measures structural design complexity Applied to design and code risk analysis Also used to determine the number of test cases needed to drive through the linearly independent paths in the system Larger the number, more risk, more testing required –1 – 10: low risk and simple –>50: high risk Keep control flow so cyclomatic complexity is much less than 50 McCabe’s Cyclomatic Complexity

8 Henry-Kafura (Fan-in and Fan-out) Henry and Kafura metric measures the inter-modular flow, which includes: –Parameter passing –Global variable access –inputs – outputs Fan-in : number of inter-modular flow into a program Fan-out: number of inter-modular flow out of a program Module’s Complexity, Cp = ( fan-in x fan-out ) 2 for example above: Cp = (3 + 1) 2 = 16 Module, P

9 Henry-Kafura (Fan-in and Fan-out) Measures intermodular flow Based on flow of information in and out of a module Includes –Parameter passing –Global variable access –Inputs –Outputs

10 Henry-Kafura (Fan-in and Fan-out) Total Henry-Kafura structural complexity –Sum of Henry-Kafura structural complexity for all program modules. C T = ∑C pi i=1 n ModuleMod-AMod-BMod-CMod-D Fan-in3422 Fan-out1232 C p for Mod-A = (3 * 1) 2 = 9 C p for Mod-B = (4 * 2) 2 = 64 C p for Mod-C = (2 * 3) 2 = 36 C p for Mod-D = (2 * 2) 2 = 16 C T for entire program = 125 C p = (fan-in X fan-out) 2

11 Potential Design or Implementation Difficulties Predicted by Henry-Kafura Poorly refined (overloaded) data structures Improper modularization –Procedure should be in one and only one module Poor internal module construction –Many procedures access the data structure directly Poor functional decomposition

12 Card and Glass (Higher Level Complexity) Card and Glass used the same concept of fan-in and fan-out to describe design complexity: –Structural complexity of module x Sx = (fan-out ) 2 –Data complexity Dx = Px / (fan-out +1), where Px is the number of variables passed to and from the module –System complexity Cx = Sx + Dx Note: Except for Px, fan-in is not considered here

13 “Good” Design Attributes Easy to: –Understand –Change –Reuse –Test –Integrate –Code Believe that we can get many of these “easy to’s” if we consider: – Cohesion – Coupling

14 Modularity A concept closely tied to abstraction Modularity supports independence of models Modules support abstraction in software Supports hierarchical structuring of programs Modularity enhances design clarity, eases implementation Reduces cost of testing, debugging and maintenance Cannot simply chop a program into modules to get modularly Need some criteria for decomposition

15 Coupling Independent modules: if one can function completely without the presence of other Independence between modules is desirable –Modules can be modified separately –Can be implemented and tested separately –Programming cost decreases In a system all modules cannot be independent Modules must cooperate with each other More connections between modules –More dependent they are –More knowledge about one module is required to understand the other module. Coupling captures the notion of dependence

16 Coupling between modules is the strength of interconnections between modules In general, the more we must know about module A in order to understand module B the more closely connected is A to B "Highly coupled" modules are joined by strong interconnection "Loosely coupled" modules have weak interconnections Coupling…

17 Uncoupled - no dependencies Highly coupled - many dependencies Loosely coupled - some dependencies Coupling…

18 Goal: modules as loosely coupled as possible Where possible, have independent modules Coupling is decided during architectural design Cannot be reduced during implementation Coupling is inter-module concept Major factors influencing coupling –Type of connection between modules –Complexity of the interface –Type of information flow between modules Coupling…

19 Complexity and obscurity of interfaces increase coupling Minimize the number of interfaces per module Minimize the complexity of each interface Coupling is minimized if –Only defined entry of a module is used by others –Information is passed exclusively through parameters Coupling increases if –Indirect and obscure interfaces are used –Internals of a module are directly used –Shared variables employed for communication Coupling…

20 Coupling increases with complexity of interfaces e.g. number and complexity of parameters Interfaces are needed to support required communication Often more than needed is used, e.g. passing entire record when only a field is needed Keep the interface of a module as simple as possible Coupling…

21 Coupling depends on type of information flow Two kinds of information: data or control. Transfer of control information –Action of module depends on the information –Makes modules more difficult to understand Transfer of data information –Module can be treated as input-output function Coupling…

22 Lowest coupling: interfaces with only data communication Highest: hybrid interfaces (some data, some control) CouplingInterfaceType ofType of complexityconnectionscommunication LowSimpleTo moduleData Obviousby name HighComplicatedTo internalControl ObscureelementsHybrid Coupling…

23 Coupling Coupling addresses the attribute of “degree of interdependence” between software units, modules or components. Content Coupling Common Coupling Control Coupling Stamp Coupling Data Coupling Passing only the necessary information No Coupling Ideal, but not practical Accessing the internal data or procedural information Levels of coupling where Data coupling is lowest Lower the better

24 HIGH COUPLING LOW LOOSE Data coupling Stamp coupling Uncoupled Control coupling Common coupling Content coupling One component modifies internal data of another: Not good, Change in one component will not affect any other component Organize data in common data store: Better, but dependencies still exist One component passes parameters to control another component Pass data structure from one component to another Only data is passed, not data structure Coupling…

25 A B C D E Component B Go to D1 Component D Go to D1 D1: B branches into D even though D is under control of C Content Coupling

26 Global:A1 A2 A3 Variables:V1 V2 Common data area and variable names Component XComponent YComponent Z V1 = V2 + A1 Change VI to zeroIncrement VI All three components make changes to V1. Could be a problem. Common Coupling

27 Cohesion Coupling characterized the inter-module bond Reduced by minimizing relationship between elements of different modules Another method of achieving this is by maximizing relationship between elements of same module Cohesion considers this relationship Interested in determining how closely the elements of a module are related to each other In practice both are used

28 Cohesion of a module represents how tightly bound are the elements of the module Gives a handle about whether the different elements of a module belong together High cohesion is the goal Cohesion and coupling are interrelated Greater cohesion of modules, lower coupling between module Correlation is not perfect Cohesion…

29 Levels of Cohesion There are many levels of cohesion. –Coincidental –Logical –Temporal –Communicational –Sequential –Functional Coincidental is lowest, functional is highest Scale is not linear Functional is considered very strong

30 Cohesion Cohesion of a unit, of a module, of an object, or a component addresses the attribute of “ degree of relatedness” within that unit, module, object, or component. Functional Sequential Communicational Procedural Temporal Logical Coincidental Levels of Cohesion where Functional is the “highest” Performing more than 1 unrelated functions Performing 1 single function Higher the better

31 HIGH COHESION LOW Logical Temporal Coincidental Procedural Communicational Sequential Functional Components whose parts are unrelated to one another Logically related functions or data elements are placed in the same component Functions are related by timing issues only: hard to make changes Grouping functions in a single component just to insure the proper ordering of execution Grouping functions in a single component just because they produce the same data set Output from one element of component input to another element of the component Ideal cohesion: every processing element is essential to the performance of a single function Levels of Cohesion…

32 FUNCTION D FUNCTION E Procedural Related by order of functions Logical Similar functions FUNCTION A FUNCTION A’ FUNCTION A” logic Temporal Related by time TIME T0 TIME T0 + X TIME T0 + 2X FUNCTION A FUNCTION B FUNCTION C FUNCTION A FUNCTION B FUNCTION C Communicational Access same data Sequential Output of one part is input to next DATA FUNCTION A FUNCTION B FUNCTION C Functional Sequential with complete, related functions FUNCTION A - part 1 FUNCTION A - part 2 FUNCTION A - part 3 Coincidental Parts unrelated FUNCTION A FUNCTION B FUNCTION C Levels of Cohesion…

33 Determining Cohesion Describe the purpose of a module in a sentence Perform the following tests 1. If the sentence has to be a compound sentence, contains more than one verb, the module is probably performing more than one function. Probably has sequential or communicational cohesion. 2. If the sentence contains words relating to time, like "first", "next", "after", "start" etc., the module probably has sequential or temporal cohesion.

34 3. If the predicate of the sentence does not contain a single specific object following the verb, the module is probably logically cohesive. E.g. "edit all data", while "edit source data" may have functional cohesion. 4. Words like "initialize", "clean-up" often imply temporal cohesion. Functionally cohesive module can always be described by a simple statement Determining Cohesion…

35 E A BC F D G System 1 E A BC F D System 2 G Scope of control: has control on other elements Scope of effect: controlled by other elements No component should be in the scope of effect if it is not in the scope of control. If scope of effect is wider than scope of control, almost impossible to guarantee that a change will not destroy the system. System 1 may be better because of this. Scope of Control

36 Using Program and Data Slices to Measure Program Cohesion Bieman and Ott introduced a measure of program cohesion using the following concepts from program and data slices: –A data token is any variable or constant in the program –A slice within a program is the collection of all the statements that can affect the value of some specific variable of interest. –A data slice is the collection of all the data tokens in the slice that will affect the value of a specific variable of interest. –Glue tokens are the data tokens in the program that lie in more than one data slice. –Super glue tokens are the data tokens in the program that lie in every data slice of the program Measure Program Cohesion through 2 metrics: - weak functional cohesion = (# of glue tokens) / (total # of data tokens) - strong functional cohesion = (#of super glue tokens) / (total 3 of data tokens)

37 A Pseudo-Code Example of Functional Cohesion Measure Finding the maximum and the minimum values procedure: MinMax ( z, n) Integer end, min, max, i ; end = n ; max = z[0] ; min = z[0] ; For ( i = 0, i = < end, i++ ) { if z[ i ] > max then max = z[ i ]; if z[ i ] < min then min = z[ i ]; } return max, min; Data Tokens: z1 n1 end1 min1 max1 i1 end2 n2 max2 z2 01 min2 z3 02 i2 03 i3 end3 i4 z4 i5 max3 max4 z5 i6 z6 i7 min3 min4 z7 i8 max5 min5 (33) Slice max: z1 n1 end1 max1 i1 end2 n2 max2 z2 01 i2 03 i3 end3 i4 z4 i5 max3 max4 z5 i6 max5 (22) Slice min: z1 n1 end1 min1 i1 end2 n2 min2 z3 02 i2 03 i3 end3 i4 z6 i7 min3 min4 z7 i8 min5 (22) Glue Tokens: z1 n1 end1 i1 end2 n2 i2 03 i3 end3 i4 (11) Super Glue: z1 n1 end1 i1 end2 n2 i2 03 i3 end3 i4 (11)

38 Example of pseudo-code Cohesion Metrics For the example of finding min and max, the glue tokens are the same as the super glue tokens. –Super glue tokens = 11 –Glue tokens = 11 The data slice for min and data slice for max turns out to be the same number, 22 The total number of data tokens is 33 The cohesion metrics for the example of min-max are: weak functional cohesion = 11 / 33 = 1/3 strong functional cohesion = 11 / 33 = 1/3 If we had only computed one function (e.g. max), then : weak functional cohesion = 22 / 22 = 1 strong functional cohesion = 22/ 22 = 1

39 Chidamber and Kemerer (C-K) OO Metrics Weighted Methods per class (WMC) Depth of Inheritance Tree (DIT) Number of Children (NOC) Coupling Between Object Classes (CBO) Response for a Class (RFC) Lack of Cohesion in Methods (LCOM) Note that LCOM is a negative measure in that high LCOM indicates low cohesion and possibly high complexity. Cohesion is based on the association of methods with common instance variables.

40 Cohesion and Coupling Cohesion Coupling High Level Low Level Strong WeakLoose Tight

41 User Interface Mandel’s 3 “golden rules” for UI design –Place the user in control –Reduce the users’ memory load ( G. Miller’s 7 + or – 2) –Consistency ( earlier - design completeness and consistency) Shneiderman and Plaisant (8 rules for design) –Consistency –Short cuts for frequent (or experienced) users –Informative feedback –Dialogues should result in closure –Strive for error prevention and simple error handling –Easy reversal of action (“undo” of action) –Internal locus of control –Reduce short term memory

42 UI Design Prototype and “Test” UI design prototypes: –Low fidelity (with cardboards) –High fidelity (with “story board” tools) Usability “laboratories” and statistical analysis – # of subjects who can complete the tasks within some specified time –Length of time required to complete different tasks –Number of times “help” functions needed –Number of times “redo” used and where –Number of times “short cuts” were used

43 Origin of Law of Demeter A design “guideline” for OO systems that originated from the Demeter System project at: –Northeastern University in the 1980’s –Aspect-Oriented Programming Project Addresses the design coupling issue through placing constraints on messaging among the objects –Limit the sending of messages to objects that are directly known to it

44 Law of Demeter An object should send messages to only the following kinds of objects: –the object itself –the object’s attributes (instance variables) –the parameters of the methods in the object –any object created by a method in the object –any object returned from a call to one of the methods of the object –any object in any collection that is one of the above categories

Download ppt "Chapter 8 Design Characteristics and Metrics Fall 2011."

Similar presentations

Ads by Google