COMP 304B Object-Oriented Software Design - Assignment 3
Due date: Monday February 19th, 2007 before 23:55 extended to Monday, the 26th

Practical information

• Team size == 2 (pair design/programming) !
  
  
• Each team submits only one full solution. Use the index.html template provided on the assignments page. Use exactly this format to specify names and IDs of the team members. The other team member must submit a single index.html file containing only the coordinates of both team members. This will allow us to put in grades for both team members in WebCT. Beware: after the submission deadline there is no way of adding the other team member's index.html file and thus no way of entering a grade !
  
  
• Your submission must be in the form of a simple HTML file (index.html) with explicit references to all submitted files as well as inline inclusion of images. See the general assignments page for an index.html template.
  
  
• The submission medium is WebCT.
  
  

Requirements

• There are 6 clients and 2 chat rooms in the system. The clients must be connected to a chat room before they can randomly send messages.
• The system works in a round-robin fashion. In each round, a random client will connect or send a message to a random chat room.
• Initially, the clients are not connected. They try to connect to a random chat room in each round. The requested chat room immediately receives the request.
• A chat room can accept at most 3 clients. It accepts a connection request if and only if its capacity is not exceeded.
• The requesting client receives acceptance or rejection from the chat room immediately.
• When connected, a client sends random messages to the chat room in each round. The chat room immediately receives the message. It processes the message and broadcasts it to all the other clients (except the sender) connected to it.
• The clients immediately receive the broadcast messages.
• For simplicity, disconnection and reconnection need not be modelled.

• Adding an association class between Clients and Chat rooms which can record connections is not a bad idea.
• It could be easier to model dynamic system behaviour if you define two phases in a client's life: connecting and communicating.

1. When a client sends a connection request to a chat room, the chat room immediately responds by printing to the output.
2. On receiving a connection request, the chat room immediately makes a decision whether to accept the client or reject it.
3. When a chat room accepts a client, the client immediately receives the acceptance and dumps to the output.
4. When a chat room rejects a client, the client also immediately dumps the rejection.
5. When a client sends a message, the chat room immediately receives it and prints the message to the output.
6. When a chat room receives a message, it broadcasts it to all connected clients except the sender.
7. The sender cannot receive its own message after it sends it.

1. Design the static structure in a UML Class Diagram;
2. Design the dynamic interaction behaviour in UML Sequence Diagrams;
3. Write regular expressions (refer to the format of the given output trace) for verifying the above use cases (in this assignment, you only need to verify TWO use cases: use case 2 and use case 7); the following is an example:
   

   Regular expression pattern for rule 1:
   ##[^\n]*\n\(CL (\d+)\) RS (\d+)\.\n##[^\n]*\n\(CR \2\) RR \1\.\n
   
   The following output will match the above pattern:
   ## (Client 2) A connection request is sent to chat room 1.
   (CL 2) RS 1.
   ## (Chat room 1) Received connection request from client 2.
   (CR 1) RR 2.
   

4. Design a FSA which encodes the regular expressions for verification;
5. Implement this FSA for verification in the provided code framework;
6. Run this FSA implementation (which in turn implements the regular expressions which in turn encode the checking of interaction behaviour use cases) on the given output trace (output) to verify the specification.
7. There is an intentional bug in the implementation (chatprotocol.py) which makes it unsatisfy the system specification. You need to figure it out by verifying the output trace with your FSA implementation, and fix it (just one line).

Starting Point

• The program implemented the system: chatprotocol.py
• The output trace generated from the above program: output
  To make life easier, we use abbreviation to shorten the messages that you need to recognize by FSA. Here is the mappings:
  

  CL := Client
  CR := Chat room
  RS := A connection request is sent to chat room
  RR := Received connection request from client
  AC := Accepted client
  AB := Accepted by chat room
  RC := Rejected client
  RB := Rejected by chat room
  SY := Says
  RM := Received message from client
  SM := Sent message to all connected clients except client
  

  As you can see, any message in the output file which starts with "##" is some comments to make the output readable. You need to ignore these messages when you do verification.
• Programs used to implement FSA: the scanner is in scanner.py which requires an input stream class CharacterStream found in charstream.py.

Examples