Contents:

• Overview
• Collaboration Policy
• Design and Documentation
• Your Task
• Demonstration
• Available Files
• Artifacts to Submit

Topic: Huffman Demo: InputDialog
Due: Sunday, 4 December 2011, 11:59pm

Collaboration Policy

For this assignment, you are allowed to work in pairs (if you are having trouble finding a parnter, please contact me as soon as possible).

Please make sure you adhere to the policies on academic integrity in this regard.

Design and Documentation

As we start to unfurl a comprehensive design for the Huffman project, we will begin by focusing on the mechanism for gathering input from the user, and the collaborations between the top-level HuffmanDemo class and the classes related to the input dialog. We have settled on the following high-level design:

The InputDialog class is a JComponent that manages the GUI interface for gathering user input in a variety of forms. Since the software is event-driven, the interaction will not be finalized until the user clicks a button to submit or cancel. In order to communicate the result to the HuffmanDemo level, we use a listener model based on the InputListener interface. The InputDialog allows for listeners to be registered, and the HuffmanDemo will create such an anonymous listener and register it with the dialog.

The additional complexity in the design is because we wish to use the general input dialog GUI in order to input information in one of three forms: raw text, a table of symbol frequencies, or a table of codewords. We accomplish this by using the Strategy design pattern, allowing the InputDialog to accept a Validator that is used to filter the text entered by the user to see if it matches the desired form, and if so to report the object that results from the parsed input. Furthermore, since both the frequency and codebook formats are based on a two-column table, in which the left column should designate unique symbols, there is a lot of commonality in the parsing and validating. Therefore, we have suggested an abstract TwoColumnValidator that will become a parent class to the concrete FrequencyValidator and CodebookValidator classes.

For more detailed explanations of each class, including detailed signatures for all public methods, we rely on javadocs for the entire project.

For an example of a layout which is very similar to our envisioned InputDialog, please see the microphonePanel of Chapter 5.4 of the text book.

Your Task

Your task is to implement the entire design sketched above, with the exception of the HuffmanDemo class. We will provide a "stub" version of that class with a simple menu system that invokes the input dialog functionality with an appropriate choice of validators, and then displays the resulting return values. You are to adhere to the precise public interface we have outlined for all of these classes, and you must implement all described semantics. An example of a working program is given in the next section.

Demonstration

We provide you with our version HuffmanDemo.java. A copy of this can also be found at turing:/Public/goldwasser/290/inputDialog/HuffmanDemo.java.

Please submit the source code for your entire project exported together into a single .jar file. That jar file must include both the .java files and .class files. In Eclipse, you can build such a JAR file from a project by going to "File -> Export" menu, selecting "Java -> JAR file" as the type, and then on the next screen make sure to select the option "Export Java source files and resources".

You must also include a readme.txt file with your assignment. This file can be brief, but please explain any challenges you faced. When working as a pair, the readme should also provide an overview of the contributions that each team member made to the project. If you create the readme as a file within the eclipse project, please make sure that it is included within the jar file. Alternatively, you may feel free to submit the readme as a separate file from the jar.