partner-pub-5002 w w w .

uml-diagra

FORID:10

UTF-8

Search

Home Activity Diagrams Activity Diagrams Reference Activity Diagrams Examples UML Index

Activity Diagrams
Activity modeling emphasizes the sequence and conditions for coordinating lower-level behaviors, rather than which classifiers own those behaviors. These are commonly called control flow and object flow models. The actions coordinated by activity models can be initiated because other actions finish executing, because objects and data become available, or because events occur external to the flow. The following nodes and edges are typically drawn on UML activity diagrams: activity, partition, action, object, control, activity edge. You can find some activity diagram examples here:

Online Shopping Business Flow - Process Order Business Flow - Document Management Process Software Design - Resolve Issue Sentinel HASP SL - Manual Activation of Trial Product Single Sign-On for Google Apps

Activity
Activity is a parameterized behavior represented as coordinated flow of actions. The flow of execution is modeled as activity nodes connected by activity edges. A node can be the execution of a subordinate behavior, such as an arithmetic computation, a call to an operation, or manipulation of object contents. Activity nodes also include flow of control constructs, such as synchronization, decision, and concurrency control. Activities may form invocation hierarchies invoking other activities, ultimately resolving to individual actions. In an object-oriented model, activities are usually invoked indirectly as methods bound to operations that are directly invoked. Activity contains activity nodes which could be:

Action

Object Control

Activities may contain actions of various kinds:

Occurrences of primitive functions, such as arithmetic functions. Invocations of behavior, such as activities. Communication actions, such as sending of signals. Manipulations of objects, such as reading or writing attributes or associations.

There are actions that invoke activities - either directly using call behavior action or indirectly with call operation action. Activity could be rendered as round-cornered rectangle with activity name in the upper left corner and nodes and edges of the activity inside the border. UML 2.4 specification examples show activity name in bold.

Online Shopping activity. Activity parameters are displayed on the border and listed below the activity name as: parameter-name: parameter-type.

Authenticate User activity with two parameters - Login Id and Password.

As a behavior activity could have pre- and post-condition constraints. If present, these are shown with the keywords precondition and postcondition, respectively. The keyword singleExecution is used for activities that execute as a single shared execution (singleton), otherwise, each invocation executes in its own space. The round-cornered activity border may be replaced with the frame notation for diagrams. The kind of the frame in this case is activity or act in short form. Activity parameters if any are displayed on the frame.

Authenticate User activity frame with two parameters - Login Id and Password. The notation for classes with the keyword activity can be used to show the features of a reflective activity, to indicate it is an activity class. Association and state machine notation can also be used as necessary. UML allows behaviors to produce tokens that are activities and which can in turn be executed at the runtime.

Activity Partition
An activity partition is activity group for actions that have some common characteristic. Partitions often correspond to organizational units or business actors in a business model. Partitions provide a constrained view on the behaviors invoked in activities. Constraints could be selected according to the type of the element that the partition represents. The following constraints are normative (standard) in UML 2.4:

classifier instance part attribute and value

In other words, partitions could represent specific classifiers. In this case actions in each partition should be operations or signals targeting objects that are instances of the corresponding classifier. A partition may represent some attribute and its subpartitions - specific values of that attribute. For example, a partition may represent the location at which a behavior is carried out, and the subpartitions would represent specific values for that attribute, such as New York. Activity partition may be shown using a swimlane notation - with two, usually parallel lines, either horizontal or vertical, and a name labeling the partition in a box at one end. Any activity nodes, e.g. actions and edges placed between these lines are considered to be contained within the partition.

Activity partitions Customer and Order Dept as horizontal swimlanes

Activity partitions Customer and Order Dept as vertical swimlanes Hierarchical partitioning is represented using swimlanes for subpartitions as illustrated below.

Hierarchical partitioning with subpartitions A partition may be marked as a dimension for its subpartitions to contain (group) those subpartitions along dimension. For example, an activity may have one dimension of partitions for location at which the contained behaviors are carried out, and another for the cost of performing them. Dimension partitions cannot be contained by any other partition. Diagrams can also be partitioned multidimensionally, where each swim cell is an intersection of multiple partitions. The partitions within each dimension may be grouped into an enclosing activity partition with isDimension=true, whose name is the dimension name. Rather than being shown as a partition itself, however, the dimension is indicated by placing its name along side the set of partitions in the dimension. Partition could represent an external entity to which the partitioning structure does not apply. External partitions are intentional exceptions to the rules for partition structure. For example, a dimension may have partitions showing parts of a structured classifier. It can have an external partition that does not represent one of the parts, but a completely separate classifier. In business modeling, external partitions can be used to model entities outside a business. When activities are considered to occur outside the domain of a particular model, the partition can be labeled with the keyword external. Whenever an activity in a swimlane is marked external, this overrides the swimlane and dimension designation.

Buy action occurs in external partition Customer In the situations when swimlanes can't be used to show partitions, alternate text notation with qualified action name could be used instead. In this case partition name is placed in parenthesis above the action name. A comma-delimited list of partition names means that the node is contained in more than one partition. A double colon within a partition name indicates that the partition is nested, with the larger partitions coming earlier in the name.

Buy action occurs in the external partition Customer

Action
Action is a named element which represents a single atomic step within activity, i.e. that is not further decomposed within the activity. Activity represents a behavior that is composed of individual elements that are actions. Note, that call behavior action may reference (call) activity. This action is simple for the activity containing it, but may be complex in its effect. An activity defines a behavior that can be reused in many places. Explicitly modeled actions as part of activities are new in UML 2.0, and replace action state, call state, and subactivity state in UML 1.5. Actions are notated as round-cornered rectangles. Name or description of the action is placed inside of the rectangle.

The Process Order action. Name of the action is usually action verb or noun for the action with some explanation. Don't use state names as action names. Some action name examples:

Fill Order Review Document Enroll in Course Checkout Show Error Page

Action could also be expressed in some application-dependent action language.

Example of action expressed with tool-dependent action language. An action may have sets of incoming and outgoing activity edges that specify control flow and data flow from and to other nodes. An action will not begin execution until all of its input conditions are satisfied. The completion of the execution of an action may enable the execution of a set of successor nodes and actions that take their inputs from the outputs of the action. If an exception occurs during the execution of an action, the execution of the action is abandoned and no regular output is generated by this action. If the action has an exception handler, it receives the exception object as a token. If the action has no exception handler, the exception propagates to the enclosing node and so on until it is caught by one of them. If an exception propagates out of a nested node (action, structured activity node, or activity), all tokens in the nested node are terminated. The data describing an exception is represented as an object of any class. Local pre-conditions and local post-conditions are constraints that should hold when the execution starts and completes, respectively. They hold only at the point in the flow that they are specified, not globally for other invocations of the behavior at other places in the flow or on other diagrams. How local pre- and postconditions are enforced is determined by the implementation. For example, violations may be detected at compile time or runtime. The effect may be an error that stops the execution or just a warning, and so on. Local pre-conditions and local post-conditions are shown as notes attached to the invocation with the keywords localPrecondition and localPostcondition, respectively.

Local pre- and post-conditions shown as notes attached to Process Order action. Action subclasses are listed below. Note, that I added object actions and event actions, which are not defined explicitly in UML 2.4 specification.

object action (not explicit in UML standard) variable action invocation action raise exception action structural feature action link action event action (not explicit in UML standard) opaque action

Object Action
Object actions include different actions on objects, e.g. create and destroy object, test object identity, specify value, etc. Object action is not defined explicitly by UML standard. In the UML standard all object actions are direct subclasses of action. Object actions:

create object action destroy object action test identity action read self action value specification action start classifier behavior action read is classified object action reclassify object action read extend action

Variable Action

Variable actions include variable read, write, add, remove and clear actions.

Variable actions overview diagram

Invocation Action
Invocation actions include several call actions, signal send and broadcast actions and send object action.

Invocation actions overview diagram Call Behavior Action Call behavior action is a call action that invokes a behavior directly rather than invoking an operation that invokes the behavior. Parameters could be passed by the action to the invoked behavior. The number of argument pins and the number of parameters of the behavior of type in and in-out must be equal. Also equal should be the number of result pins and the number of parameters of the behavior of type return, out, and in-out. For synchronous calls the execution of the call behavior action waits until the execution of the invoked behavior completes. Execution of the calling action is blocked until it receives a reply. The reply includes values for any return, out, or inout parameters. The result values are placed on the result pins of the call behavior action, and the execution of the action is complete after that. If the execution of the invoked behavior throws an exception, the exception is transmitted back to the call behavior action to begin search for some exception handler. If the call is asynchronous, the call action completes immediately after behavior started. Any return or out values from the invoked behavior are not passed back.

Call behavior action is shown as action with the name of the behavior that is performed by the action or description of the behavior placed inside the action's round-cornered rectangle. If the node name is different than the behavior name, then it appears in the symbol instead.

Call behavior action for Checkout behavior Note, that because it looks exactly the same way as the common action, there is no way just looking at the diagram to say whether the name is common action name, call behavior action name or some behavior name. As you know, some subclasses of behavior are interaction, state machine, activity. Call activity action is indicated by placing a rake-style symbol within the action symbol. The rake resembles a miniature hierarchy, indicating that this invocation starts another activity. Note, that though UML provides this notation, there is no official call activity action in UML specification.

Call activity action for User Authentication activity An alternative notation for the invoked activity is to show the contents of the invoked activity inside a large round-cornered rectangle. Edges flowing into the invocation connect to the parameter object nodes in the invoked activity. The parameter object nodes are shown on the border of the invoked activity. Pre- and post-conditions on the behavior can be shown using keywords precondition and postcondition. Send Signal Action Send signal action is an invocation action that creates a signal from its inputs, and transmits it to the specified target object, where it may cause the firing of a state machine transition or the execution of an activity. When all the prerequisites of the action execution are satisfied, a signal is generated from the arguments and is transmitted to the identified target object. The target object may be local or remote. If input of the action is already a signal, send object action should be used instead.

The sender of the signal (aka "requestor") continues execution immediately, without waiting for any response. Send signal action receives no reply from the invoked behavior. Any attempt to reply is simply ignored, and no transmission is performed back to the sender. The manner of transmitting the signal, the amount of time required to transmit it, the order in which the transmissions reach the various targets, and the path for reaching the targets are undefined in . The signal instance may be copied during transmission, so identity might not be preserved. When a transmission arrives at a target object, it may invoke behavior in the target object. The effect of receiving a signal object is specified in Common Behaviors. Such effects include executing activities and firing state machine transitions. Send signal action is notated as convex pentagon. Note, that the name of the action corresponds to the name of signal class it sends. Target object is not specified with this notation.

Notify Customer send signal action creates and sends Notify Customer signal

After order is shipped, Notify Customer send signal action creates and sends Notify Customer signal

Structural Feature Action

Structural feature actions include several actions working on composite structures - read, write, add, remove, clear and reduce actions.

Structural feature actions overview diagram Note, that in UML 2.4 specification reduce action is direct subclass of action.

Link Action
Link actions include several actions working on links - read, write, create, destroy and clear association actions.

Link actions overview diagram Note, that in UML 2.4 specification read link object end action, read link object end qualifier action, clear association action are direct subclasses of action.

Event Action
Event actions include accept event action, accept call, accept time event, reply and unmarshall action. Note, that event action is not an explicit part of UML specification, In UML 2.4 all event actions are direct subclasses of action. I added event action here for clarity.

Event actions overview diagram Accept Event Action Accept event action is action that waits for a specific event to occur. This action handles asynchronous messages, including asynchronous calls. It cannot be used with synchronous calls (except accept call action). Accept event action was introduced in UML 2.0. Accept event action handles events detected by the object owning the executing behavior. Events are stored by the object in some queue. The order of detected events is not defined by the UML specification, but it could be specified in extensions or profiles. If accept event action is executed and object detected event matching one of the triggers on the action, then the accept event action outputs a value describing the event. If the event does not match expected event, the action waits for the next event. In a system with concurrency, several actions or other behaviors might compete for an available event. Only one action accepts event, unless otherwise specified by an extension or profile, even if the event would satisfy multiple concurrently executing actions. An accept event action is notated as a concave pentagon. By default, name of the accept event action corresponds to the name of the event this action accepts, so that e.g. Accept Order accept event action waits for Accept Order event.

Acceptance of the Accept Order event by Accept Order action causes an invocation of a Process Order action. The accept event action is enabled upon entry to the activity containing it If an accept event action has no incoming edges, then the action starts when the containing activity or structured node does, whichever most immediately contains the action. In addition, an accept event action with no incoming edges remains enabled after it accepts an event. It does not terminate after accepting an event and outputting a value, but continues to wait for other events. This semantic is an exception to the normal execution rules in activities. An accept event action with no incoming edges and contained by a structured node is terminated when its container is terminated. Accept Signal Action Accept signal action is informal name for the accept event action whose trigger is a signal event. It corresponds to send signal action. An accept signal action is notated the same way as accept event action - as a concave pentagon. By default, name of the accept signal action corresponds to the name of the signal this action accepts.

Payment Requested signal is sent. The activity then waits to receive Payment Confirmed signal. Acceptance of the Payment Confirmed signal is enabled only after the request for payment is sent. Wait Time Action If the event is a time event occurrence, the result value contains the time at which the occurrence happened. Such an action is informally called a wait time action. Accept time event action (aka informal: wait time action) is notated with an hour glass.

The Every Hour accept time event action generates output every hour. There are no incoming edges to this time event action, so it is enabled as long as its containing activity or structured node is enabled.

Control
Control node is an activity node used to coordinate the flows between other nodes. It includes:

initial node flow final node activity final node decision node merge node fork node join node

Initial Node
Initial node is a control node at which flow starts when the activity is invoked. A control token is placed at the initial node when the activity starts, but not in initial nodes in structured nodes contained by the activity. Tokens in an initial node are offered to all outgoing edges. For convenience, initial nodes are an exception to the rule that control nodes cannot hold tokens if they are blocked from moving downstream, for example, by guards. Activity may have more than one initial node. In this case, invoking the activity starts multiple flows, one at each initial node. Note that flows can also start at other nodes, so initial nodes are not required for an activity to start execution. Initial nodes are shown as a small solid circle.

Activity initial node.

Flow Final Node

Flow final node is a control final node that terminates a flow. It destroys all tokens that arrive at it but has no effect on other flows in the activity. Flow final was introduced in UML 2.0. The notation for flow final node is small circle with X inside.

Flow final node.

Activity Final Node

Activity final node is a control final node that stops all flows in an activity. Activity final was introduced in UML 2.0. An activity may have more than one activity final node. The first one reached stops all flows in the activity. A token reaching an activity final node terminates the activity. In particular, it stops all executing actions in the activity, and destroys all tokens in object nodes, except in the output activity parameter nodes. Terminating the execution of synchronous invocation actions also terminates whatever behaviors they are waiting on for return. Any behaviors invoked asynchronously by the activity are not affected. If it is not desired to abort all flows in the activity, use flow final instead. Activity final nodes are shown as a solid circle with a hollow circle inside. It can be thought of as a goal notated as "bulls eye," or target.

Activity final node.

Decision Node
Decision node is a control node that accepts tokens on one or two incoming edges and selects one outgoing edge from one or more outgoing flows. Decision nodes were introduced in UML to support conditionals in activities. The edges coming into and out of a decision node, other than the decision input flow (if any), must be either all object flows or all control flows. Each token arriving at a decision node can traverse only one outgoing edge. Tokens are not duplicated. Each token offered by the incoming edge is offered to the outgoing edges. Which of the edges is actually traversed depends on the evaluation of the guards on the outgoing edges. The order in which guards are evaluated is not defined, i.e. we should not rely on any visual or text description order. The notation for a decision node is a diamond-shaped symbol.

Decision node with two outgoing edges with guards. The modeler should arrange that each token only be chosen to traverse one outgoing edge. For decision points, a predefined guard "else" may be defined for at most one outgoing edge.

Decision node with three outgoing edges and [else] guard. Decision can have decision input behavior specified. Decision input behaviors were introduced in UML to avoid redundant recalculations in guards. In this case each data token is passed to the behavior before guards are evaluated on the outgoing edges. The behavior is invoked without input for control tokens. The output of the behavior is available to each guard. Because the behavior is used during the process of offering tokens to outgoing edges, it may be run many times on the same token before the token is accepted by those edges. This means the behavior cannot have side effects. Decision input behavior is specified by the keyword decisionInput and some decision behavior or condition placed in a note symbol, and attached to the appropriate decision node.

Decision node with decision input behavior.

Decision may also have decision input flow. In this case the tokens offered on the decision input flow that are made available to the guard on each outgoing edge determine whether the offer on the regular incoming edge is passed along that outgoing edge. A decision input flow is specified by the keyword decisionInputFlow annotating that flow.

Decision node with decision input flow. If there are both a decision input behavior as well as decision input flow, the token offered on the decision input flow is passed to the behavior (as the only argument if the regular incoming edge is control flow, as the second argument if it is an object flow). Decision nodes with the additional decision input flow offer tokens to outgoing edges only when one token is offered on each incoming edge.

Merge Node
Merge node is a control node that brings together multiple incoming alternate flows to accept single outgoing flow. There is no joining of tokens. Merge should not be used to synchronize concurrent flows. For example, if a decision is used after a fork, the two flows coming out of the decision need to be merged into one before going to a join; otherwise, the join will wait for both flows, only one of which will arrive. All edges coming into and out of a merge node must be either object flows or control flows. The notation for a merge node is a diamond-shaped symbol with two or more edges entering it and a single activity edge leaving it.

Merge node with three incoming edges and a single outgoing edge

The functionality of merge node and decision node can be combined by using the same node symbol, as illustrated below. This case maps to a model containing a merge node with all the incoming edges shown in the diagram and one outgoing edge to a decision node that has all the outgoing edges shown in the diagram.

Merge node and decision node combined using the same symbol

Fork Node
Fork node is a control node that has one incoming edge and multiple outgoing edges and is used to split incoming flow into multiple concurrent flows. Fork nodes are introduced to support parallelism in activities. As compared to UML 1.5, UML 2.0 activity forks model unrestricted parallelism. Tokens arriving at a fork are duplicated across the outgoing edges. If at least one outgoing edge accepts the token, duplicates of the token are made and one copy traverses each edge that accepts the token. The outgoing edges that did not accept the token due to failure of their targets to accept it, keep their copy in an implicit FIFO queue until it can be accepted by the target. The rest of the outgoing edges do not receive a token. The notation for a fork node is a line segment with a single activity edge entering it, and two or more edges leaving it.

Fork node with a single activity edge entering it, and three edges leaving it. The functionality of join node and fork node can be combined by using the same node symbol. This case maps to a model containing a join node with all the incoming edges shown in the diagram and one outgoing edge to a fork node that has all the outgoing edges shown in the diagram.

Combined join node and fork node.

If guards are used on edges outgoing from forks, the modelers should ensure that no downstream joins depend on the arrival of tokens passing through the guarded edge. If that cannot be avoided, then a decision node should be introduced to have the guard, and shunt the token to the downstream join if the guard fails.

Join Node
Join node is a control node that has multiple incoming edges and one outgoing edge and is used to synchronize incoming concurrent flows. Join nodes are introduced to support parallelism in activities. The notation for a join node is a line segment with several activity edges entering it, and only one edge leaving it.

Join node with three activity edges entering it, and a single edge leaving it. The functionality of join node and fork node can be combined by using the same node symbol. This case maps to a model containing a join node with all the incoming edges shown in the diagram and one outgoing edge to a fork node that has all the outgoing edges shown in the diagram.

Combined join node and fork node. Join nodes have a join specification which is Boolean value specification using the names of the incoming edges to specify the conditions under which the join will emit a token. The join specification is evaluated whenever a new token is offered on any incoming edge. The evaluation is not interrupted by any new tokens offered during the evaluation, nor are concurrent evaluations started when new tokens are offered during an evaluation. The default join specification is the reserved string "and". It is equivalent to a specification that requires at least one token offered on each incoming edge. Join specifications are shown in curly braces near the join node as joinSpec=....

Join node with join specification shown in curly braces.

Activity Edge
Activity Edge is an abstract class for the directed connections along which tokens or data objects flow between activity nodes. It includes control edges and object flow edges. The source and target of an edge must be in the same activity as the edge. Activity edge is notated by an open arrowhead line connecting two activity nodes.

