Scope
Like roles (aka UML actors) events sit on the fence between systems and their environment, which means that while they come with dual significance nothing can be said before their processing. If events patterns are to be of any use they should be defined with regard to what can be known upfront, namely the origins and causes.
Actual vs Symbolic Events
From an architectural perspective, events have to be classified with regard to their representation by systems:
- Actual events are associated with changes in the state of external objects or activities, including agents’ expectations.
- Symbolic events are associated with changes in the state of symbolic objects or activities.
On that account, it must be noted that external events can be associated with symbolic objects (e.g contractual agreements) and symbolic events can be associated with actual objects (e.g change in agents’ expectations); what matters is the relationship between business entities and their system representation.
External events are first introduced with requirements, use cases providing for an explicit definition of their origin and semantics upfront, based solely upon business considerations.
Archetypes
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.
From a system perspective, events are perceived as changes 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.
Whereas those distinctions may remain implicit when events footprints are not distributed across systems, they should be explicitly specified when synchronization across communication networks has to be taken into account.
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.
Setting apart signals generated by non symbolic devices is especially helpful when the Internet of Things (IoT) is considered: the distinction between what happens at physical level and its footprint within systems is to determine how the latter is to be synchronized with the former.
Events & States Machines
As far as systems modelling is concerned, and whatever the doctrine, the objective is to describe system behaviors with regard to events deemed relevant for the business under consideration. As such, events semantics must be congruent with the ones used to describe the states of objects, processes, and agents.
Stereotyped events can easily be defined for homogeneous changes respectively in the state of expectations (neutral, waiting, acknowledged, …), objects (open, locked, updated, …), or activities (idle, ready, running, completed …). But models of systems’ behaviors are to combine heterogeneous changes governed by complex events. Specifying consistent transitions across systems heterogeneous states would be challenging without orthogonal specification of corresponding events; hence the need of patterns combining homogeneous events with the same standard logical operators used to define the states of expectations, objects, and activities.
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.
As long as state machines are built exclusively from homogeneous events combined with logical operators, systems’ behaviors can be comprehensively and consistently modeled.
Time & Derived Events
On that basis timers are represented by processes run by dedicated physical devices and emitting periodic signals depending on selected scales and initial events. Time events can therefore be seen as a special case of 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.
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.
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.
Annexe
As represented in the Caminao Ontological Kernel (CaKe).
Connectors Branch for transitions