General description

Your textbook describes the Object Client-Server Framework (OCSF). Code and test cases are available at the textbook website: http://www.site.uottawa.ca/school/research/lloseng/supportMaterial/source/ .

First install the code corresponding to Phase 1 of the SimpleChat program and the OCSF framework from the website. Zip files for both the source and compiled class files are available along with the Javadoc documentation for all the source code.

In this part of the project, you will

1. test Phase 1
2. extend the code to implement and test Phase 2
3. extend the code to add a blocking feature to the chat application.

Steps

1. Testing Phase 1

On the book's website, you will find a set of test cases for Phase 1 of the SimpleChat program. Execute all the tests to understand and test the functionality of the system. Note that the page numbers may not match because of the difference in edition and the result of customizing the textbook for this class.

Write some additional test cases that execute the system. Use ideas from equivalence class analysis, boundary value testing, and code coverage to create test cases that aren't already included in the website. The test cases don't need to be written using JUnit. Just describe the test inputs, test outputs, and rationale for each test case. Feel free to use the format given in the book's test cases, noting that you need to add the rationale for each test case. Type your test cases in a document called TP1.pdf (only PDF documents will be accepted).

2. Implementing Phase 2 of SimpleChat

Without modifying the framework classes, do exercises E49, E50, and E51 given on pages 104-106 of the Lethbridge/Laganiere part of your textbook. Document your code with appropriate comments.

3. Testing Phase 2

On the book's website, you will find a set of test cases for Phase 2 of the SimpleChat program. Execute all the tests to understand and verify the functionality of the system. (Again, note that the page numbers may not match.)

Write some additional test cases that execute the system. Use ideas from equivalence class analysis, boundary value testing, and code coverage to create test cases that aren't already included in the website. The test cases don't need to be written using JUnit. Just describe the test inputs, test outputs, and rationale for each test case. Feel free to use the format given in the book's test cases, noting that you need to add the rationale for each test case. Type your test cases in a document called TP2.pdf (only PDF documents will be accepted).

4. Implement Phase 2x (i.e. extended Phase 2) of SimpleChat

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. Again, all code must be properly documented.

Issues considered: The following paragraphs discuss the issue before presenting the list of requirements for phase 2x.

Functional requirements: Based on the above discussion of issues, here are the functional requirements for phase 2x.

1. General (applies to client and server alike). Commands can be issued from the user interface of the client or the server. If issued from the client UI, they will be transmitted to the server unchanged.
   • #block <user>
     • Initiate blocking for any user named <user>, except self.
     • Works whether <user> is connected or not.
     • Displays a message on the originating UI that states:

       Messages from <user> will be blocked.
       

     • An attempt to block messages to self will cause the following message to be displayed:

       You cannot block the sending of messages to yourself.
       

     • An attempt to block messages from a user that does not exist will result in the following message being displayed:

       User <user> does not exist.
       

       Assume that the server has a list of valid user ids
       read from a file (e.g., usernames.txt) passed as a command line argument.
       The order of arguments is <filename> <port>, where <port> is optional.
     • Any number of these commands can be issued to a series of users.
     • Blocking an already blocked user is allowed. Display:

       Messages from <user> were already blocked.
       

     • server is a valid user argument for this command (i.e. if a user needs to block server messages).

   • #unblock {<user>}
     • If an argument is specified, terminates blocking for messages from <user> that had previously been established by the #block <user> command command.
     • When successful, displays the following on the originating UI:

       Messages from <user> will now be displayed.
       

     • If #unblock <user> is issued with no preceding #block <user> for the same user, then displays the following:

       Messages from <user> were not blocked.
       

     • When issued with no argument:
       1. Cancels any blocking in effect.
       2. If blocking had been active, displays the following messages for each previously blocked user:

          	Messages from <user> will now be displayed.
          	

       3. If no blocking had been in effect, display:

          	No blocking is in effect.
          	

     • server is a valid user argument for this command.

   • #whoiblock
     • For each user for which this user has issued a #block <user> command, displays the following message:

       Messages from <user> are blocked.
       

     • If no users are blocked, then displays:

       No blocking is in effect.
       

   • #whoblocksme
     • For each user that is blocking messages from this user, displays the message:

       Messages to <user> are being blocked.
       

2. Operation:
   • 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.

4. Testing Phase 2x

Write some test cases that execute the above features. Use ideas from equivalence class analysis, boundary value testing, and code coverage to create test cases that aren't already included in the website. The test cases don't need to be written using JUnit. Just describe the test inputs, test outputs, and rationale for each test case. Feel free to use the format given in the book's test cases, noting that you need to add the rationale for each test case. Type your test cases in a document called TP2x.pdf (only PDF documents will be accepted).

5. Peer review and self evaluation

Type this up based on the instructions given here describing the entire group project.

6. Using GitHub

GitHub repository set up for this course by Dr. Ghosh must be used, and a commit log submitted. Please refer to the general project description for more information.

What to turn in

There are two types of things to turn in --- team artifacts and individual artifacts.

Team artifacts

Team artifacts are to be submitted through RamCT, 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. (5 points) Test cases for phase 1: TP1.pdf. Submit this file through RamCT.
2. (15 points) Test cases for phase 2: TP2.pdf. Submit this file through RamCT.
3. (5 points) Test cases for phase 2x: TP2x.pdf. Submit this file through RamCT.
4. (60 points) Code that implements phases 2 and 2x: Create a jar file containing all the Java source files, keeping the directory structure as is. Submit the jar file through RamCT. Exercises E49, E50, and E51, and phase 2x are each worth 15 points.
5. (5 points) Commit log showing checkin-checkout activity for each team member. Submit this file through RamCT.

Individual artifacts

1. (5 points) Self evaluation
2. (5 points) Peer review