1 Kyung Hee University Class Diagrams Spring 2001

11

Kyung Hee University

Class DiagramsClass Diagrams

Spring 2001

22


Class Diagrams

Object diagrams model the data held in a system at a given

instant.

Instances of classes, showing what objects exist.

Data stored as attributes in objects.

Information stored structurally as links between objects.

Object diagrams can represent both legal and illegal states of a

system:

33


Class Diagrams

We need to be able to specify which object diagrams represent

legal states of the system: it won’t be practicable to simply list

them.

UML uses class diagrams to specify the static structure of a

system.

It acts as a kind of specifications for a system.

44


Datatypes

Primitive data is represented in UML as data values belonging to

suitable data types, of the following kinds:

Predefined types UML defines a number of primitive types, including Boolean, Integer and String.

55


Datatypes

User-defined types These are enumerations, and can be represented graphically:

Language types Defined by type expressions borrowed from the target programming language.

66


Multiplicity

Multiplicity in UML is a way of specifying a number, or cardinality. In general, a UML multiplicty is a comma-separated list of number ranges, such as:

2,4,6..10

0..3,5..* (* represents “infinity”)

A set of integer values

Representing one possibility for the number of occurrences of the entity being specified

Example,

suppose that a given entity is optional but that if it is present there must be at least three of them.

77


Instances of classes

UML makes a basic distinction between descriptors and instance

s. Descriptors – such as classes – describe, or specify, the properti

es of their instances – such as objects.

The relationship between a class and its instances is known as inst

antiation. It can be represented in UML using a dependency labell

ed with the stereotype “instantiates”.

88


Class Multiplicity

It is very rare that there is a need to show this explicitly. A multi

plicity in a class specifies the number of instances of that class tha

t can exist simultaneously. The default is “zero or more”. A comm

on use is to specify that a class can only have one instance.

99


Attributes

Classes have attributes, which specify the data that can be held in

instances of that class.

Normally every instance has its own copy of an attribute, and can

store different data.

Attributes with class scope are shared by all instances of the class

: only one copy of the attribute is stored.

1010


Attributes

Attributes with class scope are underlined in a class icon. They ar

e similar to static data members in programming languages.

Attribute syntax: types are optional; optional multiplicity betwe

en the name and the colon.

1111


Operations

Classes also have operations, whcih specify ways of accessing or

manipulating the data stored in objects. As operations are the sam

e for every instance of a class, they are not normally shown on obj

ect icons.

1212


Operations

Normal operations can be applied to individual objects. Operatio

ns with class scope are applied to the class (and can be thought of

as only accessing class scope attributes).

The commonest use for operations with class scope in UML is to

model class constructors.

Operation syntax: types are optional.

1313


Object Identity

Two objects of a class can have identical values for their attribute

s, while still being distinct objects.

Unlike data values: objects have an identity which is distinct from

the data they hold, and which serves to distinguish objects. (An ob

ject’s identity is often implemented as its address in memory.)

1414


Object Identity

There is therefore no need to add special identifying attributes to

classes, though if one exists in the problem domain it can be adde

d:

Here the id attribute is quite distinct from the identity of the insta

nces of the class.

1515


Associations and Links

Two objects can only be linked if there is a corresponding associ

ation between their classes.

Both an association and its two ends can be labelled. These labels

can also be applied to the relevant links if necessary.

1616


Associations and Links

An association name is often a verb. The arrowhead indicates wh

ich direction to read it in. This association shows people working f

or companies, not companies working for people (which is a perfe

ctly sensible, but different, association).

Role names are often nouns, describing the role an object plays in

the relationship.

1717


Self associations

Associations are normally binary, connecting two classes. UML

does provide a notation for associations that connect more than tw

o classes, but it is rarely used.

The two classes need not be distinct: an association that connects

a class to itself is called a self-association.

1818


Multiplicity of associations

Multiplicities on associations specify properties of the number of

links that can exist between instances of the associated classes.

This asserts that an instance of Person can be linked to only one

company, but an instance of Company can be linked to many peop

le. In other words, a company has many employees, each of who

m only works for one company.

1919


Multiplicity of associations

Given this class diagram, the following object diagram represents

an illegal situation, as it show a person working for two companie

s.

2020


Labelling associations

In general:

1. Multiplicity annotations must be shown on associations.

2. Labels and role names are optional; the designer can choose the level of detail necessary to make the diagram easily comprehensible.

In a few cases, some form of labelling must be used.

1. To distinguish between different associations between the same pair of classes.

2121


Labelling associations

2. To distinguish between the two ends of a self-association

2222


Semantics of links

Unlike objects, links don’t have identity. This means that you cannot have two instances of the same association connecting the same pair of objects.

The links are identified by the pair of objects that they link, and therefore cannot be distinguished.

In order to model a situation where a person is employed twice by the same company, it would be necessary to introduce a suitable intermediate class.

2323


Semantics of links

2424


The Need for Generalization

In many modelling situations, a number of classes share some of

the same properties. These might be attributes, operations or the

way in which they are associated with other classes (or a combina

tion of all three).

For example, a bank might offer its customers a range of differen

t types of account, and a customer could hold any number of acco

unts, which could be of different types.

2525


The Need for Generalization

This is a clumsy model:

From a customer’s point of view, there is logically one relation, of holding an account. It shouldn’t have to be modelled by three separate associations.

The account classes will likely share a range of properties, which shouldn’t have to be defined in three separate places.

2626


Generalization

These problems can be addressed by introducing a common supe

rclass which represents what the three types of account have in co

mmon (namely, that they are accounts).

2727


Generalization

This relationship between superclasses and subclasses in UML is

known as generalization. The term for the inverse relation that su

bclasses have to superclasses is specialization.

Generalization relationships are quite different from associations:

Generalizations do not specifiy any type of link or relationship between objects.

Therefore, it makes no sense to put multiplicity symbols on generalization relationships.

2828


Generalization hierarchies

Generalization hierarchies can be formed. Omitted classes can be

shown with an ellipsis.

2929


Generalization hierarchies

Generalization is sometimes referred to as the is–a relationship.

The diagram above shows that a current account is an account, a p

ersonal account is a current account and so on.

Alternatively, specialized classes can be viewed as classifying the

instances of the superclass: an account can either be a current acc

ount or a deposit account; a current account can either be a person

al account or a business account, and so on.

3030


Substitutability

Generalization relationships in UML imply a notion of substitutability. For example, consider a single relationship of holding an account”.

This would normally imply that instances of the customer class could be linked to instances of the account class. Because of generalization, however, customers can be linked to accounts from any subclass.

3131


Substitutability

In other words, an instance of a subclass can be substituted wherever an instance of a superclass is specified or expected (in links, or operation parameters for example).

3232


Abstract Classes

Superclasses are introduced into a model to define the general fea

tures of a number of related classes. Often it does not make sense

to create instances of these superclasses.

For example, the model of the banking system might never create

simple Account classes, but only instances of one of the subclasse

s. In other words, every account must be either a current account,

or a deposit account, or . . . .

3333


Abstract Classes

In the case, Account would be modelled as an abstract class.

This can be shown typographically by writing the class name in a

slanted font:

3434


Inheritance

Attributes and operations are inherited by subclasses in a generali

zation relationship.

New attributes and operations can be added to support the speciali

zed requirements of subclasses.

3535


Inheritance

The set of attributes and operations of the deposit account class, f

or example, includes both those defined in the class itself and thos

e inherited from the account class.

3636


Overriding operations

Sometimes the basic functionality provided by an operation defin

ed in a superclass is not appropriate for a specialized subclass.

In this case the operation can be overridden, or redefined, in the s

ubclass.

3737


Overriding operations

The appearance of the inherited operation withdraw in the high interest accoun

t class indicates that it is redefined there, perhaps to impose a surcharge on the

withdrawal of money from accounts of that type.

3838


Polymorphism and Multiplicity

Suppose we wanted to enforce a constraint that customers could

hold at most one account of each type. The following diagram is t

oo restrictive:

We might try to define the required multiplicity constraint by me

ans of additional associations.

3939


Polymorphism and Multiplicity

This is wrong, because it defines an additional association (illega

lly given the same name as the original) which would permit a cus

tomer to optionally hold a current account in addition to all the ac

count they already held.

4040


Association Generalization What is required is to indicate that the new association is a specialization of the o

riginal:

The “superassociation” states that a customer can hold many accounts.

As the account class is abstract, these links must actually be to instances of subclasses.

The multiplicity of the “subassociation” constrains these links to a maximum of one of each kind of account.

The semantics of this are rather obscure. The “superassociation” should be thought of as being abstract, although it is not clear if UML defines this possibility.

4141


Parallel hierarchies

Association generalization is occasionally used to relate parallel

