Run-time adaptability of synchronization policies in concurrent objectoriented

Transcription

1 Run-time adaptability of synchronization policies in concurrent objectoriented languages Fernando Sánchez, Juan Hernández, Juan Manuel Murillo, Enrique Pedraza Computer Science Department University of Extremadura Campus Universitario s/n Cáceres, Spain {fernando, juanher, ABSTRACT Adaptability has become one of the most important research areas in concurrent object-oriented systems in recent years. It tries to cope with system evolution by adding/replacing components without affecting other components of the same application. Nevertheless, at the present time, concurrent object-oriented languages do not provide enough support for the development of true adaptable software because either i) the different aspects that appear in these systems, synchronization and behavior, are mixed in the same component or, ii) if they are properly separated in different components, once these components are woven the resulting executable piece of software is too rigid to be adapted or reconfigured at run-time. In this paper, we present the Disguises Model, a model mainly thought for a clear and consistent separation of the synchronization aspect from the behavioral aspect. Whereas the model allows behavioral code to be written in a standard language like Java, it provides a different language for the specification of synchronization components and a third language for the specification of the composition rules between the synchronization and behavioral aspects. This composition language allows synchronization policies to be added, replaced or reconfigured at run-time, which is the main contribution of the proposed model. The techniques here presented have been satisfactorily integrated in Java. 1 Introduction Frequently, large and complex systems have to cope with a continuous change of requirements during their life. Consequently, these systems tend to grow and change after they have been developed. In order to adapt to changing requirements, the demand has risen for adaptable software. This research area has been recently named the adaptability [Tek96] of software, which can be defined as the ability to deal with new/changing requirements with minimum effort. In this definition, the meaning of effort must be understood as the number of modules that are created or modified when changes in the requirements are necessary. In practice, it is possible to obtain an adaptable object-oriented application if its software architecture allows its components to be removed, replaced or reconfigured without perturbing other parts of the application [Nie95]. Nevertheless, experience has demonstrated that the object-oriented model does not provide effective adaptability. It has been detected various interferences when several aspects must be introduced or modified in order to cope with the changing requirements. The introduction or modification of new requirements affecting a single aspect may involve the modification of the other aspects, thus expanding the number of modules that must be changed or modified. And this situation is clearly against the definition of adaptability given before. Recent works [Hur95, Aks96, Kic97] have demonstrated that the problem in the conventional object model is that the different concerns or aspects involved in an application are mixed. Since then, the separation of concerns principle has been recognized as an effective approach for increasing adaptability. In the research area we are moving around, COOLs, the two aspects to be considered are synchronization and basic object behavior. In the last few years there have been several proposals trying to separate the synchronization aspect from the basic behavior of the object [McH94, Ber94, Hol97, Lop97, Rei97]. A number of proposals deserve special mention which under the name of aspect-oriented programming (AOP) try to express each of a system s aspects in a separate and natural form that will be automatically woven to form an executable code using automatic tools [Kic97]. All of these proposals have obtained a high degree of success, and they have proposed different programming techniques to separate both concerns (see related works section). But once these concerns are composed, what is the nature of the resulting entity after the composition process? Is it flexible enough to allow the synchronization aspect to be adapted not only at compile time but also at run-time? That is, is it flexible enough for adding, replacing or reconfiguring synchronization components at run-time? To our knowledge, the answer is no. Our contention is that this feature is very important in critical control systems where, due to unexpected environment changes, urgent and 1

