9.3
Other work on UML activity diagrams
Dumas and Hofstede [53] evaluate the suitability of UML activity diagrams for workflow modelling by trying to capture some workflow patterns [7] in activity di- agrams. They only consider activity diagrams that are translated into statecharts according to OMG semantics of UML 1.4 [150].
There are several other formalisations of the UML 1.4 (and of earlier versions) of activity diagrams [13, 23, 25, 73, 137]. Gehrke et al. [73] propose to give a semantics to activity diagrams by translating them into Petri nets, but do not provide a formal semantics. They do not relate the proposed Petri net semantics to the OMG semantics of activity diagrams. See Chapter 8 for a comparison of both our semantics with Petri nets.
The other formalisations [13, 23, 25, 137] follow the OMG semantics closely. The discussion in Section 9.2 listing the difference of our semantics with the OMG semantics also applies to these other formalisations. Like the OMG semantics, these formalisations map activities into actions that are done in transitions of the system under development. Consequently, they too have problems modelling parallelism (see Section 9.2). The formalisations are not as complete as ours; for example none of them deals with events, none of them deals with the in predicate, none of them deals with wait nodes.
It is quite interesting to see the approach taken by these other formalisations. All of them give a semantics by defining a mapping from an activity diagram into the syntax of another formal technique, for example LOTOS [22] in the case of Apvrille et al. [13] and Pinheiro da Silva [137], or CSP [97] in the case of Bolton and Davies [23].
Implicitly, in these approaches the assumption is made that the semantic choices made in these formal techniques are valid for UML activity diagrams as well. Although this might be true, we think that choices made in the semantics should be made explicit, so that they can be validated for the intended domain of modelling, in this case workflow modelling. Unfortunately, none of the authors mentioned above seems to be aware of this problem. In none of these references the semantic choices are stated explicitly. Even if one thinks these semantic choices are valid for the domain being modelled, this should be brought out in the open and motivated. This is not done by the authors just mentioned.
To show the impact of these hidden assumptions, we give three examples of hidden assumptions that are implicitly made in the approaches above, and we vali- date these hidden assumption against the domain of workflow modelling. The first example concerns the semantics of activities. In the process algebraic formalisa- tions of UML activity diagrams [13, 23, 137], activities are modelled as actions. In every process algebra, including CSP and LOTOS, an action does not take time. Also, actions are done in transitions of the system being modelled, not in states. Actions, including parallel ones, are interleaved: only one action is done at a time. This is justified in process algebras by the fact that an action is instantaneous.
148 Chapter 9· Related work Applying the process-algebraic formalisation to our running example (Fig- ure 1.1), we thus have that activities like Check stock and Check customer do not take time. Moreover, activities Check stock and Check customer that are specified to be in parallel according to the specification, are done sequentially, i.e. one by one, in the semantics! Of course, a more fine grained mapping could be defined, in which an activity is mapped into a begin and an end action, but this is not done in these formalisations.
As a second example, one of the key features of process algebras like LOTOS and CSP is the definition of an equality relation on processes. Figure 9.5 shows two activity diagrams that are the same according to the formal semantics of Apvrille et al. [13], Pinheiro da Silva [137], and Bolton and Davies [23]. (We do not use wait nodes as these are not formalised by these references.) But the two activity diagrams are different according to our two semantics, because they have different runs. We think most workflow designers (and most UML designers) would consider them different as well.
The third example concerns the semantics of communication. In process alge- bra, communication between two parties is blocking in the sense that both parties cannot proceed unless they cooperate with each other. In other words, commu- nication is synchronous. Translating this to workflow specifications, this would mean that the environment of a WFS must run in the same pace as the WFS itself. The environment might even get blocked by the WFS, if the WFS is too slow. It is very doubtful whether this is appropriate for WFSs. We do not want to put such a constraint upon the environment of the WFS. We therefore have adopted a non-blocking semantics (see Section 4.3 on page 47).
We conclude that in these other formalisations of UML activity diagrams, some of the semantic choices that are implicitly made do not match the domain of workflow modelling. Thus, these semantics are not fit to be used for workflow modelling. A B A B B A (a) (b)
Figure 9.5 Two activity diagrams that are the same according to [13, 23, 137],