Modularity in Design: Formal Modeling & Automated Analysis

1. Modularity in Design:Formal Modeling & Automated Analysis Yuanfang Cai

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

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

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

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

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

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

8. Emerging New Approach • “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]

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

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

11. New Approach Summary • General • 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

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

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

14. 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;

15. Augmented Constraint Network • 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…}

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

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

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

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

20. KWIC Regenerated Sequential Design Information Hiding Design

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

22. Related Work • Alloy • 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]

23. Scalability Issue • Constraint Solving • Explicit Solution Enumeration

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

25. 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;

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

27. envr_input_size envr_core_size circ_ds linestorage_ds circ_impl linestorage_impl linestorage_ADT circ_ADT 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)

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

29. Sequential Design KWIC Decomposed Information Hiding

30. L0 C0 L2 L3 C1 Output 1: 2: 3: 4: 5: Result Integration 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

31. Result Integration Pair-wise Dependence Relation

32. Generalizability--- WineryLocator

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

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

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

36. Related Work • Constraint Network Decomposition • Choueiry and Noubir [CN98] • Dechter and Peal [DP89] • Freuder and Hubbe [FH93] • Bottom-up Clustering • Hutchens and Basili [HB95] • Schwanke [S91] • Mancoridis [MMRC98]

37. Expressiveness Issue • Role Assignment • 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

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

39. Model Extension 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))

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

41. 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; Designate Design Alternative

42. An Evolution Point

43. An Evolution Point

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

45. Related Work • Product Line Engineering • 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

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

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

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

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

50. Questions?