Modularity in Design Formal Modeling Automated Analysis

Modularity in Design Formal Modeling & Automated Analysis Yuanfang Cai

Longhorn is late n “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 n “ 60 -m-lines-of-code mess of spaghetti” ---Financial Times

What we have known for decades n Low coupling, high cohesion [Constantine 1974] n Information hiding [Parnas 1972] n Open to extension, close to modification n Seek to modularize n Parallel implementation n Change Accommodation n … Success depends on designers’ intuition and experience.

What we still don’t do well n Intuition and experience do not prevent n n n unexpected dependencies modularity decay delay in bringing software to market n It remains difficult to n n n estimate the consequences of a change analyze options to accommodate a change make decisions with significant consequences

We seek for A Formal Model and Theory n Description n Why some architectures are more adaptive than others? n Prediction n What’s going to happen if the requirement changes? n Prescription n What’s the best way to accommodate a change? Shall we refactor?

We seek for n A Formal Model and Theory n General enough n n n Explicitly represent decisions n n Span language paradigm Span software lifecycle Design is a decision-making procedure [Alexander 1970] Computable Scalable Capture the essence of informal principles. We first need an analyzable design representation

Roadmap n An Emerging Approach n Design rule theory [Baldwin 2000] n Design structure matrices (DSM) n How DSM and DR explain n Augmented Constraint Network n Formal model for the basis of automation n DSM derivation and design impact analysis n Splitting formal designs n ACN in practice n Future work

“Design Rule: the Power of Modularity” [Baldwin 2000] Design Rules and Modular Operators n Modeling: Design Structure Matrix (DSM) [Steward 81, Eppinger 91] n Economic Analysis: Net Option Value (NOV) n

Design Rule Theory & Design Structure Matrices n Design Structure Matrix n n n Design Variables Dependences Proto-Modules n Design Rule Theory n n n Design rule Splitting Substitution Modules create options Net option value analysis

How DR and DSM Explain n The characteristic of a good design n Clearly defined design rules n Blocks along diagonals model modules n n No off-diagonal dependencies among blocks n n n Modules create options Informally, low-coupling Formally, splitting and substitution Small blocks n n Informally, high-cohesion Formally, more options, higher value

How DR and DSM Explain n Tomcat n Why it is successful? n What is the key enabler? n Server 2 n Why refactor? n Is the refactoring successful? n Linux and Mozilla [Mac. Cormack et al. 2006]

Tomcat n Tomcat DSM n Classes as variables n Reverse engineer dependencies n A DSM for each version. n Why it is successful? n It allows different rates of evolution in different modules n What is the key enabler?

Server 2: Before and After Refactoring

Mozilla Evolution

The Power of Description n The indicator of healthy evolution n Fewer off-diagonal dependencies among blocks n Informally, low-coupling n Formally, splitting and substitution n Smaller blocks n Informally, high-cohesion n Formally, more options, higher value n Intuitively or unconsciously, a good designer n Define design rules n Splitting n Substitution

Models at Design Level n Retrospective conclusion is not sufficient n Designers need to make decision at early stages n Changes start from requirements

First Attempt: Design DSM (A) Sequential Design (B) Information Hiding Design (B) NOV = 0. 26 NOV = 1. 56 “The Structure and Value of Modularity” [SWC 01]

First Attempt: Design DSM n General n Object-Oriented (OO), Aspect-Oriented (AO) [SGSC 05] [Lopes 05] n Generalized Information Hiding Interface n Make Information Hiding Criterion Precise n Design Rules are Invariant to Environment Change n 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 x 1 to x 2? - How many ways? -

Constraint Network 1. l 2. l 3. l Variables Design Dimensions Values Possible Choices Constraints Relations Among Decisions input_ds: {core 4, disk, core 0, other}; envr_input_size: {small, medium, large}; input_ds = disk => envr_input_size = large;

Augmented Constraint Network 1. 2. l l Constraint Network Dominance Relation Design rule Environment (input_impl, input_ADT) (input_impl, input_format) 3. Clustering Environment: {envr_input_format, envr_core, …} Design Rules: {input_ADT, circ_ADT…}

Analyzable Models 1. Constraint Network Analyses n n Design Change Impacts Precise Dependence DSM Analyses Design Automaton n n Change Dynamics Design Space Design Evolution Design. Space 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}

