CS314 Fall 2015
Group Project Part 1
Assigned: Oct 1, 2015
Team artifacts due: 11:59 pm, Thurs, Oct 15, 2015 (Canvas)
Individual artifacts due: 9:00 am, beginning of class, Fri, Oct 16, 2015 (in class)
100 points


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/ . The installation procedure in Eclipse was described in class using the slide set 08OCSF.pdf available from Canvas modules.

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.

Issue 1: Can the user block more than one other user at a time?
Decision: Yes; however, he or she will have to issue a sequence of block commands, one for each user to block.
   
Issue 2: The user needs some way of finding out if he or she has any blocking in progress, otherwise the user might forget that he or she had earlier established blocking.
Decision: Add a command called #whoiblock that will list those clients I am blocking.
   
Issue 3: It would be useful for a user to know if anyone is blocking messages that come from him or her.
Decision: Add a command called #whoblocksme that will do this.
   
Issue 4: Should the server be able to block messages.
Option 4.1: Do not allow the server to block messages.
Advantage: This would be simpler.
Option 4.2: The server should be able to block ordinary messages from clients, but not administrative messages (ones starting with #, etc).
Advantage: This would prevent a malicious user from overwhelming the server's display.
Decision: Choose option 4.2.
   
Issue 5: Does it make sense to block messages from myself?
Decision: No.
   
Issue 6: Can a user block messages from the server?
Decision: Yes.
   
Issue 7: How does a user unblock messages?
Decision: The #unblock command with no arguments will cancel all blocking that a user has set up. The #unblock command with an argument will cancel blocking for messages from that user only.
   
Issue 8: Any user could circumvent blocking by logging in using a different login id.
Option 8.1: Stop allowing users to create their own login IDs.
Advantages: Would solve this problem.
Disadvantages: Would make this system less useful in a chat environment.
Option 8.2: Status quo. Live with this problem
Decision: Choose option 8.2.
   
Issue 9: Should it be possible to block users who are not even logged on; and should a block persist even if the blocked user logs off and logs on again?
Decision: Yes to both questions, because otherwise a user could circumvent the blocking by logging off and on.
   
Issue 10: Should a block persist even if the blocking user logs off and logs on again?
Decision: No. For simplicity, we require a user to re-establish any blocks that he or she desires.
   

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 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. (5 points) Test cases for phase 1: TP1.pdf. Submit this file through Canvas.
  2. (15 points) Test cases for phase 2: TP2.pdf. Submit this file through Canvas.
  3. (5 points) Test cases for phase 2x: TP2x.pdf. Submit this file through Canvas.
  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 Canvas. 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 Canvas.

Individual artifacts

Individual artifacts are to be printed and submitted at the beginning of class. Emailed self evaluations and reviews will NOT be accepted.
  1. (5 points) Self evaluation
  2. (5 points) Peer review