Object-Oriented Programming

(OOP)
The Unified Modeling Language
UML
 7. Unified Modeling Language (UML)

• This Lecture will introduce you to the roles of

the Unified Modeling Language (UML) and
explain the purpose of four of the most
common diagrams (class diagrams, object
diagrams, sequence diagrams and package
diagrams).
• Particular emphasis will be placed on class
diagrams as these are the most used part of
the UML notation.

2 OOP
 Outlines

1) An introduction to UML
2) UML Class Diagrams
3) UML Syntax
4) UML Package Diagrams
5) UML Object diagrams
6) UML Sequence Diagrams

3 OOP
 1. An Introduction to UML
• UML a precise diagramming notation that will
allow program designs to be represented and
discussed.
• As it is graphical in nature it becomes easy to
visualize, understand and discuss the
information presented in the diagram.
• However, as the diagrams represent technical
information they must be precise and clear.

4 OOP
• There are 13 UML diagrams which can be
grouped into three categories:
– structure: class diagrams, package diagrams,
object diagrams, composite structure diagrams;
– behavior: use case diagrams, state diagrams,
sequence diagrams, timing diagrams,
communication diagrams, activity diagrams,
interaction overview diagrams;
– implementation: component diagrams,
deployment diagrams.

5 EA: Lecture 7
 2. UML Class diagrams
• Classes are the basic components of any
object oriented software system.
• UML class diagrams provide an easy way to
represent classes.
• As well as showing individual classes, in detail,
class diagrams show multiple classes and how
they are related to each other.
• Thus a class diagram shows the architecture
of a system.
6 OOP
• A class consists of :-
1. a unique name (conventionally starting with an
uppercase letter)
2. a list of attributes (int, double, boolean, String
etc)
3. a list of methods

7 OOP
 • This is shown in a simple box
structure…
• For attributes and methods
visibility modifiers are shown
(+ for public access, – for
private access).
• Attributes normally being kept
private and methods normally
made public.

8 OOP
• Thus a class Book, with
String attributes of title
and author, and the
following methods
setTitle(), getTitle(),
setAuthor(), getAuthor()
and toString() would be
shown as ….

9 OOP
10 OOP
11 OOP
• UML allows us to suppress any information we
do not wish to highlight in our diagrams – this
allows us to suppress irrelevant detail and
bring to the readers attention just the
information we wish to focus on.
• Therefore the following are all valid class
diagrams…

12 OOP
• Firstly with the access modifiers not shown….

13 OOP
• Secondly with the access modifiers and the
data type not shown…..

14 OOP
• And finally with the attributes and methods
not shown….. i.e. there is a class called
‘BankAccount’ but the details of this are not
being shown.

15 OOP
• Of course virtually all Java programs will be made
up of many classes.
• Classes will relate to each other – some classes
will make use of other classes.
• These relationships are shown by arrows.
• Different type of arrow indicate different
relationships (including inheritance and
aggregation relationships).
• In addition to this, class diagrams can make use
of keywords, notes and comments.

16 OOP
As we will see in examples that follow, a class
diagram can show the following information :-
1. Classes
2. Relationships
3. Generalization / specialization
4. Keywords
5. Notes and Comments

17 OOP
• Classes
- attributes
- Operations (methods)
- visibility

18 OOP
• Relationships
- navigability
- multiplicity
- dependency
- aggregation
- composition

19 OOP
• Generalization / specialization
- inheritance
- interfaces
• Keywords
• Notes and Comments

20 OOP
 3. UML Syntax
• As UML diagrams convey precise information
there is a precise syntax that should be followed.
• Attributes should be shown as:
visibility name : type multiplicity

Where visibility is one of :- and multiplicity is one of :-

‘+’ public ‘n’ exactly n
‘-’ private ‘*’ zero or more
‘#’ protected ‘m..‘n’ between m and n
‘~’ package

21 OOP
• The following are examples of attributes
correctly specified using UML :-
- custRef : int [1]
a private attribute custRef is a single int value
this would often be shown as - custRef : int
However with no multiplicity shown we
cannot safely assume a multiplicity of one was
intended by the author.

22 OOP
 # itemCodes : String [1..*]
a protected attribute itemCodes is one or
more String values

23 OOP
 validCard : boolean
an attribute validCard, of unspecified visibility,
has unspecified multiplicity

24 OOP
• Operations also have a precise syntax and
should be shown as:
visibility name (par1 : type1, par2 : type2): returntype
where each parameter is shown (in
parenthesis) and then the return type is
specified.

25 OOP
• An example would be
+ addName (newName : String) : boolean
• This denotes a public method ‘addName’
which takes one parameter ‘newName’ of
type String and returns a boolean value.

26 OOP
27 OOP
28 OOP
Denoting Relationships
• As well as denoting individual classes, Class
diagrams denote relationships between
classes.
• One such relationships is called an
‘Association’

29 OOP
• In a class attributes will be defined. These could be
primitive data types (int, boolean etc.) however
attributes can also be complex objects as defined by
other classes.

• Thus the figure above shows a class ‘OneClass’ that has

an attribute ‘value’.
• This value is not a primitive data type but is an object of
type defined by ‘OtherClass’.

30 OOP
• We could denote exactly the same information by
the diagram below.

• We use an association when we want to give two

related classes, and their relationship, prominence
on a class diagram
• The ‘source’ class points to the ‘target’ class.

31 OOP
• Strictly we could use an association when a
class we define has a String instance variable –
but we would not do this because the String
class is part of the Java platform and ‘taken for
granted’ like an attribute of a primitive type.

32 OOP
• This would generally be true of all library
classes unless we are drawing the diagram
specifically to explain some aspect of the
library class for the benefit of someone
unfamiliar with its purpose and functionality.

33 OOP
• Additionally we can show multiplicity at both ends of
an association:

• This implies that ‘OneClass’ maintains a collection of

objects of type ‘OtherClass’.
• Collections are an important part of the Java
framework that we will look at the use of collections
later.

34 OOP
35 OOP
• Note: All class names begin in uppercase, attribute and method
names begin in lowercase.
• Also note that the class ItemForSale describes a single item (not
multiple items).
• ‘listOfItems’ however maintains a list of zero or more individual
objects.

36 OOP
Types of Association
There are various different types of association
denoted by different arrows:-
1. Dependency,
2. Simple association
3. Bidirectional association
4. Aggregation and
5. Composition

37 OOP
38 OOP
• Dependency

– Dependency is the most unspecific relationship between

classes (not strictly an ‘association’)
– Class A in some way uses facilities defined by Class B
– Changes to Class B may affect Class A
• Typical use of dependency lines would be where Class
A has a method which is passed a parameter object of
Class B, or uses a local variable of that class, or calls
‘static’ methods in Class B.
39 OOP
• Simple Association

– In an association Class A ‘uses’ objects of Class B

– Typically Class A has an attribute of Class B
– Navigability is from A to B:
i.e. A Class A object can access the Class B object(s) with
which it is associated. The reverse is not true – the Class
B object doesn’t ‘know about’ the Class A object
• A simple association typically corresponds to an
instance variable in Class A of the target class B type.
40 OOP
• Example: the Catalogue above needs access to
0 or more ItemsForSale so items can be added
or removed from a Catalogue.
• An ItemForSale does not need to access a
Catalogue in order to set its price or perform
some other method associated with the item
itself.

41 OOP
• Bidirectional Association

• Bidirectional Association is when Classes A and B have a two-way

association
• Each refers to the other class
• Navigability A to B and B to A:
- A Class A object can access the Class B object(s) with which it is
associated
- Object(s) of Class B ‘belong to’ Class A
- Implies reference from A to B
- Also, a Class B object can access the Class A object(s) with which it is
associated

42 OOP
• A bidirectional association is complicated
because each object must have a reference to
the other object(s) and generally bidirectional
associations are much less common than
unidirectional ones.

43 OOP
• An example of a bidirectional association may between
a ‘Degree’ and ‘Student’. ie. given a Degree we may
wish to know which Students are studying on that
Degree. Alternatively starting with a student we may
wish to know the Degree they are studying.

• As many students study the same Degree at the same

time, but students usually only take one Degree there
is still a one to many relationship here.
44 OOP
• Aggregation

• Aggregation denotes a situation where Object(s) of Class B

‘belong to’ Class A
• Implies reference from A to B
• While aggregation implies that objects of Class B belong to
objects of Class A it also implies that object of Class B retain
an existence independent of Class A. Some designers
believe there is no real distinction between aggregation
and simple association

45 OOP
• An example of aggregation would be between a
Class Car and a Class Tyre

• We think of the tyres as belonging to the car they

are on, but at the garage they may be removed
and placed on a rack to be repaired. Their
existence isn’t dependent on the existence of a
car with which they are associated.

46 OOP
• Composition

• Composition is similar to aggregation but implies a much

