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
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
SEMANTIC junction – This type of Pseudostate is used to connect multiple Transitions into compound paths between States. Unified Modeling Language 2.5.1 Pseudostate, PseudostateKind::junction, Transition
SEMANTIC If an Activity has more than one InitialNode, then invoking the Activity starts multiple concurrent control flows, one for each InitialNode. (Additional concurrent flows may begin at input ActivityParameterNodes and enabled ExecutableNodes ... Unified Modeling Language 2.5.1 Activity, InitialNode, ControlNode, ActivityParameterNode, ExecutableNode
RULE An Activity may have more than one InitialNode. Unified Modeling Language 2.5.1 Activity, InitialNode, ControlNode
SEMANTIC An InitialNode is a ControlNode that acts as a starting point for executing an Activity. Unified Modeling Language 2.5.1 Activity, InitialNode, ControlNode
CONSTRAINT The Transitions outgoing from a fork Pseudostate cannot have a guard or a trigger. Unified Modeling Language 2.5.1 Pseudostate, Transition, Transition::guard, Transition::trigger, PseudostateKind::fork
SEMANTIC fork – fork Pseudostates serve to split an incoming Transition into two or more Transitions terminating on Vertices in orthogonal Regions of a composite State. Unified Modeling Language 2.5.1 Pseudostate, Transition, Region, composite State, orthogonal Region, PseudostateKind::fork
SEMANTIC Similar to junction points in Petri nets, join Pseudostates perform a synchronization function, whereby all incoming Transitions have to complete before execution can continue through an outgoing Transition. Unified Modeling Language 2.5.1 Pseudostate, PseudostateKind::join, Transition
CONSTRAINT Transitions terminating on a join Pseudostate cannot have a guard or a trigger. Unified Modeling Language 2.5.1 Pseudostate, PseudostateKind::join, Transition, Transition::guard, Transition::trigger
join – This type of Pseudostate serves as a common target Vertex for two or more Transitions originating from Vertices in different orthogonal Regions. Unified Modeling Language 2.5.1 Pseudostate, PseudostateKind::join, Transition, Region, Vertex
CONSTRAINT There can be at most one initial Vertex in a Region. Unified Modeling Language 2.5.1 PseudostateKind::initial, Region, Vertex
CONSTRAINT initial - ... It is the source for at most one Transition, which may have an associated effect Behavior, but not an associated trigger or guard. Unified Modeling Language 2.5.1 PseudostateKind::initial, Transition, Transition::effect, Transition::guard
SEMANTIC initial - An initial Pseudostate represents a starting point for a Region; that is, it is the point from which execution of its contained behavior commences when the Region is entered via default activation. Unified Modeling Language 2.5.1 PseudostateKind::initial, Region
SEMANTIC 14.2.3.6 FinalState: FinalState is a special kind of State signifying that the enclosing Region has completed. Thus, a Transition to a FinalState represents the completion of the behaviors of the Region containing the FinalState. Unified Modeling Language 2.5.1 FinalState, Transition, Region, enclosing Region, Behavior
SEMANTIC When a Region of the submachine StateMachine reaches the corresponding exit point, the submachine state is exited via this exit point. Unified Modeling Language 2.5.1 State, StateMachine, submachine, ConnectionPointReference, exit point, PseudostateKind::exitPoint, Region
SEMANTIC An exit point connection point reference as the source of a Transition implies that the source of the Transition is the exit point Pseudostate as defined in the submachine of the submachine State that has the exit point connection point defined. Unified Modeling Language 2.5.1 State, StateMachine, submachine, ConnectionPointReference, Transition, DirectedRelationship::/target, exit point, PseudostateKind::exitPoint
SEMANTIC An entry point connection point reference as the target of a Transition implies that the target of the Transition is the entryPoint Pseudostate as defined in the submachine of the submachine State. As a result, the Regions of the submachine ... Unified Modeling Language 2.5.1 State, StateMachine, submachine, ConnectionPointReference, Transition, DirectedRelationship::/target, PseudostateKind::entryPoint, Region
SEMANTIC Connection point references are sources/targets of Transitions implying exits out of/entries into the submachine StateMachine referenced by a submachine State. Unified Modeling Language 2.5.1 State, StateMachine, submachine, ConnectionPointReference, Transition, DirectedRelationship::/source, DirectedRelationship::/target
SEMANTIC Connection point references of a submachine State can be used as sources/targets of Transitions. They represent entries into or exits out of the submachine StateMachine referenced by the submachine State. Unified Modeling Language 2.5.1 State, StateMachine, submachine, ConnectionPointReference, Transition, DirectedRelationship::/source, DirectedRelationship::/target
SEMANTIC 14.2.3.5 ConnectionPointReference ... a connection point reference represents a usage (as part of a submachine State) of an entry/exit point defined in the StateMachine referenced by the submachine State. Unified Modeling Language 2.5.1 State, StateMachine, submachine, entry point, exit point, ConnectionPointReference
SEMANTIC Exiting via a FinalState or by a group Transition has the same meaning as for ordinary composite States. Unified Modeling Language 2.5.1 State, StateMachine, submachine, group Transition, Transition, composite State
RULE a submachine Statemachine can be exited as a result of: reaching its FinalState; triggering of a group Transition originating from a submachine State, or; via any of its exit points. Unified Modeling Language 2.5.1 State, StateMachine, submachine, FinalState, State::exit, group Transition, exit point
CONSTRAINT Any guards associated with these entry point Transitions must evaluate to true in order for the specification to be well formed. Unified Modeling Language 2.5.1 State, StateMachine, submachine, State::/isComposite, State::/isSubmachineState, State::entry, Transition, Transition::guard, entry point
SEMANTIC An entry point is equivalent to a junction Pseudostate (fork in cases where the composite State is orthogonal): Entering via an entry point implies that the entry Behavior of the composite state is executed, followed by the Transition from the entry ... Unified Modeling Language 2.5.1 State, StateMachine, submachine, Pseudostate, State::/isSubmachineState, PseudostateKind::junction, PseudostateKind::fork, State::entry, Vertex, entry point, composite State
SEMANTIC A submachine StateMachine can be entered via its default (initial) Pseudostate or via any of its entry points (i.e., it may imply entering a non-orthogonal or an orthogonal composite State with Regions). Entering via the initial Pseudostate ... Unified Modeling Language 2.5.1 State, StateMachine, submachine, Pseudostate, Region, PseudostateKind::initial, State::/isComposite, State::/isSubmachineState, composite State, entry point
SEMANTIC NOTE. Each submachine State represents a distinct instantiation of a submachine, even when two or more submachine States reference the same submachine. Unified Modeling Language 2.5.1 State, StateMachine, submachine
SEMANTIC The entry, exit, and effect Behaviors and internal Transitions are defined as contained in the submachine State. Unified Modeling Language 2.5.1 State, StateMachine, submachine, State::entry, State::exit, Transition, Transition::effect
SEMANTIC The Regions of the submachine StateMachine are the Regions of the composite State. Unified Modeling Language 2.5.1 State, StateMachine, submachine, Region, composite State
SEMANTIC A submachine State implies a macro-like insertion of the specification of the corresponding submachine StateMachine. It is, therefore, semantically equivalent to a composite State. Unified Modeling Language 2.5.1 State, StateMachine, submachine, composite State
SEMANTIC Each ConnectionPointReference is matched by a corresponding entry or exit point in the referenced submachine StateMachine. This provides the necessary binding mechanism between the submachine invocation and its specification. Unified Modeling Language 2.5.1 State, StateMachine, submachine, ConnectionPointReference, Transition, State::exit, State::entry
SEMANTIC A ConnectionPointReference represents a point on the submachine State at which a Transition either terminates or originates. That is, they serve as targets for incoming Transitions to submachine States, as well as sources for outgoing Transitions ... Unified Modeling Language 2.5.1 State, StateMachine, submachine, ConnectionPointReference, Transition, DirectedRelationship::/target, DirectedRelationship::/source
SEMANTIC The concept of ConnectionPointReference is provided to support binding between the submachine State and the referenced StateMachine. Unified Modeling Language 2.5.1 State, StateMachine, submachine, ConnectionPointReference
SEMANTIC Consequently, they require a more complex binding. This is achieved through the concept of submachine State (i.e., States with isSubmachineState = true), which represent references to corresponding submachine StateMachines. Unified Modeling Language 2.5.1 State, StateMachine, submachine, State::/isSubmachineState
SEMANTIC However, whereas encapsulated composite States and their internals are contained within the StateMachine in which they are defined, submachines are, like programming language macros, distinct Behavior specification ... Unified Modeling Language 2.5.1 State, StateMachine, submachine, Behavior, composite State
SEMANTIC Submachines are a means by which a single StateMachine specification can be reused multiple times. They are similar to encapsulated composite States in that they need to bind incoming and outgoing Transitions to their internal Vertices. Unified Modeling Language 2.5.1 State, StateMachine, submachine, Transition, Vertex
NOTATION Receptions are shown in the receptions compartment using the same notation as for Operations with the keyword «signal». Unified Modeling Language 2.5.1 Reception
NOTATION A required Interface may be shown by the socket notation attached to the Port. Unified Modeling Language 2.5.1 Interface, Usage
NOTATION A provided Interface may be shown using the lollipop notation ... attached to the Port. Unified Modeling Language 2.5.1 Interface, InterfaceRealization
SEMANTIC DataTypes model Types whose instances are distinguished only by their value Unified Modeling Language 2.5.1 Type, DataType
SEMANTIC Features represent structural and behavioral characteristics of Classifiers. Unified Modeling Language 2.5.1 Feature, Classifier, StructuralFeature, BehavioralFeature
CAVEAT ValuePin – Value pins are excluded from fUML because they are redundant with using value specifications to specify values. Semantics of a Foundational Subset for Executable UML Models 1.4 ValuePin, ValueSpecification fUML, Foundational UML, execution, simulation
CONSTRAINT If the triggers of an AcceptEventAction are all for ChangeEvents and/or CallEvents, then the AcceptEventAction has no result OutputPins (unless the AcceptEventAction is an AcceptCallAction ...) Unified Modeling Language 2.5.1 AcceptEventAction, ChangeEvent, CallEvent, Trigger, OutputPin, AcceptCallAction
SEMANTIC Such an AcceptEventAction is terminated when its immediately containing Activity (or StructuredActivityNode) is terminated. Unified Modeling Language 2.5.1 AcceptEventAction, Activity, StructuredActivityNode
SEMANTIC That is, it does not terminate after accepting an Event occurrence and outputting any values (as described above), but continues to wait for another Event occurrence. Unified Modeling Language 2.5.1 AcceptEventAction, Activity
SEMANTIC However, in addition, an AcceptEventAction with no incoming edges remains enabled after it accepts an Event occurrence. Unified Modeling Language 2.5.1 AcceptEventAction, Activity, Event
SEMANTIC If the AcceptEventAction has no incoming edges, by the usual rules, it is enabled when its immediately containing Activity (or StructuredActivityNode) begins execution. Unified Modeling Language 2.5.1 AcceptEventAction, Activity
RULE If an AcceptEventAction is used in an Activity, there are special rules for when it is enabled .. Unified Modeling Language 2.5.1 AcceptEventAction, Activity
CONSTRAINT 7.10.2.2 ActivityEdge [1] fuml_activity_edge_allowed_guards A guard is only allowed if the source of the edge is a DecisionNode. Semantics of a Foundational Subset for Executable UML Models 1.4 ActivityEdge, ActivityEdge::guard
CAVEAT Variables are excluded from fUML because the passing of data between actions can be achieved using object flows. Semantics of a Foundational Subset for Executable UML Models 1.4 Variable
CAVEAT The sole mechanism for asynchronous invocation in fUML is via send signal action. This can be used to achieve the effect of broadcasting and sending objects. Semantics of a Foundational Subset for Executable UML Models 1.4 BroadcastSignalAction, SendObjectAction, SendSignalAction fUML
CONSTRAINT NOTE. Operation referenced in the CallEvent of an AcceptCallAction should not have an associated method Behavior. Otherwise, a call to the Operation will have the immediate effect of executing the method and will not be placed into the event pool ... Unified Modeling Language 2.5.1 AcceptCallAction, Operation, CallEvent, Behavior