N. Soundarajan and S. Fridella "Inheriting and Modifying Behavior", in Proceedings of the 23rd International Conference on Technology of Object Oriented Systems, TOOLS 23, pp. 148-162, IEEE Computer Society Press, 1998.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....model, such as TLA [65] UNITY [76] or various forms of process algebra [53, 75] Inheritance, as a means for modular system design, has been a subject of extensive research for decades. Many researchers employed formal methods to define various inheritance constructs and study their properties [2, 16, 28, 33, 49, 56, 70, 69, 79, 88, 87, 86, 13, 76, 48]. Our distinguishing contribution is a provision of a formal framework that allows simulation proofs to be constructed incrementally when inheritance is applied at two levels: specifi23 cation and algorithm. Thus, we extend the applicability of inheritance from the realm of incremental system ....

....and show how it can be used in conjunction with the specialization construct to achieve subclassing for extension; we then extend the proof reuse theory presented in Section 3.3 to this situation. Section 3. 5 compares our results with related work; it shows that, while many other works (e.g. [2, 16, 28, 33, 49, 56, 70, 69, 79, 88, 87, 86]) have dealt formally with inheritance, the distinguishing contribution of our approach is the provision of a formal framework for applying inheritance to both system modeling and system verification. Section 3.6 concludes this chapter. This chapter employs a simple running example to illustrate ....

[Article contains additional citation context not shown here]

Neelam Soundarajan and Stephen Fridella. Inheriting and modifying behavior. In R. Ege, M. Singh, and B. Meyer, editors, Technology of Object-Oriented Languages (TOOLS-23), pages 148--162. IEEE Computer Society Press, 1997.

....Composition and inheritance are two complementary means for modular system design. Inheritance, as a means for modular system design, has been a subject of extensive research for decades. Many researchers employed formal methods to de ne various inheritance constructs and study their properties [1, 5, 10, 11, 20, 24, 29, 30, 35, 39, 37, 38, 4, 34, 15]. Our distinguishing contribution is a provision of a formal framework that allows simulation proofs to be constructed incrementally when inheritance is applied at two levels: speci cation and algorithm. Thus, we extend the applicability of inheritance from the realm of incremental system ....

....for modifying its variables. The actual mechanism is implemented by the child while abiding to the parent s constraints; the child of course can also re ne the policy and the integrity constraints. 8 Related work The works that most closely relate to ours are those of Soundarajan and Fridella [37, 38] and Stata and Guttag [39] Unlike our formalisms, both of these works are restricted to the context of sequential programming and do not encompass reactive components. Like us, Soundarajan and Fridella [37, 38] have recognized that incremental reasoning is important in exploiting the full ....

[Article contains additional citation context not shown here]

N. Soundarajan and S. Fridella. Inheriting and modifying behavior. In R. Ege, M. Singh, and B. Meyer, editors, Technology of Object-Oriented Languages (TOOLS23), pages 148-162. IEEE Computer Society Press, 1998.

....in Ensemble [15] a large scale, modularly structured, group communication system. Inheritance, as a means for modular system design, has been a subject of extensive research for decades. Many researchers employed formal methods to de ne various inheritance constructs and study their properties [1, 5, 9, 10, 19, 23, 29, 30, 35, 39, 37, 38, 4, 34, 14]. Our distinguishing contribution is a provision of a formal framework that allows simulation proofs to be constructed incrementally when inheritance is applied at two levels: speci cation and algorithm. Thus, we extend the applicability of inheritance from the realm of incremental system design ....

....by describing its use in a large scale modeling and veri cation project. In Section 7 we discuss the modeling methodology that we have used with our formalism in the context of the same project. Section 8 compares our results with related work; it shows that, while many other works (e.g. [1, 5, 9, 10, 19, 23, 29, 30, 35, 39, 37, 38]) have dealt formally with inheritance, the distinguishing contribution of this paper is the provision of a formal framework for applying inheritance to both system modeling and system veri cation. Section 9 concludes the paper. 2 Background: I O Automata and Simulation Proofs This section ....

[Article contains additional citation context not shown here]

