Modularity in Design: Formal Modeling & Automated Analysis

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


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


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

Y - Corpus X . X

Z - User X .

N - Line Type .

A - In Type .

D - Circ Type .

G - Alph Type .

J - Out Type .












1. Constraint Network2. Dominance Relation

Design Rules Environment

3. Clustering

Augmented Constraint Network

(input_impl, input_ADT)(input_impl, input_format)


X - Computer .

Y - Corpus X . X

Z - User X .

N - Line Type .

A - In Type .

D - Circ Type .

G - Alph Type .

J - Out Type .












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


(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



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



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:




Input 1: Original Design

Input 2: A Change


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


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


observer_role


AND

d_paradigm_OO

OR

OR

Basic constraints

v1{Screen} other

OR


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


observer_role


AND

d_paradigm_OO

OR

OR

Basic constraints

v1{Screen} other

OR


OR


OOAO

d_paradigm_AO

An Evolution PointFigure Editor


observer_role


AND

d_paradigm_OO

OR

OR

Basic constraints

v1{Screen} other

OR


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?

Documents

Modularity in Design: Formal Modeling & Automated Analysis