1. Modularity in Design Formal 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. 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 seek for 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 Structure Matrix Design Variables Dependences Proto-Modules Design Rule Theory & Design Structure Matrices 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 (A)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 x 1 to x 2 ?  How many ways?

21. 1. Variables Design Dimensions 2. Values Possible Choices 3. Constraints Relations Among Decisions Constraint Network input_ds:{core4,disk,core0,other}; envr_input_size:{small,medium,large}; input_ds = disk => envr_input_size = large;

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

23. Analyzable Models 2. Dominance Relation 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; } {(ds, client), (alg, client)} Environment Cluster: {client} Design Cluster: {ds, alg} 1. Constraint Network 3. Clustering Analyses Design Change Impacts Precise Dependence DSM Analyses Design Automaton Change Dynamics Design Space Design Evolution

24. Design Automaton client = dense ds = array_ds alg = array_alg client = sparse ds = list_ds alg = list_alg client = dense ds = array_ds alg = other_alg client = sparse ds = list_ds alg = other_alg client = dense ds = other_ds alg = other_alg client = sparse ds = other_ds alg = other_alg S1S1 S2S2 client = sparse alg = other_alg client = sparse ds = other_ds 1. Non-deterministic; 2. Minimal Perturbation; 3. Respect Dominance Relation ds = list_ds alg = other_alg S3S3 S4S4 S5S5 S6S6 Design Impact Analysis

25. Design Automaton client = dense ds = array_ds alg = array_alg client = sparse ds = list_ds alg = list_alg client = dense ds = array_ds alg = other_alg client = sparse ds = list_ds alg = other_alg client = dense ds = other_ds alg = other_alg client = sparse ds = other_ds alg = other_alg S1S1 S2S2 client = sparse alg = other_alg client = sparse ds = other_ds Precise Definition of Pair-wise Dependence – DSM Derivation 123 1.client. 2.ds. 3.alg. x x x x S3S3 S4S4 S5S5 S6S6

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

27. KWIC Regenerated Sequential DesignInformation 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: 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; (1) Construct CNF Graph (2) Cut Edges According to Dominance Relation (3) Create Condensation Graph (4) Compose Sub-ACN

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. Construct CNF Graph (¬circ_ds = copy  envr_input_size = small  envr_core_size = large) (¬linestorage_ds = core0  envr input size = small) envr_input_sizeenvr_core_size circ_ds linestorage_ds circ_impllinestorage_impl linestorage_ADT circ_ADT (1) Construct CNF Graph (2) Cut Edges According to Dominance Relation

34. Construct Condensation Graph envr_input_size envr_core_size linestorage_ADT linestorage_ds linestorage_impl envr_input_size envr_core_size linestorage_ADT circ_ADT circ_ds, circ_impl envr_input_size envr_core_size linestorage_ADT circ_ADT linestorage_ds linestorage_impl circ_ds circ_impl Line Storage FunctionCircular Shift Function

35. KWIC Decomposed Information Hiding Sequential Design

36. Result Integration 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 L0 L2L3 C0 C1 1: 2: 3: 6: 7: 8: 1: 2: 3: 4: 5: 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: 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: 1: 2: 3: 4: 5: 1: 2: 3: 6: 7: 8: Design Impact Analysis envr_input_size = large Input 1: Original Design Input 2: A Change envr_input_size = large Output

37. Result Integration Pair-wise Dependence Relation

38. Generalizability--- WineryLocator

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

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. Find not-well modularized parts Find incomplete testing plan An error in a sequence diagram … Vodka Design Analysis Results

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

51. General enough Span language paradigm Span software lifecycle Explicitly represent decisions Computable Scalable Capture the essence of informal principles. Analyzable design representations Design Structure Matrix (DSM) Augmented Constraint Network (ACN) A Formal Model and Theory

52. Future Work Design Level Modularity vs. Source Code Modularity Make Complex Design Decision Further Evaluation

53. Questions?