Objective
Connectors are used for symbolic objects (references), actual ones (channels), symbolic activities (flows), and execution states (transitions). Since those different perspectives are meant to be weaved together, using standard constructs to organize them will greatly improve traceability and transparency. For instance, data and control flows follow symbolic references, persistent or transient, and are supported by channels; transitions are associated to control flows.
Whereas there is much debate about languages and meta-models, the objective here is to look at the problem the other way around, namely the aim is first to identify core relevant features that need to be specified, and only then to select the relevant language constructs.
Coupling
As already noted, a primary concern is to set apart connectors associated with coupling or synchronization constraints:
- Regarding symbolic objects, a strong coupling (aka composite structure) means an exclusive and non mutable relationship, while a weak one (aka aggregate) corresponds to an exclusive yet mutable relationship.
- Regarding activity flows, composition should be used for tightly coupled message communication (aka synchronous), and aggregate for loosely coupled message communication (aka asynchronous). In other words, a strong coupling connects activities performed within the same execution context while a weak one points to a dependent activity that can be executed independently.
- Since execution states and transitions are often used informally, it may be useful to make a distinction between nondescript transitions, and those meant to be crossed instantly and exclusively (strong coupling), or just exclusively (weak coupling).
- The same reasoning applies to channels, with composite ones for proprietary communication from the source (strong coupling), and aggregate ones for protected yet transferable channels.
Depending on modeling language, coupling archetypes may be associated with explicit notation, eg UML’s diamonds, stereotypes, and/or multiplicities.
Structural Integrity Constraints
From an architectural perspective, one must set apart structural integrity constraints from functional ones. The former deal with objects (persistent or transient) and can be managed at architecture level, independently of the specificities of business domains and processes, the latter necessitate access to object features and semantics.
UML uses diamonds to describe structural integrity constraints. An additional notation (#) may be necessary to indicate bound identities between objects belonging to different domains.
To take documents as an example:
- A document is (partially) identified by its author (from another domain).
- A document contains a summary (local) and parts (exclusive but mutable ownership)
- Parts contains other parts (exclusive but mutable ownership), paragraphs (exclusive and frozen ownership), and illustrations (from another domain).
Connectors can also be stereotyped according set-based constraints:
- Collections (*): for structural or functional sets.
- Exclusive connectors: for non overlapping partitions.
- Inclusions: for subsets and subtypes.
Multiple Composition
A special mention is to be made for shared (aka multiple, aka cross) composition which describe objects whose identity is defined by two or more references, in other words components that belongs to (i.e are owned by) more than a single root. In UML it is represented by association class. It would be interesting to see how that constructs could be generalized to other types of connectors: communication channels, data and control flows, and state transitions.
Partitions
Considering that partitions are symbolic constructs, they can only be connected to symbolic representations of objects (typologies) or activities (control tables). Yet, those targets may themselves represent actual or symbolic objects or activities. Whereas not strictly necessary, it may be helpful to distinguish connectors supporting partitions.
Multiplicity
Multiplicity, as used with relationships between actual or symbolic objects to set constraints on the number of instances, can be generalized to functional and execution units: forward multiplicity on flows can be associated with number of runs: minimums stand for mandatory or optional runs, maximums may be understood as tokens, ie the number of runs that can use (“consume”) the flow. Moreover, backward multiplicities could be used to document constraints on ownership. Applied to state transitions multiplicities describe how events are consumed.