1. Modularity in Design: Formal Modeling & Automated Analysis
Yuanfang Cai

2. 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

3. Goals Ultimate Goal The Goal of this Dissertation
Rational value-oriented decision-making
Tool support
The Goal of this Dissertation
Formal analyzable design modeling framework
Prototype tool: Simon

4. 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

5. Outline Traditional Design Representations Emerging New Approach
Formal Models and Analysis Tool
Model Decomposition
Model Extension
Evaluation Summary
Future Work

6. (B) (A) Not Well Suited to Model Not Designed for
Environment condition
Implicit design decisions
Not Designed for
Design structure reasoning
Evolvability analysis
Quantitative analysis
Choose which?
“information hiding”?
“memory size”, “input size”?

7. Outline Traditional Design Representations Emerging New Approach
Formal Models and Analysis Tool
Model Decomposition
Model Extension
Evaluation Summary
Future Work

8. Emerging New Approach Design Rules
“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]

9. Design Structure Matrix (DSM)
Input
Circular Shift
Design Variables
Dependences
Design Rule
Proto-Modules
Reorder
Extension
Alphabetizing
Output
Master Control

10. Design Structure Matrix (DSM)
(B) Information Hiding Design
(A) Sequential Design

11. New Approach Summary General Represent Software Coupling Structure
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

12. 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

13. Outline Traditional Design Representations Emerging New Approach
Formal Models and Analysis Tool [CS05]
Model Decomposition
Model Extension
Evaluation Summary
Future Work

14. Constraint Network Variables Values Constraints Design Dimensions
Possible Choices
Constraints
Relations Among Decisions
input_ds:{core4,disk,core0,other};
envr_input_size:{small,medium,large};
input_ds = disk => envr_input_size = large;

15. Augmented Constraint Network
Dominance Relation
Design Rules
Environment
Clustering
(input_impl, input_ADT)
(input_impl, input_format)
Environment:
{envr_input_format, envr_core,…}
Design Rules:
{input_ADT, circ_ADT…}

16. Analyzable Models Analyses Design Automaton Design Change Impacts
2. Dominance Relation
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; }
{(ds, client), (alg, client)}
Environment Cluster: {client}
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

17. Design Impact Analysis
Design Automaton
Design Impact Analysis
client = sparse
client = dense
ds = array_ds
alg = array_alg
client = sparse
ds = list_ds
alg = list_alg S6
ds = list_ds S1
alg = other_alg
client = dense
ds = array_ds
alg = other_alg
client = sparse
ds = other_ds S5
client = sparse
alg = other_alg S2
client = sparse
ds = other_ds
alg = other_alg S3 S4
client = dense
ds = other_ds
alg = other_alg
client = sparse
ds = list_ds
alg = other_alg
1. Non-deterministic;
2. Minimal Perturbation;
3. Respect Dominance Relation

18. Precise Definition of Pair-wise Dependence – DSM Derivation
Design Automaton
Precise Definition of Pair-wise Dependence – DSM Derivation
client = sparse
client = dense
ds = array_ds
alg = array_alg
client = sparse
ds = list_ds
alg = list_alg S6 S1
alg = other_alg
client = dense
ds = array_ds
alg = other_alg
client = sparse
ds = other_ds S5
client = sparse S2
client = sparse
ds = other_ds
alg = other_alg S3 S4 1 2 3
1.client .
2.ds
3.alg
client = dense
ds = other_ds
alg = other_alg
client = sparse
ds = list_ds
alg = other_alg x x x x

19. Simon Constraint Network Dominance Relation Cluster Set
Augmented Constraint Network
Constraint Network
Dominance Relation
Cluster Set
User Input
Derive
A Cluster
Design Automaton
Derive
Pair-wise Dependence
Modeling
Analysis

20. Information Hiding Design
KWIC Regenerated
Sequential Design
Information Hiding Design

21. Design Impact Analysis
(A) Sequential Design
(B) Information Hiding Design

22. Related Work Alloy DSM Lattix—A Commercial Tool
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]

23. Scalability Issue Constraint Solving Explicit Solution Enumeration
Transition
Changes
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

24. Outline Traditional Design Representations Emerging New Approach
Formal Models and Analysis Tool
Model Decomposition [CS06]
Model Extension
Evaluation Summary
Future Work

25. 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;

26. 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)

27. Construct CNF Graph (1) Construct CNF Graph
(2) Cut Edges According to Dominance Relation
(¬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_ds
linestorage_ds
circ_ADT
linestorage_impl
circ_impl
linestorage_ADT

28. Construct Condensation Graph
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
envr_input_size
envr_core_size
linestorage_ADT
circ_ADT
linestorage_ds
circ_ds
circ_impl
linestorage_impl
Line Storage Function
Circular Shift Function

29. KWIC Decomposed
Information Hiding
Sequential Design

30. Result Integration Design Impact Analysis Output1: 2: 3: 4: 5:
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 L2
envr_input_size = large 1: 2: 3: 4: 5:
Design Impact Analysis
Input 1: Original Design L0 1: 2: 3: 4: 5:
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
envr_input_size = large L3 1: 2: 3: 6: 7: 8:
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: 2: 3: 6: 7: 8:
Input 2: A Change
envr_input_size = large C0 C1
envr_input_size = large

31. Result Integration
Pair-wise Dependence Relation

32. Generalizability--- WineryLocator

33. Generalizability--- WineryLocator [Lopes05]
(1) Missing Transitive Dependences (2) Ambiguities
(3) Potential Problems in Quantitative Analysis

34. Generalizability--- HyperCast
6 Main Functions
No Crosscutting
5 “Crosscutting” Functions

35. Generalizability--- HyperCast [SGSC05]
Missing Transitive Dependences
Potential Problems in Quantitative Analysis

36. Related Work Constraint Network Decomposition Bottom-up Clustering
Choueiry and Noubir [CN98]
Dechter and Peal [DP89]
Freuder and Hubbe [FH93]
Bottom-up Clustering
Hutchens and Basili [HB95]
Schwanke [S91]
Mancoridis [MMRC98]

37. Expressiveness Issue Role Assignment Design Pattern
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

38. Outline Traditional Design Representations Emerging New Approach
Formal Models and Analysis Tool
Model Decomposition
Model Extension
Evaluation Summary
Future Work

39. Model Extension (1) Set-Valued Variable (2) SubSpace-Valued Variable
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); …
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))

40. Designate Design Alternative
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

41. Designate Design Alternative
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

42. An Evolution Point

43. An Evolution Point

44. Generalizability--- Galileo
A Real Situation: How to Refactor the Error Handling Part?
Verified Decision
Error Handling Option 3
Error Handling Option 4

45. Related Work Product Line Engineering Feature Oriented Programming
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

46. Evaluation Summary 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

47. Evaluation Summary
Evaluation 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

48. 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

49. 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

50. Questions?