Yuanfang Cai
Modularity in Design:Formal Modeling & Automated Analysis
Motivation
A Real Story
Consequences of a Change Options to Accommodate a Change Refactor or not Architecture Adaptability
Designers Need to Reason
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
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
Thesis
Outline
Traditional Design Representations Emerging New Approach Formal Models and Analysis Tool Model Decomposition Model Extension Evaluation Summary Future Work
(A) (B)
Choose which? “information hiding”?“memory size”, “input size”?
Not Well Suited to Model 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]
A B C D E F G H I J K L M
A - In Sig . X X
B - In Data X . X X X X X XC - In Impl X X .
D - Circ Sig . X X
E - Circ Data X X . X X XF - Circ Impl X X X .
G - Alph Sig . X X
H - Alph Data X X X . X XI - Alph Impl X X X X .
J - Out Sig . X X
K - Out Data X . XL - Out Impl X X X X .M - Master X X X X .
Design Variables Dependences Design Rule Proto-Modules Reorder Extension
Design Structure Matrix (DSM)Input Circular Shift
OutputAlphabetizing Master Control
X Y Z A D G J B E H K C F I L M
X - Computer .
Y - Corpus X . X
Z - User X .
A - In Type .
D - Circ Type .
G - Alph Type .
J - Out Type .
B -In Data X X . X X
E - Circ Data X X X . X
H - Alph Data X X X X .
K - Out Data X X .
C - In Alg X X X X .
F - Circ Alg X X X X X .
I - Alph Alg X X X X X X X .
L - Out Alg X X X X X X .
M - Master X X X X X .
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 X . X
P - Line Alg X X X X .
B - Input Data X X X . X
C - Input Alg X X X X X .
E - Circ Data X X X X . X
F - Circ Alg X X X X X .
H - Alph Data X X X X . X
I - Alph Alg X X X X X X .
K - Out Data X X X . X
L - Out Alg X X X X X .
M - Master X X X X X X .
Design Structure Matrix (DSM)
(A) Sequential Design(B) Information Hiding Design
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 X X .
K - Out Data .
C - Input Impl X X .
F - Circ Impl X X X .
I - Alph Impl X X X X .
L - Out Impl X X X X .
M - Master Impl 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
1. Variables Design Dimensions
2. Values Possible Choices
3. Constraints Relations Among Decisions
Constraint Network
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 X . X
P - Line Alg X X X X .
B - Input Data X X X . X
C - Input Alg X X X X X .
E - Circ Data X X X X . X
F - Circ Alg X X X X X .
H - Alph Data X X X X . X
I - Alph Alg X X X X X X .
K - Out Data X X X . X
L - Out Alg X X X X X .
M - Master X X X X X X .
1. Constraint Network2. Dominance Relation
Design Rules Environment
3. Clustering
Augmented Constraint Network
(input_impl, input_ADT)(input_impl, input_format)
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 X . X
P - Line Alg X X X X .
B - Input Data X X X . X
C - Input Alg X X X X X .
E - Circ Data X X X X . X
F - Circ Alg X X X X X .
H - Alph Data X X X X . X
I - Alph Alg X X X X X X .
K - Out Data X X X . X
L - Out Alg X X X X X .
M - Master X X X X X X .
Environment: {envr_input_format, envr_core,…}Design Rules: {input_ADT, circ_ADT…}
Analyzable Models
2. Dominance Relation
DesignSpace matrix{DesignSpace matrix{client:{dense, sparse};client:{dense, sparse};ds:{list_ds, array_ds, other_ds};ds:{list_ds, array_ds, other_ds};alg:{array_alg, list_alg, other_alg};alg:{array_alg, list_alg, other_alg};ds = array_ds => client = dense;ds = array_ds => client = dense;ds = list_ds => client = sparse;ds = list_ds => client = sparse;alg = array_alg => ds = array_ds;alg = array_alg => ds = array_ds;alg = list_alg => ds = list_ds;alg = list_alg => ds = list_ds;
}}
{(ds, client), (alg, client)}{(ds, client), (alg, client)}
Environment Cluster: {client}Environment Cluster: {client}Design Cluster: {ds, alg}Design Cluster: {ds, alg}
1. Constraint Network
3. Clustering
Analyses Design Change Impacts Precise Dependence DSM Analyses
Design Automaton Change Dynamics Design Space Design Evolution
Design Automaton
client = denseds = array_dsalg = array_alg
client = sparseds = list_dsalg = list_alg
client = denseds = array_dsalg = other_alg
client = sparseds = list_dsalg = other_alg
client = denseds = other_dsalg = other_alg
client = sparseds = other_dsalg = other_alg
S1
S2
client = sparse
client = sparsealg = other_alg
client = sparseds = other_ds
1. Non-deterministic; 2. Minimal Perturbation;3. Respect Dominance Relation
ds = list_ds
alg = other_alg
S3 S4
S5
S6
Design Impact Analysis
Design Automaton
client = denseds = array_dsalg = array_alg
client = sparseds = list_dsalg = list_alg
client = denseds = array_dsalg = other_alg
client = sparseds = list_dsalg = other_alg
client = denseds = other_dsalg = other_alg
client = sparseds = other_dsalg = other_alg
S1
S2
client = sparse
client = sparsealg = other_alg
client = sparse
ds = other_ds
Precise Definition of Pair-wise Dependence – DSM Derivation
1 2 3
1.client .
2.ds .
3.alg .
xx
xxxx
xx
S3 S4
S5
S6
Simon
Design Impact Analysis
Design Structure Matrices
Net Option Value
Other DSM Analyses: scheduling, cycle detection...
Design Automaton
Cluster SetDominance Relation
Constraint Network
Pair-wise Dependence
Augmented Constraint Network
Modeling
Analysis
User Input
Derive
Derive
A C
luster
KWIC Regenerated
Sequential Design Information Hiding Design
S179
S555
S558
S102
S19
C4
C5
C1C2
C3 S18
input_impl
C1 envr_input_format = new 1 1C2 envr_input_size = large 7 2C3 envr_input_size = small 0 0C4 envr_alph_policy = partial 3 2C5 envr_alph_policy = search 3 2
alph_dsalph_imploutput_impl
alph_dsalph_imploutput_impl
input_dsalph_dscirc_dsinput_implcirc_implalph_imploutput_impl
S155
S2476S1284
S75
S1535
C4
C5
C1
C2C3
S1034
input_impl
alph_dsalph_impl
alph_dsalph_impl
linestorage_dslinestorage_impl
(b) KWIC IH DA(a) KWIC SD DA
S865
C2
Design Impact Analysis
(A) Sequential Design (B) Information Hiding Design
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
Constraint Solving Explicit Solution Enumeration
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
Outline
Traditional Design Representations Emerging New Approach Formal Models and Analysis Tool Model Decomposition [CS06] Model Extension Evaluation Summary Future Work
Model Decomposition
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;
(1) Construct CNF Graph (2) Cut Edges According to Dominance Relation(3) Create Condensation Graph(4) Compose Sub-ACN
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(¬circ_ds = copy envr_input_size = small envr_core_size = large)
(¬linestorage_ds = core0 envr input size = small)
envr_input_size envr_core_size
circ_dslinestorage_ds
circ_impllinestorage_impl
linestorage_ADT
circ_ADT
(1) Construct CNF Graph (2) Cut Edges According to Dominance Relation
Construct Condensation Graphenvr_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
circ_ADTlinestorage_ds
linestorage_impl circ_ds
circ_impl
Line Storage Function Circular Shift Function
KWIC Decomposed
Information Hiding
Sequential Design
Result Integration
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
L0
L2
L3
C0 C1
1:
2:
3:
6:
7:
8:
1:
2:
3:
4:
5:
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
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
envr_input_size = large
1:
2:
3:
4:
5:
1:
2:
3:
4:
5:
1:
2:
3:
6:
7:
8:
Design Impact Analysis
envr_input_size = large
envr_input_size = large
Input 1: Original Design
Input 2: A Change
envr_input_size = large
Output
Result Integration
Pair-wise Dependence Relation
Generalizability--- WineryLocator
Generalizability--- WineryLocator [Lopes05]
(1) Missing Transitive Dependences (2) Ambiguities(3) Potential Problems in Quantitative Analysis
6 Main Functions
5 “Crosscutting” Functions
No Crosscutting
Generalizability--- HyperCast
(1) Missing Transitive Dependences (2) Potential Problems in Quantitative Analysis
Generalizability--- HyperCast [SGSC05]
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]
+getX():int()+getY():int()+getColor():Color()+setX(int)()+setY(int)()+setColor(Color)()
-x: int-y: int-c: color
Point: Subject
+addObserver(Observer)()+removeObserver(Observer)()+notify()()
<<interface>>Subject
+getP1():Point()+getP2():Point()+getColor():Color()+setP1(Point)()+setP1(Point)()+setColor(Color)()
-p1:Point-p2:Point-c:Color
Line:Subject
+update()-display:StringScreen:Observer
+update()
<<interface>>Observer
Expressiveness Issue
Role Assignment A decision brings a Set
Design Pattern A Decision Brings a SubSpace
Crosscutting Decisions Prevailing notification policy
Haneemann and Kiczales’s Analysis Object Oriented vs. Aspect Oriented
Outline
Traditional Design Representations Emerging New Approach Formal Models and Analysis Tool Model Decomposition Model Extension Evaluation Summary Future Work
Model Extension2: set subject_role(*elements):(v1{point, line}, v2{point, line, screen}, other);
3: set policy_observing(orig, other):
(v1{color}, v2{color, position}, other);
…
8: subspace d_paradigm: (OO, AO);
9: d_paradigm_OO[
10: scalar adt_observer:(orig, other);
…
14: ˜subject_role = orig => adt_subject = orig && ˜policy_observing = orig; ];
16: d_paradigm_AO[
17: scalar abstract_protocol_interface:(orig, other);
…
22: ˜concrete_protocol = orig => abstract_prototcol_interface = orig
&& ˜subject_role = orig && ˜observer_role = orig && policy_update = orig;];
(1) Set-Valued Variable
(2) SubSpace-Valued Variable
(3) Crosscutting Constraints
impl : observer role • subject = orig)(adt observer = orig ^ ( policy :policy_observing • policy = orig))
Designate Design AlternativeFigure Editor
elementssubject_role policy_observing
observer_role
d_paradigmv1{point, line, screen} other
AND
d_paradigm_OO
OR
OR
Basic constraints
v1{Screen} other
OR
v1{point, line} v2{point, line, screen} other
OR
v1{color} v2{color, position} other OR
OOAO
d_paradigm_AO
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;
Automatically Generated ACN
Designate Design AlternativeFigure Editor
elementssubject_role policy_observing
observer_role
d_paradigmv1{point, line, screen} other
AND
d_paradigm_OO
OR
OR
Basic constraints
v1{Screen} other
OR
v1{point, line} v2{point, line, screen} other
OR
v1{color} v2{color, position} other OR
OOAO
d_paradigm_AO
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;
Automatically Generated ACN
An Evolution PointFigure Editor
elementssubject_role policy_observing
observer_role
d_paradigmv1{point, line, screen} other
AND
d_paradigm_OO
OR
OR
Basic constraints
v1{Screen} other
OR
v1{point, line} v2{point, line, screen} other
OR
v1{color} v2{color, position} other OR
OOAO
d_paradigm_AO
An Evolution PointFigure Editor
elementssubject_role policy_observing
observer_role
d_paradigmv1{point, line, screen} other
AND
d_paradigm_OO
OR
OR
Basic constraints
v1{Screen} other
OR
v1{point, line} v2{point, line, screen} other
OR
v1{color} v2{color, position} other OR
OOAO
d_paradigm_AO
Generalizability--- Galileo
(1) A Real Situation: How to Refactor the Error Handling Part?(2) 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
1. Formal account of the key concepts of informal modularity
1. Baldwin and Clark's theory2. Parnas's information hiding modularity
2. Automatic derivation of design coupling structures1. Design Structure Matrix2. Other coupling Analysis
3. Evolvability analyses such as design impact analysis.
4. General model of modularity in design is general.1. Traditional object-oriented modularity 2. Newer aspect-oriented modularity
Evaluation Summary
Thesis:
1. Formal account of the key concepts of informal modularity
Baldwin and Clark's theory Parnas's information hiding modularity
Evaluation Summary
Evaluation 1
Formalized Framework (Chapter 7) Formalized Theories within the Settings
Evaluation Summary
Evaluation 2
2. Automatic derivation of design coupling structures3. 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 NotationDirect SAT SolverEmpirical StudyIntegrate Design with:
Code: Combine with recovered design Specification: Specification provides an
environment Testing: Testability, Unit Testing Value: A Real Story
Questions?
Top Related