GamePlay Development Document

CSCE 320

With the completion of this use case we will have a basic Gomoku game. This use case starts with the end of
the Matchmaking use case and two client applications connected. One of the clients makes the first move and
play then continues turn-by-turn until one wins, one concedes, or one quits. At the end of the game one client
sends the results to the server.
1. Write use case descriptions:
1. Simple: suitable as a description for a non-technical customer
2. Detailed: suitable as a description for a developer
2. Design classes necessary to support the use case description (UML Class Diagram).
3. Draw a UML Sequence Diagram for the detailed description to validate your class design.
4. Implement and test the use case.
5. Include a section in your document that fully describes the running of the programs.
Pay careful attention to consistency in your development document and code. Be sure that class and method
names are spelled the same throughout. Be sure that other terms are used consistently as well.

Evaluation Rubric each person will be evaluated as follows

A

Weight & Score

Use Case

Well described with detailed steps and clear pre

and post conditions with abnormal cases
identified.

The use case is generally understandable but may be

ambiguous or missing important steps. The
description may be incomplete or the conditions may
not be covered.

The use case is not well described. There are

essential elements that are missing or ambiguous.

Class Diagram

Supports the Use Case well with classes, fields,

and methods clearly derived from the Use Case.
The UML diagram is well drawn and uses
standard notation.

The class diagram is reasonably complete but may be

ambiguous or missing important fields or methods or
associations.
The UML diagram is not well drawn or uses non
standard notations.

The class diagram does not support the use case

adequately. There are essential
classes/fields/methods/associations that are missing
or ambiguous or erroneous.
The UML diagram is poorly drawn.

Sequence Diagram

Each step of the Use Case is clearly identified in

the diagram with methods present in the class
diagram
The UML diagram is well drawn and uses
standard notation.

The sequence diagram is reasonably complete but

may be ambiguous or missing important steps in the
use case. Messages may not match class diagram
methods.
The UML diagram is not well drawn or is not using
standard notation.

The diagram does not follow the steps of the use

case or does not use the methods of the class
diagram.
The UML diagram is poorly drawn.

Implementation & Testing

Good coding practices were used (names,

indentation, javadocs, ).
The use case was tested and documented to work
as specified.

The code does not use good practices in several ways

(poor names, layout, javadocs, ).
The testing is partial and incomplete.

The code is poor in many aspects of practice.

The testing is minimal or poorly documented.

Revisions

Revisions to existing material are clearly

documented and explained.

Revisions have been made but are weakly explained.

Revisions are not clearly documented or explained.

10%

Repository

A source management system is being used to

manage the code for the project. The revisions
are well commented and are frequent throughout
the entire development process.

There is a source management system that holds the

current version of the code and a few previous
versions. The management system is only
occasionally updated.

The source management system is not being used.

20%

Document

Document looks professional with title page,

TOC, bibliography and numbered sections. There
are no spelling or grammar errors and the prose is
clear and well organized.

Document is missing two or more attributes. At most

two or three trivial spelling or grammar errors.

Document does not look professional at all. Weak

phrasing and many spelling or grammar errors.

10%

Evaluations how you

evaluate others

Evaluations of peers is constructive and

informative with a good range of values from
high to low. Evaluation by peers shows you are a
useful member of the group.

Peer evaluations either do not have much range or are

not descriptive. Evaluations by peers shows minor
problems.

Peer evaluations are weak and uninformative.

Evaluations by peers shows some problems.

5%

Evaluations how others

evaluate you

Other members of your group cite specific valued

contributions to the project.

Your evaluations show that you are a constructive

member of the group.

One or more negative evaluations are given.

5%

Group Evaluations
GamePlay

60%

Group Total
Individual Evaluations

Individual Total
Total