Reengineering: The Horseshoe Model
Integration between systems has always been difficult; there is little systematic reuse of assets between systems; and new software quickly becomes a liability. In conjunction with the recent architectural reconstruction work, a conceptual "horseshoe" model was developed that distinguishes different levels of reengineering analysis and provides a foundation for transformations at each level, especially for transformations to the architectural level.
In its most fundamental form there are three basic reengineering processes 1) analysis of an existing system, 2) logical transformation, and 3) development of a new system. These three processes form the basis of the "horseshoe", as illustrated below. The purpose of the visual metaphor of the "horseshoe" is to integrate the code-level and the architectural reengineering views of the world.
In its purest and most complete form (represented by the large outlined arrows), the first process recovers the architecture by extracting artifacts from source code. This recovered architecture is analyzed to determine whether it conforms to the "as-designed" architecture. The discovered architecture is also evaluated with respect to a number of quality attributes such as performance, modifiability, security, or reliability.
The second process is architectural transformation. In this case, the "as-built" architecture is recovered and then reengineered to become a desirable new architecture. It is re-evaluated against the system's quality goals and subject to other organizational and economic constraints.
The third process of the horseshoe uses architecture-based development (ABD) to instantiate the desired architecture. In this process, packaging issues are decided and interconnection strategies are chosen. Code-level artifacts from the legacy system are often wrapped or rewritten in order to fit into this new architecture.
For convenience we break the world of program understanding tools into categories according to the program, system, or design information they work with and the corresponding information that they produce. We break our knowledge schema into three distinct levels. The first, or base, is the code level which includes the source code and artifacts such as abstract syntax trees and flow-graphs obtained through parsing and rote analytic operations. The second is the function level which describes the relationship among a program’s functions (calls for example), data (function and data relationships), and files (groupings of functions and data). Third is the concept level in which clustering of both function and code level artifacts are assembled into patterns of architectural level components.
The trip around the outside of the horseshoe represents the most abstract and purest form of reengineering. In practice there are two additional shortcuts that cut across the horseshoe and that enable one to get from the "as-built" system to the "as desired" system. These "shortcut" paths across the horseshoe can represent pragmatic choices based on organizational or technological constraints, such as reengineering tools available. In these cases our analysis process does not result in the system architecture representation, but in lower level artifacts that may be closer to the source code than the architecture.
To learn more about the horseshoe model, please refer to:
- S. J. Carriere, S. G. Woods, R. Kazman, "Software Architecture Transformation", Proceedings of WCRE 99, (Atlanta, GA), October 1999, 13-23.
- S. G. Woods, S. J. Carriere, R. Kazman, "A Semantic Foundation for Architectural Reengineering", Proceedings of ICSM99, (Oxford, UK), Sept. 1999, 391-398.
- R. Kazman, S. G. Woods, S. J. Carriere, "Requirements for Integrating Software Architecture and Reengineering Models: CORUM II", Proceedings of WCRE 98, (Honolulu, HI), October 1998, 154-163.
The "horseshoe" model describes the rich set of technical choices that reengineers make. However, because of its technical focus, it has not been widely accessible to decision makers in a form that can assist them in deciding on complex options regarding the future of their legacy systems. We have taken the "horseshoe" model as a starting point and propose a structured and accessible vehicle for making informed choices in a variety of real world situations. This method, "Options Analysis for Reengineering" (OAR) is a reengineering decision aid, grounded in the technical underpinnings of the "horseshoe" model. It provides a coherent method for making technical, organizational, mission and programmatic choices in practical reengineering decision making.