Modularity in Design:
Formal Modeling & Automated Analysis
Yuanfang Cai
Motivation
A Real Story
Designers Need to Reason




Consequences of a Change
Options to Accommodate a Change
Refactor or not
Architecture Adaptability
Prevailing Design Representations are not
Adequate
Goals
 Ultimate Goal
 Rational value-oriented decision-making
 Tool support
 The Goal of this Dissertation
 Formal analyzable design modeling framework
 Prototype tool: Simon
Thesis
 Formal account of the key concepts of informal
modularity


Baldwin and Clark's theory
Parnas's information hiding modularity
 Automatic derivation of design coupling structures


Design Structure Matrix
Other coupling Analysis
 Evolvability analyses such as design impact analysis.
 General model of modularity in design is general.


Traditional object-oriented modularity
Newer aspect-oriented modularity
Outline







Traditional Design Representations
Emerging New Approach
Formal Models and Analysis Tool
Model Decomposition
Model Extension
Evaluation Summary
Future Work
(A)
(B)
 Not Well Suited to Model
Choose which?
“information hiding”?
“memory size”, “input size”?


Environment condition
Implicit design decisions
 Not Designed for



Design structure reasoning
Evolvability analysis
Quantitative analysis
Outline







Traditional Design Representations
Emerging New Approach
Formal Models and Analysis Tool
Model Decomposition
Model Extension
Evaluation Summary
Future Work
Emerging New Approach
 “Design Rule: the Power of Modularity” [Baldwin 00]
 Design
Rules
 Modeling: Design Structure Matrix (DSM)
[Steward81,Eppinger91]
 Economic Analysis: Net Option Value (NOV)
 “The Structure and Value of Modularity” [SWC01]
Design Structure Matrix (DSM)
Input
Circular Shift
A B C D E F G H I J K L M
A - In Sig
B - In Data
C - In Impl
. X
X . X
X X .
D - Circ Sig
E - Circ Data
F - Circ Impl






Design Variables
Dependences
Design Rule
Proto-Modules
Reorder
Extension
X
X
G - Alph Sig
H - Alph Data
I - Alph Impl
J - Out Sig
K - Out Data
L - Out Impl
M - Master
Alphabetizing
X
X X
X X
. X
X . X
X X .
X
X
X
X
X
X X
. X
X . X
X X .
X
X
X
X
Output
X
X
X
X
. X
X
X . X
X X .
X
.
Master Control
Design Structure Matrix (DSM)
(B) Information Hiding Design
(A) Sequential Design
X Y Z N A D G J O P B C E F H I K L M
X Y Z A D G J B E H K C F I L M
X - Computer
.
X - Computer
.
Y - Corpus
X . X
Y - Corpus
X . X
Z - User
X
Z - User
X
N - Line Type
.
A - In Type
J - Out Type
.
B -In Data
X X
. X X
E - Circ Data
X X
X . X
H - Alph Data
K - Out Data
X X
X X
X X .
X
X X
I - Alph Alg
X X X
L - Out Alg
X X
M - Master
E - Circ Data
F - Circ Alg
.
X X
X
X X X X X
X
. X
X
X .
X X
X X
X
X X X
H - Alph Data X X
X
I - Alph Alg
X X X X
.
X X X
X X
.
B - Input Data X X
X
C - Input Alg
X X X X
X
X
.
O - Line Data X X
P - Line Alg
X X
.
F - Circ Alg
.
G - Alph Type
J - Out Type
.
X X
.
D - Circ Type
.
G - Alph Type
C - In Alg
.
A - In Type
.
D - Circ Type
.
.
K - Out Data
L - Out Alg
.
.
M - Master
X X
X X
X
. X
X .
X
. X
X
X .
X
. X
X
X .
X
. X
X
X .
X X X X X X
.
New Approach Summary
 General


Object-Oriented (OO), Aspect-Oriented (AO) [SGSC05]
Generalized Information Hiding Interface
 Represent Software Coupling Structure


Constantine, Stevens, Brooks….
Call Graph, Reflexion Model [Murphy 95], Lattix
 Make Information Hiding Criterion Precise

Design Rules are Invariant to Environment Change
 Analyze Software Quantitatively
