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

Updated 9/17 at 1:00 AM to clean up homework numbering.


C14 In Class Exercise: High Level Design & Architecture -- Sequence Diagrams

Consider an electronic dimming light switch that has four buttons: ON, OFF, UP, DOWN, and MEM. The output of the system is LIGHT with an intensity of 0-100. Generally speaking, ON and OFF turn the light all the way on and off. UP adds 10% illumination. DOWN subtracts 10% illumination. Pressing MEM sets lights to a predefined setting. Pressing and holding MEM remembers the current light setting as the predefined setting. Generally this corresponds to the functionality of the Lutron Pico Wireless Control. http://www.lutron.com/en-US/Products/Pages/Components/PicoWirelessController/Overview.aspx

Part #1: Create a statechart for this system. Take turns within your group. Do this by having each student in your group either adding ONE state to the diagram OR adding an arc between two states until the statechart is fully defined.

Part #2: Create sequence diagrams for this system according to the following roles. Take turns within your group as follows:

Be sure to hand in drawing drafts. (photo of hand-written drawing is OK)

Hints:


C15 In Class Exercise: Sequence Diagram Homework Warm Start

Consider the digital alarm clock in the REQUIREMENTS homework question. Also consider that the internal values, the outputs and the switches (inputs) are all objects that can receive data from other objects, send data to other objects, and/or store data. Objects can also perform computations. Remember that you cannot read actuator values.

Create eight sequence diagrams for the alarm clock: one sequence diagram per use case. Each sequence diagram should show all the objects involved in a particular operation. It will show one possible way that an operation can be performed, but not necessarily ALL possible ways. As an example, if you can set alarm time by pressing the button multiple times or holding down the button, it is likely that there are (at least) two sequence diagrams for setting time: one that shows a single quick press of the button, and one that shows what happens if the button is held down. (You would not need a sequence diagram for repeated button presses, because that is really just multiple invocations of the single-button sequence diagram invoked by the user.) There must be at least one sequence diagram for each use case except "housekeeping"


HW #14: Alarm Clock more SDs

NOTE: This week's homeworks are all related. You should iterate across them as a set so that the finished set is consistent and complete. They are broken into three homeworks simply so that you get a weight of three homework grades toward the course grade for the amount of work required. All these homeworks refer to the alarm clock in the REQUIREMENTS homework question. Don't forget you did work there that you can modify and/or build upon for this homework.

NOTE: In previous semesters some students said that this week's homework took longer than anticipated. Start early; don't wait until the last minute!

NOTE: In principle, this homework should precede the next homework on updated requirements, because you should be looking at the SDs to create your requirements AND you have already done a draft of requirements previously. However, some students feel more comfortable starting with requirements (the next HW), then doing back to SDs, then updating requirements again. You can do these two homeworks in whatever order and iteration style you prefer.

Finish the alarm clock high level design from the previous class exercise. It is OK to use your group result as the starting point for your homework. It is also OK to add ideas you learned from class discussion. However, because this is a homework the rest of the work must be YOUR OWN INDIVIDUAL EFFORT. (In other words the class discussion was to get you started; this homework is NOT a group effort.) Be sure to think of alternate ways that use cases might apply. For example, a user will want to deactivate the alarm to keep it from going off, but will also want a way to turn off the alarm once it has sounded. There is no set total number of requirements and SDs, and your result will depend on your approach.

14-1. (10 points) Add additional sequence diagrams to ensure you have a complete set. It is possible you'll want to completely re-do your SDs, and that's OK too.You'll need to coordinate this with your requirements and statechart (see the following homeworks for this week), iterating until all three match each other. Some use cases might need only one SD, but some might need more. (TAs can add up to +5 additional points for particularly thorough jobs at this at their sole discretion.)

High Level Design Supplemental Reading:

Supplemental Reading on System Architecture:


HW #15: Update Requirements for Alarm Clock

15-1. (10 points) Building on your submission for the previous alarm clock REQUIREMENTS homework question, supplement your list of requirements so that you think you have a complete set. It is possible you'll want to completely re-do your requirements, and that's OK too. Grading will be according to whether you did a reasonable job of getting all the additional requirements needed to make the system a clock. Submit a complete set of requirements for this question.

15-2. (10 points) Redo your requirements from low level requirements (your answer to the previous question) into product requirements. What is the difference you ask? The low level requirements you previously did probably amounted to a verbal description of what the statechart did, and many of you probably ended up doing the statechart first and the requirements second. This was a way to bootstrap your ability to write requirements. However, in real projects the requirements come FIRST and the statecharts come LATER. So now that you are hopefully comfortable writing requirements, we want you to completely rewrite requirements for the same alarm clock, but do so from PRODUCT point of view (i.e., what the user is experiencing, not how the software inside the alarm is accomplishing the task). This means, for example, you are NOT allowed to refer to internal state variables, because the user has no idea about those. For many of you this will feel like a bit of a squishy exercise, but that is because you already know how the system works and you're translating to a less precise description. In real product design first you create the less precise description and then go from there to design. For this question, write a complete set of product requirements that satisfies the following constraints:

Some comments on this question:


HW #16: Design a statechart

16-1. (25 points) Create a statechart for the alarm clock based on the requirements. Include all states and all transition conditions. If you have trouble fitting all the conditions on arcs graphically, it is acceptable to have a table that lists the transition conditions. (See this web page: https://www.ece.cmu.edu/~ece649/project/sodamachine/portfolio/reqs/requirements2.html#buttoncontrol for an example.) Follow these design rules the best you can:

Hints: you can use pressing a button on one arc and releasing the button on a different arc. Also, since these requirements will result in a software state machine, you should assume that the state machine executes periodically at a reasonably fixed rate that you pick, such as 2 times per second, and that people will press and release the button before the button is re-sampled if you wish to make such an assumption.

Grading: Since every homework solution will be diffferent, grading is at TA discretion. Grading will be primarily on following hte stated style rules and having a reasonable approach. An optimal or "perfect" answer is not required to get full credit.


HW #17: System Level Test

There is no homework for System Level Testing. You'll be doing this in the course project.

OPTIONAL Activity (work not graded; work not handed in; no grade assigned; do this if you want to know more about testing)

17-1: Watch the video on Irreproducible Bugs by Cem Kaner here: http://www.testingeducation.org/BBST/bugadvocacy/ ("Lecture 3: Anticipating and Dealing with Objections: Irreproducible Bugs"; 17 minutes. Direct Download: http://www.testingeducation.org/BBST/bugadvocacy/BugAdvocacy2008C.wmv). This video is oriented more toward IT/desktop software applications, but the ideas generally apply to embedded systems. (And yes, the video is pretty old, but it's still the best one, and is from the World Expert on this topic.

Supplemental Reading: