Will be supplied an existing Java application, which implements a basic roster management system. That is, it allows sto

[answerhappygod]

Will be supplied an existing Java application, which implements
a basic roster management system. That is, it allows storing data
about which shifts staff members are working at a business each
week, calculating wages payable and identifying scheduling
problems.
- This is not intended to be a real timesheet/roster management
program and is missing many features that would be required in
practice.
This starter application is badly in need of refactoring, and
even a casual viewing of the code reveals many examples of “code
smells”.
The basic architecture of the system revolves around four
classes, with a Main class that manipulates the data and contains
some testing code.
Part one – Getting started
Download the base code. In Eclipse, create a new project.
The following files are included in the base code
• Main.java
• roster/Roster.java
• roster/StaffContainer.java
• roster/StaffMember.java
• roster/TimeSlot.java
Import the files into your project, and run it. You should see
some test output.
Save a copy of the original output. Your program must continue
to generate exactly the same output as you make changes.
Create a report document that you will submit as part of your
assignment. Your report must include the outputs described below,
plus:
• A statement of completion, indicating which parts of this
assignment you have attempted
• A statement of acknowledgement, indicating any assistance you
received and the nature of the assistance. This statement must be
included even if you receive no assistance.
• A list of references, as applicable
Part two – Familiarity with the code as given
Explore the code, and create a UML Class Diagram of the code as
provided. You may use Enterprise Architect or a different UML
diagramming tool.
Your class diagram should include appropriate association
connectors, and show private, public, and static members.
- Use underline to represent static members.
Include this diagram in your report.
Part three – Code smells
Identify at least four “code smells” in the base code. Use the
names as given in the lecture.
Include these in your report, explaining for each:
• The name of the code smell,
• A snippet of code demonstrating the problem
• An explanation of why you think the code has the smell
(approx. 50 words per case)
If you use a third-party resource to identify examples of code
smells not discussed in class, reference them appropriately.
- You may find multiple examples of a single code smell, but
your report should not contain four instances of the same
problem.
At least two of your identified code smells must require
changing the class structure of the code to resolve.
Part four – Refactoring
For each of the code smells you identify above, refactor the
code to remove it. Each time you complete a refactoring, run the
program to confirm that the program output is the same as the
output before refactoring.
Save a zipped copy of your Java files for each code smell you
remove by refactoring.
Name these zip files appropriately; for example Refactor 1 –
Long Method.zip
- Do not include .class or other IDE files. Include only the
.java files, preserving directory structure.
If you identified more than four code smells, you can bundle any
additional changes into your final zip file. You only need to
include three in-progress revisions and one final of your code.
- Refactoring should not change the output. You can make
whatever changes you need to the code, but the output should remain
the same.
Part five – Documenting
Create a second UML Class Diagram showing the class structure of
your final refactored code. Include this diagram in your report