CSE116 Project Stage 3

Introduction

In this third and last stage you will create a networked version of the game, as well as add a bit of extra functionality. The networking functionality will be accomplished by using Java's Remote Method Invocation (RMI) facility.

In this third and last stage you will extend the functionality of stage 2 in several ways, as outlined below. Note that you will have the choice of building your stage 3 functionality on someone else's stage 2, or your own. The codebases you have to choose from are in a CVS repository:

           Host: yeager.cse.buffalo.edu
Repository path: /projects/CSE116/Repositories/Fall2007/Stage2CodeBases

Your first task will be to review the available submissions, and choose the one which you feel is best to work from. You should take into account such things as how well documented it is as well as how good the design is. Note that if your selected stage 2 codebase does not have complete stage 1 and stage 2 functionality you must provide it, in addition to the new stage 3 functionality.

You will continue to work with your Stage 2 team unless you are told otherwise.

Remember that if anything is unclear, you should ask your customer. Your customer is easily accessed in lecture, in recitation, in office hours, via email, or on the newsgroup.

New requirements

Note that I have indicated point values for each piece of functionality required. Documentation, unit tests, the functionality fom stages 1 and 2, etc. will in total count for 60 points. If you add up the points below they amount to more than 40 points, which means that you can get more than 100 percent on stage 3. Another way of looking at this is that you do not need to complete all the functionality below to get a perfect score on stage 3.

Network distribution (25 points)

In order to create a distributed version of the game you must use Java's Remote Method Invocation (RMI) facility to allow objects which exist in distinct Java virtual machines to communicate with each other. As part of setting up the communications you will need to run an rmiregistry. To ensure that there are not no conflicts for ports each team will run their own rmiregistry on their own port; team a's port number will be 1100, team b's port number will be 1101, team c's port number will be 1102, and so on.

team	port
A	1100
B	1101
C	1102
D	1103
E	1104
F	1105
G	1106
H	1107

The basic idea is that the core part of the program will run as a game server, and will allow up to four people to play from remote locations. Clients run on their own machines, anywhere on the Internet, and connect to the server to play a game.

More details about how to set up the server and clients, how to determine the number of players, etc., will be discussed in recitation.

This week it is especially important that you attend recitation. This week your primary job is to learn about RMI. The TA's will go over RMI basics in recitation this week.

All the required functionality of stages 1 and 2 must be maintained in stage 3.

Dictionary (15 points)

