Jin Jing - Project Portfolio

The undo/redo mechanism is facilitated by VersionedBook. There are two extensions of it. VersionedHealthWorkerBook extends HealthWorkerBook and VersionedRequestBook extends RequestBook. Both contain an undo/redo history, stored internally as an healthWorkerBookStateList or requestBookStateList and currentStatePointer. Additionally, it implements the following operations:

These operations are exposed in the Model interface as Model#commit(), Model#undo() and Model#redo() respectively.

The feature also makes use ModifyCommandHistory to keep track of the commands that modified the books. It contains currentStatePointer and a list of CommandType enums to differenciate the type of command to undo or redo. Similar to CommandMode, the various CommandType enums are:

Given below is an example usage scenario and how the undo/redo mechanism behaves at each step.

Step 1. The user launches the application for the first time. The VersionedRequestBook and VersionedHealthWorkerBook will be initialized with the initial state, and the currentStatePointer for each VersionedBook pointing to that single book state. Since no modify command has been called, the initial list of commands in ModifyCommandHistory is empty and the initial currentStatePointer of ModifyCommandHistory is initialized to -1.

Step 2. The user executes delete r 5 command to delete the 5th request in request book. The delete r command calls Model#commit(REQUEST_COMMAND), causing the modified state of the request book after the delete r 5 command executes to be saved in the requestBookStateList, and the currentStatePointer is shifted to the newly inserted request book state. Since the request book is modified, the enum REQUEST_COMMAND is added to the modifyCommandHistory list within the ModifyCommandHistory class and the currentStatePointer is now pointing at the most recent command. The VersionedHealthWorkerBook is unaffected.

Step 3. The user executes add h n/David …​ to add a new healthworker. The add h command also calls Model#commit(HEALTHWORKER_COMMAND), causing a modified health worker book state to be saved into the healthWorkerBookStateList and the currentStatePointer is shifted to the new health worker book state. The enum HEALTHWORKER_COMMAND is added into the modifyCommandHistory list of the ModifyCommandHistory class. The VersionedRequestBook is unaffected.

Step 4. The user now decides that adding the health worker was a mistake, and decides to undo that action by executing the undo command. The undo command will call Model#undo(), which will first obtain the type of command that needs to be undone by caling ModifyCommandHistory#getUndoCommand(). In this case HEALTHWORKER_COMMAND is returned, and hence will call undo on VersionedHealthWorkerBook. It will shift the currentStatePointer once to the left, pointing it to the previous health worker book state, and restores the health worker book to that state. The currentStatePointer of the ModifyCommandHistory also gets shifted once to the left, pointing it to the previous command.

The user first enters the undo command in the command line interface. The logic manager processes the command as a string and checks using the AddressBookParser is the string is a valid command. In this case, the parser sees that the command string matches the undo command string and hence returns an undo command to the LogicManager which then calls execute() to execute the command. The execute() method calls Model#undo() in which the model checks the ModifyCommandHistory for the correct VersionedBook that needs to be undone and then calls VersionedBook#undo(). Upon a successful undo, the UndoCommand will return a successful result to the LogicManager which will then the "Undo Success!" message will be displayed on the command line interface.

The following sequence diagram shows how the undo operation works:

The redo command does the opposite — it calls Model#redo(), which first obtains the command type by calling ModifyCommandHistory#getRedoCommand() and based on the returned command type it shifts the currentStatePointer once to the right, pointing to the previously undone state, and restores the respective book to that state.

Step 5. The user then decides to execute the command list r. Commands that do not modify the books, such as list r, will not call Model#commit(), Model#undo() or Model#redo(). Thus, the VersionedBook s and ModyfiCommandHistory do not change.

Step 6. The user executes delete h 1, which calls Model#commit(HEALTHWORKER_COMMAND). Since the currentStatePointer is not pointing at the end of the healthWorkerBookStateList, all health worker book states after the currentStatePointer will be purged. We designed it this way because it no longer makes sense to redo the add n/David …​ command. This is the behavior that most modern desktop applications follow.

The following activity diagram summarizes what happens when a user executes a new command: