Microsoft Word – CSCI 2134 Assignment 4.docx CSCI 2134 Assignment 4 Due date: 11:59pm, Thursday, April 6, 2023, 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/2023-winter/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 Ticket to Ride solver is moving on to version 2. Your boss wants you to add some new fea- tures 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., when you create different types of links they could implement a Link interface or be subclasses of an abstract Link class and be constructed by a new LinkFactory class. Implement the Factory pattern to improve the creation of Links. 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 Ticket to Ride solver software accept new types of input and be more robust to user input errors. You will need to • Extend the software to support new one-way directed links • Handle improper input in a user-friendly way. Specification: Changes to Program Input 1. After a link is read there may be a fourth value to read “one” or “two”. • For example, “A 42 B one” represents a one-way link and “B 13 C two” represents a two- way link. Note that “A 42 B” and “B 13 C” are still valid input and represent two-way links. Specification: Functional Changes 1. One-way links can only be traveled in one direction: • The first listed city is the source and the second listed city is the destination. • For example, “A 42 B one” indicates that you can move from A to B but not vice versa. 2. Output of the rail network must include the type of any one-way links • One-way links print their cities in the same order as input – they are not sorted • One-way links include the word “one” after them in the output • Two-way links still print the cities in sorted order. They do not print the word “two” after them • E.g. “A 42 B one” for a one-way link • E.g. “B 42 A one” for a one-way link in the opposite direction • E.g. “B 13 C” for a two-way link 3. The program should handle invalid input in a user-friendly way: • If the input is invalid the software should output “Invalid line: “ (without the quotes), followed by the invalid line of input. • E.g. “Invalid line: A B three” • The software does not need to read any more input if a line is invalid • Only the first invalid line needs to be indicated 4. Invalid input includes: • Too many tokens on one line • Too few tokens on one line • A link type other than one or two • A non-integer value in place of a distance Specification: Nonfunctional Changes 1. The design should follow the SOLID principles 2. The customer has informed us that different kinds of links will be added in the near future, so the design should reflect this.
