Activities (OOM)

An activity is the invocation of a manual or automated action, such as "send a mail", or "increment a counter". When the activity gains control, it performs its action and then, depending on the result of the action, the transition (control flow) is passed to another activity.

An activity can be created in the following diagrams:

Activity Diagram

PowerDesigner's support for UML 2 allows you a great deal of flexibility in the level of detail you provide in your activity diagrams. You can simply link activities together to show the high-level control flow, or refine your model by specifying the:

parameters that are passed between the activities (see Specifying activity parameters)
action type of the activity and associate it with other model objects (see Specifying action types)

In the example above, the ReceiveCheckLogin activity has an action type of "Accept call" (see Specifying action types), and passes the two output parameters "login" and "password" (see Specifying activity parameters) to a series of decisions that lead to the ReplyCheckLogin. This last activity has an input parameter called "Result" and an action type of Reply Call.

Atomic and Decomposed Activities

An activity can be atomic or decomposed. Decomposed activities contain sub-activities, which are represented in a sub-diagram. For more information, see Decomposed activities and sub-activities.

A PowerDesigner activity is equivalent to a UML activity (ActionState or SubactivityState) and an activity graph. In UML, an ActionState represents the execution of an atomic action, and the SubactivityState is the execution of an activity graph (which is, in turn, the description of a complex action represented by sub-activities).

The following table lists the mappings between UML and PowerDesigner terminology and concepts:

UML Objects	PowerDesigner Objects
ActionState	Activity
SubactivityState	Composite activity
Activity Graph	Composite activity

PowerDesigner combines a SubactivityState and an activity graph into a decomposed activity so that you can define sub-activities directly under the parent without defining an additional object. If you do need to highlight the difference, you can create activities directly under the model or the package, and use activity shortcuts to detail the activity implementation, so that the SubactivityState corresponds to the shortcut of a decomposed activity.

Creating an Activity
You can create an activity from the Toolbox, Browser, or Model menu.
Activity Properties
To view or edit an activity's properties, double-click its diagram symbol or Browser or list entry. The property sheet tabs and fields listed here are those available by default, before any customization of the interface by you or an administrator.
Specifying Activity Parameters
Activity parameters are values passed between activities. They are represented as small squares on the edges of activity symbols. In the example below, the parameters login and password are passed from the Enter login activity to the Check login activity:
Specifying Action Types
You can add additional detail to your modeling of activities by specifying the type of action performed and, in certain cases, associating it with a specific model object that it acts upon, and the parameters that it passes.
Decomposed Activities and Sub-Activities
A decomposed activity is an activity that contains sub-activities. It is equivalent to a SubactivityState and an activity graph in UML. The decomposed activity behaves like a specialized package or container. A sub-activity can itself be decomposed into further sub-activities, and so on.

Parent topic: Dynamic Diagrams