the semantics of an activity diagram in UML 1.4. UML 2.0, under development at the time of writing, will not adopt this constraint, as it will define the semantics of activity diagrams independently from statecharts. We too have not adopted such a constraint, as it restricts the concurrency (parallelism) that can be expressed in an activity diagram (see Section 9.1).
3.2
Activity hypergraphs
In the previous section (page 27), we saw that a compound edge corresponds closely to a hyperedge. Thus, we can model an activity diagram with its compound edges as a hypergraph: a graph with hyperedges instead of edges. In this section, we define such a hypergraph structure, called an activity hypergraph. This structure is not defined in the UML standard. The activity hypergraph is the syntactic structure for which we will define two execution semantics. Figure 3.6 shows the activity hypergraph that underlies the activity diagram in Figure 1.1. Section 3.3 explains how an activity diagram maps into an activity hypergraph.
Receive order Check stock Send bill Ship order Check customer Make pro−
duction plan Produce
[not insufficient stock] [insufficient stock] WAIT−3 Handle payment receive payment Fill order WAIT−2 WAIT−1 WAIT−4 WAIT−5 [payment ok] [not customer ok]
[customer ok]
[customer ok & insufficient stock]
[not customer ok] [customer ok & not insufficient stock]
[not payment ok] Notify
customer
Send reminder after(2 weeks)
32 Chapter 3· Syntax of activity diagrams
Syntax of activity hypergraphs. We assume there is a set of activities Activities and a set of events Events. Set NamedInternalEvents is defined below; it is a subset of Events.
An activity hypergraph is a tuple (Nodes, Events, Guards, HyperEdges, LVar) where:
• Nodes is the set of nodes,
• Events is the set of event expressions, • Guards is the set of guard expressions,
• HyperEdges is the transition relation between the nodes of the activity dia- gram,
• LVar the set of local variables. Every variable in a guard expression is a local variable.
We now discuss these elements in more detail. Set Nodes is partitioned into set AN of activity nodes, set WN of wait nodes, set FN of final nodes, and one initial node initial . Every activity node has an associated activity, denoted by the function act : AN Activities, that is enabled upon entry of the node. In
Section 3.4 we discuss how activities can be specified. To distinguish between an activity and an activity node, activities are written in italic whereas activity nodes are written in sans serif. We use the convention that in the activity diagram, an activity node a is labelled with the (name of the) activity act (a) it controls. So we have for example act (Check stock) = Check stock . Note that different activity nodes may have the same label, since they may enable the same activity. Wait nodes are labelled WAIT with an additional number for ease of reference.
Set Events is partitioned as follows. There are several kinds of events: named external events, named internal events, condition change events, termination events, and temporal events (cf. Section 2.4). These event types are mutually exclusive: an event has only one type. We partition set Events in six subsets:
NamedExternalEvents, NamedInternalEvents, ConditionChangeEvents, TerminationEvents, WhenEvents and AfterEvents. Sets WhenEvents and AfterEvents together comprise the set of temporal events. Note that an event in WhenEvents is a temporal event, not a condition change event.
A termination event denotes that a certain activity node has terminated. By function act , the termination event indirectly also denotes which activity has ter- minated. The bijective function term defines for each termination event the ac- tivity node that has terminated.
term : TerminationEventsAN
A termination event refers to an activity node and not directly to a terminated activity for the following reason. An activity can belong to more than one activity
3.2· Activity hypergraphs 33 node, i.e., more than one activity node can enable the same activity. So, more than one instance of the same activity can be active at the same time. Then if one activity instance completes, only knowing which activity terminates does not provide enough information to decide which node should be left.
As explained in Section 2.4, events can be either external or internal, but not both. Whether an event is external or internal depends upon its type. Named events can be either external or internal. Condition change events and termination events are always external. Temporal events are a special case: they could be considered either as external or internal. We consider them as external here.
We also explained in Section 2.4 that an event can either be broadcast, trigger- ing possibly more than one compound edge, or point-to-point, triggering at most one compound edge. Function sendtype : Events{bc, p2p} specifies for each
event whether it is broadcast or point-to-point.
Every activity termination event is point-to-point, since it denotes completion of one instance of an activity node. Every timeout event (after) is point-to-point, since the timeout is generated some finite amount of time after the corresponding compound edge became relevant. Every global temporal event (when) is broad- cast. Named events and condition change events can be either point-to-point or broadcast. In this thesis, we use the convention, however, that they are broadcast. This convention is also adopted in UML.
Table 3.1 summarises the kind of events and their properties. Completion events denote completion of a wait node. They are only needed in the implemen- tation-level semantics, which we define in Section 5.4. For a motivation why they are needed, see Section 5.4. Although completion events are not used in the syntax of activity hypergraphs, for the sake of completeness, we have included them here. Set Guards is the set of all boolean expressions on set LVar , using boolean connectors ∧, ∨, ¬ . Special guard expression is in(name), which is true if and only if the system is in node name.
Hyperedges have several parameters. For every hyperedge h ∈ HyperEdges, source(h) is a non-empty set of source nodes, from which the hyperedge h departs. The source nodes are left if h is taken. Symmetrically, target (h) is a non-empty
Event type external internal broadcast point-to-point
named x x x (x) condition change x x (x) termination x x when (temporal) x x after x x completion x x (x)
Table 3.1 Event properties. An entry ‘(x)’ is possible, but not considered in this
34 Chapter 3· Syntax of activity diagrams set of target nodes, which are entered if the hyperedge h is taken.
Like every edge in an activity diagram, every hyperedge h in an activity hyper- graph is labelled with an ECA rule. The trigger event of h is denoted by event (h). Below, we will put the constraint that a hyperedge cannot be triggered by more than one event. Thus, a hyperedge has either no trigger event or only one trigger event. We use symbol ⊥ as a special event label to denote that a hyperedge has no trigger event. So event (h)∈ Events ∪ {⊥}.
Every hyperedge h has a guard expression (possibly [true]), denoted guard (h). Guard expression guard (h) should be valid, i.e. guard (h)∈ Guards.
Moreover, every hyperedge h has an action expression. The only action expres- sions we allow in hyperedges are sets of send event actions; other action expres- sions would change the case attributes, which is undesirable, as case attributes are changed in activities. Given a hyperedge h, the set of events generated by taking h is denoted sendactions(h). Every hyperedge h can only generate named internal events: sendactions(h)⊆ NamedInternalEvents.
Local variables in LVar represent the case attributes. As explained on page 16, case attributes represent control data.
Note. In the remainder of this thesis, we will use the term ‘activity diagram’ when we actually mean an activity hypergraph. And we will show activity dia- grams when we actually intend to show activity hypergraphs. This is not harmful, however, as each activity diagram maps into a unique activity hypergraph (see Section 3.3).
Constraints on activity hypergraphs.
1. For every hyperedge h that has activity node a as source, a is the only source of h. Consequently, if a hyperedge has more than one source, none of its sources is an activity node.
∀ h ∈ HyperEdges ∀ a ∈ AN • a ∈ source(h) ⇒ source(h) = {a} We motivated this constraint already on page 28.
2. Every hyperedge that leaves an activity node is labelled with a corresponding activity termination event.
∀ h ∈ HyperEdges ∀ a ∈ AN • a ∈ source(h) ⇒
( event (h)∈ TerminationEvents ∧ term(event(e)) = a ) 3. The initial node is only part of the sources of a hyperedge. Moreover, if it is
source of a hyperedge, it is the only source of that hyperedge. ∀ h ∈ HyperEdges • initial ∈ target(h)
3.3· From activity diagram to activity hypergraph 35