stronger belonging relationship i.e. Object(s) of Class B are
‘part of’ a Class A object
• Again implies reference from A to B
• Much ‘stronger’ than aggregation in this case Class B
objects are an integral part of Class A and in general objects
of Class B never exist other than as part of Class A, i.e. they
have the same ‘lifetime’

47 OOP
• An example of composition would be between
Points, Lines and Shapes as elements of a
Picture.
• These objects can only exist as part of a
picture, and if the picture is deleted they are
also deleted.

48 OOP
As well as denoting associations, class diagrams
can denote :-
• Inheritance,
• Interfaces,
• Keywords and
• Notes

49 OOP
• Inheritance

• Aside from associations, the other main modeling

relationship is inheritance:
• Class A ‘inherits’ both the interface and
implementation of Class B, though it may override
implementation details and supplement both.
• We will look at inheritance in detail later.

50 OOP
Interfaces
• Interfaces are similar to inheritance however with
interfaces only the interface is inherited. The methods
defined by the interface must be implemented in every
class that implements the interface.
• Interfaces can be represented using the <<interface>>
keyword:

51 OOP
• There is also a shorthand for this

• In both cases these examples denote that the

SaleableItem interface is required by CashTill
and implemented by Publication.

52 OOP
• NB the dotted-line version of the inheritance
line/arrow which shows that Publication
‘implements’ or ‘realizes’ the SaleableItem
interface.
• The “ball and socket” notation is new in UML
2 – it is a good visual way of representing how
interfaces connect classes together.
• We will look at the application of interfaces in
more detail later.

53 OOP
Keywords
• UML defines keywords to refine the meaning of the
graphical symbols We have seen <<interface>> and
we will also make use of <<abstract>> but there are
many more.
• An abstract class may alternatively be denoted by
showing its name in italics though this is perhaps less
obvious to a casual reader.

54 OOP
Notes

• Finally we can add notes to comment on a

diagram element. This gives us a ‘catch all’ facility
for adding information not conveyed by the
graphical notation.

55 OOP
56 OOP
57 OOP
58 OOP
59 OOP
60 OOP
61 OOP
62 OOP
 4. UML Package Diagrams
• While class diagrams are the most commonly
used diagram in UML notation, there are
other diagrams that denote different types of
information.
• Here we will touch upon three of these :-
– Package Diagrams
– Object Diagrams and
– Sequence Diagrams

63 OOP
• World maps, country maps and city maps all
show spatial information, just on different
scales and with differing levels of detail.
• Large OO systems can be made up of
hundreds, or potentially thousands, of classes
and thus if the class diagram was the only way
to represent the architecture of a large system
it would become overly large and complex.

64 OOP
• Thus, just as we need world maps, we need
package diagrams to show the general
architecture of a large system.
• Even modest systems can be broken down
into a few basic components i.e. packages.
• For now we will just look at the package
diagramming notation.

65 OOP
• A package is not just a visual representation of a
group of classes instead.
• A ‘package’ is a directory containing a group of
related classes (and interfaces).
• Packages allow us to provide a level of
organization and encapsulation above that of
individual classes and all of the standard Java
platform classes are arranged in a single large
package hierarchy.
• Similarly we can also arrange our own classes
using the Java package mechanism.
66 OOP
• Packages are described as a series of dot-separated names, e.g.
java.awt.event. The names correspond to a series of sub-directories
in the file system, e.g.

• A large Java development should be split into suitable packages at

the design stage
• UML provides a ‘Package Diagram’ to represent the relationships
between classes and packages.

67 OOP
We can depict
• classes within packages
• nesting of packages
• dependencies between packages

68 OOP
• In the diagram next, we see two packages:-
‘monitor systems’ and ‘management systems’.
• The depict part of a large system for a
multinational corporation to manage and
maintain their operations including their
computer systems and personnel.

69 OOP
70 OOP
• Looking at this more closely we can see that
inside the ‘monitor systems’ package is
another called ‘monitor network’.
• This package contains at least two classes
‘Router’ and ‘Hup’ through presumably it
contains may other related classes.
• The package ‘management systems’ contains
tow classes (or more) ‘System Reports’ and
‘Personnel Reports’.

71 OOP
• Furthermore, we can see that the classes
inside the package ‘management systems’ in
some way use the classes inside ‘monitor
network’.
• Presumably it is the ‘System Report’ class that
makes use of these as it needs to know about
the status of the network.

72 OOP
• Note that the normal UML principle of
suppression applies here- these packages may
contain other packages and each package may
contain dozens of classes but we simply
choose not to show them.

