Objective
Some activities have a direct impact on business contexts, others deal only with symbolic representations. As their impact upon system architectures are clearly different, they should be set apart as neatly as possible.
Computations
As far as system architecture is concerned, computations are irrelevant if they can be performed in isolation, i.e by a single unit without requiring any interaction between inception and completion. Hence the rationale of factoring them out. Symbolic activities describe the flow of computations disregarding actual conditions on processes execution, ie constraints on interactions with actual contexts are ignored. They may include symbolic interactions as the origin or destination of flows as far as they can be performed in isolation.
Symbolic Activities and Architecture
Whereas single computations have no impact on architectures, that is not the case for symbolic activities which may involve distributed resources and computation dependencies. The objective is then to identify logical constraints as described by flows and set execution units accordingly. Sequences can then be organized using standard structure operators (local context) or functional connectors for data and control flows between execution units. Partitions should be used to describe variants on roles, flows and object states.
When applied to symbolic activities, synchronization (# qualifier) refers to flow contents, no to be confused with its run-time counterpart, which refers to actual execution.
Execution units can be grouped into application domains together with associated views and business rules, and containers introduced to represent ownership (symbolic) or control (actual) activities.