The Collaboration Diagram
The first draft of the class diagram is now complete. Now we'll use the class diagram and make our collaboration diagrams. Start by copying the class icons from your class diagram to a blank diagram. Draw lines between the elements you think will interact with one another. Add a stick figure to represent the user and draw an arrow from the user to the first element in the diagram the user will interact with. Put a number "1" next to this arrow followed by a description of the interaction. Let's use the task list application from our previous example:

Then determine what the next interaction will be. In our example the TaskList view would have to get the list of tasks; let's assume it would get that from the User class:

Keep doing this, step-by-step, mapping the interactions of the application. This is another area that a Use Case, if available, can help. Again, don't worry about it being perfect just do your best. Here's what I ended up with after walking through my description of the task list application:

You might notice a few things. First, I used fractions for numbering some of the step (like 1.1, 1.2, 1.3...). This is a common technique to keep a series of step clear and it also makes it easier to add more steps later. The important thing is to keep the diagram clear and easy to read. I could even create three separate diagrams for each of these sequences if I felt that would be easier to read.

Second, you might notice that the TaskList page goes to the ManageTasks controller to update or add a task. Why do I do this instead of just updating the Task element? Well, as mentioned before when talking about MVC a view element can't modify a model element, it mostly goes through a controller. This is simply how I've chosen to architect my application. If you have a different standard, or use a framework, the collaboration diagram is still completely applicable; you simply diagram the interactions according to your own standards.

The Sequence Diagram
Now we have the first draft of the collaboration diagram. We've already revealed some relationships that were missed in the class diagram. But let's not revise the class diagram just yet; let's create a sequence diagram first to clarify these details even more. We'll use the collaboration diagram to create the sequence diagram. Once again start with a blank diagram and copy all our classes over to it, but line them along the top side-by-side. Put the views on the left, the controllers in the middle, and the models on the right. Then add another user stick figure on the far left. Below each of these draw dashed lines; these are the "lifelines" of the elements:

Now we'll map the same sequence of events from the collaboration diagram in more detail. Start with the first interaction on the collaboration diagram and draw a line from the user to the TaskList:

Notice I gave this arrow a short name that describes the interaction and put blocks on the two element's lifelines. These blocks represent activity. This first interaction is nothing existing, so let's move on to the next step in the sequence, step 1.1 from the collaboration:

Ah, now things are more interesting. This time we have an interaction between the system elements, so instead of a description of the interaction, we actually gave it a method name. Now we not only know that these two elements interact with one another we're actually defining what methods will be used during the interaction. You might also notice the dotted line arrow going from the User back to the TaskList; this is a return message, and I've noted that an array is being returned. Now we've even defined what kind of information the method will return. Let's move on to the third step, 1.2:

Notice how I've taken "Get each task's information" and expanded that out into two methods, getName() and isCompleted(). Also notice the box around those methods with the funny looking upper-left corner titled "loop." This is how UML frame's special logic flows. This obviously indicated a loop. The note in the lower corner states "[each task]" meaning we'll loop the framed content once for each task. In other words, we're going to get the name and completion status of each task. Right after the loop we simply return the page to the user.

Keep walking through each interaction on the collaboration diagram adding them to the sequence diagram, giving system interactions actual method names. Here's what I came up with for our task list application:

There are two things worth noting in this diagram. First, there are arguments for some of the new methods I added. I noted those by simply adding them in the parenthesis of the method.

The second thing I'd like you to notice is that the diagram doesn't specify how the TaskList calls the completeTaks() or addTask() method. This could be done with AJAX, a normal page refresh, or by posting to the CFC as described on www.benorama.com. The sequence diagram is very flexible this way; it helps clarify how elements will interact and communicate, but can apply to many different technologies or techniques. The previous sequence diagram could apply to Java or PHP just as easily as ColdFusion.

Rinse and Repeat
We now know a great deal more about how our application will work than we did when we first created the class diagram. Now it's time to revise the class diagram based on what we discovered in the collaboration and sequence diagrams:

This revision might have resulted in new classes, or classes being dramatically changed. Don't shy away from making drastic changes, that's what this process is all about.

Are we done? Not quite yet. We now repeat these steps, returning to the collaboration diagram to refine it further, and adding anything we might have missed the first time. Then revise the sequence diagram and go back to the class diagram. We'll repeat this process until we feel confident that the diagrams are complete and accurate.

Summary
This article covered some very basic UML. No single article can cover UML in its entirety; that would be like trying to explain everything about ColdFusion in a single article. But in the end the suite of diagrams I've showed you here will describe an application in great detail, and give you a starting point from which to explore UML further. One could hand these diagrams over to a developer - just like someone would hand a script to an actor - and improv development would be avoided.