Programming Lab #2:


Assigned: Thu 5 Mar 1998

Due: Thu 19 Mar 1998


General description

For this project you will write a program which:

  • implements stacks, queues and priority queues as instances of an abstract notion of "StorageStructure",
  • reads in commands and numbers from interactive user input,
  • allows the user to create various stacks, queues and priority queues (using Weiss' implementations),
  • allows the user to test the created structures by loading numbers into (and dumping numbers out of) each created structure.

More specifically, you should implement a program which repeatedly reads commands from a command line and performs input, output and structure modifications as specified by the user. The specific command structure is as follows:

  • each command begins with a single code specifiying which command is to be performed (the codes are C, L, T, D and Q, as detailed below). Each command may have several parameters and may cause input to be read or output to be written (on a line or two down from the original command). The parameters will be separated from the command code and from each other by spaces (possibly several in a row).

  • the C command specifies creation of a storage structure with a specified "reference number" and of a specified kind, either stack, queue or priority queue. The reference number will be a single digit, between 0 and 9, and can be thought of as an index into an array of 10 storage structures. Creation of a structure implicitly destroys any former structure with that number (i.e., you can over-write the array slots). The codes for the structures are S, Q and P; thus a typical creation command might look like this:
    
    	C 3 P
    				 
    which creates a priority queue with reference number 3.

  • the L command specifies a structure by reference number and is implemented by loading the structure with positive integer values input from the user, separated by blanks and ending with the sentinel value 0. The values read in should be placed in the structure one after the other using the abstract method tossIn (see discussion below).

  • the T command specifies two storage structures by reference number and indicates that the values stored in the first structure should be extracted (using the yankOut method) and stored into the second (using the tossIn method) one after another, in the order returned from the first structure by the method. The transfer command leaves any existing input in the second structure, and continues until the first structure is empty.

  • the D command specifies a single structure by number and indicates that the indicated structure should have its contents dumped out, one value after another, onto the display, separated by blanks, until the structure is empty.

  • the Q command terminates the program and all user interaction.

  • there is no explicit command for descturction of a structure: they may be implicitly destroyed when over-written by a new structure (in which case all their stored values are lost) and all structures are implicitly destroyed when the program terminates.

  • you should be able to catch a number of errors in command syntax, such as missing parameters, reference number out of range, etc. You may ignore any input characters on a line after the last legal character which is part of the command.

Here is a sample run showing typical input/output (you should feel free to use appropriate introductory text and prompts of your own design):


Welcome to Store-o-Rama, your storage structure service center.
Enter commands one per line, and input values where indicated:

> C 2 S

  [stack in slot 2 created]

> C 4 Q

  [queue in slot 4 created]
  
> L 4

  [input values, stop with 0:]

10 3 6 7 8 5 2 0

  [structure 4 loaded from input]
  
> T 2 4

  [transferred 0 items from 2 to 4]

> T 4 2

  [transferred 7 items from 4 to 2]

> D 2

  [dumping structure 2 to output ...]

  2 5 8 7 6 3 10

> D 2  -- check to make sure 2 is empty

  [dumping structure 2 to output ...]


> Q  -- OK, time to quit (end-of-line text is ignored)

Thanks for using Store-o-Rama, come again soon!
		


Logistics

In order to successfully implement this assignment, you will need access to Weiss' implementations of stacks, queues and priority queues; these can be found in the data structures section of his on-line code library.

More specifically, you will need at least an interface and one implementation for each of the three structures. For example, you could use the QueueAr.java implementation of the the Queue.java interface and the BinaryHeap.java implementation of the PriorityQueue.java interface.

Ideally, you should not need to modify these interfaces or implementations at all in order to use them. If you need to change the behavior of the implementation, it should be done through sub-classing, that is to say, by extending the class. You will at the very least need to extend these classes in order to implement the abstract storage structure interface (see below). A good way to enforce your own comliance with the "no modifications" rule would be to only download the compiled .CLASS files for the implementations you need.

In order to implement the various commands for the storage structures efficiently, you should use the abstract storage structure interface described in class. You can find the relevant files in the directory: ~fruehr/public_html/dsa/code/StorageStructure. The basic idea, as described in lecture, is that the StorageStructure interface gives you a means to implement each of the relevant commands (load, dump and transfer) in an abstract setting, divorced from any particular structure or its implementations. For example, the load command cn be implemented using a loop which repeatedly reads input values until a 0 is encountered, and which uses the tossIn method to put the values into a structure one after another as they are read in. Because you will supply a "glue code" class definition which extends (for example) stacks and implements the StorageStructure interface, if you declare your stack to be of this class, you will be able to access the stack methods by way of the names supplied in the abstract interface.

This access by abstract methods means that you will not have to write different chunks of code to implement the three commands for each kind of structure: rather, you will need only write a single implementation of each command, for the general case, and then invoke the method for different specific structures as needed. Judicious use of typing and type-casting will be necessary to make this all work. For an example of the interaction between interface, implementation class and "glue code", see the DumbStruc and classes in the code directory listed above. A better choice of names might be something like DumbStruc and DumbStrucAsStSt, where the suffix "AsStSt" can be read "As a StorageStructure"; using consistent naming conventions such as this one makes your code easier to understand and develop.

Assessment

Your project will be assessed on the basis of both a "live" demonstration and a hard copy description and print-out of the project code. The printed version should specify both members of your group and should specifically mention any free late days used, remaining problems or bugs, special enhancements, etc. In addition to "raw code", you should include a brief introduction describing anything that is special in your approach to the problem (bugs, enhancements, etc., should also be mentioned here).

Your grade will be determined in part by the correctness of your code, but also by virtue of the techniques you use to implement it. In particular, you should try to avoid revising any of Weiss' code, and you should avoid repetition of code for different structures (i.e., you should use one general implementation for each command, as described above). If you have trouble constructing the classes and interfaces so that this is possible, see me for help.

I will be available in lab on Monday mornings from 10:00 - 11:30 for demonstrations. You may also demonstrate at other times (Thursday morning office hours will likely be popular), including by appointment, but you must demonstrate your project and hand in your hard copy by the due date unless you receive a specific provision otherwise (see also the information about free late days on the syllabus).