B. Liskov and J. M. Wing. Specifications and their use in defining subtypes. In Proceedings of the eighth annual conference on Object-oriented programming systems, languages, and applications, pages 16--28. ACM Press, 1993.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....Two such examples are invariants and history constraints. An invariant is a property that must hold in all client visible states of an object, and a history constraint is a relation that should hold between each visible state and all visible states that occur later in the program s execution [101] [103]; a history constraint is used to describe the way that an object changes its state over time. The following are some highlights of JML that are particularly interesting from the perspective of runtime assertion checking. In addition to this summary, Chapter 2 provides an overview of JML with ....

.... of JML s specification inheritance is that its semantics supports a behavioral notion of subtyping [40] 101] The essence of behavioral subtyping is summarized by Liskov and Wing s substitution property, which states that a subtype object can be used in place of a supertype s object [101] 102] [103]. In JML, specifications are inherited in such a way to ensure the 22 substitution property [40] Preconditions are disjoined, and postconditions are conjoined in the form of ( old(p i ) q j ) where p i is a precondition and q i is the corresponding postcondition. Type assertions such as ....

[Article contains additional citation context not shown here]

Barbara Liskov and Jeannette M. Wing. Specifications and their use in defining subtypes. ACM SIGPLAN Notices, 28(10):16--28, October 1993. OOPSLA '93 Proceedings, Andreas Paepcke (editor). 141

....value must have a dynamic type that is a subtype of T . Reason about client code using the static types of expressions, as in standard reasoning about programs with ADTs. Prove that each subtype used in the program is a behavioral subtype of its supertypes [Ame87, AvdL90, Ame91, Dha97, LW93b, LW94, Utt92, UR92] In simplest terms, this means that the subtype objects obey the specification of their supertype objects [DL96] The advantage of modular reasoning is that unchanged methods do not have to be respecified or reverified when new behavioral subtypes are added. 6.1.4 Outline ....

....(invariant C (self # ) invariant A (x # ) 6.2) C s history constraint must imply A s: C . A . constraint C (self , self # ) constraint A (x , x # ) 6. 3) A history constraint is a monotonic relation on pairs of states; it relates an earlier state to a later state [LW93b, LW94] History constraints are useful in abbreviating specifications, and have implications for behavioral subtyping that are discussed below. In JML history contraints are syntatically stated as if they related a pre state and a post state, although the semantics is more general. for each ....

[Article contains additional citation context not shown here]

Liskov, B. and Wing, J. M. Specifications and their use in defining subtypes. ACM SIGPLAN Notices, 28(10):16--28, October 1993. OOPSLA '93 Proceedings, Andreas Paepcke (editor).

....would otherwise have to be repeated in every operation s postcondition. However, time based constraints are not just mere notational abbreviations, because they apply to all operations, even when new ones are added to a class or type. The idea of time based constraints was first introduced in [16][17] under the name history constraints. Timebased constraints can be easily incorporated in OCL by introducing a keyword constraint as follows: context Class constraint: constraint where constraint is a boolean expression representing the constraint. This expression relates two states (before ....

B. Liskov and J. Wing, A, Specifications and their use in defining subtypes, ACM SIGPLAN Notices, 28(10)16-28, 1993, OOPSLA'93 Proceedings.

....of pre existing software components under application requirements. Such kind of reasoning is also refered further as Semantic Interoperable Reasoning (SIR) The completeness requirement is still ignored by industrial environments [20, 21] though recent analysis clearly indicates its importance [13, 11, 17]. To support the above SIR an adequate specification and development tool should be used. Commonly such tools are based on Formal Software Development Methods which have been a subject of intensive investigations during the last two decades. The significant experience in this area resulted in ....

....Figure 1.4. dealer junker is refinement of Figure 1.5: Refinement hierarchy It should be noted that there are different formalisms supporting the refinement based reasoning. Say, in our example we could use covariance contravariance reasoning based on general Liskov Substitutability Principle [16, 17], as well as the RAISE Implementation Relation [5] which is exploited in the current report. Although a clear relationship between the formalisms has not been established yet, all of them satisfies the substitutability property in specifications of complex systems, which is crucial for software ....

B. Liskov, J. Wing. Specifications and their use in defining subtypes. OOPSLA'93, 1993

....limited solely to testability issues related to information hiding and encapsulation. The other dimension that must be considered is inheritance and what it contributes to the problem of testability. In this article, we consider inheritance solely from the perspective of a sub typing relationship [11]. If a class B is a subtype of a class A, then the behavior of a B must be consistent with that of A. An instance of B must be freely substitutable for an instance of A. Clients must not be aware of the fact that they are using B s instead of A s. What this means is that any polymorphic method ....

Liskov, B. and J.M. Wing. Specifications and their use in defining subtypes. in 8th Annual ACM Conference on Object-Oriented Programming Systems, Languages, and Applications, OOPSLA 1993. 1993. Washington, DC, USA.

....reprints of this article, please send e mail to: tsecomputer. org, and rcference IEEECS Log Number 112157. A can do, but it will do so in the very same way and with the very same results. This notion is not new. It has its roots in work of Wegner and Zdonik [26] and Liskov and Wing [13] [14], and is often referred to as the Liskov principle. See also Abadi and Cardelli [1] Niestraz [17] discussed this notion in the framework of state machine modeling, but on a relatively simple level. Our work can be thought of as providing a detailed proposal as to how one might define the Liskov ....

B.H. Liskov and J.M. Wing, "Specifications and Their Use in Defining Subtypes," Lecture Notes in Computer Science, vol. 967, pp. 245-267, 3.995.

....of behavioral subtyping. For example, with reasoning choice 1, all additional methods of behavioral subtypes must satisfy the history constraint (and invariant) of their supertypes. This leads to a less restrictive form of Liskov and Wing s history constraint definition of behavioral subtyping [33, 31], which we call minimal strong behavioral subtyping. In minimal strong behavioral subtyping , a subtype s methods must obey the invariant and history constraint of its supertypes, but Liskov and Wing s methods rule is not imposed. When the methods rule is imposed as well, we call their ....

....only has to be valid for computations that do not invoke the additional methods of the subtype. Thus, although the constraint rule in the definition of weak behavioral subtyping is similar to the constraint rule in Liskov and Wing s history constraint definition of strong behavioral subtyping [33, 31], the di#erence in the way history constraints are applied to the subtype s additional methods explains the di#erent e#ects they have on permitted subtype relationships. Another way of interpreting the di#erence in the application of history constraints is by viewing the supertype s history ....

B. Liskov and J. M. Wing. Specifications and their use in defining subtypes. ACM SIGPLAN Notices, 28(10):16--28, Oct. 1993. OOPSLA '93 Proceedings, Andreas Paepcke (editor).

....the categories in the spectrum can be interpreted as types, we are interested only in those where the compatibility rules ensure that a subclass instance can be used in any situation in which an instance of the superclass can be used. This constraint is known as the property of substitutability (Liskov and Wing 1993). Only when this property is realised can inheritance achieve a worthwhile benefit (i.e. through type safe polymorphism) and therefore justify the severe limitation that observing the subtype relation places on its operational flexibility. Bar David (1992) agrees for every restriction that I ....

....if it has the same domain [of values] as the supertype and, for all operations of the supertype, corresponding arguments yield corresponding results . A number of different techniques for specifying the behaviour of a class have been proposed, and implemented, including history invariants (Liskov and Wing 1993), class invariants, pre and post conditions (Meyer 1988) A subtyping relationship can be established explicitly, by naming a type to be a subtype (or subtyping inheritor) of another; or structurally, where the relationship can be inferred through structural equivalence (i.e. one type has all ....

[Article contains additional citation context not shown here]

Liskov, B. and J. Wing (1993). Specifications and their use in defining subtypes. In Proceedings of OOPSLA'93, pp. 16--28. ACM Press.

.... subtyping must even be stronger than the syntactic guarantee that the new type will not cause type checking (or message not understood ) errors (see, for example, 8] It must instead be a behavioral notion, based on the specification of an abstract data type [1] 42] 40] 30] 15] 2] 44] [45]. See Section 8 for a discussion of related work. As an example of the distinction between legal subtyping and subclassing, consider two types IntSet and Interval, where Interval is a type of closed intervals of integers, and IntSet is a type of integer sets. Both types of objects are ....

....Simulation relations are the main technical tool used to define legal subtype relations. Note, however, that we only deal with first order 2 , immutable, abstract data types. Subtyping for mutable types (types whose objects have time varying state) is still a subject of research [17] 44] [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] ....

[Article contains additional citation context not shown here]

Liskov, B. and Wing, J. M. Specifications and their use in defining subtypes. ACM SIGPLAN Notices, 28(10):16--28, October 1993. OOPSLA '93 Proceedings, Andreas Paepcke (editor).

