Principles of Package Architecture August 28, 2017

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

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.

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

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

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.

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

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

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.

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.

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

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

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

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

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

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

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

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

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

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

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