1. Use Case Modeling

2. Kendall & Kendall© 2005 Pearson Prentice Hall18-2 Commonly Used UML Diagrams The most commonly used UML diagrams are: – Use case diagram, describing how the system is used. The starting point for UML modeling. – Use case (not a diagram). – Activity diagram. Each use case may create one activity diagram.

3. Kendall & Kendall© 2005 Pearson Prentice Hall18-3 Commonly Used UML Diagrams The most commonly used UML diagrams (continued): – Sequence diagram, showing the sequence of activities and class relationships. Each use case may create one or more sequence diagrams. A collaboration diagram is an alternative to a sequence diagram.

4. Kendall & Kendall© 2005 Pearson Prentice Hall18-4 Commonly Used UML Diagrams The most commonly used UML diagrams (continued): – Class diagram, showing classes and relationships. Sequence diagrams and CRC cards are used to determine classes. – Statechart diagram. Each class may create a statechart diagram, useful for determining class methods.

5. Kendall & Kendall© 2005 Pearson Prentice Hall18-5 Overview of UML Diagrams

6. Use Cases Depiction of a system’s behavior or functionality under various conditions as the system responds to requests from users Full functioning for a specific business purpose

7. Kendall & Kendall© 2005 Pearson Prentice Hall18-7 Use Case Diagram A use case describes what the system does, not how it does the work. The use case model reflects the view of the system of the user outside of the system. Symbols are: – Actor, a stick figure. – Use case, an oval. – Connecting lines.

8. UML Use Case Diagram Symbols Use Case Actor Boundary Connection Include relationship Extend relationship >

9. Customer Buy Item Refund a Purchased Item Store System

10. Kendall & Kendall© 2005 Pearson Prentice Hall18-10 Actors Represent role played by one or more users Exist outside of the system May be a person, another system, a device, such as a keyboard or Web connection Can initiate an instance of a use case May interact with one or more use cases and a use case may involve one or more actors

11. Kendall & Kendall© 2005 Pearson Prentice Hall18-11 Actors (Continued) Actors may be divided into two groups: Primary actors supply data or receive information from the system Secondary actors help to keep the system running or provide help – Help desk, analysts, programmers, etc.

12. What is a Boundary? A boundary is the dividing line between the system and its environment. Use cases are within the boundary. Actors are outside of the boundary.

13. Kendall & Kendall© 2005 Pearson Prentice Hall18-13 Use Case Consists of three things: – An actor (user) that initiates an event. – An event that triggers a use case. – The use case that performs the actions triggered by the event.

14. Kendall & Kendall© 2005 Pearson Prentice Hall18-14 Use Case (Continued) Better to create fewer use cases 20 use cases for a large system 50 use cases would be the maximum for a large system Can nest use cases, if needed

15. Use case for a Camera

16. What is a Connection? A connection is an association between an actor and a use case. Depicts a usage relationship Connection does not indicate data flow

18. Kendall & Kendall© 2005 Pearson Prentice Hall18-18 Use Case Relationships Communicates – Connect an actor to a use case Includes (or uses) – Use case contains a behavior that is common to more than one use case. – The common use case is included in other use cases.

19. What is an > Relationship? A connection between two use cases Indicates a use case that is used (invoked) by another use case Links to general purpose functions, used by many other use cases

21. Kendall & Kendall© 2005 Pearson Prentice Hall18-21 Use Case Relationships (Continued) Extends – A different use case handles variations or exceptions from the basic use case. – Arrow goes from extended to basic use case. Generalizes – One thing is more general than another thing. – Arrow points to the general thing.

22. What is an > Relationship? A connection between two use cases Extends a use case by adding new behavior or actions Specialized use case extends the general use case

26. Kendall & Kendall© 2005 Pearson Prentice Hall18-26 Steps for Creating a Use Case Model The steps required to create a use case model are: – Review the business specifications and identify the actors within the problem domain. – Identify the high-level events and develop the primary use cases that describe the events and how actors initiate them.

27. Kendall & Kendall© 2005 Pearson Prentice Hall18-27 Steps for Creating a Use Case Model The steps required to create a use case model are (continued): – Review each primary use case to determine possible variations of flow through the use case. – Develop the use case documents for all primary use cases and all important use case scenarios.

29. Example Use-Case Description

30. Adapted from Larman “Applying UML and Patterns” Use Case Example - Store system

31. Use-Case Description Use case: Buy Item Actors: Customer (initiator), Cashier Type: Primary Description:1. The Customer arrives at the checkout with items to purchase. 2. The Cashier records the purchaseitems and collects a payment. 3. On completion theCustomer leaves with the items. Cross Ref.:Requirements XX, YY, and ZZ Pre-conditions: Cashier must have completed the Log In use-case Success-conditions: Customer has the item, Cashier has the money

32. Use Case Example - Buy Goods CHARACTERISTIC INFORMATION Goal in Context: Buyer issues request directly to our company, expects goods shipped and to be billed. Preconditions: We know Buyer, their address, etc. Success End Condition: Buyer has goods, we have money for the goods. Failed End Condition: We have not sent the goods, Buyer has not spent the money. Primary Actor: Buyer, any agent (or computer) acting for the customer Trigger: purchase request comes in. Buyer Buy Goods Company is out of one of the items Buyer pays directly with credit card Buyer returns goods «extend» Stimuli

33. Buyer Buy Goods Company is out of one of the items Buyer pays directly with credit card Buyer returns goods «extend» Use Case: 5Buy Goods ---------------------------------------- MAIN SUCCESS SCENARIO 1. Buyer calls in with a purchase request. 2. Company captures buyer’s name, address, requested goods, etc. 3. Company gives buyer information on goods, prices, delivery dates, etc. 4. Buyer signs for order. 5. Company creates order, ships order to buyer. 6. Company ships invoice to buyer. 7. Buyers pays invoice. ---------------------- EXTENSIONS 3a. Company is out of one of the ordered items: 3a1. Renegotiate order. 4a. Buyer pays directly with credit card: 4a1. Take payment by credit card (use case 44) 7a. Buyer returns goods: 7a. Handle returned goods (use case 105) Each step take the form ”A does X”, where A is an actor and X is an action. If a use case is included you will find a step that has the form ”include U”, where U is another use case. Extension 3a is execute instead of 3 if condition: ”Company is out of one of the ordered items” is fulfilled!

34. More On Use Cases The last step in a extension can take one of the following forms: – Fail - use case is terminated and goal is not achived – Stop - use case is terminated and goal is achived – Resume N - execution should continue at step N in main success scenario. – If the last step is not one of the above, continue at main scenario.

35. InitiatorReservationMaker GoalReserve room(s) at a hotel Main Success Scenario 1. ReservationMaker asks to make a reservation 2. ReservationMaker selects, in any order, hotel, dates and room type. 3. System provides price to ReservationMaker. 4. ReservationMaker asks for reservation. 5. ReservationMaker provides name, e-mail… 6. System makes reservation and allocates tag to reservation. 7. System reveals tag to ReservationMaker. 8. System creates and sends confirmation by e-mail. Extensions 3. Room not available. a. System offers alternatives. b. ReservationMaker selects from alternatives. 3b. ReservationMaker rejects alternatives. a. Fail 4. ReservationMaker rejects offer a. Fail 5. Customer already on file a. Resume 6 One More Example

36. Member Services Department Past Member Club Member Request Membership rpts Submit subscription renewal Create new subscription program Submit New Subscription Send subscription renewal offer Send new subscription offer Potential Member Member Services System Submit Regular Order Request Sales Reports Submit Promotion Order Marketing Department Create New Seasonal Promotion Create New Monthly Promotion Request Promotion Reports Send Club Promotion Membership System Orders SubSystem Promotions SubSystem

40. Guidelines for Developing Use-Case Descriptions Identify the Major Use Cases 1.Find the system’s boundaries 2.List the primary actors 3.List the goals of the primary actors 4.Identify and write the overview of the major use cases for the above 5.Carefully review the current use cases. Revise as needed.

41. Guidelines for Developing Use-Case Descriptions Expand the Major Use Case 6.Choose one of the use cases to expand 7.Start filling in the details of the chosen use case 8.Write the normal flow of events for the use case 9.If the normal flow of events is too complex or long, decompose into subflows 10.List the possible alternate or exceptional flows 11.For each alternate or exceptional flow, list how the actor and/or the system should react

42. Guidelines for Developing Use-Case Descriptions Confirm the Major Use Cases 13.Carefully review the current set of use cases. Revise as needed. 14.Start at the top again.

43. Term Project Submit the Software Requirement Specification (SRS) Document by April 1 st.