Objective
Structures are used to hide components whose implementation can be managed independently of the architecture.
Structures are Local Constructs
Whereas connectors (aka functional connectors) link elements with independent semantics, structures bind elements whose semantics are set by that structure. That definition hold for any elements, whatever their nature: objects, activities, or links.
As a consequence structures constitute the building blocks of system architectures and should be characterized by non ambiguous archetypes. First and foremost, if proper traceability is to be supported, structures must be rooted by and local to individual identities, be that of objects or activities: strong structures will bind identities to the root, weak structures will let them be recombined. Structure strength can then be combined with the standards of collections, alternatives and joins to define archetypes for objects, activities, and connectors.
The aim of architecture driven modelling is to use a single generic description of structures for objects, activities and connectors so that the consistency and correctness of transient models could be checked against persistent ones. From that (architectural) point of view, structures should be used when parts cannot be used directly but always through the whole, even if its not necessarily the same.
Object Structures
Applied to objects, actual structures refer to physical objects and their components, while symbolic structures refer to object representations and their dependent aspects.
Since symbolic representations are driven by business concerns, the structure of symbolic representations does not necessarily match the structure of the actual ones, with some parts being ignored by symbolic representations. The same reasonning hold for objects features, which are included on a “need to know” basis.
Activity Structures
Activities can be structured just like objects. In that case the root is identified by a time stamp and the set of symbolic representations affected by the activity. Actual structures describe the states and execution paths of business processes and their dependent threads, while symbolic structures describe the actions and processing flows.
As for objects, structured activities are used when parts can only be performed within the whole; otherwise, ie if target activities can be called in different contexts, non-descript flows (data or control) are to be used. Strong (composite) structures mean that whole and part activities must be synchronized, ie they must be run under a single clock, weak (aggregate) structures mean that they don’t have to be synchronized and may be performed independently yet on the same context.
Structure & Synchronization
Synchronization is at the root of architectural concerns as it sets integrity constraints between persistency units and sequencing constraints between execution units. Those constraints can also be defined locally, ie between parts of objects or activities:
Composites of objects are synchronized because their identity is bound to the identity of their owner, aggregates are not since they can be transferred without losing their identity. Those principles apply to actual and symbolic structures.
The same reasoning applies to composite activities, whose execution must be bound to their owner’s execution, while the execution of aggregates ones can be decoupled. Symbolic synchronization deals with flow contents, actual synchronization deals with timing.
Structures & Domains
Since elements of a structure are to be used only through their owner, they must be defined within the same semantic domain if they are to be understood consistently. A special mention is to be made for collections which come with a standard access mechanism and can therefore be used to access set elements across domains.
Structure operators can be applied to actual containers as well as to symbolic ones,