Transcript Class Diagram

Class Diagrams
Spring 2001
Kyung Hee
University
1
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:
Kyung Hee
University
2
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.
Kyung Hee
University
3
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.
Kyung Hee
University
4
Datatypes
User-defined types These are enumerations, and can be represented
graphically:
Language types Defined by type expressions borrowed from the target
programming language.
Kyung Hee
University
5
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.
Kyung Hee
University
6
Instances of classes
 UML makes a basic distinction between descriptors and
instances. Descriptors – such as classes – describe, or specify, the
properties of their instances – such as objects.
The relationship between a class and its instances is known as
instantiation. It can be represented in UML using a dependency
labelled with the stereotype “instantiates”.
Kyung Hee
University
7
Class Multiplicity
 It is very rare that there is a need to show this explicitly. A
multiplicity in a class specifies the number of instances of that
class that can exist simultaneously. The default is “zero or more”.
A common use is to specify that a class can only have one
instance.
Kyung Hee
University
8
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.
Kyung Hee
University
9
Attributes
 Attributes with class scope are underlined in a class icon. They
are similar to static data members in programming languages.
 Attribute syntax: types are optional; optional multiplicity
between the name and the colon.
Kyung Hee
University
10
Operations
 Classes also have operations, whcih specify ways of accessing or
manipulating the data stored in objects. As operations are the
same for every instance of a class, they are not normally shown on
object icons.
Kyung Hee
University
11
Operations
 Normal operations can be applied to individual objects.
Operations 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.
Kyung Hee
University
12
Object Identity
 Two objects of a class can have identical values for their
attributes, 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
object’s identity is often implemented as its address in memory.)
Kyung Hee
University
13
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
added:
 Here the id attribute is quite distinct from the identity of the
instances of the class.
Kyung Hee
University
14
Associations and Links
 Two objects can only be linked if there is a corresponding
association 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.
Kyung Hee
University
15
Associations and Links
 An association name is often a verb. The arrowhead indicates
which direction to read it in. This association shows people
working for companies, not companies working for people (which
is a perfectly sensible, but different, association).
 Role names are often nouns, describing the role an object plays in
the relationship.
Kyung Hee
University
16
Self associations
 Associations are normally binary, connecting two classes. UML
does provide a notation for associations that connect more than
two 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.
Kyung Hee
University
17
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
people. In other words, a company has many employees, each of
whom only works for one company.
Kyung Hee
University
18
Multiplicity of associations
 Given this class diagram, the following object diagram represents
an illegal situation, as it show a person working for two
companies.
Kyung Hee
University
19
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.
Kyung Hee
University
20
Labelling associations
2. To distinguish between the two ends of a self-association
Kyung Hee
University
21
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.
Kyung Hee
University
22
Semantics of links
Kyung Hee
University
23
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
combination of all three).
 For example, a bank might offer its customers a range of different
types of account, and a customer could hold any number of
accounts, which could be of different types.
Kyung Hee
University
24
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.
Kyung Hee
University
25
Generalization
 These problems can be addressed by introducing a common
superclass which represents what the three types of account have
in common (namely, that they are accounts).
Kyung Hee
University
26
Generalization
 This relationship between superclasses and subclasses in UML is
known as generalization. The term for the inverse relation that
subclasses 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.
Kyung Hee
University
27
Generalization hierarchies
 Generalization hierarchies can be formed. Omitted classes can be
shown with an ellipsis.

Kyung Hee
University
28
Generalization hierarchies
 Generalization is sometimes referred to as the is–a relationship.
The diagram above shows that a current account is an account, a
personal 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
account or a deposit account; a current account can either be a
personal account or a business account, and so on.
Kyung Hee
University
29
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.
Kyung Hee
University
30
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).
Kyung Hee
University
31
Abstract Classes
 Superclasses are introduced into a model to define the general
features 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
subclasses. In other words, every account must be either a current
account, or a deposit account, or . . . .
Kyung Hee
University
32
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:
Kyung Hee
University
33
Inheritance
 Attributes and operations are inherited by subclasses in a
generalization relationship.
New attributes and operations can be added to support the
specialized requirements of subclasses.
Kyung Hee
University
34
Inheritance
 The set of attributes and operations of the deposit account class,
for example, includes both those defined in the class itself and
those inherited from the account class.
Kyung Hee
University
35
Overriding operations
 Sometimes the basic functionality provided by an operation
defined in a superclass is not appropriate for a specialized
subclass.
 In this case the operation can be overridden, or redefined, in the
subclass.
Kyung Hee
University
36
Overriding operations


 The appearance of the inherited operation withdraw in the high interest
account class indicates that it is redefined there, perhaps to impose a surcharge
on the withdrawal of money from accounts of that type.
Kyung Hee
University
37
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
too restrictive:
 We might try to define the required multiplicity constraint by
means of additional associations.
Kyung Hee
University
38
Polymorphism and Multiplicity
 This is wrong, because it defines an additional association
(illegally given the same name as the original) which would
permit a customer to optionally hold a current account in addition
to all the account they already held.
Kyung Hee
University
39
Association Generalization
 What is required is to indicate that the new association is a specialization of
the original:
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.
Kyung Hee
University
40
Parallel hierarchies
 Association generalization is occasionally used to relate parallel
generalization hierarchies. The following diagram enforces the
constraint that individuals should hold current accounts, and
companies business accounts.
Kyung Hee
University
41
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
situations in which it applies are common, however, and the
constraints imposed important.
Kyung Hee
University
42
Aggregation
 Aggregation is a special form of assocition which represents the
part-whole relationship between classes.
Kyung Hee
University
43
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”.
Kyung Hee
University
44
Instance hierarchies
 In the bill of materials example, hierarchical component
structures were modelled, where a component could either be a
part, or an assembly containing a number of (sub)components.
There was nothing in the model to prevent the following sort of
structures, however:
Kyung Hee
University
45
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.
Kyung Hee
University
46
Composition
 Composition is a stronger form of aggregation. In a composite,
the 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
deleted when the message is deleted, but the attachments are not:
Kyung Hee
University
47
Links with data
 Suppose we have a many-to-many association recording students’
registrations on modules.
Kyung Hee
University
48
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
either object: it’s the mark the student got for a particular module.
Kyung Hee
University
49
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.
Kyung Hee
University
50
Association Classes
 An association class is represented as an association and a class,
joined by a dashed line. Notice that there are not two distinct
model elements here: in this diagram the name of the association
is Result, and it is shown in the class icon belonging to the
association class.
 Association classes can also participate themselves in further
associations.
Kyung Hee
University
51
Reifying Associations
 A common alternative approach to this problem is to replace the
many-to-many association with a class and two further
associations.
 Exercise: Draw this alternative diagram
Unlike the model using the association class, this mode allows two
different marks to be recorded for the same student/module
combination. (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
links cannot exist between the same pair of objects.
Kyung Hee
University
52
Indexes
 In Unix, the relationship between files and directories is a manyto-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
directory, file names must be unique. This model would permit
two different files to be linked to the same directory under the
same name.
Kyung Hee
University
53
Indexes
 Because filenames within a directory must be unique, it is natural
to think of the directory as implementing an index, or look-up
table, of names and the location of the corresponding files.
 These situations are modelled in UML by using a qualifier.
Kyung Hee
University
54
Qualifiers
 A qualifier is really an attribute of an association class, but
because of its role as a “key” in identifying objects at one end of
the association it is written as an attribute attached to the side of
the class that, conceptually, holds the index of qualifer values.
Kyung Hee
University
55
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.
Kyung Hee
University
56
Qualifiers and Identifiers
 Qualifiers are often used in connection with attributes which
serve to identify objects in the real world. Consider:
Kyung Hee
University
57
Qualifiers and Identifiers
 This does not make it clear that, within the context of the
university, every student is expected to have a unique ID number
to distinguish them from all other students.
The situation can be more accurately modelled using a qualifier.
Kyung Hee
University
58