.

COMP33812: Software Evolution

Andy Carpenter
School of Computer Science
(Andy.Carpenter@manchester.ac.uk)
 G&T: 3.3 .

Why Evolve (Change) Software?

Bug Fix
Corrective change
Enhancement request
Perfective change
Environmental change
Adaptive change
Refactoring
Preventive change
Repay software debt
Which are justifiable?
COMP33812: Software Evolution Review 2
 G&T: 3.3 .

Types of Maintenance
• Corrective change 17%
– requirements unchanged, code changes
• Adaptive change
18%
– business or technical environment changes
• Perfective change
65%
– new stories (enhancement)
• Preventive change 0%
– refactoring, code cleanup
• Which is the most common?
– Study by Lientz and Swanson (1980)
• Agile equivalents?

COMP33812: Software Evolution Review 3

 .

Software Change is Risky

On
OnMonday,
Monday,Mr. Mr. But on Tuesday,
White’s
White’sreports
reports every *!*?!
all
allrun
run report exits with
satisfactorily
satisfactorily an error message!

The Killer Problem is the hidden

(one way) dependency

COMP33812: Software Evolution Review 4

 .

Code Reading: How is it Done?

Existing Acquired
Knowledge Knowledge

Application Application
domain domain

Mental Mental
model of model of
s/w
Code Reading s/w

General General

?
Programming Programming

COMP33812: Software Evolution Part I: System Comprehension - Introduction 5

 .

Sources of Information?
• Documentation; design (intension), maintenance
• Source code, build process; must reverse engineer
• Test cases and results (expected operation)
• logs (access & error); info about dynamics of system
• Developers; can give intension of system
• Users; see what does; speak in domain terms
• Testers; see system like users, speak your lang
• Technical support
• Stakeholders; context of use, goals
• Business experts; business rules implemented
• Which sources are the most reliable?
COMP33812: Software Evolution Part I: System Comprehension - Introduction 6
 .

Top-Down: Exploit Beacons

• Cues that suggest instant hypotheses
• Should stand out (be visible at a glance)
• Examples
– Var names: “num” and “ttl”
– Procedure names: “process_mgr”
– Data structures: “next” & “prev” suggest linked list
– Class/file names: BasketFactory, DiscountCalculator
– Embedded languages: SQL code
– API’s used: JPA, ORM

COMP33812: Software Evolution System Comprehension - Code Reading 7

 .

Bottom-Up Code Reading

• Applies when class/method/procedure/file/etc to be
examined already identified
• Skim over code, looking for recognisable idioms
– e.g. the “swap” idiom: t = x; x = y; y = t;
• Form abstract view of the task of the idiom
– e.g. smaller number swapped with larger one
• Combine recognised units to make conjectures about
ever larger sections of the code
– e.g. this swap inside loop over an array could be a sort

COMP33812: Software Evolution System Comprehension - Code Reading 8

 .

For unfamiliar languages

• Follow the normal code reading process, plus
• Use additional class of hypothesis (about language), e.g.
– “I guess that this type is an integer variable type”
– “This group of keywords looks like an if-then-else
statement”
– “It looks as though the `&&’ operator is a logical AND
operator with McCarthy semantics”

if (ptr != null if (ptr != null) {

&& ptr.value > x) { if (ptr.value > x) {
… …
} }
}

COMP33812: Software Evolution System Comprehension - Code Reading 9

 .

How do we Automate Slicing?

• Many algorithms proposed
– Ottenstein and Ottenstein (1984)
• Several layers of static analysis
– Data Dependency Graph (DDG)
– Control Flow Dependency Graph (CFG)
– Control Dependency Graph (CDG)
• from CFG
– Program Dependence Graph (PDG)
• from DDG + CDG
– Slice created from PDG

COMP33812: Software Evolution System Comprehension - Tool Support 10

 .

Evolutionary Design: Where?

Local System System

code code component
level level level

Refactoring Test-driven Incremental

design migration

Open question: can these measures

(especially TDD) lead to a principled,
high-quality design, according to
current notions?

COMP33812: Software Evolution Evolutionary Design: Introduction 11

 .

Refactoring

Preventive
maintenance
Who done?
How often
done?
In eXtreme
Programming Removing
bad practice Backdoor
refactoring

Feasible with
IDE support
extensive tests
COMP33812: Software Evolution Evolutionary Design: Introduction 12
 .

Evolving Legacy Systems

• Perform preventive maintenance to
improve maintainability

Costs?

• Modernise the system Risks?

Benefits?

• Rebuild the system from scratch (as

if current system did not exist)

COMP33812: Software Evolution Evolutionary Design: System Scale 13

 .

Incremental Migration Example

Customer Marketing Batch Customer Marketing

Service UI UI Cust Entry Service UI UI

Batch
Customer Customer List
Customer
Mgt Mgt Mgt
Entry

File handling
RDBMS
routines

Source Decomposable Target

Architecture CustDB architecture? CustDB Architecture
COMP33812: Software Evolution Evolutionary Design: System Scale 14

COMP33812: Software Evolution Evolutionary Design: System Scale 14

 .

Data as an Asset
• Data as long-term organisational memory
– customer understanding/management
– scenario modelling, data mining
• Data is “declarative”
– can support new applications, including applications
not envisaged when the data was first captured
• Schema often models core domain concepts
• Raw data may be even more revealing than the DB
structure

COMP33812: Software Evolution Data Evolutiion - Challenges 15

 .

Migration/Replication Plan

Extract what? Extract when?

Extract how?

Transformations?
Transform where?

Freshness?

COMP33812: Software Evolution Evolutionary Design: Data Evolution 16

 .

Extract when?

Legacy Target
DB DB

Extraction Window
2.00am to 5.00am Mondays Average of 1,000,000 records
to transfer @ 0.02sec/record
= 5 hrs 34 mns
Strategy?

Snapshot + By domain Horizontal

One step
updates concept partition

Zero downtime?
COMP33812: Software Evolution Evolutionary Design: Data Evolution 17
 .

Transform where?
Push
Legacy Target
DB ETL DB

Pull
Legacy Target
DB ETL DB

Remote

Legacy Target
DB ETL DB
COMP33812: Software Evolution Evolutionary Design: Data Evolution 18
 .

New Software Techniques

• AOP
• Dependency Injection
• DSL/Model-driven

COMP33812: Software Evolution Review 19