UML Action Semantics Action Semantics Consortium ... - MSDL

UML Action Semantics
Action Semantics Consortium
Proposal Version 9
17 December 1999
title.fm Version 9 January 17, 2000 6:41 pm i

title.fm Version 9 January 17, 2000 6:41 pm ii

Contents
Contents
Preface ix
Part I. Summary of Proposal 1
1. Action Semantics Overview 3
1.1 Action Specification Metamodel 3
1.2 Execution Model 3
1.3 Action Semantics 3
1.4 General Principles 4
Part II. Execution Semantics 5
2. Execution Instance Model 7
2.1 Overview 7
2.2 Identities and Snapshots 7
2.3 Links 8
2.4 Objects 9
2.5 Instance Classes 10
AttributeValue 10
DataValueIdentity 11
Identity 11
InstanceIdentity 11
LinkEndValue 11
LinkIdentity 12
LinkObjectIdentity 12
ObjectIdentity 12
ObjectSnapshot 13
Snapshot 14
3. Execution Activation Model 15
3.1 Contents of the activation model 15
3.2 Execution semantics summary 16
3.3 Activation Classes 19
Activation 19
ClauseToken 19
GroupToken 20
ConditionToken 20
ConditionalToken 20
LoopToken 21
Token 21
4. Advanced Execution Mechanisms 23
4.1 Exceptions 23
4.2 Interrupts 23
4.3 Primitive Intertoken Communication 24
4.4 Advanced Execution Classes 24
Action SemanticsTOC.fm Version 9 December 17, 1999 5:09 pm iii

Contents
SimpleQueue 24
5. State Machine Execution 27
5.1 Active Objects 27
5.2 Call events 27
5.3 Interobject Communication 27
5.4 State machines and event processing 27
5.5 State Machine Execution Classes 28
EventInstance 29
SignalInstance 29
Part III. Actions 31
6. Action Foundation 33
6.1 Overview 33
6.2 Summary 33
6.3 Foundation Classes 37
Action 37
ControlFlow 38
DataFlow 38
InputPin 39
OutputPin 39
Pin 39
PrimitiveAction 40
Procedure 40
7. Composite Actions 41
7.1 Group Action 41
7.2 Conditional Action 43
7.3 Loop Action 45
7.4 Concurrent Collection Actions 46
7.5 Composite Classes 46
Clause 46
ConditionalAction 47
GroupAction 49
LoopAction 51
MapAction 52
ReduceAction 52
8. Access Actions 55
8.1 Read Actions 55
8.2 Write Actions 55
8.3 Access Classes 55
ReadAssociationAction 56
ReadAttributeAction 56
WriteAssociationAction 56
WriteAttributeAction 57
9. Manipulation Actions 59
Action SemanticsTOC.fm Version 9 December 17, 1999 5:09 pm iv

Contents
9.1 Manipulation Classes 59
CreateLinkAction 60
CreateObjectAction 60
DestroyLinkAction 61
DestroyObjectAction 61
FindLinkAction 62
ManipulateLinkAction (abstract) 62
10. Computation Actions 63
10.1 Computation Classes 63
ApplyFunctionAction 63
CodeAction 64
LiteralValueAction 65
NullAction 65
11. Interaction Actions 67
11.1 Interaction Classes 67
CallAction 68
Call return (implicit action) 69
InterruptAction 69
RaiseAction 70
SendAction 70
Signal (from core) 71
SpawnAction 71
TerminateAction 71
WatchAction 72
12. Primitive Communication Actions 73
12.1 Primitive Communication Classes 73
NotifyAction 73
PollAction 74
WaitAction 74
13. Exception Actions 75
13.1 Exception and Interrupt Handling Classes 75
ExceptionAction (implicit) 75
InterruptAction 75
KillAction 76
RaiseAction 76
Part IV. Appendices 77
A Examples of Program Specifications 79
Index 81
Action SemanticsTOC.fm Version 9 December 17, 1999 5:09 pm v

Contents
Action SemanticsTOC.fm Version 9 December 17, 1999 5:09 pm vi

Table of Figures
Table of Figures
Figure 1. Snapshot and identity execution model 8
Figure 2. Link execution model 9
Figure 3. Object execution model 10
Figure 4. Action and pins 33
Figure 5. Data flow 34
Figure 6. Control flow 34
Figure 7. Data flows across composite action boundary 35
Figure 8. Available inputs and outputs of composite action 35
Figure 9. Procedure with pins and action 36
Figure 10. Action foundation metamodel 37
Figure 11. Group action and its flows 41
Figure 12. Conditional action and pins 43
Figure 13. Loop and pins 45
Figure 14. Composite actions metamodel 46
Figure 15. Access classes metamodel 55
Figure 16. Manipulation classes metamodel 59
Figure 17. Computation classes metamodel 63
Figure 18. Interaction classes metamodel 67
Figure 19. Primitive communication classes metamodel 73
Figure 20. Exception and interrupt handling classes 75
Action SemanticsLOF.fm Version 9 January 17, 2000 6:38 pm vii

Table of Figures
Action SemanticsLOF.fm Version 9 January 17, 2000 6:38 pm viii

Preface
The preface starts here. Do not delete the previous two paragraphs, which reset Framemaker counters.
preface.fm Version 9 December 17, 1999 4:16 pm ix

preface.fm Version 9 December 17, 1999 4:16 pm x

I Summary of Proposal
Part I. Summary of Proposal
This part summarizes the action semantics proposal.
part-summary.fm Version 9 December 17, 1999 5:00 pm 1

I Summary of Proposal
part-summary.fm Version 9 December 17, 1999 5:00 pm 2

1 Action Semantics Overview 1.1 Action Specification Metamodel
Chapter 1. Action Semantics Overview
Currently the UML metamodel is able to construct system models, which are fully adequate for declaring and generating
static structures, but it is incomplete and vague regarding the specification and semantics of executable actions.
The action semantics proposal remedies that lack. The action semantics specification requires 3 additional parts:
1.1. Action Specification Metamodel
An extension to the UML 1.3 metamodel that expands on the kinds of actions and their structure sufficient to specify
executable actions to all necessary detail. Mainly a listing of actions and their parameters. Class Action itself has been
altered. Additional classes have been added to get all of the parameterization right. Stubs (such as Action::recurrence)
in the original UML 1.3 specification have been removed and replaced with action subclasses.
Additional clarifications may be needed on state machines as well, but they have not yet been provided. The goal
is to support all behavioral concepts, including state machine transitions, in terms of actions, so that the semantics can
be unambiguously defined.
The program (an informal term used in this document) includes instance of the actions specified in this document.
The program forms part of the overall system model, which describes the structure and behavior of a system.
Users create system models that include action specifications. Another phrase for program is behavioral specification,
but this leaves an ambiguity about whether we are specifying the behavior of a particular model or the behavior
mechanisms in general.
We regard state machines and actions as two different but equivalent ways of expressing computation. In practice,
both are useful, but the semantics of either can be expressed in terms of the other. In this document, we (eventually
will) show how to express state machines as actions. This appears simpler, because a state-machine-based
approach would ultimately require some primitive actions, but an action-based approach does not require state
machines. UML state machines are regarded as a high-level concept, as they involve considerable complexity and
internal synchronization.
1.2. Execution Model
A new, separate UML execution model (not a metamodel!) defines the state of a run-time system and relates it to the
action specification. Users do not use the execution model directly to specify run-time systems. Run-time systems are
created from the system model by execution semantics engines in accordance with the execution semantics rules. The
execution model includes objects, links, and their attributes, as well as the run-time structure of active objects, activations,
and tokens (the mechanisms that make execution work).
Note that users can create models showing snapshots and scenarios that illustrate the execution of systems. The
form of these illustrative models is similar to or isomorphic to the structure of the run-time system, but they are models
designed by a user, whereas the run-time system is a living thing that evolves according to the execution semantics
rules. We will not discuss or build the metamodel for illustrative models in this proposal, although a simple mapping
is possible.
In this proposal we define a foundational model that can support many different physical computer architectures
(SISD, SIMD, MIMD, data flow, and so on). Some of the constructs might seem unusual to many people, but the
intent is to define the fundamental semantics of concurrent execution without making unnecessary assumptions about
the physical architecture (because we want to model them all), while not creating a model that is too abstract for
actual use. In the responses to the Real-Time Semantics RFPs, we would expect to layer one or more models of the
physical machine architecture on top of the semantic model proposed here. We do not describe the physical model in
this document, but we have tried to avoid making the mapping to a physical model difficult.
1.3. Action Semantics
For each action, must specify how the state of the system is transformed.
overview.fm Version 9 December 17, 1999 5:00 pm 3

1 Action Semantics Overview 1.4 General Principles
The specification will be in terms of primitive actions on local fragments. Need to tell how they assemble into
larger systems and actions. The issue of conflict must be addressed (but not removed). Nondeterminism is permissible
when necessary.
Physically this description is packaged with the definition of each action and expressed as precondition-postcondition
pairs.
1.4. General Principles
Provide a logical model of computation without forcing it into a particular implementation or hardware architecture.
Try to capture the essence of computation.
The logical model can be mapped into various physical computer architectures. One of these is the conventional
Von Neumann SISD computer with a processor and a memory, but there are many others that are becoming more
important, and we do not want to assume the conventional computer. We don’t want to make it inefficient to model,
either.
The logical model must be overlayable by physical models of computers for real time and other purposes. It is
not our purpose to provide the overlays here but only to make them possible.
Concurrency and distribution are becoming extremely important, although standard languages and computer
architectures are still somewhat lagging. Model concurrency and distribution in the most general way, without making
assumptions that won’t scale up. No assumption of centrality or global synchronicity is permissible.
Actual programs sometimes fail to terminate, have bugs, and cause problems. Means must be provided to clean
up erroneous executions. This is messy but necessary and involves issues such as killing processes, exception handling,
and interrupting other processes.
Practical computation in the presence of concurrency requires accepting the possibility of conflict. To prevent it
in the architecture is not practical.
We must support conventional programming languages, particularly the concept of calls, although they are tricky
in the presence of concurrency and distribution.
Both coarse-scale and fine-scale concurrency must be modeled, but not necessarily in the same way. They will be
implemented differently on all but experimental machines.
Low-level primitives should separate computation and memory access so that they can be cleanly mapped to a
physical model.
The set of primitive functions should not be limited but should be extensible, although this creates some problems
for interchangeability, because we don’t want to be defining a programming language.
Compilers will map from convenient syntax and constructs to the action semantics constructs. We don’t need to
provide sugarings for all useful things.
The fundamental semantics should be expressed in terms of simple primitive behavioral concepts. Complicated
constructs should be treated as high-level concepts and mapped into the primitive concepts. Users would not necessarily
work in terms of all the primitive concepts. Primitive concepts should be simple logically, should have precise
semantics, and should be conceptually simple to implement.
overview.fm Version 9 December 17, 1999 5:00 pm 4

II Execution Semantics
Part II. Execution Semantics
During execution the run-time system state is a set of objects, links, activations, and tokens, each of which may contain
values, including references (pointers to objects). The objects and links together define the data set of the system.
The data set is consistent with the UML static model for the given system. Its form is specified by the execution
instance model defined in this document. The active objects, activations, and tokens define the control set of the system.
The control set is consistent with the program model for the given system. Its form is specified by the execution
activation model defined in this document. The entire run-time system state evolves over time in accordance with the
execution semantics rules defined in this document. The execution model is the model for the run-time system state.
The complete description of an executing system includes its system model, consisting of classes, methods, state
machines, and the like; and the run-time system state, consisting of objects, links, active objects, activations, and
tokens. Many values in the run-time system state reference elements in the system model (e.g., the class of an object,
the type of a value, the method or state where an activation is executing, and so on).
There are four chapters in this part. Chapter 2, “Execution Instance Model”, describes the run-time instance data
that corresponds to a class model for a system. Chapter 3, “Execution Model”, describes the internal structure needed
to support dynamic execution of actions. Chapter 4, “Advanced Execution Mechanisms”, describes the exception and
interrupt handling mechanisms. Chapter 5, “State Machine Execution”, describes the state machine and active object
execution model.
part-execution.fm Version 9 January 17, 2000 6:38 pm 5

II Execution Semantics
part-execution.fm Version 9 January 17, 2000 6:38 pm 6

2 Execution Instance Model 2.1 Overview
2.1. Overview
Chapter 2. Execution Instance Model
The execution model is our basic formalism for defining the semantics of UML actions (and, potentially, other behavioral
constructs). The primary portion of this model, common to the denotational and operational approaches to defining
the UML dynamic semantics, is the definition of the information that must be maintained at any one point in time
by a “virtual machine” executing a UML model. This portion can be further divided into two parts: the execution
instance model, which defines the structure of instances and links conforming to classes and associations in the model
being executed, and the execution activation model, which defines the information that must be maintained regarding
the execution of an action itself.
This chapter focuses on the execution instance model. Each of the following sections provides an overview discussion
of a portion of this model together with a class diagram for this portion. The classes for all portions are
described together in a single alphabetical list at the end of the chapter. Generally, classes in the structure model have
associations with metaclasses in the UML metamodel. The formal connection of the structure model to the UML
metamodel is provided by conformance rules that constrain the relationship of instances of structure model classes to
associated instances of UML metaclasses.
Note. Like the well-formedness rules of the UML metamodel, the conformance rules here must ultimately
be formally expressed using OCL. This is yet to be done, though.
2.2. Identities and Snapshots
Execution deals with instances and links whose structure is specified by classifiers and associations. Each of these
“entities” has a unique identity that is immutable over time. However, of these entities, objects are mutable and have
properties that change over time. An object snapshot is a view of an object at any one point in time, with the specific
values at that time for all object properties. (Object snapshots are the only kind of snapshots in the structure model,
but the general concept of a “snapshot” is also used in the activation model.)
The idea that a snapshot represents a single point in time is crucial here. One cannot introduce the idea of something
“changing over time” directly into the static semantic model without ending up with a circular definition of
dynamic semantics. (This circularity can be avoided in the case of strictly static semantics by mapping the static
semantic UML modeling constructs to the usual set-theoretic semantic representation.)
Nevertheless, one can still think of the entity as “changing over time.” A sequence of such snapshots form a history
of the entity over time. Intuitively, one can think of viewing this sequence over time like a movie, giving the mental
picture of a single entity with changing properties over the course of its history. (These ideas will be formalized in
the dynamic semantic model.)
Another important corollary is that it is not possible to directly navigate from an identity to a snapshot, since
there is no distinguished “current” snapshot in the history of an entity. Indeed, dereferencing an identity to yield a current
snapshot is a non-trivial operation requiring a synchronization in time between the snapshot performing the
dereference and the snapshot resulting from the dereference. (This will also dealt with formally in the dynamic
semantic model.)
It is important to distinguish instance identities from link identities, because it is the instance identities that are
the values of attributes and association ends. It is further necessary to distinguish data-value identities from object
identities, because a data value is immutably associated with a single data type, while an object can have multiple
classifiers that can change over time (allowing for multiple and dynamic classification). Thus, the data type of a data
value can be associated directly with its identity, while the classifiers of an object must be associated with its snapshot.
executionInstance.fm Version 9 January 17, 2000 6:39 pm 7

2 Execution Instance Model 2.3 Links
These basic concepts of identities and snapshots are formalized in the following model.
DataValueIdentity
+type 1
DataType
2.3. Links
*
InstanceIdentity
ObjectIdentity LinkIdentity
ObjectSnapshot
LinkObjectIdentity
Identity
+identity
1
*
Association
Figure 1. Snapshot and identity execution model
A link is related to an association in an analogous manner to the relationship of an instance to its classifier(s). The
link then provides link-end values for the association ends of the association. However, a link is not a mutable entity.
The set of link-end values for a link is part of the very identity of the link, in the sense that a link can basically be
thought of as a tuple of values for the ends of an association.
Further, even though it is conventional to talk of the “creation” and “destruction” of links, the lack of any other
mutating actions makes the concept of a “link snapshot” unnecessary. Instead, a link can be considered to exist as
long as its link-end values are referenced by object snapshots, and it ceases to exist when all object snapshots have
been “unlinked” from it.
executionInstance.fm Version 9 January 17, 2000 6:39 pm 8
*
1
+association
AssociationClass
Snapshot
*
1..*
Classifier
Class
+classifier

2 Execution Instance Model 2.4 Objects
This approach to links is formalized in the following metamodel.
+connection
2.4. Objects
Association
AssociationEnd
+associationEnd 0..1
+qualifier
2..*
Attribute
Object is a mutable entity, that is, one whose properties may change over time. The values of the properties at any one
point in time are given by the snapshot for the object that is effective at that time. The mutable properties of an object
associated with its snapshot include the following.
• The set of classifiers of the object.
1
*
{ordered}
+association
1
*
+attribute
+associationEnd
1 *
1
*
Figure 2. Link execution model
• Values for the attributes specified by all of these classifiers.
Identity
LinkIdentity
+link 1
+linkEndValue 2..*
LinkEndValue
+qualifierValue *
AttributeValue
+predecessor
*
1
• Values for the (navigable) opposite link ends of associations in which the classifiers participate.
InstanceIdentity
Note that we do not include snapshot specializations for other types of mutable instances, such as instances of nodes,
components and use cases. The representation of mutable objects in the execution model presented here is rich
enough to also act as the semantic representation for other mutable instances, with appropriate restrictions (e.g., a
component instance must have a single component as its classifier throughout its history).
A link object has both the properties of a link and the properties of an object. Since there is no link snapshot, the
link properties are all associated with the link-object identity (see Section “Objects” on page 9). Therefore, the mutable
properties of a link object are all object properties that can be represented using an object snapshot.
executionInstance.fm Version 9 January 17, 2000 6:39 pm 9
*
0..1
0..1
0..1
{ordered}
+successor
1
+value
+value

2 Execution Instance Model 2.5 Instance Classes
This concept of an object snapshot is formalized in the following metamodel.
+value 1
InstanceIdentity
+value 1
2.5. Instance Classes
Snapshot
ObjectIdentity
+/objectId
*
1
*
*
LinkEndValue
+linkEnd *
ObjectSnapshot
Figure 3. Object execution model
{ordered}
Association
AssociationEnd
Classifier
Feature
+feature
StructuralFeature
AttributeValue
An attribute value provides a single value for a specific attribute. The value is represented as an instance identity. In
the case of an object identity, this effectively represents a reference to the object, since it is not dependent on the
object snapshot. Note that if the attribute has a multiplicity, then there may be several attribute values for that
attribute, but each attribute value only has a single associated instance identity. (See also Section “Objects” on page 9
on the use of attribute values to represent the values of association-end qualifiers.)
executionInstance.fm Version 9 January 17, 2000 6:39 pm 10
0..1
*
*
AttributeValue
*
1
+associationEnd
*
+attributeValue
*
+classifier
1..*
+attribute
1
2..*
*
1
0..1
*
1
Attribute
+connection
+type
+owner

2 Execution Instance Model 2.5 Instance Classes
Associations
• attribute The attribute whose value is given by this attribute value.
• value The actual instance identity representing a value of the attribute.
Issue. It would seem logical to include here a conformance rule requiring the value of an attribute to have a
classifier that conforms to the type of the attribute. However, objects can be dynamically classified, so it is
not possible in general to determine their classifier(s) from their identity. Instead, any check for type conformance
must be done on assignment of the value to the attribute. If the object is dynamically reclassified,
though, there does not seem to be any good way to assure that it will still necessarily conform to the type of
the attribute.
DataValueIdentity
In UML, data values represent “immutable” instances whose properties do not change over time. Indeed, the properties
of a data value are implicit in the identity of the data value itself, so data values do not have snapshots or histories
at all. A data value can have only one classifier, which must be a data type.
Associations
• type The data type of the value represented by this data-value identity.
Identity
The identity of some entity is immutable, timeless and unique from all other identities.
InstanceIdentity
An instance identity is the identity of some instance of a “classifier”.
LinkEndValue
A link-end value provides a single value for a specific end of a link. The value is represented as an instance identity.
In the case of an object identity, this effectively represents a reference to the object, since it is not dependent on the
object snapshot.
If the specified association end has qualifiers, then the link-end value must also include attribute values for each
of the qualifiers. If the association end is ordered, then the link-end value also has links to the previous and/or next
link-end values in the ordering for that end of the link snapshot. (See also Section “Links” on page 8 for the relationship
of link-end values to object snapshots.)
Issue. The instance-level specification of qualifier values is incorrect in the UML 1.3 specification. The
association “qualifierValue” is mentioned in the description of LinkEnd, but it is not shown on Figure 2-16
(Common Behavior - Instances and Links) or covered in the well-formedness rules.
Note. It seemed simpler to specify the ordering of link-end values for an ordered association end using a
“linked-list” kind of approach then, say, explicit index attributes.
executionInstance.fm Version 9 January 17, 2000 6:39 pm 11

2 Execution Instance Model 2.5 Instance Classes
Associations
• associationEnd The association end whose value in a link is represented by this link-end value.
• link The identity of the link containing this link-end value.
• predecessor The link-end value for the same association end in a different link for the same association
that represents the value, if any, that precedes this link-end value in an ordered association
end.
• qualifierValue The set of values for qualifiers of the association end.
• successor The link-end value for the same association end in a different link for the same association
that represents the value, if any, that follows this link-end value in an ordered association
end.
• value The actual instance-identity that is the value of this link end.
Conformance rules
[1] Ordering consistency. A link-end value may only have a predecessor or successor if its association end is ordered
and any predecessor or successor must be for the same association end but be in a different link.
[2] Qualifier conformance. For each qualifier of the association end of a link-end value, the link-end value must have
a number of attribute values for that qualifier conforming to the multiplicity of the qualifier and the instanceidentity
values of those attribute values must all be distinct.
LinkIdentity
The identity of a link is determined by the association of the link and by the values the link gives to the association
ends of the association. Therefore, a link identity is associated with both an association and a set of link-end values,
reflecting the immutability of a link. Note that a link has at most one link-end value for each association end of its
association.
Associations
• association The association for the link represented by this link identity.
• linkEndValue The set of values of the ends of the link corresponding to the association ends of the association.
Conformance rules
[1] Association-end conformance. Each link-end value of a link identity must be for a distinct association end of the
association of the link identity and each non-optional association end (i.e., one with a multiplicity lower bound
greater than zero) must have a corresponding link-end.
LinkObjectIdentity
A link object is an instance of an association class, which is both an association and a class. As such, a link-object
identity is both a link identity and an object identity.
ObjectIdentity
An object identity represents the identity of an object or any other mutable instance.
executionInstance.fm Version 9 January 17, 2000 6:39 pm 12

2 Execution Instance Model 2.5 Instance Classes
ObjectSnapshot
An object snapshot represents a snapshot of the properties of an object or any other mutable instance. These properties
include the classifiers of the object, the values of the attributes of the object and the values of the opposite link
ends of the object.
Associations
• attributeValue The set of values for attributes of the classifiers of the object snapshot.
• classifier The set of classifiers of the object represented by the object snapshot.
• linkEnd The set of values for the opposite link ends of navigable association ends of associations in
which classifiers of the object snapshot are involved.
• objectId (Derived) The identity of the object snapshot, as an object identity.
Conformance rules
[1] Object-identity constraint. The identity of an object snapshot must be an object identity.
[2] Multiple-classification constraint. If an object snapshot has more than one classifier, then they must all be
classes.
[3] Attribute conformance. For each attribute owned by each classifier of an object snapshot, there must be a number
of attribute values conforming to the multiplicity of the attribute and the instance-identity value of these attribute
values must all be distinct.
Issue. How are classifier-scope attributes represented?
[4] Association conformance. For each association in which a classifier of an object snapshot is involved, for each
navigable opposite association end of the association, for each distinct set of values for qualifiers of that association
end (if any) there must be a number of link-end values consistent with the multiplicity of that association end
and the instance-identity values of those link-end values must be distinct. If an association end is ordered, then
all the link-end values for that association end, with the same values of any qualifiers of the association end, must
be linked together in a single predecessor/successor list. (See Section “Links” on page 8 for the modeling of
qualifier values and predecessor/successor ordering.)
Issue. This association conformance rule only handles the multiplicity of navigable association ends (whose
link-end values are accessible from object snapshots). One way to handle multiplicity constraints on nonnavigable
ends requires would be to also make the link-end values of non-navigable ends properties of object
snapshots, but this would introduce a coupling to the association that seems unexpected in the absence of
navigability. Alternatively, we could introduce snapshots to represent the extension of the association as a
whole, with multiplicity constraints applying across all the links of the association in existence at any point
in time.
[5] Association-class conformance. If the identity of an object snapshot is a link-object identity, then exactly one of
the classifiers of the object snapshot must be an association class that is the same as the association related to its
identity, otherwise none of the classifiers may be association classes.
Issue. Since the association of a link object is fixed here via its link-object identity, it is not possible for the
link object to be reclassified from one kind of association to another or for a non-link object to be reclassified
as a link object. This does not seem to be too severe a limitation.
executionInstance.fm Version 9 January 17, 2000 6:39 pm 13

2 Execution Instance Model 2.5 Instance Classes
Snapshot
A mutable entity (such as an object, as opposed to a data value) will have a unique identity over its entire lifetime, but
its properties may change over time. A snapshot is a record of a complete set of properties for the entity at a single
instant in time. Note that snapshots do not “change over time” as such. Rather, there is a separate snapshot for each
point in time at which the entity has a different set of properties.
executionInstance.fm Version 9 January 17, 2000 6:39 pm 14

3 Execution Model 3.1 Basic execution semantics
Chapter 3. Execution Model
This chapter describes the model for when actions and their various composite forms execute. Any implementation
that has the same effect is compliant, regardless of its actually implementation.
An action, as it appears on a UML model, is a specification for a desired execution. Each appearance of the “same”
action appears as two instances in the repository because each appearance is a separate specification for a desired execution.
Consequently, each appearance is, in fact, a separate action; more precisely, an action-as-specified.
At run time, however, each action-as-specified may be executed zero, one or more times. For example, an action
may be guarded by a conditional that is not true, and so it never runs. Separately, each instance of a class may have its
own state machine, which means that an action-as-specification appearing once on the state chart may be in execution
multiple times at the same time, once for each state machine. An action-in-execution is therefore a different concept
from an action-as-specified. Each action-as-specified appears as a separate instance in the metamodel; each action-inexecution
appears only at run-time, possibly on different processors.
We use the term Action to refer to an action-as-specified and ActionX for action-in-execution. [Several terms
have been proposed for the action-in-execution, including Token and Action Instance. For ease of making a global
replacement, as there will certainly be discussion on the best term, this chapter uses ActionX instead of these either of
these terms. If you wish, make a global replacement with your favorite term and see how it reads.] An actionX, then,
is the potential execution of an action. The two concepts cannot be merged because multiple actionXs may be in
(potential) execution at once for a single action.
Actions are grouped together for several reasons. The highest-level such grouping is the Procedure, which refers
to a set of actions in a method body, or the set of actions specified to execute on exit from a state, on a transtition, or
on entry to state. Just as an action specifies a desired execution and an actionX is the run-time execution of it, so too
a procedure-as-specified has a corresponding procedure-in-execution, dubbed ProcedureX for parallelism of terminology.
This chapter describes a model for the execution of actionXs, ProcedureXs, and all the intermediate composites
in execution. It does not descibe the composites in specification (See Chapter xx), nor does it describe the context for
how or why a particular ProcedureX is caused to be executed (See Chapter yy).
3.1. Basic execution semantics
When can a ProcedureX execute?
A procedureX executes when a method is invoked or when an event triggers a transition. The details are described in
Chapter yy.
When a procedureX starts execution, it has available to it the arguments passed in with the call, or the arguments
supplied with the event. These data items may be viewed as data flows, and they are made available to all actions
within the procedure. In addition, data in the static structure model is available to any (read) action that requires them.
Note: We have used “arguments” for both call arguments and the supplemental data items passed in with an
event. There is some utility in separating the two terms, but in this chapter they are truly identical in their
treatment, though not their specification (which is not in this chapter, but in Chapter yy.)
Because of the concurrent nature of the action semantics, every action within the procedure may execute at once,
unless otherwise constrained by data flow or explicit control flow. Consequently, every actionX within the procedureX
is enabled as soon as the procedureX is enabled.
Enabled actionXs that have all their inputs can execute immediately. Therefore, enabled actionXs that have no
inputs can execute, as can actions that rely solely on arguments, and all read actions in their various kinds. Stated in
the other way, enabled actionXs that depend on the outputs of other actionXs cannot run until the “upstream”—either
in a data flow or control flow sense—actionXs complete.
executionActivation.fm Version 9 January 7, 2000 8:02 am 15

3 Execution Model 3.1 Basic execution semantics
From the perspective of a “downstream” action, an upstream actionX indicates its completion by generating all
its outputs at once, which are then made available to the downstream actionXs. This, in turn, allows downstream
actionXs to execute, and this continues downstream until the chain of actionXs writes the static model, generates a
signal event, or otherwise produces no outputs of interest to actions in the same procedure.
When the only flows remaining are outputs from the procedure, and no actionXs are executing, the procedureX
is complete. At that point, all the outputs on the flows of the procedure—the output arguments—are made available.
Note that there may still be enabled actionXs within the procedure. However, if all actionXs that produce output have
produced their data, and there is other data flow inside the procedure, no enabled action can ever execute, so the
entire proceedure cannot make further progress, so it must, perforce, be complete.
Note. I find this messy. Better would be to have each action with a single output (tupular) flow which is
either produced or not. That way, we know when the procedureX is complete because it has all its component
output flows. This does not require that every element of a flow is present; the tuple can have nulls.
Note that actionXs within a procedureX execute for an indeterminate but finite time, and therefore complete at
different times, so it is possible for a output flow from the procedureX to hold a value before the entire procedureX
completes. Each flowX is therefore “gated” by the definition of the procedureX and no flowXs are made available
outside the procedureX until the whole procedureX is complete as defined above.
A procedureX therefore exhibits a lifecycle: It is created enabled; it enables all its component actions, which is
equivalent to “executing”; at some point, none of the component actions can execute, and the output flows are loaded.
At this point, the outputs are produced, and the procedureX is complete.
When can an ActionX execute?
An actionX can execute when it is enabled and when it has all its inputs, both data flows and control flows, if any.
An actionX then executes for an indeterminate time.
Once the actionX has completed execution, it generates all its outputs, both data flows and control flows, if any.
An actionX therefore exhibits a lifecycle: It is created enabled; it executes when it has all its inputs; it executes
and produces its outputs at once; it is then complete and dies.
FlowXs
A control flowX is an explicit sequencing between two actions. Because an actionX cannot execute unless it has
all its inputs, the presence of a control flowX effectively sequences two actions. Similarly, a data flowX represents the
presence of an immutable value for input to some other actionX. And because an actionX can’t execute without all its
inputs, a data flowX also effectively sequences actionXs.
Flows may be produced, though not made available to other actions. For example, if an action generates more
than one flow, no downstream action may execute until the upstream action releases all the flows. Note that this is the
same whether the flows are from an actionX or a procedureX.
Each flowX, then, has a lifecycle: It is created present, released, then it is consumed and destroyed.
The following model describes the classes required. Note that each X has an association with the corresponding
class that captures the specification of the execution.
Note that PinXs are not required. A pin models a specification of a (logical) name for the data flow that is of no use in
execution.
Note: Two simplifications are possible at this point. First, we could redefine data flows in Foundation so that
it means the combination of all the data between two actions. If we do this, we can place all the data elements
on a (combined) flow “at once.” Second, we could make all the data from an action into a single
“cable.” Then we don’t have to deal with all the issues about what “at once” means at any level: either the
whole cableX has a tuple on it or it doesn’t. I prefer the second.
executionActivation.fm Version 9 January 7, 2000 8:02 am 16

3 Execution Model 3.2 Composite Actions
3.2. Composite Actions
There are several kinds of composite action, each of which is treated in turn.
Group Action
A group action also has a porous boundary that allows data and control flows to enter and leave the group. The group
action may also be a predecessor and successor in control flows. An input control flow governs the execution of all
actions within the group and is semantically equivalent to a control flow to every action that composes the group.
Similarly, an output control flow from the group indicates that all actions must complete before the successor(s) of
the control flow.
The group-action control flows then are merely shorthands. As GroupAction is a specialization of Action, and
there are no new semantics, there is no need for a corresponding GroupActionX. Note that this requires a control flow
to or from the Group Action to be represented—in the execution model—as control flows to and from the component
actions.
Note: We could choose to model the concept of ‘all actions complete’ in a group, and if so, we should model
it in the same way as a ProcedureX. But then we’d still have to deal with the idea of partial completeness.
Conditional Action
Like a group action, the combination of flows and actions fully model the contents of a conditional action, and there
are no new semantics.
Note: We could choose to model a TestActionX to describe the behavior of the diamond in the conditional.
But all the diamond does is to copy the control flow to another. It would also need a value to make the decision.
It’s better to view the diamond as indicating mutual exclusion of two conditional control flows.
Loop ActionX
The view modeled so far allows for the execution of an action no more than once, and for a flow to be consumed.
However, a loop requires execution of both test and body more than once. We therefore introduce the concept of a
loopactionX, which controls the execution of the loop.
Because a LoopAction is a specifialization of Action, we may treat a loop in the same way as all other actions.
For a loop, this means that the test actionX and body actionX (whatever they may be in fact) are both enabled when
the loop actionX is enabled. The flows will arrive when they’re ready. When the body executes, it places the outputs
on the output flows and a single iteration is complete. The outputs are, by default, routed to the back to the actions in
the loop (both test and body), and are treated as the outputs from the loopactionX, though these outputs are not yet
available to downstream actions.
The purpose of the loopactionX is to re-enable the test and the body. When the test fails, as it should eventually,
only then is the loop actionX complete. At that point, the output flows from the loop become available to their consumers.
A loopactionX has a lifecycle: It is created ready; once the clause executes, the loopactionX re-enables the clause
and routes the flows to the test and body actions; once the test fails, the loopactionX allow the body outputs to be
available as the output flows for the entire loop action.
3.3. A note on calls and returns
Calls. A call action comprises a name for an operation, a target object, an ordered list of input pins for the argument
values and an ordered list of output pins for the output argument values. When a call action executes, the called procedure
executes in the “thread” of the caller. More exactly, when the call actionX executes, it is equivalent to executing
the invoked procedureX with the appropriate agruments.
executionActivation.fm Version 9 January 7, 2000 8:02 am 17

3 Execution Model 3.4 Execution Classes
In an object-oriented system, the call action performs a dynamic method lookup based on the class of the target
object and the class hierarchy to determine the actual method, but this merely determines which procedure is executed.
The values of the call arguments are copied into the input pins for the invoked procedureX, and when the
invoked procedureX completes its execution, its output arguments become outputs of the call actionX.
A set of nested calls therefore maps into a set of procedureXs.
Returns. The return pins in a procedure take their values from the output pins of actions in the procedure. All
actionXs in a procedureX must be unable to execute before the procedureX can complete execution. When an procedureX
completes, it and its actionXs cease to exist and the values in the return pins are copied into the output pin of
the calling actionX. The call actionX is then complete and its output values are available to subsequent actions within
the calling procedureX.
Qui faxit? Note that a call is not actually handled by the target object. A conventional procedure call, including OO
method invocations, does not occur in the target object but instead in the thread of control of the caller. The specification
of the procedure exists in the called class, but the execution of the procedureX executes sequentially in the thread
of control of the calling object instance’s state machine.
If the target class is passive (i.e. it has no state chart), the execution of the procedureX exists in the execution
context of the calling active object. If the target class is active, and so has a state chart, then there is the possibility of
data access conflict with the execution of the corresponding state machine. It is the responsibility of the developer to
synchronize the execution of the two state machines, or to be oblivious to the possibility of conflict.
Note. An alternative approach is to use call events. However, in the case that the invoked operation is truly
state independent, there is no need to synchronize. And if it is state-dependent, then the synchronizing mechanisms
of the state chart suffice.
3.4. Execution Classes
These classes define the run-time mechanisms to support execution. They form the execution machinery. They are
not directly accessible by user models; they are created implicitly as part of the execution process. These classes reference
classes in the metamodel and in the user model.
actionX
A potential execution of an action is abstracted as an actionX. Note that this is different from an instance of an action,
which is realized as an instance of the class action in the repository. For any such instance in the respository, there
may be several actionXs, one for each execution—whether actual or pending—at run time.
An actionX has a status value to indicate the progress of executing its action. Normal statuses are enabled (available
to begin execution of the action), executing (in the process of executing the action), and completed (finished executing
the action and waiting to be advanced to the next action).
An actionX does not “advance” to the next action. Rather, its completion permits the execution of successor
actions by generating data and control flowXs. All actionXs are enabled by (some kind of) composite actions that
contain them.
executionActivation.fm Version 9 January 7, 2000 8:02 am 18

3 Execution Model 3.4 Execution Classes
Associations
• guard: ControlFlowX The control flowXs that guard the execution of the actionX.
• source: ControlFlowX The control flowX of which this actionX is the source.
• input: dataFlowX The data flowXs that are input for the execution of the actionX.
• source: dataFlowX The data flowX of which this actionX is the source.
Attributes
• status The state of execution of the actionX. One of:
enabled—available to begin execution
executing—in the process of execution
complete—finished execution
control FlowX
At specification time, an action may produce one or more control flows. At execution time, because there may be several
actions in execution, an actionX may produce one or more control flowXs.
Associations
• receiver: actionX The actionX to which this control flowX is input.
• producer: actionX The actionX that generates this control flowX
Data FlowX
At specification time, an action may produce one or more data flows. At execution time, because there may be several
actions in execution, an actionX may produce one or more data flowXs.
Associations
• receiver: actionX The actionX to which this data flowX is input.
• input: actionX The actionX that generates this data flowX
• receiver: procedureX The procedureX to which this data flowX is input.
• input: procedureX The procedureX that generates this data flowX.
LoopactionX
When a set of actions appear in a loop, the component actions must execute multiple times. Similarly, the flows that
feed these actions and are produced by these actions are reloaded each time round the loop. The machinery that
effects this behavior is abstracted as a loop actionX.
On the first iteration of the loop, the input flowXs are loaded in the normal manner. If the test suceeds and the
loop executes, the outputs from the body become flowXs input to both test and body actionXs. If the test fails, however,
the extant flowXs that are input the the loop action become the outputs of the loop actionX as a whole.
Associations
A loop actionX is a specialization of actionX. No other associations are required—all information about the structure
executionActivation.fm Version 9 January 7, 2000 8:02 am 19

3 Execution Model 3.5 Caboose
of the model is already in Foundation.
Attributes
• status: enum The following status values apply:
enabled—The loop is ready to execute and actionXs are not set up
testing—The while condition is being tested
executing—The body action is being executed
complete—The while condition has evaluated false and the loop execution is
complete
procedureX
A potential execution of a procedure is abstracted as an procedureX. Note that this is different from an instance of an
procedure, which is realized as an instance of the class procedure in the repository. For any such instance in the respository,
there may be several procedureXs, one for each execution—whether actual or pendining—at run time.
An procedureX has a status value to indicate the progress of executing its procedure. Normal statuses are
enabled (available to begin execution of the procedure), executing (in the process of executing the procedure), and
completed (finished executing the procedure and waiting to be advanced to the next procedure).
An procedureX does not “advance” to the next procedure. Rather, its completion permits the execution of successor
procedures. All procedureXs are created by a state machine or a call action in a state machine.
Associations
• receiver: dataFlowX The data flowXs that are input for the execution of the procedureX.
• source: dataFlowX The data flowX of which this procedureX is the source.
Attributes
• status The state of execution of the procedureX. One of:
enabled—available to begin execution
executing—in the process of execution
complete—finished execution, may do another procedure
procedureX
3.5. Caboose
Constraint checking and transactions
UML constraints apply at various levels. Some apply at all times, but most can be violated during the actions of a
transition. Some may be valid after certain actions. To do the job right, we need levels of constraint checking, probably
eventually a full transaction mechanism.
A constraint is an action that is conceptually performed between any transitions that affect its referents. We have
to be careful, because there may be many procedureXs and the entire system does not necessarily quiesce, so some
global constraints may be conceptually impossible to apply at times (!). Perhaps constraints can be considered small
procedureXs that simply keep looping and doing the same thing, raising a signal if they find an inconsistency. When
they are to be executed is a question and probably needs to be added to the original metamodel as a user modeling
choice (and maybe a semantic variation point).
Defining the times at which a constraint is evaluated may be difficult. Preconditions and postconditions are
applicable at a definite time, so they are clear. Invariants may prove to be problematical and may need to be avoided
or specified as to when they apply, as they are not usually valid at all intermediate points in a computation.
executionActivation.fm Version 9 January 7, 2000 8:02 am 20

3 Execution Model 3.5 Caboose
In general, the action semantics model will not attempt to verify or enforce user-defined constraints that are made
invalid by actions. (Semantic variations to maintain association multiplicity will be provided as well as automatic
maintenance of composition hierarchies.)
The action semantics will not provide a rollback facility. That is part of the fault tolerance RFP. If conflicts occur,
they may corrupt the data. That’s how real systems work. It is the responsibility of the designer to avoid that. (Using
the to-be-proposed fault tolerance facility is one solution.)
A constraint always involves both data access (read only) and a functional test. Thus it is subject to data access
conflict on reading and must be defined carefully if it involves the reading of multiple values, so that the multiple values
are consistent but we don’t violate causality in obtaining them. However, constraints never modify data (no side
effects), so they can’t affect the course of the computation (unless error signals or exceptions are allowed and occur).
executionActivation.fm Version 9 January 7, 2000 8:02 am 21

3 Execution Model 3.5 Caboose
executionActivation.fm Version 9 January 7, 2000 8:02 am 22

4 Advanced Execution Mechanisms 4.1 Exceptions
Chapter 4. Advanced Execution Mechanisms
This chapter describes classes intended to support advanced forms of control, such as exceptions and interrupts.
These mechanisms operate at the action level (not the state machine level), but their semantics is much more complex
than the primitive execution machinery, and it seems best to separate them. If possible, they should be defined in
terms of the more primitive mechanisms.
4.1. Exceptions
The exception and interrupt handling mechanisms are high-level concepts that can be defined in various ways in
terms of the primitive behavior concepts. They are not part of the fundamental semantics.
Exception handling is a mechanism that deals with occurrences that are difficult to handle with the normal flow
of control of a program. When an exception occurs, the normal flow of control is abandoned and a different flow of
control, specified in the program, is taken. An abnormal occurrence is either a exception or an interrupt.
An exception is a condition that arises synchronously as part of an action, often as an indication that the input
values are inconsistent with the normal mathematical interpretation of the action, for example, taking the square root
of a negative number or attempting to pop an empty stack. An exception could be handled by providing variant outcomes
for the operation, one for each kind of exception as well as one for the normal outcome, but this makes the
code difficult to read and obscures the main flow of control. In normal mathematics it is treated by extending the
result range to be a union of types, but this is often awkward in programming, although this approach is taken in the
IEEE floating point standard (an operation can return values such as NotANumber, Underflow, etc.). Exceptions,
therefore, are not absolutely necessary, but code without them may be very difficult to follow. (Code that misuses
them is also difficult to follow, so they must be used with restraint and care.)
The occurrence of an exception terminates the current action and causes control to progress up the stack of activations
until some activation handles it. This requires a considerable amount of mechanism in the program specification
structure, equal to the mechanisms provided in Ada or C++. An action may have a table of handler actions
indexed by exception kind. If an exception occurs during the execution of the action and the exception index on a handler
matches the kind of exception that occurred (or is an ancestor of it), the handler action receives control. We do
not support handling exceptions and then reexecuting or resuming the action that failed. (This is not supported by
C++ or Ada, either.) Resumption is extremely complicated, not supported by most programming languages, very
implementation dependent, and its effect can be usually be expressed more cleanly without it.
4.2. Interrupts
An interrupt is an asynchronous outside signal independent to the state of execution of an token that affects the flow
of control. Unlike a normal signal, it does not obey run-to-completion semantics. It forces abandonment of the current
execution path and forces the program to take an alternative path specified in the exception structure. This permits the
response to the interrupt to depend on the state of execution, to perform some clean up before exiting, for example.
An interrupt is not subject to run-to-completion processing, in fact, its purpose is often to kill an execution that is out
of control or no longer needed. Interrupts are needed logically, as there is no other way to terminate an unneeded subactivity.
Note that an interrupt handler may raise exceptions to propagate its effects up the call tree. Also, an exception
handler may send an interrupt to notify subordinate tokens. In practice, interrupts and exceptions are closely linked.
A token must be able to kill its dependent activations. This will happen when an active object is killed and its
activations must be cleaned up. A token has a list of pointers to dependent activations so that they can be killed, if
necessary. (We can’t just wait for them to die, because they might not do it.) Therefore the execution of an activation
is not totally synchronous, as it might receive an interrupt signal commanding it to die. Such an interrupt could happen
anywhere within the body of a computation, often leaving the object in a messy state. The exception mechanism
permits a handler to be attached to an action, indicating the exception action to be performed if an interrupt occurs
while tokens are executing in the action. (Often many actions can use the same exception handler.) There must be an
advancedExecution.fm Version 9 December 17, 1999 5:04 pm 23

4 Advanced Execution Mechanisms 4.3 Primitive Intertoken Communication
unconditional kill interrupt, however, in case of an uncooperative activity that refuses to stop even when interrupted.
Such an interrupt cannot be caught.
Permitting activations to be interrupted adds considerable complexity to the execution model, but again there
appears to be no alternative, because the ability will be needed in real applications.
4.3. Primitive Intertoken Communication
4.4. Advanced Execution Classes
Exception
A condition whose occurrence disrupts the normal flow of control of execution and causes a special exception
handling mechanism to be invoked. An exception is a usually synchronous effect of executing an action that indicates
that execution of the action cannot be completed normally. Execution of the action must be abandoned and an exception
handling mechanism attached to nested control actions invoked. An exception may also occur in response to an
interrupt that raises an exception. An exception permits a computation to attempt to recover in a clean, context-dependent
manner. An exception handler is an action attached to an action that deals with the occurrence of a specified
exception during execution of the control action or an action nested within it. Exceptions usually propagate bottomup.
Interrupt
An outside request to modify the flow of control of a computation and invoke a context-dependent action. Execution
of an interrupt handler suspends computation of an action and performs an alternate action that may terminate the
action. Interrupt handling is asynchronous because it can happen at any time. The interrput action can propagate the
interrupt downward, kill the execution, and raise an exception. An interrput permits a computation to respond to an
outside occurrence to in a clean, context-dependent manner. An interrupt handler is an action attached to an action
that deals with the occurrence of a specified interrupt during execution of the control action or an action nested within
it.
SimpleQueue
A primitive container for events that supports low-level communication among tokens and infrastructure interpreters
used to implement higher-level concepts, such as active objects and UML state machines. A simple queue only permits
a single reader at one time, but it serializes events added to it concurrently. It provides the fundamental synchronization
concept needed at the low level. This model of waiting is logically simple as well as simple to implement.
The UML state machine semantics can be specified by an interpreter that uses Wait and Poll actions on Simple-
Queues.
A SimpleQueue holds events. An action can poll the queue (taking an event, if any, but returning immediately if
there is no event) or wait on the queue (waiting for an event if there is none), but only one action may wait on a queue
at a time. An action may add an event to the queue. Because the queue may be (conceptually or physically) distant
from the token doing the add, such an action may take time to complete. The queue can handle concurrent adding of
events (this is the source of synchronization). The queue maintains the events in the order they arrive, but implementations
may extend the actions to permit events to be added in various locations in the queue or taken from various
locations in the queue.
Associations
• event: EventInstance [0..*]A set of event instances placed on the queue but not yet handled. The events have an
ordering that is maintained, but an implementation may provide action options to add and
advancedExecution.fm Version 9 December 17, 1999 5:04 pm 24

4 Advanced Execution Mechanisms 4.4 Advanced Execution Classes
to remove events in any location, although a first-in first-out policy is consistent and provides
a simple default.
• waiter: Token[0..1] A token that is waiting for an event on the queue (if any). There may only be a single
waiter.
Constraints: event and waiter may not both be nonempty except for a brief while after an event appears on a
previously empty queue (but this may be hard to formalize)
advancedExecution.fm Version 9 December 17, 1999 5:04 pm 25

4 Advanced Execution Mechanisms 4.4 Advanced Execution Classes
advancedExecution.fm Version 9 December 17, 1999 5:04 pm 26

5 State Machine Execution 5.1 Active Objects
Chapter 5. State Machine Execution
We view the system as a collection of collaborating state machine instances. State machines are copies of the state
chart for a class; each state machine is identified by the object to which it belongs, the target object. For the purposes
of the action semantics, orthogonal or concurrent states constitute a separate state machine, also identified with the
object. Objects can also execute method bodies at the same time as executing a state machine.
This chapter describes how the asynchronous behavior of state machines interact with the synchronous invokation
of methods.
5.1. Active Objects
An active object is an object with a state machine; a passive object is one without. Both active and passive objects
(collectively, objects) may execute method bodies at any time when called by another (active) object, even if they are
executing actions associated with a state machine. All activity in a system is therefore ultimately traceable to active
objects.
An action may send an asynchronous signal event to an active object. Each active object has its own (logical)
event queue. When a signal arrives at an active object, it is added to the event queue of the active object. An active
object chooses when to remove an event from the queue. When the active object dequeues an event, it may initiate a
chain of procedures, each of which receive a copy of the data associated with the event as input. Only when the entire
chain of activity is complete does the active object take another event from the queue.
Sequencing constraints are imposed by causal chains of steps, such as sequential actions or a signal sent to
another active object which then executes and eventually sends a signal to the original sender, but actions that are not
causally connected may proceed at different rates.
There is no assumption of synchronous operation of the entire system, nor indeed any assumption that there even
exists a single time across the entire system. There is no assumption of centrality or globality. There is no central
repository, queue, control, timer, arbiter, etc. These are permissible optimizations, but are not be assumed in the fundamental
execution model. We may define an “absolute” time for the convenience of each object so that we may
cause a signal event to be generated at a giventime, but there is no guarantee that 6:00pm for one instance is the same
as 6:00pm for another. However, this does not fundamentally change the constraints on the computation.
This is a relativistic or Einsteinian view of time, and it requires local frames of reference. With local frames of
reference, one cannot know an absolute time, nor an absolute order. A sender may send two events to two receivers
and have the one sent second one arrive first. All that can be guaranteed conceptually is the order of events between
sender and receiver instances. This guarantee allows two state machines to synchronize their behavior.
5.2. Event processing
A send action transmits a signal event to a target active object. In execution, a send actionX creates a signal event
instance that is transmitted to the target active object. The signal event instance comprises a set of argument values
(passed by value, so they may be data values or pointers but not objects) that must conform in type and number to the
parameters specified by the signal event specification.
The transmission may take some finite time, during which both the sender and the receiver may continue to execute.
A received signal event instance is held, in the logical queue, until it can be handled by the target active object.
Active objects may receive signal event instances. There may be a delay between enqueuing an event and handling
it. When all the actions associated with the state machine for an active object are quiescent, an event, if any, is
handled, and the appropiate transition, if any, is fired. The firing of a transition will cause the exit procedure (the set
of actions on exit from a state), the transition procedure, and the entry procedure to execute in sequence. Each procedure
executes the component actions, including executing calls or creating other active or passive objects.
Because each procedure must have a common set of parameters on which it operates, the action semantics
restrict all signal events that leave a state, including histories, to have the same set of parameters. Similarly, all signal
events entering a set must have the same parameters.
stateMachine.fm Version 9 January 7, 2000 7:55 am 27

5 State Machine Execution 5.3 Run to completion
Note. See the submission by Ian Wilkie on this.
5.3. Run to completion
While the procedure is performing actions, it is insensitive to newly-arrived events, which accumulate in the
queue attached to the active object, until all procedures complete.The fact that an active object must complete the
activity triggered by one event before handling another event is called run-to-completion. Run to completion implies
that an active object synchronizes its own subactivity each time it handles an event. If a procedure contains multiple
actions, they must all complete before any of them can receive another event. However, run to completion does not
imply that the chain of activity is atomic. Run to completion merely says that an active object will not process another
event until all actions caused by one event have completed.
Interrupts, such as kills, supersede run to completion. See Chapter XX
Note that a “do activity” must be represented by a “start action” and a “stop action” in a program, to preserve the runto-completion
property.
5.4. Data access conflict
It may happen that two actions may write the same variable, attribute, or link, or one may write and the other read the
same variable, attribute, or link. This is called data access conflict, and the outcome is not determined: either execution
order is possible, or the value read may be total garbage. Conflict may occur at two levels: within a procedure,
when concurrent actions write the same variable, or at the procedure level, when two procedures write to static object
memory.
Conflict amongst the actions in a procedures is managed by the submission in two ways. First, actions communicate
by data flow, and a variable may not be written twice. Second, read and write actions can access tuples of data as
a unit, effectively providing atomic access.
Conflict amongst procedures can only reliably be managed by synchronizing procedures, or by avoiding overlap
in data access sets that are written and read. Models, then, can be designed so that conflict does not occur.
Preventing conflict is a design issue, not a semantics issue. Preventing conflict in the definition of the execution
machinery would cut the heart out of concurrency. Consequently, the action semantics submission does not attempt to
define what happens in case of this type of conflict.
5.5. State Machine Execution Classes
State machine
Each class has a state chart that describes the behavior of a typical instance. The behavior of each instance is
abstracted as a state machine. A state machine serializes the handling of events. It has an event queue into which
events are added asynchronously as they arrive, but the removal of events from the queue and their handling by the
state machine are serial and subject to the control of the state machine. A state machine obeys run-to-completion
semantics: once it starts handling an event, all triggered actions must be completed before another event can be handled.
An state machine can receive an interrupt, which is handled immediately and may result in the premature termination
of ongoing actions.
stateMachine.fm Version 9 January 7, 2000 7:55 am 28

5 State Machine Execution 5.5 State Machine Execution Classes
Constituent associations:
• queued: SignalEventInstanceThe set of event instances received by the active objects but not yet handled. One
signal event instance is designated the current event.
• currentEvent: EventInstance[0..1]An event instance that is being processed by the active object. Once an event is
removed from the queue (under whatever policy) it becomes and remains the current event
while actions triggered by the event are executed. When all actions in an active object
cease activity, the object is said to be quiescent and the current event is discarded in preparation
to handle a new event from the event queue. Run-to-completion means that another
event will not be handled until all activity triggered by a current event has completed.
Note: I left this in though I think the last sentence of the entry above handles it.
SignalEventInstance
An instance of an event set to an active object is abstrated as a Signal Event Instance. Actions can instantiate signal
evet instances; instances of other kinds of events (such as time events) are generated by the execution infrastructure in
accordance with specified conditions. The ordered collection of signal event instances is also informally referred to as
the event queue.
Signal events have no inherent identity. They are simply the sum of their values and can therefore be passed by
value and copied freely without loss of information.
The form of time event instances and condition instances needs to be determined as they are a bit vague in UML
1.3.
Associations
• sender: SendActionInstanceThe sending actionX for the signal event instance. At run time, only a single actionX
may generate a sigal event instance
• receiver: StateMachineInstanceThe state machine instance to which the event is sent.
• cariee: Argument A signal event instance comprises several arguments, possibly none, in addition to the target
object identifer.
• spec time: SignalEventSpecEach signal event instance conforms to a specification as given by the Signal Event
Spec.
Others
The remaining classes are:
• SignalEventSpec. At specification time, we specify an event that can be generated to a state chart. Each such
specification is abstracted as a Signal Event Spec. UML 1.3 conflates this and the SignalEventInstance.
• Parameter: Defined in UML. Question: Is there an association to SignalEvent(Spec)?
• Argument: Defined in UML. Association to SignalEventInstance is presumably new.
• SendActionInstance. This is a role of actionX, the actionX that is the send action. Unclear whether the role
should be modeled explicitly.
stateMachine.fm Version 9 January 7, 2000 7:55 am 29

5 State Machine Execution 5.5 State Machine Execution Classes
stateMachine.fm Version 9 January 7, 2000 7:55 am 30

III Actions
Part III. Actions
This part contains descriptions of the various actions that can be included in user models. Related actions are organized
into chapters. For each action, a description in given of its model structure, well-formedness rules on its use
within a model, and its semantics specified by before-after conditions on the state of the execution model.
Arguments of actions
Syntax of action arguments is
name:class
The default attribute multiplicity is 1, otherwise it is shown in brackets after the type name.
Semantics specifications
The semantics are given as preconditions and postconditions on the execution values. The values after the action step
are expressed in terms of the values before the step. New values after the step are notated with a prime ('). An
unprimed value represents the previous values. The token performing the step is denoted T and the action being performed
is therefore T.actionPtr. For convenience, we let
A = T.activation
P = T.actionPtr
The phrase “new T”, where T is the name of a class, indicates that an object of the given class is created as part of
the action. Its postcondition values are specified by the semantics.
Multiple sets of preconditions-postconditions-comments may be included in a single actions. The sets are meant
to be applied individually. Each postcondition specification applies to the given precondition.
part-actions.fm Version 9 December 17, 1999 5:04 pm 31

III Actions Semantics specifications
part-actions.fm Version 9 December 17, 1999 5:04 pm 32

6 Action Foundation 6.1 Overview
6.1. Overview
Chapter 6. Action Foundation
As previously proposed, local variables provided local, mutable state during the execution of actions within the context
of some overall “procedure.” While this is a typical concept in traditional programming languages, it introduces
additional possibilities for conflict in the presence of internal concurrency between actions in the procedure. That is,
it opens up the possibility of actions concurrently reading and writing the same local variable without synchronization.
To avoid such conflict while retaining local variables requires a complication of the action semantics and potentially
an undesired reduction in allowed concurrency. On the other hand, the possibility for conflict comes without
much real gain in power. While local variables may be traditional, there are data-flow and single-assignment languages
that do quite well without them. And, in fact, such languages can deal much more simply with fine-grained
concurrency.
So, we can eliminate the problems with local variables by eliminating local variables all together. In this case,
actions can only obtain values from other actions via data-flow connections (at least without resorting to “external”
state-modifying side effects, such as writing then reading an object attribute). The result is an approach to action composition
that allows the maximum amount of internal concurrency without introducing unnecessary potential for conflict.
In this note, we attempt to address the building of an action metamodel foundation based on this approach. Since
the main area of difficulty with the approach is dealing with control constructs, we also address such “composite”
actions.
6.2. Summary
An action is the basic unit of behavior. In general, when executed, an action takes some input values, performs some
processing and produces some set of output values. This may be viewed schematically as follows. (Note that the
graphical notation used here is intended to be illustrative and not a proposal for an actual surface language.)
input
pins
action
output
pins
Figure 4. Action and pins
Input pins are the connection points for delivering the input values to actions. Output pins are the connection
points for obtaining the output values from actions. The types and multiplicities of the input and output pins of an
action are constrained by the form of the action. For example, an action that reads a certain attribute has an output pin
with the type and multiplicity of that attribute, while an action that writes to an attribute has an input pin with the type
and multiplicity of that attribute. An action that calls an operation has input and output pins with types and multiplicities
corresponding to the input and output parameters of the operation.
Note. The types of the input and output pins of an action form the input and output “signature” of the action.
The signature is modeled by derivation from the types of the input and output pins; it is not modeled explicitly.
Some actions impose constraints on the types of some of their pins.
actionFoundation.fm Version 9 December 17, 1999 5:04 pm 33

6 Action Foundation 6.2 Summary
A data flow from an output pin to an input pin indicates that an output value of one action is used as an input
value of another action. This is shown schematically below.
action
Figure 5. Data flow
Note that a single output pin can be connected to multiple (zero or more) input pins. However, each input pin can
have at most one connection. Thus, inputs pins are effectively “single assignment” data holders—once they receive a
value, this value does not change. In other words, normal data-flow connections allow “fan out” (as shown above), but
not “fan in.”
The input pin that is the destination of a data flow must conform to the output pin that is the source of the flow.
Conformance means that the type of the output pin is the same as or a descendant of the type of the input pin, and all
cardinalities allowed by the multiplicity of the output pin are allowed by the multiplicity of the input pin. For example,
if the type of the output pin is money, and the type of the input pin is real, and money is a descendant of real, then
the types conform.
A control flow indicates a predecessor action that must complete all execution before a successor action can
begin to execute. Control flows permit normal imperative programming, and make it possible to sequence actions
explicitly, particularly when the actions have memory-modifying side effects (e.g., writing or reading a value of an
attribute). All these requirements can be captured using control flows.
Two such control flows are shown schematically below. Both predecessor actions (A and B) must be completed
before the successor action (C) can execute.
action A
data flow
Figure 6. Control flow
action
action
predecessors action C successor
action B
control flow
A data flow implies a control dependency in the sense that an executing action cannot consume an input value
during execution until it has been produced by the source action. Control sequencing is implicit between actions connected
by data flows; it is unnecessary to include explicit control flows between such actions. Explicit control flows
must not violate the sequencing implied by data flows.
A primitive action is one that cannot be decomposed into other actions. Primitive actions include purely mathematical
functions, such as arithmetic and string functions, actions that work on object memory, such as read actions
and write actions, and actions related to object interaction, such as call actions and send actions. Each kind of primi-
actionFoundation.fm Version 9 December 17, 1999 5:04 pm 34

6 Action Foundation 6.2 Summary
tive action has a form that specifically defines sets of input and output pins. The details of the various kinds of primitive
actions are not considered further in this note.
Primitive actions may be composed into composite actions, which may in turn be themselves parts of larger composites.
Depending on the form of the composite, data flows may cross the boundary of a composite and connect to
input and output pins of actions within the composite. (There are constraints imposed by some composites. See the
description of each one.) Such pins may be owned by the composite or by actions (including other composite actions)
nested within it. Pins directly or indirectly within a composite action that may be connected to flows crossing the
boundary of the composite are said to be available inputs and available outputs of the composite. For example, consider
the composite shown schematically below.
composite action
m
n
action
p
action
action
Figure 7. Data flows across composite action boundary
The pins labeled m, n and q are available inputs for the composite, while pin r is not (since it is already connected
within the composite). An input pin is an available input only if it is not already connected within the composite, and
the connection rules permit its connection outside the composite. Pins x, y and z are available outputs, and so is pin p
(since any output may be connected more than once). An output pin is an available output if the connection rules permit
its connection outside the composite. The description of each kind of composite defines the connection rules for
available inputs and outputs. Thus, if we “zoom out” to a higher-level view gives an effective external view such as
shown below.
available
inputs
Figure 8. Available inputs and outputs of composite action
While in this view the available input and output pins are shown as inputs and outputs of the composite action, it
is important to remember that the composite action in this case does not actually own those pins, actions inside the
composite do. Drawing the available inputs and outputs of a composite action, as above, is simply an illustrative convenience.
However, some composite actions (conditionals and loops) may actually also have pins of their own, which
are included in their sets of available inputs and/or outputs. This is discussed in detail in the following section on
composite actions. For generality, primitive actions may be considered to have available inputs and outputs, too,
which are the same as the input and output pins that they own.
At the highest level of composition, an action can provide the behavioral specification for a procedure. A procedure
can be the body of a method, or it may specify the behavior executed on exit from a state, on a transition or on
actionFoundation.fm Version 9 December 17, 1999 5:04 pm 35
q
r
q
p
m composite
x
available
y
n action
outputs
z
x
y
z

6 Action Foundation 6.2 Summary
entry to a state. The inputs of the action take their values from the arguments of the procedure (corresponding to the
input parameters) and the outputs of the action provide the results of the procedure (corresponding to the output
parameters). Effectively, then, we treat the body of a method, and the behavior associated with exit from, transition to,
or entry to a state each as a procedure with arguments and results. (Note that methods and transitions triggered by call
events may have results; other transitions, as well as entry and exit procedures, do not have results.)
So that the arguments can be attached to the available inputs of the action using normal data flows, the arguments
are represented as output pins within the procedure (they supply values to the action). Similarly, the results are represented
as input pins within the procedure (they use values produced by action). This is shown schematically below.
procedure (a,b): x,y
a
x
arguments action
results
b
y
Figure 9. Procedure with pins and action
Note that, to be well formed, the ordered list of arguments and results of the procedure must match the types and
multiplicities of the corresponding (by order) parameters of the method or event. (The in and in-out parameters must
conform to the argument pins, and the result pins must conform to the in-out, out and return parameters.) However,
these are well-formedness rules for a method or event-triggered transition that are not considered further here.
Argument pins are output pins, and therefore each one may be connected to zero or more available inputs of the
action. Result pins are input pins, and therefore each one must be connected to exactly one available output of the
action. The data flow connections must follow the normal connection rules for input and output pins.
Note. The previous metamodel had a “procedure action” as a kind of group action. However, on reflection, it
seems better to not have a procedure be a kind of action. A procedure is intended to be solely a top-level construct,
and so it should not be included in composite actions like other actions can be.
actionFoundation.fm Version 9 December 17, 1999 5:04 pm 36

6 Action Foundation 6.3 Foundation Classes
The above foundational concepts for actions are reflected in the following metamodel.
ControlFlow
*
*
+antecedant
+predecessor 1
PrimitiveAction
+consequent
+successor
1
Action
+action 1
Note. It might be desirable to make the association between Action and Procedure bidirectional. However, in
this case, consistency would argue that all possible composition as associations of Action should be bidirectional
(i.e., compositions with GroupAction and Clause in the next section). But this would add a lot of
knowledge to the specification of Action of its composite-action subclasses, which might not be particularly
desirable. There is no inherent reason why an action need know that it is a top-level action within a procedure,
therefore the association is shown as directed.
6.3. Foundation Classes
*
*
ModelElement
Classifier +type
Pin
1 * multiplicity : Multiplicity
+action
+outputPin
0..1
+action
{ordered} * OutputPin 1
+source
0..1
{ordered}
+inputPin *
*
{ordered}
+argument
+flow *
+/availableInput
*
*
{ordered}
InputPin
+/availableOutput *
+result
+destination
Figure 10. Action foundation metamodel
+procedure
DataFlow
Procedure
Action
An action is the fundamental unit of behavior specification. In general, an action takes a set of inputs and converts
them into a set of outputs, though either or both sets may be empty. (If both inputs and outputs are missing, the action
must perform some kind of fixed, nonparameterized side effect on the system state, but it is possible to think of such
actions.) Actions may access or modify accessible, mutable objects. (Note that, by definition, changes to mutable
objects are side-effects on the memory of the object, not data flow. However, references to objects to read or write and
values to write are passed as data flow inputs to read or write actions, and data values read from objects are passed to
subsequent actions as data flows. The result of a write action is not a new object pointer. In this case, the object iden-
actionFoundation.fm Version 9 December 17, 1999 5:04 pm 37
1
+flow
0..1
0..1
0..1
+procedure
0..1

6 Action Foundation 6.3 Foundation Classes
tity has not changed. Write actions have their effects by side effects on the system state.) Composite actions may
include data-transformation actions as well as object-access actions.
An action may have a set of incoming data flows as well as a set of explicit control flow dependencies to predecessor
actions. An action will not begin execution until all of its input values (if any) have been produced by preceding
actions and all predecessor actions have completed.The completion of the execution of an action may enable the
execution of a set of successor actions and actions that take their inputs from the outputs of the action. Actions come
in various kinds, each of which has its own formation rules. An action must be one of those kinds.
Associations
• antecedent The set of control flows that must be enabled before this action can execute.
• availableInput (derived) The set of all input pins available to be the destinations of data flows from outside
the action. This implies that they are not connected by data flows within the action.
The derivation rule is defined for each kind of action.
• availableOutput (derived) The set of all output pins available to be the sources of data flows out of the
action. The derivation rule is defined for each kind of action.
• consequent The set of control flows that are enabled when this action finishes executing.
• inputPin The ordered set of input pins owned by the action, which act as connection points for providing
values consumed by the action
• outputPin The ordered set of output pins owned by the action, which act as connection points for
obtaining values generated by the action.
Well-formedness rules
[1] There must be no cycles in the graph of actions and flows, where a cycle is defined as a path that begins and ends
at the same action and a path is constructed from directed edges between actions, with control flows traversed
from predecessor action to successor action and data flows traversed from the action of the source pin to the
action of the destination pin. A control flow from or to a group action is treated as being a set of control flows
from or to each action within the group action.
Note. This is a necessary but not sufficient condition to prevent ill-formed control cycles. There are additional
conditions related to conditional and loop actions that are handled below as well-formedness rules for
those kinds of actions.
ControlFlow
A control flow represents a sequencing dependency between two actions. The successor action of the flow may not
execute until the predecessor action has completed execution.
Associations
• predecessor The action that must finish executing before the successor can execute.
• successor The action that cannot execute until the predecessor completes execution.
DataFlow
A data flow is a carrier of values from a source output pin to a destination input pin. When a value is generated on the
source pin, it is copied to the destination pin. The source pin must therefore conform in type and multiplicity to the
destination pin
actionFoundation.fm Version 9 December 17, 1999 5:04 pm 38

6 Action Foundation 6.3 Foundation Classes
Associations
• destination The input pin that receives the data carried by the flow.
• source The output pin that provides the data carried by the flow.
Well-formedness rules
[1] The type of the source pin must be the same as or a descendant of the type of the destination pin.
[2] All cardinalities allowed by the multiplicity of the source pin must be allowed by the multiplicity of the destination
pin.
InputPin
An input pin is a pin that represents input values to be consumed by an action. An input pin may be the destination for
at most one data flow. In this case, the input pin receives its values from the source output pin of the data flow.
Associations
• action The action that owns the pin as an input (not used with procedures)
• flow The data flow for which this input pin is the destination.
• procedure The procedure that owns the pin as a result (not used with actions).
Well-formedness rules
[1] An input pin must be owned by either an action or a procedure.
OutputPin
An output pin is a pin that represents output values generated by an action. A single output pin may have several dataflow
connections to several input pins. In this case, the output pin provides a copy of its value to each of the associated
input pins.
Associations
• action The action that owns the pin as an output.
• flow The data flow for which this output pin is the source.
• loop The loop action that owns the pin as a loop variable (see the discussion under Composite
Actions).
• procedure The procedure that owns the pin as an argument.
Well-formedness rules
[1] An output pin must be owned by either an action or a procedure.
Pin
A pin is a connection point for delivering input values to or obtaining output values from an action. Any values passing
through the pin must conform to the type of the pin and have cardinalities allowed by the multiplicity of the pin.
Pin is completely specialized into input and output pins.
actionFoundation.fm Version 9 December 17, 1999 5:04 pm 39

6 Action Foundation 6.3 Foundation Classes
Attributes
• multiplicity A specification of the number of values a pin may hold at any one time.
Associations
• type A classifier specifying the allowed classifiers of values passing through the pin. The actual
classifier of a value must conform to the type specification of the pin.
PrimitiveAction
A primitive action is one that does not contain any nested actions, so all available inputs and outputs of the action are
pins directly owned by the action. PrimitiveAction describes the common properties of all the various kinds of primitive
actions.
Well-formedness rules
[1] The available inputs of a primitive action are the input pins of the action.
[2] The available outputs of a primitive action are the output pins of the action.
Note. PrimitiveAction is really only defined as a convenience to provide a common definition of these wellformedness
rules for all kinds of primitive actions.
Procedure
A procedure may act as the body of a method or the reaction to an event. The behavior of the procedure is specified
using an action. The procedure has an ordered list of arguments, represented as output pins, that may be connected as
sources to the available inputs of the body action. It also has an ordered list of results, represented as input pins, which
must be connected as destinations to the available outputs of the body action.
Associations
• action The action that provides the behavioral specification of the procedure.
• argument The ordered set of output pins representing procedure arguments.
• result The ordered set of input pins representing procedure results.
Well-formedness rules
[1] All available inputs of the action of a procedure must be the destinations of flows, the sources of which are arguments
of the procedure.
[2] All results of a procedure must be the destination of flows, the sources of which are available outputs of the
action of the procedure.
actionFoundation.fm Version 9 December 17, 1999 5:04 pm 40

7 Composite Actions 7.1 Group Action
Chapter 7. Composite Actions
Composite actions are recursive structures that permit more complex actions to be composed from simpler action.
Depending on its structure, a composite action can contain other composite actions as well as primitive actions. Ultimately
the leaves of the action tree are primitive actions.
7.1. Group Action
The simplest form of composite action is the group action. A group action simply composes a set of actions into a single
higher-level unit. These actions may be interconnected within the group.
A group action does not own any pins of its own. Data flows may “cross the boundary” of a group action to connect
to input an output pins of actions within the group. In effect, the boundary of the group action is “porous”, allowing
input values to flow into the group and output values to flow out. This approach to grouping is intended to focus
on convenience in organizing a computation rather than encapsulation of decomposition.
When can define this more precisely using the concept of available inputs and available outputs introduced in the
previous section. Any available inputs of actions within the group that are not connected within the group are available
inputs of the group as a whole. All the available output actions within the group are available outputs of the group
as a whole (since there is no restriction on the number of data-flow connections an output pin may have).
This is shown schematically below.
A
group action
m
n
action E
B
p
C D
action F
action G
Figure 11. Group action and its flows
Group actions can be predecessors and successors in control flows, so they provide the ability to synchronize on
the execution of groups of actions, as shown in the diagram above. A control flow whose destination is a group action
requires that the predecessor must complete before any action within the group action may begin. A control flow
whose source is a group action requires that all actions within the group action must complete before the successor
may begin.
Control-flow connections may also cross the boundary of a group action, allowing synchronization on individual
actions within the group. Other actions in the same group action are not affected by such a direct control flow connection
into the group action.
compositeActions.fm Version 9 December 17, 1999 5:04 pm 41
q
r
x
y
z

7 Composite Actions 7.1 Group Action
For instance, in the example shown above, predecessor action A must complete before any of the actions inside
the group—E, F, and G—can execute. All of the interior actions E, F, and G must complete before exterior action D
can execute. In addition, exterior action B must complete before interior action G can execute, but interior actions E
and F are unaffected by exterior action B. Action E must also wait for the actions that produce its input values m and
n. Action F must also wait for interior action E to complete, because it uses data produced by E. Action F is concurrent
with actions E and G. It must wait for its input value p produced by an exterior action. Exterior action C must
wait for interior action E to complete, but it need not wait for actions F and G. Any actions that use values x and y
must wait for action F. Any actions that use value z must wait for action G.
compositeActions.fm Version 9 December 17, 1999 5:04 pm 42

7 Composite Actions 7.2 Conditional Action
7.2. Conditional Action
The other forms of composite action provide for control structuring. A conditional action provides for the conditional
execution of contained actions depending on the result of test actions. The structure of a conditional action is shown
schematically below.
conditional action
clause
test
test
test
Figure 12. Conditional action and pins
As shown above, a conditional action contains a set of clauses, each of which consists of a test action and a body
action. The test action must have an output of type Boolean that is used to control whether or not the body action is
executed. The body action can be executed only if the test output has the value “true”. This implicit conversion of a
data flow to a control flow is shown above as a small diamond. The implicit control flow is not actually explicitly
included in a model. (Note that, per the discussion on group actions above, if any the test or body actions are group
actions, then the input and output pins diagrammed above for these actions are really available input and output pins
of the group actions.)
Note. We have chosen here to have tests return normal Boolean data outputs, which are then implicitly converted
to control flows. Actually, only a very primitive concept of Boolean is necessary with the distinguished
data values “true” and “false”)
In addition to the implicit “success” control flow (enabled when the test results in “true”) that triggers the body of
a clause, there is also implicitly a complementary “failure” control flow (enabled when the test completes execution
but does not result in “true”). This is shown above as a second control flow arrow from the little diamonds. The test
action of one clause may be the destination of the implicit “failure” control flows of the test actions of other clauses,
meaning that it can only execute if the test actions of the other clauses all fail. This is useful, for example, if a predecessor
test is necessary to ensure the validity of the successor test (such as first testing for null pointers or empty containers).
In the absence of such control-flow constraints, test actions are executed concurrently. Since failure control-flow
connections are thus optional, they must be included explicitly in the metamodel. They are actually captured as control
flows between the tests themselves, though unlike other control flows they only fire if the test source test completes
execution and fails. (These are not actually normal control flows, and their form within the conditional is
highly constrained.)
compositeActions.fm Version 9 December 17, 1999 5:04 pm 43
body
body
body
conditional
output
pins

7 Composite Actions 7.2 Conditional Action
In any execution of a conditional action, exactly one body action is executed. If the results of the test evaluation
imply that more than one body action is triggered for execution, then exactly one action is selected for execution, but
it is unspecified which one. At least one test action must always evaluate to true or the conditional action is ill formed.
(Note that there is no guarantee that the execution environment will produce a “fair” or random outcome in its selection
of an action to execute—it might always pick the same outcome, but then it might not. The modeler, though, has
no way to predict this and must not assume any particular result or pattern.)
If the tests are not otherwise guaranteed to be exhaustive, then this can be ensured by providing a default action
with a test of “true” that is a successor of all other tests (as shown in the diagram above). Such a default clause is not
required in all cases, however, because this would impose an unnecessary burden on those models in which all of the
choices can be exhaustively enumerated.
Indeed, in many cases the tests in a conditional will be both exhaustive and mutually exclusive by design. This
case is common and important enough that the conditional action can be explicitly tagged as being “determinate.” In
this case, exactly one concurrent test action must evaluate to true.
Determinism is an assertion by the designer—if it is not correct, the model is ill formed. It can be achieved either
by complete, explicit sequencing of the test actions or through the designer’s knowledge that tests that are not
sequenced are mutually exclusive. Note that the latter case does not imply a need for the run-time system to test that
the other tests do indeed evaluate to false—the developer has the responsibility to guarantee mutual exclusion. (If the
tests are totally sequenced explicitly, then mutual exclusion is guaranteed in any case, so the flag is really needed only
in case the tests are not totally sequenced.)
The available inputs of all test and body actions must be connected to output pins outside the conditional action.
Thus the available inputs of the entire set of test and body actions are the available inputs of the conditional action as
a whole. The conditional action as a whole owns an ordered set of output pins. Each clause must identify as its outputs
an ordered list of available outputs of its body action. This list must be of the same size as the list of outputs of
the conditional. Further, the each output pin of each clause must conform in type and multiplicity to the corresponding
output pin of the conditional. Whichever (single) clause of the conditional action has its body executed, the values
of the outputs of that clause are implicitly copied to the conditional output pins.
Conditional actions provide the only points of effective “fan in” of data flow. This fan in within a conditional
action does not violate the “single assignment” principle, however, since only one of the body actions can execute
during any execution of the conditional action, so the each conditional output pin will receive only one value. Also,
since exactly one body action must execute, each conditional output pin will always receive a value.
The available outputs of a body action may not be directly connected to input pins outside the body action. The
available outputs of test actions may not participate in data flows at all.
Note. In principle, available outputs of a test could be connected to available inputs of the corresponding
body, but it seems simpler to keep the test and body actions separate except for their implicit control link.
compositeActions.fm Version 9 December 17, 1999 5:04 pm 44

7 Composite Actions 7.3 Loop Action
7.3. Loop Action
The final kind of composite action is the loop action. The loop action provides for repeated execution of a contained
action so long as a test action results in an appropriate value. The structure of a loop action is shown schematically
below.
conditional action
clause
test body
fixed value (during loop)
loop
variables
Figure 13. Loop and pins
loop input pins
loop
output
pins
As shown above, the loop action contains a single clause with a test action and a body action. The body action is
executed repeatedly as long as the test action outputs “true”. The body action operates on a set of “loop variables,”
which are represented as an ordered set of output pins defined within the loop action.
As output pins, the loop variables may be connected to available inputs of the test and body actions. They provide
the “old values” or “current values” of the loop variables during a loop iteration. The clause outputs, which must conform
to the types and multiplicities of corresponding loop variables, provide the “new values” or “next values” of the
loop variables at the end of an iteration. The values of the clause outputs are implicitly copied to the loop-variable
pins, to become the “old values” for the next iteration.
Before the first iteration, the loop variables are initialized with the values from a corresponding ordered set of
loop input pins, which must conform in type and multiplicity to the loop variables. The test is performed after the initial
values of the loop are copied to the loop variables, before the body is first executed. If the test outputs true, then
the body is executed. Otherwise the loop terminates without executing the body at all and the values of the loop variables
are copied to the corresponding loop output pins. The loop variables must conform in type and multiplicity to
the loop output pins.
After each execution of the body, the test is executed again using the new values of the loop variables (i.e., the
values produced by the previous execution of the body). If the output value of the test is true, the body is executed
again. Otherwise, the values of the loop variables are copied to corresponding loop output pins, and the execution of
the loop is complete.
Note that the loop variables are not explicitly “reassigned” in the body action. Instead, the input and output pins
for the body action hold the “old values” and the “new values” of the loop variables during a single iteration. This preserves
the single-assignment principle, at least as far as the loop body action is concerned.
compositeActions.fm Version 9 December 17, 1999 5:04 pm 45

7 Composite Actions 7.4 Concurrent Collection Actions
7.4. Concurrent Collection Actions
The map and reduce actions invoke an action concurrently on the elements of a collection. In the map action, an
action is applied concurrently to each of the elements of the collection. Each input value must be a collection; all the
collections must have the same shape (number of elements and class of element). If the action has output values, they
are assembled into a new collection of the same shape as the input collection.
The reduce action invokes an associative action with two input pins and one output pin, all of the same type. This
action accepts as input a collection whose elements are of the type accepted by the associative action. The action is
repeatedly applied to adjoining pairs of elements with the result replacing the pair of elements. When a single value
remains, the reduce action produces the single value as its output. The result of executing the reduce action does not
depend on the order in which pairs of values are evaluated (assuming there are no side effects). Common rank-reduction
functions such as sum, product, maximum value, Boolean and and or, and many others can be expressed as
reduce actions.
7.5. Composite Classes
The above structures for composite actions are formalized in the following metamodel.
+subaction
0..1
*
Action
1
GroupAction
+test
1 0..1
+body
+testOutput 1
0..1
OutputPin
0..1
Clause
ConditionalAction
isDeterminate : Boolean
Figure 14. Composite actions metamodel
Clause
A clause is a part of a conditional or loop action. A clause contains a test action and a body action. The execution of
the body action is conditional on the execution of a test action and its producing a “true” value. The clause distinguishes
one available output of the test action, which must have type Boolean; the body action is only executed if this
output has the value “true”. (Additionally, for a conditional, only one clause body is executed even if more than one of
their tests is true.) The outputs of the clause are an ordered subset of the available outputs of the body action.
compositeActions.fm Version 9 December 17, 1999 5:04 pm 46
*
*
1..*
+output
{ordered}
+clause
0..1
+loopVariable
* {ordered}
+clause
1
LoopAction
0..1
0..1
+loop

7 Composite Actions 7.5 Composite Classes
During the execution of an enclosing conditional action, a test action may not execute unless all of its predecessor
test actions (if any) have executed and produced “false” values. A test action may not participate in any explicit
control flows except control flows among test actions contained in the same conditional. A body action may not participate
in any explicit control flows.
Associations
• test The action whose Boolean result must be true for execution of the body action to proceed.
• testOutput The available output pin of the test action whose value is the test result. It is this output
that is converted to the control flow that manages which body to execute.
• body The action whose execution is contingent on the result of the test action.
• output The ordered set of available outputs of the body that are considered to be results of the
clause.
Well-formedness rules
[1] None of flows attached to the available outputs of the test action of a clause may have destinations outside the test
action.
[2] The testOutput of a clause must be an available output of the test action.
[3] The testOutput pin must conform to type Boolean and multiplicity 1..1.
[4] None of the actions within the test action of a clause (if any) may have control-flow connections with actions outside
the test action.
[5] None of the actions within the body action of a clause (if any) may have control-flow connections with actions
outside the body action.
[6] The body action of a clause may not participate in control flows.
[7] An output of a clause must be an available output of the body of the clause.
ConditionalAction
A conditional action consists of a set of one or more clauses, exactly one of whose bodies is executed during any execution
of the conditional action. If more than one clause has a test that outputs “true”, then exactly one of the corresponding
body actions is selected for execution, but it is unspecified which one. (However, if the conditional action is
an “determinate,” then exactly one concurrent clause test must return true.) Each clause must have an ordered list of
output pins that conform to the ordered list of output pins of the conditional. The only available outputs of the conditional
action as a whole are the output pins owned by the conditional action directly.
Attributes
• isDeterminate If true, then whenever the conditional action is executed, exactly one test action must
result in “true”. (This is an assertion, not an executable property. If the assertion is not
true, the model is ill formed.)
Associations
• clause The set of clauses contained in the conditional action.
Well-formedness rules
[1] Each clause of a conditional action must have a number of outputs equal to the number of output pins of the conditional
action. Each output of a clause must conform in type and multiplicity to the corresponding output of the
conditional.
compositeActions.fm Version 9 December 17, 1999 5:04 pm 47

7 Composite Actions 7.5 Composite Classes
[2] No data flow attached to an available output of the test or body actions of a clause of a conditional action may
have a destination outside that action.
[3] The test action of a clause of a conditional action may not participate in control flows other than with the test
actions of other clauses in the conditional action.
[4] A conditional action owns no input pins.
[5] The available inputs of a conditional action are the union of the available inputs of the test actions and body
actions of all the clauses of the conditional action.
[6] The available outputs of a conditional action are the output pins of the conditional action.
[7] There may be no path from an output pin of a conditional action to any action within the conditional action
(where a path is defined as in rule [1] for Action).
GroupAction
Output: none
Parameters: clause:Clause[0..*]
Consists of a set of clauses, each of which has a condition and a body action. The condition is itself an action that
yields a Boolean value. Evaluation of the condition must not cause side effects in the system state.
The referenced clauses may have TestOrder links (predecessor-successor) among themselves to specify the
sequencing constraints among the tests of the guard conditions. If these are arranged sequentially, the testing is totally
deterministic. Otherwise the outcome may be nondeterministic.
The condition values are evaluated in the order specified by the test order; the body of exactly one clause whose
condition evaluates to true is executed, unless no conditions are true, in which case no statement is executed. A clause
body will not be executed unless the guard conditions of all of its predecessors test false. If there is no constraint
among two clauses and both of their guard conditions test true, the choice of which body to execute is nondeterministic,
but only one will be executed in any case whatsoever.
If there are no sequencing constraints among clauses, there is a nondeterministic choice among the clauses whose
guard conditions test true; this is similar to a set of state transitions, only one of which is triggered. If the clauses are
arranged as a list by a chain of constraints, the construct represents an if..elseif...elseif... chain. A literal true condition
represents an else clause. If all the conditions are true but there are no constraints, the construct represents a nondeterministic
branch. By the proper choice of guard conditions, a case statement can be represented.
Semantics
T: ExclusiveSetToken; P->type = ExclusiveSet
Comment: must keep track of the statements whose guards have been tested because of precedence constraints, only
enable one action even if multiple guards are true, the choice is nondeterministic
Precondition: T.status = ready
Postcondition: T.status' = testing
T.subtoken' = {for each C:Clause in P.clause | new U:ClauseToken where U.actionPtr = C and U.status = unready
}
Comment: start the testing, create tokens to keep track of what has been tested
Precondition: T.status = testing; (there exists U in T.subtoken | U.status = unready and
(for each Q in U.actionPtr.predecessor there exists Y in T.subtoken | Y.actionPtr = Q and Y.status = failed and
compositeActions.fm Version 9 December 17, 1999 5:04 pm 48

7 Composite Actions 7.5 Composite Classes
(there does not exist W in T.subtoken | W.status = testing) and
U.actionPtr.guard is not empty)
Postcondition: U.status' = testing; new V: ConditionToken; U.test = V; V.actionPtr = U.actionPtr.guard; V.status =
ready
Comment: If no test is outstanding, find a statement whose predecessors have failed and test it. The assumption is that
the setup step is atomic, at least within the action set, otherwise two concurrent statements could be enabled
simultaneously, the test for an existing execution notwithstanding. This step introduces nondeterminism. The
tests themselves are not concurrent, although they could be made so, but that would require killing uncompleted
tests.
Precondition: T.status = testing; (there exists U in T.subtoken | U.status = unready and
(for each Q in U.actionPtr.predecessor there exists Y in T.subtoken | Y.actionPtr = Q and Y.status = failed and
(there does not exist W in T.subtoken | W.status = testing) and
U.actionPtr.guard is empty)
Postcondition: T.status' = executing; U.status' = executing; new W: Token; T.body' = W; W.actionPtr =
U.actionPtr.body; W.status' = ready
Comment: If no test is outstanding, find a statement whose predecessors have failed and and whose guard condition is
absent (and therefore true) and execute its body.
Precondition: T.status = testing and (there exists U in T.subtoken | U.status = testing and
V = U.test and V.status =passed)
Postcondition: T.status' = executing; U.status' = executing; destroy V'; new W: Token; T.body' = W; W.actionPtr =
U.actionPtr.body; W.status' = ready
Comment: If a test succeeds, then execute the corresponding body and stop testing
Precondition: T.status = testing and (there exists U in T.subtoken | U.status = testing and
V = U.subtoken and V.status =failed)
Postcondition: destroy V'; U.status' = failed
Comment: if a guard fails, mark the clause as failed
Precondition: T.status = testing and (for each U in T.subtoken) U.status = failed
Postcondition: T.status' = complete; destroy T.subtoken' and contents
Comment: if all the guards fail, then don’t execute anything, the statement is complete
Precondition: T.status = executing and (there exists U in T.subtoken) U.status = executing and U.subtoken.status =
complete
Postcondition: T.status' = complete; destroy T.subtoken' and all contents, including U'
Comment: when the triggered action is complete, then the statement is complete
Comment: An if-elseif chain is just a special case of an exclusive set with predecessors arranged linearly.
GroupAction
A group action represents a simple composition of a set of subactions. A group action does not own any pins of its
own, but data-flow connections may (generally) be made from actions outside the group to pins owned by actions
within the group action. The group action as a whole may participate in control flows and actions within the group
action may also participate in control flows with actions outside the group action. There is an implicit control flow
from the group action to each action within it; this is important only if there is a control flow to the group action. Sim-
compositeActions.fm Version 9 December 17, 1999 5:04 pm 49

7 Composite Actions 7.5 Composite Classes
ilarly, there is an implicit control flow from each action in the group action to the group action; this is important only
if there is a control flow from the group action.
Associations
• subaction The set of actions contained in the group.
Well-formedness rules
[1] A group action does not own any pins.
[2] The set of available inputs of a group action is the union of the available inputs of all the subactions of the group
action not connected within the group action to an output of a subaction of the group action.
[3] The set of available outputs of a group action is the union of the available outputs of all the subactions of the
group action.
Semantics
Input: none
Output: none
Parameters: subaction:Action[0..*]
The referenced actions may have control flow links (predecessor-successor) among themselves to specify the
sequencing constraints among the actions.
The actions in the set are executed concurrently, subject to the sequencing constraints among them. An action can
execute when all its predecessors have executed. When all actions in the set have executed, execution of the concurrent
set construct is complete.
T: GroupToken; T. actionPtr->type = GroupAction
Comment: must keep track of the set of statements that have been executed because of precedence constraints,
therefore need a set of tokens or other markers of size O(statements)
Precondition: T.status = ready
Postcondition: T.status' = executing
T.subtoken' = {for each S in P.statement => new U: Token where U.actionPtr = S; U.status = unready}
Comment: to start the concurrent set, create a set of unready tokens, one for each statement in the set, and mark them
as not having executed yet
Precondition: T.status = executing; (there exists U in T.subtoken | U.status = unready;
(for each Q in U.actionPtr.predecessor | there exists V in T.subtoken | V.actionPtr = Q and V.status = complete))
Postcondition: U.status' = ready
Comment: start executing a statement if its predecessors have completed and it has not yet been run
Precondition: T.status = executing; (for each U in T.subtoken | U.status = complete)
Postcondition: destroy T.subtoken' and its contents; T.status = complete
Comment: the concurrent action is complete when all of its statements have executed
Discussion
Normal sequential execution is just a special case of concurrent execution in which the sequencing constraints
form a list.
compositeActions.fm Version 9 December 17, 1999 5:04 pm 50

7 Composite Actions 7.5 Composite Classes
LoopAction
Output: none
Parameters: whileTest: Condition, body: Action
The condition is repeatedly evaluated. As long as it is true, the body action is executed. When is evaluates false,
the loop is complete.
Semantics
T: ConcurrentSetToken; T. actionPtr->type = ConcurrentSet
Precondition: T.status = ready
T: LoopToken; T.actionPtr->type = Loop
Postcondition: T.status'= testing; new U: ConditionToken; T.test = U; U.actionPtr = P.whileTest; U.status = ready
Comment: Start the test going
Precondition: T.status = testing; T.test = U; U.status = passed
Postcondition: destroy U'; T.status' = executing; new V: Token; T. body' = V; V.actionPtr = P.body; V.status = ready
Comment: if the condition is true, execute the body
Precondition: T.status = testing; T.test = U; U.status = failed
Postcondition: T.status' = complete; destroy U''
Comment: if the condition is false, the loop is complete
Precondition: T.status = executing; T.body = V; V.status = complete
Postcondition: T.status' = ready
Comment: repeat the loop
LoopAction
A loop action contains a single clause whose test action and body action are executed repeatedly as long as the test
action outputs a “true” value. A special list of output pins acts as “loop variables” for the loop action. The loop variables
are not directly available outside the loop. Input pins of the overall loop action provide initial values that are
copied into these loop variables before the first iteration of the loop. As output pins, the loop variables may be connected
to available inputs of the test and body actions using normal data flows, to provide the “old values” of the loop
variables during an iteration. The outputs of the loop clause provide “new values” that are copied to the loop variables
at the completion of an iteration. The test is executed after the initial values are copied to the loop variables, and also
after each execution of the body action. The body action is executed only if the test outputs a “true” value. When the
loop terminates, the final values of the loop variables are copied to the regular output pins of the loop action, which
are the only available outputs for the loop action as a whole.
compositeActions.fm Version 9 December 17, 1999 5:04 pm 51

7 Composite Actions 7.5 Composite Classes
Associations
• clause The clause that contains the test and body actions for the loop.
• loopVariable The set of loop-action output pins that act as loop variables for the loop. These are owned
directly by the loop action, but they are not available outside the loop.
Well-formedness rules
[1] The clause of a loop action must have the same number of outputs as the number of loop variables of the loop and
each clause output in the ordered list must conform to the corresponding loop variable in type and multiplicity.
[2] A loop action must have the same number of inputs pins as loop variables and each input pin must conform to the
corresponding loop variable in type and multiplicity.
[3] A loop action must have the same number of output pins as the number of loop variables and each loop variable
in the ordered list must conform to the corresponding output pin (in order) in type and multiplicity.
[4] The test action of the clause of a loop action may not participate in any (explicit) control flows.
[5] The set of available inputs of a loop action is the union of the available inputs of the test and body actions of the
clause of the loop action that are not connected to loop variables and the loop-action input pins.
[6] The available outputs of a loop action are the output pins of the loop action.
[7] There may be no path from an output pin of a loop action to any action within the loop action (where a path is
defined as in Rule [1] under Action).
MapAction
Output: none
Parameters: target: Collection of Object, mapop:Operation, input: Collection [0..*] of Value
Constraints: The number and types of the arguments must be compatible with the operation.
The operation is called concurrently on each object in the set of targets. When all of the calls are complete, the
map action is complete. The operation must perform its work by side effects on the targets, as there are no return values
Note that there is one target specification, which at run time must be a collection of objects. There is a list of
input argument specifications, each of which at run time must be a collection of values of the same shape as the target
collection. The number of input collections must equal the number of arguments in the operation. For each call on the
operation, one value is taken from the target collection and from each input collection.
ReduceAction
Output: Value
Parameters: target: Collection of Object, redop:Operation
Constraints: The redop type operation must be an operation on the type of objects in the collection, which must all be
compatible with the type. The redop operation must be associative. Its arguments are a pair of target objects (or a
target object and another of the same type as argument). The result of the reduce operation is also of the same type.
The operation is applied to a pair of consecutive values and the result value conceptually replaces the two input
values, reducing the size of the list. This procedure is repeated until only one value remains. This value is the result of
the reduce action. Because the redop is associative, the result value is insensitive to the order in which the reduction is
done (partial parallel execution is possible).
Note that there is one target specification, which at run time must be a collection of objects. There is no collection
of input values. The result is a single value.
compositeActions.fm Version 9 December 17, 1999 5:04 pm 52

7 Composite Actions 7.5 Composite Classes
TestAction (implicit rules, not an explicit action)
T: TestToken; T.actionPtr->type = TestAction
Comment: execute an action and return status passed or failed
Precondition: T.status = ready
Postcondition: new U: token; T.testBody' = U; T.status' = executing; U.status = ready
Precondition: T.status = executing; U = T.testBody; U.status = complete
Postcondition: destroy U'; if U.activation[P.flag] = true then T.status' = passed else T.status' = failed
Discussion
As part of the procedure structure, there are flow of control meta-actions that structure simple actions. These are
concurrent sets (execute all the contained statements), exclusive sets (execute only one contained statement whose
guard condition evaluates true), and loops (execute one statement repeatedly until the guard condition evaluates
false). Control actions build larger actions out of smaller ones.
Note that a condition itself is an action that may have structure. The result must be a boolean value and there
must be no side effects.
The presence of concurrency and overlapping conditions may lead to nondeterminism. That’s OK.
compositeActions.fm Version 9 December 17, 1999 5:04 pm 53

7 Composite Actions 7.5 Composite Classes
compositeActions.fm Version 9 December 17, 1999 5:04 pm 54

8 Access Actions 8.1 Read Actions
Chapter 8. Access Actions
These actions access values in object memory, that is, in the system state. The include actions to read and write
attributes and links. Any of these actions may cause a conflict, therefore they must often be explicitly sequenced
using control flows to avoid concurrent access on the same memory location.
8.1. Read Actions
Read actions include actions to read attributes and links. The input values identify the object from which to start the
access and model elements to identify the navigation path (attribute or association end). If the multiplicity of the target
location is many, a read action will produce a collection as its output.
8.2. Write Actions
Write actions include actions to write attributes and links. The input values identify the object from which to start the
access and model elements to identify the navigation path (attribute or association end), as well as the value to be
stored in the target location. There are no output values of a write action. If the multiplicity of the target location is
many, a write action will produce a change (add an element or delete an element) to a collection of values.
8.3. Access Classes
The following metamodel shows the access classes.
InputPin
0..1 +index
ReadAssociationAction
+feature 1
AssociationEnd
+sourceObject
1
ReadAction
Attribute
{1 result}
ReadAttributeAction
+feature 1
Action
WriteAction
WriteAssociationAction
AssociationEnd
Figure 15. Access classes metamodel
+targetObject
1
+source
InputPin
1
WriteAttributeAction
1 +feature
1 +feature
Attribute
accessActions.fm Version 9 December 17, 1999 5:04 pm 55
0..1
+index

8 Access Actions 8.3 Access Classes
ReadAssociationAction
Output: Value
Parameters: sourceObject: Object, feature:AssociationEnd, index:Value
Constraints: The association (and index, if present) must be compatible with the declared type of the object. The
association must be binary.
The value associated with the source object across the link to the given association end is read and becomes the
result. The read is subject to conflict.
Semantics
Precondition: T.status = ready; P.index is empty
Postcondition: A.resultValue[result]' = getlink (A.resultValue[P.object], P.feature); T.status' = complete
where getlink (objectptr, associationEnd) means the value or collection of values (depending on multiplicity)
associated with the given object across to the given end of the association
Precondition: T.status = ready, P.index is not empty
Postcondition: A.resultValue[result]’ = select (A.resultValue[P.object], P.feature, P.index); T.status' = complete
where select (objectptr, associationEnd, index) means the value selected by the index value as a qualifier with the
collection of values associated with the given object across to the given end of the qualified association
ReadAttributeAction
Output: Value
Parameters: sourceObject: Object, feature:Attribute, index:Value
Constraints: The attribute (and index, if present) must be compatible with the declared type of the object.
The value in the specified attribute of the source object is read and becomes the result. The read is subject to conflict.
Semantics
Precondition: T.status = ready; P.index is empty
Postcondition: A.resultValue[P.result]' = getattr (A.resultValue [P.sourceObject], P.feature); T.status' = complete
where getattr (objectptr, attribute) means to get the value of the named attribute within the object
Precondition: T.status = ready; P.source: AttributeNavigation, P.index is not empty
Postcondition: A.resultValue[result]’ = index (A.resultValue[P.sourceObject], P.feature, P.index); T.status' = ready
where index (objectptr, name, index) means to get the value of the given element of the list of values of the
named attribute in the object
WriteAssociationAction
Output: none
Parameters: source: Value, targetObject: Object, feature: (AssociationEnd or Attribute), index: Value
Constraints: The navigation must be compatible with the declared type of the object and the source value type must
be compatible with the type of the association end (may be a scalar value or a collection, depending on multiplicity)
The source value is stored as the value of the given link.
accessActions.fm Version 9 December 17, 1999 5:04 pm 56

8 Access Actions 8.3 Access Classes
Note that there may be secondary effects to keep the multiplicity consistent if an association with non-unlimited
multiplicity is updated.
Semantics
Precondition: T.status = ready, P.index is empty
Postcondition: getlink (A.resultValue[P.targetObject], P.feature)' = A.resultValue[P.source]
where getlink (objectptr, associationEnd) means the value or collection of values (depending on multiplicity)
associated with the given object across to the given end of the association
and other links of the association are deleted as necessary to keep the multiplicities correct
Precondition: T.status = ready, P.index is not empty
Postcondition: select (A.resultValue[P.targetObject], P.feature, A.resultValue[P.index])' = A.resultValue[P.source]
where select (objectptr, associationEnd, index) means the value selected by the index value as a qualifier with the
collection of values associated with the given object across to the given end of the qualified association
and other links of the association are deleted as necessary to keep the multiplicities correct
This action must be reconciled with the manipulation actions that operate on links.
WriteAttributeAction
Output: none
Parameters: source: Value, targetObject: Object, feature: Attribute, index: Value
Constraints: The navigation must be compatible with the declared type of the object and the source value type must
be compatible with the attribute type
The source value is stored as the value of the given attribute.
Semantics
Precondition: T.status = ready; P.index is empty
Postcondition: getattr (A.resultValue[P.targetObject], P.feature)' = A.resultValue[P.source]; T.status' = complete
where getattr (objectptr, attribute) means the value of the named attribute within the object
Precondition: T.status = ready, P.index is not empty
Postcondition: index (A.resultValue[P.targetObject], P.feature, A.resultValue[P.index])' = A.resultValue[P.source]
where index (objectptr, attribute, index) means the value of the given element of the list of values of the named
attribute in the object
accessActions.fm Version 9 December 17, 1999 5:04 pm 57

8 Access Actions 8.3 Access Classes
accessActions.fm Version 9 December 17, 1999 5:04 pm 58

9 Manipulation Actions 9.1 Manipulation Classes
Chapter 9. Manipulation Actions
Manipulation actions create and destroy objects and links.
9.1. Manipulation Classes
The following metamodel shows the manipulation classes.
+class
1
CreateObjectAction
Class
{ordered
must match constructor}
Association
0..* +argument
InputPin
+association
1
Action
InputPin
{1 result}
DestroyObjectAction
+target
{ordered
must match association}
{may be wild card}
+end 2..*
LinkEndData
+participant 1
InputPin
{object or set of objects}
{2 results}
CreateLinkAction
FindLinkAction
Figure 16. Manipulation classes metamodel
{1 result}
{1 result}
DestroyLinkAction
manipulationActions.fm Version 9 December 17, 1999 5:04 pm 59
1
{may be wild card}
+qualifier
0..1
ManipulateLinkAction

9 Manipulation Actions 9.1 Manipulation Classes
CreateLinkAction
Output: Link, Status
Parameters: association:Association, end:LinkEndData[2..*]
Constraints: The number of ends must match the rank of the association. The ends must be objects or objects with
qualifier values, and their types must match the association.
If a link of the given association is created with the given list of end values. If a link with that value already
exists, nothing happens.
The status indicates whether a new link was created.
The action can conflict with DestroyLink and FindLink.
If the resultant cardinality would be inconsistent with the declared multiplicity, existing links are destroyed if
necessary to maintain the declared multiplicity. The link always exists after the step.
It is not possible to simply abandon an attempted operation that would violate multiplicity, because cardinality
would have to pass through illegal states to reach a legal value, therefore we cannot have a variant that simply rejects
an attempt to set an incorrect multiplicity. That is why the action repairs inconsistencies in multiplicity.
Discussion
Link manipulation (creation, finding, navigating, editing, destroying) involves
• creating links from the object at either end or as explicit tuples
• multiplicity constraint maintenance: various options
• n-ary links
• changing links, including attributes
• destroying links from either end or as tuples, effect on multiplicity maintenance
Links may be created by specifying the association and a list of object references compatible with the association.
Link attributes are initialized after creation of the link. This is all atomic. The objects are then pointed at the new
link. [This is an opportunity for conflict if another activation attempts to create the same link or a conflicting link.]
It makes no sense to talk about updating the two ends of a link independently, as if they were independent pointers.
The object pointers in a link may not be changed. (Links don’t have identity apart from the list of values they
relate.) In other words, you can’t just move the end of a link to point at a different object. The link must be destroyed
and a new one created. The attribute values in an existing link may be modified without destroying the link, because
the object pointers give identity to the link as a container of attribute values.
This action works from the point of view of the association, whereas WriteAssociation works from the point
of point of an object that participates in the association. Do we need both? Need to reconcile them.
CreateObjectAction
Output: Object
Parameters: class:Class, argument:Value[0..*]
Constraints: The argument values must match the arguments of the constructor of the class. The type of the result is
the class.
Identity for a new object is created, storage for the object of the given class is allocated and its type is set to the
given class. Initial value expressions are evaluated for attributes of the object. The constructor for the class (if any) is
called using the argument values. When initialization is complete, the identity of the new object is returned as the
value of the action.
Discussion
manipulationActions.fm Version 9 December 17, 1999 5:04 pm 60

9 Manipulation Actions 9.1 Manipulation Classes
Creates a new object involving the following tasks, not necessarily all in the same action:
• create a new identity
• allocate storage
• initialize the contents
• create subordinate objects
Return the identity of the new object for storage in a variable. At this point its identity and storage exist. It is an
open question whether it is fully initialized. This may be a user choice in the program.
If it is an active object, then also:
• create a new, empty event queue
• create a root activation
• start a token at the initial statement
• make a create event for the new object using the arguments (this needs to be traded off against just running a constructor)
Creation of a composite requires creation of its parts recursively.
DestroyLinkAction
Output: Status
Parameters: association:Association, end:LinkEndData[2..*]
Constraints: The ends must match the association in number and type.
Any link of the given association whose ends match the values of the end arguments is destroyed. Some of the
end values may be wild cards, which match any corresponding end value in a link. For example, DestroyLink (Works-
For, (Joe, *)) destroys all of the employment links from Joe.
The result indicates how many links were destroyed. (Other status formats are conceivable.)
DestroyObjectAction
Output: None
Parameters: target: Object
Constraints: The target object is destroyed. Any links involving it are destroyed.
Semantic variation point. If the object is a composite in any links, the corresponding parts are destroyed
recursively.
Any token that is blocked doing a watch action on the destroyed object is unblocked.
Discussion
Destroys an existing object involving the following tasks, not necessarily all in the same action:
• destroy subordinate objects
• deallocate storage
• mark the object as dead
• deallocate the identity (some variations will never reuse identity)
• notify requestors of its death
If it is an active object, then also
• stop or wait for execution to cease (there may be semantic variation points as to whether the stop is forced)
• destroy all of its activations
Destruction of an object implies destruction of any composite parts recursively.
Destruction may be a source of conflict if multiple references are outstanding. This should preferably be prevented
by the composition semantics, but it might still be a problem with references.
manipulationActions.fm Version 9 December 17, 1999 5:04 pm 61

9 Manipulation Actions 9.1 Manipulation Classes
FindLinkAction
Output: Set of Link
Parameters: association:Association, end:LinkEndData[2..*]
Constraints: The ends must match the association in number and type.
Returns a set of identity to links that match the list of ends. Some of the end values may be wild cards, which
match any corresponding end value in a link. For example, FindLink (WorksFor, (Joe, *)) finds all of the employment
links from Joe.
The link identity can be navigated to find the participants, qualifier values, or link attribute values.
ManipulateLinkAction (abstract)
Includes various kinds of link manipulation and searching actions.
Output: depends on specific action subclass
Parameters: association:Association, end:LinkEndData[2..*]
The number of LinkEndData values and their structure (with or without qualifiers) must match the structure of
the association. Each end value specifies a link end value to insert in a new link or to search for in an existing link. On
a search, a WildCardValue indicates that any link end value is acceptable as a match, usually resulting in a set of
matching links.
manipulationActions.fm Version 9 December 17, 1999 5:04 pm 62

10 Computation Actions 10.1 Computation Classes
Chapter 10. Computation Actions
These actions transform a set of input values to produce a set of output values.
10.1. Computation Classes
The following metamodel shows the computation classes.
{1..* results}
ApplyFunctionAction
+input 0..*
{ordered}
InputPin
1 +function
PrimitiveFunction
name : Name
definition : Undefined
+inputType 0..* 1..* +resultType
Classifier
Figure 17. Computation classes metamodel
ApplyFunctionAction
Compute a primitive predefined function without side effects.
Output: Value[1..*] (number of results and result types depend on the specific primitive function)
Parameters: function:PrimitiveFunction, input:Value [0..*]
Constraints: The input and result types of the arguments must match the declared types in the primitive function
definition in number and type (subject to normal polymorphism rules).
Description: Applies the primitive function to the input values to yield a result value or values.
There are absolutely no side effects of this action and it therefore cannot conflict with anything. All it does it produce
result values using a mathematical function.
New primitive functions may be defined (outside of UML) as mathematical functions of input values to output
values. All usual primitive operations should be considered as primitive functions, e.g., addition, nand, square root,
finding a substring, Bessel function, etc. A list of defined primitive functions may be supplied as part of a modeling
profile.
computationActions.fm Version 9 December 17, 1999 5:04 pm 63
Action
CodeAction
language : String
encoding : String
NullAction
{1 result}
LiteralValueAction
+value
DataValueIdentity
(from Structure Model)

10 Computation Actions 10.1 Computation Classes
Semantics
Precondition: T.status = ready
Postcondition:
where n is the number of inputs and m is the number of inputs to the function
(for j=1..n) a[j] = A.resultValue [P.input[j]]
(for i=1..m) b[i] = fj (a[1], a[2], ..., a[n])
A.resultValue[P.result[i]]' = b[i]
T.status' = complete
Comment:
The a and b values are temporary identifiers within the semantics expression
The result designators A.resultValue[i] must all be distinct (no aliasing).
The primitive function must define a family of functions fj(x1, x2, ..., xn) whose value types match the argument
and result values.
Note: The literal value action could have been defined as a primitive function (no inputs, one output), but it seems
common enough to provide directly without the bother of defining functions.
Discussion
• multi-input, multi-output, using local variables as parameters
• no effect or access to object state
• arbitrary mathematical functions (not just a few built-in primitives)
• predefined number of parameters
Apply actions are specified as pure functions from a list of input values to a list of output values, both of which
are stored in local variables of an activation. This separates functional computation from data manipulation and flow
of control issues. By necessity, a call on a method cannot be a functional step, as it includes all of these aspects.
We permit arbitrary definition of functions (within reason) rather than defining a primitive language. This seems
the only way to avoid defining yet another programming language or tilting toward an existing programming language.
It may be necessary to define a canonical set of basic functions, however, for ease of interchange (but not
needed for semantics). Functions operate on scalar values, because collections are stored as objects. Therefore there
are no functions on collections (but operations on collections can be constructed as actions at a higher level out of
functional pieces).
Functions have no effect on and may not access object state.
Semantic variation point. Stuck function: whether a function may fail to terminate and require interruption. At a
first glance, we would expect primitive functions to always complete, but this may not be true.
Functions may raise exceptions which trigger the exception mechanism. These must be predefined as part of their
range of results (need to add to operations, methods, and primitive functions.
CodeAction
Output: none
Parameters: language:String, encoding:String
Constraints: The constraints and effects of this statement are implementation dependent. They must be defined by the
particular implementation, and they provide an opportunity to tailor the semantics.
Semantics
Cannot be defined in UML. Must be defined by the extender.
computationActions.fm Version 9 December 17, 1999 5:04 pm 64

10 Computation Actions 10.1 Computation Classes
Precondition: T.status = ready
Postcondition: T.status' = complete
Other changes as specified by the implementation-specific code
LiteralValueAction
Output: DataValueIdentity
Parameters: value: DataValueIdentity
Generates a literal value. The value can be of any pure data type.
Precondition: T.status = ready
Postcondition: T.status = complete; A.resultValue[P.result[1]]' = P.value
NullAction
Output: none
Parameters:
There is no effect of executing this action.
precondition: T.status = ready
postcondition: T.status' = complete
computationActions.fm Version 9 December 17, 1999 5:04 pm 65

10 Computation Actions 10.1 Computation Classes
computationActions.fm Version 9 December 17, 1999 5:04 pm 66

11 Interaction Actions 11.1 Interaction Classes
These actions cause interactions among objects.
11.1. Interaction Classes
Chapter 11. Interaction Actions
The following metamodel shows the interaction classes.
InputPin
SpawnAction
{0 result}
{ordered}
+input
0..*
1 +targetObject
InvocationAction
CallAction
{0..* results}
TerminateAction
Action
SendAction
+argument 0..*
+target
1
{object set}
{must match signal}
InputPin
Figure 18. Interaction classes metamodel
+signal
Signal
interactionActions.fm Version 9 December 17, 1999 5:04 pm 67
1
WatchAction
{object set}
1 +target
InputPin

11 Interaction Actions 11.1 Interaction Classes
CallAction
Call an operation.
Output: Value[0..*]
Parameters: targetObject: Object, operation: Operation, input: Value [0..*]
Constraints: The number and types of argument and return values must match the number and types of the declared
parameters of the operation. Normal polymorphism rules apply. The operation must be defined for the declared class
of the target argument.
Description: The current token is set to executing status and a new activation is created whose hostPtr is the target
object, whose local variables are copied from the arguments (with names from the operation declaration), and whose
token is set to the start of the method found by searching the operation in the actual class of the target object. When
the execution of the created activation terminates, the return values (if any) are copied back to the result values and
the current token is set to active states and advanced to the next statement.
Semantics
Precondition: T.status = ready
Precondition:
new AA: Activation
new U: Token
T.status' = executing
T.dependent' = T.dependent + AA — addition of an element to a set
AA.caller = T
AA.host = A.resultValue [P.targetObject]
AA.token = Set {U}
AA.resultValue = empty table
AA.name = empty table
(for i=1..n) AA.parameter[P.operation.parameter[i].name] = A.resultValue [P.input[i]]
{ need to handle default parameters, but they are just a kind of sugaring, also initialize return parameters }
U.status = ready
program: Action = method-lookup (AA.host, P.operation)
U.actionPtr = program
Comment: operation.parameter[i] represents the i’th parameter designated as an input parameter. We assume that all
parameters are input or return parameters. We ignore out and in-out parameters and treat them as programminglanguage
sugarings, and we propose that they be removed from core UML.
macro method-lookup (object: Object, operation: Operation)
let found-methods = empty set
let C-set =object.class (the type of the actual runtime object, a set of classes)
let c-all = the classes in C-set together with all of their ancestor classes
for each class C in C-all, if operation has a matching method in C,
add the method to found-methods
eliminate any method whose class is an ancestor of another method in found-methods
if there is exactly only method in the set, it is the target method
interactionActions.fm Version 9 December 17, 1999 5:04 pm 68

11 Interaction Actions 11.1 Interaction Classes
if there are no methods in the set, there is an error (method not found)
if there are two or more methods in the set, there is a conflict error
MUST WRITE SEMANTICS FOR CALL EVENTS AND THEIR RETURNS
Call return (implicit action)
U.status = complete; AA.token = {U} — U is the only remaining token in the activation
T = AA.caller
Postcondition:
destroy AA' and all its contents (values and tokens)
T.dependent' = T.dependent - AA — set subtraction
(for i=1..n) T.activation.resultValue [T.actionPtr.result[i]]' = AA.parameter[T.actionPtr.operation.parameter
[ret(i)]], where ret(i) denotes the index of the i’th return parameter within the operation’s parameters
T.status' = complete
Comment: This is the implicit action at the conclusion of a normal call.
Precondition:
U.status = complete; AA.token = {U} — U is the only remaining token in the activation
AA.caller = null — root activation
Postcondition:
destroy AA' and all its contents (values and tokens)
Comment: This is the cleanup for a spawned activation.
Discussion
A call creates a new activation with a return pointer to the calling activation and blocks the calling token (it waits for
the completion of the called activation). The new activation receives the list of arguments specified in the call as its
parameter values and its host object pointer is set to the target object. A token is created with its action pointer set to
the enclosing action for the method. Usually this action is a composite set action that includes the individual actions
that compose the method.
If the called operation is marked for a call event, then a signal is sent to the target object instead of creating a new
activation. The signal has a return pointer to the calling activation, which is still blocked.
Completion of the called activation terminates and destroys the current activation and completes the calling
action. Similarly, completion of the action (including a null action) on the transition triggered by a call event, or the
failure to trigger any transition after handling a call event, sends a return packet to the calling activation.
InterruptAction
Output: none
Parameters: target: ActionResult(ActiveObject), exception:Exception, argument:ActionResult[0..*]
Constraints: The list of argument values must be compatible with the exception.
An interrupt is transmitted to the active object (this may take time). When it is received, each active token of the
active object performs the exception after completing any step in progress. The exception is handled as if it had been
raised internally.
Discussion
interactionActions.fm Version 9 December 17, 1999 5:04 pm 69

11 Interaction Actions 11.1 Interaction Classes
Causes the exception to occur in the activation(s) of the active object with the given arguments. This can be used to
ask an active object to die but give it a chance to clean up properly (“soft kill”).
RaiseAction
Output: none
Parameters: exception:Exception, argument: ActionResult[*]
Constraints: The argument types and number must be compatible with the exception.
An instance of the exception with the given values occurs for the token. If the innermost action being executed has a
handler for the exception, the token sets its program pointer to the handler and continues. Otherwise control passes to
the end of the current action and the exception is handled by the next control action, until some action handles the
exception or the outermost action is reached, which destroys the active object.
An unhandled exception within a concurrent action set causes termination of concurrent activity.
Poorly designed exceptions can obviously cause a lot of trouble, so they should be used with care.
Discussion
Exceptions are implicit actions that are performed during synchronous computation when some condition is met. This
is usually deemed to be an “error” condition, often one that would prevent the normal action from being completed,
so the exception effectively permits defining the action for all its input values. Exceptions are synchronous with the
actions that cause them and cannot conflict with them. They are not signals. They can also be raised explicitly by an
action and can be caused externally by an interrupt action.
An exception is handled by terminating the current action and taking the exception handler clause matching the
given exception. If there is no exception handler clause matching the given exception, control passes to enclosing
actions until one is found to handle the exception. This could force the killing of concurrent tokens if an action set
contains them. If control reaches the top action without finding a handler, the activation terminates and the exception
propagates to the caller until it is handled.
SendAction
Output: none
Parameters: target: ActionResult(Set of Object), signal:Signal, argument: ActionResult[*]
Constraints: The number and types of arguments must be compatible with the signal.
A signal is created and initialized with the given values and sent to each object in the target set. A separate copy of the
signal is sent to each object. There are no guarantees about transmission time, and it may vary for objects in the target
set.
Semantics
next T'
(for j=1..n) some time later, separately for each j:
Heap[target[j]].eventQueue.eventInstance' contains E[j],
where E[j] is an SignalInstance that is an instance of signal,
E[j].(T.signal.parameter[i].name) = T.argument[i]
Discussion
Forms a signal packet and transmits it to the target active object. When the packet arrives at the target active object, it
is added to the event queue.
interactionActions.fm Version 9 December 17, 1999 5:04 pm 70

11 Interaction Actions 11.1 Interaction Classes
Signal (from core)
A class of information communicated asynchronously as a unit from an object to an active object. A signal has a set
of attributes, which can equivalently be interpreted as a list of parameters. The receipt of a signal by an active object
is an event that is added to its event queue. The communication of signals among objects may take time.
SpawnAction
Output: none
Parameters: targetObject: Object, operation: Operation, input: Value [0..*]
Constraints: The number and types of argument and return values must match the number and types of the declared
parameters of the operation. Normal polymorphism rules apply. The operation must be defined for the declared class
of the target argument.
Description: A new activation is created whose hostPtr is the target object, whose local variables are copied from the
arguments (with names from the operation declaration), and whose token is set to the start of the method found by
searching the operation in the actual class of the target object. The calling token continues with its execution. When
the execution of the created activation terminates, it is simply destroyed; no return values are transmitted.
Semantics
Precondition: T.status = ready
Precondition:
new AA: Activation
new U: Token
T.status' = ready
AA.caller = null
AA.host = A.resultValue [P.targetObject]
AA.token = Set {U}
AA.resultValue = empty table
AA.name = empty table
(for i=1..n) AA.parameter[P.operation.parameter[i].name] = A.resultValue [P.input[i]]
{ need to handle default parameters, but they are just a kind of sugaring, also initialize return parameters }
U.status = ready
program: Action = method-lookup (AA.host, P.operation)
U.actionPtr = program
Comment: operation.parameter[i] represents the i’th parameter designated as an input parameter. We assume that all
parameters are input or return parameters. We ignore out and in-out parameters and treat them as programminglanguage
sugarings, and we propose that they be removed from core UML.
TerminateAction
Output: none
Parameters:
The current active object dies.
interactionActions.fm Version 9 December 17, 1999 5:04 pm 71

11 Interaction Actions 11.1 Interaction Classes
Discussion
A terminate (i.e., suicide) is mostly easily done by the root activation running off the end, but probably a lower-lever
activation might be able to terminate the active object—or maybe this is not necessary. On termination (suicide or
murder), a signal is sent to those other threads who have requested notification.
Knowledge of an active object is equivalent to having a link to it, so the issue of dangling active objects is the
same as the issue of dangling pointers. There is the possibility of conflict.
WatchAction
Output: none
Parameters: target: ActionResult(Object)
The token blocks until the target object dies.
Discussion
The caller is added to the list of active objects that will resume when the target active object dies.
Other kinds of notification might make sense at the engineering level, such as time-outs, etc.
interactionActions.fm Version 9 December 17, 1999 5:04 pm 72

12 Primitive Communication Actions 12.1 Primitive Communication Classes
Chapter 12. Primitive Communication Actions
These actions support low-level communication among tokens without the large mechanisms needed to support active
objects. These actions are intended to permit defining more complicated actions, such as state machine execution and
interobject signal sending, without having to impose the complexities of those more complicated actions on the base
execution machinery. These actions may also be useful directly in real-time work and other cases.
12.1. Primitive Communication Classes
The following metamodel shows the primitive communication classes.
+argument 0..*
NotifyAction
Output: none
InputPin
NotifyAction
+signal 1
Signal
Action
WaitAction PollAction
Figure 19. Primitive communication classes metamodel
Parameters: queue:SimpleQueue, signal:Signal, argument: ActionResult[0..*]
Constraints: The number and types of arguments must be compatible with the signal.
A signal instance is created and initialized with the given values and added to the queue. The location where the
signal instance is inserted in the queue may be specified by a subclass of SimpleQueue, but in the general case it is
unspecified and no assumptions should be made. However, the queue maintains the order of events added to it. A
first-in first-out policy is consistent with these rules.
The action may take time, but the signal instance will be on the queue when the action completes. In particular, a
subsequent DequeueAction will find the event unless it has been subsequently removed from the queue.
primitiveCommunication.fm Version 9 December 17, 1999 5:04 pm 73

12 Primitive Communication Actions 12.1 Primitive Communication Classes
More than one token may attempt to notify the same queue, and all of them will succeed, but the relative order in
which they are added is indeterminate. A queue serializes notify actions. It is a synchronizer.
Semantics
Precondition: T.status = ready
Postcondition: T.status' = completed
P.queue.event' = P.queue.event + instantiate (signal, argument)
where instantiate creates and initializes a new object of the given class and constructor values.
PollAction
Output: Event
Parameters: queue: SimpleQueue
Takes an event from the queue and make it the result, if the queue contains at least one event, otherwise produces
the null value as the result. The event is removed from the queue. This action always completes immediately without
waiting for a new event to arrive.
Precondition: T.status = ready; there exists e:Event in queue.event
Postcondition: T.status = complete; queue.event' = queue.event - e; result = e
Precondition: T.status = ready; queue.event is empty
Postcondition: T.status = complete; result = null
WaitAction
Output: Event
Parameters: queue: SimpleQueue
Takes an event from the queue, if it contains at least one, otherwise waits until the queue receives an event and
then takes it. The event is removed from the queue.
Only one wait action may be outstanding at a time. A second wait action is an error to be handled in an implementation-specified
manner (such as causing an exception).
Precondition: T.status = ready; there exists e:Event in queue.event
Postcondition: T.status = complete; queue.event' = queue.event - e; result = e
Precondition: T.status = ready; queue.event is empty
Postcondition: T.status' = executing
Comment: For this action, status executing means that it is waiting for an event.
Precondition: T.status = executing; there exists e:Event in queue.event
Postcondition: T.status' = complete; queue.event' = queue.event(at time t) - e; result = e
Precondition: T.status = ready; queue.waiter is nonempty
Postcondition: ill-formed model error
primitiveCommunication.fm Version 9 December 17, 1999 5:04 pm 74

13 Exception Actions 13.1 Exception and Interrupt Handling Classes
Chapter 13. Exception Actions
These actions invoke the exception and interrupt handling mechanisms.
13.1. Exception and Interrupt Handling Classes
The following metamodel shows the exception and interrupt handling classes.
{ActiveObject}
+target 1
InterruptAction
0..*
InputPin
0..1
+argument
+interrupt
1
exception : Exception
Interrupt
Signal
Action
+exceptionHandler
Exception
Figure 20. Exception and interrupt handling classes
ExceptionAction (implicit)
An exception occurs when some exception condition stated in the description of an action occurs. The exception contains
a list of values describing the nature of the occurrence. The execution of the action is aborted and the exceptionhandling
mechanism is invoked.
InterruptAction
An action can send an interrupt to an active object. The interrupt action includes an exception as a parameter. When
the interrupt is received, the active object raises the given exception in each of its active tokens. The exception occurs
between steps. {Perhaps interrupts might need levels of atomicity, so that they occur at clean times, but that is a
detail.] Each activation then has the opportunity to finish up and exit cleanly, even if it is executing a run-to-completion
step (the interrupt breaks into the RTC step). If the exception is not handled, it propagates to a higher level as
with other exceptions. If it reaches the outer level, the thread dies.
exceptionActions.fm Version 9 December 17, 1999 5:04 pm 75
0..1
interrupt : Interrupt
0..1
+interruptHandler
1 +exception
0..1
{ActiveObject}
RaiseAction
+target
1
InputPin
+argument
0..*

13 Exception Actions 13.1 Exception and Interrupt Handling Classes
Implementing interrupts requires dependent pointers so that the interrupt can be propagated downward to all the
leaf activations.
KillAction
An action can kill the active object outright, which cleans up all of its subordinate detail. This is an extreme measure
because it does not execute the cleanup (exit actions, etc.) in the target state machine. When the active object receives
the event, the transition forces exit of inner states and goes to the termination state. This can probably be treated by
using an interrupt with an exception that cannot be handled.
Reflective actions on active objects. It has been suggested that applications need some degree of reflective control on
active objects, such as querying status, setting priorities, suspending or resuming execution, etc. These would seem to
be appropriate actions, but it is unclear how to enumerate them, as they seem somewhat implementation-dependent.
Probably they are part of an implementation and do not belong in the core execution semantics.
RaiseAction
An action that explicitly raises an exception in the current action. The normal exception-handling mechanism is
invoked.
exceptionActions.fm Version 9 December 17, 1999 5:04 pm 76

IV Appendices
Part IV. Appendices
part-appendices.fm Version 9 December 17, 1999 5:04 pm 77

IV Appendices
part-appendices.fm Version 9 December 17, 1999 5:04 pm 78

A Examples of Program Specifications
Appendix A. Examples of Program Specifications
This chapter contains examples illustrating the use of actions in sample models.
programExamples.fm Version 9 December 17, 1999 5:04 pm 79

A Examples of Program Specifications
programExamples.fm Version 9 December 17, 1999 5:04 pm 80

A
Activation 19
activation 17
E
execution instance model 7
L
link 7, 8, 56
Index
Action SemanticsIX.fm Version 9 December 17, 1999 5:09 pm 81

Action SemanticsIX.fm Version 9 December 17, 1999 5:09 pm 82