May 26, 2005 - Granularity: The principles of Package Cohesion. â¡ REPâThe .... In Java. â¡ Counting import statemen
Principles of Package Design Chien-Tsun Chen Department of Computer Science and Information Engineering National Taipei University of Technology, Taipei 106, Taiwan
[email protected] May 26 2005
OOD principles roadmap: What distinguish good and bad OO design? Single Responsibility Class
Separation of concern
Open-Closed
Inheritance
Program to an interface, not an implementation
Liskov Substitution
polymorphism
Favor object composition over class inheritance
Dependency-Inversion Interface-Segregation
basic
advanced
1
OOD principles and principles of package design Reuse-Release Equivalence
Single Responsibility Granularity Open-Closed
Common-Reuse Common-Closure
Liskov Substitution Acyclic-Dependencies Dependency-Inversion Interface-Segregation
class
Stability
Stable-Dependencies Stable-Abstractions
package
References
2
Outline
Granularity: The principles of Package Cohesion
REP—The
Reuse-Release Equivalence Principle
CRP—Then Common-Reuse Principle
CCP—The Common-Closure Principle
Stability: The Principles of Package Coupling
ADP—The
Acyclic-Dependencies Principle
SDP—The Stable-Dependencies Principle
SAP—The Stable-Abstractions Principle
What is Reuse-Release Equivalence Principle (REP)?
Definition: the granule of reuse is the granule of release.
If a package contains software that should be reused, then it should not also contain software that is not designed for reuse. Either all of the classes in a package are reusable or non of them are.
3
What do you expect from the author of a class library that you are planning to reuse?
Good documentation, Working code Well-specified interface, etc. And You want the author to maintain it for you. You want the author to notify you in advance of any changes he plans to make to the interface and functionality of the code, giving you the option to refuse to use any new versions.
This issue is primarily political and has a profound effect on the packaging structure of software
To provide the guarantees that reusers need, authors must organize their software into reusable packages and then track those packages with release numbers Reusability comes only after there is a tracking system in place that offers the guarantees of notification, safety and support atha the potential reusers will need
4
We must also consider who the reuse is GUI library
Financial library
GUI library Financial library
What is Reuse-Release Equivalence Principle (REP)?
Definition: the granule of reuse is the granule of release.
Either all of the classes in a package are reusable or non of them are.
5
Outline
Granularity: The principles of Package Cohesion
REP—The
Reuse-Release Equivalence Principle
CRP—Then Common-Reuse Principle
CCP—The Common-Closure Principle
Stability: The Principles of Package Coupling
ADP—The
Acyclic-Dependencies Principle
SDP—The Stable-Dependencies Principle
SAP—The Stable-Abstractions Principle
What is Common-Reuse Principle (CRP)?
Definition: the classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all.
Classes that tend to be reused together belong in the same package.
6
Reusable classes collaborate with other classes that are part of the reusable abstraction
P3
P1
P2
P4
Software system
When one package uses another, a dependency is created between the packages
P3
P1
P2
P4
Software system
7
Even if the using package only uses one class within the used package, the dependency is not weaken at all changed
P3
P1
P2
P4
Every time the used package (P2) is released, the using package (P1) must be revalidated and rereleased
When you depend on a package, you depend on every class in that package
The classes you put into a package are inseparable, that it is impossible to depend on some and not the others. Otherwise, you will be revalidating and redistributing more than is necessary, wasting significant effort.
8
CRP tells more about what classes shouldn’t be together than what classes should be together
Classes which are not tightly bound to each other with class relationships should not be in the same package
What is Common-Reuse Principle (CRP)?
Definition: the classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all.
Classes that tend to be reused together belong in the same package. Classes which are not tightly bound to each other with class relationships should not be in the same package
9
Outline
Granularity: The principles of Package Cohesion
REP—The
Reuse-Release Equivalence Principle
CRP—Then Common-Reuse Principle
CCP—The Common-Closure Principle
Stability: The Principles of Package Coupling
ADP—The
Acyclic-Dependencies Principle
SDP—The Stable-Dependencies Principle
SAP—The Stable-Abstractions Principle
What is Common-Closure Principle (CCP)?
Definition: the classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package and no other packages.
This is the Single-Responsibility Principle restated for packages.
10
The Common-Closure Principle focuses on maintainability If the code in an application must change, you would rather that the changes occur all in on package, rather than being distributed through many packages. The CCP minimizes the workload related to releasing, revalidating, and redistributing the software.
The Common-Closure Principle is closely associated with the Open-Closed Principle
The OCP states that classes should be closed for modification.
100%
closure is not attainable
We design systems such that they are closed to the most common kinds of changes that we have experienced.
The CCP amplifiers this by grouping together classes that are open to certain types of changes into the same packages
11
Stability: the Principles of Package Coupling
Outline
Granularity: The principles of Package Cohesion
REP—The
Reuse-Release Equivalence Principle
CRP—Then Common-Reuse Principle
CCP—The Common-Closure Principle
Stability: The Principles of Package Coupling
ADP—The
Acyclic-Dependencies Principle
SDP—The Stable-Dependencies Principle
SAP—The Stable-Abstractions Principle
12
What is Acyclic-Dependencies Principle (ADP)?
Definition: Allow no cycles in the packagedependency graph.
To avoid morning-after syndrome
Package structures are a directed acyclic graph (DAG) 4
3 2
2 1 1
1
2
13
A package diagram with a cycle
How to testing
Breaking the cycle
Apply the Dependency-Inversion Principle
Create a new package on which both MyDialogs and MyApplication depend
14
The package structure cannot be designed from the top-down
Perspective of the package dependency diagrams:
Package
dependency diagrams have very little to do with describing the function of the application
They are a map to the buildability of the application
Do not try to design the package dependency structure before we had designed any classes
The package dependency structure grows and evolves with the logical design of the system
Outline
Granularity: The principles of Package Cohesion
REP—The
Reuse-Release Equivalence Principle
CRP—Then Common-Reuse Principle
CCP—The Common-Closure Principle
Stability: The Principles of Package Coupling
ADP—The
Acyclic-Dependencies Principle
SDP—The Stable-Dependencies Principle
SAP—The Stable-Abstractions Principle
15
What is Stable-Dependencies Principle (SDP)?
Definition: Depend in the direction of stability.
Modules that are intended to be easy to change are not depended on by modules that are harder to change than they are
What is stability?
instable (easy to change)
stable (difficult to change)
16
A package with lots of incoming dependencies is very stable
A
B
C
X is a stable package because is it difficult to change (X is responsible to A, B, and C)
A package with lots of outgoing dependencies is very instable
I
J
K
Y is a instable package because is it easy to change (Y is irresponsible to I, J, and K)
17
Stability metrics
(Ca) Afferent Couplings: The number of classes outside this package that depend on classes within this package (Ce) Efferent Couplings: the number of classes inside this package that depend on classes outside this package (Instability I): I = Ce / (Ca + Ce)
I
has the range [0,1]
I = 0 indicates a maximally stable package
I = 1 indicates a maximally instable package
An example for calculating stability metrics of the package Pc:
in-2 in-3
out-1 in-1
Ca = 3 Ce = 1 I = Ce / (Ca + Ce) = 1 / (3 + 1) = 0.25
18
How to count dependencies?
In C++
Dependencies
are typically represented by #include
Organizing your source code such that there is one class in each source file will simplify the counting
In Java
Counting
import statements and qualified names
The meaning of Stable-Dependencies Principle from the view point of I metrics
I metric of a package should be larger than the I metrics of the packages that it depends on (i.e., I metrics should decrease in the direction of dependency) I=1
I=1
I=0 I = 0.25
19
Not all packages should be stable: if all the packages were maximally stable, the system would be unchangeable
Violation of SDP
The cause of the bad dependency
How to balance stability with flexibility?
Fixing the stability violation using DIP or creating a new package Stable
U
I=0
I=1
Flexible
C
IU
Applying DependencyInversion Principle
I = 0.25 I=1 I=0
Creating a new package, and moving the class that the stable depend on into the new package
20
The relationship between Open-Closed Principle and the Stable-Dependencies Principle
Some software (high-level architecture and design decisions) in systems should not change very often
If
the high-level design is placed into stable packages, it would be difficult to change
The OCP tells us:
A
module should be open for extension (flexible), but closed for modification (stable)
What kinds of classes are flexible enough to be extended without requiring modification?
Abstract classes and interfaces Programming to interface, not to implementation
Outline
Granularity: The principles of Package Cohesion
REP—The
Reuse-Release Equivalence Principle
CRP—Then Common-Reuse Principle
CCP—The Common-Closure Principle
Stability: The Principles of Package Coupling
ADP—The
Acyclic-Dependencies Principle
SDP—The Stable-Dependencies Principle
SAP—The Stable-Abstractions Principle
21
What is Stable-Abstractions Principle (SAP)?
Definition: A package should be as abstract as it is stable.
Stability implies abstraction
A
stable package should also be abstract so that its stability does not prevent it from being extended
An instable package should be concrete since its instability allows the concrete code within it to be easily changed
Measuring abstraction
(Nc) : The number of classes in the package (Na) : The number of abstract classes in the package (Abstractness A): A = Na / Nc
A
has the range [0,1]
A = 0 implies that the package has no abstract classes
A = 1 implies that the package contains nothing but abstract classes
22
Defining the relationship between stability (I) and abstractness (A) I = 0, A = 1 maximally stable and abstract
I = 1, A = 0 maximally instable and concrete
The A-I graph
Zones of exclusion: areas where packages should not be
I = 1, A = I maximally instable and abstract
I = 0, A = 0 maximally stable and concrete
The A-I graph
23
The main sequence: a package that sits on the main sequence is not too abstract for its stability, nor is it too instable for its abstractness
The A-I graph
Distance from the main sequence: package should be on or close to the main sequence
(Distance D): D = |A + I - 1| / √2
D
ranges from [0, ~0.707]
(Normalized Distance D’): D’ = |A + I - 1|
D’
ranges from [0, 1]
D = 0 indicates that the package is directly on the main sequence
D = 1 indicates that the package is as far away as possible from the main sequence
24
Using the D metric: calculate the mean and variance of all the D metrics abstract and instable
concrete and stable
standard deviation
Using the D’ metric: plot the D’ metric of each package over time
a control threshold at D’ = 0.1
some strange dependencies have been creeping into the package over the last two releases
25
Applying the following package design principles well will help you in designing large software system Single Responsibility
Reuse-Release Equivalence Granularity
Open-Closed
Common-Reuse Common-Closure
Liskov Substitution Acyclic-Dependencies Dependency-Inversion
Stability
Stable-Dependencies Stable-Abstractions
Interface-Segregation
Question?
26
Modular Continuity [OOSC]
Definition: a method satisfies Modular Continuity if, in the software architectures that it yields, a small change in a problem specification will trigger a change of just one module, or a small number of modules.
Continuity means that small changes should affect individual modules in the structure of the system, rather than the structure itself.
A small change in the argument will yield a proportionally small change in the result argument (specification)
result (system)
27
Breaking the cycle with dependency inversion
28
Breaking the cycle with a new package
29
Examples of packages that fall within the Zone of Pain (I = 0, A = 0. Maximally stable and concrete)
Database schema
Notoriously
volatile, extremely concrete, and highly depended on
Utility libraries
string
(concrete , nonvolatile)
30