15/06/2015Dr Andy Brooks1 Fyrirlestrar 7 & 8 The Effect of Inheritance on Maintainability Depth 1 Depth 2 Depth 3 MSc Software Maintenance MS Viðhald hugbúnaðar

18/04/23 Dr Andy Brooks 1

Fyrirlestrar 7 & 8The Effect of Inheritance on Maintainability

Depth 1

Depth 2

Depth 3

MSc Software MaintenanceMS Viðhald hugbúnaðar


Case Study Dæmisaga

ReferenceAn Empirical Study Evaluating Depth of Inheritance on the Maintainability of Object-Oriented Software, J Daly, A Brooks, J Miller, M Roper, and M Wood, EFoCS-10-95, Department of Computer Science, University of Strathclyde, Glasgow, Scotland. http://www.cis.strath.ac.uk/research/efocs/index.html


What Is The Truth About OO?

• Object-oriented software has been publicised as being more maintainable than conventional software and less likely to degrade as a result of maintenance.

• But dynamic binding, encapsulation, inheritance, messaging, and polymorphism have been reported as causing difficulties in program understanding, change impact identification, testing, and software maintenance.

• Unfortunately, little evidence exists to support many claims about the object-oriented paradigm.


Delocalised Plans• It has long been recognised that

delocalised plans (where pieces of code that are conceptually related are physically located in non-contiguous parts of the program) make it difficult to understand a program.

• Inheritance creates difficulties through delocalisation. Depth of inheritance might be correlated with the effect of such difficulties.


Experimental Justification

• In structured interviews, software professionals drew attention to depth of inheritance as an issue in program understanding.

• In a following questionnaire survey, 55% of 275 respondents believed depth of inheritance is an issue in program understanding.

• Most of the 55% indicated that between 4 and 6 levels of inheritance depth is where difficulties begin.

• So a series of experiments was conducted by EFoCS to evaluate if depth of inheritance is an issue when maintaining object-oriented code.


Hypotheses Experiment 1

• H0 The use of a hierarchy of 3 levels of inheritance depth does not affect the maintainability of object-oriented programs.

• H1 The use of a hierarchy of 3 levels of inheritance depth does affect the maintainability of object-oriented programs.

• No direction was specified on the alternative hypothesis because of the varying views expressed in the literature and because a Level of 3 is close to where difficulties are said to occur in program understanding.

tilgötur


Design Experiment 1

• Subjects were randomly allocated into one of two groups (A or B).

• Group A performed a maintenance task on a program with an inheritance hierarchy.

• Group B performed a maintenance task on a program with no inheritance hierarchy.– The ´flat´version.

• To counter-balance, the reverse was performed on a similar program.– Group A flat; Group B inheritance.

• Counter-balancing should eliminate ability effects and any task direction bias.– There is, however, always the possibility of a learning effect from

one task to the next.


Group Allocations To Tasks Experiment 1


Variables Experiment 1

• The program version (inheritance or flat) was the independent variable.

• Time taken to complete the maintenance task was the dependent variable.– Time taken is one of the main product measures of

performance.

• Other data was gathered to allow an inductive analysis.– To provide an insight into what subjects did or did not

do and why.

breytur


Subjects Experiment 1

• 31 postgraduate students who had taken an intensive C++ module delivered over a 4 week period.– 16 subjects Group A, 15 subjects Group B

• Note that subjects were matched on the results of multiple-choice tests and then randomly assigned to a group.– Reduces subject variability between groups.

• Module practical tests (EFoCS experiments) constituted 60% of the final module mark.– Subjects consented to the practical test data being

used for experimental purposes.

þátttakendur


Procedure For Each Practical Test Experiment 1a & 1b

• Subjects allowed 5 minutes to read the instructions and ask questions.

• Packet 1 was opened which contained the maintenance task. Subjects were given a further 10 minutes to read the task and ask questions.

• When Packet 2 was opened, which contained the code listing, data recording began. Subjects had up to 1hr 45minutes to complete the task.

• At the end, subjects were asked to complete a debriefing questionnaire covering: personal details, programming experience, and various impressions of the maintenance task attempted.


Programs For Modification Experiment 1

• Two C++ programs representing simple database systems.– Records could be created, displayed, modified, and deleted.– First program manipulated lecturers, secretaries, and students.– Second program manipulated books, conferences, and theses.

• Two versions of each program were used: flat and inheritance.– The flat versions were created by removing inheritance and adding

the data members and functions to each class which had previously inherited them.

• Flat versions had 4 classes and about 440 lines of code. • Inheritance versions had 6 classes and about 390 lines of

code.


Maintenance Task Experiment 1

• The task introduced a new requirement to increase the amount of information the database could store.

• The task involved:– Adding a Professor to the university system, or a

PhD_Thesis class to the library system.– Creating an instance of the new class, modifying

values, and displaying the object.

• Regardless of the program version, the modification task was the same.


Inheritance Hierarchy For University System


Materials Experiment 1

• Each subject was provided with:– a Sun-Sparc workstation, Sun C++ compiler, and the

GNU Emacs editor– full experimental and maintenance task instructions– complete, documented source code listings

• Note that subjects in the same group were not sitting next to each other and that subjects were allowed access to the module textbook.


Data Collection Experiment 1

1. Time to complete task.

2. Time-stamped file backups of compilation attempts.

3. A shell script of the process the subject adopted towards the modification.

4. The modification solution.

5. Data elicited from a debriefing questionnaire.


Pilot Study Experiment 1

• A pilot study was performed with 4 experienced subjects: one for each program version.

• No significant issues were encountered.

• But subjects required clarification of several points of instruction.

• The instructions were amended to make them clearer.


Timing Results Experiment 1

Stime: standard deviation Inc: number of incompletions


