A pattern for prompting actors
Subsequently, we have seen this pattern appearing in many use cases for a wide variety of systems: to provide warnings that a new program will overwrite the current contents of a programmable logic controller; to advise a stockroom that a supermarket shelf is running low and should be restocked from the warehouse; and to notify users when they have new mail, to give just three examples.
The alarm pattern also illustrates the move from System Response in Wirfs-Brock's two-column use cases to System Responsibility in Constantine's (and our) essential use cases: a response requires some prior user interaction to which it can respond, while a responsibility includes both initiating and responding to communication with actors.
The figure also shows a variant of the alarm pattern: where it is important that the actor confirm receipt of the alarm, the use case can be written to capture the actor's intention with an extra, explicit, confirmation step. As the figure explains, this variant pattern resolves the forces in the use case in a slightly different way: the alarm cannot be ignored, but it will be more intrusive, interrupting the current task by requiring the actor to confirm it explicitly. Microsoft Windows' ``hard disk full'' can be seen as an implementation of this variant pattern: when a machine's disk is full, the system warns the user of this fact, and expects confirmation that the warning has been received.
Figure 
gives another example of a similar pattern -- the
Prompting Step Pattern -- where the actor intends to make a
decision, the system can supply that actor with up-to-date information
before the decision is made, thus removing the responsibility to remember,
store, or track the information maintained by the system. Although more
intuitive than the alarm pattern, the prompting step pattern has also been
useful to analysts writing essential use cases, to determine whether (or
not) to include a prompting step in their models.