uml101 - Activity Diagram - notation - REFERENCE CARD

Gallery

Tutorial

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

Section

01:04: UML Behavior: Activities quick start

Tags and keywords

Topic level

UML keywords

Activity Diagram

ExceptionHandler

ExceptionHandler::protectedNode

ExecutableNode::handlers

ActivityParameterNode

CallBehaviorAction

AcceptEventAction

SendSignalAction

StructuredActivityNode

InterruptibleActivityRegion

ActivityEdge::guard

TimeEvent::isRelative

ActivityFinalNode

elided Pin notation

Slide kind

UML Activity Diagram

This content has been marked as discussing an ADVANCED topic!

NOTATION REFERENCE ONLY: This diagram is not meant to be executable!

Please not do not be overwhelmed by this advanced reference card diagram! Each main aspect is explored in dedicated tutorial slides and in the Webel IT Australia UML and SysML courses. And you don't have to learn every single possible capability of Activities up-front to get started with them:

Click on the image to view it full size

Tool concerns:

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)

Webel recommends when using MagicDraw/Cameo: AVOID the "elided Pin" abstract ObjectNode notation on Activity Diagrams, use explicit Pins!

Noteworthy;

UML-2.5.1: 'An Activity may have more than one InitialNode. 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 ...'

For SysML Activity Diagrams only:

In a SysML Activity Diagram a control flow may be notated with a dashed line and stick arrowhead; this helps distinguish a ControlFlow from an ObjectFlow symbol.

Up next

Activity example: send and catch Signal

Notes

[DISPLAY, TIP]{INFORMATIVE} In a SysML Activity Diagram a control flow may be notated with a dashed line and stick arrowhead; this helps distinguish a ControlFlow from an ObjectFlow symbol.

[ISSUE, TOOL] 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)

[DISPLAY, ISSUE, TOOL, WARNING] Webel recommends when using MagicDraw/Cameo: AVOID the "elided Pin" abstract ObjectNode notation on Activity Diagrams, use explicit Pins!

Snippets (quotes/extracts)

[SysML-1.6] Control flow may be notated with a dashed line and stick arrowhead, as shown in Figure 11-4.

[UML-2.5.1] no_executable_nodes ObjectFlows may not have ExecutableNodes at either end.

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

[UML-2.5.1] All concrete kinds of ExecutableNodes are Actions ...

[UML-2.5.1] 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.

[UML-2.5.1] 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.

[UML-2.5.1] 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.

[UML-2.5.1] An InitialNode is a ControlNode that acts as a starting point for executing an Activity.

[UML-2.5.1] An Activity may have more than one InitialNode.

[UML-2.5.1] 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 ...

[UML-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

[UML-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 ...).

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

[UML-2.5.1] ObjectNodes hold object tokens accepted from incoming ObjectFlows and may subsequently offer them to outgoing ObjectFlows (with a modeler-specified exception for ControlFlows, see isControlType for ObjectNodes ...).

[UML-2.5.1] 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.

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

[UML-2.5.1] A DecisionNode is a ControlNode that chooses between outgoing ActivityEdges for the routing of tokens.

[UML-2.5.1] A MergeNode is a control node that brings together multiple flows without synchronization.

[UML-2.5.1] 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.

[UML-2.5.1] 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.

[UML-2.5.1] 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.

[UML-2.5.1] Pins are used to specify the inputs and outputs for Actions.

[UML-2.5.1] Action::/input : InputPin [0..*] ... The ordered set of InputPins representing the inputs to the Action.

[UML-2.5.1] Action::/output : OutputPin [0..*] ... The ordered set of OutputPins representing outputs from the Action.

[UML-2.5.1] 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.

Visit also

Screencast: Mini tutorial: UML/SysML: Cameo Simulation Toolkit: StateMachine with entry Activity and Transition guard

Screencast: Mini tutorial: UML/SysML: Cameo Simulation Toolkit: StateMachine with doActivity and a Transition with a ChangeEvent trigger

Screencast: Mini tutorial: UML/SysML: Cameo Simulation Toolkit: Send and receive a Signal using a SendSignalAction and an AcceptEventAction

Screencast: Tutorial: UML/SysML: StateMachines vs Activities: Operation-driven Transition case study - UML-2.5.1 'Figure 14.7 Composite State with two States' in Cameo Simulation Toolkit

HOWTO simulate UML-2.5.1 'Figure 14.7 Composite State with two States' in Cameo Simulation Toolkit - Operation-driven Transition case study

Visit also (backlinks)

SysMLv1: A basic ControlFlow and DecisionNode loop with implied variable popup dialog [with mini video]

Webel: SysMLv1: Overview of annotated Diagram Slides and Note pages related to general high level SysML modelling principles (some specific to MagicDraw/Cameo). Recommended reading for all Webel SysML/MBSE course attendees.

Related slides (includes other tutorials)

UML2 Activity Diagram - essential metaclasses - ADVANCED REFERENCE ONLY

UML2 Actions - metaclasses - ADVANCED REFERENCE ONLY

Overview: Controller class (and its Activity), Dialer Class (and its StateMachine), Number class

CatchDialN: Activity with AcceptEventAction for a SignalEvent and a CallBehaviorAction

The Controller Activity (classifierBehavior of the Controller class)

The Connect Activity

The number.append Activity as entry Behavior for the PartialDial State

The append(n:int) operation and its Activity method Append

The number.print Activity as exit Behavior for the PartialDial State

The WhenValid Activity as effect Behavior

A quick look at accessing an Operation on a Transition or ActivityEdge guard with Alf vs ALH

Related slides (backlinks, includes other tutorials)

Flags