In Homework # 1, we gave you a class called ThreeParticles
that animated three particles. This week, you will generalize this
class using a variant of the Sequence ADT from the textbook.
We recommend that you start with our solution to the previous homework
by copying the files from
$CLASSHOME/solution/homework1/
directory, which will be made accessible after the previous homework
deadline has passed.
The ParticleSeq ADT is a variant of the Sequence ADT from the textbook (Figure 3.10 on pages 148-152). The data structure is used in the same way, but some methods are different:
addBefore and addAfter, there
is a single method insert that functions the same as
addBefore except where there is no current item, in which
case it inserts at the end, rather than at the beginning.
addAll, there is a method
insertAll that inserts another sequence before the current
item (if any) or at the end (otherwise).
The first item (if any) of the inserted sequence
will become the current item. If the inserted sequence is empty,
there is no effect.
isCurrent, there is
a method hasCurrent which has precisely the same behavior.
For this assignment, you need to produce a class ManyParticles
that generalizes ThreeParticles. The constructor should take
a ParticleSeq as input rather than three particles.
This class must correctly work for arbitrary sequences and should not
use its own arrays. You will find it necessary to ``clone'' the
sequence so that you can compute the gravitational attraction of every
particle on every other particle. You will also need to
clone it to make sure that the drawing thread does not conflict
with the moving thread. If you do not do so, then every once a while
(after running the program a long time), you will get a strange
exception trace.
Your solution should use the
ADTs at a high level (no use of x() and dx() methods,
for example), in the same way as done in the ThreeParticles class.
The data structure makes use of two integer fields, a boolean field and an array field. There are certain configurations that make no sense. Thus it is recommended to define and check object invariants. See page 123 in the textbook.
There are conventions and Java language features to help you codify
and test the invariant. For this homework, you should implement
the class invariant as a private boolean method named
_wellFormed(). Then the beginning of every public method
should have code as follows:
assert _wellFormed() : "Invariant failed at start";and at the end of any public method that changes any field, there must be the following line, right before the end:
assert _wellFormed() : "Invariant failed at end";We have placed these lines in the code in the skeleton file for your convenience. Do not remove them!
An invariant may be expensive to check. Therefore in Java,
assertions are turned off by default. You should turn them on.
With the command line, this is done by passing the flag -ea
to the java executor.
In Eclipse, assertions are enabled by adding -ea (don't forget
the hyphen!) as a
``VM argument'' on the ``Arguments'' tab of the run configuration.
As mentioned in the previous assignment,
for debugging, you may find it useful to cause an exception to be
thrown when a test fails. In order to get this behavior with our
Test.java class, add -throw in the ``Program Arguments''
section of same ``Arguments'' tab.
Recall that the solution to Homework # 1 is available in
$CLASSHOME/solution/homework1/.
You should grab copies of the three ADTs for use with this assignment.
In the source directory for this assignment,
$CLASSHOME/src/homework2/, we provide the following files:
src). The skeleton file should be placed in the
edu.uwm.cs351 package and then renamed as explained on the last
page of Homework #1.
Before the deadline, you should have the following files in the homework/2 directory of your AFS volume:
homework/2 directory.
The technique was explained at the end of Homework #1.