The most obvious omission from the modeling language was the complete lack of
the concept of an Alarm. It had been mentioned early on but never focused on for long
enough to actually ?¬?gure out how it should be modeled. Setting the alarm seemed easy
enough: we could edit some time value for it, either the time at which the alarm would
ring, or the amount of time until it would ring. An alarm ringing would be similar to a
button press in that it could cause a change of state. More interestingly, this change of
state could happen at any time, even if the watch was running a different application at
that point. Clearly, we could not drawtransitions from every state in the entire model in
case the alarm rang there. Instead, we settled on having an alarm symbol, and a single
special ???alarm??? transition from that to a state. Whenever the alarm rang, its application
would take control and jump to that state. On exiting the alarm application, the watch
would return to the application that was current when the alarm rang.
In deciding whether to set alarms at a time of day or as an amount of time until
the alarm rang, we hit a problem. What would happen if the user changed the watch
time after setting the alarm? If we stored alarms as a time of day, a standard Alarm
Clock application would be ?¬?ne, but a Countdown Timer would suddenly be wrong.
Pages:
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371