Advanced Principles II

Principles of Object-Oriented Component Design

Copyright 1998-2006 by Object Mentor, IncAll Rights Reserved

Portions of this material are Copyright © 1998, by Addison Wesley Longman,Inc. and have been

reproduced here with permission.

www.objectmentor.com

www.junit.org

2

Increasing Complexity

1 10 1001000

10000

0

2000

4000

6000

8000

10000

Lines of Code(thousands)

1960s 1970s 1980s 1990s 2000s

Software Complexity increases Geometrically with Time

Windows 95: 14,500,000Windows NT: 35,000,000

3

Complexity and Failure(Software’s Chronic Crisis, Scientific American, September, 1994)

Project Failure vs Function Points

02000400060008000

1000012000

10 20 30 40 50

Percent Projects that Fail

Function Points

4

Complexity dilutes Productivity

Because complexity of software can grow geometrically with size...

5

Coupling

Coupling is the term used to describe the dependence of one software module upon another.

When coupling is high, there are many dependencies between the modules.

In a system with n modules, the coupling can be as high O(n2).

Coupling as a function of O(n2)

0.E+005.E+051.E+062.E+062.E+063.E+063.E+064.E+064.E+065.E+06

Number of Modules

Num

ber

of d

epen

denc

ies

1

2 3

4

5 6

7

6

Coupling – Impact of ChangeThe impact of making a change to a module is a function of its coupling.

Every module that depends upon the changed module must be inspected, compiled, tested, and redeployed.

Moreover, the transitive closure of modules that depend upon a changed module must be recompiled, re-tested, and redeployed.

That transitive closure can be as high as O(n); And since there are n such closures in the system…

(A system with a fully coupled architecture)

1

2 3

4

5 6

7

7

Dilution of Productivity

As the application size grows, more and more effort is applied to dealing with coupled modules.

At the knee of the curve more effort is applied to coupling than adding features.

The effort expended to add new features drives the complexity upwards and drives the productivity downwards.

Productivity vs Module Count

0

10

20

30

40

50

60

70

80

90

100

Number of Modules

Effo

rt a

pplie

d to

new

feat

ures

8

So…Project effort increases

geometrically with project size. … Project size increases

Exponentially with time.

9

Other costs of a highly coupled architecture

Geometrically increasing compile time.

Geometrically increasing unit test time.

Componentization is infeasible.Making footprint and load-time issues unmanageable.

10

Barrier to Components

As footprint and load time grows, the desire to break the software into individual components -- that can be independently built, tested, and deployed -- increases.

However, componentization depends critically upon being able to create subsystems that are independent. So long as coupling is high, and dependency cycles are rampant, componentization will be infeasible.

1

2 3

4 5 6 7

1

2 3

4

5 6

7 ?

11

Faulty Architecture:Dependency Cycles

A single cyclic dependency in an otherwise acyclic structure can dramatically increase coupling.

Note that the red dependency forces module six to depend upon every other module in the system.

Such dependencies have a tendency to creep in over time as the system is being maintained and enhanced. Especially during schedule crunches.

1

2 3

4 5 6 7

12

The Solution

Create a software architecture with well managed interdependencies.

13

Flattening the Geometric Curve

Coupling need not increase as O(n2).

Tree structures have no cycles and reduced coupling to O(nlog n);

Productivity decreases with the log, not the square, of the number of modules.

1

2 3

4 5 6 7

1

2 3

4

5 6

7

14

Productivity Recaptured

1

2 3

4 5 6 7

Productivity vs Module Count

0

10

20

30

4050

60

70

80

90

100

6 256 506 756 1006 1256 1506 1756 2006

Number of Modules

Pe

rce

nt

Pro

du

ctiv

ity

O(n**2)

O(nlog n)

1

2 3

4

5 6

7

time See: Large Scale C++

Software Designby John Lakos.

15

Principles of Object Oriented Component Design

What is a component?

Components on Class Diagrams

The Triad of Component PrinciplesREP: The Reuse/Release Equivalency Principle

CCP: The Common Closure Principle

CRP: The Common Reuse Principle

16

Intro to Components

Large systems of objects and classes would be overwhelming

We have lots of small and simple classes

A way must exist to deal with groups of classes

Otherwise, it’s almost like building a sand castle from individual grains of sand

“…the class is a necessary but insufficient vehicle for decomposition.”-- Grady Booch

17

What is a component

A group of classes.Some of the classes are public.

Some of the classes are private.

A C++ “Namespace”.

A Java “Package”.

A DLL.

A releasable component.

The “Simple” Answer

18

Components on Class Diagrams

Drawn as rectangle with a smaller rectangle above it.

They can be drawn large with icons of classes and their

interrelationships within them.Then the name should be in the “tab”.

Also drawn as rectangle with two small rectangles on left.

Looks like a file folder

G eom etry

19

Package Relationships

We will discuss two relationships between components

Dependency

Realizes

Packages do not stand alone and must interact with other packages

20

Dependency Structure

ControlPanel

Transport Revenue

DatabaseElevatorConveyor

A larm

Dependency structure of a nautomated parking garage.

21

Realizes

Components may be composed of abstract classes.Other packages may provide implementations for the abstract classes.

«interface»Package

ConcretePackage

This is drawn as a dashed line (like dependency) with an open, triangular arrowhead (like inheritance).

The relationship is officially known as “realizes”, but means that the concrete package implements the abstract package’s interface(s).

This is another kind of dependency.

22

Component Cohesion Principles

REP Reuse-release Equivalency Principle

CCP Common Closure Principle

CRP Common Reuse Principle

23

(REP) The Reuse/Release Equivalency Principle

What do you expect from a supplier of reusable modules?

The granule of reuse is the granule of release

24

Expectations

Documentation.Accuracy.Maintenance.

You expect the supplier to maintain the modules that you are reusing.

Predictability.You expect that the module will not change out from under you.That you will be notified in advance of any changesThat you will be given the option to use the old version.

25

Reusers Expect Release Control

In order to get users to agree to reuse a module:You must bind the reusable classes together into components.Each component need to be tracked in a release system.Each component needs release numbers.Each release needs release notes.Users must be able to continue to use the older versions for a while.

Thus, the granule of reuse is the granule of release.

Version numbers and release tracking.

26

The granule of reuse is the granule of release.

Single classes are seldom reusableThey typically depend on other classes.

They are not typically released alone.

There are ramifications for component design

The classes in a component should form both a releasable and a reusable module.

This principle deals with a kind of cohesion.

27

REP Review

What is the REP?

Are reuse groupings coincidental?

Is it primarily concerned with coupling or cohesion?

How does this differ from more traditional ways of grouping components?

REP: Group for reusers

28

(CCP) The Common Closure Principle

Given an application to which changes need to be made:

Do we want to change many components?

Or as few as possible?

Minimize the impact of change

29

Scaling up the OCP

The open closed principle states that a class should be “open for extension but closed for modification.”

This cannot be completely achieved.

Thus, we design our classes to be closed to the most likely kinds of changes that we can foresee.

That important class design consideration is also an important component design consideration.

30

Cohesion of Closure

Classes within a component should be closed together.

A component is cohesive if the classes within it are all closed to the same kinds of modifications.

When this principle can be achieved, changes do not propagate through the system.

Given a particular kind of change, either all of the classes within a package are closed to it, or they are all open to it.

31

Non-Propagation of Changes

Changes focus upon one, or a very few packages.

The rest of the packages remain unaffected.

This greatly lessens the number of packages that are affected by a change, and reduces the frequency with which components must be released.

32

CCP and REP

Sometimes these principles are in complete harmony

The best of times

Other times the two groupings may conflict somewhat.

You can choose one to lean toward

How much maintenance is expected?

REP: Group for reusers

CCP: Group for maintenance

33

CCP Review

What does the CCP tell us to do?

Why is this a good idea?

How is the CCP different from the REP?

Do the CCP and REP direct us more toward broad horizontal (technical) partitioning, or vertical (functional) partitioning?

34

(CRP) The Common Reuse Principle

Classes within a component should be reused together

Reuse creates a dependency upon the whole reused component.

Reusable components are generally made of many collaborating classes.

35

Reusers Depend on the Whole Component

When a new release of that component is created, the reuser must reintroduce it into existing applications.

There is a cost for this

And a risk

Therefore, the user will want each component to be as focused as possible.

If the component contains classes which the user does not make use of, then the user may be placed in the position of accepting the burden of a new release which does not affect any of the classes within the component that he is using.

36

Common Reuse Principle

This is a principle that breaks up components.You will end up with some small, focused components.You’ll end up with some loose classes.Loose classes may be grouped with REP and CCP into more cohesive groups.Volatility should be considered.

Given simply, the user should depend on the whole package.

This is a scaled up version of Interface Segregation.

37

Reusable Components Have Many Collaborating Classes

The relationships between those classes bind them together

Placing them in separate components will create dependencies between those components.

38

Conflict in the Triad

REP: Group

for reu

sers

CCP: Group for

maintenance

CRP: Split to avoid unneeded releases

Will receive unneeded releases.

Changes split among components Too

little

reus

er co

nven

ienceWhere in this space does your package fall?

39

CRP Review

What does the CRP tell us to do in component design?

How is it different from the REP?

How is it different from the CCP?

Could you draw the triad, and label the corners?

Place a well-known library or component in the triangular space, showing how the tradeoffs were made.

40

Package Cohesion Principles Summary

REP Group for convenience of (re)users

CCP Group for convenience of maintainers

CRP Split to prevent dependencies on partial packages

41

Principles of Component Coupling

(ADP) The Acyclic Dependencies Principle.

(SDP) The Stable Dependencies Principle.

(SAP) The Stable Abstractions Principle.

Metrics: Management vs. random walks.

Packages and Directory Structures.

Source code configuration systems.

The larger the project, the more critical it is to manage the relationships between components

42

(ADP) The Acyclic Dependencies Principle

Applications must be stabilized and released in pieces.

Otherwise, the developers interfere with each other: The “Morning After” Syndrome.

By carefully structuring components, the problem is avoided.

The dependency structure for components must be a DAG.

43

The “Morning After” Syndrome

You work till 5PM getting something working.

But when you come back the next day…Your stuff doesn't work.

Somebody stayed later than you did…

… or came in earlier

And this repeats, day after day after day…The engineers on a project step all over each other.

Time to stabilize a release is unpredictable.

44

Dependency Structures

The problem may be that the dependency structure of the project is poor, is not understood or is not respected.

Changes are rippling through the system in several directions!

You

YourCoworker

45

Well structured packages prevent this problem

Components can be released.Users that aren’t ready for the release can continue to use the old versions.

The developers can continue to modify components without affecting the users.

Components are stabilized and then released internally

Changes flow in one direction only

Dependency Cycles ruin this scheme.

46

Well Structured Packages Prevents This Problem

ControlPanel

Transport Revenue

DatabaseElevatorConveyor

A larm

47

In the garage system (prev page), we have a sane structure.

We can stabilize and plan in a rational way.

Now there is a change:When there is a problem, we just rang an alarm

Now we realize we need to display a message

The ‘alarm’ programmers aren’t aware of the DAG...

How do package structure problems occur?

48

Dependency Cycles Ruin This Scheme

The resulting structure is no longer a DAG.

D atabase

R ev enue

C ontro lP ane l

T ransport

C onv eyor E lev a to r

A la rm

49

Breaking the Cycle

It’s once again a DAG. Structure and sanity return to our little world.

D atabase

R evenue

C ontro lP ane l

T ransport

C onveyor E levator

A larmD isp lay

50

Cycles can also be broken by adding abstraction

Imposing an abstract class can invert a dependency

AbstractB

A

B

C

A

B

C

51

Stable Dependencies Principle

A component should only depend upon others that are more stable than itselfStability is a measure of the difficulty in changing a component

What makes a component hard to change?

52

A Component with many dependents is “Responsible”

Responsibility implies stability.Not free to change

Irresponsibility implies instability.Free to change

A Component that depends on many others is “Dependent”.

Independence implies stability.

Dependence implies instability.

A

A

Stable Dependencies Principle

53

Depending in the direction of INstability

This is a bad thingComponent A depends in a direction of INstability. B is free to change. When B changes, changes can ripple up to A.Since A is not free to change, this will create a problem.We wish to depend in the direction of Stability

B

A

Stable Dependencies Principle

54

B

A

Here, A is irresponsible and very dependent. B is responsible and independent.

In this case, A is free to change on its own, and nothing in the system is impacted by the change.

B is stable, and so it’s undesirable to change it.

This is a healthy structure.

Stable Dependencies Principle

55

Stable Dependencies Principle

Stability can be measured Define I. Instability metric

I = Ce / ( Ca + Ce) Ce = Efferent couplingsCa = Afferent couplings

I = 1 / ( 3 + 1 ) = 0.25

I = 0

I = 1I = 1

56

Stable Abstractions Principle

The abstraction of a package should be in proportion to its stabilityIf all packages are maximally stable, the system would be unchangable

Some packages should be stableThose that encapsulate high-level policyThese packages should be abstract

Some packages should be instableThose that encapsulate low-level implementation details

57

Stable Abstractions Principle

• Abstractness of a package can be measured

A = Na / NNa = number of abstract classesN = total number of classes

58

Analyzing Metrics

Packages have degrees of abstraction versus stabilityPackages along the line from (0,1) to (1,0) have a good balance

A

I

(0,1)

(1,0)

Main Sequence

59

Analyzing Metrics

Abstractions without dependents are useless.Concretions with lots of dependents are painful.

e.g. database schemae

A

I

(0,1)

(1,0)

Main Sequence

Zone of uselessness

Zone of pain

60

Main Sequence (cont.)

A

I

Main Sequence

• Distance from Main Sequence (normalized)

D = | A + I - 1 |• Design can be analyzed for conformance to

main sequence

D

61

Tools that Calculate the Metrics

Smallworlds

Headway

Jdepend www.clarkware.com

Depend.sh www.objectmentor.com

62

Component and Directory Structures

Our convention at Object Mentor, Inc.Each component is represented by a directory.All the .cc and.h files are placed in that directory.

A library file (.a) is generated for that directory.Any documentation files should be included too

Make file.

The directory structure is generally flat.Nested packages are not impossible, but are rare.

#includeWritten as # include “package/file.h”