Use case and Use Case Diagrams


Published on

  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Use case and Use Case Diagrams

  1. 1. USE CASE AND USE CASE DIAGRAMS<br />AN-MODE<br />July 26, 2010<br />Prepared by: Christine Mae Tavera<br />
  2. 2. INTRODUCTION<br />A house is basically a bunch of walls thrown together to hold up a roof that keeps out the weather. <br />
  3. 3. INTRODUCTION<br />But when you work together with your architect to design your house, you’ll give strong consideration to how you’ll use that house. <br />
  4. 4. INTRODUCTION<br />Reasoning about how you and your family will use your house is an example of a use case-based analysis.<br />The needs of a large family are different from the needs of single adult just out of college. <br />These variations have a great impact on the shape of your final home. <br />
  5. 5. THINK THE HOUSE AS YOUR SYSTEM<br />For many decades, the software industry has depended on functional requirements specifications document to define the software to be developed. <br />“The system shall display all numbers with 2 decimal numbers” <br />“The system shall calculate all numbers to 4 decimal places of accuracy”<br />
  6. 6. BUT HOW THE SYSTEM WORKS IS DIFFICULT TO DETERMINE.<br />What is my goal as a user in using the system? <br />Why do I want to use that system?<br />
  7. 7. USE CASES IS THE ANSWER…<br />Use cases were developed to write functional requirements in a way that emphasizes how the system is to be used. <br />
  8. 8. WHAT IS USE CASE?<br />Describe the functional requirements of the system from the point of view of system users. (Schneider and Winters)<br />Textual descriptions of the functionality of the system from the users’ perspective. (Bennet, McRobb, Farmer)<br />
  9. 9. WHAT IS USE CASE?<br />They show the functionality that the system will provide and which users will communicate with the system in some way that it provides that functionality. <br />
  10. 10. USE CASE SYMBOLS<br />Actor<br />Represented by a stick man.<br />Actors can be people and things. It could even be a system.<br />Who could benefit from the system.<br />
  11. 11. USE CASE SYMBOLS<br />Use Cases<br />Used to represent capabilities<br />Connectors<br />use case connectors are used to indicate how actors and use cases are associated.<br />
  12. 12. USE CASE SYMBOLS<br />Connector Line Styles<br />Plain Line connector<br />Used to show which actors are related to the use cases.<br />Dashed Line with a directional arrow<br />Referred to as a dependency.<br />The arrow points to the use case it depended on. <br />
  13. 13. USE CASE SYMBOLS<br />Connector Line Styles<br />Directed line with hollow triangle<br />Represents generalization or inheritance.<br />We are indicating that the child actor or use case is an instance of the base actor or use case and something more.<br />Arrow points towards the thing on which are expanding. <br />
  14. 14. INCLUDING AND EXTENDING USE CASES<br />Dependency relationship between two use cases means that in some way, the dependent use case needs the depended-on use case. <br />
  15. 15. INCLUDE<br />Means that the dependent use case ultimately is intended to reuse the depended-on use case. <br />The dependent use case will need the services of and know something about the realization of the depended-on use case. <br />
  16. 16. EXTEND<br />Used to add more detail to a dependency; to add more capabilities.<br />
  17. 17. REMEMBER:<br />The include relationship is intended for reusing behavior modelled by another use case<br />The extend relationship is intended for adding parts to existing use cases as well as for modelling optional system services<br />
  18. 18. ANNOTATING USE CASES<br />You can always add text to your UML diagrams.<br />Just use notes sparingly because they can clutter up a diagram and make it harder to read. <br />
  19. 19. ADDING SUPPORTING DOCUMENTATION<br />Continuous narratives. Write a few statements or paragraphs that describe the typical sequences of activities involved in the use case.<br />Partitioned narratives. List in two columns the activities of the actor and the response of the system.<br />Numbered sequence. Write the activities as a series of numbered steps or event flows.<br />
  20. 20. CONTINUOUS NARRATIVE<br />Registered Car Sharer:<br />The car sharer (user) enters his name, address, and phone number into the system. For each journey that he wants to share, the start address, the destination address, the start time and the end time of the journey are entered.<br />
  21. 21. PARTIONED NARRATIVE<br />Registered Car Sharer<br />
  22. 22. NUMBERED SEQUENCE<br />Use Case: Place Customer Order<br />Precondition: The Customer selects Place Order option<br />Main flow of events:<br />1. The customer enters his or her name and address.<br />2. The customer enters a product code.<br />3. The system supplies a description and price.<br />4. The system adds the item price to the total.<br />5. The customer enters credit card payment information.<br />6. The customer selects Submit.<br />7. The system verifies the information, saves the order as pending, and forwards payment information to the accounting system.<br />8. When payment is confirmed, the order is marked confirmed and an order ID is returned to the customer.<br />
  23. 23. LET’S NOW START CREATING OUR USE CASE DIAGRAMS<br />Use case can be likened to a to-do list. <br />Use cases are not only for softwares. They can be used for other things that you want to model.<br />
  24. 24. LET’S NOW START CREATING OUR USE CASE DIAGRAMS<br />Suppose you are preparing a list of chores to prepare your house for an extended visit from your relatives. <br />Dust Living Room – decided that your 10-year old daughter will be assigned to dusting. <br />Dusting has different kinds:<br />Small knickknacks can be dusted with a feather duster<br />Coffee tables and end tables might need dusting spray and clean, dry cloth.<br />Ceiling fans needs the wand and brush of a vacuum cleaner.<br />
  25. 25. LET’S NOW START CREATING OUR USE CASE DIAGRAMS<br />The use case diagram itself need not depict all of the micro task like “Find the dusting spray and clean, dry cloth”<br />
  26. 26. HOW MANY DIAGRAMS IS ENOUGH?<br />20-50 use cases is a reasonable baseline for your use case diagram.<br />But if you know that your problem is complex and you only have 5 use cases, then you may be missing critical functionality. <br />There are no hard and fast rules. <br />Defining the right use cases takes practice and requires good judgement that is acquired over time. <br />
  27. 27. SKI RESORT INFORMATION SYSTEM<br />Users should be able to query weather and snow condition forecasts for a date they enter.<br />The system should allow users to book single-bed or double-bed rooms at the resort hotel “Skier’s Luck” online (with credit card).<br />Visitors should be able to book one-day beginner’s courses on snowboards.<br />There is only one course per day.<br />Each course can accommodate a maximum of 8 students only.<br />The resort offers special courses for kids. The customer has to enter his/her kid’s age to avail of age-appropriate courses.<br />Bookings for courses and/or rooms can be canceled at least 10 days prior to the actual schedule.<br />
  28. 28. Query weather and snow forecast<br /><<include>><br />Book room<br />Submit personal info<br />Book SB course<br />Visitor<br /><<include>><br /><<extend>> (Enter kid’s age)<br />Cancel course<br />Book kid’s SB course<br />Cancel room<br />
  29. 29. SKI RESORT INFORMATION SYSTEM<br />Use Case: Query weather and snow forecast<br />Precondition: -<br />Main flow:<br />Visitor enters date<br />System displays weather & snow forecast for local region for specified date<br />
  30. 30. SKI RESORT INFORMATION SYSTEM<br />Use Case: Book SB course<br />Precondition: -<br />Main flow:<br />Visitor enters date<br />Include (Enter personal info)<br />(Enter kid’s age)<br />System stores reservation details<br />System confirms reservation with Visitor<br />Exceptional flow:<br />If number of course participants for specified date > 8, system informs visitor and allows him to choose another date<br />
  31. 31. SKI RESORT INFORMATION SYSTEM<br />Use Case: Book kid’s SB course<br />Precond: SB course is for a kid<br />Main flow:<br />Visitor enters kid’s name and age<br />System stores booking details<br />System confirms booking with Visitor<br />Exceptional flow:<br />If the course for the specified date is an adult course, system informs the visitor and allows him to choose another date.<br />Exceptional flow:<br />If the course for the specified date is a kids’ course, and the specified age is outside the course’s age range,system informs the visitor and allows him to choose another date.<br />