Rik Eshuis

Verification support for workflow design with UML activity graphs

We describe a tool that supports verification of workflow models specified in UML activity graphs. The tool translates an activity graph into an input format for a model checker according to a semantics we published earlier. With the model checker arbitrary propositional requirements can be checked against the input model. If a requirement fails to hold an error trace is returned by the model checker. The tool automatically translates such an error trace into an activity graph trace by high-lighting a corresponding path in the activity graph. One of the problems that is dealt with is that model checkers require a finite state space whereas workflow models in general have an infinite state space. Another problem is that strong fairness is necessary to obtain realistic results. Only model checkers that use a special model checking algorithm for strong fairness are suitable for verifying workflow models. We analyse the structure of the state space. We illustrate our approach with some example verifications.

Comparing Petri Net and Activity Diagram Variants for Workflow Modelling : A Quest for Reactive Petri Nets

Petri net variants are widely used as a workflow modelling technique. Recently, UMLa ctivity diagrams have been used for the same purpose, even though the syntax and semantics of activity diagrams has not been yet fully worked out. Nevertheless, activity diagrams seem very similar to Petri nets and on the surface, one may think that they are variants of each other. To substantiate or deny this claim, we need to formalise the intended semantics of activity diagrams and then compare this with various Petri net semantics. In previous papers we have defined two formal semantics for UMLact ivity diagrams that are intended for workflow modelling. In this paper, we discuss the design choices that underlie these two semantics and investigate whether these design choices can be met in low-level and high-level Petri net semantics. We argue that the main difference between the Petri net semantics and our semantics of UML act ivity diagrams is that the Petri net semantics models resource usage of closed, active systems that are non-reactive, whereas our semantics of UMLact ivity diagrams models open, reactive systems. Since workflow systems are open, reactive systems, we conclude that Petri nets cannot model workflows accurately, unless they are extended with a syntax and semantics for reactivity.

Reactive Petri nets for workflow modeling

Petri nets are widely used for modeling and analyzing workflows. Using the token-game semantics, Petri net-based workflow models can be analyzed before the model is actually used at run time. At run time, a workflow model prescribes behavior of a reactive system (the workflow engine). But the token-game semantics models behavior of closed, active systems. Thus, the token-game semantics behavior of a Petri net-based workflow model will differ considerably from its behavior at run time. In this paper we define a reactive semantics for Petri nets. This semantics can model behavior of a reactive system and its environment. We compare this semantics with the token-game semantics and prove that under some conditions the reactive semantics and the token-game semantics induce similar behavior. Next, we apply the reactive semantics to workflow modeling and show how a workflow net can be transformed into a reactive workflow net. We prove that under some conditions the soundness property of a workflow net is preserved when the workflow net is transformed into a reactive workflow net. This result shows that to analyze soundness, the token-game semantics can safely be used, even though that semantics is not reactive.

Requirements-level semantics for UML statecharts

We propose a formal real-time semantics for UML statecharts aimed at the requirements level. A requirements-level model assumes perfect technology and has a considerably simpler semantics than an implementation level model. Our semantics is an adaptation of the Statemate statechart semantics, with local variables, real time, identifier addressing, point-to-point communication, synchronous communication and dynamic object creation and deletion. We start with an informal comparison of Statemate and UML statechart semantics and then give a formalisation of our semantics in terms of labelled transition systems.

Requirements-level semantics and model checking of object-oriented statecharts

In this paper we define a requirements-level execution semantics for object-oriented statecharts and show how properties of a system specified by these statecharts can be model checked using tool support for model checkers. Our execution semantics is requirements-level because it uses the perfect technology assumption, which abstracts from limitations imposed by an implementation. Statecharts describe object life cycles. Our semantics includes synchronous and asynchronous communication between objects and creation and deletion of objects. Our tool support presents a graphical front-end to model checkers, making these tools usable to people who are not specialists in model checking. The model-checking approach presented in this paper is embedded in an informal but precise method for software requirements and design. We discuss some of our experiences with model checking.

A Real-Time Execution Semantics for UML Activity Diagrams

We define a formal execution semantics for UML activity diagrams that is appropriate for workflow modelling. Our semantics is aimed at the requirements level by assuming that software state changes do not take time. It is based upon the STATEMATE semantics of statecharts, extended with some transactional properties to deal with data manipulation. Our semantics also deals with real-time and multiple state instances. We first give an informal description of our semantics and then formalise this in terms of transition systems.

An Execution Algorithm for UML Activity Graphs

We present a real-time execution semantics for UML activity graphs that is intended for workflow modelling. The semantics is defined in terms of execution algorithms that define how components of a workflow system execute an activity graph. The semantics stays close to the semantics of UML state machines, but differs from it in some minor points. Our semantics deals with real time. The semantics provides a basis for verification of UML activity graphs, for example using model checking, and also for executing UML activity graphs using simulation tools. We illustrate an execution by means of a small example.

Animating ebXML Transactions with a Workflow Engine

ebXML is becoming the new international standard for the specification and deployment of complex B2B transactions over the internet. ebXML transactions are inherently distributed, involving many actors exchanging XML messages with each other according to complex flows and rules. This complexity hampers validation of the correctness of a modelled business transaction by business experts. To alleviate this problem, we have developed an animator to support the cooperative validation of ebXML transactions by business experts. The animator is internet-based, supporting distributed animation of an ebXML transaction. The animator automatically checks business rules on the messages exchanged during animation. Heart of the animator is a workflow engine that can read workflow descriptions in XPDL. In this paper, we show how the animator is automatically configured from the UML models describing the ebXML transaction. The main UML models used are class diagrams to model messages and an activity diagram to model the global flow of the messages that are exchanged by the actors. Class diagrams are annotated with business rules. The UML activity diagram maps into XPDL code for the workflow engine. The class diagrams map into XML Schemas that are used by the animator for receiving, checking and sending messages. The mapping algorithms have been implemented as plugins in a commercial UML-based CASE tool. Throughout the paper, we illustrate the whole approach on a real-life example.