The fourth assignment is about stacks and deques. In Part A you’ll use a stack to create a simple Calculator application using the stack implementation in Java Collections.In Part B you’ll be testing a flawed Deque implementation that we will be providing to you, with the goal of determining what mistakes the implementer made
Files you will be editing are marked with an asterisk (*).
hw4-student.zip -- exceptions/ EmptyException.java IndexException.java ExampleException.java LengthException.java hw4/ Deque226.java Assignment4.jar Calc.java * tests/ FlawedDeque226Test.java *
These provided files should compile as is. Notice that we have separated the JUnit test files into a subdirectory to make command-line compilation easier. You can compile everything in exceptions from the command line by running
javac -Xlint:all exceptions/*.java. Compiling the hw4 java files will be similar:
javac -Xlint:all hw4/*java. Then you can compile and run the junit files from the same directory using our aliases:
This structure will hopefully circumvent many of the command-line compilation problems people were having with hw3. However, it will make life more difficult for jGrasp people. In jGrasp, your test files and source code are supposed to be in the same folder. You can carefully get around this problem:
package hw4.tests;as originally given.
package hw4.tests;before submitting.
Your first task is to implement a basic RPN calculator that supports integer operands like
-42as well as the (binary) integer operators
%. RPN is the same as post-fix arithmetic expression notation that we discussed in class. The stack underlying your implementation should be the one provided by Java Collections, the documentation for which can be found here. Your program should be called
Calc and work as follows:
?to request that the current state of the stack be displayed (based on toString),
.to pop the top value off the stack and display only that value,
!to exit the program.
Here are two examples for interacting with
Calc that will hopefully help you understand what you’re trying to achieve. First a “slow” example:
> java hw4.Calc ?  10 ?  20 30 ? [10, 20, 30] * ? [10, 600] + ?  . 610 ?  ! >
> is the shell prompt. After starting the program, the first command was
? to print the stack (which is empty at this point, hence
 is the output). Then the user typed
10 followed by
? and we see that the stack now holds that number:
. Now the user typed two numbers
20 30 in sequence before hitting return. When we check the stack now using
? we get the answer
[10, 20, 30] so obviously the “top” of the stack is to the right. Then we see the
* operator being typed, which will pop and multiply the top two numbers, pushing the result onto the stack. We use
? again to check the result:
[10, 600]. This is followed by the
+ operator, which will add the top two numbers. Again we check with
? and get
 as we’d expect. The
. command pops and prints the value
? command then displays an empty stack, and finally the user typed the
! command to quit, returning us to the shell. Here’s the same example, done “fast” this time:
> java hw4.Calc ? 10 ? 20 30 ? * ? + ? . ? !   [10 20, 30] [10, 600]  610  >
As you can see, if the entire sequence of integers, operators, and commands is entered on a single line, they are all executed in order. It’s like having our own little programming language! Finally, here’s an example for the two error conditions described below:
> java hw4.Calc 1 2 blah 1.0 3 ? ERROR: bad token ERROR: bad token [1, 2, 3] + + ?  + + ? ERROR: Not enough arguments. ERROR: Not enough arguments.  ! >
Note in particular that
1.0 lead to error messages but are otherwise ignored (the program doesn’t stop); same for the two
+ operations when the stack only has a single element (the program doesn’t even modify the stack in that case).
Most of these details explain how to use a Stack to evaluation a post-fix expression, similar to the example we worked through in class. More details regarding the special operations are also included.
Stackto hold intermediate results and then repeatedly accept input from the user.
?(that’s a question mark), you print the current state of the stack using its
toString()method followed by a newline.
.(that’s a dot or full-stop), you pop the top element off the stack and print only that value, followed by a newline.
!(that’s an exclamation mark or bang), you exit the program, regardless of the state of the stack.
Note that there are a number of error conditions that your program must deal with gracefully for full credit. We’ll give you two examples for free, you’ll have to figure out any further error conditions for yourself:
blah(or anything else that doesn’t make sense for a calculator as specified above) your program should make it clear that it can’t do anything helpful with that input; but it should not stop at that point.
Of course this means that you’ll have to print error messages to the user. Error messages must be printed to standard error (
System.err) and not to standard out! (Of course, the regular input and output is done through standard in and standard out as usual.) Furthermore, all error messages must start with the string
ERROR:, be exactly one line, and be followed by a newline!**
In your README, document all error conditions you determined and why they are error conditions. Do this by including the inputs that you used to test your program and what error conditions they exposed.
> java hw4.Calc 10 5 - . !
> java hw4.Calc 5 10 - . !
to be different! More generally, if the stake state is
[a, b] and we want to apply the operator
op, it should be equivalent to evaluating
a op b in infix notation. Take a look at the RPN wiki page for more examples.
!is not absolutely required in order to stop the program.
/stands for integer division (DIV) and
%stands for integer remainder.
%to work just as the
%operation in Java. Some languages have different conventions for this (in regards to dealing with negative numbers, since remainder and modulo differ when dealing with negatives), but for this assignment
%is the Java remainder operator.
Calcshould never terminate with an exception. If it does (if our test cases trigger some sort of exception like an
EmptyException), you will be penalized.
Integerobjects yet still do arithmetic like we would on regular
Your second task is to write comprehensive testing for a flawed deque implementation
FlawedDequeImpl.class that we have provided you, with the intention of finding all the bugs and mistakes it contains. Note that we will not be saying how many bugs In particular, we are supplying you with a compiled Java executable that has no attached Java source files, so you are only able to interact with the implementation as a black box. For reference, we also provide the
Deque226.java interface that our implementation implements.
You are going to develop a JUnit 4 tests for your
FlawedDeque226 class. We provide the skeleton code to get you started in
test/FlawedDeque226Test.java. Note that all we really care to test is that an
FlawedDeque226 is a correct implementation of the
Deque226 interface, and that you detect times when it fails to live up to that expectation.
To run against the implementation in the Jar file, simply import it as a library! This can be done in IntelliJ via
File -> Project Structure -> Libraries -> + -> /path/to/jar.
In your README, please give a list of the flaws you uncovered in our implementation and list the JUint 4 tests that uncovered each flaw. For each flaw you identify, please share an educated guess as to what is the mistake that led to the flaw. Also, please discuss the process with which you determined what tests to write? What made this process more difficult?
expectedparameter of the
@Testannotation. One of the example tests we give you shows how to do this properly.
The files you have
// TODO items in are listed explicitly below:
You need to submit all of these files to the autograder along with a README. You can upload them individually or in a zip file. If you upload them in a zip file make sure they are all at the top level, you cannot have any extra directories or else the autograder won’t be able to find them. This even applies to the test file - do not submit it in a tests subdirectory!
Make sure the code you hand in does not produce any extraneous debugging output. If you have commented out lines of code that no longer serve any purpose you should remove them.
You must hand in the source code and a README file. The README file can be plain text (
README with no extension), or markdown (
README.md). In your README be sure to answer the discussion questions posed in this description. You should discuss your solution as a whole and let the staff know anything important. If you are going to be using late days on an assignment, we ask that you note it in your README.
If you want to learn markdown formatting, here is a good starting point.
Once you are ready to submit your files, go to the assignment 4 page for Gradescope and click submit. Note that you can resubmit any time up until the deadline. Only your most recent submission will be graded. Please refer to course policies as far as policies regarding late days and penalties.
After you submit, the autograder will run and you will get feedback on your functionality and how you performed on our test cases. Some test cases are “hidden” from you so you won’t actually know your final score on the test cases until after grades are released. We also include your checkstyle score as a test case.
If you see the “Autograder Failed to Execute” message, then either your submission did not compile at all or there was a packaging error. Please see the Gradescope Submission Notes in Piazza Resources for help debugging why your submission is not working.
You do not need to fully implement each file before you submit, but you’ll probably fail the test cases for the parts of the assignment you haven’t done yet. Also note that only the files with
// TODO items in them will be used. You cannot modify any of the provided interface files as the autograder will overwrite any changes you made with the original provided file.
For reference, here is a short explanation of the grading criteria; some of the criteria don’t apply to all problems, and not all of the criteria are used on all assignments.
Packaging refers to the proper organization of the stuff you hand in, following both the guidelines for Deliverables above as well as the general submission instructions for assignments.
Style refers to Java programming style, including things like consistent indentation, appropriate identifier names, useful comments, suitable
javadoc documentation, etc. Many aspects of this are enforced automatically by Checkstyle when run with the provided configuration file.
privateappropriately, etc.). Simple, clean, readable code is what you should be aiming for.
Testing refers to proper unit tests for all of the data structure classes you developed for this assignment, using the JUnit 4 framework as introduced in lecture. Make sure you test all parts of the implementation that you can think of and all exception conditions that are relevant.
Performance refers to how fast/with how little memory your program can produce the required results compared to other submissions.
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
If your submission does not compile, you will not receive any of the autograded-points for that assignment. It is always better to submit code that at least compiles. You will get freebie points just for compiling.
If your programs have unnecessary warnings when using
javac -Xlint:all you will be penalized 10% functionality per failed part. (You are also unable to use the
@SuppressWarnings annotation - we use it just to filter our accepted warnings from yours.)
If your programs fail because of an unexpected exception, you will be penalized 10% functionality per failed part. (You are not allowed to just wrap your whole program in to a universal try-catch.)