ActivityEdge

Webel: SysML/UML: Dr Darren explains HOWTO use concise 'i'/'o' (input/output) Pin and Parameter naming conventions to promote a signal processing mindset in Activity Diagrams. And HOWTO get them compact.

GOTCHA: UML/SysML: Cameo Simulation Toolkit 19SP3: A [true] or [false] guard on an ActivityEdge MUST be a LiteralBoolean, not just characters typed in, or the evaluation may give unexpected or ill-defined results

SysML Activity extension stereotypes - REFERENCE CARD

Gallery

Tutorial

TRAIL: Webel's ultimate guide to Systems Modeling Language (v1) with MagicDraw/Cameo

Section

11:01: [STUB] Activity modelling extensions in SysML

Slide kind

UML Profile Diagram

When the «probability» stereotype is applied to edges coming out of decision nodes and object nodes, it provides an expression for the probability that the edge will be traversed. These shall be between zero and one inclusive, and add up to one ...

Source

OMG Systems Modeling Language (SysML) 1.6

When the LoopNode begins executing, the tokens on the loopVariableInput InputPins are moved to the corresponding loopVariable OutputPins before the first iteration of the loop.

Source

Unified Modeling Language 2.5.1

A LoopNode may also define a set of loopVariable OutputPins used to hold intermediate values during each loop iteration. These OutputPins may have outgoing ActivityEdges, in order to make the values they hold available within the test and bodyPart ...

Source

Unified Modeling Language 2.5.1

This means that an Activity model in which non-determinacy occurs may be subject to timing issues and race conditions. It is the responsibility of the modeler to avoid such conditions in the construction of the Activity model, if they are not desired.

Source

Unified Modeling Language 2.5.1

If a token is offered to multiple ActivityNodes at the same time, it shall be accepted by at most one of them, but exactly which one is not completely determined by the Activity flow semantics.

Source

Unified Modeling Language 2.5.1

However, the same token can only be accepted at one target at a time (unless it is copied, whereupon it is not the same token, see ForkNodes ... and ExecutableNodes ...).

Source

Unified Modeling Language 2.5.1

As an ActivityNode may be the source for multiple ActivityEdges, the same token can be offered to multiple targets.

Source

Unified Modeling Language 2.5.1

The ActivityEdges going out of ForkNodes continue to hold the tokens they accept until all pending offers have been accepted by their targets.

Source

Unified Modeling Language 2.5.1

If a JoinNode does not have a joinSpec, then this is equivalent to a joinSpec Expression with the Boolean operator “and.” That is, the implicit default joinSpec condition is that there is at least one token offered on each incoming ActivityEdge.

Source

Unified Modeling Language 2.5.1

Alternatively, the joinSpec may consist of an Expression with the name of a single Boolean operator and no operands specified. In this case, the value of the joinSpec shall be given by applying the given operator to Boolean values indicating ...

Source

Unified Modeling Language 2.5.1

If the joinSpec ValueSpecification is given by a textual expression, then the names of the incoming edges may be used to denote ... the value associated with an object token offered from an ObjectFlow (if any).

Source

Unified Modeling Language 2.5.1

If the joinSpec ValueSpecification is given by a textual expression, then the names of the incoming edges may be used to denote a Boolean value indicating the presence (true) or absence (false) of an offer from a ControlFlow ...

Source

Unified Modeling Language 2.5.1

joinSpec ... This evaluation shall not be interrupted by any new tokens offered during the evaluation, nor shall concurrent evaluations be started when new tokens are offered during an evaluation. The ValueSpecification shall evaluate to a Boolean value.

Source

Unified Modeling Language 2.5.1

Join nodes may have a joinSpec, which is a ValueSpecification that determines the condition under which the join will emit a token. If a JoinNode has a joinSpec, then this ValueSpecification is evaluated whenever a new token is offered to the JoinNode ...

Source

Unified Modeling Language 2.5.1

A DecisionNode accepts tokens on its primary incoming edge and offers them to all its outgoing edges. However, each token offered on the primary incoming edge shall traverse at most one outgoing edge. Tokens are not duplicated.

Source

Unified Modeling Language 2.5.1

If any of the incoming edges of a JoinNode are ObjectFlows, the outgoing edge shall be an ObjectFlow. Otherwise the outgoing edge shall be a ControlFlow.

Source

Unified Modeling Language 2.5.1

A JoinNode is a ControlNode that synchronizes multiple flows. A JoinNode shall have exactly one outgoing ActivityEdge but may have multiple incoming ActivityEdges.

Source

