Reengineering Of Legacy Systems Research Articles

Agile model-driven re-engineering

In this paper we describe an Agile model-driven engineering (MDE) approach, AMDRE, for the re-engineering of legacy systems. The objective is to support the reuse of business-critical functionality from such systems and the porting of legacy code to modernised platforms, together with technical debt reduction to improve the system maintainability and extend its useful life. AMDRE uses a lightweight MDE process which involves the automated abstraction of software systems to UML specifications and the interactive application of refactoring and rearchitecting transformations to remove quality flaws and architectural flaws. We demonstrate the approach on Visual Basic, COBOL and Python legacy codes, including a finance industry case. Significant quality improvements are achieved, and translation accuracy over 80% is demonstrated. In comparison to other MDE re-engineering approaches, AMDRE does not require high MDE skills and should be usable by mainstream software practitioners.

SPReaD: service-oriented process for reengineering and DevOps

The reengineering of systems into a microservice-based architecture can be seen as an implementation of a service-oriented architecture (SOA). However, the deployment of SOA into an enterprise is a challenging task, as it may involve the modernization of mission-critical systems with high technical debt and high maintenance costs. To this end, a process is required to provide an appropriate set of steps and techniques that minimize risks and at the same time ensure the quality of the systems during the migration process. Thus, this work presents the Service-oriented Process for Reengineering and DevOps—SPReaD, an instantiation of the mainstream SOA methodology focusing on the reengineering of legacy systems integrating DevOps aspects for developing microservices systems. This process has been defined during a real software reengineering project of legacy systems from a Brazilian State Department of Taxation. The results obtained include a substantial improvement in the quality of the main taxation system used by the state, including not only code-related metrics but also performance improvements of the services offered, and a change in the methodology adopted by the software development team.

Web Service Candidate Identification Using the Firefly Algorithm

Identification of web service candidates in legacy software is a crucial process in the reengineering of legacy systems to service oriented architecture. Researchers have proposed various automatic and semi-automatic methods for this purpose, some of which have proved to be quite efficient, but there are still certain gaps which need to be addressed. This article discovers the strengths and weaknesses of previous methods and develops a method with improved service candidate identification performance. In this article, service identification is considered as a search and optimization problem and a firefly algorithm is developed accordingly to give high-quality solutions in reasonably short times. A filtering method is also developed to remove excess modules (false positives) from the algorithm outputs. A case study on a legacy flight reservation system demonstrates the high reliability of the outputs given by the proposed method.

On the application of model-driven engineering in data reengineering

Model-Driven Engineering (MDE) emphasizes the systematic use of models to improve software productivity and some aspects of the software quality such as maintainability or interoperability. Model-driven techniques have proven useful not only as regards developing new software applications but also the reengineering of legacy systems. Models and metamodels provide a high-level formalism with which to represent artefacts commonly manipulated in the different stages of a software evolution process (e.g., a software migration) while model transformation allows the automation of the evolution tasks to be performed. Some approaches and experiences of model-driven software reengineering have recently been presented but they have been focused on the code while data reengineering aspects have been overlooked. The objective of this work is to assess to what extent data reengineering processes could also take advantage of MDE techniques.The article starts by characterising data-reengineering in terms of the tasks involved. It then goes on to state that MDE is particularly amenable as regards addressing the tasks previously identified. We present an MDE-based approach for the reengineering of data whose purpose is to improve the quality of the logical schema in a relational data migration scenario. As a proof of concept, the approach is illustrated for two common problems in data re-engineering: undeclared foreign keys and disabled constraints. This approach is organised following the three stages of a software reengineering process: reverse engineering, restructuring and forward engineering. We show how each stage is implemented by means of model transformation chains. A running example is used to illustrate each stage of the process throughout the article. The approach is validated with a real widely-used database. An assessment of the application of MDE in each stage is then presented, and we conclude by identifying the main benefits and drawbacks of using MDE in data reengineering.

Reengineering of Legacy Systems into Supply Chain Systems

The paper presents data oriented and process oriented models of legacy systems. It discusses the details of systems development and evolution models mainly aiming at an ongoing reengineering of legacy systems into supply chain systems. It proposes few strategies for reengineering of both data oriented model and process oriented models. The legacy systems often miss automatic interfaces to supply chain systems, so the article presents a strategy focusing on automatic update of data of the system. Likewise, the article also presents a strategy for process reengineering in order to integrate these legacy systems into supply chain systems. Finally, a legacy system is envisioned as a comprehensive mix of both data and process oriented, while proposing a gradual ongoing reengineering of both data structures and process methods.

Study and Application of Legacy System Reengineering based on Component Reuse

Study and Application of Legacy System Reengineering based on Component Reuse

A systematic mapping study on software product line evolution: From legacy system reengineering to product line refactoring

Software product lines (SPLs) are used in industry to develop families of similar software systems. Legacy systems, either highly configurable or with a story of versions and local variations, are potential candidates for reconfiguration as SPLs using reengineering techniques. Existing SPLs can also be restructured using specific refactorings to improve their internal quality. Although many contributions (including industrial experiences) can be found in the literature, we lack a global vision covering the whole life cycle of an evolving product line. This study aims to survey existing research on the reengineering of legacy systems into SPLs and the refactoring of existing SPLs in order to identify proven approaches and pending challenges for future research in both subfields. We launched a systematic mapping study to find as much literature as possible, covering the diverse terms involved in the search string (restructuring, refactoring, reengineering, etc. always connected with SPLs) and filtering the papers using relevance criteria. The 74 papers selected were classified with respect to several dimensions: main focus, research and contribution type, academic or industrial validation if included, etc. We classified the research approaches and analyzed their feasibility for use in industry. The results of the study indicate that the initial works focused on the adaptation of generic reengineering processes to SPL extraction. Starting from that foundation, several trends have been detected in recent research: the integrated or guided reengineering of (typically object-oriented) legacy code and requirements; specific aspect-oriented or feature-oriented refactoring into SPLs, and more recently, refactoring for the evolution of existing product lines. A majority of papers include academic or industrial case studies, though only a few are based on quantitative data. The degree of maturity of both subfields is different: Industry examples for the reengineering of the legacy system subfield are abundant, although more evaluation research is needed to provide better evidence for adoption in industry. Product line evolution through refactoring is an emerging topic with some pending challenges. Although it has recently received some attention, the theoretical foundation is rather limited in this subfield and should be addressed in the near future. To sum up, the main contributions of this work are the classification of research approaches as well as the analysis of remaining challenges, open issues, and research opportunities.

RCause - A Root Cause Analysis Model to Identify the Root Causes of Software Reengineering Problems

Organizations that wish to modernize their legacy systems, must adopt a financial viable evolution strategy to gratify the needs of modern business environment. There are various options available to modernize legacy system in to more contemporary system. Over the last few years’ legacy system reengineering has emerged as a popular system modernization technique. The reengineering generally focuses on the increased productivity and quality of the system. However many of these efforts are often less than successful because they only concentrate on symptoms of software reengineering risk without targeting root causes of those risk. A subjective assessment (diagnosis) of software reengineering risk from different domain of legacy system is required to identify the root causes of those risks. The goal of this paper is to highlight root causes of software reengineering risk. We proposed a root cause analysis model RCause that classify root causes of software reengineering risk in to three distinctive but connected areas of interest i.e. system domain, managerial domain and technical domain. .

Theory and algorithms for slicing unstructured programs

Program slicing identifies parts of a program that potentially affect a chosen computation. It has many applications in software engineering, including maintenance, evolution and re-engineering of legacy systems. However, these systems typically contain programs with unstructured control-flow, produced using goto statements; thus, effective slicing of unstructured programs remains an important topic of study. This paper shows that slicing unstructured programs inherently requires making trade-offs between three slice attributes: termination behaviour, size, and syntactic structure. It is shown how different applications of slicing require different tradeoffs. The three attributes are used as the basis of a three-dimensional theoretical framework, which classifies slicing algorithms for unstructured programs. The paper proves that for two combinations of these dimensions, no algorithm exists and presents algorithms for the remaining six combinations.

Data Reverse Engineering of Legacy Databases to Object Oriented Conceptual Schemas

This paper presents a solution and a methodology to recover legacy databases of most DBMS using formal-method based techniques. These formal methods (terms rewriting systems) are applied during the data reverse engineering process and allow for an automatic approach. This automatic approach reduces the time invested and the number of people involved in the data reverse engineering and data migration processes. This solution is being implemented in the RELS (Re-Engineering of Legacy Systems) tool. The RELS tool is under development in the Department of Information Systems and Computation of the Valencia University of Technology in collaboration with the industrial partner CARE-Technologies. RELS is used together with the model compiler Sosy Technology® of CARE-Technologies and provides a complete solution to the re-engineering proccess.

