CS5004 Summer 2022 SF – Object Oriented Design Using Java Midterm Exam
Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: daixieit
CS5004 Summer 2022 SF – Object Oriented Design Using Java
Midterm Exam (100 points)
Instructions: You may start this test at your convenience, from the time it becomes visible on Canvas until four hours before the posted deadline. However, once you start, you must complete and submit it in a single 4-hour session. Submit your solution by pushing all ofyour code files to a new folder within your 5004 GitHub repo, and then uploading the appropriate URL to Canvas. The later of the time pushed to GitHub and the time the URL is submitted to Canvas determines your time of submission – no exceptions. Allow at least 10 minutes for the mechanics of submission, in case of technical difficulties. If you use even afew minutes more than the allotted time to complete this exam, heavy penalties will apply. It is not necessarily assumed that you will have sufficient time to fully answer every question or implement every feature; do as much as you can within the time limits; leave comments indicating how you would go about finishing any parts you do not finish, so that graders can award partial credit. Also, there is a “safety net” option for students scoring less than 85%: you would be allowed to take a re-test, which would include both corrections to your original test and 1-2 additional problems, with a maximum re-test score of 85%. (Only the higher of your two scores would be carried forward for final grade calculations.)
Your mission is to design and implement “ business logic” for a Shopping List application in Java. A ShoppingList is a list of Items to be purchased, in different categories, taking into account price, importance, and other factors such as sellByDate. Your deliverables will include both a design (a
Class Diagram) and Java code (interfaces, classes, tests, documentation). Your code should use
good Object Oriented Design principles, follow established style guidelines, work as specified, and include Junit testing, Javadocs, and internal commentary suitable for a software engineer who might be maintaining your application in the future. Your solution should minimize repetition of the same or similar code in multiple places and should validate arguments to methods, throwing exceptions as appropriate. You are not expected to provide a main method or user interface.
0. Prepare a design (class diagram), expecting that it may require updates as you progress. Use appropriate boxes and arrows, and indicate public/private fields/methods in the boxes. For a quick review of notation, see https://www.educba.com/class-diagram/. Minor flaws in drawing the arrows will not be penalized, but distinguish “is-a” from “has-a” arrows. Save your diagram in any common format (jpg, pdf, etc.) in the same folder as your code.
1. Each Item should have the following fields :
a. name (String, cannot be changed)
b. price (Double, as estimated by end user)
c. importance (int, scale from 0 through 9)
2. There are currently three categories of Item: FOOD, CLOTHING, and OTHER; but additional categories are likely to be added in the future.
a. FoodItems have a sellByDate (use 3 ints for parameters: YYYY, MM, DD; refer to contractEmployee code (Lec08) for how to convert to LocalDate field)
b. ClothingItems do not have a sellByDate but have a clothingSize field (int size)
c. OtherItems have no special fields
3. All types of Items should support the following methods:
a. constructor
b. getters for each applicable field
c. getCategory which returns an Enum type (currently, FOOD, CLOTHING, or OTHER)
d. setters for price, importance (but not name, category, sellByDate, or clothingSize)
e. compareTo (implementing Comparable) // based on Price
f. equals
g. hashCode
h. toString
4. A ShoppingList should honor the following methods. You should use the built-in ArrayList or LinkedList classes to implement ShoppingList, leveraging inheritance from built-in Java lists to reduce your work.
a. constructor
b. add(Item i) // Items are added when user runs out of food etc
c. get(int index) // Get the Item at a particular index
d. contains(Item i) // boolean, does the ShoppingList contain this item?
e. isEmpty() // Shopping complete!
f. remove(Item i) // Items are removed when purchased
g. size() // Count of items still to be purchased
h. sortByPrice() // Use Comparable ordering from Items class
i. sortByImportance() // Use Comparator ordering based on importance
Methods directly inherited from built-in lists, without modification, need not be tested.
5. Be sure to provide Javadocs as well as internal comments, where appropriate, for each class and method. Your Junit testing needs only basic Javadocs, but should also include a bit of internal commentary. There is no need to provide trivial, obvious comments (“This tests checks the getter” – the name of the method should convey that!); but do comment where helpful (“Verifies that exception is thrown if importance argument is out of range.”)
6. All code should include modest amounts of “software engineer”-oriented documentation, such as explaining why a particular design choice was made (e.g., “I implemented this with LinkedList rather than ArrayList because … <reason>“).
2022-07-28