Topology Analysis of Software Dependencies

MARTIN P. ROBILLARD, McGill University, CanadaACM Transactions on Software Engineering and Methodology (TOSEM), vol. 17, no. 4, August 2008

Presented by Celal Ziftci, University of California San DiegoCSE-294@UCSD-Spring’10

May 21 2010

Part of this presentation explains the journal paper as it stands, however I have added model-driven-development as a motivation and suggestions to make use of the paper’s approach in a model-driven-development context.

Disclaimer

Motivation◦ w.r.t. MDD◦ Example

Approach◦ Heuristics◦ Definitions◦ Sample run on our example◦ Case-study results

Why do we care?

Contents

Hopefully, a system has proper models that represent it in a true sense for round-trip engineering◦ We can associate models to code◦ We can associate code to models

But reality is not always so in many real-life projects…◦ Many legacy systems have code, but no models

If MDD was used up-start, this would not happen, but here we are now…

So, what do we do, if we need to make changes to/understand the system◦ Fixing a bug◦ Adding new functionality◦ New programmer in the team

Motivation: w.r.t. MDD

Big systems have so many lines of code◦ Software running in a car

10 million lines of code 10 ECUs communicating

with each other For our use-case, let us

pick a simplified car◦ Our focus: Understanding

acceleration & braking

Motivation: Example

Motivation: Example

Motivation: Example

Motivation: Example

Note that, in our case, we start from source code… We would like to explore parts of code that lead to

the part we are interested in step-by-step: in waves

Can’t we do this in tools like Eclipse IDE already?◦ Yes and No…◦ Yes:

Eclipse can show all code paths leading to a method/field◦ No:

No ranking in the relevancy of results No extra custom dependencies (for eg. who writes to a field?)

Motivation: Example

Motivation: Example

Adapted from [1]

Specificity

Approach: Two heuristics for degree of interest

Reinforcement

6 is more specific2 is more specific 6 is reinforced

2 is reinforced

[1]

[1]

Approach: Definitions

Consider a specific relation: called-by

Approach: Sample run

called-by

called-byT = called

A: Sforward={c,d,e}◦ c: Sbackward={A}

◦ d: Sbackward={A}

◦ e: Sbackward={A, B, f}

B: Sforward={e}◦ e: Sbackward={A, B, f}

degreec = 0.76 * 0.75 = 0.57 degreed = 0.76 * 0.75 = 0.57 degreee = max(0.69 * 0.75, 0.9 * 0.25) = 0.52

Approach: Sample run (called-by)

[1]

We did the sample run for called-by dependency.

Same calculations done for other dependencies as well (for eg accessed-by for fields)

All the suggestion sets are combined using fuzzy sets (similar to what we did in our example)

Approach: Sample run

And more similar results…

Approach: Results

[1]

[1]

This tool (and other similar ones) makes it easier to follow the approach effective developers were observed to follow [2].◦ As the developer uses this tool in waves, the tool can record

which elements were chosen to be worthy of interest and further investigation.

◦ Then, the tool can generate models out of the relationships between those elements automatically

◦ The developer already investigated and marked what is relevant, and the tool saves him from the burden of creating a model that explains what he did already.

Using this approach, we can do round-trip engineering.◦ Even if we go the forward direction (models to code), we can

use this approach to check if what we believe to exist in code is the reality

So… Why do we care?…

Thank you! Now any further questions?

Questions

[1] Robillard, M. P. 2008. Topology analysis of software dependencies. ACM Trans. Softw. Eng. Methodol. 17, 4 (Aug. 2008), 1-36. DOI=http://doi.acm.org/10.1145/13487689.13487691

[2] Robillard,M. P.,Coelho,W., Andmurphy,G. C. 2004. How effective developers investigate sourcecode: An exploratory study. IEEE Trans. Softw. Engin. 30, 12, 889–903.

References