....sending Depth to some stack s (yielding an integer object) and then verifying that the integer returned is one less than the integer object returned by Depth after sending Add to s. This type of testing is commonly done when using algebraic specifications [2, 3] or when using class invariants [6, 8]. Thus, in this model, two objects must be generated and compared. These objects may be either: a) objects of the CUT or (b) objects returned by an observer method of the CUT. Case (a) corresponds to the case where testing a stack class might involve generating two stack objects and comparing ....

Liskov, B. and Wing, J. "Specifications and Their Use in Defining Subtypes," Proceedings of OOPSLA '93, pp. 16-28.

....not lead to these sequences arising. That is, it will not deadlock if the former does not deadlock. This in effect is the basis of the process algebra theory of extension (Brinksma Scollo December 1986) This model of a history preserving extension is also consistent with the work presented in (Liskov Wing 1995). ServerServerSubBehOk : ServerInterface # ServerInterface 8 si 1 ; si 2 : ServerInterface j (si 1 ; si 2 ) 2 ServerServerSubBehOk ffl (si 1 :ois ; si 2 :ois) 2 SubstituteSyntaxOk (8 is : IntSig ; it : InvTemplate; tt : TermTemplate; s 1 ; s 2 ; s 3 ; s 4 ; s 5 ; s 6 ; s 7 ; s 8 : State j is ....

