Seiter, L.M., J. Palsberg, and K.J. Lieberherr. Evolution of Object Behavior Using Context Relations. in Fourth ACM SIGSOFT Symposium on the Foundations of Software Engineering. 1996. San Francisco: ACM.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....Baumgartner, Laufer and Russo [1] propose an implementation of Visitor based on multi method dispatch and claim that it makes datatype and toolkit extension easy, but they do not recognize the problems that arise when extending tools or coordinating multiple tools. Seiter, Palsberg, and Lieberherr [29] describe how dynamic relationships between classes can be captured more expressively using context relations, which extend and override the behavior of classes and decouple behavioral evolution and inheritance hierarchies. While context relations offer a more concise way of expressing ....

Seiter, L. M., J. Palsberg and K. J. Lieberherr. Evolution of object behavior using context relations. IEEE Transactions on Software Engineering, 1998.

....are very generic. For example we implemented Lasagne on top of the Java implementation of Aspect Components (JAC) 21] With regard to the composition filters model, incoming messages can be delegated to a meta object that implements the necessary coordination mechanisms. Linda Seiter et al. [22] proposed a context relation to dynamically modify a group of base classes. A context class contains several method updates for several base classes. A context object may be dynamically attached to a base object, or it may be attached to a collaboration, in which case it is implicitly attached to ....

L. Seiter, J. Palsberg, and K. Lieberherr, "Evolution of Object Behavior using Context Relations. In IEEE Transactions on Software Engineering, 24(1), 1998.

....additional measures (e.g. conditional statements in the form of if (notifyEnabled) to be able to choose at runtime which graphs feature the notification behavior. A number of approaches focus on the evolution of single objects or single classes. The basic idea of the context relationship [30] is that if a class C is contextrelated to a base class B, then B objects can get their functionality dynamically altered by C objects. A C object may be explicitly attached to a B object, or it may be implicitly attached to a group of B objects for the duration of a method invocation. In Rondo ....

L. M. Seiter, J. Palsberg, and K. Lieberherr. Evolution of object behavior using context relations. IEEE Transactions on Software Engineering, 24:79--92, 1998.

....Components has however no explicit support for selective combination on a per collaboration basis. This could of course be added, as we proved recently by implementing Lasagne on top of the Java implementation of Aspect Components (JAC) 4.2. Dynamic behavior composition Linda Seiter et al. [15] proposed a context relation to dynamically modify a group of base classes. A context class contains several method updates for several base classes. A context object may be dynamically attached to a base object, or it may be attached to a collaboration, in which case it is implicitly attached to ....

L. Seiter, J. Palsberg, and K. Lieberherr, "Evolution of Object Behavior using Context Relations. In IEEE Transactions on Software Engineering, 24(1), 1998.

.... LAC allows modular software composition along these lines: It allows collaboration based development like PCA[7] some techniques of generative programming [12] and Hyper J [11] Activating and deactivating Connectors provides for dynamic, stateful contexts as in PCA[7] and Context Relations [10]. Using wildcard based weaving allows modularization of code that would otherwise be scattered through many di erent places. In this, LAC resembles AspectJ [9] Composition is performed by a separate module, the Connector, thus strictly decoupling Collaboration and base. Also Connectors are ....

L. Seiter, J. Palsberg, and K. Lieberherr. Evolution of Object Behavior using Context Relations. IEEE Transactions on Software Engineering, 24(1):79{ 92, Jan. 1998. 5

....In addition, our model is more flexible in that in contrast to the aforementioned approaches, objects do not have a single special parent attribute. In our model it is possible to override and redirect multiple arbitrary attributes. Predicate objects [10] Rondo [21] and the context relationship [27] allow the programmer to express certain kinds of context dependent facets of an object by explicit linguistic means. The composition of the basic behavior of an object and its facets obeys delegation semantics in [10, 27] and some form of mixin based inheritance in [21] Our model shares with ....

....attributes. Predicate objects [10] Rondo [21] and the context relationship [27] allow the programmer to express certain kinds of context dependent facets of an object by explicit linguistic means. The composition of the basic behavior of an object and its facets obeys delegation semantics in [10, 27], and some form of mixin based inheritance in [21] Our model shares with these approaches the support for a two dimensional incremental modification: 1) vertically by means of inheritance in our model, Rondo, and context relationship, respectively by means of delegation in predicate objects, ....

[Article contains additional citation context not shown here]

L. Seiter, J. Palsberg, and K. Lieberherr. Evolution of object behavior using context relations. In D. Garlan, editor, Proceedings of the 4th ACM SIFSOFT Symposium on Foundations of Software Engineering, pages 46--56. ACM Press, 1996. Software Engineering Notes 21(6).

....Components has however no explicit support for selective combination on a per collaboration basis. This could of course be added, as we proved recently by implementing Lasagne on top of the Java implementation of Aspect Components (JAC) 5.2. Dynamic behavior composition Linda Seiter et al. [20] proposed a context relation to dynamically modify a group of base classes. A context class contains several method updates for several base classes. A context object may be dynamically attached to a base object, or it may be attached to a collaboration, in which case it is implicitly attached to ....

L. Seiter, J. Palsberg, and K. Lieberherr, "Evolution of Object Behavior using Context Relations. In IEEE Transactions on Software Engineering, 24(1), 1998.

....For any class in the base module, the programmer should know which specialized metaclass corresponds to the particular property setting in the contract of the class. Furthermore, extending the system to support new kinds of properties is not easy in such tangled hierarchies. Finally, as argued in [18, 19, 21], dynamic behavior alterations of an existing (meta)object are difficult to handle when static inheritance is used as the mechanism for behavior variation. Smalltalk 80 takes a different approach to support classes with special semantics, as presented in Fig. 11 (for the sake of simplicity, only ....

Seiter L., Palsberg J., and Lieberherr K. Evolution of Object Behavior using Context Relations. In Garlan D., (ed.), Proceedings of the 4th ACM SIGSOFT Symposium on the Foundations of Software Engineering, Software Engineering Notes, Vol.21, No. 6, pp.46--56, ACM Press, Nov. 1996.

....descriptions of paths in the class graph and do not embed detailed knowledge about the structure. Behavior written in this way is more robust against structural changes. Several works in the area of object oriented language design on roles [13] composition filters [1] context objects [44], variation oriented programming [27] etc. also propose language support for separating the definition of di#erent aspects. However, they focus on the separation of concerns at the level of a single, isolated object, and ignore important issues that need to be addressed when dealing with sets ....

L. Seiter, J. Palsberg, and K. Lieberherr. Evolution of Object Behavior using Context Relations. IEEE Transactions on Software Engineering, 24(1):79--92, Jan. 1998. 17

....succinct descriptions of paths in the class graph and do not embed detailed knowledge about the structure. Behavior written in this way is more robust against structural changes. Several works in the area of object oriented language design on roles [13] composition lters [1] context objects [44], variation oriented programming [27] etc. also propose language support for separating the de nition of di erent aspects. However, they focus on the separation of concerns at the level of a single, isolated object, and ignore important issues that need to be addressed when dealing with sets of ....

L. Seiter, J. Palsberg, and K. Lieberherr. Evolution of Object Behavior using Context Relations. IEEE Transactions on Software Engineering, 24(1):79-92, Jan. 1998.

....code is structured to expose as join points those places where an invariant becomes or ceases to be true. Karl Lieberherr et al. at Northeastern University are developing techniques that make object oriented programs more reusable and less brittle in the face of common program evolution tasks [13, 15, 31]. In their work, the component languages are existing OOPs like C and Java. Succinct traversal specifications [13] and context objects [31] provide aspect languages that can be used to address a variety of crosscutting issues. Weaving of aspect programs that use succinct traversal specification ....

....University are developing techniques that make object oriented programs more reusable and less brittle in the face of common program evolution tasks [13, 15, 31] In their work, the component languages are existing OOPs like C and Java. Succinct traversal specifications [13] and context objects [31] provide aspect languages that can be used to address a variety of crosscutting issues. Weaving of aspect programs that use succinct traversal specification is compile time oriented, the join point representation is, roughly speaking, the class graph. Weaving of aspect programs that use context ....

Seiter L. M., Palsberg J., et al., Evolution of Object Behavior Using Context Relations, in proc. Fourth ACM SIGSOFT Symposium on the Foundations of Software Engineering, pp. 46--57, San Francisco, 1996.

....may be explicitly built and attached to an object. Also attached to each object is a set describing patterns of ancestor classes. When a message is received by an object, the choice of method to invoke is determined by which pattern the ancestor list of that object matches. Context relations [13] provide a language based mechanism in support of the Strategy pattern [4] by allowing context objects, basically dispatch tables, to be dynamically attached to instances. Upon receipt of a message by an object, method selection is performed by the context object currently attached to the ....

L. Seiter, J. Palsberg, and K. Lieberherr. Evolution of object behavior using context relations. IEEE Transactions on Software Engineering, 24(1):79--92, 1998.

.... No industry, type of business, or company is immune [13] In our research, systematic management and automation of software evolution processes, such as formalizing the software evolution process [11] prototyping the software [7, 8, 10] seeking the relationship among software evolution objects [1, 6, 9, 14]; and reusing software evolution components [5, 15] can hold out the promise of significantly improving these numbers. This research was supported in part by the U. S. Army Research Lab under grant number 7DNAVYR010 and in part by the U. S. Army Research Office under contract grant number ....

....Office under contract grant number 38690. 2. Previous work and open issues There are numerous results related to our research about the formalization and automation of software evolution processes that have been published in the past decade. These include: object oriented software evolution [6, 14], software evolution through computer aided prototyping [7, 8, 10] a graph data model and control system for evolution [9] a hypergraph model for evolution [11] a change merging model for prototyping [4] a mechanism for retrieving reusable components [5] an evolution control system model and ....

[Article contains additional citation context not shown here]

L. Seiter, J. Palsberg, K. Leiberherr, Evolution of Object Behavior Using Context Relations, IEEE Trans. on Software Engineering, Vol. 24, No. 1, January 1998, pp. 79-92.

....emphasizes changing the semantics of multiple objects, although in a more abstract way (aspects may encapsulate changes in the semantics of components or in implementation policies) Mezini s approach [22] emphasizes dynamic (single )object evolution with mixin components. The context relations of [30] concentrate on dynamic modifications to a group of classes. Feature oriented programming [27] focuses on role (or feature) interaction, through explicit entities (called lifters) that determine how two features interact. The nested mixin methods of Agora [34] offer a powerful mechanism to ....

L. Seiter, J. Palsberg, and K. Lieberherr, "Evolution of Object Behavior using Context Relations", ACM SIGSOFT 1996.

....is strongly dependent on its name and type, increasing component coupling and the presence of EEK. Predicate classes [1] permit the type of an object to be transiently redefined according to its state (or according to a userdefined predicate that can be fairly arbitrary) Context relations [5] provide a language based mechanism in support of the Strategy design pattern by allowing context objects to be dynamically attached to instances. Subjectivity [2] allows different method implementations to be executed for a message depending on the run time type of the sender of the message. ....

....reflection and dispatch. Reflection is ordinarily defined in terms of monitoringand altering what is currently occurring within a system not what has already taken place. Many attempts have been made to leverage the idea of context in interpreting messages or selecting implementations (e.g. [5, 3]) These approaches are quite static, looking only at the current state of the system, or more likely, some small portion thereof. But the previous state and execution of the system have a lot to say about what should happen next: whether certain components have been used yet when they need to ....

L. Seiter, J. Palsberg, and K. Lieberherr. Evolution of object behavior using context relations. IEEE Trans. on Software Engineering, 24(1):79--92, 1998.

....the conflicts cannot be detected at compile time. Unfortunately, none of the existing object oriented incremental composition mechanisms provides a general framework to handle these issues in a uniform manner. The class based inheritance models do not support dynamic composition, as argued in [11, 22, 24, 30, 32, 35]. The object based [38] and hybrid [33] inheritance models do provide support for dynamic composition of object behavior, but at the price of violating the encapsulation of the client interface [35] and losing valuable sharing and structuring mechanisms [32] The approaches that model real world ....

.... modifications within an object itself, but the problem is that an object is required to know all its possible modifications in advance [35] Moreover, neither the mixin methods approach, nor more advanced approaches to behavior composition, such as composition filters [1] or the context relation [30], adequately support internal encapsulation. With respect to internal encapsulation, most of existing inheritance models either declare name collisions as invalid, i.e. they do not support internal encapsulation at all (like single inheritance and linear approaches to multiple inheritance [14, ....

[Article contains additional citation context not shown here]

Seiter L. M., Palsberg J, Lieberherr K. Evolution of object behavior using context relations. In Garlan D., ed., Proceedings of the 4th ACM SIFSOFT Symposium on Foundations of Software Engineering, Software Engineering Notes, vol. 21, no. 6, pp. 46--56, ACM Press, 1996.

....or objects. For other extensions such as parameterized features and a detailed comparison to object oriented techniques we again refer to [8] Among related work on software composition is adaptive programming [7] which aims at adaptable software design. Some versions of adaptive programming [10] apply similar techniques as we do here, but do not consider the idea of feature interaction and composition. ....

Linda M. Seiter, Jens Palsberg, and Karl J. Lieberherr. Evolution of object behavior using context relations. In David Garlan, editor, Symposium on Foundations of Software Engineering, San Francisco, 1996. ACM Press.

....determine when a composition is harmless. As this criterion is based on the features of meta operators and program slices, and not of a special aspect language, it is valid for all application domains and easy to check. Context relations allow to adapt objects to their context at allocation time [SPL96] This is similar to the exchange of superclasses at allocation time [Wec97] However, adapting components and exchanging superclasses is just a special case of meta programmed composition at allocation time. Composition filters [Ber94] ABV92] and the layered object model [Bos95] represent ....

Linda M. Seiter, Jens Palsberg, and Karl J. Lieberherr. Evolution of Object Behavior using Context Relations. In David Garlan, editor, 4th ACM SIGSOFT Symposium on the foundations of Software Engineering, pages 46--57, October 1996.

....of a method of the service. It is called whenever the appropriate method is invoked. Further approaches to dynamic objects are reflective object architectures and meta object protocols (MOP) as implemented in CLOS [Kic91] or GBO [Bis96a, Bis96b] Context relations as defined by Seiter et al. [Sei96] provide an interesting theoretical background for dynamic objects. 4.7 Extended semantic data representation mechanisms Almost each one of the introduced mechanisms profits from SDRMs, although they are rather simple. Unfortunately, SDRMs are not well suited for the handling of large amounts of ....

Seiter L, Palsberg J, Lieberherr K: Evolution of Object Behavior using Context Relations. In ACM SIGSOFT'96, San Francisco, CA, October 1996

....L aufer and Russo [1] propose an implementation of Visitor based on multi method dispatch and claim that it makes datatype and toolkit extension easy, but they do not recognize the problems that arise when extending tools or coordinating multiple tools. Seiter, Palsberg, and Lieberherr [29] describe how dynamic relationships between classes can be captured more expressively using context relations, which extend and override the behavior of classes and decouple behavioral evolution and inheritance hierarchies. While context relations offer a more concise way of expressing ....

Seiter, L. M., J. Palsberg and K. J. Lieberherr. Evolution of object behavior using context relations. IEEE Transactions on Software Engineering, 1998.

....However, contracts do not allow conflicting customizations to be simultaneously active. Thus, it is not possible to allow different instances of a class to follow different collaboration schemes. Seiter et al. proposed a context relation to link the static and dynamic aspects of a class [17]. While supporting multiple dynamic collaboration schemes, the approach is based on dynamically altering a class definition for the duration of a method invocation, thus affecting all class instances. Multiple dynamic variations of an object s behavior are also supported in the Rondo model [12] ....

L. Seiter, J. Palsberg, and K. Lieberherr. Evolution of Object Behavior using Context Relations. In IEEE Transactions on Software Engineering, January 1998.

....OO teaching tool combined with [5] RELATED WORK Numerous references to related work are in [5] Recently, aspect oriented programming from Xerox PARC has emerged as an area related to AP [4, 3] See also http: www.parc.xerox.com aop. The work on context objects is a generalization of visitors [7]. ACKNOWLEDGEMENTS This work is supported by DARPA and Rome Laboratory under agreement F30602 96 0239 and NSF under grant CCR 9402486 and a grant from Xerox PARC. We thank Jens Palsberg, Boaz Patt Shamir, Linda Seiter, Mitchell Wand for their input to Demeter Java and to Kedar Patankar, Binoy ....

L. M. Seiter, J. Palsberg, and K. J. Lieberherr. Evolution of Object Behavior using Context Relations. In D. Garlan, editor, Symposium on Foundations of Software Engineering, San Francisco, 1996. ACM Press.

....they are only syntactic 1 sugar to express certain commonly occurring traversals and visitors. The insight we gained was that propagation patterns were too big of an abstraction which is better decomposed into traversals and visitors with an attachment mechanism of visitors to traversals [8]. While in Demeter C traversals are static, in Demeter Java with the TAO (traversal as objects) extension, traversals may be computed at run time. Johan Ovlinger) While in Demeter C generic behavior for copying, printing, etc. was hardcoded for entire objects, in Demeter Java you can ....

....Java. RELATED WORK Numerous references to related work are in [6] and the Demeter home page. Recently, aspectoriented programming from Xerox PARC has emerged as an area related to AP [4, 3] See also http: www.parc.xerox.com aop. The Demeter Java visitors are inspired by the context objects in [8]. ACKNOWLEDGEMENTS This work is supported by DARPA and Rome Laboratory under agreement F30602 96 0239 and NSF under grant CCR 9402486 and a grant from Xerox PARC. John Salasin was influential in guiding this project, both as an NSF and a DARPA project. ....

L. M. Seiter, J. Palsberg, and K. J. Lieberherr. Evolution of Object Behavior using Context Relations. In D. Garlan, editor, Symposium on Foundations of Software Engineering, San Francisco, 1996. ACM Press.

....by relaxing the class subclass relationships that could also support modeling stand alone behavior that can be reused in several scenarios. This category includes the work on mixin based inheritance [4,5] contracts [10] mixinmethods [16] MixedJava [6] Rondo [18] and context relationship [20]. These works share the fact that variations on a base behavior are modeled in stand alone artifacts called mixins in [4,5] and [6] contracts in [10] mixinmethods in [16] adjustments in [18] and context objects in [20] These artifacts do not commit to any base behavior when defined. Rather, ....

.... mixinmethods [16] MixedJava [6] Rondo [18] and context relationship [20] These works share the fact that variations on a base behavior are modeled in stand alone artifacts called mixins in [4,5] and [6] contracts in [10] mixinmethods in [16] adjustments in [18] and context objects in [20]. These artifacts do not commit to any base behavior when defined. Rather, they refer to the base behavior by means of an (unbound) super parameter and the self reference. The individual approaches differ from each other on two main points: 1) the level at which the variation is specified ....

Seiter, L., Palsberg, J., Lieberherr, K. Evolution of Object Behavior Using Context Relations. IEEE Transactions on Software Engineering. Vol. 24, No. 1, January 1998, pp. 79-92.

....However, contracts do not allow conflicting customizations to be simultaneously active. Thus, it is not possible to allow different instances of a class to follow different collaboration schemes. Seiter et al. proposed a context relation to link the static and dynamic aspects of a class [18]. While supporting multiple dynamic collaboration schemes, main.tex; 24 01 2000; 17:21; p.26 27 the approach is based on dynamically altering a class definition for the duration of a method invocation, thus affecting all class instances. Multiple dynamic variations of an object s behavior are also ....

L. Seiter, J. Palsberg, and K. Lieberherr. Evolution of Object Behavior using Context Relations. In IEEE Transactions on Software Engineering, 24(1), pp. 79--92, 1998.

....by relaxing the class subclass relationships that could also support modeling stand alone behavior that can be reused in several scenarios. This category includes the work on mixin based inheritance [2,3] contracts [8] mixin methods [14] MixedJava [4] Rondo [16] and context relationship [18]. These works share the fact that variations on a base behavior are modeled in stand alone artifacts called mixins in [2,3] and [4] contracts in [8] mixin methods in [14] adjustments in [16] and context objects in [18] These artifacts do not commit to any base behavior when defined. Rather, ....

.... [8] mixin methods [14] MixedJava [4] Rondo [16] and context relationship [18] These works share the fact that variations on a base behavior are modeled in stand alone artifacts called mixins in [2,3] and [4] contracts in [8] mixin methods in [14] adjustments in [16] and context objects in [18]. These artifacts do not commit to any base behavior when defined. Rather, they refer to the base behavior by means of an (unbound) super parameter and the self reference. The individual approaches differ from each other on two main points: 1) the level at which the variation is specified ....

Seiter, Linda, Palsberg, Jeng, and Lieberherr, Karl. Evolution of Object Behavior Using Context Relations. IEEE Transactions on Software Engineering. Vol. 24, No. 1, January 1998, pp. 79-92.

....by relaxing the class subclass relationships that could also support modeling stand alone behavior that can be reused in several scenarios. This category includes the work on mixin based inheritance [4,5] contracts [10] mixinmethods [16] MixedJava [6] Rondo [18] and context relationship [20]. These works share the fact that variations on a base behavior are modeled in stand alone artifacts called mixins in [4,5] and [6] contracts in [10] mixinmethods in [16] adjustments in [18] and context objects in [20] These artifacts do not commit to any base behavior when defined. Rather, ....

.... mixinmethods [16] MixedJava [6] Rondo [18] and context relationship [20] These works share the fact that variations on a base behavior are modeled in stand alone artifacts called mixins in [4,5] and [6] contracts in [10] mixinmethods in [16] adjustments in [18] and context objects in [20]. These artifacts do not commit to any base behavior when defined. Rather, they refer to the base behavior by means of an (unbound) super parameter and the self reference. The individual approaches differ from each other on two main points: 1) the level at which the variation is specified ....

Seiter, L., Palsberg, J., Lieberherr, K. Evolution of Object Behavior Using Context Relations. IEEE Transactions on Software Engineering. Vol. 24, No. 1, January 1998, pp. 79-92.

