1. Class Diagrams using UML
Object-Oriented Software Systems Engineering – Chapter 4 Slide 1
2. Objectives
In this chapter we will:
Introduce class diagram notation
Discuss how to identify problem domain classes
Discuss the different relationships which exist
between classes
Introduce the concept of an Interface
Object-Oriented Software Systems Engineering – Chapter 4 Slide 2
3. Class Diagram
- order processing (Association with navigability
adornments)
Order Customer
{persistent} {persistent}
dateReceived * belong to 1
isPrepaid name : Name
number : String address : String
price : Money creditRating() : String
dispatch()
close()
1
{if Order.customer.creditRating is
“poor” then Order.isPrepaid
Must be true} Corporate Customer Personal Customer
{persistent} {persistent}
contactName
has
creditCard#
creditRating
creditLimit
remind()
* billForMonth(bn : Integer)
OrderLine
{persistent}
quantity : Integer
refer to 1
price : Money *
isSatisfied : Boolean Product
Object-Oriented Software Systems Engineering – Chapter 4 Slide 3
4. Class Diagrams
Purpose
model the static view of a system
how they are related, but not how they interact to
achieve particular behaviour
model static relationships between classes
association and generalisation are the two
principal kinds of relationships
Scope
abstraction : the key domain class
only the aspects of the domain which are important
to the application
a class should be named using the vocabulary of the
domain
Object-Oriented Software Systems Engineering – Chapter 4 Slide 4
5. Static Modelling - Class
Class
name
attributes - describe characteristics of the objects
operations - used to manipulate attributes and to perform
other actions
Attribute
has type - which tells what values the attribute can take
visibility - tells whether the attribute is visible and can be
referenced from classes other than the one in which it is
defined (private, public, protected)
may have a default value - assigned at the time an object
of the class is created
Object-Oriented Software Systems Engineering – Chapter 4 Slide 5
6. Static Modelling - Class
Operations (methods)
a function defined within a class and can be only applied
to the objects of that class
describe what any object of the class can do
describe the interface to the class - what the class can do
and what services it offers
signature, visibility, scope
Object-Oriented Software Systems Engineering – Chapter 4 Slide 6
7. O-O Concepts Messages and Methods
Objects perform work when sent messages
Messages are sent to objects to invoke their behaviour
(methods)
For example a Customer object could sent a message to a
pump to start pumping
Methods are the implementation of the behaviour
invoked when a message arrives
they only have access to an objects attributes (data)- unless
data attributes are declared as static
Object-Oriented Software Systems Engineering – Chapter 4 Slide 7
8. O-O Concepts Messages and Methods
Methods are defined by their signature
visibility(public,private,protected,default)
return type
method name
method parameters
Different methods can have same name but a different
parameters,these will decide which method is invoked at
runtime (method overloading)
Object-Oriented Software Systems Engineering – Chapter 4 Slide 8
9. O-O Concepts Full Class UML Notation
Frame name
Underlining
denotes static
Header : FrameHeader
- FrameID : Long attributes
private - encrypt()
protected # setCheckSum()
operations
public + addMessage(m : Message) : Status
signature
Object-Oriented Software Systems Engineering – Chapter 4 Slide 9
10. Static Modelling Association - Relationships
Association
relationship that describes a set of links
class A and class B are associated if
an object of class A sends a message to an object of
class B
an object of class A creates an object of class B
an object of class A has an attribute whose values are
objects of class B or collections of objects of class B
an object of class A receives a message with an object
of class B as an argument
Multiplicity
a range that tells how many objects are linked
placed near the class it is applicable to
ranges : n..m 0..1 0..* 1..* 2 1,2,4,8
Object-Oriented Software Systems Engineering – Chapter 4 Slide 10
11. An Example of Association
Car Person
owns
model company car driver name
0..* 1..*
opname() opname()
Multiplicity Role Name
Name Role
indicates the role played by
verb/noun from a problem domain
the class in terms of
association placed near the
class it applies to
Object-Oriented Software Systems Engineering – Chapter 4 Slide 11
12. Static Modelling – Normal Association
If an association is only ever used in one direction
it can be labeled with an arrow head at the end
<<control>>
<<boundary>>
PumpControl
Nozzle
In
triggers
out
start
stop
Object-Oriented Software Systems Engineering – Chapter 4 Slide 12
13. Static Modelling Generalization Relationship
Generalization
relationship between a general thing
(superclass or parent) and a more specific kind
of that thing (subclass of child)
the child will inherit all the structure and
behaviour of the parent
the child may add new structure and behaviour
or it may modify the behaviour of the parent
the child is substitutable for the parent
Object-Oriented Software Systems Engineering – Chapter 4 Slide 13
14. Examples of Generalisation
A taxonomic relation between a more general and
a more specific element
The more specific element
is fully consistent with the more general
contains additional properties
The relationship between the classes is
inheritance
the specific class inherits everything (attributes,
operations, relations) from the general class
Object-Oriented Software Systems Engineering – Chapter 4 Slide 14
15. An Example of Generalisation
Customer
name
address
creditRating():String
Corporate Personal
Customer Customer
contactName creditCard#
creditRating
creditLimit
remind()
billForMonth(Integer)
Object-Oriented Software Systems Engineering – Chapter 4 Slide 15
16. An Example of Generalisation
Vehicle
Boat
Car
SportCar Truck MotorBoat SailingBoat
Object-Oriented Software Systems Engineering – Chapter 4 Slide 16
17. Static Modelling Aggregation with
examples
Aggregation indicates that a relationship between
the classes is "whole-part”.
• Shared aggregation
the parts may be parts of many wholes
Membership
club member
Team Person
0..* 1..*
Car
• Composition aggregation
strong ownership - the whole owns the parts,
the part lives inside the whole 4
Wheel Engine
Object-Oriented Software Systems Engineering – Chapter 4 Slide 17
18. Static Modelling - Aggregation
Aggregation indicates that a relationship between
the classes is "whole-part”
Shared aggregation – the parts may be parts of
many wholes
Membership
club member
Team Person
0..* 1..*
Object-Oriented Software Systems Engineering – Chapter 4 Slide 18
19. Static Modelling - Aggregation
Composition aggregation
Strong ownership
The whole owns the parts; the parts live inside the whole
Car
4
Wheel Engine
Object-Oriented Software Systems Engineering – Chapter 4 Slide 19
20. Identification of Classes
Noun identification technique
This technique involves two stages:
Select all the nouns and noun phrases in a
requirements specification of the system as
candidates for classes
Discard candidate which are inappropriate for any
reasons
How do we decide which are inappropriate?
Object-Oriented Software Systems Engineering – Chapter 4 Slide 20
21. Discarding Candidate Classes
Candidates may be inappropriate for many reasons:
redundant : the same class is given more than one name
vague : cannot tell unambiguously what is meant by a noun
an event or an operation : where noun refers to something
which is done to or by the system
an attribute : where the noun refers to something simple
with no interesting behaviour
meta-language : where the noun forms part of the way we
define things (e.g., requirements, system)
outside the scope of the system : where the noun is relevant
to describing how the system works but does not refer to
something inside the system
Object-Oriented Software Systems Engineering – Chapter 4 Slide 21
22. Identifying Classes for a Library
Consider the following example
A library contains books and journals. It may have
several copies of a given book. Some of the books
are for short term loans only. All other books may
be borrowed by any library member for three
weeks. Members of the library can normally
borrow up to six items at a time, but members of
staff may borrow up to 12 items at one time. Only
members of staff may borrow journals.
Object-Oriented Software Systems Engineering – Chapter 4 Slide 22
23. LibraryMember Copy of Book Book
{persistent} {persistent} {persistent}
CopyID: int
0..1 0..* MemberID : Object 1..* 1 Title: String
Publisher: String
LoanTime: int Author: String
ISBN: int
borrowed()
TotalCopies: int
returned()
AvailabelCopies: int
updateAvaCopies()
reservedCopy() addBook ()
removeBook()
findBook()
borrowable()
Journal
{persistent}
MemberOfStaff
{persistent}
0..1 0..*
addJournal ()
removeJournal(
)
findJournal()
Object-Oriented Software Systems Engineering – Chapter 4 Slide 23
24. Examples of Class Diagrams
On the next two slides examples of class diagrams
are given
One relating to course management
The other relating to order processing
Study the diagrams to see if you can understand
them
Object-Oriented Software Systems Engineering – Chapter 4 Slide 24
25. School Department
{persistent} {persistent}
Chairperson
name : Name name : Name 0..1
has
address : String address : String
PhoneNo : Number PhoneNo : Number
1 1..* 1..*
addStudent() addStaff
removeStudent() removeStaff
getStudent() getStaff
getAllStudent() getAllStaff
addDepartment()
removeDepartment() 1..*
assigned to
getDepartment()
getAllDepartment()
own
1..*
1..*
member
Course 1..* 0..1
{persistent} Academic Staff
* name : Name
Student {persistent}
courseID : Number
{persistent} attends teaches name : Name
addCourse
name : Name 1..*
updatCourse *
studentID : Number * * getCourse
Object-Oriented Software Systems Engineering – Chapter 4 Slide 25
26. School Department
{persistent} {persistent}
Chairperson
name : Name name : Name 0..1
has
address : String address : String
PhoneNo : Number PhoneNo : Number
1 1..* 1..*
addStudent() addStaff
removeStudent() removeStaff
getStudent() getStaff
getAllStudent() getAllStaff
addDepartment()
removeDepartment() 1..*
assigned to
getDepartment()
getAllDepartment()
own
1..*
1..*
member
Course 1..* 0..1
{persistent} Academic Staff
* name : Name
Student {persistent}
courseID : Number
{persistent} attends teaches name : Name
addCourse
name : Name 1..*
updatCourse *
studentID : Number * * getCourse
Object-Oriented Software Systems Engineering – Chapter 4 Slide 26
27. Order Customer
{persistent} {persistent}
dateReceived * belong to 1
isPrepaid name : Name
number : String address : String
price : Money creditRating() : String
dispatch()
close()
1
Corporate Customer Personal Customer
{persistent} {persistent}
contactName
has
creditCard#
creditRating
creditLimit
remind()
* billForMonth(bn : Integer)
OrderLine
{persistent}
quantity : Integer
refer to 1
price : Money *
isSatisfied : Boolean Product
Object-Oriented Software Systems Engineering – Chapter 4 Slide 27
28. Realisation
A semantic relationship between classifiers in
which one classifier specifies a contract that
another classifier guarantees to carry out
semantically a cross between a dependency and
generalisation
used in two cases
Use case collaboration
realizes Order
Place order
management
<<interface>>
UserInterface realizes
Bank Account
Object-Oriented Software Systems Engineering – Chapter 4 Slide 28
29. Realizing use cases - Relationship
Realized in a collaboration
shows an internal implementation dependent solution of
a use case in terms of classes & their relationships
<<realizes>>
Collaboration
Use Case
<<implements>>
<<implements>>
<<implements>>
Use case description: Class A Class B Class C
1. Insert the coins
2. Choose a drink
3. Deliver a drink Oper1() Oper1() Oper1()
4. E.t.c Oper2() Oper2() Oper2()
Oper3() e.t.c Oper3() e.t.c Oper3() e.t.c
Object-Oriented Software Systems Engineering – Chapter 4 Slide 29
30. Interfaces in UML
• UML has a short hand notation for representing
interfaces but does not show the methods
associated with the interface
BankAccount
AccountHolder 1 name:String BankEmployee
1..* 1..* 1
balance:Currency
has accountNo:String looksAfter
credit(Amount:double)
debit(Amount:double)
suspend()
chargeFee(Amount:double)
getBalance();double
UserInterface
interface administers
Object-Oriented Software Systems Engineering – Chapter 4 Slide 30
31. Interfaces in UML
• A more detailed representation
<<interface>> realises BankAccount
UserInterface
name:String
credit(Amount:long) balance:long
debit(Amount:long) accountNo:Int
getBalance():long
credit(Amount:long)
debit(Amount:long)
<<uses>> dependency
suspend()
1 1..* chargeFee(Amount:long)
AccountHolder getBalance();long
has
Object-Oriented Software Systems Engineering – Chapter 4 Slide 31
32. Dependencies - relationship
Dependency is a using relationship
a change in one thing may effect another
shown as a stereotype e.g. friend
one class takes an object of another class as a parameter
one class accesses a global object of another class
one class calls a class scope method in another class
<<friend>>
Example Class A Class B
friend
specifies that source is given special visibility into the target
instanceOf
source object is an instance of the target classifier
instantiate
source creates instances of the target
Object-Oriented Software Systems Engineering – Chapter 4 Slide 32
33. Summary
In this chapter we have:
Introduced class diagram notation
Discussed how to identify problem domain
classes
Discussed the different relationships which exist
between classes
Introduced the concept of an Interface
Object-Oriented Software Systems Engineering – Chapter 4 Slide 33