Software Development Processes: Assignment
farzadbigz
Module8.pptxChapter 8: Design: Characteristics and Metrics
1
Characterizing “Good” Design
Besides the obvious — design should match the requirements — there are two “basic” 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 (what do you think?)
Completeness of the design
All requirements are accounted for.
All parts of the design are carried to completion, to the same depth level.
2
Intuitively, Complexity Is Related to “Good/Bad” Design
Some “legacy characterization” of design complexity
Halstead metrics
McCabe’s Cyclomatic Complexity metric (most broadly used)
Henry-Kafura Information Flow (fan-in/fan-out) metrics
Card and Glass design complexity metrics
3
Halstead Metrics
Developed by Maurice Halstead of Purdue in the 1970s to mostly analyze program source code complexity.
Used four fundamental units of measurements from code:
n1 = number of distinct operators
n2 = number of distinct operands
N1 = sum of all occurrences of the n1
N2 = sum of all occurrences of the n2
Program vocabulary: n = n1 + n2
Program length: N = N1 + N2
Using these, he defined four metrics:
Volume: V = N * (Log2 n)
Potential volume: V@ = (2 + n2@) log2 (2+n2@) (based on most “succinct” program’s n2 — thus n2@)
Program implementation level: L = V@/ V
Effort: E = V / L
Halstead metrics really only measure the lexical complexity, rather than structural
complexity of source code — also “potential volume” is a suspect.
4
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”.
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 complexity number can also
be computed as follows:
– number of binary decision +1
– number of closed regions + 1
5
Henry-Kafura (Fan-In and Fan-Out)
Henry and Kafura metric measures the intermodular flow, which includes:
Parameter passing
Global variable access
Inputs
Outputs
Fan-in : number of intermodular flow into a program
Fan-out: number of intermodular flow out of a program
Module’s complexity: Cp = ( fan-in x fan-out )2
for the “picture” above: Cp = (3 x 1)2 = 9
Module, P
non-linear
6
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.
7
A Little “Deeper” on 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
8
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 function
Performing 1 single function
Higher the better
9
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 occurrence of 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 two metrics:
– weak functional cohesion = (# of glue tokens) / (total # of data tokens)
– strong functional cohesion = (# of super glue tokens) / (total # of data tokens)
10
A Pseudo-Code Example of Functional Cohesion Measure
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
12
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
13
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 reverse measure in that high LCOM indicates
low cohesion and possibly high complexity. #p = number of pairs of methods in class that have no common instance variable; #q = number of pairs of methods in the class that have common instance variables: LCOM = #p – #q
14
Cohesion and Coupling
Origin of Law of Demeter
A design “guideline” for OO systems that originated from the Demeter System project at:
Northeastern University in the 1980s
Aspect-Oriented Programming Project
Addresses the design coupling issue through placing constraints on messaging among the objects
Limits the sending of messages to objects that are directly known to it
16
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
17
User Interface
Mandel’s three “golden rules” for user interface (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 (eight 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.
18
UI Design Prototype and “Test”
UI design prototypes:
Low fidelity (with cardboards)
High fidelity (with “story board” tools)
Usability “laboratories test” and statistical analysis
Number 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
19
