Elevator project for 18-649.

Please submit all project-related correspondence to

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

Now you will implement the checks you described in part 1.1 above.  Add a new class to the simulator.elevatorcontrol package called Proj11RuntimeMonitor.  Be sure you use the right name because the monitor may be graded by an automated script that relies on this name.  Make sure Proj11RuntimeMonitor extends simulator.framework.RuntimeMonitor.

• Your runtime monitor must clearly demonstrate that it has no false negatives: if there is a violation of any of the high-level requirements, the violation must be detected and your verifier must clearly indicate which requirement was violated. 
• Your monitoring code must belong to the simulator.elevatorcontrol package (the same directory as your other code) and be called Proj11RuntimeMonitor.  You must include the code in the elevatorcontrol/ folder of your portfolio and fully link and document all Java files in the package.html file, just like all the rest of your code.
• Your monitor must be a subclass of the simulator.framework.RuntimeMonitor class.
• Your monitor must check each high level requirement and generate a warning (using the provided warning() class in the RuntimeMonitor parent class) if any high level requirement is violated.  The warning must name the requirement that was violated and give a descriptive message of how it was violated.  For example , "R-T.6 Violated:  Car stopped at floor 5 FRONT when there were no pending calls."

If your monitor does more than monitor the system (e.g. outputs any framework or network messages, or affects the simulation state in any way, you will receive significant deductions on the final assignment.

It is acceptable for your monitor not to throw warnings during startup, but it must register any violations of the high level requirements that occur after the elevator has moved for the first time.

In order to verify that your design meets the requirements, we will run your elevator against our own runtime monitor.  Although the grading monitor is not provided, you will receive the output of our tests in your project feedback.

Execute at least the following acceptance tests using the runtime monitor.  Log the tests, the test results, and any comments in the High Level Requirements Verification page of your portfolio.

• proj10acceptance1.pass
• proj10acceptance2.pass
• proj10acceptance3.pass
• proj11acceptance1.pass
  
• proj11acceptance2.pass
  
• proj11acceptance3.pass

• Pass all unit tests - all tests must pass with 0 failed assertions.  You do NOT have to run with the "-b 200" option.
  
• Pass all integration tests - all

  </span>tests must pass with 0 failed assertions. You do NOT have to
  

  run with the "-b 200" option.

• All acceptance tests - rerun all the acceptance tests listed below.  Be sure to use the "-b 200" option to enable the finite bandwidth setting.  You are not required to pass these tests for this project, but you must include a detailed description of the issues that are preventing the elevator from passing any test.
  
• proj7acceptance1.pass
• proj7acceptance2.pass
• proj7acceptance3.pass
• proj8group#acceptance1.pass
• proj10acceptance1.pass
• proj10acceptance2.pass
• proj10acceptance3.pass
• proj11acceptance1.pass
  
• proj11acceptance2.pass
  
• proj11acceptance3.pass

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

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

• 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/proj10/group#/ontime/).
  
• Be sure you follow the required format for the directory structure of the portfolio and its location in the handin directories.
  
• 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).

This project assignment is worth 115 points:

• 20 points for 4 peer reviews of the updated Runtime Monitor in the Peer Review Log.
  
• 20 points for completely passing all unit tests
  
• 20 points for completely passing all integration tests
• 20 points for running all acceptance tests and either passing the tests or logging the results.
• 30 points for your runtime monitor, description, and High Level Requirements Verification 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.