1. 9/10/2004Use Case Workshop 1 CSC480 Software Engineering Workshop 1 Requirements Modeling

2. Use Case Workshop2 9/10/2004 Requirements Modeling Use cases  Context diagrams  Actors  Use case formats  Use case lists  Scenarios Exercises

3. Use Case Workshop3 9/10/2004 Why Do Analysis & Design? Communicating with Domain Experts Communication within the development team Learning OO Imagine the scenario in which a customer needs a music box.

4. Use Case Workshop4 9/10/2004 Basic Rules Analysis answers the What-question Design answers the How-question Never do design before analysis Start from a clear description of the concept and think naturally Communicate with your partners intensively Analysis and design are iterative and creative processes: don’t obsess over perfection

5. Use Case Workshop5 9/10/2004 Analysis Activities

6. Use Case Workshop6 9/10/2004 The Restaurant Example Buys lunch Buys dinner Delivers supplies Guest Supplier System border Actor Use case Restaurant

7. Use Case Workshop7 9/10/2004 The Buys Lunch Use Case Basic course of actions A. The Guest enters B. The Guest may leave his/ her coat to the cloakroom C. The Guest is shown a table D. The Guest makes an order E. The food is prepared in the kitchen and beverage picked from the refrig. F. The food is served to the table G. The Guest pays the bill H. The guest gets his/her coat and leaves Alternative courses of actions  Alternative I: if the restaurant is full, the Guest can wait in the bar (to be continued at stage B) or leave (use case completes).  Alternative II: if the dish that the Guest ordered is not served that day, the waiter should recommend an alternative. The use case continues at stage E when the Guest’s decided on sth.

8. Use Case Workshop8 9/10/2004 Scenarios or Alternatives Scenario 1.1.1 Guest get desired selection: no problem Scenario 1.1.2 Restaurant is full: guest waits in bar Scenario 1.1.3 Restaurant is full: guest leaves Scenario 1.1.4 Desired selection unavailable: guest makes alternate choice; guest gets alternate

9. Use Case Workshop9 9/10/2004 Any UserPSP Tools 1. Select Open... 2. Specify a project database and select OK. 3. Open the project database. If an error occurs, display an appropriate error message and end this use case. 4. Enter the user name and optional password and select Login. Select Cancel to end this use case with no state change. 5. Ensure that the username and password (if present) are for an existing member of the database. If not, display an appropriate message and allow the user to be added to the database. If the PSP User decides not to add the new user, end the use case; otherwise, proceed with Alternate Flow of Events: Add New User to Project Database. If there is an existing user, proceed with the next step. 6. Make the database the current database for the user. Close any open database. Display the appropriate view of the data in the project database for this user. Another Format

10. Use Case Workshop10 9/10/2004 Relationships: extend and include Buys dinner Guest Buys a starter Buys dessert Buys candlelight dinner Buys lunch Buys dinner Guest Buys candlelight dinner >

11. Use Case Workshop11 9/10/2004 Use Case A definition by the inventor A use case is a sequence of transactions between the system and an actor yielding a result of measurable value for the actor. Ivar Jacobson

12. Use Case Workshop12 9/10/2004 Why Use Case? A good tool to model what perspective users want and need  Someone or something interact with the system  The system performs a sequence of actions in response  All the use cases together provide a complete answer to: What is the system supposed to do for each user? The use cases drive the development process

13. Use Case Workshop13 9/10/2004 RUP is use-case -driven

14. Use Case Workshop14 9/10/2004 Use Cases: our sources Domain Expert / Subject Matter Experts Problem statement Specification Documentation System users  “Day in the Life...”...

15. Use Case Workshop15 9/10/2004 Use Cases: our tasks How to capture and describe  The “System”  The “Actor(s)”  The “Sequence of transactions” between the system and the actor(s)  The “Result of Measurable Value” for the actor(s)

16. Use Case Workshop16 9/10/2004 The Problem: a vending machine Design a program that simulates a vending machine. Products can be purchased by inserting the correct number of coins into the machine. A user selects a product from a list of available products, add coins, and either get the product or gets the coins returned if insufficient money was supplied or if the product is sold out. Products can be restocked and money removed by an operator.

17. Use Case Workshop17 9/10/2004 Exercise I: Establish the Context Identify the Actors Identify their inputs to and outputs from the system Construct a context diagram

18. Use Case Workshop18 9/10/2004 One Way To... Capture and describe the “System”  Use Context Diagram System Actor 1 Actor 2 Input Output Input Output  Advantage: forces focus on system-level I/O  Disadvantage: enterprise concept not shown

19. Use Case Workshop19 9/10/2004 Capture and Describe the “Actors” “Actors” vs “roles” vs “people”  Originally meant “role” (a mistranslation from Swedish)  An actor usually represents a person in a certain role  Another system interacting with the system of concern may also be an actor Primary vs Secondary actors  It’s possible that multiple actors might be involved in one use case  The actor starting the use case is considered primary

20. Use Case Workshop20 9/10/2004 Use Cases: our tasks What’s left?  The “Sequence of transactions” between the system and the actor(s)  The “Result of Measurable Value” for the actor(s) Approach it in this order: do “... value” 1st  Ties to system level requirements  Easier: “Sequence of transactions” is time consuming

21. Use Case Workshop21 9/10/2004 Heuristics: Use Case Name use cases as “Actor verb Object”  Object is a class in model Guest buys Dinner Teller cashes Check Write in terms of things that will become candidate domain objects (classes) Can be used to divide workload among (teams of) developers or planning iterations

22. Use Case Workshop22 9/10/2004 Organize Use Cases Use the use case diagram Use a use case list  Actor 1 Use case 1.1 name Use case 1.2 name...  Actor 2 Use case 1.1 name Use case 1.2 name... ...

23. Use Case Workshop23 9/10/2004 Exercise II: Identify Use Cases For each of the actors identified in Exercise I, identify their use cases via a Use Case Diagram

24. Use Case Workshop24 9/10/2004 Heuristics: Selecting Use Cases Begin with the key actor Select the key use case  Most important to the success of the project Represents customer satisfaction if completed  Not necessarily most obvious; maybe most common  Completion of this use case represents a measurable, significant part of the system requirements  Implementation of the depth before the breath

25. Use Case Workshop25 9/10/2004 Exercise III: Document Key Use Case Identify the key actor Identify the key use case Provide a description for the key use case