a formal model for assessing software architecture and predicting coordination requirements

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 …

ProcessArchitecture

Organization

FUNDAMENTAL DESIGN THEORIES

Information Hiding [Parnas 1972]

Design Rule Theory [Baldwin and Clark 2000]

Can we make theories operable?

DO WE HAVE TO DIG INTO SOURCE CODE? Empirical StudiesAPACHE TOMCAT VS. A PROPRIETARY SOFTWARE [WICSA 2008]

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?

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

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

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

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

  1 2 3

1.client .    

2.ds .

3.alg .

client = denseds = array_dsalg = array_alg

client = sparseds = list_dsalg = list_alg

client = denseds = array_dsalg = other_alg

client = sparseds = list_dsalg = other_alg

client = denseds = other_dsalg = other_alg

client = sparseds = other_dsalg = other_alg

S1

S2

client = sparse

client = sparsealg = other_alg

client = sparse

ds = other_ds

Precise Definition of Pair-wise Dependence And DSM Derivation

xx

xx

S3

S4

S5

S6

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 TO ACN

ACN-BASED ASSUMPTION DEPENDENCIES A lot more than pure syntactical

dependenciesApache 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 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

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

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.