CS 246
Packaging
If builders built buildings the way programmers write
programs, the first woodpecker would destroy civilization
Weinberg's Second Law
July 8th
John Champaign
(jchampaign@uwaterloo.ca)
Software Architecture Group
Overview
• Packaging
• Martin’s Packaging Principles
• Principle Validation
• Grad studies in CS
What is Packaging?
• Higher level organization of source code, analogous to
classes
• To improve human understanding, no benefit at machine
level (slight hit)
• Supported to a lesser/greater extent in different languages
• As mentioned last week, architectural-level issues typically
NOT managed by any tool or language
Architectural Structuring
Mechanisms
• Large-scale information hiding as discussed last week
What is Packaging? (cont’d)
• Different from a module or a subsystem
• Dividing system for release
– Booch equates package with module, stressing high
cohesion and low coupling
• Whereas namespace and package control
access, packages provide a bundle of functionality
• Components are subtly different, but similar
Martin Packaging
• Martin Package, Good Martin Package
• Explicit long-term division, dependencies, separation of
concerns
• Follows Martin’s principles (ambiguity)
• In Java a JAR is more of a Martin Package than code with
the package keyword
Principles
• Granularity - partitioning classes, package
cohesion
– Reuse-Release Equivalence (REP), Common-Reuse
(CRP), Common-Closure (CCP)
• Stability - package coupling
– Acyclic-Dependency (ADP), Stable-Dependencies
(SDP), Stable-Abstractions (SAP)
Cohesion
• Any part of a software system has SOME
relationship with the rest of the system
• Cohesion deals with how tightly two parts of a
system are related
• Following three principles help developers decide
how to partition classes into packages
Reuse-Release Equivalence
Principle (REP)
• The granule of USE is the granule of release
• Use vs. Reuse (Malton view, Martin view)
• Political principle - every release a separate
product (e.g. Linux Kernel)
• Same audience for entire package
REP Example
• Macrohard software sells a popular financial
framework, in version 7.0 they begin depending
on a new math package (that they bundle with
their financial framework and demand that you
install).
• After a bug is discovered (also present in 6.3, the
last version in the 6 series), they tell all their
customers to upgrade to 7.1.
• Some customer run this framework on a platform
which doesn’t support the new math package and
are outraged.
Common-Reuse Principle (CRP)
• If you USE one class in a package, you use them all
• Depending on a package means depending on the entire
package -> keep it trim!
• If a class tends to be used along with other classes, they
should all be in the same package
• Somewhat pragmatically, this principle also simplified
support if you can prevent your customers from tearing
apart packages and using only part of it
CRP Example
• Classes Buffy, Xander, Willow and Giles tend to
be used together (if one is used, it often depends
on, or in turn uses the others)
– they should all be in the same package
• Class Angel works on its own, occasionally
interacting with the other classes, but often
operating independently
– it should be in its own package (and perhaps get his
own show)
Common-Closure Principle
(CCP)
• A change that affects a package affects all classes
in that packages and nothing else.
• Any change request (new features, bug fixes, etc)
should be fulfilled by changing only 1 package
• Minimizes effort for release, validation and
distribution
CCP Example
• During the 3.x series of its popular database
product, Prophesy made a total of 317 bug fixes.
Of these, 253 were resolved within a single
package, the other 64 spanned multiple packages.
• The packages these bug fixes spanned should be
examined to ensure their purpose is clear (and
possibly some should be merged into a single
package)
Stability
• Ease of change as opposed to frequency
• A system that never changes is useless
– e.g. vi
• We try to be strategic about change, isolate
the areas where it should occur
Acyclic-Dependencies Principle
(ADP)
• Allow no cycles in the package-dependency graph.
• Circular dependencies between classes will
(usually) prevent compilation – no such
enforcement at package level
• Circular dependencies cause the “Weekly Build”
problem
Weekly Build Problem
• Good discussion in text
• Problems can start as soon as multiple people
work on a code base
• Starts getting bad for medium sized projects,
solution is a weekly build – Everyone develops
independently, then Friday afternoon is spent
integrating changed, everyone starts from the
same place Monday morning
Weekly Build (cont’d)
• Friday afternoon creeps into Friday night, then
Saturday, then Sunday
• Weekly integration changes to fortnightly, then
monthly
• Eventually system gets large enough that we need
a new approach (see DIP in Martin)
Cyclic to Acyclic
Stable-Dependency Principle
(SDP)
• Depend in the direction of stability.
• Packages will have different stabilities, less stable
packages should depend on more stable packages
• Payoff comes in validation and release
• I = Ce / (Ce+Ca)
– I – Instability, Ce – Efferent Coupling, Ca – Afferent
Coupling
SDP Example
Instability
IPC:
MM:
VFS:
NI:
PS:
2/2 = 1
2/3 = 0.67
2/3 = 0.67
1/2 = 0.5
0/4 = 0
Packages Arranged by Instability
Stable-Abstraction Principle
(SAP)
• A package should be as abstract as it is stable.
• The rationale for this is that abstract classes
formalize the design at the code level, and the
design should not be changing often
• A = Na / Nc
– A – Abstractness, Na – Number of abstract classes,
Nc - Number of classes
SAP Example
Code
enum outputDevice {PRINTER, DISK};
void Copy(OutputDevice dev)
int c;
while ((c = ReadKeyboard()) != EOF) {
if (dev == PRINTER) {
WritePrinter(c);
} else {
WriteDisk(c);
}
}
}
class Writer {
public:
virtual void Write(char) = 0;
};
class Reader {
public:
virtual char Read() = 0;
};
void Copy(Reader& r, Writer& w) {
int c;
while((c = r.read()) != EOF) {
w.write(c);
}
}
Main Sequence
• SDP and SAP are tightlycoupled (should be used
together)
• Comparing Abstractness
to Instability gives us the
“Main Sequence” which
provides warning areas
Principles Validation
(MMath work)
• Take principles and validate that they provide the
benefits they claim to
• Started with Stable-Dependency Principle
• Considered the Linux kernel and decided that a
source directory was analogous to a package
• Compared how often each package changed with
the calculated stability
Results
Problems
• Directory/Package equivalence might be bad
assumption
• SDP predicts EASE of change, not frequency –
assumption that the two are correlated might be
off
• Next step, try again with another system, continue
work with other 5 principles
Grad Studies
(in general)
• As different from undergrad as undergrad is from high
school
• If academia was a family (with the profs as parents),
undergrads would be the children and grad students would
be the teenagers
• Low pay, but financially do-able
• Enjoyable lifestyle, chance to think about interesting ideas,
have engaging conversations and opens door to certain
careers