3.3 Behavior Primitives: Actions and Activities
| In the UML, Classifiers (specifically BehavioredClassifiers) have behaviors, and one kind of behavior is called an Activity. Activities contain actions, the elemental quanta of UML behavior. Activities provide an execution context for actions, including scope of values (e.g., variables) manipulated by a common set of actions. Activities may be represented textually by an action language or graphically in an activity diagram. An action takes a (possibly empty) set of inputs and produces a (possibly empty) set of outputs. That is, it is a primitive, simple statement similar in scope to a single statement in a standard source-level language, such as "++X" or "a=b+sin(c*p)." Formally speaking, each input value enters the action on an Input Pin and each output value is sent to an Output Pin; however, for virtually all real modeling, the notions of pins can be safely ignored. It is enough to say that actions take input values and computationally produce a set of output values. The UML specification identifies a number of kinds of actions, such as the following:
Some types of PrimitiveActions include
This all may seem confusing (mostly because it is), but if you just remember that actions are meant to describe the kinds of statements you find in standard programming languages, you'll be all right. Actions are normally computationally simple things and, by far, are most commonly represented using an action language. The UML does not define an action language,[3] because most developers want to use the implementation source-level language for the action language in their models. That is, almost all of the time, actions in a UML model are specified in the implementation language of that system. A more abstract action language could be used, allowing the developer to generate code in multiple target languages, but the UML does not define one. There are advantages to using abstract language independence of the model from the implementation being the primary one but there are disadvantages as well, such as making the testing and debugging of the system more difficult. Whether the best action language is the implementation language or abstract action language depends on the nature of the application. If the application has a very long lifecycle or will be ported to multiple environments, then an abstract action language is arguably the best choice. If the application will remain on a single platform, if the difficulty of test and debugging the system is high, if it is clear that a single source language will be used in the implementation, or if you'd like be able to work in either the source language or the model, then using the implementation language to specify the actions will be preferred.
Actions are normally specified in one of three places: First, and most common, actions are simply entered into the bodies of methods defined within classes. This enables the generation of both simple and continuous behaviors, although in most action languages continuous behaviors are "discretized" and differential equations are represented using difference equations. Another common place for actions is in statecharts. In statecharts, activities may be specified for execution when a state is entered or exited, when a particular transition is taken, or when special "do activities" are done after the entry activities are executed. Figure 3-1 shows examples of state entry and transition activities that are executed as the object moves from state to state. These activities may be simple textual lists of actions in the action language, or they may refer to activity diagrams for graphical representation. Actions have "run-to-completion" semantics, meaning that once an action is started it will run until it is done. This does not mean that an action cannot be preempted by another action running in a higher-priority thread, merely what when the context executing that action returns from preemption, it will continue executing that action until it is complete before doing anything else. This means that if an object is executing an action, the action will run to completion even if that object receives events directing it to do something else. The object will not accept the incoming events until the action has completed. For this reason, actions are usually, although not always, short in duration. Activities do not have run-to-completion semantics. Activities may be interruptible between their contained actions.[4] An object executing a "do activity" may receive an event that triggers a transition in its state machine, exiting the state and terminating the activity. Thus, the UML allows the modeling, at a primitive level, of both interruptible and noninterruptible behaviors. Activities are most often represented on activity diagrams and are composed of sequences of action executions that proceed largely through completion (i.e., they progress by completing actions as opposed to waiting for events of interest).
An operation is a specification of an invocable behavior of a Classifier, whereas a Method is the implementation of an Operation. That is, an Operation is a specification of a Method. Operations are synchronously invoked with CallActions and are logically associated with CallEvents in the UML metamodel. Operations have typed parameter lists, as you might expect, and can return typed values. It is common to use an operation call as an action on a state behavior. Modeling of the behavior of an operation is done primarily in two ways. First, and most common, is to simply list, in a textual fashion, all of the actions comprising the internals of the operation or method, such as "write the code" for the method. The second, which will be described shortly, is to model the operation with a synchronous state machine or with an activity diagram. |
EAN: 2147483647
Pages: 127