Com S 362 --- Object-Oriented Analysis and Design HOMEWORK 7: DIAGRAMS AND NOTATION (File $Date: 2003/03/27 00:04:53 $) Due: problem 1, March 26, 2003; problem 2, March 31, 2003. This is an individual homework. You should its problems on your own, without directly collaborating with your teammates. 1. (20 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, and the accompanying 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), including queries or messages to the user. Think of each message in the SSD as the call of a Java procedure in the application logic layer. It is best to draw the SSD by hand. 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.) Hand in your system sequence diagram on paper. 2. (50 points) [Domain Model for "Playing a Hand of 500"] For this problem read chapters 10-12 of Craig Larman's book Applying UML and Patterns (Second edition, Prentice-Hall PTR, Upper Saddle River, NJ, 2002). Also read chapter 4 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 again the above use case for playing a hand of the card game "500". Write a domain model (a domain class diagram) that includes the concepts the use case above, including all the alternative scenarios. Be sure to precisely use the UML notation for class diagrams, as shown in the readings. Proper notation will be one of the main criteria for grading on this problem. Don't include methods and don't include visibility links (directional arrowheads) on the association links, as those are reserved for design class diagrams. The other main criteria is a sensible use of the notation to capture the main conceptual classes, associations, and attributes. It is best to draw the domain model by hand. We recommend against drawing class diagrams 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.) Hand in your domain model on paper.