12.3.38 ObjectNode
An object node is an abstract activity node that is part of defining object flow in an activity.
*Generalizations
*Description
An object node is an activity node that indicates an instance of a particular classifier, possibly in a particular state,
may be available at a particular point in the activity. Object nodes can be used in a variety of ways, depending on where
objects are flowing from and to, as described in the semantics section.
Package CompleteActivities
Complete object nodes add support for token selection, limitation on the number of tokens, specifying the state required for
tokens, and carrying control values.
*Attributes
Package CompleteActivities
• ordering : ObjectNodeOrderingKind [1..1] = FIFO Tells whether and how the tokens in the object node are ordered for selection
to traverse edges outgoing from the object node.
• isControlType : Boolean [1..1] = false Tells whether the type of the object node is to be treated as control.
*Associations
Package CompleteActivities
• upperBound : ValueSpecification [1..1] = * The maximum number of tokens allowed in the node. Objects cannot flow into the
node if the upper bound is reached.
*Constraints
Package BasicActivities
[1] All edges coming into or going out of object nodes must be object flow edges.
[2] Object nodes are not unique typed elements.
isUnique = false
Package CompleteActivities
Issue 8040 - Remove constraint on upper bound.
[1] If an object node has a selection behavior, then the ordering of the object node is ordered and vice versa.
[2] A selection behavior has one input parameter and one output parameter. The input parameter must be a bag of elements of
the same type as the object node or a supertype of the type of object node. The output parameter must be the same or a subtype
of the type of object node. The behavior cannot have side effects.
*Semantics
Object nodes may only contain values at runtime that conform to the type of the object node, in the state or states specified,
if any. If no type is specified, then the values may be of any type. Multiple tokens containing the same value may reside
in the object node at the same time. This includes data values. A token in an object node can traverse only one of the outgoing
edges.
An object node may indicate that its type is to be treated as a control value, even if no type is specified for the node.
Control edges may be used with the object node having control type.
Package CompleteActivities
An object node may not contain more tokens than its upper bound. The upper bound must be a LiteralUnlimitedNatural . An upper
bound of * means the upper bound is unlimited. See ObjectFlow for additional rules regarding when objects may traverse the
edges incoming and outgoing from an object node.
The ordering of an object node specifies the order in which tokens in the node are offered to the outgoing edges. This can
be set to require that tokens do not overtake each other as they pass through the node (FIFO), or that they do (LIFO or modeler-defined
ordering). Modeler-defined ordering is indicated by an ordering value of ordered, and a selection behavior that determines
what token to offer to the edges. The selection behavior takes all the tokens in the object node as input and chooses a single
token from those. It is executed whenever a token is to be offered to an edge. Because the behavior is used while offering
tokens to outgoing edges, it may be run many times on the same token before the token is accepted by those edges. This means
the behavior cannot have side effects. The selection behavior of an object node is overridden by any selection behaviors on
its outgoing edges. See ObjectFlow . Overtaking due to ordering is distinguished from the case where each invocation of the
activity is handled by a separate execution of the activity. In this case, the tokens have no interaction with each other,
because they flow through separate executions of the activity. See Activity.
*Notation
Object nodes are notated as rectangles. A name labeling the node is placed inside the symbol, where the name indicates the
type of the object node, or the name and type of the node in the format name:type. Object nodes whose instances are sets of
the name type are labeled as such. Object nodes with a signal as type are shown with the symbol on the right.
name
Set of name
|
|
|
|
|
|
| Object node |
Object node |
Object node |
|
|
|
|
for tokens |
for tokens with |
|
|
|
|
containing sets |
signal as type |
|
|
|
Figure 12.114 - Object node notations
Package CompleteActivities
A name labeling the node indicates the type of the object node. The name can also be qualified by a state or states, which
is to be written within brackets below the name of the type. Upper bounds, ordering, and control type other than the defaults
are notated in braces underneath the object node.
name
name name
[state, state...]
{ordering = LIFO} {upperBound = 2}
Object node for tokens containing Object node Object node objects in specific with a limited with ordering
states other than FIFO
upper bound
Figure 12.115 - Object node notations
Selection behavior is specified with the keyword «selection» placed in a note symbol, and attached to an ObjectNode symbol
as illustrated in the figure below.
name
Figure 12.116 - Specifying selection behavior on an Object node
*Presentation Options
It is expected that the UML 2.0 Diagram Interchange specification will define a metaassociation between model elements and
view elements, like diagrams. It can be used to link an object node to an object diagram showing the classifier that is the
type of the object and its relations to other elements. Tools can use this information in various ways to integrate the activity
and class diagrams, such as a hyperlink from the object node to the diagram, or insertion of the class diagram in the activity
diagram
as desired. See example in Figure 12.127.
*Examples
See examples at ObjectFlow and children of ObjectNode.
Object nodes are introduced to model the flow of objects in an activity.
*Changes from previous UML
ObjectNode replaces and extends ObjectFlow State in UML 1.5. In particular, it and its children support collection of tokens
at runtime, single sending and receipt, and the new pin style of activity model.