18-649 Project Assignment #9

Due Thursday March 27, 2008 11:59 PM

Improved Dispatcher; All SDs; Dispatcher Statechart

Now that you've finished the detailed design for your elevator control system, you'll design a test suite to exercise each module individually, as well as perform integration tests.


Assignment:

This assignment has three parts:
1) Design State charts
Update your state charts so that they reflect the new requirements you created in project 8.
2) Design Unit Tests
Create a set of complete unit tests for each of the seven control modules.
3) Implement and +Test Improved Dispatcher
This does not include the other objects affected by the improved Dispatcher.

In this assignment you're going to update your state charts to reflect your new design and create a test plan.  For this project we will require you to write unit tests that you will perform in the next project (after you have written all of the code).    In real life testing to assure product quality is an extremely important aspect of the development cycle.  In industry, it is common to have about one tester for every developer on a project team (the ratio varies, but it is often in the range of 1-2 testers out of every 3 people in a software project team).
 

Why testing isn't just debugging

Believe it or not, the primary purpose of testing highly dependable software is not to find bugs.  Instead, testing provides a way to measure the quality of a design and implementation.  Thus, it is important when designing and executing tests to keep in mind that a failed test case means more than simply a bug was found -- it means that the system design and implementation process failed in some respect.  Finding a bug also suggests that other similar problems are likely to exist elsewhere in the project, caused by possible systematic problems with the process used to create the system being tested.  This is something to keep in mind when you're using these tests in the next assignment.

Beyond the fact that testing is a quality assurance activity, there is a fundamental difference between debugging and testing in what you're allowed to do.  In debugging you can insert extra print statements and in general change implementations to help understand what is going on.  In testing you must take a module as it is intended to be used in the final program and exercise it using only its intended inputs and outputs.  For this project that means that in module tests you must input and observe network messages.


1) State Charts:

Update your state charts so that match your design from project 8.  Update the corresponding traceability tables.

2) Unit Tests:

Create tests that exercise all transitions of your design (i.e., all arcs on your state diagrams).

Unit test for this project means testing the behavior of a single system object such as a door controller or the dispatcher.

We provide a simulation framework that "glues" together all the different system objects, both ones you design and ones we're designing for you.  You are responsible for implementing and testing the objects you have designed (DoorControl, DriveControl, LanternControl, HallButtonControl, CarButtonControl, CarPositionControl, Dispatcher).  You may assume that we have tested the other objects we provided.

The unit test option instantiates a special diagnostic object which takes a plain text file describing messages to be sent on the network and sends them out on the network at specific times.  This diagnostic object also records all network messages and places them in an output file.   When you run the simulator with this option you can run single unit tests and observe the output.

The module test file format is:

<seconds>,<rep_interval>,<message_type>,<data_field1>,..,<data_fieldN>,<context> ; <comment_field>
Where each line of the file generates a single copy of a single message onto the network at the time specified.  <seconds> is a floating point number of seconds; <rep_interval> is the repetition interval (in floating point seconds) for the message, with zero being a single event message; <message_type> is the name of a message; the data fields are as documented.  Context will be N for network, F for framework.  Comments are indicated by a ";", with the comment extending to the end of a physical line. Any modules in the system will be fed an "initialize" signal before the testing begins.
CLICK HERE TO SEE EXAMPLES OF ALL SUPPORTED MESSAGE TYPES.

The assignment is to generate a set of files that are sufficient to completely test all your designs. 

We are going to leave the details of how to accomplish things to you, but to be correct a test shall address the following points:

CLICK HERE FOR AN EXAMPLE TEST FILE.

Note:  Designing these tests may require some assumptions about timing. You should include in comments any timing-sensitive conditions that you might have to set up when you actually have code running.  For example, you might have a time of "X" and in the comments put "set X to be exactly the time at which the first door closed switch goes true".


3) Implement and Test Improved Dispatcher:

First you must implement in Java your improved dispatcher. You only need to implement the improved dispatcher for this project (you will implement the remaining objects in the next project). Please follow the coding guidelines outlined in Projects 5 & 6. Namely, mark the line in each code that causes each and every state transition (i.e. forward traceability) you have designed on your state charts. Utilize comments in the form:

// #transition 'A()'
at the line causing the transition. 

Secondly, you need to execute the unit tests on the implemented improved dispatcher. You will not lose points for failed tests, but points will be taken off if the tests aren't completed OR the tests fail and you don't specify what tests failed.  (You will have to pass all tests in the next project phase). 


Design portfolio:

Your portfolio should be up to date and reflect all changes through project 9. This includes adding the updated state charts, unit tests, improved dispatcher code and the results of the unit tests executed on the improved dispatcher.


Handing In Results

Each team shall submit exactly one copy of the assignment.

Your submission shall follow format, directory, and other aspects of organization specified in project8, except of course everything for this assignment will be placed in the appropriate project directory. Do NOT modify files in the directories for previous assignments.

Make sure everything in your project is updated and consistent across the entire design. Use the checklists we've given you. Listen to what the TAs have told you and address the issues they point out. By this point in the semester you know the drill...

In addition for this project you must include:

Grading (105 points):

Note: above points include relevant updates to traceability, change log, defect tracking, etc.

Note: we are no longer awarding points for having a complete and consistent design package, nor just for following instructions. Those should be a given at this point. However, TAs can deduct points from the project for failing to following turn-in directions or having an end-to-end design package with blatant gaps.


Back to course home page