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.