Introduction
In this project, you are to design and implement an Instant Messaging App (IM App) using the Model View Controller architecture design with delegates. The IM App consists of a front-end (Client) and a back-end (Server) component.
The IM App builds on the WebSocket Chat Client/Server Apps exercises that we did in class on with some additional functionality as listed bellow:
- Users can log in/out from the Server; logging in requires a name and password, which are managed in the Server and must be persisted across running sessions by serializing the account objects as a JSON string stored in a file.
- Once logged in, users can manage their contact list by adding and removing contact entries.
- At the client side, the contact list shows each contact’s status (online/offline). This status is dynamically updated as the users in the list log in/out from the server.
- A user X, while online, can establish a 2-way chat session with another user (with online status) in X’s contact list. Conversations are not recorded/saved in the Server.
- While user X is chatting with user Y, any of them can add a third user Z (also online) to have a group chat.
- Similar to the class exercise, the Client and Server Apps communicate via a WebSocket connection. Moreover, each chat message should be time-stamped and the client GUI should indicate who sends the message in the chat window.
Use Cases
As you might have experienced when using some IM app, there are many IM features that can be provided. Bellow are the minimal use cases that your solution must provide.
Log in/Sign in. A user A launches the Client app (C) and enters a name (n) and password (p) to log into the Server (S). Server S can respond to C in two ways:
Login is successful – if p matches what is in n’s account record, or if n is a new name, in this case, S creates a new account with name n and password p.
Login is unsuccessful – if p does not match the information in n’s account records.
Server-Client Synch. After a successful login, Server S communicates A’s contact list to client C (empty if n is a new name), and let other online users, that have A in their contact lost, know that A is now online, (the other user’s contact list displays A as online). A can use client C to do any of the following:
Add a new contact. A enters contact name (e.g. b). If an account exists in server S with name b, server S adds b to A’s contact list (persisted), and let client A know so it can update/display A’s contact list appropriately. Otherwise, (if b does not exists), server S notifies client C (and thus A) that b does not exists.
Remove an existing contact (e.g. C). A selects the contact c from A’s contact list, confirms/cancels the removal of the contact. If confirmed, server S removes c from A’s contact list (persisted, and let client A know). If cancelled, nothing should happen.
Chat with a contact (or more) (e.g. D) that is online. Client A opens a chat window where A can send messages to D (and vice versa). Server S sends both clients (e.g. A and D) the contact list that both have in common.
Either A or D add a third client E to the chat (E is common to A and D). Server S sends E the chat history for that particular session.
Log out. Server S notifies other online users that have A in their contact list that A is now offline (the other user’s client displays A status accordingly).
Note that the above description left out some details; for example, when A is chatting with D And somehow D goes offline, should A’s client close the chat window? In such unspecified cases, you are given the degree of freedom to creatively decide how your solution should behave.
Requirements
Design
In this phase, you are to write use case realizations, create class and state diagrams for your server and client apps. The goal of your architecture design is to increase/benefit coupling and cohesion, and non functional requirements like. Here is the list of artifact expected in your design:
Elaborate a detailed Use Case Realization for the Use Cases “Add a new contact” and “Log out”.
Class Diagrams for your solution that follows the MVC architecture with interfaces, delegates, and patterns as appropriate. Note that your class diagram should include classes (whose objects will be de/serialized) for client/server communication. You can submit your diagrams as PDF files generated form a computer program (e.g. Visio), or scanned if you create nice and CLEAR drawings.
State Diagrams for the controllers in your MVC.
Implementation
In this phase, you are to implement the client and the server apps that fulfill all the functional requirements described in the Use Cases. If you have made some revisions on your diagrams, submit the revised class and state diagrams along with your implementation.
Submission
Design
Your submissions should consist of PDF documents named TeamN-FP-DesignName.PDF, where N is your team number, and DesignName can be “UCR” for use case realization, “CD” for class diagram, or “SD” for state diagram.
Implementation
VS projects, C# code, and other files should be submitted using your GitHub account. Each team member must upload to GitHub his or her team solution.