73 OOP
• In the class diagram below we have an
alternative way of indicating that ‘Router’ is a
class inside the ‘monitor network’ package,
which is in turn inside ‘monitor systems’
package.

74 OOP
• And again below a form which shows both
classes more concisely than at the top.

• These different representations will be useful

in different circumstances depending on what
a package diagram is aiming to convey.
75 OOP
Package Naming
• By convention, package names are normally in
lowercase
• For local individual projects packages could be
named according to personal preference, e.g.
mysystem
mysystem.interface
mysystem.engine
mysystem.engine.util
mysystem.database
76 OOP
• However, packages are often distributed and to enable this
packages need globally unique names, thus a naming convention
has been adopted based on URLs

• Note on a package diagram each element is not separated by a ‘.’

but by ‘::’.

77 OOP
78 OOP
79 OOP
80 OOP
81 OOP
82 OOP
83 OOP
 5. UML Object Diagrams
• Class diagrams and package diagrams allow us to
visualize and discuss the architecture of a system
however at times we wish to discuss the data a
system processes.
• Object diagrams allow us to visual one instance of
time and the data that a system may contain in
that moment.
• Object diagrams look superficially similar to class
diagrams however the boxes represent specific
instances of objects.
84 OOP
• Boxes are titled with :-
objectName : ClassName
• As each box describes a particular object at a
specific moment in time the box contains
attributes and their values (at that moment in
time).
attribute = value
• These diagrams are useful for illustrating
particular ‘snapshot’ scenarios during design.
85 OOP
• The object diagram below shows several
object that may exist at a moment in time for
a library catalogue system.
• The system contains two classes :-
Book, which store the details of a book and
Library, which maintains a collection of books.
With books being added, searched for or
removed as required.

86 OOP
87 OOP
• Looking at this diagram we can see that at a
particular moment in time, while three books
have been created only two have been added
to the library.
• Thus if we were to search the library for
‘Cooking for Beginners’ we would not expect
the book to be found.
• As with class diagrams, elements can be freely
suppressed on object diagrams.

88 OOP
89 OOP
 6. UML Sequence Diagrams
• Sequence diagrams are entirely different from
class diagrams or object diagrams.
• Class diagrams describe the architecture of a
system and object diagrams describe the state
of a system at one moment in time.
• However sequence diagrams describe how the
system works over a period of time.

90 OOP
• Sequence diagrams are ‘dynamic’ rather than
‘static’ representations of the system.
• They show the sequence of method
invocations within and between objects over a
period of time.
• They are useful for understanding how objects
collaborate in a particular scenario.

91 OOP
92 OOP
• We have three objects in this scenario.
• Time runs from top to bottom, and the
vertical dashed lines (lifelines) indicate the
objects’ continued existence through time.

93 OOP
This diagram shows the following actions taking place :-
• Firstly a method call (often referred to in OO
terminology as a message) to method0() comes to
object1 from somewhere – this could be another class
outside the diagram.
• object1 begins executing its method0() (as indicated by
the vertical bar (called an activation bar) which starts
at this point.
• object1.method0() invokes object2.method1() – the
activation bar indicates that this executes for a period
then returns control to method0()

94 OOP
• Subsequently object1.method0() invokes
object2.method2() passing two parameters
• method2() subsequently invokes
object3.method3(). When method3() ends it
passes a return value back to method2()
• method2() completes and returns control to
object1.method0()
• Finally method0() calls another method of the
same object, method4()
95 OOP
Selection and Iteration
• The logic of a scenario often depends on selection (‘if’)
and iteration (loops).
• There is a notation (‘interaction frames’) which allow
ifs and loops to be represented in sequence diagrams
however these tend to make the diagrams cluttered.
• Sequence diagrams are generally best used for
illustrating particular cases, with the full refinement
reserved for the implementation code.
• Fowler (“UML Distilled”, 3rd Edn.) gives a brief
treatment of these constructs.
96 OOP
 7. Summary
• UML is not a methodology but a precise
diagramming notation.
• Class diagrams and package diagrams are
good for describing the architecture of a
system.
• Object diagrams describe the data within an
application at one moment in time and
sequence diagrams describe how a system
works over a period of time.

97 OOP
• UML gives different meaning to different
arrows therefore one must be careful to use
the notation precisely as specified.
• With any UML diagram suppression is
encouraged – thus the author of a diagram
can suppress any details they wish in order to
convey essential information to the reader.

98 OOP