N. Soundarajan and S. Fridella. Inheriting and modifying behavior. In R. Ege, M. Singh, and B. Meyer, editors, Technology of Object-Oriented Languages (TOOLS23), pages 148-162. IEEE Computer Society Press, 1998.

....I will describe these contributions in more detail, and discuss my plans for future work. Incremental Implementer Reasoning Using the OO language mechanism inheritance an implementer can build a new class (an OO module) from an existing one by specifying only the di erences between the two. In [3] we introduce a speci cation notation and reasoning method that allows implementers of such new derived classes to reason about their behavior in an incremental fashion, based on the reasoning already performed about the original base class. In [5] we explore the amount of reasoning reuse allowed ....

N. Soundarajan and S. Fridella. Inheriting and modifying behavior. In Ege, Singh, and Meyer, editors, Proceedings of TOOLS '97, pages 148-163. IEEE Computer Society Press, 1997.

....possible to use inheritance to define derived classes that are not conceptually closely related to the base class. Such derived classes are not meant to be used polymorphically and will not obey the restrictions imposed in this paper. We will not consider such use of inheritance in this paper; in [13] we show how the designer of such derived classes can, in validating his 2 class, reuse much of the reasoning behind the base class. Note that OO polymorphism does not require a C like inheritance mechanism; for instance, Java s interface inheritance allows us to achieve OO polymorphism ....

....a derived class of B. Let us first consider how to specify B. As usual, each class will have a concrete specification and an abstract specification. The concrete specification of B is needed not only when establishing the correctness of B s implementation, but also, as we discuss in some detail in [13], when establishing the correctness of D s implementation. Since our focus is on the behavior of client code we will concentrate on abstract specifications. 3 The abstract specification of B will consist of three components: a conceptual model of the class; an invariant over this model; and the ....

[Article contains additional citation context not shown here]

N. Soundarajan and S. Fridella. Inheriting and modifying behavior. In Proceedings of TOOLS, published by IEEE Computer Society (to appear), 1997.

....are methods, i.e. there are no public data members. Further, in order to simplify the discussion we will assume that there are no private members. 4 The specification hA; Ci of B consists of two components, A, the abstract specification of B, and C, the 4 We consider private members in [11]. Eiffel has no private members, only public and protected; thus all members of a class are accessible in derived classes. Java allows not only derived classes, but all other classes that are in the same package as B to access all members of B except those declared private. But these other ....

N. Soundarajan and S. Fridella. Inheriting and modifying behavior. In TOOLS23, pages 148-- 162. IEEE, 1998.

....2 Let us return brie y to the question of abstraction. While it is true that clients of a class should not concern themselves with the internals of a class, designers of derived classes are indeed very concerned with the internals of the appropriate base classes. As we discuss in detail in [21, 22], in the absence of a concrete speci cation for the base class B, the designer of the derived class D that inherits from B would be forced to analyze the code of the methods de ned in B in order to ensure that the methods he 1 de nes (or rede nes) in the derived class use the member variables ....

N. Soundarajan and S. Fridella. Inheriting and modifying behavior. In Ege, Singh, and Meyer, editors, Proceedings of TOOLS '97, pages 148-163. IEEE Computer Society Press, 1997.

....of B since even their conceptual models may be very different from each other. In most examples, however, the models are similar to each other, and much of the abstract specification of B can also be inherited by D. 12 We consider how our approach can be extended to handle private members in [10]. Eiffel has no private members, only public and protected; thus all members of a class are accessible in derived classes. Java allows not only derived classes, but all other classes that are in the same package as B to access all members of B except those declared private. But these other ....

....and code that uses StreetMap is unaffected by OneWayStreetMap. 21 In C , g would have to be declared virtual; otherwise f will always invoke the original g; in Eiffel all methods are virtual. 22 Systems that handle limited versions of this problem have been considered (see, for example, [10, 11]) In order to deal with general methods of this kind, one possible approach would be include, in the concrete specification of f , some information identifying the functions that f invokes; this information can then be combined with information about the behavior of g when it is redefined in the ....

N. Soundarajan and S. Fridella. Inheriting and modifying behavior. In TOOLS, 1997.

