Metodologías para la Evaluación de Impactos

Restricted temporal logic. In a seminal paper, Lamport [113] argues not to use the next time X operator in temporal logic specifications, because this operator makes it possible to distinguish between a high-level specification and a lower

10.7· Related work 181 level implementation. Lamport does not, however, restrict usage of the until U operator, because in his formalism variables referred to by a property must change instantaneously. By contrast, in our implementation-level semantics, variables that a property refers to do not have to change instantaneously. Consequently, it is possible to observe an inconsistent state. For example, in the ILS it is possible to observe a configuration in which some nodes have been left but still some nodes have to be entered. That is why the only states we allow to observe are stable ones. That is also why we need to restrict usage of the until U operator, whereas Lamport does not need to do so.

General requirements. The conjunction of the first three general requirements resembles the soundness criterion that Van der Aalst [3] uses for Petri nets that model workflows. There is however a subtle difference. The proper termination property in the soundness criterion amounts to the CTL formula AG EF final , which states that the workflow can terminate properly. This formula is weaker than the property we use, F G final , which states that the workflow will terminate properly. The difference between the two formulations pops up in the case of divergence: a diverging workflow specification would pass the soundness criterion but not our proper termination requirement.

Hofstede and Orlowska [98] also discuss some general requirements for work- flow models that are formalised in process algebra. They focus on the computa- tional complexity of verifying these requirements. They do not consider divergence. Sadiq and Orlowska [143] also focus on verifying general requirements like absence of deadlock by applying graph reductions. They do not consider divergence.

Verification tools. There are several workflow verification tools. Woflan [155] is a tool for verification of textual workflow specifications without data and real- time. Feedback is also textual. The workflow specifications are based on low-level Petri nets. In Woflan the properties that are verified, like soundness, are fixed and cannot be changed by the user. The issue of strong fairness is not addressed.

FlowMake [143] is a tool for verification of workflows that are notated in a subset of the WFMC workflow notation. Data and real-time are not modelled. FlowMake verifies some fixed properties of a workflow by applying graph reduction techniques; if the reduction does not lead to an empty graph, apparently the graph contains an error and it should be possible for the user to find this error using the reduced graph. The issue of strong fairness is not addressed.

The tool developed in the Mentor project [130] uses a CTL model checker for statecharts [101]. The tool is not integrated with the model checker. The authors do not use strong fairness. They do not provide any details on how the feedback is presented to the user.

The Testbed Studio tool [104] supports model checking of business process models with Spin [99]. The process modelling language neither has external events nor temporal events. Models can have loops, but the analysis results on such

182 Chapter 10· Verification of functional requirements models may be counterintuitive, since it cannot be specified that loops are exited. The authors do not use strong fairness.

Karamanolis et al. [107] use the existing LTSA toolkit for model checking workflow specifications. Workflow specifications are translated manually into input for LTSA; the output of verification is shown graphically in the LTSA input, not in the original workflow specification. LTSA is based on process algebra; data and real-time cannot be explicitly modelled. Strong fairness constraints can also be specified in LTSA, but Karamanolis et al. [107] do not focus on loops in workflow schemas.

Our work is also closely related to the work done on model checking State- mate and UML statecharts. Chan et al. [34] and Mikk [126] have defined model checking for Statemate statecharts or variants thereof, using SMV [125] and Spin [99]. Latella et al. [116] present a translation for a subset of UML statecharts to Spin [99]. None of the implementations discussed in these papers provide a graphical representation of the feedback of the model checker. All these papers encode the syntax of the statechart explicitly in the input language and let the model checking tool derive the step semantics implicitly. We, on the other hand, have programmed our execution algorithm [65] in TCM, so TCM generates the se- mantic structure directly. These syntactic encodings only work for simple models with a restricted syntax. Amongst others, every node can be active at most once at the same time: it must have a bound of one (i.e., the activity diagram must be safe). This is true for a statechart but not for an activity diagram. Also, syntactic encodings are error prone (see for example a discussion by Mikk on errors he found in such translations [126]).

We have also implemented a syntactic encoding for activity diagrams in TCM in order to compare it with our own encoding. We found that if the syntactic encoding can be applied, it is more efficient than the enumerative encoding we use. But in order to decide whether the syntactic encoding can be applied, still the semantics of the activity diagram needs to be computed using our first implementation in order to check that the activity diagram is safe.

Lilius and Paltor [120] present vUML, a tool for model checking a commu- nicating set of objects whose behaviour is modelled by UML statecharts. They use Spin [99] as their underlying model checker. No details are given on how the statechart is encoded. The feedback of the tool is graphically represented by a UML sequence diagram. They neither address strong fairness nor real-time.

It is difficult to compare our work with this work on statecharts, since our se- mantics differs somewhat from the statechart semantics, both UML andStatem- ate, in particular since we have atomic activity states whose effect is declaratively specified (these are not present in statecharts). Next, we have configurations and steps that are bags rather than sets, since nodes in our models can have a bound of more than one. None of the references above use strong fairness constraints, since these are apparently not required in the domain they model (usually embedded real-time systems). Neither do they analyse the state space nor discuss possible

10.8· Conclusion and future work 183