1 / 50

Modularity in Design: Formal Modeling & Automated Analysis

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.

brosado
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related