OOAD – IIUse Case Analysis

Nupul Kukreja6th 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 ScopeTo 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 orformal 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 5771. Create a domain model2. Keep use cases short (~2 paragraphs i.e., 10-

20 lines)3. Use active voice4. Write an event/response flow (2-col table)5. Use GUI prototypes and screen mockups6. Reference domain classes as is7. Reference ‘screens’ (GUI a.k.a., boundary

classes by name)

ROBUSTNESS ANALYSISDisambiguating Use Cases

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/web-pages. 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 topics2. Collect stakeholders’ win conditions3. Converge on win conditions4. Define glossary of key terms5. Prioritize win conditions on:

Business Value vs. Relative Penalty & Ease of Realization

6. Reveal issues and constraints7. Record issues and options8. Negotiate agreementsAbove 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