| 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. |
....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.
....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.
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.
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