P. Steyaert, C. Lucas, K. Mens, and T. D'Hondt. Reuse Contracts: Managing the Evolution of Reusable Assets. In Object-Oriented Programming Systems, Languages, and Applications, October 1996.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....to invoke methods whose names are dynamically build at runtime. Dependencies of these kinds of invocations cannot be retrieved statically. However, it is possible to compute sensible suggestions to programmers. We are also investigating another approach using dependency attributes (see also [7] [5] instead of being code retrieved, dependencies could express imposed design decisions, thus realizing strong data abstraction. Investigation on this path is still needed. Our experience shows that the new features provided by the .NET platform could be used to support developers in writing ....

P. Steyaert, C. Lucas, K. Mens, and T. D'Hondt. Reuse contracts: Managing the evolution of reusable assets. In OOPSLA '96 Conference on Object-Oriented Programming Systems, Languagges and Applications, pages 268--285. ACM Press, October 1996.

....correctly. An object oriented framework consists of a class hierarchy that must be subclassed and extended to instantiate an application. Frameworks make use of many common idioms and design patterns, and the rules for correctly subclassing the framework classes typically entail reuse contracts [18] that may only be implicit in the code. Not only are OO frameworks hard to develop, but they entail a steep learning curve to use them. Missing Plugs. OO frameworks tend to be based on white box reuse , i.e. requiring knowledge of implementation details. Black box (component based) reuse is ....

Patrick Steyaert, Carine Lucas, Kim Mens, and Theo D'Hondt. Reuse contracts: Managing the evolution of reusable assets. In Proceedings of OOPSLA '96 Conference, pages 268--285. ACM Press, 1996.

....notation) that aims at improving the selection and usage processes in component based software development. They are somehow similar approaches, although none of them is associated to any commercial component platform like CORBA or EJB, nor supported by standard proving tools. Reuse Contracts [Steyaert et al. 1996] is another well known proposal, although it is based on textual annotations to facilitate the reuse by humans, not by computer programs during object execution. Bastide et al. Bastide et al. 1999] use Petri nets to describe the behavior of CORBA objects, providing their full operational ....

Steyaert, P., Lucas, C., Mens, K., and d'Hondt, K. (1996). Reuse contracts: Managing the evolution of reusable assets. ACM SIGPLAN Notices, 31(10):268--285.

....to the bag. The user also overrides the cardinality method to return the value of n which should be equal to the number of elements in the bag. Note that the user is obliged to verify that CountingBag is substitutable for Bag to be safely used by the framework. This example is adopted from [26] Leonid Mikhajlov and Emil Sekerinski After some time a system developer decides to improve the e#ciency of the class Bag and releases a new version of the system. An improved Bag # implements addAll without invoking add. Naturally, the system developer claims that the new version of the ....

....towards developing a methodology for specifying classes to make code reuse less error prone. The key idea of extending a class specification with specification of its specialization interface was presented first by Kiczales and Lamping in [16] This idea was further developed by Steyaert et al. in [26]. In fact the second paper considers the fragile base class problem in our formulation (although they do not refer to it by this name) The authors introduce reuse contracts that record the protocol between managers and users of a reusable asset . Acknowledging that reuse contracts provide only ....

[Article contains additional citation context not shown here]

P. Steyaert, Carine Lucas, Kim Mens, Theo D'Hondt. Reuse contracts: managing the evolution of reusable assets. OOPSLA'96 Proceedings, volume 31 of SIGPLAN Notices, pp. 268--285, 1996. 357, 376, 376

....of Lamping et al. 4, 3] where they advocated the use of a specialization interface, di#erent from the use one. Specialization interfaces were augmented by Stata et al. 11] by incorporating full behavioral specifications. A detailed study on reuse operators and their interactions appeared in [12]. They proposed to associate with any class a reuse contract, composed by method signatures annotated with dependencies information. Reuse contracts record the protocol between developers and inheritors of a reusable component and they can be amended by using a number of predefined operators ....

P. Steyaert, C. Lucas, K. Mens, and T. D'Hondt. Reuse contracts: Managing the evolution of reusable assets. In ACM SIGPLAN Notices, volume 31, pages 268--285. ACM, Oct. 1996. Proceedings of Conference on Object-Oriented Programming, Systems, Languages and Applications.

....but with local requirements of individual components that are violated only in a few situations; in these cases, effective testing can be very difficult to achieve. So techniques are needed in order to guarantee that evolution does not induce a degradation of the system or affect its reliability [16, 19]. We think that design issues should be represented in a manner that can be processed by a machine [3] so that they can be verified whenever a change is made to the system. Pre postconditions and invariants have been used for this purpose [17] but software must be executed in order for these ....

Steyaert, Patrick et al. Reuse contracts: Managing the evolution of reusable assets. Proceedings of OOPSLA'96, vol. 31(10) of ACM Sigplan Notices, pages 268-285. ACM Press, 1996.

.... The past years has seen a lot of research activity on how to increase re use and quality of design through techniques as (re)factoring [Foo95] reflection [Foo96] how to support design and documentation through patterns [Gam95] how to support the development process through re use contracts [Ste96] and how frameworks evolve [Rob96] Yet few results show how to capture the simple observation that what may be a stable model or piece of software in one organization, may evolve very soon or even continuously within another one. Likewise some components can be re usable across different ....

Patrick Steyaert, Carine Lucas, Kim Mens, Theo D'Hondt, Reuse Contracts: Managing the Evolution of Reusable Assets, Proceedings of the ACM OOPSLA'96 Conference on Programming Systems, Languages and Applications, 1996

....component interaction. Secondly, components to be composed by delegation depend on the specialization interface of their parent components. Therefore, further advances of component interface specifications are required, which make its specialization interface ( 18] or reuse contract ([22]) explicit, along with other work aimed at solving the semantic fragile base class problem ( 20, 24, 27] Finally, the impact of language support for delegation on general design patterns, component design methods, component description languages, component architectures and component ....

P. Steyaert; C. Lucas; K. Mens, et al.: "Reuse Contracts: Managing the Evolution of Reusable Assets", Proceedings OOPSLA '96, ACM SIGPLAN Notices, no. (1996), pp. 268-285.

....a tool called JPort for exploring evolution between successive versions of the JDK. Their intent was to provide a tool for detecting possible problem areas when developers wish to port their Java tools across versions of the JDK. They provide evolution analysis at the level of Reuse Contracts [STE 96] In [JAZ 99, RIV 98] Claudio Riva presents work which has similarities with ours, i.e. he also visualizes several versions of software (at subsystem level) using colors. Through the obtained colored displays they can make conclusions about the evolution of a system. Their approach differs as ....

STEYAERT P., LUCAS C., MENS K., D'HONDT T., "Reuse Contracts: Managing the Evolution of Reusable Assets", Proceedings of OOPSLA '96 Conference, ACM Press, 1996, p. 268-285.

....a tool called JPort for exploring evolution between successive versions of the JDK. Their intent was to provide a tool for detecting possible problem areas when developers wish to port their Java tools across versions of the JDK. They provide evolution analysis at the level of Reuse Contracts [STE 96] In [JAZ 99, RIV 98] Claudio Riva presents work which has similarities with ours, i.e. he also visualizes several versions of software (at subsystem level) using colors. Through the obtained colored displays they can make conclusions about the evolution of a system. Their approach differs as ....

STEYAERT P. LUCAS C., MENS K., D'HONDT T., "Reuse Contracts: Managing the Evolution of Reusable Assets", Proceedings of OOPSLA '96 Conference, ACM Press, 1996, p. 268-285.

....From this perspective, one of the current concerns with components is that the usual signature based interface definitions do not describe the component communication precisely enough. The need for such a definition is reflected in efforts of the object oriented programming community, e.g. in [3, 16, 24, 26]. 1.1. Objects and protocols An object interface definition can be considered as a service definition. As stated in [15] the sequences of requests (method calls) that an object is capable of servicing constitute the object s protocol, a specification of which should be an integral part of the ....

