Object Oriented Analysis: Class Diagrams

Dr Ilir Gashi
Centre for Software Reliability
School of Mathematics, Computer
Science and Engineering
City University London
2nd – 4th May, 2014
 Acknowledgment
 Slides and tutorials are based on materials
prepared by Jim Arlow (Clear View Training)
and Dr Peter Popov (City University London)

2
 Objectives

 To introduce the concept of object-oriented analysis

 To introduce a technique of discovering problem
domain classes
 Noun-verb analysis
 To introduce the UML syntax for analysis class diagrams
 Classes
 Attributes
 Operations
 Associations
 Multiplicities
 Roles
 Association classes
5.3
Analysis - introduction

© Clear View Training 2010 v2.6 5.4

 Some definitions of objects
 An object is:
"An abstraction of something in a problem domain,
reflecting the capabilities of a system to keep information about it,
interact with it, or both”
(Coad & Yourdon 1991)

"An entity able to save a state (information) and which offers a

number of operations (behaviour) to either examine or affect this
state"
(Jacobson 1992)

5.5
 Objects & abstraction
 "An abstraction denotes
the essential
characteristics of an
object that distinguish it
from all other kinds of
objects and thus provide
crisply defined conceptual
boundaries, relative to
the perspective of the
viewer"
 (Grady Booch 1994)

5.6
7.2

What are objects?

 Objects consist of data and functions packaged together in a reusable
unit. Objects encapsulate data
 Every object is an instance of some class which defines the common
set of features (attributes and operations) shared by all of its instances.
Objects have:
 Attribute values – the data part
 Operations – the behaviour part
 All objects have:
 Identity: Each object has its own unique identity and can be accessed by a
unique handle (e.g. the location in memory the instance is stored)
 State: This is the actual data values stored in an object at any point in time
 Behaviour: The set of operations that an object can perform

© Clear View Training 2010 v2.6 5.7

7.2.1

Encapsulation
operations
attribute values
 Data is hidden inside the
object. The only way to
deposit()
access the data is via one
of the operations
 This is encapsulation or number = "1243"
withdraw()
data hiding and it is a very
owner = "Jim Arlow"
powerful idea. It leads to
balance = 300.00
more robust software and getOwner()
reusable code.
setOwner()

An Account Object

© Clear View Training 2010 v2.6 5.8

7.2.2

Messaging
 In OO systems, objects send messages to each other over
links
 These messages cause an object to invoke an operation
Bank Object Account Object
message

withdraw( 150.00 )

the Bank object sends the the Account object responds by

message “withdraw 150.00” to invoking its withdraw operation. This
an Account object. operation decrements the account
balance by 150.00.

© Clear View Training 2010 v2.6 5.9

7.3

UML Object Syntax

variants
object class (N.B. we've omitted the attribute compartment)
object identifier name name
(must be underlined) object and
class name
jimsAccount : Account
name
compartment jimsAccount : Account
object name
accountNumber : String = "1234567" only jimsAccount
attribute owner : String = "Jim Arlow"
compartment balance : double = 300.00
class name
only : Account

attribute attribute attribute

name type value an anonymous object

 All objects of a particular class have the same set of operations. They are not shown
on the object diagram, they are shown on the class diagram (see later)
 Attribute types are often omitted to simplify the diagram
 Naming:
 object and attribute names in lowerCamelCase
 class names in UpperCamelCase
© Clear View Training 2010 v2.6 5.10
7.4

What are classes?

 Every object is an instance of one class - the class describes
the "type" of the object
 Classes allow us to model sets of objects that have the same
set of features - a class acts as a template for objects:
 The class determines the structure (set of features) of all objects of that
class
 All objects of a class must have the same set of operations, must have
the same attributes, but may have different attribute values
 Classification is one of the most important ways we have of
organising our view of the world
 Think of classes as being like: class
 Rubber stamps
 Cookie cutters
object
© Clear View Training 2010 v2.6 5.11
7.4.1

Classes and objects

Account
 Objects are instances of
class accountNumber : String
classes owner : String
balance : double
 Instantiation is the creation
of new instances of model withdraw()
deposit()
elements
 Most classes provide special
«instantiate» «instantiate» «instantiate»
operations called
constructors to create JimsAccount:Account fabsAccount:Account ilasAccount:Account
instances of that class.
accountNumber : "801" accountNumber : "802" accountNumber : "803"
These operations have owner : "Jim" owner : "Fab" owner : "Ila"
class-scope i.e. they belong balance : 300.00 balance : 1000.00 balance : 310.00

to the class itself rather

than to objects of the class objects
objects are instances of classes

© Clear View Training 2010 v2.6 5.12

7.5

UML class notation

class name
tagged values

name Window
{author = Jim,
compartment status = tested}
+size : Area=(100,100) initial
#visibility : Boolean = false values
attribute +defaultSize: Rectangle
compartment #maximumSize : Rectangle
-xptr : XWindow*
visibility
adornment +create() class scope (static)
+hide() operation
operation
+display( location : Point )
compartment -attachXWindow( xwin : XWindow*)

 Classes are named in UpperCamelCase

 Use descriptive names that are nouns or noun phrases
 Avoid abbreviations!
© Clear View Training 2010 v2.6 5.13
Analysis - finding analysis classes

© Clear View Training 2010 v2.6 5.14

17.3

OO analysis and design

Problem Analysis Design Solution
domain classes classes domain

java.util

© Clear View Training 2010 v2.6 5.15

8.3b

What are Analysis classes?

 Analysis classes represent a crisp
abstraction in the problem domain
 They may ultimately be refined into class name BankAccount
one or more design classes name : String
 All classes in the Analysis model attributes address
should be Analysis classes balance : double
 Analysis classes have: deposit()
 A very “high level” set of attributes. operations withdraw()
They indicate the attributes that the
design classes might have. calculateInterest()
 Operations that specify at a high level
the key services that the class must
offer. In Design, they will become We always
actual, implementable, operations. specify attribute
 Analysis classes must map onto real- types if we
know what
world business concepts they are!

© Clear View Training 2010 v2.6 5.16

17.4

Analysis vs. Design classes

analysis design

BankAccount BankAccount
name -name:String
«trace»
number -number:String
balance -balance:double = 0
deposit()
withdraw() +BankAccount(name:String, number:String)
constructor +deposit(m:double):void
calculateInterest()
+withdraw(m:double):boolean
 A design class must have: +calculateInterest():double
+getName():String
 A complete set of operations +setName(n:String):void
including parameter lists, return +getAddress():String
types, visibility, exceptions, set +setAddress(a:String):void
and get operations, constructors +getBalance():double
and destructors
 A complete set of attributes
including types and default
values
© Clear View Training 2010 v2.6 5.17
8.3.2

What makes a good analysis class?

 Its name reflects its intent
 It is a crisp abstraction that models one specific element of the problem domain
 It maps onto a clearly identifiable feature of the problem domain
 It has high cohesion
 Cohesion is the degree to which a class models a single abstraction
 Cohesion is the degree to which the responsibilities of the class are semantically related
 It has low coupling
 Coupling is the degree to which one class depends on others
 Rules of thumb:
 3 to 5 responsibilities per class A responsibility is a
 Each class collaborates with others contract or obligation of a
 Beware many very small classes class - it resolves into
 Beware few but very large classes operations and attributes
 Beware of “functoids”
 Beware of “omnipotent” classes
 Avoid deep inheritance trees
© Clear View Training 2010 v2.6 5.18
8.4

Finding classes
 Perform noun/verb analysis on documents:
 Nouns are candidate classes
 Verbs are candidate responsibilities
 Other methods exist (e.g. Class-responsibility-collaboration
(CRC) cards)
 Beware of spurious classes:
 Look for synonyms - different words that mean the same
 Look for homonyms - the same word meaning different things
 Look for "hidden" classes!
 Classes that don't appear as nouns in the specifications
 Use patterns – often domain neutral and reusable

© Clear View Training 2010 v2.6 5.19

8.4.1

Noun/verb analysis procedure

 Make a list of nouns and noun phrases
 These are candidate classes or attributes
 The analysis consists of passing judgement about whether a
noun phrase is:
 A class
 An attribute
 Ignored in analysis
 Make a list of verbs and verb phrases
 These are candidate operations or named associations
 Analysis consists of passing judgement whether a verb phrase
is:
 An operation
 A named association
 Ignored in analysis
 Tentatively assign attributes and operations to classes
© Clear View Training 2010 v2.6 5.20
8.4.4

Other sources of classes

 Physical objects
 Paperwork, forms etc.
 Be careful with this one – if the existing business process
is very poor, then the paperwork that supports it might
be irrelevant
 But be aware not to try automate “archaic” paper based
processes
 Business processes may require redesign before automation
 Known interfaces to the outside world
 Conceptual entities that form a cohesive abstraction
e.g. LoyaltyProgramme

© Clear View Training 2010 v2.6 5.21

 Example - food manufacturing company

 Tangible objects:
 one packet of herbal tea

 invoice 63501 sent to A Farm, Lincolnshire

 Role objects:
 plant operator

 quality controller

 Interaction objects:
 a purchasing transaction

 order for new stock

 Event objects:
 processing plant breaks down

 Organisational objects:
 Marketing Department

5.22
 Worked example
 We will look at the vision statement for an
example case study, Town Map
 Note that we could also use other documents
as input to this activity, and we would process
them in exactly the same way:
 Use cases
 Project glossary
 Initial statement of the requirements (i.e. an
Informal descriptions of the system)

5.23
 Town map example
The system you are analysing is an electronic town map in a public car
park that is designed to show the key points of the town.
The map has a light to identify each key location, such as the hospital and
the library. Below the map is a panel containing buttons labelled with the
location names. When a visitor pushes the button on the panel the light at
the related location lights up for 10 seconds.
A visitor who wants a printed copy of the map can push the "print map"
button, and a hard copy map is released through the map slot.
The system keeps a tally of the number of printed maps requested. If the
machine runs out of paper, a sign saying "Sorry, no printed maps available"
is lit up, until an operator comes and restocks with paper. If the paper gets
low (less than about 100 sheets) an internal "paper low" light illuminates.
When an operator comes to maintain the TownMap they perform two
tasks:
1) Restock with paper if necessary.
2) Press the internal "test lights" button to illuminate all the lights for 1
minute. If any of the lights have burned out, the operator replaces them

