Concern Oriented Programming using Re ection - Semantic Scholar

Submission to OOPSLA 2000 Workshop on Advanced Separation of Concerns in Object-Oriented Systems

Concern Oriented Programming using Re ection Noury Bouraqadi

http://www.emn.fr/bouraqadi E cole des Mines de Nantes - Dept. Informatique 4, rue Alfred Kastler - BP 20722 44307 Nantes cedex 3 - FRANCE

Abstract

Building softwares in a concern oriented fashion can be splited in two main steps : rst de ning each concern separately (or reusing existing ones) and then composing (i.e. integrating) those concerns together. Among existing approaches to support this development scheme, we are interested in re ection. This interest is particularly motivated by the natural separation between functional and non-functional concerns provided by re ection. In this paper, we describe our approach based on re ection. We provide a solution to de ne and compose reusable non-functional concerns, while minimizing integration eorts. Keywords: Concerns Composition ; Concern Reuse ; Metaclasses ; Re ection ; Smalltalk.

1 Introduction Separation of concerns [Dij76] [HL95] is the foundation for the programming paradigm that we named Concern Oriented Programming (COP). This programming paradigm consists of separating concerns before composing (i.e. integrating) them to produce softwares. Once concerns identi ed at the design stage, they can be developed separately. Alternatively, concerns already existing can be reused. All chosen concerns are then composed to build the software. Our focus is on the use of re ection to support the COP programming paradigm. Re ection is the ability of a system to observe and change its own execution [Smi82]. Thus, using a re ective language, programmers can not only de ne applications functionalities, but they can also de ne execution mechanisms, i.e. how functionalities will be performed. Functionalities and execution mechanisms can be de ned separately. In an object-oriented re ective language, objects that de ne functionalities are called base objects while objects de ning execution mechanisms are called meta-objects. Protocols to manipulate meta-objects are called meta-object protocols (MOP) [KdRB91]. Base objects and meta-objects belong to dierent abstraction levels. They can be de ned separately and then connected through a link named meta link. Functionalities provided by each base object are then executed using the execution mechanisms de ned in meta-objects the base object is linked to. Thus, re ection introduces a natural way to separate and to compose functionalities with nonfunctional concerns [WY88] [KP94] [McA95] [GC96] [SW96]. Besides, since a re ective system can reason and act upon itself at run-time, concerns can be dynamically changed to take into account environment evolution [LBS00]. In this paper, we propose a scheme based on re ection to de ne multiple reusable non-functional concerns and to compose them. Our approach relays on metaclasses, i.e. classes which instances are also classes. Non-functional concerns are de ned as sets of application independent, and thus reusable, metaclasses. So, classes play the role of meta-objects that control execution of their own instances. One bene t of this approach is achieving non-functional concern composition with application functionalities through the meta-link. To deal with multiple non-functional concern composition, we extended this composition mechanism with mixin-based multiple-inheritance [BC90]. This approach, has the advantage to transpose the concern composition badly known problem into the well known issue of multiple-inheritance. 1

[email protected]

2

This article is organized as following. First, we brie y introduce our experimentation platform, a re ective extension of Smalltalk named MetaclassTalk (section 2). Next, we describe our approach to de ne separated reusable concerns and composing them (section 3). Then, we provide concluding remarks and sketch future work (section 4).

2 MetaclassTalk : our experimentation platform Our experiments are based on a re ective extension of Smalltalk named MetaclassTalk [BS99]. MetaclassTalk is an ospring of ClassTalk [BC89] (the implementation of the ObjVLisp model into Smalltalk [Coi87]) and NeoClassTalk [Riv96a]. It provides explicit metaclasses likewise ClassTalk, and allows to transparently control and rede ne the method evaluation process likewise NeoClassTalk. Besides, MetaclassTalk MOP allows to transparently control and rede ne mechanisms for reading and writing instance variables, sending and receiving messages and looking up for methods.

One characteristic of MetaclassTalk is that classes play the role of meta-objects which de ne execution mechanisms for their instances. Thus, the instantiation link plays also the role of a meta link which is automatically set on objects creation. In MetaclassTalk, classes are themselves instances of other classes: metaclasses. Since metaclasses de ne class properties (i.e. class behaviors), then metaclasses hold de nitions of execution mechanisms. Therefore metaclasses can hold the de nitions of non-functional concerns. The MetaclassTalk MOP, inspired from CodA [McA95] and composition lters [AB92], allows the de nition of a wide set of non-functional concerns [BS99] [Cas00]. The set of the non-functional concerns that can be de ned is even wider since MetaclassTalk extends Smalltalk. The choice to extend Smalltalk was in fact made because of the Smalltalk's unique set of powerful re ective facilities [Riv96b]. Access to run-time stack and to processes are examples of such facilities. The latest version of MetaclassTalk1 [Cas00] was implemented on top of Squeak [IKM+ 97], a free open source Smalltalk completely written in itself. Even the virtual machine is de ned in term of Smalltalk classes2 . This interesting feature makes it possible to adapt the Squeak VM in order to natively support the MetaclassTalk MOP in the future. Such an extension will help improving MetaclassTalk performance as highlighted later in this paper.

3 Separating and composing concerns in MetaclassTalk 3.1 An example

In order to give an intuition of our approach, we propose to start with an example of a simple concern : trace. Suppose that we want to trace all messages sent by instances of two classes: Store and Client, in a e-business application. On one hand there is the trace concern and on the other have e-business functionalities. To achieve separation of concerns, classes Store and Client should de ne only application functionalities. While the trace concern is isolated in a metaclass named Tracer. The Tracer metaclass de nition should be application independent to achieve reusability. It means that this de nition should not reference elements (classes, methods, ... ) of our e-business applications. Figure 1 provides a such de nition in a Smalltalk like syntax. The send:. . . method is part of the MetaclassTalk MOP, and allows the control of message sendings. The basic de nition of this method is extended in the Tracer metaclass, in order to produce a trace on every message sending. To nish building our application, we need to compose concerns. In the MetaclassTalk context, this means to assign the trace property de ned by the Tracer metaclass to the Store and Client

1 Available at http://www.emn.fr/bouraqadi 2 One can change it and then use the Smalltalk to C translator embedded within Squeak to get the VM de nition

in C code.

3

[email protected]

Metaclass De nition

Con guration Script

Tracer instanceVariables: 'outputStream'.

\Creates a stream allowing writing into the le which name is given" logFilename: aString jlogFilej logFile := Filename named: aString. outputStream := logFile writeStream \Method to control sent messages" send: messageName from: sender to: receiver arguments: argsArray. . . \Produce a trace" outputStream nextPutAll: `sending message '. outputStream nextPutAll: messageName. outputStream cr. \Append a return character to the stream" \Send message" super send: messageName from: sender to: receiver arguments: argsArray.. .

Store addProperty: Tracer. Store logFilename: `store.log'. Client addProperty: Tracer. Client logFilename: `client.log'.

Figure 1: De nition of a trace concern in MetaclassTalk classes. The basic solution to do this property assignment is by making the Store and Client classes instances of the Tracer metaclass. A con guration script de nes how the trace concern should be composed to application functionalities (see gure 1). The trace property assignment is expressed using the addProperty: message3 . Con guration includes setting les where to store traces for each class using the logFilename: method de ned in the Tracer metaclass. Once the con guration script is evaluated, the Store and Client classes become instances of the the Tracer metaclass, and then understand the send:. . . method. Because this method is part of the MetaclassTalk MOP, it is implicitly invoked on the Store and Client classes, each time one of their instances sends a message.

3.2 Abstract description of non-functional concerns

We de ne a non-functional concern as a set of application independent metaclasses and a application dependent con guration script (cf. gure 2). When de ning or reusing a concern, only

metaclasses are dealt with since they are application independent. As opposite, a con guration script is bound to application and thus can not be reused. Application integrators are in charge of de ning con guration scripts. Scripts of all concerns of a given application should be evaluated in order to set up the application and trigger concerns composition. n

Metaclass

1 Non-Functional Concern 1 1

Configuration Script

Figure 2: Representation of non-functional concerns 3 Remember that in our context classes are also objects and thus can receive messages.

4

[email protected]

3.3 Composing many concerns

Most applications have many non-functional concerns. Unavoidably, a class involved in many concerns should be linked to many metaclasses. Since then, the instantiation link is not enough. A possible solution to this problem was addressed by building a stack of meta-objects [FP98] [VTJV99]. Each meta-object controls the execution of the lower meta-object, and the bottom meta-object controls the execution of some base object. We argue that this solution is not convenient since all meta-objects should control execution mechanisms of base-level objects. Besides, access to base level objects becomes a dicult task. The approach we propose is based on mixin-based multiple inheritance [BC90]. Metaclasses involved in concerns are de ned as mixins [BS99]. Within an application, a class C that should be linked to many mixin-metaclasses Mix-f, Mix-g and Mix-h is de ned as instance of a metaclass MetaC that inherits from those mixin-metaclasses (cf. gure 3). Mix-g Mix-f

Mix-h

receive:...

send:... receive:...

send:... receive:... inherit from

linearization list for send:... Mix-h

MetaC

Mix-f

linearization list for receive:... Mix-g

Mix-f

Mix-h

instance of

C

Figure 3: Linking one class to many metaclasses The process of concern composition can then be splited in two parts. First, non-functional concerns are composed through multiple inheritance. Then, the instantiation link is used to compose application functionalities to the result of non-functional concerns composition. Overlaps between non-functional concerns are translated into the well-known multiple inheritance con icts issue. The decision to use mixins inspired by previous work on meta-object composition [MMC95] aimed to reduce con icts, but does not suppress all of them. Still some con icts can appear since many mixins can rede ne the same methods of the MetaclassTalk MOP. A linearization of mixin-metaclasses is not enough to solve con icts since dierent methods may require dierent linearizations. Thus, we propose a ner grain for linearization: the method grain. The metaclass MetaC in gure 3 is provided with two linearizations: one linearization for each of the two methods send:. . . and receive:. . . de ned in MetaC superclasses. For example, when an instance of the C class sends a message, this message sending is performed by applying method send:. . . de ned in Mix-h. If this method makes a call to super, the method send:. . . in Mix-f is applied. A question remains: how to order methods and build linearization lists? Roughly, we have to avoid undesirable shadowing and interferences between the con icting methods [BS99]. A method m1 shadows another method m2 if m1 does not call m2 (i.e. no super call). A method m1 is said to interfere into another method m2 if m1 change some arguments before calling m2. Shadowing can

[email protected]

5

be avoided by putting at the beginning of linearization lists methods that call next ones through super calls. Interference can be avoided by putting into the linearization list methods that use some arguments before those that change those arguments. In order to achieve a good linearization, we need informations about shadowing and interferences. Such informations may be extracted (at least partially), automatically. But, in our current prototype we require that metaclass programmers provide them. Based on these informations, we can cope with most of con icts automatically. Application integrators intervention to solve con icts is then reduced to few cases where linearization fails.

4 Conclusion and future work The proposed solution is based on the use of application independent, and thus reusable, metaclasses to describe non-functional concerns. Application integration requires writing con guration scripts (one per concern). The evaluation of these scripts triggers composition. This latter is achieved through instantiation link and mixin-based multiple inheritance. Classes de ning applications functionalities are instances of some metaclasses that inherit form mixin-metaclasses de ning non-functional concerns. Thus, concerns remain separated even after composition. As a result, and thanks to re ection, one can dynamically add, remove or replace mixin-metaclasses to adapt application execution mechanisms to environment evolution [LBS00]. One future work direction is to explicit concerns adaptability. Adaptability can be regarded as dynamic recon guration of concerns. Our goal is to allow application integrators to de ne when and how concerns should be adapted, in the same way they can de ne how to con gure concerns. Another future work direction is to improve the MetaclassTalk performance. Currently, re ection hooks are introduced using program transformation technics [BS99] [Cas00]. That is messages sendings/receptions and accesses to instance variables are replaced by messages sent to the classes. This transformation automatically done using a speci c compiler result in a non-negligible overhead. One possible direction to improve MetaclassTalk performance is to use Squeak -our implementation platform- capabilities. Squeak is a Smalltalk dialect completely written in itself. The basic class library includes the virtual machine (VM) de nition and a Smalltalk to C translator. These facilities were used to enhance, test and port the VM [IKM+ 97][Spo99]. We plan to use these facilities and extend the VM to natively support the MetaclassTalk MOP, in order to speed up execution.

Acknowledgments The author would like to thank Dr. Thomas Ledoux for his valuable comments and suggestions on drafts versions of this paper.

References [AB92] [BC89] [BC90] [BS99] [Cas00]

