Problem set 1

Due Tuesday, February 12 at 1:30pm in class. Total 100 points.

Some general info and advice

Please read the entire problem carefully and think of a general strategy of approaching it before you write any code.

The best way of writing a program is incremental: start with a very simple subset of your program that you can run; write, compile and run this subset; add more code; compile and run again, and so on. I recommend testing a program after adding every five lines of code or less.

Make sure to comment your code. Your comments may be more helpful for readers of your program (including you) if you write them every time you have finished a part of a program: a method, a class, a non-trivial block of code. It also helps to comment any non-trivial line of code right away. Your code will be graded for readability and organization, in addition to correctness, functionality, and efficiency.

For every program please include a brief description of its structure, as well as instructions on how it can be executed, what input it takes, what output it produces, etc. Please submit printouts of sample runs of your program.

Problem 1: case study of commercial web sites (20 points)

Describe any two commercial web sites. You can choose sites that you know well, or any other ones, as long as they are commercial, i.e. sell products or services. You need to specify the following about each of the sites:
  1. Give the site's URL and a brief description of the organization it represents and goods and/or services that it offers. List main parts of the sites (s.a. product page, page for documentation for the products, consumer forums, etc). Also mention if the site requires a membership (i.e. if you need to register to enter or to browse some pages).
  2. Describe the functionality of the site:
  3. Rank the implementation of the site: does it provide all functionality that customers need, or would you suggest adding or changing something?
  4. How would you rank the graphic design of the
  5. What is your overall opinion of the site: did you like it, would you come back to it or recommend it to a friend?
If the two web sites that you have chosen offer similar products or services, you might want to include comparison in your answer.

Problem 2: Java threads and exceptions: threads playing poker (30 points)

Your task for this problem is to write a simulation of a (very simplified) poker game using threads. A poker is a card game where certain 5-card compinations are ranked higher than others. For instance, if you have two of the same kind of cards, s.a. two queens, then you have a pair. If all of your cards are of the same suit, s.a. 5 hearts, then it is called a "flush", and is ranked higher than a pair. Players put some amount of money in the middle of the table, this money is called a pot. Each player gets 5 cards. This is usually followed by betting (putting more money in the pot, i.e. increasing the bet). Players are also allowed to exchange some of their cards to cards in the deck. In the end the player with the highest combination on his hand wins the pot. Here is a brief description of poker rules and the ranking of hands.

In this simulation you are not required to implement betting and exchange. Here are the minimum requirements for your simulation, but please feel free to add more features to make it more interesting.

The game will be played by five players implemented each as a separate thread. A player thread has (at least) two private variables representing the players name and the amount of money that the player has. The program implements a deck of cards as a shared resource, you may need other shared resources (the deck has 52 cards). You need to make sure that after a player takes a card, it is not available for other players.

After the player's threads have been created and their names and initial amounts initialized, the game proceeds as follows:

  1. Each player puts some amount of money as ante.
  2. Each player gets five cards from the deck (at random). The order in which the players get cards depends on the order in which threads get access to the deck, so it may be different for different runs of the program.
  3. When all players have gotten the cards, they compare their hands, and the one with the highest combination wins and takes all the bets. You may implement a small subset of poker combinations, for instance just a pair, three of a kind, four of a kind, and a straight.
The game is repeated until one of the players runs out of money.

You need to print out cards that each player has and the combination (for instance, that it is a pair or a straight), and the amount of money that each player has after each round.

You can also implement other features of poker, s.a. betting and exchanging cards after the first five are given out.

Problem 3: adding a Java exception to the poker program (10 points)

Please modify the previous problem as follows: define an exception that is thrown when there are no more cards in the deck. Test this modification by creating 12 player threads (then there is not enoug cards for each player).

Problem 4: a graphical interface for file reading and writing (40 points)

Write a program that provides a user with a graphical interface for reading and writing files. Your program should be a Java application which uses JFrame to implement a window for dialog with the user. The window must have at least the following:
  1. A way for the user to select "Read" or "Write" option.
  2. A text area where the user types in the file name. The file names are relative to the current directory.
  3. A button "Go ahead" which displayes the next 10 rows of text (when reading a file) or stores the next portion of information into the file (when writing).
  4. A text area with 10 rows and 80 columns for displaying the contens of the file when the user is reading the file and for entering the text when the user is writing data into a file.
  5. An error message text area which displays messages when the file has not been found (when reading), access to the file is denied, the end of file has been reached (when reading), and similar messages. It's a good idea to display these messages in a bold font and/or a different color, s.a. red.
  6. A "Done" button which indicates that the user is finished with the file and the file should be closed. The user may make a different file selection after clicking the "Done" button.
A typical dialog for reading should be as follows:
  1. The user selects "Read" option, types in a file name, and clicks the "Go ahead" button.
  2. If the file is not found or is not accessible, an error message is displayed, otherwise the first 10 rows of text in the file are displayed.
  3. The user clicks the "Go ahead" button again, the next 10 rows of the file text are displayed, and so on, until the end of file is reached. Then the message "End of file" is displayed in the message window.
  4. The user clicks "Done" and may choose another option ("Read" or "Write") and another file. The user may also click the "Done" button before reaching the end of file.
A dialog for writing is similar, except for the following:
  1. If the file with the given name exists, the text gets appended to the end of the file. If the file does not exist, it is created.
  2. When the user attempts to enter more than 10 rows of text at a time, an error message is displayed.
  3. The process continues until the user clicks on "Done" button.
The program should terminate when the window is closed by selecting "close" from the menu in the upper left corner. Note that it is not enough that the window closes, the program should stop, and you should see the LINUX prompt in the shell window from which the program has been started.

Some cool things that you can add to enhance the appearance of the GUI: adding graphics, for instance placing .gif and even annimated .gif files on buttons and labels, adding keyboard mnemonics for buttons, color-coding files when they are displayed in the text area, and so on. These features are not reguired (no points will be taken off if you don't have them), but they are a good thing to know for your project.

The problem will be graded for both the functionality and the appearance of the GUI.


This page has been created and is maintained by Elena Machkasova
Comments and suggestions are welcome at emachkas@wellesley.edu

Spring Semester 2002