Lecture 6

Object oriented
modelling and use cases
11486 Systems Analysis and Modelling
6677 Systems Analysis and Modelling G
Dr Luke Nguyen-Hoan
This session will be recorded
Contents
Administration
1. Object oriented modelling
2. Use cases
3. Syntax and semantics
Textbook chapters:
4. Guidelines Systems Analysis and Design
Chapter 10 Object-Oriented Systems Analysis and Design Using UML* > Use Case Modeling
5. Use case descriptions UML@Classroom, An Introduction to Object-Oriented Modeling
Chapter 1 Introduction
6. Where are the objects? Chapter 3 The Use Case Diagram

All images under the Creative Commons Attribution licence or in the public domain unless otherwise stated
 Administration

Computer problems
Image by Randall Munroe
https://xkcd.com/722/
Tutorials
Don’t forget that tutorials are assessed (1% each, best 10 or 11)
Assessment – Quiz 3 for UG students
The third quiz opens right after this lecture, and is due at 11:59pm on Sunday
Assessment – Assignment 2 - Group
This is due at the end of week 9

Full information is in the assignment instructions available on Canvas, including the

following group formation information
Groups should be set by the start of week 7 using self-signup on Canvas
Groups for the group assignments
Choosing a group for the assignment (before Monday Week 7 – next week)
To sign up for a group on Canvas, follow the instructions here:
https://community.canvaslms.com/docs/DOC-10516
Self sign up for groups will be closed on the day listed above. If you have any issues
with sign up or your group composition, please contact the unit convener as soon as
possible. The longer you delay, the less that can be done to resolve any issues!
Groups for the group assignments
Groups for this assignment are limited to a maximum of 4 students per group, with no
exceptions. Please note that this assignment is intended for groups of 3-4 students, so
students in groups smaller than 4 students should expect that more effort and time is
required to accomplish equivalent grades. No consideration will be given for groups
comprising less than 3 students.
Undergraduate students (11486) should form a group with other undergraduate
students only, in the “11486 Undergraduate Groups” set.
Graduate students (6677) should form a group with other graduate students only, in
the “6677 Graduate Groups” set.
Make sure your group is in the correct group set, or your marks won’t be allocated
properly (and you might be penalised marks when I have to fix it as per the late group
change penalty).
Groups for the group assignments
Note that there is no requirement for all group members to be in the same tutorial–
you may form a group with friends from other tutorials if you wish. However, it may
be easier for you to coordinate and work together if you form a group with other
people in your tutorial.
It is each student’s responsibility to organise their group – the tutors and unit
conveners will not assist you in finding or joining a group. You may wish to use the
Canvas Discussion forums to help find a group.
If there are no empty groups remaining for the case study that your group has
chosen, email the unit convener and additional groups will be added.
Groups for the group assignments
Groups finalised for the assignment – Monday Week 8
This is just under two weeks prior to the assignment due date, and thus by this point
everyone should now be in groups and have organised to complete the assignment
with their peers.
Any students not in a group by this date will be assumed to be completing the
assignment individually, and will thus be placed into a group of 1 student only.
Groups for the group assignments
Groups finalised for the assignment – Monday Week 8
Any changes requested after this date will result in a mark penalty of 10% of the
available marks for the students involved
This deadline is imposed as changes to group allocations after assignments have
started to be submitted can cause issues with Canvas submissions and grading, so
groups need to be finalised in advance of any assignments being submitted.
This mark penalty will apply for only the students whose group allocations are
changed – for example, if one student changes from one group to another, only that
student will receive the mark penalty. Other students in both groups whose group
allocates are not changed will not be penalised.
The mark penalty may also apply if your group is in the wrong group set (11486
Undergraduate Groups or 6677 Graduate Groups) and I have to fix it later!
Questions?
Any questions about the unit before we get into this week’s topic?
Assessment
Tutorials
Anything else?
I know this is tiny
– there’s a bigger
version on the
Canvas site
I know this is tiny
– there’s a bigger
version on the
Canvas site
1. Object
oriented
modelling
a) Big picture
b) Object oriented modelling
c) Unified modelling language
(UML)
Big Picture

Diagram from Systems

