Com S 362 --- Object-Oriented Analysis and Design HOMEWORK 4: USE CASES AND SSDs (File $Date: 2002/10/09 17:01:49 $) Due: Problems 1-2 on October 7, 2002; Problem 3-4 on October 11, 2002; Problem 5 on October 14, 2002; Problems 6-7 on October 28, 2002. This homework has both an individual and a team part. That is, you should do the individual problems on your own, without directly collaborating with your teammates. The individual part of this homework, problems 1-5, relates to some of the basic concepts and skills we have been discussing in class; in particular, writing use cases and system sequence diagrams. For the problems relating to use cases in this part, read chapter 6 of Craig Larman's book Applying UML and Patterns (Second edition, Prentice-Hall PTR, Upper Saddle River, NJ, 2002). Also read chapter 3 of Martin Fowler with Kendall Scott's book UML Distilled (Addison-Wesley Longman, Inc., Reading, MA, 2000). Finally, as an example look at the web page for the StickSync project: http://www.cs.iastate.edu/~cclifton/courses/sticksync/ 1. (20 points) [Brief format use case "Cancel a Reservation"] Consider a reservation system for an airline. Such a system allows travel agents to make reservations for customers who want to fly on airplanes. Using the brief format, write a use case titled "Cancel a Reservation", which would involve a travel agent talking to the reservation system and a customer. Assume that the customer has an existing reservation that they want to cancel. Be sure your use case is written in an essential, UI-free style (see Larman's section 6.11). You only need to consider the "happy path". Although we'd prefer that these be typed, this can be handwritten if your handwriting is clear. 2. (40 points) [Casual format use case "Check Reservation Status"] Consider again a reservation system for an airline. Using the casual format, write a use case titled "Check Reservation Status". Again in this use case the travel agent is talking to the reservation system and a customer who has called to check on one or more reservations that they may have made. (The customer wants to know that the reservation is in the system.) Consider as alternative scenarios what happens if (a) the reservation does not exist, and (b) a flight in the reservation has been canceled. Be sure your use case is written in an essential, UI-free style. Although we'd prefer that these be typed, this can be handwritten if your handwriting is clear. 3. (70 points) [Fully dressed format use case "Make a Reservation"] Consider again a reservation system for an airline. Using the fully dressed format, write a use case titled "Make a Reservation". If you're unfamiliar with the process of making an airline reservation, you might want to play with an online airline booking system, such as expedia.com. (You can do this without actually buying a ticket if you stop at the point where they want your credit card number.) You should consider at least two alternative scenarios for this use case: (a) the customer requests a destination that does not exist, (b) the customer decides that the price is too high. Be sure your use case is written in an essential, UI-free style. Although we'd prefer that these be typed, this can be handwritten if your handwriting is clear. 4. (10 points) [EBP guidelines] Consider again and airline reservation system. For each of the following, write (i) either "yes" to indicate that this is an elementary business process (see Larman section 6.8), or "no", and (ii) briefly explain why. a. Change seat assignments for an existing reservation. b. Compute the sales tax for a payment. c. Delete a flight from the system (without doing anything else to existing reservations). d. Interpret a keystroke from the travel agent. e. Upgrade a reservation to first class status. 5. (40 points) [SSD for "Playing a Hand of 500"] For this problem read chapter 9 of Craig Larman's book Applying UML and Patterns (Second edition, Prentice-Hall PTR, Upper Saddle River, NJ, 2002). Also read chapter 5 of Martin Fowler with Kendall Scott's book UML Distilled (Addison-Wesley Longman, Inc., Reading, MA, 2000). Finally, as an example look at the web page for the StickSync project: http://www.cs.iastate.edu/~cclifton/courses/sticksync/ Consider the following main success scenario from a casual format use case, the accompanying and glossary. This use case is for playing a hand of the card game "500" (see http://www.wikipedia.org/wiki/500_Card_Game for more information). We imagine that the user is playing on a computer system, where the other 3 players are simulated by the computer. Playing a Hand of 500: Main success scenario: The user asks the System to play a hand. The System deals the cards, and shows the User 10 cards, selected at random and not given to the other three simulated players or the "kitty". The System tells the User the bids for any simulated players to the left of the dealer who are between the simulated player who dealt and the User. The User bids. The System tells the User the bids for any simulated players to the left of the user who have not yet bid. The User has the highest bid, and so the system shows the User the three cards in the kitty. The User tells the System which three cards they would like to discard from the 13 they have. The User then leads to the first trick from the remaining 10 cards. The system plays cards for the other simulated players in order to the left. The player with the highest card takes the trick and leads to the next trick. This continues for the other nine tricks. The User and the User's parter take the number of tricks that were bid or more and so win the hand. The system remembers the number of points corresponding to the bid. Alternative scenarios: The User does not have the highest bid, and so the simulated player with the highest bid picks up the kitty, discards, and then leads to the first trick. The User and the User's parter do not take the number of tricks that were bid, and so lose the hand. Glossary: Bid: saying a number of tricks that will be taken with a given suit as trump (or "no trump" or "nello" or "double nello"). Hand: a round of the game of 500, which consists of dealing, one round of bidding (where each player bids just once), and playing 10 tricks. Kitty: 3 cards not dealt to any player, that are taken by the bidder. Leading to a trick: playing the first card in a trick. Left: players sit in a circular arrangement around a table, so the player to the left of a given player is the one at their left hand. Partner: the player sitting opposite a given player. Taking a trick: having played the high card in a trick. Trick: each player playing a card, with the high card winning. Write a system sequence diagram (SSD) for the main success scenario of the use case above. Note that you're not to diagram the alternative scenarios. Be sure to precisely use the UML notation for SSDs, as shown in the readings. Proper notation will be one of the main criteria for grading on this problem. The other main criteria is a sensible use of the notation. Since we are designing for the application logic layer, your SSD should reflect the interaction between the user interface code (symbolized by the external actor labeled the "User" in the SSD) and the system's application logic layer. That is, you should not have messages like "userButtonPress()" but instead have messages like "startHand()". Thus your SSD, like the use case, should be UI-free. Only use the return line if there are values returned to the user interface (to be shown to the user). Think of each message as the call of a Java procedure in the application logic layer. It is best to draw the SSD by hand. 6. [Elaboration phase, planning] The team part of this homework, below, is part of the first iteration of the elaboration phase of your team project. (We have quite artificially emphasized use cases and SSDs, however.) For this problem, read chapters 5-9 of Craig Larman's book Applying URL and Patterns (Second edition, Prentice-Hall PTR, Upper Saddle River, NJ, 2002). You may also find it helpful to read chapter 20. Also read chapter 3 of Martin Fowler with Kendall Scott's book UML Distilled (Addison-Wesley Longman, Inc., Reading, MA, 2000). Finally, as an example look at the web page for the StickSync project: http://www.cs.iastate.edu/~cclifton/courses/sticksync/ Your task is to create your team project's: a. Use case model. (i) (5 points) List all the names of all the use cases for your project. (This can be an index on a web page with hyperlinks to the use case text if you wish.) (ii) (10 points) Determine a subset of the use cases (and scenarios within these) for your project that you will implement in the first elaboration iteration of your project. You must plan to implement at least two scenarios and also a startUp use case (see Larman, section 17.8). The rest of the elaboration phase will be part of homework 5, and will last two weeks. (iii) (10 points) Briefly justify your team's selection of use cases based on your project's risks. (iv) (60 points) Write all of the use cases from which you are implementing scenarios in this iteration in fully dressed format. (See Larman's book, section 6.6 or go to usecases.org for the format.) Also, even if you are only implementing scenarios from one use case, You must have at least 2 fully dressed use cases. (v) (30 points) Write at least some of the remaining use cases in casual format (see Larman section 6.3). You must write up enough of these so that at least 50% of the use cases in your project are done in either casual or fully dressed format. There must be at least 3 casual format use cases. (vi) (15 points) Write another 25% of the remaining use cases in brief format. That is only 25% of the use cases for your project should have only titles. There must be at least 3 brief format use cases. (vii) (60 points) Write system sequence diagrams (see Larman chapter 9) for all of the scenarios that you are implementing in this iteration. You must have at least 3 SSDs. b. Other requirements: (10 points) Include other requirements artifacts that you find helpful. For example, you may want to write system operation contracts (see Larman Chapter 13) for some of the system operations if they are subtle or complex. You may also want to present a refined supplementary specification or a glossary. If you don't need any other artifacts, write a brief statement as to why and label it "part c". Since you will be both learning a lot of things and trying to accomplish various things on your team's project, it's very important that you don't put off everything until the last minute. However, it is sensible to wait until the individual parts of this homework are due before starting the team part, as that will make sure everyone is up to speed on the ideas and notation. We recommend against drawing SSDs using a tool (like Rational Rose), because you would spend a significant part of your time working with the tool. (However, it's okay if you really want to do this.) Instead we suggest drawing the SSDs by hand; if you wish, scan them in to your project's web site. All of your project's artifacts, with the possible exception of your SSDs, should be on your project's web site. Hand in a print out of these artifacts. 7. Don't forget to hand in the course's "Certification of Individual Contribution and Understanding Form". You can find this form in 3 formats from the course web pages at the URL: http://www.cs.iastate.edu/~cs362/docs/ or on the department machines in the directory /home/course/cs362/public/docs/ The certification form must be printed and signed, you cannot turn that in by email.