Activity edge connects Fill Order and Review Order. Edges can be named, however, edges are not required to have unique names within an activity. If the edge has a name, it is notated near the arrow.

Activity edge "updated" connects two nodes. Activity edge can have a guard - specification evaluated at runtime to determine if the edge can be traversed. The guard must evaluate to true for every token that is offered to pass along the edge. The guard of the activity edge is shown in square brackets that contain the guard.

Fill Order when priority is 1 An activity edge can be notated using a connector, which is a small circle with a name inside. Though UML 2.4 specification calls it name of the edge, provided connector notation and examples suggest that connector has its own name (also called label).

Connectors are generally used to avoid drawing a long edge. This is purely notational. It does not affect the underlying model. The circles and lines involved map to a single activity edge in the model. Every connector with a given label must be paired with exactly one other with the same label on the same activity diagram. One connector must have exactly one incoming edge and the other exactly one outgoing edge, each with the same type of flow, object or control.

Connector A connects two edges between Fill Order and Review Order.

Object Flow Edge

Object flow edges are activity edges used to show data flow of object and data tokens between action nodes. An object flow is notated by an arrowed line.

Object flow of Orders between Fill Order and Review Order actions Any number of tokens can pass along the edge, in groups at one time, or individually at different times. The weight attribute dictates the minimum number of tokens that must traverse the edge at the same time. When the minimum number of tokens are offered, all the tokens at the source are offered to the target all at once. The weight of the edge may be shown in curly braces that contain the weight. The weight is a value specification, which may be a constant, that evaluates to a non-zero unlimited natural value. An unlimited weight is notated as "*".

Send Notification when number of Warnings reaches 6.

Interrupting Edge
Interrupting edge is activity edge expressing interruption for regions having interruptions. It is rendered as a lightning-bolt.

Cancel Request signal causes interruption resulting in Cancel Order. An option for notating an interrupting edge is a zig zag adornment on a straight line.

Cancel Request signal causes interruption resulting in Cancel Order.

Object
An object node is an activity node that is part of defining object flow in an activity. It indicates that an instance of a particular Classifier, possibly in a particular state, may be available at a particular point in the activity. Object nodes can be used in a variety of ways, depending on where objects are flowing from and to. Object nodes are notated as rectangles. A name labeling the node is placed inside the symbol, where the name indicates the type of the object node, or the name and type of the node in the format "name:type."

Object flow of Orders between Fill Order and Review Order actions

The name can also be qualified by a state or states, which is to be written within brackets below the name of the type. Upper bounds, ordering, and control type other than the defaults are notated in braces underneath the object node. Noticed some spelling error? Select the text with your mouse and press Ctrl + Enter. 6 Comments
o o o
Disqus Login About Disqus Like Dislike 13 people liked this.

Glad you liked it. Would you like to share?

Facebook Twitter Share No thanks Sharing this page Thanks! Close

Add New Comment

Image Post as

Showing 6 comments
Sort by
New est first

Subscribe by email

Subscribe by RSS

Prad124

4 days ago

Thanks !! That's quite a lot of info..neat and clear.

Flag

Like ReplyReply

Josh

1 month ago

Thanks for sharing... What do you use to connect the note symbol with the decision node?


Flag

Like ReplyReply

Michael Allen

1 month ago

Thanks for sharing! bookmarked as reference.

Flag

1 person liked this. Like ReplyReply

Lalit Singh

2 months ago

Can we connect a decision node to decision node in sequnce ?

Flag

Like ReplyReply

KF

2 months ago in reply to Lalit Singh

yes, it is ok to connect several decision nodes - to make one decision following another. Flag Like ReplyReply

Antony492

7 months ago

Thanks! This helped with my coursework!

Flag

1 person liked this. Like ReplyReply

blog comments powered by DISQUS

This document describes UML 2.4 and is based on OMG Unified Modeling Language (OMG UML) 2.4 specification [UML 2.4 - Superstructure].

All UML diagrams were created in Microsoft Visio 2007, 2010 using UML 2.2 stencils by Pavel Hruby. Images of UML elements and diagrams may be used without written permission for any personal, educational, or nonprofit use provided this website is credited. Any commercial or other use requires prior written permission. You can send your comments and suggestions to web master at webmaster@uml-diagrams.org.