Object Oriented

Analysis and Design

(OOAD)
M2I322952

Lecture 4
Class Modelling – Part 1
1
 Contents

Class diagrams
– Describe the use of the following relationships
• Association
–Multiplicity
–Naming
–Direction

– UML@Classroom – 4.2

2
 Main Purposes of Class Diagrams
• Used to document the classes that make up the system

• Show features of classes – attributes/operations

• Class diagrams show the static structure of the classes in the system

• Describe the associations & relationships between the classes

• Used throughout the software lifecycle

• Document how classes of a particular system interact with existing class

libraries

• Used to create Object Diagrams which show individual object instances

within the class structure
3
 Specifying Classes
• In Class Diagram
– Each class is given a name
– Singular noun
• Recommendation – multiple words joined; each word starting with a
capital letter (e.g. CarSharer)
• Meaningful
• Short (less than 30 characters)

• Class properties to be defined

– Attributes (initially those that capture interesting object states)
• Recommendation – small letters;
– Operations (can be delayed till later analysis stages or even till
design)

4
 Modelling an individual Class
Only class name Attributes
shown shown

Reservation
Reservation startDate
endDate

Both attributes & operations

shown
Reservation
Reservation
calculateBill() startDate
endDate
calculateBill()
Operations shown
5
 Standard Notation: Classes

BankAccount
Class name

Balance
Interest Rate
Attributes Review Date
Name
CreditAccount()
DebitAccount()
Operations OpenAccount()
CloseAccount() 6
Attribute Type - Java

7
 Attributes of a Class
Attribute type

Reservation
Attribute
visibility
-reservationNumber: integer
-guest: Customer
-roomNumber: integer
-startDate: Date
-endDate: Date
Attribute
name
+calculateBill()
8
 Encapsulation
• Objects are able to collaborate through behaviour and
attributes which are public

• Objects can also have behaviour and attributes which are

private

• These are for the object itself to use in performing its

responsibilities

• Public behaviour may modify private attributes or use

private behaviour

• Collaborating objects do not need to know about these

 Visibility of Attributes & Operations
(Encapsulation)
UML@Classroom – 4.2.5

• Relates to its availability to other classes

– Private (-) : feature is available only within the class that
owns that feature

– Public (+) : feature is available to any class associated with

the class that owns that feature

