Relationships
Classes don't live in a bubble; they interact with one another. Any sort of interaction between classes is a type of relationship. A relationship is illustrated with a line or arrow between the two classes. There are many kinds of relationships in UML, but we'll focus on just three in this article, associations, generalizations, and messages.

An association means that one class uses another in some way. That could mean the first class utilizes a method of the second. Or it could mean that the first class contains the second as one of its properties. For example:

In this example, the Person class has an "addr" property that has a type of "Address." So there's an association between the two classes. The association line also has its own notation. At each end of the line is a "multiplicity" and in the middle is a "descriptor":

The descriptor in the middle simply describes the type of relationship. The multiplicities at each end of the line indicate how many of these classes are involved in the relationship. If you've ever worked with database schemas these may look somewhat familiar to you. Values can be a comma delimited or two dots (..) that indicate a range of values. An asterisk indicates an unknown number. For example:

0..      Zero or 1
*      Any amount (zero or more)
1..*      Any amount greater then one
1,3,4      1, 3, or 4
1..6,10      1 through 6, or 10

These association lines should actually be readable top-down, left-to-right. So in the example above, one person has zero or one address.

The second type of relationship is a "generalization." This is when one class inherits another; in ColdFusion this is called extending. The rule of thumb is if you can say that "A is a type of B", then "A is a generalization of B". Or you could say B extends A. A generalization is noted in UML with a solid line with an open arrow at one end. For example:

This says that a Geek is a kind of Person (they really are you know). In the Geek.cfc I'd expect to see this code:

<cfcomponent extends="Person">
     ...code...
</cfcomponent>

The last type of relationship you'll see in this article is messages, which are used in collaboration and sequence diagrams. Messages are when one class calls the method of another class. An arrow between the two classes is how we illustrate a message, usually with a description or method name just above or beside it. You'll see more on how messages are used in UML when we cover collaboration and sequence diagrams.

MVC symbols
As we said, UML can help enforce better MVC design. There are actually three special symbols used to indicate those kinds of elements:

What does Model-View-Controller mean?

• Model: A person, place, or thing. This class is intended to represent (model) something in real life like a "car" class.
• View: These are the elements the user will interact with. They are forms, pages, pop-up windows, even e-mails.
• Controller: This is the middleman, the one that controls the flow of information. If the view needs to modify a model, it should go through a controller.

For a great example of using MVC in ColdFusion take a look at "ColdFusion Best Practices" at www.benorama.com/coldfusion.

These symbols can be put inside the class icon to indicate the type of class:

This isn't official UML - to my knowledge - but I've found it to be very useful.

Creating UML
There are a few basic UML diagrams I use to design a ColdFusion application. A UML diagram can't be created in a single pass. Like writing a story it takes a number of iterations to refine and complete. The process we'll follow here will help us gradually explore and define each diagram, using one diagram to help explore the next. The point of this process will be to generate a suite of diagrams that will tell you almost anything you need to know about how your application will work. The basic suite I use consists of three diagrams: a Class Diagram, a Collaboration Diagram, and a Sequence Diagram. This is only a subset of the UML diagrams available, and complex applications may require other more specialized diagrams to complete the suite. But in this article we'll only look at creating that core set of diagrams.

The Class Diagram
The first thing I do when designing a system is to create a class diagram. What's the point of a class diagram? It's a view of all the system's elements and how they'll interact with one another.

To get started we'll need to identify our classes. There's an old trick in the OO world that will work well here. Take the Use Case, or whatever document you used to gather the system's requirements, and highlight all the nouns. Take those nouns and put them into an Excel spreadsheet. Only put each noun in once, ignore duplicates, and ignore pronouns. This is the initial list of classes.

Next, in the column following the nouns, enter what type of class or element the noun is. Common possibilities are Model, View, Control, Property, or Other:

• Model: If the noun refers to something in the real world like "car" or "dog" then the noun is a model class (it "models" something).
• View: If it refers to something that the user interacts with, it's a view. Examples are forms, pages, pop-up windows, or e-mails.
• Control: If the noun is the name of a use case, process, or sequence of events then it's a controller.
• Property: This sometimes comes up when referring to the property of a class. For example, the use case might say, "Display the name of a person." There are two nouns there, "person" and "name." The "person" is a model class, and "name" is one of its properties.
• Other: Anything that's unclear or doesn't fit into one of the types above. Try to use this as little as possible, and if you do, write in the third column why it doesn't fit or what's unclear about it.

Don't stress the class identification too much; it's really just to help get the class diagram started so it does not have to be perfect. Just take your best guess; you can always change it later. We can now start the class diagram. Put all the classes from the spreadsheet into the diagram and note what kind of class they are (Model, View, Control) using the three symbols. Also add any properties you identified. Now add any relationships, methods, or properties that are obviously going to be needed. You're still drafting the class diagram so just put in what you know will be needed, and don't worry about how it looks, we can clean it up later.

Let's say I'd like to create a very basic to-do list application. In this application the user goes to a task list page and all his uncompleted tasks are listed. He can mark a task as completed or add a new task by naming it and clicking an "add" button. To start my class diagram I'll take whatever requirements document I have, even if it's just a description like what I just gave, and identify the nouns. I use that to draft a class diagram, and add a few of the obvious relationships, methods, and properties. This is what I end up with:

It's far from complete; most of my classes don't even have any details. I just fill in what I know so far.