12.3.37 ObjectFlow
An object flow is an activity edge that can have objects or data passing along it.
*Generalizations
•
ActivityEdge (from BasicActivities , CompleteActivities , CompleteStructuredActivities , IntermediateActivities ) on
page 338.
*Description
An object flow models the flow of values to or from object nodes.
Package CompleteActivities
Object flows add support for multicast/receive, token selection from object nodes, and transformation of tokens.
*Attributes
Package CompleteActivities
• isMulticast : Boolean [1..1] = false Tells whether the objects in the flow are passed by multicasting.
• isMultireceive : Boolean [1..1] = false Tells whether the objects in the flow are gathered from respondents to multicasting.
*Associations
Package CompleteActivities
*Constraints
Package BasicActivities
[1] Object flows may not have actions at either end.
[2] Object nodes connected by an object flow, with optionally intervening control nodes, must have compatible types. In particular,
the downstream object node type must be the same or a supertype of the upstream object node type.
[3] Object nodes connected by an object flow, with optionally intervening control nodes, must have the same upper bounds.
Package CompleteActivities
[1] An edge with constant weight may not target an object node, or lead to an object node downstream with no intervening
actions, that has an upper bound less than the weight.
[2] A transformation behavior has one input parameter and one output parameter. The input parameter must be the same or a
supertype of the type of object token coming from the source end. The output parameter must be the same or a subtype of the
type of object token expected downstream. The behavior cannot have side effects.
[3] An object flow may have a selection behavior only if it has an object node as a source.
[4] A selection behavior has one input parameter and one output parameter. The input parameter must be a bag of elements of
the same or a supertype of the type of source object node. The output parameter must be the same or a subtype of the type
of source object node. The behavior cannot have side effects.
[5] isMulticast and isMultireceive cannot both be true.
*Semantics
Package BasicActivities
See semantics inherited from ActivityEdge . An object flow is an activity edge that only passes object and data tokens. Tokens
offered by the source node are all offered to the target node, subject to the restrictions inherited from ActivityEdge .
Two object flows may have the same object node as source. In this case the edges will compete for objects. Once an edge takes
an object from an object node, the other edges do not have access to it. Use a fork to duplicate tokens for multiple uses.
Package CompleteActivities
If a transformation behavior is specified, then each token offered to the edge is passed to the behavior, and the output of
the behavior is given to the target node for consideration instead of the token that was input to the transformation behavior.
Because the behavior is used while offering tokens to the target node, it may be run many times on the same token before the
token is accepted by the target node. This means the behavior cannot have side effects. It may not modify objects, but it
may for example, navigate from one object to another, get an attribute value from an object, or replace a data value with
another. Transformation behaviors with an output parameter with multiplicity greater than 1 may replace one token with many.
If a selection behavior is specified, then it is used to offer a token from the source object node to the edge, rather than
using object node’s ordering. It has the same semantics as selection behavior on object nodes. See ObjectNode. See application
at DataStoreNode .
Issue 8257 - replace ‘receiving is’ with ‘multireceiving are’
Multicasting and multireceiving are used in conjunction with partitions to model flows between behaviors that are the responsibility
of objects determined by a publish and subscribe facility. To support execution the model must be refined to specify the particular
publish/subscribe facility
employed. This is illustrated in the Figure 12.113 on page 408.
*Notation
Issue 8859 - add more explanations about the notation and update figure
An object flow
is notated by an arrowed line. In Figure 12.107, upper right, the two object flow
arrows denote a single object flow edge between two pins in the underlying model, as shown in the lower middle of the figure.
See also the
discussion on Figure 12.120 on page 418.
Object flow arrow Two object flow arrows linking (without activity nodes) object nodes and actions
An object flow arrow linking two object node pins.
Figure 12.107 - Object flow notations
Package CompleteActivities
Selection behavior is specified with the keyword «selection» placed in a note symbol, and attached to the appropriate objectFlow
symbol as illustrated in the figure below.
Figure 12.108 - Specifying selection behavior on an Object flow
*Presentation Options
To reduce clutter in complex diagrams, object nodes may be elided. The names of the invoked behaviors can suggest their parameters.
Tools may support hyperlinking from the edge lines to show the data flowing along them, and show a small square above the
line to indicate that pins are elided, as illustrated in the figure below. Any adornments that would normally be near the
pin, like effect, can be displayed at the ends of the flow lines.
With explicit pins With pins elided
Figure 12.109 - Eliding objects flowing on the edge
*Examples
In the example on the left below, the two arrowed lines are both object flow edges. This indicates that order objects flow
from Fill Order to Ship Order. In the example on the right, the one arrowed line starts from the Fill Order object node pin
and ends at Ship Order object node pin. This also indicates that order objects flow from Fill Order to Ship Order.
Order Order Order
Figure 12.110 - Object flow example
On the left, the example below shows the Pick Materials activity provides an order along with its associated materials for
assembly. On the right, the object flow has been simplified through eliding the object flow details.
With explicit pins With elided pins
Figure 12.111 - Eliding objects flowing on the edge
Package CompleteActivities
Issue 8257 - replace ‘selection, then’ with ‘transformation’
In the figure below, two examples of selection behavior are illustrated. The example on the left indicates that the orders
are to be shipped based on order priority—and those with the same priority should be filled on a first-in/first-out (FIFO)
basis. The example on the right indicates that the result of a Close Order activity produces closed order objects, but the
Send Customer Notice activity requires a customer object. The transformation, specifies that a query operation that takes
an Order evaluates the customer object via the Order.customer:Party association.
Order
Order Order
Figure 12.112 - Specifying selection behavior on an Object flow
In the example below, the Requests for Quote (RFQs) are sent to multiple specific sellers (i.e., is multicast) for a quote
response by each of the sellers. Some number of sellers then respond by returning their quote response. Since multiple responses
can be received, the edge is labeled for the multiple-receipt option. Publish/subscribe and other brokered mechanisms can
be handled using the multicast and multireceive mechanisms. Note that the swimlanes are an important feature for indicating
the subject and source of this.
Figure 12.113 - Specifying multicast and multireceive on the edge
Object flow is introduced to model the flow of data and objects in an activity.
*Changes from previous UML
Explicitly modeled object flows are new in UML 2.0. They replace the use of (state) Transition in UML 1.5 activity modeling.
They also replace data flow dependencies from UML 1.5 action model.