UML 4. Class diagrams

The class diagram is the most directly applied when it comes to coding. Most UML tools will generate a set of classes in many programming languages straight from the class diagram. They are not always complete, especially where collections or templates are concerned, but they can save a lot of repetitive typing.

Class diagrams are also the most complex, and certainly the most discussed when modelling object oriented concepts such as composition and aggregation. Hopefully, we can avoid such arguments for now and accept that class diagrams are able to model many object oriented, and even entity relationship particulars.

Class diagrams come in two basic flavours. The simplest uses class stereotypes, and the more complex details the member properties and functions of the classes. We shall begin with the class stereotypes.

Class acts

The class stereotypes are boundary, control and entity classes.

Figure 1.13 Boundary, Control and Entity classes

You may see these stereotypes used in other types of UML diagrams. They are useful for doing initial high level modelling, mapping out what objects a component might contain, and what relationships exist between them before specifying the class details.

Boundary classes are used to specify interfaces between systems, control classes are used as objects to control other class actions, and entity classes are typically data stores.

Figure 1.14 An example using boundary, control and entity classes

As I have been showing basic objects, I have allowed myself a booklist object, which will hold a collection of book objects. This is not strictly required as in a more detailed diagram, I might have defined the relationship between the objects book selector and book as in figure 1.14.

Figure 1.15 Class relationships

The relationship here is 1 to 0..n. It means one book selector is related to zero or more books. In reality, I know my database will only hold a certain number of books, such as 232, but 1 to 0..4294967296 is not usually required. The numbers defining the relationship are known as cardinality.

Cardinality can contain more than one item. For example, 1..4,6..n means any positive number except 0 and 5. Negative numbers are not used.

Figure 1.15 implies a collection is used, but the UML tools do not take the cardinality and create a collection holding zero or more books. Despite this, the cardinality notation is used as class diagrams begin to get cluttered when they contain collections.

Figure 1.16 Spacemanís food dispenser

In this example, our spaceman has access to a food dispenser. Actors always connect to a boundary class. A dietician creates his main course from meat and vegetable substitutes, and the spaceman, lucky fellow, is allowed to choose which fruit he wants from his fruit bowl. Itís not real fruit, which would deteriorate over the five years he is in space, but there are three fruit definitions, all derived (inheriting) from a base class of fruit. UML uses quite a few line and arrow types, all with specific definitions. We shall look at other line and arrow types shortly.

These simple class diagrams are fairly easy to produce, and not too difficult to understand. Getting it right at this stage makes finalising object oriented designs far easier, as the high level view without properties and functions means you do not get lost in the detail. Displaying them in this format means you have a good foundation upon which to build the detail, and a good picture to use in early discussions with designers and developers.

I believe all diagrams should be able to fit on one page of printed paper. Any fitting together of pages or searching for a larger printer is a fruitless activity. An A3 diagram (like a Business Analystís magnificent flowchart) is usually impossible to understand without some serious study. It is far better to create one skeleton diagram and a series of more detailed diagrams each representing a bone. Unfortunately, many become lost in their works of art, and spend so much time on them that they begin to understand them. What is worse, this creates a false belief that others will have their immediate insight into the odd shaped boxes and decision flows. We should be eternally grateful to the UML creators for their foresight not to use the flowchart symbols.

Class diagrams are very useful design diagrams, representing specific implementations. They can also become works of art. Beware.

Figure 1.17 A class diagram for the Apple class

Figure 1.17 shows a more detailed representation of a class. It is quite straightforward, having three public properties and one private property. The class name is Apple. SkinColour is an RGB value, Juiciness is measured in the Standard Juiciness Number, the Variety is a string, and the Worms collection is private. You wonít know about them until you take a bite. You could say the same about some software.

Itís not a very good class, as classes go. Letís try a little harder.

Figure 1.18 A better model of an apple

The apple now derives quite a lot from its base class of fruit. Not only does it have properties, but it is able to rot too. Calling the apple.rot() function could decrease its Freshness. It may also decrease the size slightly. The apple class itself has only two properties and one object. The object Worms does not have to exist, as an apple can contain either 0 or 1 Worms collections. The Worms collection has no properties of its own, but contains 0 or more worm objects. Worms can be added to the apple, or removed, or counted. Every property in this set of classes is public, and shown with a +. You will know about the worms before you take a bite.

Figure 1.19 A fruitier fruit model

Figure 1.19 shows a fruit with a private freshness property. However, you can derive its freshness by using its smell and look functions. Anyone can look at the fruit as it is a public function, but you may only smell it if you are a friend.

Here are two examples showing the relationship between a teacher and her students, and a pentagon and its sides.

Figure 1.20 Teacher and student

The teacher teaches between 2 and 25 students. The name of the association is teaches, and direction shows that it is the teacher doing the teaching. An opposite arrow could show the students learning from the teacher, but that is not always the case.

Figure 1.21 A pentagon and its sides

The cardinality shows one pentagon has exactly five sides. Also we see that the sides are ordered, and that the pentagon is composed of its sides. The black diamond is a composition sign, declaring that the pentagon is made of sides, and that the sides are contained within the pentagon.

Figure 1.22 A class qualifier

This shows the relationship between train journeys and ticket sales. The train journey class has a qualifier of seat number and departure time, for which either no ticket or one ticket can be sold. The classifiers can be used as keys in data structures or databases.

You may also define associations between classes when they are not specifically defined in the class relationships. To do so, the normal class relationship is stated, then the associated class is shown connected to the connector which states the relationship between the associated classes.

Figure 1.23 A reservation class shown as an association to the sales relationship of train journey and ticket.

Letís take a look at the relationships we can show in a class diagram. Most of these connectors or more correctly associations are not confined to the class diagram and are used in most of the diagram types. The last two are not used in class diagrams, but are included here as a reference of all the UML association types.

Figure 1.24 Connector types in UML

These connectors represent object oriented concepts. I expect anyone developing software today uses at least a few object oriented methods, so at least a few of the connections will be familiar. Some of these concepts are discussed further below.

Dependency and interfaces

Figure 1.25 - Interface dependency

Figure 1.25 shows class B is dependent upon the DataOut interface of class A. This means class B uses the DataOut interface of Class A to provide it with some information, and is unlikely to operate properly without it.

Realisation

If a class is a realisation of another class, then it fully implements its behaviour, but does not inherit (unless specifically stated) its structure or interface. The behaviour must be coded in the realised class.

Composition and aggregation

These two terms mean different things to different people. Both terms allow a class to be made up from a number of other classes.

Figure 1.26 A dog class made up of other classes

In both aggregation (shown in figure 1.26) and composition (solid black diamonds rather than the outlined diamonds), the dog class is made up of a head, a body, the legs and a tail. If you kill a dog made by aggregation, the head, body, legs and tail live on and can be attached to another dog. Killing a dog made by composition would be killing the parts too. Frankenstein believed we were made by aggregation and could be reassembled and kick-started with a few good shots of electricity. And so have we proved, that as long as we work on the interface with anti-rejection drugs, we can supplant organs from dead (or live) donors into others.

Class diagrams may contain many other constructs. Some of them are very useful shortcuts for defining relationships. Too often, information discovered about the system being modelled is written up in paragraphs, where a little extra work on the class diagram can state relationships exactly.

In the following class diagram we see a business entity called a group which is made up of practices. The practices themselves are an aggregation of practices, i.e. a practice can contain other practices. As it is an aggregation, the practices do not rely on the parent practice for their existence, and can be moved to another parent practice if desired. Such a practice hierarchy is usually implemented as a linked list where each practice is linked to a parent. Those with no parent will be the top level practices in the group.

Figure 1.27 Class diagram example

The cardinality attached to this aggregation means a practice may or may not contain child practices, and also may or may not have a parent practice.

The relationships between practice and employee shows that a practice has one or more members. It shows how a practice can have no manager (if the last one left and has not been replaced), one manager (as is normal), or two managers, in the rare case of joint heads of practice. Manager is identified as a subset of member, implying that a manager is also a member, and defined as a {subset} of member.

This model states relationships quite succinctly. It states a manager must be a member of the practice, and a member may or may not be a manager. It also shows the relationship between practices and their children are specified, or keyed, by the property PracticeID

Thatís quite enough on class diagrams for now. The only way to get the hang of them is to model with them.

Class diagrams, as you have no doubt realised, are extremely rich in the methods available to define their properties and relationships.

next >>