Scope
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.
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.
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.
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.
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.
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:
- Entry points of supported activities.
- Events associated with its execution.
- Connectors between actual and symbolic representations.
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.
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.
Further along the modeling path, using UML Sequence Diagram, the single timescale will be represented by a critical region.
