modularity in design formal modeling automated analysis n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Modularity in Design Formal Modeling & Automated Analysis PowerPoint Presentation
Download Presentation
Modularity in Design Formal Modeling & Automated Analysis

Loading in 2 Seconds...

play fullscreen
1 / 53

Modularity in Design Formal Modeling & Automated Analysis - PowerPoint PPT Presentation


  • 77 Views
  • Uploaded on

Modularity in Design Formal Modeling & Automated Analysis. Yuanfang Cai. Longhorn is late. “With each patch and enhancement, it became harder to strap new features onto the software, since new code could affect everything else in unpredictable ways” --- The Wall Street Journal

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Modularity in Design Formal Modeling & Automated Analysis' - avedis


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
longhorn is late
Longhorn is late
  • “With each patch and enhancement, it became harder to strap new features onto the software, since new code could affect everything else in unpredictable ways” ---The Wall Street Journal
  • “60-m-lines-of-code mess of spaghetti”

---Financial Times

what we have known for decades
What we have known for decades
  • Low coupling, high cohesion [Constantine 1974]
  • Information hiding [Parnas 1972]
  • Open to extension, close to modification
  • Seek to modularize
    • Parallel implementation
    • Change Accommodation

Success depends on designers’ intuition and experience.

what we still don t do well
What we still don’t do well
  • Intuition and experience do not prevent
    • unexpected dependencies
    • modularity decay
    • delay in bringing software to market
  • It remains difficult to
    • estimate the consequences of a change
    • analyze options to accommodate a change
    • make decisions with significant consequences
we seek for
We seek for
  • Description
    • Why some architectures are more adaptive than others?
  • Prediction
    • What’s going to happen if the requirement changes?
  • Prescription
    • What’s the best way to accommodate a change? Shall we refactor?

A Formal Model and Theory

we seek for1
We seek for
  • A Formal Model and Theory
    • General enough
      • Span language paradigm
      • Span software lifecycle
    • Explicitly represent decisions
      • Design is a decision-making procedure [Alexander 1970]
    • Computable
    • Scalable
    • Capture the essence of informal principles.

We first need an analyzable design representation

roadmap
Roadmap
  • An Emerging Approach
    • Design rule theory [Baldwin 2000]
    • Design structure matrices (DSM)
    • How DSM and DR explain
  • Augmented Constraint Network
    • Formal model for the basis of automation
    • DSM derivation and design impact analysis
    • Splitting formal designs
    • ACN in practice
  • Future work
design rule the power of modularity baldwin 2000
“Design Rule: the Power of Modularity” [Baldwin 2000]
  • Design Rules and Modular Operators
  • Modeling: Design Structure Matrix (DSM) [Steward81,Eppinger91]
  • Economic Analysis: Net Option Value (NOV)
design rule theory design structure matrices
Design Rule Theory & Design Structure Matrices
  • Design Structure Matrix
    • Design Variables
    • Dependences
    • Proto-Modules
  • Design Rule Theory
    • Design rule
    • Splitting
    • Substitution
    • Modules create options
    • Net option value analysis
how dr and dsm explain
How DR and DSM Explain
  • The characteristic of a good design
    • Clearly defined design rules
    • Blocks along diagonals model modules
      • Modules create options
    • No off-diagonal dependencies among blocks
      • Informally, low-coupling
      • Formally, splitting and substitution
    • Small blocks
      • Informally, high-cohesion
      • Formally, more options, higher value
how dr and dsm explain1
How DR and DSM Explain
  • Tomcat
    • Why it is successful?
    • What is the key enabler?
  • Server 2
    • Why refactor?
    • Is the refactoring successful?
  • Linux and Mozilla [MacCormack et al. 2006]
tomcat
Tomcat
  • Tomcat DSM
    • Classes as variables
    • Reverse engineer dependencies
    • A DSM for each version.
  • Why it is successful?
    • It allows different rates of evolution in different modules
  • What is the key enabler?
the power of description
The Power of Description
  • The indicator of healthy evolution
    • Fewer off-diagonal dependencies among blocks
      • Informally, low-coupling
      • Formally, splitting and substitution
    • Smaller blocks
      • Informally, high-cohesion
      • Formally, more options, higher value
  • Intuitively or unconsciously, a good designer
    • Define design rules
    • Splitting
    • Substitution
models at design level
Models at Design Level
  • Retrospective conclusion is not sufficient
  • Designers need to make decision at early stages
  • Changes start from requirements
first attempt design dsm
First Attempt: Design DSM
  • Sequential Design
  • NOV = 0.26

(B) Information Hiding Design

NOV = 1.56

“The Structure and Value of Modularity” [SWC01]

first attempt design dsm1
First Attempt: Design DSM
  • General
    • Object-Oriented (OO), Aspect-Oriented (AO) [SGSC05] [Lopes05]
    • Generalized Information Hiding Interface
  • Make Information Hiding Criterion Precise
    • Design Rules are Invariant to Environment Change
  • Analyze Software Quantitatively (Net Option Value Analysis
design level dsm limitations
Design Level DSM Limitations
  • Ambiguous !!!!
  • What is “dependence?”
    • a  b  c
    • c  d  e
  • Can’t represent possible choices
    • Input Condition?
    • Core Size?
  • Design Impact Analysis?
    • What if x changes from x1 to x2?
    • How many ways?
constraint network
Constraint Network
  • Variables
    • Design Dimensions
  • Values
    • 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;

augmented constraint network
Augmented Constraint Network
  • Constraint Network
  • Dominance Relation
    • Design rule
    • Environment
  • Clustering

(input_impl, input_ADT)

(input_impl, input_format)

Environment:

{envr_input_format, envr_core,…}

Design Rules:

{input_ADT, circ_ADT…}

analyzable models

1. Constraint Network

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

Analyzable Models
  • Analyses
    • Design Change Impacts
    • Precise Dependence
    • DSM Analyses
  • Design Automaton
    • Change Dynamics
    • Design Space
    • Design Evolution
design automaton

ds = list_ds

S5

S4

S3

S6

S2

Design Automaton
  • Design Impact Analysis

client = sparse

client = dense

ds = array_ds

alg = array_alg

client = sparse

ds = list_ds

alg = list_alg

S1

alg = other_alg

client = dense

ds = array_ds

alg = other_alg

client = sparse

ds = other_ds

client = sparse

alg = other_alg

client = sparse

ds = other_ds

alg = other_alg

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

S6

S4

S3

S5

S2

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

S1

alg = other_alg

client = dense

ds = array_ds

alg = other_alg

client = sparse

ds = other_ds

client = sparse

client = sparse

ds = other_ds

alg = other_alg

client = dense

ds = other_ds

alg = other_alg

client = sparse

ds = list_ds

alg = other_alg

x

x

x

x

simon

Pair-wise Dependence

Cluster Set

Design Automaton

Derive

Dominance Relation

Constraint Network

Derive

Simon

Augmented Constraint Network

User Input

A Cluster

Modeling

Analysis

kwic regenerated
KWIC Regenerated

Sequential Design

Information Hiding Design

design impact analysis
Design Impact Analysis

(A) Sequential Design

(B) Information Hiding Design

scalability issue
Scalability Issue
  • Constraint Solving
  • Explicit Solution Enumeration
  • Our approach
    • Using design rules (dominance relation) to split logical constraints
model decomposition
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
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 graph1

envr_input_size

envr_core_size

circ_ds

linestorage_ds

circ_impl

linestorage_impl

linestorage_ADT

circ_ADT

Construct CNF Graph

(¬circ_ds = copy  envr_input_size = small  envr_core_size = large)

(¬linestorage_ds = core0  envr input size = small)

(1) Construct CNF Graph

(2) Cut Edges According to Dominance Relation

construct condensation graph

envr_input_size

envr_core_size

linestorage_ADT

circ_ADT

linestorage_ds

linestorage_impl

circ_ds

circ_impl

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

Line Storage Function

CircularShift Function

result integration

L0

C0

L2

L3

C1

Result Integration

Output

1:

2:

3:

4:

5:

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:

Design Impact Analysis

Input 1: Original Design

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

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

envr_input_size = large

result integration1
Result Integration

Pair-wise Dependence Relation

slide39

Generalizability--- HyperCast

6 Main Functions

No Crosscutting

5 “Crosscutting” Functions

slide40

Vodka Case Study

  • VODKA Organizational Device for Keeping Assets (VODKA)
    • An online financial management system for student societies on campus
    • Three-tier and service-oriented architecture
    • Follow software engineering standards
      • Requirement
      • Design
      • Implementation
      • Testing
      • Iterative Process
slide41

Modeling and Analysis

  • Decisions that span overall lifecycle
    • Standard Requirement Specification
    • Design Document
    • Testing Plan
  • Decomposition
    • Modules (Responsibility Assignments)
    • Traceability Analysis
    • Changeability Analysis
  • Proactively Control Design Evolution
slide44

Model Relations among Decisions at Different Stages

  • Model Testing Decisions
  • Model Dominance Relations
  • Model Clustering
  • 162 Variables in total
slide47

Vodka Design Analysis Results

  • Find not-well modularized parts
  • Find incomplete testing plan
  • An error in a sequence diagram
vodka case study summary
Vodka Case Study Summary
  • Model decisions that span software lifecycle
  • Automatically split the design into independent responsibility assignments
  • Identify big modules that need to be further decomposed
  • Automatic traceability and changeability analysis
  • Proactively control design evolution
a formal model and theory
A Formal Model and Theory
  • Description
    • Design Structure Matrix
  • Prediction
    • Design Impact Analysis – a preliminary step
  • Prescription
    • Decision-tree Analysis
a formal model and theory1
A Formal Model and Theory
  • General enough
    • Span language paradigm
    • Span software lifecycle
  • Explicitly represent decisions
  • Computable
  • Scalable
  • Capture the essence of informal principles.
  • Analyzable design representations
    • Design Structure Matrix (DSM)
    • Augmented Constraint Network (ACN)
future work
Future Work
  • Design Level Modularity vs. Source Code Modularity
  • Make Complex Design Decision
  • Further Evaluation