abstraction—data, procedure, control
architecture—the overall structure of the software
modularity—compartmentalization of data and function
Functional independence—single-minded function and low coupling
refinement—elaboration of detail for all abstractions
Refactoring—a reorganization technique that simplifies the design
Abstraction is the intellectual tool that allows us to deal
with concepts apart from particular instances of those
concepts. During requirements definition an design,
abstraction permits separation of the conceptual aspects
of a system from the implementation details
details of enter
implemented with a "knowledge" of the
object that is associated with enter
Three widely used abstraction mechanism in s/w design are
It involves the use of parameterized subprograms. The
ability to parameterize a subprogram and to bind different
parameter values on different invocations of the subprogram
is a powerful abstraction mechanism.
It involves specifying a data type or a data object by
specifying legal operations on objects. Representation and
manipulation details are suppressed.
It is the third commonly used abstraction mechanism in
software design. Control abstraction is used to state a
desired effect without stating the exact mechanism of
control. IF statements and WHILE statements in modern
programming languages are abstractions of machine code
implementations that involve conditional jump instructions.
A statement of the form
“for all I in S sort files I”
leaves unspecified the sorting techniques, the nature of S, the
nature of the files, and how “for all I in S” is to be handled
“The overall structure of the software and the ways in
which that structure provides conceptual integrity for a
Structural properties. This aspect of the architectural design representation
defines the components of a system (e.g., modules, objects, filters) and the
manner in which those components are packaged and interact with one
another. For example, objects are packaged to encapsulate both data and the
processing that manipulates the data and interact via the invocation of methods
Extra-functional properties. achieves requirements for performance, capacity,
reliability, security, adaptability, and other system characteristics.
Families of related systems. The architectural design should draw upon
repeatable patterns that are commonly encountered in the design of families of
similar systems. In essence, the design should have the ability to reuse
architectural building blocks.
e se t b i d e se t c a g , e se t f x. .
ai r o u , ai r o h n e ai r o i
Modularity is the way of defining the system as a collection of well defined, manageable units with
well defined interfaces among the units. Desirable properties of a modular system include:
•Each module is a well defined subsystem that is potentially useful in other applications
•Each module has a single, well defined purpose.
•Modules can be separately compiled and stored in a library
•Modules can use other modules.
•Modules should be easier to use than to build
•Modules should be simpler from the outside than from the inside.
What is the "right" number of modules
for a specific software design?
module development cost
number of modules
COHESION - the degree to w hich a
module performs one and only one
COUPLING - the degree to w hich a
module is "connected" to other
modules in the system.
Coupling is the measure of the degree of interdependenc
between modules. Two modules with high coupling are
strongly interconnected and thus, dependent on each oth
•Content/Pathological Coupling : (worst) When a module
uses/alters data in another
•Control Coupling : 2 modules communicating with a control flag
(first tells second what to do via flag)
•Common/Global-data Coupling : 2 modules communicating via
•Stamp/Data-structure Coupling : Communicating via a data
structure passed as a parameter. The data structure holds more
information than the recipient needs.
•Data Coupling : (best) Communicating via parameter passing. The
parameters passed are only those that the recipient needs.
Coincidental Cohesion : (Worst) Module elements are
unrelated Logical Cohesion : Elements perform similar
activities as selected from outside module, i.e. by a flag that
selects operation to perform
Temporal Cohesion : operations related only by general time
performed (i.e. initialization() or FatalErrorShutdown?())
Procedural Cohesion : Elements involved in different but
sequential activities, each on different data
Sequential Cohesion : operations on same data in significant
order; output from one function is input to next (pipeline)
Informational Cohesion: a module performs a number of
actions, each with its own entry point, with independent
code for each action, all performed on the same data
structure. Essentially an implementation of an
Functional Cohesion : all elements contribute to a single,
well-defined task, i.e. a function that performs exactly one
Communicational Cohesion : unrelated operations except
need same data or input
interface • data structure
• details of external interface
• resource allocation policy
a specific design decision
Why Information Hiding?
reduces the likelihood of “side effects”
limits the global impact of local design decisions
emphasizes communication through controlled
discourages the use of global data
leads to encapsulation—an attribute of high
results in higher quality software
walk to door;
reach for knob;
repeat until door opens
turn knob clockwise;
if knob doesn't turn, then
take key out;
find correct key;
insert in lock;
move out of way;
Fowler [FOW99] defines refactoring in the following manner:
"Refactoring is the process of changing a software system in such a way that it
does not alter the external behavior of the code [design] yet improves its internal
When software is refactored, the existing design is examined for
unused design elements
inefficient or unnecessary algorithms
poorly constructed or inappropriate data structures
or any other design failure that can be corrected to yield a better design.