Ng Jun Hao - Project Portfolio

Typically, engagement managing software require users to enter the entire command in one shot.

For example, a user that wishes to add a meeting must type out the following: - add t/meeting s/16/11/2019/1500 e/16/11/2019/1600 l/Meeting Room 2 d/Team Meeting a/John | Smith p/High

This can prove to be rather tedious and cumbersome as users must remember every detail of a command.

Typee overcomes this by allowing users to interact with its interface and build commands sequentially. Users just need to type the relevant command word to get prompted about subsequent inputs.

With interactive parsing, the aforementioned 'Add' command reduces to the following sequence of inputs: -

Experienced users that have a grasp of the structure and format of various commands can also benefit from this feature. Interactive parsing allows multiple arguments to be input simultaneously, as long as the entered arguments adhere to a set of rules detailed in a later subsection.

The same 'Add' command can be constructed this way by a fairly experienced user: -

Finally, a highly experienced user can create an 'Add' command in the conventional manner, i.e. by typing out the entire command at once. This is identical to the format introduced in the beginning of this section: - add t/meeting s/16/11/2019/1500 e/16/11/2019/1600 l/Meeting Room 2 d/Team Meeting a/John | Smith p/High

All commands are parsed and built interactively. Each command, however, adheres to its own structure. Individual commands' structures and idiosyncrasies are detailed in the sections belonging to the respective commands.

In general, commands are of two types - static and dynamic.

At any point of time, the user can enter // current to view the current input constraints and input // clear to stop parsing the current command. These are examples of dynamic commands.

Static commands are executed one at a time, whereas dynamic commands can be built at any point of time, even while parsing an ongoing static command.

Examples:

'Add' and 'Delete' are static commands. The following input sequence is invalid: -

'Help' and 'Exit' are dynamic commands. Therefore, the following input sequence is valid: -

Valid input sequences can be one of three types.

After the last argument is specified, the required command is built and executed, carrying out the operation intended by the user.

The order of arguments entered is important. Consider the 'Add' command. The ideal ordering is as follows: - add t/ s/ e/ l/ d/ a/ p/

When users resort to any of the three aforementioned forms of supplying arguments, they are required to conform to the specified ordering.

When the arguments aren’t in order, then the input is parsed as far as possible, in the expected order of the arguments.

For example, add t/meeting l/Meeting Room 2 is parsed till the argument for t/. The parameter location is deemed invalid and the user is prompted to enter a start date-time.

This happens because the parser expects an argument for s/, but there is no such argument. As a consequence, all arguments that are supposed to be entered after s/ (like l/) are not parsed.

Similarly, add t/meeting s/15/01/2019/1500 d/desc p/low is parsed till s/ and a prompt is raised to enter a valid end date-time, leaving d/ and p/ untouched.

Thus, to summarize, the parser continues parsing in the order of the expected arguments, as long as the corresponding prefixes are found in the input.

Erroneous inputs occur in three mutually exclusive categories.

An example of the first case is as follows: add t/teeming. "Teeming" is an invalid engagement type. Typee flags this inaccuracy and prompts the user to enter an acceptable engagement type instead. Since Typee has already begun building an 'Add' command, the subsequent input must begin with t/…​

Attempting to replace the argument for a parameter or supply different arguments to the same parameter will result in Typee rejecting the user input.

For example, the input add t/meeting t/interview will be rejected.

The following sequence will also be rejected since it attempts to overwrite an argument.

Last but not least, Typee will reject cases wherein the user supplies excessive and irrelevant arguments. add t/meeting s/16/11/2019/1600 e/16/11/2019/1700 l/COM-1 d/Meeting a/Damith p/High o/High will be rejected because o/ is not a parameter for the 'Add' command.

Interactive parsing allows users to build a command sequentially, as opposed to doing it entirely in one shot. A user that wishes to add an interview can simply type add t/interview to receive prompts on what to enter next.

This feature was conceived to make the application easy to use for amateur users.

Important Classes:

The interface InteractiveParser is the connecting interface between the LogicManager and the main Parser. This interface is designed by contract (DbC - proposed by Bertrand Meyer). The interface exposes four methods to the LogicManager, namely:

To achieve interaction, the Parser keeps track of the State of the current Command being built. State is an abstract class that represents the individual states the application can be at in the midst of building a Command. EndState is an abstract class that extends from State, from which Command objects can be built. As and when valid inputs are entered, the Parser updates the current State to the subsequent States of the corresponding Command.

The Parser starts at an idle, inactive State Upon entering add t/meeting, the State being tracked is changed twice - first to the State corresponding to the type of the Engagement and then to the State responsible for the start date-time.

Such State changes happen sequentially until all the arguments necessary for the Command have been supplied. When all necessary arguments are present, the State being tracked transitions into an EndState. Once the tracked State transitions into an EndState, the Parser builds the Command which is executed by the LogicManager.

The structure of the interactive parser is detailed in the UML diagram below.

Parsing of user entered inputs can be viewed as parsing a small, finite context-free language. The command built by a sequence of inputs is uniquely determined by the sequence of inputs entered by the user and happens to be deterministic.

This observation allows the Parser to be modeled by a finite state machine. A finite state machine is an abstract computational model which consists of a machine comprising several states. At a particular point in time, only one state of the state machine is active. The machine transitions from one state to another state if certain conditions are met.

In the context of Typee’s Parser, the parser of each individual Command is a distinct finite state machine. The condition to be satisfied to transition to another state is the validation of user-entered inputs.

The incorporation of state machines into the Parser is done by implementing a slightly modified version of the state pattern documented by the Gang of Four (GoF).

Upon initiating the parsing (building) of a Command, the state machine that corresponds to the required Command is instantiated and set to its initial state. This state becomes the State tracked by the Parser Subsequent inputs are tokenized by the ArgumentTokenizer class, processed by the InputProcessor class and forwarded to the current State. If the input is deemed valid, the Parser invokes the transition() method of the current State to proceed to the next State. This process is repeated until an EndState is reached. Throughout this process, the user receives feedback from the Parser in the form of an encapsulated CommandResult object.

Below is a sequence diagram illustrating the processes that occur when the user enters add t/meeting s/15/11/2019/1500 e/15/11/2019/1600.

The high-level working of the Parser can be summarized by the activity diagram shown below.