1.5 Software Reengineering

Software reengineering is a form of modernization that improves capabilities and/or maintainability of a legacy system by introducing modern technologies and practices. Software reengineering offers a disciplined approach to migrating a legacy system toward an evolvable system. The process applies engineering principles to an existing system to meet new requirements. In the mid-1990s, the SEI developed a definition of reengineering: Reengineering is the systematic transformation of an existing system into a new form to realize quality improvements in operation, system capability, functionality, performance, or evolvability at a lower cost, schedule, or risk to the customer [Tilley 95, p. 3]. This definition emphasizes that the focus of reengineering is on improving existing systems with a greater return on investment (ROI) than could be obtained through a new development effort.

Reengineering is both more expensive than simple maintenance and less attractive ”from a technical perspective ”than replacing a legacy system. But even though reengineering may not be the cheapest or the most attractive option, it is often the most pragmatic. Because so many legacy systems exist, complete replacement is financially inconceivable for most organizations. Reengineering offers a cost-effective way to extend their useful lifetimes. The key advantages of reengineering over replacement are reduced risk and reduced cost.

Reengineering takes numerous forms: retargeting, revamping, use of commercial components , source code translation, code reduction, and functional transformation. All are intended to improve on a quality or set of qualities of the legacy system.

Retargeting

Retargeting is the migration of a legacy system to a new hardware platform. Retargeting is often motivated by the gain of increasingly powerful hardware platforms and the pain of increasingly expensive maintenance cost of legacy platforms. The trend to retargeting is evidenced by the steadily contracting market share of traditional proprietary environments, such as Compaq/Tandem's NonStop, Unisys' MCP and OS 2200, Fujitsu Siemens' BS Series mainframes, Stratus's VOS, and Groupe Bull's GCOS. Migrating to a modern hardware platform often reduces operational and maintenance costs, allows the introduction of higher-performance computers, and provides an evolvable platform to other modernization efforts.

Revamping

The user interface (UI) is the most visible part of a system. Replacing only the UI is a common form of software reengineering often referred to as revamping. These days, organizations often "Web enable" their " green-screen " systems in response to pressures for Web presence and, from a technical standpoint, the ease of using a standard browser as interface to a system. Revamping the UI should improve usability and is always noticed by the end users of a system. On the other hand, Web enablement may require the purchase of additional hardware for the clients and may be slower than the legacy green screens.

A common black-box technique for revamping is screen scraping [Carr 98]. As shown in Figure 1-4, screen scraping consists of wrapping old, text-based interfaces with new, graphical interfaces. The old interface typically consists of a set of text screens running in a terminal. In contrast, the new interface can be a PC-based graphical user interface (GUI) or even a Hypertext Markup Language (HTML) client running in a Web browser. This technique can be extended easily, enabling one new UI to wrap one or more legacy systems. The new graphical interface communicates with the old one through a specialized commercial tool. ^[1] These tools often generate the new GUI automatically from the original screens.

^[1] For example, OC://WebConnect Enterprise Integration Server from Open-Connect Systems or QuickApp from Attachmate.

Figure 1-4. Legacy system wrapping using screen scraping.

From the perspective of the legacy system, the new graphical interface is indistinguishable from an end user entering text in a screen. From the end user's point of view, the modernization has been successful. The new system now provides a modern, usable graphical interface. However, from the IT department's perspective, the "new" system remains inflexible and difficult to maintain because it is still dependent on the legacy system. With screen scraping, it is still not possible to add, modify, or recompose functions and screens. Its detractors call this approach "whipped cream on road kill." Screen scraping can, however, be effective for stable systems for which the principal objective is to improve usability. ^[2]

^[2] Imagine using on-screen buttons and other navigational tools instead of awkward combinations of function keys.

Screen scraping can also be used to generate application program interfaces (APIs) from legacy user interfaces. This technique was applied in a large government program integrating an ERP system with other systems. In this case, screen scraping was used to extract data from the ERP, reversing the normal use of this wrapping technique, because the ERP did not provide a callable API.

Commercial Components

Software reengineering projects may replace existing legacy code with commercial-off-the-shelf (COTS) components. Although replacing code that you own with components that you license may seem counterintuitive, there are numerous reasons to attempt it. Replacing legacy code with commercial components typically reduces the amount of source code that must be maintained. When building a business case for this type of reengineering project, it is important to consider not only the savings of not having to maintain code but also the cost of extracting the legacy code, the amount of glue code that must be developed and maintained , and any additional licensing and training costs.

Commercial components may be categorized as infrastructure or functional components. Examples of infrastructure components are database managers, HTTP servers, ORBs, application servers, and middleware products. Financial systems, human resource systems, and ERP systems are examples of functional components.

Replacing legacy code with commercial infrastructure components is done for many reasons. These components are often more robust, more secure, have better performance, are more scalable, or are more usable. In addition, commercial infrastructure components often implement industry-standard interfaces, providing integration opportunities in future reengineering projects. Unfortunately, these components often touch many portions of the system, making the infrastructure difficult to extract and replace. Still, replacing legacy code with infrastructure components may well be worth the cost in many cases.

Replacing functional components may also provide additional capabilities and improve on such attributes of system quality as robustness or performance. Replacing functional components can be quite difficult. New components often support business processes that differ from existing ones. This often means undergoing some level of business process reengineering, which can be a time-consuming , expensive exercise.

