understanding software evolution michael w. godfrey software architecture group university of...
TRANSCRIPT
![Page 1: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/1.jpg)
Understanding Software Evolution
Michael W. Godfrey
Software Architecture Group University of Waterloo
![Page 2: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/2.jpg)
Background and interests Research
Software evolution Versioning, configuration management Software architecture, reverse engineering,
program visualization Interchange formats for rev. eng. tools
Software engineering education SIGCSE (J ), CCCEE, IST Professional M.Eng. program (Cornell) SE option (Wloo), SE ugrad program (Wloo)
![Page 3: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/3.jpg)
Overview What is software evolution?
Why should we care? Previous research A case study: The Linux OS kernel Observations, hypotheses, and
future research
![Page 4: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/4.jpg)
What is software evolution?
“Evolution is what happens while you’re busy
making other plans.”
Usually, we consider evolution to begin once the first version has been delivered:
Maintenance is the planned set of tasks to effect changes.
Evolution is what actually happens to the software.
![Page 5: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/5.jpg)
Common “maintenance” tasks Adaptive
Add new features Add support for new platforms
Corrective Fix bugs, misunderstood requirements
Perfective Performance tuning
Preventive Restructure code, “refactoring”, legacy
wrapping, build interfaces
![Page 6: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/6.jpg)
Why should we care? Much of the commercial software world operates
in perpetual crisis mode. “Fix it, don’t try to understand it.” Just-in-time program comprehension [Lethbridge]
… but … large software systems are major assets of many businesses
Getting it right more important than getting it done fast. Budget and time for preventive maintenance, navel
gazing. Relatively little research on trying to understand
how and why programs evolve.
![Page 7: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/7.jpg)
Previous research Lehman’s laws Parnas on software geriatrics Eick et al. on code decay (10 MLOC
telecom) Gall et al. (10 MLOC telecom)
Munro, Burd et al. (2 MLOC gcc)
![Page 8: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/8.jpg)
Lehman’s Laws of Software Evolution Based on measurement of a few
(commercially-developed) systems, most notably IBM’s OS 360 Originally three laws, now there are eight.
Controversial as “laws” Has been criticized for strong claims based
on limited data. However, it’s pioneering work on software
evolution and software engineering.
![Page 9: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/9.jpg)
Lehman’s Laws of Software Evolution
1. Continuing change — An E-type program that is used must be continually adapted else it becomes progressively less satisfactory.
2. Increasing complexity — As a program is evolved, its complexity increases unless work is done to maintain or reduce it.
3. Self regulation — The program evolution process is self-regulating with close to normal distribution of measures of product and process attributes.
![Page 10: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/10.jpg)
Lehman’s Laws of Software Evolution
4. Invariant work rate — The average effective global activity rate on an evolving system is invariant over the product lifetime.
5. Conservation of familiarity — During the active life of an evolving program, the content of successive releases is statistically invariant.
6. Continuing growth — Functional content of a program must be continually increased to maintain user satisfaction over its lifetime.
![Page 11: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/11.jpg)
Lehman’s Laws of Software Evolution
7. Declining quality — E-type programs will be perceived as of declining quality unless rigorously maintained and adapted to a changing operation environment.
8. Feedback system — E-type programming processes constitute multi-loop, multi-level feedback systems and must be treated as such to be successfully modified or improved.
![Page 12: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/12.jpg)
Lehman’s Laws in a nutshell Observations:
(Most) useful software must evolve or die. As a software system gets bigger, its resulting
complexity tends to limit its ability to grow. Development progress/effort is (more or less)
constant. Advice:
Need to manage complexity. Do periodic redesigns. Treat software and its development process as a
feedback system (and not as a passive theorem).
![Page 13: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/13.jpg)
Lehman’s examples
![Page 14: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/14.jpg)
A case study in evolution:The Linux OS kernel
![Page 15: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/15.jpg)
A case study in evolution:The Linux OS kernel“Evolution in Open Source Software: A Case Study”
[Godfrey and Tu, ICSM 2000] It’s Linux!
Large system, very stable, many releases over several years, many developers
Growing mainstream adoption Open source development model
Interesting phenomenon in itself Easy to track, can publish results, many
experts Not much previous study
![Page 16: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/16.jpg)
Evolution of Linux: Questions How has Linux evolved over time?
Does it obey Lehman’s laws? What is the best way to characterize
growth? How has its (open source) process
model affected its development? How has the (high-level) architecture
changed over time? affected the system’s evolution?
![Page 17: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/17.jpg)
Open source development Open source development vs. open source software
GNU, Linux, Apache, vim, gcc, FreeBSDvs.
Mozilla, JDK, Jikes, NetBeans “The Cathedral and the Bazaar” [Raymond]
Usual goal: scratching an interesting itch, not filling a commercial void.
Anyone may contribute, tho owner(s) have final say. Usually, developers work part-time and for free.
Motivation is peer recognition and personal satisfaction, not money.
However, industrial participation also increasing (e.g., Cygnus, IBM)
![Page 18: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/18.jpg)
Open source development Largely immune from time-to-market pressures
Can release when it’s really ready Can be hard to control/direct developers
Big egos, can’t be “fired” What’s cool vs. what’s needed Less “sexy” development tasks often suffer
e.g., planned testing, preventive maintenance Code quality varies widely
Some projects have coding standards Unstable/experimental code common (and even
encouraged) Quality maintained via “massively parallel debugging”,
not rigorous testing.
![Page 19: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/19.jpg)
Linux background Linux kernel v1.0 released March 1994
487 source files, 165 KLOC, i386 only Linux kernel v2.3.39 released January
2000 4854 source files, 2.2 MLOC, 10 hardware
architectures supported, over 300 developers credited
Maintained along two parallel paths: development and stable
![Page 20: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/20.jpg)
Methodology Examined 96 versions of Linux kernel
34 of the 67 stable releases 62 of the 369 development releases
All measures considered only .c/.h files contained in the tarball
Counted LOC using “wc –l” and an awk script that ignored comments and blank lines
Counted # of fcns/vars/macros using ctags Architectural model (SSs hierarchy) based on default
directory structure We plotted growth against calendar time
Lehman suggests plotting growth against release number
![Page 21: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/21.jpg)
Growth of compressed tar file
0
2,000,000
4,000,000
6,000,000
8,000,000
10,000,000
12,000,000
14,000,000
16,000,000
18,000,000
20,000,000
Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 2001
Siz
e in
byt
es
Development releases (1.1, 1.3, 2.1, 2.3)
Stable releases (1.0, 1.2, 2.0, 2.2)
![Page 22: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/22.jpg)
Growth of # of source files
0
1000
2000
3000
4000
5000
6000
Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 2001
# o
f so
urc
e co
de
file
s (*
.[ch
] )
Development releases (1.1, 1.3, 2.1, 2.3)
Stable releases (1.0, 1.2, 2.0, 2.2)
![Page 23: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/23.jpg)
Growth of # of global fcns, variables, and macros
0
20,000
40,000
60,000
80,000
100,000
120,000
140,000
Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 2001
# o
f g
lob
al f
cns,
var
iab
les,
an
d m
acro
s Development releases (1.1, 1.3, 2.1, 2.3)
Stable releases (1.0, 1.2, 2.0, 2.2)
![Page 24: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/24.jpg)
Growth of Lines of Code (LOC)
0
500,000
1,000,000
1,500,000
2,000,000
2,500,000
Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 2001
To
tal
LO
C
Total LOC ("wc -l") -- development releases
Total LOC ("wc -l") -- stable releases
Total LOC uncommented -- development releases
Total LOC uncommented -- stable releases
![Page 25: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/25.jpg)
Average/median .c file size
0
100
200
300
400
500
600
700
Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 2001
Un
com
men
ted
LO
C
Average .c file size -- dev. releasesAverage .c file size -- stable releasesMedian .c file size -- dev. releasesMedian .c file size -- stable releases
![Page 26: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/26.jpg)
Average/median .h file size
0
20
40
60
80
100
120
140
Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 2001
Un
co
mm
ente
d L
OC
Average .h file size -- dev. releasesAverage .h file size -- stable releasesMedian .h file size -- dev. releasesMedian .h file size -- stable releases
![Page 27: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/27.jpg)
Growth of major SSs (dev. releases)
0
200,000
400,000
600,000
800,000
1,000,000
1,200,000
Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 2001
To
tal
un
com
men
ted
LO
C
drivers
arch
include
net
fs
kernel
mm
ipc
lib
init
![Page 28: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/28.jpg)
Growth of major SSs (ignoring drivers)
0
50,000
100,000
150,000
200,000
250,000
Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 2001
To
tal
un
com
men
ted
LO
C
arch
include
net
fs
kernel
mm
ipc
lib
init
![Page 29: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/29.jpg)
SS LOC as percentage of total system
0.0
10.0
20.0
30.0
40.0
50.0
60.0
70.0
Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 2001
Per
cen
tag
e o
f to
tal
syst
em u
nco
mm
ente
d L
OC
driversarchincludenetfskernelmmipclibinit
![Page 30: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/30.jpg)
SS LOC as percentage of total system (ignoring drivers)
0.0
5.0
10.0
15.0
20.0
25.0
30.0
Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 2001
Per
cen
tag
e o
f to
tal
syst
em u
nco
mm
ente
d L
OC
archincludenetfskernelmmipclibinit
![Page 31: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/31.jpg)
Growth of small core SSs
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 2001
To
tal
un
com
men
ted
LO
C
kernel
mm
ipc
lib
init
![Page 32: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/32.jpg)
Growth of arch SSs
0
5,000
10,000
15,000
20,000
25,000
30,000
35,000
40,000
Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 2001
To
tal
un
com
men
ted
LO
C
arch/ppc/
arch/sparc/
arch/sparc64/
arch/m68k/
arch/mips/
arch/i386/
arch/alpha/
arch/arm/
arch/sh/
arch/s390/
![Page 33: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/33.jpg)
Growth of drivers SSs
0
50,000
100,000
150,000
200,000
250,000
300,000
Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 2001
To
tal
un
com
men
ted
LO
C
drivers/netdrivers/scsidrivers/chardrivers/videodrivers/isdndrivers/sounddrivers/acorndrivers/blockdrivers/cdromdrivers/usbdrivers/"others"
![Page 34: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/34.jpg)
Observations and hypotheses Growth along development path is
super-linear
y = .21*x^2 + 252*x + 90,055 r2=.997y = size in LOC x = days since v1.0 r2 is “coefficient of determination” using least
squares
Strong growth is continuing. This is stronger growth than observed by
others (Lehman, Gall), even for other OSs.
![Page 35: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/35.jpg)
Why has Linux been able to continue its geometric growth? Core code quality is carefully maintained Architecture/problem domain
It’s largely drivers Much of the code is “parallel” It’s not as big as you might think
Vanilla configuration used only 15% of files
Development model (OSD) and its sociology Popularity and visibility has encouraged outsiders
(both hackers and industry) to contribute
![Page 36: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/36.jpg)
Growth of fetchmail [Raymond]
![Page 37: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/37.jpg)
Growth of pine (email client)
0
50
100
150
200
250
300
350
Jan-93 Jun-94 Oct-95 Mar-97 Jul-98 Dec-99 Apr-01
# o
f M
od
ule
s
![Page 38: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/38.jpg)
Growth of X Windows
0
500
1000
1500
2000
2500
3000
Nov-84 Aug-87 May-90 Jan-93 Oct-95 Jul-98 Apr-01
# o
f M
od
ule
s
X11R6
X11R5
X11R3
X10R3
X10R4
X11R1
X11R2
X11R6.1
X11R6.3X11R6.4
![Page 39: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/39.jpg)
Growth of gcc/g++/egcs
0
100
200
300
400
500
600
700
800
900
1000
Aug-87 Dec-88 May-90 Sep-91 Jan-93 Jun-94 Oct-95 Mar-97 Jul-98 Dec-99 Apr-01
# o
f m
od
ule
s g++
gcc
egcs
![Page 40: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/40.jpg)
Growth of vim (text editor)
0
20,000
40,000
60,000
80,000
100,000
120,000
140,000
160,000
May 1990 Sep 1991 Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 2001
To
tal
LO
C
Total LOC ("wc -l")
Total LOC (ignoring comments and blank lines)
![Page 41: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/41.jpg)
vim avg % comments and blank lines per file
25.0
26.0
27.0
28.0
29.0
30.0
31.0
May 1990 Sep 1991 Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 2001
Ave
rag
e p
erce
nt
com
men
ts +
bla
nk
lin
es
![Page 42: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/42.jpg)
vim avg/median file size
0
100
200
300
400
500
600
700
800
900
1000
May 1990 Sep 1991 Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 2001
Un
com
men
ted
LO
C
Average uncommented LOC per source fileMedian uncommented LOC per source file
![Page 43: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/43.jpg)
vim’s architecture
![Page 44: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/44.jpg)
HypothesesFactors affecting evolution include
Size and age of system Use of traditional sw. eng. principles during
development
PLUS Problem domain
Problem complexity, multi-platform, multi-features Software architecture Process model Sociology, market forces, and acts-of-God
![Page 45: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/45.jpg)
Software evolution research: What next? So far, have examined only growth
of various aspects of code.
We need:1. more detailed case studies 2. supporting tools3. codified knowledge
![Page 46: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/46.jpg)
Case studies (future work) Need to look at more systems:
Qualitative and quantitative studies Industrial and open source systems Different architectures, problem domains
OSs, telecom systems, compilers, …
Examples: More detailed analysis of Linux [Davor
Svetinovic]
Linux vs. FreeBSD, Solaris gcc vs. commercial compilers [Qiang Tu]
![Page 47: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/47.jpg)
Reqs for a program evolution comprehension tool Usual prog. comp. / reverse eng. tool
requirements: fast, reliable fact extractors practical repository visualization tools interoperability (!)
![Page 48: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/48.jpg)
Reqs for a program evolution comprehension tool Fast, incremental ocean boiling:
take advantage of “mostly the same” precompute, use relational calculator (grok)
when possible Usability analysis
Support for disposable views, experimentation, flexible usage, system “slicing”
![Page 49: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/49.jpg)
Example: KAC and gmake Refactoring — Various functions (within Parser
and General Services) were renamed or replaced by similar functions.
INCLUDES
RULEENGINE
GENERALSERVICES
LIBRARIES
JOBCONTROL
DEPENDENCYENGINE
MAIN
FILEHANDLING
PARSER
removed
added
![Page 50: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/50.jpg)
Tool future work So far, have assumed nodes are the same
between graphs, only relationships change not realistic
Need to account for: added / removed / preserved nodes changed nodes and relationships rearranged (different) containment trees several versions at once
linear evolution vs. variants
![Page 51: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/51.jpg)
Codified knowledge Mature engineering disciplines codify knowledge
and experience. Arguably, this is lacking in software engineering.
Software architecture styles [Shaw] Design patterns [GoF]
Codified knowledge of how and why programs evolve:
Evolutionary narratives [Godfrey] Long term, coarse granularity
Change patterns Short term, fine granularity
![Page 52: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/52.jpg)
Evolutionary narratives
% webster elephantine
1a: having enormous size or strength: MASSIVE
1b: CLUMSY, PONDEROUS
![Page 53: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/53.jpg)
Change patterns and evolutionary narratives
Cathedral style [Raymond] careful control and management debugging done before committing code evolution is slow, planned, rarely undone
Bazaar style (OSD) lots of low-level changes, frequent fixes lots of “building around” rather than wholesale
changing, occasional redesigns creeping feature-itis, “complete” dependency graph
![Page 54: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/54.jpg)
Change patterns and evolutionary narratives Band-aid evolution (just add a layer)
quick & dirty way to add new functionality, esp. if system is not well understood
e.g., Y2K fixing, adding portability, new features
“Vestigial features” design artifact persists after rationale dies
e.g., whale fin bone structure resembles hand
![Page 55: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/55.jpg)
Change patterns and evolutionary narratives “Adaptive radiation” [Lehman]
when conditions permit, encourage wild variation for a while.
later, evaluate and let “best” ideas live on.e.g., Linux kernel evolution
“Convergent evolution” compare similar systems to reference arch.
(or to each other)e.g., everyone grows an XML generator in response
to market pressure
![Page 56: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/56.jpg)
Change patterns and evolutionary narratives Radical redesigns (localized and global)
aka “refactoring” little new functionality added, but structure
changes significantly, legacy cruft dissipates likely “goodness” (design metrics) improves
Migration patterns look out for known translation idioms,
especially if migration is not one big bange.g., procedural-to-OO idioms
![Page 57: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/57.jpg)
Change patterns and evolutionary narratives OO evolutionary patterns
one recognizable design pattern transformed into another (or a variation of the original)
requires good OO extraction tools (dynamic binding, polymorphism, reflection, etc.)
Reuse patterns components are (re)used in different systems
e.g., build COTS interface, throw out homebrew DB
![Page 58: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/58.jpg)
Change patterns and evolutionary narratives Phenomena observed in Linux evolution
Bandwagon effect Contributed third party code “Mostly parallel” enables sustained growth Clone and hack Careful control of core code; more flexibility
on contributed drivers, experimental features
![Page 59: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/59.jpg)
Summary of future research
More case studies needed Qualitative and quantitative Industrial and open source systems Different problem domains, architectures
Supporting tools to aid analysing, visualizing, and querying program evolution
More than just RCS and perl Support for architecture repair
Why and how does software change? Build catalogue of change patterns and evolutionary
narratives
![Page 60: Understanding Software Evolution Michael W. Godfrey Software Architecture Group University of Waterloo](https://reader036.vdocuments.us/reader036/viewer/2022062301/5697bfba1a28abf838ca056c/html5/thumbnails/60.jpg)