Developer Guide

In order to start the setup, you are required to install the following:

Current Implementation

This feature provides different access levels of commands to the user, depending on the password entered.

The following is an example usage scenario of the password feature.

Step 1: User enters password for HQP.

Step 2: decipherUserCommandText() in MainWindow class identifies command as a password input, through the use of isLocked() method in the Password class.

Step 3: unlockDevice() in Password class is called.

Step 4: The user input, userCommandText, is then hashcoded using userCommandText.hashCode().

Step 5: Using a Buffered reader from the ReaderAndWriter class, a loop through passwordStorage.txt tries to match the hashcoded input with an existing password.

Step 6: The user and password are stored in passwordStorage.txt in this format : "userID (hashcoded)password".

Step 7: When matched, the userID is returned and a welcome message is displayed for the particular user.

Current Implementation

This feature enables only HQP to update any existing password.

The following is an example usage scenario of the update password feature.

Step 1: User enters password for HQP.

Step 2: User enters "update password" command.

Step 3: decipherUserCommandText() in MainWindow class identifies the command as "update password" and begins update password sequence.

Step 4: User enters password for HQP.

Step 5: Similar to the password feature, the process of the user input to match the existing HQP password maintains.

Step 6: User enters new 5-character long alphanumeric password.

Step 7: The new entered password runs through passwordValidityChecker() to check if the password is at least 5 characters long and at least alphanumeric. This password is stored as oneTimePassword String.

Step 8: The user enters the same new password. It matches with the oneTimePassword.

Step 9: The Buffered reader then reads reads through passwordStorage.txt, and a Print writer from the ReaderAndWriter class writes existing passwords to a temporary file, while writing the new password in place of the old password that has been requested to be updated.

Step 10: The temporary file is renamed to passwordStorage.txt and deleting the old passwordStorage.txt file.

Step 11: The System returns a message that update password is successful.

Current Implementation

The new "find" command is revised from the existing "find" command in AB3. Instead of finding a person by name, it finds a person using his NRIC. It also implements the following operations:

The following is an example usage scenario of the "find" command:

Step 1: The user input his password and unlocks the system.

Step 2: The user executes "find s1234567a" command.

Step 3: Parser class determines the command word and runs prepareFind method.

Step 4: prepareFind determines string is a valid nric, then instantiates a new FindCommand.

Step 5: Logic class calls the execute() method on the FindCommand object.

Step 6: The getPersonWithNric() method called in execute() searches the Police Records for the person with "s1234567a" if he exists and person is stored in a list.

Step 7: The person is found and is stored in a matchedPerson list variable. execute() returns a CommandResult using the matchedPerson list as its argument.

Step 8: The CommandResult object displays to the user the searched person and his details, all of which in string form.

Current Implementation

Only HQP may use this command. This command displays the timestamps of which a person with the specified NRIC was screened using the "find" command. The "check" command makes some use of the "find" command. Every time the "find" command successfully finds a person, a line in the format of: "NRIC timestamp" is printed in a text file called "screeningHistory.txt". The "check" command will read this file and retrieve the timestamps corresponding to the specified NRIC.

It also implements the following operations:

Below is an example of its usage:

Step 1: The user(a HQP) input his password and unlocks the system.

Step 2: The user executes "check s1234567a"

Step 3: Parser class determines the command word and runs prepareCheck method.

Step 4: prepareCheck determines string is a valid nric, then instantiates a new CheckCommand.

Step 5: Logic class calls the execute() method on the CheckCommand object.

Step 6: execute() also calls the getPersonWithNric() method. This method will read the screeningHistory.txt line by line, where each line is in the format of "NRIC timestamp", for example "s1234567a 18/10/2018-2038hrs by hqp". Each line is split into the NRIC and timestamp. If line[0] is the NRIC specified, the corresponding timestamp is stored in a list.

Step 7: The list from step 6 gets returned by execute() to create a CommandResult object which displays all the timestamps to the user.

Current Implementation

Only a HQP may use this command. This command allows HQP to update their chosen parameters which include the status, offense, postal code and wanted attributes of a specific NRIC. It is similar to the "find" command in the sense that it searches for the person in the Police Records list by NRIC. At least one parameter must be updated. Offenses are added not replaced.

It also implements these methods:

This is an example scenario of "edit" command

Step 1: The user inputs HQP password and logs in as HQP.

Step 2: The user types "edit n/s1234567a p/510247 s/wanted w/murder o/gun" and executes it.

Step 3: Parser class determines the command word and runs the prepareEdit method

Step 4: prepareEdit method in Parser class would parse each non-empty input such as NRIC, Postal Code, Status, Wanted & Offense from the input text to instantiate the EditCommand class.