....to ensure type safety, the inability to override existing behavior in a controlled manner, as well as the negative performance impact. To directly model and implement dynamic variations of behavior, we introduce a new kind of relation called the context relation to the object oriented model [8]. In the remainder of this paper, we demonstrate how the context relation solves many problems associated with dynamic evolution. The relation exists between classes and is intended to support behavioral evolution while maintaining the safety and performance benefits available with strongly typed, ....

Linda M. Seiter, Jens Palsberg, and Karl J. Lieberherr, "Evolution of Object Behavior using Context Relations," in ACM SIGSOFT'96: The Fourth Symposium on the Foundations of Software Engineering, San Francisco, CA, October 1996.

....with the given concrete path set. To make the traversal useful, each object has a special visit method attached to it; when an object is added to the traversal history, this method is invoked. A more comprehensive discussion of the visitor programming pattern and visitor methods can be found in [5, 21]. But first, we define traversals formally. The definition here is adapted from the simplified semantics from [19] We use a few technical notions. For a set of sequences R, define head(R) fx j 9ff: xff 2 R)g tail(R; x) fff j xff 2 Rg : In the definition below, we shall assume that there ....

Linda M. Seiter, Jens Palsberg, and Karl J. Lieberherr. Evolution of Object Behavior using Context Relations. In David Garlan, editor, Symposium on Foundations of Software Engineering, San Francisco, 1996. ACM Press (SIGSOFT). To appear in IEEE Transactions on Software Engineering.

No context found.

Seiter, L.M., J. Palsberg, and K.J. Lieberherr. Evolution of Object Behavior Using Context Relations. in Fourth ACM SIGSOFT Symposium on the Foundations of Software Engineering. 1996. San Francisco: ACM.

No context found.

L.M.Seiter, J.Palsberg, K.J.Lieberherr, "Evolution of Object Behavior Using Context Relations", IEEE Transactions on Software Engineering, (24)1, 1998.

No context found.

L. Seiter, J. Palsberg, and K. Lieberherr, "Evolution of Object Behavior using Context Relations", ACM SIGSOFT 1996.

No context found.

Seiter L. M., Palsberg J, Lieberherr K. 1996. Evolution of Object Behavior Using Context Relations.

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