Limitations of Formal Methods and An Approach to ... - Semantic Scholar

Limitations

of Formal Methods Improvement

and An Approach

to

Shaoying Liu*and Rolf Adams Faculty of Information Sciences Hiroshima City University 151-5, Ozuka, Numata-cho Asaminami-ku, Hiroshima 731-31, Japan [email protected] [email protected]

Abstract Software development using formal methods is believed to be a process of successive refinements from abstract specifications into concrete specifications. Refinement rules rnag be used to demonstrate that the concrete specifzcations satisfy the corresponding abstract ones. However, there are serious Iimitations of the refinement rules in both theory and in practical applications. This paper first uses examples to demonstrate the limitations, and then proposes a new software development model for improvement based on our experience. The limitations include that (1) the refinement rules are not suficient to guarantee that a refined specification (or concrete specification) satisfy the user’s real requirements if it satisfies the abstract speci’cation, (2 the existing rejlnement rules are not always applica l/le in theory during the successive refinements, (3) the refinement rules are difficult to be applied effectively in practice due to various kinds of uncertainties and resource constraints. The proposed model suggests that system development using formal methods should be divided into two phases: a static development phase and a dynamic development phase, the whole process in each phase involving requirements analysis. In order to suit the new model, the existing refinement rules are modified.

/

Formalpmofs

Introduction

supported by a grant (A424) of Hiroshima City University,

from the Special ReJapan

498 O-8186-7171-8/95

$04.00

using

specification is then transformed into a real system i.e. program) by a sequence of refinements. Each reB nement transforms an abstract specification (which includes more information on what to do but less information on how to do it) into a concrete specification which includes more information on how to do it). A Lormal proof demonstrates statically that a concrete specification satisfies its corresponding abstract specification, while testing demonstrates dynamically that the program satisfies the user’s real requirements. Based on the model of the software life-cycle, the process described in Fig 1 can be understood as follows. The ‘User Requirements is the result of requirements analysis and is normally described in informal

Systematic software development using formal methods is believed to be a process of successive refinements from abstract specifications into concrete specifications [27]., as shown in Figure 1. The top level abstract specification is derived from the user requirements by means of formalisation, and its correctness must be validated in agreement with the user. This *Partially search Fund

j

:

Figure 1: The process of software development formal methods

Keywords: Formal methods, specifications, refinement, formal proofs, system development model.

1

Refinement

0 1995 IEEE

Proceedings of the 1995 Asia Pacific Software Engineering Conference (APSEC '95) 0-8186-7171-8/95 $10.00 © 1995 IEEE

’

model is put forward in this paper. The principle of this model is that system development using formal methods should be divided into two phases: static and dynamic development, and the whole process in each phase involves requirements analysis. Static development is a process of developing the system without excuting it while dynamic development is a process of developing the system via executing it. In the static development, not only does the abstract specification serve as the basis for the subsequent refinements and formal proofs, but also the user should be treated as part of the basis for providing decisions which need to be taken during the refinement. In the dynamic development, prototyping and testing (or simulation) are considered as being necessary. The static and dynamic development complement rather than exclude each other. We believe that this model provides an effective approach for formal software development, and will therefore be able to have a strong impact on the industrial practice of formal methods. The remainder of this paper is organized as follows. Section 2 analyses the limitations of formal methods in the three aspects: specification, refinement and formal proof. Section 3 discusses the limitations of formal methods in practical applications. Section 4 describes a new formal software development model. Finally, section 5 summarizes our contributions presented in this paper and points out further research. To make the paper concise, we assume that the reader of this paper understands VDM notation [15].

language (e.g. English). ‘Specificationi’ corresponds to the stage of functional specifkation, and from ‘Specification,’ to ‘Specification,’ corresponds to the stage of design. The refinement from ‘Specification,’ into ‘Program’ corresponds to the stage of irnplementation, or coding. Note that this model does not exclude the case of directly refining the Specification, to the program (or any level specification) and the iterative feature of software development process, but emphasizes that a complex software development should be completed by successive refinements and each feedback from the lower level specification must only refer to the immediate abstract specification level. There are three questions about the formal development process. The first is whether the existing refinement rules can be used to guarantee (via formal proof) that a concrete specification, as the result of a refinement, will satisfy the user’s real requirements if it satisfies its abstract specification which is approved by the user. The second question is whether the existing refinement rules are applicable throughout the whole process of successive refinements. Finally, is the formal development principle applicable in practice? Many people have discussed the limitations of formal methods, see [3, 28, 19 , but they mainly explored the practical limitations eit ll er caused by the quality of formal specifications (e.g. readability, structure, precision) or practical constraints (e.g. time, budget, staff training, difficulty in formal proofs). There seems to be an illusion that formal proofs can replace software testing if the formal proofs can be done completely and correctly for the whole system under development. It also appears to be largely believed that currently formal proofs cannot replace software testing in practice only because formal proofs for large projects are too complicated to conduct [6], Little attention has been given to identifying the theoretical limitations of formal methods and their consequences in practical applicat ions. In this paper we discuss extensively the limitations of formal specifications, refinements, and formal proofs in their capability from both practical and theoretical angles, since these three activities are the heart of the principle of formal system development. The exploration of theoretical limitations will be focused on refinements and formal proofs. Examples related to VDM [15] are used to demonstrate that the existing refinement rules are not sufficient to guarantee that (1) a concrete specification satisfies the user’s real requirements if it satisfies its abstract specification which is approved by the user, (2) the refinement rules are not always applicable in theory during the successive refinements, (3) the refinement rules are difficult to apply in practice due to various kinds of uncertainties and resource constraints. As a result of this analysis, we will clarify the relationship between formal proofs and software testing. Our conclusion is that formal proofs cannot replace software testing in general, especially for large and complex system development. We believe that this conclusion is universal rather than only applicable to VDM. In order to overcome the limitations and deficiencies of formal methods, a formal software development

2

Limitations

of Formal

Methods

Since the key activities which formal methods require are specification, refinement and formal proof, we will focus on the discussion of the limitations of these three aspects in this section. 2.1

Limitations

of Formal

Specifications

Formal specifications are believed to be able to record the precise software requirements, to allow the formal reasoning about the specifications, and to serve as a firm basis for the subsequent software development [15, 71. However, there are several limitations in achieving accurate and complete requirements specifications with respect to the user’s requirements. Firstly, formal methods are expected to help software developers construct precise requirements specifications in order to capture the real requirements from users, but there is no general principle in theory of how to acquire requirements from the user and then how to record them using a formal specification language. The difficulty is that there is usually a substantial gap between the real world and the formalism, and the transformation from the user’s informal requirements to a formal specification involves considerable clarification of the problem. Secondly, the specification may be precise, but not necessarily accurate with respect to the user’s real requirements. For example, in a formal specification the output variable y is specified in terms of the input variable t as 2, = x + 1, where both y and z are defined as real number variables. However, this precise definition may not reflect the user’s real requirements which

499


achieve precise and logically consistent requirements, but cannot guarantee their accuracy. Also, formal specifications in practice can help to improve the common understanding of the requirements by different individuals with differing background and knowledge, but cannot guarantee the quality of the understanding. 2.2 Limitations of Refinements A refinement is the process of transforming an abstract specification into a concrete specification. It must be justified by using a reasonable refinement rule to demonstrate that the concrete specification satisfies its abstract one. It seems that there is a common understanding about what this rule should be, but different people express it slightly differently, see [15, 29! 221. Some expressions of the refinement rule do not indicate explicitly the relation between abstract data and concrete data, while some others give consideration to this point. The most well-presented refinement rule is described by Jones in [15]. This rule includes several obligations on data reification and operation refinement, but the following three are useful for our discussion:

1. This situation might be caused by maybey=x(1) misunderstanding(s) between the analyst and the user, (2) a lack of the accurate abstract system model of the real system concerned, (3) mistakes made by the user in providing requirements for the system to be developed, (4) mistakes made by the analyst during recording the user’s requirements. Unfortunately, there is so far no effective way to ensure that the precise specification must be the accurate one satisfying the user’s real requirements. Thirdly, formal specifications are expected to ensure the common understanding of the user’s requirements by both the user and the developers due to mathematically-based notations. However, this seems unlikely always to be true in practice. The reason is that formal specifications do not just have an interpretation in terms of the underlying mathematics, they are also interpreted by the developers in terms of a computational model and by system users in terms of a model of the use of the system in its operational environment. The issue of ambiguity then becomes not one of the existence of a unique model for the specification in the underlying logic, but of compatibility of interpretations made in different domains by individuals with differing backgrounds and knowledge. For example, in a specification the variable staff number is defined as a natural number variable and is used to represent the number of all the full time staff in a department. But the user may understand that this variable represents the number of all the full time and part time staff in the department because the user has a different concept of staff from the developer. In addition, professionals within the software industry usually find it difficult to understand formal specifications due to their abstraction and complexity, and therefore cannot always guarantee to understand the specifications correctly. This problem may be exacerbated for some users. Finally, research shows that the specification cannot be completed with respect to the user’s real requirements until the desired system is implemented [4, 171. In fact, the whole process of software development must involves requirements analysis, even if the requirements specification is precise. In this case, the formal specification cannot serve as a unique basis for the subsequent software development. The user, as well as the background knowledge of the real system concerned (e.g. its abstract system model, operational environment model, and operational constraints), must be treated as another important part of the basis for the subsequent software development (this point will be described in detail in section 4). The main contribution formal methods can provide for quality software development is to assist developers to gradually understand, clarify and express the user’s real requirements, and to formally verify that the real requirements are met by the desired system. This contribution can be achieved by means of successive refinements involving the three activities: constructing specifications, refining abstract specifications into concrete specifications, and proving the correctness of refinements. In summary, formal specifications can help to

Proof obligation 1: v aEAbs ’&Rep ’ retr(r)

= a

where Abs and Rep represent the abstract data type and its reified data type, and retr is a retrieve function from Rep to Abs. This proof obligation is called the adequacy obligation. It states that for every value in the abstract data type, there must be one concrete value in the reified data type such that the concrete value represents the abstract value. Based on the adequacy obligation, proof obligation is given as follows:

an operation

Proof obligation 2: (1) The domain rule: (2) The result rule: s pre-OP(retr(tir))

‘7 TER posi-OP(retr(f),

A post-O&(c5;-,

T) x=+

retr(r))

where R is the input domain of the operation OPl that is a refinement of the operation OP, pre-OP and post-OP represent the pre-condition and the postcondition of the operation OP. The domain rzlde requires that if the pre-condition of the abstract operation OF’ is true of a retrieved state, then the concrete state must satisfy the precondition of the concrete operation OPl. The result rule requires that any pair of states in the post-OPl relation must - when viewed under the retrieve funcrelation. The rationale for tion - satisfy the post-OP the Proof obligation 2 is described in [I5]. However, the refinement rule above is not sufficient, in both theory and practice, to guarantee that the concrete specification OPl will satisfy the user’s real re-

500


It may be arguable that the refinement from SQUARE-ROOT to either SQUARE-ROOT1 or SQUARE-ROOT2 should be treated as part of completing the specification of operation SQUAREROOT rather than a refinement. Therefore, the refinement rule should not be applied until the specification is completed. However, as explained in section 2.1, the specification cannot usually be completed until the desired system is constructed, especially for large and complex systems. We believe that it is appropriate to achieve large, complex and detailed requirements specification by means of successive refinements. If we try to complete the specification first and then do refinement, applying the refinement rule would bring trivial benefits to the quality assurance of system development. Note that SQUARE-ROOT is only a very small op eration. Evidence in large software project developments using formal methods shows that the deficiencies and the difficulty of refinement have been seriously affecting the efficacy of formal methods [I, 8, 91. We believe that this unsatisfactory situation in industrial applications can be improved by applying more effective software development models and principles as this paper is proposing (see section 4).

quirements if it satisfies its abstract specification OP, even when OP is approved by the user. Since the goal of software development is to provide a software system that not only satisfies the requirements specification, but most importantly satisfies the user’s real requirements, the justification of a refinement depending on the above refinement rule is not necessarily satisfactory. For example, suppose an operation to obtain a square root of a given real number is specified at the abstract level, which is approved by the user, as follows : SQUARE-ROOT ext rdx: R wry: R m-e x>o post y2 = x where R represents the real number type. If this operation is refined into the following operation: SQUARE-ROOT1 ext rdx: R wry: R x>o p=e post y2 = 2 A y > 0

2.3

Limitations of Formal Proofs As described previously, a refinement can be justified to ensure that the concrete specification satisfies its abstract one by formal proof using the refinement rule Proof obligation 1 and 2. We have demonstrated that the rule is not sufficient to guarantee that the concrete specification will satisfy the user’s real requirements if the rule can be applied successfully. In this subsection, we will demonstrate that the refinement rule cannot be always applied during the successive refinements. Most people may understand that this limitation is due to the resource constraints found in practice (e.g. money, time and labour), but know little about its limitation in theory. The focus of the discussion here is on the latter. Suppose the operation OPI is a refinement of the operation OP, represented by OP & OPl, the rule Proof obligation 2 can be applied to verify that OPl satisfies OP only if the Proof obligation 1 is satisfied because the former is based on the latter, as the example concerning the refinement of the operation SQUARE-ROOT shows. However, the Proof obligation 1 cannot always be satisfied during the successive refinements because the retrieve function cannot always be established. Since data is one of the essential part of specifications, satisfactory data definition can only be gradually achieved by successive data reifications with the successive refinements of operations. Each data reification not only needs to choose the concrete data type (e.g. the reification of a set of natural numbers s could be an array, linked list or tree structure of natural numbers), but must also incorporate the user’s further constraints (a kind of user’s requirement) on the data in the reified (or concrete) data definition. This feature of data reification sometimes leads to a situation that no retrieve function can be established to

it is not difficult to prove that SQUARE-ROOT and SQUARE-ROOT1 satisfy the Proof obligation 1 and 2. Since there is no data reification involved in the refinement of SQUARE-ROOT (i.e. we can build the retrieve function retr as: retr: R --+ R, retr(x) = x), the Proof obligation 1 on the adequacy of data reification is satisfied. Furthermore, Proof obligation 2 is also satisfied by SQUARE-ROOT and SQUAREROOT1 because: pre-SQUARE-ROOT pre-SQUARE-ROOT * post-SQUARE-ROOT

a pre-SQUARE-ROOT1 A post-SQUARE-ROOT1

However, the refined operation SQUARE-ROOT1 might not be the one which the user really wants. The user may require the following refined operation: SQUARE-ROOT2 ext rdz: R wry: R x>O p=e post y2 = II: A y < 0 In the same way as for SQUAREROOTl, we can also prove that SQUARE-ROOT2 satisfies SQUAREROOT. The key point here is that for the operation OP, there may be more than one concrete operation to satisfy it according to the refinement rule. A refinement of OP must choose one, and the decision on the choice must be made by the developer in agreement with the user (the user should be the ultimate authority, in theory, to make the decision). Obviously, only the refinement rule alone cannot guarantee that a right decision is made.

501


ification point of view, any set. Therefore, it is impossible to build a retrieve function from the reified data type Student to the abstract data type Student in order to ensure that for every value in the abstract Student, there must be one concrete value in the reified Student such that the concrete value represents the abstract value. Consequently, the Proof obligation 2 cannot be applied to demonstrate that QUEUE1 satisfies QUEUE. The reason is that the condition preQUEUE e pre-QUEUE1 does not hold because the real pre-condition of QUEUE1 is no longer only the pre-QUEUE1 (i.e. card 5 > 0) but the conjunction of pre-QUEUE1 and the invariant V’sel: . 0 0 elem y = x

The operation QUEUE is expected to produce a sequence of students i.e. y) based on a given set of students (i.e. z). At t L is abstract level what criterion should be used to arrange the sequence of students is not yet clear (in the developer’s mind mainly, but it may also be unclear in the user’s mind). It is expected that the criterion will become clear when the specification, especially the abstract data type Student, is reified into a concrete one. Suppose we refine the above specification into the following one: type Student =

compose Student of name: seq of char exammark: R end inv-Student(s) n 0 < exammark < 100 state State of end operations QUEUE1 ext p=e post

x: Y:

set of Student seq of Student

state State of rd z: set of Student wr y: seq of Student card x > 0 let no = len y in elem y = 2 A Vd,jE[1..7ac~ . i < j ----r. exammark(y(i)) 2 exammark(y(j))

2: y:

array[l..lOO] array[l..lOO]

of Student of Student

end operations QUEUE2 ext

rd x: array[l..lOO] of Student wr y: array[l..lOO] of Student len x > 0 pre post let no = len y in elem y = elem x A V~,j~:[1.,,,1 . i < j ti exammark( y(i)) > exammark( y(j)) where we treat record and array types as compose and seq types, respectively, in order to apply the corresponding operations on compose and seq types en, elem etc) to variables over record or array

In this refinement, the abstract operation QUEUE is refined into QUEUEl, the abstract type Student is reified into a composite type, and an associated invariant is imposed. This data reification is derived, presumably, from the user’s requirements. Due to the invariant, the reified data type Student contains a smaller number of elements than the abstract data type Student as defined in the abstract specification because the abstract Student means, from the spec-

502


mal methods [16, 181 and our investigation of the applications of formal methods in industry [19, 281, ,ye believe that the following seven classes are most critical: human ability, abstract system model, consistency of theories, tool quality and availability, management pressure, notation quality, and resource constraints. That is, these elements affect systems development using formal methods, and their quality are uncertain in practice. For the detailed analysis of these uncertainties, see [28].

In this refinement, more constraints on data are imposed, presumably in agreement with the user’s requirements. For example, the name of a student must be of less than or equal to 10 characters, while the set x (which is implemented by an array) can contain no more than 100 students, and so does the sequence y. Also, the real pre-condition of QUEUE2 is not only the pre-QUEUE2 (i.e. card z > 0) but the conjunction of pre-QUEUE2 and the constraints, as shown below : kn 2 > 0 A (VJEStudent . kn name(s) 5 lo) A lenz 1 * pre-QUEUE2

3

An Improved velopment

4.1

in Practice

Apart from the theoretical limitations of formal methods described previously, there are many uncertainties and constraints in practice to seriously affect the efficacy of formal methods. Based on our experience in large software project development using for-

503


Figure 2: The Static and Dynamic Development

model

if the high level specification S consists of the parts Sl, sz, ‘,‘, sn, and Si, for example, specifies the system behaviours concerned with the human-computer interface, then a program (or prototype) can be implemented to satisfy Si. The other parts of S can be gradually refined into corresponding subprograms either concurrently with the implementation of 5’1 (if other developers are responsible for them) or afterwards (if the same developer is responsible for them). The first priority in choosing the parts of S to be refined into a prototype is tha.t the parts are concerned with the human-computer interface of the desired system, and the second priority is their simplicity.

Dynamic development is a process of discovering dynamic features of the system under development, verifying the system against the user’s real requirements, and acquiring more requirements by means of executing the system with well-selected test cases, analysing the test results and modifying the system. Prototyping should be one of the important techniques for the dynamic development of systems. It is suitable for portraying the user’s requirements for some special features which cannot easily be obtained via formal methods exercises, such as human-computer interface, timing behaviours etc. We believe that in general it is more effective for quality software development using the combination of the prototyping technique and formal methods, especially for large and complex systems. Prototypmg can be carried out based on a formal requirements specification and the result of the prototyping may provide new information for extending or modifying the original formal specifications. For example, in order to acquire the real requirements for the human-computer interface of a system, VDM can be used to write a formal specification of the user’s informal requirements. Then a prototype can be constructed based on the specification, and a formal proof can be performed to ensure that the prototype satisfies the specification. A test of the prototype can then be conducted to confirm that the prototype has captured the user’s real taste. If it does not do so exactly, the specification must be changed to clarify and accommodate the fresh requirements from the user. The cycle of the static and the dynamic development continues until the desired system is implemented. Based on our experience, we believe that the SDD model can be used effectively for large system development if the development is incremental. That is,

The major difference between the SDD model and the existing models (e.g. Waterfall model [25], Spe’ral model [5], Formal System Development model as given at the beginning of this paper) is that the SDD model emphasizes that the requirements analysis is involved throughout the whole process of a software development. Compared with the Waterfall model and the Spiral model, the SDD model not only indicates the management features of a software development pro cess, but most importantly reflects its technical features. While compared with the existing formal development system model, as shown in Figure 1, the SDD model not only emphasizes that the high level specification is a firm basis for the subsequent development, but also requires that the user be consulted in making decisions of refinements; not only is the static development using formal methods necessary, but also the dynamic development by means of prototyping and testing is essential to achieve the dependability of systems with respect to the users real requirements.

504


Improved refinement rule In order to overcome the weakness of the refinement rule described as the Proof obligation 1 and 2 before and to suit the principle of the SDD model, the refinement rule needs to be modified to take into account the fact that the user is part of the basis for a refinement from an abstract specification into a concrete one, including data reification and operations refinement. We believe that data reification is a process of transforming abstract data types to concrete data types and of imposing invariants (or constraints) on the abstract data types, as indicated in the examples in section 2.3. According to this idea, we modify the Proof obligation 1 as follows:

data type to a set in the abstract data type which contains the exact same elements as x does. Based on the Improved proof obligation 1, an improved proof obligation 2 concerning the relationship between an abstract operation and its refined concrete operation is defined as follows: Improved proof obligation 2: (1) The domain rule: V,-ER .pre-oP(retr(r)) q pre-oPl(r) (2) The result rule:

4.2

v+ T rER . pre-OP(retr(f))

A post-OPl(F,

r) =3

posLOP(retr(f), retr(r)) This proof obligation is the same as the Proof obligation 2 in expression, but represents different requirements due to the changed definition of retr. The difference is that the proof using the Improved proof obligation 2 is restricted to the constrained input domain of OP rather than to its whole input domain. Thus, the improved proof obligation not only reflects that a concrete specification needs to satisfy its abstract one, but also indicates the relationships between the concrete specification, its abstract specification, and the user whose further requirements for data during the data reification step is reflected by the inv.

Improved proof obligation 1: v aEAba(dnv). %~Rep . retr(r) = a where Abs and Rep represent the abstract data type and its reified data type, retr is a retrieve function from Rep to Abs(inw), and Abs(inw) is the subtype of Abs in which each value (or element) satisfies the invariant inv. Note that the invariant inv, which is derived during a data reification, reflects the user’s decision on imposing constraints on the data (usually agreed by the developer, or maybe in practice it is often proposed by the developer and approved by the user). If there is no further constraints on abstract data, Abs will be the same as Abs(inw) and retr will be a retrieve function from Rep to Abs. In this case, the Improved proof obligation 1 is the same as the Proof obligation 1 given in section 2.2. That is, the former is applicable to general cases of data reification while the latter is suitable for the special case. Note that there might be the case that Abs(inw) is an empty set due to inw. This case is usually a mistake in practice unless the abstract operation is expected to have no functional behaviour. It could be difficult to obtain a correct inv due to either the complexity of data analysis or inappropriate data requirements by the user. For example, in the specification defining the operation QUEUE1 given in section 2.3, a data type is used to define the variable 2, as shown below: . set of Student When the operation QUEUE1 is refined into the operation QUEUE2, the data type is reified into the following concrete data type: . array[l..lOO] of Student Izthis case we can build an invariant inv on the abstract type Let of Student as follows: inw = V xEset of student.cardo 5 100Acardz 2 1 and a retrieve function retr from the concrete type array[l..lOO] of Student to the subtype of the abstract type set of Student which satisfies the constraint of the above invariant is defined implicitly as follows: retr(z: array l..lOO] of Student) y: {z 1 z E set of Student A inw I true pre post y = elem z A card y = len x Note that in the post-condition, y represents retr(z). This retrieve function maps an array a: in the concrete

4.3

Discussion Although the SDD model makes a progress towards practical guidelines on software development, it still seems difficult for developers to completely follow the principles the SDD model requires due to practical resource constraints according to our experience in applying the SDD model to the development of the safety alaysis support system SAM (Safety Argument Manager) [ll] . For example, in most situations, the user cannot be always involved in a formal software project development because (1) he or she may not always be available, (2) he or she may not be able to provide sensible decisions for refinements of specifications. Furthermore, formal proofs are time-intensive, and therefore may not be conducted for every part of the system. After the dynamic development phase, it may be difficult and time-intensive to incorporate the results of testing in the modifications of the specifications produced during the static development phase. Since the user may not always available and the developers may be the same as the user, applying the SDD model in practice could be as follows. The user’s role during the successive refinements at a detailed level can be replaced by the developers who are in charge of the abstract specifications. The reason for this is that the developers of abstract specifications are usually responsible to the user and are experienced at developing systems for similar application domains. Although this is not perfect, it is a practical compromise. In order to save time and follow the project schedule, formal proofs can be replaced by rigorous reviews conducted by the developers of both abstract and concrete specifications, possibly with the manager of the project concerned. Furthermore, dynamic development can be carried out in parallel with the static

505


colleagues. They include John T. Latham, K.K. Lau of the University of Manchester, John A. McDermid of the University of York, Bev Littlewood of the City University, Bruno Dutertre of RHBNC, University of London of the U.K., Chris Higgins of Griffith University of Australia, and Mitsuru Ohba, Yasuomi Sato of Hiroshima City University of Japan. We should also thank Hiroshima City University for a grant 4424) ~a~c~he Special Research Fund to support t L is re-

development in an incremental manner, as described previously. Since the rigorous reviews replace the formal proofs, the testing against the documented user requirements must be conducted before the acceptance testing, in order to discover errors which could not be discovered by the rigorous reviews.

5

Conclusions

This paper uses examples to demonstrate the lirntations of formal methods and proposes a new software development model for improvement. The limitations include (1) the existing refinement rules are not sufficient to guarantee that a refined specification (or concrete specification) will satisfy the user’s real requirements if it satisfies the abstract specification, (2) the refinement rules are not always applicable in theory during the successive refinements, (3) the refinement rules are difficult to be applied effectively in practice due to various kinds of uncertainties and resource constraints. Seven different uncertainties and constraints are identified, which are hnman ability, abstract system model, consistency of theories, tool quality and availability, management pressure, notation quality, and resource constraints. The new software development model, called the Static and Dynamic Development model, reflects the technical features of system development and provides guidelines on documentation and software management. The principle of the model is that software system development using formal methods should be divided into two phases: static development and dynamic development,, and the whole process in each phase involves requirements analysis. Static development is a process of successive refinements of requirements specifications, while dynamic development is a process of discovering dynamic features of the system under development, verifying the system against the user’s real requirements, and acquiring more requirements by means of executing the system with wellselected test cases, analysing the test results and modifying the system. Static development and dynamic development are complementary rather than exclusive in the assurance of system dependability. Further research on the SDD model will focus on the technical issues concerned with both the static and the dynamic development. The issues include (1) how to obtain, validate and express requirements for data and operations from the user during the refinement of an abstract specification, (2) how to use a rigorous review process to replace formal proofs in practice, (3) how to perform prototyping and how to validate that the prototype is satisfactory, (4) how to make use of the result of the static development phase in the dynamic development phase, and vice versa, (5) how to assess whether the developed system satisfies the user’s real requirements, (6) how to do documentation and software management. Furthermore, it is also important to research on the construction of tools supporting the model.

References

PI Stephen

Austin and Graeme I Parkin, “Formal Methods: A Survey”, National Physical Laboratory, Teddington, Middlesex, U.K., March 1993.

121R. Barden, S. Stepney and D. Cooper, “The Use of Z”, Sixth Annual l-25.

Z User Meeting,

1991, pp.

PI L.M.

Barroca and J.A. McDermid, “Formal Methods: Use and Relevance for the Development of Safety-Critical Systems”, The Computer Journal, Vol. 35, No. 6, 1992.

PI F.L.

Bauer, B. Moller, H. Partsch and P. Pepper, ‘LFormal Program Construction by Transformations - Computer-Aided, Intuition-Guided Programming”, IEEE Transactions on Software Engineering, 15, 1989.

[51 B.W. Boehm, “A Spiral Model of Software Development and Enhancement”, IEEE Computer, May 1988, pp. 61-72. Reprinted in R.H. Thayer (ed) IEEE Tutorial on Software Engineering Project Management, 1988.

PI L.

BougC, N. Choquet, L. Fribourg, M.C. Gaudel, “Test Sets Generation from Algebraic Specifications Using Logic Programming”, Journal of Systems and Software, Vol. 6, No. 4, November 1986, pp. 343-360.

Sys[71 J. Bowen and V. Stavridou, ‘Safety-critical tems, Formal Methods and Standards”, Technical Report No. PRG-TR-5-92, Programming Research Group, Oxford University Computing Laboratory, 11 Keble Road, Oxford OX1 3QD, March 1992, to appear in the Software Engineering Journal. PI David Brownbridge, “Using Z to Develop a CASE Toolset”, in Proceedings of the 1989 Z user meeting, Workshops in Computer Series, SpringerVerlag, December 1989.

PI Dan

Craigen et aZ, “An International Survey of International Applications of Formal Methods Volume 2 Case Studies”, NISTGER 93/626, 1993.

[lOI Judith

L. Cyrus, J. Daren, Paul D. Harry, “Formal Specification and Structured Design in Software Development”, Hewlett-Packard Journal, December 1991.

6

Acknowledgements The ideas presented in this paper have benefited from discussions with many our former and present

506


[ll]

[21] Cydney Minkowitz and Peter Henderson, “A Formal Description of Object-Oriented Programming Using VDM], VDM’87, Lecture Notes in Computer Science 252, Springer-Verlag, 1987.

Justin Forder et al, “SAM - A Tool to Support the Construction, Review and Evolution of Safety Arguments”, Proceedings of Safety-critical Systems Symposium 1993, Bristol, Springer-Verlag, Sth-11th February, 1993.

[12] J.S. Gourlay, “A Mathematical the Investigation of Testing”, tions on Software Engineering, 6, November 1983.

from Specifications”, [22] C. Morgan, “Programming Prentice-Hall International Ltd., 1990.

Framework for IEEE TransacVol. SE-g, No.

[23] Paul Mukherjee and Victoria Stavridou, “The Formal Specification of Safety Requirements for Storin Explosives”, Formal Aspects of Computing, 5 f 4), pp. 299-336, 1993.

[13] M.C. Gaudel and B. Marre, “Algebraic Specifications and Software Testing: Theory and Application”, Internal Report LRI 407, Orsay, France, February 1988, and extended abstract in Proceedings of Workshop on Software Testing, Banff, IEEE-ACM, July 1988.

[24] P. Naur, “Understanding Turing’s Universal Machine - Personal Style in Program Description”, The Computer Journal, Vol. 36, No. 4, 1993. [25] W.W. Royce, “Managing the Development of Large Software Systems”, In Proceedings of IEEE WESCON, 1970, pp. 1-9. Reprinted in Thayer, R.H. (ed.) IEEE Tutorial on Software Engineering Project Management, 1988.

[14] S.H. Hekmatpour and D.C. Ince, “Formal Methods, Software Prototyping and VDM”, AddisonWesley, London, 1988.[15] C.B. Jones, “Systematic Software Development Using VDM” , Prentice-Hall International, Second edition, 1990.

[26] L.T. Semmens, R.B. France and T.W.G. Docker, “Integrated Structured Analysis and Formal Specification Techniques”, The Computer Journal, Vol. 35, No. 6, 1992.

[16] Shaoying Liu and Youren Li, “Production Software Development Tool”, Journal of Computer Research and Development, Beijing, No.6, 1990.

[27] M. Van Sinderen et al, “Protocol Design and Implementation Using Formal Methods”, The Computer Journal, Vol. 35, No. 5, October 1992. pp. 478-491.

[17] Shaoying Liu, “A Structured and Formal Requirements Analysis Method based on Data Flow Analysis and Rapid Prototyping”, Ph.D thesis, University of Manchester, U.K., August 1992.

[28] 2;;~:;~

Stavridou, Shaoying Liu, Bru+no “Formal Methods and Dependablhty Assessm&t” , Proceedings of COMPASS’94 conference, Gaithersburg, Maryland, U.S.A., 27 June - 1 July, 1994.

[18] Shaoying Liu, “A Formal Requirements Specification Method Based on Data Flow Analysis”, The Journal of Systems and Software, USA, 1993;21:141-149,

[29] I%;Pa~hysall,

a chapter in th,e Engineer s Reference Book, Butterworth-Heinemann, 1993, pp. 24/g-24/10.

[19] Shaoying Liu et al, “The Practice of Formal Methods in Safety Critical Systems”, to appear in The Journal of Systems and Software, USA, 1994. [20] Shaoying Liu, “Internal Consistency of FRSM Specifications”, to appear in The Journal of Systems and Software, USA, 1995.

507


“Refinement”,