In this part of the project, you will extend the chat application further by adding some security, the capability to communicate privately with another user or a group of users as opposed to all the users, and message forwarding. You will also address the problem of "feature interaction"; the features you will add will interact with the blocking features you implemented in P4.
Important: You cannot change the OCSF framework code. You must use the version that was used to start phase 2 of P4. Severe point deductions will happen if you change the framework code.
In all the requirements below, appropriate status messages and error messages must be displayed on the appropriate console. All the features need to work correctly in the presence of the blocking feature implemented in P4.
Since there is no password, and user_ids are publicly known, the current version of the chat application has a problem. A user can impersonate another user. Prevent this from happening.
The current version allows a client's message to be sent to all other clients (except when blocked). Users should be able to chat privately with another user. Multiple private one-to-one communications should be allowed. You will need to define a command to send a private message from a user of one client to another user of a different chat client (e.g., #private user_id message).
Users should be able to chat in a channel with one or more users. Messages sent in a channel should only reach other members of the channel (unless blocked). A user can participate in multiple channels at any time. You will need to define useful commands to (1) create a channel (e.g., #channel <name>, (2) join a channel (e.g., #join <name>), and (3) leave a channel (e.g., #leave <name>).
A user may want someone else to monitor his/her messages while the user is busy/away. This requires forwarding messages originally sent to the user to the other person. Set up commands that allow forwarding (e.g., #startforwarding user_id) and cancel forwarding (e.g., #cancelforwarding user_id).
Users can be in one of four states:
Add commands to let the user change his/her status from available to unavailable and vice versa (e.g., #available and #unavailable). Note that the online, offline, and idle status options are decided by the system.
Add commands to let the user check on the status of another user (#status <user_id>) or all the users of a channel where this user is also a member (e.g., #status <channel>).
Here are some constraints.
Note that the availability feature is not affected by the blocking feature. However, think about how the availability feature interacts with the message forwarding (monitoring) feature. Discuss this interaction in your meetings and make your decisions with a suitable rationale. Must user A be available in order to enable user B to monitor A's messages? Once B starts monitoring A's messages, does A remain available or become unavailable/idle/offline? What you will do if A asks B to monitor messages, but B is blocked. Or, what happens if B is monitoring A's messages, but needs to block---what happens to A's messages from that point?
(20 points) Based on the requirements described in Section 2 above, write out the user stories in a document called US.pdf. For each user story, list the acceptance criteria and the story points (size estimation as S/M/L/XL) information. Finally, provide the definition of "done" (including your testing goals, coverage level of test cases, among other criteria) for this project.
(60 points) Implement your user stories.
(10 points) Describe 30 system test cases in a document called TP.pdf. Add information on code coverage obtained by running these test cases using EclEmma.
To get full points for this part, GitHub logs must show the following:
Team artifacts are to be submitted through Canvas, once for each team.
One and only one team member must do the submission. Please check to see
that the files have actually been submitted, not just uploaded.
Each file must be submitted separately. You must not include the pdf files inside your jar file.
Put your names and team number at the top of each page of the PDF files.
The code that you submit will be graded via a demo. You must schedule a demo based on time slots that will be provided by your GTAs. Not performing a demo will result in a loss of 60 points for the code portion of your project.