Design & Testing

USES Relation

The USES relation indicates dependencies within classes in a project. In the diagram below, the interface classes are to the left, and the algorithm/base classes are to the left. The interface classes are dependent on the functionality of the algorithm since the base classes/algorithm must be completely implemented in order to test the interface classes (since they read in information about the camp from the current camp object).

Cohesion & Coupling

The interface and algorithm modules are loosely coupled -- they only communicate by passing parameters through method invocations; therefore, the modules are data coupled.

Both modules in the HOOPS project are functionally cohesive: In the interface module, all of the classes and methods facilitate the task of inputing, viewing and modifying information about a schedule. Since all of the methods contribute to a single, well-defined outcome, the interface module is functionally cohesive. The goal of the scheduling module is simply to store, process and retrieve the data from the interface module. All of the methods contribute to a single task; therefore, the algorithm module is also functionally cohesive.

Build & Test Plan

In order to throroughly test the HOOPS project, we incorporated the two approaches below into our test plan:
  • Generating schedules from prior camp data
  • Boundary and problem case testing
The first approach simply involves acquiring the schedule information from our client from three prior camps, and entering that data into the HOOPScheduler program. If the package is working correctly, a schedule will be generated that satisfies all of the scheduling constraints defined by the user, and the user will be able to view and modify the information using the CampEditor. This is an example of black box testing.

The second approach will reinforce the results of the first type of testing