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.
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.
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:
A user can see the status of other users 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.
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:
#notavailableIf the user was already unavailable, this has no effect (or error message).
#availableIf 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.
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.
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).
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.
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.
There are two types of things to turn in --- team artifacts and individual 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.