UML 2 Activity and Action Models, Part 2

This is the second 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 first article covered motivation and architecture for the new models, basic aspects of UML 2 activities and actions, and introduced the general notion of behavior in UML 2 [2]. The remainder of the series elaborates specific elements in the models. This article recaps behavior models in UML and the role of actions in them. It covers the execution characteristics of actions in general, which inherit to the many kinds of actions provided in UML 2. It also covers additional characteristics of actions that invoke behaviors. UML is divided into structural and behavioral specifications, that is, models of the static and dynamic aspects of a system. Behavior models specify how the structural aspects of a system change over time. UML has three behavior models: activities, state machines, and interactions. Activities focus on the sequence, conditions, and inputs and outputs for invoking other behaviors, state machines show how events cause changes of object state and invoke other behaviors, and interactions describe message-passing between objects that causes invocation of other behaviors. Each kind of behavior model emphasizes a different aspect of system dynamics, making one or the other more suitable for a particular application, or stage of application development. Behaviors can be invoked directly, or as methods on objects accessed through operations on objects. For example, in Figure 1 the DELIVER MAIL behavior can be invoked directly, or through the DELIVERMAIL operation on an instance of the POEMPLOYEE class (the arrow is only for exposition, it is not UML notation). Invoking a behavior through an operation means that an object determines at runtime which behavior actually executes, whereas no object is needed to invoke a behavior directly and the behavior to be invoked is specified at design-time. The provision for first-class behaviors independent of objects was introduced in UML 1.5 [3]. These can be used, for example, when modeling function libraries of popular programming languages, They also facilitate