DIT085 Ed 2015 Practical Phase 2 - Revision history

Ceres at 20:31, 5 February 2015

2015-02-05T20:31:49Z

Ceres at 20:30, 5 February 2015

2015-02-05T20:30:39Z

Ceres at 16:36, 5 February 2015

2015-02-05T16:36:26Z

Ceres at 15:55, 5 February 2015

2015-02-05T15:55:22Z

Ceres at 13:47, 5 February 2015

2015-02-05T13:47:34Z

Ceres at 13:29, 5 February 2015

2015-02-05T13:29:57Z

Ceres at 09:43, 22 January 2015

2015-01-22T09:43:53Z

Ceres at 01:50, 22 January 2015

2015-01-22T01:50:46Z

Ceres: Created page with "= Objectives = The objective of phase 2 is to apply the following techniques and tools in a practical case study: * Software integration, * Integration testing, and * Measu..."

2015-01-17T17:55:48Z

Created page with "= Objectives = The objective of phase 2 is to apply the following techniques and tools in a practical case study: * Software integration, * Integration testing, and * Measu..."

New page

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

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

== Part 2: TDD of New Modules ==

== Part 3: Integration Testing ==

== Part 4: Measuring Coverage and Testability ==

=[[DIT085|Back to DIT085]]=

@@ Line 188: / Line 188: @@
 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.
 =[[DIT085|Back to DIT085]]=

@@ Line 178: / Line 178: @@
 == Part 3: Integration Testing ==
-First document 5 sceanrios 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.
+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.
 Implement these scenarios as a mock-up for the client (preferably on the server-side by mocking the class responsible for socket connection) using [https://code.google.com/p/mockito/ Mockito] (or similar tools).

@@ Line 178: / Line 178: @@
 == Part 3: Integration Testing ==
-First document 5 sceanrios 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 its has with the server, to closing the connection by the client.
+First document 5 sceanrios 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.
-Implement these scenarios as a mock-up for the client (either on the server-side or as a separate application) using [https://code.google.com/p/mockito/ Mockito] (or similar tools).
+Implement these scenarios as a mock-up for the client (preferably on the server-side by mocking 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).

← Older revision		Revision as of 15:55, 5 February 2015
Line 166:		Line 166:

	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]).		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 ==		== Part 2: TDD of New Modules ==

@@ Line 19: / Line 19: @@
 === Accepting Connections ===
-  <Request connection  id +/>
+  <Request connection  "ID" +/>
-  <Accepted connection from  id +/>
+  <Accepted connection from  "ID" +/>
-where id is the unique identifier (account name) provided by the client.
+where ID is the unique identifier (account name) provided by the client.
 === Adding a message  ===
@@ Line 86: / Line 86: @@
   <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.
+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:
@@ Line 95: / Line 95: @@
 See above for the description of Reason.

@@ Line 47: / Line 47: @@
   </ErrorMsg>
-where reason specifies the reason for failure to be displayed on the client side.
+where reason is a string specifying the reason for failure; the string is to be displayed on the client side.
@@ Line 64: / Line 111: @@
 == Part 2: TDD of New Modules ==
 == Part 3: Integration Testing ==
-== Part 4: Measuring Coverage and Testability ==
+First document 5 sceanrios 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 its has with the server, to closing the connection by the client.
 =[[DIT085|Back to DIT085]]=

← Older revision		Revision as of 09:43, 22 January 2015
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.

@@ Line 11: / Line 11: @@
 = General Description =
-This phase of the project concerns developing, integrating and integration testing of the modules that will together comprise a functioning WhatsUpGU server.
+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]).
@@ Line 17: / Line 54: @@
 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 ==
 == Part 2: TDD of New Modules ==