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

C06 In Class Exercise: Peer Reviews

Do a peer review on the following code: OpenBSD qsort version 1.10. (Note that this is an acrobat file so everyone will have consistent line numbers to work with.

Spend a few minutes (no more than 5 minutes) getting general familiarity with the file so you more or less understand what's going on. This is a QuickSort implementation, and hopefully you've seen that algorithm before somewhere, but that is not essential for the code review.

Assign the following roles within your group:

Methodically go through the code starting at line 83 using the following procedure:

  1. The review leader identifies a chunk of 1 to 10 lines (typically 4-5 lines) to focus on.
  2. Each reviewer looks ONLY at the assigned code chunk and looks at EACH assigned item one at a time.
  3. A revie/wer finding a problem states: Rule #, Line #, brief description; review leader writes them down in the review log.
  4. When all reviewers have completed their checklist, review leader asks "anything else?" Reviewers can spend a brief moment saying things not in their assigned item list.
  5. Review leader returns to step #1, starting the next chunk

When you've recorded 10 defects let the instructor know and take a break. This is not a race; and it is MUCH better to be thorough than fast. So the fewer chunks of code you look at to find 10 defects, the better you are doing.

C07 In Class Exercise: Requirements

This is a GROUP exercise. Create two slides that have a list of behavioral requirements for a left-hand-rule wall follower turtle similar to the one used in the course project. Use good format/style for the requirements.

Note that the requirements should NOT simply be a verbal, complete description of the code or an associated statechart. Rather, it should contain snippets of required behaviors that can later be woven together via creating a state-machine based implementation. (We'll get to state machines and statecharts in a future lecture.) This is a subtle but extremely important difference. It is, however, OK for this exercise to refer explicitly to state names, sensor inputs, and actuator outputs by name since that will help make this exercise more concrete. The point of this exercise is to give you some experience with the difference between implementation (code) and design (a higher level of abstraction that is not simply a verbal description of all the details in the implementation).

Examples of GOOD high level product requirements

Examples of GOOD detailed requirements:

Examples of a BAD requirements -- this is simply a verbal statement exactly describing the statechart:

HW #4: Coding Style

4.1 Consider the Embedded C Coding Standard from Barr Group ( We recommend you at least skim through the whole thing, but the questions below apply to a specific section. (Strictly speaking some of these rules are more about language use, but the point is that this is a language use guide directed toward programmers rather than toward language specifications.)

Make sure you have access to these answers during recitation (e.g., via your smart phone) in case you are called on to discuss.

Topic assignments for question 6-1 are per below, based on the last digit of your student sign-in number. (For example, if your sign-in sheet number is 17 you are a "7.")

Supplemental Material:

HW #6: Peer Reviews

There is no homework for this lecture. You'll be practicing this material in lab.

Supplemental Material:

HW #7: Requirements

Consider a digital alarm clock. This is a cheap, minimalist alarm clock with ONLY the inputs, outputs, and internal values indicated. The goal is to create a set of requirements for this simple alarm clock.

FAIR WARNING: you will be building upon this design for the high level design homework later, so take the time to do it right, and make sure you save your answer in a place you can access it later when you need it. Be sure to use the defined terms below in your responses:

The alarm design has to account for at least the following use cases:

7-1: (25 points) Creat a list of HIGH LEVEL PRODUCT requirements for the alarm clock. This are user-facing functions that the alarm clock must perform to be an alarm clock. Use the identified use cases above as reminder list. (Usually the high level requirements come first, but we wanted to fix the use cases for this exercise to prevent too much random dispersion of student work.) For each high level requirement, state which use cases it covers. Make sure each use case is covered by at least one requirement. An example that you can use as a starting point is: "PR-1. Clock shall display correct time of day when not performing other functions. (U-1, U-2)"

7-2: (5 points) Create a list of values required for the STATE of the system in terms of reasonable names. For example, make it a list of the enum values you would use. One of the items on this list MUST be "Idle-State" or something obviously equivalent using whatever capitalization and punctuation approach you prefer. (You'll need to update this answer as you complete the next part; just give us the final answer here after you've completed everything on this homework.)

7-3: (7 * 8=56 points) Write at least one DETAILED FUNCTIONAL requirement for each use case #1 through #8 (so that means at least 8 detailed requirements). These are functional requirements (i.e., how the system functions) and not extra-functional requirements (e.g., don't worry about limits on power use). Browse the web for examples of what requirements look like if you find that helpful. If you use material from a clock-like example be sure to reference it. Make sure your requirements conform to the following bullets. The points on each bullet are applied PER REQUIREMENT for the FIRST requirement you list for each use case.

Examples requirement (it's OK to use this if you want to):


Supplemental Reading: