G. J. Holzmann. Designing executable abstractions. In Proceedings of the second workshop on formal methods in software practice, pages 103--108, Clearwater Beach, Florida USA, March 1998.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....is a sequence of transitions s 0 e1 s 1 e2 : en s n . In this paper, we assume that FSA based models of the threads of control are derived from the source code for the system. While construction of models based on high level descriptions is attractive and has been advocated for FSV [11], since testing is used in our approach, we need a direct mapping between the thread models and the executable code for the system. A property about a software system is a representation of either desirable or undesirable behavior of this system. We de ne properties in terms of the events ....

G. Holzmann. Designing executable abstractions. In Proceedings of the 2nd Workshop on Formal Methods in Software Practice, pages 103-108, Mar. 1998.

....in the cases when only a part of the system s behaviour is of interest 1 Introduction Model checking encounters the state explosion problem. To keep the state space manageable for model checkers, models of systems should only include features relevant to the property being checked. Holzmann[12] showed it is possible check useful properties using very small models less than 100 states. Unfortunately, it is often too expensive to manually create a separate model for each property to check. Thus, a single model of a system must be used to verify many different properties of the system. ....

G.J. Holzmann. Designing executable abstractions. Proc. Formal Methods in Software Practice, ACM Press, Clearwater Beach Florida USA, March 1998.

....model checked instead. The limitation on the state space size implies that a veri cation model should be abstract enough. However, the more abstract the veri cation model is, the harder it is to relate it to the (speci cation or implementation of the) original, real system. Indeed, as argued in [12], inexperienced users are often inclined to specify details in their models that are redundant for veri cation purposes. The reason for this is that such details are also present in the real system, and by incorporating them into the veri cation model, the user s con dence in the faithfulness of ....

G. J. Holzmann, Designing Executable Abstractions. Keynote address, Proc. Formal Methods in Software Practice, March 1998.

....has become a verification tool of choice for many projects. However, limitations of model checking are well known systems have to be finite, and abstractions have to be used to combat the state space explosion. Although abstractions are essential in reasoning about complicated algorithms [6], they are not always natural or even feasible. Consider the following scenario: a customer specifies the environment at a certain level of abstraction. This might include timing, frequency of input sampling, etc. The goal of a system engineer then is to model and verify the system subject to the ....

Gerard Holzmann. Keynote address: "Designing Executable Abstractions". In Proceedings of 2nd Workshop on Formal Methods in Software Practice, March 1998.

....to be applied to requirements engineering [6, 23, 60, 7, 64] However, the size of the state space grows exponentially to the number of variables in the problem, making all but the most trivial programs too large to analyze. Various researchers have been proposing checking abstractions of programs [66, 42, 35]. Unfortunately, coming up with useful abstractions and interpreting counter examples remains difficult. Motivated by the necessity to create highly scalable analysis techniques, we have developed a low degree polynomial time approach to check low level designs against requirements, summarized in ....

Gerard Holzmann. Keynote address: "Designing Executable Abstractions". In Proceedings of 2nd Workshop on Formal Methods in Software Practice, March 1998.

....salient properties and specify this model in the input language of the verification tool. This process is both error prone and time consuming. In fact, these two problems are closely related since analysis of a naive model of even a trivial program is likely to be intractable. As pointed out in [20], a considerable amount of abstraction is almost always needed to construct an analyzable model. The challenge in constructing a model is to capture just enough detail of the program under analysis to check the requirements, but not so much detail as to make the analysis intractable. Generally ....

G. J. Holzmann. Designing executable abstractions. In M. Ardis, editor, Proceedings of the Second Workshop on Formal Methods in Software Practice, pages 103--108, March 1998.

....analyzed and or executed. He illustrated his point with several examples of seemingly intractable systems, whose analysis becomes tractable upon identifying the right abstractions. A conclusion of the talk was that software engineers can be taught the skills required to design such abstractions [8]. Formal models of critical software components allow simulation and analysis, which help the software developer better understand an algorithm and identify deficiencies early in the development process when they are easiest to correct. In addition to revealing errors, simulations provide the ....

G. J. Holzmann. Designing executable abstractions. Slides from Keynote Address. Available at !http://www.bell-labs.com/~maa/fmsp98/Talks/ holzmann.pdf?.

....language to be able to deploy e ectively. An informed choice of tool run time options is also essential. Similarly, the results of our case study show that state explosion can be further curtailed by applying certain general purpose abstraction techniques, several of which are identi ed in [Hol98] Indeed, the main contribution of this paper is to identify the modeling guidelines, run time options, and abstractions that allowed us to e ectively and eciently model check the i protocol, and to present the supporting tool performance data. Moreover, we believe that many of these techniques ....

....and sink processes to explicitly model upper layer entities. This point is discussed further in the context of abstraction level 1. Level 1: A source process is a process whose sole purpose is to generate a sequence of predetermined messages, while a sink process merely consumes such messages [Hol98] Our level 0 speci cations of the iprotocol for Cospan and Spin used source and sink processes to explicitly model the protocol s upperlayer entities. The level 1 abstraction eliminated source and sink processes from these speci cations. As described in [Hol98] this can be done without ....

[Article contains additional citation context not shown here]

G. J. Holzmann. Designing executable abstractions. In Proceedings of Workshop on Formal Methods in Software Practice, Clearwater Beach, FL, March 1998. ACM Press.

....The very purpose of a model is to enable proof. If it fails to do so, with the tools that are available to the prover, the model should be considered inadequate. We could stop here, and merely illustrate the point by presenting some examples of poorly constructed and well constructed models [H98b], sketching the types of abstraction techniques that are useful in building verifiable models of software applications. There are some problems with this approach though. First, finding the right abstraction can be hard. It takes time to develop the insight that is needed to capture the essence of ....

G.J. Holzmann, Designing executable abstractions, Proc. Formal Methods in Software Practice, Clearwater Beach, Fl., ACM Press, 1998.

....guidance. Verification Engine. The verification engine that is central to the work described here is the Bell Labs model checker SPIN [12] 1 Until now, to user of a model checking system will typically manually define an abstract model that captures the essential aspects of an application [2] [13]. Properties can then be formulated as assertions, or more generally as formulae in propositional temporal logic [20] SPIN can perform either an exhaustive check that proves whether or not the model satisfies the property, or it can deliver a best effort estimate of this fact within given time or ....

G.J. Holzmann, Designing executable abstractions, Proc. Formal Methods in Software Practice, March 1998, Clearwater Beach, Florida, USA, ACM Press.

No context found.

Holzmann, G.J., Designing executable abstractions, Proc. Formal Methods in Software Practice, March 1998, Ft. Lauderdale, Fl., USA, ACM Press. 18 GERARD J. HOLZMANN and MARGARET H. SMITH

No context found.

G. J. Holzmann. Designing executable abstractions. In Proceedings of the second workshop on formal methods in software practice, pages 103--108, Clearwater Beach, Florida USA, March 1998.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC