Figure 11- - uploaded by Vinicius Cardoso Garcia
Content may be subject to copyright.
Source publication
his article presents a strategy of Component-Oriented Software Reengineering using Transformations, to rebuild legacy systems. Components are used to facilitate the reuse and maintenance of the rebuilt system. The strategy is a result of several researches [1,3,4,5,7]. The strategy is divided in 4 steps: Organize Legacy Code, Recover Project, Repro...
Citations
... Thus, we conclude that a lack of tools focused on requirements recovery, instead of pure architecture recovery, still exists. Furthermore, in agreement with flaws of reengineering and reverse engineering area presented in Section 2, and based on industrial experience of the authors and the institutions involved in this work[Fontanette et al., 2002, Alvaro et al., 2003, Almeida et al., 2004, Garcia et al., 2004, Almeida et al., 2007, Brito et al., 2007a, we identified lacks in recovery of entire systems (interface, design and database) and to trace the requirements from user interface to database access, the difficulty of managing huge data amount, and the high dependency on the expert's knowledge. Thus, in order to fulfill these lacks, next Section presents the LIFT – Legacy InFormation retrievalTool.Based on the survey that identified the main approaches in reengineering and reverse engineering areas, with their strong and weak points, presented in Section 2, as well as the study of reverse engineering tools presented in Section 3, we defined, designed, and implemented a tool for reverse engineering, focused on extracting the requirements of legacy systems, in general performed by engineers with low knowledge about the systems which many times have little or no documentation. ...
Nowadays software systems are essential to the environment of most organizations, and their maintenance is a key point to support business dynamics. Thus, reverse engineering legacy systems for knowledge reuse has become a major concern in software industry. This article, based on a survey about reverse engineering tools, discusses a set of functional and non- functional requirements for an effective tool for reverse engineering, and observes that current tools only partly support these requirements. In addition, we define new requirements, based on our group’s experience and industry feedback, and present the architecture and implementation of LIFT: a Legacy InFormation retrieval Tool, developed based on these demands. Furthermore, we discuss the compliance of LIFT with the defined requirements. Finally, we applied the LIFT in a reverse engineering project of a 210KLOC NATURAL/ADABAS system of a financial institution and analyzed its effectiveness and scalability, comparing data with previous similar projects performed by the same institution.
... The construction of this kind of environments, which are referred in this paper as Component Based Software Reengineering Environments (CBSRE), involves issues relating to CASE environments in general, such as tools integration, and issues related to CBSR, such as reverse engineering and component-based development techniques Orion-RE is an extension of a Component-Based Software Engineering Environment, called Orion [25], and integrates different works from our research group, including a transformational system, an UML-based modeling tool, a Java-based programming tool, a network tool, a repository and a middleware platform. A process model, called SRT (Software Reengineering using Transformations) [13], guides the Software Engineer through the usage of Orion-RE, consisting of two major activities: reverse engineering and forward engineering. The first activity aims to recover, through software transformations, the system's design, with basis on the source code and the available information. ...
... However, several researches found in literature [9] [10] [38] attempt to identify requirements related to Component-Based Development and Reengineering Environments. Thus, basing ourselves in literature and in our experience [13] [16] [30] [33] [34], we identified six requirements for CBSRE: -Language and technology independence: A CBSRE can't be fixed in a limited set of languages and/or technologies, since its applicability would be compromised. Legacy systems are written in many different languages, and there are countless new technologies that a reengineering work may focus in. ...
Software reuse is the process of implementing or updating software systems using existing software assets, resulting in a software quality increase, productivity and reducing time to market. One way to achieve reuse is through software reengineering. This papers presents Orion-RE, a Component-Based Software Reengineering Environment that uses software reengineering and component-based development techniques to rebuilt legacy systems, reusing their available documentation and knowledge embedded in the code. Orion-RE integrates several tools: a software transformation system, modeling/development tools, a software artifacts repository, and a middleware platform. A software process model drives the environment usage through the reverse engineering, to recover the system design, and forward engineering, where the system is rebuilt using modern technologies, such as design patterns, frameworks, CBD principles and middleware.
The vast majority of present legacy information systems were implemented using the traditional paradigm. The traditional paradigm consists of modeling techniques used by system analysts such as System Flow Charts and Data Flow Diagrams (DFD) to capture, during the analysis phase, the activities within a system. However, with recent developments, particularly trends towards e-Commerce applications, platform independence, reusability of pre-built components, capacity for reconfiguration and higher reliability, many organizations are realizing they will need to re-engineer their systems into new component based systems that meet these trends given the limitations of legacy systems to adapt to these new technical requirements. There is a high degree of interest and concern in establishing whether or not a full migration to a more portable and scalable component-based architecture will be able to represent the legacy business requirements in the underlying requirements model of the re-engineered information systems. As a result, this study poses the question: Is the resulting component-based requirements model ontological equivalent to the legacy requirements model when shifting paradigms in the re-engineering process? After a literature review, the research study is justified given the differences in requirements modeling between component-based and traditional paradigms, which give an indication that the resulting component model might not represent the same business requirements represented in the legacy system requirements model. The study evaluated the requirements models generated by the component-based and traditional approaches when shifting paradigms in the re-engineering process in order to verify that the re-engineered component-based requirements model was capable of representing the same business requirements of the legacy system. Design science and an ontological evaluation using the Bunge-Wand-Weber (BWW) model were the central research methodologies for this study. A legacy system was selected as part of the case study and re-engineered by using the component-based paradigm with the help of UML diagrams. The requirements model of the legacy system was recovered using reverse engineering and compared to the component-based requirements model using normalized reference models generated with the help of BWW transformation maps. These maps revealed that the re-engineered requirements models were capable of representing the same business requirements of the legacy system. A set of rules was suggested when reengineering legacy into component-based information systems to ensure the same representation of legacy system’s requirements in the re-engineered requirements model. Finally, this research included directions of future research that put emphasis on the development of automated software tools for systems re-engineering that could implement the rules suggested in this study and the ontological methodology approach used.
The vast majority of present legacy information systems were implemented using the traditional paradigm. The traditional paradigm consists of modeling techniques used by system analysts such as System Flow Charts and Data Flow Diagrams (DFD) to capture, during the analysis phase, the activities within a system. However, with recent developments, particularly trends towards e-Commerce applications, platform independence, reusability of pre-built components, capacity for reconfiguration and higher reliability, many organizations are realizing they will need to re-engineer their systems into new component based systems that meet these trends given the limitations of legacy systems to adapt to these new technical requirements. There is a high degree of interest and concern in establishing whether or not a full migration to a more portable and scalable component-based architecture will be able to represent the legacy business requirements in the underlying requirements model of the re-engineered information systems.
This paper presents an approach to retrieve the knowledge embedded in object-oriented legacy system. This approach aids in the migration from object-oriented code, written in Java, to a combination of objects and aspects, using AspectJ. The approach uses aspect mining in order to identify possible crosscutting concerns from the object-oriented source code and extracts them through refactorings into new aspect-oriented code. Next, the aspect-oriented design is retrieved through software transformations and may be imported in a CASE tool, becoming available in higher abstraction levels. The retrieved information constitutes important knowledge that may be reused in future projects or in reengineering.
Many organisations have become aware of the limitations of their legacy systems to adapt to new technical requirements. Trends
towards e-commerce applications, platform independence, reusability of pre-built components, capacity for reconfiguration
and higher reliability have contributed to the need to update current systems. Consequently, legacy systems, typically designed
and developed using traditional methods, need to be re-engineered into new component-based systems. The objective of the study
is to develop a method to compare traditional and component-based models of systems. Design science is the approach used to
build and evaluate the method. The method incorporates and integrates existing methodologies for information systems re-engineering
and conceptual model evaluation. A case study illustrating the comparison method revealed that a re-engineered component-based
conceptual model was capable of representing and enriching all the traditional conceptual model constructs. However, there
was a conflict with the use of data flows as these can represent both events and also couplings between processes, data stores,
and external agents. Thus, the project derived an additional set of rules to use when generating a component-based model to
improve the re-engineering step.