Modularity in Design Formal Modeling Automated Analysis Yuanfang

Modularity in Design: Formal Modeling & Automated Analysis Yuanfang Cai

Motivation A Real Story Designers Need to Reason l l Consequences of a Change Options to Accommodate a Change Refactor or not Architecture Adaptability Prevailing Design Representations are not Adequate

Goals l Ultimate Goal u Rational value-oriented decision-making u Tool support l The Goal of this Dissertation u Formal analyzable design modeling framework u Prototype tool: Simon

Thesis l Formal account of the key concepts of informal modularity u u Baldwin and Clark's theory Parnas's information hiding modularity l Automatic derivation of design coupling structures u u Design Structure Matrix Other coupling Analysis l Evolvability analyses such as design impact analysis. l General model of modularity in design is general. u u Traditional object-oriented modularity Newer aspect-oriented modularity

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

(A) (B) l Not Well Suited to Model Choose which? “information hiding”? “memory size”, “input size”? u u Environment condition Implicit design decisions l Not Designed for u u u Design structure reasoning Evolvability analysis Quantitative analysis

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

Emerging New Approach l “Design Rule: the Power of Modularity” [Baldwin 00] u Design Rules u Modeling: Design Structure Matrix (DSM) [Steward 81, Eppinger 91] u Economic Analysis: Net Option Value (NOV) l “The Structure and Value of Modularity” [SWC 01]

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

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

New Approach Summary l General u u Object-Oriented (OO), Aspect-Oriented (AO) [SGSC 05] Generalized Information Hiding Interface l Represent Software Coupling Structure u u Constantine, Stevens, Brooks…. Call Graph, Reflexion Model [Murphy 95], Lattix l Make Information Hiding Criterion Precise u Design Rules are Invariant to Environment Change l Analyze Software Quantitatively

DSM Limitations - 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? - Ambiguous - What is “dependence? ” - a b c - c d e - Very hard to build

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

Constraint Network Variables 1. l Design Dimensions Values 2. l Possible Choices Constraints 3. l 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 Dominance Relation 1. 2. l l Design Rules 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 l u u u Design Change Impacts Precise Dependence DSM Analyses Design Automaton l u u u 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

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

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

Related Work l Alloy u Jackson [J 06] l DSM u Mac. Cormack, Rusnak, and Baldwin [MRB 05] l Lattix—A Commercial Tool u Sangal, Jordan, Sinha, and Jackson [SJSJ 05] l Traditional Design Impact Analysis u Robert Arnold and Shawn Bohner [AB 96]

Scalability Issue Transitio n l l 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 Constraint Solving Explicit Solution Enumeration

Outline l l l l Traditional Design Representations Emerging New Approach Formal Models and Analysis Tool Model Decomposition [CS 06] 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 = 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 (1)(¬circ_ds = copy envr_input_size = small envr_core_size = large) Construct CNF Graph (2)(¬linestorage_ds = core 0 envr input size = small) 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_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 large= orig 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: 7: envr_input_size 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--- Winery. Locator [Lopes 05] (1) Missing Transitive Dependences (2) Ambiguities (3) Potential Problems in Quantitative Analysis

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

Generalizability--- Hyper. Cast [SGSC 05] (1) (2) Missing Transitive Dependences Potential Problems in Quantitative Analysis

Related Work l Constraint Network Decomposition u Choueiry and Noubir [CN 98] u Dechter and Peal [DP 89] u Freuder and Hubbe [FH 93] l Bottom-up Clustering u Hutchens and Basili [HB 95] u Schwanke [S 91] u Mancoridis [MMRC 98]

Expressiveness Issue l Role Assignment u A decision brings a Set l Design Pattern u A Decision Brings a Sub. Space l Crosscutting Decisions u Prevailing notification policy l Haneemann and Kiczales’s Analysis u Object Oriented vs. Aspect Oriented

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

Model Extension 2: set subject_role(*elements): (v 1{point, line}, v 2{point, line, screen}, other); 3: set policy_observing(orig, other): (v 1{color}, v 2{color, position}, other); (1) Set-Valued Variable … 8: subspace d_paradigm: (OO, AO); (2) Sub. Space-Valued Variable 9: d_paradigm_OO[ 10: scalar adt_observer: (orig, other); … 14: ˜subject_role = orig => adt_subject = orig && ˜policy_observing = orig; ]; (3) Crosscutting Constraints 16: d_paradigm_AO[ 17: scalar abstract_protocol_interface: (orig, other); impl : observer role • subject = orig) (adt observer = orig ^ ( policy : policy_observing • policy = orig)) … 22: ˜concrete_protocol = orig => abstract_prototcol_interface = orig && ˜subject_role = orig && ˜observer_role = orig && policy_update = orig; ];

Designate Design Alternative Automatically Generated ACN 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;

Designate Design Alternative Automatically Generated ACN 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;

An Evolution Point

An Evolution Point

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

Related Work l Product Line Engineering u Sinnema, Deelstra, Nijhuis, and Bosch [SDNB 04] u Lane [L 90] l Feature Oriented Programming u Batory and O’Malley [BO 92, BSR 03] u Czarnecki et al. and Eisenecker [EC 00] l Design Structure and Business Strategy u Woodard 06 a

Evaluation Summary Thesis: Formal account of the key concepts of informal modularity 1. 1. 2. Baldwin and Clark's theory Parnas's information hiding modularity Automatic derivation of design coupling structures 2. 1. 2. Design Structure Matrix Other coupling Analysis Evolvability analyses such as design impact analysis. General model of modularity in design is general. 3. 4. 1. 2. Traditional object-oriented modularity Newer aspect-oriented modularity

Evaluation Summary Evaluation 1 1. l l Formal account of the key concepts of informal modularity l Baldwin and Clark's theory u 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. l Modeling Existing Designs u u l l Two Canonical Designs Three Real Designs Analyze Well-known Problems Compare the Results u Confirm Previous Results or Reveal Errors

Future Work l Improve Language Notation l Direct SAT Solver l Empirical Study l Integrate Design with: u Code: Combine with recovered design u Specification: Specification provides an environment u Testing: Testability, Unit Testing u Value: A Real Story

Questions?