View source for DT8021 Phase 2, 2015 Ed

= 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.

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 WhatsAppHH client. The client should connect to the sever on a given IP address (coded as a constant in the code) and on port 4444. The connection should be established every 10 seconds, added messages should be pushed and received messages should be pulled. We assume that each user with a given ID should have at most one instance of a client. 


The client's GUI features a main activity in which one can choose the following options: 

* Add a message,
* Delete a message, 
* Edit a message, and 
* View messages 

 Each of these option will lead to another activity in which the corresponding functionality can be performed. 
 It is assumed that pull and push are performed with a fixed regularity in a background thread. 

The client uses an XML-based interface  to interact with the server on the socket connection. 
 
=== Establishing a Connections ===

 <Request connection  "ID" +/>



 <Accepted connection from  "ID" +/>


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

=== Pushing new message  ===
During the pushing process, a number of messages with the following format is sent to the server. 

 <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. 

Note that replace and delete take place at the client side and do not involve interaction with the server. 




=== Pulling messages  ===
When requesting a pull a message with the following format is sent to the server. 

 <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. 

If for any reason the server cannot sent the pulled message, 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, [http://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/ 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 GUI, the background threads for push and pull, as well as a new module that can establish TCP/IP connections. 

These modules are to be designed in a TDD manner and their 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 single interactions of with the client  (such as adding and deleting a message), as well as interactions involving two clients via a server.  
Document these 5 scenarios (in English text).

Implement these scenarios as a mock-up for the client (preferably on the client-side by mocking the socket class or the class responsible for socket connection) using [https://code.google.com/p/mockito/ Mockito] (or similar tools). 

Measure statement and interface coverage of your server-side application using [http://www.eclemma.org/ 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. 


=[[DIT085|Back to DIT085]]=