& Dropping the Course
A C2-Style Architecture
for a Chat System
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
with the chat system theme established so far in this course, in this
assignment you will define a C2-style architecture for a distributed
System contains the following components:
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).
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
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 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.
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.
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.
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.
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).
turn in a report containing
- a cover
page listing your name, student ID, the course number and the
- a graphical
drawing of your architecture, with components clearly identified
and with the configuration strictly adhering to the C2 architectural
- a set
of interface specifications for each of your components.
drawing in Item 2 should contain detail similar to the drawings in the
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;
- 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.)
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
a partial specification for the Chat Room could look like the following:
String, roomID: String)
The e-mail address of the registering user
The unique name of this chat room
register request is sent upward in response only
in response to incoming register requests from some
clients, located below this chatroom. This component
adds its name as the roomID parameter of the outgoing
String, roomID: String)
The identifier of the confirmed user.
The identifier of the chatroom in which the user
the roomID parameter of this notification matches
the current chatroom, this chatroom records that the
user has been registered here and...
The e-mail address of the registering user
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
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).
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).
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.
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.