Iterative reengineering of legacy systems

During its life, a legacy system is subjected to many maintenance activities, which cause degradation of the quality of the system: When this degradation exceeds a critical threshold, the legacy system needs to be reengineered. In order to preserve the asset represented by the legacy system, the familiarity with it gained by the system's maintainers and users, and the continuity of execution of current operations during the reengineering process, the system needs to be reengineered gradually. Moreover, each program needs to be reengineered within a short period of time. The paper proposes a reengineering process model, which is applied to an in-use legacy system to confirm that the process satisfies previous requirements and to measure its effectiveness. The reengineered system replaced the legacy one to the satisfaction of all the stakeholders; the reengineering process also had a satisfactory impact on the quality of the system. Finally, this paper contributes to validate the cause-effect relationship between the reengineering process and overcoming the aging symptoms of a software system.

Architectural Re-engineering of Janus using Object Modeling and Rapid Prototyping

This paper describes a case study to determine whether computer-aided prototyping techniques provide a cost-effective means for re-engineering legacy software. The case study consists of developing an object-oriented modular architecture for the existing US Army Janus combat simulation system, and validating the architecture via an executable prototype using the Computer Aided Prototyping System (CAPS), a research tool developed at the Naval Postgraduate School. The case study showed that prototyping can be a valuable aid in the re-engineering of legacy systems, particularly in cases where radical changes to system conceptualization and software structure are needed. The CAPS system enabled us to do this with a minimal amount of coding effort.

Identifying and communicating expertise in systems reengineering: a patterns approach

The reengineering of legacy systems — by which we mean those that have value and yet `significantly resist modification and evolution to meet new and constantly changing business requirements' — is widely recognised as one of the most significant challenges facing software engineers. A complex mixture of business and technical factors must be taken into account to ensure success, and there is a wide range of different contexts each with its own problems. Moreover, the business needs do not stay constant while the technical factors are dealt with. In the paper it is argued that the main problem is not that the necessary expertise does not exist, but rather, that it is hard for software engineers to become expert in all of the necessary areas. It is proposed that systems reengineering patterns may help to codify and disseminate expertise, and that this approach has some advantages over conventional methodological approaches. This contention is supported by means of some candidate patterns drawn from the authors experience and supported by information from elsewhere.

The Story of Re-engineering 350,000 Lines of FORTRAN Code

This paper describes a case study to determine whether computer-aided prototyping techniques provide a cost-effective means for re-engineering legacy software. The case study consists of developing a high-level modular architecture for the existing US Army Janus combat simulation system, and validating the architecture via an executable prototype using the Computer Aided Prototyping System (CAPS), a research tool developed at the Naval Postgraduate School. The case study showed that prototyping can be a valuable aid in re-engineering of legacy systems, particularly in cases where radical changes to system conceptualization and software structure are needed. The CAPS system enabled us to do this with a minimal amount of coding effort.

Systems reengineering patterns

The reengineering of legacy systems --- by which we mean those that have value and yet "significantly resist modification and evolution to meet new and constantly changing business requirements" --- is widely recognised as one of the most significant challenges facing software engineers. The problem is widespread, affecting all kinds of organisations; serious, as failure to reengineer can hamper an organisation's attempts to remain competitive; and persistent, as there seems no reason to be confident that today's new systems are not also tomorrow's legacy systems.This paper argues1. that the main problem is not that the necessary expertise does not exist, but rather, that it is hard for software engineers to become expert;2. that the diversity of the problem domain poses problems for conventional methodological approaches;3. that an approach via systems reengineering patterns can help.We support our contention by means of some candidate patterns drawn from our own experience and published work on reengineering. We discuss the scope of the approach, how work in this area can proceed, and in particular how patterns may be identified and confirmed.

Planning the reengineering of legacy systems

How can you know if reengineering is cost-effective? If it is preferable to new development? Or to maintaining the status quo? The author proposes a way to quantify the costs and prove the benefits of reengineering over other alternatives and offers some advice on contracting a reengineering project.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>