Over the past 12 months, I have observed significant benefits using the Unified Modeling Language (UML) when developing Rich Internet Applications using Macromedia's Flash Platform and JRun (Java application server).

This article first discusses what the UML is, then lists some of the main diagram types. It highlights how these diagrams can be used and draws attention to some of the benefits I've observed when using them. It concludes with a list of resources.

What Is the Unified Modeling Language
To understand the essence of the UML, consider the elements of its name:

• Unified: The result of unifying three leading approaches to system modelling in the 1990s
• Modeling: concerned with the simplified representation of system structure and behavior
• Language: A language, not a methodology

The UML provides a language-neutral, tool-supported, well-documented standard for modeling systems such as Web applications. It enables system requirements, structure, and behavior to be succinctly captured and effectively communicated.

At the time of writing this article, the UML 2.0 Specification is going through final editing, although you'll find that many books and tools support at least a subset of this specification. A draft version of the specification is available on the Object Management Group's UML Web site. Helpful note - don't try and learn the UML from this document, but it can make interesting reading!

The UML is not a methodology. This point is important. Some people think that you have to use every diagram type to model every aspect of system behavior all the time as part of a complex, cumbersome approach. Not at all. Simply make intelligent choices about what works for you. The UML is designed to serve you, not the other way around.

To illustrate this point, consider the Java programming language. Java is a language, not a methodology. To derive full benefit from your use of Java, you adopt an effective methodology. You may adapt your approach on different projects. You use a subset of Java to build an application. You don't try and use every feature of the language in every application you build.

In the same way, blend the UML into the successful methodology you already use.

Main Diagram Types
Essentially, when you use the UML, you draw diagrams and add notations to them. You may draw a UML diagram by hand on the back of a menu over lunch with a client or on a whiteboard. Equally, you may use a tool such as MagicDraw UML.

There are two main categories of UML diagrams defined by the UML 2.0 Specification:

• Structure Diagrams (six): Concerned with modeling static structure (architecture)
• Behavior Diagrams (seven): Concerned with modeling dynamic behavior

I have found the following diagrams most useful since I began using the UML 12 months ago:

• Use Case Diagram (behavior)
• Activity Diagram (behavior)
• Class Diagram (structure)
• Sequence Diagram (behavior)

Using these four diagrams in sequence has been very effective, so I will address each in turn.

Use Case Diagram
Use case diagrams help to define the requirements of a system from the user's perspective - what they want to achieve when using the system.

The use case diagram is deceptively simple yet incredibly powerful. Notes are added to the diagram, and may of course be supplemented by other documents where appropriate. This is exactly what architects and engineers in other disciplines do too, of course - use blueprints and drawings.

The user may be a human object or software object (if you are developing a Web service in Java for example). The basic syntax is very simple (see Figure 1).

As you can see from the diagram in Figure 1, the system is required to let a user check availability and book a ticket. Notice that the diagram does not go into the detail of how this will be accomplished. It helps them focus on desired outcomes and not the process. For me, that's the power of use case diagrams - focusing minds and drawing out detail. Of course, it's important to remember that clients may:

• Not know exactly what they want or need.
• Be reporting to a boss who has given them unclear, incorrect, and incomplete requirements.
• Be part of a wider team among which requirements are fragmented.
• Forget or contradict their own requirements.

I have noticed a number of business benefits when using use case diagrams. It's the simplicity of the diagram and the practice of going through the process with a client that really pays off. I've noticed that these diagrams help to:

• Discover what clients actually want and need
• Draw in other stakeholders (the boss, co-workers, etc.) to the requirements gathering process on an ongoing basis
• Identify any correct and contradiction in requirements

I was recently involved in a project to build a Rich Internet Application for a business run by three extremely capable directors in their 50s. They found the use case diagram indispensable. At every meeting, the first thing we would do was review it, to confirm that all requirements had been captured and were fully up to date.

As additional requirements were identified, these were either added into the current version or added to a list for future discussion. Either way, it was up to the clients to decide. The use case diagram was a living, breathing document that provided an ideal way to ensure that the interface with the clients remained cohesive.

Letting them each have a copy of the diagram that they could mark up and use in their own internal meetings proved to be a very effective way to draw everybody in and ensure we built the right system.

We became a natural extension of their business; they became a natural extension of our project team. As a result, meetings were more productive, a better application was delivered more quickly, and business was stored up for the future. In addition, our approach helped us to differentiate ourselves from our competition and ensure a strong ongoing relationship with the clients.