Specification of Chatroom behaviour using Statecharts
Specification of Chatroom behaviour using Statecharts  

General Information

  • The due date is Thursday 5 December 2019, before 23:55.
  • Submissions must be done via BlackBoard. Beware that BlackBoard's clock may differ slightly from yours.
    All results must be uploaded to BlackBoard, including a report that details your solution.
  • The assignment must be made in groups of maximum 2 people. It is understood that all partners will understand the complete assignment (and will be able to answer questions about it). Clearly identify who did what.
  • Grading will be done based on correctness and completeness of the solution. Do not forget to document your requirements, assumptions, design, implementation and modelling and simulation results in detail!
  • Contact Simon Van Mierlo if you have any questions or problems.

Goals

This assignment will make you familiar with Statechart modelling, simulation, and code synthesis (and a bit of testing).

Problem statement

In this assignment, you will design a Statechart model specifying the reactive behaviour of a chat client.

Note that incremental development is good practice: start modelling and trying out (after simulation and subsequently, code synthesis) small parts of the desired behaviour (satisfying only some of the requirements) in isolation. These can be saved and loaded later to incremental build the full solution Statechart.

The model and its visual representation must both be discussed and included in your report.

The application's reactive behaviour (Java code) will be synthesized from the Statechart.

(Behaviour) Requirements

  1. The client is either disconnected or connected to a chatserver.
  2. The client has a (hardcoded) list of servers that it can connect to. A server is identified by its IP address (or hostname) and a port.
  3. If the client is disconnected, the user can not enter any input and must wait for a connection to be established.
  4. The client will autonomously connect to a server by sending a connection request. If the server does not respond within a certain amount of time, another server is chosen until one of the connections succeeds.
  5. As soon as the client is connected, the client will continuously poll the server with a certain interval. Should the server not respond after a certain timeout, the client will automatically go to disconnected mode and the user is again unable to enter any input.
  6. After transferring to disconnected mode, the client will automatically try to establish a connection to another server. After a connection is successfully made, the user can again enter input.
  7. All input that was made by the user before a disconnect should remain in memory and visible to the user.
  8. When the user has connected to a server, the user starts without having joined any room. The user can give the input 'j' (Join) to join a specific room. After pressing 'j', the input box is colored green and only numerical input is accepted. Other input is not accepted, and will result in a warning printed in the console about the rejected input.
  9. After joining a room, the user starts to receive messages from the server that should be shown in the chat window. The user can either leave the room again by pressing 'l' (Leave), or can send a message by pressing 'm' (Message).
  10. After pressing 'm', the entry box colors white and the user can type a message. The message will be sent after the return key is pressed.
  11. Should a disconnect from the server occur while the user has already joined a room, the same room should automatically be joined after reconnection to the server.
  12. Make sure that backspace also works in every input mode.
  13. Input processing must happen in a way that resembles Finite State Automata.
  14. You should test the above requirements by building a testing harnass that will determine whether your Statechart satisfies the requirements. Do this by using sctunit, the testing framework provided by Yakindu.

Interface: Network

This interface provides access to network functionality.
- in event connected
    received when the user successfully connects to a server
- in event disconnected
    received when the user successfully disconnects from a server
- in event joined
    received when the user successfully joins a room
- in event left
    received when the user successfully leaves a room
- in event receive_message: string
    received when a user receives a message from the server (if another participant in the room sends a message)
- in event alive
    received when the server sends an "alive" message (response to a "poll")
	
- out event connect: string
    establish a connection to the server.
    This event takes 1 parameters: a string detailing the full address of the server ("hostname:port")
- out event disconnect
    disconnect from the server
- out event join: integer
    join a server, identified by an integer
- out event leave
    leave the current room
- out event poll
    poll the server (expects an "alive" reply)
- out event send_message: string
    send a message to the room
	
- operation get_nr_of_servers(): integer
    returns the number of hardcoded servers of the client
- operation get_server(index: integer): string
    gets the information of the server with the index provided

Interface: UI

This interface provides access to user interface functionality.

- in event input: string
    a keystroke has occurred
    the event has a single parameter, containing the input character
    some special characters include backspace (\b) and carriage return (\r)
- operation add_message(msg: string, type: string)
    shows the message in the chat window, with the specified type (as a string, either "info", "local_message", or "remote_message"))
- operation append_to_buffer(char: string)
    adds a string to the input field and visualizes the change
- operation remove_last_in_buffer()
    removes the final character from the input field and visualizes the change
- operation clear_input()
    clears the input field and visualizes the change
- operation input_join()
    color the input field in the 'join' mode
- operation input_msg()
    color the input field in the 'message' mode
- operation input_command()
    color the input field in the 'command' mode
- operation get_buffer(): string
    returns the current content of the input field

Interface: util

This interface provides access to utility functions, mainly implementing string operations that are not available in Yakindu.
- operation concatenate(one: string, two: string): string
    returns the concatenation of the argument strings
- operation remove_last_char(inp: string): string
    removes the last character from the argument string
- operation stoi(inp: string): integer
    if the argument string represents an integer, returns its integer value
- operation is_numerical(inp: string): boolean
    returns true if the argument string represents an integer, else false
- operation is_backspace(inp: string): boolean
    returns true if the argument string is a backspace, else false
- operation is_enter(inp: string): boolean
    returns true if the argument string is a return, else false
- operation is_alphanumerical(inp: string): boolean
    returns true if the argument string is alphanumerical, else false
- operation print(inp: string)
    prints the argument string to the console

Starting point

As you should only focus on the reactive behaviour of the chat client, we have provided a starting point for you, which you can download here. The starting point includes a working chatserver (implemented in Java) and a network client (in Statecharts). Additionally, the binding with the GUI is also provided. To run the example project, import it as an existing project into your Yakindu workspace. Make sure that the configuration of your project is such that one of the two .jar files in the 'lib' folder (depending on your OS) is on the Java build path of your project. Download the correct SWT jar from the Eclipse website. To run the server, run the Server main class (pass as argument in your run configuration a port number, either 8000 or 8001).

You should therefore only change the ChatRoom.sct file. It should not be necessary to change the Network, UI, and util interfaces. You might need to add an 'internal' interface for internal bookkeeping.

You can download the examples discussed in class (the traffic light) here: https://reactivesystemsmodeling.github.io/

Practical information

Modelling of the Statechart model can be done using Yakindu SCT. Follow the installation instructions presented on the website. to install the tool and run it.

As this assignment uses a server, you will have to start a server by running the Server main class (which takes as argument a port, for example 8000). You can have multiple servers running, as long as each has a different port. By default, 2 server locations are included in the chat client: localhost port 8000 and 8001. The server will print some information about its communication, so you can see whether or not your calls reach the server. You can run the UI by running the ChatRoomUI main class.

To hand in your project, please export it to a zip-file using the functionality that Yakindu (and any Eclipse installation) offers. Also, please include your model as an image in your report. Use the functionality Yakindu offers to export your model to an image.

It is good practice to model and simulate different parts of the overall solution in isolation (incremental, bottom-up design). Additionally, while doing this incremental design, test the requirements (using sctunit) as you go along; this ensures your increments are always correct with respect to the requirements you have implemented.

You are encouraged to use all functionality that Statecharts offer, such as history states, after events, and orthogonal components.

Maintained by Hans Vangheluwe. Last Modified: 2019/11/29 10:08:06.