A FORMAL MODEL FOR ASSESSING SOFTWARE ARCHITECTURE AND

A FORMAL MODEL FOR ASSESSING SOFTWARE ARCHITECTURE AND PREDICTING COORDINATION REQUIREMENTS Yuanfang Cai, Sunny Wong, Kanwarpreet Sethi, Yuan Duan

ARCHITECTURE, PROCESS, COORDINATION Team Organization Task Assignment Change Management … Organization Architecture Process

FUNDAMENTAL DESIGN THEORIES Information Hiding [Parnas 1972] Design Rule Theory [Baldwin and Clark 2000] Can we make theories operable?

DO WE HAVE TO DIG INTOSOURCE CODE? Empirical Studies APACHE TOMCAT VS. A PROPRIETARY SOFTWARE [WICSA 2008]

DO WE HAVE TO DIG INTOSOURCE 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?

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?

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

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

AUGMENTED CONSTRAINT NETWORK 1. Constraint Network Design. Space 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}

Precise Definition of Pair-wise Dependence And DSM Derivation client = dense ds = array_ds alg = array_alg client = sparse S 6 ds = list_ds alg = list_alg S 1 alg = other_alg client = sparse ds = other_ds client = sparse S 2 client = sparse ds = other_ds alg = other_alg client = dense S 5 ds = array_ds alg = other_alg S 4 S 3 client = dense ds = other_ds alg = other_alg client = sparse ds = list_ds alg = other_alg 1 1. client 2. ds 3. alg 2 3 . x x

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)

DIVIDE AND CONQUER

TRANSFORMING UML TOACN

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?

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

DESIGN RULE HIERARCHY: HOW TO ASSIGN TASKS TO MAXIMIZE CURRENCY

DESIGN RULE HIERARCHY

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

METRICS: STABILITY AND MODULARITY

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

MODULARITY METRIC: INDEPENDENCY LEVEL

CASE STUDY: 8 VERSIONS OF A PRODUCT LINE

CASE STUDY: 8 VERSIONS OF A PRODUCT LINE

DOES ADDING ONE COMPONENT MEANS ADDING ONE MODULE?

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.

PREDICTING CHANGE IMPACT

STATE-OF-THE ART Prediction from History What if : � The project is relatively new � The version history does not exist � The system is refactored

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

A CASE STUDY –HADOOP

A CASE STUDY –HADOOP

A CASE STUDY –HADOOP

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 Distributed. File. System class but not only is its parent class File. System impacted, another child of the File. System (Local. File. System) is also impacted. The File. System class is changed 47% of the time Distributed. File. System is changed and the Local. File. System class is changed 37% of the time Distributed. File. System is changed, yet there are no syntactic dependencies between Distributed. File. System and Local. File. System. “ Distributed. File. System deprecated in v. 19. 0

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 Reduce. Task 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 Reduce. Task 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 Task class is changed in the same transaction as the Reduce. Task class nearly 40% of the time. ” Task class is also refactored in v. 19. 0

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

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.