Code Refactoring of PG Components

Team Members

Paul Bryan

Benjamin Chen

Steve Lineberry

Richard Trull

1. INTRODUCTION

Purpose

The purpose of this project is to refactor existing code in order to promote efficiency, understandability, and to reduce complexity. This project includes the removal of redundant code and unnecessary object instantiation. Code will be restructured to convey readability, handle exceptions, and check that the access modifiers are used correctly.

This project differs from others because no enhancements are being designed into the system. As a result, many portions of the design document do not pertain to this project. Dr. Gehringer is aware of these discrepancies.

Scope

The scope of the project includes modifying the following java classes: LinkPage.java, ViewPage.java, and RcvPage.java. Java code for objects instantiated within these pages are not changed unless their current design prevents the listed files from being written effectively. No additional features will be developed. Existing code will be tested to ensure the functionality does not change.

Background

The program being modified is called the Peer Grading System (PG System). Its purpose is to allow students to evaluate work submitted by their peers. The PG System was designed with the following objectives:

  • To permit students to provide feedback on assignments to improve communication.
  • To improve the evaluation process by pooling knowledge from the entire class.
  • To help in the teaching of engineering design.

Documentation

The project incorporates the following files:

LinkPage.java

This servlet serves as the main page for the Peer Grading system. Once a user has logged in, this class provides links to various actions that involve assignments.

RcvPage.java

This servlet is responsible for the prompting and transfer of files to the Peer Grading system.

ViewPage.java

This servlet allows a user to view past assignments that have been entered into the Peer Grading System. Previous submissions and other information are displayed.

NOTE: Our copy of the PG System has fatally crashed and cannot be viewed. We have discussed this problem with Dr. Gehringer, but still have not resolved the issue. As a result, we have not been able to test the system pertaining to the files we intend to modify. Subsequently, we cannot give a complete and full description of the provided servlets.

Standards

All developed code will adhere to the java coding guidelines, including use of javadocs.

Other Documents

We will be using the website as reference to the Java APIs.

In addition, we will be using the following books as additional references.

  • Core JAVA Fundamentals
  1. SYSTEM ARCHITECTURE

The following UML describes the files to be modified in their current form.

Assumptions

For the project, the code that is being modified is assumed to be correct and meet all system requirements. Current interactions with other components will be the basis for refactoring decisions to ensure that functionality does not change.

  1. REQUIREMENTS

The main objective for the refactoring project is to clarify and improve code quality. Although specific implementation details will change through this process, the functionality of the system will remain intact. The overall requirements to the system will therefore not change.

  1. TESTING

As per instruction from Dr. Gehringer, our project will require no use cases or extensive layout of classes. Rather, the code will be tested by systematically probing all options provided by the three servlets. A baseline of tests will be built before any code modifications take place. These tests will then be applied to the system incrementally to ensure that no bugs have been introduced.

  1. REFACTORING PROCESS

Through inspection of the source code, the following problems have been found:

Problem 1: Hard coded values

Description: Many of the combo boxes found on the main page (provided by the LinkList.java servlet) are populated through numerous static calls. While effective, this method creates many unnecessary lines of code.

Solution: The combo boxes that are populated in this manner can be optimized through the use of for loops.

Problem 2: Very large methods

Description: Several methods, such as the doPost method, are very large and hard to understand.

Solution: In most cases, large methods can be shortened through the use of smaller helper methods. Such methods could be reused across different components.

Problem 3: Legacy Code

Description: As the system has been modified for bug fixes and enhancements, unnecessary code has accumulated.

Solution: Isolate and remove all dead code.

Problem 4: Code beautification

Description: As code has been modified in the system, developers have not adhered to the same documentation or coding styles. This results in code that is harder to read and understand.

Solution: Beautify the code with a consistent standard of documentation, indentation, and style.

Problem 5: Documentation

Description: The provided files contain portions of well documented code, and areas that have no documentation whatsoever.

Solution: Provide a consistent level of documentation to increase understanding for future developers. Comments will be entered in the standard javadoc notation.

Problem 6: Duplicate Code

Description: The LinkPage.java file contains many duplicate portions of code that read the information from a student’s <.prob> file. Code in the other files will likely have similar problems.

Solution: Remove duplicate code by implementing functions.

Problem 7: Unnecessary data structures

Description: Some static methods are called by creating an object of that class. As a result, unnecessary data structures are created.

Solution: Remove unnecessary or redundant objects.