Over the past 12 months, I have observed significant benefits using the Unified Modeling Language (UML) when developing Rich Internet Applications using Macromedia technology.

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 modeling 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 was 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 ColdFusion Markup Language (CFML). CFML is a language, not a methodology. To derive full benefit from your use of CFML, adopt an effective methodology. You may adapt your approach on different projects. Use a subset of the CFML to build an application. Don't try and use every tag and every function 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, draw diagrams and add notation 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'll address each in turn.

Use Case Diagram
Use Case Diagrams help to define the requirements of a system from the users' perspective - what they want to achieve when using the system.

It's 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 exposing a ColdFusion Component as a Web service for example). The basic syntax is very simple.

As you can see from Figure 1, the system is required to let a user check availability and book a ticket. Notice that the diagram doesn't 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 amongst which requirements are fragmented
• Forget or contradict their own requirements