EMOOSE 2002-2003 Object-Oriented Software Evolution Dr. Tom Mens [email protected] Programming...

EMOOSE 2002-2003Object-Oriented Software Evolution

Dr. Tom [email protected]

Programming Technology Lab

http://prog.vub.ac.be

Vrije Universiteit Brussel

Pleinlaan 2 - 1050 Brussel

Belgium

Introduction

mailto:[email protected]

http://prog.vub.ac.be/

2EMOOSE - January 2003 © Tom Mens, Programming Technology Lab

Course Schedule January 2002

13/1 PM 15:00 ‡ 17:45 Theory

14/1 AM 9:30 ‡ 12:15 Theory

PM 13:30 ‡ 17:45 Practice

15/1 AM 9:30 ‡ 12:15 Theory


16/1 AM 9:30 ‡ 12:15 Theory



Course Overview

13/1 PMIntroduction about software evolution andrefactoring

14/1 AM Refactoring basics and XP

PM Refactoring Practice

15/1 AM Refactoring advanced


16/1 AM Formal refactoring and design patterns



Definition

Software maintenance isThe process of modifying a software system or

component after delivery to correct faults, improve performance or other attributes, or adapt to a changed environment [IEEE Std 610.12-1999]

The software product undergoes modification to code and associated documentation due to a problem or the need for improvement. The objective is to modify the existing software product while preserving its integrity [ISO Std 12207]


Definition

Software evolution isall programming activity that is intended to generate a

new software version from an earlier operational version [Lehman&Ramil 2000]

the life of the software after its initial development cycle (or after the first delivery of the software system)Any subsequent change to the software, such as bug fixes

and adding new functionality, is considered to be software evolution

staged model of software life-cycle


Staged life-cycle model

initial development

evolution

servicing

phase-out

close-down

evolution changes(preserves architectural integrity)

servicing patches

first running version

loss of evolvability

servicing discontinued

switch-off

evolutionversion 2

servicingversion 2

phase-outversion 2

close-downversion 2

evolutionversion 3

servicingversion 3

phase-outversion 3

close-downversion 3

[Bennett 1999]


Software Aging

A legacy system is a piece of software thatyou have inherited is valuable to you

but for whichoriginal developers are no longer availableoutdated development methods are usedextensive patches and modifications have been madedocumentation is missing or outdated

so that further evolution may be prohibitively expensive


Software Aging

The difference between legacy systems and adaptable software is the ability to change

We need to learn how to reverse the effects of aging“Programs, like people, get old. We can’t prevent aging,

but we can understand its causes, take steps to limit its effects, temporarily reverse some of the damage it has caused, and prepare for the day when the software is no longer viable.” [Parnas 1994]

Possible solution: restructuring/refactoring


Software Aging

Reasons why software ages Maintenance (e.g., bug fixes) ignorant surgery and architectural erosion inflexibility from the start insufficient or inconsistent documentation deadline pressure duplicated functionality (code duplication) lack of modularity increasing complexity ...


Evolution is Unavoidable

The main difficulty in software engineering is that changes cannot be anticipated at design time“The fundamental problem, supported by 40 years of hard

experience, is that many changes actually required are those that the original designers cannot even conceive of.”

[Bennett&Rajlich 2000]

Heisenberg principle of software development requirements start changing from the moment you start building

or using a software system


Evolution is Unavoidable

Laws of software evolution [Lehman&Belady1985, Lehman1996]

Continuing change A program that is used in a real-world environment must change, or

become progressively less useful in that environment

Increasing complexity As a program evolves, it becomes more complex, and extra

resources are needed to preserve and simplify its structure cf. evolution versus servicing techniques like refactoring are needed

... many other laws ...Based on the evolution of IBM 360 mainframe OS over a period of 30

years


Types of software evolution

3 coarse-grained types of software maintenanceCorrective fix reported errors in the software

Adaptive adapt the software to a new

environment (platform, OS, ...)

Perfective implement new functional or

nonfunctional requirementsPerfective

(65%)

Adaptive (18%)

Corrective (17%)

[Lientz&Swanson 1980]

(classification based on what the software developers see as causes or purposes of the maintenance, i.e., why maintenance has to be done)



Main reasons why software evolves changes in user requirements

user-requested extensions as well as modifications bug fixes

scheduled routine fixes emergency fixes (more costly due to heavy pressure)

changes in data formats Y2K, Euro, tax rates, postal codes,

phone numbers, ... new standards: UML, XML, COM,

DCOM, CORBA, ActiveX, WAP hardware changes efficiency improvements

Changed data formats (18%)

Bug fixes (21%)

Hardware changes (6%)

Efficiency improvements

(4%)

Changed user

requirements (42%)

[Lientz&Swanson 1980]



Other reasons for software evolution preventive changes (e.g., refactoring / restructuring)

To prevent and reverse effects of software aging To enhance the software maintainability To improve the design To cope with new insights in the domain

iterative incremental development use of software components beyond their original goals reuse of software components in other systems

It is inconceivable to anticipate all possible reuses of a given software component



objective-evidence-based classification[Chapin et al. 2001] classifies software evolution and maintenance

activities or processes in1. the software (including documentation)

2. the code

3. the customer-experienced functionality

by comparing software before and after evolution

12 types of software evolution identified



Was software changed?

Was source code changed?

Was function changed?

1. Training2. Consultive3. Evaluative

1. Reformative2. Updative

1. Groomative2. Preventive3. Performance4. Adaptive

1. Reductive2. Corrective3. Enhancive

Yes

No

No

Yes

No

Yes



A. Did the activities change the software? No.1. (Training) Did the activities use the software as a subject for

stakeholder training?2. (Consultive) Did the activities use the software as a basis for

consultation?3. (Evaluative) Did the activities involve evaluating the software?

B. Did the activities change the code? No.1. (Reformative) Did the activities make the non-code

documentation conform more closely to the stakeholders needs?

2. (Updative) Did the activities make the non-code documentation conform more closely to the system as implemented?



C. Did the activities change the customer-experienced functionality? No.

1. (Groomative) Did the activities change maintainability or security?

2. (Preventive) Did the activities avoid or reduce future maintenance activities?

3. (Performance) Did the activities alter software performance characteristics or properties?

4. (Adaptive) Did the activities change the technology or resources used?

.

.

.



D. If answer to C is “Yes”.1. (Reductive) Did the activities restrict or reduce the customer-

experienced functionality?

2. (Corrective) Did the activities fix the customer-experienced functionality or make it more correct?

3. (Enhancive) Did the activities replace, add to, or extend the customer-experienced functionality?

.

.

.

.


Scalability is essential

Very small programs do not have maintenance problems

Research results must scale up to large software systems for industrial applications “A major challenge for the research community is to

develop a good theoretical understanding and underpinning for maintenance and evolution, which scales to industrial applications.” [Bennet&Rajlich2000]


Problems with Evolution

Difficult to predict/anticipate evolution Version proliferation Lack of domain insight Software drift and erosion / co-evolution * Overfeaturing (e.g. MS Word) Change propagation & change impact analysis *

Ripple effect Traceability problems

Predicting evolution * effort estimation


Software Erosion

architecture,analysis,design,

documentation

implementationevolved

implementation

not updateddue to

deadline pressurenot consistent

anymore


Software Erosion

Possible solution: co-evolutionWhen the implementation evolves, which changes do

we need to make to higher-level models?When the architecture/analysis/design evolves, how

do we make the existing implementation consistent again?

Difficult problemSupporting techniques and tools needed


Change Impact Analysis

Definition [Bohner&Arnold 1996]The activity by which the programmers assess the

extent of a change, i.e., the components that will be impacted by the change.

Change impact analysis indicates how costly the change is going to be (cf. effort estimation) and whether it is to be undertaken at all.


Ripple effect!

Changepropagation

Changinga component

Change Impact Analysis ctd.


Change Impact analysis ctd.

Ripple effect [Yau 1978] the phenomenon where a change in one piece of a software

system affects at least one other area of the same software system (either directly or indirectly).

Change propagation [Rajlich 1997] occurs when making a change to one part of a software system

requires other system parts that depend on it to be changed as well. These dependent system parts can on their turn require changes in other system parts. In this way, a single change to one system part may lead to a propagation of changes to be made throughout the entire software system.


Change mini-cycle

According to [Yau 1978]:Request for changePlanning phase

Program comprehensionChange impact analysis

Change implementationRestructuring/refactoring for changeChange propagation

Verification and validationRe-documentation

to avoid software erosion


Predicting evolution

Software engineers are louzy in predicting which classes will change upon evolutionEmpirical study of [Lindvall&Sandahl1998]:

only between 30% and 40% of actual changed classes were predicted to be changed!

Need for a more objective approach for identifying evolution-prone parts of a software system


Effort Estimation

It is important for managers toestimate amount of effort and related schedule

required for accomplishing software evolution tasksassess programming productivitydetect productivity decreases due to software aging

or increase of software complexityneed for restructuring or replacing the software system

detect productivity increases due to more programmer experience or process improvements


Effort Estimation ctd.

Effort estimation in the context of software evolution not thoroughly treated in the literature Only in the context of software development “from scratch” there

are some approaches available, but results are not transferable to the context of software evolution

Notable exception: [Lehman&Ramil2000] Evolution of a mainframe operating system kernel (IBM 360)

over 17 years of its lifetime Effort estimation model with an accuracy of appr. 20%


Bibliography

[Bennett 1999] K. H. Bennett, V. T. Rajlich. A new perspective on software evolution: the staged model, 1999

[Bennett&Rajlich 2000] K. H. Bennett, V. T. Rajlich. Software Maintenance and Evolution: a Roadmap. The Future of Software Engineering, ACM Press, 2000

[Bohner&Arnold 1996] Shawn A. Bohner, Robert S. Arnold. Software Change Impact Analysis. IEEE Computer Society Press, 1996

[Chapin et al. 2001] N. Chapin, J.E. Hale, K.Md. Khan, J.F. Ramil, w.-G. Than. Types of software evolution and software maintenance. Journal of software maintenance and evolution 13: 3-30, 2001.

[Lehman&Belady 1985] M. M. Lehman, L. Belady. Program Evolution: Processes of Software Change. London Academic Press, 1985


Bibliography ctd.

[Lehman 1996] M. M. Lehman. Laws of Software Evolution Revisited, 1996

[Lehman&Ramil 2000] M. M. Lehman, J. F. Ramil. Effort Estimation from Change Records of Evolving Software, 2000

[Lientz&Swanson 1980] B. P. Lientz, E. B. Swanson. Software maintenance management: a study of the maintenance of computer application software in 487 data processing organizations. Addison-Wesley, 1980

[Lindvall&Sandahl 1998] M. Lindvahl, K. Sandahl. How Well do Experienced Software Developers Predict Software Change? J. Systems and Software, 43(1): 19-27, 1998

[Parnas 1994] D. L. Parnas. Software Aging. Invited plenary talk. Proc. Int. Conf. on Software Engineering (ICSE ’94), pp. 279-287, IEEE Computer Society Press, 1994


Bibliography ctd.

[Rajlich 1997] V. Rajlich. A Model for Change Propagation Based on Graph Rewriting. Proc. Int. Conference on Software Maintenance, pp. 84-91. IEEE Computer Society Press, 1997

[Swanson 1976] E.B. Swanson. The dimensions of maintenance. Proc. Int. Conf. Software Engineering, pp. 492-497, IEEE Computer Society Press, 1976

[Yau 1978] S. S. Yau, J. S. Colofello, T. MacGregor. Ripple Effect Analysis of Software Maintenance. Proc. COMPSAC, pp. 60-65, IEEE Press, 1978

EMOOSE 2002-2003 Object-Oriented Software Evolution Dr. Tom Mens [email protected] Programming...

Documents

Transcript of EMOOSE 2002-2003 Object-Oriented Software Evolution Dr. Tom Mens [email protected] Programming...