A Formal Model for Assessing Software Architecture and Predicting Coordination Requirements

1. A Formal Model for Assessing Software Architecture and Predicting Coordination Requirements Yuanfang Cai, Sunny Wong, KanwarpreetSethi, Yuan Duan

3. Architecture, Process, Coordination • Team Organization • Task Assignment • Change Management • … Organization Architecture Process

4. Fundamental Design Theories • Information Hiding [Parnas 1972] • Design Rule Theory [Baldwin and Clark 2000] • Can we make theories operable?

5. Do we have to dig into Source Code? • Empirical Studies Apache Tomcat vs. a Proprietary Software [wicsa 2008]

6. Do we have to dig into Source Code? • Making decisions • Which language paradigm is better: OO or AO? • What else are going to change if one part changes? • How to assign tasks to maximize concurrency in large-scale, globally distributed projects? • Can we predict before coding?

7. Fundamental Questions • What is a “Module”? • What does it mean by “Dependence”? • Syntax Dependency? • Logic Dependency? • Are these dependency sufficient for prediction? • What is the basic unit of dependency?

8. Our Goal A Formal Model and Theory • 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? • Bridges Architecture with Process, Organizational Structure, and Economic Analysis

9. Research In My Lab • A formal model: Augmented Constraint Network • Model decisions as first-class members • Model assumption relations as logical constraints • A formal definition of Pair-wise Dependency • The automatic generation of Design Structure Matrix

10. 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} Augmented Constraint Network

11. S6 S4 S3 S5 S2 Precise Definition of Pair-wise Dependence And 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 = sparse ds = list_ds alg = other_alg x x client = dense ds = other_ds alg = other_alg x x

12. Challenges • How to make this formal model scalable? • Divide and Conquer [ASE 2006] • Binary ACN (BACN, Sunny Wong) • How to derive “Decisions”? • Transform UML Class Diagram to ACNs (Sunny Wong) • Transform UML Component Diagram to ACNs (KP Sethi)

13. Divide and Conquer

14. Transforming UML to ACN

15. ACN-based Assumption Dependencies • A lot more than pure syntactical dependencies • Apache Ant • Lattix dependencies: 829 • ACN dependencies: 2929 • Maze Game: • Lattix Dependencies: 34 • ACN Dependencies: 71 • Much fewer than transitive closure. • Do these extra dependencies produce better prediction?

16. What we can do So Far • Suggest Task Assignments to Maximize Parallelism • Design Rule Hierarchy • New Stability and Modularity Metrics • Decision Volatility Metrics • Concern Diffusion Metrics • Independence Level Metrics • Predict Change impact

17. Design Rule Hierarchy:How to assign Tasks to Maximize Currency

19. Design Rule Hierarchy

20. Apache Ant Case Study • The Architecture • Version 1.6.5, 1000 variables and 4000 constraints, 13000 dependences in DSM • Derived 500 classes and interfaces (including inner classes) • 640 modules • 11 layers • The Coordination • Same Layer Different Module • Same Layer Same Module • Different Layer Dependent Module

21. Metrics: Stability and Modularity

22. Modularity and Stability Metrics • Which architecture will generate more options? • Independence Level Metrics • Which system/part of the systems is most unstable? • Decision Volatility Metrics • Design Volatility Metrics • How concerns are separated? • Concern Diffusion Metrics

24. Modularity Metric: Independency Level

25. Case Study: 8 Versions of a Product Line

26. Case Study: 8 Versions of a Product Line

27. Does Adding One Component means adding one Module?

28. Conclusion • We reached highly consistent conclusions with source-code analysis • Several source code level analysis results are less accurate • It is possible to assess stability and modularity from architecture level.

29. Predicting Change Impact

30. State-of-the Art • Prediction from History • What if : • The project is relatively new • The version history does not exist • The system is refactored

31. ACN-based Prediction • Pure ACN Prediction • The more subsystem involved, the more likely to be affected • The higher the level in the hierarchy, the less likely to be affected • The distance also matters. • Hybrid Prediction • Combining ACN prediction and Version History

32. A Case Study –Hadoop

33. A Case Study –Hadoop

34. A Case Study –Hadoop

35. Design Issues Discovered • Is it ok if design rules are constantly violated? • We found: “Modification task #51, in version 0.1.0, describes changing the DistributedFileSystem class but not only is its parent class FileSystem impacted, another child of the FileSystem (LocalFileSystem) is also impacted. The FileSystem class is changed 47% of the time DistributedFileSystem is changed and the LocalFileSystem class is changed 37% of the time DistributedFileSystem is changed, yet there are no syntactic dependencies between DistributedFileSystem and LocalFileSystem. “ • DistributedFileSystem deprecated in v.19.0

36. Design Issues Discovered • “Modification task #1127 in version 12 is titled “Speculative execution and output of Reduce tasks” and it describes a change to the ReduceTask class (and only this class). When we examine the solution for this modification task, it also includes changes to the Task class, which is the parent class of the ReduceTask class. In fact, the Task class is one of the classes most often changed with the Reduce-Task class; by release 0.14.0, the the Task class is changed in the same transaction as the ReduceTask class nearly 40% of the time.” • Task class is also refactored in v.19.0

37. Conclusion • The ACN/Hybrid Approach works better in early versions. • The ACN approach helps identify refactoring candidates. • Hybrid Approach generates reliable predictions

38. Future Work • Application to on-going projects • Linking decisions with decision-makers to predict coordination needs. • Extending change impact analysis to coordination change impact analysis. • Linking formal mode with economic analysis.