0% found this document useful (0 votes)
196 views34 pages

S03 - Requirement Modeling (Use Case Diagram)

Use case diagrams depict the functionality of a system from a user perspective by showing actors, use cases, and relationships between them. Actors represent roles that interact with the system, use cases represent system functions, and relationships show how actors and use cases are connected. Use case diagrams are developed iteratively to model user requirements and system behavior at different levels of abstraction.

Uploaded by

mash
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
196 views34 pages

S03 - Requirement Modeling (Use Case Diagram)

Use case diagrams depict the functionality of a system from a user perspective by showing actors, use cases, and relationships between them. Actors represent roles that interact with the system, use cases represent system functions, and relationships show how actors and use cases are connected. Use case diagrams are developed iteratively to model user requirements and system behavior at different levels of abstraction.

Uploaded by

mash
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 34

Requirement Modeling:

Use Case Diagram

Md. Mohaiminul Islam


Lecturer, CSE
University of Asia Pacific
Introduction
Use-cases are descriptions of the functionality of a system
from a user perspective.

Depict the behaviour of the system, as it appears to an
outside user.

Describe the functionality and users (actors) of the system.

Show the relationships between the actors that use the
system, the use cases (functionality) they use, the
relationship
and between different use
 cases. Document the scope of the
 system.
Illustrate the developer’s understanding of the
user’s requirements.
Use Case Diagram, purpose
Class Activity
diagram diagram
s s
Requirement Sequenc
s document e
(text in natural
language) diagram
s
Statechar
t
diagrams
• Use case models are developed at different levels of abstraction
– system, system component, or a class.
• Use case modelling is an iterative and incremental process.
– If user requirements change, the changes should be made in all
affected
the
documents.
Use Case diagrams, basic UML notation
Use Case: A Use Case is a description of a set of
interactions between a user and the system.
Components of use case diagram:
 Actor
 Use
use case
 case name

 System use case


boundary name

Relationship use case


name
Actor
• Actor is someone interacting with use case
(system function). Named by noun.

•Similar to the concept of user, but


a user can play different roles;
Name (example: a prof. can be instructor and
researcher – plays 2 roles with two systems).

• Actor triggers use case.


•Actor has responsibility toward the system (inputs),
and Actor have expectations from the system (outputs).

13
ACTOR
Actors can be human or automated systems.
Actors are not part of the system.
UML notation for actor is stickman, shown
below.

Student Faculty Employee


Finding Actors
External objects that produce/consume data:
• Must serve as sources and destinations for data
• Must be external to the system
Primary and Secondary Actors
• Primary Actor
– Acts on the system
– Initiates an interaction with the system
– Uses the system to fulfill his/her goal
– e.g. the employee receiving the paycheck
• Secondary Actor
– Is acted on/invoked/used by the system
– Helps the system to fulfills its goal
– Something the system uses to get its job
done
– e.g. the warehouse receiving a packing slip
USE CASE
What is USE case?
A use case is a pattern of behavior, the
system exhibits
The use cases are sequence of actions that
the user takes on a system to get particular
target
USE CASE is dialogue between an actor and
• the system.
Examples Add a
: course
Use Case
Do something

• System function (process – automated or manual).


• Named by verb.
• Each Actor must be linked to a use case, while some use cases
may not be linked to actors.

= Use Case

14
System Boundary
 It is shown as a rectangle.
 It helps to identify what is external versus internal, and
what the responsibilities of the system are.
 The external environment is represented only by
actors.
Relationship
• Relationship is an association between use case and
• actor. There are several Use Case relationships:

 Association

 Extend

 Generalization

 Uses

 Include
1. Generalization
Generalization is a relationship between a
general use case and a more specific use
case that inherits and extends features to it
use cases that are specialized versions of
other use cases
It is shown as a solid line with a hollow
arrow point
1. Generalization

• The child use case inherits the


parent
behavior and meaning of the
parent use case.
• The child may add to or child

override the behavior of its


parent.

18
1. Generalization

registration

non-graduate graduate
registration registration

19
1. Generalization

The actor Order Registry


Clerk can instantiate
the general use case
Place Order.
Place Order can also be
specialized by the use
cases Phone Order or
Internet Order.
2. Extend

base <<extend>> extending

• The base use case implicitly incorporates the


behavior of another use case at certain points
called extension points.
• The base use case may stand alone, but under
certain conditions its behavior may be
extended by the behavior of another use case.
• It is shown as a dotted line with an arrow
point and labeled <<extend>>
27
2. Extend
Enables to model optional behavior or branching under
conditions.

<<
extend>> Register
Logi
New
n
User
2. Extend
• Extend relationship – linking an optional use
case to a standard use case.

• Example: Register Course (standard use case) may


have Register for Special Class (extend use case) –
class for non-standard students, in unusual time, with
special
topics, requiring extra fees…).

• The optional UC extends the standard UC

• Standard use case can execute without the extend case


 loose coupling.

29
3. Include

base <<include>> included

• The base use case explicitly incorporates the


behavior of another use case at a location
specified in the base.
• The included use case never stands alone. It only
occurs as a part of some larger base that includes
it.
• They are shown as a dotted line with an open
arrow and the key word <<include>>
22
3. Include
Include relationships insert additional behavior into
a base use case
use cases that are included as parts of other use
cases.
Enable to factor common behavior.
3. Include

• Include relationship – a standard case linked to a


mandatory use case.

• Example: to Authorize Car Loan (standard use case),


a clerk must run Check Client’s Credit History (include use case).

• The standard UC includes the mandatory UC (use the verb


to figure direction arrow).

•Standard use case can NOT execute without the include


case  tight coupling .

24
3. Include

•Enables us to avoid describing the same flow of events several times by


putting the common behavior in a use case of its own.

updating
grades <<include>>
verifying
student
id
output <<include>>
generating

‫עדימ תוכרעמ חותינ‬ 23


4. Uses
When a use case uses another process,
the relationship can be shown with the
uses relationship
This is shown as a solid line with a hollow
arrow point and the <<uses>> keyword
4. Uses
How to create use case diagram
1. List main system functions (use cases) in a column:
– think of business events demanding system’s response
– users’ goals/needs to be accomplished via the system
– Create, Read, Update, Delete (CRUD) data tasks
– Naming use cases – user’s needs usually can be translated in data tasks
2. Draw ovals around the function labels

3. Draw system boundary

4. Draw actors and connect them with use cases.

5. Specify relationships between use cases.


37
Example 1

place
place <<extend>>
conference
phone call
call
cellular
receive
receive <<extend>>
network additional
phone call
call

use
user scheduler
Cellular Telephone

18
Example 2

Altered State University (ASU) Registration System

1. Professors indicate which courses they will teach on-line.


2. A course catalog can be printed
3. Allow students to select on-line four courses for upcoming
semester.
4. No course may have more than 10 students or less than 3
students. Registrar.
5. When the registration is completed, the system sends
information to the billing system.
6. Professors can obtain course rosters on-line.
7. Students can add or drop classes on-line.
Example 2 cont.
Altered State University (ASU) Registration System
Example 3

I. Begin with a Use Case!


A user placing an order with a sales company might
follow these steps :
1. Browse catalog and select items.
2. Call sales representative.
3. Supply shipping information.
4. Supply payment information.
5. Receive conformation number from salesperson.
II. Then translate Use Case sequence into Diagram
Example 3

The salesperson could also


be included in this use case
diagram because the
salesperson is also
interacting with the
ordering system.
Example 4
Vending Machine

After client interview the following system scenarios were


identified:
– A customer buys a product
– The supplier restocks the machine
– The supplier collects money from the machine

On the basis of these scenarios, the following three actors


can be identified:

Customer; Supplier; Collector (in this case Collector=Supplier)


Example 4
Thank you

You might also like