Professional Documents
Culture Documents
UML Activity Diagrams
UML Activity Diagrams
Guidelines
Visual Studio 2013
Other Versions
In Visual Studio Ultimate, you can draw an activity diagram to describe a business process or
a software algorithm as a flow of work through a series of actions. People, software
components, or devices can perform these actions. For a video demonstration, see: Capture
Business Workflows by using Activity Diagrams.
To create a UML activity diagram, on the Architecture menu, click New Diagram.
You can use an activity diagram for many purposes:
To describe a business process or a flow of work between users and your system. For
more information, see Modeling User Requirements.
To describe the steps performed in a use case. For more information, see UML Use
Case Diagrams: Guidelines.
To describe a method, function or operation in software. For more information,
see Modeling the Architecture of a Software System.
Drawing an activity diagram can help you improve a process. If the diagram of an existing
process proves to be very complex, you can consider how the process could be simplified.
For reference information about the elements on activity diagrams, see UML Activity
Diagrams: Reference.
In This Topic
Relationship to Other Diagrams
Basic Steps for Drawing Activity Diagrams
Describing Control Flow
Describing Data Flow
Defining an Action in More Detail
Concurrent Flows
Relationship to Other Diagrams
If you draw an activity diagram to describe a business process, or a way in which users use
your system, you can draw a use case diagram to show a different view of the same
information. In the use case diagram, you draw actions as use cases. Give the use cases the
same names as the corresponding actions. The advantages of the use case view are that
you can:
Show in one diagram how larger actions/use cases are composed of smaller ones,
using the Includes relation.
Connect each action/use case explicitly to the users or external systems involved in
its execution.
Draw boundaries around the actions/use cases supported by your system, or each
major component of it.
You can also draw an activity diagram to describe the detailed design of a software
operation.
In an activity diagram, you can show the flow of data passed between actions. See the
section on Describing Data Flow. But an activity diagram does not describe the structure of
the data. For that purpose, you can draw a UML class diagram. For information see UML
Class Diagrams: Guidelines.
Basic Steps for Drawing Activity Diagrams
Detailed steps for creating any of the modeling diagrams are described in How to: Edit UML
Models and Diagrams.
To draw an activity diagram
1. On the Architecture menu, click New Diagram.
2. Under Templates, click UML Activity Diagram.
3. Name the diagram.
4. In Add to Modeling Project, select an existing modeling project in your solution,
or Create a New Modeling Project.
To draw elements on an activity diagram
1. Drag elements from the toolbox onto the diagram.
Start by placing the main activities on the diagram, connecting them, and then
adding final touches such as the initial and final nodes.
Note
You cannot drag existing elements onto the diagram from UML Model Explorer.
2. To connect the elements, follow these steps:
a. In the Activity Diagram toolbox, click Connector.
b. On the diagram, click the source element.
c. Click the target element.
Note
Note
The activity will appear in UML Model Explorer only when you add the first element to the diagram.
Activity diagrams use Actions and Connectors to describe your system or application as a
series of actions with the control flowing sequentially from one action to the next.
Create an Action (1) for each major task that is performed by a user, the system, or
both in collaboration.
Note
Try to describe your process or algorithm with just a few actions. You can use Call Behavior Actions to
detail in a separate diagram, as described in Describing Sub-activities with Call Behavior Actions.
Make sure that the title of each action clearly indicates what it typically achieves.
Link the actions in sequence with Connectors (2).
Each action ends before the next action in the control flow begins. If you want to
describe actions that overlap, use a Fork Node as described in the
section Concurrent Flows.
Although the diagram describes the sequence of actions, it does not describe how the
actions are executed, or how control is passed from one action to the next. If you use the
diagram to represent a business process, control might be passed, for example, when one
person sends an e-mail message to another. If you use the diagram to represent a software
design, control might be passed by the normal flow of execution from one statement to the
next.
Describing Decisions and Loops
Use a Decision Node (3) to indicate a point where the outcome of a decision
dictates the next step. You can draw as many outgoing paths as you want.
If you use the activity diagram to define part of an application, you should define the
guards (4) so that it is clear when each path should be taken. Right-click the
connector, click Properties, and in the Properties window, type a value for
the Guard field.
It is not always necessary to define the guards. For example, if you use the activity
diagram to describe a business process or an interaction protocol, a branch defines
the range of options open to the user or to the interacting components.
Use a Merge Node (5) to bring together two or more alternative flows that branched
at a Decision Node.
Note
You should use a Merge Node to bring together alternative flows, instead of bringing the flows together
it would not be correct to connect from the decision node directly back to Choose Menu Item. This is b
start until threads of control have arrived at all its incoming connectors. Therefore, you should bring onl
at an action. For more information, seeConcurrent Flows.
Use branches to describe loops, as shown in the example.
Note
Try to nest loops in a well-structured way, as you would in program code. If you are describing an existi
might reveal some opportunities for improving it.
Note
For an overview of the elements used in this section, see the Data Flows section of the topic see UML A
Describing Data Flow with Object Nodes
Most control flows carry data. For example, the output flow from the "Customer provides
details" action carries a reference to the shipping address.
If you want to describe that data on your diagram, you can replace a connector with an
object node and two connectors as shown in the following figure.
Notice that the round-cornered rectangles, such as Dispatch Goods, represent actions, where
processing occurs. The square-cornered rectangles, such as Shipment Address, represent a
flow of objects from one action to another.
Give the object node a name that reflects the role of the node as a conduit or buffer of the
objects that flow between the actions.
You can set the Type of the object node in the Properties window. The type can be a
primitive type such as Integer, or a class, interface, or enumeration that you have defined in
a class diagram. For example, you could create a class Shipment Address, with attributes of
Street Address, City, and so on, together with an association to another class that is named
Customer. For more information, see UML Class Diagrams: Guidelines.
Note
If you type the name of a type that has not yet been defined, an item will be added under Unspecified Types in
you subsequently define a type of that name in a class diagram, you should reset the type of the object node so t
type.
To create a pin, click Input Pin or Output Pin on the toolbox and then click an action. You
can then move the pin around the perimeter of the action, and change its name. You can
create input and output pins on any kind of action, including Call Behavior Actions, Call
Operation Actions, Send Signal Actions, and Accept Event Actions.
A connector between two pins represents an object flow, just as the flows to and from an
object node do.
Give each pin a name that indicates the role of the objects it produces or accepts, such as a
parameter name.
You can set the type of objects transmitted in the Type property. This must be a type that
you have created in a UML Class Diagram.
The objects flowing between connected pins must be compatible in some way. This could be
because the objects produced by the output pin belong to a derived type of the input pin's
type.
Alternatively you can specify that the object flow includes a transformation that converts
data between the type of the output pin and the type of the input pin. The most common
transformation of this kind just extracts the appropriate part from a larger type. The example
in the figure implies the existence of a transformation that extracts the Shipping Address
from the Order Detail.
Defining an Action in More Detail
In addition to using the name of the action to make clear the result it should ordinarily
achieve, here are some ways you can add more detail to an action:
Write a more detailed description in the Body property. For example, you could write
a fragment of program code or pseudo code, or a complete description of the results
achieved.
Replace the action with a Call Behavior Action, and describe its detailed behavior
within a separate activity diagram. See Describing Sub-activities with Call Behavior
Actions.
Set the action's Local Postconditions and Local Preconditions properties to
describe its outcome in more specific detail. For more information, seeDefining
Postconditions and Preconditions.
Describing Sub-activities with Call Behavior Actions
You can describe the detailed behavior of an action using a separate activity diagram. A
called behavior is an activity diagram that is represented on your main activity diagram by a
Call Behavior Action. You can also use the Call Behavior Action to describe behavior that is
shared between different activities so that you do not have to draw the sub-activity multiple
times.
In the following figure, Diagram 1 shows an activity that has a Call Behavior Action and
Diagram 2 shows the sub-activity diagram that shows the called behavior.
To describe a sub-activity with a Call Behavior Action
1. To create the diagram for the sub-activity, in Solution Explorer, right-click your
modeling project, point to Add, and then click New Item.
2. In the Add New Item dialog box, under Templates click Activity Diagram and in
the Name box type the name that you plan to give your Call Behavior Action.
3. Draw the detailed work flow for the sub-activity. This is the called behavior.
o In the called sub-activity diagram, the Initial Node indicates where control
starts when the called behavior is invoked. The Activity Final Nodeshows
where control should return to the parent activity.
4. Set the Behavior property of the Call Behavior Action to refer to the called
behavior diagram.
Note
The sub-activity diagram must have some elements on it or the diagram will not be available in the drop
the Behavior property. Also, the trident icon will not appear on your Call Behavior Action shape until y
its Behavior property.
5. Set the Is Synchronous property of the action to indicate whether your activity
waits for the called activity to complete.
o If you set Is Synchronous to false, you are indicating that the flow can
continue to the next action before the called activity finishes. You should not
define output pins or outgoing data flows from the action.
Describing data flow in and out of sub-activities
You can describe the data flowing in and out of sub-activities, in the same way that you use
parameters in software.
Create input and output pins (1) on the Called Behavior Action, for each piece of data
that flows into or out of the action. Name each one appropriately.
In the sub-activity diagram, create an Activity Parameter Node (2) for each input
and output pin on the calling action. Give each node the same name as its
corresponding pin.
Note
An activity parameter node resembles an object node. To check what type of node that you are looking a
then clickProperties. The type of node is shown in the header of the Properties window.
In the sub-activity diagram, draw connectors that show the flow of objects into or out
of each activity parameter node.
When the "Customer provides details" action completes, it produces two objects: "Shipment
address" and "Credit card details." The two objects go forward for processing by different
actions.
Because an action requires all its inputs to be available before it can start, the last action
does not start until all the actions that lead to it are complete.
Streams
You can use an activity diagram to help you describe a pipeline or a series of actions that
execute at the same time, and continuously pass data from one action to another.
The intention in the following example is that each action can produce objects and continue
to work. Because there are no control flows, each action can start as soon as it receives its
first objects.
Notice that the connectors in this example are object flows, because they all have at least
one end on an Activity Parameter Node, Object Node, or on an Input or Output Pin.
1. The example has three Activity Parameter Nodes, which represent its inputs and outputs.
2. Object Nodes, Input Pins and Output Pins can represent buffers. You can set the Upper
Bound property of an Object Node to state how many objects can be in the buffer at the
same time.
3. You can use Decision nodes to show that a stream divides, sending different objects down
different branches. You can use comments or the titles of the nodes to explain what the
dividing criterion is.
4. You can use Fork nodes to show that two or more copies of the objects are made, sending
them for concurrent processing.
5. You can use Join nodes to show that two streams of processing are merged back into one.
Selection and Transformation
You can specify that the objects in an object flow are transformed, selected, or both. An
object flow is a flow to or from a pin or an object node.
A transformation describes how objects entering a flow are converted to another
type.
A selection describes how only some of the objects entering a flow are transmitted to
the receiving action.
The example shows a transformation. The first action in Diagram 1 produces a postal code,
or zip code, at an output pin. This is connected to an input pin on the second action. But the
second action expects a fully-specified address. The conversion from one type to another is
specified in a second activity, Address Lookup. This is referenced from the Transformation
property of the object flow. The Address Lookup activity contains one Activity Parameter
Node for the incoming postal code, and another Activity Parameter Node for the outgoing full
address.