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 decisionInput : Behavior [0..1] ... A Behavior that is executed to provide an input to guard ValueSpecifications on ActivityEdges outgoing from the DecisionNode. Unified Modeling Language 2.5.1 DecisionNode, DecisionNode::decisionInput, ControlNode, ActivityEdge, Behavior, ValueSpecification, ActivityEdge::guard
INFO A DecisionNode is a ControlNode that chooses between outgoing ActivityEdges for the routing of tokens. Unified Modeling Language 2.5.1 DecisionNode, ControlNode, ActivityEdge, token
INFO The values on such object tokens may be used to affect the control of ExecutableNodes that are the targets of such ControlFlows, though the specific meaning of such values is not defined in this specification Semantics of a Foundational Subset for Executable UML Models 1.4 ObjectNode, ObjectNode::isControlType, ControlFlow, token, object token
INFO If isControlType=true for an ObjectNode, ControlFlows may be incoming to and outgoing from the ObjectNode, objects tokens can come into or go out of the ObjectNode along ControlFlows, and these tokens can flow along ControlFlows reached downstream ... Semantics of a Foundational Subset for Executable UML Models 1.4 ObjectNode, ObjectNode::isControlType, ControlFlow, token, object token
isControl : Boolean [1..1] = false Indicates whether the Pin provides data to the Action or just controls how the Action executes. Unified Modeling Language 2.5.1 Pin, Pin::isControl
INFO Pins for control parameters are regular pins, not UML control pins. This is so the control value can be passed into or out of the action and the invoked behavior, rather than control the starting of the action, or indicating the ending of it. OMG Systems Modeling Language (SysML) 1.6 Behavior, Operation, Pin ControlOperator, ControlValueKind
INFO The control value inputs do not enable or disable the control operator execution based on their value, they only enable based on their presence as data. OMG Systems Modeling Language (SysML) 1.6 Behavior, Operation ControlOperator, ControlValueKind, ControlValueKind::enable, ControlValueKind::disable
When the «controlOperator» stereotype is not applied, the behavior may not have a parameter typed by ControlValue. OMG Systems Modeling Language (SysML) 1.6 Behavior, Operation ControlOperator, ControlValueKind
When the «controlOperator» stereotype is applied to behaviors, the behavior takes control values as inputs or provides them as outputs, that is, it treats control as data OMG Systems Modeling Language (SysML) 1.6 Behavior, Operation ControlOperator
A control operator is a behavior that is intended to represent an arbitrarily complex logical operator that can be used to enable and disable other actions. ... The «controlOperator» stereotype also applies to operations with the same semantics. OMG Systems Modeling Language (SysML) 1.6 Behavior, Operation ControlOperator
INFO Using an InstanceValue in a ValueSpecificationAction is similar to creating an instance using a CreateObjectAction, except that values may be given for the StructuralFeatures of the instance using slots on the InstanceSpecification of the InstanceValue. Unified Modeling Language 2.5.1 Action, ValueSpecificationAction, CreateObjectAction, InstanceValue, InstanceSpecification, Slot, StructuralFeature
INFO a LiteralSpecification may be used in a ValueSpecificationAction to produce a constant value. Unified Modeling Language 2.5.1 Action, ValueSpecificationAction, ValueSpecificationAction::result, LiteralSpecification
INFO 16.4.3.5 Value Specification Actions - A ValueSpecificationAction is an Action that evaluates a ValueSpecification and places the resulting value on its result OutputPin. Unified Modeling Language 2.5.1 Action, ValueSpecificationAction, ValueSpecificationAction::value, ValueSpecificationAction::result, OutputPin
An Interval is a ValueSpecification specified using two other ValueSpecifications, the min and the max. Unified Modeling Language 2.5.1 Interval, Interval::min, Interval::max
INFO In general, a ValueSpecification is a model element that is considered semantically to yield zero or more values. Unified Modeling Language 2.5.1 ValueSpecification
CONSTRAINT 7.11.2.7 LoopNode [1] fuml_loop_node_no_setup_part no setupParts in fUML self.setupPart->isEmpty() Semantics of a Foundational Subset for Executable UML Models 1.4 LoopNode, LoopNode::setupPart fUML
14.5.2 FinalState ... If the enclosing Region is directly contained in a StateMachine and all other Regions in that StateMachine also are completed, then it means that the entire StateMachine behavior is completed. Unified Modeling Language 2.5.1 StateMachine, FinalState, State, Region, enclosing Region
14.5.2 FinalState - A special kind of State, which, when entered, signifies that the enclosing Region has completed. Unified Modeling Language 2.5.1 StateMachine, FinalState, State
A StateMachine or composite State may contain multiple Regions representing behaviors that may occur in parallel. Unified Modeling Language 2.5.1 Region, StateMachine, composite State, Vertex, Transition
A Region is a top-level part of a StateMachine or a composite State, that serves as a container for the Vertices and Transitions of the StateMachine. Unified Modeling Language 2.5.1 Region, StateMachine, composite State, Vertex, Transition
INFO external - Implies that the Transition, if triggered, will exit the composite (source) State. Unified Modeling Language 2.5.1 Transition, TransitionKind, Transition::kind, Enumeration, TransitionKind::external, State::exit, composite State
INFO local - Implies that the Transition, if triggered, will not exit the composite (source) State, but it will exit and re-enter any state within the composite State that is in the current state configuration. Unified Modeling Language 2.5.1 Transition, TransitionKind, Transition::kind, Enumeration, TransitionKind::local, State::entry, State::exit, composite State
INFO An internal Transition can be taken even if the S[t]ateMachine is in one or more Regions nested within the associated State. Unified Modeling Language 2.5.1 Transition, TransitionKind, Transition::kind, Enumeration, TransitionKind::internal, State::entry, State::exit
INFO internal - Implies that the Transition, if triggered, occurs without exiting or entering the source State (i.e., it does not cause a state change). This means that the entry or exit condition of the source State will not be invoked. Unified Modeling Language 2.5.1 Transition, TransitionKind, Transition::kind, Enumeration, TransitionKind::internal, State::entry, State::exit
INFO TransitionKind is an Enumeration type used to differentiate the various kinds of Transitions. Unified Modeling Language 2.5.1 Transition, TransitionKind, Transition::kind, Enumeration, TransitionKind::internal, TransitionKind::local, TransitionKind::external
INFO A Pseudostate is an abstraction that encompasses different types of transient Vertices in the StateMachine graph. A StateMachine instance never comes to rest in a Pseudostate, instead, it will exit and enter the Pseudostate within a single ... step Unified Modeling Language 2.5.1 Vertex, StateMachine, Pseudostate, Abstraction, run-to-completion, Pseudostate::kind, Pseudostate::state, Pseudostate::stateMachine abstraction
INFO A Vertex is an abstraction of a node in a StateMachine graph. It can be the source or destination of any number of Transitions. Unified Modeling Language 2.5.1 Vertex, StateMachine, Transition, DirectedRelationship::/source, DirectedRelationship::/target
CONSTRAINT trigger_with_ports: If a Trigger specifies one or more ports, the event of the Trigger must be a MessageEvent. Unified Modeling Language 2.5.1 Event, Trigger, Trigger::event, Port, Trigger::port, MessageEvent
INFO A Trigger may be qualified by the Port on which the Event occurred. Unified Modeling Language 2.5.1 Event, Trigger, Trigger::event, Port, Trigger::port
INFO A Trigger specifies a specific point at which an Event occurrence may trigger an effect in a Behavior. Unified Modeling Language 2.5.1 Event, Behavior, Trigger, Event occurrence, Trigger::event
INFO The selection and transformation Behaviors on outgoing ObjectFlows can be used to get information out of a DataStoreNode as if a query were being performed. Unified Modeling Language 2.5.1 Activity, DataStoreNode, ObjectFlow::selection, Behavior, ObjectFlow::transformation
INFO Unlike a regular CentralBufferNode, a DataStoreNode contains objects uniquely. Unified Modeling Language 2.5.1 Activity, CentralBufferNode, token, object token, DataStoreNode, token offer
RULE When a DataStoreNode accepts an object token, if that token contains an object with the same identity as an object contained in a token already held by the node, then the duplicate object token shall not be placed on the DataStoreNode. Unified Modeling Language 2.5.1 Activity, token, object token, DataStoreNode, token offer, identity
INFO ... a copy is made of the removed object token, with the same value, and this is immediately placed back onto the DataStoreNode. Thus, the values held by a DataStoreNode appear to persist for the duration of each execution of its containing activity, even Unified Modeling Language 2.5.1 Activity, token, object token, DataStoreNode, token offer, value, execution
RULE When an offer for an object token held by a DataStoreNode is accepted by a downstream object node, the offered token is removed from the DataStoreNode, per the usual CentralBufferNode semantics. However, a copy is made of the removed object token ... Unified Modeling Language 2.5.1 Activity, CentralBufferNode, token, object token, DataStoreNode, token offer
INFO 15.4.3.4 Data Store Nodes - A DataStoreNode is a CentralBufferNode that holds its object tokens persistently while its activity is executing. Unified Modeling Language 2.5.1 Activity, CentralBufferNode, token, object token, DataStoreNode
CONSTRAINT Held object tokens are offered to outgoing flows according to the general ordering rules for ObjectNodes. When an offer for a token is accepted by a downstream object node, that token is removed from the CentralBufferNode and moved to the accepting ... Unified Modeling Language 2.5.1 Activity, CentralBufferNode, token, object token, ObjectFlow
INFO 15.4.3.3 Central Buffer Nodes - A CentralBufferNode acts as a buffer between incoming ObjectFlows and outgoing ObjectFlows. It accepts all object tokens offered to it on all incoming flows, which are then held by the node. Unified Modeling Language 2.5.1 Activity, CentralBufferNode, token, object token, ObjectFlow
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