The design activity for this unit is to
analyze an existing program. Your team will reverse engineer the design
and discover the intentional (and unintentional) uses of design patterns in the
program. You will provide an analysis of the existing design describing
what you perceive its strengths and weaknesses to be. You will also analyse the code base using quantitative metrics. There is an
Eclipse plug-in for computing metrics on a Java code base at metrics2.sourceforge.net. (The
original version is at metrics.sourceforge.net.)
If you are familiar with an equivalent metrics package, discuss this with your
instructor before using it. After doing the analysis of the existing code base
you will suggest a refactoring of the design to better adhere to the design
principles that you worked with in this course. Principles such as
coupling, cohesion, delegation vs. inheritance, assignment of responsibilities,
elimination of bad code smells, metric
values, etc. should be in your consideration when doing the analysis and
refactoring. The refactored design should have some connection to the
original design. The intention is not to throw away the design and start
with a clean sheet of paper. At a minimum, you will need to understand
the current design so that you can present your analysis of it.
After doing the refactoring of the design the
team will select some significant aspects of the refactoring to
implement. The aspects of the design that will be implemented must be
approved by your instructor by the date specified on the course schedule.
On the day scheduled for completion of this
unit, each team will do a presentation of their analysis of the existing design
including its strengths and weaknesses in the dimensions of the design
principles discussed in this course, its use of design patterns, analysis of
the metrics for the original system and the team's suggested refactoring to
improve the design. The design should be presented using UML diagrams. To
highlight the improvements you made by refactoring the design, show sequence
charts for, at least, two important operations executing in the original design
and in your refactored design. Discuss the metrics report for the refactored
design. In your presentation do not discuss every metric. Select the ones that
are most important and relevant and that guided your refactoring.
The system that you are to
work with is found in this ZIP file.
This is a previous student team submission for an SE course. The zip file
includes a statement of the problem that this software system solves, all available documentation, and the code base.
Assessment
|
Component
|
Percent
|
|
Presentation
|
15
|
|
Reverse Engineering, Refactoring
and Documentation
|
70
|
|
Implementation
|
15
|
The instructor will use the following rubrics
to evaluate your work on this unit:
1.
Refactoring and documentation
2.
Presentation
3.
Implementation
Submission Instructions
Your team will place a zip file in
the Refactoring Exercise dropbox for Unit 4
in myCourses. Your file must be named unit4project.zip. Note that you can submit
many versions of this file and they all be kept in the dropbox,
though your instructor will only look at the last submission.
The unit4project.zip file must
contain the following:
1.
The final design documentation as a single document. named design.doc or design.docx. (if
using MS/Word) or design.pdf (if using PDF).
Instructors may, at their discretion, further restrict the
acceptable formats.
This
is the only file that
the instructor will look at to evaluate your design. Your design documentation
must include at
a minimum:
a. A title page, including
the name of your team, the name of the project, the submission date, and the
names all team members. The remaining information will start on the second page.
b. A short overview section
describing the product and the features it included.
c.
One or more UML class diagrams
showing the main classes and interfaces in your design, along
with inheritance (generalization), association, aggregation, and composition
relationships. Include cardinality and role indicators as you deem appropriate
to make the diagram clear. Indicate the role a class plays in any patterns in
which it participates. DO NOT include state or method information. You
will need several class diagrams at different levels of abstraction and for
different subsystems to completely document your design in a way that the
reader can physically see and intelligently understand.
d.
One or more other UML diagrams
(e.g., sequence charts, collaboration diagrams, state diagrams) to provide
insight into the key static and dynamic characteristics of the program both
before and after refactoring.
e.
A CRC refactoring table for each class
that is involved in your refactoring. You do not have to document classes that
your design changes do not touch.
f.
A narrative analyzing the original
design (note: the "original" design is what is in the code you
reverse engineered), its weaknesses and strengths, fidelity to the design
documentation, and use of design patterns.
g.
A narrative outlining how the
refactored design reflects a balance among competing criteria such as low
coupling, high cohesion, separation of concerns, information hiding, the Law of
Demeter, extensibility, reusability, etc. This should include a discussion of
the design patterns used to achieve this balance.
h.
A short reflection on the process of
discovering the design in an existing software system.
i.
A discussion of your metrics analysis
of up to four metric values including answers to the following questions:
i.
What were the metrics for the
original code base? What did these initial measurements tell you about the system.
ii.
How did you use these measurements
to guide your refactoring?
iii.
What are the metrics for the
refactored code base? This only has relevance for the areas of the
refactored design that you implemented.
iv.
How did your refactoring affect the
metrics? Did your refactoring improve the metrics? In all
areas? In some areas? What contributed to these results?
j.
A brief discussion of the aspects of
your refactoring that the team was able to implement, including a list of all
classes that were modified.
2.
A copy of the final presentation
named presentation.doc or presentation.docx (for MS/Word) or presentation.pdf (for PDF). Again, your
instructor may restrict the set of acceptable formats.
3.
All the Java source files required
to compile, link, and run your project.
4.
A JAR file named project.jar containing the final compiled
version of your project.
5.
A PDF file named listing.pdf which contains a listing
of all the source files in a logical order decided upon by the team. It is this
file which will be evaluated for implementation quality.
6.
A copy of the log from SVN or other approved
version control system named vclog.txt. Your instructor will
use this along with the Peer2Peer evaluations and
observations of the team during class to assess the relative contributions of
each team member to the project.
7.
The zip file must be submitted by
the end of the day on which the presentations for this unit are made. Late
submissions will not be accepted; teams are advised to submit something
early to ensure they receive at least minimal credit.
Documentation and Presentation Instructions
You can find general instructions for your
documentation and presentation on the Unit Activities page.
$Id: RefactoringCaseStudy.htm 336
2012-03-10 18:37:08Z mjl $