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
CONSTRAINT An inout Parameter shall be associated with at most one input ActivityParameterNode and at most one output ActivityParameterNode. Unified Modeling Language 2.5.1 Activity, Behavior, Parameter, ActivityParameterNode, ActivityEdge, ParameterDirectionKind::inout, Parameter::direction
CONSTRAINT An in Parameter shall not be associated with an output ActivityParameterNode and an out or return Parameter shall not be associated with an input ActivityParameterNode (though either may be associated with an ActivityParameterNode that does not have .. Unified Modeling Language 2.5.1 Activity, Behavior, Parameter, ActivityParameterNode, ActivityEdge, ParameterDirectionKind::in, ParameterDirectionKind::out, ParameterDirectionKind::return, Parameter::direction
INFO An Activity shall have one ActivityParameterNode corresponding to each in, out, or return Parameter and two ActivityParameterNodes for each inout Parameter. Unified Modeling Language 2.5.1 Activity, Behavior, Parameter, ActivityParameterNode, ActivityEdge, ParameterDirectionKind::in, ParameterDirectionKind::out, ParameterDirectionKind::inout, ParameterDirectionKind::return
INFO (Note that whether an ActivityParameterNode is for input or output is not determined until at least one ActivityEdge is connected to it.) Unified Modeling Language 2.5.1 Activity, Behavior, Parameter, ActivityParameterNode, ActivityEdge
INFO An ActivityParameterNode shall have either all incoming or all outgoing ActivityEdges. An ActivityParameterNode with outgoing edges is an input ActivityParameterNode, while an ActivityParameterNode with incoming edges is an output ActivityParameterNode. Unified Modeling Language 2.5.1 Activity, Behavior, Parameter, ActivityParameterNode, ActivityEdge
INFO Each ActivityParameterNode is associated with one Parameter of the Activity that owns the node. The type of an ActivityParameterNode shall be the same as the type of its associated Parameter. Unified Modeling Language 2.5.1 Activity, Behavior, Parameter, ActivityParameterNode, Type
INFO Within an Activity, inputs to and outputs from an Activity are handled using ActivityParameterNodes. Unified Modeling Language 2.5.1 Activity, Behavior, Parameter, ActivityParameterNode
INFO When the Activity is invoked, values may be passed into the Activity execution on input Parameters (i.e., those with direction in or inout) and values may be passed out .. on output Parameters (i.e., those with direction inout, out or return). Unified Modeling Language 2.5.1 Activity, Behavior, Parameter, ActivityParameterNode, ParameterDirectionKind::in, ParameterDirectionKind::out, ParameterDirectionKind::inout, ParameterDirectionKind::return, Parameter::direction, execution
INFO 15.4.3.2 Activity Parameter Nodes - As a kind of Behavior, an Activity may have Parameters Unified Modeling Language 2.5.1 Activity, Behavior, Parameter, ActivityParameterNode
INFO If the upperBound evaluates to *, then there is no limit on the number of tokens the ObjectNode may hold. Unified Modeling Language 2.5.1 Activity, ObjectNode, token, object token, ObjectNode::upperBound, ValueSpecification, UnlimitedNatural, *
INFO If the removal of one or more tokens brings the number of tokens held below the evaluated upperBound, then the ObjectNode may accept any pending offers up to the limit of the upperBound. Unified Modeling Language 2.5.1 Activity, ObjectNode, token, object token, ObjectNode::upperBound, ValueSpecification, UnlimitedNatural
INFO If the number of tokens already held by the ObjectNode is greater than or equal to the evaluated upperBound, then the ObjectNode shall not accept any further tokens until some of the ones it is holding are removed. Unified Modeling Language 2.5.1 Activity, ObjectNode, token, object token, ObjectNode::upperBound, ValueSpecification, UnlimitedNatural
INFO An ObjectNode may not contain more tokens than specified by its upperBound, if any. If an ObjectNode has an upperBound, then this ValueSpecification shall evaluate to an UnlimitedNatural value. The upperBound is evaluated each time a token is offered ... Unified Modeling Language 2.5.1 Activity, ObjectNode, token, object token, ObjectNode::upperBound, ValueSpecification, UnlimitedNatural
INFO ObjectNodes may also specify an inState set of States. If such a set is specified, then any object token held by the ObjectNode shall have a value with a type that has or inherits a StateMachine as its classifierBehavior that has all of the states .. Unified Modeling Language 2.5.1 Activity, ObjectNode, ObjectNode::inState, token, object token, StateMachine, BehavioredClassifier::classifierBehavior, instance, state configuration, State
INFO Null tokens (object tokens without a value) satisfy the type of all object nodes. Unified Modeling Language 2.5.1 Activity, ObjectNode, token, object token, TypedElement, null token
INFO ObjectNodes are TypedElements ... If an ObjectNode has a type specified, then any object tokens held by the ObjectNode shall have values that conform to the type of the ObjectNode. If no type is specified, then the values may be of any type. Unified Modeling Language 2.5.1 Activity, ObjectNode, token, object token, TypedElement
INFO An ObjectNode may contain multiple object tokens with the same value. Such tokens are not normally combined (but see the special semantics for DataStoreNodes ...). Unified Modeling Language 2.5.1 Activity, ObjectNode, token, object token, DataStoreNode
CONSTRAINT A token may traverse only one of the outgoing edges. Unified Modeling Language 2.5.1 Activity, ObjectNode, token, object token, ActivityEdge
INFO Except in the case of an output ActivityParameterNode, tokens held by an ObjectNode may leave the node on outgoing ActivityEdges. Unified Modeling Language 2.5.1 Activity, ObjectNode, token, object token, ActivityParameterNode, ActivityEdge
INFO Except in the case of an input ActivityParameterNode ... the tokens held by an ObjectNode arrive from incoming ActivityEdges. Unified Modeling Language 2.5.1 Activity, ObjectNode, token, object token, ActivityParameterNode, ActivityEdge
INFO 15.4.3.1 Object Nodes - An ObjectNode holds object tokens during the course of the execution of an Activity. Unified Modeling Language 2.5.1 Activity, ObjectNode, token, object token
RULE The type, ordering, and multiplicity of the argument and result pins of a CallAction shall be the same as the corresponding Parameters. Unified Modeling Language 2.5.1 CallAction, CallBehaviorAction, CallOperationAction, StartObjectBehaviorAction, Parameter, Behavior, Operation, Pin
RULE The argument Pins of a CallAction are matched, in order, to the sublist of input Parameters, while the result Pins are matched, in order, to the sublist of output Parameters. Unified Modeling Language 2.5.1 CallAction, CallBehaviorAction, CallOperationAction, StartObjectBehaviorAction, Parameter, Behavior, Operation, Pin
RULE Behaviors and Operations have totally ordered lists of owned Parameters, and these Parameters are matched to Pins on a CallAction using that ordering. Unified Modeling Language 2.5.1 CallAction, CallBehaviorAction, CallOperationAction, StartObjectBehaviorAction, Parameter, Behavior, Operation, Pin
SEMANTIC 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 ... Unified Modeling Language 2.5.1 Action, InvocationAction, CallAction, Behavior, CallBehaviorAction, StartObjectBehaviorAction::object, BehavioredClassifier::classifierBehavior, InputPin
SEMANTIC 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. Unified Modeling Language 2.5.1 Action, InvocationAction, CallAction, Behavior, CallBehaviorAction, StartObjectBehaviorAction::object, Behavior, BehavioredClassifier::classifierBehavior, InputPin
SEMANTIC 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. Unified Modeling Language 2.5.1 Action, InvocationAction, CallAction, CallOperationAction, Operation, CallOperationAction::target, InputPin
SEMANTIC 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. Unified Modeling Language 2.5.1 Action, InvocationAction, CallAction, Behavior, CallBehaviorAction
SEMANTIC A CallAction is an InvocationAction that calls a Behavior or an Operation. There are three kinds of CallActions Unified Modeling Language 2.5.1 InvocationAction, CallAction, Behavior, Operation
If it has isUnmarshall=true, then it must have result OutputPins corresponding to each of the attributes of the Signal of the SignalEvent (in order), and the attribute values of the Signal instance associated with an accepted SignalEvent occurrence ... Unified Modeling Language 2.5.1 AcceptEventAction, accept signal action, AcceptEventAction::isUnmarshall, OutputPin, Trigger, SignalEvent, Signal, Classifier::attribute
If an accept signal action has isUnmarshall=false, then it must have a single result OutputPin on which the Signal instance associated with an accepted SignalEvent occurrence is placed. Unified Modeling Language 2.5.1 AcceptEventAction, accept signal action, AcceptEventAction::isUnmarshall, OutputPin, Trigger, SignalEvent, Signal
SEMANTIC If the Trigger on the AcceptEventAction is chosen, then it completes and produces output on any result OutputPins. Unified Modeling Language 2.5.1 Action, AcceptEventAction, Trigger, OutputPin, AcceptEventAction::result
SEMANTIC 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 ... Unified Modeling Language 2.5.1 Behavior, Activity, Action, AcceptEventAction, execution
SEMANTIC 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). Unified Modeling Language 2.5.1 Activity, Action, AcceptEventAction, wait point
SEMANTIC 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 ...) Unified Modeling Language 2.5.1 Action, Behavior, AcceptEventAction, Trigger, Event, context object, execution
SEMANTIC 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. Unified Modeling Language 2.5.1 Action, AcceptEventAction, Trigger, Event, event pool
An AcceptEventAction with a trigger for a SignalEvent is informally called an accept signal action. Unified Modeling Language 2.5.1 AcceptEventAction, accept signal action, AcceptEventAction::isUnmarshall, OutputPin, Trigger, SignalEvent, Signal
NOTATION <assignment-specification> is optional and may be omitted even if the Operation has Parameters. No standard mapping is defined from an assignment specification to the UML abstract syntax. A conforming tool is not required to support this notation. ... Unified Modeling Language 2.5.1 CallEvent, Trigger, Operation
NOTATION <assigned-name> is an implicit assignment of the argument value for the corresponding Parameter of the Operation to a Property or Variable of the context object for the triggered Behavior. Unified Modeling Language 2.5.1 CallEvent, Trigger, Operation
NOTATION A CallEvent is denoted by the name of the triggering Operation, optionally followed by an assignment specification: <call-event> ::= <name> [‘(‘ [<assignment-specification>] ‘)’] <assignment-specification> ::= <assigned-name> [‘,’ <assigned-name>]* Unified Modeling Language 2.5.1 CallEvent, Trigger, Operation
SEMANTIC 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. Unified Modeling Language 2.5.1 OpaqueExpression, computation, language, Behavior, value, textual statement
SEMANTIC 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. Unified Modeling Language 2.5.1 Expression, StringExpression, String, value, LiteralString, StringExpression::subExpression, Expression::operand
CONSTRAINT The substrings are given as either a list of LiteralString operands or as a list of StringExpression subExpressions (but it is not allowed to mix the two). Unified Modeling Language 2.5.1 Expression, StringExpression, String, value, LiteralString, StringExpression::subExpression, Expression::operand
SEMANTIC A StringExpression is an Expression that specifies a String value that is derived by concatenating a list of substrings. Unified Modeling Language 2.5.1 Expression, StringExpression, String, value
SEMANTIC Expressions are ValueSpecifications that specify values resulting from a computation. Unified Modeling Language 2.5.1 Expression, ValueSpecification, computation
SEMANTIC 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. ... Unified Modeling Language 2.5.1 value, notation, LiteralReal, Real, digit, scientific notation
SEMANTIC 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. Unified Modeling Language 2.5.1 value, notation, LiteralReal, Real, decimal, digit
SEMANTIC A LiteralReal is shown in decimal notation or scientific notation. Unified Modeling Language 2.5.1 value, notation, LiteralReal, Real, decimal, scientific notation
SEMANTIC 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.” Unified Modeling Language 2.5.1 value, notation, LiteralUnlimitedNatural, UnlimitedNatural, *, unlimited
SEMANTIC A LiteralUnlimitedNatural is shown either as a sequence of digits or as an asterisk (*), where an asterisk denotes unlimited. Unified Modeling Language 2.5.1 value, notation, LiteralUnlimitedNatural, UnlimitedNatural, *, unlimited, digit
SEMANTIC A LiteralBoolean is shown as either the word “true” or the word “false,” corresponding to its value. Unified Modeling Language 2.5.1 value, notation, LiteralBoolean, Boolean, true, false
SEMANTIC A LiteralInteger is shown as a sequence of digits representing the decimal numeral for the Integer value. Unified Modeling Language 2.5.1 value, notation, LiteralInteger, Integer, decimal, digit, numeral
SEMANTIC 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. Unified Modeling Language 2.5.1 value, notation, LiteralString, character, String
SEMANTIC 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. Unified Modeling Language 2.5.1 value, LiteralNull, null, notation
SEMANTIC A LiteralReal specifies a constant value of the PrimitiveType Real. Unified Modeling Language 2.5.1 value, LiteralReal, PrimitiveType, Real
SEMANTIC A LiteralUnlimitedNatural specifies a constant value of the PrimitiveType UnlimitedNatural. Unified Modeling Language 2.5.1 value, LiteralUnlimitedNatural, PrimitiveType, UnlimitedNatural
SEMANTIC A LiteralBoolean specifies a constant value of the PrimitiveType Boolean. Unified Modeling Language 2.5.1 value, LiteralBoolean, PrimitiveType, Boolean
SEMANTIC A LiteralInteger specifies a constant value of the PrimitiveType Integer. Unified Modeling Language 2.5.1 value, LiteralInteger, PrimitiveType, Integer
SEMANTIC 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. Unified Modeling Language 2.5.1 value, LiteralString, PrimitiveType, String
SEMANTIC 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. Unified Modeling Language 2.5.1 LiteralNull, MultiplicityElement, value
SEMANTIC A LiteralNull is intended to be used to explicitly model the lack of a value. Unified Modeling Language 2.5.1 LiteralNull, value
SEMANTIC 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. Unified Modeling Language 2.5.1 StructuralFeature, AddStructuralFeatureValueAction, StructuralFeatureAction, AddStructuralFeatureValueAction::insertAt, StructuralFeature::isReadonly, MultiplicityElement::/upper, MultiplicityElement::upperValue
SEMANTIC The insertion point is ignored if it is used when isReplaceAll=true. Unified Modeling Language 2.5.1 StructuralFeature, AddStructuralFeatureValueAction, StructuralFeatureAction, AddStructuralFeatureValueAction::insertAt, AddStructuralFeatureValueAction::isReplaceAll
SEMANTIC 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). Unified Modeling Language 2.5.1 StructuralFeature, AddStructuralFeatureValueAction, StructuralFeatureAction, AddStructuralFeatureValueAction::insertAt, MultiplicityElement::isOrdered, MultiplicityElement::isUnique
SEMANTIC The semantics are undefined for a value of 0 or an integer greater than the number of existing values Unified Modeling Language 2.5.1 StructuralFeature, AddStructuralFeatureValueAction, StructuralFeatureAction, AddStructuralFeatureValueAction::insertAt
SEMANTIC A value of unlimited (“*”) for the insertion point means to insert the new value at the end of the sequence. Unified Modeling Language 2.5.1 StructuralFeature, AddStructuralFeatureValueAction, StructuralFeatureAction, AddStructuralFeatureValueAction::insertAt, UnlimitedNatural, multiplicity, *
SEMANTIC 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. Unified Modeling Language 2.5.1 StructuralFeature, AddStructuralFeatureValueAction, StructuralFeatureAction, AddStructuralFeatureValueAction::insertAt
CONSTRAINT If the insertAt InputPin is present, it has type UnlimitedNatural and multiplicity 1..1 Unified Modeling Language 2.5.1 StructuralFeature, AddStructuralFeatureValueAction, StructuralFeatureAction, AddStructuralFeatureValueAction::insertAt, UnlimitedNatural, multiplicity
RULE NOTE. Values of StructuralFeatures may be ordered even if the upper multiplicity is 1. Unified Modeling Language 2.5.1 StructuralFeature, AddStructuralFeatureValueAction, StructuralFeatureAction
RULE Adding a value to an ordered StructuralFeature requires an insertion point for the new value given in the insertAt InputPin, which is required for ordered StructuralFeatures when isReplaceAll is false and omitted for unordered StructuralFeatures. Unified Modeling Language 2.5.1 StructuralFeature, AddStructuralFeatureValueAction, StructuralFeatureAction, AddStructuralFeatureValueAction::insertAt, InputPin
SEMANTIC 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. Unified Modeling Language 2.5.1 StructuralFeature, AddStructuralFeatureValueAction, StructuralFeatureAction, AddStructuralFeatureValueAction::isReplaceAll
RULE If isReplaceAll is true ... The StructuralFeature always has a single value when the Action completes, even if the lower multiplicity of the StructuralFeature is greater than 1. Unified Modeling Language 2.5.1 StructuralFeature, AddStructuralFeatureValueAction, StructuralFeatureAction, AddStructuralFeatureValueAction::isReplaceAll, Action
RULE If isReplaceAll is true, then the existing values of the StructuralFeature are removed before the new value is added, except if the StructuralFeature already contains the new value, in which case it is not removed under this option. Unified Modeling Language 2.5.1 StructuralFeature, AddStructuralFeatureValueAction, StructuralFeatureAction, AddStructuralFeatureValueAction::isReplaceAll
SEMANTIC 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. Unified Modeling Language 2.5.1 StructuralFeature, AddStructuralFeatureValueAction, StructuralFeatureAction, InputPin, CreateLinkAction, Association::ownedEnd, Association::navigableOwnedEnd, Association::memberEnd, Property::owningAssociation, Property::association
CONSTRAINT The value to be added is given on the value InputPin, which is required. This InputPin has the same type as the StructuralFeature and a multiplicity of 1..1 (that is, a single value is added). Unified Modeling Language 2.5.1 StructuralFeature, AddStructuralFeatureValueAction, StructuralFeatureAction, InputPin, multiplicity
SEMANTIC 16.8.3.3 Add Structural Feature Value Actions: An AddStructuralFeatureValueAction is a StructuralFeatureAction for adding a value to a StructuralFeature of an object. Unified Modeling Language 2.5.1 StructuralFeature, AddStructuralFeatureValueAction, StructuralFeatureAction
CONSTRAINT terminate – Entering a terminate Pseudostate implies that the execution of the StateMachine is terminated immediately. The StateMachine does not exit any States nor does it perform any exit Behaviors. Any executing doActivity Behaviors are ... aborted Unified Modeling Language 2.5.1 StateMachine, State, Pseudostate, PseudostateKind::terminate, termination, State::exit, State::doActivity, Behavior, DestroyObjectAction UML
CONSTRAINT shallowHistory Pseudostate can only be defined for composite States and, at most one such Pseudostate can be included in a Region of a composite State. Unified Modeling Language 2.5.1 StateMachine, State, Pseudostate, PseudostateKind::shallowHistory, composite State, Region
CONSTRAINT shallowHistory – ... A single outgoing Transition from this Pseudostate may be defined terminating on a substate of the composite State. This substate is the default shallow history state of the composite State. Unified Modeling Language 2.5.1 StateMachine, State, Pseudostate, PseudostateKind::shallowHistory, composite State, Transition, substate, default shallow history
CONSTRAINT shallowHistory – ... this type of Pseudostate is a kind of variable that represents the most recent active substate of its containing Region, but not the substates of that substate. A Transition terminating on this Pseudostate implies rest Unified Modeling Language 2.5.1 StateMachine, State, Pseudostate, PseudostateKind::shallowHistory, Region, Transition
CONSTRAINT A deepHistory Pseudostate can only be defined for composite States and, at most one such Pseudostate can be contained in a Region of a composite State. Unified Modeling Language 2.5.1 StateMachine, State, Pseudostate, PseudostateKind::deepHistory, composite State, Region
SEMANTIC deepHistory – ... The entry Behaviors of all States in the restored state configuration are performed in the appropriate order starting with the outermost State Unified Modeling Language 2.5.1 StateMachine, State, Pseudostate, PseudostateKind::deepHistory, State::entry
SEMANTIC 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 ... Unified Modeling Language 2.5.1 StateMachine, State, Pseudostate, PseudostateKind::deepHistory, Region
RULE junction – ... If more than one guard evaluates to true, one of these is chosen. The algorithm for making this selection is not defined. Unified Modeling Language 2.5.1 Pseudostate, PseudostateKind::junction, Transition, Transition::guard
CONSTRAINT exitPoint – ... If multiple Transitions from orthogonal Regions within the State terminate on this Pseudostate, then it acts like a join Pseudostate. Unified Modeling Language 2.5.1 State, Pseudostate, PseudostateKind::exitPoint, StateMachine, composite State, Region, State::exit, Behavior
CONSTRAINT Transitions terminating on an exit point within any Region of the composite State or a StateMachine referenced by a submachine State implies exiting of this composite State or submachine State (with execution of its associated exit Behavior). Unified Modeling Language 2.5.1 State, Pseudostate, PseudostateKind::exitPoint, StateMachine, composite State, Region, State::exit, Behavior
CONSTRAINT exitPoint – An exitPoint Pseudostate is an exit point of a StateMachine or composite State that provides encapsulation of the insides of the State or StateMachine. Unified Modeling Language 2.5.1 State, Pseudostate, PseudostateKind::exitPoint, StateMachine, composite State
CONSTRAINT entryPoint – ... NOTE. ... If multiple Regions are involved, the entry point acts as a fork Pseudostate. Unified Modeling Language 2.5.1 State, Pseudostate, PseudostateKind::entryPoint, StateMachine, PseudostateKind::fork
CONSTRAINT entryPoint – ... NOTE. If the owning State has an associated entry Behavior, this Behavior is executed before any behavior associated with the outgoing Transition. Unified Modeling Language 2.5.1 State, Pseudostate, PseudostateKind::entryPoint, StateMachine, Behavior, Transition, State::entry
CONSTRAINT In each Region of the StateMachine or composite State owning the entryPoint, there is at most a single Transition from the entry point to a Vertex within that Region. Unified Modeling Language 2.5.1 State, Pseudostate, PseudostateKind::entryPoint, StateMachine, composite State, Vertex, Transition, Region
SEMANTIC 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. Unified Modeling Language 2.5.1 State, Pseudostate, PseudostateKind::entryPoint, StateMachine, composite State
SEMANTIC, TIP 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. Unified Modeling Language 2.5.1 Pseudostate, PseudostateKind::choice, StateMachine, Transition::guard, [else], ill formed
SEMANTIC 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. Unified Modeling Language 2.5.1 Pseudostate, PseudostateKind::choice, StateMachine, Transition::guard
SEMANTIC 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 ... Unified Modeling Language 2.5.1 Pseudostate, PseudostateKind::choice, StateMachine, dynamic conditional branch, Behavior, compound transition
SEMANTIC 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 ... Unified Modeling Language 2.5.1 Pseudostate, PseudostateKind::choice, Transition, StateMachine, dynamic conditional branch, Transition::guard, Constraint
SEMANTIC (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). Unified Modeling Language 2.5.1 Pseudostate, PseudostateKind::junction, Transition, StateMachine, [else]
SEMANTIC 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 ... Unified Modeling Language 2.5.1 Pseudostate, PseudostateKind::junction, Transition, StateMachine, valid state configuration, state configuration
RULE, SEMANTIC 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. Unified Modeling Language 2.5.1 StateMachine, Pseudostate, PseudostateKind::junction, static conditional branch, Constraint, Transition::guard, compound transition
SEMANTIC .. a junction Pseudostate ... can be used to split an incoming Transition into multiple outgoing Transition segments with different guard Constraints. Unified Modeling Language 2.5.1 StateMachine, Pseudostate, PseudostateKind::junction, Transition, Transition::guard, Constraint
EXAMPLE For example, a junction Pseudostate can be used to merge multiple incoming Transitions into a single outgoing Transition representing a shared continuation path. Unified Modeling Language 2.5.1 Pseudostate, PseudostateKind::junction, Transition, StateMachine