General description

In this part of the project you will develop requirements, implement, and test phase three of the SimpleChat application. Refer to Chapter 10--Developing Requirements of the custom text, starting on page 334, (originally Chapter 4--Developing Requirements in the Lethbridge/Laganiere textbook, starting on page 109).

READ THE ENTIRE DESCRIPTION ON THIS WEBPAGE BEFORE YOU START WORKING ON THE FIRST STEP. Subsequent steps may affect how you think about the earlier steps. 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 385 of custom text or page 160 of Lethbridge/Laganiere). Draw a use case diagram (e.g., see page 358 of custom text) and describe them in the format shown on pages 358--360 of the custom text. For drawing use case diagrams, feel free to use any tool.

2. Implement the features

Do exercise E80. Note that this exercise is about the chat application. Do not work on the Small Hotel Reservation System.

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:

• #status <user>: Displays the status of the user as follows:

      User <user> is <status>.
  

  where status is one of online, idle, unavailable, or offline. If a user has not been active and is also unavailable, the status is shown as unavailable.
• #status <channel>: Displays the status of all the users in the private channel as follows:

      User <user1> is <status>.
      User <user2> is <status>.
      ...
  

  If the channel doesn't exist, then display

      Channel <channel> does not exist.
  

  This command can be only issued by someone who is a member of the channel. Otherwise, display a message:

      You are not authorized to get information about channel <channel>.
  

A user can change his/her status as follows:

• Change to unavailable by typing:

      #notavailable
  

  If the user was already unavailable, this has no effect (or error message).
• Change to available by typing:

      #available
  

  If the user was already available, this has no effect (or error message).

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

• If the user indicated s/he is available, and has sent messages within the last 5 minutes to the server, then the system knows that this user is online.
• If the user indicated s/he is available, but hasn't sent messages within the last 5 minutes to the server, then the system knows that this user is idle.
• If the user indicated s/he is unavailable, then the system knows that this user is unavailable.
• If the user is not logged in, the system knows that this user is offline.

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.

• Once a user is offline, they cannot receive any messages (public, private, channel, or server).
• An unavailable user can receive server messages, but not from other clients (public, private or channel).
• Unavailable users cannot be sent private messages. If an attempt is made (based on how you did E79.b), an appropriate error message should be issued to the user trying to send the message.
• Unavailable users cannot be added to channels. If an attempt is made (based on how you did E79.c, an appropriate error message should be issued to the user trying to add to the channel.
• Think about how the availability feature will interact with the monitoring feature discussed in the book in E79.d. 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?

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

Individual artifacts

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