Designing an Instant Messaging System for Effective Communication

1. Informatics 122Software Design II Lecture 12 André van der Hoek & Alex Baker Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited. February 21, 2009 – 18:05:18 (c) 2009 University of California, Irvine – André van der Hoek 1

2. Today’s Lecture • Final design project February 21, 2009 – 18:05:18 (c) 2009 University of California, Irvine – André van der Hoek 2

3. Final Design Project • Design and implement an Instant Messaging system • With a team of 13 • The team is partitioned into four subteams • Server team • Communication team • Standalone client team • Web client team • Each team is responsible for the design and implementation of its part • Everyone, of course, is responsible for the overall design and implementation at the end, that is, the parts should fit and the final demo should be fully working February 21, 2009 – 18:05:19 (c) 2009 University of California, Irvine – André van der Hoek 3

4. Final Design Project • March 3: breakdowns into subteams due (e-mail)‏ • March 4: no class • March 7: preliminary designs from subteams (e-mail)‏ • March 9: open discussion in class to address any emerging issues • March 11: final design, to be frozen (e-mail)‏ • March 16: final implementation and demo (on CD, with documentation, and any design changes carefully motivated)‏ February 21, 2009 – 18:05:19 (c) 2009 University of California, Irvine – André van der Hoek 4

5. Server Team • The server provides the central storage of all information that should be centrally kept (buddy lists, for one; who is a member and who is not, for two; and any preferences that should be known independent from where I log in, for three). • The server team also should provide a viewer for administrators to use to understand usage statistics of the IM system (both overall, such as peak times and the like, and individually, such as how many messages the average person sends, their length, how much file sharing, etc). Be imaginative, this feature is crucial. The viewer should be able to both provide historical views as well as instant “right now” insight. • The server should be scalable, and be able to deal with 1000s if not 100,000s of requests in a very short time. • The server should be secure. February 21, 2009 – 18:05:19 (c) 2009 University of California, Irvine – André van der Hoek 5

6. Communication Team • Provide a high level interface through which it is easy for the other teams to use services such as "send to buddy x", "get list of buddies", "join group chat y", "find available group chats involving any of my buddies", ... • Make sure that communication is reliable, and can support delivery of messages at a later time, when someone comes back online. • Make sure to support file transfer, as that is part of our IM system. • Make sure that the architectural approach is sufficiently general to accommodate other protocols at a later time (i.e., gtalk, yahoo, AIM, ...). February 21, 2009 – 18:05:19 (c) 2009 University of California, Irvine – André van der Hoek 6

7. Standalone Client Team • Support all the input and output of chatting and file sharing, essentially, the UI plus the internal engine of the client as it builds upon the communication infrastructure. • Support a skinnable UI, so the interface can have different looks. • Support the ability to view and search past chats. • Provide a reasonable number of configuration options (such as the ability to configure how and when “away mode” happens, how sound is dealt with, how the contact list appears (sorting, with or without icons, how to present on/offline, show offline contacts yes/no), how buddies are grouped (which buddies are part of which groups, particularly), how and where message windows appear (tabs per group, each person individually, location), appearance of text, where saved files go, and how long of a history is kept. February 21, 2009 – 18:05:19 (c) 2009 University of California, Irvine – André van der Hoek 7

8. Web Client Team • Support the functionality of the standalone client team through a web client, except: the skinnable UI, sound, and window placement, and away mode. • The client cannot be a simple Java applet wrapping the standalone client, but should be designed separately, using HTML, Javascript, and/or Flash, etc. February 21, 2009 – 18:05:19 (c) 2009 University of California, Irvine – André van der Hoek 8

9. Reuse • Cannot pick up an existing IM implementation (sorry ). • For other major components, double check with Kyle. February 21, 2009 – 18:05:19 (c) 2009 University of California, Irvine – André van der Hoek 9

10. Team Assignments • Team 1 • Jay Bacuetes • Lance Cacho • Alton Chislom • Jeff Gaskill • Ben Kahn • Derek Lee • Leslie Liu • James Milewski • Rakesh Rajput • Tomas Ruiz-Lopez • Matt Shigekawa • Aylwin Villanueva • Lance Zepeda • Team 2 • Chad Curtis • Scott Ditch • Robert Duncan • Alexander Doan • Matt Fritz • Robert Jolly • Alex Kaiser • Dan Morgan • Scott Roeder • James Rose • David Schramm • Jordan Sinclair • Josh Villamarzo February 21, 2009 – 18:05:19 (c) 2009 University of California, Irvine – André van der Hoek 10