Events and Signals

Introduction

 

In state machines (sequence of states), we use events to model the occurrence of a stimulus that can trigger an object to move from one state to another state. Events may include signals, calls, the passage of time or a change in state.

 

In UML, each thing that happens is modeled as an event. An event is the specification of a significant occurrence that has a location in time and space. A signal, passing of time and change in state are asynchronous events. Calls are generally synchronous events, representing invocation of an operation.

 

UML allows us to represent events graphically as shown below. Signals may be represented as stereotyped classes and other events are represented as messages associated with transitions which cause an object to move from one state to another.

 

 

Types of Events

 

Events may be external or internal. Events passed between the system and its actors are external events. For example, in an ATM system, pushing a button or inserting a card are external events. Internal events are those that are passed among objects living inside the system. For example, a overflow exception generated by an object is an internal event.

 

In UML, we can model four kinds of events namely: signals, calls, passing of time and change in state.

 

Signals

 

A signal is a named object that is sent asynchronously by one object and then received by another. Exceptions are the famous examples for signals. A signal may be sent as the action of a state in a state machine or as a message in an interaction. The execution of an operation can also send signals.

 

In UML, we model the relationship between an operation and the events using a dependency stereotyped with “send”, which indicates that an operation sends a particular signal.

 

 

Call Events

 

A call event represents the dispatch of an operation from one object to another. A call event may trigger a state change in a state machine. A call event, in general, is synchronous.

 

This means that the sender object must wait until it gets an acknowledgment from the receiver object which receives the call event. For example, consider the states of a customer in an ATM application:

 

 

Time and Change Events

 

A time event represents the passage of time. In UML, we model the time event using the “after” keyword followed by an expression that evaluates a period of time.

 

A change event represents an event that represents a change in state or the satisfaction of some condition. In UML, change event is modeled using the keyword “when” followed by some Boolean expression.

 

 

Sending and Receiving Events

 

Any instance of a class can receive a call event or signal. If this is a synchronous call event, the sender is in locked state with receiver. If this is a signal, then the sender is free to carry its operations without any concern on the receiver.

 

In UML, call events are modeled as operations on the class of an object and signals that an object can receive are stored in an extra component in the class as shown below:

 

 

Common Modeling Techniques

 

Modeling a family of signals

 

To model a family of signals,

1. Consider all the signals to which a set of objects can respond.
2. Arrange these signals in a hierarchy using generalization-specialization relationship.
3. Look out for polymorphism in the state machine of the active objects. When polymorphism is found, adjust the hierarchy by introducing intermediate abstract signals.

 

 

Modeling Exceptions

 

To model exceptions,

1. For each class and interface and for each operation of such elements, consider the exceptional conditions that might arise.
2. Arrange these exceptions in a hierarchy.
3. For each operation, specify the exceptions that it may rise.