1 kyung hee university class diagrams spring 2001
Post on 20-Jan-2016
218 Views
Preview:
TRANSCRIPT
11
Kyung Hee University
Class DiagramsClass Diagrams
Spring 2001
22
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
Labelling associations
2. To distinguish between the two ends of a self-association
2222
Kyung Hee University
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
Kyung Hee University
Semantics of links
2424
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
Generalization hierarchies
Generalization hierarchies can be formed. Omitted classes can be
shown with an ellipsis.
2929
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
Aggregation
Aggregation is a special form of assocition which represents the
part-whole relationship between classes.
4444
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
Links with data
Suppose we have a many-to-many association recording students
’ registrations on modules.
4949
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
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
Kyung Hee University
Qualifiers and Identifiers
Qualifiers are often used in connection with attributes which serv
e to identify objects in the real world. Consider:
5858
Kyung Hee University
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.
top related