LibraryTechnical BriefsAnalyze a Legacy Application

This Technical Brief was adapted from a series of posts that originally appeared in the Altova Blog. Here is a link to Part 1 of the Analyzing a Legacy Application series. If you would like to reread the entire series, the conclusion of Analyzing a Legacy Application with Altova UModel opens with a list of links to the preceding four parts.

Introduction

Sooner or later nearly every professional developer will be assigned to debug or add features to an existing application the developer did not help create. In these situations, inaccurate or incomplete documentation and lack of access to the original development team can pose huge obstacles. Fortunately, Altova UModel can reverse-engineer existing software to create a visual model that accelerates analysis and improves comprehension of a legacy application, reducing the time needed to track down an existing issue or add new functionality.

This Technical Brief will demonstrate how to apply UModel, Altova’s UML tool for software modeling and development, to analyze an ATM (Automatic Teller Machine) simulation written in Java. The application is based on several ATM examples from popular Java tutorials. Since it is small and the operation of an ATM is familiar, we will be able to focus more on techniques you can apply to your own Java, C#, and Visual Basic projects, rather than the example code.

In the folder containing the application we see Java source files and compiled .class files, but no project files.

You will certainly want to run the legacy application to familiarize yourself with its operation. However, even from the list of class files we can see how the application is designed to follow the functionality of a bank ATM, with some classes that correspond to the physical components: the Screen, Keypad, DepositSlot, and CashDispenser, and other classes that represent user actions: BalanceInquiry, Deposit, and Withdrawal.

An actual ATM would communicate with one or more banks to verify account information and is not likely to contain a BankDatabase class.

The UModel Project menu lets you import a project, a source directory, or even the binary files of a compiled application. Source code for very large projects is likely to be organized in multiple folders, so even when you have a project file, you may want to investigate one folder at a time.

Set the Import Options

UModel normally saves any changes you make to your local user preferences and restores those settings each time you launch a new session. The screenshots that follow illustrate user options that are most relevant when importing existing source code. These options control:

• Diagramming of associations between classes
• Importation of existing JavaDocs in the source code
• Automatic hiding of class attributes and operations compartments

Before you start, you will want to be sure the option is set to automatically draw class associations defined in the source code:

As you import the folder, you will also want to include any JavaDocs comments in the source code as Documentation for the UModel project:

For your first look at the legacy application it’s convenient to examine a high-level overview, without opening all the class attributes and operations compartments:

UModel imports the project in just a few seconds, and the Diagram Tree contains two diagrams:

UML Classes and Diagrams of the Legacy Application

You can click the Model Tree tab to expand the source folder to view icons representing all the Java classes UModel imported:

You can go back to the Diagram Tree to open the Content of source UML class diagram. UModel applies Autolayout logic to the elements of the class diagram, but you can change any element position or style, polishing the diagram to illustrate your application’s classes and their relationships according to your own preferences:

Note the name of the Transaction class is in italic, indicating it is an abstract class, and the BalanceInquiry, Withdrawal, and Deposit subclasses inherit its features. If you click the Transaction class to select it, inheritance is illustrated in the UModel Hierarchy helper window and any JavaDoc comments appearing in the source code immediately before the class definition are displayed in the Documentation window:

Refining the UML Class Diagram

You can also select each class individually to examine its documentation in the Documentation window. Or, if you prefer a cleaner diagram, you can delete the association labels from the diagram without completely removing them from your UML model:

Now the asterisk representing the definition of “zero to many” multiplicity of Accounts in the BankDatabase is much more apparent.

Final Enhancements to the UML Class Diagram

The representation of composition in the Java language is identical to ordinary association, so UModel could not deduce the composition characteristic between ATM and its physical components. Of course the ATM “is composed of” a keypad, screen, cash dispenser, and deposit slot, so you can show composition by updating the aggregation characteristic of each ATM association in the UModel properties window.

You can also add a text annotation to any UModel association arrow. Simply click the arrow and start typing to add an annotation between the ATM and bankDatabase classes, for instance.

The UModel Layout toolbar lets you make the rectangles representing all the classes the same size. The polished diagram class diagram looks like this:

Now the UML class diagram is a useful aid to continue your analysis and to share with colleagues. You can print it, save it as an image file, or include it in project documentation that you can generate automatically with a selection from the UModel Project menu.

Apply UModel® 2012 to reverse engineer your own Java, C#, or Visual Basic legacy application.

 Click here to download a fully functional, free 30-day trial of Altova UModel® 2012!