use cases 1. last week introduction to software engineering how is it different from traditional...
TRANSCRIPT
Last week
Introduction to software engineering How is it different from traditional engineering?
Introduction to specification Operational vs descriptive Used throughout the product lifecycle
Introduction to Requirements An instance of a specification Functional versus non-functional
This week
Use cases: one way to capture requirements
Operational specifications, during the analysis/planning phase of development UML diagrams
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)
Each use case represents a discrete goal for the user
4
Use-Case Diagram
5
homeowner
Arms/ disarms system
Accesses system via Internet
Reconfigures sensors and related
system features
Responds toalarm event
Encounters anerror condition
system administrator
sensors
Each oval is a separate use case that has a description
Each oval is a separate use case that has a description
Each stick figure is an actor in your system
Each stick figure is an actor in your system The block is an
external system that interacts with your system. Any system you aren’t developing is external
The block is an external system that interacts with your system. Any system you aren’t developing is external
Use Case Description
Maps to a single bubble (user goal)
See the example on the course webpage:
http://www.cs.gmu.edu/~kdobolyi/cs321/UseCaseTemplate.html
6
Alternate and Exception Flows1. Basic Flow
1. User enters user name
2. User enters password
3. User submits the form
4. Password is validated as correct
5. Main menu is displayed
2. Alternate Flow 1: No password is present at step 1.41. System displays error message.
2. System continues at step 1.2
3. Alternate Flow 2: Password is incorrect at step 1.41. …
4. Exception Flow 1: Database is unreachable1. System displays an unrecoverable error and exits.
7
Includes versus Preconditions
8
Don’t forget to show this on the use case diagram as “includes”
Don’t forget to show this on the use case diagram as “includes”
Includes are steps in the use-casePre-conditions happen before the use caseItems are one or the other, not both!
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 Relationships
9
AuthorizedStaff Worker
TeacherStudent
Record class grades Review Transcripts
User Goals User Goals are statements that represent what the users need to
accomplish, independent of specific software features
Examples of user goals for a Student Records Management System Ensure that a student’s records reflects courses
taken and grades received in those courses Allow only authorized faculty and staff to update
student records Ensure that students can obtain copies of their own
(and only their) records in a timely manner
10
System Interactions Represent expected interacts between users and
the computer-based system
Suggest how the system fulfills a user goal
Examples: A teacher alters a course grade for a student by
selecting a course selecting a student reviewing the previous grade entering a new grade confirming the change
A process for an administrator to create a new user A process for granting a user access rights
11
User Goals vs. System Interactions
In some cases, system interactions and user goals can be very similar
However, confusing system interactions with user goals or neglecting to identify user goals can obscure the reasons why a system
should have certain features result in lost opportunities for creativity
12
Example showing interactions: User wants to spell check document.
Basic Flow1.User clicks “Spell Check” button2.System checks each word3.New dialog box appears with results
Example showing interactions: User wants to spell check document.
Basic Flow1.User clicks “Spell Check” button2.System checks each word3.New dialog box appears with results
Example showing goals: User wants to spell check document.
Basic Flow1.User starts spell check process2.System checks each word3.System presents results to the user
Example showing goals: User wants to spell check document.
Basic Flow1.User starts spell check process2.System checks each word3.System presents results to the user
User Goals vs. System Interactions
User goals help answer “What” and “Why” questions
System interactions help answer “How” questions (from a user’s perspective)
We will model user goals with Uses Cases
Later, we will model system interactions with interaction diagrams or activity diagrams
13
Actors
Actors are people or external systems that need to interact with our system
14
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 iPodAnswer these questions to find actors for an iPod
Finding ActorsFinding Actors
Relationships Between Actors
Actors can be related by generalization/specializ- ation
Actors are classifiers (not individual users)
15
Student
Graduate Student
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
16
Use-Case Relationships
Includes Dependency: Defines how one use case can invoke behavior defined by another use case
18
Teacher
Alter Student Grade
Record Grades for a Section
<<includes>>
Use-Case Relationships
Extends dependency: defines a use-case that is a variation of another, usually for handling an abnormal situation
19
AuthorizedStaff Worker
Alter Student Grade
Alter student grade for a class taken more
than a year ago
<<extends>>
Use-Case Relations Generalization: Defines one use case as a generalization of
another. Replaces generic functionality with alternate implementation
Coming up: Documenting Use Cases
20
Teacher
Alter Student Grade
Alter Student Grade for a Graduate Course
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
22
In Class Exercise
Lets create a use case diagram for
iPod Television set Elevator ATM Online Scrabble game Word Processor
23
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?
24