DIT085 Ed 2015 Practical Phase 2

Objectives

The objective of phase 2 is to apply the following techniques and tools in a practical case study:

• Software integration,
• Integration testing, and
• Measuring code coverage and testability.

In addition, for the modules that are to be developed for this phase, we will keep on practicing test-driven development

General Description

This phase of the project concerns developing, integrating and integration testing of the modules that will together comprise a functioning WhatsUpGU server. The server should listen on port 4444 and should be able to accept multiple connections using the multi-threading mechanisms in Java (see, for example, Oracle's Tutorial on Concurrency in Java). Each connection is handled in a separate thread, all of which will access the messages concurrently. We assume that each user with a given ID should have at most one connection open at a time; multiple connections for the same user should be refused hence.

The server should provide an XML-based interface on its socket with the following specifications.

Accepting Connections

<Request connection  "ID" +/>

<Accepted connection from  "ID" +/>

where ID is the unique identifier (account name) provided by the client.

Adding a message

<AddMessage>
    <Receiver "ID" />
    <Content "TEXT" />
</AddMessage>

The serve will reply to the client with

<Message added: "MsgID" />

Where MsgID is the unique identifier of the added message.

if the text is empty or ID is not a valid receiver identifier, or for any other reason the message is not added the following XML message is replied to the client:

<ErrorMsg>
    Reason
</ErrorMsg>

where reason is a string specifying the reason for failure; the string is to be displayed on the client side.

Deleting a message

<DelMessage>
    <MsgId "ID" />
 </DelMessage>

Where MsgID is the unique identifier of the to-be-deleted message.

The serve will reply to the client with

<Message deleted: "MsgID" />

if the message does not exist (e.g., it has already been fetched), or for any other reason the message is not deleted the following XML message is replied to the client:

<ErrorMsg>
    Reason
</ErrorMsg>

See above for the description of Reason.

Replacing a message

<RplMessage>
    <MsgId "ID" />
    <Content "TEXT" />
  </RplMessage>

Where ID is the unique identifier of the to-be-replaced message and TEXT is the new text to be put in the message.

The serve will reply to the client with

<Message replaced: "MsgID" />

Depending on the implementation, the MsgID may be the same as the old one, or a new unique identifier may be generated for the message. If the message does not exist (e.g., it has already been fetched), the new text is empty, or for any other reason the message is not deleted the following XML message is replied to the client:

<ErrorMsg>
    Reason
</ErrorMsg>

See above for the description of Reason.

Fetching messages

<FetchMessages/>

Note that at the start of the connection the ID is passed to the server and hence, the server already "knows" which messages are to be fetched.

The serve will reply to the client with

<FetchedMessages>
  
    <Messages>
       <Sender "ID" />
       <Content "TEXT" />
     </Message>

     .
     .
     .

 </FetchedMessages>

where ... denotes the other messages for the same receiver, which are included in the same format. Note that until the receiver has not yet confirmed the completion of fetch, either in this connection or in a subsequent one, the messages are kept on the server and another fetch command will return the same set of messages (if no message is sent to this receiver in the meanwhile). If there are no pending messages for the receiver the list of messages will simply be empty.

If for any reason the server cannot fetch the message, the following XML message is replied to the client:

<ErrorMsg>
    Reason
</ErrorMsg>

See above for the description of Reason.

Fetching complete

<FetchComplete/>

This command will result in removing all messages that has been fetched in the last fetch attempt. The serve will reply to the client with

<FetchedCompleteAck/>
  

If for any reason the server cannot perform this action, e.g., since there has been no unconfirmed fetch command, the following XML message is replied to the client:

<ErrorMsg>
    Reason
</ErrorMsg>

See above for the description of Reason.

Deliverables

There are two main deliverables for this phase: a single pdf file documenting the outcome of each and every of the following steps and a .zip file containing the source code of the software implemented in different parts.

Part 1: Architectural Design

First, make an architectural design of the server and decompose ints functionality into some distinct modules. The module you designed in phase 1 will certainly be part of this architectural design. It is recommended that you document your design using a given notation such as UML class diagrams (see, for example, IBM Rational's Tutorial on UML Structural Diagrams).

In your architectural design, make a separate class for accepting connections and communicating with the connected sockets; this will facilitate your integration testing through replacing this class with a mock class for client interaction.

Part 2: TDD of New Modules

You need to design a new module that can accept TCP/IP connections and spawn new threads to deal with the connections concurrently. This module is to be designed in a TDD manner and its specification (interface, description, pre- and post-conditions, and test cases) are to be included in the report. You do not need to include extra information about the techniques used to design the test-cases.

Part 3: Integration Testing

Think of 5 scenarios that capture the main functionalities of the server: these scenarios start from establishing a new connection from the client to the server, to one or more interactions that the client has with the server, to closing the connection by the client. Document these 5 scenarios (in English text).

Implement these scenarios as a mock-up for the client (preferably on the server-side by mocking the class responsible for socket connection) using Mockito (or similar tools).

Measure statement and interface coverage of your server-side application using EclEmma (or similar tools).

Design 5 additional scenarios such that each of them will increase at least one of your coverage criteria. Document the scenario's and the reason you think they contribute to more coverage. Implement them in your mock-up and document the resulting additional coverage for each and every scenario. Note that your mock-up may allow for testing more than one client connecting to the server.