Overview of Modeling & Use

case diagrams

Ms. Sassandara Ranasingha

ICT1411 – Object Oriented Programming

1
Learning Outcomes
• Understand what is modeling
• Explain the importance of Software modeling
• Understand structured and Object oriented modeling approaches
• Create Use case diagrams for given scenarios

ICT1411 – Object Oriented Programming 2

Why we model?
• We build models of complex systems because we cannot understand
such a system in its entirety.
• That is to achieve a high level of quality in the final software product.
• Everyone builds and uses models – we want to develop “formal”
models.
• Deploy quality software that meets the
• Needs of its users.
• In a timely and predictable fashion
• With an efficient and effective use of resources.

ICT1411 – Object Oriented Programming 3

What is a model?

• A model is “a representation in three dimensions of

• Some proposed or existing structure,
• Or of some material object artificial,
• Or natural showing the proportions,
• And arrangements of its component parts.

ICT1411 – Object Oriented Programming 4

The Importance of Modeling
Aim of modeling:
• Helps to visualize a system as it is or as we want it to be.
• Permits us to specify the structure or behavior of a system.
• Give us a template that guides us in constructing a system.
• Document the decision we have made.

ICT1411 – Object Oriented Programming 5

Steps in modeling
• There are THREE steps to creating a quality model:
• Analysis
• Design
• Implementation

• A successful project is the result of:

• A lot of analysis
• Less design
• Even less implementation

ICT1411 – Object Oriented Programming 6

Modeling Views
• Functional Oriented View
• Object Oriented View

ICT1411 – Object Oriented Programming 7

Modeling views
• Functional Oriented View : Traditional view of modeling
• E.g. Dataflow diagrams
• Focuses on
• Issues of control.
• The decomposition of larger system into smaller ones

ICT1411 – Object Oriented Programming 8

Modeling views contd..
Object Oriented view:
• What is OO?
• Object Orientation is the result of merging ideas and concepts
about how to design and build better product.
• That is to create a representation of the real world problem domain and
maps it into solution domain.
• Why use OO?
• Object orientation enables us to create more complicated
programs.

ICT1411 – Object Oriented Programming 9

Use Case Diagrams

ICT1411 – Object Oriented Programming 10

Introduction
• Use cases are a critical technique in developing an application.

• Use cases are used to capture the high-level user-functional

requirements of a system.

• It is an excellent way to communicate to management, customers and

other non development people.
• WHAT a system will do when it is completed.
• BUT..it does not go into detail of HOW a system will do anything.

ICT1411 – Object Oriented Programming 11

 An Alternative View

Requirements Capture USE CASE DIAGRAM

System Structure CLASS DIAGRAM

INTERACTION DIAGRAMS
System Behavior
ACTIVITY DIAGRAMS

ICT1411 – Object Oriented Programming 12

Why develop Use Case model?
• Use Case model is the starting point for designing the system.

• With the UML, we can apply use case diagrams to

• Visualize the behaviour of a system, subsystem or a class so that users can
comprehend how to use that elements.
• So that developers can implement that element

• It illustrates to the development team exactly what is expected from a

system.

ICT1411 – Object Oriented Programming 13

Components of a Use Case Diagram

• System : Something that performs function(s).

• Actors : the roles adopted by those participating.
• Use Cases : high level activities to be supported by the system.
• Relationships / Links : which actors are involved in which use
cases (dependency, generalization, and association)

ICT1411 – Object Oriented Programming 14

Actors
• An Actor represents an entity in the outside world that takes
on the role of interacting with the software system.
• An actor can be
• A user (i.e. Human)
• Another software system
• A hardware device (with embedded software)

Customer Video DB EFTPOS

System
ICT1411 – Object Oriented Programming 15
Identifying Actors
• An Actor indicates an external person or system which is involved in a
use case.

• An actor may be involved in more than one use case.

• One actor is normally the initiator of each use case.

ICT1411 – Object Oriented Programming 16

Human Actors
• Actors must always interact with the software.
• A human actor who:
• Is involved in some process performed by the system but
• Who does not directly interact with the software, is not a valid actor.

• Actors are connected to use cases only by an association.

• Example:
• A video library customer is not a valid actor because customers do not get to
leap over counter and use the video library software.

• A video library staff member serving at the counter, is a valid actor because
they do directly interact with the software.

ICT1411 – Object Oriented Programming 17

Non Human Actors
• A non human actor must:
• Be an item of hardware or software which is external to the system.
• Have a clearly defined mechanism, usually message passing for interacting with
objects in the software.

• Have a behavior which is:

• Totally determined by itself.
• Significant in terms of the design (i.e. high level and relevant)

• Operating systems, files, monitors, mice are not valid actors.

• A printer may or may not be an actor.

ICT1411 – Object Oriented Programming 18
Non Human Actors
• A non human actor must:
• Be an item of hardware of software which is external to the system.
• Have a clearly defined mechanism, usually message passing for interacting with
objects in the software.

• Have a behaviour which is:

• Totally determined by itself.
• Significant in terms of the design (i.e. high level and relevant)

• Operating systems, files, monitors, mice are not valid actors.

• A printer may or may not be an actor.

ICT1411 – Object Oriented Programming 19

Use Case
• A use Case represents a set of sequence of events (actions) which
combine to form some interaction between the software system and
the outside world.

• Use cases does something of value to an actor.

Loan Video

ICT1411 – Object Oriented Programming 20

Use Cases - Names
• Every use case must have a name that distinguishes it from
other use case.
• A use case name may be text consisting of
• Any number of letters, numbers and most punctuation marks (except
for marks such as the colon, which is used to separate a class name
and the name of its enclosing package.)

• In practice, use case names are short active verb phrases naming
some behavior found in the vocabulary of the system you are
modeling.

ICT1411 – Object Oriented Programming 21

How to Find Use Cases
• When you are looking for Use Cases you can ask following questions,

• Which functions, services (full functions) does actors require frame from the
system ? What does the actor need to do?

• Does the Actor need to read, create, destroy, modify or store some kind of
information in the system?

• Does the Actor need to get notified when some events occur in the system?

• Can some Actors daily work be simplified by functionality in the system? If so

what work?
ICT1411 – Object Oriented Programming 22
Example

Laon Videos

Look Up Video Data

Shop Attendant
Returns Videos

Pay Fine

Create Membership

ICT1411 – Object Oriented Programming 23

Scenarios
• A Use Case represents a high level description of an actor interacting
with a software system.

• There may be a number of alternative possibilities for a given Use

Case.

• Each of theses alternatives is called a scenario.

• The first scenario is the basic all went well flow of events.

• The other scenarios will be concerned with handling different possible

outcomes.
ICT1411 – Object Oriented Programming 24
Scenarios (cont.)
• Example
• John clicks the view report button.
• The login dialog is displayed.
• John enters the username “john”.
• John enters the password “johnpass”.
• The system checks the validity.
• The system displays the report menu page.

• A scenario can be thought of as an Instance of a Use Case.

• Each scenario comes with
• A list of preconditions
• A list of post conditions
• A flow of events descriptions.

ICT1411 – Object Oriented Programming 25

Scenario – Pre-Conditions
• A text description.
• Concerned with what must be true prior to the start of this scenario.
• Concerned with facts NOT actions.
• Must not contain predictions of what will happen in the flow of event in
the scenario.
• Example
“A scenario in the member borrows video Use Case.”
• Valid pre-condition –
• Member has a library video card and some videos to rent.
• Invalid pre-condition –
• Member has invalid membership card which will be rejected.

ICT1411 – Object Oriented Programming 26

Scenario – Post – Condition
• A text description.
• Concerned with what must be true after the end of this scenario.
• Concerned with facts NOT actions.
• Must not describe future actions because scope should be restricted to
the Use case which contains it.
• Example
• “A scenario in the member borrows video Use Case.”
• Valid pre-condition –
• The member whose card was scanned was prevented from renting any videos.
• Invalid pre-condition –
• A member has been denied access and will be arrested by police.

ICT1411 – Object Oriented Programming 27

Describing the flow of events in a Use Case

