2IS95 Seminar Software Engineering and Technology

2IS95 Seminar Software Engineering and Technology

Software Evolution

/ SET / W&I 22-04-2023 PAGE 2

Software Evolution. In the beginning.

• Royce 1970, “Waterfall model”.

Maintenance = bug fixes and minor adjustments

What are the main shortcomings of this model, in your opinion?

NB: Still in use anno 2009!2IS99 – Software evolution – Research topics in software evolution

/ SET / W&I 22-04-2023 PAGE 3

1974. Lehman’s laws.

• E-type system:• Systems operate in the real world (or address it)• They should be evolved since the real world evolves!

• Evolution laws:• E-type systems must be continually adapted else they

become progressively less satisfactory. • As an E-type system evolves its complexity increases

unless work is done to maintain or reduce it. • The quality of E-type systems will appear to be

declining unless they are rigorously maintained and adapted to operational environment changes.

• There are more…

2IS99 – Software evolution – Research topics in software evolution

/ SET / W&I 22-04-2023 PAGE 4

Macro look: Bennett and Rajlich (2000)

• Legacy system = the system that is still valuable despite its degraded quality.

• Migration = keep functionality, improve quality!• At what stage would you like to plan migration?

Loss of architectural

integrityPatches

too costly?

architecture decay


/ SET / W&I 22-04-2023 PAGE 5

Micro look: Yau et al. (1978)

• “Evolution” stage of the Bennett-Rajlich model• Refactoring = keep functionality, improve structure!• What is the difference between refactoring and

restructuring as defined in the Yau model?


/ SET / W&I 22-04-2023 PAGE 6

Going extreme

• Software evolution (iterative, incremental) + short time periods + high degree of collaboration + explicit accommodation of changing needs agile software development

Extreme programming is an example of agile.


/ SET / W&I 22-04-2023 PAGE 7

Software Evolution: Definition

• Look at the discussion so far.• How would you define “software evolution”?

• Software evolution is the set of activities, both technical and managerial, that ensures that software continues to meet organisational and business objectives in a cost effective way.


/ SET / W&I 22-04-2023 PAGE 8

Where do we start?

• Versioning repositories (CVS, SVN, …)• Software but what about models,

requirements, etc?

• Bug tracking systems• Change logs• Documentation• Mailing list archives

• Huge amount of information• Tooling is essential!


/ SET / W&I 22-04-2023 PAGE 9

Research Themes in Software Evolution: Science

• What is the nature of software evolution?• Lehman’s law:

• Evolution = a multi-loop, multi-level and multi-agent feedback system

• Understanding the evolution requires understanding• Human psychology• Social interaction• Organizational aspects• Economics and management• Legislation


/ SET / W&I 22-04-2023

Social interaction?

PAGE 10

Madey, Freeh and Tynan 2002

Linchpin developers create a social network!

/ SET / W&I 22-04-2023 PAGE 11

Research Themes in Software Evolution: Engineering• Technology, means and tools to direct, implement

and control software evolution.

• Some relevant questions:• What artefacts evolve?

− Requirements, design, code, tests, …• What can we learn from evolution so far?

− Quality change, software analysis• How evolvable are our artefacts? • How can we make them more evolvable?

− Migration, reverse engineering and reengineering• How is the evaluation implemented?

− Refactoring, architecture transformations• …


/ SET / W&I 22-04-2023 PAGE 12

What does evolve?


Evolution of different artefacts should be consistent.This is called the co-evolution problem.

Requirements evolution

Design (architecture) evolution. Data, code, documents, technology evolution

Tests and proofs evolution

/ SET / W&I 22-04-2023 PAGE 13

Consistency and co-evolution: Points of discussion

• What should co-evolve?• Code and database table definitions• Code and design documentation• Code and tests• Different code elements (packages, modules, files…)• …

• What constitutes inconsistency?• How to detect inconsistencies?• How to ensure absence of inconsistencies?


/ SET / W&I 22-04-2023

Co-evolution is time-dependent!

• Assumption: files committed together are co-evolving.

PAGE 14

D’Ambros, Gall, Lanza, and Pinzger. “Analysing Software Repositories to Understand Software Evolution”

/ SET / W&I 22-04-2023

Source/Test Files Co-evolution

PAGE 15

Added Source Modified Source Added Test Modified Test

Andy Zaidman, Bart Van Rompaey, Serge Demeyer and Arie van Deursen. “Mining Software Repositories to Study Co-Evolution of Production & Test Code”

/ SET / W&I 22-04-2023 PAGE 16

What can we learn from the evolution so far?

• What modules are stable?

• How to predict bugs from history?

• How to detect the architecture decay?

• What can we say about the project organisation?• Is there a major developer? (risk if she leaves)• Is there correlation between #bugs, productivity and

certain developers/teams?


Is there a major developer? Fractal Figures!

• Fractal value (between 0 and 1)

/ Mathematics and Computer Science PAGE 1722-04-2023

D’Ambros, M., Lanza, M., Gall, H.: Fractal figures: Visualizing development effort for CVS entities.

Area

/ SET / W&I 22-04-2023

Work assignment in an industrial project

PAGE 18

Number of Modification Requests (MRs) per file1 30

Some modules have many red(dish) files

Package

Module

File

Courtesy of Alexandru Telea

/ SET / W&I 22-04-2023

The “reddish” modules: Team assignment

PAGE 19

Team ATeam BTeam C

7 of the 11 red(ish) modules are assigned to the red team


/ SET / W&I 22-04-2023

Problems in the development?

PAGE 20

Time

MR

id ra

nge

(400

0 –

5000

; gro

uped

on

hund

reds

)

Ex: Number of file commits referring to MRs with IDs in the range [4700 - 4800)

In mid 2008, activity related to MRs addressed in 2006-2008 still takes place


/ SET / W&I 22-04-2023

How do systems evolve? Evolution patterns!

PAGE 21

Nakakoji et al. 2002

/ SET / W&I 22-04-2023 PAGE 22

How evolvable are our artefacts? Analysis!

• Resilience to change caused by• Bad readability• Bad structure• Code clones (see next slide)• High complexity• Insufficient abstractness (OO)• …

• How to detect these situations?• Metrics (discussed earlier)• Dependencies

Abstractness and Instability

0

0.2

0.4

0.6

0.8

1

0 0.2 0.4 0.6 0.8 1

Abstractness (A)

Inst

abili

ty (I

)

co

re.m

od

el.b

ase

co

re.m

od

el

co

re.a

ctio

n.c

on

figu

ratio

n.d

efa

ults

.he

lpe

r

co

re.s

erv

ice

co

re.a

ctio

n.c

on

figu

ratio

n.s

ale

sTa

x.h

elp

er

co

re.a

ctio

n.c

on

tracts

.me

terre

ad

s.h

elp

er

co

re.a

ctio

n.c

red

itap

p.a

pp

lica

tion

.he

lpe

r

co

re.a

ctio

n.c

red

itap

p.c

red

itde

cis

ion

.bu

rea

uS

um

ma

ry

co

re.in

teg

ratio

n.b

usin

essla

ye

r.cre

ditA

pp

lica

tion

.cre

ditD

ecis

ion

.bu

rea

us.p

ojo

co

re.a

ctio

n.c

red

itap

p.c

red

itde

cis

ion

.rac

co

re.a

ctio

n.c

red

itap

p.c

red

itde

cis

ion

.sco

ring

co

re.a

ctio

n.c

red

itap

p.h

elp

er

co

re.a

ctio

n.c

red

itap

p.im

po

rted

Cre

ditA

pp

s

co

re.in

teg

ratio

n.b

usin

essla

ye

r.SU

SI

co

re.a

ctio

n.p

ricin

g.a

pp

lica

tion

.he

lpe

r

co

re.a

ctio

n.q

uo

te.v

do

co

re.c

lien

t.we

b.fo

rm

co

re.c

riteria

co

re.h

crite

riaA

PI

co

re.in

teg

ratio

n.b

usin

essla

ye

r.ad

dre

ssV

alid

atio

n

co

re.in

teg

ratio

n.b

usin

essla

ye

r.co

ntra

ct.e

xp

ort

co

re.in

teg

ratio

n.b

usin

essla

ye

r.cre

ditA

pp

lica

tion

.cre

ditD

ecis

ion

.bu

rea

us

co

re.in

teg

ratio

n.b

usin

essla

ye

r.cre

ditA

pp

lica

tion

.cre

ditD

ecis

ion

.racs.p

ojo

co

re.in

teg

ratio

n.b

usin

essla

ye

r.cre

ditA

pp

lica

tion

.cre

ditD

ecis

ion

.sco

ring

.po

jo

co

re.in

teg

ratio

n.b

usin

essla

ye

r.cre

ditA

pp

lica

tion

.do

cu

me

nts

.po

jo

co

re.in

teg

ratio

n.b

usin

essla

ye

r.cre

ditA

pp

lica

tion

.me

rlin

co

re.in

teg

ratio

n.b

usin

essla

ye

r.ge

nie

co

re.in

teg

ratio

n.b

usin

essla

ye

r.mo

od

ys.c

usto

me

rSe

arc

h

co

re.in

teg

ratio

n.m

ars

ha

lling

.ca

sto

r

co

re.m

od

el.im

pl

co

re.m

od

el.im

pl.b

ase

co

re.p

ricin

g.fa

cto

ry

co

re.ru

le.s

erv

ice

co

re.s

ch

ed

ule

.job

.bu

rea

us

co

re.s

erv

ice

.acce

ss

co

re.s

erv

ice

.pa

rtne

r

co

re.s

erv

ice

.wo

rkflo

w

co

re.u

til.exce

l

co

re.u

til.va

lida

tion

co

re.v

ers

ion

ing

test.s

erv

ice

.se

lect


/ SET / W&I 22-04-2023 PAGE 23

Special technique: Code clones elimination

• Presence of code clones impedes evolution.• Why?

• Points of discussion:• When A and B can be considered clones?

− Identical− Up to variable/constant/number renaming− Allowing gaps/repetitions

• How to detect clones?• When is it beneficial to remove the clones?• Why do people clone code?


/ SET / W&I 22-04-2023

• Why? [Kim et al. 2004] • Limitations of the programming language• Inability to predict future variability• Reuse of the existing code• Struggle against bad(?) modularization

− Cross-cutting concerns and aspects• How? [Kapser, Godfrey 2006]

• Forking• Templating• Customization

PAGE 24

Code duplication

/ SET / W&I 22-04-2023

How to make artifacts more evolvable?

Evolution strategies

• Refactor• Reengineer

• E.g., using models (see next slides)• Re-implement

How can one decide which strategy to follow?• Aversano, Esposito, Mallardo, Tortorella• Ransom, Somerville, Warren• …

PAGE 25

/ SET / W&I 22-04-2023 PAGE 26

Reengineering


Analysis

/ SET / W&I 22-04-2023 PAGE 27

How to make the artefacts more evolvable?


Reverse engineering

Analysis

/ SET / W&I 22-04-2023 PAGE 28



Reverse engineering

Restructuring, model evolution

Analysis

/ SET / W&I 22-04-2023 PAGE 29



Reverse engineering


Forward engineering

Analysis

/ SET / W&I 22-04-2023 PAGE 30



Reverse engineering


Forward engineering

Analysis

/ SET / W&I 22-04-2023 PAGE 31



Reverse engineering


Forward engineering

Analysis

/ SET / W&I 22-04-2023

Reverse Engineering: From Code to Models

PAGE 32

• Depends on• What kind of model would we like?

− structure / behaviour− precise / approximate

• What kind of code do we have?− complete / incomplete− compilable / executable / neither− programming languages:

heterogeneous / homogeneous− “special cases”:

− process models− business rules

• We need tools!

/ LaQuSo / Mathematics & Computer Science 22-04-2023 PAGE 33

Example: Reverse Engineering Class Diagram

Inferred class diagram contains more details than the original one:

• Additional fields and methods in certain classes• Additional relationship: aggregation

Bellflower (C++)CPP2XMI

/ SET / W&I 22-04-2023

Example: Reverse Engineering State Machines

PAGE 34

CPP2XMI

Flow System Controller (C), module SPUR

/ SET / W&I 22-04-2023

Example: Reverse Engineering Sequence Chart

PAGE 35

:ProductFacade:Login :Profiler

access(ctx)

proceed()

logMethods(ctx)

proceed()

proceed()

ctx:Invocation

Context

productInfo(id)

:Auditor

measureDuration(ctx)

proceed()

doAudit(ctx)

find()

em:

EntityManager

:Product

productInfo(id)

getDescription()

Artificial (Java, EJB 3.0)

/ SET / W&I 22-04-2023 PAGE 36



Reverse engineering


Forward engineering

Analysis

See talk about MDE!

/ SET / W&I 22-04-2023

Summarizing… Software Evolution

• A “hot” topic• Challenges:

• Science and engineering• Different evolving artifacts• Different evolution patterns and strategies• Co-evolution• Analysis and visualization

PAGE 37

/ SET / W&I 22-04-2023 PAGE 38

Software Evolution @ TU/e

• What does evolve?• Repositories for models – Zvezdan Protic, MvdB

• What can we learn from evolution so far?• Statistical approaches – Serguei Roubtsov, AS, MvdB

• How evolvable are our systems?• SQuAVisiT – Serguei Roubtsov, Martin vd Vlist, Peter

Schachtschabel• How to make the artefacts more evolvable?

• Reverse engineering – Dennie van Zeeland, MvdB, AS• How is the evolution implemented?

• Model transformations – Marcel van Amstel, Luc Engelen, MvdB

• Migration coordination – Erik de Vink, Suzana Andova


/ SET / W&I 22-04-2023 PAGE 39

2IS95 Seminar Software Engineering and Technology

Documents

Transcript of 2IS95 Seminar Software Engineering and Technology