generalization hierarchies. The following diagram enforces the co

nstraint that individuals should hold current accounts, and compan

ies business accounts.

4242


Parallel hierarchies

Without the association generalizations, it would permit any type

of customer to hold any type of account.

As this example shows, the notation for association generalization

is visually rather complex and it should be used sparingly. The sit

uations in which it applies are common, however, and the constrai

nts imposed important.

4343


Aggregation

Aggregation is a special form of assocition which represents the

part-whole relationship between classes.

4444


Aggregation

This diagram states that a message consists of one header, one body and zero or more attachments. Each header and body is part of exactly one message, but attachments can be part of many message. Further, headers and bodies cannot exist independently of messages, unlike attachments.

In uses like this, aggregation has virtually no formal properties other than to suggest an informal notion of “parts”. It imposes no constraints on a model in addition to those implied by a simple association.

It is tempting to overuse this form of aggregation, but as it is effectively meaningless, a better rule is “if in doubt, leave it out”.

4545


Instance hierarchies

In the bill of materials example, hierarchical component structure

s were modelled, where a component could either be a part, or an

assembly containing a number of (sub)components. There was not

hing in the model to prevent the following sort of structures, howe

ver:

4646


Instance hierarchies

This sort of recursive object structure is ruled out by the formal properties of aggregation.

Antisymmetry prevents an object being linked to itself.

Transitivity extends the association to “chains” of links, and in conjunction with antisymmetry rules out cycles in the object graph.

4747


Composition

Composition is a stronger form of aggregation. In a composite, th

e lifetime of the “part” objects is dependent on that of the “whole”

objects: they cannot exist after the “whole” has been deleted.

For example, the header and the body of a mail message are delet

ed when the message is deleted, but the attachments are not:

4848


Links with data

Suppose we have a many-to-many association recording students

’ registrations on modules.

4949


Links with data

Now suppose that in addition we wish to record the mark that

each student got for the modules they took.

If we store the marks in the student objects, we have the problem of recording which mark corresponds to which module.

If we store the marks in the module objects, we have the problem of recording which mark correspond to which student.

A mark is more naturally associated with the link rather than eith

er object: it’s the mark the student got for a particular module.

5050


Association Classes

In UML this situation can be handled by defining an association

class. An association class is “an association that is also a class”,

and so can contain data.

5151


Association Classes

An association class is represented as an association and a class, j

oined by a dashed line. Notice that there are not two distinct mode

l elements here: in this diagram the name of the association is Res

ult, and it is shown in the class icon belonging to the association c

lass.

Association classes can also participate themselves in further ass

ociations.

5252


Reifying Associations

A common alternative approach to this problem is to replace the

many-to-many association with a class and two further associatio

ns.

Exercise: Draw this alternative diagram

Unlike the model using the association class, this mode allows two d

ifferent marks to be recorded for the same student/module combin

ation. (This might be useful if, for example, a student could retake

a module after failing it.)

This cannot be done with the association class because two distinct l

inks cannot exist between the same pair of objects.

5353


Indexes

In Unix, the relationship between files and directories is a many-t

o-many relationship. Each time a file is “linked” into a directory,

an identifying name is given to it.

This model does not reflect the important fact that within a direct

ory, file names must be unique. This model would permit two diff

erent files to be linked to the same directory under the same name.

5454


Indexes

Because filenames within a directory must be unique, it is natural

to think of the directory as implementing an index, or look-up tabl

e, of names and the location of the corresponding files.

These situations are modelled in UML by using a qualifier.

5555


Qualifiers

A qualifier is really an attribute of an association class, but becau

se of its role as a “key” in identifying objects at one end of the ass

ociation it is written as an attribute attached to the side of the clas

s that, conceptually, holds the index of qualifer values.

5656


Qualifiers

This diagram states that:

The diagram does not assert that a directory can only contain zero or one file. It means that for a given directory, each possible file name may optional be used as the name of a linked file. As there are many possible names, each directory can contain many files.

As before, files can be linked in many directories, with a name specified for each link.

5757


Qualifiers and Identifiers

Qualifiers are often used in connection with attributes which serv

e to identify objects in the real world. Consider:

5858


Qualifiers and Identifiers

This does not make it clear that, within the context of the universi

ty, every student is expected to have a unique ID number to distin

guish them from all other students.

The situation can be more accurately modelled using a qualifier.

Documents

1 Kyung Hee University Class Diagrams Spring 2001