CSCI 2134 Assignment 4 Due date: 11:59pm, Friday, December 4, 2020, submitted via Git Objectives Extend an existing code-base and perform some basic class-level refactoring in the process. Preparation: Clone the Assignment 4 repository https://git.cs.dal.ca/courses/2020-fall/csci-2134/assignment4/????.git where ???? is your CSID. Problem Statement Take an existing code-base, add required features, test it, and refactor it as necessary. Background The JSON Comparison Software is moving on to version 2. Your boss wants you to add some new features to the program that have been requested by the customer. She has hired you to extend the code. She also mentioned that the original designer of the code did not do a great job and wondered if there was any way to improve the code. She will provide you with (i) the code-base, (ii) the existing requirements, and (iii) the specification of the additions to be made. Your job is to (i) create a design for the additions, (ii) implement the additions, (iii) create unit tests for the additions, and (iv) identify opportunities for class-implementation and class-inter- face refactoring, and (v) do some refactoring where appropriate. May the source be with you! Task 1. Review the old specification (specification.pdf) in the docs directory. You will ab- solutely need to understand it and the code you are extending. 2. Review the extension specification at the end of this document, which describes all the ex- tensions to be done. 3. Design and implement the extensions using the best-practices we discussed in class. 4. Provide a readable, professional looking UML diagram of the updated design. This should be a PDF file called design.pdf in the docs directory. 5. For each new class that you implement, you must provide unit tests in the form of Junit5 tests. You should design your classes and modify existing classes to facilitate the testing. 6. In a file in the docs directory called refactoring.txt list all the class-implementation and class-interface refactoring that you will do and refactoring that you would recommend. 7. Perform any class-implementation and class-interface refactoring that you promised to do. 8. Bonus: Research the Factory pattern that is used to instantiate classes derived from the same superclass or interface. E.g., all the JSON values could instead implement a Value interface or be subclasses of an abstract Value class and be constructed by a new ValueFactory class instead of Value. Implement the Factory pattern to improve the creation of Values in Value. Be sure to update the UML diagram and provide unit tests. 9. Commit and push back everything to the remote repository. Grading The following grading scheme will be used: Task 4/4 3/4 2/4 1/4 0/4 Design (10%) Design is cohesive, meets all require- ments, and follows SOLID principles Design meets all re- quirements and mostly follows SOLID principles Design meets most of the re- quirements. Design meets few of the of re- quirements. No design submitted. Implementation (25%) All requirements are implemented Most of the re- quirements are im- plemented Some of the re- quirements are implemented Few of the re- quirements are implemented No imple- mentation Testing (25%) Each new class has a set of unit tests associated with it. All requirements are tested. If imple- mentation is incom- plete, the test is still present. Most of the new classes have an as- sociated set of unit tests. Most re- quirements are tested. Some of the new classes have an associ- ated set of unit tests. Some re- quirements are tested. Few of the new classes have an associated set of unit tests. Few require- ments are tested. No testing Refactoring Description (10%) At least 4 class level refactoring sugges- tions that follow SOLID principles and make sense. At least 3 class level refactoring sugges- tions that follow SOLID principles and make sense. At least 2 class level refactoring suggestions that follow SOLID principles and make sense. At least 1 class level refactoring suggestions that follow SOLID principles and make sense. No refactor- ing sugges- tions. Refactoring Implementation (10%) At least 2 class-level refactoring sugges- tions are imple- mented correctly. 2 class-level refac- toring suggestions are implemented, with 1 being done correctly. 1 class-level re- factoring sug- gestion is imple- mented cor- rectly. 1 class-level re- factoring sug- gestion is imple- mented. No refactor- ing sugges- tions imple- mented. Code Clarity (10%) Code looks profes- sional and follows style guidelines Code looks good and mostly follows style guidelines Code occasion- ally follows style guidelines Code does not follow style guidelines Code is illeg- ible or not provided Document Clarity (10%) Documents look professional, in- clude all infor- mation, and easy to read Documents look ok. May be hard to read or missing some information. Documents are sloppy, incon- sistent, and has missing infor- mation Documents are very sloppy with significant miss- ing information Documents are illegible or not pro- vided. Bonus [10%] Factory pattern im- plemented and tested. Factory pattern im- plemented Factory pattern partially imple- mented Factory pattern attempted. No attempt Submission All extensions and files should be committed and pushed back to the remote Git repository. Hints 1. You can get a large number of marks without writing any code. 2. Do the design first and look at refactoring as you design. 3. The extensions are intended to require minimal code. 4. Testing is as important as implementation 5. The example input in system_tests has been updated to match the required extensions Specification of Required Extensions Background Our customer has requested that the JSON Comparison software accept new types of input and be more robust to user input errors. You will need to • Extend the software to support a new “set” type of JSON Object, • Extend the software to compare up to three JSON object at once, and • Handle improper JSON input in a user-friendly way. Specification: Changes to Program Input 1. After two JSON values are read, there may be a third value to read: • If all three JSON values are equal, the program outputs only one representation of them followed by the line “Objects are equal.”, as in the two-value case. • If any one of the JSON values are different, the program outputs the representation of each of the three objects followed by the line “Objects are not equal.” The software does not need to indicate which Objects are different or equal. 2. The JSONScanner can accept two additional tokens ‘(‘ and ‘)’ Specification: Functional Changes 1. A new “set” type of JSON Object may be part of the input. A set is similar to an array but two sets are equal even if their members are in a different order. More specifically: • A set is a sequence of primitive values. • A set begins with a left round bracket ‘(‘, has zero or more values, separated by com- mas, and ends with a right round bracket ‘)’. • Two sets are equal if both sets have the same number of elements and the elements are the same (but not necessarily in the same order) 2. The program should handle invalid JSON input in a user-friendly way: • If a JSON object is invalid the software should output “Object X is invalid”, where X is 1, 2 or 3 • The software does not need to compare equality of any of the objects if any one of them is invalid • Only the first invalid object needs to be indicated 3. Invalid JSON includes: • JSON with an invalid token (i.e. one not handled by the JSONScanner) • JSON pairs where the key and value are not separated by a colon ‘:’ • JSON objects where the members are not separated by a comma ‘,’ • JSON arrays where the members are not separated by a comma ‘,’ • JSON sets where the members are not separated by a comma ‘,’ Specification: Nonfunctional Changes 1. The design should follow the SOLID principles 2. The customer has informed us that more types of JSON extensions will be added in the near future, so the design should reflect this.
欢迎咨询51作业君
