18-649 Project 9

Advanced Elevator Design, Smart Dispatcher Implementation and Unit Testing

Due Thursday March 26, 2009 at 11:59 PM

Please submit all project-related correspondence to staff email address
Changelog:
Now that you've finished the detailed design for your elevator control system, you'll design a test suite to exercise each module individually.

Assignment:

This assignment has three parts:
  1. Design Statecharts   -- 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 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 fix 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 unit tests you must input and observe network messages.

1) State Charts:

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

Recall that your design must be completely time triggered.  If needed, go back and review the Time Triggered Design Overview in Project 4.  You should make sure that you continue to adhere to these guidelines as you go forward with your optimized elevator design. 

In addition to these existing requirements, note the following:
Your implementation may not take more than one transition per execution of the control loop*, and the control loop must execute periodically with the periods dictated in previous projects. 
While this requirement does not affect your statecharts directly, you should consider how it may affect the timing of your controllers and your controllers' ability to meet safety deadlines, especially if you are using intermediate states to approximate entry actions.

*Note:  To schedule controller code in real systems, there must be a worst-case bound on the execution time.  If the controller is allowed to make multiple transitions, then there is (theoretically) no upper bound on how long it takes to execute the controller.  The one-transition-per-loop rule also approximates the limited processing power of the small microcontrollers you would likely see in a highly distributed application.

2) Unit Tests:

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.

You began unit testing back in Project 5.  Review Unit Testing in the Testing Requirements document.  Now you will write complete unit tests for all of your controllers. After the tests are written, each test must be peer reviewed by someone other than the author. 

Note:   If a peer review results in changes to the unit tests, those tests shall be logged in the change log.

You are not required to execute the tests this week, but you must still make an entry for each test in the Unit Test Log with all the appropriate links to the test files. In addition to the Unit Test Log, you will prepare the Unit Test Summary File, which is described below.

Note:  Even though you are not required to run your tests this week, don't blow off this part of the assignment.  You should at least execute your tests to make sure that they are syntactically correct.  If you do a poor job of test creation this week, you will just have twice as much work to do next week, please you will have to log all the revisions to the tests in your issue log!

Unit test summary file

In order to facilitate automated testing, we require a machine-readable input format that summarizes your unit tests.  Even though you are not actually executing the tests for this project, you should make the test summary file as you make your unit tests.  This requirement is in addition to any HTML documentation you use to summarize your test results. 

The unit test summary file shall be called unit_tests.txt, and it shall be located in the unit_test folder of your project.  This file shall contain a line for each unit test you wrote.  The line shall contain three text fields with the following format:

<object tested> <configuration file (.cf)>  <message injector file (.mf)>

(Note that this requirement precludes the use of filenames with spaces).  The files names for the .mf and .cf files should include the relative path from the location of the unit_tests text file.  Your unit test files should be located in the unit_test directory or one of its subdirectories. 

The portfolio template contains a placeholder file with the correct name and location and an example entry.

Comments in the unit tests file shall be on a separate line and the first character of the line shall be a semicolon. 

You can use the test_verify.sh script to check your summary file.  The syntax is
    ./test_verify.sh   <summary file name>
This script must be run from the unit_test/ directory of your portfolio.

Other Testing

For this project, you are not required to modify your sequence diagram tests to be compatible with the new design.  Note that your sequence diagrams and scenarios DO need to be up to date.

3) Implement Dispatcher:

First you must implement in Java your improved elevator system. 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. Especially, make sure you 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. 

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 and unit test summary file, and improved dispatcher code.

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 previous projects, except of course everything for this assignment will be placed in a project9 directory.   By this point in the semester you know the drill...

Make sure everything in your project is updated and consistent across the entire design. Pay attention to what the course staff has told you in the lectures, recitations, office hours, and in the feedback from previous projects, and address the issues they point out.

In addition for this project you must include:

Grading Criteria:

This project counts as one team grade. Points are assigned as follows:

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