Why Our Project is a Good One


Cohesion

Each one of our packages accomplishes one and just one thing. There are no extraneous classes placed in package for convenience; rather each class included directly relates to the goal. Plenty of composition and aggregation is used within packages to make sure that work that is not related to a class's function is delegated to another class designed just for that work. For example, in the screen_sharing package we have SocketReader and SocketWriter classes used by the ScreenReceiver/Sender sessions, rather than having the socket code be mixed in with the session logic. When designing the audio_chat package, we found volume control classes to not have high enough cohesion with the rest of the package, therefore we placed them in a separate package.

Coupling

The Mooch design also utilizes interfaces and the observer design pattern to minimize coupling between packages. As can be seen in the packages diagram, there are very few dependencies between packages. The implementations of the screen sharing, audio chat, and the instant messaging are all independent and in fact each implementation does not even know that the others exist. Any communication from a package to a user of that package occurs through Listener interfaces; this way a package need not have any knowledge of its user. In addition, each package has a few public classes that are used from the outside while all other classes used in implementation are package-visible and are therefore only used inside the package.

Reusability

Although this is not a requirement for the class, the Mooch design focuses on long-term component reusability. For example, instead of having one package to implement the instant messaging functions, Mooch has two. One package is the "front" package with which the GUI interacts, while the second package implements the interfaces presented in the first package. This way, the jabber_instant_messaging implementation can at any time be replaced by an implementation for another messaging network without modifying _any_ GUI code. Each package other than the GUI package is effectively a standalone component which can be used directly in almost any application.

Peer Connection


This very important package facilitates setting up connections between users. It includes UPnP. [ PDF | ZUML ]

Screen Sharing


This package contains all of the details for screen sharing sessions. This is the main focus of our project and the most innovative feature in the messenger. [ PDF | ZUML ]

Audio Chat / Volume Control


The Audio chat package handles VoIP. This is also a significant part of our project, and is key to full usability of the screen sharing sessions. The Volume Control package is a helper package that will communicate with the system to control input and output volume. [ PDF | ZUML ]

Instant Messaging / Jabber


The Instant Messaging package creates an interface for generic instant messaging protocols, and the Jabber Package implements the Jabber protocol using this interface. [ PDF | ZUML ]

GUI


This package contains all of the various windows in the GUI, and the methods that are associated with each buttons, menu bar, slider, etc. This package is incredibly large, because the GUI is the driver for our program and will be communicating with all of the other packages. [ PDF | ZUML ]

Implementation Plan


The implementation work was divided up amongst the group members, and the lines of code were estimated for each package. Having little experience estimating lines of code, we guess lower and upper bounds for each package. The plan can be found here. [ PDF ]

Program Description Language


This is the psuedo-code for the Server Socket Thread. It is taken from comments in our actual source code. [ PDF ]

JavaDoc


You can find the current Mooch JavaDoc here