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.
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.
The Evolutionary Reengineering Process.
Documentation content copyright © 1996-2014 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.