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.
|