Activity diagrams
Definition
Activity diagrams are used to illustrate workflows in a system, from the business level down to the operational level.
Activity
diagrams (an example is shown below) are created in activities, which are
themselves created in packages, classes, interfaces, actors, use cases, components
and collaborations.
The following
screenshot shows an example of an Objecteering activity diagram.
An example of an activity diagram
Activity partitions and sub-partitions
An activity partition is a kind of activity group used to identify actions that have some characteristics in common.
Activity partitions and
sub-partitions are laid out vertically or horizontally depending on diagram
orientation (chosen when the diagram is created, by either clicking on the 
"Create a vertical activity
diagram" or the 
"Create a horizontal activity
diagram" icon).
Activity partitions are created by
clicking on the 
"Create
an activity partition" icon and then clicking on the diagram background.
The newly created partition will be laid out on the left or right (for a
vertical diagram) or at the top or bottom (for a horizontal diagram) of
existing partitions, depending on where you click.
When you create an activity partition directly under an activity in the explorer, an activity partition is automatically created and laid out in every diagram belonging to this activity.
Activity sub-partitions are created
by clicking on the same "Create an activity partition" icon
and then clicking on the header of the existing activity partition or sub-partition
to which you want to add the new sub-partition.
When you create an activity sub-partition directly under an activity partition or sub-partition in the explorer, an activity sub-partition is automatically created and laid out in every diagram belonging to the activity containing these partitions.
Activity actions
Activity actions are used to represent actions in an activity diagram.
Aside from the basic action node, the following specific activity actions exist:
|
Element |
Role |
Creation icon |
|
Call behavior action node |
Call behaviour action nodes are used for an action that is another activity in the model. If this node actually represents another activity, then you can access this activity’s first diagram by using the "Open related diagram" command in the context menu. |
|
|
Call operation action node |
Call operation action nodes are used for an action that is an operation in the model. |
|
|
|
|
|
|
Conditional node |
Conditional nodes are used for an action whose execution will depend on the realization of a particular condition. These conditions and the associated executions can be shown by adding conditional clauses to the conditional node and then creating and/or moving elements directly in the clause. |
|
|
Structured activity node |
The structured activity node is used for an action made up of several simpler elements. These elements can be created and/or moved directly inside the structured activity node. |
|
|
Send signal action node |
The send signal action node is used to represent a signal being sent. |
|
|
Accept signal action node |
The accept signal action, accept call event action, accept change event action and accept time event action nodes are used to represent the reception of an external element (respectively a signal, a call event, a change event or a time event). |
|
|
Accept call event action node |
|
|
|
Accept change eveng action node |
|
|
|
Accept time event action node |
|
Control nodes
Control nodes represent particular points in the flow(s) expressed in the activity diagram.
|
Element |
Role |
Creation icon |
|
Activity initial node |
The initial node represents the starting point of the flow. |
|
|
Decision-merge node |
The decision-merge node represents a choice in the flow and the merging of the different flows resulting from this choice. |
|
|
Fork/join node |
The fork/join node represents the forking of the flow into several flows or the joining together of several parallel flows. |
|
|
Activity final node |
The activity final node represents the end of a whole activity flow. |
|
|
Flow final node |
The flow final node only expresses the end of the current flow. |
|
Flows
Elements in an activity diagram can be linked by flows. Two types of flow can be created:
· control flows
· object flows
A control flow is an edge that starts an activity node after the previous one is finished.
An object flow is an activity edge that can have objects or data passing along it.
To create a control flow, use the 
"Create a control flow" icon. For an object flow, use the 
"Create an object flow" icon.
You can also use the 
"Create a control or object flow" smart
icon, which will decide whether a control flow or an object flow should be
created, based on the two elements to be linked. A control flow is automatically created when
both the source and the destination of the link are activity actions or control
nodes (see lists above). An object flow
will be created in any other case.
Note: Input pins and output pins are object nodes (see below) and so will produce object flows although they can only be created on activity actions.
Object nodes
Object nodes define the object flow in an activity.
In addition to the default object node, certain specialized object nodes exist:
· A central buffer node is an object node used to manage flows from multiple sources and destinations.
· A data store node is a central buffer node for non-transient information.
· An activity parameter node is an object node for inputs and outputs to activities.
· Input and output pins are object nodes that receive or deliver values to and from other actions through object flows.
Migrating
UML 1.4 activity diagrams to UML 2 activity diagrams
If your model contains activity diagrams created using an earlier
version of Objecteering, these UML 1.4 activity diagrams are automatically
migrated to UML 2 through the automatic creation of a UML 2 activity diagram
when the UML 1.4 activity diagram is opened.
This UML 2 diagram has the same name as the earlier diagram, belongs to
the same model element and is directly displayed.
The new diagram retains the following information from the migration of
the earlier diagram:
- The presence of elements and their embedding
- The size of elements, with regard to the target representation
- The paths of links
Association labels are positioned using the new intelligent positioning
system implemented in UML 2 diagrams.
The following points are specific to activity diagrams:
·
When no color customization has been made to the diagram, default colors
will be applied to the migrated diagram.
·
Action states deferred events are lost on migration, as they have no
equivalent in UML2.
·
Action states that sent events are migrated to SendSignalActions.
·
Action states that referenced operations are migrated to
CallOperationActions.
·
Action states that both referenced operations and sent events will be randomly converted to SendSignalAction or
CallOperationAction, and the other meaning will then be lost.
·
For signal sending pseudo states with many incoming transitions with
associated signals, the migrated SendsignalAction will send only one Signal,
the others will be lost.
Elements not managed by diagram migration are as follows:
- N-ary associations. These
are deleted from the UML 2 diagram.
- Constraints defined on several elements. A single element is presented as being
constrained in the UML 2 diagram.
Since the earlier UML 1.4 activity diagram is conserved, it can still be
opened after migration in the usual way (either by double-clicking on it in the
Objecteering explorer, or through the "Edit" command in the context
menu). The diagram is then opened in
read-only mode, meaning that only the zoom and grab functions are active.
We recommend that the UML 1.4 activity diagram be deleted once it has been migrated. If the new UML 2 activity diagram is renamed, the migration procedure will once again be run the next time the UML 1.4 activity diagram is opened.