# Ans Doc402

Turn in a printout either at the beginning of class on the due date, or in the bin outside my door later. As a warm-up for writing the Polynomial class for Project 1, write a simple class called Quadratic for representing and using quadratic equations. A quadratic equation is any equation of the form f(x) = ax2 +bx + c (and is just a polynomial with degree 2). Your class will have:
one instance variable: an integer array with exactly 3 slots, one for each coefficient a constructor which takes three integer arguments a, b, and c and stores them in the array, which the constructor creates; a in slot 2, b in slot 1, etc. so the coefficient is at the index that corresponds to the associated power of x one accessor method that returns the coefficient array when called
a method roots that returns a two-element array containing the roots of the quadratic. Use the quadratic equation from algebra.
a method evaluate that returns the result of evaluating the quadratic for any given real number x a method toString that returns a String representation of a quadratic function; for example, the function x2 + 3x – 4 will be represented by the string x^2 + 3x – 4.
Having toString available allows us to pass a Quadratic object to the various System.out.print functions and get readable output.
Include a main method to unit test your constructor and methods. It should create at least three Quadratic objects and call the three methods on various values. As in the project, this method should produce output that completely documents each test and the results, so it is clear at a glance what works and what doesn’t.
Coding and Documentation Requirements
Document the complete specification for each method you develop, including preconditions, postconditions, complexity, and throws clauses if applicable. Pay particular attention to possible errors that these methods can produce if the preconditions on inputs and intermediate computations are not checked. In general you want to throw exceptions rather than produce error messages.
Generate HTML documentation using Javadoc and post it on your hive.sewanee.edu web page.

Part I. The Polynomial ClassConstruct a class for representing polynomials as described in Exercise 13, part (a), page 57 of the text, subject to the modifications given below.Store the coefficients in an array of type double (not int as suggested in the text); the coefficient of the k-th term should be stored in index k of the array. This means the array will be at least as big as the degree of the polynomial, even if the coefficients of some terms are zero. For example, the coefficients of the polynomial x5 + 0.3×3 + 0.5×2 – 0.9x + 5 would be stored as [5.0, -0.9, 0.5, 0.4, 0.0, 1.0]Modify the exercise as follows:
As stated above, the coefficients array will hold items of type double.
The constructorpublic Polynomial(int degree)will create a coefficients array large enough to hold the number of coefficients given by the parameter degree.
The coefficient parameter to setCoefficients will be of type double.Override the methods toString and equals. For example:
The string representation of x2 + 2 should be x^2 + 2
The string representation of x5 + 0.3×3 + 0.5×2 – 0.9x + 5 should be x^5 + 0.3x^3 + 0.5x^2 – 0.9x + 5
Two Polynomial objects are equal if they have the same degree and coefficients.
Part II. Polynomial Test ClassWrite a test program in a separate class file, as described in Exercise 13, part (b). Many software developers advocate documenting test cases first, then using those as a guide in writing the test program.Document test cases for each method (especially evaluate) in a separate file called README.TEST; this gives you something to check against. For example, to test evaluate a test case will consist of:a specific polynomial
the input parameter to evaluate the expected result returned by the method
Test at least 5 different polynomials of various sizes (including just 1 term); for each polynomial, test at least 3 inputs to evaluate (consider a positive value, a negative value, and 0). Test cases must be turned in along with the program. Also, I will be applying my own tests. All test cases (both mine and yours) must pass for full credit. Note: a wise computer scientist once said that tests can show the presence of bugs in a program, but not their absence. There is no such thing as too many test cases. Part III. Inheriting from PolynomialUsing inheritance, create a class that represents a specific family of polynomials used to create the Logistic Map: rx(1 – x) = rx – rx2, where r can be any real number. The only instance variable needed will represent r; initialize it using a parameter in the constructor. Be sure to consider:what should be inherited from the Polynomial class? what should not?
are the access modifiers for instance variables in the superclass appropriate for inheritance?
how will the constructor work?
Add a section of test cases for this type of polynomial to your test docs and your test class.Coding and Documentation Requirements
When writing your project, remember to follow the style guidelines; in particular, include a comment block at the top of each source file giving your name, e-mail address, and project number.
Document the complete specification for each method you develop, including preconditions, postconditions, computational complexity, and throws clauses if applicable.Produce documentation using Javadoc and post it on your web page.
Deliverables
For each project you will turn in these files:a file README containing instructions on how to compile and run your program, where to find your Javadocs online, and a description of any issues or known bugs.
a file README.TEST containing your test cases; show which if any tests did not pass by turn-in time all Java files required to build and run the program(s)
These files are to be turned in as follows: zipped into a single archive file, emailed to me. My system recognizes ZIP, GZ, and TAR files automatically.
Do not include binary files (such as .class files) as sometimes Gmail will flag those as malware and not send them.
In addition, hand in printouts of the source files you developed or modified (even when you e-mail the code) either in the bin outside my office or beginning of next class meeting.