Revised March 18, 2008:

18-649 Project Assignment #6

More Implementation & Test

Due Thursday February 28, 2008 at 11:59 PM

Please submit all project-related correspondence to ece649-staff "at" ece.cmu.edu

Assignment:

In project 6 you will continue building your elevator system. You began coding in project 5 by building and testing four modules: DoorControl, DriveControl, HallButtonControl, and CarButtonControl. In this project you will continue working on controls, and also the dispatcher. You will implement and test: LanternControl, CarPositionControl, and the Dispatcher. You will also prepare a draft of your mid-term project presentation for review during the group meeting with the TAs on Friday, February 29, 2008.

At the end of project 6 you will be expected to give a mini-demo of your functioning code. You may begin modifying you dispatcher to have more intelligent behavior, but please remember this must be documented in your past turn-ins.

Please note this project is very similar to Project 5. You have to test an additional sequence diagram, but only one. Also, one additional unit test will be required. Please keep in mind that now is an excellent time to develop further unit tests, and you will be required to do so at a later time. Note that in project 6 you are required to design an acceptance test in step 1.

The procedure is the same as Project 5, briefly:
1. Implement 3 new controls in Java. Test these with provided and original acceptance tests.
2. Test one sequence diagram that has a control you just implemented.
3. Write unit tests for CarPositionControl.
4. Prepare a draft of your mid-term project presentation.


As a reminder, please be sure to employ defect tracking. When you test your code, you will no doubt run into errors. These errors will have many possible sources, they could simply be syntax errors in Java, but we are interested in the errors caused by problems in your original requirements and design, these are defects. When a defect is located that requires changes to earlier steps in the project, say you created a scenario in project 2 that needs to be expanded, we want you to track this. You will write in your change log the files you had to update. However, the important aspect of defect tracking is that you will also state where the problem was discovered (at this stage, probably in coding), and what previous project turn-ins had to be changed to correct the problem. By having this tracability you will be able to see where this problem was originally created.

This defect tracking file will include the above information, namely:
1. What file the error was discovered in.
2. Brief description of the problem.
3. What documents had to be updated in response.
4. First document to include this fault, and thus the source of the error.

What you need to create:

1) Implement (in Java) LanternControl, CarPositionControl, and the Dispatcher objects. These correspond to objects you have previously designed in state charts.

Things you are allowed to do:

Things you are NOT allowed to do:
(NOTE: Please refer to the Elevator Simulation API for important information on the differences between Framework and Network messages.)

Additionally, you are REQUIRED to mark the line in each code that causes each and every state transition (i.e. forward traceability) you have designed on your state charts. This marking will be accomplished with comments. So that these lines are easily distinguished from other comments, you shall begin the line with the character '#' followed by the word 'transition' followed by the transition name as described on your state machine backward traceability matrix in single quotes.

For example, on the line of code that corresponds to the A() transition on your Drive Controller statechart traceability matrix, you would add the comment: 

// #transition 'A()'

to the line in your code that actually CAUSES this transition.

This is done so that it is possible to easily check to ensure all of the arcs in your state transition diagram are implemented as you have described them.

We will provide you two acceptance test files to test against your elevator system: proj6acceptance1.pass, and proj6acceptance2.pass.  Part of your grade for this project will be based on whether or not your elevator system can pass these two tests and three others we will not provide you. 

You must also create an acceptance test of your own. This should differ noticibly from the tests we provided you. Include in the comments field the behavior or performance aspect of the elevator you are trying to test. The acceptance test file must have the extension .pass (e.g., people.pass) for the simulator to run it.

The system acceptance test file format is:

<seconds>,<start_floor>,<start_hallway>,<destination_floor>,<destination_hallway>  ;  <comment_field>

Where each line of the file creates a single passenger to appear at time <seconds>.  That passenger starts on floor <start_floor> and hallway <start_hallway>, and will behave in such a way as to go to  floor <destination_floor> and hallway <destination_hallway>. <start_floor> and <destination_floor> should be integers in the range [1...MaxFloor].  <start_hallway> and <destination_hallway> should be 0 for the front hallway and 1 for the back hallway.  Tests with this input file are run with all modules in the system loaded.  The entire system is initialized before the testing begins.  An example input for the system integration test is:

15,1,1,3,0    ; person A going up
15,7,1,1,1    ; person B going down

Which means that at the same time, t = 15, two people show up, 1 person on the 1st floor back hallway wanting to go to the 3rd floor front hallway, and 1 person on the 7th floor back hallway wanting to go down to the 1st floor back hallway.  Keep in mind that certain floors do not have certain hallways, and if you mistakenly assign people to hallways that do not exist, they are likely to get stranded in the elevator or may not get on the elevator at all!  Here is the hoistway setup.  Keep this handy when making your integration tests.

Floor #
8 FH
7 FH and BH
6 FH
5 FH
4 FH
3 FH
2 BH
1 FH and BH

2) Write tests to informally test one sequence diagram from project 2.  The sequence diagram you choose must concentrate on one or more of the three control objects created in this project (Dispatcher, LanternControl, CarPositionControl).  For example, it should have at least one input arc and one output arc for one of those three objects.

The assignment is to generate a set of files that are sufficient to completely test one sequence diagram from project 2.   Although this is not exactly "unit testing"  (see project step 3 below), you will use the unit test file format as outlined in section 3 to test the sequence diagram.   We're going to leave the details of how to accomplish things to you, but to be correct a test must somehow address all the below points:

3) Write unit tests to informally test the CarPositionControl statechart. 

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

Unit test for this project means testing the behavior of a single system object such as a door controller or the dispatcher.  These tests are derived from the system design, and should completely cover all states and transitions in your state diagrams to ensure that code that is written actually implements the intended design.

The general format of the system implementation will be that there is 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've designed in previous assignments; we're responsible for implementing and testing objects we provided complete requirements for back in Project #2 as well as the simulation framework.  You do not have to provide tests for the objects we're providing to you.  For this particular assignment you will only design tests for the CarPositionControl object.  However, you will be required to produce similar tests for the other objects in future projects.

We will be providing a special diagnostic object to you which has the purpose of taking a plain text file describing messages to be sent on the network and actually sending them out on the network at specific times.  This diagnostic object also records all network messages and places them in an output file.  If you put this diagnostic object and one or more other objects into the system framework you can run single-module tests by sending specific messages at specific times and observing that correct outputs are produced.

The unit test file format is the following:

<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 your CarPositionControl design.  Each file can test more than one thing, but ideally tests are shorter rather than longer. We're going to leave the details of how to accomplish things to you, but to be correct a test must somehow address all the below points:

CLICK HERE FOR AN EXAMPLE TEST FILE.

4) Create an acceptance of your own.
Create an acceptance test of your own that differs noticibly from the tests we provided you. Include in the comments field the behavior or performance aspect of the elevator you are trying to test. The acceptance test file must have the extension .pass (e.g., people.pass) for the simulator to run it.

5) Prepare a draft of your mid-term project presentation.
Each team will prepare a draft of their mid-term project presentation for review during the group meeting with the TAs on Friday, February 29, 2008. The expectations for the project presentation are outlined in Lecture 13.  The presentation can be either in PDF format or a Microsoft PowerPoint presentation.
To receive full credit, the draft of your project presentation must contain the following content:

Team Design Portfolio: 

 

Each team shall maintain a design portfolio to organize all materials for the design package of its elevator system.  You are going to update this portfolio for every weekly assignment, so it is worth investing some time now to get things organized and easy to maintain. 

 

1) Organize your design portfolio.

Your project6 directory should contain the most up-to-date design package for your elevator system organized into the following directories.  This directory structure will develop as the semester progresses. This is to organize things for the rest of the course -- you'll be keeping this same organization and updating things for each subsequent project phase.

2) Ensure your design portfolio is complete and consistent.  If you have been keeping up with updates in the previous project stages, most of this work will already be done. The following is a partial list of the characteristics your portfolio should exhibit:

Handing In Results

Each team shall submit exactly one copy of the assignment. Also, please compile all of your group member's work into one HTML document.

Please submit your JAVA files for this weeks three modules in addition to your previous four modules. These previous modules can be modified from your last submission, but please be sure to turn in a copy of all four of the modules.

Please include at the top of each file the assignment number, your group number, the names of your group members, and the file name.

Any submission that contains files with modification dates after the project deadline will be considered late and subject to a grade deduction (see course policy page for more information).

Submission shall be electronically in the form of a web page with text and in-lined images. Please use "plain-vanilla" HTML so that the web page is easily viewable and printable from Internet Explorer and Firefox. Any drawings shall be in non-animated GIF format. (You can use other graphics formats at your own risk, but we must be able to view them in the web browsers mentioned above). You can also submit your project in pdf format, but make sure it prints correctly and legibly on 8.5"x11" paper. Projects shall be submitted by copying all needed files into your group's directory in the course AFS space in the following directory: /afs/ece/class/ece649/Public/project/group#/project#/ (group# is your group number and project# is the number of this project. You might need to create the project# directory yourself). Any submission that contains files with modification dates after the project deadline will be considered late and subject to a grade deduction (see course policy page for more information). So don't over-write the files after the deadline! A regular text editor should be sufficient for this assignment - you may want to make the traceability tables in Excel or Word and use the 'Save as HTML' or 'Save as Web Page' feature in the File menu. If you need some help with HTML please come to Office Hours :)

Additionally, the result should be easily readable when printed on a black-and-white laser printer. Each HTML file AND picture shall include the team number and names of all members of the team.

Grading (90 points):

This assignment counts as one team grade. If you choose to divide the work, remember that you will be graded on the whole assignment.

Note: To receive full credit for the assignment the test files you create must be formatted correctly and  fully commented to explain what they are doing.

Back to course home page