P5: Chat Application Part B
100 points
Due November 2, 2016

1. Overview

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.


2. Requirements

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.

  1. Problem with impersonation:

    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.

  2. Private communication:

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

  3. Channel communication:

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

  4. Message forwarding:

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

  5. Availability feature:

    Users can be in one of four states:

    1. Online (the user is logged in, is active, and willing to chat).
    2. Idle (the user is logged in but has not sent any message--chat or command-- in the last five minutes, but is willing to chat).
    3. Unavailable (the user is logged in, is either active or idle, but not willing to chat)
    4. Offline (the user is not logged in).

    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?


3. Tasks

  1. (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.

  2. (60 points) Implement your user stories.

  3. (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.


4. Appropriate Use Of GitHub (10 points)

To get full points for this part, GitHub logs must show the following:

  1. (4 points) No work occurred directly on the master branch and no merge was done to the master branch without using the pull review system first.
  2. (2 points) The pull review system shows the student has requested reviews of their proposed changes to the master.
  3. (2 points) The pull review system shows the student has reviewed their teammates' proposed changes to the master.
  4. (2 points) At least 1 branch with a descriptive name of the changes exits for each student, and the student has made multiple commits on these branches using descriptive commit messages.


5. Submission

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.

  1. US.pdf: User stories. Submit this file through Canvas.
  2. P5.jar: Code that implements P5: Create a jar file named P5.jar containing all the Java source files, keeping the directory structure as is. Submit the jar file through Canvas.
  3. TP.pdf: Test cases and coverage. Submit this file through Canvas.

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.