COMP 111

Lab 5
Scenario
Now you are going to put the finishing touches on the Life Insurance Quotation System
prototype for Tri-State Financial Services. While there is new functionality in
LifeRatesManager, much of what you need to do is to make design improvements in your
code.
Design changes are needed in the LifeRates and LifeRatesManager classes to guard
against potential side effects. These can occur when an object reference is passed into a
method/constructor as a parameter or is the value returned from a method. In modifying your
solution to Lab 4 to prevent such side effects, you can make use of a “copy” constructor in
RateEstimator (available but hidden in the starter project). Its signature is:
public RateEstimator(RateEstimator inEstimator)
This constructor creates a new instance of RateEstimator with the same instance variable
values as the parameter. You will note that a “copy” constructor for LifeRates has been
added and coded for you in the Lab 5 starter project. Rather than “starting from scratch,” modify
your LifeRates and LifeRatesManager classes from Lab 4 to address this design issue.
In the LifeRatesManager class, another design change is to use an ArrayList, rather than an
array, to manage the collection of LifeRates objects. An ArrayList can grow and shrink
dynamically, and, unlike an array, you know how many initialized elements are in the
ArrayList object at any one time (the size of the ArrayList). Thus, you do not need a tracking
variable as you did for the array in the previous project. You can also take advantage of some of
the methods the ArrayList class provides.
Begin with your solution for Lab 4 and make changes to the previous LifeRatesManager class
to work with the ArrayList instance variable.
In addition, code methods to delete an element of the collection (a LifeRates object) by
position and also by name. Add a sortValidRates method to create a new instance of
LifeRatesManager that only contains those elements of the instance variable for which a valid
term rates can be quoted; furthermore, the “valid” LifeRates should be ordered by increasing
term rate (i.e. the object with the lowest term rate calculation is in position 0). Two additional
methods are needed – one to find the LifeRates object with the lowest quoted term rate in the
collection and another method to obtain the object with the highest quoted term rate.
In refining the design of LifeRates and LifeRatesManager, consider how their test classes
need to be modified. Some of the design changes (e.g., the change from use of arrays to
ArrayLists) should require little or no changes in testing (remember the notion of “black box”
testing), but added functionality needs to be tested. Also, consider how to strengthen your
testing in light of what you have learned over the past few months.
You feel that you've done well so far on this project and deserve to get the extended contract for
the production version of the quotation system. However, you decide to successfully complete
this final prototype before you go out and buy that new car you've been daydreaming about. You
head to the coffee machine with requirements in hand.
Notes
 Note that the RateEstimator class:
o Has an additional constructor (the so-called ‘copy constructor’ discussed
previously in this write-up.
o Returns RateUtility.INVALID if the monthly term rate can’t be calculated
(due to invalid demographic data)
 Use a bubble sort (consult the book or reading guide) to perform the sorting in the
sortValidRates method.
 You will need to create an array or ArrayList to do the sorting. Copy LifeRates
objects for which valid term rates can be quoted to your array or ArrayList, sort them,
and then transfer them, in sorted order, to the instance of LifeRatesManager you
return from the sortValidRates method. If there are no valid rates in the collection,
return an “empty” collection (not null, but a collection with zero elements).
 To simplify implementation of getMinTermQuote and getMaxTermQuote , use
sortValidRates to create an ordered LifeRatesManager, then pull out the first and
last elements (respectively).
 The toString method of LifeRatesManager returns a multi-line string listing the
candidate policyholders in the following format:
There are 4 policyholders
1: Doe, Dan (quoted a term rate of 32.0)
2: Kay, Karen (cannot quote a term rate)
3: Lovelace, Ada (quoted a term rate of 74.482)
4: Babbage, George (quoted a term rate of 338.805)
o Note that the numbering in the string starts at 1 (for the candidate policyholder at
position 0)
o Note the output format is different when no valid term rate can be quoted
o If there are no candidates in the collection, only the first line will be included in
the returned string

Assignment
1. A starter BlueJ project will be provided to you. The "shell" for the classes LifeRates,
LifeRatesTest, LifeRatesManager, and LifeRatesManagerTest are provided.
You will need to complete and compile the four classes as specified in the comments within
the code and per the requirements in this write-up. It is recommended that you begin with
your solution from Lab 4 and modify and extend it to meet the requirements of Lab 5.
2. You must use the provided project files and develop the lab within the BlueJ IDE to complete
this assignment.
3. Do NOT change the recommended name, return type, or parameter order/type of any of the
provided class methods. For those methods you code from scratch, use the recommended
method names and appropriate return types and parameter values. These same attributes are
used by Web-CAT to grade your submission, and you will lose points if they are changed or
not as expected.
4. Each class constructor and method should have a corresponding unit test method. As is
customary, the getters for instance variables are tested in the constructor tests. Besides
serving to verify that your code is accomplishing what you intended, writing unit test
methods helps you understand how the objects should behave (how the class methods create,
access, and mutate the object). That is, writing the test methods first helps guide your class
coding efforts.
Follow these steps to complete this assignment:
a. Review the first JUnit test method, completing the code if necessary. Note that
proper testing includes making manual calculations to verify that expected values
for a method action are equivalent to actual results.
b. Once you feel the unit test method is a valid and robust test of the method’s
expected behavior, review the corresponding class constructor or method and
complete the coding if necessary.
c. Obtain a clean compile of both classes.
d. Run the JUnit test for the method. If it does not pass, review and correct the code
for this method.
e. When the test passes, continue in like manner for the next and subsequent
methods, iteratively completing tests and developing your class or classes. All
class methods must be tested.

5. Check your programming style using the “Checkstyle” tool provided within BlueJ (Tools 
Checkstyle).

6. Document the overall project in the README file as directed in the Action Items for the
Lab.

7. Submit your completed lab to Web-CAT using BlueJ (Tools  Submit) and review the Web-
CAT results for errors. Repeat the above steps as needed to resolve any errors.

8. Note that the driver class LifeRatesManagerDriver included in the project file provides
a visual confirmation of correct class behavior. It is not part of the actual solution. You can
modify it if that is helpful to you, but neither your instructor nor Web-CAT will review the
driver class.

9. When you unzip the Lab5 starter project, note that a library jar file for the RateEstimator
class is in the +libs folder. This allows the project access to the methods of RateEstimator
or RateUtility. Although you will not be able to see the source code for
RateEstimator or RateUtility, you will be able to use the documentation contained in
the doc folder underneath +libs to review the support class public interfaces. Open the
index.html file in a browser to view the API for the class.