Event Patterns


Given that events must be interpreted before being processed, patterns should be of great help. Yet, analysts not being famous clairvoyants, interpretations can only consider the past, namely the origin and causes of events.


Missed Event (Elmen & Dragset)

From an an architectural perspective, the critical point is the way business events have to be taken into account:

  • Actual (aka external) events are associated with changes in the state of actual objects or activities. Their instant mapping into system representations is therefore meaningful; whether it is necessary depends on the synchronization of  business activities.
  • Symbolic events are associated with changes in symbolic representations of objects or activities. Whether they must be notified immediately is set by business rules.

External events are first introduced with requirements, often with use cases, and their origin and semantics should be defined upfront, based solely upon business considerations.


As already noted, business events may be associated with changes or interactions. Those may be further characterized along architecture driven representation patterns already introduced with use cases.

Events based on changes may be triggered by physical or symbolic objects or by execution states:

  • Changes to physical objects can only be known indirectly, i.e through entry points.
  • Changes to symbolic objects can be known directly at system level when persistent representations are modified.
  • Changes to execution states of business processes can be known directly at local level when transient representations are modified.

Events based on interactions are reflections of changes:

  • Signals (aka external events) are originated by changes in contexts. They are identified by receiving entry points and timed then.
  • Requests are originated by changes in expectations (aka state of mind) either from agents or business processes, and therefore they entail new architectural constraints. They are identified by their source and timed accordingly.
  • Messages are originated by changes whatever the source and entail no architectural constraints. They are identified by their source and timed accordingly.

Changes to physical or symbolic objects, requests (change in state of mind), signals, messages, changes in execution state.

Whereas those distinctions may remain implicit when events footprints are not distributed across systems, they must be explicitly described otherwise.

Representation Patterns

Events are used to describe changes affecting the relationship between context and systems. As a corollary, their representation is twofold, external phenomena and its symbolic representation.

  • Signal: nondescript phenomena that has to be processed in order to determine its origin and relevancy.
  • Change in user expectation: captured through identified user and possibly recorded.
  • Change in object state: captured through sensor, associated to target, and possibly recorded.
  • Change in process state: captured through sensor, associated to target, and possibly recorded.

Four categories of events crossed with symbolic counterparts

It is important to note that, given the role of events, the distinction between what happens at process level and its footprint within systems will determine how the latter is to be synchronized with the former.

Events & States Machines

As far as modelling is concerned, and whatever the doctrine, events are introduced to describe system behaviors and eventually specify controls. As such, their semantics must be congruent with the ones used to describe the states of context and system elements, namely objects, processes, and agents.

Actual events are associated to actual changes: state of mind, mended object, mending activity.

Combined with their counterpart for execution units, stereotyped events can be used to make explicit assumptions about state machines.  As an example, assuming that technical status of vehicles is managed by after-sales department, and customer state-of-mind by CRM, the repairing process will be governed by three categories of events:

  • Once initialized (change in process), it remains idle until a check-in (change in user expectations) of a vehicle in need of repair or maintenance (waiting lists are not considered).
  • Maintenance proceeds as specified by a checklist until completion, repairing proceed until the vehicle is repaired.
  • Once actual operations are completed, the process has to wait for customer acceptance and check-out.

Events, States, Transitions

Timer Events

Timer events are signals issued by dedicated physical devices according measuring scales set from initial events.

Derived Events

Just like derived objects are computed from existing symbolic representations and have no business meaning on their own, derived events are triggered by other events and don’t refer to additional changes.

At model level, derived (aka chain, aka cascade) events are used to synchronize changes across state machines. That make them easily identified as stereotyped notifications for transitions, entering or exiting states.

Derived events have no effect of their own

At requirement level things are no so simple and two conditions are to be met for derived events:

  • They will necessarily occur once the original event has happened, whatever may happen in between.
  • Their happening will have no additional effect on business processes execution.

Hence the benefits of using state-machines (especially StateCharts) for synchronization requirements. That may be illustrated with the model above.

Without derived events agent’s behavior, vehicle status, and document workflow are lumped together:

  • A vehicle is moved to repair when a mechanic is idle.
  • A repair is invoiced when a vehicle is moved from repair.

Derived events introduce a level of indirection that will support explicit modeling of synchronization requirements: vehicle moves and repair invoices are not triggered by actual events but by their shadow notification by controllers.

Events Scope & Embedded States

Applied to embedded execution units, stereotyped events can be used to check the orthogonality of sub-states. Taking example from the Home Alarm System already introduced, there is three pairs of triggering events each sourced from disjoint contexts: external (power on/off), physical objects (power-grid and battery) and the system under consideration.

When events and states are stereotyped depending on their footprint they can be used to check the orthogonality of embedded execution units.

Events & Rules

How events relate to states can be defined explicitly or implicitly:

  • Explicit reference (conditions): actions are triggered WHEN events DO occur.
  • Implicit reference (constraints): actions are performed WHILE events DON’T occur.

    Events and Processing States

Such explicit semantics make models open to refutation and greatly enhance the benefits of test-driven development.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: