Object-oriented Reengineering Patterns

Front Cover
The documentation is missing or obsolete, and the original developers have departed. Your team has limited understanding of the system, and unit tests are missing for many, if not all, of the components. When you fix a bug in one place, another bug pops up somewhere else in the system. Long rebuild times make any change difficult. All of these are signs of software that is close to the breaking point.

Many systems can be upgraded or simply thrown away if they no longer serve their purpose. Legacy software, however, is crucial for operations and needs to be continually available and upgraded. How can you reduce the complexity of a legacy system sufficiently so that it can continue to be used and adapted at acceptable cost?

Based on the authors' industrial experiences, this book is a guide on how to reverse engineer legacy systems to understand their problems, and then reengineer those systems to meet new demands. Patterns are used to clarify and explain the process of understanding large code bases, hence transforming them to meet new requirements. The key insight is that the right design and organization of your system is not something that can be evident from the initial requirements alone, but rather as a consequence of understanding how these requirements evolve.

* Describes how to reverse engineer a monolithic system to understand how it really works and how to identify potential problems.
* Includes reengineering patterns that tackle well-known reengineering techniques often encountered in object-oriented programming, such as introducing polymorphism, factoring out common behavior, detecting duplicated code, and understanding design.
* Shows how to build a culture of continuous reengineering for achieving flexible and maintainable object-oriented systems.
 

What people are saying - Write a review

We haven't found any reviews in the usual places.

Contents

II
2
III
5
IV
6
V
10
VI
12
VIII
16
X
18
XIII
19
LXVI
143
LXVIII
148
LXIX
150
LXX
152
LXXII
154
LXXIV
156
LXXVI
158
LXXVIII
160

XIV
20
XV
21
XVI
24
XVIII
25
XIX
28
XX
30
XXI
31
XXII
32
XXIV
39
XXVI
45
XXVIII
51
XXX
59
XXXII
66
XXXIII
68
XXXIV
69
XXXVI
77
XXXVIII
85
XL
96
XLIII
97
XLIV
98
XLV
99
XLVII
104
XLVIII
108
L
110
LII
114
LIII
120
LIV
122
LV
123
LVI
124
LVIII
129
LX
131
LXII
137
LXIV
140
LXXIX
161
LXXXI
164
LXXXIII
165
LXXXV
167
LXXXVII
169
LXXXIX
170
XCI
174
XCIII
175
XCIV
176
XCVI
181
XCVIII
188
CI
189
CII
191
CIV
200
CVI
209
CVII
216
CX
217
CXI
218
CXIII
226
CXV
235
CXVII
238
CXVIII
241
CXX
244
CXXII
254
CXXVI
255
CXXIX
256
CXXXII
257
CXXXVII
258
CXL
259
CXLI
260
CXLII
268
Copyright

Other editions - View all

Common terms and phrases

Popular passages

Page xvii - The law of continuing change A program that is used in a real-world environment necessarily must change or become progressively less useful in that environment.

About the author (2003)

Tom Mens is professor at the Institute of Computer Science of the University of Mons-Hainaut in Belgium. He obtained his PhD in Science in 1999 at the Vrije Universiteit Brussel on the topic of software evolution. Being one of the leading researchers in this domain, he currently directs the ERCIM Working Group on Software Evolution.

Serge Demeyer is professor at the University of Antwerp (Department of Mathematics and Computer Science), where he leads a research group investigating the theme of "Software Reengineering" (LORE - Lab On REengineering). His main research interest concerns software engineering (more precisely, reengineering of object-oriented software systems) but due to historical reasons he maintains a heavy interest in hypermedia systems as well. He is an active member of the corresponding international research communities, serving in various conference organization and program committees.

Stephane is a post doctoral researcher in the Software Composition Group in Berne.

Nierstrasz is a professor of computer science at the University of Bern where he leads the Software Composition Group.

Bibliographic information