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., 10- 20 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)
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)
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