1. Slide 16.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified Process McGraw-Hill, 2004 Stephen R. Schach srs@vuse.vanderbilt.edu

2. Slide 16.2 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CHAPTER 16 MAINTENANCE

3. Slide 16.3 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter Overview l Why Maintenance Is Necessary l Development and Maintenance l What Is Required of Maintainers? l Temperate Fruit Committee Mini Case Study l The Management of Maintenance l Maintenance and the Object-Oriented Paradigm l Maintenance Skills versus Development Skills l Reverse Engineering l Testing during Maintenance l CASE Tools for Maintenance

4. Slide 16.4 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Maintenance—Definition l Maintenance is the process that occurs when an information system artifact is modified –Either because of a problem, or –Because of a need for improvement or adaptation »(International Standards Organization and International Electrotechnical Commission, 1995) l That is, maintenance occurs whenever an information system is modified –Regardless of whether this takes place before or after installation

5. Slide 16.5 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Why Maintenance Is Necessary l There are three main types of maintenance: l Corrective maintenance –To correct a fault l Perfective maintenance –To improve the effectiveness of the information system l Adaptive maintenance –To react to changes in the environment in which the information system operates

6. Slide 16.6 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Development and Maintenance l The information system life cycle can be viewed as an evolutionary process –This is how maintenance is viewed by the Unified Process –Maintenance is treated merely as another increment l However, there is a basic difference between development and maintenance –It is easier to create a new version than to modify an existing version

7. Slide 16.7 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Development and Maintenance (contd) l Example l Consider the similarities and differences between –Modifications to a portrait –Modifications to a information system l Conclusions –A new portrait must be painted from scratch –The existing information system must be modified

8. Slide 16.8 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. What Is Required of Maintainers? l About 67% of the total cost of a product can be attributed to maintenance l Maintenance is a major income source l Nevertheless, even today many organizations assign maintenance to –Unsupervised beginners, and –Less competent maintainers

9. Slide 16.9 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. What Is Required of Maintainers? (contd) l Maintenance is one of the most difficult aspects of software production because –Maintenance incorporates aspects of the rest of the life cycle

10. Slide 16.10 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. What Is Required of Maintainers? (contd) l Suppose a fault report is handed to a maintainer l What tools does the maintainer have to find the fault? –The fault report filed by user –The source code –And often nothing else

11. Slide 16.11 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. What Is Required of Maintainers? (contd) l A maintainer must have superb debugging skills –The fault could lie anywhere within the information system –The original cause of the fault might lie in the old (and by now non-existent) specifications or design documents

12. Slide 16.12 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. What Is Required of Maintainers? (contd) l Suppose that the maintainer has located the fault l Problem –How to fix it without introducing a regression fault

13. Slide 16.13 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. What Is Required of Maintainers? (contd) l How to minimize regression faults –Consult the detailed documentation for the information system as a whole –Consult the detailed documentation for each individual code artifact l What usually happens –There is no documentation at all, or –The documentation is incomplete, or –The documentation is faulty l The maintainer must gather information from the source code to avoid introducing a regression fault

14. Slide 16.14 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. What Is Required of Maintainers? (contd) l Now the maintainer changes the source code, then –Tests that the modification works correctly »Using specially constructed test cases –Checks for regression faults »Using stored test cases –Adds the specially constructed test cases to the existing test data for future regression testing, and –Documents all changes

15. Slide 16.15 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. What Is Required of Maintainers? (contd) l Major skills required for corrective maintenance –Superb diagnostic skills –Superb testing skills –Superb documentation skills

16. Slide 16.16 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. What Is Required of Maintainers? (contd) l Adaptive and perfective maintenance –The maintainer must go through the »Requirements workflow »Analysis workflow »Design workflow »Implementation workflow –Using the existing information system as a starting point

17. Slide 16.17 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. What Is Required of Maintainers? (contd) l When information systems are developed –Analysis artifacts are produced by analysis experts –Design artifacts are produced by design experts –Code artifacts are produced by programming experts

18. Slide 16.18 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. What Is Required of Maintainers? (contd) l But every maintainer needs to be an expert in –Analysis –Design –Implementation

19. Slide 16.19 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. What Is Required of Maintainers? (contd) l No form of maintenance –Is a task for an unsupervised beginner, or –Should be done by a less skilled computer professional

