代写 ITECH2100/6100
100%原创包过,高质代写&免费提供Turnitin报告--24小时客服QQ&微信:120591129
代写 ITECH2100/6100
Page 1 of 5
ITECH2100/6100
Week 3 Lab
Encapsulation, Object State,
Testing and Debugging
Note: This practical is assessable. All work must be submitted. You also must attend an
interview with the marker - the marker will tell you the details of when this will be.
Due: You have the opportunity to work on it in class during week 3, but must submit it to
Moodle by 11:59PM on the evening of the day prior to your week 4 lab class.
Submission after that time will incur lateness penalties, of the subtraction of 10% of the
total marks available per day 1 that it is late, from the value that the work is worth.
Submission instructions are found towards the end of this document.
Cut-off: The cut-off date, after which no submission will be accepted for assessment, is 7 days
from the original due date/time.
Assessment Value: 10% of final course mark.
The work you submit must be your own individual work.
Objectives:
By completing all tasks in this week’s lab, you should have consolidated your understanding of
topics such that you are able to:
Code classes to ensure that objects will always have a valid state;
Ensure that classes have an appropriate toString() method;
Understand the significance of the ‘static’ modifier;
Be able to design test cases to test methods of a class to ensure it behaves according to its
intention
Be able to arrange test cases into a test plan in order to thoroughly and adequately cover all
key aspects of a class;
Write a test driver to execute the test plan; and
Be able to use Eclipse’s debugging tools to set breakpoints, inspect variables, and step
through code to observe the behaviour of code to detect errors
1 using each midnight as marking the start of each new day
Page 2 of 5
Tasks
Stage 1:
Start a new Java Project named lab03-A.
Create a class named BankLoan which will represent information about a loan a person wants to get
from the bank, to purchase a car, a house, or some other expensive item, and they will pay back
gradually over time.
The BankLoan will have the following states (which the subsequent tasks will explain what you
need to code), and will allow the described actions during each state:
Application – in this state, the amount desired to be borrowed can be set and altered
Assessment – in and after this state, the amount desired to be borrowed cannot be changed
any more. In this state there can be disapprovals, i.e. reasons provided why the loan should
not be permitted (e.g. because of bad credit ratings)
Rejected – in this state, nothing more can be done to the BankLoan, you can only access the
information about the application and subsequent rejection.
Approved – in this state, you can take the money, or cancel by closing the loan.
Paying Back – in this state, you cannot take any more money, but you can make payments
back and have interest applied on the outstanding amount.
Closed – once all the money owed has been paid, nothing more can be done to the
BankLoan, you can only access the information about the historic facts.
1. Ensure the class contains definitions for the following attributes:
The full name of the person applying for the loan
A description of what they want the loan to be for (e.g. to buy a car)
The amount the loan will be for. Note, the maximum loan that someone can apply for is
$10 million – so the data type must be appropriately chosen to allow for this.
The amount which remains unpaid – over time this value will vary somewhere between the
value of the previous attribute, and zero.
A string for storing any ‘notes’ about the loan (such as reasons for rejecting an application).
An attribute to “know” what state the BankLoan is currently in, which can be assigned a
value of one of the constants (see next task)
2. Ensure the class defines the following constants (i.e. using ‘final’ in their declaration), to signify
the different possible states of the object:
APPLICATION
ASSESSMENT
REJECTED
APPROVED
PAYING_BACK
CLOSED
代写 ITECH2100/6100
3. Ensure there are accessors for all the attributes.
4. Ensure there is a constructor that accepts two String parameters (one for the applicant’s name,
one for the reason they want the loan), and ensure that the state of the object is set to be the
Application state.
Page 3 of 5
5. Ensure there is a mutator to allow adjustment of the amount that they are applying for. Be sure
to include a check that the current state is the Application state, before accepting the parameter.
(i.e. if the state is not currently the Application state, then do nothing except return false.) If the
parameter is sensible, and the state is currently the Application state, then update the attribute to
the new value and return true.
6. Include a method named ‘beginAssessment’ which confirms that the current state is the
Application state, and if so, changes the state to now be the Assessment state (otherwise, it does
nothing except possibly to return false).
7. Provide a method named ‘rejectApplication’ which should have a parameter for receiving a
reason why the application is being rejected. The method should first confirm that the current
state is the Assessment state (otherwise it should do nothing except possibly to return false). If it
was currently in Assessment state, then it will set the note attribute to be the string that was
given as the parameter, and will change the state to be Rejected.
8. Provide a method named ‘approveApplication’ which confirms that the current state is the
Assessment state (otherwise it should do nothing except possibly to return false). If it was
in the Assessment state, then it should change to the Approved state.
9. Provide a method named ‘takeOutMoney’ which requires a parameter to specify how much
money is going to be taken out. If the amount specified in this parameter is equal to or less than
the amount that had been approved for the loan, and if the object is currently in the Approved
state, then the attribute for recording how much remains unpaid should be set to the value of the
parameter, and the state should be changed to the Paying Back state. Otherwise the method
should do nothing (except possibly to return false).
10. Provide a method named ‘makePayment’ which requires a parameter to specify how much
money is being paid back to the bank by the person who the loan is for. The method should
check to confirm that the object is currently in the Paying Back state, and if the parameter
amount is not more than a few cents of the amount that remains unpaid, then the value of the
parameter should be subtracted from the amount that remains unpaid (e.g. if $10,000.99 remains
due, a parameter of exactly 10001 should be acceptable, even though it is one cent more than
the unpaid amount; but 10002 is too large to be acceptable).
11. Provide a method named ‘closeAccount’ which is only valid in the following cases:
The state is Approved, and no money has been taken out yet, or
The state is Paying Back, and the amount owing (the amount unpaid) is less than $0.10
If one of those cases applies, then the method will change the state of the object to be Closed.
(Otherwise it should do nothing except possibly to return false.)
12. Provide a method named ‘toString’, which accepts no parameter but returns a String. The String
returned should indicate that this is a BankLoan object, and which particular person it is for. It
should also indicate the current state of the object. If known/relevant it should also indicate: the
amount that was approved for the loan; the amount that is currently unpaid (owed).
Page 4 of 5
Stage 2: Test Planning
13. Develop a test plan for testing the BankLoan class. This means, write up a set of test cases to
adequately test that the BankLoan class is behaving correctly. Follow the format that is provided
in the supplementary guide about testing, on Moodle.
Stage 3: Code a Test Driver
14. Write a class containing a main() method, which will effectively execute (automatically) the test
cases of your test plan. In comments, indicate which test case is being tested at each section of
the main() method’s code.
Submission Instructions
You should zip the entire eclipse project (or at least the .java source code files of your work if you
are using a different IDE) and the document containing your test plan, into a single ZIP file, and
then upload this file to Moodle through the assignment link labelled “Submit Week 3 Lab Work”.
This link will only become available after you have completed the ‘Declaration of Originality’ form
for this week’s work, and accept the Student’s Statement – which is instead of you needing to sign a
paper cover sheet.
You should use your full name followed by “-week3” as the name of your zip file. For example
Walt Disney would make his file to be named: Walt-Disney-week3.zip
Assessment Explained
The assessment occurs in two parts. You will be assessed on the quality and completeness of the
code and test plan, as well as on your ability to demonstrate some practical skills during an
interview as explained below.
(20%) The marker will require you to demonstrate to him/her that you:
are able to set breakpoints so that when running in debug mode the code will pause at the
breakpoint.
can step through code in the debugger mode of Eclipse
can inspect variables
can interpret the call stack showing what lines of code are executing
(20%) In regards to the test plan (Stage 2), you will be assessed on:
The appropriateness of the selected test cases to adequately confirm the behaviour of the
BankLoan class
The appropriateness of the manner in which you have expressed the test plan.
Page 5 of 5
(60%) In regards to the coded BankLoan class, you will be assessed on:
Ability to create a basic class in Java
Ability to choose appropriate data types for attributes, and appropriate scope for variables
and constants.
Ability to write methods that accept parameters and that return values
Ability to use suitable relational expressions to selectively run different parts of code
Ability to ensure that objects will always have a valid state, and that behaviours are only
effective when invoked while an object is in a suitable state for that behaviour.
Ability to write a test driver to execute a test plan.
Correctness of functionality to meet the specifications (provided earlier in this document)
代写 ITECH2100/6100