18-649 Project 5

Please submit all project-related correspondence to 

• Dated entries will be added here if the project is modified after it is released.
  

Assignment:

1. Each controller shall extend the simulator.framework.Controller class.
2. Each controller shall be places in the simulator.elevatorcontrol package.
   
3. Each controller shall use the network and physical interface objects provided in the Controller super class and no other network connection objects.
4. Each controller shall receive, at most, one physical input and generate, at most, one physical output.
5. Each physical message shall be sent by, at most, one object and received by, at most, one object.  For example, if your DriveController listens to the DriveSpeed message, your Dispatcher may NOT listen to DriveSpeed messages as well.  If your DriveController sends Drive Framework messages, your Dispatcher may NOT send Drive Framework messages as well.
6. Each controller shall receive and send network message according to the interfaces defined in the Elevator Behavioral Requirements document.
7. You may not create additional communication channels of any kind between the controllers.  This includes creating shared references to static/global variables and any method where a controller may directly modify the state of another controller.  If you are in doubt as to whether something you are doing violates this requirement, consult a TA in office hours.

In addition to the above:

• All Java files you write must be placed in the simulator.elevatorcontrol package. 
  
• You may implement additional utility classes in simulator.framework.Controller (e.g. the Translator classes), provided that these do not create an additional communication channel between the controllers.
• You must submit ONLY the Java files that your team has written.  You must not submit the entire code tree.
• Your code must be compatible with the latest required code release.  (Note the details of this in the bug handling policy).

• Although you are going to be able to define your own bit-level message payloads, you are still required to adhere to the message dictionary and interface requirements we have provided.  This means that you may not do any of the following:
• Add more information (e.g. another variable value) to a message that has already been defined
• Define a new message.
• Use a message for a purpose other than its stated purpose.
• If you violate these constraints, it will result in a significant point deduction.
  
• Regarding CAN payload translators and message IDs, the acceptance tests for this project will be run on a simulated CAN bus with 'infinite' bandwidth, so performance and message prioritization will not be an issue.  For this project and the next project, it is acceptable to use the CanTranslators and CAN message ID's that we have provided.  There will be a project later in the semsester where you will deal with optimizing the network performance.

For example, on the line of code that corresponds to the DC.1 transition on your Drive Controller statechart traceability matrix, you would add the comment:

//#transition 'DC.1'

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.

In order to ensure that you have traced all your arcs, you will add an entry to the Statecharts to Code Traceability file (traceability/sc_code.html in the portfolio template)

Controller Name (e.g. DoorControl)
Module Author:  Module author's name
Traceability performed by:  Team member's name
Line Number    Transition #
Line Number    Transition #
....

You may use a table or other basic formating to organize this information. The line number refers to the line that the comment appears on.  Line numbering shall include empty lines.
Hint:  the following linux commands may help you generate some of the required output:  
        nl -b a Dispatcher.Java | grep "#transition"
where Dispatcher.Java is the name of the controller Java file.

Someone other than the person who authored the module must generate this check and verify that every transition traces to the code.

Read the Unit Test section of the Testing Requirements.   Using these guidelines, create tests that exercise all transitions of your DriveControl design (i.e., all arcs on your state diagram).  Have someone other than the test author perform a peer review of the test.  Execute the test.  Record the peer review and test results in the Unit Test Log in your portfolio.

Team Design Portfolio

The portfolio you submit should contain the most up-to-date design package for your elevator system organized into the following directories.  You are going to update your portfolio every week, so be sure to keep an up to date working copy. 

Files that you should update for this week are:

• Portfolio Table of Contents (as needed)
  
• Scenarios and Sequence Diagrams
• Improvements Log
• Requirements II
• Sequence Diagrams to Requirements Traceability
  
• Requirements to Constraints Traceability
• Elevator Control Package (be sure to include a complete, compilable submission in the elevatorcontrol folder)
• Issue Log
• Statechart to Code Traceability
  
• Unit, Integration, and Acceptance Test Logs (be sure to include all relevant input and output files from the tests)
  

Ensure your design portfolio is complete and consistent.

• Changes requested by the TAs in previous projects have been applied.
• All required documents are complete and up-to-date to the extent required by the projects (you do not need to update files or links related to future projects).
  
• All documents include group # and member names at the top of the document.  (This includes code, where this information should appear in the header field)
• Individual documents have a uniform appearance (i.e., don't look like they were written by 4 individual people and then pieced together)
• The issue log is up to date and detailed enough to track changes to the project.

Handing In Results

Each team shall submit exactly one copy of the assignment.

Follow the handin instructions detailed in the Project FAQ to submit your portfolio into the afs handin directory (/afs/ece/class/ece649/Public/handin/project5/group#/ontime/).

Be sure to follow ALL the portfolio guidelines detailed in the Portfolio Layout page.

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).

Grading Criteria:

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

105 Points Total. (135 points possible with bonus) Grading will be as follows:

•  40 points for creating the four modules listed above (DoorControl, DriveControl, CarButtonControl, HallButtonControl).  Each module is worth 10 points.  You will lose points if your controllers do not meet the requirements specified in the project.
• 15 points for passing the three acceptance tests or documenting the bugs that prevented the elevator from passing the tests. We will recompile these four modules before running the acceptance tests for grading.  For the other control modules (Dispatcher, LanternControl, and CarPositionControl) you may use the .class files we provided with the code (you will be writing these modules in the next project stage).   We do not expect perfection, but to pass the test, your elevator must 1) deliver all the passengers and 2) not activate the emergency brake.
• 10 points for the traceability exercise
• 10 points for testing one sequence diagram.   Include in your submission the test files you used to do this and the output of the test.  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.  Also remember to have the test peer reviewed.
• 10 points for unit testing the DriveControl object.  Include in your submission the test files you used to do this and the output of the test.  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.  Also remember to have the test peer reviewed.
  
• 15 points for the complete design package.  You should include all scenarios, sequence diagrams, requirements, statecharts, traceability etc. that you have done up-to this point.  These materials should represent the most up-to date version of your elevator system, including all changes you have made (which should be tracked in the issue log).
• 5 points for an entry in the Improvements Log that tells us what can be improved about this project. If you encountered any minor bugs that we haven't already addressed, please mention them so we can fix them. If you have no suggestions, say so in your entry for this project.
• Bonus:  30 points for passing two acceptance tests run by the TAs.  To be eligible for the bonus, you elevator must also have passed the three acceptance tests given in the assignment and you must have made a non-trivial effort on all the graded portions of the project above. 

Back to course home page