20. Slide 16.20 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. What Is Required of Maintainers? (contd) l The rewards of maintenance –Maintenance is a thankless task in every way »Maintainers deal with dissatisfied users »If the user were happy, maintenance would not be needed »The user’s problems are often caused by the individuals who developed the information system, not the maintainer »The code itself may be badly written »Maintenance is despised by many software developers »Unless good maintenance service is provided, the client will take future development business elsewhere »Maintenance is the most important part of the life cycle, the most difficult—and most thankless

21. Slide 16.21 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. What Is Required of Maintainers? (contd) l How can this situation be changed? –Managers must assign maintenance to skilled professionals, and –Pay them accordingly

22. Slide 16.22 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Maintenance Case Study l Temperate Fruit Committee l An information system is developed for exactly 7 temperate fruits –Apples, apricots, cherries, nectarines, peaches, pears, and plums l It is extended to include kiwi fruit, with difficulty

23. Slide 16.23 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Maintenance Case Study (contd) l The product now needs to handle 26 additional fruits l “Just do the same thing 26 times”

24. Slide 16.24 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Lessons of the Case Study l The problem was caused by the developer, not the maintainer l A maintainer is often responsible for fixing other people’s mistakes l The client frequently does not understand that maintenance can be difficult, or nearly impossible

25. Slide 16.25 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Lessons of the Case Study (contd) l Previous apparently similar perfective and adaptive maintenance tasks can exacerbate the problem l While performing development activities, always keep future maintenance in mind

26. Slide 16.26 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Management of Maintenance l Topics in maintenance management are now considered

27. Slide 16.27 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Fault Reports l A mechanism is needed for changing a product l If the information system appears to function incorrectly, the user files a fault report –It must include enough information to enable the maintainer to recreate the problem l Ideally, every fault should be fixed immediately –In practice, an immediate preliminary investigation is the best that can be done

28. Slide 16.28 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Fault Reports (contd) l If a fault is reported –The maintainer should first consult the fault report file –It contains »All reported faults not yet fixed, and »Suggestions for working around them

29. Slide 16.29 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Fault Reports (contd) l If the fault was previously reported –Give the information in the fault report file to the user

30. Slide 16.30 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Fault Reports (contd) l If the fault is new –The maintainer should try to find »The cause of the fault »A way to fix it »A way to work around the problem –The new fault is now filed in the fault report file, together with supporting documentation »Listings »Designs »Manuals

31. Slide 16.31 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Fault Reports (contd) –The file should also contain the client’s requests for perfective and adaptive maintenance »The contents of the file must be prioritized by the client »The next modification is the one with the highest priority –Copies of fault reports must be circulated to all users »Including: Estimate of when the fault can be fixed –If the same failure occurs at another site, the user can determine »If it is possible to work around the fault, and »How long it will be until the fault can be fixed

32. Slide 16.32 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Fault Reports (contd) l In an ideal world –Every fault is fixed immediately, then –The new version of the product is distributed to all sites l In the real world –Fault reports are distributed to all sites –Staff are not available for instant maintenance –It is cheaper to make a number of changes at the same time, particularly if there are multiple sites

33. Slide 16.33 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Authorizing Changes to the Information System l Corrective maintenance –Assign a maintainer to determine the fault and its cause, repair it, then –Test the fix, test the product as a whole (regression testing) –Document the change »What was changed »Why it was changed »By whom, and »When

34. Slide 16.34 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Authorizing Changes to the Information System l Adaptive and perfective maintenance –The procedure is the same as with corrective maintenance, except there is no fault report –There is a change in requirements instead

35. Slide 16.35 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Authorizing Changes to the Information System l What if the maintainer has not tested the fix adequately? –Before the information system is distributed, it must be tested by the SQA group l Maintenance is extremely hard l Testing is difficult and time consuming –Baselines and private copies must be utilized

36. Slide 16.36 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Ensuring Maintainability l Maintenance is not a one-time effort l Maintenance must be planned for over the entire life cycle –Design workflow »Use information-hiding techniques –Documentation must be complete and correct at all times »It must reflect the current version of every component artifact

37. Slide 16.37 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Ensuring Maintainability (contd) l While performing maintenance, maintainability must not be compromised –Always be conscious of the inevitable further maintenance l The principles of development that lead to maintainability are equally applicable during maintenance

38. Slide 16.38 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Problem of Repeated Maintenance l The moving target problem –Is frustrating to the development team –Frequent changes have an adverse effect on the information system

39. Slide 16.39 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Problem of Repeated Maintenance (contd) l Apparent solution –Perform the requirements and analysis workflows »Once the client is satisfied, the specifications are approved, and »The information system is constructed l In practice –The client can change the requirements the next day –If willing to pay the price, the client can change the requirements daily

40. Slide 16.40 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Problem of Repeated Maintenance (contd) l The problem is exacerbated during maintenance l The more changes there are –The more the product deviates from its original design –The more difficult further changes become –Documentation becomes even less reliable than usual –Regression testing files are not up to date –A total rewrite may be needed for further maintenance

41. Slide 16.41 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Problem of Repeated Maintenance (contd) l This is clearly a management problem l In theory –Developers must explain the problem at the start of the project –Specifications can be frozen until delivery –Specifications can be frozen after perfective maintenance

42. Slide 16.42 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Problem of Repeated Maintenance (contd) l In practice –It does not work that way –A client with clout can order changes and they are implemented »“He who pays the piper calls the tune

43. Slide 16.43 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Problem of Repeated Maintenance (contd) l Warning –It is no use implementing changes slowly –The relevant personnel will simply be replaced –Nothing can be done if the person calling for repeated change has sufficient clout

44. Slide 16.44 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Maintenance and the Object-Oriented Paradigm l The object-oriented paradigm promotes maintenance –A class is an independent unit –Example: Bank Card Class models every aspect of a bank card »No aspects of a bank card are modeled by any other class –Information hiding ensures that implementation details are not visible outside a class –Message passing is the only form of communication permitted

45. Slide 16.45 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Maintenance and the Object-Oriented Paradigm l In theory, it is easy to maintain a class –Independence ensures it will be easy to determine which part of an information system must be changed –Information hiding ensures that a change made to a class will have no impact outside that class –This reduces regression faults l In practice, there are obstacles specific to the maintenance of object-oriented information systems

46. Slide 16.46 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Maintenance and the Object-Oriented Paradigm l Inheritance is the cause of some problems l If new features is added to a class with no subclasses, there is no effect on any other class, but l If a class with subclasses is changed, all its subclasses are changed in the same way

47. Slide 16.47 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Maintenance and the Object-Oriented Paradigm l Inheritance hierarchy

48. Slide 16.48 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Maintenance and the Object-Oriented Paradigm l A new attribute added to class Bottom Class cannot affect any other class in any way l A new attribute added to class Top Class applies to all the classes in the diagram –This is termed the fragile class problem l Inheritance can have –A positive influence on development, but –A negative impact on maintenance

49. Slide 16.49 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Maintenance and the Object-Oriented Paradigm l A second problem arises as a consequence of polymorphism and dynamic binding –(See Chapter 20)

50. Slide 16.50 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Maintenance and the Object-Oriented Paradigm l Create new subclass via inheritance –Does not affect superclass –Does not affect any other subclass l Modify this new subclass –Again, no affect l Modify a superclass –All descendent subclasses are affected

51. Slide 16.51 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Maintenance and the Object-Oriented Paradigm l Inheritance can have –A positive effect on development –A negative effect on maintenance

52. Slide 16.52 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Maintenance versus Development Skills l Key point –Maintainers must not merely be skilled in a broad variety of areas, they must be highly skilled in all those areas –Specialization is impossible for the maintainer l Maintenance is the same as development, only more so

53. Slide 16.53 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Reverse Engineering l When the only documentation is the code itself –Start with the code –Recreate the design artifacts –Recreate the specification artifacts (extremely hard) –CASE tools can help (flowcharters, other visual aids) l This is a common problem with legacy systems

54. Slide 16.54 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Reverse Engineering (contd) l Definitions –Reengineering »Reverse engineering, followed by forward engineering –Restructuring »Improving the information system without changing its functionality –Examples: »Prettyprinting »Converting code from traditional to object-oriented form »Improving maintainability

55. Slide 16.55 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Testing during Maintenance l Maintainers view an information system as a set of loosely related code artifacts –They were not involved in the development of the product l Regression testing is essential –Store test cases and their outcomes, modify as needed

56. Slide 16.56 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CASE Tools for Maintenance l Version control tools are essential l Configuration control tools are essential –Examples: »Commercial: PVCS, SourceSafe »Open source: CVS l If no configuration control tool is available –A build tool is required

57. Slide 16.57 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CASE Tools for Maintenance (contd) l A fault tracking tool is also needed –It keeps a record of reported faults that are not yet fixed –Example: »Open source: Bugzilla

58. Slide 16.58 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CASE Tools for Maintenance (contd) l CASE tools can assist in reverse engineering and reengineering –Examples »Commercial: Battlemap, Teamwork

59. Slide 16.59 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CASE Tools for Maintenance (contd) l Maintenance is difficult and frustrating l Management must provide maintenance programmers with the CASE tools needed for efficient and effective maintenance