The integration of a formal process theory with a practically usable notation is not straightforward, but it is necessary for practical verification of process specifications. Given such an intermediate language, a verification process that gives useful feedback is not trivial either: Model checkers are not powerful enough to deal with object models, and theorem provers provide insu#cient feedback and are not certain to find a proof

Rein, H. van

English

van Rein, H.

University of Twente Research Information

On Practical Verification of Processes

NARCIS 

On Practical Verification of ProcessesRick van Reinvanrein@cs.utwente.nlUniversity of Twente, Enschede, The NetherlandsAbstract. The integration of a formal process theory with a practicallyusable notation is not straightforward, but it is necessary for practicalverification of process specifications. Given such an intermediate lan-guage, a verification process that gives useful feedback is not trivial ei-ther: Model checkers are not powerful enough to deal with object models,and theorem provers provide insufficient feedback and are not certain tofind a proof.Our work on life cycles has provided us with a precise process notationwhich is expressive enough to capture customary object designs. In thisposition paper we present our plans to perform verification on life cyclesin such a way that it can provide useful feedback and at the same timeproves a reasonable class of systems correct.1 Introduction to Life CyclesIn this section we shall introduce our process language, called Life Cycles. Con-sider the diagram in Fig. 1. This is a life cycle, where transitions selectivelycause transitions in instances. For example, the marry(this,?partner) transitionsrespond to the occurrence of a marry event with concrete parameter values. Onlythe life cycles with this equal to the first parameter make a transition and storethe value of the second parameter in the partner variable.The transition birth(this) is also a normal transition, responding to the occur-rence of a birth event. We imagine an infinite number of new Person instancesto be ready in a ‘prenatal’ state, and only the one with the right identity storedin the special variable this makes the transition to the Single state; this is alsoknown as instance creation.Formally, the order of parameters is important, but for brevity’s sake we shallassume the marry event to be an exception. Then, if a marry event with concreteparameters occurs, like marry(Tarzan,Jane), it is observed by both the life cycleinstances Tarzan and Jane that respond by each making a transition, either fromSingle to Married or from Working to OverWorked.If one life cycle can observe the occurrence of events, then so can two or more.For instance, the life cycle in Fig. 2 observes an event hire that is also observed bypersons; if two life cycles respond to the same event, they are said to communicateabout hiring personnel.This company life cycle sets strict procedures regarding hiring of new personnel,in an attempt to avoid that partners can form an information leak to competitors.marry(this,  ?partner)marry(this,  ?partner)hire(this,  ?employer)hire(this,  ?employer)Married OverWorkedWorkingSinglebirth(this)Person e.g. Tarzan, JaneFig. 1. Life cycle for a Person, who can marry and be hired.So, Single people can be hired, or married people with jobless (that is, Marriedinstead of OverWorked) partners, or people whose partner already works forthe hiring company. These constraints are captured in the constraints in squarebrackets; a transition can only take place if that condition is not violated.We are rounding up the definition of the formal semantics of life cycles at thistime. Having such a semantics is a big advantage with respect to state charts,and so is the explicit creational construct, and the simplicity of the notation,which nevertheless is quite powerful.In comparison to process algebras such as ACP [BW90], we see the advantageof a pleasing graphical notation, and a set of practical extensions such as pa-rameters and variables and, of course, a straightforward creational construct.In comparison to the π-calculus, this paper demonstrates that our richer nota-tion will be beneficial in proofs and providing useful feedback. We also dislikethe point-to-point communication structures in the π-calculus, and prefer a CSP-like scheme [Hoa85] of globally visible events, because this has a less ‘procedural’feeling.2 On Process VerificationIt is our intention to perform verification on process structures such as our lifecycles. In our example, it would be interesting to find out if the hiring procedurespracticed by companies ensure that no married couple can ever have partnersworking for different companies. In more formal notation, we would require that∀p, p′ : Person · p.partner = p′⇒ p@Married ∨ p′@Married ∨ p.employer = p′.employerwhere p@s indicates that life cycle instance p is in state s.HiringCompanyhire(?p,this) [ p@Single ]hire(?p,this) [ p.partner@Married ]e.g. RedHat, SuSeestablish(this)hire(?p,this) [ p.partner.employer=this ]Fig. 2. Life cycle of a Company that fights spying.Feedback as a proof goal. Such verifications are preferably done with modelcheckers, because they can provide excellent feedback. In this case, there is oneway of invalidating the constraint, and a good model checker could produceoutput as in Fig. 3. This trace shows what can go wrong: If two persons arefirst hired by different companies and then marry, the constraint is invalidated.Such feedback is quite useful to improve designs or constraints, or perhaps makeassumptions explicit, until they are accepted by the verifier.A disadvantage of model checkers is their inability to deal with an arbitrary num-ber of instances, as suggested by the creational construct for life cycle instancesand by the ∀p, p′ : Person quantifications. To deal with this more general classof problems, it is necessary to use more general problem solvers, and theoremprovers are the customary next guess.Theorem provers may be able to find errors like these, but they mostly pro-vide rather crude feedback, sometimes no more than ‘nope’. As we showed be-fore [Rei99], useful feedback is crucial, and therefore we cannot accept such crudefeedback. Some theorem provers will explain the paths of reasoning that led tothe failure to prove a property, but these paths are usually formulated in terms ofthe logic used internally. This kind of feedback is too detailed to be of practicaluse.Using theorem provers. The benefit of model checkers is that they perform theirproofs at the level at which the designer thinks, namely in terms of processinstances, states and transitions. When a theorem prover is taught to reasonat this level, it should not be hard to provide feedback of the same quality asmodel checkers do, but for a more general class of constraints, including dynamiccreation of new process instances.Tarzan@SingleJane@SingleRedHat SuSe@Hiring @Hiringhire(Tarzan,RedHat)hire(Jane,SuSe)marry(Tarzan,Jane)Fig. 3. Possible feedback from a good constraint verifier.We want to remark explicitly that this benefit of good feedback can hardlybe expected from a proof on π-calculus formulations. Although π-calculus isan excellent vehicle to specify a minimalistic semantics, it is less suitable forfeedback-generation, because its syntax is too terse. For example, it is a non-trivial problem to distinguish an object from a message in a π-calculus system ifboth are described as a process. This has been another motivation for our self-made process language: We wanted to provide a sufficiently expressive languagein which we could recognise the concepts in terms of which a process designerthinks.To let a theorem prover ‘reason’ in these terms, there must be a (preferably com-plete, but at least sound) set of rules that describe knowledge and reasoning atthat level. Except for standard logical manipulations, these rules should describetransitions, and the knowledge that can be inferred from them.Note that this is an uncommon approach. When a syntax contains some operator→ and a slightly altered variant →∗, then the usual approach in theory designis to try and describe the difference between these two operators in an ad hocoperator (say, ∗) to avoid overlapping rules. The ideal is then to make the rulesentirely orthogonal and minimalistic. In our approach however, we aim for rulesdescribing the behaviour of → as well as →∗ for the simple reason that thosecover the concepts in the designer’s mind better.For example, model checkers usually treat communication || as syntactical sugarthat can be simplified with rules like this one from ACP:X || Y = X bb Y + Y bb X +X | YMore rules follow to simplify the forms | and bb, until nothing remains but + and. operators. This is useful from the perspective of definition of semantics, but itmay be harmful for feedback from proofs. For example, the left merge operatorbb starts with an action from the left side argument, so that bb does not commute,while || does commute: That information is lost. Another disadvantage is that thestate space that describes the processes explode in size; this is the well-knownproblem of state space explosion in model checking. Retaining the || operatorPerson CompanyemployerpartnerFig. 4. Life cycles pointing to each other by way of variables.can solve this problem, and that is roughly what partiality techniques [God96]in model checkers do. Getting rid of the || operator also makes it impossible todeal with process instantiation, because a state space describing any numberof instantiations must be infinite-sized. The translation of derived operators to‘base’ operators is useful to establish the derived operator’s semantics, so thatadded syntax does not lead to ambiguity. In conclusion, we prefer a richer syntaxand non-orthogonal proofs over terse rules applied to a terse syntax.Termination of proofs. A problem of theorem provers is that they risk endingup in infinitely recursive proofs, by instantiation a quantor introduction ruleover and over again. When the level of reasoning is that of logic, it cannotbe foreseen how many instantiations of such introduction rules are needed tocomplete a proof. We expect that the added knowledge of life cycle semanticsmakes it possible to constrain the number of subsequent introductions and stillcover most practical applications.As explained before, a life cycle instance refers to other life cycle instances. Thismeans [Rei00] [Kri94] that something like an entity-relationship diagram can beinferred from a life cycle definition. For example, the process references for theexample of this paper are given in Fig. 4.Our proposal is to constrain the class of solvable problems for now:A theorem prover only needs to find proofs for which it traverses everyrelation between life cycles at most once.Since the number of arrows from and to a life cycle L is known, it is possible toset a maximum to the number of instantiations of every quantor introductionrule of the form ∀l : L · . . . and therefore, the number of instances reasonedabout is also constrained, like in model checking, but the difference is that thoseinstances can now be treated as general cases that describe the behaviour ofevery single instance.We think that most practical applications lie within the boundaries endowedby the constraint on solvable problems. Our use of parameters to match eventoccurrences allows a set of life cycle instances to respond simultaneously, thustaking care of most set updates. Among the unsupported set updates are thosefor which the sets require a transitive closure, like when an employee wishes toaddress all managers bossing him around. These problems also occur in SQL,where they are only rarely missed. Since we know of no other limitations, weexpect that our boundaries on provable problems allow verifications on a usefulclass of problems.3 Towards a new Behavioural LanguageModel checkers usually use a language called CTL [Eme90], or the slightly moregeneral µ-calculus, to represent behavioural expressions. CTL allows quantifica-tions over different paths to the future and over different moments on such paths.Several variations on CTL exist; we specifically like ACTL [DNFGR93], becauseit adds knowledge of the actions that cause a state transition, while CTL onlyconsiders the from and to state of a transition. As explained before, we prefer anrich language over a minimal one, to enhance the producible feedback; we evenallow multi-actions [Bla96] (which we shall call multi-events) on each transition.Something that we need to add to a model checking language is quantificationover instances of a life cycle L. For the rest, we shall try to be compatible withCTL or ACTL. We are currently defining a Behavioural Inference Logic for Lifecycles, or Bill for short, that captures all such concepts.Let s be a state name. Let v be a variable name (bound by a quantor), thena parameter list p is a comma-separated list of variable names. An event canbe written as e(p), and a multi-event m as a set of |-separated events. Then anexpression in Bill takes the following form:B ::= v = v′| v@s| v†| ¬v| B ∧B′| [m] B| ∀v : L ·BAnd the usual derived forms ∨, ∃, ⇒, and 6=. The form v@s is a test whether vis (at the considered moment) in state s. The form v† is a test whether v is notan existing instance (it is either in the start state or in the end state). The form[m] B is a test that B holds after all possible occurrences of multi-event m. Theremaining forms are defined as usual.A transition like the birth of a Person can be modelled in Bill as follows:∀p : Person · p† ⇒ [birth(p)] p@SingleIn words, when a Person, say p, does not exist, then the event birth(p) will createit in the Single state.The semantics of each life cycle L can be formulated in a Bill expression CL.There may also be assumptions A and expectations E for a system composed oflife cycles. The task of the theorem prover is to prove thatA ∧∧LCL ⇒ EIf this does not hold, good feedback must be provided. Errors can be repairedby altering any of the components of the above proposition: An error can berepaired by altering the life cycle diagrams, or by lowering expectations, or bymaking assumptions explicit.Our current work is to set up a theory to reason at the level of Bill and to proveit sound and (for the selected class of problems) complete; this can then be usedto tell a theorem prover how to reason at the level of Bill.Example 1. Given the transitions on a Person, or CPerson in the formal model, itshould be possible to derive a Bill expression E like:∀p : Person · ¬p† ⇒ in some future state, (p@Married ∨ p@OverWorked)where the form ‘in some future state’ is a CTL styled operator that we shall notget into here.Example 2. Given the birth transition above, and given the absence of a birthtransition elsewhere in the Person life cycle, the following constraint specifiesthat identities are unique:[ birth(p) ] [ birth(q) ] p 6= qTwo distinctly birth event occurrences for p and q imply that they must representdistinct instances. Intuitively, this is quite clear, and formally it is easy to see too.However, describing such knowledge at a purely logical level is very complicated,because it is much harder to find and to formulate this particular case. Thegenerality of the logical level comes at the price of harder specification; at thelevel of Bill, it is often more straightforward to see a truth.4 Related WorkA lot of excellent research has been performed in the field of model checking[McM93] [BCM+90], but it is focussed on hardware verification. This meansthat is optimised for processes with fixed numbers of instances, quite unlikesoftware processes.There has been interesting work on verification of software with theorem provers[Spe99], but it suffers from feedback which is unusable in practice.5 ConclusionThis paper introduced our planned approach to process verification based on ourprocess language called life cycles. It is our intention to support verification onlife cycles in such a way that useful feedback can be generated, and we decidedto use a theorem prover to do this.Our preliminary conclusions are that it is important to conduct such proofs onthe level at which a designer thinks and specifies. This means that the proof toolrepresents intermediate proofs in a syntax to which the designer can relate. Italso means that the proof rules are proof steps that a designer would have mademanually.This relatively high level contains information to guide the proof strategy throughdecisions that would not be possible at a lower, logical level. Furthermore, a highlevel proof makes it possible to generate more useful feedback to a designer. How-ever, to allow useful feedback, we have to prefer a rich syntax over a minimalone, and express rules with semantical overlap. The disadvantage of such a setof proof rules is that it cannot be designed to be terse and orthogonal.We introduced a class of problems that we intend to address; we believe this classto be of practical use, and we explained why we believe that theorem proverscan complete all proofs for this class of problems in finite time.We introduced a behavioural language named Bill, which will hopefully permitus to let a theorem prover reason at the level of life cycle behaviour.Acknowledgement. I wish to thank Maarten Fokkinga for his constant feedbackand guidance of my work.References[BCM+90] J.R. Burch, E.M. Clarke, K.K. McMillian, D.L. Dill, and J. Hwang. Sym-bolic model checking: 1020 states and beyond. In LICS, 1990.[Bla96] J.O. Blanco. The State Operator in Process Algebra. PhD thesis, Eind-hoven University of Technology, 1996.[BW90] J.C.M. Baeten and W.P. Weijland. Process Algebra. Cambridge UniversityPress, 1990.[DNFGR93] R. De Nicola, A. Fantechi, S. Gnesi, and G. Ristori. An action-basedframework for verifying logical and behavioural properties of concurrentsystems. In Computer Networks and ISDN Systems, volume 25, pages761–778. North-Holland, 1993.[Eme90] E.A. Emerson. Temporal and modal logic. In J. van Leeuwen, editor,Handbook of Theoretical Computer Science, Volume B: Formal Models andSemantics, pages 995–1072. Elsevier Science Publishers, Amsterdam, TheNetherlands, 1990.[God96] P. Godefroid. Partial-Order Methods for the Verification of ConcurrentSystems — An Approach to the State-Explosion Problem. LNCS 1032.Springer, 1996.[Hoa85] C.A.R. Hoare. Communicating Sequential Processes. Prentice Hall, 1985.[Kri94] G. Kristen. Object Orientation: The KISS Method: From InformationArchitecture to Information System. Addison-Wesley, 1994.[McM93] K.L. McMillian. Symbolic Model Checking. Kluwer Academic, 1993.[Rei99] R. van Rein. Protocol-safe workflow support for Santa Claus. In A. Val-lecio, J. Hernández, and J.M. Troya, editors, ECOOP’99 Workshop onObject Interoperability. Universidad de Málaga, Dpto. Lenguajes y C. dela Computación, 1999.[Rei00] R. van Rein. Specifying processes with dynamic life cycles. In Proceedingsof the CAiSE*00 conference, pages 190–208, 2000.[Spe99] D. Spelt. Verification Support for Object Database Design. PhD thesis,University of Twente, Sep 1999.

An action-based framework for verifying logical and behavioural properties of concurrent systems.

Communicating Sequential Processes.

Object Orientation: The KISS Method: From Information Architecture to Information System.

Partial-Order Methods for the Veri of Concurrent Systems | An Approach to the State-Explosion Problem.

On Practical Verification of Processes

Abstract

Similar works

Full text

Available Versions

University of Twente Research Information

NARCIS

NARCIS

University of Twente Research Information