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 incorrect and contradiction in requirements

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.

Activity Diagram
Once the requirements of a system from the users' perspective have been defined, Activity Diagrams help to define how this user experience will be achieved.

Activity Diagrams are also extremely powerful. They're well suited to fleshing out the details of a use case by modeling the detailed interaction between a user and a system or screen. Activity Diagrams are used to model:

• Business processes
• Flow of control in an executing program
• Details of a method

As you identify and diagram the different activities, you'll naturally see a pattern of objects emerge to which the different activities can be assigned. You can use the swim lanes to assign responsibilities to different objects - whether those objects are people or software.

Class Diagram
Class Diagrams are used to model the classes of objects in a system (people and software). In the context of this article, the software building blocks are likely to be ColdFusion Components (CFCs) and Java classes.

Think of a CFC - it has properties and methods and can be represented as shown in Figure 3.

The Order.cfc has an orders property, which is an array of order items, each one represented by an instance of OrderItem.cfc. Although this could simply have been shown as an attribute inside the class, it's often more meaningful to represent such a property using an association as above.

On this point, I found Martin Fowler's excellent book, UML Distilled, particularly helpful. I highly recommend it. He goes into Class Diagrams in some detail and wisely splits his coverage into two chapters, focusing the first chapter on the essentials.

Class Diagrams seem to follow so naturally from Activity Diagrams; the activities identified often may neatly correspond to methods in a Class diagram, which helps save time and increase productivity.

There is, of course, no requirement to identify every property or method on a class in a class diagram. You may choose to show only public methods, for example. Equally, you don't have to show all classes and relationships between them. Again, use what works for you.

Class Diagrams really help when architecting the system and seem to give the design "room to breathe." It seems that if the design is elegant, the implementation is elegant too. If the implementation is elegant, it can be more pleasurable and cost-effective to evolve and maintain on an ongoing basis once the system has been put into production.

In Ian Sommerville's definitive work, Software Engineering, he cites (and qualifies) research that suggests up to 90% of software costs are evolution costs. Looking at this another way, if all you build for a client is the initial implementation of a system, you may only be getting as little as 10% of the revenue stream that you would otherwise get from that client over the lifetime of the system. Of course, these figures will vary significantly, but it's an interesting thought.