^{Author: Dr. Marco Konersmann, April 2024}

Introduction

As a special interest group for Software Reengineering, we discuss challenges and solutions for software reengineering (SRE). In this essay we present an overview of the topic of SRE for discussions. The SWEBOK v3 [SWEBOK] defines reengineering as follows:

"Reengineering is defined as the examination and alteration of software to reconstitute it in a new form, and includes the subsequent implementation of the new form."

Thus, SRE includes analytic ("examination") and constructive ("alteration") aspects, to reconstitute a "new" from an "old" form. We follow this definition.

In the following, we will briefly introduce multiple aspects of SRE, that we consider important. There are recurring fundamental practices of SRE. These are part of processes and subject to automation. Management aspects and Engineering aspects contribute to successful SRE projects. But first we introduce reasons for SRE.

Why Software Reengineering?

Software ages. It does not age like living beings, but ages in the sense that requirements towards the software system changes, referenced technology evolves, and knowledge about the software erodes. Software aging is a continuous threat to software, due to multiple reasons. In general, we differentiate between

• technical reasons, e.g., when no compilers are available anymore for an outdated programming language, or technological benefits are expected from an update to newer technologies (faster development cycles, etc.), and

• social reasons, e.g., programmers of an outdated language are expensive and rare, or the developers are more productive in a more modern language.

The following concrete threats come up due to software aging:

1. the usefulness decreases when the requirements change, but the software is not changed accordingly;
2. the functionality decreases, e.g. when a software loses the ability interact with its (changing) context;
3. the quality decreases, e.g., when interfaces to the context need to be wrapped over time, because the contextual systems change, or when third party libraries in use are no longer maintained and cannot be replaced (think of security frameworks);
4. the perceived quality decreases, because better technology and sociotechnical knowledge increases the quality of other software systems. When a software does not hold up to this development, it can be perceived as low-quality or old software;
5. the ability to maintain and evolve the system decreases when the technology ages, original developers leave the organization and new developers are not educated in the relevant technologies.
6. the organization becomes less interesting for prospective developing employees when the software is built on outdated technology, potential employees don't see a long-term perspective for their career to work on this software.

Goals for starting a SRE project might be individual for each project, but they usually address the mitigation of one or more of the threats above.

Fundamental Practices of Software Reengineering

SRE is in general a part of software engineering and therefore employs software engineering practices. That said, there are some practices of special importance to SRE:

Artifact analysis means that development artifacts, such as requirements, design models, code or logs are analyzed manually or by automated means to gain information and knowledge about the system. Examples of artifact analyses in SRE include slicing, tracing, clustering, recovery etc.

Reverse engineering is used to recover the design and requirements of a software system, which is especially important when original design and requirements documents are missing or were never created. Reverse engineering can also be used to retrieve cross dependencies between artifacts, such as between source code structures and design elements.

Refactoring is the restructuring of existing code (or sometimes design models) which keeps the functionality, with the goal to achieve better product qualities, especially maintainability and evolvability in the case of SRE. Refactoring can be automated to a certain extent.

The application of patterns is used to mitigate technical and organizational issues of aging software. Recurring examples in SRE are:

• decomposition (sometimes also called "modularization"), e.g. implemented using the strangler fig application pattern [Fow14],
• wrapping existing components,
• adapting existing interfaces.

Code and model transformations are (usually automated) changes to structures such as code or models based on an original structure. Refactorings are one kind of transformations. Transformations in the context of SRE are often model transformations, where technical models are transformed to new structures, e.g. from a monolith to modularized structures.

Processes of Software Reengineering

SRE must be executed in structured processes to be successful. As a subarea of software engineering, SRE can draw from software engineering process knowledge. Recent experiences show that SRE benefits from agile processes. An SRE project is a software engineering project, which includes that the requirements towards the software to be (re)engineered are usually refined during the process. SRE projects share some characteristics that have an impact on the processes:

1. An existing software system and often documents can be used as the basis for development.
2. The resulting software system should be functionally equivalent. Meaning that potentially existing (automated) tests can be reused. That said, SRE projects often also introduce changed or new requirements. We can handle this by splitting this into a reengineering and an evolution project.

Due to these characteristics, typical processes such as the horse shoe model [KWC98] include the analysis of the existing system, the definition of automated transformations of the productive code and the test code(!).

Management Aspects of Software Reengineering

Software Reengineering projects are complex software engineering projects with a need for professional management. Management aspects arise on the enterprise, project, and line level.

The enterprise level focuses on software reengineering strategies with the long-term business success in mind. It requires a management roadmap and an IT strategy for current and future systems, along with software lifecycle management.

The project level considers the management of individual software reengineering projects.

