Lab Assignment 2: Learning Outcomes Assessed
Lab Assignment 2: Learning Outcomes Assessed
__________________________________________________________________________________
Lab Assignment 2
Learning Outcomes Assessed
The following course learning outcomes are assessed by completing this assessment:
Skills:
S5. Incorporate pre-written classes including those from an API into a software solution
A1. Design, develop, test, debug and release programs from supplied program specifications
This is a group assignment. Groups must contain two students. You are expected to partner with the same student
that you partnered with for Lab Assignment 1. You are expected to continue engaging in collaboration and paired
programming to complete this assignment.
• You will practise skills in reading a specification and developing functional requirements to inform your object
__________________________________________________________________________________
• You will develop a multi-class system to meet functional specifications applying object oriented design
principles.
• You will use a GitHub repository to maintain your code. This repository will be shared with your partner.
• You will develop your understanding of and application of object-oriented programming techniques, in
particular those relating to inheritance and abstract classes.
• You will test your code using thoughtful test cases and write some JUnit tests that can be run to test your
code.
It is expected that you will creatively design and update a system based on appropriate design choices that address
the requirements and is consistent with the design of the starting system. Before you submit, read over the entire
assignment and understand all the tasks.
All code must conform to stylistic conventions including proper commenting, appropriate choice of identifier names
(including case), proper indentation and other readability issues. If the code does not follow consistent style and
formatting standards, marks will be deducted. For examples of coding style guides, please consult:
• Yohanan (2016)
General Requirements
Demonstrate an understanding of particular concepts covered in lectures, workshops, laboratories and reading to
provide the details requested. This may require further reading and research beyond the material discussed in class.
Assessment Details
__________________________________________________________________________________
All developed code should also be committed into the pair’s GitHub repository in the GitHub Classroom.
It is important there is evidence of each student contributing to the assignment and pushing to GitHub. If there is no
evidence of each student committing code regularly to GitHub, that student will be given zero marks.
Generally, each individual student must at a minimum (more details are specified in the next section):
1. Update one of the group’s Junit test cases from Lab Assignment 1 with appropriate validation for object
creation
2. Update one of the group’s Property classes with appropriate Javadoc documentation
4. Be available, if required to answer questions about the code they have written
Generally, as a group students must write code to demonstrate their understanding of the requirements and the
starter system by correctly implementing three functions to load rate payers and properties and to display
properties for a rate payer (more details are specified in the next section). In this coding, students should be able to
demonstrate:
1. appropriate understanding of the classes modified/changed by including their names and a description under
the author tag at the top of the class
4. correct use of file I/O with respect to text based and serializable files
Each student group must modify their developed system from Lab Assignment 1 to address the user requirements.
The following description updates the user requirements that are to be addressed in the computer system that
students are developing.
Where there is not enough information provided, you may make assumptions as long as you document these.
__________________________________________________________________________________
Further information is given in the Detailed Requirements and Marking Criteria sections of this document.
System Specification
Previous content (unchanged):
“A city council is looking for a new computer system in which to keep a register of all rate payers that pay rates on
properties within the council boundary. Each rate payer will be one person or legal entity identified at Australian law
e.g. public or private company, trust, partnership or other incorporated body e.g. sport club. For each ratepayer, the
system will store their name and postal address. The address will be stored in one text field containing the postal
address e.g. “75 Boundary Street, SomeSuburb, City”. Their postcode will be stored in a separate field. There will be
an optional field for the rate payer’s telephone number. Their type as identified e.g. individual or public company etc.
above will also be stored.
The council also has a record of each ratepayer’s property. Each ratepayer has only one property. Properties can be
of seven types: residential, commercial, vacant land, hospital, industrial, school/community and other. Each type has
additional attributes. These details are displayed in the following table:
For all property types there will be a description (lot number and portfolio according to state government registration
index), location (address format as defined above), an area in square metres, site value, capital improved value
__________________________________________________________________________________
(CIV), net annual value and valuation date. The capital improved value is a separate valuation performed at the
same time as the site (land) valuation and is greater than the land value for all cases except vacant land where it is
the same value. The valuation date is stored in the format DD MMM YYYY.
The total rates charged for a property depends on the CIV of the property and the type of property. The amount
charged is calculated by multiplying the CIV by the CIV rate for that type of property and then adding relevant extra
service levies designated for that property type. The table below indicates the 2020 rates.
Extra
CIV
Property Type Extra Services Services
Rate
Rate
Waste Management 1 x $350
Green Waste
1 x $75
Management
residential 0.39%
$110 +
Fire Services Levy (0.006% of
CIV)
Waste Management 2 x $350
__________________________________________________________________________________
Extra
CIV
Property Type Extra Services Services
Rate
Rate
$200 + ($60
for small or
$80 for
Traffic Management medium or
Levy $100 for
large
organisation
category)
$150 +
other 0.30% Fire Services Levy (0.006% of
CIV)
If the ratepayer has a charitable status, a discount is applied to the total rate amount. The discount is 20% off the
total rate calculation.
As an example a property classified as a residential property having a CIV value of $350,000 would have a rate
charged for a calendar year of:
As the ratepayer has no charitable status no discount is applied. If they had a charitable status, then the $1921
would be reduced to $1921 x 80% = $1536.80.
__________________________________________________________________________________
At this stage a proof of concept system has been developed. It runs in the Eclipse console and although three menu
items are listed only item 3 is implemented:
Item three presents a menu for selecting a type of property on which to estimate the total yearly rates:
__________________________________________________________________________________
When a user selects a type of property they are asked a number of questions (NB: only the Residential and Other
property types currently produce a rate calculation).
The answers to these questions help determine the total rate costs
After the calculation is displayed, the user has the opportunity to generate another rate notice for another type of
property or return to the main menu and exit the system.
The code for the system is present in a GitHub repository. You are asked to continue the coding of that system so
that it provides sufficient functionality that can demonstrate at least six property types and their total yearly rate
costs. You may also need to improve the formatting of some of the output.
__________________________________________________________________________________
New Information:
You are now in the second iteration. You have discovered and need to address a number of new requirements:
1. You have discovered that a ratepayer can have multiple properties. At the moment you have designed the
classes with a ratepayer on each property. You believe this design will still work.
2. You need to provide functionality to populate the system with ratepayers and their properties by creating
some serializable files that can be the persistent information for the system. This functionality will not be run
from the menu but will be run seperately by you. You need to make sure that the new system can be loaded
appropriately with this information. You have constructed two comma separated values (CSV) files to test
out the use of utility classes to upload each of these in separate runs.
3. You have though thought that you need to make the validation more robust on these classes and applicable
sub-classes as you eventually want a seamless transition to a live system.
4. You need to prove that the load of these details and the association between them is correct. The users
have requested a new menu item on the main menu of the system and you will use this to determine how
well you have loaded the data. This menu item, Query a Rate Payer should provide a list of all ratepayers in
the system and then after one is selected, the screen should display all the information of all the properties
for that ratepayer. The information must include all property attributes from the super and sub-class.
5. You’ve also been told by some of your team members that you should improve the documentation of your
code by providing some Javadoc for the classes that you are creating.
Detailed Requirements
Create a document named surnameStudentID1StudentID2Assignment1.doc/pdf. This document is to be completed
by both students in the group. The document should be presented as a business or management style report which
adheres to academic writing presentation standards. As well as a title page, table of contents and details of the two
students in the team it should contain headings and sections for:
• Screenshot of successful running of new menu item for a ratepayer with more than one property;
Individually, update at least one of the property classes (other than Industrial which is available as an example) with
appropriate Javadoc comments (as a group you will therefore complete two Javadoc files).
__________________________________________________________________________________
Individually update one of your JUnit test case files from Lab Assignment 1 (therefore two for the group) with
sufficient methods for testing that all input data for ratepayers and properties contains valid information.
As a group, write code to satisfy the functional requirements identified under New Information in the System
Specification. Namely:
1. You may not need to change anything for item 1 other than ensuring that where needed you have a
collection of some form e.g. array or ArrayList to store the 1:M association. Remember currently an object of
type property or one of its sub-classes, contains an object of type ratepayer.
o If Valid,
o Else
__________________________________________________________________________________
• Do you need to create some new constructors on your classes and chain to/from your existing
ones?
• Do you need to create defaults for attributes not already referenced in code?
• Do your toString() methods need to change to show the correct details for the object you are
creating?
• What order do you run your utility classes in? RatePayer then Property or vice versa or doesn’t it
matter?
• Do you need to think about overriding the equals() method on ratepayer so that you can correctly
compare ratepayers for equality (see week 7 lecture notes and Parson (2012), pps 166-168).
You need to imagine that the serializable file you write is some sort of persistent data store that can be
used by your system. Even though it is less powerful and less convenient than a table on a DBMS you
could still use a pattern such as a Data Access Object (DAO) 1 for accessing the serializable file if you
really want to expand your understanding.
3. You need to think about ensuring that zero values are not written, String values are not null or empty and
other types have valid values e.g. is it valid that a capital improved value of -100.00 is entered? You might
create validator classes and interfaces for your validations but in class methods are okay. You should use
existing Java API exceptions to catch and process appropriately e.g. for file I/O or existing conversion
problems (see week 8 lecture notes and Parsons (2012, Chapter 9)).
4. You need to change the existing MainMenu class to include an option to execute a screen display where all
ratepayers are listed (with a corresponding selection number at their left). You obtain the list of ratepayers
by reading the file with the serialized ArrayList of properties and then iterating through that ArrayList. When
1We are not really dealing with a full enterprise system here but you could look at Fowler (2003), Jenkov (2014), Rocha & Purificacao (2019) or Sun
Microsystems, Inc (2002), for a good explanation on why you might separate the data access layer from your domain layer.
__________________________________________________________________________________
a user of the system chooses an appropriate ratepayer, a list of all properties for that ratepayer are listed on
the console (you should be able to modify the toString() methods of Property and the appropriate sub-class
to provide further details of attributes now initialized i.e. the output for each property should appear like that
from your rate calculation screen in Lab Assignment 1 but with all variable values displayed). Once again all
properties are obtained from a file with the serializable ArrayList of properties and you then iterate through
the ArrayList matching the ratepayer on that property with the one chosen from the screen. You might need
to override the equals() method on the ratepayer class for this.
5. This is actually an individual task. You have been given an example of a Javadoc html file for your Industrial
class – Industrial.html. Try to match the messages and format for one other (two for the group) Property sub-
classes and produce an html Javadoc file for each.
As a group, run your JUnit tests (if you were performing TDD you would already have all your tests, but generally,
students tend to complete tests after their coding so you may need to write some more tests now with respect to
validation and then verify all tests have run successfully). Capture screenshots of successful operation.
As a group, run your application to successfully display a ratepayer with more than one property and capture a
screenshot of this.
Create a zip file of your Eclipse project. That project should now contain your new classes in the utility package,
changes to existing classes, appropriate Javadoc files in the .doc folder and the csv files in your .files folder.
Complete your group document including the screenshots and appropriate link.
Additional Information
General Comments
The submission must be presented in a professional, clear and concise manner. If you need further system
information please use your initiative and make reasonable and logical assumptions. State your assumptions in your
report. Ask your lecturer or tutor for further information.
Readings
Your text, course material and references listed on the Course Description will assist you with this assignment.
Submission
__________________________________________________________________________________
Each group should submit an electronic copy of their report and eclipse project via Moodle. Please refer to the
Course Description for information regarding late assignments, extensions, special consideration, and plagiarism.
You are reminded that all academic regulations can be accessed via the university’s website, see:
http://federation.edu.au/staff/governance/legal/feduni-legislation/feduni-statutes-and-regulations
Marking Criteria
Work will be assessed according to the details within the Assessable Tasks/Requirements section of this document
and at a more specific level, according to the Marking Rubric below.
Reports submitted should be presented as business or management style report which adhere to academic writing
presentation standards. Marks may be deducted if this is not the case. Where applicable, the reports must contain
high quality academic presentation, expression and features as outlined in:
o Federation University’s
Assignment Layout and Appearance Guidelines;
General Guide to Writing and Study Skills,
FedCite - referencing tool; and
Feedback
Assessment marks will be made available in fdlMarks, Feedback to individual students will be provided via Moodle.
Plagiarism
Plagiarism is the presentation of the expressed thought or work of another person as though it is one's own without
properly acknowledging that person. You must not allow other students to copy your work and must take care to
safeguard against this happening. More information about the plagiarism policy and procedure for the university can be
found at:
http://federation.edu.au/students/learning-and-study/online-help-with/plagiarism.
Any support material must be compiled from reliable sources such as the academic resources in Federation University
library which might include, but not be limited to: the main library collection, library databases and the BONUS+ collection
as well as any reputable online resources (you should confirm this with your tutor).
__________________________________________________________________________________
References
Fowler, M. (2003). Table Data Gateway. Retrieved 3rd May, 2020 from
https://martinfowler.com/eaaCatalog/tableDataGateway.html
Evans, B. J. & Flanagan, D. (2015). Java in a Nutshell. (6th ed.). Sebastopol, CA: O'Reilly Media Inc
Jenkov, J. (2014). The DAO Design Pattern. Retrieved 3rd May, 2020 from http://tutorials.jenkov.com/java-
persistence/dao-design-pattern.html
Rocha, R. & Purificacao, J. (2019). Java EE 8 Design Patterns and Best Practices. Birmingham, UK: Packt
Publishing.
Sun Microsystems Inc., (2002). Core J2EE Patterns - Data Access Object. Retrieved 3rd May, 2020 from
https://www.oracle.com/technetwork/java/dataaccessobject-138824.html
Sun Microsystems Inc., (1997). Java Code Conventions. Retrieved 3rd May, 2020 from
https://www.oracle.com/technetwork/java/codeconventions-150003.pdf
Yohanan, S. (2016). Code Conventions for Java. Retrieved 3rd May, 2020 from
http://yohanan.org/steve/projects/java-code-conventions
__________________________________________________________________________________
Marking Rubric
Marking Criteria Marks
awarded
Group marks for code developed 80 marks
Appropriate code for successful reading and parsing of …Load_RatePayers input file /7
including appropriate exception handling
Ensuring ratepayer objects are in a consistent state by providing appropriate validation in /7
methods and constructors including where appropriate validation checks for zeros, nulls,
numeric ranges and negative values
Appropriate use of an ArrayList to store loaded ratepayers /7
Appropriate code to successfully store ArrayList into a serializable binary file /4
Appropriate code for successful reading and parsing of …Load_Properties input file including /7
appropriate exception handling
Ensuring property objects are in a consistent state by providing appropriate validation in /7
methods and constructors including where appropriate validation checks for zeros, nulls,
numeric ranges and negative values
Appropriate use of an ArrayList to store loaded properties of the six developed sub-classes /7
Appropriate code to successfully store ArrayList into a serializable binary file /4
Successful update of MainMenu to provide “Query a Rate Payer” option /3
Appropriate code to successfully read ratepayer ArrayList from a serializable binary file, /5
display and allow selection of ratepayer
Appropriate code to successfully read properties ArrayList from a serializable binary file, /5
select valid properties
Correct display of all property information for ratepayer /7
Good design including, where applicable, appropriate constructor chaining, overriding of /10
equals(), toString() and hashCode() methods.
Individual Tasks 20 marks
Update to selected Property sub-class to provide appropriate Javadoc. /5
Update to selected JUnit test case with sufficient tests for validation for all variables. /5