Extracting UML from Legacy Applications

Michael Oara

CEO, System Renewal, Inc.

For a new application, UML diagrams are usually built by gleaning information form the user community that the application is supposed to serve. There is a process in which the analyst starts by identifying the main concepts and categories and describing the high level processes in need of automation. The initial high-level information is then analyzed and new details are added until some concrete models emerge naturally. After the models are clear and well defined, some forward engineering helps make the transition to the actual code of the application.

While for new applications the top-down approach described above works very well, for existing applications a new approach is warranted. The existing application already contains a large volume of detail that should not be discarded. The paradigm is now different and involves two movements: bottom-up then top down. In the bottom up phase, the existing application is mined for specific information that would result in models at the appropriate level of abstraction. These models can be refined to reflect new requirements or business conditions and in the last phase they are used for generating or building the new application.

What UML diagrams can we build based on information minded from the legacy code via static analysis tools? Here are some possibilities.

From Screen Navigation Diagram to Use Case Diagrams

The Relativity’s SOA Analyzer tool can extract screen navigation diagrams (see the section on user interface and screen navigation). One such diagram may look like in Figure 1:

Figure 1 - Screen navigation

In this diagram, the boxes are screens (you can see both their technical and business names) and the edges are transitions between screens, which happen on certain events (like pressing a Return key). The diagram gives us a lot of information about the use cases and activities supported by the legacy application. We can notice, for instance, that the operator can register a customer in the system (via MNTMAP2 – Customer Change Screen) and can specify an order (via ORDMAP1 – Order Screen). From this we can build a UML diagram, as that in Figure 2:

Figure 2 - Order Entry use cases

We can even specify an activity diagram, as that in Figure 3:

Figure 3 - "Create an order" activity diagram

We have used some very simple and self-obvious cases here. In real life legacy applications may contains tens or hundred of screens with complex navigation between them. Deriving these diagrams from the actual screen navigation would offer the advantage that all cases are accounted for and no important aspects are left out.

As such UML diagrams are created from the analysis of the legacy application, they initially reflect the “as is” state of the application. They could be the starting point for creating a “to be” model, which will serve as the specification of the modernized application.