Typee - Developer Guide

MainWindow will have an additional method fetchTabInformation(tabName). After the parser executes the TabCommand, it will return a CommandResult with Tab property.
System will then check whether the input name matches with one of the tab names in the system. If there is a match, system will fetch the tab information and return the Tab object. If no match is found, system will return with an empty tab with only name attached.

The undo/redo mechanism is facilitated by HistoryManager. It extends EngagementList with an undo/redo history, stored internally as an historyList and versionPointer. Additionally, it implements the following operations:

These operations are exposed in the Model interface as Model#saveEngagementList(), Model#undoEngagementList() and Model#redoEngagementList() respectively.

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 HistoryManager will be initialized with the initial engagement list state, and the versionPointer pointing to that single engagement list state.

Step 2. The user executes delete i/5 command to delete the 5th person in the engagement list. The delete command calls Model#saveEngagementList(), causing the modified state of the engagement list after the delete 5 command executes to be saved in the historyList, and the versionPointer is shifted to the newly inserted engagement list state.

Step 3. The user executes add t/meeting …​ to add a new engagement. The add command also calls Model#saveEngagementList(), causing another modified engagement list state to be saved into the historyList.

Step 4. The user now decides that adding the person was a mistake, and decides to undo that action by executing the undo command. The undo command will call Model#undoEngagementList(), which will shift the versionPointer once to the left, pointing it to the previous engagement list state, and restores the engagement list to that state.

The following sequence diagram shows how the undo operation works:

The redo command does the opposite — it calls Model#redoEngagementList(), which shifts the versionPointer once to the right, pointing to the previously undone state, and restores the engagement list to that state.

Step 5. The user then decides to execute the command sort p/start o/ascending. Commands that do not modify the engagement list, such as sort, will usually not call Model#saveEngagementList(), Model#undoEngagementList() or Model#redoEngagementList(). Thus, the historyList remains unchanged.

Step 6. The user executes clear, which calls Model#saveEngagementList(). Since the versionPointer is not pointing at the end of the historyList, all engagement list states after the versionPointer will be purged. We designed it this way because it no longer makes sense to redo the add d/meeting …​ 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:

The sort mechanism is facilitated by EngagementComparator. The EngagementComparator is an enum class that implements Java Comparator<Engagement> and specifies the comparing logic of 8 different orders, namely START_TIME, START_TIME_REVERSE, END_TIME, END_TIME_REVERSE, ALPHABETICAL, ALPHABETICAL_REVERSE, PRIORITY, and PRIORITY_REVERSE. Each positive sequence comparator compares two Engagements with the field specified within its name in ascending order, and _REVERSE comparators compare in descending order.

Additionally, the Model interface is modified to support the following methods:

These operations are implemented in the ModelManager class as ModelManager#setComparator(Comparator<Engagement>), ModelManager#updateSortedEngagementList() and ModelManager#getSortedEngagementList() respectively.

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

Step 1. The user launches the application for the first time. The currentComparator will be initialized as null.

Step 2. The user executes sort p/priority o/ascending command to sort the engagement list in ascending order of priority. The sort command calls Model#setComparator(), causing the currentComparator in ModelManager to assume the value EngagementComparator#PRIORITY. The command then calls Model#updateSortedEngagementList to execute the sorting.

The following sequence diagram shows how the sort operation works:

Step 3. The user executes add t/meeting …​ p/high to add a new engagement. The add command also calls Model#updateSortedEngagementList() with currentComparator, causing the execution of sorting after the new engagement is added to the list, to preserve the current ordering.

Step 5. The user then decides to execute the command list. Commands that do not modify the engagement list or alter the order of the list, such as list, will usually not call Model#setComparator(Comparator<Engagement>), or Model#updateSortedEngagementList(). Thus, the internal ObservableList remains unchanged.

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

The feature will be implemented as an additional type of Command; PdfCommand

Util class PdfUtil will be implemented for handling all pdf document creation related methods. It will be implemented under util package and it will be able to deliver few essential features that are necessary for document creation.

Below is the sequence diagram for document generation which displays the concept of how this feature will be implemented by multiple interaction between different architecture components.

ReportWindow will be the UI container which helps the user to interact using PdfCommand. The window will include dynamic tree-view that is directly linked to the external directory in the file-system; reports/

The CalendarWindow is part of the MainWindow. Specifically, it is one possible Tab which can be displayed. The CalendarWindow class and any of its associated UI components can be found under the com.typee.ui.calendar package.

The following sequence diagram shows the creation of a CalendarWindow instance when the user switches to the calendar window tab.

The CalendarWindow class was designed with the observer pattern in mind. The calendar’s display and any open engagements list windows are automatically updated as engagements are added to or deleted from the application. CalendarDateCell and EngagementListViewCell both have a reference to an ObervableList of engagements in order to conform to the observer pattern. The following table shows all UI components which are used and their respective purposes.

The following are the four commands which interact with CalendarWindow. They are accompanied by their respective activity diagrams which are used to model their workflows:

The game feature is implemented using the singleton pattern using the singleton class GameWindow which is created by button-click in StartWindow. This means that there can only be one gameInstance at any given time with the exception of the game being over. The two diagrams below show the UML sequence diagram and activity diagram of the game window, which gives a high level overview of the game.

GameWindow has three main components PlayerInformation, GameBody and Player.

The component GameBody makes use of javafx.animation.AnimationTimer API to continuously loop MovingWords objects moving from top to bottom of the window using GameBody#loopWords(). MovingWords are created using HighlighterUtil#convertToTextFlowUsing(String word) , which appears as a TextFlow object of javafx.scene.text API.

Player input is represented as a javafx.beans.property.StringProperty in Player. Based on player input, MovingWords are updated using HighlighterUtil#convertToTextFlowUsing(String playerInput, String word) , which appears as a highlighted TextFlow object. In order to update the MovingWords object, the API javafx.animation.AnimationTimer is used by calling MovingWords#continuouslyUpdate().

The component PlayerInformation is bound to Player using javafx.beans.property API and is also updated when MovingWords#continuouslyUpdate() is called.

The table below summarises the various purposes of the 3 main Game Window UI components.

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.