Unified Modeling Language 2.5.1

Tokens offered to a ForkNode are offered to all outgoing ActivityEdges of the node. If at least one of these offers is accepted, the offered tokens are removed from their original source and the acceptor receives a copy of the tokens.

Source

Unified Modeling Language 2.5.1

ControlNodes act as “traffic switches” managing the flow of tokens across ActivityEdges. Tokens cannot “rest” at ControlNodes (with exceptions for InitialNodes and ForkNodes ...).

Source

Unified Modeling Language 2.5.1

Unlike ControlFlows, ObjectFlows also provide additional support for multicast/receive, token selection from ObjectNodes and transformation of tokens

Source

Unified Modeling Language 2.5.1

An ObjectFlow is an ActivityEdge that can have object tokens passing along it. ObjectFlows model the flow of values between ObjectNodes.

Source

Unified Modeling Language 2.5.1

ControlFlows are used to explicitly sequence execution of ActivityNodes, as the target ActivityNode cannot receive a control token and start execution until the source ActivityNode completes execution and produces the token.

Source

Unified Modeling Language 2.5.1

A ControlFlow is an ActivityEdge that only passes control tokens (and some object tokens as specified by modelers, see isControlType for ObjectNodes ...).

Source

Unified Modeling Language 2.5.1

There are two kinds of ActivityEdges:

Source

Unified Modeling Language 2.5.1

The outgoing ActivityEdges of an InitialNode must all be ControlFlows. The control token placed on an InitialNode is offered concurrently on all outgoing ControlFlows.

Source

Unified Modeling Language 2.5.1

An InitialNode shall not have any incoming ActivityEdges, which means the InitialNodes owned by an Activity will always be enabled when the Activity begins execution and a single control token is placed on each such InitialNode when Activity execution sta

Source

Unified Modeling Language 2.5.1

The ActivityEdge, Transition, and Connector metaclasses do not extend (directly or indirectly) the Relationship metaclass (although the notations for them do indicate a kind of "relationship").

UML2 simplified key "relationship" metaclasses hierachy - ADVANCED REFERENCE ONLY

This content has been marked as discussing an ADVANCED topic!

Gallery

Tutorial

TRAIL: Webel's ultimate guide to Systems Modeling Language (v1) with MagicDraw/Cameo

Section

01:02: UML 101 for model-based systems engineering with SysML

Slide kind

UML Profile Diagram

object_nodes ControlFlows may not have ObjectNodes at either end, except for ObjectNodes with control type.

Source

Unified Modeling Language 2.5.1

A ControlFlow is an ActivityEdge traversed by control tokens or object tokens of control type, which are use to control the execution of ExecutableNodes

Source

Unified Modeling Language 2.5.1

Figure 11-8: Abstract Syntax for SysML Activity Extensions

Gallery

Tutorial

TRAIL: The SysML-1.6 Hybrid SUV sample and specification diagrams in MagicDraw/Cameo (with annotations) [UNDERGOING UPDATE to SysML1.7]

Section

Section: SysML-1.6 specification diagrams: 11 Activities

Slide kind

UML Profile Diagram

Multiple arrows coming out of a standalone Pin rectangle is an optional notation for multiple edges coming out of an OutputPin.

Source

Unified Modeling Language 2.5.1

The standalone Pin in the notation maps to an OutputPin and an InputPin and one ObjectFlow edge between them in the underlying model. This form should be avoided if the Pins are not of the same type.

Source

Unified Modeling Language 2.5.1

The situation in which the OutputPin of one Action is connected to the InputPin of the same name in another Action via an ObjectFlow may be shown by the optional notations of Figure 16.6.

Source

Unified Modeling Language 2.5.1

An object flow is notated by an arrowed line. In Figure 15.9, upper right, the two object flow arrows denote a single object flow edge between two pins in the underlying model, as shown in the lower middle of the figure.

Source

Unified Modeling Language 2.5.1

MagicDraw/Cameo 19SP3: Continuous and Discrete have metaclass [ActivityEdge, ObjectNode, Parameter] not just [ActivityEdge, Parameter] (via Rate), so may be applied directly to Pin and ActivityParameterNode

When the «rate» stereotype is applied to an activity edge, it specifies the expected value of the number of objects and values that traverse the edge per time interval, that is, the expected value rate at which they leave the source node and arrive at ...

Source

OMG Systems Modeling Language (SysML) 1.6

Continuous ... It is independent from UML streaming, see clause 11.3.2.8. A streaming parameter may or may not apply to continuous flow, and a continuous flow may or may not apply to streaming parameters.

