Evolutionary reengineering, or ER, might be defined as a
process of slowly and selectively introducing new structured
code in with legacy code. This process is to start out at the
lowest level of module detail and slowly filter one “branch”
up through the structure of the program until the main drivers
are accessed. By testing a single branch of the module tree in
each of the main sections of the code, it can be determined
more quickly if the module structure that is being proposing
for each section is valid.
This strategy is in some respects the opposite of starting
with a clean slate and then trying to piece together the
program. In effect, it moves incrementally from old
unstructured legacy code to new modular code by incorporating
the new code with the old. The existing code retains its
capability to interface with the user input data, and is
extended to generate parameters needed by the new code
modules. In this way, the new modules can be verified without
having to completely replace the entire functional capability
of the old program with new code before any verification can
take place. As the process proceeds, the parameters being
supplied by old routines can be supplanted by those available
from new routines and new data structures. This makes the
transition evolutionary, and permits a smooth transition with
a greater capability for verification testing. One main
advantage of ER is that there will always be a working version
of EnergyPlus available. One slight disadvantage is that there
may be the need for temporary scaffolding code to transition
from the mixed mode to fully modular code.
The process is shown schematically in the following figure
as a series of four stages. The first stage is the starting
point with legacy code and traditional input and output. The
second stage, which could consist of several substages,
incorporates new structured code with the legacy code. This
new code receives all needed inputs from the legacy code, and
produces only developers’ verification output. This stage is
considered complete when it includes the fundamental initial
modules, and has defined interfaces for new plug-in modules.
In the third stage, the new input data structure is included
to supply input to the structured code modules, which have
been algorithmically verified. In the fourth stage, the new
output data structure is incorporated, and the transition is
complete.
Appendix C: Evolutionary Reengineering[LINK]
Evolutionary reengineering, or ER, might be defined as a process of slowly and selectively introducing new structured code in with legacy code. This process is to start out at the lowest level of module detail and slowly filter one “branch” up through the structure of the program until the main drivers are accessed. By testing a single branch of the module tree in each of the main sections of the code, it can be determined more quickly if the module structure that is being proposing for each section is valid.
This strategy is in some respects the opposite of starting with a clean slate and then trying to piece together the program. In effect, it moves incrementally from old unstructured legacy code to new modular code by incorporating the new code with the old. The existing code retains its capability to interface with the user input data, and is extended to generate parameters needed by the new code modules. In this way, the new modules can be verified without having to completely replace the entire functional capability of the old program with new code before any verification can take place. As the process proceeds, the parameters being supplied by old routines can be supplanted by those available from new routines and new data structures. This makes the transition evolutionary, and permits a smooth transition with a greater capability for verification testing. One main advantage of ER is that there will always be a working version of EnergyPlus available. One slight disadvantage is that there may be the need for temporary scaffolding code to transition from the mixed mode to fully modular code.
The process is shown schematically in the following figure as a series of four stages. The first stage is the starting point with legacy code and traditional input and output. The second stage, which could consist of several substages, incorporates new structured code with the legacy code. This new code receives all needed inputs from the legacy code, and produces only developers’ verification output. This stage is considered complete when it includes the fundamental initial modules, and has defined interfaces for new plug-in modules. In the third stage, the new input data structure is included to supply input to the structured code modules, which have been algorithmically verified. In the fourth stage, the new output data structure is incorporated, and the transition is complete.
Documentation content copyright © 1996-2026 The Board of Trustees of the University of Illinois and the Regents of the University of California through the Ernest Orlando Lawrence Berkeley National Laboratory. All rights reserved. EnergyPlus is a trademark of the US Department of Energy.
This documentation is made available under the EnergyPlus Open Source License v1.0.