DT8021 Ed 2016 Practical Phase 2

From CERES
Revision as of 11:33, 29 April 2016 by Ceres (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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 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 methods should be run concurrently using the multi-threading mechanisms in Java (see, for example, Oracle's Tutorial on Concurrency in Java).


To do this, first design a class representing the typical functions of a USB connection (you can decide about the details of its interface and data fields yourself). Document this design, but do not implement it.

Use the dependency injection technique to parameterize the class you designed in phase 1 with a generic interface representing the USB channel (instead of the fixed internal bitstreams you used in phase 1). Refactor your code by using this new design pattern, re-run your tests and if necessary design new tests to cover your re-factored code. Make an instance of the class where the input and output bitstreams are replaced with two instances of the designed USB class (representing input and output USB channels). Mock the USB class behavior to perform a USB connection connected to the Odroid processor board as specified above.



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.

All deliverables are sent as a group by en email.



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, IBM Rational's Tutorial on UML Structural Diagrams).

You may use the 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 3 scenarios (in English text).

Implement these scenarios as a mock-up for the USB connection to Odroid (preferably using Mockito (or similar tools). Note that using a Mocking library such as Mockito is not mandatory for passing but will result in a higher project mark.

Measure statement and interface coverage of your Adruino application using 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.


Back to DT8021, Edition 2016