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.