UML 2 Activity and Action Models
Conrad Bock, U.S. National Institute
of Standards and Technology
|
 |
COLUMN
PDF Version |
This is the first in a series introducing the activity model in the
Unified Modeling Language, version 2 (UML 2), and how it integrates
with the action model [1]. The series is a companion
to the standard, providing additional background, rationale, examples,
and introducing concepts in a logical order. This article covers motivation
and architecture for the new models, basic aspects of UML 2 activities
and actions, and introduces the general notion of behavior in UML 2.
1 BACKGROUND
A focus of recent developments in UML has been on procedures and processes.
UML 1.5 introduced a model for parameterized procedures defined by control
and data flow to complement the existing state and interaction models
[2]. For the first time UML supports first-class
procedures that can be used as methods on objects or independently of
objects, as occurs when modeling, for example, function libraries with
popular programming languages. It also facilitates application of UML
by modelers who do not use object-orientation (OO) routinely, such as
system engineers and enterprise modelers, and provides them a path to
incrementally adopt OO as needed [3]. The flexibility
to combine OO with functional approaches considerably widens and integrates
the potential applications of UML.
Figure 1: UML Timeline
UML 1.5 also inherited from earlier versions a form of state machine
that was notationally modified to appear as a flow diagram, called the
activity diagram. Unfortunately, the underlying state machine semantics
restricts expressiveness and is confusing to users. Especially those
not using an OO approach perceive UML 1.x activity models as not working
for them. There is also concern that UML 1.5 has multiple models for
control and data flow.
In light of this experience, UML 2.0 redefined the activity model to
give it a basis in flow modeling intuition, and to integrate it with
the UML 1.5 action model. The new activity model supports the control
and data flow of UML 1.5 procedures, as well as more general features,
such as cycles and queuing. Consequently, UML 2 activities support flow
modeling across a wide variety of domains, from computational to physical.
This makes it ideal for specifying systems independently of whether
the implementation is software or hardware, as in system engineering,
and independently of where the system/environment boundary is drawn.
Finally, the combination of activities and actions retains the UML 1.x
capability of reacting to events, so can be applied to areas requiring
that, such as embedded and agent-based systems.
2 MULTIPLE DOMAINS
Although the UML 2 activity and action models are defined independently
of application, some features are more appropriate to some domain styles
than others. For example, actions for throwing exceptions will probably
be used more often by programmers, whereas enterprise modelers are more
likely to apply other techniques for atypical flows, such as exception
parameters and interrupting regions. This redundancy is unavoidable
when creating an abstraction over user groups that do not overlap. However,
it is more than made up for by the efficiency in communication based
on a common model between domains that are integrated in delivered systems.
To support vendors focusing on particular users, the activity model
is packaged in a more fine-grained way than other behavior models, and
has more complex dependencies between packages, as shown in Figure 2.
Figure 2: Activity Package Dependencies
The features in common between the applications, such as the abstract
action concept, control/data flow, and input/output, are at the root
(basic activities). From there, dependencies branches in two directions,
one mainly for software modeling (structured activities), and the other
for general process modeling (intermediate and complete activities).
Structured activities introduce well-nested constructs, for modeling
conditionals, variables, try/catch, and so on. Intermediate and complete
activities introduce explicit parallelism, partitions, flow-based forms
of exception handling, and a number of constructs for finer-grained
control of flows. These are orthogonal branches, so they may be combined.
For example, structured activities may be folded in with intermediate
activities, to support explicit parallelism and structured conditionals
at the same time1. This series will
cover the functionality of the various packages.
Supporting a wide range of applications also requires multiple notations.
For example, programmers tend to favor textual notations, while subject
matter experts prefer graphical notations. UML addresses this by defining
a repository for storing specifications that can be populated from multiple
notations. Programmers can use a textual syntax to build and read activity
models in the repository, and enterprise modelers can use a graphical
notation. The UML repository is a communication medium between multiple
notations, and a source for highly directable compilers targeting multiple
platforms [4].
3 FLOW MODELS AND SEMANTICS
Behavior models in general determine when other behaviors should start
and what their inputs are [3]. In particular, the
UML 2 activity models follow traditional control and data flow approaches
by initiating subbehaviors according to when others finish and when
inputs are available. It is typical for users of control and data flow
to visualize runtime effect by following lines in a diagram from earlier
to later end points, and to imagine control and data moving along the
lines. Consequently a token flow semantics inspired by Petri nets is
most intuitive for these users, where "token" is just a general
term for control and data values.
UML 2 takes the same approach to behavioral semantics as UML 1.x, namely
to define intuitive virtual machines. This enables users and vendors
to predict the runtime effect of their models. UML 2 activities define
a virtual machine based on routing of control and data through a graph
of nodes connected by edges. Each node and edge defines when control
and data values move through it. These token movement rules can be combined
to predict the behavior of the entire graph2.
The rules for control and data movement are only intended to predict
runtime effect, that is, when behaviors will start and with what inputs.
They do not constrain implementation further than that. In particular,
the rules do not imply that activity models must be implemented as a
virtual machine corresponding to the token analogy, messaging passing,
or any other scheme. It is only necessary that the runtime effects predicted
by the virtual machine actually occur in the implementation.
The activity model is defined with few semantic variations, which is
the UML term for allowing implementations to choose alternative runtime
behavior without recording those choices in the model. Semantic variations
cause a model in one implementation to execute differently than the
same model in another implementation, with no standard way to tell what
the differences are. Variations in activity execution are mostly modeled
as attribute values in the user’s model. This means they are under
user control and are transmitted to other users without requiring implicit
alignment of implementations.
4 ACTIVITY NODES AND EDGES
UML 2 activities contain nodes connected by edges to form a complete
flow graph. Control and data values flow along the edges and are operated
on by the nodes, routed to other nodes, or stored temporarily. More
specifically, there are three kinds of node in activity models:
- Action nodes operate on control and data values that they receive,
and provide control and data to other actions.
- Control nodes route control and data tokens through the graph. These
include constructs for choosing between alternative flows (decision
points), for proceeding along multiple flows in parallel (forks),
and so on.
- Object nodes hold data tokens temporarily as they wait to move
through the graph.
Figure 3 shows the notation for some of the activity nodes to be discussed.
Contrary to the names, control nodes coordinate both data flow and
control flow in the graph, and object nodes can hold both objects
and data3.
Activity nodes are connected by two kinds of directed edges:
- Control flow edges connect actions to indicate that the action at
the target end of the edge (the arrowhead) cannot start until the
source action finishes. Only control tokens can pass along control
flow edges.
- Object flow edges connect objects nodes to provide inputs to actions.
Only objects and data tokens can pass along object flow edges.
Figure 3: Activity Nodes
Figure 4 shows the notation for edges. Control and object flow edges
are distinguished by usage. Control edges connect actions directly,
whereas object flow edges connect the inputs and outputs of actions
(see next section).
Figure 4: Activity Edges
This rest of this article introduces actions and edges with a small
example. Later articles will cover the other kinds of nodes, and more
features of actions and edges.
5 ACTIONS
Activity models coordinate actions, some of which may invoke user-defined
behaviors, including other activities. All actions are predefined. For
example, UML 2 has actions to create objects, set attributes values,
link objects together, and to invoke user-defined behaviors. Actions
can have inputs and outputs, which are called pins, that are connected
by object flow edges to show how values flow through the activity, provided
by some actions and received by others. In the simple cases, all inputs
to an action are required to be available for it to begin executing.
Figure 5 shows an example of an action creating a new instance of an
Order class, then another action invoking
a user-defined behavior to fill it. The object creation action creates
a blank order that FillOrder completes.
Action nodes are notated with round cornered rectangles4,
5. At the top of Figure 5, the small
rectangles attached to the actions are input and output pins. The type
of object accepted as input or provided as output is shown as an adornment.
The notation at the bottom of Figure 5 can be used when the types of
input and output are the same. Pins are a kind of object node, so they
also hold data values temporarily in the flow.
Figure 5: Example Actions and Object Flow Edges
As mentioned before, it is not necessary to use the notation of Figure
5. Programmers will mostly likely prefer a textual notation [4],
such as:
Order o;
o = new Order;
FillOrder(o);
The repository model defined by UML 2 is the same for the above notations,
as shown in Figure 6, assuming the variables of the textual language
are modeled as dataflow6. Each element
of the repository is an instance of a metaclass defined in the UML specification,
which is the name to the right of the colon. The name of the repository
instance itself is to the left of the colon, blank if it is anonymous.
The model shows a CreateObjectAction
with an output pin passing its value to the input pin of a CallBehaviorAction.
The CreateObjectAction is linked to the
user class it instantiates (Order), and the CallBehaviorAction
is linked to the user-defined behavior it invokes (FillOrder).
Figure 6: Repository model for Figure 5
The primitive actions for creating objects, invoking user-defined behaviors,
and so on, are not technically behaviors themselves, but this is more
an artifact of metamodeling than a conceptual distinction. The fundamental
distinction is between a specification of dynamic effect and its usage,
to support multiple usages of the same specification. For example, the
same FillOrder behavior may be invoked in many activity diagrams, or
many times in the same activity diagram, but each invocation will be
represented by a separate instance of CallBehaviorAction in the repository,
all referring to the same FillOrder behavior. This is because each usage
of FillOrder will be in a different flow, or at different points in
the same flow, and each usage may have different actions before and
after it. For example, Figure 6 has a CreateObjectAction before FillOrder,
whereas another flow might not7.
Actions are also reusable, but this happens to be modeled in a different
way than user-defined behaviors. Each action in a flow is a new instance
of a single class from the UML metamodel. For example, if an activity
contains two object creation action nodes, then the user’s repository
has two instances of the CreateObjectAction class from the UML metamodel,
and separate sets of pins for each. Reusability is achieved by using
multiple instances of the same UML metaclass as action usages8. Later
articles will cover the various kinds of actions.
6 ACTIVITIES
Activities are user-defined behaviors, and like all behaviors in UML
2 can be initiated by invocation actions, and support parameters to
receive and provide data to the invoker. Parameters are part of the
reusable definition of an activity. Parameters are not pins, because
pins are used to connect actions in a flow, whereas activities are behaviors
invoked by actions (see previous section). However, to access parameter
values from actions in the activity, activity parameters are modeled
as a special kind of object node used to temporarily hold actual parameter
values as they flow into and out of the activity. Figure 7 shows a parameterized
activity with a parameter object node connected to pins on actions.
Parameter object nodes are shown on the border, with object flow edges
connecting them to pins. The type of object held in an object node is
usually shown in the label. In this example, the information used to
fill the order is provided as an input parameter and passed along to
the invocation of the FillOrder behavior.
Figure 7: Example Activity
The control nodes at the beginning and end of the flow in Figure 7
are initial and final nodes respectively. When the OrderActivity is
invoked, a control token is placed at the initial node, and a data token
with ordering information is placed at the input parameter object node.
The control token flows from the initial node to the CreateOrder action,
which begins executing. The data token flows from the parameter to the
invocation action for FillOrder, which must wait for CreateOrder to
provide its other input before starting. When FillOrder is done, a control
token is passed to the final node and the activity terminates, returning
control to execution that started it. A partial repository model for
Figure 7 is in Figure 8 below. It connects to the repository model of
Figure 6 through the CB1 CallBehaviorAction. The CreateOrder action
and its flows are omitted for brevity.
Figure 8: Partial repository model for Figure 7
7 BEHAVIOR IN UML 2
UML 2 supports the concept of parameterized behavior for all the kinds
of behavior in UML, not just activities. This means state machines,
interactions, and activities all can be parameterized, and be methods
on objects or invoked directly, in a uniform way. The upper right of
Figure 9 shows an activity model for a behavior called DeliverMail
(the curved arrows are not part of UML notation). DeliverMail
could be invoked as is with a CallBehaviorAction,
or as a method on the POEmployee class
with a CallOperationAction. In either
case, the behavior takes an instance of KEY as input. Because behaviors
can be invoked directly or as operations, UML 2 provides a path to incrementally
adopt object-orientation [3].
Figure 9: UML 2 Behavior
UML 2 user-defined behaviors are also classes. Each time a behavior
is executed at runtime, a new runtime instance of the user’s behavior
class is created. The instance is destroyed when the behavior terminates.
Behavior classes, like all classes, can support attributes, associations,
operations, and even other behaviors, such as state machines. This reflects
common practice in systems that manage processes, for example, workflow
and operating systems. The bottom of Figure 8 shows the behavior class
for the DeliverMail activity with an
attribute for how long each execution of DeliverMail
has been running, an operation to abort the execution, and an association
for the truck it is using. Applications can also put state machines
on the behavior class to describe the status of each execution, such
as NOT_STARTED, SUSPENDED, and so on [5] [6].
UML 2 behavior classes enable the definition of standard functionality
for process management, even though UML 2 does not define standard features
itself. Behavior class features can be defined by domain standards,
vendors, or user groups as reusable model libraries containing abstract
behavior classes with normative attributes and operations such as ABORT
and so on. Then these classes can be used as supertypes of user-defined
behaviors such as DeliverMail in Figure 9.
8 CONCLUSION
This article begins a series on the UML 2 activity and action models.
It reviews progress in UML flow modeling, package structure needed to
serve the wide range of flow modeling applications, UML's approach to
semantics, then introduces some basic elements of activity modeling,
and the UML 2 behavior model generally.
Footnotes
1The action model should be finely
packaged to correspond with activities, but is currently divided into
IntermediateActions and CompleteActions
only. These contain the predefined actions, such as object creation, setting attributes, and so on. The
abstract notion of action is defined in the BasicActivities package
because it is integral to the flow model. See later sections of this
article.
2It is hoped that the rules are
precise enough to be translated to a formal semantics, especially to
support proving properties about modeled processes. This is left for
future work.
3UML abstracts from objects and
data to classifiers in general.
4The wording inside the action nodes
is not normative, because a standard textual notation for actions is
not adopted yet. Also action nodes can be given labels that are more
descriptive than the predefined action name.
5The round cornered notation is
also used by state machines to notate states, unfortunately. This is
not a desirable situation. However, it is beneficial to those users
and vendors who have been trying to apply state machines to flow modeling
applications, for lack of a flow modeling standard until now.
6UML 1.5 and UML 2 also support
variables if needed.
7Programming languages make the
same distinction between a procedure declaration or definition, which
has the signature, and statements that call the procedure, providing
actual parameters at runtime. In UML 2 terms, a procedure definition
is a behavior, and a statement is an action.
8It is possible that actions could be modeled in the same way as user-defined
behaviors and be standardized as a reusable model library. Then only
one predefined action would be needed to invoke all behaviors, whether
predefined or user-defined. However, the static requirements of predefined
actions, such as CreateObjectAction requiring a class to instantiate,
would need to be recorded in constraints rather than associations in
the metamodel. Constraints are generally not as easy to read in the
UML specification as metamodel associations.
ACKNOWLEDGEMENTS
Thanks to Evan Wallace and James Odell for their input to this article.
REFERENCES
[1] U2 Partners, “Unified Modeling Language:
Superstructure”, version 2.0, 3rd revised submission to OMG RFP
ad/00-09-02, http://www.omg.org/cgi-bin/doc?ad/2003-04-01,
April 2003.
[2] Object Management Group, “OMG Unified Modeling Language”,
version 1.5, http://www.omg.org/cgi-bin/doc?formal/03-03-01,
March 2003.
[3] Bock, Conrad, "Three Kinds of Behavior Model," Journal
of Object-Oriented Programming, 12:4, July/August 1999.
[4] Bock, Conrad, “UML Without Pictures”, to appear in
IEEE Computer Special Issue on Model-driven Development, September/October
2003.
[5] Object Management Group, “Workflow Management Facility Specification”,
version 1.2, http://www.omg.org/cgi-bin/doc?formal/00-05-02,
May 2000.
[6] Workflow Management Coalition, “Workflow Standard - Interoperability
Abstract Specification”, http://www.wfmc.org/standards/docs/TC-1012_Nov_99.pdf,
November 1999.
About the author
|
 |
Conrad Bock is a Computer Scientist
at the National Institute of Standards and Technology. He is the
workgroup lead for activities and actions in the UML 2 submission
team, and can be reached at conrad.bock at nist.gov.
|
Cite this column as follows: Conrad Bock: “UML 2 Activity and
Action Models”, in Journal of Object Technology, vol.
2, no. 4, July-August 2003, pp. 43-53. http://www.jot.fm/issues/issue_2003_07/column3
|
