Modularity in Design: Formal Modeling & Automated Analysis Yuanfang Cai

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

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

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

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

(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”?

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

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]

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

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

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

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

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

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;

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

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

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

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

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

Information Hiding Design KWIC Regenerated Sequential Design Information Hiding Design

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

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]

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

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

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)

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

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

KWIC Decomposed Information Hiding Sequential Design

Result Integration Design Impact Analysis Output 1: 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

Result Integration Pair-wise Dependence Relation

Generalizability--- WineryLocator

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

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

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

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]

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

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

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

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

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

An Evolution Point

An Evolution Point

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

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

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

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

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

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

Questions?