For this exercise each student will create a very high-level design of a software product. The design will be presented as one of more UML diagrams, including at least one class diagram, showing the overall structure of the system. The class diagrams should contain only class names – no state or methods – and the relationships among the classes (inheritance, association, and aggregation, and possibly cardinality and role labels). A separate section of the document should give brief (1-2 sentence max.) descriptions of the responsibilities for each class. The total document size, including diagrams, must not exceed 3 pages.
Feel free to work with each other during the remainder of the first class and before the second class to develop ideas and strategies. However, each individual is responsible for handing in his or her own design sketch at the start of the second class, and this sketch will contribute 5% to your final grade. Students who make a good faith effort to develop a robust design can expect to receive 4 or 5 points, even if the design itself is suboptimal. The goal is to start students on the path to reflecting about design at a higher level than individual classes and methods.
The second class will be divided into three sub-sessions. In the first sub-session, small groups (3-4 students each) will quickly sketch consensus design that incorporates the best aspects of the individual designs. In the second sub-session, one or more of the teams will present their sketches to the class as a whole (5-10 minutes per presentation). In the final sub-session, we revisit the problem and the designs to show how patterns might make it easier to create, discuss, and evaluate designs.
There are many competing instant messaging (IM) systems available on the Internet (AIM, ICQ, Microsoft Messenger and Yahoo Messenger, to name four). Trillian is a product that attempts to provide a single, consistent interface to these systems so that users can communicate with with buddies on any IM system. Information on Trillian can be found at:
http://www.ceruleanstudios.com/trillian/index.html.
We’ve decided to enter this product space ourselves with a product called “Thrillian” with the marketing slogan “If you like Trillian, you’ll be thrilled by Thrillian!” Unfortunately, the marketing department has gotten ahead of the development group – we don’t even have a design for Thrillian. That’s your job – you are responsible for designing the core functionality (you can ignore the details of the user interface for now). An outline of the requirements is given on the next page.
1. The system must provide a seamless virtual IM environment in which basic IM functions are supported transparently across the four real IM systems above and others that may be added in the future:
a. Acquiring, maintaining, and updating contact lists. The contacts on any given list may be from a mixture of real IMs, but there must be some way to identify the underlying IM system associated with each contact.
b. Organizing contact lists into arbitrary hierarchical groupings of the user’s choice.
c. Initiating peer-to-peer chat sessions and responding to requests for such sessions.
d. Sending and receiving IM messages and displaying them in a transparent manner.
e. Sending and receiving files in a transparent manner.
2. The system must be able to set and view parameters and controls appropriate to each IM (e.g., account names, passwords, filters, etc.). While the parameters and controls are “real” IM dependent, the mechanism for setting and viewing these must be “virtual” (that is, the overall system is ignorant of the details of configuring any specific IM).
3. The system must be able to set and view information related to any contact. Again, this is dependent on the “real” IM system with which the contact is associated, but the mechanism for viewing and setting contact information must be “virtual.”
4. The system must support N-way conferences, where the contacts involved in the conference need not be associated with the same “real” IM system. The only difference between N-way conferences and peer-to-peer sessions are:
a. Sending a message to a conference results in the message being sent to every contact involved in the conference.
b. A message received from any participant in the conference will be displayed as if it came from the conference as a unit.
c. Contacts can be added or removed from a conference dynamically.
5. Your section instructor is free to clarify, modify, or amplify these requirements based on discussions during the first class session. It is highly unlikely that two sections will end up designing to identical requirements.