SOF TWARE MAINTENANCE

SOF TWARE MAINTENANCE

Dr. Vadim Zaytsev Universiteit van Amsterdam

27 January 2014 CC-BY-SA

http://grammarware.net/index.html

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



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



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


4



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

http://www.cs.toronto.edu/~sme/CSC444F/slides/L20-SoftwareMaintenance.pdf

Program Types: P

• P-type programs

• “problem-solving”

• problem imperfectly models a real-world task

• qualitative acceptance

• such software probably evolves continuously


Program Types: P


1







!Software Reuse

2











3




PROGRAM

solution

realworld


of


mayrelate

to realworld


PROGRAM


solution

compare change

change

real world

PROGRAM


specification

model

change

S-type

P-type

E-type


4









and invariants







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


1







!Software Reuse

2











3




PROGRAM

solution

realworld


of


mayrelate

to realworld


PROGRAM


solution

compare change

change

real world

PROGRAM


specification

model

change

S-type

P-type

E-type


4









and invariants







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)



• Increasing Complexity

• E-system becomes more complex

• evolving means complicating

• (unless we do something)



• Self-regulation

• E-system evolution is SRP

• obeys certain statistical laws

• (distribution close to normal)



• Conservation of Organisational Stability

• E-system dev activity is invariant

• throughout its lifetime

• (does not depend on resources)



• Conservation of Familiarity

• E-system changes per release: invariant

• throughout its lifetime

• (too little: bored; too much: overwhelmed)



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


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


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

http://models2013.lcc.uma.es/downloads/charles.pdf

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

http://homepages.cwi.nl/~jurgenv/teaching/evolution1314/slides/intro-evol.pdf

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

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



Forward Engineering

ImplementationImplementation

SpecificationSpecification

RequirementsRequirements

GoalsGoals



Reverse Engineering




GoalsGoals




GoalsGoals

Legacy system Renovated system

Reverse Engineering



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 understanding 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 enhancement, or support replacement.

life cycles and abstractions

well to the concept of abstraction levels. Earlier stages of systems planning and requirements definition involve expressing higher level abstractions of the system being designed when compared to the implementation itself.

These abstractions are more closely related to the business rules of the enter- prise. They are often expressed in user terminology that has a one-tomany relationship 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 engineering, 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 levels.

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 information in any life-cycle stage in detailed form (lower degree of abstraction) or in more summarized or global forms (higher degree 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 environment,” 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 maintenance. 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 represented 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 engineering, 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 engineering 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.

Documents

SOF TWARE MAINTENANCE