1. Principles of Package Architecture
August 28, 2017

2. Package Cohesion Principles
The Release Reuse Equivalency Principle (REP)
The unit of reuse is the unit of release
A reusable element cannot be reused unless it managed by a release system.
The package is an effective unit for reuse and release
The common Closure Principle (CCP)
Classes that change together, belong together
In large system, the more packages that change, the greater the work to rebuild
Grouping classes that change together can minimize the # of packages that are changed.
The Common Reuse Principle (CRP)
Classes that are not reused together should not be grouped together
When they are bundled together, some classes may not be needed by certain client
The client would still need to upgrade/recompile even a class that has changed is really not used

3. Discussion - Package Cohesion Principles
The three principles are mutually exclusive
Each principle benefits a different group of people
The REP and CRP are intended to minimize the burden on reusers.
The CCP makes the system easy to maintain – so it is good for maintainers.
The CCP tends to make packages as large as possible
The CRP tries to make packages as small as possible.
In practice
Architects start with a CPP dominated design more towards in-house developers and maintainers
As the system stabilizes and functionally becomes mature, the architects may refactor it to maximize REP and CRP for external users.

4. Package Coupling Principles
The Acyclic Dependencies Principle (ADP)
The dependencies between packages must not form cycles.
The Stable Dependencies Principle (SDP)
Depend in the direction of stability
The Stable Abstraction Principle (SAP)
Stable packages should be abstract packages

5. Acyclic Dependencies Principle
GUI
Comm
Analysis
Protocol
Database
Modem Ctrl
This design is not perfect:
It violates the DIP
It violates the OCP
Comm Error

6. ADP Break Cycles – New Package
GUI
Comm
Analysis
Protocol
Database
Modem Ctrl
The designer of Comm Error decided to use a GUI component to display error message. It makes Comm Error depend on GUI.
Comm Error
A cycle of dependencies is formed.

7. Acyclic Dependencies Principle
What is wrong with a cycle?
When we test Protocol after a change, for example, we need build the test suite with Comm Error, GUI, Comm, Modem Control, Analysis, and Database.
How to Break a Cycle
Creating a new package
Move what is used by Comm Error from GUI into a new package
Using the DIP and ISP.
Define an interface in the package of higher abstraction
The class in the lower package implements the interface

8. ADP Break Cycles – New Package
GUI
Comm
Analysis
Protocol
Database
Modem Ctrl
Comm Error
The new package Message Manager contains the component needed by Comm Error.
It breaks the cycle.
Message Manager

9. ADP Break Cycles – DIP AB XY ClassA ClassX ClassB ClassY
ClassA depends on ClassX and ClassY depends on ClassB. Thus, Packages AB and XY form a cycle of dependency.

10. ADP Break Cycles – DIP AB XY ClassA ClassX ClassB ClassY implements
uses
InterfaceY
Interface InterfaceY contains all operations needed by ClassB from ClassY.
ClassY implements InterfaceY and ClassB depends on InterfaceY.

11. Stable Dependencies Principle
The Stable Dependencies Principle (SDP)
Depend in the direction of stability
A package should depend on packages that are more stable than itself.
Stability
The amount of work required to make changes
A package is very stable if many other packages depend on it
It would require propagate all the changes to the dependent packages
A package is responsible to those packages that depend on it
A package is irresponsible if there is no package depending on it
A package is dependent if it depends on another package
A package is independent if it does not depend on any package

12. SDP: Stability AA BB CC XX
XX: very stable since three packages AA, BB, and CC depend on it
XX: responsible for AA, BB, and CC
XX: independent since it does not depend on anyone
AA, BB, CC: dependents of XX

13. SDP: Stability A X Y Z
A: very instable, external changes may be from X, Y, and Z
A: Irresponsible since no one depends on it

14. SDP – Stability Metrics
The Instability of a package
Afferent coupling
Ca = the # of incoming dependencies (classes outside the package)
Efferent coupling
Ce = the # of outgoing dependencies (classes outside the package)
Instability
I = Ce/(Ca + Ce)
If no outgoing dependencies (Ce = 0), I = 0, very stable
If no incoming dependencies (Ca = 0), I = 1, very instable
The SDP
Depend upon packages whose I metric is lower than yours
Instable packages at the top and stable ones at the bottom

15. Stable Abstraction Principle
The Stable Abstraction Principle (SAP)
Stable packages should be abstract packages
Rationale for the SAP
The SDP leans to stable bottom and flexible top
The bottom becomes really hard to change
Abstracts are less prone to change than concretes
The OCP can make a class stable (closed for changes) and flexible (open for extension)
Highly abstract bottom
Instable packages are easy to change
Stable packages are easy to extend

16. SAP: OCP NO OCP With OCP AA AA MyStack MyStack Stack Not Desirable
AA depends on
a concrete class.
Better Design
AA depends on interface Stack
MyStack implements Stack, and thus
It depends on Stack

17. SAP – Abstractness Metrics
The Abstractness Metrics
Nc = total # of classes in the package
Na = # of abstract classes
Abstractness
A = Na / Nc
= (# of Abstract classes ) / (total # of classes)
A = 0  very concrete
A = 1  very abstract

18. SAP – The A and I Graph The SAP: A=1 A I I=1
The Main Sequence A I
I=1
The SAP:
I should increase as A decreases
Concrete packages should be instable while abstract packages should be stable

19. SAP – The A and I Graph Upper-Left Lower-Right
Completely abstract and very stable
Lower-Right
Completely concrete and very instable
Upper-Right – useless zone
Highly abstract, but no one depends on it
So we don’t want to put a package there
Lower-Left – pain zone
Highly concrete, and has many incoming dependencies
So we want to avoid to put a package there
The Main Sequence
To stay away from the useless and pain zones
Its abstractness is proportional to its incoming dependencies
Its concreteness is proportional to its outgoing dependencies

20. SAP – Distance Metrics The Distance to the main sequence
Distance D
D = | A + I – 1| / sqrt(2) ranging [0, 0.707]
Normalized Distance
D’ = | A + I – 1| ranging [0, 1]
D’ = 0  directly on the main sequence - desirable
D’ = 1  far away from the main sequence – not desirable
The metrics are not prefect
DO NOT use them as the sole indicator

21. Summary The Acyclic Dependencies Principle (ADP)
The dependencies between packages must not form cycles.
The Stable Dependencies Principle (SDP)
Depend in the direction of stability
The Stable Abstraction Principle (SAP)
Stable packages should be abstract packages