....introduce a simple model of frameworks: A framework F consists of a concrete 3 1 For concreteness we use C terminology but the approach is not language specific; further, we use the terms method and function interchangeably. 2 For ways of dealing with limited versions of this problem see [13, 12]. 3 A class is concrete if it has no virtual functions, abstract if it has one or more pure virtual functions; for simplicity 1 controller class C, zero or more other concrete classes C 1 ; Cm , and one or more abstract classes A 1 ; A n . The controller class has a ....

N. Soundarajan and S. Fridella. Inheriting and modifying behavior. In Meyer Ege, Singh, editor, Proceedings of TOOLS '97, pages 148--163. IEEE Computer Society Press, 1997.

.... 9 As far as operations that are defined or redefined in D are concerned, we must, of course, come up with appropriate concrete specifications describing their effects on the various member variables (both those declared in D as well as those inherited from B) 7 We consider private members in [11]. Eiffel has no private members, only public and protected; thus all members of a class are accessible in derived classes. Java allows not only derived classes, but all other classes that are in the same package as B to access all members of B except those declared private. But these other ....

N. Soundarajan and S. Fridella. Inheriting and modifying behavior. In TOOLS, 1997.

....should then be considered as constraints that application designers must satisfy when they provide actual definitions for them. One further point should be noted: throughout this chapter, we will be mostly working with what are usually called concrete specifications , see for example [17], in other words our specifications of functions are in terms of their effects on the actual data members of the classes we are dealing with. When trying to understand the behavior of the framework and the application in terms of how they are built, naturally we have to work with such ....

....the framework and the application in terms of how they are built, naturally we have to work with such specifications since the behavior they exhibit is realized in terms of these components. Once we have an understanding of the concrete behavior of the entire application, we can use standard ways [11, 17] to convert it into an abstract specification in terms of a conceptual model. The problems of using OO have been remarked on by many people in the literature see, for example, 5] One of the important issues is that of documentation; the issue becomes particularly critical for frameworks as has ....

[Article contains additional citation context not shown here]

N. Soundarajan and S. Fridella. Inheriting and modifying behavior. In Meyer Ege, Singh, editor, Proceedings of TOOLS '97, pages 148--163. IEEE Computer Society Press, 1997.

....interest in this paper is in investigating how to allow for the changed behavior of a polymorphic function that is inherited unchanged from B, as a result of redefinitions of virtual functions that it invokes. For possible ways of dealing with non virtual functions being overridden, please see [7]. A common reason for providing new definitions for virtual functions is that the derived class D contains new member variables and the designer of D wishes to redefine one or more of the virtual functions to manipulate these variables. For instance, suppose in the example we considered at the ....

N. Soundarajan and S. Fridella. Inheriting and modifying behavior. In Meyer Ege, Singh, editor, Proceedings of TOOLS '97, pages 148--163. IEEE Computer Society Press, 1997.

....existing classes, with the derived class not being conceptually closely related to the base class. Such derived classes of course are not meant to be used polymorphically and will not obey the restrictions imposed in this paper. We will not consider such use of inheritance in this paper; in [14] we show how the designer of such derived classes can, in validating his 3 class, make use of much of the reasoning that the base class designer went through in validating the behavior of the base class. Finally, OO polymorphism does not require, for its implementation, a C like inheritance ....

....class of B. 4 Let us first consider how to specify B. As usual, each class will have a concrete specification and an abstract specification. The concrete specification of B is needed not only when establishing the correctness of B s implementation, but also, as we discuss in some detail in [14], when establishing the correctness of D s implementation. Since our focus in this paper is on reasoning about the behavior of client code rather than on establishing that classes meet their specifications, we will not worry about the concrete specifications of the classes, but instead concentrate ....

[Article contains additional citation context not shown here]

N. Soundarajan and S. Fridella. Inheriting and modifying behavior. In Proceedings of TOOLS, published by IEEE Computer Society (to appear), 1997.

No context found.

N. Soundarajan and S. Fridella "Inheriting and Modifying Behavior", in Proceedings of the 23rd International Conference on Technology of Object Oriented Systems, TOOLS 23, pp. 148-162, IEEE Computer Society Press, 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