Ong Wei Xiang - Project Portfolio

The class diagram below depicts the important methods and attributes that provide us the ability to switch views between the main list and the archival list.

The object diagram below illustrates the three UniqueInternshipApplicationList objects maintained by InternshipDiary:

As the name suggests, displayedInternships is the list that is shown to the user in the GUI. It references either archivedInternships or unarchivedInternships at any one time.

When a user is viewing the main list, displayedInternships references unarchivedInternships. And when a user is viewing the archival list, displayedInternships references archivedInternships.

The following sequence diagram illustrates how an archival command is executed. The list command is similar to archival. You may use the same sequence diagram for the list command.

The following code snippet is retrieved from the InternshipDiary class. It illustrates the internal workings of how we switch the view between the archived list and the main list.

It can be seen explicitly from the code snippet that we make use of referencing to switch between the views of archival and main list. However, such implementation brings about issues with reactivity — where elements that reference displayedInternships will not be aware of the reference change in displayedInternships whenever the user executes archival or list. Therefore, in the above scenario, users would still see the main list after executing the archival command.

In order to resolve this issue, we need to employ the observer pattern design. The broad idea is to assign each UI element to be an observer and InternshipDiary to be the observable. Consequently, whenever there is a state change to InternshipDiary, the list of observers will be notified and updated automatically.

To achieve this observer pattern, we made use of the PropertyChangeSupport class and the PropertyChangeListener interface. PropertyChangeSupport is a utility class to support the observer pattern by managing a list of listeners (observers) and firing PropertyChangeEvent to the listeners. A class that contains an instance of PropertyChangeSupport is an observable. On the other hand, a class that implements the PropertyChangeListener interface is an observer.

The class diagram above showcases our implementation of a two-tier observer-observable structure:

We will briefly discuss how the observer pattern works in our implementation.

Whenever an object wants to observe changes in another object, it will call the addPropertyChangeListener function of the PropertyChangeSupport instance from the appropriate object that it wishes to observe. It will also have to specify which property of that object it wants to observe.

In our case, when ModelManager is created, it will call the addPropertyChangeListener function of the PropertyChangeSupport instance belonging to InternshipDiary. The function call will look like this: addPropertyChangeListener("displayedInternships", this) where this is a reference to ModelManager itself (so that it can be registered as a listener of the displayedInternships property of InternshipDiary).

The process is similar for any UI element that wants to observe the filteredInternshipApplications property of ModelManager.

As a result, whenever there is a change to the property displayedInternships in InternshipDiary, the PropertyChangeSupport instance of InternshipDiary will call firePropertyChange to emit a PropertyChangeEvent to ModelManager. The emitted event will trigger the propertyChange function of ModelManager. ModelManager can then retrieve the new reference from the event and update its filteredInternshipApplications accordingly. It will then repeat the event emission process to any UI element (e.g. StatisticsWindow) that is observing the filteredInternshipApplications property.

The following activity diagram gives a high-level overview of the above event-driven process.

As an extension, our team also implemented enumeration for each property that is being observed. This modification ensures type safety and a way for us to track what properties are observed. This is especially important when many properties are being observed.

Below is the updated class diagram with the implementation of ListenerPropertyType enumeration.

As seen from the diagram above, each observable will implement two additional methods to use ListenerPropertyType enumeration as parameters:

This forms a layer of abstraction as we would not be allowed to call the addPropertyChangeListener and firePropertyChange methods of PropertyChangeSupport directly.

The following class diagram depicts our implementation of the extended functionality.

The idea of the implementation can be summarized as follows:

Users are able to execute removal-based commands like archive according to the execution types we have in the enumeration class RemovalBasedCommandExecutionType.

We have implemented the following execution types: BY_INDEX, BY_INDICES, and BY_FIELD. For the execution type BY_FIELD, users can only execute by the Status field of an internship application currently.

It is important to note that each RemovalBasedCommandExecutionType works similarly. At the core, all of them involves retrieving the index of an internship application to execute on. The difference lies in the pre-processing stage — the steps an execution type takes to retrieve all the required indices.

Therefore, to ensure succinctness, we will only be illustrating the usage of the command archive with the execution type BY_FIELD. Other variations of removal-based commands and execution types are similar.

The following sequence diagram provides a high-level overview of how the archive command with the execution type of BY_FIELD is executed in our application.

As illustrated in the diagram above, the pre-processing steps of BY_FIELD involves applying the appropriate predicate to filter the internship applications and then converting these internship applications to their respective index. This provides us with required indices that we will execute the removal-based command archive on.

The following sequence diagram captures how RemovalBasedCommandExecuteTypeParser parses the input and determines the execution type of the command. It also shows how a RemovalBasedCommand is created with the appropriate RemovalBasedCommandExecutionType and command word.

As seen from the diagram above, the parser determined the execution type to be BY_FIELD and generated the appropriate predicate to construct a RemovalBasedCommand instance.

Based on the command word passed in to construct the RemovalBasedCommand instance, RemovalBasedCommand creates a lazy lambda function that can be called to construct the appropriate removal-based command for execution.

The following sequence diagram depicts the above behaviour.

As the command word is archive, a lazy lambda function to construct an ArchiveCommand is returned.

The following sequence diagram captures the process of executing the lazy removal-based command on one index. This particular index allows us to retrieve the appropriate internship application.

It can be seen that the previously-generated lazy command is executed in the above sequence diagram.

ArchiveCommand is constructed and subsequently executed on the index provided, by making the appropriate function call to the model to execute on the internship application. In this case, archiveInternshipApplication is called.

The following sequence diagram captures the process of executing the lazy ArchiveCommand on indices.

As seen above, executeLazyCommandOnIndices merely reuses the function executeLazyCommandOnIndex (from the previous sequence diagram) by running it on every index provided. The feedback from each execution is cumulatively concatenated to form a single feedback.

The following sequence diagram captures the process of re-creating the command result in RemovalBasedCommand by using the feedback obtained from the specific command execution, which is ArchiveCommand in our example.

A list of internship application(s) will be passed into the statistics model and upon function call, the statistics model will iterate through the list and generate/update the latest statistics accordingly.