A F ORMAL M ODEL FOR A SSESSING S OFTWARE A RCHITECTURE AND P REDICTING C OORDINATION R EQUIREMENTS Yuanfang Cai, Sunny Wong, Kanwarpreet Sethi, Yuan Duan

A RCHITECTURE, P ROCESS, C OORDINATION Team Organization Task Assignment Change Management … Process Architecture Organization

F UNDAMENTAL D ESIGN T HEORIES Information Hiding [Parnas 1972] Design Rule Theory [Baldwin and Clark 2000] Can we make theories operable?

D O WE HAVE TO DIG INTO S OURCE C ODE ? Empirical Studies A PACHE T OMCAT VS. A P ROPRIETARY S OFTWARE [ WICSA 2008]

D O WE HAVE TO DIG INTO S OURCE C ODE ? 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?

F UNDAMENTAL Q UESTIONS 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?

O UR G OAL 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 A Formal Model and Theory

R ESEARCH I N M Y L AB 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

A UGMENTED C ONSTRAINT N ETWORK 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

123 1.client. 2.ds. 3.alg. 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 And DSM Derivation x x x x S3S3 S4S4 S5S5 S6S6

C HALLENGES 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)

D IVIDE AND C ONQUER

T RANSFORMING UML TO ACN

ACN- BASED A SSUMPTION D EPENDENCIES 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?

W HAT WE CAN DO S O F AR 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

D ESIGN R ULE H IERARCHY : H OW TO ASSIGN T ASKS TO M AXIMIZE C URRENCY

D ESIGN R ULE H IERARCHY

A PACHE A NT C ASE S TUDY The Architecture Version 1.6.5, 1000 variables and 4000 constraints, 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

M ETRICS : S TABILITY AND M ODULARITY

M ODULARITY AND S TABILITY M ETRICS 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

M ODULARITY M ETRIC : I NDEPENDENCY L EVEL

C ASE S TUDY : 8 V ERSIONS OF A P RODUCT L INE

D OES A DDING O NE C OMPONENT MEANS ADDING ONE M ODULE ?

C ONCLUSION 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.

P REDICTING C HANGE I MPACT

S TATE - OF - THE A RT Prediction from History What if : The project is relatively new The version history does not exist The system is refactored

ACN- BASED P REDICTION 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 C ASE S TUDY –H ADOOP

D ESIGN I SSUES D ISCOVERED 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

D ESIGN I SSUES D ISCOVERED “ 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 , 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

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

F UTURE W ORK 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.