Scope
Actual activities are bound to context and therefore may have to be synchronized depending on their location and time-scale.
Processes & Events
Actual activities (aka processes) are the transient equivalent of physical objects as they describe how activities are performed when bound to actual contexts. The point is to define the system behavior in terms of states, events, synchronization, and access to resources.
Just like physical objects are described by different symbolic facets, processes may involve the execution of different activities, some symbolic and some actual. That may include their synchronization depending on symbolic and actual dependencies as described respectively by data and control flows on one hand, state transitions on the other hand.
Control Strategies
Since the objective is to identify architectural constraints, the modeling of activities must distinguish between functional and operational levels, i.e what is to be done, and how it may be controlled (cf connectors, workflow patterns).
Hence, when activities are to be synchronized, two policies may be considered:
- Activity driven processes: running activities are in charge, controlling the execution of collaborating ones depending on their status.
- Event driven processes: dedicated controllers follow the state of affairs and, depending on events, rule over the execution of activities.
One of the benefits of such a distinction is to trace architectural decisions to functional requirements:
- Activity-driven (aka push) put activities in the driving seat. It relies on the assumptions that all participants are running within the same address space and under a single clock, or that synchronization is not a concern.
- Event-driven (aka pull) introduces events in order to explicitly describe how activities are synchronized. That is necessary if distributed activities are to be supported but it will require dedicated middle-ware.
Since actual activities are execution units, they can only be identified by a location and a time stamp. Hence, synchronization (# qualifier) applied to actual activities refers to timing, no to be confused to its symbolic counterpart, which refers to flow contents.
Guidelines
As it happens, states, either objects’ or activities’, don’t have to be modelled in any circumstances, only when history is to be remembered before taking a decision:
- No memory: the same input will always return the same outcome.
- Too much memory: there is an infinite number of states so each outcome has to be computed anew.
- Selective memory: a finite set of states can be identified, each which predefined outcomes.
From a architectural perspective two kind of business constraints must be clarified as soon as possible:
- First, it’s necessary to distinguish between activities whose execution is bound to contexts on one hand, and the processing of symbolic representations on the other hand. Whereas the former has to be synchronized with other behaviors, the latter is not constrained and therefore doesn’t have to be executed on the same time-scale, i.e under a single clock.
- Then, when activities are connected, one need to specify if the subsequent one must be performed without delay lest some event would interfere, or if nothing relevant can happen and therefore the later activity can be triggered at will. The architecture will have to support synchronous communication channels if activities are to be executed in real-time.
Obviously, activities that can be executed at will put less constraints upon system architectures, and the objective should be to fence off those whose execution must be synchronized. Variants of execution units should be structured accordingly.