Gary T. Leavens. Modular Specification and Verification of Object-Oriented Programs. IEEE Software, 8(4):72-80 (July 1991).  Home/Search   Document Not in Database   Summary   Related Articles   Check

....(5.4) however, the reasoning would still hold even when the subtype is added to the program. As static assertions are not inherited by subtypes, they are not constrained by the modular verification requirements. In sum, the properties support modular reasoning of code in the presence of subtyping [84] [91] 77 Inheritance of Specifications In JML, specification inheritance ensures that the behavior of a supertype is imposed on its subtypes, thereby supporting behavioral subtyping [40] Furthermore, a subtype may inherit specifications from more than one supertype, thus allowing multiple ....

....T. However, what is invoked is the subtype S s (down call) invariant method, because it is overridden in S. Thus, all relevant invariants are checked. The same technique works for constraint methods. The anomaly of specification inheritance a#ects modular verification of object oriented programs [84] [91] 92] 95] 114] 113] 151] as the supertype s methods, if not overridden, have to be verified again with respect to the subtype s specifications. This may mean that the supertype s implementation should be available for such re verification. However, the implications of the anomaly on ....

[Article contains additional citation context not shown here]

Gary T. Leavens. Modular specification and verification of object-oriented programs. IEEE Software, 8(4):72--80, July 1991.

....correctness of the application logic basically involves the large field of software testing. Various methods exist and can be directly applied to the software representing the application logic. We do not further discuss details of software testing here but refer the reader to related work such as [15, 50, 103,124, 125]. Another aspect of the testing process is user testing. Depending on the targeted audience of the Web application, users have different requirements and knowledge. The presentation of the content, clear and consistent navigation structures, and the lack of surprises (e.g. unexpected popup ....

Gary T. Leavens. Modular specification and verification of object-orient programs. IEEE Software, 8(4):72--80, Jul 1991.

....C in subsequent composition. A priori correctness is just what we need in order to do system prediction. 3 6 A Priori Reasoning in Modular Specification and Verification A degree of a priori reasoning is carried out in current approaches to modular (formal) specification and verification, e.g. [9, 14], which use modular reasoning. This is specification based reasoning that tries to say before running the software whether it will behave as specified or not (subject to relevant assumptions) This is illustrated in Figure 4. Before a composite module C is deployed, we can predict whether it will ....

G. Leavens. Modular specification and verification of object-oriented programs. IEEE Software, pages 72--80, July 1991.

....Component based Software Development (CBD) is third party assembly. To achieve this, it is necessary to be able to specify components in such a way that we can reason about their construction and composition, and correctness thereof, a priori. Work in modular specification and verification, e.g. [9, 14] has shown the way, and our approach follows its lead. However, our approach is novel and hence different in the way we define correctness. In this paper, we will discuss how we specify components, and in particular how we define and reason about correctness, and why this is useful for CBD. 2 ....

....Moreover, we need to know how to certify C properly, and thus how to use C in subsequent composition. A priori correctness is just what we need in order to do system prediction. 5 Modular Specification and Verification Current approaches to modular (formal) specification and verification, e.g. [9, 14], use modular reasoning. This is specification based reasoning that tries to say before running the software whether it will behave as specified or not (subject to relevant assumptions) This is illustrated in Figure 4. Before a composite module C is deployed, we can Code Interface Interface ....

G. Leavens. Modular specification and verification of object-oriented programs. IEEE Software, pages 72--80, July 1991.

....it is essential to have a programmatic interface contract(s) for the COTS product. This is the topic of this section. In modular reasoning it is possible to ensure that a component implementation satisfies its specification, based only on the specifications of reused components [Ernst 90, Leavens 91, Weide 94b] Figure 4 provides an illustration to explain the basic idea. In the figure, an oval represents the specification of a component, whereas a rectangle represents an implementation. A thin arrow labeled i indicates an implements relationship and a thick arrow labeled u indicates a ....

Leavens, G., "Modular Specification and Verification of ObjectOriented Programs", IEEE Software, Vol. 8, No. 4, July 1991, pp. 72-80.

....1. INTRODUCTION 3 about procedure calls difficult. It is highly desirable for practical verification or refinement systems to support modular reasoning, in the sense that certain components of a system, such as procedures or ADTs, can be verified independently of the rest of the system [EMHO85] Lea91] For example, in an ADT language, modular reasoning would allow the implementations of different ADTs to be developed independently. However, supporting modular reasoning in an object oriented language is more difficult, due to the late binding of procedure calls. It is necessary to restrict the ....

