Transcript Adv. Use cases - Winona State University

Adv. Use cases
• Actor generalization – general and special
actors
• Use case generalization – general and
special use cases
• Include and extend relationships among
use cases
• Keep these simple – and use only to
enhance clarity
Actor Generalization
• Actor - Customer  list products, order
products, accept payment
• Actor - Sales agent  list products, order
products, accept payment, calculate
commission
• Can have a general actor – Purchaser
• Abstract Actor - Purchase  list products,
order products, accept payment
• Concrete actor - Customer and Sales
agent are derived from Purchaser
• Concrete actor - Sales agent  calculate
commission
– (unique to sales agent)
Use-case generalization
• One use can be a specialization of another
use case
• Use only to add clarity to your diagram
• Child inherits all properties – but cannot
override relationship and attribute
• An abstract use case may have
incomplete or empty event flow
• The child use case is precise
•
•
•
•
Find product is a general use case
Find books is a specific case
Find cds is another specific case
We can have other use cases as and
when identified
• Many use cases may involve a common
sequence of event flow
• We can then write a separate use case for
this common sequence
• And then include it whenever it is needed
• The client use case calls the supplier use case
as appropriate
• Find employee details is a supplier use case
• Change employee details, view employee
details, delete employee details, etc. are client
use cases
• Some supplier use cases can be used to extend
client use case
• Extension are new add-on behavior and are not
necessary for completeness of use case
• IssueFine for overdue book can be a
supplier use case
• Can be used in a return books use case
as an extension
• Multiple versions of extension may be
useful and pluggable
• Clarity is the key to all analysis and design
diagrams
• Maintain glossary of terms as you develop
them
Use-case Engineering
• Develop top-level readable use-case descriptions. This
should include actors involved and success criteria.
• Identify alternate situations and descriptions of events
thereof.
• Capture the actor's intention, not the user interface
details.
• Have an actor pass information, validate a condition, or
update state.
• Write between-steps commentary to indicate step
sequencing (or lack of).
• Specify data names and descriptions as required
Focus
• User/Actor intent and objective
• Is-a relationship may indicate generalspecial actors or general-special usecases
• Common steps/events in a different usecases may be identified as include usecases
• Useful – optional steps – may be identified
as extension use-cases
Writing Use-cases
•
•
•
•
•
•
•
•
Name the system scope.
Brainstorm and list the primary actors. Find every human and non-human
primary actor, over the life of the system.
Brainstorm and exhaustively list user goals for the system.
Select one use-case at-a-time to expand. Write narrative to learn the
material.
Write the main success scenario (MSS). Use 3 to 9 steps to meet all
interests and guarantees.
Brainstorm and exhaustively list the extension conditions.
Include all that the sytsem can detect and must handle.
Write the extension-handling steps – as use-cases
Each will end back in the MSS, at a separate success exit, or in failure.
Extract complex flows to sub use cases; merge trivial sub use cases.
Extracting a sub use case is easy, but it adds cost to the project. .
Process
• Use Case Title
– Is it an active-verb goal phrase that names the goal of the primary
actor?
– Can the system deliver that goal?
• Primary Actor
– Does he/she/it have behavior?
– Does he/she/it have a goal against the System under Discussion - that
is this a service promise of the System?
• Preconditions
– Are they mandatory, and can they be set in place by the System
– Is it true that they are never checked in the use case?
• Main Success scenario
– Does it have 3-9 steps?
– Does it run from trigger to delivery of the success guarantee?
– Does it permit the right variations in sequencing?
• Each Step in Any
– Is it phrased as a goal that succeeds?
– Does the process move distinctly forward after its successful
completion?
– Is it clear which actor is operating the goal--who is "kicking the ball"?
– Is the intent of the actor clear?
– Is the goal level of the step lower than the goal level of the overall use
case? Is it, preferably, just a bit below the use case goal level?
– Are you sure the step does not describe the user interface design of the
system?
– Is it clear what information is being passed in the step?
– Does it "validate" as opposed to "check" a condition?
• Extension Condition
– Can and must the system both detect and handle it?
– Is it what the system actually needs?
• Overall Use Case Content
– To the sponsors and users: "Is this what you want?“
– To the sponsors and users: "Will you be able to tell, upon delivery,
whether you got this?“
– To the developers: "Can you implement this?"
Guide
• Avoid pronouns when there may be more than
one actor
• Avoid adverbs or adjectives
• Avoid negatives
• Describe in present tense format
• Every event should have a meaningful response
• Has to be coherent set of steps
• Subject verb object [propositional phrase]