• A use case describes what a system does but it does not specify how does
it.
• When you model it is important that you keep clear the separation of
concerns between this outside and inside view.
• A plain text description used to describe the events which occur in the Use
Case.
• You can specify the behavior of a Use Case by describing the flow of events
in text.
• When you write this flow of events it should include
• How and when the use case starts and ends.
• When the use case interacts with the actors.
• What objects are exchanged.
• The basic flow.
• Alternative flows (exceptional) of the behavior.
ICT1411 – Object Oriented Programming 28
Example
• In the context of an ATM system, you might describe the use case validateUser in
following way.
• Main flow of events
• The use case starts when the system prompts the customer for a PIN number.
• The customer can now enter a PIN number via keypad.
• The customer comments the entry by pressing enter button.
• The system then checks the PIN number to see if it is valid.
• If the PIN number is valid the system acknowledges the entry thus ending the use case.

ICT1411 – Object Oriented Programming 29

Continued…
• Exceptional flow of events:
• The customer can cancel a transaction at any time by pressing the cancel
button, thus restarting the use case. No changes are made to the customer
account.
• Exceptional flow of events:
• The customer can clear a PIN number anytime committing it and reenter a new
PIN number
• Exceptional flow of events:
• It the customer enters an invalid PIN number, the Use Case restarts, if this
happens three times in a row system cancel the entire transaction, preventing
the customer from interacting with the ATM for 60 seconds.
ICT1411 – Object Oriented Programming 30
Use Case Relationships
• You can have plain relationships
• Between Use Cases and
• Between Actors, and
• Between Actors and Use Cases.

• A relationship like this means one Use Case activates another.

• The most common of these relationships in an Actor that
<<communicate>> with a Use Case.

ICT1411 – Object Oriented Programming 31

Use Case Relationships
• There are FOUR kinds of relationships can exist between use
cases.
• Association
• Indicates that an actor participate in (i.e. communicate with) the use case.
• Include
• Indicates that the behavior of one use case includes the behavior of a
another.
• Extend
• Indicates that one use case may be extended (subjected to specific
conditions) by the behavior of another.
• Generalization
• Indicates that one use case inherits the properties of another with the usual
possibilities for overriding and substitution.

ICT1411 – Object Oriented Programming 32

Association Relationship
• The relationship between actors and use cases.
• The ONLY relationship between actors and use cases shown by association.
• Example:

link

Use case
Actor

ICT1411 – Object Oriented Programming 33

Include (uses) relationship
• Also known as the uses relationship.
• Use Case A calls Use Case B.
• The separation of behaviors into two use cases means that other Use
Cases which require the same set of actions described in Use Case B
can make use of an include relationship as well.
• Use Case C which also requires the actions performed in use Case B can also
have an includes (or uses) relationship with Use Case B.

ICT1411 – Object Oriented Programming 34

Include Relationship – Example
• Include relationship is to avoid describing the same flow of events several
times
• By putting the common behavior in a use case of its own (the use case that is
included by a base use case).
• You render an include relationship as a dependency, stereotyped as
include.
Identify
<<include>> Member

Including use Rent

Video Included use case
case

<<include>>
Process
Rental

ICT1411 – Object Oriented Programming 35

Extend – Relationship
• Borrowed from the concept of generalization in class hierarchies.
• If Use Case A extends Use Case B then,
• The behavior of Use Case A is similar to but more specialized than that Use
Case B.
• The behavior of Use Case B is more generalized than that of Use Case A
• Use Case B is known as the base Use Case.

• The base Use Case is a complete Use Case in its own right, which may
have its behavior extended by another Use Case when specific
conditions arise.

ICT1411 – Object Oriented Programming 36

Extend Relationship : Example

• An extend relationship is to model the part of a use case the user may see
optional system behavior.
• In this way, separating optional behavior from mandatory behavior.

<<Extend>>
Rent Video Rent Video
with late fines

ICT1411 – Object Oriented Programming 37

Extend / Include Example
“late fine” is
the name of the
extension point in the
rent video use Case
<<extend>>
Late fine Rent Video
Rent Video
with late fines

<<include>>

<<include>> Process rental

Identify member

ICT1411 – Object Oriented Programming 38

Generalization Relationship
• Generalization is a technique used to indicate Inheritance.
• This means that a child use case inherits the behavior and meaning of the
parent use case.
• The child may add or override the behavior of the parent.
• The child may be substituted in any place the parent may appear in the
system.
• Generalization appears as :

Child Use case Parent Use case

ICT1411 – Object Oriented Programming 39

Example of Generalization in a Use Case Diagram

Check
password
Validate User

Retinal Scan

• Generalization can even be hierarchical where children use cases of a

parent use case can have their own children.

ICT1411 – Object Oriented Programming 40

 Actor Generalization
• Actor Generalization is drawn from the concept of inheritance in
Object Oriented Programming.
• A super class is a more generalized version of a sub class
• A sub class is a more specialized version of the super class.

• Just like classes actors can include generalizations.

• In other words, a child actor:
• Inherits all of the characteristics and behavior of the parent actor.
• Can add to, modify or ignore any of the characteristics and behaviors of the
parent actor.

ICT1411 – Object Oriented Programming 41

Actor Generalization: Example

Video Library Staff

Manager Shop Attendant

ICT1411 – Object Oriented Programming 42

Organizing Actors
• Actors can have generalization relationships.

Visitor

Registered Visitor

ICT1411 – Object Oriented Programming 43

ICT1411 – Object Oriented Programming 44
Components of a Use Case

• start with a verb to emphasize that it is a process.

• It is a role that a user plays in respect to the system.

• Actors are generally shown when they are the ones who need the use case .
• The system is never an actor
• Primary represents major common processes .
• Secondary represents minor or rare processes .
• Optional processes that may not be implemented in the system depending upon
resources.
• DESCRIPTION - short and essential
ICT1411 – Object Oriented Programming 45
Activity : Introductory Case Study
The Bank Account
• You are asked to design a system to handle current and savings accounts for a
bank.
• Accounts are assigned to one or more customers, who may make deposits or
withdraw money.
• Each type of account earns Interest on the current balance held in It.
• Current accounts may have negative balances (overdrafts).
• On a savings account there Is a maximum amount that can be withdrawn in one
transaction.

ICT1411 – Object Oriented Programming 46

Introductory Case Study contd..
The Bank Account
• Bank employees may check any account that is held at their branch. They are
responsible for invoking the addition of interest and for issuing statements at the
correct times.
• A money transfer is a short lived record of an amount which has been debited
from one account and has to be credited to another.
• A customer may create such a transfer from their account to any other.
• Transfers within a branch happen immediately, while those between branches
take three days.

Draw the Use Case Model for the Bank.

ICT1411 – Object Oriented Programming 47

Steps
• The first step is to identify the actors.
• The next step is to identify the main categories of interaction that each actor has
with the software system.
• Each interaction is then represented as a Use Case.
• For each Use Case the scenarios are identified.
• In the fleshing out of scenarios, overlap is then observed.
• This overlap in the Use Cases is then used for factor them into include or extend
relationships.
• The goal of using extend or include relationships is to make the design process
easier If the use of an include or extend relationships makes the generation of
flow of events description difficult then don't!
• Similarly actors are factored into generalizations where appropriate.
ICT1411 – Object Oriented Programming 48
Important facts on Use Cases
• All use cases are either
• Directly indicated by an actor.
• Related (transitively) to such a use case

• This is important
• You are modeling all tasks the (system under development) SUD can perform
you are modeling what the real users expect.
• If you focus all tasks the SUD can perform you will fall into design space too
quickly.

ICT1411 – Object Oriented Programming 49

Exercise 2
Mark, a librarian at a local library, receives a new batch of books. He
adds them to the library system, removes any outdated or damaged
books, issues a book to a member, processes a returned book, helps a
member search for a particular book, and renews the membership of
an expired member.

ICT1411 – Object Oriented Programming 50

Exercise 2
• The following is a description of the activities of a box office clerk
interacting with a theatre ticket booking system. On receiving a
request for tickets from a customer, the clerk must firstly set up an
order on the system. She then asks the customer if the order is a
single order or a subscription order. Members of the theatre are
entitled to place subscription orders.
• If a single order, the clerk assigns the seats on the system and charges
the customer's credit card.
• If on the other hand, it is a subscription order, the clerk assigns the
seats and debits the customer's account at the same time as
awarding the customer a member's bonus. In both cases, the final
step is to send out the tickets.

ICT1411 – Object Oriented Programming 51