|
|
A Multi-Computer Application
using Remote Method Invocations
The final project may be any sort of non-trivial
application that works on a peer-to-peer (i.e. is symmetrical and has both
client and server capabilities) or client-server connection between
two or more computers. The application must however be
able to run with just two computers even if it is capable of more
simultaneous connections.
The application will use Java's Remote
Method Invocation ("RMI") capablility that makes an object
residing on a remote machine (the "server") appear as a
local object in the local machine (the "client").
Only an interface to the remote object needs to be specified to the
client machine. Look here for more info on RMI.
The class will be divided into several groups
and common storage space on Exciton will be arranged. FTP access and discussion
forums will be set up for each group to exchange
code, ideas and questions. Each group will
be divided into at least three teams of at
most 3 people per team.
Individual teams usually are tasked with specific tasks in the
project. However, having teams create separate implementations
of the same application is also possible. It is crucial however, that each team's task be clearly
identified and communicated to all teams. Post these
tasks on the group web site!
Since the RMI communications is based on the use of interfaces, each
group will need to quickly establish communication interfaces and
protocols. Project success
is directly correlated to the communication skills of the group
members. Posting group decisions,
tasks and common code on the group's web site will make a huge
difference in how well the group does.
Each team will be given a grade that will apply to all the team's
members. The final application and its accompanying
architecture and user manuals will graded on the following criteria:
- 50%
Technical: Does your program do what you say it
does? Does it crash or give erroneous results under
various situations?
- 30%
Architecture: Does your program use good OO design
principles? Is there a minumum of repeated code? Is
it modular with good levels of abstraction, making it easy to
extend or modify?
- 20%
Useability: Is your program easy, straightforward, and
intuitive to use?
To help keep everyone on track on this project,
milestones have been established. Each milestone involves the
submission of written work and often, the demonstration of the work in
progress. Each milestone is approximately one week apart. Only
one submission per group
is required.
The dates below are approximate and will be
adjusted as per the needs of
the class.
- Milestone A, due 11:59 PM, Sunday,
3/4/01: Turn in a
Word document describing the inter-computer interface
specifications and a description of the basic functionality of
application.
- Milestone
B, due 11:59 PM, Sunday, 3/18/01: Turn in a UML
architecture diagram showing the object structure of your
program with explanations of each piece and how it fits into the
system as a whole. Generate full API documentation for
your program, and make it available on your group's web
page. (See Lab
6 for details)
- Mini-Milestone, due 11:59 PM,
Sunday 4/8/01: Turn in code that implements basic
RMI connectivity between two or more computers, and demonstrates
basic functionality of
the application.
- Milestone
C, due 11:59 PM, Sunday, 4/15/01: Turn in a
Word document that is preliminary user's manual with enough
detail to give the reader a basic feel for how the program will
be run. Demonstrate most of the functionality
of your program.
- Milestone
D, due 9:00 AM, Friday, 5/4/01: Demonstrate
full functionality of program, especially the ability to work
with any other implentations or sub-applications developed in
the group. All inter-computer communication should
function almost fully. Commands sent from one machine
to another must trigger some unique operation
related to the application. (i.e. printing out that the
command has been recieved is not
enough)
Final Submission Requirements
The group website must contain the following in an easy-to-find
format:
-
The group members' names
-- You'd be surprised how many groups forget
this one.
-
Working code of
course! -- Zipped up nicely, for sure, with
a link for downloading.
-
Installation
instructions -- Be sure to test your instructions,
so as not to cause excessive pain and suffering to your professor and
grader!).
-
User's manual --
Assume you-know-who's are completely out-of-it and are incapable of
following the simplest of directions.
-
Class documentation --
Complete documentation of all classes and methods. No
"this method does what it is supposed to do" type descriptions! Be
nice and have the docs open up in a new window.
-
Architecture discussion --
Simple but complete discussion of how and why your system
works. Especially pay attention to how your
architecture ensures flexibility, extensibility, robustness and
correctness.
|