Software Evolution and Reengineering Group

 
RESEARCH PROJECTS AT A GLANCE
Reverse Engineering Legacy Systems into UML Use Case Diagrams
   


Legacy systems are difficult to maintain but still valuable to the business.?On the one hand, the legacy systems are critical to the businesses. Legacy system may contain the central data and covers the essential business rules.?Although the code is difficult to read and understand, it may be the only record of the operation rationale. On the other hand, it is costly to maintain them. Legacy systems may have high rate of operation failure. It often causes its own problems and sometimes even core risks, especially when the developers of the legacy software system are gone, or the documentation is not complete. It is difficult to correct its errors or maintain it. The disasters are inevitable for legacy systems within changing environment.?

One way to deal with legacy systems is to reverse engineer them into use case diagrams of the UML in order to maintain, modify, and reuse them. The process includes several steps described below. The transformation of legacy systems starts with the analysis of the original code. The legacy software has some code that is useless. That code is called "dead code". That code can be easily eliminated. The structure of legacy systems is extracted and improved with an intermediate programming language into the clean code.?The specification of the legacy systems is refined from the clean code. Because it contains all the information of the code, it is unreadable. Transforming specification into requirements of the legacy systems results in the loss of detailed information. The requirements of the legacy systems are more readable and more understandable than the software specification. The requirements of the legacy systems describe the system functionality. Use cases and associated actors can be identified from the system requirements.?Use case diagrams present a high-level view of system usage as viewed from the outsider's perspective. They show the functionality of the system and how the system interacts with the outside world. They are produced based on those actors, their related use cases and the relationships among actors and use cases.