In Part 1 of the Analyzing a Legacy Application series we introduced our ATM simulation app, imported the Java source code into a UModel project, and refined a class diagram to see an overview of the application classes and their relationships. In this entry we will create use case diagrams to document the current functionality of our ATM app and we’ll add to one use case diagram to plan a future enhancement. As we saw in Part 1, when a user runs our ATM simulation, he is asked to log in with an account number and PIN, then is presented with a transaction menu that summarizes all available interactions with the application: With the Transaction menu as a guide, we can create an overview use case diagram that documents user interactions with the ATM simulation: If you are familiar with UML notation, the first thing you may have noticed is the actor in our diagram doesn’t look like the typical UML stick figure. UModel lets software modelers assign any Windows .bmp image file to represent an actor in a use case diagram. We used the Properties helper window to assign an image from the library provided with UModel. A use case diagram is not the appropriate place to define application flow or object-oriented classes, but simply to document how a user (an actor in UML terminology) interacts with the system. We can create additional use case diagrams to show more detail about each interaction. Expanding each interaction in a separate diagram improves clarity by keeping each layout simple and uncluttered and leaves plenty of space to try out different options. We added authentication of the account number and PIN in a note instead of a use case oval because the ATM user is not the actor who performs that step. From real-life ATM experience we can guess (because we haven’t looked at the code yet) that a withdrawal will be cancelled if the amount requested is larger than the account balance. But comparing the withdrawal amount and account balance is not done by the user, so that activity is also not drawn in a use case oval. The arrow inside the Withdraw Cash use case indicates a hyperlink. UModel lets you can attach one or more hyperlinks to any element in your diagrams. A hyperlink can reference a URL, an external file, or another diagram. The hyperlink dialog even lets you define helper text for your hyperlinks. If you define more than one hyperlink, your helper text becomes a pop-up selection menu. Let’s say we’ve been assigned to modify the existing ATM Simulation to charge a fee for each withdrawal. If the withdrawal amount is less than $100, the fee will be $2. If the withdrawal amount is $100 or higher, the fee will be $4. Since the ATM is not stocked with one dollar bills, the fee must be charged against the account, not deducted from the cash withdrawal. The fee will be disclosed before any cash is dispensed and the user will be allowed to cancel the transaction. We can add the new requirement to our ATMWithdrawal use case diagram. We changed 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. But lots of people are confused about the difference between include and extend and it’s best to be absolutely clear. We can also take advantage of the UModel Layers feature to place all elements related to the new feature on a separate layer. Now the Layers helper window allows us to show or hide the planned feature in our diagram view. Real world ATM experience tells us a transaction is missing from the legacy ATM simulation. The transaction menu does not offer an option to transfer funds between accounts. From the diagrams we’ve already created, we can see the original application design will make a transfer operation difficult to implement. The user sign in is based on the account number, and it appears that the legacy application does not understand the concept of a single bank customer who has both a checking account and a savings account. If our manager requests the transfer funds feature, we’ll need to have a conversation with our company’s enterprise software architect. A user ID linked to multiple accounts will need to be implemented not only in our ATM Simulation app, but also in the bank database. The Jolt award-winning Altova MissionKit for Enterprise Architects is a collection of eight XML, database, and UML tools for the enterprise software architect who may require UML modeling and database management tools in addition to advanced XML, Web services, and data integration capabilities. Click here to download a fully-functional 30-day trial. In the next installment we’ll look at the legacy ATM simulation from a completely different perspective as we prepare to dive into the code. See ya later!
Tags: database tool, DatabaseSpy, demo videos, IBM DB2, MissionKit, Oracle, SQL Server, Sybase
We’ve just launched the third video in the DatabaseSpy series. Exploring Databases is a tour of the DatabaseSpy Online Browser, a powerful tool for viewing, searching, and analyzing one or more connected databases. Exploring Databases builds on the preceding video, Database Connections, which demonstrated how easy it is to use DatabaseSpy to connect to one or more databases. You can even simultaneously connect to databases of different types. And DatabaseSpy supports the most popular databases in production today, including Microsoft SQL Server, IBM DB2, Oracle, Sybase, MySQL, and more. Once you’re connected, the DatabaseSpy Online Browser shows you an expandable hierarchy of the database structure. It’s a great place to start exploring an unfamiliar database or quickly navigate to any specific element you need to work with in a familiar one. The Altova Flash videos are proving to be a popular feature on our Web site, with close to 350,000 views in all. If you haven’t seen an Altova product video yet, you’re missing a great opportunity to get a flavor for components of the award-winning Altova MissionKit by seeing them in action. If you’re already a fan, check back again soon — we’re in the studio working on more videos right now.
Tags: C#, Java, software modeling, UML, UML tool, UModel, Visual Basic
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. This is the first of a series in posts where we will 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 focus more on techniques you can apply to your own Java, C#, and Visual Basic projects, rather than the example code. Here is a view of the legacy application running in a command window: The original developer conveniently provided the sample account information, so we can log in. The application then presents a familiar ATM transaction menu: If we inspect the folder containing the application, we see Java source files and compiled .class files, but no project files. That’s not a problem. The UModel Project menu lets us 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. Before we start, we’ll want to make sure to set the UModel Options to automatically draw any class associations defined in the source code: As we import the folder, we’ll also want to include any JavaDocs comments in the source code as Documentation for our UModel project: For our first look at the legacy application we’ll want a high-level overview, so we won’t open all the optional compartments: UModel imports the project in just a few seconds, and the message window reports no errors. The Diagram Tree contains two diagrams: We can click the Model Tree tab and expand the source folder to view icons representing all the Java classes UModel imported: We can go back to the Diagram Tree to open the Content of source UML class diagram. After setting all the line styles to orthogonal and repositioning a few lines and classes to avoid overlap, we see the diagram clearly illustrates the application classes and their relationships: Note the name of the Transaction class is in italic, indicating it is an abstract class (or super 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: If we were using only a text editor to examine the legacy application, we would need to look into every single source code file to understand the hierarchy image shown above. That’s because the Transaction class does not internally identify its subclasses. When we do locate one subclass, it does not identify its siblings. And we can’t be sure some other illogically-named class is not a subclass of Transaction until we look at them all. You can also select each class individually to examine its documentation in the Documentation window. Or, if you prefer a cleaner diagram, you can remove the association labels from the diagram only: Now the asterisk representing the definition of “zero to many” multiplicity of Accounts in the BankDatabase is much more apparent. Another member of our development team found a partial class diagram purporting to represent the legacy project and passed it on. We can immediately see it does not look like the diagram UModel generated: The documentation for our legacy app does not match the code – an unfortunate but common event! There are several differences between the old diagram and the one we generated:
· The associations between ATM and the physical components are shown as composition associations
· The association between ATM and the BankDatabase is described by a text annotation
· The association between ATM and Transaction also has a text annotation, and it does not even exist in the UModel diagram
· Multiplicity is defined at each end of each association, but none were created by UModel
Let’s consider each point:
· The representation of composition in the Java language is identical to ordinary association, so UModel could not deduce the composition characteristic. Of course the ATM “is composed of” a keypad, screen, cash dispenser, and deposit slot, so we can update the diagram to show composition.
· We can add a text annotation to any UModel association arrow. Simply click the arrow and start typing.
· If UModel did not create an association arrow between the ATM class and the Transaction, one must not be defined in the source code. We will postpone further investigation of this anomaly for now. · Multiplicity as shown in the legacy diagram would also require specific definition in the source code. We’ll leave this for investigation later too. Maybe that old diagram was left in the back of the file cabinet for a reason!
We’ll add the annotation, then update the aggregation characteristic of each ATM association in the UModel properties window. Let’s also use the UModel Layout toolbar to make the rectangles representing all the classes the same size. Now our class diagram looks like this: The completed class diagram just gets us started on our analysis. In the next installments we’ll drill deeper into the application code, automatically generate more UML diagrams, and draw some new diagrams of our own as our understanding of the existing code increases. If you want to jump in right away and reverse engineer your own Java, C#, or Visual Basic legacy app, click here to download a free, fully functional 30-day trial of Altova UModel.