....reasoning about late binding, since it allows supertype specifications to be used as approximations to the actual behaviour of an object whose precise class is not known. 3.3. 3 NOAL Another approach to reasoning about programs that use subtyping has been developed by Gary Leavens [Lea89] LW90] Lea91] His verification rules for object oriented programs that use late binding were the first to be proven sound. Leavens uses an object oriented functional language called NOAL to illustrate verification techniques for subtyping. NOAL is a hybrid of Trellis Owl [S 86] an object oriented ....

Gary Leavens. Modular specification and verification of object-oriented programs. IEEE Software, 8(4):72--80, July 1991. Ref. on pages 3, 27.

....Further, Poetzsch He#ter and Muller [PHM98] provided a proof system for a class based language, representing properties of the type system of the language in axioms. Much of the emphasis of the previous research has been on issues of refinement and inheritance. Lano and Haughton [LH92] Leavens [Lea89, Lea91], and Liskov and Wing [LW94] all studied notions of subtyping and of refinement of specifications (similar to our subspecification relation, though in some respects more sophisticated) Stata and Guttag [SG95] studied the notion of subclassing, and presented a pre formal approach for reasoning ....

G. T. Leavens. Modular specification and verification of objectoriented programs. IEEE Software, pages 72--80, July 1991. 35

....to a class is an enhancement is when the new version of a changed class does not implement the same abstract type as the old one but its semantics are an enhanced version of those of the old one. This notion can be formalized using the notion of subtypes and supertypes introduced by Leavens [Lea91] A type T is said to be a supertype of T 0 if every abstract value of T 0 simulates an abstract value of T . For example, the abstract value [1; 3] of an integer interval type simulates the abstract value f1; 2; 3g of an integer set type. 83 vars head, tail; Method add (e) vars l; ....

....begin p l; l l.getlink; end end if found then begin if p 6= nil then p.setlink(l.getlink) else head l.getlink; if l.getlink = nil then tail p; end return self; end Figure 5. 5: Changes to the list class 84 The formal definition of the simulation relation can be found in [Lea91] Now suppose, we replace a class C representing type T by a class C 0 representing type T 0 which is a supertype of T . If we use a restructuring mapping which maps the object space of an object to the new concrete representation of the abstract value (of T 0 ) which is simulated by the ....

G. T. Leavens. "Modular specification and verification of object-oriented programs". IEEE Software, pages 72--80, July 1991.

....e.g. the RESOLVE project [SW94] Both [JC93] and [MMM94] use formal specifications to determine a subsumption relation between components and structure their libraries accordingly. Similarly, LW94] define the notion of behavioral subtype as an extended means to organize class libraries and [Lea91] has developed techniques to support the specification and verification of object oriented programs. Deductive component retrieval has also been investigated by [RW91] which used Prolog to specify the components and its built in higher order unification as retrieval mechanism. Moorman Zaremski ....

G. T. Leavens. "Modular Specification and Verification of Object-Oriented Programs". IEEE Software, 8(4):72--80, July 1991.

....not allow data refinement between supertype and subtype value spaces. Others have worked on the specification of types and subtypes. For example, many have proposed Z as the basis of specifications of object types[8, 12, 6] Goguen and Meseguer use FOOPS[15] Leavens and his colleagues use Larch[22, 24, 11]. Though several of these researchers separate the specification of an object s creators from its other methods, none has identified the problem posed by the missing creators, and thus none has provided an explicit solution to this problem. In summary, our work is similar in spirit to that of ....

Gary T. Leavens. Modular specification and verification of object-oriented programs. IEEE Software, 8(4):72--80, July 1991.

No context found.

Gary T. Leavens. Modular Specification and Verification of Object-Oriented Programs. IEEE Software, 8(4):72-80 (July 1991).

No context found.

Gary T. Leavens. Modular Specification and Verification of Object-Oriented Programs. IEEE Software, 8(4):72-80 (July 1991).

....checkable by using keywords to stand for behavioral properties. 6.3.1 Model Theory 6.3.2 For Types with Immutable Objects Also in the late 1980s Leavens, in his Ph.D. thesis [Lea88, Lea90] showed how to use the notion of behavioral subtyping to do modular verification of OO programs [Lea91, LW90, LW95] Leavens s definition of behavioral subtyping is modeltheoretic. The basic notion is that of a coercion relation between models of abstract values [LP92] which has led to a precise model theoretic characterization of behavioral subtyping for types with immutable objects [LP96] ....

Leavens, G. T. Modular specification and verification of object-oriented programs. IEEE Software, 8(4):72--80, July 1991.

