ProManage - Developer Guide

This project follows oss-generic coding standards. IntelliJ’s default style is mostly compliant with ours but it uses a different import order from ours. To rectify,

Optionally, you can follow the UsingCheckstyle.adoc document to configure Intellij to check style-compliance as you write code.

After forking the repo, the documentation will still have the SE-EDU branding and refer to the se-edu/addressbook-level4 repo.

If you plan to develop this fork as a separate product (i.e. instead of contributing to se-edu/addressbook-level4), you should do the following:

Set up Travis to perform Continuous Integration (CI) for your fork. See UsingTravis.adoc to learn how to set it up.

After setting up Travis, you can optionally set up coverage reporting for your team fork (see UsingCoveralls.adoc).

Optionally, you can set up AppVeyor as a second CI (see UsingAppVeyor.adoc).

When you are ready to start coding,

The sort mechanism is facilitated by Comparator<Event>. When the sort method for FXObservableList is called, it will take a Comparator object to be use for sorting the list. The comparator is able to take in two Event class objects and compare the relative parameter values. The parameter can be EventName, Date & StartTime. To allow sorting of these parameters, there are three types of comparators.

The invite command allows users to add attendees to an existing event, which is represented by an Event object. The command currently only allows users to add a single person to an event at a time, based on the indices on the UI. This command adds the to-be-invited Person 's email, which is unique, to the chosen Event, so that the attendees of a particular event is recorded.

The adding of attendees is facilitated by the class: Attendees, which consists of a list of emails of type String.

The following is a more detailed description of the Attendee class:

Storing only the email of Person in the Attendees object of Event saves memory storage and facilitates the select, viewmine and selectEvent feature. As we select a person, we can simply iterate through the event list and check whether the person’s email is in the attendees list. Similarly, as we select an event, we can first obtain the list of emails from the Attendees, and filter the employee list accordingly.

This command only executes successfully if the event does not not clash with the person’s schedule.

Given below is an illustration to describe the detection of whether two events clash, which is facilitated by the method hasClash in Event:

Thus, to check whether the event clashes with an employee’s schedule, we iterate through the ObservableList<Event> and check whether the Event 1) contains the employee’s email in the Attendee and 2) clashes with the selected event.

Implementation of RemoveCommand is similar to InviteCommand, but removes persons from Attendees of events instead.

Given below is an example usage scenario and how the invite mechanism works.

For example, the user inputs invite 1 to/1 to invite the 1st person in the address book to the 1st event in the event list.

Step 1. The command text is passed to an instance of the LogicManager class.

Step 2. The LogicManager instance calls ProManageParser#parseCommand, which parses the invite command phrase.

Step 3. InviteCommandParser#parse parses the person and event index. An instance of the InviteCommand encapsulating the two indices information is then returned after parsing.

Step 4. Logic Manager then executes this InviteCommand by calling InviteCommand#execute.

Step 5. The filtered person list and event list is first obtained by calling PersonModel#getFilteredPersonList and EventModel#getFilteredEventList. Based on the indices, the Person and Event is selected. Then, the Person object’s email is obtained by calling Person#getEmail

Step 6. Two steps of verification is required before the person is invited to the event.

Step 7. After successful verification, the person’s email is added to the obtained Attendees object. The new Attendees object is then added to a new copy of the Event object.

Step 8. The new Event object is updated to the model by calling Model#updateEvent.

Step 9. The InviteCommand#execute finally returns a CommandResult with a success message.

The sequence diagram below illustrates the execution of the invite command.

The select command allows users to view the event schedules of an employee on a certain date, month, and year, or all of his/her events. The command currently only allows users to view the event of a single employee, based on the indices of the employee list on the UI. This command only executes successfully if the input index is valid (not out of bound).

The command is facilitated by the class: Attendees, a HashSet of emails of type String, as described in Section 3.2.1.

Given below is an example usage scenario and how the select mechanism works.

For example, the user inputs select 1 y/2018 m/06 to select the 1st person in the address book and view his/her event schedule on June 2018.

The sequence diagram below illustrates the execution of the invite command.

The findEvent allows the user to search for an event using some keywords. It searches for such events which contain at least one of keywords in their names or description.

Given below is an example usage scenario and how the findEvent mechanism works.

Step 1. The user inputs findEvent meeting to find the event containing the word meeting in its name or description.

Step 2. The command is parsed and the result is shown.

The list feature allows users to filter through all the individual people in ProManage and understand which department they are from. The command currently has 4 sub-features; list all , list all people, list all events and list dep DEPARTMENT. The user can list all the people and events in ProManage by simply typing list all. Alternatively, the user can filter through ProManage and get the relevant Person’s information by listing those of the specified department. The user can list multiple departments such as list dep Admin Finance. As of now, each person can only be inside one department.

The listing of people from the respective departments is facilitated by the class: Departments, a list of departments of type String.

The following is a more detailed description of the classes involved:

Given below is an example usage scenario and how the list mechanism works.

