Nicholas Cristian Fernando - Project Portfolio

The undo/redo mechanism is facilitated by three versioned databases VersionedInventory, VersionedAddressBook and VersionedTransactionHistory for Good, Supplier and Transaction data respectively. These versioned classes extend their non-versioned counterparts. These classes also implement the Versionable interface, which has these methods:

These operations are exposed in the Model interface, which extends Versionable as well. Each call of these methods will call the respective methods of each of the versioned classes.

The class diagram below shows how the classes are related to each other.

The three versioned classes use the same logic for versioning, so only VersionedInventory will be mentioned in subsequent examples and diagrams.

The sequence diagram below illustrates the events that occur when a user calls the undo command assuming that there is a state to return to. VersionedAddressBook#undo() and VersionedTransactionHistory#undo() are called as well, but omitted for brevity.

Currently, VersionedInventory uses LinearHistory for versioning, and delegates all Versionable methods to it. LinearHistory can store objects of Inventory class, which has implemented the Copyable interface to allow creation of independent copies for storage. On the other hand, LinearHistory implements the interface Version, which extends from Versionable and has the following additional method:

The class diagram below shows how the classes are connected such that VersionedInventory is able to use LinearHistory.

Given below is an example usage scenario and how the undo/redo mechanism behaves at each step. For simplicity, goods are each represented with strings containing their name and quantity.

Step 1. The user launches the application for the first time. The VersionedInventory will be created with a list of Good objects from storage, while creating a LinearHistory that stores a copy of this state, and also stores another copy in its history. Using copy() method from Copyable ensures currentState and saved0 are independent Inventory objects.

Step 2. The user executes delete-g 3 command to delete the 3rd good in the inventory list. The delete-g command first deletes the 3rd good in the currentState of the LinearHistory, exposed by VersionedInventory. Then, the command calls Model#commit() since it modifies the data. LinearHistory then makes a copy of the modified currentState and stores it in the history, moving the statePointer up.

Step 3. The user executes buy 1 g/apple q/5 to buy 5 apples from the first supplier. Let us assume that the first supplier sells apples. The buy command also calls Model#commit() as it modifies the data, causing LinearHistory to save a copy of the modified currentState.

Step 4. The user now decides that buying the apples was a mistake, and decides to undo that action by executing the undo command. The undo command will call Model#undo(), which will shift the statePointer one step backward, pointing it to the previous saved state saved1, and updates currentState with saved1.

The redo command does the opposite — it calls Model#redo(), which shifts the currentStatePointer one step forward, pointing to the previously undone state, and restores the currentState to that state.

Step 5. The user then decides to execute the command list-t. Commands that do not modify the data, such as list-t, will not call Model#commit(). Thus, the history and currentState in LinearHistory remains unchanged.

Step 6. The user executes sell 2 q/1 p/5 to sell 1 of the second goods in the list, banana. This calls Model#commit(). Since there is a branching in history, all states after the state pointed by statePointer will be purged. Many mainstream editing software exhibit this behaviour, which would condition the user to expect this behavior.

The activity diagram below shows the conditions under which Model#commit() is called by a command, and its effects. As shown, only undoable commands that are successfully executed will call Model#commit() and purge the "future" states. This behavior in command execution guards against unwanted states being saved during invalid commands and confusing the user. In addition, the guard against invalid execution at the start helps to keep the currentState free of changes when the command will be invalid. Thus, the correctness of the commit() behavior is tied to the correct command execution protocol.