....semantics, and to programming environment issues. The above goals are directed at making Larch C practical. In addition, we have some other goals which should help make Larch C useful, but which are motivated by a particular view of object oriented programming [Ame87] Mey88] LW90] Lea90] Lea91] This view centers around supertype abstraction, which is the ability to reason about a program based on nominal (i.e. static) type information by letting supertypes stand for all their subtypes. Informally, a subtype is an abstract data type such that each object of the subtype acts like some ....

....and Modula 3. Since message passing causes special difficulties in program verification it is worth taking extra trouble in specification if that will make the job of verification easier. One way to make such verification easier is by the use of legal subtype relationships [LW90] Lea90] Lea91] 2.2.1 Distinguish Subtypes and Subclasses In software engineering it is important to distinguish between the notions of type and class and the relationships of subtype and subclass. A type (i.e. an abstract data type) is a behavioral notion, and may be implemented by many different classes. ....

[Article contains additional citation context not shown here]

Gary T. Leavens. Modular Specification and Verification of Object-Oriented Programs. IEEE Software, 8(4):72--80, July 1991.

No context found.

Gary T. Leavens. Modular Specification and Verification of Object-Oriented Programs. IEEE Software 8(4), pp. 72-80, July, 1991.

....Along with the promise of reuse, object oriented (OO) techniques bring several challenges. A key problem that our research addresses is how to verify (or reason about) code that uses message passing and subtype polymorphism. Our research on such questions has been mostly model theoretic [18, 29, 30, 31, 32, 33, 34, 35, 36]. However, the models we use may seem, at first glance, to have little to do with standard OO programming languages, such as Smalltalk80 [24] C [50] Eiffel [42] and Java [2, 25] Such single dispatching languages seem to be better modeled by models in which objects resemble records, and ....

Gary T. Leavens. Modular specification and verification of object-oriented programs. IEEE Software, 8(4):72--80, July 1991.

....of objects without knowledge of their exact run time types. This causes difficulties in verification, because many different operations may be invoked by a single message at different times, and these operations may have different specifications. The technique of supertype abstraction [40] 38] [35] overcomes this problem by reasoning using static (what we call nominal) type information, and restricting the run time types of the objects denoted by expressions to be subtypes of their nominal types. That is, supertype abstraction means using supertypes to stand for all their subtypes. ....

....[45] By ruling out mutation, attention is focused on two other features that make reasoning difficult in object oriented languages: message passing and subtyping. 1.2 An Example of the Reasoning Problem This section motivates the need for supertype abstraction and modularity. See also [38] and [35] for more background. Consider the specification of Figure 1. In that figure, the meaning of the operators used in the pre condition (following requires) and the post condition (following ensures) is expressed using trait functions from the specification of IntSet, for example 2, and ....

[Article contains additional citation context not shown here]

Leavens, G. T. Modular specification and verification of object-oriented programs. IEEE Software, 8(4):72--80, July 1991.

....with aliasing, we plan to require that the verifier verify a method for each possible case of aliases among the names it uses. Often some of these cases can be ruled out by preconditions. To deal with subtyping and dynamic dispatch, we plan to use behavioral subtyping and supertype abstraction [1, 5, 17, 18, 24, 25, 29, 30, 41]. Since JML forces subtypes to be behavioral subtypes [6] this allows one to reason about Java programs using the static types of variables and expressions, ignoring dynamic dispatch. 4 Future Work and Conclusions One area of future work for JML is concurrency. Our current plan is to use when ....

Gary T. Leavens. Modular specification and verification of object-oriented programs. IEEE Software, 8(4):72--80, July 1991.

No context found.

G. T. Leavens. Modular specification and verification of object-oriented programs. IEEE Software, pages 72--80, July 1991.

No context found.

Leavens, G. T., "Modular specification and verification of object-oriented programs," IEEE Software, pp. 72--80, July 1991.

No context found.

G. T. Leavens "Modular Specification and Verification of Object-Oriented Programs", IEEE Software, July, pp. 72-80, 1991.

No context found.

G. Leavens. Modular specification and verification of object-oriented programs. IEEE Software, 8(4):72--80, 1991.

No context found.

G. Leavens. Modular specification and verification of object-oriented programs. IEEE Software, pages 72--80, July 1991.

No context found.

G. Leavens, "Modular Specification and Verification of Object-Oriented Programs," IEEE Software, Nov./Dec., 1991, pp. 72-80.

No context found.

Leavens, G. T., "Modular specification and verification of object-oriented programs," IEEE Software, pp. 72--80, July 1991.

First 50 documents  Next 50

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