Source Code Translation

Another common reengineering project is source code translation ”converting from an old programming language to a more modern language. Source code translation may be performed along with moving a system off a legacy platform if, for example, the current language is not available on the target platform. These projects are somewhat risky because benefits are often overestimated and costs underestimated. To be cost-effective, these efforts require automated translation tools. Automatic translation offers consistency; however, it cannot significantly change the structure of the code. For example, automatically translating COBOL to Java often results in code that looks like COBOL written in the Java programming language. For this and other reasons, transformed code is often difficult to maintain: in this case, for either a COBOL or a Java programmer.

Transforming legacy source code to a newer version of the same language can help keep the legacy system current with the evolving environment. However, the risk of source code translation increases as the differences between the legacy and target languages increase. For example, converting from COBOL 68 to COBOL 74 or from COBOL 74 to COBOL 85 should be less risky than converting directly from COBOL 68 to COBOL 85. Likewise, converting from one object-oriented language, such as C++, to another, such as Java, might be fairly straightforward, whereas converting from a procedural language, such as COBOL, to an object-oriented language, such as Java, may be risky. For example, a straightforward translation from COBOL to Java might translate programs directly into classes regardless of object-oriented principles. The sidebar above, "A Tale of Automatic Translation" provides other examples of the consequences of automated translation.

A Tale of Automatic Translation

At the SEI, we are often asked to evaluate software engineering tools, methods , and processes. Recently, we evaluated the results of an automated translation of COBOL to C++. The characteristics of the resulting code follow.

1. The generated C++ is a relatively straightforward translation from COBOL to C++. Thus, the code looks like COBOL written in the C++ programming language.

2. The code contains large class structures, with many nested classes defined within these classes.

3. The class hierarchy is not well organized or designed.

4. All variables within a class are declared as public.

5. All methods within a class are declared as public.

6. Many of the class constructors have a huge number of initializers and are basically unreadable.

7. A large number of the methods do not have any parameter values or return values. Therefore, most of the generated C++ methods perform operations on data via side effects, using global variables.

8. The generated C++ uses GOTOs in an unacceptable manner for a structured programming language such as C++.

9. Many of the generated class and variable names are not meaningful to a developer or a maintainer.

10. The generated code contains few comments. Even comments from the original COBOL source code were lost.

11. The code does not separate application logic from the user interface in a way that the application logic could be reused in a modernized system.

    ”Dan

Code Reduction

Code reduction is conceptually simple even if its execution may be difficult. The idea is analogous to moving: It is better to throw out stuff before you move rather than move and then throw it out. In this case, unnecessary code is eliminated before porting the remaining code to another platform or language. The benefit of code reduction is especially apparent when using a third party to port the code. Many of the organizations providing this service charge from $6 to $20 per line of code ported [Singh-Rangar 00]. Therefore, eliminating unnecessary code can provide an easily measured cost savings.

Identifying functionality that is no longer required can account for large reductions in source code. This includes functionality that was originally required but is now unnecessary. You must make sure that there are no hidden or unknown dependencies with other software modules before removing this code.

Numerous tools exist to identify redundant blocks of code. ^[3] These tools are often included with software products designed to identify and extract business rules. Although their ability to differentiate business rules from garbage code is arguable, these tools can usually identify similar code segments, using pattern matching. These code segments can often be converted into subroutines through a manual programming effort. ^[4] Although this approach to code reduction is effective, it has risks. Because developing reusable subroutines is largely a manual process, it is easy to introduce defects, especially as the degree of similarity between the code segments decreases.

^[3] For example, McCabe Reengineer and Semantic Designs CloneDR.

^[4] Authors' note: In 1982, I worked with a programmer whose programs consisted of large blocks of similar code, each with only minor variations. When I asked why he used this unusual coding style, he told me that he had had a bad experience with subroutines and no longer trusted them. This is an example of how poor coding practices can lead to redundant code and increased maintenance costs. ”rCs

One approach to managing such an effort is to eliminate code segments with the highest degree of matching code and gradually proceed to less similar code segments. It is possible to track the cost of removing each line of code; when the cost of porting each line of code is well known, it is a simple matter to determine when the process should be terminated . Of course, this process must also account for any delay in the schedule resulting from the code reduction, as well as any "lost opportunities" as a result of using staff in this manner.

Functional Transformation

Functional transformation includes program structure improvement, program modularization , and data reengineering. Program structure improvement can come in the form of replacing GOTOs with structured code or simplifying complex condition statements. Generally, improvements in program structure start by identifying the structural flaw that is repeated throughout the system. Correcting it involves choosing an alternative structure and converting from the old structure to the new one. The modification of the source code may be performed automatically or manually.

Program modularization collects related parts of a program into common modules. Modularization makes it easier to identify and to eliminate redundant code, optimize interactions between modules, and simplify interactions with the remainder of the system. Program modularization is often a preliminary step in an incremental modernization effort because well-defined modules are easier to replace with new components.

Data reengineering involves modifying the storage, organization, and format of data processed by the legacy system. Data reengineering is often necessary because of data degradation or because data has been recorded inconsistently at the multiple locations from where it was consolidated.