Tuesday, February 4, 2003

Musing on Events

"Events" are a subclass of "Data" where there is one required attribute, namely, a time-stamp.  Arbitrary amounts of other data may be included in an Event but they all have a time-stamp.

The canonical use of Events is for them to act as a trigger for some action to occur.  They secondarily may be logged for audit/replay/etc.  Many systems do not care what the actual time-stamps are, but only that they are sorted in chronological order.

Examples of events are; keystrokes, message receipt, mouseclick, etc.

Since the only requirement for an event is that it has a time-stamp, the clock itself can generate events that consist of nothing more than the time-stamp.

"Actors" are generators of events.  Having a "thread of control" means "being able to generate events" rather than only being able to react to events.

Since events only need time, people often overlook the fact that a "clock" can be an "actor" and therefore the source of events in a system.

Objects are usually described as containing both behavior and state. State is data. Behavior is a sequence of events.  Control flow is the proscription of how to decide which events are to be generated. So, if objects can be modelled as state change diagrams, the states represent the possible instances of the object data, and the events represent the arcs that trigger a change from one state to another.

Programs represent a planned source of events, and "external actors" represent an unplanned (i.e. unpredictable) source of events.

No comments: