Transcript EC-18_OOAD__II_Use_Case_Analysis

OOAD – II
Use Case Analysis
Nupul Kukreja
6th October, 2014
Agenda
• Domain Modeling – Recap
• Use Cases:
– What, Why and How?
– Formats
– Comparing to user stories
– Use in 577
• Robustness Analysis
– What, Why?
• Case Study in Action:
– Winbook
“Why” Domain Modeling?
• To represent vocabulary and key concepts of
problem domain
• Identifies relationships among all entities
– May sometimes include “attributes”…
– But NO methods
• Provides a “structural view” of the domain
• Describes constraints and scope of the “problem
domain”
• Useful for V&V understanding of problem domain
• Adds precision and focus to discussions
Use Case – “What?”
• Captures a contract between stakeholders of a
system and its behavior
• Describes system’s behavior under various
conditions…
• …as it responds to a request from one of the
stakeholders (a.k.a., primary actor)
• The system responds protecting the interests
of all stakeholders
• Different sequences of behavior/scenarios can
unfold depending on the
Use-Case Scope
To describe:
• A business’ work process
• To focus discussion “about” upcoming system
requirements but not “be” the requirements
• To be the functional requirements for a
system
• To document the design of the system
Might be written in small, close-knit group or
formal setting or large/distributed group
Example: Buy Stocks Online
•
•
•
•
Primary Actor: Purchaser
Scope: Personal Advisors / Finance package ("PAF")
Level: User goal
Stakeholders and Interests:
Purchaser - wants to buy stocks, get them added to the
PAF portfolio automatically.
Stock agency - wants full purchase information.
• Precondition: User already has PAF open.
• Minimal guarantee: Sufficient logging information that
PAF can detect that something went wrong and can ask
the user to provide details.
• Success guarantee: Remote web site has
acknowledged the purchase, the logs and the user‘s
portfolio are updated.
Buy Stocks Online (Cont’d)
Main success scenario:
1. User selects to buy stocks over the web.
2. PAF gets name of web site to use (E*Trade,
Schwabb, etc.) from user.
3. PAF opens web connection to the site, retaining
control.
4. User browses and buys stock from the web site.
5. PAF intercepts responses from the web site, and
updates the user's portfolio.
6. PAF shows the user the new portfolio standing.
Buy Stocks Online (Cont’d)
Extensions/Alternative courses of action:
2a. User wants a web site PAF does not support:
2a1. System gets new suggestion from user, with option to cancel use
case.
3a. Web failure of any sort during setup:
3a1. System reports failure to user with advice, backs up to previous step.
3a2. User either backs out of this use case, or tries again.
4a. Computer crashes or gets switched off during purchase transaction:
4a1. (what do we do here?)
4b. Web site does not acknowledge purchase, but puts it on delay:
4b1. PAF logs the delay, sets a timer to ask the user about the outcome.
4b2. (see use case Update questioned purchase)
5a. Web site does not return the needed information from the purchase:
5a1. PAF logs the lack of information, has the user Update questioned
purchase.
Use-Cases “Why?”
• Gives a more detailed understanding of “what”
the documented process entails
• Easier to understand in “story”/scenario form
than detailed requirements
• Early detection of “failure” responses instead of
at coding time
– May uncover new stakeholders or functions or
business rules!
– Enables detailed estimations of size/complexity, cost,
schedule etc.,
• Usually in natural language making  better
communication/training/on-boarding etc.,
How to Document Use-Cases
•
•
•
•
•
•
Natural language
Sequence diagrams
Flow-charts
Petri-nets
Organization specific
…whatever works for the organization
Plain text / natural language most preferred
Use-Case Formats
• Fully dressed form (previous example)
• Tabular form
– One column (prettifying fully dressed)
– Two column (Column 1: primary actor Column 2:
system response) – used in 577
• Casual Form
– One-two paragraph natural language description
• If-statement style
• Diagrams/graphical notations
• …formats specific to organization (flexible)
Use-Cases vs. User Stories
• Some claim “use-cases” not agile
• User-stories helpful if business expert always
available for fleshing out details
• Both can be used in tandem
– Use-cases  User stories
– User stories  Use cases (we use this)
• User-stories are high level features of intent
with associated goals
– Need to be elaborated into series of steps for
fleshing out the details (i.e., use cases!)
To GUI Or Not To GUI
• Camp 1:
–
–
–
–
–
Keep GUI out of UC descriptions
Use UC as guideline for designing GUI (i.e., how)
Verify that GUI satisfies UC steps
Come up with a UI spec from above
Implement design with corresponding UI spec and UC
description
• Camp 2:
– Keep GUI “in” UC description
– UC == User manual
– Draw UI spec from high level informal UC and create a
‘system usage’ use case description
– Closer to system design
– Used in 577 
Capturing Use-Cases in 577
1. Create a domain model
2. Keep use cases short (~2 paragraphs i.e., 1020 lines)
3. Use active voice
4. Write an event/response flow (2-col table)
5. Use GUI prototypes and screen mockups
6. Reference domain classes as is
7. Reference ‘screens’ (GUI a.k.a., boundary
classes by name)
Disambiguating Use Cases
ROBUSTNESS ANALYSIS
Robustness Analysis: Bridging the Gap
• Robustness diagram is an object picture of the use case
• Correlated: flow of action in RA and steps of UC
description
Robustness Diagram
• Boundary objects: Typically screens/webpages. Interface between system and outside
world
• Entity objects: Classes from domain model
• Control objects: “glue” between the above
(i.e., the functions/communications)
“Why” do Robustness Analysis
•
•
•
•
•
•
•
•
Disambiguating use case descriptions
Uncovers hidden/missed details
Excellent for identifying failure scenarios
Provides ability to “debug” use case text!
Helps identify new/missing domain classes!
Mostly throwaway models
Need to use tools once adept at modeling
Enables easier transition into low level
technology modeling and implementation
(next OOAD lecture)
CASE STUDY IN ACTION – WINBOOK
WinWin Negotiation “Domain”
1. Refine and expand negotiation topics
2. Collect stakeholders’ win conditions
3. Converge on win conditions
4. Define glossary of key terms
5. Prioritize win conditions on:
Business Value vs. Relative Penalty & Ease of Realization
6. Reveal issues and constraints
7. Record issues and options
8. Negotiate agreements
Above steps accelerated by a “shaper”
Winbook User Stories
• As a user I can add a win condition to the
project so that other stakeholders may know
what I want
• As a user I can edit a win condition to fix any
typos and/or remove ambiguity so that it may
be clear for all knowledge contributors
• As a user I can delete a win condition that is
no longer relevant to the project under
discussion
A user writes a win
condition on the
project wall and
clicks ‘post’. The
system adds the win
condition to the list
of win conditions for
the project and
displays it on the
project page
Alternative course:
-Empty win
condition: The ‘Post’
button is disabled
preventing posting of
win condition
A user enters the
their email id and
password on the
login page. The
system checks if the
user is registered by
validating their
account against the
set of registered
users. If the user is
registered he is taken
to the page showing
the list of projects
Alternative course:
-Invalid login/
password: The
system displays
invalid username/
password