CSCI 2134 Assignment 4

CSCI 2134作业4
截止日期：2020年4月9日星期五晚上11:59，通过Git提交
目标
扩展现有的代码库，并在此过程中执行一些基本的类级重构。
准备：
您的CSID在哪里。
问题陈述
使用现有的代码库，添加所需的功能，对其进行测试，并在必要时对其进行重构。
背景
票务乘车求解器正在升级到版本2。您的老板希望您添加一些新功能
客户要求的程序。她雇用了你扩展
代码。她还提到代码的原始设计者做得不好，并且
想知道是否有任何方法可以改善代码。她将为您提供（i）代码库，
（ii）现有要求，和（iii）要添加的内容的说明。
您的工作是（i）为添加项创建设计，（ii）实施添加项，（iii）创建单元
测试添加的内容，以及（iv）确定实现类和实现类接口的机会
重构，并且（v）在适当的地方进行一些重构。愿消息来源与您同在！
任务
1.在docs目录中查看旧规范（specification.pdf）。你绝对会
需要了解它以及您要扩展的代码。
2.查看本文档末尾的扩展规范，其中描述了所有扩展
有待完成。代写CSCI 2134程序
3.使用我们在课堂上讨论的最佳实践设计和实施扩展。
4.提供更新设计的可读，专业外观的UML图。这应该是
docs目录中的一个名为design.pdf的PDF文件。
5.对于实现的每个新类，必须以Junit5的形式提供单元测试。
测试。您应该设计您的类并修改现有的类以方便测试。
6.在docs目录中名为refactoring.txt的文件中，列出所有类实现
以及您将要进行的类接口重构和建议的重构。
7.执行您承诺要做的任何类实现和类接口重构。
8.奖金：研究用于实例化从相同实例派生的类的Factory模式
超类或接口。例如，当您创建不同类型的链接时，它们可以实现
一个Link接口或抽象Link类的子类，并由一个新的
LinkFactory类。实施“工厂”模式以改善“价值中的价值”的创建。
确保更新UML图并提供单元测试。

CSCI 2134 Assignment 4
Due date: 11:59pm, Friday, April 9, 2020, submitted via Git
Objectives
Extend an existing code-base and perform some basic class-level refactoring in the process.
Preparation:
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 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-interface
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 absolutely
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 extensions
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 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 requirements,
and follows
SOLID principles
Design meets all requirements
and
mostly follows
SOLID principles
Design meets
most of the requirements.
Design meets
few of the of requirements.
No design
submitted.
Implementation
(25%)
All requirements
are implemented
Most of the requirements
are implemented
Some of the requirements
are
implemented
Few of the requirements
are
implemented
No implementation
Testing
(25%)
Each new class has
a set of unit tests
associated with it.
All requirements
are tested. If implementation
is incomplete,
the test is still
present.
Most of the new
classes have an associated
set of unit
tests. Most requirements
are
tested.
Some of the
new classes
have an associated
set of unit
tests. Some requirements
are
tested.
Few of the new
classes have an
associated set
of unit tests.
Few requirements
are
tested.
No testing
Refactoring
Description
(10%)
At least 4 class level
refactoring suggestions
that follow
SOLID principles
and make sense.
At least 3 class level
refactoring suggestions
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 refactoring
suggestions.
Refactoring
Implementation
(10%)
At least 2 class-level
refactoring suggestions
are implemented
correctly.
2 class-level refactoring
suggestions
are implemented,
with 1 being done
correctly.
1 class-level refactoring
suggestion
is implemented
correctly.
1 class-level refactoring
suggestion
is implemented.
No refactoring
suggestions
implemented.
Code Clarity
(10%)
Code looks professional
and follows
style guidelines
Code looks good
and mostly follows
style guidelines
Code occasionally
follows style
guidelines
Code does not
follow style
guidelines
Code is illegible
or not
provided
Document
Clarity
(10%)
Documents look
professional, include
all information,
and easy to
read
Documents look ok.
May be hard to
read or missing
some information.
Documents are
sloppy, inconsistent,
and has
missing information
Documents are
very sloppy with
significant missing
information
Documents
are illegible
or not provided.
Bonus
[10%]
Factory pattern implemented
and
tested.
Factory pattern implemented
Factory pattern
partially implemented
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 two different players,
• Extend the software to support new player specific links to represent a game partially in
progress, and
• 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, red or blue.
• For example, “A 42 B red” represents a red link and “B 13 C blue” represents a blue link.
2. After a route is read there may be a third value to read, red or blue.
• For example, “ A B red” represents a red route and “B C blue” represents a blue route.
Specification: Functional Changes
1. Colored routes can only use uncolored links or links of the correct color:
• Red routes can only use uncolored links or red links.
• Blue routes can only use uncolored links or blue links.
• Uncolored routes can only use uncolored links.
2. Output of the rail network must include the color of any colored links
• Output the links in the same format as they are input
• E.g. “A 42 B red” for a red link
• E.g. “B 13 C blue” for a blue link
• E.g. “A 5 D” for an uncolored 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 green”
• 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 player color other than red or blue
• 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 more than 2 players and different kinds of links will be
added in the near future, so the design should reflect this.

请加QQ：99515681 或邮箱：99515681@qq.com   WX：codehelp

标签：blue,2134,links,Assignment,CSCI,design,input,class,red
来源： https://www.cnblogs.com/hopjava/p/14613989.html