John Hofman's Design Study

My Project

This design study was introduced by my ENEL428 software assignment. The purpose of the assignment was to design a prototype of an Instant Messenger System using concurrent programming. The system was broken into two separate parts a client and a server. This design study is regarding the client program.

Design Study

The initial system uses a simple login model, a user attempts to log in with just a username which the server accepts or rejects.

Functional requirements of the client:

• Connect to a server.
• Login.
• Logout.
• Display the other users online.
• Start a conversation with another online user.
• Post Messages in a conversation.
• Invite other online users to a conversation.
• Leave a conversation.

Constraints:

• C++
• Uses POSIX threads for concurrency.

Room for Expansion:

• Other protocols, XMPP etc.
• Other GUI implementations, currently uses fltk-1.1.9

Initial Design

This is the design which is fully functional.

[UML]

Description

Concurrent Design

This design is an event driven system. There are two threads.

• The Inbox encapsulates a thread that reads and responds to packets from the server via the Socket.
• The GUI uses a thread to respond to user input and manipulate Chats and the UserManager.

Chats and the UserManager use Mutexs to synchronise access to their data.

Class Descriptions

• Socket/ClientSocket: The Socket encapsulates a TCP Socket. It provides an interface to read/write packets to the socket.
• Inbox: Encapsulates a thread that reads packets from the ClientSocket, unpacks them and executes operations on the Chats and the UserManager.The Inbox also contains a map that links Chat objects to their ChatID's (This is nasty, why does the inbox have this map).
• Chat: Each chat represents a conversation with another user. The chat maintians a list of messages but not the participants of the conversation (YAGNI vs OCP?).
• UserManager: The UserManager keeps a record of the other users online. The server pushes updates to the client when users log on and off so they can be added and removed from the UserManager. The user manager also handles the login/logout actions of the local user.
• Outbox: The outbox builds packets to write to the socket. It is used by Chats and the UserManager to send information to the server. The outbox currently records the userID of the local user so it can tag outgoing packets, this seems like it shouldn't be there. (If it wasn't there then the outbox is just behavior without state, except a reference to the Socket)

GUI:

• Factory/Fl_Factory: Sort of implement the factory pattern, in a strange way. It makes Chats and UserManagers and also makes the associated Fl_Window'ed objects (Fl_WindowedChat and FL_WindowedUserManager) which are then linked with the observer pattern.
• Fl_WindowedChat: Encapsulates the GUI for a Chat. In an observer of a Chat. Implemented using fltk-1.1.9
• Fl_WindowedUserManager: Encapsulates the GUI for a UserManager. Is an observer of a UserManager. Implemented using fltk-1.1.9

Stuff that needs fixing, maybe?

• Chat map in Inbox
• Switch smell in Inbox to deal with packets? Polymorphism..? Which means that Socket will need a switch.
• Chat doesn't record participants, might need that for other protocol (YAGNI vs OCP)
• Socket/ClientSocket inheritance is weird, socket should just be an interface so that it is extendable.
• Packet should know how to serialise itself.
• Outbox shouldn't record who is logged in.
• Names of classes are a bit meh.

Other Stuff

Simple chat Log