0% found this document useful (0 votes)
29 views30 pages

Lecture 8 - Use Case and Activity Diagram

Uploaded by

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

Lecture 8 - Use Case and Activity Diagram

Uploaded by

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

1

SE-2102 Software Design


and Architecture

Lecture # 08

2
Recap
 4+1 architecture
 UML Component Diagram

 UML Deployment Diagram

3
Recap
 4+1 architecture
 UML Activity Diagram

 UML Use Case Diagram

4
Applying 4+1 View Architecture with UML 2

5
Use Case Diagram
Use Case Diagrams
 Consider an example: You recently bought a digital
camera. When you were shopping for it, you encountered a
wide variety of possibilities. How did you decide which one
to buy? You asked yourself exactly what you wanted to do
with a camera. Did you want extreme portability or did you
want a larger camera with a bigger lens? Would you be
taking distance shots? Did you want to take pictures and
post them on the web? Did you primarily want to make
prints? If so, how large? Did you want to make short
movies? With sound? We all go through a process like this
when we make a non-impulse purchase.
Use Case Diagrams

 Use case diagrams capture the functional requirements


of a system and help to identify how different actors
interact with the system to achieve specific goals or
tasks.
 Use case diagrams provide a high-level overview of the
system’s functionality, showing the different features or
capabilities it offers.
 It serve as a communication tool between stakeholders,
helping to clarify and validate requirements, identify
system boundaries, and support the development and
testing processes.
1. Actors
Actor in a use case diagram is any entity that
performs a role in one given system. This could be
a
 human/person
 organization
an external system (physical environment,
automated system)
Customer
and usually drawn like skeleton
An actor has a unique name and an optional
description.
Examples:
 Customer: A person who purchase something
Two Types Of Actors:
  Secondary Actor: This actor
Primary Actor: This is
the main user or system helps the system or primary
actor to complete the use
that initiates a use case. case, but they don't initiate the
For example, in an online interaction. For example, in the
shopping system, the same online shopping system,
customer is a primary a payment gateway is a
actor because they want secondary actor because it
helps process payments, but it
to buy something. doesn't start the shopping
process.

Primary actor = the main user trying to


do something.
Secondary actor = a helper that
supports the process.
10
System Boundary
It is a visual line or box that separates what is inside the
system (what the system does) from what is outside (what
is external to the system). It helps define the scope of the
system and clearly shows which use cases are part of the
system and which actors are interacting with it.

11
2. Use Case
 A use case is a sequence of actions that
user takes on a system to achieve
particular goal.
 Use case is a Dialogue between User
and System

A use case consists of:


 Unique name PurchaseTicket
 Participating actors
 Basic flow
 Alternate flow
 Pre conditions/Post conditions
Relationship

This is an association between system and


actor. It can be of different forms:
Simple association
Extend <<extend>>

Generalization

Include <<include>>

13
3. The <<extends>> Relationship
 This relationship shows
Customer that one use case can
optionally add extra
behavior to another use
Place Order
case, but only under
certain conditions. It's like
saying, "This might happen
<<extends>>
sometimes.“

Apply Discount  The direction of a


<<extends>> relationship is
to the extended use case
3. The <<includes>> Relationship
 This relationship shows that
one use case must use
Customer another use case as part of its
process. It's like saying, "This
step always happens.

Place Order  The direction of a


<<includes>> relationship is to
the using use case (unlike
<<includes>> <<extends>> relationships).

Make Payment
Continued
 Include = Always happens (mandatory
part).
 Extend = Sometimes happens (optional
or conditional).

16
3. Generalization Relationship
A generalized use case is a high-level, more abstract use case that
captures common behaviors or functionalities shared by other more
specific use cases.
Use Case Template

1
Microwave Example

Cook Food

User
Cook Food Use Case

A. Name: Cook Food


B. Brief description: User places food in microwave and
cooks it for desired period of time at desired power
level.
C. Actors: User
Cook Food Use Case

D. Basic flow:
1. User opens door and places food in unit
2. User enters time for cooking
3. User tells microwave to start
4. Unit cooks food
5. Unit indicates it is done
Cook Food Use Case

E. Alternate flows (“extensions”)


1. User cancels time before starting
2. User cancels cooking before finished
3. User selects reduced power level before pushing start button

Make sure you detail the alternate flows completely

Question 8
Cook Food Use Case

F. Pre-conditions
 Unit is plugged in
 Unit is in ready state
G. Post-conditions
 Food is cooked or user cancelled operation
H. Special requirements
 Unit should indicate remaining time to finish while cooking
 Default power setting should be "high"
Microwave Inclusion

Cook Food

<<include>>

User Set Timer


GUIDELINES: Use Case Modeling
 Keep use case names simple: Verb object
 Deposit money.
 Not: Deposit money into checking. Why not?
 Accomplish a user’s goal
 Invalid PIN is not a use case. Why not?
 Include Secondary Actors (e.g., Bank)
 Avoid ambiguity
 E.g., in the ATM problem, System could be the
machine or the Bank’s back-end server
 Start Up and Shut Down are use cases
 Why do we usually not include them at first?
Use-case Diagram

Use-case diagram for surveillance function


Alternative Actions
 Can the actor take some other action at this point?
 Is it possible that the actor will encounter some
error condition at this point?
 Is it possible that the actor will encounter behavior
invoked by some event outside the actor’s
control?
Activity diagram for
Access camera
surveillance—display
camera views function
Swimlane
diagram
The End.

30

You might also like