Ultimately, behavior is about how a device responds to these events.
To model this, we need to understand what those events are.
For the next step in the state chart modeling process,
we will look at how to determine, for each of the external controls,
what stimuli or events they can provide to the device.
Using the use cases we have developed earlier,
why don't you begin to make a list of the user actions that might generate
events that we would expect the radio to respond to.
And as a hint, go back and look at the picture, and
use it to find each of the ways that user can affect its behavior.
>> Okay. So,
the first is that the user can switch the mode button, and
that's going to change our state machine based on, we have
to look at what mode we're coming out of to determine what mode we're going into?
>> So what is the event?
What is it that the user does?
>> It's just clicking that little knob over.
>> So, sliding the thing?
And, there's really two events here.
There's one is pushing it to the right, and one is pushing it to the left.
>> Okay.
>> Okay? And, as a programmer,
if you were eventually doing an implementation for
this thing, you would have to deal with both of those.
And you want to deal with them separately, right?
You have to know.
Now we could model those as two separate events, or we could model them as one
event, maybe called slide, and have a parameter to it that says left or right.
What else?
>> Okay, so we can also turn our tuning dial.
>> Okay. And here again,
we might want to have a parameter which indicates the rotational angle or
something that indicates the information
that is being communicated from the dial to the system, that's actually
going to change the vertical bar and the actual tuning behavior of the radio.
>> Right.
Okay.
Another one is flipping our switch for the AM or FM.
>> And, once again, that's a left-right thing.
Okay? >> I guess, is it not toggle, though?
It seems like since we just have two options, kind of like toggling between,
do we need a- >> Well, this particular clock radio
that I modeled, that's on the picture there, is a slide switch left and right.
>> Okay.
And then I have pressing the snooze button, but
I felt like it might need to be split, because you could press the snooze
button while it's beeping, like kind of the intended use case for that.
But you could also press the snooze button when
It's just sitting there on accident or something,
or you just fumble- >> Okay, so
let's think about this a second.
As far as the user is concerned, the event is pressing the button.
>> Okay. >> Okay.
What's in the user's head is irrelevant here, okay?
At least as far as our initial approximation of things.
Certainly, we want to consider the possibility of what it means if the user
presses the snooze button when the alarm is not going off.
And presumably, our resultant state chart will describe for
us what behavior will happen.
This is one of the real reasons we want to do this sort of thing,
is to come up with insights about, well, I haven't thought about that yet.
And I need to take care of it.
We certainly don't want the radio to go off
when it's not playing, just because we hit the snooze button.
What else you have?
>> So, this is kind of like three parts to this,
but when you press the wake button and
then press either the hour or minute button, and then that's going to affect.
>> So is that one event or two?
>> I think the first event, there's one event of pressing the wake button,
because that's going to affect our different systems,
like displays is now going to have to display our wake time.
So that's a separate event, and then there's a conjoined event when you
press the wake button, and then you press either the hour or minute buttons.
Now you're going to be adjusting the display time,
so that's switching modes from your display to wake, for instance.
And then you have this separate case for actually changing the time.
>> Okay. So, we want to be clear about this,
because this one of the different ways that state chart modeling
forces us to think about things.
As far as the user events are concerned, they're separate.
Okay, so, there's an event of pressing that wake button and
releasing that wake button.
So another event here is release.
Pressing the wake button.
And then, there's a separate thing going on, pressing the hour button.
The order in which those happen is very important.
If you press the hour button first, it's going to change the time of day.
>> Right.
>> Okay, if you press the wake button first, then press the hour button,
it's going to change when you wake up.
So its important that the state chart that we end up with reflects that
difference, because the user intends them to be used differently.
The event is pressing the wake button, the event is releasing the wake button.
Another event is pressing the hour button and pressing the minute button.
And our machine, as we eventually refine it to deal with all these contingencies,
had better behave in an expected way as far as all of the precepts in all
of those possibilities, all of those possible situations.