2 not preestablished decisions must be taken at run-time. From security and economic point of views, it is not admissible to stop the application, adapt it to the new environment and re-run it. In this paper, we present the Disguises Model, a model mainly thought for a clear and consistent separation of the synchronization aspect from the behavioral aspect. Whereas the model allows behavioral code to be written in a standard language like Java, it provides a different language for the specification of synchronization components and a third language for the specification of the composition rules between the synchronization and behavioral aspects. This composition language allows synchronization policies to be added, replaced or reconfigured at run-time. That is what we call run-time adaptability, which is the main contribution of the proposed model. Run-time adaptability is provided even if the object has not been previously designed for such changes or the run-time added synchronization policies have not been previously defined. Although the techniques here presented have been satisfactorily integrated in Java, they can be easily applied to other languages. The rest of the paper is organized as follows. Section 2 fixes the discussion universe we are moving around and presents the main requirements for achieving adaptability in COOLs. In Section 3 the Disguises Model is presented. It will be shown how it separates and composes the different aspects with the aid of several examples. In section 4 related works are discussed and, finally, section 5 summarizes the paper with conclusions and future work. 2. Adaptability in COOLs The point of view we have about the desired adaptable concurrent object-oriented model is depicted in figure 1. Each synchronization component should ideally describe exactly one and well defined synchronization policy, and it may itself be a composition of other synchronization components. The basic behavior interface specifies the operations provided to the exterior. This interface may be implemented in various ways, and both the interface and the implementation are components themselves. The dotted line around the behavior and the synchronization policy 1 indicates the boundary of the resulting composed object. Such an object should be understood as an entity ready to be executed whose design should allow the other synchronization policies to be applied at run-time. 1 different synchronization policies they can be applied to other component behaviors other implementations Basic behavior interface behavior im plem entation 2 composed to form other synchronization policies 3 Composed 4 Figure 1. Graphical view of adaptability in COOLs The following benefits and properties about the desired object model can be deduced from the figure: the set of components describing the basic behavior of the object may be reused in environments other than concurrent. synchronization components are not attached to any specific behavior component. Conversely, they are independent from each other. Consequently, synchronization components may be applied to any other components with different behavior but the same synchronization rules. As there is an independence between aspects at the implementation level, it is possible to specify the synchronization aspect in a specific language more suitable for describing synchronization than general purpose languages. 2

3 In the same way as the previous point, the composition mechanism for composing both concerns, synchronization and behavior, may be different from those used for composing individual concerns. This allows us to use a more adequate composition mechanism for run-time adaptability than inheritance or delegation. 2.1 Requirements for adaptability in COOLs From the previous point, a set of minimum and necessary requirements to be imposed in COOLs in order to address the demanded software adaptability can be easily followed. i) modularity of synchronization constraints: this means that the synchronization aspect must be clearly/cleanly separated from the behavioral aspect. Moreover, SC must not refer to implementation details. Otherwise, substitutability of software is lost [San96, Ber96]. ii) iii) iv) composability of synchronization constraints: this means the ability that a concurrent object-oriented model provides for reusing and extending the SC in an effective way. SC must be able to be freely combined to form other constraints [San96, Ber96] expressiveness of synchronization constraints: this means that SC must be able to refer to the required information for a good expressive power in synchronization mechanisms [Blo79]. composition of SC and behavior: this means the ability that a COOL provides to freely combine or compose both components: synchronization and basic behavior. This composition mechanism must be able to be done at compile time as well as run-time. At least the following three features should be provided for the demanded run-time adaptation: Addition of a new synchronization policy and its integration with the current applied policies. Replacement of a currently applied synchronization policy with another one or none. Modification of a currently applied synchronization policy in order to restrict or extend its constraints. Whereas the requirements i), ii) and iv) are for adaptability, the third one is for expressive power in synchronization constraints. We claim that these requirements should be present in any COOL designed for largescale concurrent software development. Currently, different languages or proposals fulfil the three first requirements with a certain degree of success [McH94, Ber94, Hol97, Rei97, Lop97] but, to our knowledge, none of them has addressed the ability to change the synchronization aspect during the execution of the application. The reason for this is that once these separated components are woven, the resulting executable piece of software is too rigid to be adapted or reconfigured at run-time. What it means is that the fourth requirement has not been taken into account. In the Disguises Model presented below, the synchronization policies are allowed to be added, replaced or modified at run-time without affecting other parts of the object or application. The behavior component has no need to be coded taking into account what synchronization policies can be added in the future and the policies themselves can be adapted while the application is being executed. 3 The Disguises Model In [Lop97, San97] it is shown how difficult is to achieve an effective adaptability of SC in a popular concurrent object-oriented language like Java due to it not addressing the above established requirements for adaptability in COOLs. In [San97] the well known bounded buffer example with put and get methods to store and retrieve elements is used to show interferences between aspects when inheriting code: not only we have to redefine behavioral methods only to take into account synchronization purposes, but also we are not able to reuse SC previously defined to form new ones. Both problems arises because the modularity requirement i) and the composability requirement ii) identified above are not addressed. For more details the reader is referred to [San97]. In [Lea96] several hints for solving these problems in Java are proposed but, unfortunately, Java provides no means by which to specify synchronization policies independently. So, in the bounded-buffer example, there is nothing to do if the whole synchronization policy is needed to be replaced by another one and, of course, nothing to say if it is to be done at run-time. As a result, requirement iv) is not fulfilled. Next, the proposed model will be presented at two stages. On the one hand, the separation of the synchronization aspect in different components will be outlined in section 3.1 by introducing a particular language for the specification of synchronization and, on the other hand, the composition mechanism for weaving both components will be described in section