5.24
 Highlight nouns & verbs
The system you are analysing is an electronic town map in a public car
park that is designed to show the key points of the town.
The map has a light to identify each key location, such as the hospital and
the library. Below the map is a panel containing buttons labelled with the
location names. When a visitor pushes the button on the panel the light at
the related location lights up for 10 seconds.
A visitor who wants a printed copy of the map can push the "print map"
button, and a hard copy map is released through the map slot.
The system keeps a tally of the number of printed maps requested. If the
machine runs out of paper, a sign saying "Sorry, no printed maps available"
is lit up, until an operator comes and restocks with paper. If the paper gets
low (less than about 100 sheets) an internal "paper low" light illuminates.
When an operator comes to maintain the town map they perform two
tasks:
1) Restock with paper if necessary.
2) Press the internal "test lights" button to illuminate all the lights for 1
minute. If any of the lights have burned out, the operator replaces them.

5.25
 Noun list
system panel
town map light
public car park location
map map slot
light sign saying "Sorry, no printed maps available"
key location operator
hospital paper
library internal "paper low" light
map operator
panel tally
buttons labelled with the location town map
names lights
visitor operator
button

 Notice that there will usually be:

 Duplicates
 Synonyms – different words have the same meaning e.g. "map" and "town map"
 Homonyms – the same word has different meanings e.g. "button" – there are
two different types of button
5.26
 Refined noun list
hospital
library  We have:
location  Removed
location button
location light duplicates
map slot
operator (actor?)  Resolved synonyms
paper and homonyms
paper low light
print map button  Identified nouns
public car park
sign saying "Sorry, no printed maps that don't seem to
available" be part of the
system
town map system
tally
visitor (actor?)  Identified possible
actors
5.27
 Candidate classes
 We have analysed the list of