Step 5: Logic class then calls the execute method on EditCommand Object. Person with NRIC "s1234567a" is searched for in the Police Records. If he/she exists, then the person’s attributes get updated accordingly.

Step 6: CommandResult with successful message is returned to Logic class, which then displays to user: "Edited person: s1234567a".

Current Implementation

Only a HQP may use this command. A person’s data is allowed to be deleted from the Police Records. It also implements the following methods:

The following is an example usage scenario of the "delete" command:

Step 1: The user(a HQP) input his password and unlocks the system.

Step 2: The user executes "delete s1234567a"

Step 3: Parser class determines the command word and runs prepareDelete method.

Step 4: prepareDelete determines string is a valid nric, then instantiates a new DeleteCommand.

Step 5: Logic class calls the execute() method on the DeleteCommand object.

Step 6: In execute(), the Police Records will be iterated through to see if the person with the said NRIC exists. If not, resultDeletePrediction() will be called to check if any person has an NRIC close to the input.

Step 7: Once the person is deleted, a success message will be displayed to the user using a CommandResult object, else it would be an error message stating the person with said NRIC does not exist

Alternatives considered:

Current Implementation

Once system is unlocked, regardless of which user you are, you can use this command. This command lists the new/unread messages in your inbox based on the password you used to unlock the system. When messages are sent, they are stored inside a text file called "inboxMessages/'userID'", where 'userID' refers to the ID of the intended recipient. These text files store messages directed to each individual who can log in and access their personalised inbox. It also implements the following operations:

The following is an example usage scenario of the "showunread" command:

Step 1: The user input his password and unlocks the system.

Step 2: The user executes "showunread" command. The "showunread" command calls execute() which also calls getMessagesFor() method.

Step 3: The loadMessages() method searches message storage file for the messages directed to the respective user, if any, and they are stored into a data structure.

Step 4: The messages that are found and are stored in a TreeSet, split by its read status, message priority, timestamp, and the message itself for sorting purposes.

Step 5: The concatenateMsg() method will then append all unread messages in sorted order to a string to be passed to the CommandResult object later.

Step 6: execute() returns a CommandResult using the concatenated string as its argument.

Step 7: The CommandResult object displays to the user the number of unread messages he has, and the list of unread messages sorted according to their urgency.

Current Implementation Inbox command has the same implementation as the "showunread" command - except that it shows you all the messages that are in your inbox (both read and unread). This is to allow you to access the messages that you have previously marked as read.

Current Implementation

Once the system is unlocked, you can access unread messages directed to you via the "showunread" command explained above. Once action has been taken based on what the message sent to you is about, you can mark the message as read using the "read" command. Messages displayd in "showunread" command is first stored inside a static HashMap, with the key as the message index and the message itself as the value of the HashMap. When the user wishes to mark a message as read, he will type "read 'index'", and the respective message displayed at that specific index will be marked as read and updated in the message storage file of the user. The "read" command can only be used after the "showunread" command has been used at least once successfully.

The following is an example usage scenario of the "read" command:

Step 1: User inputs his password and unlocks the system.

Step 2: User executes "showunread" OR "inbox" command. If command is successfully executed, a list of unread messages directed to the user will be displayed.

Step 3: Messages that are read from the user’s inbox will also be recorded in a static HashMap called recordNotifications, with the message index used as the key.

Step 4: User executes "read 3" command. If 3 is a valid index (i.e. there were at least 3 unread messages that were displayed), the third message displayed will be marked as read.

Step 5: For the messages to be marked as read, the message itself is updated in the HashMap based on the index, and the message storage text file will be overwritten with the messages stored in the HashMap, effectively updating the read status of the message read.

Step 6: The CommandResult object displays to the user a message indicating that the updating of the read status was successful or not.

Current Implementation

Once the system is unlocked, you can clear your own inbox should there be too many messages stored in it using this command. Once the command has been entered, ReadNotification object will first be generated to attempt reading from the text file storing messages in your inbox. This is to check that the file exists in the first place. If it reads from the text file successfully, a WriteNotification object will then be generated, instantiating a PrintWriter that overwrites the contents in the text file storing the messages in your inbox.

It also implements the following methods:

The following is an example usage scenario of the "clearinbox" command:

Step 1: User inputs his password and unlocks the system.

Step 2: User executes "clearinbox" command. If command is successfully executed, the feedback "Inbox cleared!" will be displayed to the user.

Current Implementation

The rb command is an abbreviation of request backup. Both PO & HQP can use this command as anyone can request for help. When the command is executed, a Msg object is generated. Inside this Msg object, several fields exist which include:

