ExecutableNodes actually carry out the desired behavior of an Activity. If an ExecutableNode has incoming ControlFlows, then there must be tokens offered on all these flows that it accepts before beginning execution. Source Unified Modeling Language 2.5.1
ObjectNodes hold object tokens accepted from incoming ObjectFlows and may subsequently offer them to outgoing ObjectFlows (with a modeler-specified exception for ControlFlows, see isControlType for ObjectNodes ...). Source Unified Modeling Language 2.5.1
ControlNodes act as “traffic switches” managing the flow of tokens across ActivityEdges. Tokens cannot “rest” at ControlNodes (with exceptions for InitialNodes and ForkNodes ...). Source Unified Modeling Language 2.5.1
Unlike ControlFlows, ObjectFlows also provide additional support for multicast/receive, token selection from ObjectNodes and transformation of tokens Source Unified Modeling Language 2.5.1
An ObjectFlow is an ActivityEdge that can have object tokens passing along it. ObjectFlows model the flow of values between ObjectNodes. Source Unified Modeling Language 2.5.1
ControlFlows are used to explicitly sequence execution of ActivityNodes, as the target ActivityNode cannot receive a control token and start execution until the source ActivityNode completes execution and produces the token. Source Unified Modeling Language 2.5.1
A ControlFlow is an ActivityEdge that only passes control tokens (and some object tokens as specified by modelers, see isControlType for ObjectNodes ...). Source Unified Modeling Language 2.5.1
InitialNodes are an exception to the rule that ControlNodes cannot “hold” tokens, but only manage their flow. Source Unified Modeling Language 2.5.1
The outgoing ActivityEdges of an InitialNode must all be ControlFlows. The control token placed on an InitialNode is offered concurrently on all outgoing ControlFlows. Source Unified Modeling Language 2.5.1
An InitialNode shall not have any incoming ActivityEdges, which means the InitialNodes owned by an Activity will always be enabled when the Activity begins execution and a single control token is placed on each such InitialNode when Activity execution sta Source Unified Modeling Language 2.5.1
A PrimitiveType defines a predefined DataType, without any substructure. A PrimitiveType may have algebra and operations defined outside of UML, for example, mathematically. Source Unified Modeling Language 2.5.1
If it has two incoming edges, then one shall be identified as the decisionInputFlow, the other being called the primary incoming edge. If the DecisionNode has only one incoming edge, then it is the primary incoming edge. Source Unified Modeling Language 2.5.1
A DecisionNode shall have at least one and at most two incoming ActivityEdges, and at least one outgoing ActivityEdge. Source Unified Modeling Language 2.5.1
15.3.3.6 Decision Nodes - A DecisionNode is a ControlNode that chooses between outgoing flows. Source Unified Modeling Language 2.5.1
If the input object is an instantiated Behavior that is not already executing, then it begins executing. If the input object has a classifierBehavior that is not already executing, then it is instantiated and started. In either case ... Source Unified Modeling Language 2.5.1
A StartObjectBehaviorAction is a CallAction that starts the execution either of a directly instantiated Behavior or of the classifierBehavior of an object. The object to be started is taken from the object InputPin. Source Unified Modeling Language 2.5.1
A CallOperationAction is a CallAction that transmits an Operation call request message to the target object, where it may cause the invocation of an associated Behavior. The target object is taken from the target InputPin of the CallOperationAction. Source Unified Modeling Language 2.5.1
A CallBehaviorAction is a CallAction that invokes a Behavior directly, rather than calling a BehavioralFeature that, in turn, results in the invocation of a Behavior. Source Unified Modeling Language 2.5.1
A CallAction is an InvocationAction that calls a Behavior or an Operation. There are three kinds of CallActions Source Unified Modeling Language 2.5.1
If the Trigger on the AcceptEventAction is chosen, then it completes and produces output on any result OutputPins. Source Unified Modeling Language 2.5.1
If a matching Event occurrence for an AcceptEventAction is dispatched from the event pool, then the AcceptEventAction is enabled to continue. However, if the containing Behavior execution has more than one waiting Trigger that matches ... Source Unified Modeling Language 2.5.1
An AcceptEventAction is a wait point ... except only the AcceptEventAction waits, rather than the whole Activity (Activities can have other Actions executing while AcceptEventActions are waiting). Source Unified Modeling Language 2.5.1
The context object for an AcceptEventAction is the context object of the Behavior execution within which the AcceptEventAction is executing (which may be the Behavior execution itself ...) Source Unified Modeling Language 2.5.1
AcceptEventAction is an Action with Triggers for one or more Events. When an AcceptEventAction is executed, it waits for an Event occurrence to be dispatched from the event pool of the context object for its execution that matches one of its Triggers. Source Unified Modeling Language 2.5.1
An OpaqueExpression specifies the computation of a set of values either in terms of a UML Behavior or based on a textual statement in a language other than UML. Source Unified Modeling Language 2.5.1
The String value of a StringExpression is obtained by concatenating, in order, the String values of either the operands or the subExpressions, depending on which is given. Source Unified Modeling Language 2.5.1
A StringExpression is an Expression that specifies a String value that is derived by concatenating a list of substrings. Source Unified Modeling Language 2.5.1
Expressions are ValueSpecifications that specify values resulting from a computation. Source Unified Modeling Language 2.5.1
Scientific notation consists of decimal notation followed by either the letter “e” or “E” and an exponent consisting of an optional sign character followed by one or more digits. ... Source Unified Modeling Language 2.5.1
Decimal notation consists of an optional sign character (+/-) followed by zero or more digits followed optionally by a dot (.) followed by one or more digits. Source Unified Modeling Language 2.5.1
A LiteralReal is shown in decimal notation or scientific notation. Source Unified Modeling Language 2.5.1
Note that “unlimited” denotes the lack of a limit on the value of some element (such as a multiplicity upper bound), not a value of “infinity.” Source Unified Modeling Language 2.5.1
A LiteralUnlimitedNatural is shown either as a sequence of digits or as an asterisk (*), where an asterisk denotes unlimited. Source Unified Modeling Language 2.5.1
A LiteralBoolean is shown as either the word “true” or the word “false,” corresponding to its value. Source Unified Modeling Language 2.5.1
A LiteralInteger is shown as a sequence of digits representing the decimal numeral for the Integer value. Source Unified Modeling Language 2.5.1
A LiteralString is shown as a sequence of characters within double quotes. The String value is the sequence of characters, not including the quotes. The character set used is unspecified. Source Unified Modeling Language 2.5.1
The notation for a LiteralNull varies depending on where it is used. It often appears as the word “null.” Other notations are described elsewhere for specific uses. Source Unified Modeling Language 2.5.1
A LiteralReal specifies a constant value of the PrimitiveType Real. Source Unified Modeling Language 2.5.1
A LiteralUnlimitedNatural specifies a constant value of the PrimitiveType UnlimitedNatural. Source Unified Modeling Language 2.5.1
A LiteralBoolean specifies a constant value of the PrimitiveType Boolean. Source Unified Modeling Language 2.5.1
A LiteralInteger specifies a constant value of the PrimitiveType Integer. Source Unified Modeling Language 2.5.1
A LiteralString specifies a constant value of the PrimitiveType String. Though a String is specified as a sequence of characters, String values are considered to be primitive in UML, so their internal structure is not specified as part of UML semantics. Source Unified Modeling Language 2.5.1
LiteralNull: In the context of a MultiplicityElement with a multiplicity lower bound of 0, this corresponds to the empty set (i.e., a set of no values). It is equivalent to specifying no values for the Element. Source Unified Modeling Language 2.5.1
A LiteralNull is intended to be used to explicitly model the lack of a value. Source Unified Modeling Language 2.5.1
The semantics are undefined for adding a value that violates the upper multiplicity of the StructuralFeature, and for adding a new value to a StructuralFeature with isReadonly=true after initialization of the object that would have the value. Source Unified Modeling Language 2.5.1
The insertion point is ignored if it is used when isReplaceAll=true. Source Unified Modeling Language 2.5.1
Reinserting an existing value at a new position in an ordered, unique StructuralFeature moves the value to that position (this works because such StructuralFeature values are ordered sets). Source Unified Modeling Language 2.5.1
The semantics are undefined for a value of 0 or an integer greater than the number of existing values Source Unified Modeling Language 2.5.1
A value of unlimited (“*”) for the insertion point means to insert the new value at the end of the sequence. Source Unified Modeling Language 2.5.1
An insertion point that is a positive integer less than or equal to the current number of values means to insert the new value at that position in the sequence of existing values, with the integer 1 meaning the new value will be first in the sequence. Source Unified Modeling Language 2.5.1
If isReplaceAll is false and the StructuralFeature is unordered and unique, then adding a value that is already contained in the StructuralFeature has no effect. Source Unified Modeling Language 2.5.1
If the StructuralFeature is an Association end, the semantics are the same as for a CreateLinkAction ..., where the participants in the link are the object being acted on and the new value. Source Unified Modeling Language 2.5.1
16.8.3.3 Add Structural Feature Value Actions: An AddStructuralFeatureValueAction is a StructuralFeatureAction for adding a value to a StructuralFeature of an object. Source Unified Modeling Language 2.5.1
deepHistory – ... The entry Behaviors of all States in the restored state configuration are performed in the appropriate order starting with the outermost State Source Unified Modeling Language 2.5.1
deepHistory – This type of Pseudostate is a kind of variable that represents the most recent active state configuration of its owning Region. ... a Transition terminating on this Pseudostate implies restoring the Region to that same state ... Source Unified Modeling Language 2.5.1
entryPoint – An entryPoint Pseudostate represents an entry point for a StateMachine or a composite State that provides encapsulation of the insides of the State or StateMachine. Source Unified Modeling Language 2.5.1
choice – ... If none of the guards evaluates to true, then the model is considered ill formed. To avoid this, it is recommended to define one outgoing Transition with the predefined “else” guard for every choice Pseudostate. Source Unified Modeling Language 2.5.1
choice – ... If more than one guard evaluates to true, one of the corresponding Transitions is selected. The algorithm for making this selection is not defined. Source Unified Modeling Language 2.5.1
Consequently, choice is used to realize a dynamic conditional branch. It allows splitting of compound transitions into multiple alternative paths such that the decision on which path to take may depend on the results of Behavior executions performed ... Source Unified Modeling Language 2.5.1
choice – This type of Pseudostate is similar to a junction Pseudostate ... and serves similar purposes, with the difference that the guard Constraints on all outgoing Transitions are evaluated dynamically ... Source Unified Modeling Language 2.5.1
(As a way of avoiding this situation in some cases, it is possible to associate a predefined guard denoted as “else” with at most one outgoing Transition. This Transition is enabled if all the guards attached to the other Transitions evaluate to false). Source Unified Modeling Language 2.5.1
junction – ...It may happen that, for a particular compound transition, the configuration of Transition paths and guard values is such that the compound transition is prevented from reaching a valid state configuration. In those cases, the entire ... Source Unified Modeling Language 2.5.1
NOTE. Such guard Constraints are evaluated before any compound transition containing this Pseudostate is executed, which is why this is referred to as a static conditional branch. Source Unified Modeling Language 2.5.1
.. a junction Pseudostate ... can be used to split an incoming Transition into multiple outgoing Transition segments with different guard Constraints. Source Unified Modeling Language 2.5.1
junction – This type of Pseudostate is used to connect multiple Transitions into compound paths between States. Source Unified Modeling Language 2.5.1
If an Activity has more than one InitialNode, then invoking the Activity starts multiple concurrent control flows, one for each InitialNode. (Additional concurrent flows may begin at input ActivityParameterNodes and enabled ExecutableNodes ... Source Unified Modeling Language 2.5.1
An InitialNode is a ControlNode that acts as a starting point for executing an Activity. Source Unified Modeling Language 2.5.1
fork – fork Pseudostates serve to split an incoming Transition into two or more Transitions terminating on Vertices in orthogonal Regions of a composite State. Source Unified Modeling Language 2.5.1
Similar to junction points in Petri nets, join Pseudostates perform a synchronization function, whereby all incoming Transitions have to complete before execution can continue through an outgoing Transition. Source Unified Modeling Language 2.5.1
initial - An initial Pseudostate represents a starting point for a Region; that is, it is the point from which execution of its contained behavior commences when the Region is entered via default activation. Source Unified Modeling Language 2.5.1
14.2.3.6 FinalState: FinalState is a special kind of State signifying that the enclosing Region has completed. Thus, a Transition to a FinalState represents the completion of the behaviors of the Region containing the FinalState. Source Unified Modeling Language 2.5.1
When a Region of the submachine StateMachine reaches the corresponding exit point, the submachine state is exited via this exit point. Source Unified Modeling Language 2.5.1
An exit point connection point reference as the source of a Transition implies that the source of the Transition is the exit point Pseudostate as defined in the submachine of the submachine State that has the exit point connection point defined. Source Unified Modeling Language 2.5.1
An entry point connection point reference as the target of a Transition implies that the target of the Transition is the entryPoint Pseudostate as defined in the submachine of the submachine State. As a result, the Regions of the submachine ... Source Unified Modeling Language 2.5.1
Connection point references are sources/targets of Transitions implying exits out of/entries into the submachine StateMachine referenced by a submachine State. Source Unified Modeling Language 2.5.1
Connection point references of a submachine State can be used as sources/targets of Transitions. They represent entries into or exits out of the submachine StateMachine referenced by the submachine State. Source Unified Modeling Language 2.5.1
14.2.3.5 ConnectionPointReference ... a connection point reference represents a usage (as part of a submachine State) of an entry/exit point defined in the StateMachine referenced by the submachine State. Source Unified Modeling Language 2.5.1
Exiting via a FinalState or by a group Transition has the same meaning as for ordinary composite States. Source Unified Modeling Language 2.5.1
An entry point is equivalent to a junction Pseudostate (fork in cases where the composite State is orthogonal): Entering via an entry point implies that the entry Behavior of the composite state is executed, followed by the Transition from the entry ... Source Unified Modeling Language 2.5.1
A submachine StateMachine can be entered via its default (initial) Pseudostate or via any of its entry points (i.e., it may imply entering a non-orthogonal or an orthogonal composite State with Regions). Entering via the initial Pseudostate ... Source Unified Modeling Language 2.5.1
NOTE. Each submachine State represents a distinct instantiation of a submachine, even when two or more submachine States reference the same submachine. Source Unified Modeling Language 2.5.1
The entry, exit, and effect Behaviors and internal Transitions are defined as contained in the submachine State. Source Unified Modeling Language 2.5.1
The Regions of the submachine StateMachine are the Regions of the composite State. Source Unified Modeling Language 2.5.1
A submachine State implies a macro-like insertion of the specification of the corresponding submachine StateMachine. It is, therefore, semantically equivalent to a composite State. Source Unified Modeling Language 2.5.1
Each ConnectionPointReference is matched by a corresponding entry or exit point in the referenced submachine StateMachine. This provides the necessary binding mechanism between the submachine invocation and its specification. Source Unified Modeling Language 2.5.1
A ConnectionPointReference represents a point on the submachine State at which a Transition either terminates or originates. That is, they serve as targets for incoming Transitions to submachine States, as well as sources for outgoing Transitions ... Source Unified Modeling Language 2.5.1
The concept of ConnectionPointReference is provided to support binding between the submachine State and the referenced StateMachine. Source Unified Modeling Language 2.5.1
Consequently, they require a more complex binding. This is achieved through the concept of submachine State (i.e., States with isSubmachineState = true), which represent references to corresponding submachine StateMachines. Source Unified Modeling Language 2.5.1
However, whereas encapsulated composite States and their internals are contained within the StateMachine in which they are defined, submachines are, like programming language macros, distinct Behavior specification ... Source Unified Modeling Language 2.5.1
Submachines are a means by which a single StateMachine specification can be reused multiple times. They are similar to encapsulated composite States in that they need to bind incoming and outgoing Transitions to their internal Vertices. Source Unified Modeling Language 2.5.1
DataTypes model Types whose instances are distinguished only by their value Source Unified Modeling Language 2.5.1
Features represent structural and behavioral characteristics of Classifiers. Source Unified Modeling Language 2.5.1
Such an AcceptEventAction is terminated when its immediately containing Activity (or StructuredActivityNode) is terminated. Source Unified Modeling Language 2.5.1
That is, it does not terminate after accepting an Event occurrence and outputting any values (as described above), but continues to wait for another Event occurrence. Source Unified Modeling Language 2.5.1
However, in addition, an AcceptEventAction with no incoming edges remains enabled after it accepts an Event occurrence. Source Unified Modeling Language 2.5.1
If the AcceptEventAction has no incoming edges, by the usual rules, it is enabled when its immediately containing Activity (or StructuredActivityNode) begins execution. Source Unified Modeling Language 2.5.1
