Spring Semester 2006: January 30, 2006 - May 5, 2006
Out on:
February 16, 2006
Due by:
February 22, 2006 by 5:59 pm for full credit (11:59 pm for 10% off, hard deadline)
Collaboration:
None
Grading:
Packaging 10%, Style 10%, Performance 10%, Design 20%, Functionality 50%
The third assignment for
600.226: Data Structures
deals mostly with stacks and queues and their applications.
There are no "written" problems for this assignment, but you
may want to include a README file anyway (see
Deliverables below).
Your first task for this assignment is to implement a generic,
unbounded stack using a "growing" array as outlined in lecture
and on the discussion list.
Your class GrowingStack<T> has to implement
the UnboundedStack<T> interface we provide.
You must also write a toString method:
A new stack on which 1, 2, and 3 were pushed in that order should
print as [3, 2, 1] with the "top" element first when
reading from left to right; an empty stack should print as
[].
Finally, your
GrowingStack<T>
class should also have a
main method that performs basic unit testing for
your implementation.
First and foremost your test cases must cover the stack
specification: be sure to test for all the appropriate
pre-conditions and axioms (this includes testing that the
appropriate exceptions are thrown in case of a violated
pre-condition).
However, it is also important to include test cases that
show that the array "grows" correctly; it is easy to get
the code for "growing" wrong, so please make sure that you
actually confirm things to work as expected (i.e. "growing"
the array does not "mess up" your stack).
Here are the necessary interfaces and exception classes,
as well as an (incomplete) implementation of
BoundedStack<T>
called
ArrayStack<T>
that you should study:
stacks.tar.gz
Your second task is to implement a basic calculator that
supports integer operands like "1", "12",
and "-45" as well as the integer operators
"+", "-", "*", and
"/" (that's integer division, no fractions).
Your program should be called Calc and work as
follows:
UnboundedStack<T> to hold
intermediate results and then repeatedly accepts input from
the user after printing a prompt "> ".
?" (that's a question mark)
you print the current state of the stack (using the
toString method you implemented in Problem 1).
." (that's a dot)
you pop to top element off the stack and print it.
!" (that's an
exclamation mark) you exit the
program; if the stack is not empty at this point, print it
one last time.
Note that there are a number of error conditions that your
program should deal with gracefully.
For example, if the user enters blah you should
make clear that you don't know what this is supposed to mean
but otherwise continue.
Also, if there are not enough operands on the stack to
perform an operation you should notify the user but leave
the stack unchanged.
All your error messages must start with the symbol
"?" (that's a question mark) on a new line!
Your last task for this assignment is to design the
necessary interfaces and exceptions for queues (both
bounded and unbounded queues).
You should support the operations
empty,
enqueue,
dequeue,
and front for all queues,
as well as full for bounded queues.
Testing your design requires that you have a working
queue implementation as well:
Develop a class
ArrayQueue<T>
that implements your
BoundedQueue<T>
interface in terms of an array.
Your implementation must support all queue operations
in constant O(1) time.
Of course you should again
provide a toString method to print
the state of an
ArrayQueue<T>
instance as well as a
main
method for unit testing.
Please note that you are free to model all the interfaces, exceptions, and classes for this problem on the code we provided for Problem 1 above. Of course lots of details will be different, but you can certainly reuse the overall structure. Don't forget to document the new interfaces and exceptions to design!
Please turn in a
gzip
compressed
tarball
of your assignment;
the filename should be
cs226-assign-3-login.tar.gz
with login replaced by your Unix login name
on ugradx.cs.jhu.edu
(so I would use cs226-assign-3-phf.tar.gz).
The tarball should contain no derived files whatsoever
(i.e. no .class files, no .html files, etc.),
but allow building all derived files.
Include a README file that briefly explains what your
programs do and contains any other notes you want us to check out
before grading.
For reference, here is a short explanation of the grading criteria.
Packaging refers to the proper organization of the
stuff you hand in, following the guidelines for Deliverables above.
Style refers to Java programming style, including
things like consistent indentation, appropriate identifiers,
useful comments, suitable javadoc documentation, etc.
Simple, clean, readable code is what you should be aiming for.
Performance refers to how fast your program can
produce the required results compared to other submissions.
Design refers to proper modularization and the
proper choice of algorithms and data structures.
Functionality refers to your programs being
able to do what they should according to the specification
given above; if the specification is ambiguous and you had
to make a certain choice, defend that choice in your
README file.
If your programs cannot be built you will get no points whatsoever.
If your programs cannot be built without warnings using
javac -Xlint
we will take off 10% (except if you document a very good reason).
If your programs fail miserably even once,
i.e. terminate with an exception of any kind,
we will take off 10%.
Develop an algebraic specification for the abstract data type
Queue.
Please use
new,
empty,
enqueue,
dequeue,
and front
as your operations.
Consider unbounded queues only (unless you
want to do a bonus bonus problem,
then do bounded queues as well :-).
The central difficulty is going to be modelling the FIFO
(first-in-first-out) behavior accurately; you'll probably
need to use at least one axiom that performs a case distinction.
Please be advised that doing this problem without
resorting to Google can help a lot on the first midterm...
As always, we won't give you extra points for this, but we'll give
you extra kudos. :-)