UML class diagrams for java

UML class diagrams allow us to denote the static contents of — and the relationships between — classes.   In a class diagram we can show the member variables, and member functions of a class. We can also show whether one class inherits from another, or whether it holds a reference to another. In short, we can depict all the source code dependencies between classes.

This can be valuable. It can be much easier to evaluate the dependency structure of a system from a diagram than from source code. Diagrams make certain dependency structures visible. We cansee dependency cycles, and determine how best to break them. We can see when abstract classes depend upon concrete classes, and determine a strategy for rerouting such dependencies.

The Basics

                                           

                                              Figure : 1.0

Fig 1.0 shows the simplest form of class diagram. The class named Helpis represented as a simple rectangle. This diagram represents nothing more than the code shown to its right.

A class icon can be subdivided into compartments. The top compartment is for the name of the class, the second is for the variables of the class, and the third is for the methods of the class.

Figure 1.1 shows these compartments and how they translate into code.

Figure : 1.1

Notice the character in front of the variables and functions in the class icon. A dash (–) denotes private, a hash (#) denotes protected, and a plus (+)denotes 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, in  Figure 1.2 we see an association between Phone and Button. The direction of the arrow tells us that Phone holds a reference to Button. The name near the arrowhead is the name of the instance variable. The number near the arrowhead tells us how many references are held.

Figure : 1.2

Figure 1.2 Association.

In Figure 1.2 we saw that 13 Button objects were connected to the Mobile object. In Figure 1.3, we see what happens when there is no limit. A Phonebookis connected to many PhoneNumber objects. The star means many. In Java this is most commonly implemented with a Vector, a List, or some other container type.

Figure : 1.3

Inheritance

You have to be very careful with your arrowheads in UML. Figure 1.4 shows why. The little arrowhead pointing at Employee denotes inheritance¹. If you draw your arrowheads carelessly, it may be hard to tell whether you mean inheritance or association. To make it clearer, I often make inheritance relationships vertical and associations horizontal.

Figure : 1.4

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 Java class and a Java interface. It is shown, in Figure 1.5, as a dashed inheritance arrow². In the diagrams to come, you'll probably catch me forgetting to dash the arrows that point to interfaces. I suggest you forget to dash the arrows that you draw on white boards too. Life's too short to be dashing arrows.

                                                                         Figure : 1.5