....(Wright, TRACTA, etc. In UML related ROOM [24] the approach chosen is similar to the collaborating interfaces [28] however, communication is not limited to a pair of interfaces. Also, a protocol conformance (called role substitutability) is, only briefly, outlined in [24] Reuse contracts [26] introduce the idea of specifying the set of internally invoked methods for each method of an interface, thus capturing the invocation dependencies among methods. However, the model presented in [26] is limited in the sense that since it provides description only at the object level of ....

[Article contains additional citation context not shown here]

P. Steyaert et al., "Reuse Contracts: Managing the Evolution of Reusable Assets," Proceedings of the OOPSLA `96, ACM SIGPLAN Notices, Vol. 31, No. 10, Oct. 1996, pp. 268--285.

....for delegation based component interaction. Also, components to be composed by delegation depend on the specialization interface of their parent components. Therefore, advanced component interface specifications and approaches to the semantic fragile base class problem are required ( Lam93] [Ste96], Mik97, Szy98, Wec97] ....

Steyaert, Patrick and Lucas, Carine and Mens, Kim and D'Hondt, Theo. Reuse Contracts: Managing the Evolution of Reusable Assets. Proceedings OOPSLA '96, ACM SIGPLAN Notices, pages 268--285, 1996.

....their methods and accessing their attributes. It also contains extending methods, i.e. methods which do a super call on a method with the same name. Note that such classes may be fragile, as a change in a superclass (for example removal of a method) has a direct effect on the depending subclasses [25]. The case of a pure talking extender, like we can see in Figure 16 marked as B, is rare. Mute Overrider.Amute overrider class is one which contains at least one overriding method and is thus bound to its superclass. It does however not invoke methods contained in it or access the attributes of ....

P. Steyaert, C. Lucas, K. Mens, and T. D'Hondt. Reuse contracts: Managing the evolution of reusable assets. In Proceedings of OOPSLA '96 Conference, pages 268--285. ACM Press, 1996.

....There is a tight dependency of the subclasses on their base class which is contradictory to their distribution. The contracts between the components in an implementation hierarchy are implicit and thus not clearly de ned. This problem is known as fragile base class problem [23] As outlined in [22] use of inheritance can lead to unimplemented, inconsistent methods and con icts in method interfaces. In this paper we propose an alternative approach to implement collaborationbased design and therefore achieve a functionality similar to mixin layers. We employ Aspect Oriented Programming (AOP) ....

Steyaert, P., Lucas, C., Mens, K., D'Hondt, T.: Reuse Contracts: Managing the Evolution of Reusable Assets. In: Proceedings of OOPSLA'96, (1996) 268 - 285

....implementation of addAll does not use add but immediately adds all methods, then CountingSet needs to override both methods. Several approaches were taken to alleviate these problems and provide more constrained forms of white box reuse (such as specialization interfaces [11] or reuse contracts [12]. The design pattern movement aimed at providing a better way of documenting, communicating and reusing solutions to common design problems [8, 5] like the (active) cookbook approach before it [10] Other composition mechanisms were investigated, such as Aspect Oriented Programming [9] Subject ....

P. Steyaert, C. Lucas, K. Mens, and T. D'Hondt. Reuse contracts: Managing the evolution of reusable assets. In Proceedings OOPSLA '96, ACM SIGPLAN Notices, pages 268--285. ACM Press, 1996.

....their methods and accessing their attributes. It also contains extending methods, i.e. methods which do a super call on a method with the same name. Note that such classes may be fragile, as a change in a superclass (for example removal of a method) has a direct effect on the depending subclasses [25]. The case of a pure talking extender, like we can see in Figure 16 marked as B, is rare. Mute Overrider.Amute overrider class is one which contains at least one overriding method and is thus bound to its superclass. It does however not invoke methods contained in it or access the attributes of ....

P. Steyaert, C. Lucas, K. Mens, and T. D'Hondt. Reuse contracts: Managing the evolution of reusable assets. In Proceedings of OOPSLA '96 Conference, pages 268--285. ACM Press, 1996.

....process. Process contracts proposed in this article, provide a formalization of software artifacts and their relationships. Also process contracts clearly establish pre and post conditions for each software development task. Process contracts are related to the mechanism of reuse contracts [33] [17] A reuse contract describes a set of interacting participants. Reuse contracts can only be adapted by means of reuse operators that record both the protocol between developers and users of a reusable component and the relationship between different versions of one component that has evolved. ....

Steyaert, P..Lucas, C.Mens K and D'Hondt, T. Reuse Contracts: Managing the evolution of reusable assets. In proceedings of OOPSLA'96, New York, Oct 1996.

....module: the redefinitions of the inheritor are based on assumptions made with respect to the calling structure of the base. If the base module is later changed by its designer, these assumptions may not hold anymore, and the inheritor s behavior could therefore get invalidated. Steyaert et al. [24] provide a comprehensive analysis of these problems, motivating the need for mechanisms to manage the changes a base module may undergo in order to be improved. The absence of such mechanisms has also been recognized by other authors [8] as a major obstacle to successful reuse. In the remainder of ....

....the efficient implementation of the base module is based are not maintained by the inheritor. This trade off between easy reuse and efficient implementations has been discussed by Kiczales and Lamping in [11] The problems outlined above have recently attracted the attention of several authors [9, 11, 13, 14, 24]. However, the existing approaches deal only with one category of problems and ignore the other. The approach proposed in [11] is based on informal descriptions of complex protocols which should be considered by the inheritor. Other proposals [9, 23, 24] approach the problems by means of formal ....

[Article contains additional citation context not shown here]

Steyaert P., Lucas C., Mens K., and D'Hondt T. Reuse Contracts: Managing the Evolution of Reusable Assets. In Proceedings of OOPSLA '96, ACM SIGPLAN Notices, Vol. 31 No. 10, pp. 268-- 286, 1996.

.... Research approaches to the contract specification range from supplying additional informal documentation (Murer et al. 1997) to more formal approaches, some of which seek to make interaction structures explicit (Bchi and Sekerinski 1997; Bchi and Weck 1997; De Hondt et al. 1997; Helm et al. 1990; Steyaert et al. 1996). Connecting Components By definition, components are designed for composition (Nierstrasz and Dami 1995; Szyperski 1998) A market based approach to component based development suggests a process where a system designer 4 selects the functionality they require, purchases the appropriate ....

Steyaert, P., Lucas, C., Mens, K., and De Hondt, T. (1996). Reuse Contracts: Managing the Evolution of Reusable Assets. ACM SIGPLAN Notices, 31 (10), pp. 268-285.

....support for delegation based component interaction. Also, components to be composed by delegation depend on the specialization interface of their parent components. Therefore, advanced component interface specifications and approaches to the semantic fragile base class problem are required ([Lam93,SLMD96,MS97,Szy98,Wec97]) 7 Acknowledgements This paper benefited from many discussions with Pascal Costanza and Oliver Stiemerling and from many helpful comments of the anonymous ECOOP reviewers. ....

Patrick Steyaert, Carine Lucas, Kim Mens, and Theo D'Hondt. Reuse Contracts: Managing the Evolution of Reusable Assets. Proceedings OOPSLA '96, ACM SIGPLAN Notices, pages 268--285, 1996.

....From this perspective, one of the current concerns with components is that the usual signature based interface definitions do not describe the component communication precisely enough. The need for such a definition is reflected in efforts of the object oriented programming community, e.g. in [2, 12, 17, 18]. 1.1. Objects and protocols An object interface definition can be considered as a service definition. As stated in [11] the sequences of requests (method calls) that an object is capable of servicing constitute the object s protocol, a specification of which should be an integral part of the ....

....component behavior. Although state diagrams are, in principle, finite state machines, having thus the same expressive power as regular expressions, there is no support in UML for their composition, which would be necessary for reasoning about components composed of subcomponents. Reuse contracts [18] introduce the idea of specifying the set of internally invoked methods for each method of an interface, thus capturing the invocation dependencies among methods. However, the model presented in this work is limited in the sense that since it provides description only at the object level of ....

P. Steyaert et al., "Reuse Contracts: Managing the Evolution of Reusable Assets," Proceedings of the OOPSLA `96, ACM SIGPLAN Notices, Vol. 31, No. 10, Oct. 1996, pp. 268--285.

No context found.

P. Steyaert, C. Lucas, K. Mens, and T. DHondt. Reuse contracts: Managing the evolution of reusable assets. In Proceedings of OOPSLA 96, pages 268--286, 1996.

No context found.

P. Steyaert, C. Lucas, K. Mens, and T. D'Hondt, "Reuse Contracts: Managing the Evolution of Reusable Assets," Proc. OOPSLA '96, ACM SIGPLAN Notices, Vol. 31, No. 10, 1996, pp. 268-286.

No context found.

Patrick Steyaert, Carine Lucas, Kim Mens, Theo D'Hondt, Reuse Contracts: Managing the Evolution of Reusable Assets, Proceedings of OOPSLA '96, ACM SIGPLAN Notices, 31(10), pp. 268-286, ACM Press, 1996.

No context found.

P. Steyaert, C. Lucas, K. Mens, and T. D'Hondt. Reuse contracts: Managing the evolution of reusable assets. In Proceedings OOPSLA '96, ACM SIGPLAN Notices, pages 268--285. ACM Press, 1996.

No context found.

P. Steyaert, C. Lucas, K. Mens and T. D'Hondt. Reuse Contracts: Managing the Evolution of Reusable Assets. Proceedings of OOPSLA '96, ACM SIGPLAN Notices, 31(10), pp. 268286, ACM Press, 1996.

No context found.

P. Steyaert, C. Lucas, K. Mens and T. D'Hondt, "Reuse contracts: managing the evolution of reusable assets", Proc. Int. Conf. Object-Oriented Programming, Systems, Languages and Applications, ACM SIGPLAN Notices, 31(10), ACM Press, 1996, pp. 268-286.

No context found.

P. Steyaert, C. Lucas, K. Mens, and T. D'Hondt. Reuse Contracts: Managing the Evolution of Reusable Assets. In Proc. OOPSLA96 Conf., ACM Sigplan Notices, 1996.

No context found.

P. Steyaert, C. Lucas, K. Mens, T. D'Hondt. Reuse Contracts: Managing the Evolution of Reusable Assets. Proc. OOPSLA '96, SIGPLAN Notices 31(10): 268-286, ACM Press, 1996.

....carried out in DISCO project, where selected parts of an existing mobile switch were modeled. We do not give exact meaning to the notion call, which is perhaps the most intuitive starting point in modeling a switches. However, starting with call leads to difficulties, as pointed out by Zave in [17]. processes Figure 1. Abstraction hierarchy. 4.1. Deriving an Abstraction Hierarchy The abstraction hierarchy derived in this subsection are connection, leg and process. The hierarchy is depicted in Figure 1. Abstractions are discussed in detail in the following. The highest abstraction in the ....

....International Symposium on Principles of Software Evolution (Eds. Takyo Katayama, Tetsuo Tamai, and Naoki Yonezaki) pages 43 47, Kanazawa, Japan, November 1 2, 2000. 16] D. L. Parnas. On the criteria to be used in decomposing systems into modules. Communications of the ACM 15:2, December 1972. [17] P. Zave. Calls considered harmful and other observations: A tutorial on telephony. Services and Visualization: Towards User Friendly Design (Eds. T. Margaria, B. Steffen, R. R uckert and J. Posegga) pages 8 27, Springer Verlag LNCS 1385, 1998. ....

[Article contains additional citation context not shown here]

P. Steyaert, C. Lucas, K. Mens, T. D'Hondt. Reuse Contracts: Managing the Evolution of Reusable Assets. Proc. OOPSLA '96, SIGPLAN Notices 31(10): 268-286, ACM Press, 1996. Transformation of Binary relations into Associationsand Nested Classes Jamal Sa id Eric Steegmans Department of Computer Science, K.U.Leuven

....implementation of the base class can be changed as well. This gives rise to the question how a superclass can be safely replaced by a new version while remaining behaviorally compatible with all of its subclasses. This research question has been addressed in a number of research papers, including [46]. Obviously, the kind and degree of safety that is required has a direct influence on the change support mechanisms that need to be provided. For example, a certain degree of static safety can be achieved by a programming language s type system at compile time, while dynamic type tests can be ....

P. Steyaert, C. Lucas, K. Mens, and T. DHondt. Reuse contracts: Managing the evolution of reusable assets. In Proceedings of OOPSLA 96, pages 268--286, 1996.

....by merely checking the pattern constraints or the transformation preconditions. The reason is that such conflicts are located on a different level: two entities that are related in some way are modified in parallel. We are nevertheless able to detect these conflict situations using conflict tables [15, 18]. These allow us to compare the different design pattern transformations, and to specify under which conditions they lead to a conflict if they are applied in parallel. The difference with previous approaches is that we are able to detect merge conflicts on a much higher level, by connecting the ....

P. Steyaert, C. Lucas, K. Mens, and T. DHondt. Reuse contracts: Managing the evolution of reusable assets. In Proc. Int. Conf. Object-Oriented Programs, Systems, Languages and Applications, pages 268--286. ACM Press, 1996.

....particular evolution. Such a situation should be avoided, as it leads to a proliferation of di#erent versions of the framework that can quickly become unmanageable [CDHSV97] To overcome this problem, the di#erent versions of the framework should be merged into one single version (see Figure 2. 1) SLMD96, Men99, Men02] Software merging is a time consuming, complicated and error prone process, because many interconnected elements are involved and because merging depends on both the syntax and the semantics of these elements. Moreover, merge conflicts may occur, due to the fact that parallel ....

....Reuse Contracts Reuse contracts are a methodology for identifying possible evolution conflicts caused by di#erent developers evolving the same software artifact in parallel. Originally, reuse contracts were developed to deal with evolution of classes at the implementation level [CDHSV97, SLMD96] Later the focus shifted to the design level, by looking at evolution of class collaborations [Luc97] In both domains, the approach is general enough to support anticipated as well as unanticipated evolution. The approach consists of documenting the design of the framework by means of reuse ....

[Article contains additional citation context not shown here]

Patrick Steyaert, Carine Lucas, Kim Mens, and Theo D'Hondt. Reuse Contracts: Managing the Evolution of Reusable Assets. In Proceedings of the OOPSLA Conference, ACM Sigplan Notices, 1996.

....can occur when an abstract layer is modified, and to automatically pinpoint the places where potential problems can arise. Based on this, powerful tools can be developed that support the user during incremental design. The chosen approach corresponds to the general methodology of reuse contracts [12]. By applying this methodology to nested state diagrams, we show how incremental design of such diagrams can be facilitated. 2. Nested State Diagrams (NSDs) 2.1 Definition To keep the presentation clear, we have chosen to present the definitions in this paper in a semi formal way. We will use a ....

....Transition overriding Transition overriding Transition capture Transition capture Specialisation g g Extension g Table 2: Overview of the semantic conflicts 6. Related Work The approach taken in this paper essentially corresponds to the methodology of reuse contracts presented in [12]. Apart from the fact that we have applied this methodology to state diagrams instead of object oriented class hierarchies, there are some other differences. First of all, since we allowed to deal with nested states, we needed to provide operators like specialisation and encapsulation to modify ....

Patrick Steyaert, Carine Lucas, Kim Mens & Theo D'Hondt: "Reuse Contracts: Managing the Evolution of Reusable Assets", OOPSLA '96 Proceedings, ACM Sigplan Notices Vol. 31, No. 10, pp. 268-285, ACM Press, 1996. ...page 14...

....# [JOHN 92] ODEN 97] present how patterns can support the documentation of a frameworks. # [BROW 96] WUYT 98] PREC 98] present some possible approaches to support design patterns extraction. # [FLOR 97] shows how design patterns can be supported at the development environment level. # [STEY 96] presents Reuse Contracts as a way to document frameworks for evolution. # [WINS 87] presents some discussion about variety of composition relationships. 10 CONTENTS Refactoring and Code Smells # [FOWL 99] summarises practical experience with refactorings and code smells. # The Ph.D. work of ....

P. Steyaert, C. Lucas, K. Mens, and T. D'Hondt. Reuse Contracts: Managing the Evolution of Reusable Assets. In Proceedings of OOPSLA '96 Conference, pages 268--285. ACM Press, 1996. (p 9)

No context found.

Steyaert, P, Lucas, C, Mens, K and D'Hondt, T: Reuse Contracts: Managing the Evolution of Reusable Assets, To appear in Proceedings of OOPSLA `96 Conference on Object Oriented Programming, Systems, Languages and Applications, ACM Press 1996.

....changes guarantee that the rest of the system will remain more or less consistent. Changes to the outer parts of the system occur much more frequently but do not have such a large impact. This is illustrated in figure 2. Figure 2. Characteristics of an Adaptable System 3 Reuse Contracts In [7] we propose reuse contracts as a means to codify the management of change in an (adaptable) software system. Reuse contracts record the protocol between builders and customisers of an adaptable system and offer guidelines for deriving more transient versions of the system in some problem domain. ....

....on the design decisions made in the adaptable system. Reuse contracts provide exactly this information. Because the best known technique available today for structuring and adapting object oriented software is undoubtedly the use of abstract classes with inheritance as the reuse mechanism, in [7] we focused on the problem of adaptation of classhierarchies as a more tangible case to express the ideas behind reuse contracts. In that context, reuse contracts and their operations describe the protocol between managers and users of (abstract) class libraries. Reuse contracts of abstract ....

[Article contains additional citation context not shown here]

Steyaert, P., Lucas, C., Mens, K. and D'Hondt, T.: Reuse Contracts: Managing the Evolution of Reusable Assets, Proceedings of OOPSLA`96 Conference on Object Oriented Programming, Systems, Languages and Applications, pp. 268-285, ACM Press 1996.

....is very general and is applicable to many forms of reuse. Reuse contracts come in different flavours depending on the development phase in which reuse takes place, and on what is reused: reusing single classes by inheritance, reusing multiple classes by late binding polymorphism. For example, in [6], Steyaert et al. introduce reuse contracts for (abstract) classes to provide an explicit representation of the design decisions taken to build an abstract class. 12 Evolving Custom Made Applications into Domain Specific Frameworks 12 5.2 Example A reuse contract (as depicted in Figure 5) for ....

Steyaert, P. and Lucas, C. and Mens, K. and D'Hondt, T. Reuse Contracts: Managing the Evolution of Reusable Assets. In Proceedings of OOPSLA `96 (Oct. 6-10, San Jose, California). ACM/SIGPLAN, New York, 1996, pp. 268-285.

No context found.

P. Steyaert, C. Lucas, K. Mens, and T. D'Hondt. Reuse Contracts: Managing the Evolution of Reusable Assets. In Object-Oriented Programming Systems, Languages, and Applications, October 1996.

No context found.

P. Steyaert, C. Lucas, K. Mens, and T. D'Hondt. Reuse Contracts: Managing the Evolution of Reusable Assets. In OOPSLA 1996.

No context found.

K. Mens P. Steyaert, C. Lucas and T. D'Hondt. Reuse Contracts: Managing the Evolution of Reusable Assets. In Proc. of OOPSLA, 1996.

No context found.

K. M. P. Steyaert, C. Lucas and T. D'Hondt. Reuse Contracts: Managing the Evolution of Reusable Assets. In Proc. of OOPSLA, 1996.

No context found.

P. Steyaert, C. Lucas, K. Mens, and T. D'Hondt. Reuse Contracts: Managing the Evolution of Reusable Assets. In Proc. of OOPSLA, 1996.

No context found.

P. Steyaert, C. Lucas, K. Mens and T. D'Hondt, Reuse Contracts: Managing the Evolution of Reusable Assets, Proc. Of OOPSLA,1996.

No context found.

P. Steyaert, C. Lucas, K. Mens, and T. D'Hondt. Reuse Contracts: Managing the Evolution of Reusable Assets. In Object-Oriented Programming Systems, Languages, and Applications, October 1996.

No context found.

P. Steyaert, C. Lucas, K. Mens, and T. D'Hondt. Reuse contracts: Managing the evolution of reusable assets. In Proceedings of OOPSLA '96 Conference, pages 268--285. ACM Press, 1996.

No context found.

P. Steyaert, C. Lucas, K. Mens, and T. D'Hondt. Reuse Contracts: Managing the Evolution of Reusable Assets. In Object-Oriented Programming Systems, Languages, and Applications, October 1996.

No context found.

P. Steyaert, C. Lucas, K. Mens, and T. D'Hondt. Reuse contracts: Managing the evolution of reusable assets. In Proc. of the Conf. on Object-Oriented Programming, Systems, Languages and Applications, pages 268--285, 1996.

No context found.

P. Steyaert, C. Lucas, K. Mens, and T. D'Hondt. Reuse contracts: Managing the evolution of reusable assets. In OOPSLA '96 Conference on Object-Oriented Programming Systems, Languagges and Applications, pages 268--285. ACM Press, October 1996.

No context found.

Patrick Steyaert, Carine Lucas, Kim Mens, and Theo D'Hondt. Reuse contracts: Managing the evolution of reusable assets. In OOPSLA '96 Conference on Object-Oriented Programming Systems, Languagges and Applications, pages 268--285. ACM Press, October 1996.

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