Snippets (text quotes and extracts from authoritative sources)

A Snippet is a short quote or extract (typically a phrase, a sentence, or at most a few sentences) from an authoritative source document such as a specification, technical manual, or design manual. Throughout this site, content is often related to supporting Snippets and each Snippet page links back to the content pages that reference it! The Snippet and Note concepts are very closely related and they support each other.

The Snippet concept is also at the heart of the Parsing Analysis recipe for UML® and SysML®

Kind Snippet quote/extract Source UML keywords SysML keywords Keywords
INFO However, the same token can only be accepted at one target at a time (unless it is copied, whereupon it is not the same token, see ForkNodes ... and ExecutableNodes ...). Unified Modeling Language 2.5.1 ForkNode, ActivityEdge, ActivityNode::outgoing, ActivityNode, token, ExecutableNode
INFO As an ActivityNode may be the source for multiple ActivityEdges, the same token can be offered to multiple targets. Unified Modeling Language 2.5.1 ActivityEdge, ActivityNode::outgoing, ActivityNode, token
INFO The ActivityEdges going out of ForkNodes continue to hold the tokens they accept until all pending offers have been accepted by their targets. Unified Modeling Language 2.5.1 ForkNode, ActivityEdge, ActivityNode::outgoing, token
CONSTRAINT If a JoinNode does not have a joinSpec, then this is equivalent to a joinSpec Expression with the Boolean operator “and.” That is, the implicit default joinSpec condition is that there is at least one token offered on each incoming ActivityEdge. Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, JoinNode, ActivityNode::incoming, ActivityEdge, JoinNode::joinSpec, Boolean
CONSTRAINT Alternatively, the joinSpec may consist of an Expression with the name of a single Boolean operator and no operands specified. In this case, the value of the joinSpec shall be given by applying the given operator to Boolean values indicating ... Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, JoinNode, ActivityNode::incoming, ActivityEdge, JoinNode::joinSpec, Boolean, Expression
CONSTRAINT If the joinSpec ValueSpecification is given by a textual expression, then the names of the incoming edges may be used to denote ... the value associated with an object token offered from an ObjectFlow (if any). Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, JoinNode, ActivityNode::incoming, ActivityEdge, JoinNode::joinSpec, Boolean, ValueSpecification
CONSTRAINT If the joinSpec ValueSpecification is given by a textual expression, then the names of the incoming edges may be used to denote a Boolean value indicating the presence (true) or absence (false) of an offer from a ControlFlow ... Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, JoinNode, ActivityNode::incoming, ActivityEdge, JoinNode::joinSpec, Boolean, ValueSpecification
CONSTRAINT joinSpec ... This evaluation shall not be interrupted by any new tokens offered during the evaluation, nor shall concurrent evaluations be started when new tokens are offered during an evaluation. The ValueSpecification shall evaluate to a Boolean value. Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, JoinNode, ActivityNode::incoming, ActivityEdge, JoinNode::joinSpec, ValueSpecification, token, Boolean
CONSTRAINT Join nodes may have a joinSpec, which is a ValueSpecification that determines the condition under which the join will emit a token. If a JoinNode has a joinSpec, then this ValueSpecification is evaluated whenever a new token is offered to the JoinNode ... Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, JoinNode, ActivityNode::incoming, ActivityEdge, JoinNode::joinSpec, ValueSpecification, token
INFO a predefined guard “else” (represented as an Expression with “else” as its operator and no operands) may be used for at most one outgoing edge. This guard evaluates to true only if the token is not accepted by any other outgoing edge from the DecisionNode Unified Modeling Language 2.5.1 DecisionNode, Activity Diagram, [else]
CONSTRAINT A DecisionNode accepts tokens on its primary incoming edge and offers them to all its outgoing edges. However, each token offered on the primary incoming edge shall traverse at most one outgoing edge. Tokens are not duplicated. Unified Modeling Language 2.5.1 DecisionNode, ControlNode, ActivityEdge, ActivityNode::incoming, primary incoming edge, ControlFlow, ObjectFlow, token, ActivityNode::outgoing
INFO If the Action is an invocation of a Behavior with streaming Parameters ... the Action execution may consume additional data supplied to InputPins corresponding to streaming input Parameters ... Otherwise ... any additional data on InputPins has no effect Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, execution, InputPin, Action::/input, Parameter::isStreaming
INFO For structured Actions (StructuredActivityNodes ... ), data can remain on InputPins during Action execution, otherwise they are immediately removed from the InputPins by the ActionExecution. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, execution, InputPin, Action::/input, StructuredActivityNode, ActionExecution
INFO The Action execution consumes input data on all InputPins on the Action up to the upper multiplicity for each InputPin. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, execution, InputPin, Action::/input, MultiplicityElement::/upper
INFO However, if the Action is an invocation of a Behavior with streaming Parameters ... then the Action execution may also post data to OutputPins corresponding to streaming output Parameters before completion of the execution ... Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, execution, completion, termination, Action::/output, OutputPin, InvocationAction, Parameter::isStreaming, ParameterDirectionKind::out
INFO When completed, an Action execution provides any output data on the OutputPins of the Action, and it terminates. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, execution, completion, termination, Action::/output, OutputPin
INFO An Action continues executing until it has completed. The detailed semantics of the execution of an Action and the definition of its completion depend on the particular kind of Action being executed. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, execution, completion
INFO The time at which an Action executes and what inputs are accepted by each execution are determined by the kind of Action it is, characteristics of its InputPins, and the Behavior in which it is used. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, execution, Action::/input, InputPin, Behavior
INFO When an Action in an Activity completes execution, object tokens for output data placed on its OutputPins may be offered on any outgoing ObjectFlows from those Pins ... In addition, control tokens shall be offered on any outgoing ControlFlows ... Unified Modeling Language 2.5.1 Action, Activity, OutputPin, ObjectFlow, ObjectNode, ControlFlow, ExecutableNode, execution, completion, run-to-completion
INFO A ValuePin provides a value by evaluating a ValueSpecification ... When the Action is enabled by other means, the ValueSpecifiation of the ValuePin is evaluated, and the result is provided as an input to the Action when it begins execution. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, Pin, InputPin, ValuePin, ValueSpecification, ValuePin::value
INFO When the Action is enabled by other means, values are computed as specified for the ValuePins and ActionInputPins owned by an Action, and the results are provided as inputs to the Action when it begins execution. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, Pin, InputPin, ValuePin, ActionInputPin, execution
INFO ValuePins and ActionInputPins are InputPins, but are not used in the determination of whether an Action is enabled for execution. If an Action has no other way to start execution, simply having ValuePins or ActionInputPins for its inputs will not enable.. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, Pin, InputPin, ValuePin, ActionInputPin, execution
INFO An Action may not put more values into an output in a single execution than the [upper] multiplicity of that OutputPin. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, Pin, OutputPin, Action::/output, execution, MultiplicityElement::/upper
INFO For each execution, an Action cannot terminate itself unless it can put at least as many values into its outputs as required by the multiplicity lower bounds on those OutputPins. Values that may remain on the OutputPins from previous executions are not... Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, Pin, OutputPin, Action::/output, execution, MultiplicityElement::/lower
INFO An OutputPin is a Pin that holds output values produced by an Action. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, Pin, OutputPin, Action::/output
INFO Tokens consumed by an Action are immediately removed from its InputPins when the action begins an execution (except in some cases for StructuredActivityNodes, where tokens may remain on InputPins during the Action execution ...) Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, Pin, InputPin, Action::/input, MultiplicityElement::/lower, execution, StructuredActivityNode, token, control token, object token
INFO The upper multiplicity determines the maximum number of values that can be consumed from an InputPin by a single execution of its Action. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, Pin, InputPin, Action::/input, MultiplicityElement::/upper, execution
INFO An Action cannot start execution if one of its InputPins has fewer values than the lower multiplicity of that InputPin. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, Pin, InputPin, Action::/input, MultiplicityElement::/lower, execution
INFO An InputPin is a Pin that holds input values to be consumed by its Action. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, Pin, InputPin, Action::/input
INFO Action::/output : OutputPin [0..*] ... The ordered set of OutputPins representing outputs from the Action. Unified Modeling Language 2.5.1 Action, Action::/output, OutputPin
INFO An Action may accept inputs and produce outputs, as specified by InputPins and OutputPins of the Action, respectively. Each Pin on an Action specifies the type and multiplicity for a specific input or output of that Action. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, Pin, InputPin, OutputPin, Action::/input, Action::/output, multiplicity, Type
INFO Pins are used to specify the inputs and outputs for Actions. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, Pin, InputPin, OutputPin, Action::/input, Action::/output
INFO An ActivityFinalNode is a FinalNode that stops all flows in an Activity (or StructuredActivityNode, see sub clause 16.11). A token reaching an ActivityFinalNode owned by an Activity terminates the execution of that Activity. Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, FinalNode, termination, token, ActivityFinalNode
INFO A FlowFinalNode is a FinalNode that terminates a flow. All tokens accepted by a FlowFinalNode are destroyed. This has no effect on other flows in the Activity. Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, FinalNode, FlowFinalNode, termination, token
INFO A FinalNode is a ControlNode at which a flow in an Activity stops. A FinalNode shall not have outgoing ActivityEdges. A FinalNode accepts all tokens offered to it on its incoming ActivityEdges. There are two kinds of FinalNode: Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, FinalNode, ActivityFinalNode, FlowFinalNode, ActivityNode::outgoing, ActivityNode::incoming
INFO An OpaqueAction is an Action whose specification may be given in a textual concrete syntax other than UML. An OpaqueAction may also be used as a temporary placeholder before some other kind of Action is chosen. Unified Modeling Language 2.5.1 Activity Diagram, Activity, OpaqueAction, Action
CONSTRAINT All tokens offered on the incoming edges of a MergeNode are offered to the outgoing edge. There is no synchronization of flows or joining of tokens. Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, MergeNode, ActivityNode::outgoing, ActivityNode::incoming, token, control token, object token
CONSTRAINT If the outgoing edge of a MergeNode is a ControlFlow, then all incoming edges must be ControlFlows, and, if the outgoing edge is an ObjectFlow, then all incoming edges must be ObjectFlows. Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, MergeNode, ActivityNode::outgoing, ActivityNode::incoming, ControlFlow, ObjectFlow
CONSTRAINT A MergeNode shall have exactly one outgoing ActivityEdge but may have multiple incoming ActivityEdges. Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, MergeNode, ActivityNode::outgoing, ActivityNode::incoming
INFO A MergeNode is a control node that brings together multiple flows without synchronization. Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, MergeNode
CONSTRAINT If any of the incoming edges of a JoinNode are ObjectFlows, the outgoing edge shall be an ObjectFlow. Otherwise the outgoing edge shall be a ControlFlow. Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, JoinNode, ActivityNode::outgoing, ActivityNode::incoming, ActivityEdge
INFO A JoinNode is a ControlNode that synchronizes multiple flows. A JoinNode shall have exactly one outgoing ActivityEdge but may have multiple incoming ActivityEdges. Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, JoinNode, ActivityNode::outgoing, ActivityNode::incoming, ActivityEdge
INFO Tokens offered to a ForkNode are offered to all outgoing ActivityEdges of the node. If at least one of these offers is accepted, the offered tokens are removed from their original source and the acceptor receives a copy of the tokens. Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, ForkNode, ActivityNode::outgoing, ActivityEdge
CAVEAT If the incoming edge is a ControlFlow, then all outgoing edges shall be ControlFlows and, if the incoming edge is an ObjectFlow, then all outgoing edges shall be ObjectFlows. Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, ForkNode, ActivityNode::incoming, ActivityNode::outgoing, ControlFlow, ObjectFlow
INFO A ForkNode is a ControlNode that splits a flow into multiple concurrent flows. A ForkNode shall have exactly one incoming ActivityEdge, though it may have multiple outgoing ActivityEdges. Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, ForkNode, ActivityNode::incoming, ActivityNode::outgoing
SEMANTIC 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. Unified Modeling Language 2.5.1 Activity, ActivityNode, ExecutableNode, Action, ActivityNode::incoming, ControlFlow
SEMANTIC 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 ...). Unified Modeling Language 2.5.1 Activity, ActivityNode, ObjectNode::isControlType, ObjectNode, ActivityNode::incoming, ActivityNode::outgoing, object token
SEMANTIC ControlNodes act as “traffic switches” managing the flow of tokens across ActivityEdges. Tokens cannot “rest” at ControlNodes (with exceptions for InitialNodes and ForkNodes ...). Unified Modeling Language 2.5.1 Activity, ActivityNode, ControlNode, token, control token, object token, ActivityEdge, InitialNode, ForkNode
SEMANTIC There are three kinds of ActivityNodes: Unified Modeling Language 2.5.1 Activity, ActivityNode, ControlNode, ObjectNode, ExecutableNode
SEMANTIC Unlike ControlFlows, ObjectFlows also provide additional support for multicast/receive, token selection from ObjectNodes and transformation of tokens Unified Modeling Language 2.5.1 Activity, ActivityEdge, ObjectFlow, object token, token, ObjectFlow::selection, ObjectFlow::transformation, ObjectNode, multicast
SEMANTIC An ObjectFlow is an ActivityEdge that can have object tokens passing along it. ObjectFlows model the flow of values between ObjectNodes. Unified Modeling Language 2.5.1 Activity, ActivityEdge, ObjectFlow, object token, token
SEMANTIC 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. Unified Modeling Language 2.5.1 Activity, ActivityEdge, ControlFlow, ActivityNode, ActivityEdge::target, ActivityEdge::source, execution, control token
SEMANTIC A ControlFlow is an ActivityEdge that only passes control tokens (and some object tokens as specified by modelers, see isControlType for ObjectNodes ...). Unified Modeling Language 2.5.1 Activity, ActivityEdge, ControlFlow, ObjectNode::isControlType, control token, object token, ObjectNode
SEMANTIC There are two kinds of ActivityEdges: Unified Modeling Language 2.5.1 Activity, ActivityEdge, ControlEdge, ObjectFlow
SEMANTIC InitialNodes are an exception to the rule that ControlNodes cannot “hold” tokens, but only manage their flow. Unified Modeling Language 2.5.1 Activity, InitialNode, ControlNode, control token, InitialNode
SEMANTIC The outgoing ActivityEdges of an InitialNode must all be ControlFlows. The control token placed on an InitialNode is offered concurrently on all outgoing ControlFlows. Unified Modeling Language 2.5.1 Activity, InitialNode, ControlNode, control token, ActivityEdge, ActivityNode::outgoing, ActivityNode::incoming
SEMANTIC 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 Unified Modeling Language 2.5.1 Activity, InitialNode, ControlNode, control token, ActivityEdge
INFO When an ExecutableNode completes an execution, the control token representing that execution is removed from the ExecutableNode and control tokens are offered on all outgoing ControlFlows of the ExecutableNode. That is, there is an implicit fork ... Unified Modeling Language 2.5.1 Behavior, Activity, Activity Diagram, ExecutableNode, implicit join, ControlFlow, ActivityNode::outgoing, token, control token, implicit fork
INFO In some cases, multiple concurrent executions of an ExecutableNode may be ongoing at one time (see the semantics of isLocallyReentrant=true for Actions ... ). In this case, the ExecutableNode holds one control token for each concurrent execution. Unified Modeling Language 2.5.1 Behavior, Activity, Activity Diagram, ExecutableNode, implicit join, ControlFlow, ActivityNode::incoming, token, control token
INFO While the ExecutableNode is executing, it is considered to hold a single control [token] indicating it is execution [executing]. Unified Modeling Language 2.5.1 Behavior, Activity, Activity Diagram, ExecutableNode, implicit join, ControlFlow, ActivityNode::incoming, token, control token
INFO The effect of object tokens accepted from ControlFlows is not specified (see isControlType for ObjectNodes ...), but the semantics above applies if the effect is to execute the ExecutableNode. Unified Modeling Language 2.5.1 Behavior, Activity, Activity Diagram, ExecutableNode, implicit join, ControlFlow, ActivityNode::incoming, token, object token, ObjectNode
INFO Before an ExecutableNode begins executing, it accepts all tokens offered on incoming ControlFlows. If multiple tokens are being offered on a ControlFlow, they are all consumed. Unified Modeling Language 2.5.1 Behavior, Activity, Activity Diagram, ExecutableNode, implicit join, ControlFlow, ActivityNode::incoming, token, control token, object token
INFO An ExecutableNode shall not execute until all incoming ControlFlows (if any) are offering tokens. That is, there is an implicit join on the incoming Control Flows. Specific kinds of ExecutableNodes may have additional prerequisites ... Unified Modeling Language 2.5.1 Behavior, Activity, Activity Diagram, ExecutableNode, implicit join, ControlFlow, ActivityNode::incoming, token
INFO An ExecutableNode may also consume and produce data, but it must do so through related ObjectNodes (Actions use Pins for this purpose ... Unified Modeling Language 2.5.1 Behavior, Activity, Activity Diagram, ExecutableNode, ActivityNode, ObjectNode, Action, Pin, InputPin, OutputPin
INFO An ExecutableNode is an ActivityNode that carries out a substantive behavioral step of the Activity that contains it. Unified Modeling Language 2.5.1 Behavior, Activity, Activity Diagram, ExecutableNode, ActivityNode, execution
INFO All concrete kinds of ExecutableNodes are Actions ... Unified Modeling Language 2.5.1 Behavior, Activity, Activity Diagram, ExecutableNode, ActivityNode, execution, Action
INFO Generally, the ControlNodes and ObjectNodes in an Activity are largely there to control the sequencing and to manage the flow of data between the ExecutableNodes of the Activity. Unified Modeling Language 2.5.1 Behavior, Activity, Activity Diagram, ExecutableNode, ActivityNode, execution, ControlNode, ObjectNode
INFO An ExecutableNode is a kind of ActivityNode that may be executed as a step in the overall desired behavior of the containing Activity. Unified Modeling Language 2.5.1 Behavior, Activity, Activity Diagram, ExecutableNode, ActivityNode, execution
NOTATION Transitions of the kind internal are not shown explicitly in diagrams. Unified Modeling Language 2.5.1 State, StateMachine, Transition, Vertex, TransitionKind, Transition::kind, TransitionKind::internal, Internal Transition compartment
INFO kind = internal ... This kind of Transition can only be defined if the source Vertex is a State. Unified Modeling Language 2.5.1 State, StateMachine, Transition, Transition::source, Vertex, TransitionKind, Transition::kind, TransitionKind::internal, Internal Transition compartment
INFO kind = internal is a special case of a local Transition that is a self-transition (i.e., with the same source and target States), such that the State is never exited (and, thus, not re-entered), which means that no exit or entry Behaviors are executed ... Unified Modeling Language 2.5.1 State, StateMachine, Transition, Transition::source, Vertex, TransitionKind, Transition::kind, TransitionKind::internal, Internal Transition compartment
INFO kind = local ... However, for local Transitions the target Vertex must be different from its source Vertex. A local Transition can only exist within a composite State. Unified Modeling Language 2.5.1 State, StateMachine, Transition, Transition::source, Vertex, TransitionKind, Transition::kind, TransitionKind::local, composite State, State::/isComposite
INFO kind = local is the opposite of external, meaning that the Transition does not exit its containing State (and, hence, the exit Behavior of the containing State will not be executed). ... Unified Modeling Language 2.5.1 State, StateMachine, Transition, Transition::source, Vertex, TransitionKind, Transition::kind, TransitionKind::local
INFO kind = external means that the Transition exits its source Vertex. If the Vertex is a State, then executing this Transition will result in the execution of any associated exit Behavior of that State. Unified Modeling Language 2.5.1 State, StateMachine, Transition, Transition::source, Vertex, TransitionKind, Transition::kind, TransitionKind::external
INFO The semantics of a Transition depend on its relationship to its source Vertex. Three different possibilities are defined, depending on the value of the Transition’s kind attribute ... Unified Modeling Language 2.5.1 State, StateMachine, Transition, Transition::source, Vertex, TransitionKind, Transition::kind, TransitionKind::external, TransitionKind::internal, TransitionKind::local
INFO When multiple triggers are defined for a Transition, they are logically disjunctive, that is, if any of them are enabled, the Transition will be triggered. Unified Modeling Language 2.5.1 State, StateMachine, Transition, Trigger, Transition::trigger, Event, Event occurrence, Trigger::event
INFO A Transition may own a set of Triggers, each of which specifies an Event whose occurrence, when dispatched, may trigger traversal of the Transition. A Transition trigger is said to be enabled if the dispatched Event occurrence matches its Event type. Unified Modeling Language 2.5.1 State, StateMachine, Transition, Trigger, Transition::trigger, Event, Event occurrence, Trigger::event
INFO Transitions are executed as part of a more complex compound transition that takes a StateMachine execution from one stable state configuration to another. Unified Modeling Language 2.5.1 State, StateMachine, Transition, compound transition
INFO NOTE. The duration of a Transition traversal is undefined, allowing for different semantic interpretations, including both “zero” and non-“zero” time. Unified Modeling Language 2.5.1 State, StateMachine, Transition
INFO It may have an associated effect Behavior, which is executed when the Transition is traversed (executed). Unified Modeling Language 2.5.1 State, StateMachine, Transition, Transition::effect
INFO A Transition is a single directed arc originating from a single source Vertex and terminating on a single target Vertex (the source and target may be the same Vertex), which specifies a valid fragment of a StateMachine Behavior. Unified Modeling Language 2.5.1 State, StateMachine, Transition
INFO Otherwise, the appropriate history entry into the Region is executed (see above). If no default history Transition is defined, then standard default entry of the Region is performed .... Unified Modeling Language 2.5.1 State, StateMachine, Vertex, Pseudostate, history, PseudostateKind::deepHistory, PseudostateKind::shallowHistory, default history mechanism
INFO This is a Transition that originates in the history Pseudostate and terminates on a specific Vertex (the default history state) of the Region containing the history Pseudostate. This Transition is only taken if execution leads to the history Pseudostate a Unified Modeling Language 2.5.1 State, StateMachine, Vertex, Transition, Pseudostate, history, PseudostateKind::deepHistory, PseudostateKind::shallowHistory, default history mechanism
INFO In cases where a Transition terminates on a history Pseudostate when the State has not been entered before (i.e., no prior history) or it had reached its FinalState, there is an option to force a transition to a specific substate, using the default ... Unified Modeling Language 2.5.1 State, StateMachine, Vertex, Pseudostate, history, PseudostateKind::deepHistory, PseudostateKind::shallowHistory, default history mechanism
INFO Shallow history (shallowHistory) represents a return to only the topmost substate of the most recent state configuration, which is entered using the default entry rule. Unified Modeling Language 2.5.1 State, StateMachine, Vertex, Pseudostate, history, PseudostateKind::shallowHistory, substate, default entry rule, state configuration
INFO The effect is the same as if the Transition terminating on the deepHistory Pseudostate had, instead, terminated on the innermost State of the preserved state configuration, including execution of all entry Behaviors encountered along the way. Unified Modeling Language 2.5.1 State, StateMachine, Vertex, Pseudostate, history, PseudostateKind::deepHistory, Region, enclosing Region
INFO Deep history (deepHistory) represents the full state configuration of the most recent visit to the containing Region. Unified Modeling Language 2.5.1 State, StateMachine, Vertex, Pseudostate, history, PseudostateKind::deepHistory, Region, enclosing Region
INFO Two types of history Pseudostates are provided. Unified Modeling Language 2.5.1 State, StateMachine, Vertex, Pseudostate, history, PseudostateKind::deepHistory, PseudostateKind::shallowHistory
INFO If there is no outgoing Transition inside the composite State, then the incoming Transition simply performs a default State entry. Unified Modeling Language 2.5.1 State, StateMachine, Transition, PseudostateKind, PseudostateKind::entryPoint, default entry rule, default State entry
INFO In effect, the latter is a continuation of the external incoming Transition, with the proviso that the execution of the entry Behavior of the composite State (if defined) occurs between the effect Behavior of the incoming Transition and the effect ... Unified Modeling Language 2.5.1 State, StateMachine, Transition, PseudostateKind, PseudostateKind::entryPoint, Vertex, Transition::source, Transition::effect, Behavior
INFO Entry points represent termination points (sources) for incoming Transitions and origination points (targets) for Transitions that terminate on some internal Vertex of the composite State. Unified Modeling Language 2.5.1 State, StateMachine, Transition, PseudostateKind, PseudostateKind::entryPoint, Vertex, Transition::source, Transition::target
INFO If the composite State has an exit Behavior defined, it is executed after any effect Behavior of the incoming inside Transition and before any effect Behavior of the outgoing external Transition. Unified Modeling Language 2.5.1 State, StateMachine, Transition, PseudostateKind, PseudostateKind::exitPoint, Vertex, TransitionKind::external
INFO In a well-formed model, such a Transition should have a corresponding external Transition outgoing from the same exit point, representing a continuation of the terminating Transition. Unified Modeling Language 2.5.1 State, StateMachine, Transition, PseudostateKind, PseudostateKind::exitPoint, Vertex, TransitionKind::external
INFO Exit points are the inverse of entry points. That is, Transitions originating from a Vertex within the composite State can terminate on the exit point. Unified Modeling Language 2.5.1 State, StateMachine, Transition, PseudostateKind, PseudostateKind::exitPoint, Vertex
INFO Regardless of how a State is entered, the StateMachine is deemed to be “in” that State even before any entry Behavior or effect Behavior (if defined) of that State start executing. Unified Modeling Language 2.5.1 State, StateMachine, Transition, State::entry, State::exit, active state configuration, state configuration
INFO If the Transition explicitly enters one or more Regions (in case of a fork), these Regions are entered explicitly and the others by default. Unified Modeling Language 2.5.1 State, StateMachine, Transition, composite State, orthogonal Region, State::/isOrthogonal, Region, default entry rule, PseudostateKind::fork
INFO If the Transition terminates on the edge of the composite State (i.e., without entering the State), then all the Regions are entered using the default entry rule above. Unified Modeling Language 2.5.1 State, StateMachine, Transition, composite State, orthogonal Region, State::/isOrthogonal, Region, default entry rule
INFO If the composite State is also an orthogonal State with multiple Regions, each of its Regions is also entered, either by default or explicitly. Unified Modeling Language 2.5.1 State, StateMachine, Transition, composite State, orthogonal Region, State::/isOrthogonal, Region
INFO Transition::trigger : Trigger [0..*] ... Specifies the Triggers that may fire the transition Unified Modeling Language 2.5.1 State, StateMachine, Transition, Transition::trigger, Trigger
INFO Transition::target : Vertex [1..1] ... Designates the target Vertex that is reached when the Transition is taken. Unified Modeling Language 2.5.1 State, StateMachine, Transition, Vertex, Transition::target