Step 1. The user executes list dep Admin to list only the people in the Admin department. The command text is passed to an instance of the LogicManager class.

Step 2. The LogicManager instance calls ProManage#parsecommand, which parses the list command prefix "list".

Step 3. ListCommandParser#parse parses the type of command that is called upon and if applicable, the departments listed. The list command can take in either all, all people , all events or dep. all means that are no predicates and 'dep' means specific departments are about to be listed. An instance of the ListCommand encapsulating the type of ListCommand and if applicable, the predicates involved, is then returned to Logic Manager.

Step 4. Logic Manager then executes this ListCommand by calling ListCommand#execute.

Step 5. The filtered person list is first obtained by calling PersonModel#updateFilteredPersonList. Based on the departments, the list of Person are selected.

Step 9. The ListCommand#execute finally returns a CommandResult with a success message.

The sequence diagram below illustrates the execution of the list command.

The undo and redo feature allows users to undo and redo their previous commands. The commands that can be undone are only those that modify the contents of the address book or event list, such as adding a person or event within the app. This is managed within ModelManager.

The undo/redo mechanism is implemented separately for the address book and event list by the VersionedAddressBook and VersionedEventList. They are extensions of the superclass AddressBook and EventList respectively with a history of states stored internally as an addressBookStateList for the address book, eventListStateList for the event list, and a currentStatePointer in each of them. To ensure that the address book and event list are undone/redone correctly, a StateHistoryList (sub-class of LinkedList) is kept in the ModelManager to keep track of the list that was modified.

The following operations were implemented:

These operations are exposed in the Model interface as Model#commitAddressBook(), Model#undoAddressBook() and Model#redoAddressBook() for the address book, and Model#commitEventList(), Model#undoEventList() and Model#redoEventList() for the event list. Two wrapper methods, Model#undo() and Model#redo() are also implemented. These will be the methods called by the commands undo and redo.

The StateHistoryList implements the following operations for the Model to decide whether to undo/redo the address book or event list:

A command can either modify the address book, event list, or both. Within the model, the StateHistoryList keeps track of all model methods which modify the address book or event list, and stores a history record value within itself for each method called.

When undoing a command, the ModelManager requests for the latest record by StateHistoryList#getCurrentState() and calls the corresponding VersionedAddressBook#undo() and/or VersionedEventList#undo(). The ModelManager also informs the StateHistoryList that an undo command was issued to shift the pointer back.

When redoing a command,the ModelManager requests for the next record from StateHistoryList and calls the corresponding VersionedAddressBook#redo() and/or VersionedEventList#redo(). The ModelManager also informs the StateHistoryList that an undo command was issued to shift the pointer forward.

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 VersionedAddressBook and VersionedEventList will be initialized with the initial address book and event list states, and the currentStatePointers will point to their single state respectively. The StateHistoryList is instantiated as an empty list.

Step 2. The user executes add (with valid input arguments) to add a person to the address book. The add command calls Model#addPerson(), which will add a state record index integer STATE_ADDRESSBOOK to the StateHistoryList. This command is the last entered command, therefore the pointer in StateHistoryList shifts forward. The add command also calls Model#commitAddressBook(), causing the modified state of the address book after the add command executes to be saved in the addressBookStateList, and the address book currentStatePointer is shifted to the newly inserted address book state. The currentStatePointer for VersionedEventList remains unchanged as only the VersionedAddressBook was modified..

Step 3. The user realises that they have accidentally added the wrong person, and decides to undo the action by executing the undo command. The undo command calls Model#undo(), which gets the latest record state from StateHistoryList and recognises that the VersionedAddressBook was modified in the previous command. The Model#undoAddressBook() is then called, which shift the currentStatePointer once to the left, pointing it to the previous address book state, and restores the address book to that state. Also, the pointer in StateHistoryList is shifted to the left by StateHistoryList#decrementPointer.

The following sequence diagram shows how the undo operation works:

Step 4. The redo command does the opposite — it calls Model#redo(), which shifts the currentStatePointer in either the VersionedAddressBook and/or VersionedEventList once to the right, pointing to the previously undone state, and restores it to that state.

Step 5. The user then decides to add a new event to the event list, by the addEvent command. The addEvent command calls Model#addEvent(), which will add a state record index integer STATE_EVENTLIST to the StateHistoryList. This command is the last entered command, therefore the pointer in StateHistoryList shifts forward. The addEvent command also calls Model#commitEventList(), causing the modified state of the event list after the addEvent command executes to be saved in the eventListStateList, and the event list currentStatePointer is shifted to the newly inserted address book state. The currentStatePointer for VersionedAddressBook remains unchanged as only the VersionedEventList was modified.

Step 6. The user then decides to execute clear. Since this command must clear both the address book and event list, the clear command calls both Model#commitAddressBook() and Model#commitEventList(). It adds a state record index integer STATE_BOTH to the StateHistoryList. The currentStatePointer in both VersionedAddressBook and VersionedEventList shifts to point to the newly added states respectively.