P4: Chat Application Part A
100 points
Due October 16, 2016

1. Overview

In this project you will develop new features as a team for an existing chat application. You will use Scrum, GitHub, and your knowledge of software testing. You will develop user stories, implement, and test the application. In this project, you will work on Phase 2 and Phase 2x of the application.

This document organized as follows. Section 2 describes the requirements. Section 3 describes the tasks. Section 4 summarizes the requirements for using GitHub. Submission instructions are provided in Section 5.


2. Requirements

Your team will develop user stories for the chat application based on what you read (1) in the description below, and (2) in the two websites provided by Lethbridge and Laganiere that describe system test cases for Phase 1 and Phase 2. You must read the provided test cases to fully understand the requirements described below.

2.1. Phase 2

In this phase you will make several enhancements to the client and server, such as (1) generate useful status messages on both sides, and (2) have both sides respond to various user commands, and (3) allow for user identification.

2.1.1. Useful Status Messages

  1. If a server shuts down, every connected client should first print a message saying the server shut down and then quit.

  2. If a client connects to or disconnects from a server, the server should print out a suitable notification.

2.1.2. Responding to User Inputs

  1. Currently anything that is typed on the client side is sent to the server, which echoes them back to all the clients. Now, clients need to recognize commands, and treat these user inputs differently than chat messages. Assume that every command is a word beginning with #, with zero or more command line arguments. In all of these cases, appropriate error messages should be printed when something goes wrong with a command.

    1. #quit: client closes connection to the server and terminates gracefully.
    2. #logoff: Client closes connection to the server but does not terminate.
    3. #sethost <host>: This is allowed only when the client is logged off. The server host is set for the client.
    4. #gethost: Displays the current host name.
    5. The client should optionally be able to take a port number from the Java command line arguments. If the argument is not provided, then the default port is used.
    6. #setport <port>: This is allowed only if the client is logged off. The server port is set for the client.
    7. #getport: Displays the current port number.
    8. #login: This is allowed only if the client is logged off. The client now connects to the server.
  2. Add a server console so that anything that is typed on this console (apart from commands starting with #) is echoed on the server console and to all the clients. When a message is displayed on client consoles, it should be prefixed by a suitable string to make it clear that it originated from the server and not a Chat Client.

  3. Implement server side commands for an administrator. Commands start with # and can take zero or more command line arguments.

    1. #quit: server terminates gracefully.
    2. #stop: server stops listening for new clients but existing clients are still serviced.
    3. #close: server disconnects from existing clients and stops listening for new clients.
    4. #setport <port>: This is allowed only if the server is closed.
    5. #getport: displays the current port number.
    6. #start: This is allowed only if the server is stopped. The server starts listening for new clients.

2.1.3. Identifying chat clients

The current implementation makes the server echo a message from one client to all the clients without showing any identifying information about which client sent the message. We will address this issue by using the user_id of the chat client user.

  1. Client side changes:

    The login is will be taken as a required Java command line argument. Since the host and port number are optional command line arguments, the login id will need to be the first argument from now on. Any time a client connects to the server (e.g., at the beginning, or as a result of the #login command earlier in Section 2.1.2, the client should sent a special message to the server "#login <user_id>". This is a special message that the client sends to the server. It's not like a command handled by the client. It is a message handled by the server.

  2. Server side changes:

    The server needs to recognize the special message from the client. This message is allowed by the server only if it is the first command received after the client connects. Otherwise an error message is sent back and the connection is terminated. The user_id is saved by the server for the connection with the client. Every subsequent chat message that the server receives from the client is prefixed with this user_id and then echoed back to the clients.

2.2. Blocking Feature (aka Phase 2x)

Now add a blocking feature to the chat application. Let's call this phase 2x (extension of phase 2). Sometimes a user wants to prevent messages received by a given client appearing on his or her screen. This might be because the client's user is being deliberately annoying, or because the client's user is sending lots of public messages that are useful to other users but are not useful to the current user.

There are four blocking related commands. Both servers and clients can issue them. If a user types a blocking command on the client side, it is transmitted to the server unchanged, and the server handles that message. If a server administrator types a blocking command, then it is handled on the server side itself. The following commands are available:

  1. #block <user_id>:

    This initiates blocking for the user named user_id, as long as you are not blocking yourself. Assume that there is a file that contains the valid user_ids, and the file name is the first required command line argument for the server side. This command works as long as the user_id exists, whether the user_id is connected to the server or not.

    The originating user interface where the command was typed (client or server side) gets an appropriate notification that the user_id is blocked. If you try to block yourself, an error notification message should be displayed. An attempt to block messages from a user that does not exist should result in an appropriate error message.

    You can block any number of users by issuing a series of commands. If you accidentally block an already blocked user, that is okay. The system should display an appropriate notification message. A chat client can block messages from a server too!

    If X blocks messages from Y, irrespective of whether X or Y is client or server, any simple message sent by Y will not reach X. Blocking persists no matter whether the blocked user logs off or on. However, if the originator of the blocking logs off, the blocking is terminated.

  2. #unblock [user_id]:

    The user_id is an optional argument. It can refer to the server or any client user. If no argument is provided, it cancels any blocking in effect. If no blocking was in effect previously, issue an appropriate notification message. If blocking was in effect for some user(s), then the console where this command is typed should get a series of notifications, one for each previously blocked user, that messages from that user will now be displayed.

    If an argument is provided, then blocking for that user is terminated. Display an appropriate message showing that messages from the user will now be displayed. However, if that user was not previously blocked, then notify the console that the user was not previously blocked.

  3. #whoiblock:

    This command lists all the users that is blocked by this user. If not one is blocked, then a message to that effect is displayed.

  4. #whoblocksme:

    This command lists all the other users that are blocking this user. If no one is blocking this user, then a message to that effect is displayed.


3. Tasks

  1. Make the following edits in your code from P2 to remove the issues that we had seeded prior to the code inspection exercise. We would like everyone to start from the correct version of the code. This code refers to phase 1 of the project in Lethbridge and Laganiere's textbook. Please remove the seeded errors as follows:

  2. Execute all the system test cases that are available for Phase 1 on the textbook website so that you understand how the application behaves. You can obtain the test cases here.

  3. (5 points) In a document named TP.pdf write 10 more system test cases using ideas from equivalence class analysis, boundary value testing, and code coverage to create test cases that are not already on the book website. Just describe the test inputs, test outputs, and rationale for each test case. Feel free to use the format used in the website.

  4. (10 points) Based on the requirements described in Section 2.1 above, write out the user stories in a document called US.pdf. Remember to refer to the test cases of phase 2 before you do this. 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.

  5. (40 points) Implement the features for your user stories for Section 2.1.

  6. Execute all the system test cases that are available for Phase 2 on the textbook website. You can obtain the test cases here.

  7. (5 points) Continuing in the previous TP.pdf document, add the description of 10 new system test cases to test your implementation of Section 2.1.

  8. (5 points) Continuing in the previous US.pdf document, add user stories corresponding to the requirements described in Section 2.2. 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.

  9. (15 points) Implement the features for your user stories for Section 2.2.

  10. (5 points) Continuing in the previous TP.pdf document, add the description of 10 new system test cases to test your implementation of Section 2.2.

  11. (5 points) Continuing in the previous TP.pdf document, add a coverage report obtained by running all your system 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.

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