Lee Yi Quan - Project Portfolio

As there are many different kinds of course requirements that can be found in NUS, it is difficult to iron down the common characteristic they all share. This can be seen in the examples found below:

For the requirement shown in Figure 9, students just have to complete at least one of CS3203 or CS3216 and CS3217 or CS3281 and CS3282. Whereas for the requirement in Figure 10, students have to fulfill all of the conditions stated above. Even though these two conditions might seem quite different, we are still able to draw some key observations about what they have in common:

These observations gives us some insight as to how we should design the interface. As such, the CourseRequirement interface follows a Composite design pattern. This is favoured as it allows us to treat individual and composition of CourseRequirement objects uniformly through the use of polymorphism. The diagram below gives an overview of how CourseRequirement is implemented.

This interface is realised by 2 subclasses - PrimitiveRequirement and CompositeRequirement. The PrimitiveRequirement is the simplest building block for CourseRequirement. Each PrimitiveRequirement stores a list of Condition objects. A Condition object stores a Java Pattern and an int, minToSatisfy. A Condition is satisfied if there are at least minToSatisfy many distinct ModuleInfoCode that matches Pattern in it. PrimitiveRequirement is satisfied only if all Condition objects in the list are fulfilled.

For instance in Figure 9, a suitable Condition for completing CS3216 and CS3217 would be a Pattern that accepts only CS3216 or CS3217, and a minToSatisfy of 2.

The CompositeRequirement can replicate the behaviour of more complex course requirements. Each CompositeRequirement object contains two CourseRequirement objects. It also contains a LogicalConnector enumeration that tells the CompositeRequirement how two different CourseRequirement are composed using logical operations. For instance, for a list of ModuleInfoCode to satisfy a CompositeRequirement that has a AND LogicalConnector, the list must satisfy the both CourseRequirement objects contained in CompositeRequirement.

There currently 3 methods that CourseRequirement provides information to the student:

The RequirementStatus is an association class that links a CourseRequirement with VersionedGradTrak in Model. This can be seen in the class diagram below:

It also stores the result of the associated CourseRequirement object’s isFulfilled and percentageFulfilled methods acting on the list of ModuleInfoCode.

Below is a sequence of execution when displayreq command is executed by the student:

The sequence diagram below summarises the execution mentioned earlier:

We chose the current choice over the alternative due to time constraints in the project. Moreover, our current choice is sufficient to replicate most NUS requirements accurately.

We chose our current choice as it takes up much fewer space to store. Moreover, storing a pattern also improves performance time since each ModuleInfoCode is compared against one`Pattern` instead of an entire list of String objects.