Educational objective: hands-on experience with statecharts to prepare you
for the project.
Consider the digital alarm clock in the REQUIREMENTS group project. 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. (You can store them internally if you need to
remember them, but you have to explicitly do that; you can't simply read an LED
on/off state from the LED itself.)
16-1. In general you'll all have different sequence diagrams from the
previous week's group project. Take a look at what you have and agree on ONE
set of SDs to use for this group exercise (or at least one set to use as a
starting point). You can just pick one of the sets, or you can make your own by
combining -- or whatever makes sense. You might need to update these as you
perform the next step. Don't spend a huge amount of time on picking,
since most of them will probably have a problem that you don't see until the
next step.
16-2. 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://users.ece.cmu.edu/~koopman/ece649/project/sodamachine/portfolio/reqs/requirements2.html#buttoncontrol
for an example.) Follow these design rules the best you can:
- Give every state a number/identifier (S1, S2, etc.) and a name (IDLE, etc.)
- Include an initialization ("reset") arc. Be sure to put a
reasonably large solid black dot on the arc so that it is easy to find (dot
should be 1x-2x the size of an arrow head).
- 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.
- 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.
- 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. Also, you may
NOT add additional buttons. So this means whether the alarm is on, active,
inactive, etc. must be encoded in the state variable. 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). In practice this means that STATE encodes
the states of your statechart and nothing else.
- It is OK to test for equality/inequality of state variables that have more
than 1 bit of value (i.e., current time or the set alarm time).
- If you need to create a holding variable for time of day or alarm time
that's OK. But do this to support computations, not hide states from the
statechart.
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.
16-3. Update you Sequence Diagrams until you have a good match
between the SDs and what the statechart actually does.
RUBRIC
- Final version of Sequence Diagrams after updating (OK to base on
previous-week solution provided by one of the students in the group.)
- Final version of statechart that covers all the SDs (and, hopefully, all
the use cases by extension)
- Traceability table of statecharts to SDs (rows: states & transitions;
columns: SD, and even better SD arcs). This can get a little complicated -- do
something that would convince a reasonable person that your statechart isn't
missing anything in the SDs. We're not going to be picky on grading this.
Resources: