DIT085 Ed 2015 Practical Phase 1 - Revision history

Ceres at 20:16, 27 January 2015

2015-01-27T20:16:46Z

Ceres at 17:49, 17 January 2015

2015-01-17T17:49:52Z

Ceres at 17:45, 17 January 2015

2015-01-17T17:45:18Z

Ceres at 10:05, 13 January 2015

2015-01-13T10:05:18Z

Ceres at 10:04, 13 January 2015

2015-01-13T10:04:59Z

Ceres at 09:57, 13 January 2015

2015-01-13T09:57:51Z

Ceres at 14:05, 12 January 2015

2015-01-12T14:05:33Z

Ceres at 13:59, 12 January 2015

2015-01-12T13:59:19Z

Ceres at 13:58, 12 January 2015

2015-01-12T13:58:57Z

Ceres at 13:52, 12 January 2015

2015-01-12T13:52:21Z

@@ Line 22: / Line 22: @@
 * Replace: like in the previous item, the sender of the message can modify the message before it is fetched by the recipient. To do this, the sender should provide the Id of an existing message and a new non-empty string to replace the existing message. If the message exists (and it is not yet fetched), the message is replaced by the new string and the Id of the message (a positive integer) is returned. Otherwise 0 or a negative number indicating the reason for the error is returned.
-* Fetch: when a cell-phone gets connected to the Internet, it contacts the server and fetches the messages sent to it since its last time online.
+* Fetch: when a cell-phone gets connected to the Internet, it contacts the server and fetches the messages sent to it since its last time online. This is performed by calling the fetch method and passing the identifier of the recipient;  as a result, messages are returned as a string (with an XML structure indicating messages, their Ids, and their senders.
 This is performed by calling the fetch method and passing the identifier of the recipient;
 as a result, messages are returned as a string (with an XML structure indicating messages, their Ids, and their senders.
 * Fetch-complete: Once the recipient has fetched and displayed all its messages, it will signal the successful completion of the fetch operation and as a result, the messages will be removed from the server; the sender will also be signalled to mark the fetched messages at its client user interface. Fetch complete will return a positive number if it has been successful or non-positive number indicating the type of error happened.

@@ Line 1: / Line 1: @@
 = Objectives =
-The objectives of phase 1 is to apply the following techniques and tools in a practical case study:
+The objective of phase 1 is to apply the following techniques and tools in a practical case study:
 * Interface design,
@@ Line 9: / Line 9: @@
 = General Description =
-The first phase of this project concerns test-driven development of the kernel of our WhatsUpGU server.
+The first phase of this project concerns test-driven development of the ''kernel'' module of the WhatsUpGU server.
-Before we start test-driven development, we need to fix the interface of the to-be-implemented module, which
+This kernel module implements the basic functionalities regarding adding, deleting, editing and fetching messages in the server.
 should provide the following functionalities:

@@ Line 27: / Line 27: @@
 = 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.
+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 as the final outcome of this phase.
 == Part 1: Interface and Test Design ==

← Older revision		Revision as of 10:05, 13 January 2015
Line 64:		Line 64:


−	=[[~~Mohammad Mousavi~~\|Back to ~~Home~~]]=	+	=[[DIT085\|Back to DIT085]]=

@@ Line 1: / Line 1: @@
 = Objectives =
 = General Description =
@@ Line 56: / Line 62: @@
 Before you start your implementation, implement your test-cases as a jUnit test.
 In your report, describe in a step-wise manner how each piece of implementation has been added to fulfil a test-case.

← Older revision		Revision as of 09:57, 13 January 2015
Line 45:		Line 45:

	To design your tests, first use one of the functional testing methods (preferably: classification tree or decision table) to partition the domain of different inputs (or output) using the above-given requirements.		To design your tests, first use one of the functional testing methods (preferably: classification tree or decision table) to partition the domain of different inputs (or output) using the above-given requirements.
−	~~As a general principle, when you find an ambiguity in the requirements, make a reasonable assumption and '''document it clearly''' in your report.~~
	Then define a test suite (a set of test-case) with concrete input values and expected outputs.		Then define a test suite (a set of test-case) with concrete input values and expected outputs.

@@ Line 24: / Line 24: @@
 == Part 1: Interface and Test Design ==
 The first deliverable concerns the interface and the test design of the above-specified module.
 For the interface, you need to specify the signature of the methods: name, input argument types, and output return type.
@@ Line 29: / Line 30: @@
   /**
     Description
@@ Line 45: / Line 47: @@
 As a general principle, when you find an ambiguity in the requirements, make a reasonable assumption and '''document it clearly''' in your report.
 Then define a test suite (a set of test-case) with concrete input values and expected outputs.

@@ Line 31: / Line 31: @@
     Description
-    Pre-condition:
+   Pre-condition:
     Post-condition:
     Test-cases:
-−
   */

@@ Line 26: / Line 26: @@
 The first deliverable concerns the interface and the test design of the above-specified module.
 For the interface, you need to specify the signature of the methods: name, input argument types, and output return type.
-To design your tests, first use one of the functional testing methods (preferably: decision tree or
+For each interface method, you need to give its specification in the following form: