Be sure to look at the Canvas Module for this week for various hand-in mechanisms!

### C12 In Class Exercise: Test Design

Consider the following arbitrary code:

```int32_t TestFunc(int32_t a, int32_t b, uint32_t x)
{ int32_t res;
res = a * 2;
if( b > 20)   { res = a+1; }
else if((x == 7) || (a == 3))   { res = a-100; }
else if( (a < 10) && (b < 16))
{ res = x+17; }
else
{ res = 42; }
return(res);
}```

Create unit test values to achieve the following objectives. For each unit test list the following in a row (bullet or table row as you prefer):
Test objective, a, b, x, res.
For example: MCDC1 a=99 b=99 x=99=> res=99

• Set of tests that achieves complete MC/DC coverage. (Label tests: MCDC1, MCDC2, MCDC3, etc.)
• Boundary value tests for minimum and maximum values for which the input "a" returns valid results (Label tests: BA1, BA2, etc.)

It is OK to divide up testing across the group, but everyone in the group should review the correctness of the tests before submitting the slide.

Supplemental Materials:

### C13 In Class Exercise: Statechart Exercise

This is a GROUP exercise. Complete it using your ASSIGNED groups. Create a statechart for a maze-solving robot with the below properties. Be sure that your statechart has an initialization arc, a number of states, an action for each state, and guard conditions on each transition. It is OK to hand-draw the statechart and take a picture of it, or use any other convenient method that results in an acrobat file, a powerpoint file, or an image file (e.g., JPG).

Consider a maze-solving robot that uses the left-hand-rule approach to solving a maze. A person using this rule would extend their left hand and walk while keep it touching the wall at all times, turning as required to follow the wall.

However, our turtle-bot doesn't have a "left hand," and instead only has a front bumper. We assume that the front bumper can detect the wall without the need for the turtle bot to actually move (for example, it is a single forward-facing ultrasonic distance sensor with a range of less than one square size). Thus, implementing a left-hand-rule approach requires a step of turning left to see if the wall is there, and then either proceding or turning again depending upon whether the wall was sensed.

The turtle bot has the following movement capabilities. These are the ONLY permitted actuator outputs that can be set by states in the statechart. The system can only perform one action per time step, and can only be in one state per time step. (This is a fully synchronous state machine, with the time step equalling the time taken by the robot to turn or move, which we assume is the same for each possible action.)

• LEFT: Turn left 90 degrees
• RIGHT: Turn right 90 degrees
• MOVE: Move forward one square in a maze grid
• STOP: Stay still

The turtle bot has the following input sensing capabilities:

• BUMP: Detect whether a wall is immediately in front of the turtle. Possible values: {true, false}. It is preferable to assume that the BUMP sensor is measured after any turn or movement has been performed in that movement cycle.
• GOAL: Detect whether the turtle is in the goal square (i.e., maze goal has been reached): Possible values: {true, false}

Solving a maze is subject to the following constraints:

1. The maze is an NxM size rectangular grid, for example like a chessboard.
2. You have no information as to where in the grid the turtle starts, and where in the grid the goal square is. (This means you have to book-keep movement and you can't exploit any knowledge about where the rest of the maze might be.)
3. Each statechart transition takes one time step, including same-state default transitions.
4. The turtle is only permitted to make exactly ONE of its listed movement capabilities at each time step. It should correctly process both input sources at each time step.
5. Maze walls are between squares. This implies that each square is surrounded by 0, 1, 2, 3, or 4 walls. (If trapped inside 4 walls, movement is not possible.)
6. The turtle displays movements in keeping with the left-hand-rule approach to maze solving.
7. The turtle must stay still once it has reached the goal square

The output of this exercise should be a well formed statechart. Do NOT write code to implement the statechart. Paste the statchart onto a slide:

• File name: C12_Group##.ppt (or .pdf, as appropriate). For example, in-class exercise group #5 would be C12_Group05.ppt. Please use this naming convention of C## for Class Exercise # and Group## for Group number in future in-class assignments.
• It is OK to take a photo of a hand-written or other diagram and paste it into the statechart for in-class exercises. Drawing tools are highly recommended, and in some cases required, for homeworks and project work.

Here's a video showing how the turtle should move. (View directly on YouTube here: https://youtu.be/xifVOQs9ZEc )

### HW #10: Global Variables

(Be sure to list citations for references you use as a source for answers. If multiple references say the same thing, you need to only give one of them as a source.)

10-1. Consider a situation in which a variable is declared as a global (e.g., variables in the Project 2 student function starting code).

• 10-1a. (1 point) Assuming that they are only referenced in the .c or .cpp file in which they are defined, how do you change global variables from global to file static variable without breaking the code? (This is not a trick question. Were you awake watching the lecture? If so you know the answer.)
• 10-1b. (3 points) Assuming we're talking about a large, safety critical industry embedded system, give 3 reasons why it is good practice to change a global to a file static or local static variable even if the compiled code is going to be absolutely identical. (1 point per reason)

10-2. Look up the implementation for the min() function in the C library for a typical Unix system. (Hint: it's a macro -- find the macro definition. If it's not a macro, that's not the function you're looking for.)

• 10.2a. (1 point) Give the definition of min() you found and cite the source (URL is fine).
• 10.2b. (1 point) What is an argument that using a macro is a good idea for this function?
• 10.2c. (1 point) What is an argument that using a macro is a bad idea for this function?
• 10.2d. (1 point) How does using the macro affect cyclomatic complexity? Why?
• 10.2e. (1 point) Is the min() macros' effect on cyclomatic complexity a good thing or a bad thing? Why?

10-3. Give one or two-sentence answers to the following questions:

• 10-3a. (1 point) Let's say you have a function that takes 25 input parameters. When is it OK to pass those parameters via globals? Why?
• 10-3b. (1 point) You have a global array of 100 elements. Should that be counted as 1 global, 100 globals, or something else? Why?
• 10-3c. (1 point) You have a struct with 100 different named elements. Should that be counted as 1 global, 100 globals, or something else? Why?

Supplemental Material:

### HW #11: Stack Overflow

No homework for this lecture.

Supplemental Materials: Lecture: Stack Overflow

### HW #12: Unit Testing

Note: We teach cunit because it is more commonly supported on smaller embedded systems. For this homework you can use GUnit or other reasonable notation if you prefer. However, the course staff does NOT provide support for GUnit, so use at your own risk.

12-1. Two important concepts in black box testing are equivalence classes and boundary values. For this question consider an absolute value function:
int16_t abs16(int16_t i) { return (i < 0 ? -i : i); }

• 12-1a. (2 points) We discussed boundary values in class. Give a concise definition of an equivalence class (paraphrase; cite your source)
• 12-1b. (4 points) For purposes of black box testing, there are 4 equivalence classes for the above procedure abs16(). List the four classes using a concise English description.
• 12-1c. (4 points) List the boundary values for each equivalence class identified in the previous question.
• 12-1d. (8 points) Using "cunit" notation as shown in class, list a set of tests for abs16 that checks for correct calculation results for all boundary values and for each equivalence class that has more than one value, also includes an arbitrarily picked representative non-boundary value. This should total 8 tests. (You do not have to compile & run; we'll use cunit in the project later.)

12-2. Consider testing the following code:

```int16_t baz(int16_t a, int16_t b) { int16_t res = 0;   if((b < 6) && ((a < 27) || (b > 87) || (b == 52)))
{ res = b;
} else
{ res = a;
}
return(res);
} ```
• 12-2a. (5 points) Make a truth table to show the combinations for the four conditions that need to be tested to attain 100% MCDC coverage. (Columns should be condition clauses; rows should each be a required set of test values.) Note that this is NOT all combinations for true/false for each condition, but rather just the minimum necessary set for 100% MCDC coverage. If you want to show all rows and then indicate the rows needed for MCDC testing that's OK.
• 12-2b. (5 points) Using "cunit" notation list sufficient test cases to obtain 100% MCDC coverage. (Note that you do NOT need to exercise both boundary and non-boundary values. Just identify test cases for MCDC coverage.

12-3.Consider testing the following code:

```int16_t bar(int16_t a, int16_t b) { int16_t res = 0;   if((a > 3) && (b < 112))
{ if (a == 42))
{ res = b;
} else

{ res = a;
}
} else
{ res = a-b;
if (a == 2 && b == 2)
{ res = a+b;
}
}
return(res);
} ```
• 12-3a. (5 points) Make a truth table to show the combinations for the conditions that need to be tested to attain 100% MCDC coverage. (Columns should be condition clauses; rows should each be a required set of test values.) Note that this is NOT all combinations for true/false for each condition, but rather just the minimum necessary set for 100% MCDC coverage.If you want to show all rows and then indicate the rows needed for MCDC testing that's OK.
• 12-3b. (5 points) Using "cunit" notation list sufficient test cases to obtain 100% MCDC coverage. (Note that you do NOT need to exercise both boundary and non-boundary values. Just identify test cases for MCDC coverage.

Supplemental Material:

### HW #13: Modal code and statecharts

13-1. Consider the maze-solving robot in the statechart class exercise from this week, shown above. That robot solved mazes using a left hand rule. Your team result might or might not have had a correct or clean solution in the limited time available in class. In this homework you'll get to try again ON YOUR OWN to create a statechart for a robot with the same rules EXCEPT you will create two variants: one with a left-hand-rule and one with a right-hand-rule maze solving heuristic. For the right-hand-rule turtle, the path taken to solve the maze shall be the path that would be taken by a person using their right hand to follow the maze wall until the goal is reached. While you obviously got ideas for maze solving from the class discussion, start with a clean sheet of paper (electronic or otherwise) for this homework, and make your own drawing yourself. If you missed lecture, it's OK to ask another student in class to show you their group's solution, but don't just copy it. The point of this homework is to make sure that you can do this on your own, without someone helping you. (I.e., did the knowledge from the class exercise actually stick?)

• 13-1a. (2 points) Find a statechart software drawing tool to use for this homework question and tell us which one you used. There are a number of web-based tools. (See supplemental reading section.) Hand-drawn statecharts and freehand paint programs are NOT acceptable. While you can use powerpoint, we suggest trying to find something that is smarter about manipulating boxes, arrows, and so on. (The point of this question is for you to get some familiarity with available tools, even though we realize that the tool learning curve might take more time than drawing by hand.)
• 13-1b. (10 points) Define and draw the states for the robot. Hint: start with a "goal" state, add a "move" state, and go from there. Add additional states that might be needed to keep track of history. Draw a state diagram with each state causing a particular robot behavior to be performed for one time unit/one "step" of robot movement. Partial credit will be awarded at TA discretion.
• 13-1c. (10 points) Add arcs to your statechart to fully define left-hand-rule behavior. Each arc guard shall be specified, and should be either "true" (always executed) or based on the state of one of the sensor inputs (e.g., bump). Partial credit will be awarded at TA discretion. Make this drawing of both states + arcs separate from the answer to the previous question part (on a separate slide) for grading purposes, even though it will be the same states.
• 13-1d. (4 points) Re-draw the statechart for right-hand rule behavior. This means you'll have three slides in a sequence: just the states; left-hand-rule; right hand rule, and they should differ ONLY in the arcs.
• 13-1e. (1 point) How many arcs did you have to change for right-hand rule behavior? How do you think this experience compares with changing the project code (or will compare, depending upon whether you've made that change to the project code)?

• Give every state a number/identifier (S1, S2, etc.) and a name (IDLE, etc.). For example: "S1. IDLE"
• List side effects for every state. Side effects such as output values and changes to state variables are unconditional.
• That means each state has the same side effect all the time rather than a side effect based on some condition. (If you have a conditional assignment, you need to add more states to get rid of the condition.)
• It's OK to have unconditional algorithmic side effects. That means "add one minute to alarm time" is OK, but "add one minute to alarm time if button is depressed" is not OK, because the "if" makes it conditional. If you want a conditional effect you need to break the true/false conditions into two different states.
• You can have either comparisons or a "true" guard for arcs, but no side effects on arcs. (i.e., it's a Moore state machine).
• Note that if an exit arc has a "true" guard condition the system will remain in the originating state for exactly one periodic cycle, and exit for the next cycle.
• You can omit "stays in same state" arcs if they are uninteresting since the default is to stay in the same state.
• Here are some style rules to keep everyone on the right path:
• You may NOT add additional 1-bit or boolean state variables. We want you to make one big statechart so you can get the hang of working with medium-large statechart, even though in practice you might break this into parallel statecharts.
• You may NOT use an enum or equivalent for encoding state information EXCEPT for state information explicitly represented in the statechart. (i.e., the enum should correspond to the states you're drawing in the diagram -- no hidden, undrawn states buried in an enum).
• It is OK to test for equality/inequality of state variables that have more than 1 bit of value.
• If you need to create a holding variable for a more or less continuous value of state value (e.g. X or Y position in the maze) that's OK. But do this to support computations, not hide states from the statechart.

13-2: Take a flowchart and convert it to a statechart

• 13-2. (10 points) convert the flowchart shown in Figure 5(b) of US Patent 7579964 B2 into a statechart. Don't worry too much about the details of the patent. This is describing a parking meter and that's pretty much all you need to know. Follow these modifications to turn it into more of an ordinary parking meter:
• "Issue Summons" and "update file" should be collapsed into a "METER EXPIRED" state.
• Ignore "start process" and "end process" since those don't apply to a statechart.
• Assume some other subsystem just tells the statechart how much time has been deposited in minutes.
• Assume that the statechart is executed at a fixed rate (e.g., 1 execution per second)
• Account for all the features of the statechart, such as grace time.

Supplemental Material: