CS314 Fall 2014
Group Project Part 2
Assigned: Oct 14, 2014
Team artifacts Due: 11:59 pm, Oct 27, 2014 in RamCT
Individual artifacts due in class Oct 28, 2014
100 points


General description

In this part of the project you will develop requirements, implement, and test phase three of the SimpleChat application. Refer to chapter 4 of the Lethbridge/Laganiere part of your textbook. READ THE ENTIRE ASSIGNMENT BEFORE YOU START DOING PARTS OF IT. Subsequent parts may affect how you think about the earlier parts. It's good to have a global picture.

You will now have to think about various issues and make decisions about the requirements. You will encounter cases where there will be feature interactions. As always, there will be multiple ways of implementing the same requirements, and you will need to make design decisions by analyzing the pros and cons of using a particular approach.


Steps

1. Develop requirements and use cases

Do exercise E79. Create a PDF document P2R.pdf containing both figures and text. You must list the requirements in a format shown in the textbook (e.g., see page 160). Draw a use case diagram (e.g., see page 133) and describe them in the format shown on pages 133-135. For drawing use case diagrams, feel free to use any tool.

2. Implement the features

Do exercise E80. Also, implement the requirements related to blocking users described in section 4.12 of chapter 4 (pp 160--164). You will recall that you had implemented some of these in Part P1 of the project. At that time, the chat application only supported public messages. This time you also have private and channel messages.

Now add an availability feature to the application. A user can have four states:

  1. Online (the user is logged in, is active, and willing to chat).
  2. Idle (the user is logged in but 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).

A user can see the status of other users as follows:

A user can change his/her status as follows:

Note that the online, offline, and idle status options are decided by the system.

Here is a list of issues. Some decisions have been made for you, others haven't. If you can think of other issues that are not mentioned, feel free to make and state your own decisions.

Create a jar file (P2.jar) containing all the Java source files without changing the directory structure. Note that you cannot change the OCSF framework code.

3. Test phase 3

Write test cases for E80, and the blocking and availability features. Type your test cases in a document called P2T.pdf (only PDF documents will be accepted). Use the same format as you did in the first part of the project (P1).

4. Peer review and self evaluation

Type this up based on the instructions given here describing the entire group project. Put your name and group name at the top of the document.

5. 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. (15 points) Requirements and use cases for phase 3: P2R.pdf
  2. (50 points) Code for phase 3, and the blocking and availability features: P2.jar
  3. (20 points) Test cases for phase 3, and the blocking and availability features: P2T.pdf
  4. (5 points) Commit log showing checkin-checkout activity for each team member. Submit this file through RamCT.

Individual artifacts

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