Spring Semester 2006: January 30, 2006 - May 5, 2006
Out on:
March 3, 2006
Due by:
March 10, 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 fifth assignment for
600.226: Data Structures
deals mostly with trees.
There are no "written" problems for this assignment, but you
may want to include a README file anyway (see
Deliverables below).
This is probably the biggest assignment so far, I strongly
recommend starting early!
Your first task for this assignment is to implement a
generic tree
LinkedTree<T>
as outlined in lecture.
The archive below contains a number of interfaces and
exceptions you will need.
As is to be expected,
LinkedTree<T>,
has to implement the
Tree<T>
interface we provide.
You have to implement the
Position<T>
interface as well; the class you write for this
purpose should be nested inside
your
LinkedTree<T>.
You can use the Java classes
java.util.List<T>,
java.util.ArrayList<T>,
and
java.util.LinkedList<T>
for this problem if you want to;
you must use the Java classes
java.util.Iterator<T>,
and
java.lang.Iterable<T>
for the obvious reasons (see interfaces below).
You should provide a toString() method in addition
to those defined in the
Tree<T>
interface.
The string you return should list the elements of the tree as
they would be processed during a pre-order traversal, otherwise
the format is similar to previous assignments. For example,
[] is the empty tree and [1, 2, 3]
is the tree with 1 at the root and 2
"before" 3 in 1's list of children.
Your
LinkedTree<T>.
class should also have a
main() method that performs basic unit testing for
your implementation.
Be sure to test all methods, including the
behavior of traverse().
Also, be sure to test that the correct exceptions are thrown
in error situations.
Here are the necessary interfaces and exception classes: trees.tar.gz. Warning: This is a new assignment and there may be serious bugs in these interfaces. If you think you found a bug, please email the course staff about it immediately. Thanks!
Your second task for this assignment is to write a simple
file system simulation called DOS.java for
the obvious historical reasons.
You will use a
Tree<T>
to keep track of the layout of a simple file system in which
all entries are either files or
directories.
The initial tree has a single directory called /
(that's simply a slash character) as its root, and the initial
position inside the file system (our "current directory")
is the corresponding node in the tree.
The user can issue the following commands to interact with the
simulation (where "name" stands for any sequence of the upper-case
and lower-case letters; the only "special" name is ".." for the
parent directory):
ls:
print the names of all entries (files and directories)
in the current directory, in alphabetical order; for
directories, print a "/" character at the end of the
actual name
cd name:
make "name" (which must be a directory) the current directory;
if name is ".." go up to the parent directory of the current
directory; the parent of / is / (as
in Unix); it's an error to cd into a non-existant
directory or into a file
mkdir name:
create a directory called "name" in the current directory; it's
an error to create a directory with the name of an existing
entry
rmdir name:
remove a directory called "name" from the current directory;
it's an error to remove a non-empty directory; it's an error
to remove a file with this command; it's an error if no directory
"name" exists
mk name:
create a file called "name" in the current directory; it's
an error to create a file with the name of an existing entry
rm name:
remove a file called "name" from the current directory;
it's an error to remove a directory with this command;
it's an error if no file "name" exists
pwd:
print the absolute path to the current working
directory (see below for an example)
quit:
exit the program, stop the simulation
Here is a sample interaction with the simulator, for your edification
while developing the simulator; note that > prompts
and the format of the error messages:
> ls > pwd / > cd .. > pwd / > mkdir tst > ls tst/ > mkdir bla > ls bla/ tst/ > rm bla ? error: bla is a directory, use rmdir instead > rmdir bla > ls tst/ > cd tst > pwd /tst > ls > mk bla > ls bla > mkdir hey > ls bla hey/ > cd hey > pwd /tst/hey > quit
You will have to make quite a few design decisions by yourself
to make this work.
You should probably write classes
Entry, File, and Directory,
all of which you store
inside a Tree for the simulation...
Good luck!
Please turn in a
gzip
compressed
tarball
of your assignment;
the filename should be
cs226-assign-5-login.tar.gz
with login replaced by your Unix login name
on ugradx.cs.jhu.edu
(so I would use cs226-assign-5-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%.
Add support for modification times to the file
system simulation.
The initial modification time for a file or directory is the time
when it was created using mkdir or mk.
Creating a file or directory also changes the modification time of
the current directory, which means that all
directories above the current one also change
their modification times.
Include modification times when listing directories with ls.
There are many other possible extensions, you're free to add even more
stuff if you feel like it.
Just be careful not to change the required behavior
for Problem 2 above!
As always, we won't give you extra points for this,
but we'll give you extra kudos. :-)