Then the Msg object is passed to the writeNotifcation object to be written into the HQP’s message file. The filepath for HQP’s message is ./inboxMessages/headquartersInbox

It also implements these following methods:

The following is an example usage scenario of the "rb" command:

Step 1: User inputs PO1 password and logs in as PO1.

Step 2: User executes "rb gun".

Step 3: Parser class identifies user command as "rb" and runs prepareRequest method.

Step 4: prepareRequest method identifies offense & current user ID session.

Step 5: RequestHelpCommand class is instantiated with message template consisting & case which in this case is 'gun'.

Step 6: WriteNotification is instantiated to write the message the HQP inbox file.

Step 7: CommandResult with successful message is returned to Logic class, which then displays to user: "Request for backup case from po1 has been sent to HQP."

Current Implementation

Only HQP has access to the "dispatch" command. Dispatch command sends a message to both the designated requester & backup officers. The system creates two WriteNotification classes, the first writes to the requester inbox and the second writes to the backup officer inbox.

The message sent to the requester’s inbox includes the ETA for the backup officer with his/her location both in raw longitude & latitude form and Google Maps URL format.

It is similar for the message sent to the backup’s inbox which includes the ETA that he/she should arrive within & Google Maps URL location of the requester’s Location.

It also implements these following methods:

The following is an example usage scenario of the "dispatch" command:

Step 1: User inputs HQP password and logs in as HQP.

Step 2: User executes "dispatch PO1 gun PO3".

Step 3: Parser class identifies user command as "dispatch" and runs prepareDispatch method.

Step 4: prepareDispatch method identifies PO1 as backup officer, gun as case & PO3 as requester officer.

Step 5: DispatchCommand class is instantiated with 2 different WriteNotification classes for two different files.

Step 6: DispatchCommand object is executed, Msg for requester & backup officer are generated to include content explained above.

Step 7: Both Msg objects are passed to WriteNotification class to be written to the respective recipient files.

Step 8: CommandResult with successful message is returned to Logic class, which then displays to user: "Dispatch for PO3 backup is successful."

Current Implementation

Only HQP can use this command. This command sets the engagement status(the "isEngaged" boolean) of a PO to false. It also implements the following methods:

The following is an example usage scenario of the "updatestatus" command:

Step 1: User inputs password and unlocks the system

Step 2: User executes "updatestatus po1" (example PO here is "po1")

Step 3: Parser class identifies command as "updatestatus" and runs prepareUpdateStatus method.

Step 4: prepareUpdateStatus checks is po1 is a valid PO ID through a regex expression and instantiates a new UpdateStatus command.

Step 5: Logic class calls the execute() method in the UpdateStatusCommand object.

Step 6: execute() also calls for the setStatus() method in PatrolResourceStatus class sets the isEngaged boolean of "po1", in this case, to false.

Step 7: A CommandResult object with the successful message is created to be displayed to the user.

Current Implementation

This command lists out all the POs and their current engagement statuses. The POs and their details are stored in an Arraylist as the assumption here is the system will be running continuously for the whole working time, or shift, for example. It also implements the following methods:

The following is an example usage scenario of the "checkstatus" command:

Step 1: User inputs password and unlocks the system.

Step 2: User executes "checkstatus".

Step 3: Parser class identifies command as "checkstatus" and returns a new CheckPOStatusCommand object.

Step 4: Logic class calls the execute() method in the CheckPOStatusCommand object.

Step 5: execute() also calls for the extractEngagementInformation() method and stores the PO Ids and the engagement status in a list.

Step 6: A CommandResult object is created and displays the list to the user.

Current Implementation

This command displays the current time to both HQP & PO.

The following is an example usage scenario of the "time" command:

Step 1: User inputs password and unlocks the system.

Step 2: User types "time" and executes it.

Step 3: Parser class identifies command as "time" and returns a DateTimeCommand object.

Step 4: Logic class calls the execute() method in the DateTimeCommand object.

Step 5: execute() calls

Current Implementation

This command logs the current user out of the System.

The following is an example usage scenario of the "logout" command:

Step 1: User executes "logout".

Step 2: decipherUserCommandText() in MainWindow class identifies command as "logout".

Step 3: Boolean flags for isHQP, isPO1, isPO2, isPO3, isPO4, isPO5 in the Password class is set to false. This is done using the lockIsHqp() and lockIsPo() methods in the Password class.

Step 4: isUpdatePasswordConfirm and isUpdatingPassword flags are also set to false through lockUpdatePasswordConfirm() and lockUpdatingPassword() in the Password class is also set to false.

Step 5: resetInboxWhenLogout() in the Inbox class clears all records of displayed messages and resets the number of unread messages to default value of -1.

Step 6: A CommandResult object is created and displays a message that the user is logged out of the System and prompts for a password.

Current Implementation

The autocorrect mechanism is facilitated by use of dynamic programming. The algorithm called EditDistance checks the number of single character changes to be made to convert an invalid input into one expected by the system. Currently, changes involving one single character can be corrected by the system for commands and changes involving one or two single characters can be corrected by the system for NRICs. It implements the following operations:

Step 1: The user inputs his password and unlocks the system.

Step 2: The user enters an invalid command.

Step 3: The system predicts the most probable intended command the user would have wanted to input and then prompts the user to use the prediction given in its valid format.

Step 1: The user inputs his password and unlocks the system.

Step 2: The user tries to edit, delete or check an invalid NRIC.

Step 3: The system predicts the most probable intended NRIC the user would have wanted to input and then prompts the user to use the prediction given in the valid format of the command.

The input is checked by the algorithm in the MainWindow before it is sent to the Parser class. This is to ensure invalid input can be caught by the algorithm to give its correction before it is deemed as invalid by the Parser during which time all commands will be laid out to the user.

Current Implementation

This command shuts down the System.

The following is an example usage scenario of the "logout" command:

Step 1: User executes "shutdown".

Step 2: Boolean flags for isHQP, isPO1, isPO2, isPO3, isPO4, isPO5 in the Password class is set to false. This is done using the lockIsHqp() and lockIsPo() methods in the Password class.

Step 3: isUpdatePasswordConfirm and isUpdatingPassword flags are also set to false through lockUpdatePasswordConfirm() and lockUpdatingPassword() in the Password class is also set to false.

Step 4: mainApp.stop() in MainWindow class shuts down the system

Current Implementation

The help command returns the list of commands which can be input by the user based on their level of access. A HQP user is shown all the commands while a PO user is shown only limited commands.

It also implements these methods:

This is an example scenario of "help" command

Step 1: The user inputs PO password and logs in as PO.

Step 2: The user types "help" and executes it.

Step 3: Parser class determines the command word and return the list of commands that can be input by a PO.

Current Implementation

Only a HQP may use this command. This command allows HQP to update the Police Records with a new subject. The subject can be added with the details- name, NRIC, date of birth, postal code, status, offense and optional past offences.

It also implements these methods:

This is an example scenario of "add" command

Step 1: The user inputs HQP password and logs in as HQP.

Step 2: The user types "add John Doe n/s1234567a d/1996 p/510246 s/xc w/none o/theft o/drugs" and executes it.

Step 3: Parser class determines the command word and runs the prepareAdd method

Step 4: prepareAdd method in Parser class would parse the inputs from the input text to instantiate the AddCommand class.

Step 5: Logic class then calls the execute method on AddCommand Object. Person with NRIC "s1234567a" is added in the addressbook.

Step 6: CommandResult with successful message is returned to Logic class, which then displays to user: "New person added: John Doe Nric: s1234567a DateOfBirth: 1996 Postal Code: 510246 Status: xc Wanted For: [none] Past Offences:[drugs][theft]".

We are using java.util.logging package for logging. The Parser class is used to manage the logging levels and logging destinations.

Logging Levels

Certain properties of the application can be controlled (e.g App name, logging level) through the configuration file (default: config.json).

See UsingGradle.adoc to learn how to render .adoc files locally to preview the end result of your edits. Alternatively, you can download the AsciiDoc plugin for IntelliJ, which allows you to preview the changes you have made to your .adoc files in real-time.

See UsingTravis.adoc to learn how to deploy GitHub Pages using Travis.

We use Google Chrome for converting documentation to PDF format, as Chrome’s PDF engine preserves hyperlinks used in webpages.

Here are the steps to convert the project documentation files to PDF format.

The build.gradle file specifies some project-specific asciidoc attributes which affects how all documentation files within this project are rendered.

Each .adoc file may also specify some file-specific asciidoc attributes which affects how the file is rendered.

Asciidoctor’s built-in attributes may be specified and used as well.

The files in docs/stylesheets are the CSS stylesheets of the site. You can modify them to change some properties of the site’s design.

The files in docs/templates controls the rendering of .adoc files into HTML5. These template files are written in a mixture of Ruby and Slim.

MSS

Extensions

MSS

Extensions

MSS

Use case ends.

MSS

Extensions

MSS

Extensions

MSS

Extensions

MSS

Extensions

MSS

Extensions

MSS

Extensions

MSS

Extensions

MSS

Extensions

MSS

Extensions

MSS

Extensions

MSS

Extensions

MSS

Extensions

MSS

Extensions

MSS

Extensions

MSS

Extensions

MSS

Extensions

There are a total of 6 accounts (1 HQP and 5 POs) available in the sample data: