Objective
Whenever actual activities are supported by a system, symbolic activities must take into account timing constraints on their execution.
Activities Synchronization
Processes usually combine different activities whose execution has to be synchronized. Corresponding constraints and rules are evaluated and enforced at run-time, often as a complement and/or alternative to object synchronization rules and constraints. Similarly, the synchronization of activities may be limited to the processing of symbolic objects or applies also to actual processes.
The objective of requirements analysis being to set the foundations of architecture driven modelling without preempting architectural decisions, synchronization constraints must stick to business concerns and targets:
- Synchronization of business objects representation.
- Synchronization between symbolic activities according to flow dependencies.
- Synchronization between symbolic and actual activities according to timing and operational constraints.
It must be reminded that synchronization between actual activities is not to be considered because no system is involved.
As for objects, symbolic and actual synchronization can be defined locally or across distributed contexts. As far as architecture is concerned, local synchronization constraints can be ignored since they can be managed by execution units without calling on system resources. Regarding distributed activities, it will be necessary to distinguish between symbolic activities, which make no reference to actual events, and actual ones, which will put specific constraints on communication architectures.
Synchronization Policies
While symbolic and actual synchronization constraints may clearly overlap, they seldom coincide and given that their impact on architectures is meant to be significantly different, requirements should be as explicit as possible regarding synchronization policies.
The benefits of separate descriptions appear when, for a set of given symbolic dependencies, alternative control strategies can be used: activity-driven control, derived from flow dependencies, or event-driven control, which introduces a dedicated mechanism on top of symbolic synchronization: For instance, assembling an equipage following a customer request can be driven by:
- Activity: horse and chariot are fetched according customer’s preferences and then associated into equipage.
- Event: some feedback is introduced in such a way that a new search can be triggered for a chariot to fit the horse, or vice-versa.
The actual synchronization of activities can be seen as a broader view of real-time activities.