Assignment 2

A C2-Style Architecture for a Chat System

Due Wednesday, April 24, at the beginning of discussion. If you cannot attend discussion, then please make arrangements with Joe or Eric to drop the assignment off beforehand. This assignment contributes 10% toward your final course grade.

Summary

Keeping with the chat system theme established so far in this course, in this assignment you will define a C2-style architecture for a distributed chat system.

Components

The Chat System contains the following components:

Chat Client: A Chat Client is used by users to chat with other users in a Chat Room. A user must first register with a particular Chat Room before chatting with other users in that room. Each message sent or received through a Chat Client identifies the user who sent the message and the text of the message. When finished chatting in a Chat Room, the user unregisters with the room. There can be multiple Chat Clients, each under the exclusive control of a single user; that is, multiple users cannot share a single Chat Client, although a single user may start up multiple Chat Clients (to be able to chat in multiple Chat Rooms simultaneously).
Chat Room: A Chat Room provides automated processing of messages sent from Chat Clients. It queries the Registration Database to ensure that the user associated with a message is currently registered to chat in the room. If the user is not registered, the Chat Room returns an error message. If the user is registered, the message is delivered to all other users registered in the room, and a copy of the message is filed in a Chat Log associated with the Room. There are multiple Chat Room components available, each devoted to a different chat topic.
Registration Database: The Registration Database stores the set of currently registered users for each Chat Room and is able to remember which users are registered with which Chat Room. Users are identified in this database by their email address. Any person with a valid email address can register for a chat room (i.e. there is no authentication or password needed). Users remain registered until they unregister themselves via a chat client. There is one Registration Database in the system.
Chat Controller: A Chat Controller is used by administrative personnel to monitor all the message traffic in the Chat Rooms, and to unregister users who send inappropriate messages. There is one Chat Controller in the system.
Chat Log: The Chat Log stores a record of all messages sent in a Chat Room. There is one Chat Log associated with each Chat Room.
Buddy Alarm: A buddy alarm may be started by a user to notify him or her when a particular user registers with any chat room. The buddy alarm has its own user interface which informs its user of the buddy's registration and the chat room that the buddy has registered in. When a buddy alarm is started, it remains inactive until its user enters a buddy's email address to monitor. Each buddy alarm watches for only a single buddy, although a user may start up multiple buddy alarms to watch for multiple buddies.

The above components are the only components that should appear in your architecture. Note, however, that some of the components listed above can appear in the architecture more than once.

Hint: Focus on defining the static structure of the system and the definition of the request and notification messages passed between components. Do not attempt to model aspects of dynamic behavior (such as the order in which messages are sent through the architecture, the state transitions of components, the control logic of components, or the conditional sending of messages by components).

Deliverables

You will turn in a report containing

a cover page listing your name, student ID, the course number and the assignment number;
a graphical drawing of your architecture, with components clearly identified and with the configuration strictly adhering to the C2 architectural style; and
a set of interface specifications for each of your components.

The graphical drawing in Item 2 should contain detail similar to the drawings in the C2 paper by Taylor et al. (such as Figures 8 or 10). For the component specifications, clearly list the request messages and notification messages that pass through the component's top and bottom interfaces. Each message should have:

A name; and
A set of parameters, each of which has a name and a type (limit your parameter types to standard Java types such as String, int, double, Date, etc.)

Each parameter should have a prose description associated with it describing its use in this context. Furthermore, each message should be annotated with a prose description describing the conditions under which the component will send the message out (in the case of outgoing messages) or what the component will do when it receives a message (in the case of incoming messages), just as you might describe the behavior of a method in the Javadoc style.

For instance, a partial specification for the Chat Room could look like the following:

component ChatRoom
- Top Interface
  - Requests:
    - register(userID: String, roomID: String)
      - Parameters:
        
        userID: The e-mail address of the registering user
        
        roomID: The unique name of this chat room
  - Notifications:
- Bottom Interface
  - Requests
    - register(userID: String)
      - Parameters:
        
        userID: The e-mail address of the registering user
      - Description:
        
        Incoming register requests from clients are forwarded upward to a component that can confirm or deny the registration, but the identifier of this chatroom is added to the outgoing request. See above top interface outgoing request "register" for more detail.
    - ...
  - Notifications
    - ...

You do not necessarily have to adhere to this nested-bulleted-list format, instead opting for tables or some other layout, but you must have all the elements here, preferably in the order given above (top requests, top notifications, bottom requests, bottom notifications).

The above specification is just an example, and this listing of messages is insufficient and incomplete (the Chat Room will most likely support additional requests in its top interface and additional notifications in its bottom interface).

Make sure your messages match in the following sense: For every request passing through the top interface of a component, there must be some other component that passes the same request through its bottom interface, such that the request only traverses connectors between the top of the first component and the bottom of the second. A corresponding rule applies to notifications traveling downward.

In evaluating your work, 40% of the credit will be earned for quality of the architecture and adherence to the C2 style, and 60% for definition of component interfaces.