Upload
william-rogers
View
212
Download
0
Embed Size (px)
Citation preview
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