CS367 Programming Assignment 1
Why are we doing this program?
Epoch Systems of Anorev, Wi is a leading software firm. It often requires that employees visit customers to discuss implementation and integration issues. Such meetings are often called "Go Jive" sessions. To improve employee morale, Epoch has decided to allow employees to declare a "wish list" of destinations. Travel assignments will be matched against employee preferences (to the extent possible). Epoch is not quite ready to go live — it needs a way to manage employees and their wish lists. It has hired you to start working on a simple prototype.
For this assignment you will write a program that constructs a simple database of employees and wish lists containing destinations encoded as airport identification codes (e.g., MSN or ORD). (Click here for a utility that maps airport names and their three letter codes). Your program will process a text file, specified as a command-line argument, using it to construct an employee database.
For Programming Assignment 1 you will not be building an abstract data type (ADT) from scratch. Instead, you will use Java's ArrayList class to implement the EmployeeDatabase class specified below.
The goals of this assignment are to:
What are the program requirements?
Input text files
Text files storing employees and destinations will be read by your program. Each line in the text file lists an employee (as a username) followed by the destinations (as airport id codes) in that employee's wish list in the following format:
where the employee and destinations 1 through N are sequences of characters excluding commas and spaces (i.e., "," and " "). You may assume that the text files are in the specified format and contain at least one employee. You may also assume that each employee has at least one destination in their wish list and that there are no duplicate destinations within a single employee's wish list (see this sample input file for an example). You may also assume that employee usernames and airport id codes are unique* and are to be represented by your program as lower-case Strings. *Note: for both employees and airport id codes, differences in capitalization should be ignored, e.g., UGM2017, ugm2017, and Ugm2017 should all be considered the same and represented in the database as ugm2017.
Note: employees are to be added to the employee database in the order in which they appear in the text file.
The Employee class
An Employee class is provided for you (see Employee.java). The Employee class represents a single employee. It keeps track of a username (as a String) and the airport id codes in the employee's wish list (as a List of Strings). The Employee class has the following constructor and methods:
You may not modify the Employee class. If you need to make a change to the wish list a particular employee has, use getWishList() to get the list of airport id codes in the employee's wish list and then use list operations to add, remove, etc.
The EmployeeDatabase class
The EmployeeDatabase class stores the employees. The EmployeeDatabase class has the following constructor and methods (do not add any additional public methods other than those listed below):
For the internal structure of the EmployeeDatabase class, you may write your own ArrayList class or use Java's ArrayList class that implements Java's List interface. You must also make use of Java Iterators where appropriate (i.e., whenever you need to traverse a list). You may also write additional helper classes to be used by the EmployeeDatabase class.
Note: in addition to the information given in the table above, your EmployeeDatabase class will need to be able to recognize null parameter values and, when a null parameter value is passed, throw a java.lang.IllegalArgumentException.
The InteractiveDBTester class
The InteractiveDBTester class creates and tests an EmployeeDatabase that represents information about employees and wish lists. Employee and wish list information is read from a text file (explained above) using the method populateDB. The class also contains a variety of methods used to test the database.
This assignment must make use of Java Iterators where appropriate (i.e., whenever a list is traversed).
The InteractiveDBTester.java file contains the outline of the InteractiveDBTester class. Download this file and use it as the starting point for your InteractiveDBTester implementation.
The populateDB method of the InteractiveDBTester class does the following:
The InteractiveDBTester class also contains a number of methods of the form
pushXXX. Each method implements a particular testing command.
For example pushList() implements the List command, which lists the current contents of the employee database.
Note that these methods (in final form) do not do any printing.
Rather, they retuen a String representing the result of the command.
The reason for this is that these testing commands will be used in a GUI-based database tester. GUIs do not use print statements.
Rather, they use methods to place text within a "text box" that may be placed anywhere in
a GUI interface. The text box may specify not only the text itself, but also its font, size and colour.
The testing commands we will use are:
A Graphical Test Interface
Graphical User interfaces (GUIs) are widely used to interact with programs. They easy to use and need little documentation. A GUI testing interface for our employee database is shown below. This tester is implemented in class GUItester (see GUItester.java). You need not change anything in this class. GUItester is a subclass of InteractiveDBTester. It inherits your definition of the pushXXX commands and the populateDB method. You start execution with the GUItester class. It calls populateDB to read in the initial employee database. It then creates the GUI shown to the below. When you click on a button, the corresponding pushXXX method is called. Input parameters are typed in the text box to the right of the command button. Output is displayed in the large text box at the bottom.
Thus if you click the "List DB" button, the pushList() method is called. It determines the employee database's contents, and places the information in the large text box at the bottom. To terminate testing, you simply click on "Quit."
Recall that in Java, when you run a program, it is a main method that runs. The main method always has the following header:
public static void main(String args)
The array-of-Strings parameter, args, contains the command-line arguments that are specified when the program is run. If the program is run from a command prompt (i.e., not from a programming environment like Eclipse), the command-line arguments are simply typed after the name of the class whose main method is to be executed. For example:
java GUItester employeeData.txt
runs the Java interpreter on the main method of the GUItester class, passing the string "employeeData.txt" as the command-line argument.
main passes the file name to populateDB which reads the file and creates the employee database to be tested.
To use command-line arguments when you run a Java program using Eclipse:
After the command line file is set, you can run your program by simply right-clicking "Run" on the source file you want to run. If you want to use a different file to create your database, you simply redo the above steps.
A Text-based Test Interface
GUI interfaces, while popular, can be problematic. Quality assurance teams must thoroughly test a program before it is released. This may involve hundreds or thousands of tests. Running so many tests by hand is tedious and error-prone. But how do we automate a mouse-click?
One approach is to represnt testing commands as text, with one command per line. Thus rather than entering the name Waldo in a text box and clicking the Find button, we simply enter the line:
Each text command can be abbreviated with its first character. Also, case is insignificant. Thus quit, QUIT, Quit, Q and q all terminate testing. The command gui is also implemented. It changes testing from the text based interface to the GUI interface. (The GUI tester has a button "Text interface" that changes testing from the GUI interface to the text interface.)
One of the advantages of the text interface is that testing commands can be read from a file rather than entered by hand, one by one. Similarly, the output of a testing session can be stored in a file rather than displayed on the console screen. Thus a quality assurance tester can store a standard set of test commands in a file. The output is saved in a file and then compared against an "expected results" file. This makes thorough testing much more convenient. (This is how we will test your solution to this project.)
At the command line level, adding file names for input and output data is quite simple:
java Texttester employeeData.txt < myInput > myOutput
Texttester is run with employeeData.txt as the command line argument. Input is read from myInput and output is written to myOutput.
In Eclipse (version 4.5 or later):
Unfortunately, not everyone can click a mouse or read a display. It is important to design interfaces that allow the fullest range of individuals to use an application. Screen readers convert characters on a screen into speech (or Braille). Voice recognition systems (like Apple's Siri or Amazon's Alexa) convert speech into text. These tools could be used with our text interface to enhance accessibility to our employee database. For example, a user could issues voice commands that are translated into text and fed to the employee database as characters in System.in. Characters written to System.out would be translated into voice form. A lot of development work would be needed, but such an enhanced interface is clearly feasible
How to proceed
After you have read this program specification and given thought to the program design we suggest the following steps:
What should be handed in?
Electronically submit the following files to the Program 1 Dropbox on Learn@UW:
Please turn in only the files named above. Extra files clutter up the "handin" directories.
|Last Updated: 8/8/2017 © 2017 Beck Hasti and Charles Fischer|