Think about the things in the world around you. (A pretty broad request, admittedly, but try it anyway!) The things that surround you have attributes (properties) and they behave in certain ways. We can think of these behaviors as a set of operations.

You'll also see that things naturally fall into categories (automobiles, furniture, washing machines. . . ). We refer to these categories as classes. A class is a category or group of things that have the same attributes and the same behaviors. Here's an example. Anything in the class of washing machines has attributes such as brand name, model, serial number, and capacity. Behaviors for things in this class include the operations “accept clothes,” “accept detergent,” “turn on,” and “turn off.”

Figure 1.1 shows an example of the UML notation that captures these attributes and behaviors of a washing machine. A rectangle is the icon that represents the class. It's divided into three areas. The uppermost area contains the name, the middle area holds the attributes, and the lowest area holds the operations.

Figure 1.1. The UML class icon.

Notice the spacing in the names of the class, the attributes, and the operations. In UML, a multiword classname has initial capital letters for all the words and eliminates whitespace between each word (for example, WashingMachine). Attribute-names and operation-names follow the same convention, but the first letter of the first word isn't capitalized (for example, acceptClothes()). A pair of parentheses follows the name of each operation—for reasons we'll get into in Hour 3.

As you'll see in Hour 4, a class diagram consists of a number of these rectangle icons connected by lines that show how the classes relate to one another.

Why bother to think about classes of things and their attributes and behaviors? In order to interact with our complex world, most modern software simulates some aspect of the world. Decades of experience suggest that it's easiest to develop software that does this when the software represents classes of real-world things. Class diagrams provide the representations that developers work from.

Class diagrams help on the analysis side, too. They enable analysts to talk to clients in the clients' terminology and thus stimulate the clients to reveal important details about the problem they want solved.

An object is an instance of a class—a specific thing that has specific values of the class's attributes. Your washer, for example, might have the brand name Laundatorium, the model name Washmeister, a serial number of GL57774, and a capacity of 16 pounds.

The icons in Figure 1.2 show how the UML represents an object. Note that the icon is a rectangle, just like the class icon, but the name is underlined. In the icon on the left, the name of the specific instance is on the left side of a colon, and the name of the class is on the right side of the colon. The name of the instance begins with a lowercase letter. It's also possible to have an anonymous object, as the icon on the right of Figure 1.2 shows. This just means that you don't supply a specific name for the object, although you do show the class it belongs to.

Figure 1.2. Two UML object icons—The icon on the left represents a named object, the icon on the right represents an anonymous object.

A use case is a description of a system's behavior from a user's standpoint. For system developers, the use case is a valuable tool: It's a tried-and-true technique for gathering system requirements from a user's point of view. Obtaining information from the user's point of view is important if the goal is to build a system that real people (and not just computerphiles) can use.

We'll discuss use cases in greater detail in Hours 6, “Introducing Use Cases”; 7, “Working with Use Case Diagrams”; 18, “Gathering System Requirements”; and 19, “Developing the Use Cases.” For now, here's a quick example. You use a washing machine, obviously, to wash your clothes. Figure 1.3 shows how you'd represent this in a UML use case diagram.

Figure 1.3. The UML use case diagram.

The little stick figure that corresponds to the washing machine user is called an actor. The ellipse represents the use case. Note that the actor—the entity that initiates the use case—can be a person or another system. Note also that the use case is inside a rectangle that represents the system, and the actor is outside the rectangle.

Pronunciation Tip

To help clarify the meaning of this concept, say the use in “use case” with a soft “s,” as though it rhymes with truce. Don't say it as though it rhymes with snooze.

At any given time, an object is in a particular state. A person can be a newborn, infant, child, adolescent, teenager, or adult. An elevator is either moving or stationary. A washing machine can be either in the soaking, washing, rinsing, spinning, or off state.

The UML state diagram shown in Figure 1.4 captures this bit of reality. The figure shows that the washing machine transitions from one state to the next.

Figure 1.4. The UML state diagram.

The symbol at the top of the figure represents the start state and the symbol at the bottom represents the end state.

Transitions

Transitions from state to state aren't always linear. Sometimes conditions dictate one path or another. We'll talk about this in Hour 8, “Working with State Diagrams.”

Class diagrams and object diagrams represent static information. In a functioning system, however, objects interact with one another, and these interactions occur over time. The UML sequence diagram shows the time-based dynamics of the interaction.

Continuing with the washing machine example, the components of the machine include a timer, a water pipe (for fresh water input), and a drum (the part that holds the clothes and the water). These, of course, are also objects. (As you'll see, an object can consist of other objects.)

What happens when you invoke the “Wash clothes” use case? Assuming you've completed the “add clothes,” “add detergent,” and “turn on” operations, the sequence of steps goes something like this:

Imagine that the timer, the water pipe, and the drum are objects. Assume that each object has one or more operations. The objects work together by sending messages to each other. Each message is a request from the sender-object to the receiver-object. The request asks the receiver to complete one of its (the receiver's) operations.

Let's get specific about the operations. The timer can

The water pipe can

The drum can

Figure 1.5 shows how to use these operations to create a sequence diagram that captures the messages among the timer, water pipe, drum, and drain represented as anonymous objects at the top of the diagram. Each arrow represents a message that goes from one object to another. Time, in this diagram, proceeds from top to bottom. So the first message is timeSoak(), which the timer sends to itself. The second message is sendWater(), which the timer sends to the water pipe. The final message, stopRotating(), goes from the timer to the drum.

Figure 1.5. The UML sequence diagram.

Notice that an object (in this case, the timer) can send a message to itself. Notice also that the arrowheads do not all have the same shape. You'll learn more about that in Hour 9, “Working with Sequence Diagrams.”

Note: If you don't remember what an anonymous object is, go back and look at Figure 1.2.

The activities that occur within a use case or within an object's behavior typically occur in a sequence, as in the steps listed in the preceding subsection. Figure 1.6 shows how the UML activity diagram represents steps 4 through 6 of that sequence.

Figure 1.6. The UML activity diagram.

Transitions Again

In an earlier note I mentioned that the transitions from state to state aren't always linear, but sometimes take one path or another. It's the same for activity diagrams. You'll see that in Hour 11, “Working with Activity Diagrams.”

The elements of a system work together to accomplish the system's objectives, and a modeling language must have a way of representing this. The aforementioned sequence diagram does this. The UML communication diagram shown in Figure 1.7 also does this, but in a slightly different way. Rather than show you the communication diagram that's equivalent to the sequence diagram in Figure 1.5, Figure 1.7 shows you one that captures just the first few messages among the timer, the water pipe, and the drum. Rather than represent time in the vertical dimension, this diagram shows the order of messages by attaching a number to the message label.

Figure 1.7. The UML communication diagram.

Both the sequence diagram and the communication diagram show interactions among objects. For this reason, the UML refers to them collectively as interaction diagrams.

Changing Names

The name communication diagram is new in version 2.0. In version 1.x, this was called a collaboration diagram. Don't be surprised if you find the two terms used interchangeably as version 2.0 settles in.

This diagram and the next one move away from the world of washing machines because the component diagram and the deployment diagram are geared expressly toward computer systems.

Modern software development proceeds via components, which is particularly important in team-based development efforts. Without elaborating too much at this point, Figure 1.8 shows how the UML version 1.x represents a software component.

Figure 1.8. The software component icon in UML 1.x.

Here's where UML 2.0 makes an entrance. In response to the many modelers who felt this symbol was awkward, UML 2.0 provides a revised symbol. Figure 1.9 shows the new way to represent a software component.

Figure 1.9. The software component icon in UML 2.0.

What's the Angle?

What are those angle brackets around the word “component” in Figure 1.9? That notation has a special status within UML. You'll read about it in the subsection entitled “Keywords and Stereotypes” a couple of pages from here.

The UML deployment diagram shows the physical architecture of a computer-based system. It can depict the computers, show their connections with one another, and show the software that sits on each machine. Each computer is represented as a cube, with interconnections between computers drawn as lines connecting the cubes. Figure 1.10 presents an example.

Figure 1.10. The UML deployment diagram.

It often happens that one part of a diagram doesn't present an unambiguous explanation of why it's there or how to work with it. When that's the case, the UML note is helpful. Think of a note as the graphic equivalent of a yellow sticky. Its icon is a rectangle with a folded corner. Inside the rectangle is explanatory text. Figure 1.11 shows an example. You attach the note to a diagram element by connecting a dashed line from the element to the note.

Figure 1.11. In any diagram you can add explanatory comments by attaching a note.

The UML provides a number of useful items, but it's not an exhaustive set. Every now and then you'll create a model that requires some new concepts and new symbols. Stereotypes enable you to create new UML elements by basing them on existing elements. It's sort of like buying a suit off the rack and having it altered to fit your particular measurements (as opposed to creating one out of a bolt of cloth). Think of a stereotype as just this kind of alteration. You represent it as a name enclosed in two pairs of angle brackets called guillemets, and then you add that name to a UML symbol. The guillemet-enclosed name is called a keyword.

Sometimes the UML does this for you. Rather than create an entirely new symbol for something, the UML adds a keyword to an existing element. The keyword indicates that the element is used in a somewhat different way than originally intended. The concept of an interface (which you'll read about at length in Hour 5, “Understanding Aggregations, Composites, Interfaces, and Realizations”) provides a good example. An interface is a class that just has operations and has no attributes. It's a set of behaviors you might want to use again and again throughout your model (for reasons that become clearer in Hour 5). Instead of inventing a new element to represent an interface, UML uses a class icon with the keyword «Interface» situated just above the classname. (See Figure 1.12.)

Figure 1.12. A stereotype is an existing UML element with the addition of a keyword in guillemets. The keyword indicates that the element is used in a somewhat different way than originally intended.

The stereotype concept is particularly useful when you use a UML modeling tool. One important feature of a modeling tool is a “dictionary” that keeps track of all the elements you create in your model—classes, use cases, components, and others. (“Dictionary” is my own term. Different tools call it different names.) The dictionary can only work with existing UML elements and with stereotypes based on these elements. Thus, stereotyping allows you to create something new and store it in the dictionary. This is important because the dictionary helps you organize and manage your model and enables you to reuse the elements you create.

In Hour 14, “Understanding Packages and Foundations,” I look under the hood of the UML and examine the foundations of concepts like the stereotype. For now just bear in mind that to visualize a stereotype you add a keyword to a UML icon. Also bear in mind that as you work with UML (particularly if you work with a UML modeling tool), you'll find that UML comes with some built-in stereotypes and predefined keywords (like «component» and «Interface»).

De-Evolution?

I first brought up this guillemet notation in the “Component Diagram” subsection a couple of pages ago. I mentioned that the UML 1.x software component symbol in Figure 1.8 has given way to the UML 2.0 notation in Figure 1.9. Everything I just told you about stereotypes indicates that you use a stereotype to create a symbol when you don't have one. In the case of the component icon, however, it all worked in reverse from 1.x to 2.0—a class icon with a keyword replaced an existing symbol.

When you're modeling a class, you might find it useful to show something about the class's internal structure. This often happens if the class consists of component classes.

For example, let's assume that a person consists of a mind and a body. In Hour 5 you'll see the traditional way of modeling that statement. It consists of lines and symbols that join the Person class to the Mind class and to the Body class.

With UML 2.0's composite structure diagram you add a dimension. You put each component class inside the whole. This conveys the idea that you're looking inside the class into its structure. Figure 1.13 shows you what I mean.

Figure 1.13. The composite structure diagram models a class's internal structure.

Version 1.x allowed this kind of notation in class diagrams. Version 2.0 explicitly identifies this technique as its own kind of diagram.

Philosophy on the Line

As you'll see when we get deeper into object-orientation, a line that joins two classes (like Mind and Body) usually has a name. In Figure 1.13 how should we label the line that joins Mind and Body? Philosophers have been puzzling over that one for ages! They've been arguing over the name of that association, whether it even exists, whether the Mind component exists, and on and on and on. . . .

Consider once again the activity diagram (Figure 1.6). This shows you a series of steps, that is, “activities.” Suppose each of those activities involves a sequence of messages among objects. If you replaced some of the activities with sequence diagrams or communication diagrams (or a combination of the two), you'd have UML 2.0's new interaction overview diagram.

Here's an example. Imagine you're at a library.

Figure 1.14 shows a simple activity diagram that captures these three steps.

Figure 1.14. Three activities in visiting a library.

Now let's analyze each activity. In the first one, you ask the library database to locate the book, and the database responds by telling you to go to the book's location. In the second, you ask the librarian to check the book out to you, and after the checkout, the librarian tells you to take the book. In the third, you can leave the library only if a guard verifies that you have checked out the book.

Figure 1.15 shows how to organize all this in sequence diagrams taken in . . . well . . . sequence.

Figure 1.15. An interaction overview diagram that expands the activity diagram in Figure 1.14.

Think back to the examples involving the washing machine. I used this venerable appliance to discuss diagrams for classes, states, sequences, and communications.

In the part about sequence diagrams, I mentioned the duration of each state—5 minutes for soaking, 15 minutes for washing, 15 minutes for rinsing, and 5 minutes for spinning.

If you carefully examine the sequence diagram in Figure 1.5, you'll see that it never explicitly shows these durations. UML 2.0's timing diagram handles this. It's designed to show how long an object is in a state. Figure 1.16 shows one form of this new diagram.

Figure 1.16. The UML timing diagram.

Version 1.x includes a capability for organizing the elements of a diagram. Dubbed a package, its icon is a tabbed folder, as in Figure 1.17. The idea is to put elements that go together inside one of these tabbed folder icons. For example, if a number of classes or components constitute a particular subsystem, they would go into a package.

Figure 1.17. The UML package icon.

By specifying a package diagram, Version 2.0 gives a sort of promotion to the package. No longer considered just a way of organizing a diagram's elements, the package has attained diagram status of its own.