PRS is a product that was morphed from the original Addressbook Level 3, published by a Github organization called Software Engineering Education (https://github.com/se-edu/addressbook-level3). PRS is an application that is designed to aid Police Officers in their patrolling duties to make screening subjects more efficient and well documented. It also serves as a system for communication between Police Officers (POs) on patrol and the Headquarters Personnel (HQP) in cases where additional manpower resources are required for backup. PRS is currently a desktop application, designed specifically for users who are comfortable with using Command-Line Interface (CLI).

Over the course of the project, my team and I have implemented 5 major features:

The police database is for police officers (PO) and headquarter personnel(HQP). Both groups will have varying access and authorization levels to this database. POs would be able to read from the database after screening someone while on patrol and choose his course of action base on the status/threat level of subject. HQP would have the added functions of adding and removing people from the database. Refer to quick start to get started

For HQPs: Check inbox to see a list of backup requests made by POs, and are sorted based on severity first, and then time stamp. For POs: Check inbox to see who is responding to request for backup/ambulance/fire truck or to see if there are any dispatch orders

Format: 'showunread'

Examples (as a HQP):

Examples (as a PO): * 'showunread' * Shows any backup messages by HQ or response for backup if any

For HQPs: Check inbox to see a list of backup requests made by POs, and are sorted based on severity first, and then time stamp. For POs: Check inbox to see who is responding to request for backup/ambulance/fire truck or to see if there are any dispatch orders

Format: 'inbox'

Examples (as a HQP):

Examples (as a PO): * 'inbox' * Shows any dispatch messages by HQ or response for backup if any

Updates the status of unread messages to read. Command to be used after showunread or inbox command

Format: 'read INDEX'

Examples: * read 1

Clears the text file containing all the messages (both read and unread) for the user.

Format: 'clearinbox'

The purpose of this Developer Guide is to provide useful information to software developers who desire to contribute to the project (e.g. optimizing of code, adding test cases, etc.), including an overview of the software architecture, design as well as current implementations and intended functionality of current features. The police database is for police officers(PO) and headquarters personnel(HQP). Both groups will have varying access and authorization levels to this database. POs would be able to read from the database after screening someone while on patrol and choose his course of action base on the status/threat level of subject. HQP would have the added functions of adding and removing people from the database. Refer to quick start to get started.

To set up the project successfully on your computer, follow the steps below.

The diagram below shows a high level architecture design of the current classes that are used in the project.

This section describes some of the more important details of certain features implemented.

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.

MSS

Extensions

MSS

Extensions

MSS

Extensions

MSS

Extensions