Liskov, B. & Wing, J. (1995), Specifications and their use in defining subtypes, in J. P. Bowen & M. G. Hinchey, eds, `Proceedings of the 9th International Conference of Z Users', Vol. 967 of Lecture Notes in Computer Science, Springer-Verlag.

....a clue on the object behavior, which however hinders the automatic processing by computers. Consequently, providing reuse on the basis of a behavioral specification is not a very practical thing to do. For a thorough discussion of behavioral subtyping the reader is referred to [LW93b] LW93a] LW93c] and [Nie93] Implementations Reuse of program code in distributed object systems can be based on delegation, aggregation and inheritance. While the former two are used already in distributed systems, the latter is more difficult to achieve. We will present our solution after a few words on the ....

B. Liskov and J. Wing. Specifications and Their Use in Defining Subtypes. OOPSLA'93, 28(10):16--28, October 1993.

....of pre existing software components under application requirements. Such kind of reasoning is also refered further as Semantic Interoperable Reasoning (SIR) The completeness requirement is still ignored by industrial environments [20, 21] though recent analysis clearly indicates its importance [13, 11, 17]. To support the above SIR an adequate specification and development tool should be used. Commonly such tools are based on Formal Software Development Methods which have been a subject of intensive investigations during the last two decades. The significant experience in this area resulted in ....

....player dealer junker joker is refinement of Figure 1.5: Refinement hierarchy It should be noted that there are different formalisms supporting the refinement based reasoning. Say, in our example we could use covariance contravariance reasoning based on general Liskov Substitutability Principle [16, 17], as well as the RAISE Implementation Relation [5] which is exploited in the current report. Although a clear relationship between the formalisms has not been established yet, all of them satisfies the substitutability property in specifications of complex systems, which is crucial for software ....

B. Liskov, J. Wing. Specifications and their use in defining subtypes. OOPSLA'93, 1993

....are open issues so far, for our purposes we decide type conformance of two types on the base of syntactical type descriptions, i.e. interfaces, method signatures, contra and covariance rules. For more information on the discrepancy of syntactical and semantical type specifications see [LIWI93b] CAWE85] and [AMER90] We support polymorphic binding of service objects to service users. Therefore, the type of the reference needs not to be exactly the same as the type of the object the reference points to. The reference type is always a supertype of the object type. After the reference ....

B. Liskov and J. Wing. Specifications and Their Use in Defining Subtypes. OOPSLA'93, 28(10):16--28, October 1993.

....is limited to the elements of Cl . Proof An obvious extension of the proof of theorem replacement of objects presented in [BG90] 2 We have the following correspondence with the previous general definition of refinement: j Cl c ( Sem 8 Sub typing We believe, like many other researchers [Ame90, LW93], that sub type relationship relates the behavior of the objects and therefore is a semantic concern while inheritance is used for implementation convenience. The sub type relationship we are going to set out is based on the substitutability principle. Two forms of the principle have been ....

Barbara Liskov and Jeanette M. Wing. Specifications and their use in defining subtypes. In Proceedings OOPSLA '93, ACM SIGPLAN Notices, pages 16--28, October 1993. Published as Proceedings OOPSLA '93, ACM SIGPLAN Notices, volume 28, number 10.

....the empty set. The subtype relation is the information ordering relation : Extensional interpretation of is by the set inclusion. A subtype is considered to be more informative than its supertype (we assume a subtype relation definition based on type specifications similar to the given in [12]) Let T be a set of types with a subtype ordering relation : An extensional type semantics is an order homomorphism [3] h : T ; PV; In particular: h( V; h( fg and for all T; S in T S T ) h(S) h(T ) These considerations give us a general hierarchy for placement of ....

Liskov B., Wing J.M. Specifications and their use in defining subtypes. Proceedings of OOPSLA 1993, ACM SIGPLAN Notices, vol. 28, N 10, October 1993

....mutation, she does not study the relation between mutation, aliasing, and subtyping. Further, she requires the types of the arguments for the common methods in the subtype and supertype to be the same. In contrast to the above model theoretic approaches, America [Ame87, Ame91] and Liskov and Wing [LW93b, LW94] give proof theoretic definitions of behavioral subtyping. America does not deal with extra mutators in subtypes. Liskov and Wing allow extra mutators provided that the extra mutators can be explained in terms of the supertype methods or if they do not violate any history constraints of the ....

Barbara Liskov and Jeannette M. Wing. Specifications and their use in defining subtypes. OOPSLA '93 Proceedings, Andreas Paepcke (editor), volume 28(10), ACM SIGPLAN Notices, pages 16--28, October 1993.

....on objects communicating with other objects by exchanging messages (Wegner, 1990) An object is a self contained entity characterized by its identity, state and behavior. The objects are classified according to their behavior into a system of types. Also subtyping (Cardelli and Wegner, 1985, and Liskov and Wing, 1993) and the related sort of polymorphism are regarded as necessary features of object oriented languages. In concurrent object oriented languages it is advantageous to use active objects (Nierstrasz, 1993) i.e. to view objects as processes that communicate by message passing. In this paper we use a ....

....problem: Because of aliasing, the compiler has to consider that several concurrent tasks may send messages to a single object in an interleaved way. Types in object oriented languages are partial specifications of object behavior that should express how instances of the types can be used savely (Liskov and Wing, 1993). A supertype is a less complete specification of the behavior specified by a subtype; i.e. all properties that hold for the supertype hold also for the subtype. The principle of substitutability says that an instance of a subtype can always be used in any context in which an instance of a ....

Liskov, B. and Wing, J.M. (1993) Specifications and their use in defining subtypes. ACM SIGPLAN Notices, 28(10), 16--28. Proceedings OOPSLA'93.

....all processes must agree to uphold, we use a constraint clause in the specification for type T . The predicate we write in this clause states a history property of all computations involving any object of type T . We borrow this idea from Liskov and Wing s technique for specifying subtypes [9]. A history property must hold of all successive pairs of states in a computation, and thus we formulate them as predicates over pairs of states. More formally, the constraint clause that appears in the specification of type T , constraint P (x i ; x j ) stands for the predicate, for all ....

B. Liskov and J. Wing. Specifications and their use in defining subtypes. In Proc. of OOPSLA '93, pages 16--28, September 1993.

No context found.

B. Liskov and J. M. Wing. Specifications and their use in defining subtypes. In Proceedings of the eighth annual conference on Object-oriented programming systems, languages, and applications, pages 16--28. ACM Press, 1993.

No context found.

B. Liskov and J. M. Wing. Specifications and their use in defining subtypes. In Proceedings of the eighth annual conference on Object-oriented programming systems, languages, and applications, pages 16--28. ACM Press, 1993.

No context found.

B. Liskov and J. M. Wing. Specifications and their use in defining subtypes. In Proceedings of the eighth annual conference on Object-oriented programming systems, languages, and applications, pages 16--28. ACM Press, 1993.

No context found.

Barbara Liskov and Jeannette M. Wing. Specifications and their use in defining subtypes. In Andreas Paepcke, editor, OOPSLA '93 Proceedings, volume 28, number 10 of ACM SIGPLAN Notices, pages 16-28. ACM Press, October 1993.

No context found.

Barbara Liskov and Jeannette M. Wing. Specifications and their use in defining subtypes. In Proceedings of OOPSLA'93, pages 16--28, 1993.

No context found.

Barbara Liskov and Jeannette M. Wing. Specifications and their use in defining subtypes. In Andreas Paepcke, editor, OOPSLA '93 Proceedings, volume 28, number 10 of ACM SIGPLAN Notices, pages 16-28. ACM Press, October 1993.

First 50 documents

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