LibraryTechnical BriefsEnhance a Legacy Application

This Technical Brief builds on the preceding brief titled Analyzing a Legacy Application with Altova UModel. Together they were 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

In the previous Technical Brief titled Analyzing a Legacy Application with Altova UModel, we imported classes from the source code of an existing application and refined the resulting class diagram to view the application’s object-oriented architecture. That is rarely the end of a developer’s assignment, but more likely a prelude to the task of fixing a bug or adding new functionality to the legacy application. In this Technical Brief we will use the UML model to dig deeper into the application, then modify the code to add a new feature, and complete the round trip by updating the model to accurately reflect the revised code.

Although the legacy application was written in Java, the techniques you will read about apply equally well to C# or Visual basic source code.

Planning a New Feature for the Legacy Application

Our example application is an ATM simulation project. The legacy code currently supports the following features:

• User login and password verification
• A transaction menu that features typical ATM functionality:

•  – Display account balance
•  – Withdraw cash
•  – Make a deposit
•  – Sign out

We saw in our earlier analysis that the simulated transactions are implemented in classes called BalanceInquiry, Withdrawal, and Deposit that are subclasses of the Transaction class.

The ATM simulation application does not currently charge a withdrawal fee. Your assignment is to add this functionality. Whenever a withdrawal is selected, the user must first be informed of the fee amount. The application must then ask the user to accept the fee and provide an opportunity to cancel the withdrawal. If the user chooses to proceed, the withdrawal amount plus the fee must be subtracted from the account balance. Furthermore, if the withdrawal amount is $100 or greater, the fee is $4. If the withdrawal amount is less than $100, the fee is $2.

Diagramming the New Feature

One way to visualize the new feature is to start by drawing a UML use case diagram to capture the requirements. The UML model created in the previous technical brief by reverse engineering the source code does not include any use case diagrams, so you might even want to take a step back and create an overview use case diagram that documents all the user interactions with the ATM simulation.

Your first use case diagram to show all the user interactions with the ATM might look like this:

You can create an additional use case diagram to show more detail about the Withdraw Cash transaction. Expanding the transaction in a separate diagram improves clarity by keeping each layout simple and uncluttered. Plus, you’ll have plenty of space in the main design pane to try out different options.

The arrow inside the Withdraw Cash use case indicates a hyperlink. UModel lets you attach one or more hyperlinks to any element in your diagrams. A hyperlink can reference a URL, an external file, another diagram, or any UML element in your model. The hyperlink dialog even lets you define helper text for your hyperlinks.

Now you can add the new requirement to your ATMWithdrawal use case diagram:

The UModel Styles helper window lets you change the color of the Approve fee use case oval to indicate this is a planned feature that is not yet implemented. Some developers would argue that the note attached to the Approve fee oval is redundant, since the include notation alone signifies that Approve fee is a required component of Withdraw Cash. Lots of people are confused about the difference between include and extend, so it’s best to be absolutely clear.

Also note that comparing the withdrawal amount to the account balance and transferring the fee to the bank are not shown. Those activities are not performed by the user, so they are not included in the use case diagram.

Analyzing an Object-Oriented Class

It’s logical that the fee feature will be an enhancement to the existing Withdrawal class. You can display a new UML class diagram for the Withdrawal class by selecting it in the Model Tree and choosing from the right-click context menu to create a new diagram.

If you chose to create a hierarchy diagram, all the properties of the Withdrawal class are visible, including inherited properties from the Transaction class.

A UML sequence diagram will let you trace the execution flow of a withdrawal. UModel can automatically generate sequence diagrams from the operations of reverse-engineered classes. You can select the execute operation in your class diagram and choose Generate Sequence Diagram from the UModel right-click context menu to create the diagram you need.

The UModel Sequence Diagram Generation dialog offers several options that will assist with your implementation of the new feature. Select the Automatically update diagram option to easily update the diagram later after you modify the code. Showing the code in a separate layer can help us focus on the withdrawal logic blocks by temporarily hiding the code layer. Since this is your first look at the execute operation, you probably won’t want to split into smaller diagrams. Later on, if you find the sequence diagram is complex and cumbersome, you can always generate another copy of the same diagram with the split option turned on.

Sequence Diagram from a Class Operation

When you open the sequence diagram, the size of the scroll handles indicates you are only seeing a small portion of the operation in the current window.

You could shrink the view to fit the window, but the text will probably be illegible. Instead, let’s take advantage the flexible UModel user interface to enlarge the Overview helper window:

You can easily identify shaded areas indicating nested logic blocks within the code, as you explore the sequence diagram by dragging the red square in the Overview window. This lets you quickly locate the menu of withdrawal amounts offered to the user.

You can also see where the user selection is returned. This might be the logical point to calculate the withdrawal fee and ask the user to accept it.

Returning to the Withdrawal class diagram, you can add the fee property and set its default value. Simply right-click in the properties compartment of the Withdrawal class and choose New / Property from the context menu.

You can synchronize the code with changes in the model to update the Withdrawal.java class file with the new fee property. At this point, to implement the fee logic, you will want to edit the source code directly in a text editor. One way to implement the user fee logic would be to add a new method to the class file.

When you finish working in the code, you can synchronize the UML model to illustrate the new feature in the updated application. You can use the model to create project documentation, or you can share it with other team members.

If you are working in Visual Studio or Eclipse, you can even enable automatic synchronization to keep the model aligned with each revision as you work in the source code.

After round-trip engineering, the updated class diagram shows both the new fee property originally created in the model, and the finalOkay property added directly in the source code.

The updated sequence diagram shows your new call to the getFinalOkay method, and the logic block for user acceptance.

If you choose to generate another copy of the sequence diagram with the Split into smaller diagrams option selected, your new getFinalOkay method is illustrated in a sub-diagram that is hyperlinked to the main sequence. This can be a good strategy to isolate and more clearly identify functionality added in this iteration.

Conclusion

If you’re new or relatively inexperienced with UML, we hope these Technical Briefs inspired you with ideas you can apply to your own development projects. Our aim was to demonstrate the value of visual software modeling without focusing in detail on individual elements in the UML syntax. The UModel properties helper window, tool tips, and syntax menus supplement the rich integrated Help system to guide you through diagrams and models that may be unfamiliar because they were generated directly from Java, C#, or Visual basic source.

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