Class diagrams are probably the most commonly used of all of the UML diagrams. Similar to Entity Relationship Diagrams (remember them?), class diagrams show each type of object you expect to deal with, its attributes and operations, and its relationship with other classes. Consider the class diagram in Figure 6.

I know there are a lot of notations here, so bear with me for a moment while I explain. Here we have four classes: Feed, FeedItem, CurrentCollection, and ReferencedLink. Let's start with Feed.

A UML class typically has three sections. The top section shows the name of the class. The middle section shows any attributes of the class. This is information about an object of that class. For example, a Feed has a title, a feedUrl, and so on. If I needed to, I could request that information from a Feed object. The bottom section shows operations, otherwise known as functions or methods. These are things a Feed object can do, such as save itself to the database (save()) or update its entries (update()).

Figure 6: Class diagram for the main FeedReader classes

You won't necessarily have all three sections for all classes. For example, the ReferencedLink class has no operations, only attributes.

The lines between each class show associations between them. For example, a FeedItem is associated with a Feed and a ReferencedLink, but is not directly associated with a CurrentCollection. On the other hand, a Feed is associated with a CurrentCollection. Exactly how classes are related can be read in the "role" information on the association. For example, a Feed is part of a code>CurrentCollection, while a CurrentCollection shows a Feed. A FeedItem links to a ReferencedLink, and a ReferencedLink is linked by a FeedItem.

The class diagram also shows the multiplicity of objects, or how many objects are involved in a relationship. For example, a Feed contains zero or more (0..*) FeedItems, and a FeedItem is part of exactly one (1) Feed. Note that you can also get specific. If we were sticking with RSS feeds, we could say that a Feed contains 0 to 15 Feeditems with the notation 0..15.

In fact, we can say a lot about how classes and objects relate to each other.

Relationships

In Figure 6, I showed you a set of classes with very basic relationships between them. In fact, while I told you the classes were related, I didn't say very much about how. Let's correct that now.

One kind of association is the aggregation, in which more than one object is associated with another. For example, we have multiple Feeds in a CurrentCollection, and multiple FeedItems in a Feed. Let's see how that appears in the class diagram in Figure 7.

Figure 7: Showing aggregations

Here we see two different types of aggregations: aggregation, and composition. A simple aggregation, such as the aggregation of Feeds that makes up a CurrentCollection, is shown by an open diamond like the one connection the two classes in this diagram. With an aggregation of this type, the Feeds together loosely make up the CurrentCollection. If we eliminated the concept of the CurrentCollection, the Feeds would remain. On the other hand, the composition relationship, shown by the solid diamond on the Feed-FeedItem association, indicates that the FeedItems are an integral part of the Feed. If we got rid of the Feed, the FeedItems would have to go too.

Let me put it another way: my library consists of a number of books I've read or would like to read. That's an aggregation. If I were to get hit by a bus, they'd still be there. My liver, on the other hand, is an integral part of me, along with my other internal organs; the bus crash would affect it just as much as it affects the rest of me.  That's composition.

No conversation about classes and objects would be complete without a discussion of inheritance. In UML, when you extend a parent class to create a child class, the parent is said to generalize the child. You can see this in Figure 8:

Figure 8: Child classes are generalized by their parents.

Here we have the base Feed class. The fact that the updateNeeded(), update(), and setLastUpdated() operations are italicized tells us that they are abstract. In other words, the Feed class doesn't provide an implementation for them; that's for the child classes to handle. The RSSFeed and AtomFeed classes extend the Feed class; the Feed class generalizes them, so they point to it with an open triangle arrow. Similarly, the RSSFeed class generalizes the RSS09Feed, RSS10Feed and RSS20Feed classes.

The child classes show any additional attributes, such as image or rating, and any operations that are either added or that implement abstract operations in the parent class, such as those noted for the RSSFeed and AtomFeed classes, or that override operations in the parent class, such as the update() operation on the children of RSSFeed.

(Note that the plus (+), minus (-), and pound (#) signs indicate that an attribute or operation is public, private, or protected, respectively.)

That takes care of inheriting from a concrete or abstract class, but what about interfaces?

An interface defines behaviors, but doesn't actually provide any implementation of those behaviors. In general terms, you could consider an interface to be a class that contains only abstract operations.

When we're dealing with interfaces, we don't say the child extends the parent, but rather that the class implements the interface. In UML, we say the child realizes the parent, as you can see in Figure 9:

Figure 9: The realization relationship

Here we have the Feed interface — more on the funny symbol above the interface name in a moment — and two classes that realize it: RSSFeed and AtomFeed.  The dashed line ending in the hollow arrow point represents the realization relationship.

Note that because we've indicated that Feed is an interface, we don't need to bother noting that the operations are abstract; they are by definition.

OK, so why is there a funny-looking symbol at the top of the Feed class? It's because the class is a stereotype, and it's indicated by a keyword, in this case interface, enclosed in guillemets, or French quotation marks.

A stereotype is an instance of something common that doesn't necessarily have its own symbol. For example, rather than creating an interface symbol^*, we're using the symbol for a class and indicating that it's an interface. Stereotypes can appear in various places in a UML diagram. For example, we'll make extensive use of them when we talk about components.

UML defines a number of different stereotypes, such as interface, component, and artifact. You can also create your own, as long as you communicate them to anyone else using your diagrams.

^*Yes, I know that earlier versions of UML define an interface symbol, but UML 2.0 leans toward using the stereotype version instead.