Functional Connectors

Semantics

Contrary to structures, which bind elements whose only meaning is within a single structure, non structural connectors, aka functional connectors, are symbolic operators describing links between independently defined elements.

Depending on nodes, connectors can be used with four different semantics:

• Symbolic references: relationship between symbolic objects.
• Symbolic communication: data or control flows between symbolic activities.
• Actual links: connections between physical objects or locations.
• Actual communications:  synchronization between actual processes.

Symbolic references

To begin with symbolic references, cart repairs are associated to customers (functional connectors) but are linked by aggregates (i.e structure) to staff, assuming they are identified and managed locally disregarding whatever identities or aspects they may have outside this specific business domain.

It must be noted that semantics and identification can differ, ie one object can be partially identified by another one even if their respective semantics are defined independently. Time related objects are typical examples, e.g assignments identified simultaneously by resource, target, and time stamp. Identifying associations are not to be merged with 1,1 multiplicity, obviously a consequence, but they should be modelled explicitly (#).

A special mention must be made for composite, or joint, associations, not to be confused with composite structures: the latter binds a whole with parts identified locally, the former defines an object by its association to two or more independently identified objects. For instance, equipages in chariot races are identified by driver, horse, and chariot.

Contrary to aggregate and composite structures, which target parts whose interpretation depends upon the whole, symbolic references can be used across domains and link artifacts whose semantics are set independently.

Symbolic Flows

Used for transient symbolic communication, connectors describe the contents of flow between activities executed independently, i.e when a single control on targeted objects cannot be guaranteed. As for symbolic references, functional connectors can be used across application domains and link activities whose semantics are set independently (aka polymorphism).

Multiplicity may also be used with flow connectors: minimums stand for mandatory or optional runs, maximums may be understood as tokens, ie the number of runs that can use (“consume”) the flow. For instance, a billing initiate a flow to a collecting activity repeated for multiple payments.

Connectors between objects or activities can themselves be structured by composition or alternatives.

Finally, identifying connectors (#) are used to describe workflows whose activities are identified (fully or partially) by flows content.

State transitions

Used for actual state change, connectors describe transitions as triggered by events. Applied to transitions, identifying connectors (#) are used when transitions are meant to be performed instantly, ie, triggering events have no lifetime (cf real time activities).

Transitions apply to objects (active or passive), agents as described by roles, and activities.When supported by partitions, they can be used to describe control activities.

Communication Channels

Connectors can also describe communication channels between objects or containers, with cardinalities used to specify channel features.

Couplings

Whereas structures are used to group artifacts with bound semantics, connectors can be used to bind identities of artifacts with independent purposes.

• Functional dependency: repairs are partially identified by vehicles.
• Communication dependency: a direct visual between mechanics and schedules.
• Flow dependency: repairing and invoicing constitute a single workflow.
• Time dependency: payments are triggered by invoices (transition) and nothing can interfere (binding transition).

Constraints on Connectors

Strictly speaking, integrity constraints deal with the presence of references while consistency constraints deal with their compatibility. That can be expressed with constraint languages but extending the use of subsets to connectors may be sufficient and offer the benefit of using the same approach for nodes and connectors.

Functional constraints are more problematic since they target variants and as such may involve some kind of specialization. The difficulty is therefore to describe them without making any undue assumptions about symbolic representations to be selected at a later stage. That point is made clear by specialization patterns, and the same reasoning regarding identities should be used if rules are to be defined without anticipating on analysis models.

Constraints bound on identities must be evaluated when objects or processes are created while those limited to features are to be considered when objects are updated or while processes are performed. Moreover, those distinctions lay the ground for specialization without preempting any specific option.

For example, constraints about officer postings can be directly bound to agents (place of birth) or processes (promotions), or associated with facets (engineers) or behaviors (weddings).

• Object identity: Officers cannot command a place in their native region (region is a non mutable feature of both objects).
• Object features: Depot commanders must be engineers (a mutable facet of officers)
• Activity identity: Officers can’t be promoted higher than their post commanders (to be decided before performing the actual activity).
• Operation condition: Officers cannot get lodging compensation for spouses native of the region (to be decided during activity).

Complex constraints should be defined combining those building blocs.

Derived Connectors

Derived connectors are shortcuts defined from sequences of native connectors, with or without qualification rules.