Modularity in Design Formal Modeling & Automated Analysis

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?

14. Server 2: Before and After Refactoring

15. Mozilla Evolution

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

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

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

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

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

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

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

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

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

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

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

27. KWIC Regenerated Sequential Design Information Hiding Design

28. Information Hiding Reformulated

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

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

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

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

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

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

35. Sequential Design KWIC Decomposed Information Hiding

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

37. Result Integration Pair-wise Dependence Relation

38. Generalizability--- WineryLocator

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

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

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

42. Model Decisions in Requirements

43. Model Decisions in Design

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

45. Vodka Design Analysis--Decomposition

46. Independent Responsibility Assignments

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

48. Vodka Design Analysis—Traceability and Changeability

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

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