Berhampur 70918*19311 CALL GIRLS IN ESCORT SERVICE WE ARE PROVIDING
Â
Use-Case-Diagram.ppt
1. USE CASE DIAGRAM
ICE 4212
System Analysis and Software Engineering Sessional
Coming up: Introduction
1
Md. Arafat Hossain
Lecturer
Dept. Of ICE
2. Introduction
ďŽ Use Case: â... a typical interaction between a
user and a computer systemâ, Booch
â Here, âuserâ is anything that needs or invokes the functionality
of the system
â âComputer systemâ is the system being modeled
ďŽ Use cases capture and document the user-
visible functionality of a system (functional
requirements)
ďŽ Use cases capture how the system will benefit
the user
ďŽ Each use case represents a discrete goal for
the user
2
Coming up: Example Use Case Diagram
4. Use Case Diagrams
ďŽ Use Case Diagrams provide a visual way to
document user goals and explore possible
functionality
ďŽ Three primary modeling components:
â Actors
â Use Cases
Authorized
Staff Worker
Teacher
Student
Record class grades
â Relationships between
use cases
Review Transcripts
4
Coming up: Actors
5. Actors
ďŽ Actors are people or external systems that
need to interact with our system
5
Coming up: Relationships Between Actors
ďŽ Who or what will use the main functionality of the system?
ďŽ Who or what will provide input to this system?
ďŽ Who or what will use output from this system?
ďŽ Who will need support from the system to do their work?
ďŽ Are there any other software systems with which this one
needs to interact
ďŽ Are there any hardware devices used or controlled by this
system?
Answer these questions to find actors for an iPod
Finding Actors
6. Relationships Between Actors
ďŽ Actors can be related by
generalization/specialization
ďŽ Actors are classifiers (not individual users)
Student
Graduate
Student
6
Coming up: Use Case Relationships
7. Use Case Relationships
Includes
Extends
Generalization
7
Coming up: Use-Case Relationships
After a while you realize extends and generalization are not too
different. Just know generalization and includes⌠forget about
extends (the difference is only in intent)
8. Use-Case Relationships
ďŽ Includes Dependency: Defines how one
use case can invoke behavior defined by
another use case
Teacher
Alter Student Grade
Record Grades for a
Section
<<includes>>
8
Coming up: Use-Case Relationships
9. Use-Case Relationships
ďŽ Extends dependency: defines a use-case
that is a variation of another, usually for
handling an abnormal situation
Authorized
Staff Worker
Alter Student Grade
Alter student grade for
a class taken more
than a year ago
<<extends>>
9
Coming up: Use-Case Relations
10. Use-Case Relations
ďŽ Generalization: Defines one use case as a
generalization of another. Replaces generic
functionality with alternate implementation
Teacher
Alter Student Grade
Alter Student Grade for
a Graduate Course
10
Coming up: Documenting Use Cases
11. Documenting Use Cases
Coming up: Benefits of Use Cases
11
List
Actors
List External
Events
Determine
expected behavior
Name behaviors as
use cases
Add relations
(includes, extends,
generalization)
Document use case
(basic flow, alternate,
exception)
What is system response
to external event? What is
the userâs goal?
Be Patient⌠let them unfold
12. Benefits of Use Cases
ďŽ Use cases diagrams capture user-visible functions
ďŽ Identifying actors help capture who needs the system
functionality
ďŽ Relationships between use cases document
opportunities for reuse
ďŽ Use cases provide a basis planning and scheduling
incremental development
ďŽ Use cases can provide a basis for system testing
12
Coming up: In Class Exercise
13. In Class Exercise
ďŽ Lets create a use case diagram for
â iPod
â Television set
â Elevator
â ATM
â Online Scrabble game
â Word Processor
Coming up: Use cases for CS421
13
14. Use cases for ATM System
Show system
boundary
Show Actors
outside
boundary
Use extend,
include,
generalization/spe
cialization where
appropriate
Typically one
diagram for
your project
is sufficient
14
Coming up: Use cases for ICE4212
15. Use cases
ďŽ For each use-case (oval) in your diagram
include the use-case description text
described in the slide for Chapter 5, titled:
ďŽ Use Case Description
âabout slide #14
15
Coming up: Questions
16. Questions
ďŽ Who might be interested in reviewing or using use
case diagrams?
ďŽ When in the development life cycle should we employ
use cases?
ďŽ What do use cases have to do with object-orientation?
ďŽ What level of use-case granularity is best?
ďŽ How many use cases are enough?
ďŽ Can other modeling activities help in discovering use
cases?
ďŽ When in the development life cycle do we stop
referring to or refining the use cases?
ďŽ What should the text description of use case contain?
16
Coming up:
17. ďŽ Backup Slides
ďŽ The following slides were removed over
time.
Coming up: Extends vs. Includes vs. Generalization
17
18. Actors
ďŽ Actors are people or external systems that
need to interact with our system
ďŽ Actors carry out use cases
ďŽ Actors are represented as stick figures
ďŽ Although users are actors, not all actors
are users
â Actors can be external software systems
â External hardware (sensors, actuators, etc.)
â Actors can be people that need the functionality of
the system, but may not be the ones who actually
invoke the software commands
23
Coming up: Hints for Finding Actors
19. Hints for Finding Actors
ďŽ Who or what will use the main functionality of the
system?
ďŽ Who or what will provide input to this system?
ďŽ Who or what will use output from this system?
ďŽ Who will need support from the system to do their
work?
ďŽ Are there any other software systems with which
this one needs to interact
ďŽ Are there any hardware devices used or controlled
by this system?
24
Coming up: Hints for Modeling Actors
Using these what are some actors for an iPod?
20. Hints for Modeling Actors
ďŽ An actor can be a role that a user plays with
respect to the system
ďŽ A single person may play different roles
ďŽ A single actor may perform many use cases
ďŽ A use case may be performed by many actors
ďŽ Show external systems as actors only when
they are the ones who need a use case
25
End of presentation