object-oriented analysis and design lecture 7 metrics for o-o design
Post on 20-Dec-2015
230 views
TRANSCRIPT
Object-Oriented Analysis and Design
Lecture 7
Metrics for O-O Design
Principles for O-O Design Encapsulation “Connascence” Domains Cohesion
Encapsulation
Level 0
Raw linesof code
Level 1
Proceduralmodule
Level 2
Class/object
Encapsulation First, there was machine code, and
then assembly language. Then there were
functions/procedures. Then there were classes. Then there were…what?
Packages Groups of classes
“Horizontally” (by subject area), e.g., Passengers Aircraft Personnel
“Vertically” (by business activity), e.g.,
Banking Securities Real estate
Design Criteria These govern (and measure)
“goodness” of interaction.
From:To:Lines of code
Lines of code
Procedure
Procedure
Structuredprogramming
Fan-out
Cohesion Coupling
Design Criteria Structured programming: three structures:
Sequence of instructions Selection of instructions (if-then-else) Iteration of instructions
Fan-out: number of references to other procedures by code in a given procedure
Cohesion: “single-mindedness” of code within a procedure
Coupling: number and strength of connections between procedures
Extension to Classes
From:To:Lines of code
Lines of code
Procedure
Procedure
Structuredprogramming
Fan-out
Cohesion Coupling
Class
Class
-
-
Class cohesion
-
Class coupling
Class Interdependencies (“Connascence”) Software elements a and b are
interdependent if Some change to a requires a change
to b to maintain correctness, or Some change elsewhere requires
both a and b to be changed.
Examples Lines of code:
Functions:
Classes:
Sometimes directional, sometimes non-directional
int i = 3;…i++;
void myFunction() { … int j = yourFunction();}
Class Elephant { Trunk t; …}
More Examples Connascence of name: subclass
inherits a variable, it must use the same name.
Connascence of convention: in C++, a non-zero int is considered TRUE. Also, enumeration types.
Connascence of algorithm: Binary search expects the members of a Tree to be sorted ascending.
Dynamic Connascence Connascence of execution: this is
what sequence diagrams are for. Connascence of value: corners of a
rectangle must have a certain relationship; redundant databases.
Connascence of identity: two reference-counted string objects pointing to the same character array.
“Contranascence” Connascence implies that two
things are related; contranascence implies that two things are distinct.
Class A has an int i, so does class B. But they are different.
If multiple inheritance is allowed, this can be a problem.
Connascence & Encapsulation Encapsulation is a way of
controlling interdependencies. You write some C code, with global
variable myVar. I do the same. We try to join our code…
I look at your code, and see two lines, one after the other. Must they be together?
Encapsulation Back to the tree example:
Some code inserts into the tree Some code reads from the tree If we find a better storage structure,
all this code needs to change. Make the tree a class, with well-
defined public methods, and these problems go away.
Good Rules Minimize overall dependencies by
breaking the system into encapsulated elements.
Minimize dependencies across encapsulation boundaries.
Maximize dependencies within encapsulation boundaries.
Good, Bad, Ugly
Level 3Level 3
Other Dangers Friend classes and functions in C++ Overuse of inheritance with
protected members. Relying on a specific
implementation (e.g., inserting into a map)
Class Domains Application domain: classes are
useful for one (or just a few) applications Event-recognizer classes (fuel
mixture too rich) Event-manager classes (reduce
injector pressure) Very narrow reusability
Class Domains Business domain: classes for one
business or company Attribute classes (AlloyType) subject
to business rules Role classes (WingSpar) Relationship classes
(AccountOwnership) resulting from associations
Class Domains Architecture domain: classes used
in one style of implementation GUI classes (Window, Button) Database classes (Transaction) Machine communication classes
(Socket) Useful across many businesses and
applications, but only on a single architecture
Class Domains Foundation classes: classes useful
in all businesses and architectures Fundamentals: Int, Complex, Boolean Structural: Stack, List, Array Semantic: Date, Time, Currency
These are the most valuable for reuse.
Where Do Classes Come From? Foundation classes: buy them!
Everyone needs them, they’re high volume commodities, so relatively inexpensive.
They’re well tested. Architectural classes: buy them if you
can. Microsoft, Sun, etc. Watch out for nagging incompatibilities
between vendors. Were two sets of classes built on the same
foundation classes?
Where Do They Come From? Business classes
Available for more and more businesses.
They will likely need to be tailored---that’s why we have subclassing!
Probably more volatile; what’s the change history?
Maybe better to build yourself.
Encumbrance All the classes that a given class
needs in order to work. A way to think of the domain of a
class. This can be measured.
Direct Class References A inherits from B A has an attribute of type B A has a method with argument of type B A has a method with return type B A has a method with local variable of type
B A supplies B as a parameter type C has a friend class D (but this implies one
of the above?)
Indirect Class References Class A has direct class references to A1,
A2, …, An
A has indirect class references to those classes directly and indirectly referenced by A1, A2, …, An (recursive definition)
Direct encumbrance is the count of direct class references
Indirect encumbrance is the count of indirect class references
The Law of Demeter Inside a method it is only permitted to
access or send messages to the following objects:
1. The arguments associated with the method being executed,
2. Instance variables defined in the class containing the method being executed,
3. Global variables, and4. Temporary variables created inside the method.
Variants to #2: access instance variables only through accessor functions.
Class Cohesion A measure of the interrelatedness
of a class’s public interface. Low cohesion indicates that the
class does many different things. High cohesion suggests a class is a
good conceptual “chunk”.
Types of Class (In-) Cohesion A class with mixed-instance
cohesion has some features that are undefined for some objects of the class.
Class GuitarAmp { int volumeSetting; int bassSetting; int trebleSetting; int toneSetting;}
Types of Class (In-) Cohesion A class with mixed-domain
cohesion contains an element that directly encumbers the class with an extrinsic class of a different domain.
(The class B is extrinsic to A if A can be defined with no knowledge of B.)
class List { Product headOfList; …}
Types of Class (In-) Cohesion A class C has mixed-role cohesion if
it contains an element that directly encumbers the class with an extrinsic class that lies in the same domain as C.
class Course { int NumQuizzes; …}
Part II
Process improvement depends on metrics.
What metrics are right for O-O design? One contender: Chidamber & Kemerer:
“A Metrics Suite for O-O Design,” (IEEE TSE `94)
Verification study by Basili et al. `95 (U. Maryland CS Dept. CS-TR-3443)
Let’s look at both:
Background Increased emphasis on the process of
software development. Wholesale movement toward O-O
languages and methodologies. Can `80’s metrics of complexity hold
up? lines of code “cyclomatic complexity” “fan-in, fan-out” function points
Background (cont.)
Why is measuring complexity important? cost estimation (assuming complexity
can be measured early) estimation of resource allocation for
building testing
Criticisms of Older Metrics Not “theoretical”:
no basis in sound theory lacking “appropriate mathematical
properties” unpredictable behavior
Not “O-O”: based on functional decomposition O-O induces different problem-solving
behavior
What C & K Provide
They propose new metrics Evaluate them against normative
criteria Illustrate them in real-world
settings
Where Are They Used?
In the context of Booch’s (or anybody’s) OOD. The steps: identify classes identify semantics identify relationships implement
In the class design stage Dynamic complexity is not
measured
Measurement Theory
Basically, measurement moves from empirical relations to quantitative ones.
We have a subjective notion of what makes an O-O design D complex:
A is a set of objectsR’s are empirical relations on objects (e.g.,
>, <)O’s are binary operations on elements of A
(e.g., combination)
),,,,,( 11 mOORRAD n
What?
The empirical relations satisfy our intuitions (class A is more complex then class B,...)
The binary operations let us combine intuitions (e.g., two classes combined give a more complex class).
A “viewpoint” summarizes this, and has nice properties
transitivity, etc.
I Said, “What?”
We do this all the time: empirical relations become quantitative systems.
Think of meters kilograms grades (!) now, complexity...
Objects
Object X = (x, p(x)), where x is the individual and p(x) is the set of its properties (think
of attributes and methods)
Viewpoints
Coupling: “Two objects are coupled if one of them acts upon the other. X acts on Y if Y’s history of states is affected by X.”
Given
then any action by a method of Mx which acts on either My or Iy constitutes a coupling.
yy
xx
IMyp
IMxp
)(
)(
Examples
X alters a public instance variable of Y
X calls a public method of Y X calls a public or protected
method of a superclass of Y X calls a member of Z, which calls a
member of Y.
Another Viewpoint Cohesion: “...the degree of internal
consistency within the parts of a design.” A measure of a class, relating to
encapsulation. Define similarity of two methods within a class:
If all the methods in a class are similar, in that they perform different operations on the same set of instance variables, then the class is cohesive.
2121 ),( IIMM
Other Measures
Complexity of an object: how many members does it have?
Scope of properties: roughly, how wide and deep is the inheritance hierarchy? depth of inheritance number of (immediate) children
More Measures
Measures of communication: think of methods as responses to messages; define Response set of a class: all methods
that can be invoked in response to a message to an object of the class.
This may include methods outside the class as well as global functions.
Desirable Properties
1. Non-coarseness: there are in fact two classes that measure differently.
2. Non-uniqueness: there may be two classes that measure the same.
3. Importance of design details: two classes with the same functionality may measure differently.
More Desirable Properties4. Monotonicity: the measure of the
combination of two classes is greater than the measure of either.
5. Non-equivalence of interaction: suppose X and Y measure the same; there may be a Z such that X+Z measures differently from Y+Z
6. Interaction increases complexity: The measure of X+Y is greater than the measure of X plus the measure of Y
Weighted Methods Per Class
n
i
icWMC1
Consider a class C with methods M1,...,Mn
and let c1,..., cn be the complexity of thesemethods. Then set
Properties of WMC There can be two classes that
measure differently There can be two classes that
measure the same The choice of number of methods is
a design decision Etc. But, Empirical data: most classes < 10
methods.
)()()(.., QPQPthsQP
Depth of Inheritance Tree
A class is measured according to how far down it is in its tree.
A class deeper down is likely to inherit more methods, making its behavior more complex.
Deeper trees suggest greater design complexity.
The deeper the class, the greater the reuse potential for inherited methods.
More on DIT
Properties 4 (monotonicity) & 6 (interaction increases complexity) are violated.
Empirical data C++ GUI class hierarchy was seldom deeper
than 4 (“top-heavy”). Maybe not taking advantage of reuse potential.
Smalltalk engineering classes, a uniform distribution over 1-7.
One class with DIT = 8, 132 methods...
Number of Children
The more children, the more reuse. The more children, the greater
chance for improper abstraction. More children mean more influence
on the design (more testing too?).
More on NOC
Property 6 violated. Empirical data: 70% of classes had
no children. Suggests reuse through inheritance not being adopted?
Lack of communication between designers?
Design practices dictated shallow trees?
Coupling Between Classes
Count the number of other classes to which a given class is coupled.
Excessive coupling is bad for modular design & reuse.
The larger the number of couples, the higher the sensitivity to changes in design.
More coupling, greater complexity in testing.
More on CBC
Property 6 not satisfied. Empirical data: Smalltalk site
measured much larger (the nature of the language?).
The Smalltalk library was much larger. Coupling increases with size?
50% of classes at both sites had no coupling.
Response For a Class
The size of the response set (all methods that can be invoked in response to a message to the class).
Larger implies more testing. More methods means greater
complexity. Helps allocate testing time.
More on RFC
C++ site binomial out to 60, Smalltalk binomial out to 210.
By using high RFC classes as focus of testing, broader coverage results.
Lack of Cohesion in Methods Example: Suppose class C has
methods M1, M2, M3. Let I1 = {a,b,c,d} be the variables used by M1, I2 = {a,b,e} and I3 = {x,y,z}.
I1 I2 is nonempty, but the other two intersections are empty.
LOCM is then 2 - 1 = 1. Lower LCOMs are “better”.
More on LCOM
Cohesiveness desirable, since it promotes encapsulation.
Lack of cohesion implies the class should be split.
This measure helps identify design flaws. Low cohesion increases complexity. Empirical: median values around 2. One
class had LOCM=200; what would this be?
What about Property 6?
It says that complexity should decrease when a class is divided into more classes.
Experienced designers say that more classes make memory management and run-time error detection more difficult.
Implications for Managers
Designers tend to keep inheritance hierarchies shallow. reduces complexity reduces opportunities for reuse
These metrics can help manage reuse opportunities alert misuse of subclassing help allocate testing resources help maintain architectural control
“Validation of O-O Design Metrics as Quality Indicators” Basili et al., Maryland CS Premises:
Accurate info essential to managers Scheduling & resource allocation
require metrics Where to test for best effect? Metrics reflecting the specificities of
O-O must be defined and validated.
Experimental Goals, Design Evaluate whether the C-K metrics are
useful in predicting probability of faulty classes.
All six C-K metrics studied. Four month study, graduate CS class. Students had C++, RBDMS courses. Analysis, design, implement, test, repair Documents delivered after each phase.
Experiment (cont.)
OMT was used, as were C++, GNU, Motif.
Subjects given MotifApp, GNU library, C++ database classes, no special training.
Sample Motif library programs provided.
Video store problem.
Data Collection
Source code Defect report form Component origination form Repaired code C-K metrics, automated Defective modules
Analysis Binary response variable (fault yes/no) Regression to see which metrics
predict faults They found:
WMC has very low p for new/highly modified classes
DIT was very significant (always) RFC was always significant
More Results
NOC was very significant Larger NOCs correlated with smaller
defect probability Explanation: most of the classes with
large NOC reused verbatim LCOM insignificant CBO significant, especially for UI
classes
Other Results
For a multiple regression model, 80 classes out of 180 would be
predicted faulty (so inspected); 48 out of 58 faulty classes would be identified before testing
250 out of 268 faults would be detected during pre-testing inspection
Example 7 Minute Presentation Brooks Chapter 3: The Surgical
Team
The Problem Young software managers often say
they favor a small, sharp team. Who doesn’t? The gap between the best and
worst performers (even with the same salary and experience) may be 10:1.
If you have 200 people, and 25 are really good, fire the 175.
But What About Large Jobs? A large job might be 3000 person-years. When will a 10-person team finish? Suppose those 10 people are 7 times
more productive than average. Suppose reduced communication
between fewer people gives a 7 times improvement.
The job is done in 6 years. Is the product still interesting or marketable?
The Solution Organize like a surgical team, rather than a
hog-butchering team. The chief surgeon:
Complete responsibility for designing, writing and testing the code.
Great talent, 10 years experience The co-pilot:
Can do the job, but is less experienced. Helps by being thinker, discussant, evaluator. Knows all the code. Is insurance against disaster to the chief surgeon.
Other Players The administrator:
Handles money, people, space and machines.
The editor: Takes draft documentation from the chief
surgeon, edits and checks, publishes it. Two secretaries:
Handle project correspondence and non-product files.
Other Players The program clerk:
Maintains all technical records of the team. Does the version control.
The toolsmith: Provides all the facilities the surgeon
needs. Builds special purpose classes, libraries and tools.
Other Players The tester:
Builds “scaffolding” and test cases at the request of the surgeon. Helps with day-to-day debugging.
The language lawyer: Expert in several languages, finds
clever ways to exploit a language for special purposes.
How It Works 10 people, all working hard, but one mind
designs and builds. The programming work is not divided
between many people. Everyone else is subordinate to the chief
surgeon; no differences of opinion or interest.
Communication needs are reduced to the lowest possible level.
Scaling Up A 200 person problem now requires
the coordination of only 20. The co-pilot does the talking for 10
people in meetings. The conceptual integrity of each
piece of the product is far greater. We see in the next chapter how the
coordination is done…
Example 5-Minute Critique
How Many Big Successes? One. The New York Times clipping file:
83,000 lines of code, two years Most of the code written in the last 6 months! Only 21 defects found in the first 5 weeks of use.
But other reports of chief programmer teams are very ordinary.
The NYT team (from IBM) was specially selected from the best people in the company.
What’s Wrong With the Idea The chief programmer is superbly
skilled as programmer and manager.
Where will you find this person? The skills possessed by the best
programmers and the best managers are different.
The chances of finding a chief programmer are small.
What Else is Wrong The co-pilot is as good as the chief
programmer, but has lower salary and less prestige.
The co-pilot basically waits for something to happen to the chief.
Who would take a job like this? The program clerk must love paperwork,
but software professionals hate paperwork.