LocationButton nouns to come up with some
PrintMapButton candidate classes
 Candidate classes are classes
that represent possible
TownMap analysis classes
LocationLight
 We have applied naming
standards (UpperCamelCase)
PaperLowLight to give the classes good
names
NoPrintedMapsSign
 Some classes are still missing
– e.g. what prints the maps?
Tally

Printer

5.28
Organizing the candidate classes
 The next step
is to create a
class diagram
showing the
candidate
classes and
how they
might be
related

5.29
 Find attributes
LocationButton LocationLight
locationName:String locationName:String

The map has a light to identify each key location, such as the hospital and the library.

 Nouns also indicate attributes of candidate classes

 Look for nouns that might indicate parts of something
 Look for nouns that refer to simple things such as names,
numbers and dates – such things are usually attributes

5.30
 Finding operations
LocationLight
turnOn()
turnOff()

show the key points of the town

LocationButton
push()

 You must resolve each verb phrase into one or more operations
on your candidate classes
 These operations must be distributed amongst the candidate
classes in a way that makes sense from a business perspective
 You may have to introduce new candidate classes to do this!

5.31
 Verb list
show the key points of the town
location lights up for 10 seconds
push the "print map" button
a hard copy map is released through the map slot
system keeps a tally of the number of printed maps requested
the machine runs out of paper
sign saying "Sorry, no printed maps available" is lit up
until an operator comes and restocks with paper
paper gets low (less than about 100 sheets)
internal "paper low" light illuminates
Restock with paper if necessary
Press the internal "test lights" button to illuminate all the lights for 1
minute
lights have burned out
operator replaces them
 We have to convert these verb phrases into
operations of the candidate classes
5.32
 Look for possible generalizations
LocationLight Light
turnOn() turnOn()
turnOff() turnOff()

NoPrintedMapsSign
turnOn() LocationLight PaperLowLight
turnOff()
NoPrintedMapsSign
PaperLowLight
turnOn()
turnOff()

 Classes that have attributes and operations in common might

be part of a generalization hierarchy
 Only use generalization in analysis if it improves the business semantics
of the model – this can be subjective!
5.33
Putting it all together
 The result of
this process is
what we call a
"first cut"
analysis class
diagram
 It's "first cut"
because there
is still more
analysis work
to be done!

5.34
9.2

What is a relationship?
 A relationship is a connection between
modelling elements
 In this section we’ll look at:
 Links between objects
 Associations between classes
 Aggregation These are essential in design,
not in analysis. They are not
 Composition covered in this module.
 Association classes

© Clear View Training 2010 v2.6 5.35

9.3

What is a link?
 Links are connections between objects
 Think of a link as a telephone line connecting you and a
friend. You can send messages back and forth using this link
 Links are the way that objects communicate
 Objects send messages to each other via links
 Messages invoke operations
 OO programming languages implement links as
object references or pointers. These are unique
handles that refer to specific objects
 When an object has a reference to another object, we say
that there is a link between the objects

© Clear View Training 2010 v2.6 5.36

9.3.1

Object diagrams
BookClub
 Paths in UML role name
chairperson
ila:Person

diagrams (lines to oblique secretary

you and me!) can be path
style
bookClub:Club erica:Person

drawn as object
link naomi:Person
orthogonal, oblique member

or curved lines BookClub chairperson

ila:Person
 We can combine
paths into a tree if orthogonal
bookClub:Club
secretary
erica:Person
path
each path has the style

same properties preferred naomi:Person

member

© Clear View Training 2010 v2.6 5.37

9.4

What is an association?
association
Club Person
links
«instantiate» «instantiate» «instantiate»
instantiate
associations
link
chairman
bookClub:Club jim:Person

 Associations are relationships between classes

 Associations between classes indicate that there
are links between objects of those classes
 A link is an instantiation of an association just as an
object is an instantiation of a class
© Clear View Training 2010 v2.6 5.38
9.4.1

Association syntax
association
employs name
Company 1
Person
multiplicity *
navigability

role names
employer employee
Company 1
Person
*

 An association can have role names or an association name

 It’s bad style to have both!
 The black triangle indicates the direction in which the association name is
read:
 “A Company employs many Persons”
© Clear View Training 2010 v2.6 5.39
9.4.2

Multiplicity
A Company employs many People

employer employee
Company Person
1 *
Each Person works for one Company

 Multiplicity is a constraint that multiplicity syntax: minimum..maximum

specifies the number of objects 0..1 zero or 1
that can participate in a 1 exactly 1
relationship at any point in time 0..* zero or more
 If multiplicity is not explicitly * zero or more
stated in the model then it is 1..* 1 or more
undecided – there is no default 1..6 1 to 6
multiplicity
© Clear View Training 2010 v2.6 5.40
 Multiplicity exercise
 How many Company
 Employees can a Company have? 1 employer

 Employers can a Person have?

 Owners can a BankAccount have? 7 employee

 Operators can a BankAccount have? Person

 BankAccounts can a Person have? owner 1 1..* operator
 BankAccounts can a Person operate?
0..* 0..*

BankAccount

© Clear View Training 2010 v2.6 5.41

9.4.2.1

Exercise
 Model a computer file system. Here
are the minimal facts you need:
 The basic unit of storage is the file
 Files live in directories
 Directories can contain other directories
 Use your own knowledge of a specific
file system (e.g. Windows 95 or UNIX)
to build a model

Hint: a class can have an association to itself!

© Clear View Training 2010 v2.6 5.42

9.4.2.1

Reflexive associations
subdirectory
0..* 1 0..*
Directory File
0..1
parent

reflexive association
autoexec
C
config

Windows My Documents Corel To John

Command

directories files
© Clear View Training 2010 v2.6 5.43
9.4.4

Associations and attributes

=
address
House Address House
1 1
address:Address

House pseudo-attribute attribute

address:Address

 If a navigable relationship has a role name, it is as though the source class has a pseudo-
attribute whose attribute name is the role name and whose attribute type is the target class
 Objects of the source class can refer to objects of the target class using this pseudo-attribute
 Use associations when:
 The target class is an important part of the model
 The target class is a class that you have designed yourself and which must be shown on the model
 Use attributes when:
 The target class is not an important part of the model e.g. a primitive type such as number, string etc.
 The target class is just an implementation detail such as a bought-in component or a library component
e.g. java.util.Vector (from the Java standard libraries)

© Clear View Training 2010 v2.6 5.44

9.4.5

Association classes
* employment *
Company Person

Each Person object can work for many Company objects.

Each Company object can employ many Person objects.
When a Person object is employed by a Company object, the Person has a salary.

But where do we record the Person’s salary?

 Not on the Person class - there is a different salary for each employment
 Not on the Company class - different Person objects have different salaries
 The salary is a property of the employment relationship itself
 every time a Person object is employed by a Company object, there is a salary

© Clear View Training 2010 v2.6 5.45

9.4.5

Association class syntax

Company * * Person

the association class

Job
consists of the class,
association class salary:double the association and the
dashed line

 We model the association itself as an association class. One instance of this

class exists for each link between a Person object and a Company object
 Instances of the association class are links that have attributes and operations
 Can only use association classes when there is one unique link between two
specific objects. This is because the identity of links is determined exclusively by
the identities of the objects on the ends of the link
 We can place the salary and any other attributes or operations which are
really features of the association into this class

© Clear View Training 2010 v2.6 5.46

9.4.5

Using association classes

If we use an association * *
class, then a particular
Company Person
Person can have only one
Job with a particular Job
Company
salary:double

If, however a
particular Person can
have multiple jobs 1 * Job * 1
with the same Company Person
salary:double
Company, then we
must use a reified
association
© Clear View Training 2010 v2.6 5.47
Analysis –
inheritance and polymorphism

© Clear View Training 2010 v2.6 5.48

10.2

Generalisation
 A relationship between a more general element and a more
specific element
 The more specific element is entirely consistent with the more
general element but contains more information
 An instance of the more specific element may be used where
an instance of the more general element is expected

Substitutability
Principle

© Clear View Training 2010 v2.6 5.49

10.2.1

Example: class generalisation

more general element parent

superclass
Shape base class
generalisation

ancestor
“is kind of”
child
specialisation

Square Circle Triangle subclass

descendent
more specific elements

A generalisation hierarchy
© Clear View Training 2010 v2.6 5.50
10.3

Class inheritance
 Subclasses inherit all features of Shape
origin : Point = (0,0)
their superclasses: width : int {>0}
 attributes height : int {>0}
draw( g : Graphics )
 operations getArea() : int
 relationships getBoundingArea() : int

 stereotypes, tags, constraints

 Subclasses can add new features
Circle
 Subclasses can override Square

superclass operations {width = height}

radius : int = width/2

 We can use a subclass instance

anywhere a superclass instance is But what’s
expected wrong with
Substitutability
Principle these subclasses
© Clear View Training 2010 v2.6 5.51
10.3.1

Overriding
Shape
draw( g : Graphics )
getArea() : int
getBoundingArea() : int

Square Circle
draw( g : Graphics ) draw( g : Graphics )
width x height getArea() : int getArea() : int p x radius2

 Subclasses often need to override superclass behaviour

 To override a superclass operation, a subclass must provide an
operation with the same signature:
 The operation signature is the operation name, return type and types of
all the parameters
 The names of the parameters don’t count as part of the signature
© Clear View Training 2010 v2.6 5.52
10.3.2

Abstract operations & classes

abstract class Shape
draw( g : Graphics ) abstract
getArea() : int operations
abstract class getBoundingArea() : int
and operation
concrete
names must be
in italics operations

Square Circle
concrete
classes draw( g : Graphics ) draw( g : Graphics )
getArea() : int getArea() : int

 We can’t provide an implementation for

Shape :: draw( g : Graphics ) or for
Shape :: getArea() : int
because we don’t know how to draw or calculate the area for a "shape"!
 Operations that lack an implementation are abstract operations
 A class with any abstract operations can’t be instantiated and is therefore
an abstract class
© Clear View Training 2010 v2.6 5.53
10.4

Polymorphism
A Canvas object has a collection of Shape objects
 Polymorphism = "many forms" where each Shape may be a Square or a Circle
 A polymorphic operation has Canvas
many implementations 1
 Square and Circle provide
implementations for the shapes *
polymorphic operations Shape
Shape::draw() and
draw( g : Graphics ) abstract
Shape::getArea() polymorphic
operations getArea() : int superclass
 All concrete subclasses of Shape getBoundingArea() : int
must provide concrete draw()
and getArea() operations
because they are abstract in the
superclass Square Circle
 For draw() and getArea() we
draw( g : Graphics ) draw( g : Graphics )
can treat all subclasses of
getArea() : int getArea() : int
Shape in a similar way - we
have defined a contract for concrete subclasses
Shape subclasses
© Clear View Training 2010 v2.6 5.54
10.4.1

What happens?
 Each class of object
has its own 1.draw()
s1:Circle
implementation of
the draw() operation 2.draw()
s2:Square
 On receipt of the :Canvas
draw() message, 3.draw()

each object invokes s3:Circle

4.draw()
the draw() operation
specified by its class
s4:Circle
 We can say that each
object "decides" how
to interpret the
draw() message
based on its class
© Clear View Training 2010 v2.6 5.55
10.4.1

BankAccount example
BankAccount
1 * withdraw()
Bank calculateInterest()
deposit()

ShareAccount CheckingAccount DepositAccount

withdraw() withdraw() withdraw()
calculateInterest() calculateInterest() calculateInterest()
deposit()

 We have overridden the deposit() operation even though it is not abstract.

This is perfectly legal, and quite common, although it is generally considered
to be bad style and should be avoided if possible

© Clear View Training 2010 v2.6 5.56

 Summary
 We have seen several ways to move from
use cases and requirements to analysis
classes:
 Noun verb analysis
 We have looked at relationships between
classes/objects:
 Associations
 Associations classes
 Inheritance

5.57
 Reading Material

 Jim Arlow’s book “UML 2 and the Unified Process:

Practical Object-Oriented Analysis and Design”
 Edition 2: Chapters 6 - 10.

5.58