DSM Limitations
 Can’t represent possible choices
 Input Condition?
 Core Size?
 Design Impact Analysis?
 What if x changes from x1 to x2?
 How many ways?
 Ambiguous
 What is “dependence?”
 a  b  c
 c  d  e
 Very hard to build
A D G J B E H K C F I L M
A - Input Sig
.
D - Circ Sig
.
G - Alph Sig
.
J - Out Sig
.
B - In Data
. X X
E - Circ Data
X . X
H - Alph Data
K - Out Data
X X .
C - Input Impl
F - Circ Impl
I - Alph Impl
L - Out Impl
M - Master Impl
.
X
X
X
.
X X
X
.
X X X
X X
X X X X
X X
.
.
.
Outline







Traditional Design Representations
Emerging New Approach
Formal Models and Analysis Tool [CS05]
Model Decomposition
Model Extension
Evaluation Summary
Future Work
Constraint Network
Variables
1.

Design Dimensions
Values
2.

Possible Choices
Constraints
3.

Relations Among Decisions
input_ds:{core4,disk,core0,other};
envr_input_size:{small,medium,large};
input_ds = disk => envr_input_size = large;
X Y Z N A D G J O P B C E F H I K L M
X - Computer
.
Y - Corpus
X . X
Z - User
X
N - Line Type
.
.
A - In Type
.
D - Circ Type
.
G - Alph Type
J - Out Type
.
.
O - Line Data X X
P - Line Alg
X X
X
. X
X
X .
B - Input Data X X
X
C - Input Alg
X X X X
E - Circ Data
F - Circ Alg
X X
X
X X X
H - Alph Data X X
X
I - Alph Alg
X X X X
K - Out Data
L - Out Alg
M - Master
X X
X X
X
. X
X .
X
. X
X
X .
X
. X
X
X .
X
. X
X
X .
X X X X X X
.
Augmented Constraint Network
Constraint Network
Dominance Relation
1.
2.


Design Rules
Environment
(input_impl, input_ADT)
(input_impl, input_format)
3.
Clustering
Environment:
{envr_input_format, envr_core,…}
Design Rules:
{input_ADT, circ_ADT…}
X Y Z N A D G J O P B C E F H I K L M
X - Computer
.
Y - Corpus
X . X
Z - User
X
N - Line Type
.
.
A - In Type
.
D - Circ Type
.
G - Alph Type
J - Out Type
.
.
O - Line Data X X
P - Line Alg
X X
X
. X
X
X .
B - Input Data X X
X
C - Input Alg
X X X X
E - Circ Data
F - Circ Alg
X X
X
X X X
H - Alph Data X X
X
I - Alph Alg
X X X X
K - Out Data
L - Out Alg
M - Master
X X
X X
X
. X
X .
X
. X
X
X .
X
. X
X
X .
X
. X
X
X .
X X X X X X
.
Analyzable Models
1. Constraint Network

Analyses




Design Change Impacts
Precise Dependence
DSM Analyses
Design Automaton



Change Dynamics
Design Space
Design Evolution
DesignSpace matrix{
client:{dense, sparse};
ds:{list_ds, array_ds, other_ds};
alg:{array_alg, list_alg, other_alg};
ds = array_ds => client = dense;
ds = list_ds => client = sparse;
alg = array_alg => ds = array_ds;
alg = list_alg => ds = list_ds;
}
2. Dominance Relation
{(ds, client), (alg, client)}
3. Clustering
Environment Cluster: {client}
Design Cluster: {ds, alg}
Design Automaton
Design Impact Analysis
client = dense
ds = array_ds
alg = array_alg
client = sparse
S1
client = sparse
S6 ds = list_ds
ds = list_ds
alg = list_alg
alg = other_alg
client = sparse
client = dense
S5 ds = array_ds
alg = other_alg
ds = other_ds
client = sparse
S2
alg = other_alg
client = sparse
ds = other_ds
alg = other_alg
S3
client = dense
ds = other_ds
alg = other_alg
S4
client = sparse 1. Non-deterministic;
2. Minimal Perturbation;
ds = list_ds
alg = other_alg 3. Respect Dominance Relation
Design Automaton
Precise Definition of Pair-wise Dependence – DSM Derivation
client = dense
ds = array_ds
alg = array_alg
client = sparse
client = sparse
S6 ds = list_ds
S1
alg = list_alg
alg = other_alg
client = sparse
client = dense
S5 ds = array_ds
alg = other_alg
ds = other_ds
client = sparse
S2
client = sparse
ds = other_ds
alg = other_alg
S3
client = dense
ds = other_ds
alg = other_alg
S4
client = sparse
ds = list_ds
alg = other_alg
1
1.client
2.ds
3.alg
2
3
.
x
x
.
.
x
x
Simon
Augmented Constraint Network
User Input
Dominance
Relation
Constraint
Network
Cluster Set
A Cluster
Derive
Design Automaton
Modeling
Analysis
Pair-wise
Dependence
Design Impact Analysis
Design Structure Matrices
Net Option Value
Other DSM Analyses:
scheduling, cycle detection...
KWIC Regenerated
Sequential Design
Information Hiding Design
Design Impact Analysis
(A) Sequential Design
input_impl
S19
C1
C4
S179
alph_ds
alph_impl
output_impl
input_ds
S18 C2 S
555 alph_ds
C2 circ_ds
C5
S558
input_impl
S865 circ_impl
alph_ds
alph_impl
alph_impl
output_impl
output_impl
S102
C3
(B) Information Hiding Design
input_impl
S1535
C1
S75
C3
S1284
C4
S1034
C5
C2
S2476
linestorage_ds
linestorage_impl
alph_ds
alph_impl
(b) KWIC IH DA
(a) KWIC SD DA
C1
C2
C3
C4
C5
S155 alph_ds
alph_impl
envr_input_format = new
envr_input_size = large
envr_input_size = small
envr_alph_policy = partial
envr_alph_policy = search
1
7
0
3
3
1
2
0
2
2
Related Work
 Alloy
 Jackson [J06]
 DSM
 MacCormack, Rusnak, and Baldwin [MRB05]
 Lattix—A Commercial Tool
 Sangal, Jordan, Sinha, and Jackson [SJSJ05]
 Traditional Design Impact Analysis
 Robert Arnold and Shawn Bohner [AB96]
Scalability Issue
Transition


Changes
0
matrix = dense
1
matrix = sparse
2
ds = array_ds
3
ds = list_ds
4
ds = other_ds
5
alg = array_alg
6
alg = list_alg
7
alg = other_alg
Constraint Solving
Explicit Solution Enumeration
Outline







Traditional Design Representations
Emerging New Approach
Formal Models and Analysis Tool
Model Decomposition [CS06]
Model Extension
Evaluation Summary
Future Work
Model Decomposition
(1) Construct CNF Graph
(2) Cut Edges According to Dominance Relation
(3) Create Condensation Graph
(4) Compose Sub-ACN
1: linestorage_impl = orig => linestorage_ADT = orig && linestorage_ds = core4;
2: linestorage_ds = core4 => envr_input_size = medium || envr_input_size = small;
3: linestorage_ds = core0 => envr_input_size = small && envr_core_size = large;
4: linestorage_ds = disk => envr_input_size = large;
5: circ_ds = copy => envr_input_size = small || envr_core_size = large;
6: circ_impl = orig => circ_ADT = orig && circ_ds = index && linestorage_ADT =
orig;
Construct CNF Graph
(¬linestorage impl = orig  linestorage ADT = orig) 
(¬linestorage impl = orig  linestorage ds = core4) 
(¬linestorage ds = core4  envr input size = medium || envr input size = small) 
(¬linestorage ds = core0  envr input size = small) 
(¬linestorage ds = core0  envr core size = large) 
(¬linestorage ds = disk  envr input size = large) 
(¬circ ds = copy  envr input size = small  envr core size = large) 
(¬circ impl = orig  circ ADT = orig) 
(¬circ impl = orig  circ ds = index) 
(¬circ impl = orig  linestorage ADT = orig)
Construct CNF Graph
(1)(¬circ_ds
Construct
CNF
Graph
= copy
 envr_input_size
= small  envr_core_size = large)
(2)(¬linestorage_ds
Cut Edges According
toinput
Dominance
Relation
= core0  envr
size = small)
envr_input_size
envr_core_size
linestorage_ds
circ_ds
circ_ADT
linestorage_impl
circ_impl
linestorage_ADT
Construct Condensation Graph
envr_input_size
envr_core_size
linestorage_ADT
linestorage_ds
linestorage_impl
envr_input_size
envr_core_size
linestorage_ADT
circ_ADT
circ_ds,
circ_impl
envr_input_size
envr_core_size
linestorage_ADT
linestorage_ds
linestorage_impl
circ_ADT
circ_ds
circ_impl
Line Storage Function
Circular Shift Function
KWIC Decomposed
Information
Hiding
Sequential
Design
Result Integration
Design Impact Analysis
Input 1: Original Design
1: envr_input_size = medium
2: envr_core_size = small
3: linestorage_ADT = orig
4: linestorage_ds = core4
5: linestorage_impl = orig
6: circ_ADT = orig
7: circ_ds = index
8: circ_impl = orig
Input 2: A Change
envr_input_size = large
1:
2:
3:
4:
5:
1:
2:
3:
6:
7:
8:
C0
envr_input_size
= large
L2
L0
envr_input_size
= large
L3
envr_input_size
= large
1:
2:
3:
4:
5:
C1
1:
2:
3:
4:
5:
1:
2:
3:
6:
7:
8:
Output
1: envr_input_size = large
2: envr_core_size = small
3: linestorage_ADT = orig
4: linestorage_ds = other
5: linestorage_impl = other
6: circ_ADT = orig
7: circ_ds = core4
8: circ_impl = orig
1: envr_input_size = large
2: envr_core_size = small
3: linestorage_ADT = orig
4: linestorage_ds = disk
5: linestorage_impl = other
6: circ_ADT = orig
7: circ_ds = core4
8: circ_impl = orig
Result Integration
Pair-wise Dependence Relation
Generalizability--- WineryLocator
Generalizability--- WineryLocator [Lopes05]
(1) Missing Transitive Dependences (2) Ambiguities
(3) Potential Problems in Quantitative Analysis
Generalizability--- HyperCast
6 Main
Functions
5 “Crosscutting”
Functions
No Crosscutting
Generalizability--- HyperCast [SGSC05]
(1)
(2)
Missing Transitive Dependences
Potential Problems in Quantitative Analysis
Related Work
 Constraint Network Decomposition
 Choueiry and Noubir [CN98]
 Dechter and Peal [DP89]
 Freuder and Hubbe [FH93]
 Bottom-up Clustering
 Hutchens and Basili [HB95]
 Schwanke [S91]
 Mancoridis [MMRC98]
Expressiveness Issue
<<interface>>
Subject
+addObserver(Observer)()
+removeObserver(Observer)()
+notify()()
<<interface>>
Observer
+update()
 Role Assignment

A decision brings a Set
 Design Pattern

Screen:Observer
-display:String
+update()
A Decision Brings a SubSpace
 Crosscutting Decisions

Prevailing notification policy
Point: Subject
-x: int
-y: int
-c: color
+getX():int()
+getY():int()
+getColor():Color()
+setX(int)()
+setY(int)()
+setColor(Color)()
 Haneemann and Kiczales’s Analysis

Object Oriented vs. Aspect Oriented
Line:Subject
-p1:Point
-p2:Point
-c:Color
+getP1():Point()
+getP2():Point()
+getColor():Color()
+setP1(Point)()
+setP1(Point)()
+setColor(Color)()
Outline







Traditional Design Representations
Emerging New Approach
Formal Models and Analysis Tool
Model Decomposition
Model Extension
Evaluation Summary
Future Work
Model Extension
2: set subject_role(*elements):(v1{point, line}, v2{point, line, screen}, other);
3: set policy_observing(orig, other):
(v1{color}, v2{color, position}, other);
(1) Set-Valued Variable
…
8: subspace d_paradigm: (OO, AO);
(2) SubSpace-Valued Variable
9: d_paradigm_OO[
10: scalar adt_observer:(orig, other);
…
14: ˜subject_role = orig => adt_subject = orig && ˜policy_observing = orig; ];
(3) Crosscutting Constraints
16: d_paradigm_AO[
17: scalar abstract_protocol_interface:(orig,
other);
impl : observer role
• subject = orig)(adt observer = orig ^
( policy :policy_observing • policy = orig))
…
22: ˜concrete_protocol = orig => abstract_prototcol_interface = orig
&& ˜subject_role = orig && ˜observer_role = orig && policy_update = orig;];
Designate Design Alternative
Figure Editor
AND
elements
OR
observer_role
subject_role
OR
v1{point, line, screen} other
policy_observing
OR
v1{Screen} other
d_paradigm
OR
v1{color} v2{color, position} other
v1{point, line} v2{point, line, screen} other
OR
OO
AO
Basic constraints
Automatically Generated ACN
1: scalar point_elements:(orig,other);
2: scalar line_elements:(orig,other);
…
11: screen_elements != orig || (adt_observer = orig
&& policy_update = orig);
12: adt_subject = orig => d_mapping = orig &&
adt_observer = orig && policy_notify = push;
d_paradigm_OO
d_paradigm_AO
Designate Design Alternative
Figure Editor
AND
elements
OR
observer_role
subject_role
OR
v1{point, line, screen} other
policy_observing
OR
v1{Screen} other
d_paradigm
OR
v1{color} v2{color, position} other
v1{point, line} v2{point, line, screen} other
OR
OO
AO
Basic constraints
Automatically Generated ACN
1: scalar point_elements:(orig,other);
2: scalar line_elements:(orig,other);
…
13: abstract_protocol_impl = orig =>
abstract_protocol_interface = orig
&& d_mapping = orig && policy_notify = push;
d_paradigm_OO
d_paradigm_AO
An Evolution Point
Figure Editor
AND
elements
OR
observer_role
subject_role
OR
v1{point, line, screen} other
policy_observing
OR
v1{Screen} other
d_paradigm
OR
v1{color} v2{color, position} other
v1{point, line} v2{point, line, screen} other
OR
OO
AO
Basic constraints
d_paradigm_OO
d_paradigm_AO
An Evolution Point
Figure Editor
AND
elements
OR
observer_role
subject_role
OR
v1{point, line, screen} other
policy_observing
OR
v1{Screen} other
d_paradigm
OR
v1{color} v2{color, position} other
v1{point, line} v2{point, line, screen} other
OR
OO
AO
Basic constraints
d_paradigm_OO
d_paradigm_AO
Generalizability--- Galileo
(1)
(2)
A Real Situation: How to Refactor the Error Handling Part?
Verified Decision
Error Handling Option 3
Error Handling Option 4
Related Work
 Product Line Engineering
 Sinnema, Deelstra, Nijhuis, and Bosch [SDNB04]
 Lane [L90]
 Feature Oriented Programming
 Batory and O’Malley [BO92,BSR03]
 Czarnecki et al. and Eisenecker [EC00]
 Design Structure and Business Strategy
 Woodard06a
Evaluation Summary
Thesis:
Formal account of the key concepts of informal
modularity
1.
1.
2.
Baldwin and Clark's theory
Parnas's information hiding modularity
Automatic derivation of design coupling structures
2.
1.
2.
Design Structure Matrix
Other coupling Analysis
Evolvability analyses such as design impact
analysis.
General model of modularity in design is general.
3.
4.
1.
2.
Traditional object-oriented modularity
Newer aspect-oriented modularity
Evaluation Summary
Evaluation 1
1.


Formal account of the key concepts of
informal modularity

Baldwin and Clark's theory
 Parnas's information hiding modularity
Formalized Framework (Chapter 7)
Formalized Theories within the Settings
Evaluation Summary
Evaluation 2
2. Automatic derivation of design coupling structures
3. Evolvability analyses such as design impact analysis.
4. General model of modularity in design is general.

Modeling Existing Designs




Two Canonical Designs
Three Real Designs
Analyze Well-known Problems
Compare the Results

Confirm Previous Results or Reveal Errors
Future Work
 Improve Language Notation
 Direct SAT Solver
 Empirical Study
 Integrate Design with:
 Code: Combine with recovered design
 Specification: Specification provides an
environment
 Testing: Testability, Unit Testing
 Value: A Real Story
Questions?