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.
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.
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:
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 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.