an adequate management of software developments, an e cient proof support, ... We specify a communication of two components via a bu ered FIFO-channel.
VSE: Controlling the Complexity in Formal Software Developments Dieter Hutter, Heiko Mantel, Georg Rock, Werner Stephan, Andreas Wolpers1, Michael Balser, Wolfgang Reif, Gerhard Schellhorn, and Kurt Stenzel2 1
German Research Center for Arti cial Intelligence (DFKI),Stuhlsatzenhausweg 3, 66123 Saarbrucken, Germany, email: @dfki.de 2 Abt. Programmiermethodik, Universitat Ulm, D-89069 Ulm, Germany, email:@informatik.uni-ulm.de
Abstract. We give an overview of the enhanced VSE system which is a tool to formally specify and verify systems. It provides means for structuring speci cations and it supports the development process from the speci cation of a system to the code generation. Formal developments following this method are stored and maintained in an administration system that guides the user and maintains a consistent state. An integrated deduction system provides proof support for the deduction problems arising during the development process.
1 Introduction
The reliability of complex software systems is becoming increasingly important for technical systems. Malfunctioning of software systems caused by design aws or faulty implementations may lead to loss or garbling of data, breach of security, danger to life and limb, and, in almost all cases severe economic losses. In order to allow for an industrial development of software according to the highest IT security criteria (ITSEC), the VSE tool [5] was developed on behalf of the german agency BSI from 1991 to 1994. It aimed at a thorough support in all phases of a formal development methodology. This includes in particular an adequate management of software developments, an ecient proof support, and a sophisticated user interface. After a period of evaluation in various large applications (e.g. a booking system for radio transmissions, an access control system for nuclear power plants, and a security model for digital signatures), VSE [5] is now applied in a commercial formal development. Based on these experiences, the VSE tool is now enlarged and extended with respect to comprehensive methods in order to deal with distributed and concurrent systems [9] and with respect to an even more ecient and uniform proof support which makes use of the implicit structuring of the arising proof obligations. A re ned correctness management allows for an evolutionary software development without proving everything from scratch again. Again the development of VSE-II is accompanied by case studies, where for instance the safety critical part of a robot control system working in a fusion reactor is re-developed [8]. We have formalized a smaller case study in VSE-II, presented in the next section, as a running example in this paper.
2 Example Speci cation We specify a communication of two components via a bu ered FIFO-channel with a nite capacity (see Figure 1). The producer creates arbitrary values (using the internal variable x), and sends them to the channel component along in. If the capacity max of the internal bu er q of the channel is not exceeded, the channel receives these values and stores them into the bu er. The channel eventually transmits received values according to the FIFO principle along out to the consumer. The consumer receives these values, stores them in y, and uses them in some computation speci ed elsewhere. As illustrated in Figure 1, producer, channel, and consumer work concurrently and are speci ed as separate entities using pseudo code. The components h1_in loop: computation of x loop: if sig1 = ac1 then send(x,in,h1_in,sig1)
h3_out
h2_out in sig1 ac1
loop: if sig1 /= ac1 and length(q) < max then enq(in,h2_out,ac1) if sig2 = ac2 and length(q) > 0 then deq(q,out,h2_out,sig2)
out sig2
loop: if sig2 /= ac2 then read(y,out,h3_out,ac1) z:= compute(y)
ac2
Fig. 1. Producer{Channel{Consumer exchange data in a classical way of handshaking: A sender informs a receiver that a value has been transmitted by a signal (using sig1 or sig2). A receiver informs a sender that a value has been received by an acknowledge (using ac1 or ac2). send(x,in,h1 in,sig1) denotes an atomic action which writes the value of x to in, updates the history variable h1 in, and signals along sig1. Similarly enq, deq, and read denote atomic actions. The variables h2 out, and h3 out are history variables which store the former values of out. As we have to verify, the protocol implemented by the communication through these channels will guarantee that no values are lost. Thus, we formulate an invariant property for the communication between the producer and the consumer as 9l:h1 in = l h2 out. Intuitively, this states that the history of the values sent by the channel is always a post x of the history of the values sent by the producer.
3 Development Graph VSE is based on a methodology to use the structure of a given speci cation (e.g. parameterisation, actualisation, enrichment, or modules) to distribute also the deductive reasoning into local theories. Each theory is considered as an encapsulated unit, which consists of its own deductive system and its local theory. Relations between di erent theories, as they are given by the model-theoretic structure of the speci cation, are represented by di erent links between theories.
Each theory maintains its own set of consequences or lemmata obtained by using local axioms and other formulas included from linked theories. This method of a structured speci cation and veri cation is re ected in the central data structure of a development graph (see Figure 2), the nodes of which correspond to the units mentioned above. It also provides a graphical interface for the system under development. Di erent types of speci cations are displayed as di erent types of nodes, e.g. abstract data types as hexagons, while the relations between the nodes are displayed as links in the development graph. Lists (Lists ) and queues (Queues ) are generic speci cations parameterised with speci cation Elems. Channel Data LQs unites actualisations of lists and queues, the actual parameter being Channel Datas. The speci cations of lists and queues are hierarchically structured; the basic speci cations Basic Lists and Basis Queues contain freely generated types for which axioms (and executable code) are generated automatically. These basic speci cations are enriched by additional functions and predicates. Color and Label are special abstract speci cations which de ne enumeration types. A set of prede ned speci cations| Naturals and Boolean in the example|is also provided. State machines are speci ed with the help of temporal logic constructs (see section 5). The state variables take values from the abstract datatypes used by the state machine: the channel uses the theory Queues for its internal bu er. State machines are shown as octagons in the development graph, e.g. Producer, Channel or Consumer in Figure 2. These three state machines are composed to the state machine Combined Producer Consumer by identifying the input and output variables of each component, and hiding the internal communication variables. The Safety Model contains properties which have to be satis ed by Combined Producer Consumer.
Fig.2. screen-shot of development graph
4 Functional Modelling VSE supports the development of functional systems using algebraic speci cations. Elementary algebraic speci cations contain sorts, functions, and predicates; the intended semantics of the operations is de ned by axioms in full rst order predicate logic. Additional language constructs allow for the formulation of generation principles to de ne inductive data types. For frequently used \basic" speci cations (freely generated data types), axioms and ADA or C code are automatically derived. Elementary algebraic speci cations can be combined using the structuring operations non-disjoint union, enrichment, and actualisation of speci cations. These structuring operations allow the independent (modular) re nement of algebraic speci cations [12]. THEORY Lists PURPOSE "parameterised list type" PARAMS Elems USING Basic_Lists[elems] FUNCTIONS append : list, list -> list PREDICATES is_empty : list VARS l, l1, l2 : list AXIOMS FOR append : DEFFUNC append(l1, l2) = IF l1 = nil THEN l2 ELSE cons(first(l1), append(rest(l1), l2)) FI FOR is_empty : is_empty(l) l = nil THEORYEND
Fig.3. example algebraic speci cation of lists
In Figure 3 the speci cation of lists is given as an example. The basic speci cation Basic Lists is used and additional operations append and is empty are de ned. Axioms for the operators can be written as arbitrary rst order formulas or in an algorithmic style (DEFFUNC ), the latter enabling the deduction unit to automatically derive tting induction orders. Re ning algebraic speci cations in VSE is done by de ning modules which contain functions and procedures of an imperative programming language. These functions and procedures implement the operations of an export relative to an import speci cation. The correctness of a re nement is guaranteed, if the automatically generated proof obligations can be shown. One set of proof obligations is concerned with termination of each function and procedure, another set demands conformity with the axioms of the export speci cation. The proof obligations are expressed in Dynamic Logic [10], [11]; main tactics for proving the obligations are symbolic execution and induction. The proof component uses heuristics to highly automate the deduction process. As the operations of the import speci cation of a module are usually not directly available in any machine or programming language, the programs are sometimes called abstract programs. At the end of the development process, the entire re nement structure is automatically translated into ADA or C code. Not
every operation of the speci cation has to be formally re ned. Instead, formal development of programs can be integrated with conventional development by mapping operations onto conventionally designed programs. Implementations for prede ned data types (naturals, sets, arrays, etc.) are provided.
5 Speci cations of Concurrent Systems 5.1 Elementary Speci cations For the speci cation of state transition systems (see Producer, Channel (see Figure 4) and Consumer in section 3), a speci cation language close to TLA [1,7,2] is used. In addition to the theory of compositional development presented in [2], which covers the composition of systems using input and output variables, shared variables are supported by the structuring operators in VSE-II (see section 5.2). The form of a speci cation of a component, discussed in [2], is
9 x1; : : :; xn:(INIT ^ 2[POSSIBLE-STEPS]v ^ FAIR); where POSSIBLE-STEPS are the steps made by the system, v is the stuttering
index, which contains (a part of) the ( exible) variables of the system, and FAIR stands for the fairness requirements of the system.
5.2 Structuring of Speci cations
In VSE-II we provide two operators to structure state-based speci cations: combine and include. In this paper we focus on the combine-operator which mod-
els the concurrent execution of two components. As can be seen in Figure 2, the Combined Producer Consumer state machine consists of the composition of the state machines Producer, Channel (shown in Figure 4), and Consumer. Concurrency is modeled by considering all possible interleavings of actions of the combined systems. Basically a behavior , which represents a sequence of states of the speci ed system, is a behavior of the combined system if and only if it is a behavior of every component of the system. However, in order to model the concurrent execution of, say S1 and S2 , by conjunction, we have to allow environment steps in the (local) speci cations of S1 and S2 . In [2] environment steps are modeled by stuttering. This technique only works for communication by input-output variables, not in connection with shared variables. A more general approach is to associate a \color" with each component and to mark each step in a behavior by the color of the component which has done the step. The (canonical) speci cation is then changed to:
2(((POSSIBLE ? STEPS) ^ color = mycolor ) _ color 6= mycolor ); where color is a variable and mycolor is a constant. The colors itself are hidden after the composition and not externally visible. So the external behavior remains the same.
TLSPEC Channel PURPOSE "Channel for data transmission from producer to consumer" USING BOOLEAN;NATURALS;Colours;Labels;Channel_Data_LQs DATA IN sig1,ac2 : bool IN in : channel_data OUT ac1,sig2 : bool OUT out : channel_data OUT h2_out : list INTERNAL at : label INTERNAL q : queue ACTIONS Init_Channel ::= ac1 = T AND sig2 = T AND q = emptyqueue AND h2_out = emptylist Channel_Action3 ::= out' = out AND sig2' = sig2 AND h2_out' = h2_out AND ac1' = ~ ac1 AND q' = enqueue(q, inn) ... /* Assumptions made by the channel about the producer. */ ASSUME ... (sig1 /= ac1 -> inn' = inn) ... SPEC INITIAL Init_Channel TRANSITIONS [..., Channel_Action3, ...] {q, sig2, out, h2_out, ac1} HIDE q TLSPECEND
Fig. 4. A part of the channel speci cation from Figure 1.
As mentioned before communication can be modeled by in/output variables as well as by shared variables. This communication relies on the fact that several systems can read or write the same variable(s). The second operator for the composition of systems, say S1 and S2 , is include. S1 include S2, represents a mechanism to provide certain functionalities which are often used in the speci cation of systems without re-specifying them. It allows furthermore for a hierarchical composition of state machines. The semantics of S1 include S2 is S1 ^ S2 . The steps of S2 in the composed system are not left open but the actions of the system S2 occur now in the system S1 . In this way the externally visible behavior of S1 is also determined by the system S2 . This composition style can end up in a inconsistent system. So proof obligations arise which have to be proved in order to assure the consistency of the composition.
6 Proof Engineering In order to tackle arising proof obligations there is a need for a structured deduction decomposing large proof obligations into simpler tasks and synthesizing
an overall proof from the arising partial solutions. This enables the use of specialized methods to solve speci c problems and also eases the speculation of lemmata needed to prove the theorem. Furthermore, the use of proof strategies
(like e.g. [11,9]) based on specialized logics like Dynamic Logic [10] for sequential programs or TLA [7] for reactive and concurrent systems allows for an adequate representation of speci cations and arising proof problems. In VSE the knowledge about how to tackle speci c proof situations is encoded into a bundle of individual tactics. The accumulation of various tactics imposes an emerging functionality which is able to prove complex theorems in a goal directed way. All these tactics operate on a common representation of the actual proof state which is re ected in a proof tree annotated by additional tactical knowledge. This proof tree is visualized to allow the user to give strategic advise following the direct manipulation paradigm. Tactics may prune or re ne this proof tree and represent the algorithmic part of the proof search. In VSE proof decisions can be withdrawn by backtracking steps chronologically as well as by pruning arbitrary branches of the proof tree. The approach combines a high degree of automation with an elaborate interactive proof engineering environment. VSE uses annotated terms [4] as a framework to maintain various planning information during an actual proof search. They provide a simple mechanism to propagate knowledge arising within the proof search. Within this framework tactics are able to communicate their achievements to following tactics and the progress of the proof is represented by a syntactical representation of di erences between the actual state and possible goal states. Consider for instance our example illustrated in Figure 2. In order to verify that all data sent by the producer will be either stored in the local queue of the channel or will be read by the consumer we have to prove that speci c properties of these components remain invariant. This obligation is decomposed into a proof that the initialization guarantees the invariant and that each action will preserve the invariant. The latter can be formalized as follows: Action(X; X ) ! (Inv(X ) ! Inv(X )). In order to tackle such a proof obligation we use a proof technique which is divided into two steps: First, appropriate rewrite rules are synthesized from Action(X; X ), the right hand sides of which do not contain any primed variables and allow us to remove occurrences of primed variables in Inv(X ). Second, Inv(X ) is analyzed for occurrences of primed variables guiding the appropriate selection of the computed rewrite rules. This gives rise to an elaborated case analysis in order to deal with the conditionals of the rewrite rule. Proving the individual cases we distinguish two cases: In the rst case where the selected rewrite rules contain non-primed variables in their value-part, we try to reduce Inv(X ) to Inv(X ) which is done with the help of annotated terms [4] allowing for an explicit representation of the di erences between both. In the second case, where no unprimed variables are introduced by applying the rewrite rules, the proof has to be done from scratch without using Inv(X ). Often the attempt to prove a lemma or proof obligation fails and detected errors in the speci cation or implementation have to be corrected. In VSE an elaborate correctness management supervises the application of corrections and invalidates only those proofs which really are a ected by the modi cations. Furthermore, invalid proofs can be automatically reused [13]. 0
0
0
0
0
0
0
7 Conclusion VSE enables large software projects to be formally developed. It supports the whole development process from system speci cation to executable code. Functional systems as well as state based reactive concurrent systems can be speci ed. Systems are designed using an elaborate graphical environment. The structure of a system is displayed as a development graph. The structuring operations ensure that speci cations can be separately re ned and properties can be proved locally to its components. Powerful proof support for arising proof obligations is provided. An elaborate correctness management and automatic proof reuse simplify the iterative process of (failed) proof attempts. Altogether VSE is a tool which makes it possible to use formal methods for the development of high assurance systems in an industrial context.
References 1. M. Abadi and L. Lamport: The existence of re nement mappings. Theoretical Computer Science, North Holland, Elsevier Science Publishers B.V., 82(2):253{284, May 1991. 2. M. Abadi and L. Lamport: Conjoining speci cations. ACM Transactions on Programming Languages and Systems, 17(3):507{534, May 1995. 3. D. Hutter: Hierarchical proof planning using abstractions. 10th FLAIRS'97, Daytona Beach, Florida, 1997 4. D. Hutter: Colouring Terms to control equational reasoning. Journal of Automated Reasoning, Kluwer-Publishers, Vol. 18, pp. 399-442, 1997 5. D. Hutter, B. Langenstein, C. Sengler, J. H. Siekmann, W. Stephan, A. Wolpers: Deduction in the Veri cation Support Environment (VSE). In Marie-Claude Gaudel and James Woodcock, editors, Proceedings Formal Methods Europe 1996: Industrial Bene ts and Advances in Formal Methods. Springer-Verlag, Berlin, Germany, 1996. 6. IT-Sicherheitskriterien. Bundesanzeiger, 1989. 7. L. Lamport: The temporal logic of actions. ACM Transactions on Programming Languages and Systems, 16(3), 1994. 8. G. Rock, W. Stephan, and A. Wolpers: Assumption{commitment speci cations and safety-critical systems. In Tagungsband 8. GI/ITG-Fachgesprach Formale Beschreibungstechniken fur verteilte Systeme, 1998. to appear. 9. G. Rock, W. Stephan, and A. Wolpers: Modular reasoning about structured TLA speci cations. In Proceedings TOOLS'98, 1998. to appear. 10. R. Goldblatt: Axiomatising the logic of computer programming. Springer LNCS 130, 1982. 11. M. Heisel, W. Reif, and W. Stephan: A Dynamic Logic for program veri cation. In A. Meyer and M. Taitslin, editors, Logical Foundations of Computer Science. Springer LNCS 363, 1989. 12. W. Reif. Correctness of generic modules. In Nerode and Taitslin, editors, Symposium on Logical Foundations of Computer Science. Springer LNCS 620, 1992. 13. W. Reif and K. Stenzel. Reuse of proofs in software veri cation. In R. Shyamasundar, editor, Foundation of Software Technology and Theoretical Computer Science. Proceedings. Springer LNCS 761, 1993.