The line level considers how to build and integrated reengineering activities as recurring processes in the line. This includes process management in "classical" and agile process landscapes.

For further reading we propose the essay on the management of Software Engineering.

Engineering Aspects of Software Reengineering

The engineering aspects of software reengineering are manyfold, and their thorough discussion cannot be subject to an essay such as this. We give an overview of relevant engineering aspects ordered by the development phases of software engineering projects.

Requirements engineering in SRE projects has three perspectives:

1. the requirements of the original system to be reengineered, which might not always be available and need to be reverse engineered from code, logs, and design or other documents;
2. the requirements for the resulting system, such as programming languages and frameworks to be used, or maintainability requirements; and
3. the requirements towards the reengineering process, e.g., regarding automation, time, and cost constraints.

Software architecture and design has two perspectives in SRE:

1. the original architecture and design might be unknown and need to be reverse engineered.
2. the architecture and design of the resulting system should be clearly documented, if not formally modelled.

Software analytics, static and dynamic analysis, and architecture/design metrics can help to identify and evaluate the original and potential resulting architectures and design. Automated tools, e.g. for extracting architecture information from code bases (e.g., [HYR96], or [Kon18]) or to migrate architectures (e.g., [CSW21]) assist in architecture and design activities of SRE projects.

Code analysis is often the only way to produce knowledge of legacy systems when the original developers are not available anymore and documentation is not available. Sometimes even the code is not available anymore in SRE projects and the software can only be analyzed by means of analyzing the behavior and reading logs. In the case that code is available, generic software engineering code analysis tools can help understanding the code and identifying patterns within the code.

A recurring goal of SRE projects is to build a software with a more modern programming language. A range of automated tools exist to help in this endeavor. However, expert knowledge is often needed to build code that not only uses the more modern programming language, but can also be read and understood by developers. E.g., consider COBOL code converted to Java code. Automated transformations can be used to build a Java software, but the code still follows COBOL paradigms and is very difficult to understand by Java programmers.

For a deeper dive into the topic, please please read the essay on automated code analysis and reengineering.

Testing is used in SRE projects to verify that the reengineered software behaves the same way as the original software, for an external viewer. Challenges for testing in SRE include the migration of test cases and ensuring their equivalence with the original tests. In SRE, test code is also typically generated from the code of the original system.

Operations in SRE is a challenge when the system must be operated during the reengineering activities. When downtime is not acceptable, an existing system is usually replaced part by part until the original system is not in place anymore. Such migrations can be executed within a short time frame of some minutes or hours, but can also last longer time spans of multiple years, for sufficiently complex and critical systems, and when “big bang” migrations must be avoided.

Finally, there are aspects that cover multiple phases. Deriving traceability links of an existing system, both dynamically and statically, can be very helpful for understanding and redesigning the original system and for testing the reengineered system. Traceability recovery means to identify trace links between artifacts of different phases, e.g., which architecture elements serve which requirement, or which output comes from which use case. Additionally, refactoring is an important activity in the short cycles of agile reengineering activities, that cover multiple phases.

Summary and Futher Reading

In this essay we briefly introduced SRE on a high level. To dive deeper into the topic, we recommend the further essays of the special interest group Software Reengineering. You can also find the publications of the workshop on software reengineering and evolution in the journal "Softwaretechnik Trends".

Acknowledgements

I would like to thank Leif Bonorden, Andres Koch, Jens Borchers, and Sandro Schulze for our lively discussions and their support in writing this essay.

References

[Fow14] Martin Fowler. Strangler Fig Application. https://martinfowler.com/bliki/StranglerFigApplication.html, accessed April 29, 2024

[HYR96] Harris, D.R., Yeh, A.S., Reubenstein, H.B. (1996). Extracting Architectural Features from Source Code. In: Wills, L., Newcomb, P. (eds) Reverse Engineering. Springer, Boston, MA. DOI

[Kon18] Marco Konersmann. Explicitly Integrated Architecture - An Approach for Integrating Software Architecture Model Information with Program Code. phdthesis, University of Duisburg-Essen, March 2018. PDF

[KWC98] R. Kazman, S. G. Woods, and S. J. Carrière, “Requirements for Integrating Software Architecture and Reengineering Models : CORUM II,” in WCRE conf., 1998, pp. 154–163

[SWEBOK] SWEBOK v3. Guide to Software Engineering. Eds. Pierre Bourque, Richard E. Farley. IEEE Computer Society. 2014 https://ieeecs-media.computer.org/media/education/swebok/swebok-v3.pdf

[CSW21] Nacha Chondamrongkul, Jing Sun, and Ian Warren. 2021. Software Architectural Migration: An Automated Planning Approach. ACM Trans. Softw. Eng. Methodol. 30, 4, Article 50 (October 2021), 35 pages. DOI