Searching is a very important task in computer science. In this stage, as in the last, your program must search a large dictionary to determine whether a word is valid or not. In stage 2 you may have used some linear implementation of a collection (such as ArrayList) to represent the dictionary. If so you probably noticed that dictionary lookup (a call to the collection's contains method) was quite slow.

In this stage you will build and use a more efficient data structure, a trie. Also, be sure to write your code so that the location of the dictionary file is not hardcoded into your program. Instead, when the server part of your program is started, the fully qualified file name (i.e. filename including the path to the file) must be accepted as a command-line argument to the program. Note that you cannot in any way modify the dictionary file. Recall that there is a dictionary file in /projects/CSE116/words on the CSE systems.

Special board positions and scoring (15 points)

The real Scrabble game has special positions on the board, such as "double letter score" and "triple word score", which can increase the score of a word when placed over one or more of these positions.

For stage 3 you must incorporate such positions. To keep things easy, imagine that each position on the board has both a letter multiplier and a word multiplier. There are 144 positions on the board. Of these your program must randomly distribute letter and word multipliers to positions as follows:

letter multiplier how many 1 130 2 8 3 4 4 2

word multiplier how many 1 130 2 8 3 4 4 2

Any multiplier that is greater than 1 is used for scoring only for words formed on the turn that a word is first placed over that position. After the turn is finished, both the letter and word multipliers are set to 1.

Documentation

Javadoc and other comments

You must provide Javadoc documentation comments for each class/interface, each method and each instance variable. See the Javadoc tool documentation for details on tags you can use. You must provide at the very least general descriptions of what each class and each method is supposed to do, in addition to providing the @author tag for classes/interfaces (listing everyone who worked on the class/interface, and @param and @return tags for methods. For each instance variable, you need to describe what its role is. (Note that several teams forgot some lessons of CSE115 during stage 1 and declared an enormous number of instance variables, while very few were actually necessary. Keep this in mind, and define instance variables judiciously.) These what comments are mean to be read by developers who need to use your code (including the members of your team!)

You must provide non-javadoc comments to describe how complex methods work. It may be that most of your methods require little or no how documentation - that's to be expected. However, any method whose functioning is not immediately obvious to someone other that its author needs to be documented in this way. These how comments are mean to be read by developers who need to maintain & modify your code (including the members of your team!)

UML class diagrams

You must provide a UML diagram of your final design, using Green. Name your diagram Stage3Design.dia. Do not simply open your whole project using Green to make this diagram. Instead, include the major classes of your submission and arrange them in such a way that their relationships to each other are clear, highlighting any design patterns that you have used.

Team meeting minutes

Provide a record of your team meetings (the meetings you have in recitations), including the agenda for the meeting, attendance, and minutes (who said what, what was actually accomplished). Pick someone on your team to chair each meeting (their job is to keep the meeting on-time and on-track) and someone to be secretary (whose job it is to record what is said - not in exacting detail but in broad brushstrokes). The secretary needs to ensure that a copy of each meetings' notes is placed in your team's repository (put them in a "Minutes" folder). In the next meeting the secretary should chair, and a new secretary should be found. You no longer need to e-mail your team's minutes to me, but you may if there is a particular issue you'd like to bring to my attention.

User's guide

You must provide a short user's manual which describes how to use your program to play the game. This must be in a plain text file only. Do not submit Word files or files in any other format - they will not be graded.

Technical guide

You must submit a technical guide which describes the design of your project, the testing that you have done, any required functionality which your project does not implement or does not implement properly, etc. Note that your technical guide can augment the technical guide that you "inherited" from the stage 1 codebase that you picked. The technical guide must be either a PDF or a Word document.

Note that the codebase you pick may not have all the documentation required for stages 1 and 2. You will need to add all the missing the documentation during stage 2.

Code hygiene

Writing good code is important. Advice: watch for code smells, and refactor mercilessly! The two smells you should watch for in particular are duplicated code and useless code. Duplicated code often results from cut-and-paste coding, and leads to code that is bloated, difficult to understand, and next to impossible to maintian. Useless code is code that is not being used. I've seen plenty of this during office hours: instance variables declared but never used. Methods defined but never called. Classes defined but never instantiated. Use Eclipse to help you. Find callers of methods by highlighting a method name and typing "CTRL+SHIFT+g" - this will pull up a list of all references to the selected method in the workspace. (It is best, when doing this, to have ONLY the current project open. Closing other projects when you're not working on them is a good idea anyway.) If Eclipse says there are no references to a piece of code, chuck it!

Closely related to the useless code problem is the problem of variables being declared as instance variables when they are only ever used as local variables in a single method. Clean this up too!

PRESENTATION REMINDER

Just a reminder that in the last full week of classes you and your teammates will give an oral presentation of your project work and experiences in lecture. You will be able to use the data projector in Baldy 21 to demonstrate your game, show code and/or prepared slides.

Details

• Who: Everyone on your team must have a speaking role in the presentation.
• What: You must present what you've done (current state of your project) and what you've learned working on the project (both in terms of course material and working as part of a team)
• When: The presentation will take place during lecture, in (alphabetical) order of team (i.e. cse116e then cse116f). Each team has 15 minutes for their whole presentation. Of those 15 minutes, you must allow some time for set-up, and for questions. Bank on having about 12 minutes to present.

  Scrabble Presentation Schedule

  Day	Time	Team
  M	1:00 - 1:15	A
  M	1:15 - 1:30	B
  M	1:30 - 1:45	C
  W	1:00 - 1:15	E
  W	1:15 - 1:30	F
  W	1:30 - 1:45	G
  F	1:00 - 1:15	H

• Where: NSC 205
• Why: To give you experience with an oral presentation.
• How: You can use the chalkboards, the data projector, handouts, etc. Use your imagination!
• Grading [Instructor grading sheet] [Audience rating sheet]

Team Submission

Each team must submit one jar file, exported from your eclipse workspace, containing:

• Source code (i.e. include the .java files, properly javadoc'ed (do NOT include .class files), together with .project and .classpath files, and any UML class diagrams you think may be useful for the graders. Note that you must also include your JUnit tests! You are NOT expected to unit test the GUI, but you are expected to unit tests the rest of the functionality of the system.
• Team meeting minutes
• User's guide
• Technical guide

IMPORTANT! Name your jar file with using your team designation as follows. If your team is cse116i, then name your jar file

cse116i-stage3.jar

Note that this is all lower case!

The submission deadline is on or before 11:59.59 PM on Sunday, December 9, 2007. The submission command is "submit_cse116".

Individual Submission

Each member of your team is required to submit a peer evaluation file. You must name your peer evaluation file with the following format:

team-peer-yourLastName-3.txt

For example, if your team is cse116i, and your last name is Smith, then name your peer evaluation file:

cse116i-peer-smith-3.txt

Note that this is all lower case! The submission com mand is "submit_cse116".