PROJECT: Police Records Intelligent System (PRISM)

Introduction

This portfolio was written to showcase my abilities to contribute to the project from a technical perspective such as features & code, notwithstanding communication abilities that include documentation of the code. The project is centered on building a "Police Records Intelligent System" (PRISM) that was done in CS2113T (Software Engineering & Object Oriented Programming) at the National University of Singapore in Semester 1 of the 2018/2019 Academic year. It was a team based effort that included (me) Matthew Alexander, Putra Danish, Muhammad Harun, Ong Wee Keong & Shreyas.

Overview

The Addressbook is morphed to a police records system called PRISM with two types of users, Police Officers (PO) & Headquarter Personnel (HQP). Users have their own access levels with HQP having higher authorization compared to PO. Police officers can screen civilians during duty with their respective NRIC, their criminal history and status would be shown to the police officers. POs can also request for backup when needed, HQP would dispatch other POs at their discretion based on estimated time of arrival. Refer to Quick Start guide to get started.

Summary

  • Role: Developer

  • Responsibility: Integration

  • Major enhancements:

    • Edit Command

      • What it does: Allows HQP to update selected parameters such as a civilian’s postal code, offense list, wanted for and wanted status.

      • Justification: : Individual data in Police Records System would need to be updated as people change addresses, commit crimes, serve their sentence.

      • Highlights: Due to each NRIC being assigned to a specific individual for their whole lives, they cannot be changed.

    • Request Command

      • What it does: Allows PO to request backup to HQP’s inbox. HQP would then be able to view request messages with the PO’s id, case, urgency and his/her location.

      • Justification: POs may not be able to handle a case alone especially when it involves multiple criminals or dangerous scenarios. He/she would then need backup to take handle the scenario.

      •  Highlights: HQP can view the requests with most urgent based on case.

    • Dispatch Command

      • What it does: Allows HQP to dispatch backup according to the dispatchers’ requests. HQP can dispatch other ‘free’ POs to help the POs who requested for backup. PO who requested backup is then given a return message with ETA & Google Maps URL to pinpoint the location of the backup personnel. For PO who is being dispatched, he also given an ETA & Google Maps URL to pinpoint the requester.

      • Justification: After POs request backup, HQP should be able to dispatch backup to help them in their case. Hence, location of the requester and backup officer along with ETA are crucial. Location is important, so backup officer knows where to travel to & ETA is crucial so that the requester knows how much time he/she needs to hold off the suspects on his own before backup arrives.

      • Highlights: ETA is real time with Google Maps Distance API. Location is displayed in a Google Maps URL to allow PO to navigate.

  • Minor enhancements:

    • Able to delete a person from a record without listing beforehand

  • Code contributed: Functional code & Test code

  • Other contributions:

    • Project management:

      • Guided team for proper coding standards and practices.

      • Created sequence diagrams for the product’s features.

      • Refactored teammates code that did not follow OOP style.

    • Community:

    • Tools:

      • Integrated a third-party REST API (Google Maps API) to the project.

      • Integrated a third-party library (HttpClient Apache) to the project as a Http Client to communicate with Google Maps REST API.

      • Integrated a third-party library (Commons IO) to convert buffer data into String.

      • Integrated a third-party library (JSON Org) to parse Google Maps API data.

Contributions to the User Guide

Given below are sections I contributed to the User Guide. They showcase my ability to write documentation targeting end-users.

Editing a person : edit (HQP only)

Edit specified parameter(s) of an existing person in the Police Records - only by HQP.

Format: 'edit n/NRIC p/[POSTAL_CODE] s/[STATUS] w/[WANTED_FOR] o/[PAST_OFFENCES]'

  • The NRIC tag 'n/' is required

  • The other tags are optional, but at least one of them must be filled

  • Edits the person with the specified NRIC.

  • At least one of the optional fields must be provided.

  • Existing values will be updated to the input values.

  • Offenses can only be added not replaced.

Examples:

  • edit n/g1952866q p/510246

  • Edits the postal code of the person with the specified NRIC to be 510246

Requesting for assistance : rb (HQP & PO)

Generates GPS coordinates of current location with current case and sends it to HQP. HQP would receive message in inbox.

Format: 'rb OFFENSE'

Examples:

  • rb gun

  • Sends a set of GPS coordinates, Current Case and Google Maps URL location to HQP.

Dispatch assistance for requester: dispatch (HQP only)

Generates message to dispatch an officer to backup a requesting officer Message would be sent to requester & backup officer which includes ETA(Real Time) & Location (Google Maps URL).

Format: 'dispatch BACKUP_OFFICER OFFENSE REQUESTER_OFFICER'

  • dispatch po1 gun po3

  • Sends a set of GPS coordinates, current case, ETA and Google Maps URL location of requester to backup officer and vice-versa.

Contributions to the Developer Guide

Given below are sections I contributed to the Developer Guide. They showcase my ability to write technical documentation and the technical depth of my contributions to the project.

2c. "edit" command

EditCommand

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:

  1. execute() - executes the "edit" command itself and displays result to user

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".

Design Considerations

Aspect: How edit command is implemented

  • Alternative 1 (current choice): Can set attributes for read-only person

    • Pros: Editable persons

    • Cons: Should ot edit read only person

  • Alternative 2: Maintain person as read-only

    • Pros: Attributes are protected

    • Cons: Cannot edit persons easily

Use case: Edit person

MSS

  1. User opens System.

  2. System prompts user to enter his password.

  3. User enters password.

  4. System prompts user to enter his command.

  5. User keys in edit command with NRIC and new details of person to change

  6. System edits the person’s respective details.

    Use case ends.

Extensions

  • 3a. User enters an invalid password.

    • 3a1. System shows an error message.

      Use case resumes at step 2.

  • 4a. User enters invalid NRIC format

    • 4a1. System shows an error message stating that NRIC has a certain alphanumeric format.

      Use case resumes at step 4.

  • 4b. User enters NRIC of a person that does not exist in the police records

    • 4b1. System shows an error message stating that person could not be found.

      Use case resumes at step 4.

  • 4c. User enters edit command with only NRIC tag without other details to change.

    • 4c1. System shows an error message stating that format is invalid

      Use case resumes at step 4.

  • 4d. User enters edit command with proper NRIC format and Postal Code that is not 6 digits long.

    • 4d1. System shows an error message stating that Postal Code must be 6 digits long.

      Use case resumes at step 4.

  • 4e. User enters edit command with proper NRIC and wanted status that is invalid.

    • 4e1. System shows an error message stating that wanted status should be only of 3 types.

      Use case resumes at step 4.

  • 4f. User enters edit command with proper NRIC and invalid offense.

    • 4f1. System shows an error message stating offense is not in the list.

    • 4f2. System shows list of valid offenses

      Use case resumes at step 4.

  • 8a. User enters person’s details with invalid format.

    • 8a1. System shows an error message suggesting the correct usage of the command.

      Use case resumes at step 4.

3e. "rb" command

RequestCommand

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:

  • Priority of offense

  • Patrol resource ID of requester

  • Patrol resource respective Google Maps URL Location.

  • Current case patrol resource needs help with

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:

  1. execute() - executes the "RequestHelpCommand" command and displays result to user.

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."

Design Considerations

Aspect: How rb command is implemented

  • Alternative 1 (current choice): Writes using ReaderAndWriter class

    • Pros: Data is maintained across multiple sessions

    • Cons: External text files can be tempered

  • Alternative 2: Using chat client API

    • Pros: Safe and reliable real time support

    • Cons: Data is not maintained across multiple sessions === Use Case: Request Backup

MSS

  1. User opens System.

  2. System prompts User to enter his password.

  3. User enters his password.

  4. System prompts User to key in command.

  5. User types in to request backup with pre-defined case types.

  6. System adds message into Headquarters inbox.

  7. User will be notified with success message.

    Use case ends.

Extensions

  • 3a. User enters an invalid password.

    • 3a1. System shows an error message.

      Use case resumes in step 2.

  • 5a. User enters an invalid input with invalid command format.

    • 5a1. System shows error message and prompts correct format for request feature.

      Use case resumes from step 4.

  • 5b. User enters an invalid case type.

    • 5b1. System shows an error message and prompts user with list of offences.

      Use case resumes at step 4.

