DT8021 Ed 2016 Practical Phase 1
The objective of phase 1 is to apply the following techniques and tools in a practical case study:
- Interface design,
- Test-Driven Development,
- Functional test design, and
- Unit Testing and jUnit tool.
There are two processor boards in this system: Arduino and Odroid that are connected using a USB connection. We only implement a Java class representing the basic communication functionality for the Arduino board. We model the data that is to be passed using the USB connection as internal (private) bitstream data structures in our class.
The first phase of this project concerns test-driven development of the Arduino communication module. This module implements the functionalities regarding adding new sensor data to the output bitstream buffer, reading the latest speed and angle data from the input bitstream buffer, removing an arbitrary number of bits from the output bitstream buffer and adding an arbitrary number of bits to the input bitstream buffer.
The former two interfaces (sending sensor data and reading speed data) are used by the higher level sensor and control modules on Arduino and the latter two interfaces (removing and adding bits from/to the buffers) are called by the lower level communication modules responsible for the USB connection.
The USB connection is unreliable and hence the interfaces to the higher-level modules should be able to deal with corrupted bitstreams that result from connection loss or collisions.
The following list provides more details of the functionality of these interfaces
- Send Sensor Data: This interface has three input parameters (torque, ultra_distance and ir_distance). You may assume that all these parameters are double precision floating point values. It is your choice how to convert these values into packets of bitstreams with appropriate delimiters and error detection or error correction bits. Having proper delimiters and error detection mechanisms for each packet is mandatory: there should be appropriate and unique delimiters marking the start and the end of a packet and between each of the three data items in a packet.
- Read speed and torque: This interface reads from the private field (attribute) containing the current bitstream from received from the network; it returns an object of a class with two attributes: speed and torque. It searches for the delimeter specifying the beginning of the next packet (ignores the bits until there), reads the bits of a whole packet, runs the error detection mechanism to make sure that the packet is not corrupted and if so, puts the values for speed and torque in an object and returns its reference. Otherwise, it searches for the next packet until it finds an uncorrupted packet.
- Write to input buffer: This interface has two parameters: a non-negative number "n" and a bitstream "s" and its appends the first "n" bits of "s' into the end of the input buffer bitstream. (The way a bitstream is implemented is a design choice for you.) It returns 0 if the operation has been successful and a constant non-zero value denoting an error code, otherwise.
- Read from output buffer: This interface has one parameter: a non-negative number "n" and it removes "n" bits from the beginning of the output buffer stream. It returns an object containing an error code (zero if the operation has been successful) and a bitstream with these "n" bits.
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
Before starting any implementation, think of the structure of your packets in the output and input bitstream. Write a short section in your first deliverable about the packets: the delimeters, the content, and the error detection or recovery mechanism used.
The next part of this 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. For each interface method, you need to give its specification in the following form:
/** Description Pre-condition: Post-condition: Test-cases: */
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. Then define a test suite (a set of test-case) with concrete input values and expected outputs.
Your deliverables will be judged based on:
- soundness: whether the packet structure and the interfaces have been correctly specified (according to the requirements), the test technique has been correctly exploited to design test cases, and
- completeness: whether all requirements have been considered and all test-cases necessary to cover them have been given.
Part 2: Test Driven Development
For each and every method, apply the principles of test-driven development to implement the interfaces in order to satisfy each and every test-case. Each line of code should be augmented with the reason why it has been added (which test case it is supposed to satisfy). Before you start each step in the implementation, implement a test-case as a jUnit test, observe how it fails, add the line(s) of code necessary to satisfy it, observe that all tests pass afterwards and comment the line(s) of code to specify why they have been added. In your report, describe in a step-wise manner how each piece of implementation has been added to fulfil a test-case.
Part 3: Self- and Group-Evaluation
Write a paragraph describing the parts of the deliverables you have contributed to. Also, estimate the amount of effort each and every group member has spent on the whole phase both in hours and in percentage. Note that for each group member you should report a separate pair of numbers (hours and percentage of the total work).
This deliverable should be send by each group member in a separate email sent on the same day to the supervisor handling your other deliverables. Group submission will not be accepted. Your mark on each deliverable will be judged based on the quality of the deliverable, the result of the discussion, and the share of work you seem to have performed according to the self- and group evaluations.