UML Class Diagram

Class Diagrams.


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.

UML State Diagrams(2) – Concurrent States

In the previous post i described a state diagram for a Sales Order Processing system that was based on the availability of stock items. In practice we would almost certainly requre state that were dependent on payment authorisation as well as item availablity. This leads to the notion of concurrent states, where one group of states in a diagram model the stock item availability and a separate group of states model the payment authorisation process.

The diagram below illustrates this concept of concurrent states. These concurrent states are represented in two distinct swimlanes. The concurrent sections of the state diagram a places in which, a given order can be in two different states. When an order leaves a concurrent state it will be i a single state only.

The concurrent state diagrams are useful where a given object has multiple sets of independent behaviours. In practice, I prefer to limit the number of concurrent states to a small number, usually two or three, and when I have more than three I would normally split out the independent behaviours into separate objects as I find that this improves diagram clarity and readability, as well as improving the integrity of subsequent code.

State diagrams are useful for describing the behaviour of objects that often span more than one Use case. For models that describe the interaction of several objects I prefer to use the UML Interaction Diagram.


In the next blog post I will describe the UML Interaction Diagram, and provide some examples of its use to describe the interplay of messaging and events between  co-operating groups of objects.

James Goode, Tendron Systems Ltd

UML State Diagram ( Part-1 )

UML State Diagrams

State diagrams are one of the most valuable techniques available for describing the real-time behaviour of a software system. A well constructed state diagram denotes all the states that a specific object or class can be in. In addition a state diagram describes when and how transitions between the states occur as a result of external events that affect the object. Usually a state diagram is written for each class that exhibits real time behaviour.

The UML state diagram has its origins in earlier research work on real time systems and represents the distilled expertise of three decades of research by numerous experts, David Harel, Ed Yourdon, Grady Booch, James Rumbaugh among others.

UML State Diagram

UML State Diagram

Continue reading

UML Notation – a few examples of key diagrams

English: UML Association Class Diagram

English: UML Association Class Diagram (Photo credit: Wikipedia)

Class diagram of the 13 types of diagrams of t...

Class diagram of the 13 types of diagrams of the Unified Modelling Language 2.0 (Photo credit: Wikipedia)

1) Class Diagram

yadda, absolum nostrum latinae, absolum

caption for diagram

caption for diagram

Interaction Diagram

yadda, absolum nostrum latinae

caption for diagram

caption for diagram

Sequence Diagram

yadda, absolum nostrum latinae

caption for diagram

caption for diagram

State Diagram

yadda, absolum nostrum latinae

caption for demo2 axisplot

caption for demo2 axisplot

Entity Life History

yadda, absolum nostrum latinae

caption for demo2 axisplot - medium

caption for demo2 axisplot – medium

James Goode
Tendron Systems Ltd