Tuesday, 26 June 2018

Free java Solution


Project Overview
This project will be quite different from our previous projects. Rather than writing production code, you will instead be writing tests in one part and using the debugger in the other. The project is smaller than P4 and our deadline reflects that. There are two main portions:
Problem 1: Testing
The first part of the project focuses on developing the ability to write test cases for an existing class.
In the project pack, a directory called testme contains multiple implementations of a simple system to calculate various salary-related things. One of these implementations is correct, while the remaining ones all contain bugs. You will write test cases based on the provided class documentation to discern which implementation is correct. The correct implementation should pass all tests while the buggy versions should all fail at least one test, likely many more. You will earn credit for each wrong implementation that fails tests (when the correct one is still passing tests!), and for correctly identifying the correct version.
Importantly, you do not have access to the source code for any of the implementations. Instead, you must rely on the documentation of the intended purpose of the classes to develop your tests.
Each implementation is in its own package and subdirectory. Later sections describe how to run your single testing file against any particular implementation without copying files around. (hint: opening and closing files repeatedly in DrJava is not a good workflow).
Problem 2: Debugging
The second part of the project involves developing your skills to trace code and utilize the debugger to follow execution.
The debugme directory of the project pack contains DebugMe.java, a sneaky program which requires a lot of command line arguments to be passed into it to run to completion. The first argument will always be your GMU netID (e.g. gmason76) which will uniquely use the arguments for you in ways different from other students.
DebugMe.java is divided into a series of phases with each requiring different command line input to complete. Your task is to use the debugger, reverse-engineer what is
Project Overview
This project will be quite different from our previous projects. Rather than writing production code, you will instead be writing tests in one part and using the debugger in the other. The project is smaller than P4 and our deadline reflects that. There are two main portions:
Problem 1: Testing
The first part of the project focuses on developing the ability to write test cases for an existing class.
In the project pack, a directory called testme contains multiple implementations of a simple system to calculate various salary-related things. One of these implementations is correct, while the remaining ones all contain bugs. You will write test cases based on the provided class documentation to discern which implementation is correct. The correct implementation should pass all tests while the buggy versions should all fail at least one test, likely many more. You will earn credit for each wrong implementation that fails tests (when the correct one is still passing tests!), and for correctly identifying the correct version.
Importantly, you do not have access to the source code for any of the implementations. Instead, you must rely on the documentation of the intended purpose of the classes to develop your tests.
Each implementation is in its own package and subdirectory. Later sections describe how to run your single testing file against any particular implementation without copying files around. (hint: opening and closing files repeatedly in DrJava is not a good workflow).
Problem 2: Debugging
The second part of the project involves developing your skills to trace code and utilize the debugger to follow execution.
The debugme directory of the project pack contains DebugMe.java, a sneaky program which requires a lot of command line arguments to be passed into it to run to completion. The first argument will always be your GMU netID (e.g. gmason76) which will uniquely use the arguments for you in ways different from other students.
DebugMe.java is divided into a series of phases with each requiring different command line input to complete. Your task is to use the debugger, reverse-engineer what is happening in each phase-method, and determine what command-line arguments are necessary in order to satisfy the phase. When missing or improper inputs are detected in a phase, the program throws exceptions and escapes back to attempt the next phase. You will earn points for each phase that you successfully "defuse".

Project Files

Here is the directory structure in p5pack.zip:
p5pack/
|
+--ANSWERS.txt : Describe written answers to problems in this file
|
+--debugme/
|  |
|  +--DebugMe.java
|
+--testme/
   |
   +--docs/               (javadoc output for an implementation)
   |  |
   |  +--index.html
   |  +--...
   |
   +--PayrollTest.java  (write more tests here)
   |
   +--junit-4.12.jar
   |
   +--imp1/
   |  |
   |  +--payroll
   |     |
   |     +--Dict.class
   |     |
   |     +--Payroll.class
   | 
   +--imp2/
   |  |
   |  +--payroll
   |     |
   |     +--Dict.class
   |     |
   |     +--Payroll.class
   | 
   +--remaining impN/ directories: same structure as imp1/ and imp2/ above
   |
   ...

Problem 1: Test Mode Activated

The first task is to add many @Test-annotated methods to PayrollTest.javaand determine which of the many implementations are bad, and which one is good. Then describe your results in ANSWERS.txt.
The code we're testing out tries to calculate various salary-related things based on employees and their (yearly) salaries. The implementor got a bit carried away and made a very generic Dict<K,V> class to track the (key,value) pairings representing (employee-name, yearly-salary), as part of the calculation.
We linked the Javadoc documentation to this part of the project at the top of this specification. A copy is also included in p5pack/testme/docs. You could locally open up the p5pack/testme/docs/index.html file without being online.
We're only supplying the .class files for each implementation; you don't get to look for the bugs directly, you have to just think about what the purpose of the code is, and then write test cases based on that purpose. (You're writing "black box" test cases).

Running Your Tests

Note that running one test file against many implementations can be tedious if we're not smart about it. A typical (but bad) novice approach is to make many copies of the file which will quickly get out of sync as changes are made to one and the copies are not updated.
Instead, utilize the ability of the compiler and runtime of java to set a class path on the command line to cause a search for classes in the specified locations. Navigate to the testme/ directory and run commands like the following which runs tests on implementation 1 only:
demo$ javac -cp .:imp1/:junit-4.12.jar *.java
demo$ java  -cp .:imp1/:junit-4.12.jar PayrollTest
These commands tell Java that it should first compile all .java files it finds when looking in the current directory (.), in the imp1/ directory, and it should also look through the junit-4.12.jar file while compiling; then, it again needs access to code in all three of those locations, but it should run the mainmethod of PayrollTest.
If you want to run tests on a different implementation, just change the imp1 to a different directory, as in
demo$ javac -cp .:imp2/:junit-4.12.jar *.java
demo$ java  -cp .:imp2/:junit-4.12.jar PayrollTest
For this task, the command line is likely superior to most IDEs. For instance, these commands will not work in DrJava. It's likely that most IDEs will struggle with this task. Take this as an opportunity to beef up your command line skills. It offers the ultimate flexibility and the only price to unlock that is a little practice (on the order of cut-pasting some ready-made commands).

Scripts to run tests

To ease the task of testing on the command line, two scripts are provided which will compile and run all implementations.
On Unix/Mac OS X use the unix-compile-test.sh script in a terminal.
> cd testme
> unix-compile-test.sh
Results of testing all implementations are summarized by only showing how many tests failed (or that it was OK!). If you need to understand why a particualr implementation is behaving some way, then don't use the script here, use the just-one-implementation commands shown above!
On Windows use the windows-compile-test.cmd script in the cmd.exeterminal.
> cd testme
> windows-compile-test.cmd
Results will be left in the results.txt text file due to the lack of a good grepon the Windows platform.

Goals for the Testing Problem

Multiple implementations of the payroll package are provided. One of these is correct while the remainder are crap. It is known that implementations imp2imp8, and imp11 are broken.
To complete this project, do the following:
  • Create enough tests that all implementations but one are failing at least one test.
  • Write tests for both the Dict and Payroll classes. Problems may exist in one, the other, or both.
  • Document your test cases to indicate what they are testing. Part of your grade will be assigned based on the documentation of test cases.
  • Submit your PayrollTest.java file which we will run against all implementations.
  • Identify the general flaws in the behavior of each of the known broken implementations. Describe these flaws in a few sentences in the provided ANSWERS.txt file which will be submitted with your code.

(40%) Grading Criteria for the Testing Problem   GRADING

  • 10% : Identify the correct implementation and report it in ANSWERS.txt. This implementation must pass all of your test cases to get the full 10% credit here. Narrowing to limited candidates gets partial credit. (e.g., if you're not sure which of 2-3 remaining implementations is the correct one, but it is still in those remaining ones, you'll get a bit of credit).
  • 12% : Each faulty implementation fails at least one test in yourP5Tests (1% per implementation). Points might not be earned if all implementations (including the correct one) fail at least one test! That would mean you have bogus tests that definitely aren't correct, themselves.
  • 9% : PayrollTest documents the intent of each test case using clear comments.
  • 9% (3% each) : Flaws in the known broken implementations are adequately described in ANSWERS.txt .

Demo of Dict

The Dict class provides a quite simple dictionary implementation. Below is a demonstration of creating one and calling some of its methods.
> import payroll.*;
> Dict<String,Integer> d = new Dict<String,Integer>();
> d.put("one",1);
> d
{(one:1)}
> d.size()
1
> d.put("two",2);
> d.put("three",3);
> d.size()
3
> d.get("one")
1
> d.get("350")
java.util.NoSuchElementException: "350" key not in dict.
     at payroll.Dict.complainNoKey(Dict.java:147)
     at payroll.Dict.get(Dict.java:70)
> d.pop("two")
2
> d.toString()
"{(one:1),(three:3)}"
> d.keys()
[one, three]
> d.clear()
> d
{}

Demo of Payroll

The Payroll class uses the Dict class in its implementation of some salary-related calculations. Below is a demonstration of some basic uses of Payroll.
> import payroll.*;
> Payroll p = new Payroll()
> p.hire("A",120);
> p.hire("A",120)
> p.hire("B",240)
> p.employees()
[A, B]
> p.topSalary()
240
> p.hire("C",1500)
> p.topSalary()
1500
> p.fire("C")
true
> p.employees()
[A, B]
> p.fire("C")
false
> p.giveRaise("A",0.5)
> p.getSalary("A")
180
> p.giveRaise(1.0) // everyone gets 100% raise!
> p.getSalary("A")
360
> p.getSalary("B")
480
> p.monthlyExpense() // for one month of twelve.
70

Problem 2: DebugMe!

A Programming Puzzle

The file debugme/DebugMe.java is provided in the code pack and contains a puzzle. The main() method in this program accepts a series of command line arguments that, when correctly specified, will cause the program to run to completion. If the command line arguments are not specified correctly, the program will fail prematurely. The purpose of this problem is to determine the correct inputs to cause the program to run to completion.
DebugMe is arranged in "stages" and passing stages earns points. After each run the program prints the points earned based on the stages "passed". Example:
> java DebugMe msnyde14 0 0 0
Let the games... BEGIN!
Phase One, let's have some fun!
 
     Double debugger burger, order up!
 
oops! Game Over... >:( 
 
  * Score: 0/55 pts *
Notice that the first argument is always your NetID. Don't use msnyde14unless you are Prof. Snyder. DebugMe uses your NetID to create a unique set of conditions which you must pass so that your experience with the program will likely be different from other students.
This task is actually kinder to you - if you fail one phase, you are able to continue to the next.
The stages in DebugMe are intentionally obscure. This is code that is meant to be a puzzle rather than easily readable and to that end, you are strongly encouraged to use a debugger while analyzing the program. Debuggers allow you to stop execution at any point and examine variables, step forward line by line, and ultimately identify which kinds of command line arguments will make it through a stage and which will cause the dreaded failure()method to be invoked ending the run. A primary goal of this problem is to gain experience with debuggers as they are incredibly useful tool for a programmer to have in their utility belt. Credit for the problem is entirely based on how many stages are passed.

Command Line Arguments

The only artifact of your efforts will be the specific command-line invocation of the program, as your only inputs are given as command-line arguments.
  • the first command-line argument must be your GMU netID, e.g. gmason76. Many of the phases will use this to randomize and personalize the code for you - you've got your very own unique project!
  • each phase (method) will read the next few arguments (however many it needs), and use them in more and more quirky ways.
  • towards the end of each phase, there will be some check and a guarded call to failure(). Your goal is to figure out what command-line arguments will cause these failures to never happen.
  • if you need to include spaces in a single argument, please use double-quotes.

Running DebugMe through the Debugger

How can we use the debugger with command-line arguments? It's surprisingly easy in DrJava:
  • Compile DebugMe.java
  • Set a breakpoint in the phase you're working on
  • Turn on debugging mode under the debugging menu
  • In the Interactions Pane, run a command like this to launch DebugMewith command line arguments.
> java DebugMe msnyde14 0 0 0
Let the games... BEGIN!
Phase One, let's have some fun!
oops! Game Over... >:( 
 
     error msg: Failure! Double debugger burger, order up!
 
  * Score: 0/55 pts.
If you've turned on debugging, though, you get to step through and see what's happening.
  • Most IDEs have a means of running a program through a debugger. Learn about your tool if you are not using DrJava.
  • For the brave, there is also a command line debugger, command jdbwhich should be installed with every JDK. This is somewhat less convenient as it provides only limited source code display but can work with some classic unix tools.
Regardless of how you access the debugger, you will want to familiarize yourself with features such setting breakpoints to stop the running program, stepping forward line by line, and displaying the values of variables.
DebugMe is not a "real" program as it is intentionally obscure. However, as an exercise to learn how to analyze running programs it will provide invaluable experience. Happy bug squashing.

(60%) Grading Criteria for Problem 2: Debugging   GRADING

  • 55% : In ANSWERS.txt, report your command line after passing as many phases as possible. Paste the entire thing in, including java yourNetID. To complete all phases, a total of 29 command line args including NetID are required.
  • 5% : In ANSWERS.txt describe your experience using the debugger. What helped, what frustrated, and what lessons will you take forward? Limit your description to one to two paragraphs.


Make sure to answer the required questions in ANSWERS.txt. This file is provided as part of the project pack. It is also printed below.
PROBLEM 1: TESTING
==================

(10%) The correct implementation is: (fill in your answer below)

imp #:


--------------------------------------------------------------------------------

KNOWN FAULTY IMPLEMENTATIONS (2, 8, 11)
----------------------------

(3%) Describe the general problems with imp2



(3%) Describe the general problems with imp8



(3%) Describe the general problems with imp11



--------------------------------------------------------------------------------

PROBLEM 2: DEBUGGING
====================

--------------------------------------------------------------------------------
(55%) Include the command line you found to pass as many phases as
possible. Include your NetID at the beginning.  To complete all
phases, a total of 29 command line args including NetID are required.

java DebugMe netID


--------------------------------------------------------------------------------
(5%) Describe your experience using the debugger. What helped, what
frustrated, and what lessons will you take forward? Limit your
description to one to two paragraphs please.





-------------------------------------------------------------------------

+--docs/               (javadoc output for an implementation)
   |  |
   |  +--index.html
   |  +--...
   |
   +--PayrollTest.java  (write more tests here)
   |
   +--junit-4.12.jar
   |
   +--imp1/
   |  |
   |  +--payroll
   |     |
   |     +--Dict.class
   |     |
   |     +--Payroll.class
   | 
   +--imp2/

Project Overview
This project will be quite different from our previous projects. Rather than writing production code, you will instead be writing tests in one part and using the debugger in the other. The project is smaller than P4 and our deadline reflects that. There are two main portions:
Problem 1: Testing
The first part of the project focuses on developing the ability to write test cases for an existing class.
In the project pack, a directory called testme contains multiple implementations of a simple system to calculate various salary-related things. One of these implementations is correct, while the remaining ones all contain bugs. You will write test cases based on the provided class documentation to discern which implementation is correct. The correct implementation should pass all tests while the buggy versions should all fail at least one test, likely many more. You will earn credit for each wrong implementation that fails tests (when the correct one is still passing tests!), and for correctly identifying the correct version.
Importantly, you do not have access to the source code for any of the implementations. Instead, you must rely on the documentation of the intended purpose of the classes to develop your tests.
Each implementation is in its own package and subdirectory. Later sections describe how to run your single testing file against any particular implementation without copying files around. (hint: opening and closing files repeatedly in DrJava is not a good workflow).
Problem 2: Debugging
The second part of the project involves developing your skills to trace code and utilize the debugger to follow execution.
The debugme directory of the project pack contains DebugMe.java, a sneaky program which requires a lot of command line arguments to be passed into it to run to completion. The first argument will always be your GMU netID (e.g. gmason76) which will uniquely use the arguments for you in ways different from other students.
DebugMe.java is divided into a series of phases with each requiring different command line input to complete. Your task is to use the debugger, reverse-engineer what is happening in each phase-method, and determine what command-line arguments are necessary in order to satisfy the phase. When missing or improper inputs are detected in a phase, the program throws exceptions and escapes back to attempt the next phase. You will earn points for each phase that you successfully "defuse".

Project Files

Here is the directory structure in p5pack.zip:
p5pack/
|
+--ANSWERS.txt : Describe written answers to problems in this file
|
+--debugme/
|  |
|  +--DebugMe.java
|
+--testme/
   |
   +--docs/               (javadoc output for an implementation)
   |  |
   |  +--index.html
   |  +--...
   |
   +--PayrollTest.java  (write more tests here)
   |
   +--junit-4.12.jar
   |
   +--imp1/
   |  |
   |  +--payroll
   |     |
   |     +--Dict.class
   |     |
   |     +--Payroll.class
   | 
   +--imp2/
   |  |
   |  +--payroll
   |     |
   |     +--Dict.class
   |     |
   |     +--Payroll.class
   | 
   +--remaining impN/ directories: same structure as imp1/ and imp2/ above
   |
   ...

Problem 1: Test Mode Activated

The first task is to add many @Test-annotated methods to PayrollTest.javaand determine which of the many implementations are bad, and which one is good. Then describe your results in ANSWERS.txt.
The code we're testing out tries to calculate various salary-related things based on employees and their (yearly) salaries. The implementor got a bit carried away and made a very generic Dict<K,V> class to track the (key,value) pairings representing (employee-name, yearly-salary), as part of the calculation.
We linked the Javadoc documentation to this part of the project at the top of this specification. A copy is also included in p5pack/testme/docs. You could locally open up the p5pack/testme/docs/index.html file without being online.
We're only supplying the .class files for each implementation; you don't get to look for the bugs directly, you have to just think about what the purpose of the code is, and then write test cases based on that purpose. (You're writing "black box" test cases).

Running Your Tests

Note that running one test file against many implementations can be tedious if we're not smart about it. A typical (but bad) novice approach is to make many copies of the file which will quickly get out of sync as changes are made to one and the copies are not updated.
Instead, utilize the ability of the compiler and runtime of java to set a class path on the command line to cause a search for classes in the specified locations. Navigate to the testme/ directory and run commands like the following which runs tests on implementation 1 only:
demo$ javac -cp .:imp1/:junit-4.12.jar *.java
demo$ java  -cp .:imp1/:junit-4.12.jar PayrollTest
These commands tell Java that it should first compile all .java files it finds when looking in the current directory (.), in the imp1/ directory, and it should also look through the junit-4.12.jar file while compiling; then, it again needs access to code in all three of those locations, but it should run the mainmethod of PayrollTest.
If you want to run tests on a different implementation, just change the imp1 to a different directory, as in
demo$ javac -cp .:imp2/:junit-4.12.jar *.java
demo$ java  -cp .:imp2/:junit-4.12.jar PayrollTest
For this task, the command line is likely superior to most IDEs. For instance, these commands will not work in DrJava. It's likely that most IDEs will struggle with this task. Take this as an opportunity to beef up your command line skills. It offers the ultimate flexibility and the only price to unlock that is a little practice (on the order of cut-pasting some ready-made commands).

Scripts to run tests

To ease the task of testing on the command line, two scripts are provided which will compile and run all implementations.
On Unix/Mac OS X use the unix-compile-test.sh script in a terminal.
> cd testme
> unix-compile-test.sh
Results of testing all implementations are summarized by only showing how many tests failed (or that it was OK!). If you need to understand why a particualr implementation is behaving some way, then don't use the script here, use the just-one-implementation commands shown above!
On Windows use the windows-compile-test.cmd script in the cmd.exeterminal.
> cd testme
> windows-compile-test.cmd
Results will be left in the results.txt text file due to the lack of a good grepon the Windows platform.

Goals for the Testing Problem

Multiple implementations of the payroll package are provided. One of these is correct while the remainder are crap. It is known that implementations imp2imp8, and imp11 are broken.
To complete this project, do the following:
  • Create enough tests that all implementations but one are failing at least one test.
  • Write tests for both the Dict and Payroll classes. Problems may exist in one, the other, or both.
  • Document your test cases to indicate what they are testing. Part of your grade will be assigned based on the documentation of test cases.
  • Submit your PayrollTest.java file which we will run against all implementations.
  • Identify the general flaws in the behavior of each of the known broken implementations. Describe these flaws in a few sentences in the provided ANSWERS.txt file which will be submitted with your code.

(40%) Grading Criteria for the Testing Problem   GRADING

  • 10% : Identify the correct implementation and report it in ANSWERS.txt. This implementation must pass all of your test cases to get the full 10% credit here. Narrowing to limited candidates gets partial credit. (e.g., if you're not sure which of 2-3 remaining implementations is the correct one, but it is still in those remaining ones, you'll get a bit of credit).
  • 12% : Each faulty implementation fails at least one test in yourP5Tests (1% per implementation). Points might not be earned if all implementations (including the correct one) fail at least one test! That would mean you have bogus tests that definitely aren't correct, themselves.
  • 9% : PayrollTest documents the intent of each test case using clear comments.
  • 9% (3% each) : Flaws in the known broken implementations are adequately described in ANSWERS.txt .

Demo of Dict

The Dict class provides a quite simple dictionary implementation. Below is a demonstration of creating one and calling some of its methods.
> import payroll.*;
> Dict<String,Integer> d = new Dict<String,Integer>();
> d.put("one",1);
> d
{(one:1)}
> d.size()
1
> d.put("two",2);
> d.put("three",3);
> d.size()
3
> d.get("one")
1
> d.get("350")
java.util.NoSuchElementException: "350" key not in dict.
     at payroll.Dict.complainNoKey(Dict.java:147)
     at payroll.Dict.get(Dict.java:70)
> d.pop("two")
2
> d.toString()
"{(one:1),(three:3)}"
> d.keys()
[one, three]
> d.clear()
> d
{}

Demo of Payroll

The Payroll class uses the Dict class in its implementation of some salary-related calculations. Below is a demonstration of some basic uses of Payroll.
> import payroll.*;
> Payroll p = new Payroll()
> p.hire("A",120);
> p.hire("A",120)
> p.hire("B",240)
> p.employees()
[A, B]
> p.topSalary()
240
> p.hire("C",1500)
> p.topSalary()
1500
> p.fire("C")
true
> p.employees()
[A, B]
> p.fire("C")
false
> p.giveRaise("A",0.5)
> p.getSalary("A")
180
> p.giveRaise(1.0) // everyone gets 100% raise!
> p.getSalary("A")
360
> p.getSalary("B")
480
> p.monthlyExpense() // for one month of twelve.
70

Problem 2: DebugMe!

A Programming Puzzle

The file debugme/DebugMe.java is provided in the code pack and contains a puzzle. The main() method in this program accepts a series of command line arguments that, when correctly specified, will cause the program to run to completion. If the command line arguments are not specified correctly, the program will fail prematurely. The purpose of this problem is to determine the correct inputs to cause the program to run to completion.
DebugMe is arranged in "stages" and passing stages earns points. After each run the program prints the points earned based on the stages "passed". Example:
> java DebugMe msnyde14 0 0 0
Let the games... BEGIN!
Phase One, let's have some fun!
 
     Double debugger burger, order up!
 
oops! Game Over... >:( 
 
  * Score: 0/55 pts *
Notice that the first argument is always your NetID. Don't use msnyde14unless you are Prof. Snyder. DebugMe uses your NetID to create a unique set of conditions which you must pass so that your experience with the program will likely be different from other students.
This task is actually kinder to you - if you fail one phase, you are able to continue to the next.
The stages in DebugMe are intentionally obscure. This is code that is meant to be a puzzle rather than easily readable and to that end, you are strongly encouraged to use a debugger while analyzing the program. Debuggers allow you to stop execution at any point and examine variables, step forward line by line, and ultimately identify which kinds of command line arguments will make it through a stage and which will cause the dreaded failure()method to be invoked ending the run. A primary goal of this problem is to gain experience with debuggers as they are incredibly useful tool for a programmer to have in their utility belt. Credit for the problem is entirely based on how many stages are passed.

Command Line Arguments

The only artifact of your efforts will be the specific command-line invocation of the program, as your only inputs are given as command-line arguments.
  • the first command-line argument must be your GMU netID, e.g. gmason76. Many of the phases will use this to randomize and personalize the code for you - you've got your very own unique project!
  • each phase (method) will read the next few arguments (however many it needs), and use them in more and more quirky ways.
  • towards the end of each phase, there will be some check and a guarded call to failure(). Your goal is to figure out what command-line arguments will cause these failures to never happen.
  • if you need to include spaces in a single argument, please use double-quotes.

Running DebugMe through the Debugger

How can we use the debugger with command-line arguments? It's surprisingly easy in DrJava:
  • Compile DebugMe.java
  • Set a breakpoint in the phase you're working on
  • Turn on debugging mode under the debugging menu
  • In the Interactions Pane, run a command like this to launch DebugMewith command line arguments.
> java DebugMe msnyde14 0 0 0
Let the games... BEGIN!
Phase One, let's have some fun!
oops! Game Over... >:( 
 
     error msg: Failure! Double debugger burger, order up!
 
  * Score: 0/55 pts.
If you've turned on debugging, though, you get to step through and see what's happening.
  • Most IDEs have a means of running a program through a debugger. Learn about your tool if you are not using DrJava.
  • For the brave, there is also a command line debugger, command jdbwhich should be installed with every JDK. This is somewhat less convenient as it provides only limited source code display but can work with some classic unix tools.
Regardless of how you access the debugger, you will want to familiarize yourself with features such setting breakpoints to stop the running program, stepping forward line by line, and displaying the values of variables.
DebugMe is not a "real" program as it is intentionally obscure. However, as an exercise to learn how to analyze running programs it will provide invaluable experience. Happy bug squashing.

(60%) Grading Criteria for Problem 2: Debugging   GRADING

  • 55% : In ANSWERS.txt, report your command line after passing as many phases as possible. Paste the entire thing in, including java yourNetID. To complete all phases, a total of 29 command line args including NetID are required.
  • 5% : In ANSWERS.txt describe your experience using the debugger. What helped, what frustrated, and what lessons will you take forward? Limit your description to one to two paragraphs.


Make sure to answer the required questions in ANSWERS.txt. This file is provided as part of the project pack. It is also printed below.
PROBLEM 1: TESTING
==================

(10%) The correct implementation is: (fill in your answer below)

imp #:


--------------------------------------------------------------------------------

KNOWN FAULTY IMPLEMENTATIONS (2, 8, 11)
----------------------------

(3%) Describe the general problems with imp2



(3%) Describe the general problems with imp8



(3%) Describe the general problems with imp11



--------------------------------------------------------------------------------

PROBLEM 2: DEBUGGING
====================

--------------------------------------------------------------------------------
(55%) Include the command line you found to pass as many phases as
possible. Include your NetID at the beginning.  To complete all
phases, a total of 29 command line args including NetID are required.

java DebugMe netID


--------------------------------------------------------------------------------
(5%) Describe your experience using the debugger. What helped, what
frustrated, and what lessons will you take forward? Limit your
description to one to two paragraphs please.





-------------------------------------------------------------------------


No comments:

Post a Comment