Beruflich Dokumente
Kultur Dokumente
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
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.
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.
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.
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.
This method is most useful when you are describing a sub-activity, or where you do
not have to explicitly state what initiates the activity. For example, the activity Order
a Meal clearly begins when a customer gets hungry.
Accept Event Node
Create Accept Event Nodes, as described in the section Concurrent Flows, to
indicate the start of a thread that responds to a particular event, such as a user
input. Do not provide an incoming flow to the node. Omitting an incoming flow
indicates that a thread will be started every time that the event occurs.
This method is most useful when you describe a response to a specific external
event.
Swimlanes
It is sometimes useful to arrange the actions of an activity into areas corresponding to
different objects or business roles that perform the actions. These areas are conventionally
arranged in columns and are called swimlanes.
Use lines or rectangles from the Simple Shapes section of the Toolbox to draw
swimlanes or other areas.
To label each swimlane, create a comment and set its Transparent property to True.
Simple shapes do not form part of the UML model, and do not appear in UML Model Explorer.
Note
For an overview of the elements used in this section, see the Data Flows section of the topic see UML A
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.
You can specify how the items in a buffer are stored by setting properties of the object node:
Set the Ordering property:
o Unordered to specify a random or unspecified order. (Default.)
o Ordered to specify an order according to a specific key.
o Fifo to specify an order of first-in, first-out.
o Lifo to specify an order of last-in, first-out.
Set the Upper Bound property to specify the maximum number of objects that can
be contained in the buffer. The default is *. This means that there is no limit.
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.
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.
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.
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.
You can use the Local Postconditions and Local Preconditions properties to specify in
detail the outcome of an action. These properties describe the effect of the action without
describing how the effect is achieved.
To set these properties, right-click the action and then click Properties. Type values into the
properties in the Properties window.
Local Postconditions
A postcondition is a condition that should be satisfied before the action can be considered
completed. In the example action Confirm Order, the postcondition might be:
The customer has provided complete and valid details that are required for processing his or
her credit card.
A postcondition can express a relationship between the states before and after the action
has occurred. For example:
The interest rate is double what it was before.
You can write postconditions in a more formal style, referring to specific attributes of the
data dealt with in the actions. For example:
InvoiceTotal == Sum(OrderItem.MenuItem.Price)
Local Preconditions
A precondition is a condition that should be true when the action is ready to begin. For
example, the Confirm Order action might have the precondition:
Customer has chosen at least one item from the menu.
Concurrent Flows
You can use the Fork Node and the Join Node to describe two or more threads of activities
that can execute at the same time.
The effect of the Fork Node (1) is to divide the thread of control into two or more threads.
When the previous action ends, all the actions on the output side of the fork can start.
A Join Node (2) brings concurrent threads together. The action after the Join Node may not
start until all the actions leading to the Join Node are complete.
Sending a Signal
Use a Send Signal Action (3) to indicate that a signal or message of some kind is sent to
other activities or processes. Use the name of the action to indicate what kind of message it
sends.
Control immediately passes to the next action in the control flow, if there is one.
You cannot use a Send Signal Action to describe how your process responds to any
returned information. To do that, use a separate Accept Event Action.
You can show incoming data flow to a Send Signal Action, to indicate what data can
be sent with the outgoing message. For more information, seeDescribing Data Flow.
To show that your activity waits for an external event or message at a specific point
in its flow, draw an Accept Event Action with an incoming flow, at the appropriate
place in the activity.
To show that your activity can respond to an external event or message at any time,
draw an Accept Event Action without any incoming flow. When the named external
event occurs, a new thread will begin in your activity, starting from the Accept Event
Action.
You cannot use an Accept Event Action to describe any value returned to the sender
of the signal. Use a separate Send Signal Action for that purpose.
You can show outgoing data flows from the action, to show how your activity
processes data that is received in the signal. If you want to show more than one
output flow, you should set the IsUnmarshall property of the Accept Event Action,
which indicates that the action parses the incoming signal into its separate
components. For more information, see Describing Data Flow.
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.
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.
In Solution Explorer, right-click your project, point to Add, click New Item,
and then click Activity Diagram. Give the diagram an appropriate name for
the transformation or selection flow. Click Add.
2. In the new diagram:
o Create two Activity Parameter Nodes, one for the input flow and one for the
output.
o Create actions interconnected with object flows. This shows how the
transformation or selection works.
b. In any diagram where you want to use the transformation or selection:
o Create an object flow, that is, a connector to or from an input or output pin, an
object node, or an activity parameter node.
o Right-click the object flow and then click Properties.
o In the Transformation or Selection property, select the diagram where you
specified the transformation or selection flow.
You can also define a selection for an object node, and on individual input and output pins.
Define a selection activity as in the previous procedure, and then set the Selection property
of the object node, or input or output pin.
o