13.1.1 Chain (of actions): A sequence of actions within an activity where, for each adjacent pair of actions, occurrence of the first action is necessary for the occurrence of the second action.
13.1.2 Thread: A chain of actions, where at least one object participates in all the actions of the chain.
An object may have associated with it one single thread or many threads simultaneously.
13.1.3 Joining action: An action shared between two or more chains resulting in a single chain.
13.1.4 Dividing action: An action which enables two or more chains.
There are two cases of a dividing action, depending on whether the enabled chains are required to join eventually.
13.1.5 Forking action: A dividing action, where the enabled chains must (subject to failure) eventually join each other, i.e. the enabled chains cannot join other chains and they cannot terminate separately.
13.1.6 Spawn action: A dividing action, where the enabled chains will not join. The enabled chains may interact and they may terminate separately.
13.1.7 Head action: In a given activity, an action that has no predecessor.
13.1.8 Subactivity: A subgraph of an activity which is itself an activity and which satisfies the following condition. For any pair of fork-join actions in the parent acitivity, if one of these actions is included in the subgraph, then both must be included in the subgraph.
The concepts introduced here are illustrated in Figure 2.
13.2.1 Establishing behaviour: The behaviour by which a given contract is put in place between given objects. An establishing behaviour can be
a) explicit, resulting from the interactions of objects that will take part in the contract; or
b) implicit, being performed by an external agency (e.g. a third party object, not taking part in the contract) or having been performed in a previous epoch.
NOTES
1 - Negotiation is an example of a particular kind of establishing behaviour in which information is exchanged in the process of reaching a common view of permitted future behaviour.
2 - Publication is an example of a particular kind of establishing behaviour in which information is distributed from one object to a number of others.
3 - Explicit establishing behaviour must include an instantiation of the template associated with the contract. This may follow a possible negotiation/publication about which contract to set up and which template to instantiate, and with what parameters.
13.2.2 Enabled behaviour: The behaviour characterizing a set of objects which becomes possible as a result of establishing behaviour.
The enabled behaviour will not necessarily be the same for all objects.
An object may be in a number of contractual contexts simultaneously; the behaviour is constrained to the intersection of the behaviours prescribed by each contractual context.
NOTE - In OSI, the concept of a presentation context is an example of a contractual context which can be established at connection establishment time or subsequently.
13.2.4 Liaison: The relationship between a set of objects which results from the performance of some establishing behaviour; the state of having a contractual context in common.
A liaison is characterized by the corresponding enabled behaviour.
NOTES
1 - Examples of liaisons which result from different establishing behaviours are
a) a dialogue (as in OSI-TP);
b) a binding (see 13.4.2);
c) a distributed transaction (as in OSI-TP);
d) an (N)-connection (as in OSI);
e) an association between (N)-entities enabling them to participate in (N)-connectionless communication (as in OSI);
f) a relationship between files and processes which access the files.
2 - Certain behaviours may be contingent on the establishment of multiple related liaisons. For example, a distributed transaction may depend on both the liaison between the transaction users and the supporting association. The liaison between the transaction users (the distributed transaction) may continue to exist, but be inactive, when the association is broken.
3 - A liaison may involve more than two objects. The objects involved in a liaison do not necessarily all have equivalent roles. Thus there may be liaisons for the collection or distribution of information. The number of participants and the roles of the participants are determined by the contract expressed by the liaison.
4 - There is a duality between contractual context and contractual obligation acceptance of specification and enabled behaviour. In practice structures may be arbitrarily nested and an engagement liaison at one level can also agree a contract which permits an inner level liaison.
13.2.5 Terminating behaviour: The behaviour which breaks down a liaison and repudiates the corresponding contractual context and the corresponding contract.
A terminating behaviour must be explicitly identified as such in the contract if the establishing behaviour was explicit.
Identification of causality allows the categorization of roles of interacting objects. This clause gives a basic set of roles.
Causality implies a constraint on each behaviour of the participating objects while they are interacting. Causality will be identified in the definition of classes (or sub classes) to which interacting objects belong, or in the refinement of templates for their classes (or subclasses).
13.3.1 Initiating object (with respect to a communication): An object causing a communication.
NOTE - The identification of an initiating object with respect to a communication involves an interpretation of the intent of the communication.
13.3.2 Responding object: An object taking part in a communication, which is not the initiating object.
13.3.3 Producer object (with respect to communication): An object which is the source of the information conveyed.
The usage of this term does not imply any specific communication mechanism.
13.3.4 Consumer object (with respect to communication): An object which is a sink of the information conveyed.
The usage of this term does not imply any specific communication mechanism.
13.3.5 Client object: An object which requests that a function be performed by another object.
13.3.6 Server object: An object which performs some function on behalf of a client object.
Client/server relationships of a different nature (or level of abstraction) may exist between an object and different compositions of the objects with which it communicates.
NOTE - Informally, a server provides a service requested by a client.
13.4.1 Binding behaviour: An establishing behaviour between two or more interfaces (and hence between their supporting objects).
NOTE - "To bind" means "to execute a binding behaviour".
13.4.2 Binding: A contractual context, resulting from a given establishing behaviour.
Establishing behaviour, contractual context and enabled behaviour may involve just two object interfaces or more than two.
An object which initiates an establishing behaviour may or may not take part in the subsequent enabled behaviour.
Enabled behaviour (and, by analogy, contractual context) may be uniform (i.e. each participating object can do the same as every other) or non-uniform (i.e. one participating object has a different role from another, as in client and server).
There is no necessary correspondence between an object which initiates establishing behaviour and a particular role in non-uniform enabled behaviours (e.g. in a client-server contractual context, either object could validly have initiated the establishing behaviour).
13.4.3 Binding precondition: A set of conditions required for the successful execution of a binding behaviour.
The objects performing the binding behaviour must possess identifiers for all the interfaces involved in the binding. There may be additional preconditions.
13.4.4 Unbinding behaviour: A behaviour that terminates a binding, i.e. a terminating behaviour for the binding.
13.4.5 Trading: The interaction between objects in which information about new or potential contracts is exchanged via a third party object. It involves:
a) exporting: the provision of an identifier to an interface which is claimed to meet some statement of requirements (i.e. offer a potential contract);
b) importing: the provision of an identifier to an interface which matches a given statement of requirements, allowing a future binding behaviour to take place (i.e. the establishment of a contract).
13.5.1 Failure: Violation of a contract.
NOTES
1 - The behaviour specified in the contract is, by definition, the "correct behaviour". A failure is thus a deviation from compliance with the correct behaviour.
2 - The ways an object can fail are called its failure modes. Several types of failure modes can be distinguished: arbitrary failures (non-compliance with the specification - the most general failure mode); omission failure (when expected interactions not take place); crash failures (persistent omission failures); timing failures (incorrectness due to untimely behaviour).
3 - A failure can be perceived differently by different objects in the environment of the object that exhibits it. A failure may be: consistent if all the perceptions of the failure are the same; inconsistent if objects in the environment may have different perceptions of a given failure.
13.5.2 Error: Part of an object state which is liable to lead to failures. A manifestation of a fault (see 13.5.3) in an object.
NOTES
1 - Whether an error will actually lead to a failure depends on the object decomposition, its internal redundancy, and on the object behaviour. Corrective action may prevent an error from causing a failure.
2 - An error may be latent (i.e. not recognized as such) or detected. An error may disappear before being detected.
13.5.3 Fault: A situation that may cause errors to occur in an object.
NOTES
1 - Faults causing an error may appear from the time an object is specified through to the time it is destroyed. Faults in an early epoch (e.g. design faults) may not lead to failure until a later epoch (e.g. execution time).
2 - A fault is either active or dormant. A fault is active when it produces errors. The presence of active faults is determined only by the detection of errors.
3 - Faults can be: accidental (that appear or are created fortuitously) or intentional (created deliberately); physical (due to some physical phenomena) or human-made (resulting from human behaviour); internal (part of an object state that may cause an error) or external (resulting from interference or interaction with the environment); permanent or temporary.
4 - The definitions of fault, error and failure imply, recursively, causal dependencies between faults, errors and failures:
- a fault can lead to an error (it will lead to an error if it becomes active);
- an error can lead to a system's failure (it will lead to a failure unless the system can deal with it);
- a failure occurs when an error affects the correctness of the service delivered by a system (or system component).
13.5.4 Stability: The property that an object has with respect to a given failure mode if it cannot exhibit that failure mode.