topic r software maintenance, evolution, program comprehension, and reverse engineering seg4110...
TRANSCRIPT
TOPIC RSoftware Maintenance, Evolution, Program Comprehension,
and Reverse Engineering
SEG4110Advanced Software Design and Reengineering
SEG4110 - Topic R - Software Maintenance
2
Software Maintenance
• 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
ANSI/IEEE Standard 729-1983
SEG4110 - Topic R - Software Maintenance
3
Software Maintenance Types 1
Corrective maintenance: •Fixing faults that cause the system to fail
Adaptive maintenance: •Making changes in existing software to accommodate a changing environment
Enhancement•Adding new features
SEG4110 - Topic R - Software Maintenance
4
Software Maintenance Types 2
Perfective maintenance•Making improvements to the existing system without effecting end-user functionality— To make it easier to extend and add new features in the future
— Also called re-engineering— Refactoring is a one type of perfective maintanance
Preventive maintenance•Preventing failures by fixing defects in advance of failures
•A kind of perfective maintenance•Key examples: Y2K and Daylight Savings Time adjustments
SEG4110 - Topic R - Software Maintenance
5
Software Maintenance Steps 1
Understand the existing system•Study whatever form of documentation exists about the system to be modified—Often the only reliable source of information is the source code
•Use tools to recover the high-level design models of the system
SEG4110 - Topic R - Software Maintenance
6
Software Maintenance Steps 2
Define the maintenance objectives• Set the requirements
Analysis • Evaluate alternatives for handling
the modification— Estimate the costs and benefits
of the alternative modifications
— Perform impact analysis- Determine the effect of the change
on the rest of the system
SEG4110 - Topic R - Software Maintenance
7
Software Maintenance Steps 3
Design, implement, and test the changes
Revalidate• Running regression tests to make
sure that the unchanged code still works and is not adversely affected by the new changes
SEG4110 - Topic R - Software Maintenance
8
Software Maintenance Steps 4
Train •Inform users of the changes
Convert and release •Generate and release/install a new version with the modified parts
•May involve migrating database schema changes and data at the same time
SEG4110 - Topic R - Software Maintenance
9
Software Evolution 1
Evolution: a term that is now often preferred as a replacement for ‘maintenance’
Lehman’s 8 Laws of Software Evolution•1. Continuing Change: A system must be continually adapted else it becomes progressively less satisfactory in use
•2. Increasing Complexity: As a system is evolved its complexity increases unless work is done to maintain or reduce it
•3. Self Regulation: Global system evolution processes are self-regulating
•4. Conservation of Organizational Stability: Average activity rate in an evolution process tends to remain constant over system lifetime or segments of that lifetime
SEG4110 - Topic R - Software Maintenance
10
Software Evolution 2Lehman’s 8 laws continued•5. Conservation of Familiarity: In general, the average incremental growth, or growth rate trend, tends to decline
•6. Continuing Growth: The functional capability of systems must be continually increased to maintain user satisfaction over the system lifetime
•7. Declining Quality: Unless rigorously adapted to take into account changes in the operational environment, the quality of a system will appear to decline as it is evolved
•8. Feedback System: Evolution processes are multi-level, multi-loop, multi-agent feedback systems
SEG4110 - Topic R - Software Maintenance
11
Program Comprehension
Program comprehension:•The discipline concerned with studying the way software engineers understand programs
Objective of those studying program comprehension:•design tools that will facilitate the understanding of large programs
SEG4110 - Topic R - Software Maintenance
12
Program Comprehension Strategies 1
The bottom-up model:•Comprehension starts with the source code and abstracting from it to reach the overall comprehension of the system
•Steps:—Read the source code—Mentally group together low-level programming details (chunks) to build higher-level abstractions
—Repeat until a high-level understanding of the program is formed
SEG4110 - Topic R - Software Maintenance
13
Program Comprehension Strategies 2
The top down model:• Comprehension starts with a general
idea, or hypothesis, about how the system works- Often obtained from a very quick look at what components exist
• Steps- First formulate hypotheses about the system functionality
- Verify whether these hypotheses are valid or not- Create other hypotheses, forming a hierarchy of hypotheses
- Continue until the low-level hypotheses are matched to the source code and proven to be valid or not
SEG4110 - Topic R - Software Maintenance
14
Program Comprehension Strategies 3
The Integrated Model:• Combines the top down and bottom up
approaches • Empirical results show that
maintainers tend to switch among the different comprehension strategies depending on
—The code under investigation —Their expertise with the system
SEG4110 - Topic R - Software Maintenance
15
Partial Comprehension
Usually is not necessarily to understand the whole system if only part of it needs to be maintained •But a high fraction of bugs arise from not understanding enough!
Most software maintenance tasks can be met by answering seven basic questions:•How does control flow reach a particular location?•Where is a particular subroutine or procedure invoked?
•What are the arguments and results of a function?•Where is a particular variable set, used or queried?•Where is a particular variable declared?•What are the input and output of a particular module?
•Where are data objects accessed?
SEG4110 - Topic R - Software Maintenance
16
Reverse Engineering
• The process of analyzing a subject system—to identify the system’s components and their inter-relationships
—and to create representations of the system, in another form, at a higher level of abstraction”
Chikofsky and Cross
SEG4110 - Topic R - Software Maintenance
17
Two main levels of reverse engineering
Binary reverse engineering•Take a binary executable
— Recover source code you can then modify•Useful for companies that have lost their source code
•Used extensively by hackers•Can be used legally, e.g. to enable your system to interface to existing system
•Illegal in some contexts
Source code reverse engineering•Take source code
— Recover high level design information•By far the most widely performed type of reverse engineering
•Binary reverse engineers also generally do this too
SEG4110 - Topic R - Software Maintenance
18
Reverse Engineering Objectives 1
Cope with complexity: • Have a better understanding of
voluminous and complex systems• Extract relevant information and
leave out low-level details
Generate alternative views: • Enable the designers to analyze the
system from different angles
SEG4110 - Topic R - Software Maintenance
19
Reverse Engineering Objectives 2
Recover lost information: • Changes made to the system are
often undocumented; - This enlarges the gap between the design and the implementation
• Reverse engineering techniques retrieve the lost information
SEG4110 - Topic R - Software Maintenance
20
Reverse Engineering Objectives 3
Detect side effects: • Detect problems due to the effect a
change may have on the system before it results in failure
Synthesize higher-level abstractions
SEG4110 - Topic R - Software Maintenance
21
Reverse Engineering Objectives 4
Facilitate reuse• Detect candidate system components
that can be reused
SEG4110 - Topic R - Software Maintenance
22
Source code reverse engineering techniques
Program analysis•To be discussed in a separate module of this course
Program slicing
Design recovery
Architecture recovery
SEG4110 - Topic R - Software Maintenance
23
Program Slicing
A form of data flow analysis • concerned with analyzing all the statements in a
program that may- Affect the value of a given variable at a certain point during execution» Looking backward
- Be affected by the execution of a certain statement» Looking forward
Can be either static or dynamic
Static slicing • Considers all possible inputs
- the resulting slices are usually quite largeDynamic slicing• Extracting parts of the program that contribute to
the computation of the function according to a specific input
SEG4110 - Topic R - Software Maintenance
24
Design Recovery 1
Create design abstractions in order to understand what a program does, how it does it and why it does it
Examine multiple sources of knowledge including •the system documentation (if available), •the knowledge that the software engineers have of the system
SEG4110 - Topic R - Software Maintenance
25
Design Recovery 2
Difficult to perform on large systems that have undergone ad-hoc maintenance for a long period of time • Documentation of such legacy
systems is usually out of date • Original developers are usually no
longer working within the organization
SEG4110 - Topic R - Software Maintenance
26
Architecture Recovery
Aims to recover the overall system structure in terms of its high-level components and the way they interact
There are several techniques•Using human experts•Recognizing known patterns•Static and dynamic analysis•Clustering and data mining