4 3.1 Separating aspects: the synchronization language. The first requirement for adaptability in COOLs imposes a clear separation of SC from object behavior. This is the reason why the Disguises Model separates both aspects in different components. In order to specify the synchronization aspect, the model provides a specific language in the sense of aspect-oriented programming [Kic97]. The behavioral component becomes a normal object in Java but without specifying anything about synchronization. At a later stage, the behavior and synchronization components will be composed with a composition mechanism different from inheritance which will allow synchronization components to be dynamically changed at run-time. This mechanism is shown later in section 3.2. The main concepts of the proposed synchronization language rely on abstract states. The abstract states of an object are those exceptional states under which certain methods cannot be executed. They represent some relevant aspects of the real state of execution of an object but at a level of abstraction that makes independent the synchronization component from the behavioral component. Although abstract states do not refer to implementation details, they are thought to be able to reference the required information for a good expressive power in synchronization mechanisms [Blo77] coping thus with the expressiveness requirement iii) [San97]. For the bounded buffer example the abstract states would be: abstract_states: FULL: {δ.length()==δ.maximum() EMPTY: {δ.length()==0 where the letter δ denotes the object to be synchronized and length and maximum are properties of the δ object. In addition to abstract states, the proposed model provides preconditions which establish the SC for methods execution. These conditions are boolean expressions defined in terms of abstract states so they do not refer to particular implementations. For the example being considered: preconditions: put:!full; get:!empty; In practice, abstract states depend either on instance variables or conditions that cannot be distinguished with the set of instance variables (i.e. history-only sensitiveness of states). Thus, it is possible to identify two kind of abstract states: those involving instance variables and those not involving them. For the former a functional access is provided and for the latter variables only for synchronization purposes, synchronization variables, are granted. This variables will be managed by preactions and postactions. This solution for implementing abstract states ensures the separation of concerns and the encapsulation for the behavioral component. external requests message queue PreConditions synch. variables instance variables and methods implementation. functional access real invocation of method abstract states PreActions PostActions basic behavior component synchronization component Figure 2 Graphical representation of the model The outline of the framework is illustrated in figure 2. This mechanism provide a generic object-oriented synchronization model for achieving adaptability in COOLs. It makes up a layer that provides a complete abstract interface which isolates the synchronization component from the implementation details. This means modularity of 4

5 SC, that is, requirement i). All these features can be reused, extended or redefined, in synchronization subclasses. This allows the model to cope with composability of SC, that is, requirement ii). This two statements are exemplified below. Figure 3 illustrates the behavior component of the bounded buffer without specifying anything about synchronization. It defines public methods and a set of properties that characterize the buffer: its length and the maximum number of elements that it can contain. In figure 4, two possible synchronization specifications for the bounded buffer are shown. class B_buff { protected int max, count, head, tail; protected int[] buffer; // Properties int length() { return count; int maximum() { return max; for (i=0;i<buffer.length;i++) buffer[i]=0; public void put (int element) { buffer[tail]=element; tail=++tail % max; count++; // Constructor and public methods B_buff(int size) { max=size; count=head=tail=0; buffer = new int[size]; public int get () { // implementation of get Figure 3 Behavior of the buffer without synchronization It must be observed that we have divided the synchronization constraints for the bounded buffer in two different policies: a consumer/producer policy, which deals with the problem of placing/taking elements when the buffer is full/empty, and a mutex policy, which manages the concurrent access to the buffer object. These components can be applied to the buffer at the same time, but as different entities. We could mix these two policies in one, but this choice would restrict programmer's easiness to take decisions about them separately, making the management of the synchronization aspect more difficult. Whereas the first policy deals with concurrency control for incoming messages according to the current state of the object, the second one deals with intra-object concurrency control at the level of method execution. synchronization_class Prodcons { abstract_states: FULL: {δ.length()==δ.maximum() EMPTY: {δ.length()==0 preconditions: place:!full; take:!empty; ; Figure 4.1 Prodcons class synchronization_class Mutex { mutex (put, get); mutexself (put, get); ; Figure 4.2 Mutex class The first synchronization component, prodcons, is defined in function of two abstract states, FULL and EMPTY. After defining these states, the preconditions for accessing the methods are established: place cannot be executed when the object is at the FULL state, and the same holds for take when the object is at the EMPTY state. Two important things must be noted. On the one hand, this synchronization policy doesn t refer to a particular behavioral component. In fact, nothing is said about the buffer. There is no way to know that we are synchronizing a buffer. The letter δ denotes the generic object we are referring to, not a particular one. On the other hand, the name of the methods here (take/place) is different from those in the behavioral component (get/put). These two facts make it possible for this synchronization policy to be applied to different behavioral components with different functionality and different interfaces but the same synchronization rules, that is, polymorphism of synchronization policies [San96]. Of course, a mechanism for a later binding between both components is needed. This mechanism will be outlined in next section. 5

6 With respect to the mutex synchronization component, two new constructions are introduced here to simplify a typical question in concurrent programming: the mutual exclusion problem. The construction mutex(a, b, c,...) means: 'I want the methods a, b, c,... to be executed in mutual exclusion one with each other', and the construction mutexself(a, b, c,...) means 'I want the methods a, b, c,... to be executed in mutual exclusion with themselves'. So, in figure 4.2 it is established a mutual exclusion between threads accessing the put and get methods. This syntax for mutex and mutexself has been adapted from that in [Lop97]. Once the synchronization aspect has been separated by means of abstract states, the problems related to reuse identified in [San97] can be easily solved. Let us suppose now we want to extend the functionality of the buffer by introducing a new method gget() whose behavior is the same as get() but with the particularity that it cannot be executed after a put() operation. The synchronization constraints for gget() are an extension of those of get(). So, we only have to extend the behavior component with the new added feature and to extend the synchronization component with the new added constraint. This is illustrated in figure 5.1 and 5.2. Both classes are extended independently, without interferences between them. In fact, two different hierarchies of classes are being obtained as shown in figure 6. This figure also reveals that a composition mechanism is needed. synchronization_class Ggetprod extends Prodcons { synchronization: int after_put = 0; abstract_states: LAST_PUT: { after_put == 1 preconditions: gget:!last_put; preactions: place: {after_put=1; allmethodsexcept(place): {after_put=0; Fig 5.1 Extending and reusing synchronization inheritance Behavior 1 Behavior 2 composition composition Synchronized Object Behavior 1 Object Behavior 1 Object Behavior 2 inheritance class GgetBuffer extends B_buff { public int g_get() { return super.get(); Fig 5.2 Extending and reusing behavior inheritance Synchronized Object inheritance... Behavior 2... Figure 6 Different hierarchies for different aspects 3.2 Composing aspects: the composition language. Now that the synchronization aspect has been successfully separated from the object behavior in a different component, the requirement iv) for adaptability in COOLs establishes that a composition mechanism must be provided in order to obtain the executable piece of code. Our contention is that this composition process must be able to be done either at compile time or run-time in order to allow a qualified system operator to take decisions about synchronization policies during the execution of the application. We could think about using one of the existing composition techniques such as inheritance or delegation. However, the current composition techniques are not adequate for our purposes. For example, in the first version of our model [Her96] inheritance was used as composition tool. It worked fine when solving interferences between object-oriented and concurrent paradigms, but it resulted too static to make run-time decisions. In Composition Filters [Ber94], a particular delegation-based composition is used. Here is possible, under certain conditions, to dynamically change the delegated objects. The problem is that those conditions must be explicitly declared in the application code before compilation doing so the mechanism too restricted for our purposes. In the Disguises Model we resort to a third component, a composition language, to make feasible the composition process at run-time. In its simplest form, this language has the following pattern: compose behavior_component with synchronization_component 6

7 which results in a synchronized object in the sense of figure 6. This is the syntax to be used by an external operator of the application wanting to add a new synchronization component to an existing behavior component while the application is running. However, when the composition is wanted to be done when writing the application code because the programmer knows a priori what synchronization policies have to be attached to the object, then the previous syntax is substituted by: behavior_component.addcomponent (synchronization_component) where addcomponent is a method defined in an automatically inherited superclass which we call object manager. In fact, and getting down to the implementation level, the composition language interacts with this object manager which is a superclass of all the instantiated behavior components. The object manager offers several public methods like addcomponent, removecomponent or replacecomponent among others. These methods allow the programmer to write code inside the application for adding, removing or replacing synchronization components when it is known a priori under which circumstances they must be added, removed or replaced during the execution of the application. However, when such circumstances are not known when writing the code, and there are decisions about synchronization that have to be taken at run-time, then the first syntax must be used outside the application. The relationship between the object manager and the synchronized behavior is shown in figure 7 in an OMT like notation. As we can see, the object manager makes use of a run-time loader of synchronization classes 1. Such classes are stored in a appropriate data structure to be managed by the methods of the object manager. This data structure contains the preconditions, preactions and postactions for each of the methods in the synchronized behavior. The loader of synchronization classes also checks the compatibility of the synchronization component with the behavior. Next a simple example to illustrate the applicability of the proposed composition language is shown. object manager data structure for synchronization policies addcomponent ( newcomp) removecomponent (oldcomp) replacecomponent (oldcomp, newcomp) removeallcomponents ( ) existcomponent (acomp)... run-time loader of synchronization policies synchronized behavior methods of behavior component Figure 7 Relation between the object manager and the synchronized behavior Examples of applicability Let us consider an object buff belonging to the bounded-buffer class and the Mutex synchronization class defined in figure 4.2. And let us suppose that, before executing the application, they have been composed by means of: buff.addcomponent (Mutex) After several steps of execution of the object buff, we could observe how it can reach negative values in its length (figure 8). This is so because there is no restrictions on get operations. They can be executed even if the buffer is empty. If the buffer is required to work correctly but without stopping the application because, for example, the considered application is a critical control system, then it is needed at run-time to add a synchronization policy like Prodcons, shown in figure 4.1, in order to restrict put and get operations. The syntax for this is shown below. It is also illustrated at the bottom of figure 8, at the command line. 1 This run-time loader makes use of the ClassLoader Java facility. 7

8 compose buff with Prodcons where put is place and get is take It must be noted that a binding between method names is necessary. This binding may also be done with parameters, that is, with the entire signature of methods. Mutex compose buff with Prodcons where put is place and get is take Figure 8 Adding synchronization policies at run-time Let us consider now that, due to certain circumstances, we are interested in maintaining the number of elements of the buffer between 5 and the maximum capacity. In this case, there are two possible options. On the one hand, we can modify the synchronization policy currently applied (Prodcons) and on the other hand, we can define a new synchronization policy that will replace the old one. If the choice is the first one, we only have to edit the Prodcons class, to make the appropriate changes and, after saving it, we have to use: reload in buff Prodcons which replace the old version of Prodcons with the new one. On the contrary, if we choose the second option, a new policy can be defined as in figure 9. Then, we only have to remove the old policy and to add the new one. This is done with: replace in buff Prodcons by Prodcons5 From the moment that the original policy Prodcons is removed and this new policy is added, the access to the get method is blocked until the number of elements in buff is five or greater. synchronization_class Prodcons5 extends Prodcons { abstract_states: EMPTY: {δ.length() <= 5 ; Of course, the examples here introduced are too simplified and utopian. However, the reader must note the implications and the actual applicability in real control systems. Currently, many accidents in this kind of systems occur because something relevant was not taken into account when designing the code and, when the problem arises, the right decision can not be taken at run-time. 4 Related Works Figure 9 Prodcons5 synchronization policy Since the early birth of concurrent object-oriented languages several interferences between the two considered paradigms were detected [Pap89, Mat93]. From the point of view of adaptability the main problem is the mixing of the two considered aspects: synchronization and behavior. Since this problem was identified, there have been several proposals trying to separate both aspects with a certain degree of success. However, none of them deals with the new feature presented in this paper, the dynamic change of synchronization policies at run-time. 8

9 The model integrated in DRAGOON [Atk91] perhaps is one of the first approaches trying to separate the synchronization behavior from the object behavior. It provides two different kind of class for both aspects. But, whereas behavior can be easily extended by using inheritance, there is not a provided mechanism by which to extend the synchronization classes. Composition Filters [Ber94] is another relevant approach that enforces separation of concerns. However, although the concerns are separated, they remains in the same component doing so an impossible task to apply the same synchronization policy to different objects, that is, polymorphism of SC. This approach uses a delegation-based inheritance as composition mechanism. Although it is possible to change the delegated objects during the execution phase, the spectrum of possible delegated objects have to be defined in filters when writing the code. Therefore, new relations between concerns are not allowed to be defined at run-time. A model that takes the separation of concerns to its last consequences is that proposed in [McH94]. In this work, Generic Policies (GSP) are introduced as a way to obtain polymorphism of SC. In this proposal, McHale does not allow references to instance variables in synchronization constraints neither directly nor indirectly. Instead, he duplicates instance variables inside the synchronization code. Moreover, he also has to duplicate the code to handle these duplicated variables. However, this decision may introduce an unnecessary overhead if this code is large and complex. In addition, there is no means by which to make decisions at run-time. The work nearest to the Disguises Model is that presented in [Lop97] and developed under the concepts of aspect-oriented programming. In this work, a different language for the synchronization aspect, the D-language, is presented. Although this aspect is defined in a separated component it is allowed to reference directly the instance variables defined in the behavior component from the synchronization component, breaking so the substitutability concept. The synchronization and behavior components are composed using an Aspect Weaver Tool, but the resulting piece of code is not susceptible to be adapted at run-time in the sense here presented [Lop97]. Finally, there are other proposals separating aspects that use Java as the supporting language. In [Hol97] the synchronization rings are presented to specify the different steps of a message when entering to and exiting from an object. In [Rei97] the aspects are separated by annotating the behavioral code. However, neither [Hol97] nor [Rei97] address the dynamic change of synchronization policies. The table below summarizes the relation between the related works and the adaptability requirements established in section 2. Separation of Concerns Composability of SC Run-time adaptability DRAGOON Yes No No Composition Filters Yes 1 Yes No GSP Yes Yes No D-language Yes 2 Yes No rings Yes Yes No Annotated behavior Yes Yes No Disguises Model Yes Yes Yes 1 but in the same component. 2 but breaking encapsulation. 5 Conclusions and Future Works In this paper we have firstly introduced the notion of run-time adaptability in COOLs. Then, the main problems for achieving this adaptability have been shown and the separation of concerns principle has been presented as a good approach to achieve our purposes. Moreover, a set of four requirements have been identified as necessary in order to address the demanded run-time adaptability. Then, the Disguises Model has been introduced. This model fulfils the four requirements for adaptability. Whereas the model allows behavioral code to be written in a standard language like Java, it provides a different language for the specification of synchronization components and a third language for the specification of the composition rules between the synchronization and behavioral aspects. This composition language allows synchronization policies to be added, replaced or reconfigured at run-time, which is the main contribution of the proposed model. Although the techniques here presented have been satisfactorily integrated in Java, they can be easily applied to other languages. 9

10 In the same way that we can think separately about synchronization, the same criteria can be followed with other aspects such as real-time, distribution or coordination. Other members of our research group are beginning to deal with these aspects in the same sense presented here [Her97, Pap97]. Currently, we are applying the Disguises Model to the development of a traffic control system where run-time decisions must be taken in order to adapt the application to unexpected situations. In this project the composition language becomes a composition visual tool that makes easier the composition process. We think that the experience with this project will help us in improving the model in the future. References [Atk91] C. Atkinson, S. Goldsack, A. Di Maio and R. Bayan. Object-Oriented Concurrency and Distribution in DRAGOON. Journal of Object-Oriented Programming, March/April 1991 [Aks96] M. Aksit, B. Tekinerdogan, L Bergmans. Achieving Adaptability through separation and composition of concerns. In Max Mühlhäuser editor, Special Issues in Object-Oriented Programming,, Workshop Reader of the ECOOP 96, Linz, Austria. [Ber94] L. Bergmans. Composing Concurrent Objects. Ph.D. Thesis, University of Twente, [Ber96] L. Bergmans, M. Aksit. Composing and Real-time Constraints. Journal of Parallel and Distributed Programming, Vol. 36 N 1, July, [Blo79] T. Bloom. Evaluating Mechanisms. Proceedings of the Seventh Symposium on OS Principles, pp [Her96] J. Hernández, F. Sánchez, M. Barrena, J.M. Murillo, A. Polo. Reusability, Extensibility and Polymorphism of Constraints in Concurrent Object-Oriented Languages. Technical Report nº 1/96. March [Her97] J. Hernández, M. Papathomas, J.M. Murillo, F. Sánchez. Coordinating Concurrent Objects: How to deal with the coordination aspect? Position paper in Aspect-Oriented Programming Workshop in ECOOP 97, Jyväskylä, Finland. Available at: [Hol97] D. Holmes. Aspects of. Position paper in Aspect-Oriented Programming Workshop in ECOOP 97, Jyväskylä, Finland. [Hur95] W. Hursch, C. V. Lopes. Separation of Concerns. Northeastern University, February [Kic97] G. Kiczales et. al. Aspect-Oriented Programming. Proceedings of ECOOP 97, Jyvaskyla, Finland, June [Lea96] D. Lea. Concurrent Programming in Java TM : design principles and patterns. Addison Wesley, [Lop97] C.V. Lopes. D: A Language Framework for Distributed Programming. Position paper in Aspect-Oriented Programming Workshop of ECOOP 97, Jyvaskyla, Finland, June [Mat93] [McH94] [Nie95] [Pap89] [Pap97] [Rei97] [San96] [San97] [Tek96] S. Matsuoka, A. Yonezawa. Inheritance Anomaly in Object-Oriented Concurrent Programming Languages. in Research Directions in Concurrent Object-Oriented Programming Languages. Ed.: G. Agha, P. Wegner and A. Yonezawa, MIT Press, April 1993, pages C. McHale. in Concurrent, Object-oriented Languages: Expressive Power, Genericity and Inheritance. PhD thesis, Univerity of Dublin, Trinity College. O. Nierstrasz and L. Dami. Component-Oriented Software Technology, in Obtect-Oriented Software Composition. O. Nierstrasz and D. Tsichritzis eds., Prentice-Hall, M. Papathomas. Concurrency Issues in Object-Oriented programming languages. In D. Tsichritzis, editor, Object Oriented Development, Chapter 12, pp: , University of Geneva, 1989 M. Papathomas, J. Hernández, J.M. Murillo, F. Sánchez, Inheritance and Expressive Power in Concurrent Object-Oriented Programming. Proceedings of the LMO Conference, Roscoff, France, Oct S. Reitzner. Classes: Splitting Inheritance Concepts. TR-I , Computer Science Department, Friedrich- Alexander Univeristy, Germany. F. Sánchez, J. Hernández, M. Barrena, J. M. Murillo, A. Polo. Issues in Composability of Constraints in Concurrent Object-Oriented Languages. In Max Mühlhäuser editor, Special Issues in Object-Oriented Programming,, Workshop Reader of the ECOOP 96, Linz, Austria. F. Sánchez, J. Hernández, J. M. Murillo, E. Pedraza. Run-time adaptability in COOLs. Technical Report TR3/97. Computer Science Department. University of Extremadura. September B. Tekinerdogan, M. Aksit. Adaptability in Object-Oriented Software Development: Workshop report. In Max Mühlhäuser editor, Special Issues in Object-Oriented Programming,, Workshop Reader of the ECOOP 96, Linz, Austria. 10