CSE116 Project Stage 2

Introduction

In this second stage you will extend the functionality of stage 1 in several ways, as outlined below. Note that you will be building your stage 2 functionality on someone else's stage 1, not your own. You get to choose which stage 1 submission to use, from a set of submissions we will provide you with. The codebases you have to choose from are in a CVS repository:

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

The only constraint is that you cannot choose your own, if it appears as one of the choices. 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 1 codebase does not have complete stage 1 functionality you must provide it, in addition to the new stage 2 functionality.

You will continue to work with your Stage 1 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.

Objectives

This is stage #2 of the course project. The main concepts covered are:

• Code reading

You will be working with another team's code for stage 1. You will need to read and understand their code in order to build your stage 2 on top of it. This is a real-world skill which you will likely need to use in other courses during your undergraduate program.

• Graphical User Interfaces

In this stage you will be required to design and implement a graphical user interface using Swing components. In order to do this you must understand how the Swing components relate to each other and also how events and generated and handled in Java.

• Searching

Searching is a very important task in computer science. In this stage of the project you will need to search a large dictionary to determine whether a word is valid or not.

A discussion of searching will also give us an ideal forum for discussing the efficiency of algorithms and how we might compare the efficiency of algorithms.

• Design & Documentation

The importance of design and documentation will be made readily apparent during this round.

New requirements

KnowSys has decided to enhance the game, since initial sales were disappointing. The marketing department has determined that in order to sell well the game really must support multiple players, check words for validity in a dictionary, and must sport a Graphical User Interface (GUI). Note that all stage 1 functionality is expected as well.

GUI

At a minimum the GUI must display the board, the tiles for each player when it is their turn, as well as the scores for each of the players. The GUI must also let the user place words on the board and retract words from the board before committing to the placed word. It is up to you whether placement on and removal from the board is done tile by tile or word by word.

The GUI must also display the total score of the player. When a word is placed, but before the word is committed to, the GUI must display the score of the current placement (i.e. the number of points which will be added to the total score if it is committed to).

Word validation

Words are considered well-formed only if they appear in a dictionary. In our case the dictionary we will use is the ispell dictionary file, which can be found in /projects/CSE116/words.

If a player plays a word which is not in the dictionary the player loses their turn and the tiles which they placed on the board are returned to the player.

Multiple player support

The game must support two to at least six players. First player selection must be implemented as described in the stage 1 description.

All-word scoring

All words formed on a turn are to be scored. In other words, a player's score for a turn is the sum of the scores for all the words formed on that turn, not just that of the primary word formed.

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 Stage2Design.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. Your team contact person is responsible for e-mail your team's minutes to me the day of your recitation.

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, 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.

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-stage2.jar

Note that this is all lower case!

The submission deadline is on or before 11:59.59 PM on Sunday, November 4, 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-2.txt

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

cse116i-peer-smith-2.txt

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