Analysis and Design in a
Changing World, J. Satzinger,
R. Jackson, S. Burd.
Used with permission.
Object oriented modelling
Also known as “OO modelling”
Views a system as a collection of
objects, classes of objects, and how
these objects function and interact
Object oriented analysis developed
out of object oriented
programming and design
Unified modelling language (UML)
UML is a standard for object
oriented modelling
Developed in 1995
Managed by the Object
Management Group (OMG)
Unified modelling language (UML)
UML uses a defined set of symbols
to graphically represent
components and relationships in a
system
A graphical model
https://www.omg.org/spec/UML
(last accessed 03/09/2019)
Unified modelling language (UML)
Structure diagrams Behaviour diagrams Interaction diagrams

• Describe parts of • Describe how the • Describe how parts

the system and how system acts or what of the system talk
they link together it does in certain and communicate
circumstances with each other
Unified modelling language (UML)
Structure diagrams Behaviour diagrams Interaction diagrams

• Describe parts of • Describe how the • Describe how parts

the system and how system acts or what of the system talk
they link together it does in certain and communicate
circumstances with each other

Comparable data-oriented models:

Unified modelling language (UML)
Structure diagrams Behaviour diagrams Interaction diagrams

• Describe parts of • Describe how the • Describe how parts

the system and how system acts or what of the system talk
they link together it does in certain and communicate
circumstances with each other

Comparable data-oriented models:

Entity-Relationship Process specifications Dataflow Diagrams (DFDs)
Diagrams (ERDs)
Event tables Context diagrams
Algebraic data dictionaries
Unified modelling language (UML)
Structure diagrams Behaviour diagrams Interaction diagrams

• Class • Use case • Sequence

• Object • Activity • Communication
• Component • State machine • Timing
• Composite structure • Interaction overview
• Package
• Deployment
Unified modelling language (UML)
Structure diagrams Behaviour diagrams Interaction diagrams

• Class • Use case • Sequence

• Object • Activity • Communication
• Component • State machine • Timing
• Composite structure • Interaction overview
• Package
• Deployment
 2. Use cases
a) Use cases
b) Purpose
c) Example

A UML Use Case diagram

Image by user:Slashme
Use cases
Use cases
An activity that the system
performs
Usually in response to a request by
a user (actor)
Starts to define functional
requirements
Purpose
A use case diagram provides a
graphical summary of the
functional requirements
Shows use cases and actors and
how they are related

A UML Use Case diagram

Image by user:Slashme
Purpose
There can be multiple use case
diagrams for a system, particularly
if the system is large enough that all
the use cases won’t fit on a single
page
Each use case diagram can show a
particular part of the system, for
example:
By subsystem
By actor

A UML Use Case diagram

Image by user:Slashme
 Example

Use case model of a restaurant business

Image by user:Kishorekumar 62
Redrawn by Marcel Douwe Dekker
3. Syntax and
semantics
a) Syntax (notation)
b) Actors
c) Use cases
d) Relationships
e) Generalisation
f) System boundary
Syntax (notation)
Use case
<<include>>
Use case
<<extend>>
Actor
Relationships

Generalisation
System boundary
Actors
Actors are users or user roles that exchange information with the system
Can be external systems as well
Outside the system boundary

Actor
Actors
Actors are users or user roles that exchange information with the system
Can be external systems as well
Outside the system boundary

Actor Have a descriptive name, usually a noun

Can often be identified from stakeholders, event sources, and event
destinations
Bank customer
Use cases
Use case

Use case
Use cases describe how actors interact with the system
Each use case is a single interaction, capturing it from start to end
Use cases
Use case

Use case
Use cases describe how actors interact with the system
Each use case is a single interaction, capturing it from start to end Withdraw
Money

Have a descriptive name, often verb + noun

Can often be identified from events and processes
Relationships
Relationships link actors and use cases, indicating an actor is
involved in a use case
<<include>>
Withdraw
Money
<<extend>>

Relationships
Bank customer
This is one of those rare cases where you can have a line without a
label, but you might label it to clarify the role the actor plays in the
use case (particularly if a use case has multiple actors and roles)
Relationships
Includes and extends relationships are between use cases

Submit Select <<include>>

order <<include>> product

<<extend>> <<extend>>

Relationships
Join
mailing list
Relationships - includes
Includes and extends relationships are between use cases
Includes relationships
are where a use case Submit Select <<include>>
explicitly incorporates order <<include>> product
the included use case
<<extend>> <<extend>>
Submit order includes
Select product Relationships
Join
Submit order may use mailing list
the functionality of
Select product
Select product can be included in multiple other use cases
Relationships - extends
Includes and extends relationships are between use cases
Extends relationships
are where there are Submit Select <<include>>
optional use case order <<include>> product
version(s) of a base use
case <<extend>> <<extend>>

Join mailing list is an Relationships

option in addition when Join
Submit order mailing list

Submit order still makes sense without Join mailing list

Join mailing list may or may not make sense by itself
Generalisation
Generalisation is used between actors and
other actors, or use cases and other use cases
Bank customer
A specialised item inherits behaviour and
relationships from the general item
Also known as inheritance

New customer Existing customer

Generalisation
Generalisation
New customer and Existing customer are
specialised versions of the generalised Bank
customer actor Bank customer
New customer and Existing customer inherit
behaviour and relationships from the Bank
customer actor

New customer Existing customer

Generalisation
Generalisation
Withdraw money and Deposit money are Account
specialised versions of the generalised transaction
Account transaction use case
Withdraw money and Deposit money inherit
behaviour and relationships from the Account
transaction use case
Withdraw Deposit
money money

Generalisation
Generalisation
Specialised items such as Withdraw money Account
and Deposit money are also known as transaction
subtypes or child types (sub use case or child
use case in this example)
Generalised items such as Account transaction
are also known as supertypes or parent types
(super use case or parent use case) Withdraw Deposit
money money

Generalisation
System boundary
System boundary (like previous boundaries we’ve discussed) separates what’s inside
the ICT system with what is outside the ICT system
Where do each of these fit? Inside or outside the system boundary?
Use cases
Actors
Relationships
Generalisation

System boundary
Use case diagram notation
Use case
<includes>
Use case
<extends>
Actor
Relationships

Generalisation
System boundary
Putting it all together…
System boundary
 Actors

Bank manager

New customer

Existing customer
 Convention is that actors external to the organisation go on the left,
actors internal to the organisation go on the right, but this is only
Actors convention and not an actual rule.

Bank manager

New customer

Existing customer
 List

Use cases
account
options

Change
Create Bank manager
account interest
rate

Create new
customer

New customer

Withdraw Deposit
money money
Existing customer
 List

Relationships
account
options

Change
Create Bank manager
account interest
rate

Create new
customer

New customer

Withdraw Deposit
money money
Existing customer
 List

Generalisation
account
options

Change
Create Bank manager
account interest
rate
Bank customer
Create new
customer

Account
transaction
New customer

Withdraw Deposit
money money
Existing customer
 Includes and List
account

Extends options

Change
Create Bank manager
account interest
rate
Bank customer
<<include>>
Create new
customer
View
balance
Account
transaction
New customer <<extend>>

Withdraw Deposit
money money
Existing customer
 Use case List
account

diagram options

Change
Create Bank manager
account interest
rate
Bank customer
<<include>>
Create new
customer
View
balance
Account
transaction
New customer <<extend>>

Withdraw Deposit
money money
Existing customer
 Use case List
account

diagram options

Change
Create Bank manager
account interest
rate
Bank customer
<<include>>
Create new
customer Of course, you don’t have
View to strictly follow this order
balance
Account
transaction
Often, you will go back
New customer <<extend>>
and forth while identifying
actors, use cases,
relationships, and
Withdraw Deposit generalisations
money money
Existing customer
4. Guidelines
a) Level of abstraction
b) Techniques
Level of abstraction
Manage
account

Change Change
account interest
details rate

Select
account
Level of abstraction
Probably too high (too abstract) – who does this
Manage action, and what is involved? It’s not clear from the
account
name.

Change Change
account interest Probably about right – can be linked to specific
details rate actors

Select Probably too low (not abstract enough) – is this

account level of detail really needed for analysis?
Although “Select account” may be used as an included use
case to indicate that when you change account details or
interest rate, you have to select an account to apply it to
Identifying use cases
1. User goal identification
2. Event decomposition technique
3. Coverage using CRUD (Create,
Read, Update, Delete/Archive)
User goal identification
Most commonly used
Identify categories of users of the
system
(stakeholder analysis!)
Identify use cases for each category
of user
Through interviews, direct observation,
participant observation, etc…
Don’t forget to assume perfect
technology
Event decomposition technique
Each event identified (from the
event table) will probably (but not
always) correspond to a use case
Yes, even temporal and state events
– remember that the relationship
between actors and use cases is for
involvement, not just initiating or
starting a use case
Again, don’t forget to assume
perfect technology
 Example

Use case model of a restaurant business

Image by user:Kishorekumar 62
Redrawn by Marcel Douwe Dekker
 5. Use case
descriptions
a) Further describing use cases
b) Example

Keywords to describe digital objects

Image by Cambodia4kids.org Beth Kanter from flickr.com
Further describing use cases
Use cases should have short,
concise names (as you have to
include them in a large diagram)
Thus, use cases can be further
described to clarify the role and
purpose of a use case
Because use case descriptions take
time to develop, in this unit we only
do use case descriptions for
selected use cases
Further describing use cases
Use case descriptions can help
with:
Clarifying what actually happens in
a use case
Describing to others what a use
case involves
Information for future
implementation and testing
Further describing use cases
Use case descriptions can follow
this template:
Use case name
Short description
Precondition
Postcondition
Error situations
System state in the event of an error
Actors
Trigger
Standard process
Alternative processes
Further describing use cases
Use case descriptions can follow
this template:
Prerequisites for successful execution
Use case name
Short description
Precondition System state after successful execution
Postcondition
Error situations
System state in the event of an error Events that initiate or start the use case
(different from event table triggers)
Actors
Trigger
Step by step instructions of the use case in normal operation
Standard process
Alternative processes
Alternative steps from the standard process
Example
Use case name Withdraw money Trigger Existing customer requests to withdraw
Short description An existing customer withdraws money
money from their bank account Standard 1. Existing customer selects one of their
Precondition Customer has an active account process accounts
Customer identify has been 2. Existing customer specifies amount to
verified be withdrawn
3. System confirms the account has
Postcondition Money is provided to the sufficient funds
customer and account balance 4. System reduces account funds by the
is reduced by the same amount amount
Error situations There is not enough money in 5. System provides existing customer
the account with the money
System state in the No change in account balance Alternative 3’. Account does not have sufficient funds
event of an error processes 4’. System proposes a different account
Actors Existing customer 5’. Existing customer selects different
account and confirms withdrawal
 6. Where are the
objects?
a) Objects
b) Classes
c) From programming
d) When will we get to them?

Lenticular cloud (sometimes mistaken for a UFO, by non-expert observers)

Image by user:Stahlkocher
Objects
An object is something that has at
least one of:
Identity
State
Behaviour
(In many cases, has all three)
Objects can be physical or
conceptual
Classes
A class is a set of objects that have
the same type of properties, state,
and/or behaviour
From programming
If you’ve learnt about classes and
objects from programming, in
analysis we mostly consider the
public interfaces of classes and
objects, as these are what drive
interaction and behaviour
Some elements that are commonly
programmed as private are still
included in object-oriented analysis
(mostly variables that when
implemented may not be directly
accessed)
When will we get to them?
We’ll talk more about classes and
objects next week when we cover
UML class diagrams
When will we get to them?
We’ll talk more about classes and
objects next week when we cover
UML class diagrams
Objects perform (parts of) use
cases
Actors might also be analysed as
objects later on
1. Object oriented modelling
Views a system as a collection of
objects, classes of objects, and how
these objects function and interact
2. Use cases
An activity that the system performs
3. Syntax and semantics
Use cases are related to Actors
Recap
Textbook chapters:
Systems Analysis and Design
Chapter 10 Object-Oriented
Systems Analysis and Design Using
UML* > Use Case Modeling
UML@Classroom, An Introduction
to Object-Oriented Modeling
Chapter 1 Introduction
Chapter 3 The Use Case Diagram
4. Guidelines
Check whether your use cases are at
the appropriate level of detail
5. Use case descriptions
To further describe use cases in
greater detail
6. Where are the objects?
Next week!
Recap
Textbook chapters:
Systems Analysis and Design
Chapter 10 Object-Oriented
Systems Analysis and Design Using
UML* > Use Case Modeling
UML@Classroom, An Introduction
to Object-Oriented Modeling
Chapter 1 Introduction
Chapter 3 The Use Case Diagram
I know this is tiny
– there’s a bigger
version on the
Canvas site
 Still in Use
Image by Randall Munroe
https://xkcd.com/1888/

Object oriented modelling and use cases

11486 Systems Analysis and Modelling / 6677 Systems Analysis and Modelling G
Dr Luke Nguyen-Hoan
Now for the interactive
lecture example…
(If you’re just reading these slides, I highly recommend
going and watching from this part on in the lecture
recording, as this is where we go through and actually
analyse the lecture case study and draw something!)