Loading in 2 Seconds...

Modularity in Design Formal Modeling & Automated Analysis

Loading in 2 Seconds...

- 78 Views
- Uploaded on

Download Presentation
## Modularity in Design Formal Modeling & Automated Analysis

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

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

- 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

- 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

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

- 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 Rules and Modular Operators
- Modeling: Design Structure Matrix (DSM) [Steward81,Eppinger91]
- Economic Analysis: Net Option Value (NOV)

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

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

- Retrospective conclusion is not sufficient
- Designers need to make decision at early stages
- Changes start from requirements

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

- 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

- 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

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

- 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

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

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

Cluster Set

Design Automaton

Derive

Dominance Relation

Constraint Network

Derive

SimonAugmented Constraint Network

User Input

A Cluster

Modeling

Analysis

Scalability Issue

- Constraint Solving
- Explicit Solution Enumeration
- Our approach
- Using design rules (dominance relation) to split logical constraints

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)

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

envr_core_size

linestorage_ADT

circ_ADT

linestorage_ds

linestorage_impl

circ_ds

circ_impl

Construct Condensation Graphenvr_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

C0

L2

L3

C1

Result IntegrationOutput

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 Integration

Pair-wise Dependence Relation

- 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

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

Model Relations among Decisions at Different Stages

- Model Testing Decisions
- Model Dominance Relations
- Model Clustering
- 162 Variables in total

- Find not-well modularized parts
- Find incomplete testing plan
- An error in a sequence diagram
- …

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

- Description
- Design Structure Matrix
- Prediction
- Design Impact Analysis – a preliminary step
- Prescription
- Decision-tree Analysis

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

- Design Level Modularity vs. Source Code Modularity
- Make Complex Design Decision
- Further Evaluation

Download Presentation

Connecting to Server..