The purpose of a class diagram is to depict the classes within a model. In an object oriented application classes have attributes (ie. member variables), operations (member functions) and relationships with other classes. The UML class diagram is used to depict all these.
The fundamental element of the class diagram is a square or rectangular icon that represents a class.
A class icon rectangle is often divided into three compartments. The topmost compartment
contains the name of the class. The middle compartment contains a list of attributes (member variables), and the bottom compartment contains a list of operations (member functions).
In many diagrams, the bottom two compartments are omitted for improved clarity. Even when they are present, they often do not list every attribute and operations.
This ability to abbreviate an icon is one of the hallmarks of UML. The class icons in UML diagrams are frequently abbreviated for clarity. There is typically never a need to show every attribute and operation of a class on any diagram.
Notice that, in the diagrams, that each member variable is followed by a colon and by the type of the variable. If the type is redundant, or otherwise unnecessary, it can be omitted. Notice also that the return values follow the member functions in a similar fashion. Again, these can be omitted.
The inheritance relationship in UML is depicted by a triangular arrowhead. This arrowhead points to the base class. One or more lines flow from the base of the arrowhead connecting it to the derived classes.
Aggregation / Association
The weak form of aggregation is denoted with an open diamond. This relationship denotes that the aggregate class (the class with the white diamond touching it) is in some way the “whole”, and the other class in the relationship is somehow “part” of that whole.
A question newcomers to UML often ask is “What is the difference between an aggregation and an association”? The difference is subtle, and often not visible from actual code. Aggregation denotes whole/part relationships whereas associations do not. However, there is not likely to be much difference in the way that the two relationships are implemented. That is, it would be very difficult to look at the code and determine whether a particular relationship ought to be aggregation or association. For this reason many practitioners ignore the aggregation relationship altogether.
There are classes that have nothing but pure virtual functions. In Java such entities are not classes at all; they are a special language element called an interface. UML has followed the Java example and has created some special syntactic elements for such entities.
In this blog post I have described a few of the notational elements of UML. In future posts I will expand upon this notation by showing how to use it for solving some real world software design issues.