DIT085 Ed 2016 Practical Phase 2 - Revision history

Ceres at 12:25, 19 February 2016

2016-02-19T12:25:51Z

Ceres at 12:17, 19 February 2016

2016-02-19T12:17:36Z

Ceres at 09:02, 5 February 2016

2016-02-05T09:02:20Z

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

2016-02-05T07:23:56Z

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 an application that represents the Arduino side of the communication protocol.
It should:

* periodically send the sensor data (in periods of 2 seconds) to the Odroid board and
* periodically receive speed and angle data from the Odroid board (periods of 1 seconds),
* continuously display the latest sent and received value on a display.

The first two items are implemented by making calls to the methods of the class implemented in Phase 1.
The sensor data sent to the Odroid should be read through a simple user interface (once you enter a value, it will be continuously sent to Odroid until you change it).
The three methods should be run concurrently 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]).

= Deliverables =

There are three main deliverables for this phase:

* a single pdf file documenting the outcome of each and every of the following steps,
* a .zip file containing the source code of the software implemented in different parts, and
* a self evaluation of your own effort and the effort by each and every member.

The first two deliverables are sent as a group using GUL.
The last deliverable is sent by email by each member individually to both supervisors.

== Part 1: Architectural Design ==

First, make an architectural design of the application and decompose its functionality into distinct classes. 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]).

You may use the [https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model View Controller architecture] for your design.

== Part 2: TDD of New Modules ==

You need to design new modules that take care of the specified methods and their interaction with the user interface.
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 3 scenarios that capture the main functionalities of the application: these scenarios may include sending and receiving normal data, out of range data, receiving corrupt packets from Odroid and connection loss to Odroid.
Document these 5 scenarios (in English text).

Implement these scenarios as a mock-up for the USB connection to Odroid (preferably using [https://code.google.com/p/mockito/ Mockito] (or similar tools).
Note that using a Mocking library such as Mockito is not mandatory for passing but is mandatory for a pass with distinction.

Measure statement and interface coverage of your server-side application using [http://www.eclemma.org/ EclEmma] (or similar tools).

Design 3 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]]=

← Older revision		Revision as of 12:25, 19 February 2016
Line 68:		Line 68:


−	=[[DIT085\|Back to DIT085]]=	+	=[[DIT085 Ed 2016\|Back to DIT085]]=

@@ Line 65: / Line 65: @@
 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]]=

@@ Line 55: / Line 55: @@
 Think of 3 scenarios that  capture the main functionalities of the application: these scenarios may include sending and receiving normal data, out of range data, receiving corrupt packets from Odroid and connection loss to Odroid.
-Document these 5 scenarios (in English text).
+Document these 3 scenarios (in English text).
 Implement these scenarios as a mock-up for the USB connection to Odroid (preferably using [https://code.google.com/p/mockito/ Mockito] (or similar tools).
 Note that using a Mocking library such as Mockito is not mandatory for passing but is mandatory for a pass with distinction.
-Measure statement and interface coverage of your server-side application using [http://www.eclemma.org/ EclEmma] (or similar tools).
+Measure statement and interface coverage of your Adruino application using [http://www.eclemma.org/ EclEmma] (or similar tools).
 Design 3 additional scenarios such that each of them will increase at least one of your coverage criteria.