Design Automaton l. Design client = dense ds = array_ds alg = array_alg Impact Analysis client = sparse S 1 client = sparse S 6 ds = list_ds alg = list_alg ds = list_ds alg = other_alg client = sparse ds = other_ds client = sparse S 2 client = sparse ds = other_ds alg = other_alg S 3 client = dense ds = other_ds alg = other_alg client = dense S 5 ds = array_ds alg = other_alg S 4 client = sparse l 1. Non-deterministic; l 2. Minimal Perturbation; ds = list_ds alg = other_alg l 3. Respect Dominance Relation

Design Automaton l. Precise Definition of Pair-wise Dependence – DSM Derivation client = sparse client = dense ds = array_ds alg = array_alg client = sparse S 6 ds = list_ds alg = list_alg S 1 alg = other_alg client = sparse ds = other_ds client = sparse S 2 client = sparse ds = other_ds alg = other_alg S 3 client = dense ds = other_ds alg = other_alg client = dense S 5 ds = array_ds alg = other_alg S 4 client = sparse ds = list_ds alg = other_alg 1 2 3 1. client . x x . 2. ds 3. alg

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

KWIC Regenerated Sequential Design Information Hiding Design

Information Hiding Reformulated

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

Scalability Issue n Constraint Solving n Explicit Solution Enumeration n Our approach n 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 = core 4; 2: linestorage_ds = core 4 => envr_input_size = medium || envr_input_size = small; 3: linestorage_ds = core 0 => 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;

Construct CNF Graph (¬linestorage impl = orig linestorage ADT = orig) (¬linestorage impl = orig linestorage ds = core 4) (¬linestorage ds = core 4 envr input size = medium || envr input size = small) (¬linestorage ds = core 0 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) (1) Construct CNF Graph (¬linestorage_ds = core 0 envr input size = small) (2) Cut Edges According to Dominance Relation envr_input_size envr_core_size linestorage_ds circ_ADT linestorage_impl circ_impl linestorage_ADT

Construct Condensation Graph envr_input_size envr_core_size linestorage_ADT linestorage_ds linestorage_impl envr_input_size envr_core_size linestorage_ADT circ_ds, circ_impl envr_input_size envr_core_size linestorage_ADT linestorage_ds linestorage_impl circ_ADT circ_ds circ_impl Line Storage Function Circular Shift Function

KWIC Decomposed Information Hiding Sequential Design

1: 2: 3: 4: 5: Result Integration 1: Design Impact 2: Analysis Input 1: Original Design 3: 1: envr_input_size = 4: medium 5: 2: envr_core_size = small 3: linestorage_ADT = orig 4: linestorage_ds = core 4 5: linestorage_impl = orig Input 2: A Change 6: circ_ADT = orig 7: circ_ds = index = envr_input_size 8: circ_impl = orig large 1: 2: 3: 6: 7: 8: C 0 envr_input_si ze = large L 2 L 0 envr_input_si ze = large L 3 envr_input_si ze = large C 1 1: 2: 3: 4: 5: 1: 2: 3: 6: 7: 8: 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 1: envr_input_size = 7: circ_ds = core 4 large 8: circ_impl = orig 2: envr_core_size = small 3: linestorage_ADT = orig 4: linestorage_ds = disk 5: linestorage_impl = other 6: circ_ADT = orig

Result Integration Pair-wise Dependence Relation

Generalizability--- Winery. Locator

Generalizability--- Hyper. Cast 6 Main Functions 5 “Crosscutting” Functions No Crosscutting

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

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

Model Decisions in Requirements

Model Decisions in Design

Model Relations among Decisions at Different Stages n Model Testing Decisions n Model Dominance Relations n Model Clustering n 162 Variables in total

Vodka Design Analysis--Decomposition

Independent Responsibility Assignments

Vodka Design Analysis Results n Find not-well modularized parts n Find incomplete testing plan n An error in a sequence diagram n …

Vodka Design Analysis— Traceability and Changeability

Vodka Case Study Summary n Model decisions that span software lifecycle n Automatically split the design into independent responsibility assignments n Identify big modules that need to be further decomposed n Automatic traceability and changeability analysis n Proactively control design evolution

A Formal Model and Theory n Description n Design Structure Matrix n Prediction n Design Impact Analysis – a preliminary step n Prescription n Decision-tree Analysis

A Formal Model and Theory n General enough n n n n Span language paradigm Span software lifecycle Explicitly represent decisions Computable Scalable Capture the essence of informal principles. Analyzable design representations n Design Structure Matrix (DSM) n Augmented Constraint Network (ACN)

Future Work n Design Level Modularity vs. Source Code Modularity n Make Complex Design Decision n Further Evaluation

Questions?