Events

``Events'' are not native to the UML. However, it is a useful concept for capturing the functional requirements of an information system. Now that we have discussed sequence diagrams, we can use them to identify events.

An event (from the perspective of an information system) is an external and asynchronous occurring that is not under the control of the information system being modeled. This means that the occurring is due to a cause that is external to the information system, and that the timing of the occurring is independent of the timing of the information system.

The information system must respond to an event with a response as soon as possible. In other words, if the system does not react to an external and asynchronous occurring, the occurring is not considered an event.

Last but not least, the response to an event must be directed to one of the actors. Note that the originator of an event needs not be the recipient of the corresponding response. Nonetheless, the response must be directed to an recipient actor.

After all this abstract discussion, we can illustrate events with some examples.

``Student checks grade'' is a valid event because of the following:

• it originates from outside of the system: unless a student lives inside the information system.
• it is asynchronous: the information system has no way to predict when a student wants to check his/her grade.
• there is a response: the information system responses with the retrieved grade.
• the response is directed: the response, in this case, is directed to the originating actor instance.

A begging question is whether the user authentication is included in the event called ``student checks grade''. Although the authentication messages are included in the sequence diagram, they are not considered a part of the event.