Source

OMG Systems Modeling Language (SysML) 1.6

Continuous rate is a special case of rate of flow (see Rate) where the increment of time between items approaches zero. It is intended to represent continuous flows that may correspond to water flowing through a pipe, a time continuous signal, or ...

Source

OMG Systems Modeling Language (SysML) 1.6

MagicDraw/Cameo: DO NOT use the ObjectNode menu item on Activity Diagrams ever!

Figure D.36 - Behavior Model for “Accelerate” Function (Activity Diagram) {EXPLICIT PINS}

Gallery

Tutorial

TRAIL: The SysML-1.6 Hybrid SUV sample and specification diagrams in MagicDraw/Cameo (with annotations) [UNDERGOING UPDATE to SysML1.7]

Section

Section: SysML-1.6: HSUV sample

Slide kind

SysML Activity Diagram

MagicDraw/Cameo: ERROR: Incorrectly uses 2 ObjectFlow edges and a CentralBufferNode in place of "elided Pin notation" instead of an abstract ObjectNode symbol and 2 arrow symbols (that are supposed to represent together 2 Pins and 1 ObjectFlow edge)

Figure D.36 - Behavior Model for “Accelerate” Function (Activity Diagram) {ELIDED PINS}

Gallery

Tutorial

TRAIL: The SysML-1.6 Hybrid SUV sample and specification diagrams in MagicDraw/Cameo (with annotations) [UNDERGOING UPDATE to SysML1.7]

Section

Section: SysML-1.6: HSUV sample

Slide kind

SysML Activity Diagram

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.

Source

Unified Modeling Language 2.5.1

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.

Source

Unified Modeling Language 2.5.1

A DecisionNode shall have at least one and at most two incoming ActivityEdges, and at least one outgoing ActivityEdge.

Source

Unified Modeling Language 2.5.1

incoming_control_one_input_parameter If the DecisionNode has a decisionInputFlow and an incoming ControlFlow, then any decisionInput Behavior has one in Parameter ...

Source

Unified Modeling Language 2.5.1

DecisionNode::incoming_outgoing_edges A DecisionNode has one or two incoming ActivityEdges and at least one outgoing ActivityEdge.

Source

Unified Modeling Language 2.5.1

two_input_parameters If the DecisionNode has a decisionInputFlow and a second incoming ObjectFlow, then any decisionInput has two in Parameters ...

Source

Unified Modeling Language 2.5.1

decision_input_flow_incoming The decisionInputFlow of a DecisionNode must be an incoming ActivityEdge of the DecisionNode.

Source

Unified Modeling Language 2.5.1

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.

Source

Unified Modeling Language 2.5.1

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.

Source

Unified Modeling Language 2.5.1

decisionInput : Behavior [0..1] ... A Behavior that is executed to provide an input to guard ValueSpecifications on ActivityEdges outgoing from the DecisionNode.

Source

Unified Modeling Language 2.5.1

A DecisionNode is a ControlNode that chooses between outgoing ActivityEdges for the routing of tokens.

Source

Unified Modeling Language 2.5.1

An inout Parameter shall be associated with at most one input ActivityParameterNode and at most one output ActivityParameterNode.

Source

Unified Modeling Language 2.5.1

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 ..

Source

Unified Modeling Language 2.5.1

An Activity shall have one ActivityParameterNode corresponding to each in, out, or return Parameter and two ActivityParameterNodes for each inout Parameter.

Source

Unified Modeling Language 2.5.1

(Note that whether an ActivityParameterNode is for input or output is not determined until at least one ActivityEdge is connected to it.)

Source

Unified Modeling Language 2.5.1

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.

Source

Unified Modeling Language 2.5.1

A token may traverse only one of the outgoing edges.

Source

Unified Modeling Language 2.5.1

Except in the case of an output ActivityParameterNode, tokens held by an ObjectNode may leave the node on outgoing ActivityEdges.

Source

Unified Modeling Language 2.5.1

Except in the case of an input ActivityParameterNode ... the tokens held by an ObjectNode arrive from incoming ActivityEdges.

Source

Unified Modeling Language 2.5.1

fUML-1.4 guards are NOT allowed on an ActivityEdge from a ForkNode

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.

Source

Semantics of a Foundational Subset for Executable UML Models 1.4

fUML-1.4 EXCLUDES ActivityNode::redefinedNode

fUML-1.4 EXCLUDES ActivityEdge::weight

fUML-1.4 EXCLUDES ActivityEdge::redefinedEdge

Subscribe to ActivityEdge