18-642 Project 12

Updated 11/21/2021. Changelog

Learning objective: revisit the entire build package and "ship" the final product.

This project wraps up the ece642rtle you have been working on all semester.

• It is a stupendously bad idea to wait until the last minute on this project. Seriously -- worst idea ever.
  • If you submit past the late hand-in deadline on the course web page we will assign you an "Incomplete" course grade due to limited TA availability to grade your project. If you are expecting to graduate this semester it would be a really bad idea to test that boundary.
• THIS PROJECT COUNTS DOUBLE (i.e., this is in effect a double-size project, and the project score will be counted as two project grades in weight).
  • If you've been borderline on projects, this is your chance to take the time to get a perfect score and bring up your grade with a double-weighted project.
  • You can use your one "free late" on this project if you wish to do so, and it will apply to the entire project grade even though it is doubled.
• Make sure your build works! Test it on a clean VM right before you hand in. There is no such thing as a change to the code base that is so small you don't need to re-run ALL tests.

Lab Files:

• Project 11 maze files

Hints/Helpful Links:

• $ECE642RTLE_DIR refers to ~/catkin_ws/src/ece642rtle (or corresponding project workspace).
• Please follow the handin naming convention: every filename (before the file extension) must end in [FamilyName]_[GivenName]_[AndrewID].
• See the Recitation video and slides on Canvas

Procedure:

1. Get all the mazes working
   • You must solve all mazes to get full credit. Note that inability to solve one or more mazes can affect your course grade over and above just this project grade. See course grading policies.
   • As you change your software, be sure to keep the design package updated. Depending on how you've done on previous projects your code might already be solving mazes. But if you failed to update your design package, that's where technical debt comes back to bite you.
   • Really the mazes are being used as acceptance tests. Each maze is one acceptance test, so you need to pass all ten acceptance tests for full credit. An acceptance test for maze k only passes if ALL of the following are true for that maze k:
     • The turtle traverses from start to end squares by following the maze solving algorithm you created.
     • All monitors are enabled during the entire run and actually enforce the required invariants.
     • The monitors do not detect any invariant violations.
     • The code has built clean without warnings. Yes, this means getting a high grade in the course requires you to resolve all compiler warnings in this project.
2. Clean up design package.
   1. This is where your technical debt comes home to roost. You need to ensure that your design package actually matches your final code when releasing a design to production. That applies to all the following items listed.
   2. High level requirements for Turtle. Updated? Match rest of design?
   3. Sequence Diagrams for Turtle interacting with maze. Updated? Match rest of design? (Updating them to include interaction with monitors is not required for hand-in.)
   4. Statecharts for Turtle. Updated? Match rest of design?
   5. Materials in release candidate (e.g., comments in code that trace code to statechart), including:
      • Turtle source code
      • Maze source code
      • Monitor source code -- all monitors working?
      • Scripts
      • Unit tests -- do they still achieve coverage required by previous projects?
   6. Peer review logs for your work starting with project 6. All status fields showing resolution of the issue (in some cases resolution is "not a defect" or "feature request").
   7. Note that in a commercial production system you'd also be responsible for requirements SDs, and statecharts for the maze code, the monitors, and potentially also unit tests. We're skipping those in the interest of managing the workload.
3. Create a final release candidate
   1. Make sure that everything you need is included in the submitted release candidate tar ball, the same as you have been doing for several projects now.
   2. Make sure your build script does the following:
      • Does any setup required to run ROS in a clean virtual machine
      • Compiles all source code with wall relevant warnings from previous projects enabled. If you have suppressed or failed to enable any warnings or have any unresolved warnings you must clearly state that you did not resolve all warnings in your writeup.
      • Runs all unit tests and fails hard if a unit test fails (i.e., if a unit test fails the system does not complete the build script successfully). If you are unable to meet this criterion, then you must clearly state that you have unit test failures in your writeup.
      • Sets up system so that the maze script can run successfully. The build script is only run once when bringing up the system.
   3. Make sure your maze run script does the following:
      • When maze "k" is used as a parameter, runs that maze
      • All run-time monitors are enabled for the entire maze run
      • Any invariant violations are displayed; if no invariant violations have occurred, then it is both obvious and trivial for a grading TA to determine this has happened without scrolling through any logs or screen history. If you have any known invariant violations you must clearly state this in your writeup.
   4. For grading the TA will run the build script and run the maze script on all 10 mazes m1..m10, not necessarily in that order. TAs may, at their discretion, run some mazes multiple times to ensure absence of defects related to race conditions.
4. Writeup: Do a final check that the turtle solves the mazes, and a final check that your testing and documentation is up to date. Document items shall conform to the requirements of previous projects regarding coverage and completeness. Include the following in a writeup:
   • Your name. (If the writeups are printed out, the file name info is lost, so put your name and Andrew ID in the document text as well)
   • Q1: Final High Level Requirements
   • Q2: Final Sequence Diagrams
   • Q3: Final Statechart(s) for Turtle
   • Q4: Statement regarding compiler warnings. Does your code generate any compiler warnings with the earlier project warning set? If so, which types?
   • Q5: Statement regarding monitor failures. All working? If not, state which ones fail for which mazes.
   • Q6: Peer review logs. Show logs for your code from Project 6 and later. Status must be completed for all issues.
   • Q7: Maze solutions. Screen shot of all maze m1 .. m10 runs. For each maze include in the screen shot both the maze picture after the turtle has reached the end square and a window showing whether invariant violations occurred. If your turtle does not solve a maze show the degree to which it makes progress in a reasonable way.
   • Q8: Statement regarding maze solutions. Which mazes does your handed-in code solve?
   • Q9: What one software engineering process or practice from Projects 1-12 do you think is the most important one to apply to your own work beyond this course, going forward?
   • Q10: Any feedback about Project 12, or any other projects?

Handin checklist:

Hand in the following:

1. A release candidate build file: ANDREWID_P12.tgz
2. Your writeup, which should be in a single acrobat file called p12_writeup_[FamilyName]_[GivenName]_[AndrewID].pdf

Other requirements:

• Use the usual project naming conventions with a prefix of "p12" for items other than source code.
• The writeup shall be in a single acrobat file for ease of navigation.
• Fonts for all diagrams and text shall be rendered at no smaller than 10 point font. Smaller fonts will require a resubmission

Zip the files and submit them as P12_[Family name]_[First name]_[Andrew ID].zip.

The rubric for the project is found here.

Changelog:

• 6/28/2021: issued
• 11/21/2021: changed hand-in zip file name for consistency
• 10/20/2023: updated with font size requirement