Statistics Experiment 1

• Mean difference of 11.4 minutes between inheritance and flat times.

• Skewness and kurtosis tests indicate the data is non-normal.

• A Wilcoxon signed ranks (related) test based on the 20 subjects who completed both the flat and inheritance program versions was significant with p = 0.05.

• Overall (also considering incompletions), 2 out of 3 subjects performed better when maintaining object-oriented software with inheritance.


Design Replication and Experiment 2

• 31 subjects– a more experienced mixture of Computer Science

graduates and students entering final (fourth) year• Subjects taught C++ intensively in a week during

which an internal replication was performed using only the library system.

• The university system was used to study a deeper inheritance hierarchy (5 levels).

• Subjects were blocked across average Computer Science marks.

• Same procedures, materials, and environment as the first experiment.


Group Allocation Replication and Experiment 2

Subjects performed a maintenance task to both a flat and inheritance program version.


Replication Time Statistics


Replication Results

• Similar difference of 10.9 minutes in the same direction as Experiment 1.– Easier to maintain inheritance program version.

• A Wilcoxon rank sum (unrelated) test was not significant (p = 0.07) but was arguably close enough to the 0.05 level to provide some confirmation of the results of Experiment 1.

• Overall average times are faster than Experiment 1 by 9.1 minutes (flat) and 8.6 minutes (inheritance).– Replication subjects had greater programming

experience.


Deeper Hierarchy Experiment 2

• More complex version of the university system:– undergraduate student, postgraduate student,

technician, senior technician, and supervisor classes were added

– wages and salaries of university employees now calculated

• Inheritance program version about 880 lines of code.

• Flat program version about 1,080 lines of code.


Maintenance Task Experiment 2

• Add a new class Director.– intended to be specialised from Supervisor

• Add method to calculate taxable salary for Director.

• Create, modify, display,and delete instances of Director.


Statistics Experiment 2

• On average, subjects maintaining the flat program version appear to outperform subjects maintaining the inheritance program version (as predicted by the questionnaire data).

• But a Wilcoxon rank sum test (unrelated) did not show a significant difference with p = 0.27.

• However, the turnaround is worth exploring further.


Result BoxPlotsExperiment 1 Internal replication Experiment 2

5 Levels


Possible Turnaround Explanation

• Inheritance hierarchies suffer from “conceptual entropy”

• The deeper a hierarchy, the greater the possibility a subclass will not consistently extend the concept of its superclass.

• In Experiment 1 and the internal replication, most subjects inherited from the same class.

• In Experiment 2, there was substantial disagreement about which class to specialise from.


3 Chosen Superclasses Experiment 2

• Lecturer (2 subjects)• Staff (9 subjects)

– In debriefing, 4 subjects indicated they chose this class because it had some of the needed functionality.

• Supervisor (4 subjects)– In debriefing, subjects indicated they chose this class

because it had the most attributes in common.• 10 subjects in debriefing describe the difficulty of

deciding which class to specialise from.– Experiment 2 only.

• Note also that 5 inheritance subjects stated problems tracing method invocations.– Experiment 2 only.


Use Of Inheritance By ‘Flat’ Subjects

• EFoCS found no evidence of performance differences between ‘flat’ subjects using inheritance and ‘flat’ subjects who did not use inheritance.

• Probably greater experience led to greater usage of inheritance by ‘flat’ subjects in the replication (11/14).

• Figures in brackets are incompletions.


Possible Learning Effect

• In the first run of Experiment 1, 11/15 subjects provided a ‘flat’ solution to the ‘flat’ problem.

• In the second run of Experiment 1, only 7/16 produced a ‘flat’ solution to the ‘flat’ problem.

• Subjects´ confidence with inheritance may have grown in the first run so that more of them used inheritance with the ´’flat’ problem on the second run.– Marginal evidence of a learning effect.

• A two-way ANOVA for the first experiment revealed no significant sequence effect.


Adjustments To Timings

• Some subjects began an inheritance solution but after encountering difficulties resorted to a flat solution.

• Extreme adjustment was tried: the entire time the subject was working on an inheritance solution was substracted from the total time taken.

• Significance of the first experiment became marginal (p=0.06).

• Combining data from the first experiment and internal replication recovered a statistically significant result (p=0.04).– But the confirmatory role of the internal replication is

lost.


Outliers

• Outliers outlie at least 1.5 times the distance between the 25th percentile and the 75th percentile (i.e. the size of the actual box part of the boxplot).

• It is always useful to try and seek explanations of any outlier data.


Outlier Explanations

• Subject 26 had difficulty removing syntax errors.• Subject 30 took an hour to correct a simple

editing mistake.• Subject 31 took half an hour to fully understand

the task.• Subject 11 took 20 minutes to understand the

task and had difficulty removing syntax errors.• Subject 29 twice changed their mind about

which class to inherit from.


Threats To External Validity

• The subjects (students and recent graduates) may not be representative of software professionals.

• The software used in the experiments and replication are unlikely to be representative of real industrial software.

• There is more to the maintenance process than implementation, but laboratory experimentation necessarily has limited scope.


Conclusions

• When there is a clear choice of a single superclass to inherit from, then inheritance can reduce the maintenance effort.

• When there are multiple candidate superclasses, then the maintenance effort using inheritance is not dissimilar to the effort required of maintaining ‘flat’ code.– Shallow broad code can present multiple candidate

superclasses as well as deep narrow code.

• The experiments should be externally replicated by other researchers.

niðurstöður

Documents

15/06/2015Dr Andy Brooks1 Fyrirlestrar 7 & 8 The Effect of Inheritance on Maintainability Depth 1 Depth 2 Depth 3 MSc Software Maintenance MS Viðhald hugbúnaðar