Towards a Petri-net Semantics of Data Flow in

Towards a Petri-net Semantics of Data Flow in UML 2.0 Activities Harald St¨orrle IFI-PST, Universit¨ at M¨ unchen, Oettingenstr. 67, 80538 M¨ unchen, Germany [email protected]

Abstract The Unified Modeling Language (UML) is the de facto standard for modeling software. Currently, the UML is moving from version 1.5 to version 2.0. There are many improvements in this new version, and one of the biggest is the reengineering of activity diagrams. Activity diagrams have an extremely rich syntax, providing notations for sequencing, branching, concurrency, exceptions, procedure calling, various control structures, data flow, stream processing, and bulk data processing. This paper examines the data flow aspect of activity diagrams as described in the UML 2.0, defines a simplified syntactical “normal form” that removes all syntactic sugar, defines a semantics in terms of Colored Petri-Nets (CPN) for this core language, and validates the mapping using a standard Petri-net tool. The paper also exhibits a number of shortcomings in the standard, and opens the road formally analysing activity diagrams. This paper is an extended, corrected, and improved version of [43,47]. It also builds on previous work on other aspects of activity diagrams by the author (cf. [44–46,48,49]). Key words: UML 2.0, activity diagrams, data flow, Colored Petri-Nets, formal analysis, traverse to completion

1

1.1

Introduction

Motivation and goal

Modeling of business processes and workflows is an important area in software engineering, and, given that it typically occurs very early in a project, it is one of those areas where model driven approaches definitely have a competitive edge over code driven approaches. Activity diagrams have been introduced into the UML to cover these application areas: it may be used as a workflow

Preprint submitted to Elsevier Science

12 December 2004

definition language, but it is also the natural choice when it comes to modeling web services, and plays an important role in specifying system level behaviors. The UML has become the “lingua franca of software engineering”, and it has recently undergone a major revision (advancing from version 1.5 to version 2.0), including a complete redefinition of Activities. Unfortunately, the standard has yet again failed to define a formal semantics, as would be necessary to take full advantage of the UML, e.g., in automated tools. Compared to UML 1.5, the concrete syntax of basic control flow has remained mostly the same in UML 2.0. Everything else, however, has been rewritten from scratch. The changes affect most of the concrete syntax, all of the abstract syntax, and, particularly, the semantics: while in UML 1.5, activity diagrams have been defined as a kind of State Machine Diagrams (ActivityGraph used to be a subclass of StateMachine in the UML metamodel), there is now no such connection between the two: “Activity replaces ActivityGraph in UML 1.5.” (cf. [34, p. 292]). The standard claims that “Activities are redesigned to use a Petri-like semantics instead of state machines” (cf. [34, p. 292]). However, no formal definition of the semantics is provided by the standard. In many cases, there are not even adequate examples. Thus, many ambiguities arise, and even serious problems, as the OMG issues database witnesses (cf. [35]). A discussion of some of the most blatant problems is found in [49]. Thus, this paper sets out to explore the meaning of activity diagrams using Petri-nets. The goal of this article is to better understand the standard, and lay the foundation for practical applications using semantic-based tools.

1.2

Approach

This article focuses on the data-flow aspect, since it is instrumental for practical applications. First, the concrete syntax of (data flow in) activity diagrams is reviewed, separating some notations that may be considered as syntactic sugar, and thus identifying a kind of “normal form” for activity diagrams (section 2). Some ambiguities show up on this level already, and some pragmatic choices are required to proceed with this investigation. Second, a semantic mapping for the abstract syntax representation of this fragment of the activity diagram language is defined. Obviously, this needs to include the mapping for basic control flow as introduced in [44], adding some corrections and generalizations. Some fundamental questions concerning the appropriateness of Petri-nets as the semantic domain are only skirted (see [49] for a detailed discussion).

Then, in section 4 the CPN Toolset (cf. [14]) is used to validate the results of the semantic mapping. It is currently not possible to apply this approach to practical case studies, as this would require an automatic translation from activity diagrams into Petri-nets. Unfortunately, however, there are no UML 2.0 tools available yet (despite the marketing claims of some vendors), in particular, none that support activity diagrams. In section 5, this investigation is summarized and the results are discussed, including an extensive review of related work. I conclude that while it is possible to provide a reasonable interpretation for a substantial part of data-flow in UML 2.0 activity diagrams, some questions remain unanswered, and some others emerge.

2

2.1

Activity diagrams in UML 2.0

Running example

Activity diagrams are best explained by means of an example. Our running example (see Figure 1) is taken from the standard itself (see [34, Fig. 205, p. 292]) and slightly adapted. It is also arguably the case, that the problem in question should be modeled in a different way, but for the sake of argument, we will stick to this example, mainly because it is the one used throughout the standard. The example consists of two diagrams, a class diagram (left) and an activity diagram (right). Note, that the class Order has a third compartment that contains a reference to the activity diagram OrderProcessing. This way, the class diagram sets the necessary context for the activity diagram, providing us with an inscription language for the activity diagram (see Section 2.3 for more on contexts). This is omitted in the standard. The behavior of OrderProcessing is intended to be like this. First, an order is received by the action receive order. The diamond-shape represents a decision node. The expression with square brackets on the first branch asserts that if this branch is taken, the context is in state accepted. Note that guards like this may, but need not correspond to attributes of the context. Next, the action fill order is executed, the behavior in curly brackets is invoked, and a fork (the first black bar) is reached. The fork splits the path of control flow into two. 1 On the left path, the actions produce goods and ship goods are executed. On the right 1

It is currently undefined by the standard what happens to data tokens here, but it is reasonable to assume that an identical copy is made for each branch.

CD OrderExample Order filled: Bool billed: Bool paid: Bool shipped: Bool goods: Good same (Order): Bool init (Int): Order join (Order, Order): Order pay(): void bundle(Good collection): void

AD OrderProcessing {reject}

receive order

[accepted] fill order {fill = true}

produce goods

ship goods

send invoice receive payment {pay()}

AD OrderProcessing close order

Fig. 1. An introductory specification consisting of a class diagram (left), and an activity diagram (right). The icon in the third compartment of class Order is a reference to the Activity specified in diagram OrderProcessing.

path, the actions send invoice and receive payment are executed. After receive payment, the behavior pay() is invoked. Both paths are pursued concurrently. When they have both completed their execution, the join (the other black bar) may take place, and the action close order is executed. Returning to the decision node above (after receive order), its second branch invokes the behavior reject. Note, that this behavior is not specified by the context.

2.2

Defining a normal form

