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
NOTATION A UseCase is shown as an ellipse, either containing the name of the UseCase or with the name of the UseCase placed below the ellipse. An optional stereotype keyword may be placed above the name. Unified Modeling Language 2.5.1 UseCase, UseCase Diagram, «keyword», Stereotype
EXAMPLE, INFO The use case diagram for “Drive Vehicle” in Figure D.5 depicts the drive vehicle usage of the vehicle system. The subject (HybridSUV) and the actors (Driver, Registered Owner, Maintainer, Insurance Company, DMV) interact to realize the use case. OMG Systems Modeling Language (SysML) 1.6 UseCase, UseCase::subject, Actor, UseCase Diagram HSUV sample problem
INFO UseCase::subject : Classifier [0..*] ... The subjects to which this UseCase applies. Each subject or its parts realize all the UseCases that apply to it. Unified Modeling Language 2.5.1 UseCase, Classifier, UseCase::subject, Classifier::useCase
INFO UseCase::include : Include [0..*]{subsets A_source_directedRelationship::directedRelationship, subsets Namespace::ownedMember} ... The Include relationships owned by this UseCase. Unified Modeling Language 2.5.1 UseCase, UseCase::include, Include
INFO UseCase::extensionPoint : ExtensionPoint [0..*]{subsets Namespace::ownedMember} ... The ExtensionPoints owned by this UseCase. Unified Modeling Language 2.5.1 UseCase, UseCase::extensionPoint, ExtensionPoint
INFO A UseCase specifies a set of actions performed by its subjects, which yields an observable result that is of value for one or more Actors or other stakeholders of each subject. Unified Modeling Language 2.5.1 UseCase
INFO UseCase::extend : Extend [0..*]{subsets A_source_directedRelationship::directedRelationship, subsets Namespace::ownedMember} ... The Extend relationships owned by this UseCase. Unified Modeling Language 2.5.1 UseCase::extend, UseCase, Extend
EXAMPLE, INFO Note how the relationships in this diagram are also reflected in the Automotive Domain Model Block Definition Diagram, Figure D.15. OMG Systems Modeling Language (SysML) 1.6 Connector, Association, Class context diagram, SysML Internal Block Diagram, SysML Block Definition Diagram
EXAMPLE, INFO The associations among the classes may represent abstract conceptual relationships among the entities, which would be refined in subsequent diagrams. OMG Systems Modeling Language (SysML) 1.6 Connector, Association, Class context diagram, SysML Internal Block Diagram
EXAMPLE, INFO Also, a background such as a map can be included to provide additional context. OMG Systems Modeling Language (SysML) 1.6 image context diagram, SysML Internal Block Diagram
EXAMPLE, INFO The spatial relationship of the entities on the diagram sometimes conveys understanding as well, although this is not specifically captured in the semantics. OMG Systems Modeling Language (SysML) 1.6 context diagram, SysML Internal Block Diagram
EXAMPLE, INFO Each model element depicted may include a graphical icon to help convey its intended meaning. OMG Systems Modeling Language (SysML) 1.6 icon, Stereotype, image
EXAMPLE, INFO The «system» and «external» stereotypes are user defined, not specified in SysML, but help the modeler to identify the system of interest relative to its environment. OMG Systems Modeling Language (SysML) 1.6 context diagram, «system», «external»
EXAMPLE, INFO The entities are conceptual in nature during the initial phase of development, but will be refined as part of the development process. OMG Systems Modeling Language (SysML) 1.6 context diagram, SysML Internal Block Diagram
EXAMPLE, INFO The diagram usage enables the modeler or methodologist to specify a unique usage of a SysML diagram type using the extension mechanism described in Annex A, “Diagrams.” OMG Systems Modeling Language (SysML) 1.6 context diagram, SysML Internal Block Diagram
EXAMPLE, INFO The term “context diagram,” in Figure D.4, refers to a user-defined usage of an internal block diagram, which depicts some of the top level entities in the overall enterprise and their relationships. OMG Systems Modeling Language (SysML) 1.6 context diagram, SysML Internal Block Diagram
EXAMPLE, INFO Note that the «view» models contain no model elements of their own, and that changes to the model in other packages are automatically updated in the Operational and Performance Views. OMG Systems Modeling Language (SysML) 1.6 Package, ElementImport HSUV sample problem, View
EXAMPLE, INFO The relationship between the views (OperationalView and PerformanceView) and the rest of the user model are explicitly expressed using the «import» relationship. OMG Systems Modeling Language (SysML) 1.6 Package, ElementImport HSUV sample problem, View
EXAMPLE, INFO Model elements are contained in packages, and relationships between packages (or specific model elements) are shown on this diagram. OMG Systems Modeling Language (SysML) 1.6 Package HSUV sample problem
EXAMPLE, INFO The package diagram (Figure D.3) shows the structure of the model used to evaluate the sample problem. OMG Systems Modeling Language (SysML) 1.6 Package HSUV sample problem
INFO Property::subsettedProperty : Property [0..*] ... The properties of which this Property is constrained to be a subset, if any. Unified Modeling Language 2.5.1 Property, Property::subsettedProperty
INFO Then that set shall be included in (or the same as) a set calculated by eliminating duplicates from the collection of values denoted by the subsettedProperty in the same context. Unified Modeling Language 2.5.1 Property, Property::subsettedProperty
INFO A Property may be marked as the subset of another subsettedProperty. In this case, calculate a set by eliminating duplicates from the collection of values denoted by the subsetting property in some context. Unified Modeling Language 2.5.1 Property, Property::subsettedProperty
INFO A Property may be marked as being a derived union, by setting isDerivedUnion to true. This means that the collection of values denoted by the Property in some context is derived by being the strict union of all of the values denoted ... Unified Modeling Language 2.5.1 Property, Property::isDerivedUnion, Property::subsettedProperty
INFO Property::isDerivedUnion : Boolean [1..1] = false Specifies whether the property is derived as the union of all of the Properties that are constrained to subset it. Unified Modeling Language 2.5.1 Property, Property::isDerivedUnion
INFO Action::/input : InputPin [0..*] ... The ordered set of InputPins representing the inputs to the Action. Unified Modeling Language 2.5.1 Action, Action::/input, InputPin
INFO unit : InstanceSpecification [0..1] A unit, represented by an InstanceSpecification classified by a kind of SysML Unit, in terms of which the magnitudes of other quantities that have the same quantity kind can be stated. OMG Systems Modeling Language (SysML) 1.6 ValueType, ValueType::unit, QuantityKind
INFO quantityKind : InstanceSpecification [0..1] A kind of quantity, represented by an InstanceSpecification classified by a kind of SysML QuantityKind, that may be stated by means of units. A value type may optionally specify a quantity kind without any unit. OMG Systems Modeling Language (SysML) 1.6 ValueType, ValueType::quantityKind, QuantityKind
INFO A SysML ValueType may define its own properties and/or operations, just as for a UML DataType. OMG Systems Modeling Language (SysML) 1.6 DataType, Property, Operation ValueType, Unit, QuantityKind
INFO A quantity kind is a kind of quantity that may be stated in terms of defined units, but does not restrict the selection of a unit to state the value. A unit is a particular value in terms of which a quantity of the same quantity kind may be expressed. OMG Systems Modeling Language (SysML) 1.6 DataType ValueType, Unit, QuantityKind, ValueType::quantityKind, ValueType::unit
INFO SysML ValueType adds an ability to carry a unit of measure and quantity kind associated with the value. OMG Systems Modeling Language (SysML) 1.6 DataType ValueType, Unit, QuantityKind
EXAMPLE, INFO More specific value types can define the concrete data representations that a digital computer can process, such as conventional Float, Integer, or String types. OMG Systems Modeling Language (SysML) 1.6 DataType ValueType, Float, Integer, String
EXAMPLE, INFO For example, the SysML "Real" ValueType expresses the mathematical concept of a real number, but does not impose any restrictions on the precision or scale of a fixed or floating-point representation that expresses this concept. OMG Systems Modeling Language (SysML) 1.6 DataType ValueType, Real
INFO SysML defines ValueType as a stereotype of UML DataType to establish a more neutral term for system values that may never be given a concrete data representation. OMG Systems Modeling Language (SysML) 1.6 DataType ValueType
INFO Value types may be used to type properties, operation parameters, or potentially other elements within SysML. OMG Systems Modeling Language (SysML) 1.6 DataType, Type, Property, Parameter ValueType
INFO Since a value cannot be identified except by means of the value itself, each such value within a model is independent of any other, unless other forms of constraints are imposed. OMG Systems Modeling Language (SysML) 1.6 DataType ValueType
INFO A ValueType defines types of values that may be used to express information about a system, but cannot be identified as the target of any reference. OMG Systems Modeling Language (SysML) 1.6 DataType ValueType
EXAMPLE The explicit structural allocation between the original connectors of Figure D.19 and this new bus architecture is shown in Figure D.39. OMG Systems Modeling Language (SysML) 1.6 Connector allocation, Allocate
EXAMPLE Figure D.22 continues the refinement of this Controller Area Network (CAN) bus architecture using ports. OMG Systems Modeling Language (SysML) 1.6 Signal, Connector, Port FlowProperty, "standard" Port
EXAMPLE Figure D.21 is an incomplete first step in the refinement of this bus architecture, as it begins to specify the flow properties for InternalCombustionEngine, the Transmission, and the ElectricalPowerController. OMG Systems Modeling Language (SysML) 1.6 Signal, Connector, Port FlowProperty, "standard" Port
EXAMPLE For purposes of example, the ports, flows, and related point-to-point connectors in Figure D.19 are being refined into a common bus architecture. For this example, ports with flow properties have been used to model the bus architecture. OMG Systems Modeling Language (SysML) 1.6 Signal, Connector, Port FlowProperty, "standard" Port, HSUV sample problem
EXAMPLE This single signal carries the temperature, rpm, and knockSensor information of the engine. OMG Systems Modeling Language (SysML) 1.6 Signal
CONSTRAINT If the primary incoming edge of a DecisionNode is a ControlFlow, then all outgoing edges shall be ControlFlows and, if the primary incoming edge is an ObjectFlow, then all outgoing edges shall be ObjectFlows. Unified Modeling Language 2.5.1 DecisionNode, ControlNode, ActivityEdge, ActivityNode::incoming, primary incoming edge, ControlFlow, ObjectFlow
SEMANTIC If it has two incoming edges, then one shall be identified as the decisionInputFlow, the other being called the primary incoming edge. If the DecisionNode has only one incoming edge, then it is the primary incoming edge. Unified Modeling Language 2.5.1 DecisionNode, ControlNode, ActivityEdge, ActivityNode::incoming, primary incoming edge, DecisionNode::decisionInputFlow
SEMANTIC A DecisionNode shall have at least one and at most two incoming ActivityEdges, and at least one outgoing ActivityEdge. Unified Modeling Language 2.5.1 DecisionNode, ControlNode, ActivityNode::outgoing, ActivityNode::incoming, ActivityEdge
SEMANTIC 15.3.3.6 Decision Nodes - A DecisionNode is a ControlNode that chooses between outgoing flows. Unified Modeling Language 2.5.1 DecisionNode, ControlNode, token, ActivityNode::outgoing, ObjectFlow, ControlFlow
CONSTRAINT A decisionInput Behavior has no out parameters, no inout parameters, and one return parameter. Unified Modeling Language 2.5.1 DecisionNode, Behavior, DecisionNode::decisionInput, Behavior::inputParameters(), Behavior::outputParameters(), Behavior::ownedParameter, Parameter, Parameter::direction, ParameterDirectionKind::in, ParameterDirectionKind::out, ParameterDirectionKind::inout, ParameterDirectionKind::return
CONSTRAINT incoming_control_one_input_parameter If the DecisionNode has a decisionInputFlow and an incoming ControlFlow, then any decisionInput Behavior has one in Parameter ... Unified Modeling Language 2.5.1 DecisionNode, ActivityEdge, ActivityNode::incoming, ControlFlow, DecisionNode::decisionInputFlow, DecisionNode::decisionInput, Parameter, Parameter::direction, ParameterDirectionKind::in, Behavior::inputParameters(), Behavior, TypedElement, object token, token, TypedElement::type, Type
CONSTRAINT DecisionNode::incoming_outgoing_edges A DecisionNode has one or two incoming ActivityEdges and at least one outgoing ActivityEdge. Unified Modeling Language 2.5.1 DecisionNode, ActivityEdge, ActivityNode::incoming, ActivityNode::outgoing
CONSTRAINT two_input_parameters If the DecisionNode has a decisionInputFlow and a second incoming ObjectFlow, then any decisionInput has two in Parameters ... Unified Modeling Language 2.5.1 DecisionNode, ObjectFlow, ObjectNode, ActivityNode::incoming, ActivityEdge, DecisionNode::decisionInputFlow, TypedElement, object token, token, TypedElement::type, Type
CONSTRAINT decision_input_flow_incoming The decisionInputFlow of a DecisionNode must be an incoming ActivityEdge of the DecisionNode. Unified Modeling Language 2.5.1 DecisionNode, ControlFlow, ObjectNode, ActivityNode::incoming, ActivityEdge, DecisionNode::decisionInputFlow
CONSTRAINT DecisionNode::edges The ActivityEdges incoming to and outgoing from a DecisionNode, other than the decisionInputFlow (if any), must be either all ObjectFlows or all ControlFlows. Unified Modeling Language 2.5.1 DecisionNode, ControlFlow, ObjectNode, ActivityNode::incoming, ActivityEdge, DecisionNode::decisionInputFlow
CONSTRAINT zero_input_parameters If the DecisionNode has no decisionInputFlow and an incoming ControlFlow, then any decisionInput Behavior has no in parameters. Unified Modeling Language 2.5.1 DecisionNode, DecisionNode::decisionInputFlow, ControlFlow, DecisionNode::decisionInput, Behavior, Parameter, ParameterDirectionKind::in, ActivityNode::incoming, Behavior::ownedParameter, Behavior::inputParameters()
INFO decisionInputFlow : ObjectFlow [0..1] ... An additional ActivityEdge incoming to the DecisionNode that provides a decision input value for the guards ValueSpecifications on ActivityEdges outgoing from the DecisionNode. Unified Modeling Language 2.5.1 DecisionNode, DecisionNode::decisionInputFlow, ControlNode, ActivityEdge, ObjectFlow, ValueSpecification, ActivityEdge::guard
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