Activity Diagram

Slide kind

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

ExpansionRegion: running «iterative» example

This content has been marked as discussing an ADVANCED topic!

Gallery

Tutorial

Section

Slide kind

Once the test fails and the loop is completed, the tokens on the bodyOutput OutputPins from the last iteration are moved to the result OutputPins and offered on any edges outgoing from those OutputPins.

Source

After the completion of each execution of the bodyPart of the LoopNode, any remaining tokens on the loopVariable OutputPins are destroyed and tokens on the bodyOutput OutputPins are copied to the corresponding loopVariable OutputPins so that they are ...

Source

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

If a LoopNode has loopVariable OutputPins, then it must also have matching sets of loopVariableInput InputPins, bodyOutput OutputPins (owned by Actions within the bodyPart), and result OutputPins.

Source

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

After each execution of the bodyPart, the test section is executed again, for the next iteration of the loop.

Source

The test section has an Action owning the decider OutputPin with type Boolean identified by the LoopNode. When the test section has completed execution, if the value on the decider OutputPin is true, then the bodyPart is executed. Otherwise ...

Source

Execution of the test section may precede or follow execution of the bodyPart, depending on whether isTestFirst is true or false, respectively. ... If the bodyPart is executed first (isTestFirst=false), it is always executed at least once ...

Source

The setupPart of a LoopNode is executed first. When the setupPart has completed execution, the iterative execution of the loop begins.

Source

Any ExecutableNode in the LoopNode must be included in the setupPart, test or bodyPart for the LoopNode.

Source

A LoopNode is a StructuredActivityNode that represents an iterative loop. A LoopNode consists of a setupPart, a test and a bodyPart, which identify subsets of the ExecutableNodes contained in the LoopNode.

Source

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

LoopNode: running loopVariable example

Gallery

Tutorial

Section

Slide kind

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

LoopNode with loopVariable - ADVANCED REFERENCE

This content has been marked as discussing an ADVANCED topic!

Gallery

Tutorial

Section

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

Loop: running example using DecisionNode and MergeNode and an Integer property in a context

Gallery

Tutorial

Section

Slide kind

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

LoopNode: basic running example

Gallery

Tutorial

Section

Slide kind

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

ExecutableNode has implicit fork

Gallery

Tutorial

Section

Slide kind

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

OPTION double InitialNode

Gallery

Tutorial

Section

Slide kind

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

CORRECT InitialNode explicit fork

Gallery

Tutorial

Section

Slide kind

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

INCORRECT InitialNode no implicit fork

Gallery

Tutorial

Section

Slide kind

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

ForkNode and JoinNode with optional ControlFlow guards - LIMITED SUPPORT

Gallery

Tutorial

Section

Slide kind

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

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

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

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

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

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

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

AND with ForkNode and JoinNode

Gallery

Tutorial

Section

Slide kind

a predefined guard “else” (represented as an Expression with “else” as its operator and no operands) may be used for at most one outgoing edge. This guard evaluates to true only if the token is not accepted by any other outgoing edge from the DecisionNode

Source

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

OR with DecisionNode and MergeNode

Gallery

Tutorial

Section

Slide kind

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

ActivityParameterNode cases - REFERENCE CARD

This content has been marked as discussing an ADVANCED topic!

Gallery

Tutorial

Section

Slide kind

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

Parameter vs ActivityParameterNode vs Pin

Gallery

Tutorial

Section

Slide kind

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

Starting an Action that has a ValuePin - LIMITED SUPPORT

Gallery

Tutorial

Section

Slide kind

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

Starting an Action that has a ControlPin

Gallery

Tutorial

Section

Slide kind

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

Starting an Action that has an InputPin with multiplicity

Gallery

Tutorial

Section

Slide kind

If the Action is an invocation of a Behavior with streaming Parameters ... the Action execution may consume additional data supplied to InputPins corresponding to streaming input Parameters ... Otherwise ... any additional data on InputPins has no effect

Source

For structured Actions (StructuredActivityNodes ... ), data can remain on InputPins during Action execution, otherwise they are immediately removed from the InputPins by the ActionExecution.

Source

The Action execution consumes input data on all InputPins on the Action up to the upper multiplicity for each InputPin.

Source

However, if the Action is an invocation of a Behavior with streaming Parameters ... then the Action execution may also post data to OutputPins corresponding to streaming output Parameters before completion of the execution ...

Source

When completed, an Action execution provides any output data on the OutputPins of the Action, and it terminates.

Source

An Action continues executing until it has completed. The detailed semantics of the execution of an Action and the definition of its completion depend on the particular kind of Action being executed.

Source

The time at which an Action executes and what inputs are accepted by each execution are determined by the kind of Action it is, characteristics of its InputPins, and the Behavior in which it is used.

Source

A ValuePin provides a value by evaluating a ValueSpecification ... When the Action is enabled by other means, the ValueSpecifiation of the ValuePin is evaluated, and the result is provided as an input to the Action when it begins execution.

Source

When the Action is enabled by other means, values are computed as specified for the ValuePins and ActionInputPins owned by an Action, and the results are provided as inputs to the Action when it begins execution.

Source

ValuePins and ActionInputPins are InputPins, but are not used in the determination of whether an Action is enabled for execution. If an Action has no other way to start execution, simply having ValuePins or ActionInputPins for its inputs will not enable..

Source

An Action may not put more values into an output in a single execution than the [upper] multiplicity of that OutputPin.

Source

For each execution, an Action cannot terminate itself unless it can put at least as many values into its outputs as required by the multiplicity lower bounds on those OutputPins. Values that may remain on the OutputPins from previous executions are not...

Source

An OutputPin is a Pin that holds output values produced by an Action.

Source

Tokens consumed by an Action are immediately removed from its InputPins when the action begins an execution (except in some cases for StructuredActivityNodes, where tokens may remain on InputPins during the Action execution ...)

Source

The upper multiplicity determines the maximum number of values that can be consumed from an InputPin by a single execution of its Action.

Source

An Action cannot start execution if one of its InputPins has fewer values than the lower multiplicity of that InputPin.

Source

An InputPin is a Pin that holds input values to be consumed by its Action.

Source

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

Starting an Action that has an InputPin

Gallery

Tutorial

Section

Slide kind

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

ActivityPartitions using “swimlane” notation

Gallery

Tutorial

Section

Slide kind

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

Activity example: send and catch Signal

Gallery

Tutorial

Section

SysML Block Definition Diagram (BDD)

Slide kind

hybrid diagram

SysML Activity Diagram

An Action may accept inputs and produce outputs, as specified by InputPins and OutputPins of the Action, respectively. Each Pin on an Action specifies the type and multiplicity for a specific input or output of that Action.

Source

Pins are used to specify the inputs and outputs for Actions.

Source

An ActivityFinalNode is a FinalNode that stops all flows in an Activity (or StructuredActivityNode, see sub clause 16.11). A token reaching an ActivityFinalNode owned by an Activity terminates the execution of that Activity.

Source

A FlowFinalNode is a FinalNode that terminates a flow. All tokens accepted by a FlowFinalNode are destroyed. This has no effect on other flows in the Activity.

Source

A FinalNode is a ControlNode at which a flow in an Activity stops. A FinalNode shall not have outgoing ActivityEdges. A FinalNode accepts all tokens offered to it on its incoming ActivityEdges. There are two kinds of FinalNode:

Source

An OpaqueAction is an Action whose specification may be given in a textual concrete syntax other than UML. An OpaqueAction may also be used as a temporary placeholder before some other kind of Action is chosen.

Source

All tokens offered on the incoming edges of a MergeNode are offered to the outgoing edge. There is no synchronization of flows or joining of tokens.

Source

If the outgoing edge of a MergeNode is a ControlFlow, then all incoming edges must be ControlFlows, and, if the outgoing edge is an ObjectFlow, then all incoming edges must be ObjectFlows.

Source

A MergeNode shall have exactly one outgoing ActivityEdge but may have multiple incoming ActivityEdges.

Source

A MergeNode is a control node that brings together multiple flows without synchronization.

Source

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

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

Source

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

If the incoming edge is a ControlFlow, then all outgoing edges shall be ControlFlows and, if the incoming edge is an ObjectFlow, then all outgoing edges shall be ObjectFlows.

Source

A ForkNode is a ControlNode that splits a flow into multiple concurrent flows. A ForkNode shall have exactly one incoming ActivityEdge, though it may have multiple outgoing ActivityEdges.

Source

When an ExecutableNode completes an execution, the control token representing that execution is removed from the ExecutableNode and control tokens are offered on all outgoing ControlFlows of the ExecutableNode. That is, there is an implicit fork ...

Source

In some cases, multiple concurrent executions of an ExecutableNode may be ongoing at one time (see the semantics of isLocallyReentrant=true for Actions ... ). In this case, the ExecutableNode holds one control token for each concurrent execution.

Source

While the ExecutableNode is executing, it is considered to hold a single control [token] indicating it is execution [executing].

Source

The effect of object tokens accepted from ControlFlows is not specified (see isControlType for ObjectNodes ...), but the semantics above applies if the effect is to execute the ExecutableNode.

Source

Before an ExecutableNode begins executing, it accepts all tokens offered on incoming ControlFlows. If multiple tokens are being offered on a ControlFlow, they are all consumed.

Source

An ExecutableNode shall not execute until all incoming ControlFlows (if any) are offering tokens. That is, there is an implicit join on the incoming Control Flows. Specific kinds of ExecutableNodes may have additional prerequisites ...

Source

An ExecutableNode may also consume and produce data, but it must do so through related ObjectNodes (Actions use Pins for this purpose ...

Source

An ExecutableNode is an ActivityNode that carries out a substantive behavioral step of the Activity that contains it.

Source

All concrete kinds of ExecutableNodes are Actions ...

Source

Generally, the ControlNodes and ObjectNodes in an Activity are largely there to control the sequencing and to manage the flow of data between the ExecutableNodes of the Activity.

Source

An ExecutableNode is a kind of ActivityNode that may be executed as a step in the overall desired behavior of the containing Activity.

Source

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

uml101 - Activity Diagram - notation - REFERENCE CARD

This content has been marked as discussing an ADVANCED topic!

Gallery

Tutorial

Section

Slide kind