The Basics

Classes

Figure 19-1 shows the simplest form of class diagram. The class named Dialer is represented as a simple rectangle. This diagram represents nothing more than the code shown to its right.

Figure 19-1. Class icon

This is the most common way you will represent a class. The classes on most diagrams don't need any more than their name to make clear what is going on.

A class icon can be subdivided into compartments. The top compartment is for the name of the class; the second, for the variables of the class; and the third, is for the methods of the class. Figure 19-2 shows these compartments and how they translate into code.

Figure 19-2. Class icon compartments with corresponding code

Note the character in front of the variables and functions in the class icon. A dash () denotes private; a hash (#), protected; and a plus (+), public.

The type of a variable, or a function argument is shown after the colon following the variable or argument name. Similarly, the return value of a function is shown after the colon following the function.

This kind of detail is sometimes useful but should not be used very often. UML diagrams are not the place to declare variables and functions. Such declarations are better done in source code. Use these adornments only when they are essential to the purpose of the diagram.

Association

Associations between classes most often represent instance variables that hold references to other objects. For example, Figure 19-3 shows an association between Phone and Button. The direction of the arrow indicates that Phone holds a reference to Button. The name near the arrowhead is the name of the instance variable. The number near the arrowhead indicates how many references are held.

Figure 19-3. Association

In Figure 19-3, 15 Button objects are connected to the Phone object. Figure 19-4, shows what happens when there is no limit. A Phonebook is connected to many PhoneNumber objects. (The star means many) In C#, this is most commonly implemented with an ArrayList or some other collection.

Figure 19-4. One-to-many association

I could have said, "A Phonebook has many PhoneNumbers." Instead, I avoided using the word has. This was intentional. The common OO verbs HAS-A and IS-A have led to a number of unfortunate misunderstandings. For now, don't expect me to use the common terms. Rather, I'll use terms that are descriptive of what happens in the software, such as is connected to.

Inheritance

You have to be very careful with your arrowheads in UML. Figure 19-5 shows why. The arrowhead pointing at Employee denotes inheritance.^[1] If you draw your arrowheads carelessly, it may be difficult to tell whether you mean inheritance or association. To make it clearer, I often make inheritance relationships vertical and associations horizontal.

^[1] Actually, it denotes generalization, but as far as a C# programmer is concerned, the difference is moot.

Figure 19-5. Inheritance

In UML, all arrowheads point in the direction of source code dependency. Since it is the SalariedEmployee class that mentions the name of Employee, the arrowhead points at Employee. So, in UML, inheritance arrows point at the base class.

UML has a special notation for the kind of inheritance used between a C# class and a C# interface. As shown in Figure 19-6, it is a dashed inheritance arrow.^[2] In the diagrams to come, you'll probably catch me forgetting to dash the arrows that point to interfaces. I suggest that you forget to dash the arrows that you draw on whiteboards, too. Life's too short to be dashing arrows.

^[2] This is called a realizes relationship. There's more to it than simply inheritance of interface, but the difference is beyond the scope of this book and probably beyond the scope of anyone who writes code for a living.

Figure 19-6. Realizes relationship

Figure 19-7 shows another way to convey the same information. Interfaces can be drawn as lollipops on the classes that implement them. We often see this kind of notation in COM designs.