1 / 53

Modularity in Design Formal Modeling & Automated Analysis

Modularity in Design Formal Modeling & Automated Analysis. Yuanfang Cai. Longhorn is late. “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

avedis
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 DesignFormal Modeling & Automated Analysis Yuanfang Cai

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

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

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

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

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

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

  8. “Design Rule: the Power of Modularity” [Baldwin 2000] • Design Rules and Modular Operators • Modeling: Design Structure Matrix (DSM) [Steward81,Eppinger91] • Economic Analysis: Net Option Value (NOV)

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

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

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

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

  13. Server 2: Before and After Refactoring

  14. Mozilla Evolution

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

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

  17. First Attempt: Design DSM • Sequential Design • NOV = 0.26 (B) Information Hiding Design NOV = 1.56 “The Structure and Value of Modularity” [SWC01]

  18. First Attempt: Design DSM • General • Object-Oriented (OO), Aspect-Oriented (AO) [SGSC05] [Lopes05] • Generalized Information Hiding Interface • Make Information Hiding Criterion Precise • Design Rules are Invariant to Environment Change • Analyze Software Quantitatively (Net Option Value Analysis

  19. 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 x1 to x2? • How many ways?

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

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

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

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

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

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

  26. KWIC Regenerated Sequential Design Information Hiding Design

  27. Information Hiding Reformulated

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

  29. Scalability Issue • Constraint Solving • Explicit Solution Enumeration • Our approach • Using design rules (dominance relation) to split logical constraints

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

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

  32. envr_input_size envr_core_size circ_ds linestorage_ds circ_impl linestorage_impl linestorage_ADT circ_ADT Construct CNF Graph (¬circ_ds = copy  envr_input_size = small  envr_core_size = large) (¬linestorage_ds = core0  envr input size = small) (1) Construct CNF Graph (2) Cut Edges According to Dominance Relation

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

  34. Sequential Design KWIC Decomposed Information Hiding

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

  36. Result Integration Pair-wise Dependence Relation

  37. Generalizability--- WineryLocator

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

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

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

  41. Model Decisions in Requirements

  42. Model Decisions in Design

  43. Model Relations among Decisions at Different Stages • Model Testing Decisions • Model Dominance Relations • Model Clustering • 162 Variables in total

  44. Vodka Design Analysis--Decomposition

  45. Independent Responsibility Assignments

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

  47. Vodka Design Analysis—Traceability and Changeability

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

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

More Related