IMAT5101 OO Programming Assignment 3

Faculty of Technology – Course work Specification 2019/20

Module name : Object Oriented Programming
Module code : IMAT5101
Title of the Assignment : Assignment 3
This coursework item is : Summative
This summative coursework will be marked anonymously : Yes
The learning outcomes that are assessed by this coursework are : Have a comprehensive understanding of OO programming concepts: abstraction, encapsulation, inheritance, etc. Be able to select appropriate API facilities in the design, implementation and testing of OO applications and applets. Assessment type : Individual
Weight : 50% to the overall module mark.
Your marked coursework and feedback will be available to you on : If for any reason this is not forthcoming by the due date your module leader will let you know why and when it can be expected. The Head of Studies (headofstudies-tec@dmu.ac.uk) should be informed of any issues relating to the return of marked coursework and feedback.

Note that you should normally receive feedback on your coursework by no later than four working weeks after the formal hand-in date, provided that you met the submission deadline.

Submission : Blackboard VLE through a submission portal
Submission Guidelines :
Late submissions will be processed in accordance with current University regulations which state : “ the time period during which a student may submit a piece of work late without authorisation and have the work capped at 40% [ 50% at PG level ] if passed is 14 calendar days. Work submitted unauthorised more than 14 calendar days after the original submission date will receive a mark of 0%. These regulations apply to a student’s first attempt at coursework. Work submitted late without authorisation which constitutes reassessment of a previously failed piece of coursework will always receive a mark of 0%. ”
Academic Offences and Bad Academic Practices :
These include plagiarism, cheating, collusion, copying work and reuse of your own work, poor referencing or the passing off of somebody else's ideas as your own. If you are in any doubt about what constitutes an academic offence or bad academic practice you must check with your tutor. Further information and details of how DSU can support you, if needed, is available at : www.dmu.ac.uk and www.dmu.ac.uk

About this assessment

This individual summative assessment counts 50% towards your module mark. You are given a scenario for your assignment. This takes the form of a design description and a specification by way of a class diagram. You should gain an understanding of the scenario, implement the class diagram and produce the functionality listed within the use cases.
You should implement each class to the expected standards as discussed and practiced during the module.

Objectives

The objective of this assessment is for you to demonstrate your ability to design and implement an OO system consisting of a set of Java classes and a client program. In particular:

To design and implement classes with suitable fields, constructors, accessor methods, and modifier methods. To conform to the standard conventions of Java. To implement classes that are associated by inheritance, delegation, composition and aggregation. To write a client application that uses your classes to show that they function correctly.

Submission

Submit one .zip Archive File called imat5101LabTest.zip via Blackboard consisting of your (Eclipse) project folder. Make sure all of your source code is in there.

Your Scenario : Shopping Cart

[ STAGE 1 – 80% ] When shopping for groceries online a Customer chooses a Product and places an Order for some quantity of it. The order is added to a Cart. A Date is set for the delivery. More orders can be added to the cart, and they can be changed up until checking out. It is possible for products to have a discount rate applied, i.e. a DiscountProduct. The contents of the shopping cart can be sorted in various ways. Orders within a cart can be iterated over. To support further features of the cart, orders and associated products can be tested for equality. The partial UML class diagram below shows the underlying data model you should use to achieve this scenario:

further guidance on the implementation of each class

Name : Simple name comprising a first name and family name.
Date : Simple date record with day/month/year fields. No validation.
Customer : A customer has a name, and a customer number.
Product : A product item has a unique product code, description, and price per unit. The price is given in pence.
A product can be tested for equality by providing an appropriate overridden equals(...) method that assesses the equality of each field.
Additionally, products are comparable, so they can be sorted into a natural order. They should firstly be compared by product code, if these are the same, then by description, and if these are the same, then by unit price.
DiscountProduct : A discount product is a product with a discount rate applied. The discount rate should be between 0 and 1.0, with 0.1 being a 10% discount, 0.2 being a 20% discount, etc.
When retrieving the unit price of a discount product it should return the standard unit price with any discount applied. A discount amount should always drop to the nearest whole number, e.g. a calculated discount of 7.9 pence would apply as a discount of 7 pence on the unit price.
Order : An order is for a quantity of product. It is possible to increase and decrease the quantity. The cost of the order (i.e. unitPrice * quantity) can be retrieved with the getCost() method.
An order can be tested for equality - an order is equal to another if its associated product is the same, i.e. quantity is ignored. Orders are comparable and should firstly be compared by their associated product, and if these are the same, then by their quantity.
Cart : A cart is for a customer and has a delivery date and a unique id. It consists of a list of product orders, and a set of methods to add or remove an order, retrieve an order so that it can be modified or printed on a receipt, for example. The total cost of the Cart is given by the getTotalCost() method. An order can be searched for by product code.
A cart should also allow its orders to be sorted into their natural order via a sortOrders() method. It should provide an additional overloaded method sortOrders(Comparator<Order>) that accepts a custom comparator and applies this to the list of orders.The cart requires two further methods: containsOrder and removeOrder, as shown in the UML diagram, that will make use of an equality test. A cart should also provide an iterator over its orders.
Use Cases : You should have a test class, with a main method, that should complete the following use cases for the “Shopping Cart System” to show it works as expected. Please clearly highlight where each use case is exercised in your test program with comments:
CartTest : UC1 A test program that creates an instance of Cart, populates it with several orders (for both products and discount products), and uses a for-each loop to produce a formatted listing of the orders with their price, the number of items in the cart and the overall total price.
Note: You can either use a data file to dynamically read orders, or hardcode the order instances to add to the cart.
UC2 Test each of the sort methods work as expected, as evidenced by appropriate output. For the sortOrders (Comparator<Order>) method, you should pass in a custom comparator that sorts by cost (asc) and if these are the same then by product (desc). UC3 Additionally, test the use of equality by using the contains and remove methods. Also, you should use a PrintWriter to produce a receipt for all of the orders and associated details of the cart, and output these into a text file Cart.txt.
UC4Add further code to show how each method of Cart can be used. In particular, increase and/or decrease the quantity of one or more of the products in the cart, and then re-print the updated cart listing.

To Continue Click Here > IMAT5101 OO Programming Assignment 3.pdf