Be sure to look at the Canvas Module for this week for various hand-in
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:
- Review leader & recorder (the first person listed in the group
- Review leader is responsible for guiding the review, recording results, and
keeping all discussions to less than 60 seconds on any topic.
- Reviewers (everyone else). Reviewers split up items 1-17 in the checklist
roughly evenly. Ignore checklist item #18.
- For example, for 4 reviewers in addition to the leader: (1) items #1-4; (2)
items #5-9; (3) items #10-13; (4) items #14-17.
- It's OK to vary this assignment, but each reviewer should have primary
responsibility for about a quarter of the checklist.
- It's OK to swap roles partway through just to keep things interesting, but
keep a single role for each code block.
- Use this Peer Review checklist.
This is an industry-grade checklist for generic software and is DIFFERENT from
the project 3/4 checklist. However, you'll be using this checklist later in the
- Use this reporting format: (.pptx |
Methodically go through the code starting at line 83 using the following
- The review leader identifies a chunk of 1 to 10 lines (typically 4-5
lines) to focus on.
- Here are some hints as to good chunks to consider: (1) lines 83-88; (2)
lines 90-91; (3) lines 92-98; (4) line 99; (5) lines 100-102; (6) lines
- Each reviewer looks ONLY at the assigned code chunk and looks at EACH
assigned item one at a time.
- A revie/wer finding a problem states: Rule #, Line #, brief description;
review leader writes them down in the review log.
- 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.
- 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.
- File name: C06_Group##.ppt (or .pdf, as appropriate). For example, in-class
exercise group #5 would be C06_Group05.ppt. Please use this naming convention
of C## for Class Exercise # and Group## for Group number in future in-class
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.
- First slide: High level product requirements. (Note: if you get
stuck, ask for help. When you run out of ideas, move on to the second slide.)
- Second slide: Detailed functional requirements. (Note: if you get
stuck, ask for help.)
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
- PR6. The turtle shall stop moving when it reaches the goal.
Examples of GOOD detailed requirements:
- R7. When the turtle has reached the goal state, it shall stop all movement.
- Also OK: R7. When GOAL is true, turtle movement shall be STOP.
- R3. When the turtle senses a wall and it is not at the goal, it shall
- Also OK: R3. When BUMP is true and GOAL is false, turtle movement shall be
Examples of a BAD requirements -- this is simply a verbal statement exactly
describing the statechart:
- R98: Variable barbaz shall be incremented when BUMP is equal to true.
- R99: STATE X shall have an output arc to STATE Y that is guarded by BUMP
equal to true
- File name: C07_Group##.ppt (or .pdf, as appropriate). For example, in-class
exercise group #5 would be C07_Group05.ppt. Please use this naming convention
of C## for Class Exercise # and Group## for Group number in future in-class
4.1 Consider the Embedded C Coding Standard from Barr Group (https://barrgroup.com/Embedded-Systems/Books/Embedded-C-Coding-Standard).
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.
- 4.1a (1 point) In your assigned section, which rule to you most agree with
(e.g., which rule do you think will help prevent the most bugs). Include both
the rule number and a summary or quotation of the rule in your answer. (In this
case it is OK to use a quotation if you like. This is a subjective answer and
almost any answer will be OK, but see the next question... )
- 4.1b (4 points) WHY do you think the rule you gave is the most effective
rule? (Again this is a subjective answer, but give a substantive answer that is
- 4.1c (1 point) In your assigned section, which rule do you most disagree
with (e.g., which rule do you think won't improve software quality, or might
even degrade quality?) (Again, this is a subjective answer.) If you can't find
a single rule you disagree with in your assigned section, say so and offer a
rule that you really hate from another section.
- 4.1d (4 points) WHY do you think the rule you gave in the preceding
question is the least effective rule or even a harmful rule? (Again this is a
subjective answer, but give a substantive answer that is reasonable.)
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.")
- 1. Sections 1.2-1.5 (General Rules)
- 2. Sections 1.6-1.8 (General Rules)
- 3. Sections 2.1-2.2 (Comments)
- 4. Sections 3.1-3.3 (Whitespace Rules)
- 5. Sections 3.4-3.6 (Whitespace Rules)
- 6. Sections 4.1-4.4 (Module Rules)
- 7. Sections 5.1-5.5 (Data Type Rules)
- 8. Sections 6.1-6.3 (Procedure Rules)
- 9. Sections 7.1-7.2 (Variable Rules)
- 0. Sections 8.1-8.5 (Statement Rules)
There is no homework for this lecture. You'll be practicing this material in
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:
- Internal values (read/write):
- TIME: current time in hours and minutes (no seconds); automagically
increments according to time of day. In other words, your system uses this as
the actual source of the current time.
- ATIME: alarm time in hours and minutes (no seconds); this is just an
ordinary variable memory location
- STATE: a set of values (as many as you like) that tracks state of
the alarm. (When code is written this would end being an enum, but for
requirements it's just a list of state names.)
- Outputs (write only; can NOT be read):
- DISPLAY: a numeric display that can display either TIME or ALARM
- ARMED: an indicator showing whether the alarm is currently activated
("on" means alarm will sound; "off" means alarm function is
- BUZZER: a noise maker that, when turned on, makes the alarm noise
- Input switches (read only; can NOT be written):
- SW-1: a single on/off momentary push-button switch that can be used
however you want. We strongly suggest you give it a more meaningful name.
- SW-2: a second single on/off momentary push-button switch that can
be used however you want. We strongly suggest you give it a more meaningful
The alarm design has to account for at least the following use cases:
- U-1: set time of day
- U-2: show time of day
- U-3: sound alarm
- U-4: deactivate alarm
- U-5: set alarm armed state (active/inactive)
- U-6: show alarm state
- U-7: set alarm time
- U-8: show alarm time
- U-9: housekeeping (optional) use this for any requirement that doesn't
directly trace to another use case
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,
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.
- (1 point) Each requirement is a fully completed English sentence that
contains the word "shall"
- (4 points) Each requirement talks about manipulating the state of the
system in terms of the defined internal values changing in reaction to inputs
and internal values, resulting in outputs and changes to internal values.
- (1 point) Each requirement is traceable to its use case. For example, R-1a
traces to U-1. In case of a requirement tracing to multiple use cases, pick one
and list the others in the rationale.
- (1 point) Each requirement conforms to the rules for "good"
requirements given in class.
- (0 points) It's OK, but optional, to have a "rationale" after the
requirement that is basically a comment.
Examples requirement (it's OK to use this if you want to):
- R-1a. Whenever STATE becomes Idle-State, DISPLAY shall show current value
of TIME. Rationale: Show time of day when clock isn't doing anything else
- By "state" we mean for example a state in a finite state machine
diagram that represents the current operational mode of the system. Examples of
states you might find useful (but are not required to use) are: sound alarm
state, set time state, set alarm state. Most students should have seen
statecharts and/or state machines in their undergraduate curriculum. If you've
never worked with state machines before then try web searches for tutorials on
"statecharts" and/or "finite state machines" and ask
questions at recitation. (Starting point listed below in supplemental
materials.) Or ask a friend about them (state machines in general is an OK
topic to get help with; having someone design your alarm clock states for you
is NOT). Note that the point is not to design a statechart here, but that is
where this is going to end up later in the course.
- We STRONGLY suggest you add additional requirements to this homework to try
to get a complete set. Then get help if you get stuck. You'll need to create a
set of complete requirements for a future homework. We're limiting the scope of
this homework to give you some slack if you get stuck. For time management it's
better if you can get as far ahead as possible on a complete set of
requirements. For this homework only the FIRST requirement tracing to each use
case will be graded, but it is OK to hand in additional requirements to get
- This homework assignment is NOT requesting you to create a statechart. In
fact, to get the maximum benefit from this assignment you SHOULD NOT create a
statechart, and instead you should just work on the requirements. While
creating a statechart first and then creating requirements might serve as
training wheels for some students (and is not cheating), doing so is
discouraged. The point of much of this course is getting you out of doing
coding/design first and backfilling higher level representations, and instead
getting you to start with higher level representations. In real designs, you do
the requirements first, and a large number of statecharts later. The point of
the requirements is that it is easier to see all the requirements at once than
it is to keep the details of hundreds of interacting statecharts in your head
at the same time.