Real Time Activities


Real-time activities are actual ones with the additional constraint that context events and their system counterpart must coincide. In other words local time must simultaneously govern both external events and corresponding system processing.

(R. Doisneau)
Real-time activities are bound to actual changes in context (R. Doisneau)

On a broader perspective the generalization of the so-called “internet of things” put the spotlight on the synchronization of objects and activities.

Real World and Real Time

Systems are built to manage symbolic representations of business objects and support associated business concerns. Whereas some concerns are easy-going and can do with casual updates of targeted objects, others are more jumpy and will not tolerate intervals between real worlds and symbolic representations.

Jumpy concerns: nothing relevant should happen between an event and its registration

Real-time activities are the equivalent of binary objects for behaviors:  an activity whose execution is simultaneous within and without the system, i.e it occurs on the same instant measured on the same time scale. Since real-time systems are meant to support real-time activities they must support instant representation of  contexts. As a corollary, real-time systems are not supposed to do anything between the happening of events and their proper processing.

Apparently that can only be achieved locally, i.e with all targeted object instantly available and all operations executed under the control of a single clock. On the other side, “real” doesn’t necessarily mean “fast”, but only that the system should guarantee that nothing relevant, for the business under concern, could happen while actual objects and their counterparts on symbolic representations are not in sync; protection mechanisms can be designed for that purpose.

Protection mechanisms (aka semaphores) ensure that nothing of concern will happen while context and system objects are not in sync.

From an architectural perspective, real-time processing means that context and system states must coincide.

Intrinsic vs Operational Real Time Constraints

From a business perspective, real-time constraints can be intrinsic or operational:

  • Intrinsic constraints are brought about by the supported activity itself. That is the case when some imperative real world process must be supported as it happens.
  • Operational constraints  are brought about by the way activities are performed. That is the case when real world processes depend upon the same agents or resources.
Operational vs Intrinsic Real Time Constraints

Whereas, from system architecture perspective, real-time constraints will translate into concurrent processes, synchronization and monitors, those constraints have first to be expressed as requirements, independently of the mechanisms supported by architecture. That may be achieved by using representation patterns.

Representation Patterns: left: an agent puts a request to a system; right: an actual change is communicated as a message which triggers a change to symbolic representations.

Intrinsic Real Time Constraints

Intrinsic real-time constraints occur when actual phenomena are to be dealt with before anything relevant could happen.

Requirements dealing with intrinsic real-time constraints should be expressed with stereotypes for:

Intrinsic Real Time Constraint: Representations must Follow the Flows

Operational Real Time Constraints

Operational real-time constraints occur when actual objects are shared by different processes. They may or may not come along with intrinsic real-time constraints.

While requirements involving operational real-time constraints have to specify synchronization constraints, they should not introduce architecture-specific mechanisms. For instance,  joint reservations for horses and  chariots are to be synchronized if paddocks and depots are managed from distributed locations. Yet, that may be achieved through different means whose selection will depend upon architecture.

Distributed activities must be set within the timescale of the triggering event.

One way to get around the difficulty is to set distributed activities within a single timescale initiated by their triggering event. For instance, joint reservations for horses and  chariots are to be timed from user requests using clocks replica initiated by user requests. Requirements regarding such time-related activities should be represented by stereotyped use cases.

Distributed activities must be set within a single timescale initiated by their triggering event.

Further along the modeling path, using UML Sequence Diagram, the single timescale will be represented by a critical region.

Paired reservation with UML Sequence Diagram (No Magic MD)

Leave a Reply

%d bloggers like this: