EMOOSE 2002-2003 Object-Oriented Software Evolution

1. EMOOSE 2002-2003Object-Oriented Software Evolution Introduction Dr. Tom Mens tom.mens@vub.ac.be Programming Technology Lab http://prog.vub.ac.be Vrije Universiteit Brussel Pleinlaan 2 - 1050 Brussel Belgium

2. Course Schedule January 2002

3. Course Overview

4. Definition • Software maintenance is • The process of modifying a software system or component after deliveryto 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]

5. Definition • Software evolution is • all 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

6. evolutionversion 3 evolutionversion 2 servicingversion 3 servicingversion 2 phase-outversion 3 phase-outversion 2 close-downversion 2 close-downversion 3 Staged life-cycle model initial development [Bennett 1999] evolution changes (preserves architectural integrity) first running version evolution servicing patches loss of evolvability servicing servicing discontinued phase-out switch-off close-down

7. Software Aging • A legacy system is a piece of software that • you have inherited • is valuable to you • but for which • original developers are no longer available • outdated development methods are used • extensive patches and modifications have been made • documentation is missing or outdated • so that further evolution may be prohibitively expensive

8. 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

9. 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 • ...

10. 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 principleof software development • requirements start changing from the moment you start building or using a software system

11. 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

12. Types of software evolution [Lientz&Swanson 1980] • 3 coarse-grained types of software maintenance Corrective • fix reported errors in the software Adaptive • adapt the software to a new environment (platform, OS, ...) Perfective • implement new functional or nonfunctional requirements (classification based on what the software developers see as causes or purposes of the maintenance, i.e., why maintenance has to be done)

13. Types of software evolution [Lientz&Swanson 1980] 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

14. Types of software evolution 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

15. Types of software evolution • objective-evidence-based classification [Chapin et al. 2001] • classifies software evolution and maintenance activities or processes in • the software (including documentation) • the code • the customer-experienced functionality • by comparing software before and after evolution 12 types of software evolution identified

16. Types of software evolution • Groomative • Preventive • Performance • Adaptive • Reductive • Corrective • Enhancive • Training • Consultive • Evaluative • Reformative • Updative No Was function changed? No Yes Was source code changed? No Yes Was software changed? Yes

17. Types of software evolution • Did the activities change the software? No. • (Training) Did the activities use the software as a subject for stakeholder training? • (Consultive) Did the activities use the software as a basis for consultation? • (Evaluative) Did the activities involve evaluating the software? • Did the activities change the code? No. • (Reformative) Did the activities make the non-code documentation conform more closely to the stakeholders needs? • (Updative) Did the activities make the non-code documentation conform more closely to the system as implemented?

18. Types of software evolution • Did the activities change the customer-experienced functionality? No. • (Groomative) Did the activities change maintainability or security? • (Preventive) Did the activities avoid or reduce future maintenance activities? • (Performance) Did the activities alter software performance characteristics or properties? • (Adaptive) Did the activities change the technology or resources used? . . .

19. Types of software evolution • If answer to C is “Yes”. • (Reductive) Did the activities restrict or reduce the customer-experienced functionality? • (Corrective) Did the activities fix the customer-experienced functionality or make it more correct? • (Enhancive) Did the activities replace, add to, or extend the customer-experienced functionality? . . . .

20. 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]

21. 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

22. not updateddue todeadline pressure not consistent anymore evolved implementation Software Erosion architecture, analysis,design, documentation implementation

23. Software Erosion • Possible solution: co-evolution • When 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 problem • Supporting techniques and tools needed

24. 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.

25. Ripple effect! Changing a component Change propagation Change Impact Analysis ctd.

26. 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.

27. Change mini-cycle • According to [Yau 1978]: • Request for change • Planning phase • Program comprehension • Change impact analysis • Change implementation • Restructuring/refactoring for change • Change propagation • Verification and validation • Re-documentation • to avoid software erosion

28. Predicting evolution • Software engineers are louzy in predicting which classes will change upon evolution • Empirical 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

29. Effort Estimation • It is important for managers to • estimate amount of effort and related schedule required for accomplishing software evolution tasks • assess programming productivity • detect productivity decreasesdue to software aging or increase of software complexity • need for restructuring or replacing the software system • detect productivity increases due to more programmer experience or process improvements

30. 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%

31. 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

32. 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

33. 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