3f. "dispatch" command

DispatchCommand

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:

  1. execute() - executes "dispatch" command and displays result to user

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."

Design Considerations

Aspect: How dispatch command is implemented

  • Alternatives: Similar considerations as rb command.

Use Case: Dispatch Backup

MSS

  1. User opens System.

  2. System prompts User to enter his password.

  3. User enters his password.

  4. System prompts User to key in command.

  5. User keys in backup officer to assist requester with case type.

  6. System adds new message with ETA & location of backup officer and case type in requester inbox.

  7. System adds new message with ETA & location of requester and case type in backup officer inbox.

    Use case ends.

Extensions

  • 0a. User keys in invalid command format.

    • 0a1. System shows error message and prompts correct format for dispatch feature.

      Use case resumes from step 4.

  • 3a. The entered password is invalid.

    • 3a1. System shows an error message.

      Use case resumes in step 2.

  • 5a. User is not a Headquarter Personnel.

    • 5a1. System shows an error message stating invalid credentials.

      Use case resumes in step 4.

  • 5b. User enters an engaged police officer as backup.

    • 5b1. System shows an error message stating that the police officer entered is engaged.

      Use case resumes in step 4.

  • 5c. User enters an invalid case type.

    • 5c1. System shows an error message and prompts user with list of offences.

      Use case resumes at step 4.

  • 5d. User enters same officer for backup & requester.

    • 5d1. System shows an error message stating that backup & requester is same officer.

      Use Case resumes at step 4.

Appendix A: Non Functional Requirements

  1. Should work on any mainstream OS as long as it has Java 9 or higher installed.

  2. Should be able to hold up to 1000 persons.

  3. Should come with automated unit tests and open source code.

  4. Should favor DOS style commands over Unix-style commands.

  5. Business/domain rules:

    1. Device should accept any more input after 9 characters when PO is inputting NRIC

    2. Device will constantly remind PO to charge if battery level goes below a certain level.

  6. Accessibility: Different levels of access for POs and HQPs and drivers (ambulance,fire truck).

  7. Performance requirements: The system should respond within two seconds.

  8. Security requirements: The system should be password locked.

  9. Data requirements:

    1. Data should persist, and not volatile.

    2. Data should be recoverable from last save point

Appendix B: Glossary

Headquarters Personnel (HQP)

A PO with a high level of authorised access (read and write) to the information of subjects.

ID

Refers to the identity of the user of the program based on the password he uses the log in. Currently, there can be 6 possible users - 1 HQP and 5 POs.

Mainstream OS

Windows, Linux, Unix, OS-X

NRIC

Stands for National Registration Identity Card. It is a 7-digit number preceded and succeeded by a letter. This forms a sequence of characters unique to each person and is used for identification purposes.

Police Officer (PO)

A police officer that is on patrol duty. Has low level of authorised access (read only) to subject’s information.

Police Records

Refers to the database of information that the system has of people, which includes their NRIC, name, address, past offences and status.

Status

A status that is used to describe the engagement level of POs on duty. He can either be engaged (true) or free (false). It is also used to describe a subject, should he have a criminal record: wanted, xc (ex-convict), and clear.

Subject

A person that is being screened by a PO.

System

Refers to the PRISM Application itself (i.e. when a user exits the system, he closes the application).

Appendix C: Instructions for Manual Testing

Given below are instructions to test the app manually.

These instructions only provide a starting point for testers to work on; testers are expected to do more exploratory testing.
If you want to work with pre-populated data, do not tamper with any of the text files. Should they be tampered accidentally, delete the text file that was tampered and relaunch the jar file to regenerate the text file.

Launch

  1. Initial launch

    1. Download the jar file and copy into an empty folder

    2. Double-click the jar file
      Expected: Shows the GUI with a set of sample persons. The window size may not be optimum. Input "list" command after logging to check if the data is loaded successfully

    3. Resize the window if needed

Accounts for both HQP and POs

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

User Password

HQP

papa123

PO1

popo1

PO2

popo2

PO3

popo3

PO4

popo4

PO5

popo5

Saving Data

  1. Dealing with missing/corrupted data files

    1. As mentioned earlier, if the jar file is run with any of the data files missing, the jar file will auto-generate the required data files with pre-populated data for the purpose of testing.

Update password

  1. Updates password of a user

    1. Prerequisites: Logged in as HQP

    2. Test case:

      1. Enter existing password to be updated, for e.g: 'popo1'

      2. Enter new alphanumeric password (at least 5 characters long) for example 'police1'

      3. Enter same password again, i.e 'police1'

      4. Expected: Success message shown

Viewing Help

  1. Displays a list of commands available for the current user

    1. Prerequisites: Logged in as HQP or PO

    2. Test case: 'help'
      Expected: Shows list of available commands

Check time

  1. Shows the current time

    1. Prerequisites: Logged in as HQP or PO

    2. Test case: 'time'
      Expected: Shows current time

Reading notifications from inbox (showunread & inbox)

  1. Prerequisites: Logged in as either HQP or PO.

  2. Dealing with missing data files

    1. If data files are missing while the application is running, the application will generate the required data files. However if for some reason that doesn’t happen, the command would throw an exception, indicating to the user that data file for user’s inbox cannot be found.

  3. Reading an inbox with no messages

    1. showunread A feedback will be displayed to the user indicating that there are no unread messages.

    2. inbox A feedback will be displayed to the user indicating the total number of messages in the inbox, and 0 unread messages.

Marking notifications as read

  1. Prerequisites: Logged in as either HQP or PO. Inbox must have been opened (use of inbox or showunread command) as well.

  2. Dealing with an unopened inbox

    1. If you have not used showunread or inbox command, a feedback will be displayed ot user indicating that inbox is not opened yet.

  3. Dealing with an unopened inbox after logging out and logging in again

    1. If you open your inbox and log out (logout) without exiting the application, you will still need to re-open your inbox before using read command. Otherwise, the system will display a feedback that you have not opened your inbox.

  4. Dealing with no (unread) messages in inbox

    1. A feedback will be displayed to you indicating that there are no unread messages.

  5. Dealing with invalid indices

    1. If you enter a negative number, or a number larger than the number of unread messages, a feedback will be displayed indicating what the valid range of indices are.

    2. If you enter a nonsense value such as a character or symbol, a feedback will be displayed indicating that you have entered the command with an invalid format.

    3. If you enter a positive number for the index that is bigger than the threshold set, a feedback will be displayed indicating that the index entered was too large.

Clearing your inbox

  1. Dealing with missing data files

    1. If data files are missing while the application is running, the application will generate the required data files. However if for some reason that doesn’t happen, the command would throw an exception, indicating to the user that data file for user’s inbox cannot be found.

Request backup for specific case

  1. Sends a message to HQP inbox with case, patrol resource ID & location in Google Maps URL

    1. Prerequisites: Logged in as HQP or PO

    2. Test case: 'rb gun'
      Expected: Success message will be displayed to the user stating request sent

    3. Test case: 'rb bob'
      Expected: Invalid offense message error shwon, valid offenses will be presented in a list

Dispatch police officer for specific case to requester

  1. Sends a message to backup officer & requester with Case, Location & Estimated Time of Arrival

    1. Prerequisites: Logged in as HQP only

    2. Test case: 'dispatch po1 riot po3'
      Expected: Success message will be displayed to the user stating backup successful

    3. Test case: 'dispatch po1 bob po3'
      Expected: Invalid offense message error shown

    4. Test case: 'dispatch po1 gun po3' (po1 engaged already) Expected: Error message shown

    5. Test case: 'dispatch po1 gun po1'
      Expected: Error message shown

    6. Test case: 'dispatch bobo gun po1'
      Expected: Error message shown

Adding a person

  1. Adds a person to the Police records

    1. Prerequisites: Logged in as HQP

    2. Test case: 'add John Doe n/s1234567a d/1996 p/510246 s/wanted w/none o/theft o/drugs
      Expected: If wanted, wantedFor parameter cannot be none, error message shown

    3. Test case: 'add John Doe n/s1234567a d/1996 p/510246 s/xc w/none o/theft o/drugs'
      Expected: If person is not found, success message will be shown, else, a duplicate person error message will be shown instead

    4. Test case: 'add John Doe s1234567a d/1996 p/510246 s/xc w/none o/theft o/drugs' (or any other missing prefixes)
      Expected: Invalid command format, error message is shown

    5. Test case: 'add John Doe n/s123a d/1996 p/510246 s/xc w/none o/theft o/drugs (or any other invalid data) Expected: Error message for invalid data format will be shown

List all persons

  1. Displays a list of all persons

    1. PrerequisitesL Logged in as HQP or PO

    2. Test case: 'list'
      Expected: List of persons, if any, is shown

Finding a person in the Police Records

  1. Finds a person using the NRIC parameter to see his/her details

    1. Prerequisites: Logged in as HQP or PO

    2. Test case: 'find s1234567a' (Assuming person with this NRIC exists)
      Expected: Person’s details will be displayed

    3. Test case: 'find s1234567a' (If person does not exist in the Police Records)
      Expected: Error message stating person not found will be shown

    4. Test case: 'find ' or 'find 11111'
      Expected: Invalid command format, error message will be shown

Checking a person’s screening history

  1. Check a person’s screening history in the form of timestamps

    1. Prerequisites: Logged in as HQP

    2. Test case: 'check s1234567a' (Assuming person with this NRIC exists)
      Expected: A list of timestamps and the number of times person was screened will be displayed

    3. Test case: 'check s1234567a' (If person does not exist in the Police Records)
      Expected: Error message stating person not found will be shown

    4. Test case: 'check ' or 'check 11111'
      Expected: Invalid command format, error message will be shown

Update a PO’s engagement status to free

  1. Sets the PO’s isEngaged boolean value to false (so PO is free for dispatch)

    1. Prerequisites: Logged in as HQP

    2. Test case: 'updatestatus po1' (Assuming PO with such ID exists)
      Expected: A success message will be shown

    3. Test case: 'updatestatus po20'
      Expected: No such PO exists, an error message will be shown

    4. Test case: 'updatestatus ' or 'updatestatus asdf'
      Expected: Invalid command format, error message will be shown

Check engagement status of all POs

  1. Displays all the engagement status of all POs in a list

    1. Prerequisites: Logged in as HQP or PO

    2. Test case: 'checkstatus'
      Expected: List of POs and their engagement statuses

Edit a person’s details

  1. Edits the details, only selected parameters, of a person. At least one optional parameter has to be filled

    1. Prerequisites: Logged in as HQP

    2. Test case: 'edit n/s1234567a p/111111 s/xc w/none o/theft
      Expected: If person exists, success message is shown, else, error message is shown

    3. Test case: 'edit n/s1234567a 111111' (or any missing prefix or parameters)
      Expected: Invalid command format, person’s details are not edited, error message shown

Delete a person

  1. Deletes a person from the Police Records

    1. Prerequisites: Logged in as HQP

    2. Test case: 'Delete s1234567a' (Assuming person with this NRIC exists)
      Expected: Success message will be shown

    3. Test case: 'Delete s1234567a' (If person does not exist)
      Expected: Person does not exist, error message is shown

    4. Test case: 'Delete ' or 'Delete 1111'
      Expected: Invalid command format, error message shown

Clear

  1. Clears the entire Police Records

    1. Prerequisites: Logged in as HQP

    2. Test case: 'clear'
      Expected: Success message is shown === Logout

  2. Logout from system so that another password can be entered

    1. Prerequisite: Logged in as HQP or PO

    2. Test case: 'logout'
      Expected: Startup screen is shown

Autocorrect

  1. Autocorrects an input if the input has a similar spelling to other commands

    1. Prerequisites: Logged in as HQP or PO

    2. Test case: 'lost'
      Expected: Message stating if you meant 'list'

    3. Test case: 'exit'
      Expected: Message stating if you meant 'edit'

Shutdown

  1. Shuts down the system

    1. Prerequisites: Logged in as HQP or PO or not at all

    2. Test case: 'shutdown'
      Expected: System closes