– Protected (#) : feature is available within the class that

owns that feature and any subtype of the class
10
 Valid Attributes Notation
Attribute
multiplicity

Reservation

-reservationNumber: integer
-guest: Customer
-roomNumber[0. . 20]: integer
-startDate: Date = today
Derived Attribute -endDate: Date
(the value can be -/lengthOfStay: integer
derived from other Default
attributes) value
Indicated using +calculateBill()
forward slash (/)
11
 Valid Operation annotation
parameter type
Operation return type

+getCustomerName(): String
+calculateBill(): double
Visibility +setStartDate(stayStart:Date=today)
Private(-)
Public(+)
Protected(#)

parameter name default parameter value

12
 Example

Reservation

-reservationNumber: integer
-guest: Customer
-roomNumber[0. . 20]: integer
-startDate: Date = today
-endDate: Date
-/lengthOfStay: integer

+getCustomerName(): String
+calculateBill(): double
+setStartDate(stayStart:Date=today)
13
 Class Modelling

• Should be approached iteratively with Use Case

Modelling

• Candidate classes emerge from our understanding of

use cases

• Also, expect knowledge of use cases to develop as a

result of class modelling

14
 Example of a diagram of a single class

Customer

-lastname: string
-firstname: string
-dateOfBirth: Date
-/age: integer

+ isPensioner(): boolean

On the next slide a class diagram with multiple classes 15

 Order Customer
-cust : Customer
-dateReceived : Date * 1 -name: String
-isPrepaid : Boolean -address : Address
-number : String

+dispatch()
+close()

1 .. *
Order Line

-quantity : Integer
-price : Money Company Customer Personal Customer

contactName creditCardType
* creditRating creditCardNumber
creditLimit

1
Product Note that these classes are incomplete. They
would have more attributes and operations,
16
but for space reasons only a sample is given
 Relationships

• Exist between classes and are shown using lines

or arrows

• Two main types of static relationships are-

– Association (a customer places an order)
– Subtypes (a nurse is a type of employee)

17
 Associations
UML@Classroom – 4.2.5
• Associations represent relationships between instances of a class (i.e. between
objects).
• In a running object-oriented programming, messages are passed and received
to and from instances (objects) of the classes in the system.
• Where instances of one class pass messages to instances of another class, an
association is implied between those two classes.

Customer Order

Although the commonest associations are between 2 classes (binary

associations), higher order associations can be drawn with more than 2
ends. In such cases the ends are connected to a central diamond
18
 Associations - Multiplicity
Multiplicity indicates how many objects participate in a given relationship.
The multiplicity of an association-end indicates the potential number of
objects at that end of an association, which may be linked to a SINGLE object
at the OPPOSITE end of the association.

0 to many

Customer 1 * Order

The next slide explains how this relationship should be read

19
 Associations - Multiplicity
The multiplicity of an association-end indicates the potential number of
objects at that end of an association, which may be linked to a SINGLE object
at the OPPOSITE end of the association.

ONE

Customer 1 * Order

ONE

In this example – the arrows indicate how this relationship should be

read in both directions ( Always start description with ‘ONE’ ):
ONE Customer can have zero, one, or many Orders 20
ONE Order can only have one Customer
 Associations - Multiplicity
Notes:
 Multiplicity can be a single number or a range

 A range is shown <lowest> .. <highest> (e.g. 1 .. 5 or 4 .. 6)

 on its own, * is short for 0 .. * (zero to many – no upper limit)

 If there can be any number of an object associated with

another, but there must be at least 1, this would be written
1..*

 Some books say that * means infinity. This is confusing. * just

means that no upper limit has been specified. 21
 Associations - Multiplicity
 In all the associations in the class diagrams in the previous slides the
multiplicity at one of the ends (and sometimes both ends) is 1. This does
not need to be the case. This does not change the definition already given
and repeated below:
“The multiplicity of an association-end indicates the potential number
of objects at that end of an association, which may be linked to a
single object at the other end of the association.”

Customer 1 .. 3 * Order

In this example :
ONE Customer can have zero, one, or many Orders
ONE Order can only have one, two or three Customers
22
To keep this example simple - Shows Multiplicity from ‘A to B’ ONLY
….. NOT ‘B to A’ ( but MUST always be shown in ALL class Diagrams
1 One A is always associated
A B
with one B
1..*
A B One A is always associated
with one or more B
0..1
A B One A is associated with
zero or one B

* One A is associated with

A B
zero, one or more B

5..* One A is always associated

A B
with 5 or more B 23
Class Diagram

24
 Associations can be named
An association can be labeled with a name to indicate the nature
of the association.
 The name must start with a capital
 The name should be a verb or a verb phrase
 There should be a filled-in arrowhead to indicate the direction in which
the text name should be interpreted.

Customer 1 Places * Order

One Customer Places zero, one or more Orders

Note: Labeling (naming) of associations is not essential, and can

just clutter up diagrams. In the above case the name is not really
needed as the meaning of the association is fairly obvious 25
 Associations have direction
UML@Classroom – 4.3.1

The direction of an association indicates the source and target

class of the association. Or, thinking of it another way, if we can
we navigate from class A to class B, then A is the source class
and B is the target class. Let’s consider the Customer Order
association
1 *
Customer Order

The above diagram implies that:

An Order class will have as one of its attributes a Customer.
So, if we know an Order object, we can get to a Customer object.
However the converse is not the case – the Customer class does not have
an Order, or collection of Orders, as one of its attributes – so if we know a
Customer object we would be unable to, directly, get to an Order. 26
 Associations have direction
An association can be bidirectional, meaning that code can navigate in both
directions. If the above association were bidirectional it would mean that a
Customer object held information about any Order it had placed, while an
Order object still had as one of its attributes a Customer.
 A bidirectional association is shown by either
having an arrow at each end of the association

Customer 1 * Order

or
having no arrows (however having no arrows can also mean that the
diagram is not showing navigability)

Customer 1 * Order

27
From Programming 1

28
From Programming 1

29
From Programming 1

30
 Generalisation (Inheritance)
• This will covered in greater detail next week
• Generalisation is the other form of relationship, in
class diagrams, that we’re going to look at.
• In object-oriented programming this is usually
referred to as inheritance.
• The UML refers to it as Generalisation.
• It is where one class is a specialized form of another
– sometimes referred to as a “kind of” relationship.
31
 Generalisation in “Employee” class
Employee

-employeeNo
-lastName
-firstName
-address

+getsalary()
+calculateLeaveLeft()

Salesperson Engineer Administrator

-area -qualifications -adminArea
-carregNo -project -alternative
+calculateLeaveLeft() +calculateLeaveLeft() +calculateLeaveLeft()
32
+calcSalesForMonth() +addQualification() +changeAdminArea()
 Tutorial Exercise
• Exercise 1 - To be done for next week :

• A University Department wants to computerise some of its systems.

Draw an initial class diagram for a system that represents the scenario
given below.
 
• The Department offers 4 undergraduate courses. Each course is
composed of between 12 and 24 modules. A module can be used
by any number of courses. ……..
• Every module has an academic as its leader. An academic can
lead up to 3 modules. There are three types of academic – lecturer,
senior lecturer & professor. Each student can be registered for
between 1 & 5 modules, and a module must have at least 6
students registered to it.

33
 Partial Sample Solution

Department 1 4
Course

1 .. *

12..24

Module

34