Post on 14-Jan-2022
SOF TWARE MAINTENANCE
Dr. Vadim Zaytsev Universiteit van Amsterdam
27 January 2014 CC-BY-SA
SOF TWARE TYPES
Program Types: S
• S-type programs
• “specifiable”
• problem can be formally defined by a spec
• automated acceptance possible
• such software does not evolve
M.M.Lehman, Programs, Life Cycles and Laws of Software Evolution, IEEE 68(9), 1980.
Program Types: S
Steve Easterbrook, http://www.cs.toronto.edu/~sme/CSC444F/slides/L20-SoftwareMaintenance.pdf
1
University of Toronto Department of Computer Science
© 2001, Steve Easterbrook
Lecture 20:Software Maintenance
!Software Evolution! Software types! Laws of evolution
!Maintaining software! types of maintenance! challenges of maintenance
!Reengineering and reverse engineering
!Software Reuse
2
University of Toronto Department of Computer Science
© 2001, Steve Easterbrook
Program Types!S-type Programs (“Specifiable”)
! problem can be stated formally and completely! acceptance: Is the program correct according to its specification?! This software does not evolve.
! A change to the specification defines a new problem, hence a new program
! P-type Programs (“Problem-solving”)! imprecise statement of a real-world problem! acceptance: Is the program an acceptable solution to the problem?! This software is likely to evolve continuously
! because the solution is never perfect, and can be improved! because the real-world changes and hence the problem changes
!E-type Programs (“Embedded”)! A system that becomes part of the world that it models! acceptance: depends entirely on opinion and judgement! This software is inherently evolutionary
! changes in the software and the world affect each other
Source: Adapted from Lehman 1980, pp1061-1063
3
University of Toronto Department of Computer Science
© 2001, Steve Easterbrook
formalstatementof problem
PROGRAM
solution
realworld
controls theproduction
of
providesmaybe ofinterest to
mayrelate
to realworld
requirementsspecification
PROGRAM
abstractview of world
solution
compare change
change
real world
PROGRAM
abstractview of worldrequirements
specification
model
change
S-type
P-type
E-type
Source: Adapted from Lehman 1980, pp1061-1063
4
University of Toronto Department of Computer Science
© 2001, Steve Easterbrook
Laws of Program Evolution!Continuing Change
! Any software that reflects some external reality undergoes continual change or becomes progressively less useful
! The change process continues until it is judged more cost effective to replace the system entirely
! Increasing Complexity! As software evolves, its complexity increases…
! …unless steps are taken to control it.
!Fundamental Law of Program Evolution! Software evolution is self-regulating with statistically determinable trends
and invariants
!Conservation of Organizational Stability! During the active life of a software system, the work output of a
development project is roughly constant (regardless of resources!)
!Conservation of Familiarity! During the active life of a program the amount of change in successive
releases is roughly constant
Source: Adapted from Lehman 1980, pp1061-1063. See also, van Vliet, 1999, Pp59-62
Program Types: P
• P-type programs
• “problem-solving”
• problem imperfectly models a real-world task
• qualitative acceptance
• such software probably evolves continuously
M.M.Lehman, Programs, Life Cycles and Laws of Software Evolution, IEEE 68(9), 1980.
Program Types: P
Steve Easterbrook, http://www.cs.toronto.edu/~sme/CSC444F/slides/L20-SoftwareMaintenance.pdf
1
University of Toronto Department of Computer Science
© 2001, Steve Easterbrook
Lecture 20:Software Maintenance
!Software Evolution! Software types! Laws of evolution
!Maintaining software! types of maintenance! challenges of maintenance
!Reengineering and reverse engineering
!Software Reuse
2
University of Toronto Department of Computer Science
© 2001, Steve Easterbrook
Program Types!S-type Programs (“Specifiable”)
! problem can be stated formally and completely! acceptance: Is the program correct according to its specification?! This software does not evolve.
! A change to the specification defines a new problem, hence a new program
! P-type Programs (“Problem-solving”)! imprecise statement of a real-world problem! acceptance: Is the program an acceptable solution to the problem?! This software is likely to evolve continuously
! because the solution is never perfect, and can be improved! because the real-world changes and hence the problem changes
!E-type Programs (“Embedded”)! A system that becomes part of the world that it models! acceptance: depends entirely on opinion and judgement! This software is inherently evolutionary
! changes in the software and the world affect each other
Source: Adapted from Lehman 1980, pp1061-1063
3
University of Toronto Department of Computer Science
© 2001, Steve Easterbrook
formalstatementof problem
PROGRAM
solution
realworld
controls theproduction
of
providesmaybe ofinterest to
mayrelate
to realworld
requirementsspecification
PROGRAM
abstractview of world
solution
compare change
change
real world
PROGRAM
abstractview of worldrequirements
specification
model
change
S-type
P-type
E-type
Source: Adapted from Lehman 1980, pp1061-1063
4
University of Toronto Department of Computer Science
© 2001, Steve Easterbrook
Laws of Program Evolution!Continuing Change
! Any software that reflects some external reality undergoes continual change or becomes progressively less useful
! The change process continues until it is judged more cost effective to replace the system entirely
! Increasing Complexity! As software evolves, its complexity increases…
! …unless steps are taken to control it.
!Fundamental Law of Program Evolution! Software evolution is self-regulating with statistically determinable trends
and invariants
!Conservation of Organizational Stability! During the active life of a software system, the work output of a
development project is roughly constant (regardless of resources!)
!Conservation of Familiarity! During the active life of a program the amount of change in successive
releases is roughly constant
Source: Adapted from Lehman 1980, pp1061-1063. See also, van Vliet, 1999, Pp59-62
Program Types: E
• E-type programs
• “embedded”
• solution becomes a part of the world
• acceptance is subjective
• such software is inherently evolutionaryM.M.Lehman, Programs, Life Cycles and Laws of Software Evolution, IEEE 68(9), 1980.
Program Types: E
Steve Easterbrook, http://www.cs.toronto.edu/~sme/CSC444F/slides/L20-SoftwareMaintenance.pdf
1
University of Toronto Department of Computer Science
© 2001, Steve Easterbrook
Lecture 20:Software Maintenance
!Software Evolution! Software types! Laws of evolution
!Maintaining software! types of maintenance! challenges of maintenance
!Reengineering and reverse engineering
!Software Reuse
2
University of Toronto Department of Computer Science
© 2001, Steve Easterbrook
Program Types!S-type Programs (“Specifiable”)
! problem can be stated formally and completely! acceptance: Is the program correct according to its specification?! This software does not evolve.
! A change to the specification defines a new problem, hence a new program
! P-type Programs (“Problem-solving”)! imprecise statement of a real-world problem! acceptance: Is the program an acceptable solution to the problem?! This software is likely to evolve continuously
! because the solution is never perfect, and can be improved! because the real-world changes and hence the problem changes
!E-type Programs (“Embedded”)! A system that becomes part of the world that it models! acceptance: depends entirely on opinion and judgement! This software is inherently evolutionary
! changes in the software and the world affect each other
Source: Adapted from Lehman 1980, pp1061-1063
3
University of Toronto Department of Computer Science
© 2001, Steve Easterbrook
formalstatementof problem
PROGRAM
solution
realworld
controls theproduction
of
providesmaybe ofinterest to
mayrelate
to realworld
requirementsspecification
PROGRAM
abstractview of world
solution
compare change
change
real world
PROGRAM
abstractview of worldrequirements
specification
model
change
S-type
P-type
E-type
Source: Adapted from Lehman 1980, pp1061-1063
4
University of Toronto Department of Computer Science
© 2001, Steve Easterbrook
Laws of Program Evolution!Continuing Change
! Any software that reflects some external reality undergoes continual change or becomes progressively less useful
! The change process continues until it is judged more cost effective to replace the system entirely
! Increasing Complexity! As software evolves, its complexity increases…
! …unless steps are taken to control it.
!Fundamental Law of Program Evolution! Software evolution is self-regulating with statistically determinable trends
and invariants
!Conservation of Organizational Stability! During the active life of a software system, the work output of a
development project is roughly constant (regardless of resources!)
!Conservation of Familiarity! During the active life of a program the amount of change in successive
releases is roughly constant
Source: Adapted from Lehman 1980, pp1061-1063. See also, van Vliet, 1999, Pp59-62
LEHMAN’S LAWS OF SOF TWARE EVOLUTION
Lehman’s Laws (1/8)
• Continuing Change
• E-system rots unless adapted
• the process never stops
• (true for P-systems as well)
M.M.Lehman, Programs, Life Cycles and Laws of Software Evolution, IEEE 68(9), 1980.
Lehman’s Laws (2/8)
• Increasing Complexity
• E-system becomes more complex
• evolving means complicating
• (unless we do something)
M.M.Lehman, Programs, Life Cycles and Laws of Software Evolution, IEEE 68(9), 1980.
Lehman’s Laws (3/8)
• Self-regulation
• E-system evolution is SRP
• obeys certain statistical laws
• (distribution close to normal)
M.M.Lehman, Programs, Life Cycles and Laws of Software Evolution, IEEE 68(9), 1980.
Lehman’s Laws (4/8)
• Conservation of Organisational Stability
• E-system dev activity is invariant
• throughout its lifetime
• (does not depend on resources)
M.M.Lehman, Programs, Life Cycles and Laws of Software Evolution, IEEE 68(9), 1980.
Lehman’s Laws (5/8)
• Conservation of Familiarity
• E-system changes per release: invariant
• throughout its lifetime
• (too little: bored; too much: overwhelmed)
M.M.Lehman, Programs, Life Cycles and Laws of Software Evolution, IEEE 68(9), 1980.
Lehman’s Laws (6/8)
• Continuing Growth
• E-system must add features over time
• to keep users satisfied
• (expectations creep)
M.M.Lehman, J.F.Ramil, P.D.Wernick, D.E.Perry, W.M.Turski, Metrics and Laws of Software Evolution — The Nineties View, METRICS, 1997.
Lehman’s Laws (7/8)
• Declining Quality
• E-system perceived quality declines
• internal as well as external
• (unless constantly maintained)
M.M.Lehman, J.F.Ramil, P.D.Wernick, D.E.Perry, W.M.Turski, Metrics and Laws of Software Evolution — The Nineties View, METRICS, 1997.
Lehman’s Laws (8/8)
• Feedback System
• E-system evolution is a feedback system
• multi-level
• multi-loop
• multi-agentM.M.Lehman, J.F.Ramil, P.D.Wernick, D.E.Perry, W.M.Turski,
Metrics and Laws of Software Evolution — The Nineties View, METRICS, 1997.
Simonyi’s Law Wish
• Costs proportional to
• SE: entities * aspects (impl)
• DSL: entities + aspects (impl)
• Goal: entities + aspects (domain)
Charles Simonyi, The Magic of Software, MoDELS 2013 keynote.
MAINTENANCE
So!ware engineering
Jurgen Vinju, http://homepages.cwi.nl/~jurgenv/teaching/evolution1314/slides/intro-evol.pdf
16Introduction to Software Evolution
Work distribution of programmers
Year New projects Enhancements Repairs Total
1950 90 3 7 100
1960 8,500 500 1,000 10,000
1970 65,000 15,000 20,000 100,000
1980 1,200,000 600,000 200,000 2,000,000
1990 3,000,000 3,000,000 1,000,000 7,000,000
2000 4,000,000 4,500,000 1,500,000 10,000,000
2010 5,000,000 7,000,000 2,000,000 14,000,000
2020 7,000,000 11,000,000 3,000,000 21,000,000
Now: 60% of the programmers work on enhancement and repair
In 2020: only 30% of all programmers will work on new software
Definition of maintenance
• Modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment
IEEE 1219, 1993
Maintenance phases
• Introductory • user support!
• Growth • correcting faults!
• Maturity • enhancements!
• Decline • technology replacement!
Hans van Vliet, Software Engineering: Principles and Practice. Jon Wiley & Sons, 2009.
Types of maintenance
• Corrective
• Adaptive
• Perfective
• PreventiveB.P.Lientz, E.B.Swanson, Software Maintenance Management, A Study of the Maintenance of Computer
Application Software in 487 Data Processing Organizations, 1980.
50%
4%
25%
21%
Types of maintenance
• Corrective
• Adaptive
• Perfective • user enhancements • efficiency • other
• PreventiveB.P.Lientz, E.B.Swanson, Software Maintenance Management, A Study of the Maintenance of Computer
Application Software in 487 Data Processing Organizations, 1980.
3%4%
43%
4%
25%
21%
Top 5 problems
• Quality of documentation
• User demand for enhancements
• Competing demands for maintainers’ time
• Meeting scheduled commitments
• Turnover in user organisationsS.L.Pfleeger, Software Engineering: Theory and Practice, Prentice Hall, 1998.
Is it hopeless?
• Higher quality • less (c) maintenance
• Anticipating changes • less (a&p) maintenance
• Better tuning to user needs • less (p) maintenance
• Less code • less (*) maintenance
Maurice ter Beek, http://www.liacs.nl/~mtbeek/se-ma.pdf
Legacy systems
• Size and complexity
• out of control
• Knowledge
• “in the basement”
Typical so!ware system
• Implemented with a language cocktail
• Glue languages: JCL, Make, …
• Some parts never run/accessed
• Some source code lost/incomplete
• Documentation is incomplete or obsoleteJurgen Vinju, http://homepages.cwi.nl/~jurgenv/teaching/evolution1314/slides/intro-evol.pdf
~1-100 &'()
Forward Engineering
Jurgen Vinju, http://homepages.cwi.nl/~jurgenv/teaching/evolution1314/slides/intro-evol.pdf
46Introduction to Software Evolution
Forward Engineering
ImplementationImplementation
SpecificationSpecification
RequirementsRequirements
GoalsGoals
47Introduction to Software Evolution
Reverse Engineering
ImplementationImplementation
SpecificationSpecification
RequirementsRequirements
GoalsGoals
ImplementationImplementation
SpecificationSpecification
RequirementsRequirements
GoalsGoals
Legacy system Renovated system
Reverse Engineering
Jurgen Vinju, http://homepages.cwi.nl/~jurgenv/teaching/evolution1314/slides/intro-evol.pdf
So!ware renovation
Jurgen Vinju, http://homepages.cwi.nl/~jurgenv/teaching/evolution1314/slides/intro-evol.pdf 51Introduction to Software Evolution
Renovation = Analysis + Transformation
Legacy codeLegacy code
Renovated systemRenovated system
AnalysisAnalysis
TransformationTransformation
Documentation, object model, types,metrics, visualization, components, ...
Documentation, object model, types,metrics, visualization, components, ...
Transformation rules
Transformation rules
Human insight +
tools
Reverse Engineering and Design Recovery
Elliot J. Chikofsky, James H. Cross II: Reverse Engineering and Design Recovery: A Taxonomy. IEEE Software 7(1), 1990.
Design Implementation
~:::~:~~~~~~ ”
Rastnlcturing Restructuring restructuring
F&II~~ 1. Relationship between terms. Reverse engineering and related processes are transformations between or within abstraction levels, represented here in terms of life- cycle phases.
as being conducted by someone other than the developer, ‘without the benefit of any of the original drawings . . . for the purpose of making a clone of the original hardware system....”
In applying these concepts to software systems, we find that many of these ap proaches apply to gaining a basic un- derstanding of a system and its structure. However, while the hardware objective traditionally is to duplicate the system, the software objective is most often to gain a sufficient design-level understanding to aid maintenance, strengthen enhance- ment, or support replacement.
life cycles and abstractions
well to the concept of abstraction levels. Earlier stages of systems planning and re- quirements definition involve expressing higher level abstractions of the system being designed when compared to the im- plementation itself.
These abstractions are more closely re- lated to the business rules of the enter- prise. They are often expressed in user terminology that has a one-tomany rela- tionship to specific features of the tin- ished system. In the same sense, a blue- print is a higher level abstraction of the building it represents, and it may docu- ment only one of the many models (elec- trical, water, heating/ventilation/air con- ditioning, and egress) that must come together.
To adequately describe the notion of software forward and reverse engineer- ing, we must first clarify three dependent concepts: the existence of a life-cycle model, the presence of a subject system, and the identification of abstraction lev- els.
It is important to distinguish between levelsof abstraction, a concept that crosses conceptual stages of design, and degrees of abstraction within a single stage. Span- ning life-cycle phases involves a transition from higher abstraction levels in early stages to lower abstraction levels in later stages. While you can represent informa- tion in any life-cycle stage in detailed form (lower degree of abstraction) or in more summarized or global forms (higher de- gree of abstraction), these definitions em- phasize the concept of levelsof abstraction between life-cycle phases.
Softwaremaintenawe Definitiins The ANSI definition of software mainte-
nance is the “modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a changed envi- ronment,” according to ANSI/IEEE Std 729-1983.
Usually, the system’s maintainers were not its designers, so they must expend many resources to examine and learn about the system. Reverse-engineering tools can facilitate this practice. In this context, reverse engineering is the part of the maintenance process that helps you understand the system so you can make appropriate changes. Restructuring and reverse engineering also fall within the global definition of software mainte- nance. However, each of these three pro cesses also has a place within the contexts of building new systems and evolutionary development
We assume that an orderly lifecycle model exists for the software-develop ment process. The model may be repre- sented as the traditional waterfall, as a spi- ral, or in some other form that generally can be represented as a directed graph. While we expect there to be iteration within stages of the life cycle, and perhaps even recursion, its general directed-graph nature lets us sensibly define forward (downward) and backward (upward) ac- tivities.
For simplicity, we describe key terms using only three identified life-cycle stages with clearly different abstraction levels, as Figure 1 shows:
The subject system may be a single pro gram or code fragment, or it may be a complex set of interacting programs, job control instructions, signal interfaces, and data files. In forward engineering, the subject system is the result of the develop ment process. It may not yet exist, or its existing components may not yet be uni- ted to form a system. In reverse engineer- ing, the subject system is generally the starting point of the exercise.
In a life-cycle model, the early stages deal with more general, implementation- independent concepts; later stages em- phasize implementation details. The transition of increasing detail through the forward progress of the life cycle maps
l requirements (speciftcation of the problem being solved, including objec- tives, constraints, and business rules),
l design (specification of the solution), and
l implementation (coding, testing, and delivery of the operational system).
Forward engineering. Forward engi- neering is the traditional process of mov- ing from high-level abstractions and logi- cal, implementation-independent designs to the physical implementation of a system.
While it may seem unnecessary - in view of the long-standing use of design and development terminology- to intro- duce a new term, the adjective “forward”
14 IEEE Software
Refactoring
• Rewriting code without changing behaviour
• Built-in in many IDEs
• Remove code smells
• long method, ugly name, many arguments,
• middle man, feature envy, shotgun surgery
M.Fowler, Refactoring: Improving the Design of Existing Code, Addison-Wesley, 1999.
CONCLUSION
Summary
• Software evolves
• Software evolution obeys certain laws
• Software rots in time
• 70% of software engineers do maintenance
• Many software systems are legacy
• Forward, reverse and re-engineering
• Sources of information/inspiration
• given on the bottom of each slide
• Slides?
• http://grammarware.net/slides/2014/maintenance.pdf
• Fonts?
• Avdira — George Douros, Unicode Fonts for Ancient Scripts, 2009.
• Finger Paint — Ralph Oliver du Carrois, 2013.
• Wild Honey — Denis Sherbak, 2013
• Questions? Ask or email or tweet.