Difference between revisions of "DIT085 Ed 2015 Practical Phase 2"
Line 11: | Line 11: | ||
= General Description = | = 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, [http://docs.oracle.com/javase/tutorial/essential/concurrency/index.html Oracle's Tutorial on Concurrency in Java]). | + | 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, [http://docs.oracle.com/javase/tutorial/essential/concurrency/index.html 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. |
Revision as of 10:43, 22 January 2015
Contents
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 specifies the reason for failure to be displayed on the client side.
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).