18-642 Project 7

Updated 8/28/2022. Changelog

Learning objective: Take a high level design, create a statechart, and create code to go with the statechart.

Do NOT modify your code until AFTER you have updated your statechart. Doing code first then updating statechart completely undermines the learning objective for this project.

For this project start with the material from the previous project (Requirements and Sequence Diagrams) and finish the design flow through to code. We want you to do a more rigorous design process including: product requiremnents, sequence diagrams, statecharts, code, and traceability.You should re-use the design materials from the previous project as a starting point, but you should be updating those materials to match where you end up with your statechart and code. You'll be carrying this new design forward for the rest of the project phases, so it's worth your while to get it right.

This project spans extra time (about two weeks). We are assigning it as a two-week chunk to give you more mid-semester time management flexibility as you complete work for other courses. We strongly recommend you try to get ahead and take a first pass through as much as you can on week 1 so you don't have a time crunch on week 2. But, if you are overwhelmed with another course it's up to you how you prioritize and manage your time.

Lab Files:

Hints/Helpful Links:

Procedure:

(It is expected you will iterate across these procedural steps as you refine your design.)

  1. High Level Requirements: Re-use high level requirements from the previous project as a starting point. You shall update these to match any changes you make.
  2. Sequence Diagrams: Re-use sequence diagrams from the previous project as a starting point. You shall update these to match any changes you make.
  3. SD to Reqs Traceability: Re-use the traceability table from the previous project as a starting point. You shall update these to match any changes you make.
  4. State chart: Draw a state chart for student_turtle based on the sequence diagrams and high level design in general. (If it makes sense to break the design down into multiple state charts that is OK. Make sure each statechart has unique labels and numberings for traceability.)
    1. Define the inputs, outputs, and internal variables in a table:
      Example:
      Name Type Range Description
      bumped input {TRUE, FALSE} Tells the turtle whether it has just bumped a wall
      move output {turn_left, turn_right, move_forward} The next move the turtle shall make
      ... ... ... ...
    2. Follow the conventions set forth in class to make a state chart. In particular, all output variables you described in the table must have an output at all states, and transitions shall only occur on checks on input variables or internal variables defined in the table. Make sure the initial state is indicated with an arrow, and that all states and transitions are numbered. You are allowed to use sub-states if it makes sense for your design. (Look up a tutorial on advanced state chart notation if you like.)
  5. Compute Functions: If you used a compute function of some sort in your sequence diagrams, then that compute function should be showing up as a truth value that is the result of a function call in your statechart (e.g., as a guard condition). For all such compute functions create an appropriate design description. Depending upon the compute function this might be a state chart, a flowchart, control equations, or a pseudocode algorithm. Each compute function should have its own design. (If there is no compute function of this type simply say "no compute function" and you will receive full credit assuming that statement is actually true.
  6. High Level Reqs to Statechart Design Traceability: Perform traceability of requirements to statechart and compute function using a table. (If you have multiple state charts use either one bigger table or multiple smaller tables to trace all of them.) Each state and transition shall be a row in the table (compute functions should be one or more rows as well), and each requirement shall be a column:
    R1 R2 ..
    S1 x
    S2
    ..
    T1
    ..

    Because your requirements are product-level requirements, and your statechart is low-level design, it is possible that a requirement might trace to more than one state or vice versa. That is allowed and expected, as long as you achieve full traceability: each row and each column must have at least one cell checked off. If a row has zero cells checked off, that means the corresponding state or transition does not meet any requirements and is extraneous. If a column has zero cells checked off, that means the corresponding requirement is not being fulfilled by any states or transitions. Revise your requirements and statechart until you achieve full traceability. (If there is a compelling reason not to have full traceability, explain specifically why.)
  7. Implementation: Implement your design (i.e., statechart + compute function(s)) in student_turtle.cpp
    1. Your top-level statechart implementation shall be a function in ANDREWID_student_turtle.cpp, which shall contain a switch statement with cases for every state. Since your statechart implements the turtle movement logic, no part of your statechart implementation shall be in student_maze.
    2. Define a current state variable, and use a switch statement to switch between current states. (For the following writeup items, we use the term "the state's block" to refer to the case of the switch statement that handles the current state.)
    3. Make sure all outputs are being set in all state blocks.
    4. Put transition logic at the end of the state's block. This should check internal variables and input variables and set the current state variable accordingly.
    5. Comment each state and transition with its label ("S1" or "T1") in the code. You will be graded on the traceability of statechart to code, so make sure you have an accurate label for each state and transition.
    We highly recommend that you write this implementation from scratch, instead of manipulating your existing student_turtle code. This way, it will be clear that your turtle movement code implements your statechart.
  8. System Test: Verify that your implementation works on mazes m1-m3. Remember you can run the code with a given maze file by providing it as an argument to build_run_turtle.sh: ./build_run_turtle.sh [mazefile]
    to give some time management flexiblity, this code shall compile and execute, causing the turtle to move at least one square. It shall also conform to the statechart. HOWEVER, if it does not actually solve the maze you will still get full credit for this project. (You'll want to fix that in the next project phase, and we suggest you try to fix it now, but this prevents there being an all-nighter debugging session between you and a hand-in. Caution -- if you take this as license to ignore writing code and ignore fixing mistakes in your algorithm/design the next project phase will have a high workload.)
  9. Writeup: Answer the following questions in a writeup:

Project Handin Checklist:

Other requirements:

The rubric for the project is found here.

Change log: