Structures

Objective

Structures are used to hide components whose implementation can be managed independently of the architecture.

Structure elements are meaningless on their own (R. Doisneau)

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.

Sluices are made of two gates and a locking gear; their processing combines two activities strongly bound.

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.

Weak and strong structures vs association

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.

Object structure: sluices states must be represented as well as meters if any; gates and locking don't since there is nothing to record.

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.

Chariots are identified by their body (composition), wheels are physical aggregates (they may used with different chariots), but they don't have symbolic counterparts.

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.

Payments may be collected separately but in fine they must be credited to some invoice.

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.