The concrete syntax of activity diagrams is changed only slightly with respect to control flow, but has some interesting (and problematic) difference with respect to data flow. One notable extension is the flexibility now provided by Partitions 2 (“swim lanes” in UML 1.x), which are close to simulating a kind of use case maps in UML 2.0 (cf. [13]). It does not influence the behavior of an Activity, however, and may thus be ignored here. SubactivityStates have vanished, and nesting is now accomplished by calling subordinate Activities from the Actions that define the behavior of superordinate Activities. Data flow is now expressed using ObjectNodes and ObjectFlows. 2

All terms written with an initial capital are UML metaclasses, i.e., specific concepts of the UML. They are discussed in section 2.3.

The specification of Figure 1 is only an intuitive example, not a complete one. It is perfectly “legal” UML, though, since the UML declares many elements as optional. This kind of specification involves a great deal of tacit knowledge which is no problem for a human user—but a semantics-based tool like a model compiler would probably reject it, or at least warn the user that the system is highly underspecified. Also, activity diagrams are a very rich notation with many different ways to express the same thing, and also a number of poorly specified or ambiguous constructs. With these two facts about the UML, it is difficult to define a coherent semantics for activity diagrams. So, as a first step towards a semantics, the essential constructs to which all other notations may be mapped are identified. In other words, the syntactic sugar and the ambiguities are removed to yield a kind of “normal form”.

2.2.1

Uniform notation

The standard allows three alternative notations for data flows. Figure 2 (left) shows the notation defined in UML 1.x, and the three variants defined in UML 2.0.

{effect}

Type

Type

{effect}

UML 1.x notation

traditional notation

{effect}

Type

{effect}

Type {effect}

attached notation

{effect}

Type

pin notation

Fig. 2. Concrete syntax for data flows: UML 1.5 notation (left); same diagram in UML 2.0 using the three alternative notations.

traditional notation The first variant is quite similar to that of UML 1.5: data flows are represented by an ObjectNode that is is linked to Actions by ObjectFlows. The only difference in UML 2.0 is that dashed arrows have been replaced by solid arrows. attachment notation Second, there is a simplified version that allows to “attach” an ObjectNode to an edge, visually speaking. This notation is particularly convenient from a practical point of view since with this notation, it is very easy to first specify control flows and then later to selectively add data flows without changing the control flow.

pin notation The third notation specifies so called Pins (a subclass of ObjectNode) to represent the parameters of an Action. This notation is particularly useful for hierarchical refinement of Actions by Activities (i.e. procedures, see [44] and Figure 3). These three notations are more or less interchangeable, though sometimes this requires Actions to be unfolded into several copies to deal with implicit choice. B A

A

C

B

C

Fig. 3. Pins are ObjectNodes for refinement.

For instance, in a situation as shown in Figure 4, mapping from either the pin or the attached notation into the traditional notation requires to make implicit choice explicit by replacing Action A by two copies (the gray area). This is similar to the traditional unfolding known from Petri-nets, and does not affect expressiveness.

A

A

A1

A2

Fig. 4. The three notations are interchangeable, sometimes requiring unfolding (gray area).

Another example is shown in Figure 5: ParameterSets on some action may be resolved by unfolding the action into several copies, one for each element of the set. For simplicity, we allow only the traditional notation in the normal form.

a

b

a

c

b

b

X2

X1

X

c

Fig. 5. ParameterSets may resolved using unfolding (gray area).

2.2.2

Restrictions

Then, we impose a number of (syntactic) restrictions. The following constructs are disallowed in the normal form. Weights Arc-weights may not be used. This can be compensated by using multiple edges (i.e., like traditionally in Petri-nets). Initial & final nodes There may be no arcs leaving FinalNodes, and no arcs entering InitialNodes. These are just sanity conditions and should really be part of the UML standard. Streaming Streaming is one of the features of UML new to version 2.0. Streaming is currently not very well understood (cf. [46,48]). It is thus omitted in this article. Note that processing collection data is not affected by this restriction. Connectors Connectors serve as a kind of “labeled goto”. They are just a visual notation, and disallowing them does not affect expressiveness. A Similarly, B A and time events B are omitted without negaEvents send, receive, tive effect. a

b

c

a

b

X1

a

b

X2

b

X3

c

b

X4

c

X purpose ofd this Also, for d the article, constructs that e e f have no relation to e all f d e e f data flow are ignored (e.g., partitions, LoopNodes, and so on). The problems associated with the concept of traverse-to-completion (see [8,49]) are not covD C D ered in Cthis article. Finally, all elements must be named with globally unique names.

2.2.3

Inscription language

Activity diagrams may be supplemented by different annotations. However, the standard does not specify a concrete language for inscriptions. In fact, there is not a single example of the concrete syntax, and references to the “action semantics” are scarce. So, there is the freedom to choose a language. With a view to tool-supported validation, we adopt the inscription language used in the CPN Toolset (see [14]), a dialect of Standard ML [25,36]. This way, tool support for case studies and analysis techniques is ensured. Its syntax

is fairly straightforward. The following kinds of inscriptions are mentioned in the standard. ObjectNodes must be inscribed with their type. Optionally, a state may be added in square brackets. This state, however, does not affect the behavior, so it is mere documentation and is omitted in the normal form. JoinNodes may be inscribed by a “join specification” in curly braces. The variables used in the join specification are written next to the incoming edges of the JoinNode. In the normal form, all JoinNodes must have a join specification. Though the standard does not give an example, it is necessary, that the outgoing edges also may be inscribed with variables, so these are added. ActivityEdges may be inscribed by an “output effect” or “input effect” in curly braces, depending on whether they lead to or from ObjectNodes. One of them is sufficient, so we drop input effects. Additional inscriptions (i.e. “selection”and “transformation”-clauses) may be added as comments. Since comments should not affect the semantics, these are ignored. Thus, inscriptions on edges are reduced to output effects.

2.2.4

Completeness

In practical settings, one would rarely fill in all the details of an activity diagram, but expect a human to understand the intuition. Figure 1 is actually an example for this: a human reader would simply gloss over the incomplete and informal annotation. For a formal semantics, however, this can not be tolerated, a semantical mapping requires its inputs to be complete. So, for the purpose of this paper, we assume that no elements are elided, and all elements are defined completely. The semantics defined below translates only those ObjectNodes and ObjectFlows that are actually present in a given diagram. Therefore, no DataFlows may be omitted. Also, for simplicity, we assume that the operations used in the inscriptions of the activity diagram are specified as methods of a class. Completing Figure 1 would thus yield the diagram shown in Figure 6. There, the effect reject is omitted, as it represents human decision, whose effects we chose not to implement in our model: we will be able to make this decision when simulating the net. For the same reason, the guard accepted has gone. Other changes in this diagram will be explained in the next two sections.

AD OrderProcessing CD OrderExample

receive order

{ init() }

Order

Order filled: Bool billed: Bool paid: Bool shipped: Bool goods: Good reject(): void accept(): void same(Order): Bool fill (): void bill (): void pay (): void ship (): void init (Int): Order join (Order): void bundle(Good collection): void AD OrderProcessing

Order

Order fill order { fill() }

Order Order

Order

send invoice { bill() }

ship goods

Order

{ ship() }

Order

receive payment { pay() }

order' { order.same(order') and order.join(order') }

Order order order

Order

{ close() }

close order

Order

Fig. 6. A more diligently specified version of the activity diagram of Figure 1.

2.3

Abstract syntax o:Order

The metamodel for Activities has been redesigned from scratch in UML 2.0. The main concept underlying activity diagrams is now called Activity and “replaces ActivityGraph in UML 1.5.” (cf. [34, p. 292]). Activity is not a subclass of StateMachine any more, but is described in an independent part of the metamodel. See Figure 7 for the portion of the metamodel relevant for activity diagrams. The basic two concepts are Actions and Activities. While an Action “is the fundamental unit of executable functionality” (cf. [34, p. 280]), an Activity provides “the coordinated sequencing of subordinate units whose individual elements are actions” (cf. [34, p. 280]). This coordination is captured as a graph of ActivityNodes connected by ActivityEdges (see Figure 7). Data flow is represented using ObjectNodes and ObjectFlows, which are subclasses of ActivityNodes and ActivityEdges, respectively. For all instances of metaclasses, the

ActivityNode

0..1 0..1

Activity

ActivityNode

guard

call ActivityEdge *incoming outgoing * *

ExecutableNode ObjectNode

ObjectNode

1 source * ActivityNode

ControlNode

inState: State upperBound: ValSpec

target 1

ExecutableNode Action

ActivityEdge

InitialNode FinalNode

TypedElement

DecisionNode

type: Classifier

ObjectFlow transformation: Behavior selection: Behavior effect: {C, R, U, D}

MergeNode ForkNode JoinNode

Fig. 7. A small portion of the UML 2.0 metamodel: Activities either have Actions or a graph of ActivityNodes and ActivityEdges (left); kinds of nodes and edges (right). The ObjectFlow.effect is an element of the ObjectFlowEffectKind-Enumeration (create, read, update, delete).

usual dot notation is used to access the fields of the instances, i.e., to extract the state of a given ObjectNode o, we write o.inState and so on. For convenience, we assume that an Activity is presented as a graph in the mathematical sense, i.e., in the form hActivityNodes, ActivityEdgesi, where the ActivityNodes and ActivityEdges are again partitioned into the respective metaclasses. That is, ActivityNodes is really a tuple hEN, iN, f N, BN, CN, ON i again, where: EN the set of ExecutableNodes (i.e. elementary Actions); iN , f N the InitialNodes and FinalNodes (of which there may be only one each); BN the set of branch nodes, including both MergeNodes and DecisionNodes; CN the set of concurrency nodes, subsuming ForkNodes and JoinNodes; ON the set of ObjectNodes; and ActivityEdges is a pair hAE , OF i, where: AE OF

the set of plain ActivityEdges between ExecutableNodes and ControlNodes; the set of ObjectFlows between ExecutableNodes and ControlNodes on the one hand, and ObjectNodes on the other.

So, all in all, Activities have the form hActivityNodes, ActivityEdgesi, where ActivityNodes and ActivityEdges are partitioned by hEN, iN, f N, BN, CN, ON i and hAE, OF i, respectively. From now on,

we will use this abstract syntax representation of an Activity.

3

Semantics of activities

3.1

Petri-nets as a semantic domain

Using Petri-nets as a semantic domain for activity diagrams is a fairly obvious choice, given the respective remarks in the standard. Despite the limitations of this approach (e.g. the traverse-to-completion issue, cf. [49]), no other obvious candidate for a semantic domain of activity diagrams comes close to Petri-nets. For data-flow, obviously, traditional P/T-nets are not suitable. There are several extension to the basic Petri-net model that are capable of modeling data flow. These are generally subsumed under the title of “higher order nets” (cf. [29]), with [26,23] probably being the most well known. For pragmatic reasons—availability of good tool support to name but one—colored Petrinets (CPNs, cf. [26]) are chosen as the semantic domain here (see Figure 10 for an example). Definition 3.1 (structure of colored Petri-nets) A (CPN) is a tuple hN , SigAlg, color , guard , effectiwith

colored

Petri-net

is a Petri-net hP, T, Ai of places, transitions, and arcs; is a Σ-algebra hΣ, Opi of sorts and operations; is a total function P → Σ assigning a sort (“color”) to each place; is a total function T → Expr assigning a boolean expression to each transition, the default is the constant tt; effect is a total function A → Expr assigning a expression to each arc, its type being the color of the place of the arc; variables is a partial function A → V assigning a variable from a set V to some arcs. N SigAlg color guard

For convenience, color , guard , and effect may be specified partially, with black dot tokens as the default. That is, if color (p) is undefined, then color (p) = TOKEN is intended, the defaults for guard and effect are true and skip, respectively. The definition of the behavior of net systems is a little more complicated, as we now need to take into account the values of tokens and the meanings of operations on them. A marking of a CPN is a multiset (or word) over {hp, vi | p ∈ P, v ∈ color (p)}. As we lack the space for a complete definition,

we can only provide an example here: consider Figure 11 for a sample run of the net of Figure 10, representing the activity diagram of Figure 6. Observe, that the net elements for CPNs are orthogonal to those of procedural petri nets. Thus, the semantics for data flow defined here may be combined with procedure call semantics defined in [44]. activity

TYPE

The initial and terminal markings(written m and m, respectively) are simply TYPE f N , respectively. The determined as a black-dot-token on the places iN and activity fork/join sink final state is reached, when the terminal marking is reached and no transition merge is activated (this ensures that no tokens aremerge left over in places resulting from forbidden forbidden aux FlowFinalNodes. aux

ExecutableNodes ControlNodes

activity

activity

3.2

place

Intuitive mapping

fork/join

place

forbidden

place place

forbidden

mergethe aux In this section, we first sketch the intuitionauxbehind semantic mapping forbidden aux before we go on to the precise definition in the next section.

ObjectNodes

TYPE

TYPE

aux merge

aux

merge

aux The semantic mapping is defined as a function from the abstract syntax representation of the normal form of activity diagrams to Colored Petri-nets. The translation is explained in two parts. The first part maps the graph structure of an activity graph into a plain Petri-net. The second part maps the inscriptions onto net inscriptions. target

activity

ObjectFlows

TYPE

activity activity

source

ActivityEdges

TYPE

fork/join

remove

activity fork/join

TYPE

TYPE

auxiliary

auxiliary

auxiliary

auxiliary

auxiliary

forbidden

forbidden

auxiliary

auxiliary

auxiliary

forbidden

forbidden

P

where x in { ,

, ,

Fig. 8. The intuition of the semantic mapping for control and data flow of Activities.

The graph mapping is shown intuitively in the table in Figure 8. It shows a translation rule for every case that occurs in an activity diagram in normal form. The left column and the top row contain ActivityNodes and the remove adjacent shaded cells show the Petri-net element they are mapped to, respectively. The table proper contains the net fragments to which ActivityEdges are mapped for every combination of source element (first column) and target forbidden

auxiliary forbidden forbidden

forbidden

forbidde

forbidden

element (first row). For instance, an ActivityEdge from an Action to another Action results in a Petri-net place and two arcs. Some of the combinations that are not allowed in the normal form are suppressed (e.g., ActivityEdges from FinalNodes or to InitialNodes). We will now discuss the translations in detail. First, consider the mappings of ActivityNodes. Quite obviously, Actions and ObjectNodes should map to transitions and places, respectively, for this is exactly the intuition of transitions and places, to represent active and passive elements in a model. Similarly, ForkNodes/JoinNodes and ChoiceNodes/MergeNodes should map to transitions and places, respectively, since they introduce concurrency and choice, which must be expressed by transitions and places with branches, respectively. InitialNodes and FinalNodes represent states, so in Petri-net terms this should really be markings. For simplicity, these are mapped into places as well, which will be marked under the initial and final markings. FlowFinalNodes are similar to FinalNodes, with an additional transition to remove all tokens deposited there. The mappings for the ActivityEdges follow directly from the mappings of the individual ActivityNodes as defined above. For those cases, where an ActivityEdge is mapped to a Petri-net arc or an auxiliary place with two arcs, no other possibility is sensible. For those cases, where an ActivityEdge maps to an auxiliary transition with two arcs, it would have also been possible to merge the two places instead (cf. Figure 9).

auxiliary auxiliary auxiliary (a)

(b)

(c)

(d)

(e)

Fig. 9. Alternative mappings by merging places.

In a case like Figure 9 (a), the mapping of Figure 8 creates the net (b), auxiliary though merging the structure into (c) would also work, and yields a more compact net. However, in a case like Figure 9 (d), merging would yield the wrong result: merging the structure into a single place does not properly reflect the (g) (h) specification, the net in (e) does. With this mapping, the structure of the activity is completely preserved in the Petri-net. In fact, the mapping is bijective, that is, from every net created out of an activity diagram, the original activity diagram can be reconstructed.

(i)

So, when an activity diagram is translated into a Petri-net, it is very easy to trace the behavior of the resulting net back to the activity diagram. This makes understanding the mapping and the model much easier. It also allows to apply Petri-net animation techniques (like the token game) for activity diagrams. The mapping is also modular, that is, if some portion of the activity diagram is changed, only the changed part needs to be translated again. This is very helpful in debugging an activity diagram, for the simulation of the Petri net can be simply suspended, the net may be edited and the simulation may be resumed. This greatly simplifies the task of validating both the grammar as such, and each individual mapping. We now turn to inscriptions. There are basically two kinds of inscriptions we must deal with. First, there are type declarations on ObjectNodes (they become colors of the respective CPN places in our interpretation). Some ObjectNodes also declare a variable (order and order’ in the example) representing instances of the type residing in the ObjectNode. The set of of variables declared on ObjectFlows adjacent to an ActivityNode constitute the name space for the Action that the ActivityNode executes (assuming it is an ExecutableNode). Second, there are output effects in curly braces on ActivityEdges. All we can reasonably know about them is that they work on a given name space, accessing and changing the state of some of the objects in it, possibly augmenting or reducing the name space. The modeler must fill in the details, the effect expressions are simply handed down through the translation and mapped into effect expressions attached to the arcs going out of the transition representing the ActivityEdge. In our interpretation, these functions remain at the respective net arc. As an example, for the mapping, reconsider the Activity from Figure 6 and its translation into a CPN shown in Figure 10 (this Figure is printed from the CPN Toolset). The text to the upper left of the net in Figure 10 is Standard ML code used in CPN Toolset defining the inscriptions: E is the type of the traditional black dot token, and ORDER is a custom defined type carrying the state of an order. The net is created manually using the CPN Toolset and is fully operational (see the screenshots of Figures 12 and 13).

3.3

Formal mapping

The formal semantics is also rather straightforward. We have to map the abstract syntax representation of an Activity hActivityNodes, ActivityEdgesi into a CPN hN, SigAlg, color , guard , effecti by a function [[ ]], where N = hP, T, Ai

and ActivityNodes and ActivityEdges are partitioned into the various kinds of nodes and edges as explained above. The semantic function [[ ]] is defined by:

P

= {iN , fN } ∪ BN ∪ ON ∪{pe | e ∈ AE , {e.source, e.target} ⊆ EN ∪ CN }, = EN ∪ CN

T

∪{te | e ∈ AE , {e.target, e.source} ⊆ BN ∪ ON ∪ {iN , fN }}, A

= {he.source, xe i, hxe , e.targeti | e ∈ AE , xe ∈ P ∪ T } ∪{hx, yi | hx, yi ∈ AE ∧ (x ∈ P, y ∈ T ) ∨ (x ∈ T, y ∈ P )}

SigAlg

= h{o.type | o ∈ ON }, {a.transformation | a ∈ OF }i

color

= {o 7→ o.type | o ∈ ON }

effect

= {a 7→ a.effect | a ∈ OF }

guard

= {n 7→ tt | n is a ForkNode} ∪{n 7→ expr | n is a JoinNode with effect expr }

variables = {a 7→ v | v is attached to a}

Observe the use of the dot-notation to access the nodes adjacent to edges (cf. Figure 7). If o.upperBound is defined for an ObjectNode o, this may be interpreted as a capacity of the respective place using the canonical construction.

4

Analysis of activities

With the semantics defined in the previous section, we may now transfer all the standard techniques for validation and verification of Petri-nets to UML 2.0 activity diagrams. However, an automatic translation from activity diagrams into Petri-nets is currently not possible, due to the lack of tools supporting UML 2.0, in particular activity diagrams. In the remainder of this section, we assume that A is an Activity that is mapped to the CPN N by the semantics above (i.e. [[A]] = N ). We assume that there are sensible initial and final markings of N that correspond to initial and final states of A.

1`1

id

iN

ORDER

(id,false, false, false, false) receive_order

order

p1

INT

order fill_order

color ORDER = product INT * BOOL * BOOL * BOOL * BOOL; var id: INT; var order, order2: ORDER;

fill(order) p2

ORDER order

fun init () = (1, false, false, false, false); fun fill (o1:ORDER):ORDER = (#1 o1, true, #3 o1, #4 o1, #5 o1);

order

p5

p3

fun bill (o1:ORDER):ORDER = (#1 o1, #2 o1, true, #4 o1, #5 o1);

aux ORDER order

ORDER

send_invoice

order

fun pay (o1:ORDER):ORDER = (#1 o1, #2 o1, #3 o1, true, #5 o1); fun ship (o1:ORDER):ORDER = (#1 o1, #2 o1, #3 o1, #4 o1, true);

order

fork

bill(order) ship_goods p6

fun same (o1:ORDER, o2:ORDER):BOOL = (#1 o1)=(#1 o2);

ORDER order

ship(order)

receive_payment

fun join (o1:ORDER, o2:ORDER):ORDER = (#1 o1, #2 o1 orelse #2 o2, #3 o1 orelse #3 o2, #4 o1 orelse #4 o2, #5 o1 orelse #5 o2);

p4

pay(order)

ORDER

order

[ same(order,order2) ] join

p7 ORDER order2

join(order, order2) #1 order

fN INT

close_order

order

p8 ORDER

order

Fig. 10. The Petri-net representing the Activity and the type declared in Figure 6.

4.1

Validation

The CPN Toolset (cf. [14]) is a general purpose tool for a dialect of high-level nets called Colored Petri Nets (cf. [26–29]). It provides a wide range of validation and analysis procedures, ranging from interactive and batch simulation to complex reachability and state space analysis facilities. In the setting described in this paper, the most useful tools are doubtlessly interactive simulation and reachability analysis. Further research (currently unpublished) has also explored the analysis of timing properties and functional properties concerning the dataflow. Consider for instance the simulation session that yielded the screenshots in Figure 12 and 13. The net under scrutiny matches the activity diagram of Figure 6, and its Petri-net translation as shown in Figure 10. The green circles near places represent markings, where the number inside the circle shows the

number of tokens, and the expression in the green boxes attached to them shows the precise multiset of tokens residing on the place. The transitions with the green aura (this is a CPN Toolset-term) around them are activated in the current marking. They may be fired by clicking on them, yielding a new marking that may be inspected. The firing of a transition is undoable, so if an unexpected transition is activated, or the occurrence of a transition yields an unexpected result, the user may immediately explore alternative courses of action. Usually, the expected behavior is possible, too, and the user simply overlooked the other alternatives, sometimes resulting in quite surprising executions. Traces can be a great help during testing or inspecting a design. With the CPN-semantics provided above, both methods are now available for UML 2.0 Activities. A trace of N can be turned into a trace of A by abstracting away the “internal” actions aux, fork, and join. Reconsider the Activity shown in Figure 6 that had been translated into the CPN of Figure 10. Assuming an initial marking for the place representing the InitialNode, we can generate a trace either by a manual simulation (“the token game”), tool supported interactive simulation, or batch computation. Mapping the CPN trace back to the Activity is trivial. Since we chose CPNs with Standard ML inscriptions as our semantic domain, we may use the CPN Toolset as a simulator. See Figures 12 and 13 for two screenshots of the CPN Toolset executing the net in Figure 10. 3 It would even be possible to use it as a basis for a visual simulation of the activity diagram. 4 Generating a trace, however, requires an initial marking, something that is not provided in the UML standard. For simplicity, we take only one token with value 1 as the initial marking. In the inscription language used by CPN Toolset, this initial marking is written as 1‘1.

4.2

Standard properties

Often it is of great practical value to determine whether certain states may or may not be reached. For instance, the question “will the terminal state of A be reached under all circumstances?” may be formalized as ∀m∈RN (m) : m ∈ RN (m), 3

For this example, the translation from Activity to CPN has still been done manually, but I am working on automating the process. 4 The predecessor of CPN Toolset has originally been designed as a simulator for IDEF.

marking

transitions in a step from this marking

variable bindings for this step

hiN, 1‘1i

receive order

id = 1

hp1 , h1, ff , ff , ff , ff ii

fill order

order = h1, ff , ff , ff , ff i

hp2 , h1, tt, ff , ff , ff ii

fork

order = h1, ff , ff , ff , ff i

hp3 , h1, tt, ff , ff , ff ii,

send invoice

order = h1, tt, ff , ff , ff i

hp5 , h1, tt, ff , ff , ff ii

ship goods

order = h1, tt, ff , ff , ff i

hp4 , h1, tt, ff , ff , ttii,

receive payment

order = h1, tt, tt, ff , ff i

join

order = h1, tt, ff , ff , tti

hp6 , h1, tt, tt, ff , ff ii hp4 , h1, tt, ff , ff , ttii, hp7 , h1, tt, tt, tt, ff ii hp8 , h1, tt, tt, tt, ttii

order2 = h1, tt, tt, tt, ff i close order

id = 1

hf N, 1‘1i Fig. 11. A run of the CPN in Fig. 10, representing the Activity specified in Fig. 6 (each row is a step). Here, we use the simplified initial marking 1‘1 at place iN .

where RN (m) denotes the set of markings of N reachable from m, and m and m are the initial and final markings of N , respectively. Similarly, the absence of deadlocks may be verified by ensuring that t

→, ∀m∈RN (m) : ∃t∈TN : m − t

where m − → is the Petri-net notation to express that transition t is activated in m. Finally, properties like “if an order is filled, will the respective goods be shipped eventually?” may expressed in a similar way: fill order

ship goods order

∀m∈RN (m) : m −−−−−→ =⇒ ∃m0 ∈RN (m) : m0 −−−−−−−−−−→ These properties are structurally rather similar, so that translating intuitive properties into Petri-net terminology and interpreting their results for the UML Activity is quite easy. Note, that the traverse-to-completion problem results in a deadlock, so that proness to this problem may be determined by these techniques.

4.3

Quantitative analysis

An important reason for using Petri-net based tools in the design and analysis of business processes, logistics and manufacturing problems and so on has

Fig. 12. A screenshot of a simulation run of the net shown in Figure 10 using Design Toolset: the initial state.

Fig. 13. A screenshot of a simulation run of the net shown in Figure 10 using Design Toolset: this is the state after sending the first invoice but before shipping goods for it.

always been the possibility to do simulations and apply quantitative analysis techniques. In these cases, it is not sufficient to verify that ordered goods are shipped eventually, but we need to ensure certain time bounds. Also, for many applications, it is quite useful to determine the number of orders that reside in the system at any given time or on average, and to determine minimum required capacity for the system to cope with a given load. These kinds of questions are often attacked with stochastic Petri-nets, and there is a large body of work dealing with performance-related questions for UML 1.x activity diagrams—not for UML 2.0, though. Unfortunately, the standard does not provide the kinds of inscriptions necessary to apply the typical analysis techniques for Petri-nets, much less the conceptual framework required. Thus, we would need syntactic extensions to UML activity diagrams to cover aspects like duration, frequency, probability, and latency of Actions. While there have been a number of approaches to provide and exploit such extensions for UML 1.x (e.g. [31,51,33]), it is not clear, if and how these can be transferred to the new version of the UML.

5

5.1

Conclusion

Summary of results

As of writing this, the work on the UML 2.0 has reached the finalization stage. The technical work is said to have ended, and voting should be completed late 2004, leading to the official endorsement of the new UML version probably early 2005. Thus, the currently available specification [34] will actually become the UML 2.0—in other words, even if the standard has not been endorsed right now, this investigation is in fact dealing with the UML standard, and not just some preliminary version. In this paper, a formal semantics of activity diagrams in UML 2.0 is defined. It is based on colored Petri-nets and covers control flow, concurrency and data flow, but not procedure call, exception handling, and expansion regions (see [44–46] for these aspects). Also, stream processing is not covered. By a carefully choice of net formalism and inscription language, the standard analysis techniques and tools for CPNs are made accessible for the verification and validation of UML Activities.

5.2

Discussion of contributions

Since the semantics presented here preserves the structure of the original activity diagram in the resulting Petri-net, it is very easy to map between Activities and corresponding Petri-nets, opening the road to easy mapping between an Activity and corresponding CPN, and even visualisation of executions of Activities. This is very difficult if not impossible for semantics based on a non-graphical formalism, like process algebras. Finally, defining the semantics also helped identify a number shortcomings in the standard. A tool implementation to support industrial case-studies is currently under way, together with extensions and automation of the analysis techniques. This effort is impeded, however, by the current lack of true UML 2.0 tools: despite the marketing promises by many vendors, there are currently no such tools available. With the official adoption of the UML 2.0 standard, we are hoping that this unpleasant situation will disappear.

5.3

New questions and further work

The next step is to extend this semantics to also cover quantitative aspects like processing time and amount of processed data. Also, processing of streaming data is an unsolved problem. It would be interesting to see, whether these extensions allow quantitative analysis of system architectures at an early stage during development. In the Petri-net world, analysis techniques based on Markov-chains have a long tradition, so it seems feasible to turn the semantics presented in this paper into one that creates Generalised Stochastic Petri-nets instead of Colored Petri-nets. Since CPNs are orthogonal to procedural Petri-nets, the semantics for procedure calling of UML 2.0 Activities as defined in [44], it should be easy to combine it with the data flow semantics presented here.

5.4

Related work

In moving from version 1.5 to version 2.0, the UML standard has been rewritten from scratch as far as activity diagrams are concerned. Thus, the related work may be separated into those contributions that deal with a 1.x version of the UML, and those that deal with UML 2.0.

5.4.1

Activity diagrams in UML 1.x

Concerning activity diagrams in UML 1.x, there are four distinct categories of contributions. First, there are “pragmatic” approaches that look into the pragmatics of activity diagrams, examining their usage either for comparing the expressive power of activity diagrams with that of (commercial) workflow description languages and workflow management systems (e.g. [15,1,21]), or for examining their methodological relationship to other diagram types of the UML (e.g. [38]). The main contribution of these approaches lies in exploring the potential of activity diagrams for certain purposes, and to interpret and develop the standard in such a way that the specific requirements of some particular purpose are better realized. While indeed discussing some semantic issues in doing so, the approaches in this category do not provide a semantics. Also, the new standard now defines the semantic model in mind—Petri-nets— and lists the intended usage areas of Activities, namely “procedural computations”, “workflows”, and “system level processes” (cf. [34, p. 284]). Thus, considerations as to the appropriateness of particular semantic domains or about the modeling requirements of one way of modeling versus the other have now become obsolete. Second, there are some approaches (e.g. [39]) that treat activity diagrams as a subclass of StateMachines, as declared by UML 1.x. This has always been a controversial issue, and has now disappeared from the standard. Third, there are “operational” approaches, defining the meaning of activity diagrams “by interpreter”, that is, to give them a meaning in terms of some execution mechanism such as a (commercial) workflow execution system, or a more or less formal execution algorithm (cf. [19,18]) or analysis procedure (cf. [31,16,41,17,20]). Fourth, there are those contributions that define a formal semantics in the proper sense, that is, some kind of mapping from activity diagrams or ActivityGraphs into some formal domain, e.g. [3,12,11,10,16,17,22]. These approaches may be categorized along the following three axes: domain the semantic formalism into which activity diagrams are mapped; rigor the degree of formality employed in defining the mapping, ranging from a set of examples to a mathematical function; expressiveness the degree of coverage of activity diagram notions that is mapped, i.e., control flow, non well formed control flow, data flow, and hierarchy (flat/macro expansion style vs. procedure call). See Figure 14 for a direct comparison of the contributions of the last two categories. Let us now look at some of the contributions of the fourth category in more

detail. Gehrke et al. [22] also use Petri-nets as their semantic domain, but interestingly, they use places to represent ActivityStates (Activities in UML 2.0), possibly misled by the passive sounding name in the UML 1.5 metamodel. Their work being focused on other issues, activity diagrams are treated only in passing and many interesting features are left out, including hierarchy. B¨orger et al. [12] use Abstract State Machines as their semantic domain, and this is the only other semantics that treats SubActivityStates, i.e. procedural calling of Activities. However, the mapping is only given by example, based on concrete syntax and excludes non well formed control flow. And, of course, it is based on UML 1.3, not on UML 2.0. Eshuis and Wieringa [16,17] have published a stream of papers dealing with various aspects of activity diagrams, including a kind of operational semantics using labeled transition systems. Again, hierarchy is left out. See Figure 14 for a comparison of the approaches mentioned. Surprisingly, all of the formal semantics have left out data flow, possibly underestimating both the practical importance and the theoretical value of this aspect. For practical purposes, modeling of data flow is instrumental—industrial applications simply need this facility in all but the simplest settings. This is acknowledged by the fact that authors with a practical background (like [1]) include this aspect. 5 The same is true for industrial workflow definition languages (cf. [30,42,2]), and for languages for describing web services (cf. [37,50,32]) even if they lack industrial perspective.

5.4.2

Activity diagrams in UML 2.0

While there is a rather large body of work on UML 1.x activity diagrams, it seems that so far, hardly any work. One exception is [4], who examines the semantics of pins very briefly. Also, there is a series of articles by C. Bock on UML 2 Activities (see [5–7,9]), one of which deals with data flow (cf. [8]). While being far more explicit and complete than the standard, these articles lack formal precision. Given that the author has participated in the OMG’s standardization process of the UML 2 Activities, the interpretations provided should be considered, even if they are individual opinions and not officially endorsed by the OMG. A more formal approach on UML 2 Activities is found in my previous publications: [44] deals with control flow and procedure calling, [45] deals with 5

These authors also cover other aspects of practical value which, unfortunately, cannot be covered here due to lack of space.

exceptions, and [46,48] deals with expansion regions and structured nodes. [49] raise some questions concerning the suitability of Petri-nets as the semantic domain.

References

[1] Thomas Allweyer and Peter Loos. Process Orientation in UML through Integration of Event-Driven Process Chains. In Pierre-Alain Muller and Jean B´ezivin, editors, International Ws. ’98: Beyond the Notation, number 1618 in LNCS, pages 183–193. Springer Verlag, 1999. [2] Tony Andrews, Francisco Curbera, Hitesh Dholakia, Yaron Goland, Johannes Klein, Frank Leymann, Kevin Liu, Dieter Roller, Doug Smith, Satish Thatte, Ivana Trickovic, and Sanjiva Weerawarana. Business Process Execution Language for Web Services (v1.1), 5 May 2003. available at http://www.ebpml. org/bpel4ws.htm. [3] Ludovic Apvrille, Pierre de Saqui-Sannes, C. Lohr, Patrick S´enac, and JeanPaul Courtiat. A New UML Profile for Real-Time System Formal Dessigne and Validation. In Gogolla and Kobryn [24], pages 287–301. [4] Jo˜ao P. Barros and Lu´ıs Gomes. Actions as Activities as Petri nets. In Jan J¨ urjens, Bernhard Rumpe, Robert France, and Eduardo B. Fernandey, editors, Proc. Ws. Critical Systems Development with UML, pages 129–135, 2003. [5] Conrad Bock. UML 2 Activity and Action Models. J. Object Technology, 2(4):43–53, July/August 2003. available at www.jot.fm. [6] Conrad Bock. UML 2 Activity and Action Models: Actions. J. Object Technology, 2(5):41–56, September/October 2003. available at www.jot.fm. [7] Conrad Bock. UML 2 Activity and Action Models: Control Nodes. J. Object Technology, 2(6):7–22, November/December 2003. available at www.jot.fm. [8] Conrad Bock. UML 2 Activity and Action Models: Object Nodes. J. Object Technology, 3(1):27–41, January/February 2004. available at www.jot.fm. [9] Conrad Bock. UML 2 Activity and Action Models: Partitions. J. Object Technology, 3(7):37–56, July/August 2004. available at www.jot.fm. [10] Christie Bolton and Jim Davies. Activity graphs and processes. In W. Griesskamp, T. Santen, and W. Stoddart, editors, Proc. Intl. Conf. Integrated Formal Methods (IFM), LNCS. Springer Verlag, 2000. [11] Christie Bolton and Jim Davies. On giving a behavioural semantics to activity graphs. In Reggio et al. [40], pages 17–22. [12] Egon B¨orger, Alessandra Cavarra, and Elvinia Riccobene. An ASM Semantics for UML Activity Diagrams. In Teodor Rus, editor, Proc. 8th Intl. Conf. Algebraic Methodology and Software Technology (AMAST), number 1816 in LNCS, pages 293–308. Springer Verlag, May 2000.

Fig. 14. Comparative categorization of the previous work leading to this article. Abbreviations: wf=well formed, nwf=non well formed, excn.=exceptions, proc.= procedure. 1.3 1.x 1.x 1.0 1.x 1.x 1.x 2.0 2.0 2.0 2.0

Bolton & Davies [11,10]

Eshuis & Wieringa [16,17]

Eshuis & Wieringa [19,18]

Gehrke et al. [22]

Pinheiro da Silva [39]

Rodrigues [41]

Li et al. [31]

this paper and [47]

St¨ orrle [44]

St¨ orrle [45]

St¨ orrle [46,48]

PPN

ECPN

PPN

CPN

LTS

FSP

LOTOS

PN

LTS

algorithm

CSP

ASM

LOTOS

– √ ( ) √ ( )

(–) √

–

–

(–)

–

–

–

–

–

flow √

data

√ ( ) √ ( )

– √

–

–

–

–

–

–

–

– √

–

calling

proc.

√ ( )

– √

–

–

–

–

–

–

–

–

–

–

–

excn.

– √

–

–

–

–

–

–

–

–

–

–

–

–

low

medium

high

medium

high

low

low

medium

high

high

low

medium

medium

low

rigor

–

–

–

std. PN techniques

–

–

–

simulation

(–)

–

–

–

–

techniques

analysis

FSP = finite state processes LTS = labeled transition systems ASM = abstract state machines

& streams

expansions

ECPN = exception colored Petri-nets LOTOS = Lang. of Temp. Ordering Specifications CSP = communicating sequential processes

1.x

B¨ orger et al. [12]

PN = simple P/T-Petri-nets PPN = procedural Petri-nets CPN = colored Petri-nets

1.x

Apvrille et al. [3]

–

domain

version 0.9

semantic

UML

Allweyer et al. [1]

authors, references

[13] Ray J. A. Buhr. Use Case Maps as Architectural Entities for Complex Systems. IEEE Transactions on Software Engineering, 24(12):1131–1155, December 1998. [14] CPN Tools Team. CPN Tools Manual. Technical report, Univ. of Aarhus, 2004. available at http://wiki.daimi.au.dk/cpntools/cpntools.wiki. [15] Marlon Dumas and Arthur H.M. ter Hofstede. UML Activity Diagrams as a Workflow Specification Language. In Gogolla and Kobryn [24], pages 76–90. [16] Henrik Eshuis. Semantics and Verification of UML Activity Diagrams for Workflow Modelling. PhD thesis, CTIT, U. Twente, 2002. Author’s first name sometimes appears as “Rik”. [17] Rik Eshuis and Roel Wieringa. A formal semantics for UML Activity Diagrams - Formalising workflow models. Technical Report CTIT-01-04, U. Twente, Dept. of Computer Science, 2001. [18] Rik Eshuis and Roel Wieringa. A Real-Time Execution Semantics for UML Activity Diagrams. In Heinrich Hussmann, editor, Proc. 4th Intl. Conf. Fundamental approaches to software engineering (FASE), number 2029 in LNCS, pages 76–90. Springer Verlag, 2001. Also available as wwwhome.cs. utwente.nl/∼tcm/fase.pdf. [19] Rik Eshuis and Roel Wieringa. An Execution Algorithm for UML Activity Graphs. In Gogolla and Kobryn [24], pages 47–61. [20] Rik Eshuis and Roel Wieringa. Verification support for workflow design with UML activity graphs. In Proc. 24th Intl. Conf. on Software Engineering (ICSE), pages 166–176. IEEE, 2002. [21] Rik Eshuis and Roel Wieringa. Comparing Petri Net and Activity Diagram Variants for Workflow Modelling - A Quest for Reactive Petri Nets. In Michael Weber, Hartmut Ehrig, and Wolfgang Reisig, editors, Petri Net Technology for Communication-Based Systems, pages 321–351. DFG Research Group “Petri Net Technology”, 2003. [22] Thomas Gehrke, Ursula Goltz, and Heike Wehrheim. The Dynamic Models of UML: Towards a Semantics and its Application in the Development Process. Technical Report 11/98, Institut f¨ ur Informatik, Universit¨at Hildesheim, 1998. [23] Hartmann J. Genrich and Kurt Lautenbach. Predicate/Transition Nets. In [29], 1991. [24] Martin Gogolla and Chris Kobryn, editors. Proc. 4th Intl. Conf. on the Unified Modeling Language (’01), number 2185 in LNCS. Springer Verlag, 2001. [25] Robert Harper, Robin Milner, and Mads Tofte. The definition of standard ml v3. Technical Report ECS-LFCS-89-81, CSR-299-89, Lab. for the Foundations of Computer Science., Dept. of Comp. Sci., Edinburgh University, 1989. auch erschienen bei MIT Press, 1990.

[26] Kurt Jensen. Coloured Petri Nets. Basic Concepts, Analysis Methods and Practical Use. Vol. I. EATCS Monographs on Theoretical Computer Science. Springer Verlag, 1992. [27] Kurt Jensen. Coloured Petri Nets. Basic Concepts, Analysis Methods and Practical Use. Vol. II. EATCS Monographs on Theoretical Computer Science. Springer Verlag, 1995. [28] Kurt Jensen. Coloured Petri Nets. Basic Concepts, Analysis Methods and Practical Use. Vol. III. EATCS Monographs on Theoretical Computer Science. Springer Verlag, 1997. [29] Kurt Jensen and Grzegorz Rozenberg. Application. Springer Verlag, 1991. [30] G. Keller, Markus Prozessmodellierung (EPK). Technical Saarbrcken, 1991. heft089.ps.

Nttgens, auf der Report available

High-Level Petri Nets. Theory and

and August-Wilhelm Scheer. Semantische Grundlage Ereignisgesteuerte Prozessketten 089, Institut fr Wirtschaftsinformatik, Uni at http://www.iwi.uni-sb.de/iwi-hefte/

[31] Xuandong Li, Meng Cui, Yu Pei, Zhao Jianhua, and Zheng Guoliang. Timing Analysis of UML Activity Diagrams. In Gogolla and Kobryn [24], pages 62–75. [32] Esperanza Marcos, Valeria de Castro, and Belen Vela. Services with UML: A Case Study. pages 17–27.

Representing Web

[33] Jos´e Merseguer and J. Campos. Software Performance Modelling Using UML and Petri Nets, volume 2965 of LNCS, pages 265–289. Springer Verlag, 2004. [34] OMG. OMG Unified Modeling Language: Superstructure (final adopted spec, version 2.0, 2003-08-02). Technical report, Object Management Group, November 2004. Available at www.omg.org, downloaded at November 11th , 2003. [35] OMG. The OMG UML Issues Database. Technical report, Object Management Group, 2004. available at www.omg.org/issues/uml2-superstructure-ftf. open.html. [36] Lawrence C. Paulson. ML for the Working Programmer. Cambridge University Press, 1991. [37] Cesare Pautasso and Gustavo Alonso. Visual Composition of Web Services. In John Hosking and Philip Cox, editors, Human Centric Computing Languages and Environments, pages 92–99. IEEE Computer Society, 2003. [38] Dorin C. Petriu and Yimei Sun. Consistent Behaviour Representation in Activity and Sequence Diagrams. In Bran Selic, Stuart Kent, and Andy Evans, editors, Proc. 3rd Intl. Conf. 2000—Advancing the Standard, number 1939 in LNCS, pages 369–382. Springer Verlag, October 2000. [39] Paulo Pinheiro da Silva. A proposal for a LOTOS-based semantics for UML. Technical Report UMCS-01-06-1, Dept. of Computer Science, U. Manchester, 2001.

[40] Gianna Reggio, Alexander Knapp, Bernhard Rumpe, Bran Selic, and Roel Wieringa, editors. Proc. Intl. Ws. Dynamic Behavior in UML Models: Semantic Questions. Technical Report No. 0006 of the Ludwig-Maximilians-Universit¨ at, M¨ unchen, Inst. f. Informatik, October 2000. [41] Roberto W.S. Rodrigues. Formalising UML Activity Diagrams using Finite State Processes. In Reggio et al. [40], pages 92–98. [42] August-Wilhelm Scheer. ARIS-Business Process Modeling. Springer Verlag, 1999. 2nd edition. [43] Harald St¨orrle. Semantics and Verification of Data-Flow in UML 2.0 Activities. In Mark Minas, editor, Proc. Intl. Ws. on Visual Languages and Formal Methods (VLFM’04), pages 38–52. IEEE Press, 2004. available at www.pst. informatik.uni-muenchen.de/∼stoerrle. [44] Harald St¨orrle. Semantics of Control-Flow in UML 2.0 Activities. In Paolo Bottoni, Chris Hundhausen, Stefano Levialdi, and Genny Tortora, editors, Proc. IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC), pages 235–242. Springer Verlag, 2004. [45] Harald St¨orrle. Semantics of Exceptions in UML 2.0 Activities. Technical Report 0403, Ludwig-Maximilians-Universit¨at M¨ unchen, Institut f¨ ur Informatik, 2004. available at www.pst.informatik.uni-muenchen.de/ ∼stoerrle. [46] Harald St¨orrle. Semantics of Expansion Nodes in UML 2.0 Activities. In Ivan Porres, editor, Proc. 2nd Nordic Ws. on UML, Modeling, Methods and Tools (NWUML’04), pages 19–32, 2004. [47] Harald St¨orrle. Semantics and Verification of Data-Flow in UML 2.0 Activities. Electronic Notes in Theoretical Computer Science, t.b.d(t.b.d), 2005. [48] Harald St¨orrle. Semantics of Expansion Nodes in UML 2.0 Activities. Nordic Journal of Computing, t.b.d.(t.b.d.):t.b.d., 2005. [49] Harald St¨orrle and Jan Hendrik Hausmann. Obstacles on the Way Towards a Formal Semantics of UML 2.0 Activities. In Klaus Pohl, editor, Proc. Natl. Germ. Conf. Software-Engineering 2005 (SE’05), number t.b.d. in Lecture Notes in Informatics, page t.b.d. Gesellschaft f¨ ur Informatik e.V. 2005. [50] Sebastian Th¨one, Ralph Depke, and Gregor Engels. Process-Oriented, Flexible Composition of Web Services with UML. In Proc. Intl. Ws. Conceptual Modeling Approaches for e-Business: A Web Service Perspective (eCOMO 2002), number 2784 in LNCS. Springer Verlag, 2002. [51] Jing Xu, Murray Woodside, and Dorin Petriu. Performance Analysis of a Software Design using the UML Profile for Schedulability, Performance and Time. In Proc. 13th Intl. Conf. Computer Performance Evaluation, Modelling Techniques and Tools (TOOLS’03), number 2794 in LNCS, pages 291–310. Springer Verlag, 2003.