1. An Empirical Study of the Evolution of
Eclipse Third-party Plug-ins
IWPSE-EVOL 2010, ANTWEP, BELGIUM
By: John Businge, PhD Student
Mbarara University of Science and Technology
Co-Authors: Prof. Mark van den Brand &
Dr. Alexander Serebrenik

2. Outline
• Introduction
• Goal
• Approach
• Analysis & Results
• Summary & Future work
Software Engineering and Technology (SET) PAGE 19-6-2014

3. Introduction
Software Engineering and Technology (SET) PAGE 29-6-2014
Plug-ins
Framework
Frameworks evolve from one release to another to improve quality
Plug-ins have two evolution processes: general and framework-
based
Component frameworks
simplify the work of Software
Developers
Third-party plug-in: Extend
capabilities of a framework and
reuse the functionality of a
framework

4. Goal
• Applicability of traditional results on software
evolution to constrained evolution of Eclipse plug-
ins
• Specifically, we take the first step and investigate
Lehman’s laws of software evolution on the
constrained evolution of the Eclipse third-party plug-
ins.
Software Engineering and Technology (SET) PAGE 39-6-2014

5. Approach (1) – Selected Plug-ins
• More than 1,000 Eclipse plug-ins on the advertising website
• Collected 21 plug-ins
• More
Software Engineering and Technology (SET) PAGE 49-6-2014

6. Approach (2) – 15 metrics Used
Software Engineering and Technology (SET) PAGE 59-6-2014
• Two categories of metrics:
• Eclipse-based evolution - Deps
• General Evolution - Tot

7. Lehman’s Laws of Software Evolution
• Law 1: Continuing change: Software system must be
continually adapted else it becomes less satisfactory
• Law 3: Self-regulation: System will adjust its size
throughout its lifetime
• Law 5: Conservation of Familiarity: Incremental
growth/change tends to remain constant or to
decline over time.
• Law 6: Continuing Growth: Systems usually grow
over time to accommodate pressure for change.
• Law 7: Declining quality: Quality declines over time
Software Engineering and Technology (SET) PAGE 69-6-2014

8. Results…
Continuing Change law (Deps)
• Software system must be continually adapted else it
becomes less satisfactory
Software Engineering and Technology (SET) PAGE 79-6-2014

9. Continuing Change law (NOC-Deps)
• Confirmed
Software Engineering and Technology (SET) PAGE 89-6-2014

10. Self-Regulation law (Deps-Tot)
• System will adjust its size throughout its lifetime
Software Engineering and Technology (SET) PAGE 99-6-2014

11. Self-Regulation law (Deps-Uniq)
• Confirmed
Software Engineering and Technology (SET) PAGE 109-6-2014

12. Continuing growth law (Deps-Uniq)
Software Engineering and Technology (SET) PAGE 119-6-2014
• Systems usually grow over time to accommodate
pressure for change.

13. Continuing growth law (NOC-Deps)
• Confirmed
Software Engineering and Technology (SET) PAGE 129-6-2014

14. Conservation of familiarity law (CFL)
• Incremental growth/change tends to remain constant
or to decline over time.
• Statistically test this law.
• We used 2 metrics to verify this law:
• 1. change-rate = % of handled files (additions, deletions and
modifications), in the previous version of the plug-in as the dependent
variable.
• 2. growth-rate = % of added Deps and % of added NOC in the previous
version of the plug-in as the dependent variable.
• We test these two metrics as time series on the following models and
state hypothesis
Software Engineering and Technology (SET) PAGE 139-6-2014

15. CFL - Hypothesis
• Change Rate:
• (Handled NOC-Tot) H10: β＞0, H1a: β≦0
• (Handled NOC-Deps) H20: β＞0, H2a: β≦0
• Growth Rate:
• (Deps) H30: β＞0, H3a: β≦0
• (Handled NOC-Tot) H40: β＞0, H4a: β≦0
• (Handled NOC-Deps) H50: β＞0, H5a: β≦0
Software Engineering and Technology (SET) PAGE 149-6-2014

16. CFL – Results NOC change rate
Software Engineering and Technology (SET) PAGE 159-6-2014

17. CFL – Summary Results – NOC change rate
• H1-Tot - 9/15 and H2-Deps- 8/15 supporting the law.
• 2 plug-ins have increasing change rate – further
analysis found that growth trend for the 2 metrics
used is super-linear. Corresponds to Koch’2007 –
Active revisions
• NOT CONFIRMED
Software Engineering and Technology (SET) PAGE 169-6-2014

18. CFL – Results Deps growth rate
Software Engineering and Technology (SET) PAGE 179-6-2014

19. CFL – Summary Results – Deps Growth Rate
• H3-Deps – 2/15, H4-Tot – 5/15 and H5-Deps – 6/15
supporting the law
• One plug-in had and increasing growth rate – further
analysis showed that the growth trend is super-linear.
This corresponds to Godfrey and Tu’2000 – Study of
Linux
• NOT CONFIRMED
Software Engineering and Technology (SET) PAGE 189-6-2014

20. Declining Quality Law (DQL)
• Like CFL, we also statistically test this law.
• Dn - Metric was used as the dependent variable to verify
this law.
• Dn – normalized distance from the main sequence: is
the is an indicator of the package's balance between
abstractness and stability
• A low value (closer to zero) of MEAN and STD of
package’s Dn is an indicator of high quality.
• To obtain Dn-values, we follow Serebrenik et al. (2009).
• Plug-ins having at least 30 packages (excl. 3rd party
packages) were selected. 8/21 plug-ins satisfied the
requirement
• Hypothesis were stated.
•Software Engineering and Technology (SET) PAGE 199-6-2014

21. DCL – Hypotheses
• (MEANs of different packages in
different plug-in versions)
H60: β ≦ 0, H6a: β ＞ 0
• (STDEVs of different packages in
different plug-in versions)
H70: β ≦ 0, H7a: β ＞ 0
Software Engineering and Technology (SET) PAGE 209-6-2014

22. DCL - Results
Software Engineering and Technology (SET) PAGE 219-6-2014

23. Dn – SQL - Exceptional
Software Engineering and Technology (SET) PAGE 229-6-2014
0.100
0.120
0.140
0.160
0.180
Mar/05 Nov/05 Jul/06 Mar/07 Nov/07 Jul/08 Mar/09 Nov/09
Dn-SQL
MEAN
STDV

24. DCL – Summary
• 5 / 8 plug-ins show support of the law.
• 1 plug-in has both MEAN and STD decreasing.
• Exceptional cases decrease in MEAN and increase in
STD - SQL
• Inconclusive
Software Engineering and Technology (SET) PAGE 239-6-2014

25. Summary and Future Work
• First step to study fine grained evolution of software
systems built on component frameworks using
Lehman’s laws of software evolution.
• Overall, observed trends compare to earlier research
trends
• Broader study of the laws is required
• Additional direction- distinguish “Good API” and
“Bad API” of the framework
Software Engineering and Technology (SET) PAGE 249-6-2014

26. Thank you for Listening
Software Engineering and Technology (SET) PAGE 259-6-2014