Mehmet Aksit and Lodewijk Bergmans. An Object-Oriented Language-Database Integration Model: The Composition-Filters Approach. In Proceedings of ECOOP'92, 1992. Jean-Pierre Briot and Pierre Cointe. Programmingwith Explicit Metaclasses in Smalltalk. In Proceedings of OOPSLA'89, pages 419{431, New Orleans, Louisiana, USA, 1989. ACM. Gilad Bracha and William Cook. Mixin-based Inheritance. In Proceedings of ECOOP/OOPSLA'90, Ottawa, Canada, pages 303{311, October 1990. M. N. Bouraqadi-Sa^adani. Un MOP Smalltalk pour l'etude de la composition et de la compatibilite des metaclasses. Application a la programmation par aspects. These de doctorat, Universite de Nantes, Nantes, France, July 1999. A Smalltalk MOP for Studying Metaclass Commposition and Compatibility: Application to Aspect Oriented Programming (in french). Gabriel Casarini. Towards Transparent Strong Mobility using a Re ective Smalltalk. Master's thesis, E cole des Mines de Nantes - Vrije Universiteit Brussel, August 2000.

[email protected] [Coi87] [Dij76] [FP98] [GC96] [HL95] [IKM+ 97] [KdRB91] [KP94] [LBS00] [McA95] [MMC95] [Riv96a] [Riv96b] [Smi82] [Spo99] [SW96] [VTJV99] [WY88]

6

Pierre Cointe. Metaclasses are First Class Objects: the ObjVLisp Model. In Proceedings of OOPSLA'87, pages 156{167, Orlando, Florida, USA, October 1987. ACM. Edgar W. Dijkstra. A Discipline of Programming. Prentice-Hall, Englewood Clis, N.J., 1976. Jean-Charles Fabre and Tanguy Perennou. A metaobject architecture for fault tolerant distributed systems: the friends approach. IEEE Transactions on Computers. Special Issue on Dependability of Computing Systems, 47(1):78{95, January 1998. Brendan Gowing and Vinny Cahill. Meta-Object Protocols for C++: The Iguana Aproach. In Gregor Kiczales, editor, Proceedings of Re ection'96, pages 137{152, San Francisco, California, April 21-23 1996. Walter L. Hursch and Cristina Videira Lopes. Separation of Concerns. Technical Report NU-CCS-95-03, College of Computer Science, Northeastern University, Boston, MA, February 1995. Dan Ingalls, Ted Kaehler, John Maloney, Scott Wallace, and Allan Kay. Back to the Future. The Story of Squeak, A Practical Smalltalk Written in Itself. In Proceedings of OOPSLA'97, pages 318{326, Atlanta, Georgia, October 1997. ACM. Gregor Kiczales, Jim des Rivieres, and Daniel G. Bobrow. The Art of the Metaobject Protocol. MIT Press, 1991. Gregor Kiczales and Andreas Ppcke. Open Implementations and Metaobject Protocols. Expanded tutorial notes, 1994. Thomas Ledoux and Noury M. N. Bouraqadi-Sa^adani. Adaptability in Mobile Agent Systems using Re ection. RM'2000, Workshop on Re ective Middleware, http://www.comp.lancs.ac.uk/computing/rm2000/, April 2000. Je McAer. Meta-level Programming with CodA. In Proceedings of ECOOP'95, volume LNCS 952, pages 190{214. Springer-Verlag, 1995. Philippe Mulet, Jacques Malenfant, and Pierre Cointe. Towards a Methodologyfor Explicit Composition of MetaObjects. In Proceedings of OOPSLA'95, pages 316{330, Austin, Texas, October 1995. Fred Rivard. A New Smalltalk Kernel Allowing Both Explicit and Implicit Metalclass Programming. OOPSLA'96, Workshop : Extending the Smalltalk Language, October 1996. Fred Rivard. Smalltalk : a Re ective Language. In Proceedings of REFLECTION'96, pages 21{38, San Franscico, USA, April 21-23 1996. Edited by Gregor Kiczales. Brian C. Smith. Re ection and Semantics in a Procedural Language. Technical Report 272, MIT Laboratory of Computer Science, 1982. Lex Spoon. Squeak: a Portable Virtual Machine. OOPSLA'99 workshop : Simplicity, Perofrmance and Portability in Virtual Machine Design, 1999. Robert J. Stroud and Zhixue Wu. Advances in Object-Oriented Metalevel Architectures and Re ection, chapter Using Metaobject Protocols to Satisfy Non-Functional Requirements, pages 31{52. CRC Press, 1996. Bart Vanhaute, Eddy Truyen, Wouter Joosen, and Pierre Verbaeten. Composing Non-Orthogonal MetaPrograms. OOPSLA'99 Workshop on Multi-Dimensional Separation of Concerns in Object-Oriented Systems, 1999. Takuo Watanabe and Akinori Yonezawa. Re ection in an Object-Oriented Concurrent Language. In Proceedings of OOPSLA'88. ACM, 1988.