SOFTWARE MAINTENANCE

1
SOFTWARE MAINTENANCE

• PART V
• MAINTENANCE TECHNIQUES

2
Maintenance Techniques

• Program comprehension
• Reverse engineering
• Re-engineering
• Re-structuring
• Re-documentation
• Legacy system
• Maintenance tools

3
Program Comprehension

• Program comprehension means having the knowledge
  of what the system does, how it relates to its
  environment, identifying where in the system
  changes are to be affected, and having an
  in-depth knowledge of how the parts to be
  corrected (Takang Grubb, 1996).
• Keywords
• Knowledge (about what??)
• the system, relations, effect of the changes,
  modified parts.

4
Program Comprehension in detail

• What to be understood?
• Problem of the domain
• Effects of the execution
• Relations of cause-effect
• Relations of product environment
• Features of decision-support.

5
Program Comprehension in detail

• Members of the team manager, analyst, designer,
  programmer.
• Strategies top-down model, bottom-up, etc.

6
Problems/Issues with Program Comprehension

• The comprehension process takes up a great deal
  of the total time spent on carrying out the
  change.
• The reasons
• Incorrect, out-date or non-existent
  documentation,
• The complexity of the system,
• Lack of sufficient domain knowledge on the part
  of the maintainer.

7
Solution??

• Abstract from source code relevant information
  about the system, such as the specification and
  design, in a form that promotes understanding.
• How?
• ? using reverse engineering.

8
Reverse Engineering

• Definition the process of analyzing a subject
  system to identify the systems components and
  their interrelationships and to create
  representations of the system in another form or
  at higher level of abstraction (Chikofsky
  Cross, 1990).

9
(..cont) Reverse Engineering

• RE does not change the program.
• It simply provides a way for easier
  implementation of the desired changes.
• Changes are implemented using techniques such as
  forward engineering, re-structuring, and
  re-engineering.

10
(..cont) Reverse Engineering

• Objectives of RE
• To recover lost information
• To facilitate migration between platforms
• To improve or provide documentation
• To provide alternative views
• To extract reusable components
• To reduce maintenance effort

11
Process of Reverse Engineering

• RE as a process is difficult to define in its
  rigorous terms because it is a new and rapidly
  evolving field.
• Traditionally, RE has been viewed as a two step
  process
• Information extraction
• Abstraction

12
(..cont) Process of Reverse Engineering

• Information extraction analyses the subject
  system artifacts primarily the source code to
  gather raw data.
• Information abstraction creates user-oriented
  documents and views.

13
(..cont) Process of Reverse Engineering

• IEEE1219-98 suggests that the process of RE
  evolves through 6 steps
• Dissection of source code into formal units
• Semantic description of formal units and creation
  of functional units
• Description of links for each unit (input/output
  schematics of units)
• Creation of a map of all units and successions of
  consecutively connected units (linear circuits)
• Declaration and semantic description of system
  applications
• Creation of an anatomy of the system.

Unit level
System level
14
Supporting Techniques

• Reverse engineering is passive
• It does not change the software in another form
  or result in new software.
• It produces call graphs and control flow graphs
  from source code.
• The modification can then be implemented through
  the supporting techniques
• Re-engineering, re-structuring, re-documentation.

15
Re-Engineering - Definition

• Re-engineering is the examination and alteration
  of a subject system to reconstitute it in a new
  form and subsequent implementation of the new
  form (Chikofsky Cross, 1990).

16
Re-Engineering - Definition

• Another definition by Arnold (1993)
• Software re-engineering is any activity that
• Improves ones understanding of software
• Or, prepares or improves the software itself,
  usually for increased maintainability,
  reusability or evolve ability.

17
Reasons for Re-Engineering (Arnold, 1993)

• Re-engineering can help reduce an organizations
  evolution risk
• Re-engineering can help an organization recoup
  its investment in software
• Re-engineering can make software easier to
  change
• Re-engineering is a big business
• Re-engineering capability extends CASE toolsets
• Re-engineering is a catalyst for automatic
  software maintenance
• Re-engineering is a catalyst for applying AI
  techniques to solve software re-engineering
  problems.

18
Steps for Re-Engineering

• Reverse engineering is applied to the target
  system so as to understand it and represent it in
  a new form
• Forward engineering is applied, implementing and
  integrating any new requirements, thereby giving
  rise to a new and enhanced system.

19
Forward Engineering

• Forward engineering is the opposite of reverse
  engineering.
• It refers to the traditional software development
  approach proceeding from requirements to
  detailed implementation via the design of the
  system.

20
Re-Structuring

• This involves transforming a system from one
  representational form to another at the same
  relative level of abstraction without a change in
  its functionality or semantics.

21
Types of Re-Structuring

• Control-flow-driven re-structuring
• Imposition of a clear control structure within
  the source code.
• Efficiency-driven re-structuring
• Re-structuring the function or algorithm to make
  it more efficient.
• Adaptive-driven re-structuring
• Changing the coding style to adapt to a new
  programming language or new operating environment.

22
Re-Documentation

• Creation of a semantically equivalent
  representation within the same relative
  abstraction level (Chikofsky Cross, 1990).
• Goal
• To create alternative views of the system
• To improve current documentation
• To generate documentation for a newly modified
  program.

23
Other Supporting Techniques for RE

• Design recovery
• Specification recovery

24
Legacy System - Definition

• From Bennett, 1995
• Large software systems that we dont know how to
  cope with but that are vital to our organization.
• From Brodie Stonebraker, 1995
• Information system that significantly resists
  modifications and evolution to meet new and
  constantly changing business requirements.

25
Legacy System

• A scenario that highlights the high cost of
  software maintenance.
• These are systems developed over the past 20-30
  years (or even more) to meet the growing demand
  for new products and services.
• The structure has often been degraded by a long
  history of changes and adaptations and neither
  consistent documentation nor adequate test suites
  are available.

26
How to Manage the Legacy System

• Discarding the legacy system and building a
  replacement system
• Freezing the system and using it as a component
  of a new larger system
• Carrying on maintaining the system for another
  period
• Modifying the system to operate in the new
  requirement or added requirement, functions and
  operations.

27
Modifying/Maintaining the Legacy System

• Simplification of the system
• Reduction of size and complexity.
• Preventive maintenance
• Re-documentation, re-structuring, re-engineering.
• Extra-ordinary processes of adaptive maintenance
• Interface modification, wrapping and migration.

28
Factors to Assess the Value of Legacy System

• Obsolescence age of the system.
• Deterioration maintenance cost.
• Decomposability how well system components are
  reflected in its architecture.
• Business value complexity of the business
  process to achieve efficiency in the business
  operation.

29
Maintenance Tools

• A software maintenance tool is a artifact that
  supports a software maintainer in performing a
  task.
• Used to simplifies the tasks and increases
  efficiency and productivity.
• Criteria for selecting the right tool for the
  task capability, features, cost/benefit,
  platform, programming language, ease of use,
  openness of architecture, stability of vendor,
  and organizational culture.

30
Criteria for Selecting Tool

• ?Think of the details of every criteria!!!

31
Reverse Engineering Tools

• Mainly consist of visualization tools, which
  assist the programmer in drawing a model of the
  system.
• Example
• Program slicer static analyzer
• Dynamic analyzer
• Cross-referencer
• Dependency analyzer