Tag Archive for: Java

How to Learn a New Programming Language this Summer


What better goal to set for your summer than learning a new programming language? Forget the “beach books” this summer and set your sights on diving into a new coding language – but which one should you pick?

As reported by EDC there are approximately 24 million professional software developers on Earth, and almost 700 notable programming languages (according to Wikipedia). I would wager a bet there is a staggeringly equal number of places online where you can learn one programming language or another. Whether you are already one of those 11 million coding experts or a newbie to programming, there is a plethora of information out there to sort though.

For the purposes for this blog post, we will certainly look at the world’s most-widely-used programming languages in 2021, but also at important languages for data manipulation and querying, so we’ll discuss: C and its derivatives (C++, C#, and Objective-C), Java, Python, R, JavaScript, Ruby, SQL, and XQuery.

Deciding where to start depends entirely on the kind of development scenarios you have in mind, so we’ve broken things down for you to make it easier. It doesn’t matter if you are a seasoned programmer looking to add a new language to your repertoire or a novice who doesn’t know the difference between C, C++, Objective-C, or C# yet. We have assembled a list of explanations to help you choose which language you may want to conquer next.

shutterstock_416174497_700py
Read more…
Tags: , , , ,

The Altova MissionKit 2013 Introduces Seamless Integration of XMLSpy, MapForce, and StyleVision in Java Applications


The Altova MissionKit 2013, empowers developers to integrate XMLSpy, MapForce, or StyleVision functionality seamlessly in custom Java applications for Windows. This frequently-requested capability adds to existing support for integrating these MissionKit tools in Visual Basic or C# applications, giving developers flexibility to add some or all XMLSpy, MapForce, or StyleVision views and functionality to their own custom apps.

Version 2013 of XMLSpy, MapForce, and StyleVision include a new API that allows each to run inside a window within a Java application developed using the Java Abstract Window Toolkit (AWT) or Java Swing. This functionality allows MapForce 2013, for instance, to be embedded in larger applications where data mapping and transformation is only one requirement.

MapForce running in a Java ActiveX window

Altova provides sample applications with XMLSpy, MapForce, and StyleVision illustrating use of the Java API. You can access the sample applications from the command line or from within Eclipse.

Read more…

Tags: , , , , , , ,

Meet the Altova Team at Oracle OpenWorld


clip_image002Some people say early October brings the most enjoyable weather to San Francisco, and Oracle OpenWorld and JavaOne will make things even better this year from Oct. 2 – 6. If you’re traveling to the City by the Bay for either event, plan to visit the Altova team at booth 106 in the Moscone South Oracle OpenWorld exhibit hall. We’ll be demonstrating all the tools in the Altova MissionKit with special emphasis on multi-database support, tools for working with XML in databases, and solutions for compliance with XBRL, NIEM, HL7, EDI, QR codes, and many other industry standards. Here’s your chance for a personal tour of that Altova tool or feature you’ve been curious to see – whether it’s advanced charting in StyleVision, Java code generation from UML in UModel, or refactoring XML Schemas in XMLSpy. We always enjoy meeting users face to face and hearing about the projects you’re working on too! You can also enter our Altova product raffle for a chance to win a license for Altova MapForce 2011 Basic Edition. We hope to see you there! clip_image003

Tags: , , , , , , , , ,

Solution to the Software Testing with State Machines Challenge


Last month in our blog on Software Testing for State Machines with Altova UModel we discovered unexpected behavior in our model of an air conditioning system and challenged readers to improve the design. This post describes one possible solution. When we ran the Tester application for our model, we saw that the Power switch did not turn the system off when it was in the Standby state. In the state machine diagram in our original model, the only route into Standby from Operating mode is via the Standby button, and the only way out of the Standby state is to press the Standby button again, as seen in the detail below. Detail of a state machine diagram in Altova UModel We can create an alternate exit to power off the system from the Standby state simply by drawing a new transition line from Standby to the Off state, and assigning powerButton() as the event that triggers the transition. UModel makes assigning the trigger easy by providing a pop-up window listing events that are already defined in the model. Pop-up list of triggers for transitions in a state machine diagram in Altova UModel Our completed revision to the model with the new transition from Standby to Off looks like this: State machine diagram in Altova UModel After regenerating the Java code and compiling the new version, we can run the Tester application again. The Debug output message window shows that the system entered Standby in Event 3. Event 4, activation of the Power button, now sets the state to Off. State machine test application generated by Altova UModel Find out for yourself how you can enhance the logic of your own state machine diagrams with Altova UModel – download a free 30-day trial today!

Tags: , , , , , ,

Harness the Power of Chained Transformations in MapForce


Altova MapForce includes the ability to define chained transformations. Chained transformations let you create complex mappings where the output of one mapping becomes the input to another. In other words, two or more components can be directly connected to a final target component. MapForce chained transformation example

Read more…

Tags: , , , , , , , ,

Splitting Large UML Sequence Diagrams


A new feature introduced in UModel 2010 release 2 allows you to split large sequence diagrams when you reverse engineer existing Java, C#, or Visual Basic source code. What are the advantages of splitting a sequence diagram, and how should you decide to split or not? Obviously, a single diagram makes it easy to examine in one view all the interactions that occur during the execution of a class operation. On the other hand, a large, complex diagram can be cumbersome to view, navigate, analyze, and print in a readable format. Fortunately, UModel 2010r2 makes it quick and easy to experiment. After you generate your sequence diagram, if you don’t like the results, just click the Undo button and you can create a new variation by choosing different options in the Sequence Diagram Generation dialog. Or, you can even apply the Generate Sequence Diagram feature more than once to the same class operation, and maintain multiple versions of the sequence diagram in your model. For instance, if you plan to modify the existing code, you might want to keep a permanent record of the “before” and “after” editions to document your changes. We recently adapted our analysis of a bank ATM legacy application to create two new Technical Briefs in the Reference Library section of the Altova Web site, titled Analyze a Legacy Application with Altova UModel and Enhance a Legacy Application with Altova UModel. Enhancement of the code included adding a new method called getFinalOkay directly in the original source code file for the Withdrawal class. When we completed the round trip by synchronizing our UModel project with the application code, the split version of the sequence diagram included a dedicated sub-diagram for the new method. The sub-diagram is automatically labeled with a note and hyperlinked to the main diagram. UML_sequence_diagram If you’re ready to see for yourself how a visual software model can help you work with your own legacy application, click here to download a fully-functional free trial of Altova UModel!

Tags: , , , , , ,

DiffDog Reports for Service


A recent message on Twitter asked whether DiffDog can create a differences report. The short answer is yes! In addition to its renowned directory compare and merge, file compare and merge, database compare and merge, and XML diff merge functionality, Altova DiffDog can create differences reports for directory comparisons and for file comparisons. After you select the directories or files and the compare options you want to apply, you can create a report file by choosing Export differences from the DiffDog File menu. DiffDog Export differences menu option This opens a Save File dialog that lets you choose to create the diff report in text format or as an XML file. Text format reports follow the well-accepted Unix diff style. In the directory comparison example report below, the < character indicates a file that exists only on the left side, > indicates a file exists only on the right, and ! signifies file names that occur in both directories with unequal content. DiffDog directory report text format Report files in XML format are human-readable with descriptive element names and record the the comparison mode and the paths of the directories compared: DiffDog directory report XML format You can also use the DiffDog directory report functionality to create diff report files for comparisons of Zip archives or OOXML documents. Developers and other project stakeholders often want to keep a record of changes to source code files in a software project. DiffDog can create diff reports for all comparisons of text-based files, including source code files. DiffDog can even create detailed XML-aware reports for XML file comparisons. The illustration below shows two versions of a Java source code file: DiffDog file differences example If you read our earlier series on Reverse Engineering an Existing App with Altova UModel, you may recognize this code. Lines 8 and 9 on the left introduce a new class property called fee that is set to an initial value of 2. Here is the file compare report for the differences shown above in text format: DiffDog file differences text report And the XML version of the report for the same portion of the files: DiffDog file differences text report You can even execute DiffDog from a command line to create differences reports automatically. Here is an example of a short batch file that compares the same two directories from our GUI example and writes the output in XML in a file named diff_1.xml: DiffDog batch file The DiffDog Help system includes extensive documentation on all the command line options, including specific instructions on how to integrate DiffDog with 19 popular source control systems. If DiffDog report files get your tail wagging, don’t just Twitter about it! Click here to download a free 30-day trial of Altova DiffDog.

Tags: , , , ,

Part 5 – Analyzing a Legacy Application with Altova UModel


Previously in Part 1, Part 2, Part 3, and Part 4 of this series we applied Altova UModel reverse-engineering functionality to create UML diagrams for an ATM banking simulation application. After analyzing the existing architecture, we planned and implemented a new feature, the withdrawal fee. Even in a reduced size, our updated sequence diagram for the withdrawal transaction clearly represents in graphical form the nested logic structure of the source code. UML sequence diagram (reduced size) This morning we happened to run into the ATM product manager at the coffee machine. “You’ve been working on that ATM code for over a month now,” he said. “When am I going to see what you’ve accomplished?” We can take advantage of the UModel Generate Documentation feature to satisfy this request. UModel will automatically create customized documentation for our project in HTML, Microsoft Word, or RTF formats. The Include tab in the Generate Documentation dialog box lets us choose which diagram types to include, and to specify the level of detail for our report by allowing us to expand each diagram element type. Altova UModel Generate Documentation dialog box For an overview report, we can select all diagram types. We’ll also select class from the Elements list to show further information about the classes in our application. UModel helpfully asks if we want to add elements derived from class as well. Altova UModel Generate Documentation helper After we have selected or adjusted other document parameters, including fonts and sizes, UModel generates the report in just a few seconds. At the top of the first page, the report begins with an index of diagrams and a separate index of elements. Each indexed item is hyperlinked to a bookmark in the document. Altova UModel project documentation in Word format Regardless which format you choose, the resulting report is fully editable. For instance, we can add a footer that includes page numbers and a tag line recording the document creation date. We can grab the tag line UModel created to create our footer. Altova UModel project documentation tag line Our completed report contains all the UML diagrams that describe the legacy ATM application, with detailed class diagrams that show the class properties and operations. Additionally, the illustration of each class is accompanied by a hierarchy diagram to show the class relationships, and a list of all the class associations. Later on as our project evolves further, we can easily generate an updated version of the report. We could even take advantage of the UModel command line functionality or the UModel API to automate creation of project documentation, or we could attach the .html version of the report to our developer team wiki. But for now all we have to do is email the report to the ATM product manager. Conclusion We hope you’ve enjoyed following along with this exercise in Analyzing a Legacy Application with Altova UModel. Although we are ending the series here, in the real world there is much more work to do on our ATM application. For instance, the feature to permit users to accept the fee or cancel a withdrawal remains to be implemented. Or, we could update the legacy code with newer Java language constructs such as generics, annotations, and enumerations. If you’re already experienced with UML we hope we’ve shown you a new trick or two. If you are a developer who’s never tried UML, we wanted to give you some of the flavor and benefits of visual software modeling. Either way, if you’re ready to go further on your own project, click here to download a fully-functional free trial of Altova UModel.

Tags: , , , , , , , , ,

Java Utopia


Java-powered robots, Java mobile phone apps, Java in the cloud, Java running Neil Young’s ’59 Lincoln, a new T-shirt, and photos with Duke! It can only mean the annual pilgrimage to the Moscone Center in San Francisco for JavaOne. XMLSpy and MapForce feature Java code generation and UModel can both generate and reverse engineer Java code. Of course you can use all the Java code you generate with Altova tools royalty free! Check out this YouTube video:

to see and hear a few highlights of JavaOne 2009 and Altova’s presence there.You can also click here to see an interview with Altova’s Technical Marketing Manager filmed at JavaOne by TechTarget.

Tags: , , , , , , , , , ,

Part 4 – Analyzing a Legacy Application with Altova UModel


In Part 1 of this series we imported source code into Altova UModel to create a UML project and we examined a class diagram of our legacy ATM application. In Part 2 we created a series of UML use case diagrams to describe user interactions with the system and we planned an application enhancement to implement a withdrawal fee. In Part 3 we designed a UML state machine diagram to further analyze and document the operation of our system. In this installment we will return to our planned enhancement. We’ve been assigned to implement an ATM withdrawal fee of $2 for withdrawals less than $100 and $4 for withdrawals of $100 or more. In Part 2 we drew a use case diagram to show how users will interact with the new feature: UML use case diagram From our original analysis of the object-oriented classes in Part 1, we know our system contains a Withdrawal class, which is the logical place to implement our new feature. We can display a new 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. UModel Model Tree helper window UML class diagram We chose to create a hierarchy diagram so all the properties of the Withdrawal class are visible, including inherited properties from the Transaction class. Before implementing the fee feature, we have a related leftover question to investigate. We wanted to verify that the current code includes a test to make sure a withdrawal amount requested by the user does not exceed the current account balance. A UML sequence diagram will let us trace the execution flow of a withdrawal. UModel can automatically generate sequence diagrams from the operations of reverse-engineered classes. We can select the execute operation in our class diagram and choose Generate Sequence Diagram from the UModel right-click context menu to create the diagram we need. Altova UModel Sequence Diagram Generation dialog The UModel Sequence Diagram Generation dialog offers several options that will assist with our implementation of the new feature. We selected Automatically update because we will want to update the diagram later after we modify the code, and showing the code in a separate layer can help us focus on the withdrawal logic. UML sequence diagram The size of the scroll handles indicates we are only seeing a small portion of the sequence diagram in the current window. We can 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 auto-hide the Diagram tree and Properties windows, which allows us to enlarge the Overview helper window: UModel Overview navigation window We can explore the sequence diagram by dragging the red square in the Overview window. This lets us quickly locate the comparison of the withdrawal amount and account balance. UML sequence diagram We can also see the error messages that display if the ATM does not contain enough cash or if the account balance is too low. UML sequence diagram Returning to the Withdrawal class diagram, we can add the fee property and set its default value: UML class diagram We’ll make a first pass through implementation of the fee logic without including the user cancel option. Updating the source code from our model adds the fee property to the Withdrawal class. Then we’ll jump into our favorite source code editor to implement the fee logic directly in the Withdrawal.java file. Testing our recompiled application shows the following: ATM Simulation The starting balance was $147. After withdrawing $100, the new balance is $43. The fee is displayed in a new message, and the ending balance is correct. But now the sequence diagram in our UML model is inaccurate because it doesn’t include the fee feature. We can correct the sequence diagram by updating the UML project from the revised source code. The UModel Messages window indicates that changes in the Withdrawal.java file caused the sequence diagram to be regenerated. And, we can easily navigate the diagram to locate our new test of the withdrawal amount to see if the fee needs to be increased to $4. image10a Now that our modified sequence diagram graphically represents updated operation of the ATM, we can be assured the harried driver we met in Part 3 of this series has enough cash to buy that ice cream cone! In our next installment we’ll take advantage of another UModel feature to generate rich project documentation for our work so far – one more advantage of keeping our UML model and application source code synchronized. If you’re ready to try Altova UModel on your own Java, C#, or Visual Basic legacy application, click here to download a free fully functional 30-day trial.

Tags: , , , , , , , ,

Part 3 – Analyzing a Legacy Application with Altova UModel


In Part 1 of this series we applied the reverse engineering functionality of Altova UModel to import source code from an existing ATM simulation application. We created a UML class diagram to illustrate the application’s class hierarchy and class relationships. In Part 2 we drew a UML use case diagram to document user interactions with the system and we drew several additional use case diagrams to document interaction details and a planned enhancement. In this installment we’ll look at the ATM from another point of view. On a hot summer afternoon, a harried driver spots an ice cream stand with a drive through lane up ahead. Just one problem – no cash! So he turns in at the strip mall parking lot and parks by an ATM in a glass kiosk. Before he even gets out of the car, our overheated bank customer wonders about the state of the ATM. Is another customer with complicated banking business already using it? Even if no one is inside kiosk, could the ATM be out of service? A UML state machine diagram (also called a state diagram) will let us map the states of our simulated ATM and the triggers, events, and transitions between states so we can better understand how our legacy application operates. Let’s return again to our experience running the simulation to get started: ATM Simulation Log In menu ATM Simulation Transaction Menu When we launched the legacy application, our simulated ATM entered its idle state, awaiting the first customer: UML State Machine Diagram start Next, it can be helpful to identify and draw additional states in disconnected ovals. We’ll be able to move these ovals around like pieces of a puzzle to find the logical sequence without worrying about the transitions from one state to the next. UML state machine diagram - preliminary This preliminary list of the ATM states is only our first rough draft. The state descriptions were suggested by our legacy application’s menu entries, and it’s obvious we can simplify: · There is no difference between Selecting First Transaction and Selecting Next Transaction, so these should be combined · Logging Out is probably not a state, but an instantaneous transition when our user presses 4 at the Transaction menu · We can assign user entry of a withdrawal amount or a deposit amount as sub-states within the Performing Transaction state The third item simplifies our diagram and would also be consistent with our treatment of user entry of the account number and PIN as part of Authenticating User. After we make these changes and add transitions, our diagram looks like this: UML state amachine diagram with transitions The simple transitions we’ve added are triggers that cause the ATM to leave one state and enter the next. Also, notice every state has at least one entry and one exit – otherwise the legacy application could force our user into a dead end. The diamond element between Selecting Transaction and Performing Transaction is the UML symbol for a choice of flows. At first it may seem illogical for the application to allow the user to sign out before performing any transaction, but that is an option our legacy application offers in the Transaction menu. And users in the real world have been known to change their minds at the last minute! We were careful to use consistent language wherever possible for our element names and descriptions. The states are named with verbs in the present tense that end in -ing. Transitions are labeled to indicate completion of the action that causes the state to change. Consistent element naming enhances diagram clarity. Once we have a working overview state diagram like the one above, it’s worthwhile to consider what happens if a transition is attempted, but not completed successfully. The ATM user might enter an invalid account number/PIN combination, or an authenticated user could request a withdrawal amount that exceeds the account balance. We can enhance our state diagram to include these possibilities: Complete UML state machine diagram Now our state machine diagram shows many alternate paths through the application execution, not just the single, all-successful “Happy Path.” We chose a vertical orientation for the layout of our diagram, but there is no rule dictating that form. Some applications will lend themselves to a horizontal layout, or maybe that is simply your personal preference. This illustration shows a small portion of our state machine diagram in horizontal form: UML state machine diagram in horizontal layout Whichever state machine diagram layout you choose, you should not draw transition lines that intersect or overlap. Drawing a UML state machine diagram may seem like overkill for our ATM simulation, since the legacy application is small, and we are all familiar with the way ATMs work. However, these techniques can be very illuminating when you have to work on a much larger application operating in an unfamiliar or complex subject domain. If you are ready to create UML state machine diagrams for your own Java, C#, or Visual Basic legacy application, click here to download a free fully functional 30-day trial of Altova UModel. In our next installment we’ll look in detail at the withdrawal transaction and the new feature we planned in Part 2.

Tags: , , , , , , , ,

Part 2 – Analyzing a Legacy Application with Altova UModel


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: ATM Simulation transaction menu With the Transaction menu as a guide, we can create an overview use case diagram that documents user interactions with the ATM simulation: ATM Simulation overview use case diagram 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. Altova UModel Properties Window 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. Detailed user sign in use case diagram 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. Withdraw cash use case diagram 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. Altova UModel hyperlinks dialog Hyperlink pop-up text in use case diagram 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. Enhanced Withdraw Cash 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. Altova UModel Assign Layer context menu Now the Layers helper window allows us to show or hide the planned feature in our diagram view. Altova UModel Layer helper window 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: , , , , , ,

Analyzing a Legacy Application with Altova UModel – Part 1


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: Analyzing a Legacy Application with Altova UModel The original developer conveniently provided the sample account information, so we can log in. The application then presents a familiar ATM transaction menu: Analyzing a Legacy Application with Altova UModel If we inspect the folder containing the application, we see Java source files and compiled .class files, but no project files. Analyzing a Legacy Application with Altova UModel 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. Altova UModel Project Menu 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: Altova UModel Options dialog As we import the folder, we’ll also want to include any JavaDocs comments in the source code as Documentation for our UModel project: Altova UModel Import Directory options For our first look at the legacy application we’ll want a high-level overview, so we won’t open all the optional compartments: Altova UModel diagram generation options UModel imports the project in just a few seconds, and the message window reports no errors. The Diagram Tree contains two diagrams: Altova UModel reverse engineering project We can click the Model Tree tab and expand the source folder to view icons representing all the Java classes UModel imported: image9 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: Altova UModel UML class diagram 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: Altova UModel Hierarchy 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: Altova UModel right-click context menu Now the asterisk representing the definition of “zero to many” multiplicity of Accounts in the BankDatabase is much more apparent. Altova UModel UML class diagram 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: UML class diagram for legacy application 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: Modified UMLclass diagram for ATM project 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.

Tags: , , , , , ,

Altova UModel adds Business Process Modeling, Layers, Java 6.0, C# 3.0, and VB 9.0, plus much more in v2008r2


The Altova UML tool for software modeling and application development keeps getting better and better, with recently launched UModel Version 2008 Release 2 adding exciting new features including support for business process diagrams in BPMN notation, code engineering support for Java 6.0, C# 3.0, and Visual Basic 9.0, diagram layers, enhanced auto-completion, and much more. We can’t wait to see how users take advantage of the new layers feature: In UModel 2008 Release 2 you can assign each diagram element to a specific layer and set each layer to be hidden or visible. Just imagine how you could take advantage of layers to build simplified views within complex activity diagrams, state machine diagrams that contain superstates and substates, to identify the roles of different parties in business process diagrams, or in virtually any UML diagram that grows to more than two dozen or so elements!

Tags: , , , , ,

Altova at JavaOne


Altova exhibited at JavaOne 2008 this year, talking with attendees about their projects and challenges, and showing them demos of relevant features in the Altova product line. In particular, booth visitors were interested in learning about Altova’s support for Java code generation in multiple tools, as well as the new Microsoft® Office 2007 / Office Open XML (OOXML) support that was recently added across the product line. Here is a short video of Altova’s David McGahey doing a product demo in the Altova booth.

Several other videos from the Altova booth at JavaOne are available on YouTube.

Tags: , , , ,