Using program slicing metrics to predict software maintainability Tracy Hall Paul Wernick Systems Software Group Uni

1. Using program slicing metrics to predict software maintainability Tracy Hall & Paul WernickSystems & Software GroupUniversity of Hertfordshire

2. 2 Structure Introduction Program slicing and maintainability Slicing metrics Applying slicing metrics to maintainability Conclusions and future work

3. 3 Introduction Evolving and maintaining systems is important and difficult Measuring the maintainability or evolvability of systems is not done well Understanding evolvability implications of process change difficult without good indictors Meyers & Binkley provide work on slicing metrics that might provide good indicators of maintainability

4. 4 Program slicing and maintainability Program slicing relevant to maintenance as it evaluates the implications of changing the code Slices capture many features of a systems relevant to its evolvability Slicing should enable the prediction of effort required to make a change This application of slicing techniques is subtly different from previous applications

5. 5 Slicing metrics Original set of metrics proposed by Weiser in 1981 and extended by Ott et al in the 1990�s Meyers and Binkley first to collect and analyse large scale data Metrics: Coverage Overlap Clustering Parallelism Tightness MaxCoverage MinCoverage

6. 6 Applying slicing metrics to maintainability We consider each slicing metric and the relationship to effort needed too evolve a system�

7. 7 Coverage Compares the length of slices to the length of the entire program Many short slices may indicate a system whose structure has been compromised. It may also show degraded design focus. Future changes have a higher chance of cutting across the current structure. We suggest that low coverage implies higher effort to evolve.

8. 8 Overlap Indicates how many statements in a slice are found only in that slice Higher values of overlap mean that statements are reused in different elements of the program. This means that a change will have to account for this reuse. This is potentially difficult and errors are likely. We suggest that high overlap means that more effort is needed to evolve the system.

9. 9 Clustering The degree to which slices are reflected in the original code layout Low clustering implies that code is less well structured and more interdependent. Evolving systems is likely to be more difficult as understanding and changing code will require more effort and possibly imply more error prone changes.

10. 10 Parallelism The number of slices which have few statements in common. High parallelism may indicate areas of functionality are well separated in the code. This suggests that evolutionary changes may be made more easily and with less effort

11. 11 Tightness The number of statements which are in every slice. High tightness values suggest that the code is cohesive. We suggest that high tightness values mean that the code will require less effort to evolve.

12. 12 MaxCoverage Length of the longest slice as a proportion of the program length The longer the slice the more of the code will have to be understood to evolve the system. We suggest that high MaxCoverage means that more effort will be needed to evolve the system

13. 13 MinCoverage The length of the shortest slice as a proportion of the program length This is the converse of MaxCoverage

14. 14 Conclusions and future work Slice-based metrics look a promising way to measure maintainability/evolvability There seems to be some theoretical basis for continuing to explore the ideas Results could feed into our previous system dynamics work modelling system evolution Planning a more thorough empirical evaluation of the ideas using Open Source data

15. 15 Tracy Hall & Paul Wernick Systems and Software Group University of Hertfordshire {t.hall, p.d.wernick}@herts.ac.uk