Complexity and
Modularity
Outline
 Complexity
 Understanding complexity
 Granularity and context
 Modularity
 Architecture and modules
 Importing and exporting
 Coupling and cohesion
 Design elements and design rules
 Task structure matrix
 Modular operators
 Summary
Complexity
 Complexity in designs can be measured
by the interconnectedness of things.
 Complexity is a function of the degree of
dependency among elements of a
system.
 A directed graph is a convenient way to
show these dependencies as long as the
number of nodes doesn’t exceed our
ability to view and analyze the diagram.
The Design Structure Matrix
(DSM)
 An alternative to a directed graph is a DSM.
 It is an N by N matrix where the same
elements appear as rows and columns in
the same order. (The diagonal is ignored.)
 An X is placed in the matrix where a
dependency exists. The element
corresponding to a given row is dependent
upon the elements in the columns for which
an X appears
The Design Structure Matrix
(DSM) Example
Element A
Element A
Element B
0
Element B
X
0
Complexity Arises in Many
Aspects of Software Design
 Requirements
 User Interface
 “High-level” design
 “Low-level” design
 Source code
Understanding Complexity
 The complexity of a software design is
associated with the length of its description.
 The greater the number of dependencies
the longer the description.
 Using abstraction more elements can be
added while reducing the ratio of
dependencies to elements (although the
actual number of dependencies may go
up.)
Understanding Complexity
(Cont’d)
 As the complexity of the architecture
increases, the complexity of the
individual models can decrease.
 Hierarchically decomposing a system
allows us to distribute complexity across
multiple components.
 We can reduce the apparent complexity
of a system by our choice of design
language.
Granularity and Context
 “When defining complexity it is always
necessary to specify a level of detail up
to which the system is described with
finer details being ignored. Physicists
call that ‘course graining.’” (Murray
Gell-Mann)
 You cannot understand the architecture
of a system by looking at low-level
design models and source code.
Granularity and Context
(Cont’d)
 Complexity depends not only on the
number of dependencies, but also on the
pattern of dependencies.
 One must also take into account the
relationship types.
 Part of managing complexity is in our ability
to improve the comprehensibility of a
system. Although this doesn’t reduce
complexity, it improves our ability to
understand and reason about the system.
Varying Degrees of Complexity –
Fully Connected DSM
A
B
C
D
E
A
O
X
X
X
X
B
X
O
X
X
X
C
X
X
O
X
X
D
X
X
X
O
X
E
X
X
X
X
O
Varying Degrees of Complexity –
Fully Disconnected DSM
A
A
B
C
D
E
B
C
D
E
O
O
O
O
O
Varying Degrees of Complexity –
A Layered Architecture
A
B
C
D
A
O
B
X
O
C
X
X
O
D
X
X
X
O
E
X
X
X
X
E
O
Varying Degrees of Complexity –
Also a Layered Architecture
A
B
A
O
X
B
X
O
X
X
O
X
X
O
X
X
O
C
D
E
C
D
E
Varying Degrees of Complexity –
The Most Complex
A
A
B
C
O
X
X
O
D
E
O
B
C
X
D
X
E
X
O
X
X
O
Modularity
 Modularity is the primary principle by which
we manage complexity of designs and
design tasks by identifying and isolating
those connections or relationships that are
the most complex.
 The principles of coupling and cohesion are
important to understand how to create a
modular architecture.
 Modular operators can help to achieve a
simpler design.
Architecture and Modules
 We distinguish between a static design-
level view of the system’s structure in
terms of modules and a runtime
component view of the application.
 A component is a runtime entity while a
module is a discrete package of
software.
Importing and Exporting
 Things imported by a module that are
exported by another module can thought
of as abstract interfaces.
 The term interface is used to mean
anything that is imported or exported.
Coupling and Cohesion
 Coupling refers to the connection
between two modules.
 Cohesion refers to the density of
dependencies within a module
Design Elements and Design
Rules
 Typically, we take a first pass at
decomposing or splitting our system
into several subsystems.
 First we perform a functional
decomposition of the system. The
system is split both horizontally and
vertically.
 We group one set of design elements
into a potential module and another set
into another potential module.
Design Elements and Design
Rules (Cont’d)
 We select design elements that form
the strongest dependencies between
our potential modules and establish
their design first.
 These elements become the interface
between the two modules.
Design Elements and Design
Rules (Cont’d)
 These elements are called design
rules.
 Design rules tend to be things like
shared data representation (the format
of business object data) and the
interaction style (whether application
logic functions are synchronous or
asynchronous).
Analyzing a DSM for System
Modules
A
B
C
D
E
F
G
H
A
0
B
X
0
X
C
X
X
0
X
X
D
X
E
X
0
F
G
H
X
0
X
0
X
X
X
0
X
X
X
0
Analyzing a DSM for System
Modules (Cont’d)
B
C
F
A
D
E
G
H
B
0
X
X
C
X
0
X
F
A
E
G
X
0
X
X
X
0
X
X
0
X
X
D
H
X
0
X
X
0
X
0
Analyzing a DSM for System
Modules (Cont’d)
B
B
C
0
X
F
D1
E
F
X
X
0
X
X
X
0
X
X
0
C
0
X
F
X
0
D1
A
F
G
D2
0
X
X
0
G
0
X
D2
E
A
X
X
X
X
A Modular System
Design Rules
O
Des
Rules
UI
X
App X
Logic
X
O
X
X
O
App Logic
X
O
X
X
X
UI
O
X
X
O
X
O
X
X
X
O
X
X
O
Task Structure Matrix
 The design structure matrix maps to a
task structure matrix.
 Once the DSM is stable you can see the
interdependencies between design tasks
and schedule the order in which the
design tasks are accomplished.
A TSM for a Business
Application
A
A. Business Obj 1
C
D
E
F
G
0
B. Business Obj 2
0
C. Bus. Obj. Search
X
D. UI Screen 1
X
E. UI Screen 2
X
F. UI Screen 3
G. Email Notifier
B
X
0
X
X
X
0
0
0
0
Module Operators
 Splitting a design into two or more modules
 Substituting one design module for another
 Augmenting the system by adding a new
module
 Excluding a module from the system
 Inverting a module to create new interfaces
(design rules)
 Porting a module to another system
Splitting
 This is the operation of separating a set
of design tasks as represented in a DSM
into multiple groups.
 These groups should exhibit high
internal cohesion and low external
coupling to begin with.
 A module itself may split independently
from other modules. This is how a
hierarchical design is formed.
Substituting
 If two different designs serve the same
function but with different quality
attributes, then it is possible that one can
be substituted for another.
 This allows an organization to create
multiple competing designs for a given
component to find the best design.
Augmenting and Excluding
 These are complementary operations
 Augmenting means adding a module to
a design and excluding means leaving a
module out of a design
 A reconfigurable system is one that can
later be changed by augmenting or
excluding modules
Inversion
 The operation of breaking encapsulation
 It takes (some) hidden information and
makes it visible as new design rules
Porting
 Using a module in a different system
than the one it was originally designed
for.
Summary
 Complexity is probably the most
influential force in the development of
design methods and tools.
 Modular design is one of the most
effective ways to manage complexity.
 The DSM (Design Structure Matrix) is a
powerful representation model for
learning about the complexities of a
design.
Summary (Cont’d)
 A DSM is isomorphic to a TSM (Task
Structure Matrix) which serves as the
basis for creating a development
schedule.
 An architectural design can be
transformed by the application of
modular operators.
 The creation of a design for a complex
application requires several iterations
and possibly many permutations