PROCEEDINGS OF THE ASPECT-ORIENTED PROGRAMMING WORKSHOP AT ICSE’98 Organizers: Cristina Lopes, Gail Murphy, and Gregor Kiczales http://www.parc.xerox.com/aop/icse98 Includes an overview of the workshop the position papers. The overview of the workshop was published in Proceedings of the 20 th International Conference on Software Engineering, Volume II, April 1998, Kyoto, Japan. IEEE Computer Society. The position papers are copyrighted by their authors. All rights are reserved.
Transcript
PROCEEDINGS OF THEASPECT-ORIENTED PROGRAMMING WORKSHOP
ATICSE’98Organizers:
Cristina Lopes, Gail Murphy, and Gregor Kiczales
http://www.parc.xerox.com/aop/icse98
Includes an overview of the workshop the position papers.
The overview of the workshop was published in Proceedings of the 20th International Conference onSoftware Engineering, Volume II, April 1998, Kyoto, Japan. IEEE Computer Society.
The position papers are copyrighted by their authors. All rights are reserved.
Workshop on Aspect-Oriented Programming
Cristina Videira Lopes Gail Murphy Arthur LeeGregor Kiczales University of British Columbia Korea University
Xerox Palo Alto Research Center Dept. of Computer Science Dept. of Computer Science3333 Coyote Hill Rd. Vancouver Seoul 136-701
Palo Alto, CA 94304, USA Canada Korea+1 (650) 812-4498 +82-2-3290-3196
ABSTRACTThis is a preview of the workshop on Aspect-Oriented Pro-gramming at ICSE 98. It includes an overview of the posi-tion papers. The workshop takes place on Monday, Aprilthe 20th 1998.
1 STATEMENT OF WORKMechanisms for defining and composing abstractions areessential elements of programming languages. They allowprograms to be composed up from smaller units, and theysupport design styles that proceed by decomposing a sys-tem into smaller and smaller sub-systems.
The abstraction mechanisms of most current programminglanguages – subroutines, procedures, functions, objects,classes, modules and APIs – can all be thought of as fittinginto a generalized procedure call model. The design stylethey support is one of breaking a system down into param-eterized components that can be called upon to perform afunction.
But many systems have properties that don’t align with thesystem’s functional components. Failure handling, persis-tence, communication, replication, coordination, memorymanagement, real-time constraints, and many others, areaspects of a system’s behavior that tend to cut-acrossgroups of functional components. While they can bethought about and analyzed relatively separately from thebasic functionality, programming them using current com-ponent-oriented languages tends to result in these aspectsbeing spread throughout the code. The source code be-comes a tangled mess of instructions for different purposes.
This “tangling” phenomenon is at the heart of much need-less complexity in existing software systems. It increasesthe dependencies between the functional components. Itdistracts from what the components are supposed to do. Itintroduces numerous opportunities for programming errors.It makes the functional components less reusable. In short,it makes the source code difficult to develop, understandand evolve.
A number of researchers have begun working on ap-proaches to this problem that allow programmers to expresseach of a system's aspects of concern in a separate andnatural form, and then automatically combine those sepa-rate descriptions into a final executable form using auto-matic tools. These approaches have been called Aspect-Oriented Programming (AOP).
The purpose of this workshop is to bring together research-ers and practitioners working on a wide range of AOPtechniques, including languages, tools, frameworks, pro-gramming styles, etc.
2 SUBMITTED PAPERSThis section presents an overview of the position papersreceived until the elaboration of this summary.
“Formalizing adaptability aspects”, M. Aksit and B.Tekinerdogen. This paper studies the sorting and the adapt-ability aspects and their object-oriented implementations. Itis shown that transforming aspects into the object-orientedmodel results in loss of information. Because of the mis-match between the aspect and the object-oriented models,aspect weaving and language transformation operations aregenerally ill conditioned. In the object-oriented implemen-tation some of the aspects are not separable. Performance isalso taken into account. The performance aspect can beadded by weaving the performance, adaptability and sortingaspects together. Weaving and the transformation operationare expressed in the object-oriented model. The authorssuggest the presented formalism is suitable for expressingvarious aspects, and can be a basis to defining aspect-oriented analysis and design models.
“Quality of service – aspects of distributed programs”, C.Becker and K. Geihs. This paper shows an aspect-orientedapproach for QoS integration in CORBA. By using en-hanced IDL and its target language (i.e. C++) as aspectlanguages for QoS, the conceptual changes to the originalCORBA are kept small. The presented system does notneed an explicit weaver or specialized languages for as-pects, but still provides a clear separation of concerns andthis an aspect-oriented view on QoS. The goal of this workis to reduce the complexity of distributed systems and toshow that aspect-oriented programming is an appropriateparadigm for the integration of non-functional aspects suchas QoS.
“Interactions between objects: an aspect of object-orientedlanguages”, L. Berger, A. M. Dery and M. Fornarino. Theauthors argue that object interactions should be viewed asan extensible aspect of object-oriented languages. The pa-per proposes an aspect language called IL (Interaction Lan-guage) to describe the interactions between objects. Theaspect approach, when possible, gives a higher level ofspecification better adapted to the developers. Viewinginteractions between objects in terms of an aspect of object-oriented languages allows a separation between interactionlanguage and the component language.
“Developing a tool to support the application of aspect-oriented programming principles to the design phase”, S.Clarke and J. Murphy. Integrating the technical functional-ity and the business functionality of a system, both at thedesign and the coding level, increases the complexity of thedesign models or the code. This paper presents a tool thatapplies AOP techniques at the design level. The currentversion of the tool supports the creation of an aspect pro-gram in a graphical manner, from the design model. Theauthors now consider a more flexible mechanism to supportthe design of an aspect’s semantics.
“Injecting ilities”, R. Filman. This paper discusses the useof AOP technology to impose system-wide properties ondistributed systems. Tools such as CORBA have enabledprogrammers to code the specification of objects and meth-ods; but elements such as security or reliability are still theresponsibility of the application programmer, and likely tobe done incorrectly or incompletely. The work in this paperis aspect-oriented in that it separates the tasks of creatingthe actual domain application from the code that producessecurity, reliability, and such ilities.
“Mixin composition strategies for the modular implemen-tation of aspect weaving”, Y. Roudier and Y. Ichisugi. EPP(the Extensible Preprocessor) was designed to introducenew language constructs by the mere addition of plug-inmodules that can also define new syntax and macros. Therelation of EPP and AOP is two-fold. First, the EPP kit hasbeen programmed using the Ld-2 language, which intro-duces AOP constructs: system mixins. Second, the authors
suggest that EPP could be used to program aspect-orientedweavers in a modular way.
“Extending aspect-oriented programming in order to flexi-bly support workflows”, R. Schmidt and U. Assmann. Theauthors describe a dilemma in designing architectures forworkflow support. Approaches based on virtual machinesare flexible in adapting to workflow changes, but suffer interms of performance. Architectures that directly imple-ment workflows offer good performance, but are inflexiblein adapting to workflow changes. The paper suggests thatcombining AOP and the decomposition of workflow as-pects allows an escape from this dilemma.
“Assessing aspect-oriented programming and design”, R.Walker, E. Baniassad and G. Murphy. This paper reportson an experiment designed for assessing the claims ofAOP. The authors obtained data comparing the use of anAOP language vs. an OO language. The experiment high-lighted the usefulness of being able to easily express andunderstand synchronization code. It is noted that the usersof the AOP language AspectJ were able to complete de-bugging tasks with fewer instances of semantic analysiswhich seemed to lead directly to less switching betweenfiles, and ultimately to quicker completion times. Theauthors conclude that there are times at which it is usefulfor synchronization code to be embedded in the core func-tionality, but that at times work can be speeded considera-bly when synchronization code is separated from the rest.
“An abstract view of computational reflection”, T. Wata-nabe. This paper presents a formal definition of computa-tional reflection using abstract rewriting systems. Theauthor uses the notion of an abstract implementation be-tween abstract rewriting systems that realizes the “meta”relation introduced informally by B. C. Smith. The defini-tion is independent from any particular computation modelsand can capture important concepts of computational re-flection. The paper relates to AOP in that the whole moti-vation in building a reflective system is to make its baselevel computation perform effectively by observing and/oraltering itself at the meta level.
3 INFORMATION AND QUESTIONSFor more information, contact the workshop’s organizationat [email protected], or see the workshop’shome page (http://www.parc.xerox.com/aop/icse98).
We look forward for a productive and fun workshop!
Formalizing adaptability aspectsMehmet Aksit and Bedir Tekinerdogan
University of TwenteDepartment of Computer Science
P.O. Box 2177500 AE Enschede, The Netherlandse-mail: {aksit, bedir}@cs.utwente.nl
1. Definitions
In [Kiczales et al. 97], aspects are defined as properties that affect the performance or semantics of the
components in systemic ways. Systemic characteristic of aspects implies that they can be considered as
concepts. The term performance is a special case of the general term quality. Other quality examples are
adaptability and reusability. From this point of view, aspects are concepts which affect the quality and/or
semantics of software components.
We define the term software component as a programming language abstraction. Examples of software
components are procedures, data structures and objects. Programming languages are vehicles to express
abstract executable mechanisms. An aspect language is a language whose abstractions can directly
represent one or more aspects. A trivial aspect is an aspect, which can be directly represented by a software
component. This means that an aspect can show up as a software component (or can become trivial) if a
suitable programming language can be designed for that aspect.
Aspect weaving1 is a cross product among two or more aspects, and software components. An aspect
weaving process can be defined as
M X A à R
Here M is a model, A is an aspect, X is the weaving operator, à is the transformation process and R is the
result.
Structure preserving weaving is a weaving process without ill transformations. An ill transformation is a
transformation, which has one or more of the following problems: not expressible aspects, non-separable
aspects, non-composable aspects, and scattered aspects. In non-expressible aspects, the result of a
transformation becomes less expressive than before. In non-separable aspects, aspects are tangled and
therefore cannot be individually used and extended. In non-composable aspects, although explicitly desired,
a transformation cannot compose semantics of aspects together. In scattered aspects, one or more aspects
are scattered over different software components or aspects.
1 An aspect weaving process is a cross product operation, whereas component composition is generally attachingcomponents together.
2. Example Problem: Adaptable Sorter
Sorting is the process of arranging items in order. Different kinds of sorting algorithms have been defined
in the literature such as card sort, swap sort, bubble sort, select sort, quick sort, etc. The suitability of a
sorting algorithm generally depends on the context of the application, sorting criterion, data structure, etc.
A sorting algorithm can be defined as S = (CF, RN, RW, CR), where CF is the control-flow, RN is the range of
sorting, RW is the accessing (read-write) operation, and CR is the sorting criterion.
Adaptability can be defined as A = (FX, AD), where FX represents the fixed concerns, and AD represents the
adaptable concerns.
Adaptable sorter is defined as AS = S X A = (CF, RN, RW, CR) X (FX, AD).
Here, adaptable sorter (AS) represents a list of all combinations of sorting and adaptability aspects. For
example, the element (CF.FX) means that the control-flow of the sorting algorithm is fixed, and (CR.AD)
means that the sorting criterion is adaptable.
The next concern is coupling CP, which defines relations between the elements of the adaptable sorter. All
possible couplings between the elements of the adaptable sorter is defined as: CPAS = (AS)2
For example, ((CF.FX).(CR.AD)) is the coupling between the fixed control flow and the adaptable
comparison criterion.
Object-oriented modeling of the sorter means mapping its elements into object-oriented language
abstractions. For example, fixed elements can be implemented using statements and adaptable elements are
either classes or objects. The coupled fixed elements can be in-lined together, and the coupling between
adaptable and fixed elements can be implemented using message passing or inheritance.
2.1. Object-oriented implementation of the adaptable sorter
The adaptable sorter has been defined as:
AS = S X A = (CF, RN, RW, CR) X (FX, AD).
AS =
AD.CRFX.CRAD.RWFX.RWAD.RNFX.RNAD.CFFX.CF
It is assumed that the following elements of the adaptable sorter are of our interest:
AS1 = ((CF.FX), ( RN.AD), (RW.AD), (CR.AD))
Now we will define the couplings between these elements:
Modelling and implementing distributed systems leads often to the same problems. By ignoringpartial failures, dynamic changes in bandwiths, security issues etc. object-orientation provides a verywell suited abstraction. But when actually dealing with the aspects arising from the distribution, for-mer clear designs loose their elegance. Little or none support is provided by current implementations.Quality of Service (QoS) handling provides mechanisms to integrate the handling of distribution as-pects separated from the service implementation. We will motivate QoS as aspects of distributedprograms. By extending OMG IDL we provide QoS integration in object-oriented middleware in ageneric manner such that the service itself is little a�ected.
1 Introduction
Quality of Service (QoS) addresses the non-functional issues of services in distributed processing sys-tems. QoS concerns originate from distribution e�ects such as transmission errors, dynamic bandwidth uctuation, overload situations, partial failures, etc. Obviously, these issues reduce the amount of distri-bution transparency that can be achieved in a distributed system. Nevertheless, QoS management fordistributed applications has received more and more attention since new application requirements relatedto e.g. multimedia or fault tolerance demand an explicit handling of QoS issues.The object model is a popular conceptual base model for the design and implementation of distributedsystems. Object-oriented middleware such as CORBA is available that supports the construction andoperation of distributed object systems. Distribution transparency is one of the major design goals.However, the management of QoS has not been an issue in the initial development of such systems.Only lately there is a growing interest in integrating QoS in e.g. CORBA platforms. QoS concerns thenon-functional issues of a service. It refers to performance attributes that are in general not explicitlyvisible in the service interface. Instead, client and server need orthogonal means to specify and manageQoS as part of their service association. We argue that QoS should be seen as an aspect in the senseof Aspect-Oriented Programming (AOP). Thus, it should be speci�ed in an appropriate language. We
�This work has been funded by the DFG under SFB 403yRobert Mayer Str. 11-15, 60325 Frankfurt/Main, Germany, Tel.: (+49)69 -798-23975 Fax: -22643
1
2 QOS AS ASPECTS OF DISTRIBUTED PROGRAMS 2
will show that this can be done together (but separately) with the application speci�cation, and can beintegrated into the application implementation by means of a QoS integration framework. In this paperwe will discuss QoS as an aspect of distributed programs, and we will show how CORBA can be extendedby QoS management. This includes IDL enhancements and a general QoS framework which supports theintegration of QoS categories into CORBA applications.
2 QoS as Aspects of Distributed Programs
Figure 1 illustrates our view of QoS in client-server systems. A service o�ers a functional interface toclients. Additionally, QoS guarantees may be provided such that the client can rely on certain quali-ties when the service is performed. In general, many di�erent QoS categories can be distinguished indistributed systems, e.g. real-time constraints, system availability, or sound quality. QoS managementrequires QoS handling operations at the client and the server, e.g. to monitor the status or negotiateQoS guarantees. The middleware, e.g. the ORB, must support these operations. The QoS together withthe service functionality form the contract between client and service. While existing QoS approachestend to mix these concerns and to restrict themselves to the handling of a single QoS category, we aimat an open architecture that is capable of supporting many QoS categories in a generic way.
Client
Fun
ctio
nal
Inte
rfac
e
QoS-Aspects
Contract
Service
QoS 1 QoS 2 ... QoS n
�g. 1 QoS and functional interface
To distinguish the di�erent meanings of QoS let us give some terminology de�nitions. A QoS categorydenotes a class of QoS, such as fault tolerance or real time. A QoS characteristic identi�es a speci�c QoSin a QoS category, such as a replica group in fault tolerance. A speci�c QoS consists of a QoS interfacewith QoS related operations availiable to a client and a QoS attribute which contains the QoS parametersspecifying the state of that speci�c QoS.These de�nitions might suggest, that QoS can be modelled in abstractions like classes in object-orientedprogramming. However, it turns out that the integration of QoS in existing programming languages orinterface de�nition languages cannot be encapsulated completely. QoS is a pervasive element of the client,service, and middleware programs. An example are replica groups. A speci�c QoS for replica groupscontains a QoS attribute containing the QoS parameters - here: a list of computers where replicas shouldbe running - and a QoS interface with QoS related operations, e.g. group manipulations etc. The userof such a speci�c QoS expects simple reuse, e.g. by inheriting the service implementation from the QoSimplementation. Unfortunately this is not possible since a replica QoS must consist of a state transferringoperation to keep newly started replicas in virtual synchronity. Similar examples can be found for otherspeci�c QoS as well. The abstractions provided by object-oriented programming are not su�cient toencapsulate QoS. Therefore QoS is an aspect in the sense of AOP[5].
3 QIDL 3
Though QoS management can not be encapsulated entirely, we believe that object-oriented principles canhelp in integrating QoS. The operations visible to clients of a QoS enabled service can be encapsulatedin the QoS interface. The state of a QoS is described by the QoS attribute. The aspect QoS is thereforemodelled by its interface description without regarding its implementation. The assignment to services isdone by an integration into the interface de�nition language (IDL). Instead of using an AspecWeaverTM
we generate QoS elements in a framework by the IDL compiler1. The aspect language for QoS is IDL forthe QoS de�nition and the implementation language for the QoS implementation.
3 QIDL
Enhancing CORBA for QoS management should not violate the underlying design principles. A keyconcept in CORBA is the separation between interfaces and their implementation by using an interfacede�nition language. We extend OMG IDL by QoS de�nitions and call the resulting interface de�nitionlanguage QIDL. Therefore QoS implementations are separated from their interface (QoS interface andQoS attribute). The QoS de�nitions are designed under respect to a broad variety of di�erent QoS.The QIDL compiler can assist the user in implementing QoS enabled services. Thus we do not have tointroduce new languages or weaving tools. In the following, we give a brief description of QIDL and itsmapping to implementation languages like C++. More detailed information can be found in [2].
3.1 QoS De�nitions in QIDL
A QoS de�nition in QIDL allows the speci�cation of a speci�c QoS attribute and interface. Both are de-�ned by a newly introduced syntactical construct. These QoS constructs support inheritance. Inheritanceof QoS allows generalization/specialization relationships in distinct QoS categories, e.g. a state machineQoS with voting is a specialization of a replica group QoS. The implementor of a speci�c QoS can relyon already implemented features by using implementation inheritance provided by the implementationlanguage.
"qos" QoSname [ ":" baseQoS { "," baseQoS } ]
"{"
{ simple-type-spec QoSParam ";" }
interface
"{"
{ operation-decl ";" }
"}" ";"
"}" ";"
�g. 2 QIDL QoS de�nition
Figure 2 shows the de�nition of speci�c QoS in QIDL. The qos keyword introduces the QoS de�nition.After the colon a set of names can refer to a base QoS which this speci�c QoS inherits from. The QoSde�nition is bound to an identi�er. The QoS de�nition contains two parts. The �rst part describes theQoS parameters which may have any IDL type, even a user de�ned one, since a simple-type-specmayrefer to a user de�ned type. The second part is the QoS interface which contains the operations of a QoSvisible at its interface.
1Which in fact implicitly weaves the QoS with the other generated elements of the interfaces
3 QIDL 4
An important question is, which elements in the system QoS can be assigned to. There are several possibleelements[11] a QoS can be assigned to. We restrict QoS assignment to interfaces. Finer granularity,e.g. operations or parameters, may con ict when using di�erent QoS, like replica groups and best e�ortcommunication. Assigning QoS to modules is unnecessary coarse and may be too restrictive. An interfacemay provide more than one QoS. But only one QoS at a time is allowed. This QoS is negotiated betweenclient and service. Our system MAQS[1] supports adaptive clients which use negotiation and adaptionas a respone to a changing service quality during the service association. Changing the QoS agreementduring runtime is also done by a negotiation procedure.
3.2 QIDL Mapping
Interfaces de�ned in IDL are translated to an implementation language by an IDL compiler. This shouldbe done for QoS de�nitions as well. Currently we only support a QIDL to C++ mapping. The mappingof QoS de�nitions is kept consistent to the mapping of structs and interfaces in IDL.
QIDL-definition
Stub
Mediator QoS-Impl
QoS-Skel
(QoS, interface assignement)
Client side Service side
generates
Skeleton
Implementation
inherits
delegates
�g. 3 generated entities
Figure 3 shows the generated entities for a speci�c QoS de�nition and the assignment to a service.Note that the situation in the �gure re ects only one speci�c QoS. On the client side a mediator isgenerated which is a delegate of the stub object. The mediator realizes the QoS handling above theORB on client side. Each speci�c QoS provides its own mediator which is loaded upon negotiationagreement. The mediator is generated as a skeleton with all operations of the speci�c QoS interface.Additionally it contains a generic calling interface to pass the requests to the functional service interfaceto the ORB. On the service side a QoS skeleton and the corresponding implementation is generated.The QoS skeleton is the C++ mapping of the QoS interface. The QoS implementation is a skeletonof the implementation to be completed by the QoS implementor. The service implementor can reusethis speci�c QoS implementation by using implementation inheritance. A speci�c QoS can be used withlittle or none adaption e�ort. All functionalities which must be implemented by the service implementor,such as a state transfer method, are kept as virtual functions and must be well documented by the QoSimplementor.The core framework contains a simple protocol which must be implemented by every QoS enabled service.Therefore a client can use a CORBA narrow2 on a service to test if it is QoS enabled. The negotiationis generic in the sense that CORBA::Any types are exchanged and the corresponding speci�c QoS is
2a typesave downcast to an interface
4 RELATED WORK 5
determined by checking the type of the exchanged speci�c QoS attribute. The client o�ers a QoS attribute�lled with the desired parameters to the service which replies with the best possible QoS. The client canaccept this o�ering and QoS enabled communication begins. On QoS changes a renegotiation is done ina similar way.To provide dynamic extensions of clients and hierachical QoS handling a layer between the ORB and thetransport system is integrated in our runtime system. In a paper about MAQS[1] we give an overviewabout our system.
4 Related Work
Isolating aspects of distributed computing has been done before. D[4] provides a framework for distributedprogramming based on an implementation language with aspect languages for thread coordination andremote access strategies. By isolating the aspects remote access and coordination and supporting themby suitable languages (RIDL, COOL) many applications in distributed programming can be modelled.But QoS still does not �t in these aspects since RIDL deals with remotely executed methods and copyingmechanisms of parameters rather than with timeliness of execution, group communication mechanismsetc. COOL does not provide any help in the sense of coordination since only local coordination of threadsis supported.QuO[13] provides a framework for generic QoS integration in CORBA by Aspect Oriented Programming.Three aspect languages are introduced for resources, structures, and contracts. The runtime system issupported by a set of delegates between the objects and the ORB. The aspect languages expose partof the internal behaviour of objects to the IDL level which is a contradiction to the CORBA designprinciples of separating interface and implementation. Besides that, the speci�c aspect languages of QuOintroduce additional complexity.Many other approaches to QoS integration in CORBA exist. Most of them are restricted to one QoScategory, like real time or fault tolerance. TAO[10] identi�es the requirements for real time CORBA andits implementation, whereas ELEKTRA[6] provides fault tolerance by adding group communication toCORBA.
5 Conclusion
We have shown an aspect-oriented approach for QoS integration in CORBA. In constrast to other nongeneric systems we provide a general, aspect-oriented view on QoS. By using enhanced IDL and its targetlanguage (i.e. C++) as aspect languages for QoS, we keep the conceptual changes to the original CORBAsmall. Therefore our system does not need an explicit weaver or specialized languages for aspects but stillprovides a clear separation of concerns and thus an aspect-oriented view on QoS. We hope to reduce thecomplexity of the system and to show that Aspect Oriented Programming is an appropriate paradigmfor the integration of non-functional aspects such as QoS.
6 Acknowledgements
We thank Kay R�omer and Douglas C. Schmidt for stimulating discussions and comments.
REFERENCES 6
References
[1] C. Becker, K. Geihs \MAQS - Management for Adaptive QoS-enabled Services" IEEE Workshop onMiddleware for Distributed Real-Time Systems and Services, December 1997, San Francisco
[2] C. Becker, K. Geihs \Enhancing IDL by generic QoS de�nitions" submitted to International Workshopon QoS, May 1998, Napa
[3] S. Fr�lund, J. Koistinen \Quality of Service Speci�cation in Distributed Object Systems Design," HPTechnical Report, HPL-98-10
[4] C. V. Lopes, G. Kiczales \D: A Language Framework for Distributed Programming," PARC Technicalreport, February 97, SPL97-010 P9710047
[5] G. Kiczales et. al. \Aspect-Oriented Programming," PARC Technical Report, February 97, SPL97-008P9710042
[6] S. Ma�eis, \Adding Group Communication and Fault-Tolerance to CORBA" Proceedings of theUSENIX Conference on Object-Oriented Technologies, June 1995.
[7] Object Management Group, Control and Management of Audio/Video Streams, OMG RFP Submis-sion, OMG RFP Submission, telecom/97-05-07, May 1997.
[8] Object Management Group, The Common Object Request Broker: Architecture and Speci�cation(Revision 2.0), Object Management Group, Framingham, MA, March 1995.
[9] K. R�omer, A. Puder, MICO, http://www.vsb.cs.uni-frankfurt.de/~mico
[10] D. C. Schmidt, D. L. Levine, S. Mungee , \The Design of the TAO Real-Time Object RequestBroker" Computer Communications Journal, Summer 1997.
[11] D. C. Waddington, G. Coulson, D. Hutchinson, \Specifying QoS for Multimedia Communicationswithin Distributed Programming Environments," Multimedia Telecommunications and Applications,Springer LNCS 1185, pp. 75-101, 1996
[12] J. Waldo, G. Wyant, A. Wollrath, S. Kendall, \A Note on Distributed Computing," Sun Microsys-tems Laboratories, Inc. Technical Report 94-29, 1994.
[13] J. A. Zinky, D. E. Bakken, R. E. Schanitz, \Architectural Support for Quality of Service for CORBAObjects," Theory and Practice of Object Systems, John Wiley, New York, April 1997.
Interactions between objects : an aspect of object-oriented languages
ABSTRACTThis paper is based on our experience of integrating the in-teractions to several object-oriented languages and on ourconclusion: interactions should be viewed as an “extensible”aspect of object-oriented languages.
It is now well known that it is not easy to manage the inter-actions between objects in conventional object-oriented lan-guages [Rum92, Bos94]. The interactions are tangled in thecode of the objects, specializing classes, sending messagesto other objects in the code of methods or referencing inter-acting objects by specific attributes. The consequence is thatthe semantic of the objects participating to an interaction ismodified and the application maintainability and extensibil-ity are harder.
So different works have proposed some extensions to object-oriented languages to take into account this lack of abstrac-tion [Neu91, Hol92, AF93, Pin93, Frø94]. We did the same[DFP95, DDF96, BDFJ97]. But, today, we argue that inter-actions are conceptually independent of any object-orientedlanguage and match exactly the definition of an aspect de-scribed in [KLM 97] :
ASPECTS tend not to be units of the system’s func-tional decomposition, but rather to be propertiesthat affect the performance or semantics of thecomponents in systemic ways.
So, we propose a language, called IL (Interaction Language)to describe the interactions between objects. This languageallows to specify interactions between objects referring to theobjects only through their interface (list of methods). IL is anaspect language for object-oriented languages. So, whateverthe object-oriented component language may be, classes andbehaviors of objects are written in the component languagewithout having to deal explicitly with interactions.
Our experience with integration of interactions to object-oriented languages has shown that the expressiveness re-quired for the interactions can vary according to the com-ponent languages and the target applications. When the lan-guage integrates concurrent or distributed paradigms, the in-teraction expression implies to deal with concurrent behavioror distributed communication. When the applications needmore static checking, an analysis or control of the global in-teraction graph is essential. In the first implementations, wedefined a reflexive architecture in order to give the way toa programmer to adapt the tool to its specific applications.Today, we think that this approach lives a good way to al-low the implementation and evolution of Aspect Weavers1.Although the aspect approach, when it is possible, gives ahigher level of specification better adapted to the final devel-opers. So, we propose to customize the interaction languageboth using directly aspects on the IL language and indirectlyto adjust the Aspect Weavers to the programmer needs.
This paper is based on our experience of integrating interac-tions to different object-oriented languages and on our con-clusion : interactions should be viewed as an “extensible” as-pect of object-oriented languages. The paper is organized asfollows. The next section provides a short description of ILand illustrates its integration in several environments. Sec-tion 3 presents our proposal solution as Interaction AspectWeaver. This solution is essentially based upon meta pro-gramming to facilitate the future integration of new aspects.The last section presents some aspects to extend the basic ILsuch as a synchronization aspect to synchronize interactionsin a concurrent environment. Then we conclude.
2 INTERACTIONS : THE IL LANGUAGE
This section briefly presents the IL language through a sim-ple example : a Smalltalk version (Figure 1) and an IL ver-sion (Figure 2). A more complete description of IL can befound in [Ber97a]. We conclude this section with remarks onour different experimentations for integrating interactions toobject-oriented languages.
1Aspect Weaver is a trademark of Xerox Corporation
1
2.1 Example: a Diary Manager in Smalltalk without IL
A diary manager handles the association between shared di-aries and personal diaries. When a rendezvous is added to ashared diary the participants of this rendezvous (reunion) arenotified and their personal diaries are updated.
Figure 1 shows an implementation part of this specificationusing Smalltalk 2.
We have colored the background of the code in grey whenthe code applies to interactions between objects.
2The SharedDiary object has also methods to manage the list of per-sons who share the diary
Figure 1: An implementation of shared diaries in Smalltalk
2.2 Short description of IL
With IL, the interactions are specified outside of the objects,using only their interface. The methods in the componentlanguage describe the intrinsic behavior of objects withouttaking care of future participations in interactions.
The description of interactions in IL is based on the expres-sion of interaction rules. An interaction rule describes, fora given message, the set of partial ordered messages corre-sponding to its effective execution. This description uses thesending message operator (noted .), two reactive operators(; and // respectively for synchronous and asynchronoussending), and a conditional operator.
The interaction rules are described in interaction managers.An interaction manager allows to specify the state andbehaviors (for example the cardinality [OMG95, Mul97,Rat97] and the delayed execution) fitted to the designed in-teraction. An interaction manager can be specialized addingor completing interaction rules and participating objects.
In the IL language, an interaction manager can be stati-cally declared between given objects. But, most of the time,the interactions between objects have to be dynamically es-tablished or destroyed. A given object (instance) interactswith different objects during the execution. So dynamicallyadding or removing interaction managers is essential and theresulting language must offer such a functionality.
2.3 A shared diary manager in IL
We show in Figure 2 the code of the diary manager presentedin section 2.1 using IL. This manager describes the interac-tions between a shared diary SD, a personal diary PD and itsowner P. Three rules specify the consequences of a messagesending on a shared diary. For example, when a messageaddRdV is received by a shared diary, the RdV is concur-rently added to the shared and personal diaries and then theowner is notified, if needed.
The use of IL separates the basic functionalities of objectsand interactions and then greatly decreases the level of codetangling. Subclassing the Diary class is not needed to ob-tain shared diaries. A shared diary is just a diary interactingwith other diaries. So the code is easier to extend and toreuse.
2.4 An Integrated Environment for IL
IL allows to describe interactions independently of the com-ponent language. A programming environment which allowsthe description and the edition of interaction rules and man-agers is provided with the IL language. This environment isdeveloped in Smalltalk and includes at present time two gen-erators, one for Corba and C++, another one for Smalltalk.This tool is an interaction editor and also allows the appli-cation designing by means of “interaction” scenarii. Interac-tion managers are then consequently generated in IL. In the
Figure 2: A shared diary implementation in Smalltalk and IL
same time, a set of class skeletons is deduced. These skele-tons help the design of an application and are used during thecode generation to check the existence of classes involved inthe interactions.
2.5 Experimentation with Component languages
Some experimentations have been done to integrate the in-teraction language to several object-oriented languages :Smalltalk [Bec97, Ber97b], Clos [ABB 89, DFP95], OpenC++ [Chi95, CH97], Corba-C++ [ORB92, Nac97], Corba-Open C++. At the present time we are interested in compo-nent languages that integrate network management such asJava RMI [SUN96], Corba-Smalltalk and Corba-Smalltalk-C++. Our aim is to see the impact of a distributed environ-ment to the architecture and the possible consequences onthe aspect language (see sections 3 and 4).
According to the component language, the resulting lan-guage deals with simple interactions between objects, con-currency or communication between remote objects. For ex-ample, when the resulting language, such as our first imple-mentation in Clos, does not manage concurrency the oper-ator // is equivalent to ;, otherwise the example using theinteractions is, without change, concurrent.
We can also note that no assumption is done concerning thephysical location of objects in IL. So, when a component lan-
guage is coupled with a distributed language, the interactionaspect weaver has to take into account the object location.In Corba, for example, it must generate the IDL (InterfaceDescription Language) of the remote objects from the inter-action managers described with IL. In order to hide that someobjects in the interaction managers are local or remote, theweaver has to handle the physical locality of the objects atthe message execution time.
So, according to the kind of component language, the inter-action aspect weaver has to deal with different paradigms.In answer to this extensibility problem, we will detail in thenext section the proposed architecture of an interaction as-pect weaver. The following section will deal with this prob-lem in term of aspects when the considered paradigms areweaver implementation dependent.
3 INTERACTION ASPECT WEAVER
For each experimentation, we have developed an aspectweaver. Those weavers have common features. They gen-erate in the component language first class objects for theinteraction rules and interaction managers described in IL.They add code to glue the component objects and the gener-ated objects and they install a set of units which manage theinteractions. We can consider this set as a runtime library.The principal common characteristic of all the weavers is theredefinition of the execution of a message to manage inter-actions. So, in the resulting language, it is necessary to catchthe messages and to determine if the messages are concernedby interactions. In this case, the interaction rules concerningthis message at this time are selected, and the new behaviorof the message is executed. A specific unit is responsible foreach step of this message execution. Each of these units has aspecific behavior according to the component language andthe target resulting language features. Each unit has to beeasily extensible and substituted without altering the globalbehavior.
The chosen solution is to associate a meta-object to each in-teracting object and to introduce these units in each meta-object. So, we developed all our weavers using an openobject-oriented language.
The description of the meta-object given in the followingsection is a guideline for interaction aspect weaver imple-mentation.
3.1 Meta Architecture
Figure 3 shows the architecture of a meta-object with its unitsand their collaboration to manage the new message execu-tion.
Catching Message UnitThe sending message semantic is changed because when amessage involves at least an interaction rule, this or theserules are executed instead of the message itself. So we need acatching message mechanism to modify the sending message
Figure 3: An overview of the meta architecture
behavior semantic. Several mechanisms for catching mes-sages in open object-oriented languages exist. For the catch-ing message unit, in Open C++, we have used the methodwrapper ([Bra96] gives an example of method wrapper inSmalltalk). In Corba, we gain, with the Orbix version, thefilters mechanism [Orb96, Nac97] that is suitable to catchthe sending message between hosts. We had the choice be-tween the techniques presented by Ducasse in [Duc97] in theSmalltalk environment and we take advantages of dynamicsubclassing and compilation.
Selection UnitThis unit manages the effective interaction rules. It containsthe list of all effective interaction rules in concern with theobject managed by the meta-object. This list is evolution-ary because the interaction rules can be included or removeddynamically, at runtime. This unit determines, when a mes-sage is received and caught, which interaction rules amongthe effective rules must be executed.
Merging UnitWhen the set of interaction rules to execute for one send-ing message is fixed by the Selection Unit, the Merging Unitmust merge these rules before their execution. Indeed eachrule can contain the ask of the execution of the interactingmessage but the interacting message must be executed onlyone time. So we need to merge these rules to avoid extra ex-ecution of the interacting message. The merging algorithmis based on the operator semantics.
Execution UnitThe role of the Execution Unit is to manage the executionof the interaction rule resulting from the merging realized bythe Merging Unit. Interaction rules and operators are firstclass objects which know how they execute themselves. An
execution message to an interaction rule is recursively sentto its operators. So a new operator can easily be added.
We can see in the Figure 3 that the execution unit can con-tain other units, for example, to manage remote calls in alanguage that does not provide them at base level.
The implementation of these four units is complicated whenthe weaver has to mask the network management or to han-dle the concurrency. In such a case the evolution and main-tainability of the meta-object is complex. The next sectionpresents the advantage of the introduction of an aspect lan-guage to describe concurrency interactions and the futureworks under consideration in term of aspects.
4 ASPECT ON THE INTERACTION ASPECT LAN-GUAGE
The current behavior of resulting languages are not com-pletely satisfying in some points : the network management,the synchronization of the interactions and the checking ofthe global interaction graph are not well integrated yet. TheAOP [KLM 97] can solve in part these problems. We havecompleted the interaction language features to the synchro-nized interactions due to an aspect language. We are nowstudying the advantages to use aspects to simplify the weaverimplementation in case of distributed implementation and tointroduce explicitly properties on interactions for checkingthe global consistency at runtime.
4.1 Interactions Synchronization : an aspect of IL
The problem of synchronization occurs when the interac-tions are an aspect of a concurrent or a distributed object-oriented language. We need then to express self exclusive ormutual exclusive interaction rules in an interaction managerto avoid cycle or reentrance. To extend IL with exclusioninstructions is not a good solution because such an informa-tion is not used in a sequential language and transforms thecode of interactions in a tangled code with synchronization.So interaction synchronization is typically an aspect for IL.After a first study of this solution, a language such as thecoordinators of Cool [VLL94] seems to be a good applicant.
The synchronization program refers to the interaction pro-gram by its interaction managers and interacting messagesto designate a rule in this manager. For example,
specifies that the two rules cannot be executed concurrently.
We also need sometimes to consider an interaction as anatomic transaction and more generally to declare a set ofinteracting messages in an atomic transaction. Let see theshared diary example with the following behavior : the askfor a modification or an addition of a rendezvous requires
the acceptance of all the persons involved in the rendezvousbefore the effective updating of the shared diary. This ex-ample can be directly implemented in an interaction man-ager between all the persons and the shared diary by asyn-chronous sending messages managing a two phase commit.In fact, this solution is not a satisfactory answer because itis too closely related to the implementation and too far froma specification language as IL. We have chosen to introducethe keyword atomic (associated to a rule or a set of rules)in the synchronization aspect language. It is more declarativeand then it fits better the philosophy of IL.
4.2 Future Works around aspects on aspect
Interactions between remote objectsThe problem of the network management is the complexityof the library associated to the weaver. The network manage-ment is tangled in the code of meta-object and the extensionand maintainability is then difficult. Moreover the user hasno explicit information concerning the network behavior andcannot control it nor customize it. So we think that the distri-bution management for the interactions must be an aspect. Insuch a case, our study concerns essentially to determine twopoints : which kind of language is required to express distri-bution for interactions and if this aspect must be associatedwith the interaction language, the component language, theresulting language or the Interaction Aspect Weaver design.
Interactions GraphThe last point concerns control on the complete interactionsgraph. It should be probably resolved by an aspect but thedifficulties are to find the well adapted properties we want toexpress (no cycle or limited loops, detection of synchroniza-tion points, multiple calls to a same message in an interactionrule resulting from the merging, reducing a list of interactioncalls, etc) and to check on this graph and the consequencesof the kind of the component language (concurrent or dis-tributed) on this set of properties.
The originality of our approach is that we can propose abasic interaction aspect that can be extended with other as-pects, such as coordinator language, according to the natureof the component language or the target applications. Theprogrammer can customize the interaction language accord-ing to the component language and the target features of theresulting language.
5 CONCLUSION
In our first works on the interactions, we were interested inproposing the “ideal” architecture to integrate interactions inyour “preferred” languages. Doing so, we were language de-pendent and it was difficult to determine which features wererequired by the object-oriented language and which were re-quired by the interactions themselves. The new vision ofinteractions between objects in term of an aspect of object-oriented languages allows a separation between interactionlanguage and component languages. So, we are free to elabo-
rate the syntax of our language and it is easier to check prop-erties on the interactions. But, the objective of such a lan-guage is always to be integrated in others languages. So, dueto our experimentation in the interaction weaver implemen-tation, we are today able to propose an architecture based onmeta programming to implement Weavers. Separating theinteraction language from an object-oriented language leadsus to tackle other points such as distribution or concurrency.Our current idea is that these features don’t have to be inte-grated in IL, and are in fact aspects on the IL language or asto be used to implement the Weavers.
In conclusion, we think that the IL language and its pro-gramming environment are a good way to investigate andto help the programmers in a new type of programming :interaction-oriented programming. Moreover, it seems tous that the interaction-oriented programming allows to fearthe component oriented programming in an interesting andpromising manner.
REFERENCES
[ABB 89] G. Attardi, C. Bonini, M.R. Boscotrecase,T. Flagella, and M. Gaspari. Metalevel pro-gramming in CLOS. In S. Cook, editor,Proceedings of ECOOP’89, pages 243–256,Nottingham, July 1989. Cambridge UniversityPress.
[AF93] G. Agha and S. Frølund. A Language Frame-work for Multi-Object Coordination. In Proc.Of European Conf. On Object-Oriented Pro-gramming ’93, number 707 in LNCS, pages347–360, July 1993.
[BDFJ97] L. Berger, A-M. Dery, M. Fornarino, andO. Jautzy. Contribution : Interaction and Com-munication Models. In ECOOP’97 WorkshopReader. Springer Verlag, 1997.
[Bec97] K. Beck. Smalltalk, Best Practice Patterns.Prentice Hall, 1997. ISBN- 0-13-476904-x.
[Ber97a] L. Berger. et d’unde Coordination entre Objets Distants.
Rapport de recherche I3S, RR-97-24, 1997.
[Ber97b] J-M. Bernelas. Rapport de stage ESSI secondeOctober 1997.
[Bos94] J. Bosch. Relations as first-class entities inlayom. Not Yet Published. Available on http://www.pt.hk-r.se/~bosch, 1994.
[Bra96] J. Brant. Method Wrappers. Smalltalk goody,1996. http://st-www.cs.uiuc.edu/users/brant/Applications/MethodWrappers.html.
[CH97] B .Cazaux and T. Haquet. FLO++entre objets distants, April 1997. Rapport deprojet de fin
[Chi95] S. Chiba. A Metaobject Protocol for C++. Inthe ACM Conference on Object-Oriented Pro-gramming Systems, Languages, and Applica-tions (OOPSLA), pages 285–299, October 1995.
[DDF96] A-M. Dery, S. Ducasse, and M. Fornarino. Ob-ject and Dependency Oriented Programming inFLO. In ISMIS’96 : International Sympo-sium on Methodologies for Intelligent Systems.LNAI, June 1996.
[DFP95] S. Ducasse, M. Fornarino, and A-M. Pinna. AReflective Model for First Class Relationships.In Proceedings of OOPSLA’95, pages 265–280,1995.
[Duc97] S. Ducasse. Des Techniques de del’Envoi de Messages en Smalltalk. In L’objet,
o Smalltalk en France : del’art et de la pratique. Hermes 1997.
[Frø94] S. Frølund. Constraint-Based Synchronizationof Distributed Activities. PhD thesis, Universityof Illinois at Urbana-Champaign, 1994.
[Hol92] I. M. Holland. Specifying reusable componentsusing Contracts. In O. Lehrmann Madsen, edi-tor, Proceedings of ECOOP’92, volume 615 ofLecture Notes in Computer Science, pages 287–308, Utrecht, June 1992. Springer-Verlag.
[KLM 97] G. Kiczales, J. Lamping, A Mendhekar,C. Maeda, C lopes, J-M. Loingtier, and J. Ir-win. Aspect-Oriented Programming. In Pro-ceeding of ECOOP’97, Xerox PARC, Palo Alto,CA, June 1997. Springer-Verlag.
[Mul97] P.A. Muller. objet avec UML. Ey-rolles, 1997.
[Nac97] A. Nacciu. Dependencies within a distributedobject system - a CORBA approach, July 1997.
[Neu91] C. Neusius. Synchronizing Actions. In Proc. OfEuropean Conf. On Object-Oriented Program-ming ’91, number 512 in LNCS, pages 118–132, July 1991.
[OMG95] “Relationship Service Specification”, Part9 of CorbaServices Doc. Number 95.3.31,1995. http://www.omg.org/library/corbserv.htm.
[ORB92] “The common Object Request Broker : Ar-chitecture and Specifications”, Object Manage-ment Group and X/Open, 1992.
[Pin93] X. Pintado. Gluons: a support for softwarecomponent cooperation. In Shojiro Nishioand Akinori Yonezawa, editors, First Interna-tional Symposium on Object Technologies, vol-ume 742 of Lecture Notes in Computer Science,pages 43–60, 1993.
[Rat97] Objectory Process 4.1 : Your UML Pro-cess, Rational Corp., 1997. http://www.rational.com.
[Rum92] J. Rumbaugh. Horsing around with associa-tions. Journal of Object Oriented Program-ming, 4(6):20–29, February 1992.
[VLL94] C. Videira-Lopes and K. Lieberherr. Abstract-ing Process-to-Function Relations in Concur-rent Object-Oriented Applications. In EuropeanConference on Object-Oriented Programming,pages 81–89, Bologna, Italy, 1994.
1
Developing a Tool to support the Application ofAspect-Oriented Programming Principles to the
Design Phase
Siobhan Clarke, John MurphySchool of Computer Applications,
Abstract: Integrating system, technical functionality with the business functionality ofa system, both at the design and the coding level, increases the complexity of thedesign models or the code, and thereby makes them more difficult to understand andmaintain. Research into aspect-oriented programming [Kiczales97] has shown thatprograms can be written to support the business functionality without includingdistribution support in the code, where separate programs (called “aspect programs”)cater for the distribution requirements. We introduce here a tool which applies theAOP techniques at the design level, leaving design models simpler and easier tounderstand.
1. Introduction
The design concepts corresponding to a component language and a componentprogram at the implementation level, are a component design language and acomponent design respectively. The component design is specified in the componentdesign language and the component design is the design specification of the componentprogram. In AOP, the component language’s explicit constructs constrain the definitionof the aspect language because the aspect program must coordinate with thoseconstructs. Since we are working with a design language, we translate this to the aspectlanguage being constrained by the constructs of the design language so that the aspectprogram may be generated based on the component design.
There are two distinct “tasks” which a design tool needs to support and which wouldprobably be performed by different people:
1. Specification of Aspect Language: This task is one which is likely to be performedinfrequently by a skilled individual who understands the semantics of the designlanguage and the specific technical area the aspect in question supports. In the tool,we currently simply expose a graphical representation of the component designlanguage meta-model to the creator of the aspect language, allowing the selection ofthose constructs of the design language with which an aspect program willcoordinate. The designer of the aspect language records the relevant syntax of theaspect language without attaching meaning to those constructs. Extensions to thisapproach under discussion are supporting the aspect language designer model thetechnical aspect in a manner similar to modeling the functional component.
2
2. Aspect Program Creation: A more frequent task, this allows the applicationdesigner specify how the technical aspect supported by the aspect language appliesto the particular functional component. Here, the tool assists the creator of theaspect program to work with the component design in defining the actualcomponent design elements which are affected by the aspect.
2. Specification of an Aspect Language
The specification of an aspect language is based on the explicit language constructswhich are available to the designer of the functional component. (We have not yetconsidered the case where join points are implicit in the functional components.) Whenusing our tool to define an aspect language, a representation of the constructs in themeta-model are presented to the aspect language designer. The aspect languagedesigner may then select the design language construct for which an aspect languageconstruct is required, and specify what that aspect language construct is.
The tool maintains the specification of the aspect language in a collection of objectswhich have responsibility for reifying the list of aspect language constructs defined inthe aspect language and the rules defined for each. APIs to the collection of objectsprovide clients such as the tool component responsible for graphically guiding adesigner through the creation of an aspect program, with those construct names andrules. These rules will be the basis for the different options which will be available whenusing the aspect language to define the cross-cutting functionality of a functional design.
We are currently working on support for the aspect designer to design the aspect’ssemantics behind the aspect language.
3. Using Aspect Language to create an Aspect Program
Aspect languages are designed to describe functionality which "cross cuts" all theobjects in a program which handles the system functionality. There is no dependency onthe nature of the actual functionality handled by the program. The two main parts to theprocess of creating an aspect program are supporting the designer select the functionaldesign elements affected by the aspect and secondly, generation of the aspect program.
3.1. Applying Aspect Keywords to Functional Specification
There may be many different aspect languages which have been designed to cater fordifferent kinds of system functionality. The designer selects an aspect language from alist of available ones. The objective of the designer performing this task is to select thefunctional specification elements for which the aspect functionality is required. The setof functional elements eligible for selection is dependent on the aspect languageconstruct rules. For example, if an aspect language construct deals with operations, thenthe designer is presented with the list of operations to choose from.
3
The tool makes use of an API to the appropriate aspect language object to obtain thelist of aspect language constructs available, and presents this list to the designer.
3.2. Building the Aspect Program
The aspect program is generated based on the syntax of the particular aspect languageand the designer’s selection of associated design elements.
Once the aspect program is generated, and on generation of the component programfrom the component design, we have both the required inputs to an AspectWeaversuch as those discussed within the AOP team. The component design models do notcontain any non-functional elements. The aspect program is maintained entirelyseparately. This clear separation of concerns reduces the complexity and thereby makesthe design easier to work with.
4. Current position of work
The focus of the current version of the tool was supporting the designer to create anaspect program in a graphical manner, from the design model. Specification of theaspect language was focussed on what was required to achieve that end. Currently, weare focussing on a more flexible mechanism to support the design of an aspect’ssemantics. We feel this mechanism should be similar to the process of designing afunctional component, with similar facilities for describing an aspect’s behaviour.
References:
[Kiczales97] Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda,Cristina Lopes, Jean-Marc Loingtier, John Irwin "Aspect-OrientedProgramming", ECOOP, (1997)
1
Injecting IlitiesRobert E. Filman*
Microelectronics and Computer Technology Corporation3500 West Balcones Center Drive
This paper discusses the use of aspect-oriented programmingtechnology to impose desirable system-wide properties on dis-tributed systems.
Overcoming Complexity in Distributed ComputingThe goal of the Microelectronics and Computer Technology Corporation's (MCC) ObjectInfrastructure Project (OIP) is to simplify the development and evolution of distributed,object-oriented applications. OIP is designing and implementing an architecture whereility-providing program elements (injectors) can be automatically wrapped around ap-plication components. The task of specifying the appropriate injectors is separate fromthe actual component coding.
Traditionally, software application development has been a monolithic process. Anorganization building a software system presumed to know how it wanted that systemto behave. The requirements for that behavior would flow down to the construction ofthe underlying modules. Since the modules were being built specifically for the systemin question, it was “straightforward” to get their developers to obey the rules and con-form to defined standards. To the extent that the system used an externally providedcomponent such as a GUI or database, the behavior of that component would be ascer-tained and the use of that component within the architecture of the system shaped tomatch the external component's actual behavior.
Software development has gotten more complex. Technologies such as CORBA andHTTP provide the glue for building applications from distributed components. But un-derstanding the nuances of multiple components and varieties of glue can is itself anintellectual challenge. We can't expect a single application programmer to become ex-pert in the intricacies of many components, even if the application needs to use themall. Similarly, components impose their own constraints on their usage. We want to de-velop systems from components but don’t want the artifacts of a particular componentmanufacturer to permeate our designs, rendering us eternally dependent on the whims,demands and destiny of that vendor. We want components that obey our policies—notto have to distort our systems to match the policies of the components. And we wantways to federate existing systems while still maintaining overarching rules and proce-dures. * This paper describes work performed at MCC while the author was on assignment from Lock-
heed Martin Missiles and Space. LMMS contact information: Advanced Technology Center;Lockheed Martin Missiles and Space; 3251 Hanover Street O/H1-43 B/255; Palo Alto, Califor-nia 94304. Email: [email protected].
Injecting Ilities 03/30/98
2
Distributed systems introduce additional complexity. Developing a distributed sys-tem is in itself a more difficult task because distributed systems imply non-deterministism(and non-determinism is complex), distribution introduces many addi-tional kinds of failures, distribution is naturally less secure, and distribution’s inherentdecentralization is inconvenient to manage. Distributed computing can be made simplerby making it look more like conventional programming and by providing and auto-matically invoking correct implementations of distributed and concurrent algorithms.
RequirementsSystem development (ought to) follow from requirements. What kinds of requirementsare there? In [1], I proposed dividing requirements into four classes based on the "trac-tability" of achieving the requirement: functional requirements that exhibit the primarysemantic behavior of a system and are typically locally realized, systematic requirementsthat can be achieved by "doing the right thing" consistently throughout the program,combinatoric requirements that are computationally intractable expressions of overallsystem behavior (for example, guarantees of real-time behavior or limits on storagefootprint) and aesthetic requirements that express non-computable qualities of the sys-tem (about which even wise men may differ.) The first of these is well supported by theconventional development process ("The requirements say that a dialog box appears atthis time with the choices…") and the last two are difficult to automate in any case.
Aspect-oriented programming gives us a handle on systematic requirements. Al-ways doing the right thing is hard for a single coder, no less a gaggle of hackers. Com-puters, on the other hand, can be programmed to be tediously consistent. (Compilersare programs that are tediously consistent in transforming other programs.)
What kinds of systematic requirements exist? Our applications should exhibit reli-ability, security, scalability, extensibility, manageability, maintainability, interop-erability, composability, evolvability, survivability, affordability, understandability, andagility. (I've omitted a few.) Let us label these qualities ilities. The keen reader is likely toask, “So what exactly do you mean by, say, reliability?” Reliability requirements differfor different applications and are likely to change over the lifetime of the application. The re-liability requirement maps to executing specific algorithms that need to be invoked sys-tematically throughout the application. Some ilities are consequently manifestations ofproperly defined and implemented requirements. The open scientific question is thus(given the fuzzy definition of an ility) "Which ilities can be achieved by systematic ac-tions, and what are the actions needed to achieve those ilities?"
Controlling communication
The OIP project is pursuing the thesis that certain interesting ilities (security, reliability,manageability, quality of service) can be achieved by proper manipulation of the com-munications between components and the significant events of a component’s lifecycle.We are currently creating a set of tools to realize the transformation from specified ilitiesto controlled communications, a reference architecture (set of rules defining componentinteractions) and set of frameworks (realizations of that architecture in particular envi-ronments) to demonstrate this thesis. A key observation of this work is that communi-cation is not confined to the “actual text of a message” (for example, the procedure be-
Injecting Ilities 03/30/98
3
ing called and its arguments) but also allows arbitrary additional annotation—we pr e-sume to control both sides of the communication act.
Our efforts are aspect-oriented programming [2] in that we are separating the tasksof creating the actual domain application from the code that produces security, reliabil-ity, and such ilities. Our efforts can also be seen as an instance of the perpetual effort incomputer science to raise the “level” of supporting substrates. Tools such as CORBAhave enabled programmers to code to the specification of objects and methods. But re-alizing elements such as security or reliability are still the responsibility of the applica-tion programmer, and likely to be done incorrectly or incompletely by most such pro-grammers. (A programmer expert in the workings of a satellite flight control system ormedical database is unlikely to also be expert in security and replication algorithms.)This effort can thus be seen as a way to produce the “next generation” of CORBA-likesystems [3], where the application programmer no more worries about how to achievesecurity than she does about mapping the location of a mouse click to a window’s but-ton.
Applied ilitiesLet us consider, for each of our target ilities, how communication and lifecycle controlcan be used to affect or realize that ility, and the limits of that realization.
SecuritySecurity (at least in a software sense) is primarily a combination of access control, intru-sion detection, authentication, and encryption. Controlling the communication processallows us to encrypt communications, reliably send user authentication from client toserver (and pass it along to dependent requests) and check the access rights of requests,all independent of the actual application code. (However, depending on where the en-cryption happens in the communication process, we may only be able to encrypt themessage data, not its headers.) Watching communications provides a locus for detectingintrusion events [4] (though not, of course, specifying the actual algorithms for recog-nizing an intrusion.) These mechanisms can all be imposed on a component-based sys-tem by controlling its communications. (Such mechanisms cannot, however, preventsubverting a system’s personnel, tapping communication lines, brute-force cracking ofencryption codes, or components that cheat by opening their own socket connections.)
ManageabilityThe International Standards Organization has defined five elements to manageability:performance measurement, accounting, failure analysis, intrusion detection, and con-figuration management. The first four of these can be implemented by generatingevents in relevant circumstances and directing those events to the appropriate recipi-ents. To the extent that the semantics of these events can be tied to communication acts(e.g., each time a service is called, a micro-payment for that service is processed, or thetrace of inter-component messages is sent to a system’s debugger) then they can be re-alized through external communication controls. To the extent that the interesting ac-tions happen completely within the application components (e.g., payment is due pro-portional to the number of records accessed by a database service or debugging whollywithin a component) then this technique will prove inadequate.
Injecting Ilities 03/30/98
4
Configuration management is partially an issue of object lifecycle. Communicationcontrol can be used to dynamically determine if appropriate configurations are in useand to automatically update stale configurations.
ReliabilityOur primary experiments in supporting reliability have centered on using replicationfor reliability [5]. Replication algorithms typically need to send copies of messages toreplicants, but our work has also revealed that message replication is insufficient forpractical replication. Rather, the application needs to be written to express its operationsin symbolic terms, not in terms of addresses in a specific replicant’s address space.
Similarly, I believe transaction management would (practically) yield to communi-cation control only if the managed objects provide the necessary primitives (locking androllback.) These points illustrate the limitations of pure communication control in thepresence of monolithic compents, even given the existence well-defined algorithms.
Quality of serviceBy quality of service I mean to encompass a variety of requirements for getting thingsdone within time constraints. The real-time community recognizes two varieties of real-time systems, hard real-time and soft real-time. Hard real-time systems have tasks thatmust be completed at particular deadlines, or else the system is incorrect. Soft real-timesystems seek to allocate resources so as to accomplish the most important things. Toachieve hard real-time systems, one can either reserve resources and plan consumptionor use an anytime algorithm. Aside from that latter, somewhat esoteric choice, hardreal-time requires cooperation throughout the processing chain (for example, in the un-derlying network), for the promise of particular service can be abrogated in too manyplaces. That is, you can’t get hard real-time unless you build your entire system withthat in mind. It’s a combinatoric requirement. (Doug Schmidt's work on Real-TimeCORBA ORBs [6] illustrates this point: commercial ORBs, built without constant real-time mindfulness, conceal FIFO queues and exhibit anti–real-time behavior.)
Soft real-time quality of service is amenable to several communication control tac-tics. These include calling the underlying system’s quality of service primitives, usingside-door mechanisms to efficiently transport large quantities of data (e.g., opening asocket to send a movie, thereby avoiding CORBA coding and decoding), using queuecontrol to identify the most worthwhile thing to do next [7] and by choosing amongmultiple ways of problem solving. All of these except the last are well within the scopeof communication control, and if the application supplies the alternative problem solv-ing methods (either by replicating the problem solving sites or providing genuinely dif-ferent algorithms) the communication control mechanism can learn (based on historicaltiming data and communications with other clients) the most efficient problem solvers.
ImplementationA few remarks on OIP implementation are worth mentioning. The underlying compu-tational model is to wrap components with a sequence of injectors. Systems likeCORBA and Java RMI support a stub/skeleton proxy mechanism for distributed com-munication. (In fact, several commercial ORBs include the ability to specify some user-defined filters on communications. Such filters are required by the yet-to-become-commercially-available CORBA security service.) OIP injectors are individuated by
Injecting Ilities 03/30/98
5
proxy/method and can, with the appropriate access controls, be changed for a particu-lar proxy.
Injectors can both read and write not only the application program arguments, butalso the annotations associated with the message. Thus, the annotation mechanismsupports communications among injectors.
Annotations can be understood to be the procedure-call analog of mail headers.Certain headers have common meanings ("From" and "To") while others are more spe-cialized to particular programs ("X-Sun-Charset"). Our experience with OIP has sug-gested an initial set of common annotations (including session identification, requestpriority, sending and due dates, version and configuration, answer futures, cyber wal-let, public key, sender identification and conversational thread.) Thus, a request can beidentified as having a specific priority and injectors can change their actions based onthat priority (for example, to queue incoming requests and execute the highest priorityrequest next, as was done in [7].)
Security concerns about the use of injectors can be reduced by requiring an injectorto declare which annotations it reads and writes (and enforcing that declaration). Wemay be more willing to use a plug-in injector obtained from a random site if we knowthat all it does is read the sending and due dates of messages than if it claims to altersender identification and message text. (The former could be used to support an adap-tive real-time mechanism such as the one described in [8].)
OIP also supports chaining of annotations through called threads. Thus a routinecalled with a priority of X will make calls at priority X (unless the thread explicitlychanges the priority).
Selection of which initial injectors to use for which methods of which classes isdone by a compiler that takes a language of injector specifications and builds the ap-propriate default structures for the run-time system. This language provides a level ofindirection between desired ilities and their implementations, and allows the successiverefinement of policies through an organization. This use of a separate specification lan-guage for creating filters parallels the work at BBN on QoS [9], where an IDL-like Qual-ity Description Language is woven with IDL to affect system performance.
I also note that Videira Lopes and Kiczales also apply communication control todistribution for the aspects of synchronization and distribution [10].
Concluding remarksI have argued that high-level, desirable system-level properties can be achieved in acomponent-based system by systematically controlling the inter-component communi-cations and component lifecycle. Our initial experiments have lent credence to this hy-pothesis, subject to the caveats that some algorithms (e.g., transactions) require coopera-tion on the part of the application, and that our desire for system-level properties (e.g.,security) must be kept within the range of definable mechanisms. Our work continueson developing the mechanisms to automate this process and testing our thesis.
AcknowledgmentsThe ideas expressed in this paper have emerged from the work of the MCC Object In-frastructure Project, particularly Stu Barrett, Carol Burt, Deborah Cobb, Tw Cook,Phillip Foster, Diana Lee, Barry Leiner, Ted Linden, David Milgram, Gabor Seymour,Doug Stuart and Craig Thompson. Some of these ideas have been expressed in refer-
Injecting Ilities 03/30/98
6
ence [1].My thanks to Tw Cook, Diana Lee, Ted Linden, Dave Milgram and Tom Shields for
comments on the drafts of this paper.
References[1] Robert E. Filman, "Achieving Ilities," Workshop on Compositional Software Architectures, Mon-
[2] Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier, and John Irwin “Aspect-Oriented Programming, ” Xerox PARC TechnicalReport, February 97, SPL97-008 P9710042. http://www.parc.xerox.com/spl/projects/aop/tr-aop.htm
[3] Craig Thompson, Ted Linden and Bob Filman, “Thoughts on OMA-NG: The Next Genera-tion Object Management Architecture,” Presented at the OMG Technical Meeting, Dublin,Ireland, September, 1997.http://www.mcc.com/projects/oip/next_oma.html
[4] Robert Filman and Ted Linden, “Communicating Security Agents,” The Fifth IEEE-Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises---International Workshop on Enterprise Security, Stanford, California, June 1996, pp. 86-91.
[5] Stu Barrett and Phillip Foster, “Turning Java Components into CORBA Components withReplication,” OMG-DARPA-MCC Workshop on Compositional Software Architectures,Monterey, California, Jan. 1998.http://www.objs.com/workshops/ws9801/papers/paper067.doc
[6] Douglas C. Schmidt, Rajeev Bector, David L. Levine, Sumedh Mungee, and Gurur Parul-kar, "An ORB Endsystem Architecture for Statically Scheduled Real-time Applications,"Proc. IEEE Workshop on Middleware for Distributed Real-time Systems and Services, San Fran-cisco, Dec. 1997, pp. 52-60.
[7] Diana Lee and Robert Filman, “Verification of Compositional Software Architectures,”OMG-DARPA-MCC Workshop on Compositional Software Architectures, Monterey, Cali-fornia, Jan. 1998.http://www.objs.com/workshops/ws9801/papers/paper096.html
[8] M. Gergeleit, E. Nett, and M. Mock, "Supporting Adaptive Real-Time Behavior in CORBA,"Proc. IEEE Workshop on Middleware for Distributed Real-time Systems and Services, San Fran-cisco, Dec. 1997, pp. 61-67.
[9] Richard Schantz, David Bakken, David Karr, Joseph Loyall, and John Zinky, "DistributedObjects with Quality of Service: An Organizing Architecture for Integrated System Proper-ties," OMG-DARPA-MCC Workshop on Compositional Software Architectures, Monterey,California, Jan. 1998.http://www.objs.com/workshops/ws9801/papers/paper099.doc
[10] Cristina Videira Lopes, and Gregor Kiczales, "D: A Language Framework For DistributedProgramming," Xerox PARC Technical report, February 97, SPL97-010 P9710047.http://www.parc.xerox.com/spl/projects/aop/tr-d.htm
Operation-Level Composition: A Case in (Join) Point
Harold OssherPeri Tarr
IBM T.J. Watson Research CenterP.O. Box 704
Yorktown Heights, NY 10598{ossher, tarr}@watson.ibm.com
1. Introduction
Our work on subject-oriented programming [1, 2] has focused on two central issues that webelieve to be at the core of research in the domain of “aspect-oriented'” software development:
• Facilitating the identification and description of cross-cutting concerns in a softwaresystem— i.e., those aspects that affect more than one unit of functionality in the system,given some definition of “units of functionality” (objects, modules, functions, etc.).
• Facilitating the identification and integration of join points in the system. Join points arethe locations in systems that are affected by one or more cross-cutting concerns. Theprocess of integrating join points involves describing how a cross-cutting concern affectscode at one or more join points. The integration process is referred to as composition orweaving.
The set of possible join points includes all locations in all system components, which we callstatement-level join points to indicate that they can occur in any part of code. Subject-orientedprogramming, however, is predicated on the belief that a significant majority of join points ofconcern in software development are those represented by operations, and that the majority ofcross-cutting issues that are of concern to developers are those involving capabilities that affectmultiple operations. Additionally, we believe that a focus on operation-level joining is especiallyappropriate in an object-oriented context, because it adds the power of composition naturallywithin the object-oriented paradigm.
Operation join points do not necessarily imply specification (or coding) of all aspects asfunctions. We believe that many of the kinds of capabilities for which aspect-orientedprogramming might be used, which might at first appear non-functional, do, in fact, involvefunctional aspects and operation join points. However, there are undoubtedly cases in which non-functional specification of aspects, in different notations, is appropriate. Even in such cases,operation join points are often appropriate.
The remainder of this position paper explores the broad utility of functional aspects and operationjoin points, and discusses several issues that affect the feasibility of supporting general statement-level join points.
2. The Prevalence of Operation Join Points
Many kinds of cross-cutting concerns affect the definition of collections of operations that spanmultiple units of functionality. For example, many objects might support a print capability.The particular way in which this capability works in a given system might depend on one or moresystem requirements, such as “all print operations will send mail to the system administrator ifthey cannot complete successfully.” Cross-cutting concerns that affect the behavior of groups ofoperations typically require the use of operation join points— e.g., to add a check for success afterthe invocation of each print operation, and to send mail as appropriate.
In our experience, a wide range of cross-cutting concerns that affect a system are, in fact,correctly described using operation join points, even when, at first glance, it is not obvious thatthis would be the case. This phenomenon arises because cross-cutting concerns very often arespecified in terms of how they affect existing object behaviors (when they define new behaviors,they can be said to involve operation join points trivially), which makes them amenable toimplementation via operation join points. Some examples of these kinds of cross-cuttingconcerns, and their description in terms of operation join points, are presented in the followingparagraphs.
Persistence: Persistence tends to be a pervasive property of data in systems; thus, it would beappropriate to develop a “persistence aspect” that implements the persistence capabilityindependently of any particular objects and compose this capability into those objects that are tobecome persistent. In deciding how to compose the persistence aspect with the objects to whichit will apply, we note that retrieval of persistent objects from a database occurs upon objectaccess, and update of persistent objects occurs upon object creation or modification. Thus, thenecessary join points are operations: the “update” part of the persistence aspect affects theconstructor and set methods of persistent objects, while the “retrieve” part affects get methods.
Error detection and handling, and fault tolerance: Some forms of error detection are intrinsicto the definition of a type of object; for example, it is always wrong to attempt to pop an itemfrom an empty stack. Such “well-formedness” definitions are usually built into a type. Otherkinds of errors, however, are context-specific— their presence depends on the requirements of theparticular application in which the types are used. For example, a set of generic, reusablecomponents (e.g., lists, stacks, sets) used in a compiler have considerably looser error handlingand fault tolerance requirements than the same components used in a safety-critical system. Insuch cases, it is desirable to describe the error detection and handling behaviors as one or moreseparate aspects. Some of the most common kinds of non-intrinsic error handling mechanismswe have seen are those represented as pre- and post-conditions on modify methods. The joinpoints in such cases are operations: pre- and post-condition checks, error-catching methods, anderror-handling methods can all be joined to the methods that can cause or encounter the errorconditions. There are other cases where one really needs to add additional error checks withinexisting code; in these cases operation join points are not sufficient (unless one is willing toduplicate code by replacing a function with a copy to which the additional checks have beenadded).
Logging, tracing, and metrics-gathering: Where and when logging, tracing, or metrics-gathering activities occur is frequently dependent on application-wide decisions that aredetermined, for example, by development phase or local policies. Ideally, code to perform theseactivities would be modeled as an aspect and composed selectively into the relevant parts of anapplication. All of these activities are usually associated with operations (e.g., to log entry into,and exit from, an operation) and could be composed using operation join points.
Caching behavior: It is often desirable to consider the issue of caching intermediate results in acomplex computation as an aspect separate from the algorithm itself. In particular, an algorithmwritten without caching might need to be modified to include caching upon observation ofinadequate performance. In the important case where the computation traverses a network ofobjects, processing each node to compute some value(s), operation join points are natural. The“process” operation in the algorithmic aspect just performs the computation. The caching aspectof this same operation maintains a cache of the computed value(s), probably in the node itself. Iteither returns the cached value or invokes the algorithmic aspect, depending on the currency ofthe cache. Clearly, the composition in this case must give the caching aspect control.
Other common cross-cutting issues that affect many applications include serializability,atomicity, replication, security and visualization. We believe that support for these and manyother features turn out to be well represented using operation join points.
Clearly, functional aspects and operation join points are required and useful for describing andintegrating a wide range of important cross-cutting concerns in software systems. For this reason,the subject-oriented programming paradigm supports “aspect-oriented programming” based onfunctional aspects and operation join points. Part of our ongoing research includes theexploration and validation of the variety of functional and non-functional aspects to whichoperation-level joining applies.
3. On General, Statement-Level Join Points
A key element of subject-oriented programming is flexible, domain-independent, generic pointsat which composition is to occur, and specify the details of the composition desired. It isimportant that rules continue to work even as the inputs evolve, within reason. We excludedstatement-level join points for several reasons:
• We have not yet found convincing evidence that the additional power resulting from suchjoin points is of general use, particularly in light of the concomitant increase incomplexity. This is particularly true in light of the broad spectrum of circumstancesunder which operation join points appear to be applicable.
• The tractability of the problem of defining general-purpose statement-level weavers isquestionable. Even stable references to join points in rules present serious problems inthe light of evolving inputs.
• We are extremely concerned about the degree of unpredictability that results fromstatement-level weaving. Changing a statement in a piece of code changes both the data-and control-flow properties of that code; any guarantees that might have been made aboutthe code are negated. In fact, much work in the area of software analysis and testing hasattempted to identify the impact of changes to code, in an attempt to identify new errorsand to help select test cases whose results have been invalidated by the changes.Unfortunately, data- and control-flow analyses are inherently exponential, furthersuggesting the difficulty involved in understanding the effects of statement-levelcomposition.
• One of the significant contributions of object-oriented software development was to makechanges additive rather than invasive (see, for example, [3]). This is a particularlyimportant property because of the well-documented, extremely adverse effects onsoftware systems of invasive changes. The notion of general statement-level joinsrepresents invasive software change, violating the additive-changes principle.
In light of these concerns, we do not believe that conclusive evidence yet exists to suggest that theadditional power provided by arbitrary statement-level joining is of sufficiently broad andpractical use to justify its potential disadvantages. Indeed, the work on aspect-orientedprogramming we are aware of has concentrated on weaving in specific domains, and in each casethe kinds of join points, though not always operations, are carefully circumscribed. Furtherresearch is required to characterize systematically the circumstances under which statement-leveljoining may be practical and justified, despite its drawbacks.
4. Conclusion
We believe that the ability to describe capabilities associated with concerns that cut acrossmultiple parts of a system and to specify how those capabilities affect the system, without havingto physically intersperse the code that realizes such capabilities, is an extremely important part ofsupport for programming-in-the-large. Used correctly, this capability, which defines aspect-oriented programming, can reduce the complexity and improve the maintainability of a systemconsiderably.
Identifying the points at which a cross-cutting concern affects a system is an important part ofaspect-oriented programming. While the set of potential “join points” is large and could,potentially, include every statement and expression within a system, our research suggests thatfocusing on operation-level joining can successfully address many common composition needs,for both functional and non-functional aspects. Further, we believe that general statement-leveljoining raises numerous technical and methodological concerns that may render it intractable,infeasible, or undesirable in the general case. Further work is needed to test and extend thisconclusion.
Subject-oriented programming is an approach to aspect-oriented programming that is based onoperation-level joining. Subject-oriented programming thus avoids the problems inherent ingeneral statement-level joining, while providing the ability to describe many kinds of cross-cutting concerns separately and to compose cross-cutting capabilities into object-orientedprograms. It also preserves and extends many of the desirable features of the object-orientedparadigm. The choice of join points has made it possible to develop a general-purpose, domain-independent compositor, which is central to our tool support [4].
5. Bibliography
[1] William Harrison and Harold Ossher. Subject-oriented programming (a critique of pureobjects). In Proceedings of the Conference on Object-Oriented Programming: Systems,Languages, and Applications, pages 411–428, Washington, D.C., September 1993. ACM.
[2] Harold Ossher, William Harrison, Frank Budinsky, and Ian Simmonds. Subject-orientedprogramming: Supporting decentralized development of objects. In Proceedings of the 7th
IBM Conference on Object-Oriented Technology, Santa Clara, CA, July 1994, IBM.Available as Research Report RC 20004, IBM T.J. Watson Research Center, YorktownHeights, NY, March 1995.
[3] John Vlissides. Subject-Oriented Design. In C++ Report, February 1998.[4] http://www.research.ibm.com/sop
Mixin Composition Strategies for the
Modular Implementation of Aspect WeavingThe EPP preprocessor and its module description language Ld-2
Aspect Oriented Programming workshop at ICSE'98, April 20th, 1998, Kyoto
Computer Science Division1-1-4 Umezono, Tsukuba, Ibaraki 305 JAPAN
Abstract: EPP (the Extensible Preprocessor) is an extensible language preprocessor; it was de-signed to introduce new language constructs by the mere addition of plugin modules that can alsode�ne new syntaxes and macro de�nitions. The relation of EPP to AOP is twofold. First, the EPPkit has been programmed using the Ld-2 language which introduces aspect-oriented constructs:system mixins. Second, we suggest that EPP could be used to program aspect-oriented weavers ina modular fashion. We describe here the new Java version of EPP. We also discuss the constructsneeded for providing additional capabilities regarding the composition of extension modules thatcould serve in writing weavers.
1 Issues in AOP
The traditional approach to software programminghas been to modelize a problem by de�ning in-dependent components, be it under the form ofobjects or functions. Global interactions betweencomponents and with the program environmentarise, but only implicitly, from their local calls:this is a major drawback when this global interac-tion (or other mechanisms involving parts of sev-eral components) is the most important de�nitionin the software, especially if it must be �ne-tuned.For instance, parallel or reactive systems often ex-hibit these characteristics.
Re ective systems are good at solving some ofthese issues but do not seem so well adapted fordealing with composition problems or syntactic is-sues in a simple manner.
These problems get worse when the size of thesystem grows. The programmer needs to isolateparts of its components in relation with others (un-tangling). Moreover, introducing speci�c syntax isvery important, would it only be because manyformalisms and formal systems have already beendeveloped and could improve the quality of pro-grams.
Aspectual approaches (e.g. [LK97]) directly tar-
get these problems and thus shed a new light onpossible solutions. However, this approach dele-gates many problems to the aspect weaver whichhas to gather aspectual code, process it accordingto aspect descriptions and generate the �nal pro-gram.
If the size of a system becomes quite large, com-plexity will also increase. Aspects seem to be some-how domain dependent: if the system grows, it israther likely that more aspects will be needed todescribe it. For now, we can only think of rathersimple aspects, but there could be a need for morecomplex ones as well (although not as complex asthe systems they will help to describe). Decom-posing the aspect weaver into smaller composableunits would both simplify the task of programminga weaver and allow to reuse parts of the aspect de-scription. But to date, a very limited number oftools has been developped that could readily ad-dress, in a generic manner, the de�nition of weaverswith such kind of modular units.
2 The module description
language Ld-2
We �rst introduce an object-oriented language, Ld-2 (Language for di�erential description) [IHT+96,RI97b]. Ld-2 provides a mechanism, system mixin,
1
which enables the program to be split according todi�erent points of view into small reusable mod-ules.
2.1 System Mixins
The �rst program in Fig.1 de�nes a method namedm which contains nested if statements. Thismethod is written in a traditional style, in otherwords, in a \monolithic" way. When a programmerwants to add a new else-if clause to this method,the only way to do so is to edit the source code. Byusing the inheritance mechanism, some editing canbe avoided, but this changes the name of the classwhere the method belongs. It is indeed impossi-ble to extend the behavior of the method withoutde�ning a new subclass. If at some other place inthe program, there exists the de�nition class Bar
extends Foo f� � �g or the de�nition new Foo(),all Foo occurrences have to be changed to the nameof the subclass.
class Foo {
void m(String d){
if (d.equals("B")){
doB();
} else if (d.equals("A")){
doA();
} else {
doDefault();
}
}
SystemMixin Skeleton {
class Foo {
define implement void m(String d){
doDefault();
}
}
}
SystemMixin A {
class Foo {
extend void m(String d){
if (d.equals("A")) { doA();} else { original(d);}
}
}
}
SystemMixin B {
class Foo {
extend void m(String d){
if (d.equals("B")) { doB();} else { original(d);}
}
}
}
Figure 1: Method de�nitions with and without sys-tem mixins.
Ld-2 solves this problem by introducing sys-tem mixins. Bracha [BC90] showed the exibilityand reusability of mixin-based inheritance. System
mixins are similar to mixins but the unit of inher-itance is not a class but the whole program.The second program in Fig.1 uses the system
mixin feature and has the same meaning as the�rst one; however, its structure is much more mod-ular. The keyword SystemMixin de�nes a systemmixin, that is, a fragment of the program. All sys-tem mixins are composed into a complete programbefore starting up. The expression original(d) issimilar to the method invocation to the super classin traditional object-oriented languages. When themethod m is called, the fragment of method m de-�ned in B will be called. If the fragment evaluatesoriginal(d), the next fragment de�ned in A willbe called.If there are subclasses of class Foo, the extension
of method m will be propagated to all of them.
2.2 An AO layout in Ld-2
Among other styles, system mixins allow program-ming \by di�erence", a form of aspect-orientedprogramming.Intuitively, the API of the application should be
de�ned as a description of small components. Thebase object-oriented language is very well adaptedfor expressing these matters. Classes should re-main the common reference, especially for team-work.After this �rst description has been written,
cross-cutting concepts can be introduced by othersystem mixins. Classes or parts of classes are dis-tributed among system mixins, then programmed.A system mixin thus roughly corresponds to an as-pect or to part of an aspect (either if it is complexor for reuse reasons, in a mixin style).The choice of classes or parts to be added to a
mixin is equivalent to chosing join points in otherapproaches (decided inside of the aspect weaver).Of course, each system mixin can introduce newjoin points by de�ning new classes, which could beregarded as de�ning aspects of aspects. We gener-ally �nd it preferable to de�ne a kind of abstractsystem mixin containing all these classes de�ni-tions (but only class de�nitions). All other systemmixins simply introduce additional aspects.As usual in object-related designs, this dou-
ble de�nition of components interface and cross-cutting system mixins should probably follow aniterative design (and should in fact already takeplace in the requirements speci�cation). The �nalcomposition depends on the order of speci�cationof system mixins, mostly decided for dependencyreasons, but can also be a deliberate choice of the
2
Name Function
AutoSplitFiles Splits multiple public classes in one �le to multiple �les.defmacro Macro de�nition with the same style as #de�ne .EmbedCopyright Embedding a message into all class �les.enum Constant integer de�nition.OptParam Optional actual parameters.UserOp Operators for user de�ned data types.Math Using java.lang.Math with easier way.assert Assert macro.noassert Translates assert macros to null statements.SystemMixin Supporting programming-by-di�erence.Symbol Same as lisp's symbols.BackQuote Same as lisp's back quote macros.
Table 1: Plugins currently provided.
programmer to select features from a special sys-tem mixin.
2.3 Related constructs
Flavors and CLOS [Ste90] provide before and af-ter daemon methods that are related to the systemmixins because they can add extra behavior to ex-isting methods without changing their class nameand method name. However, daemon methods area more restricted mechanism than system mixins.For example, it is impossible to add multiple before(or after) daemon to one method.
Objective-C has a notion of \category". Usingcategories, the programmer can add new meth-ods to the existing class hierarchy. A third partyprogrammer can add methods to existing class li-braries even if their source code has not been sup-plied. However, it is impossible to extend existingmethods without subclassing.
Some design patterns [GHJV93] which enhanceextensibility o�er an analogy to system mixins.For example, decorators are units of extension andmultiple decorators can be composed simultane-ously. However, applying the Decorator patternrequires explicit method delegation which is not re-quired by the system mixin construct. In addition,the Decorator pattern requires a �xed interface fordecorators. Therefore, exibility is worse than sys-tem mixins. Of course the comparison is di�cultbecause decorators are just patterns and not lan-guage constructs. Decorators also de�ne the waythey can be dynamically composed during the ex-ecution of the program. As opposed to this design,the con�guration of the system mixin list is �xed
just before starting up the program.
3 A generic extensible pre-
processor kit: EPP
To implement new languages or extend existingones, pre-processors or translators are often usedrather than native compilers (e.g. many tools forC/C++). The merits of this style of implementa-tion are its simplicity and high portability; more-over, preprocessors o�er a form of re exivity sincethe introduced extensions are ultimately describedin the extended language. We argue that the in-terest for such tools is symptomatic of their powerof description of (admittedly often simple) abstrac-tions of the code, and sometimes the possibility todeal, at least partly, with tangling issues. Syntacticissues are especially often adressed and preproces-sors clearly help increase programs declarativeness.
3.1 Preprocessing tools
The Java language [GJG96] has recently becomevery popular among programmers but lacks facili-ties for language extension o�ered by many otherobject-oriented languages. For instance, C++ pro-vides at least a macro pre-processor and has oper-ator overloading and template facilities; Smalltalkand CLOS [Ste90] have closures and metaclass fa-cilities. These features extending language con-structs and operators supplement the class mecha-nism which extends data types.
Many extensions have been proposed for theJava language and often implemented as pre-
3
processors. Although there are potentially manyuseful language extension systems, extensions areoften exclusive: it is generally impossible to mergeseveral language extensions or eliminate harmfulfeatures from the extended system.Systems with a meta-object protocol (MOP)
such as CLOS [KdRB91], MPC++ [Ish94],OpenC++ [Chi95], EC++ [C+97] or JTRANS[KK97] have solved this problem. These systemsallow the implementation of language extensionsas modules that can be selected by the users. Yet,extensibility of syntax is slightly restricted in thesesystems; composition of extensions is often not themain interest of these systems either.
3.2 EPP: the preprocessor kit
The Extensible PreProcessor kit, EPP, is a genericextensible preprocessor: it provides an applicationframework for writing preprocessor type languageextension systems. EPP basic behavior is to trans-form a Java source code into the same program. Byusing the hooks provided by EPP recursive descentstyle parser the extension programmer can extendthis basic behavior: he can introduce new features,possibly associated with new syntax without edit-ing the existing source code of EPP. Because allgrammar rules are de�ned in a modular way, itis also possible to remove some original grammarrules from standard Java.Once the parsed program has been transformed
into a tree, the pre-processor programmers can eas-ily manipulate it from their program. The useful-ness of such kind of tool has already been provenby Lisps and adapted to C++ by various systemslike Sage++ [B+94], MPC++ [Ish94] or OpenC++[Chi95].EPP enables preprocessor programmers to write
extensions as separate modules that are �nallycomposed to form a complete preprocessor. Wecall these extension modules plugins.High composability of EPP plugins can be re-
alized thanks to the module description languageLd-2 and the system mixin feature.The inheritance mechanism of object-oriented
languages makes it easy to implement extensibleapplications because all methods of objects canbe considered as hooks for extensions. In addi-tion to the traditional inheritance mechanism, sys-tem mixins encourage the development of extensi-ble and modular software.The �rst prototype of EPP (lisp-epp) was writ-
ten in Common Lisp [Ste90]. Using this sys-tem, several plugins have been implemented in-
#epp "enum"
public class EnumTest {
enum {RED, GREEN, BLUE}
enum {
MALE,
FEMALE,
}
public static void main(String argv[]){
System.out.println(EnumTest.RED);
}
}
Figure 2: A program using a enum plugin.
/* Generated by EPP 1.0beta3 (by lisp-epp1.0beta3) */
public class EnumTest {
public static final int RED = 0;
public static final int GREEN = 1;
public static final int BLUE = 2;
public static final int MALE = 0;
public static final int FEMALE = 1;
public static void main(String argv[]){
System.out.println(EnumTest.RED);
}
}
Figure 3: The translated program.
cluding a simple parallel language: Tiny Data-Parallel Java [IR97] and a reactive programmingextension [RI97a].The source code of lisp-epp is now re-written in
\Java extended by EPP" itself. The bootstappedbyte-code is available on any platform where Javais supported. Plugins also work on any platform,therefore they can circulate and be used as casuallyas class libraries written in Java.Although the current target of pre-processing is
only Java, the architecture of EPP is applicable topre-processors for other programming languages.
3.3 An Example of an EPP plugin
The user of the pre-processor can specify an EPP
plugin at the top of his Java source �les. The pluginwill be dynamically loaded by EPP before startingthe pre-processing. Fig. 2 is a simple example pro-gram using an EPP plugin that de�nes an enummacro.Fig. 3 is the translated program. Each element of
the enum declaration is expanded into static �nal�eld declarations.The plugin is a Java class �le written in \Java
extended by EPP". Fig. 4 shows how the source
4
code of the enum plugin looks like. The sourcecode makes use of four plugins (see Table 1 whichexplains the function of each plugin).The source code consists of two parts: the de�-
nition of the extended syntax and the de�nition ofthe macro expansion function. The �rst part willadd a \patch" to the recursive descent parser inorder to add a new grammar rule of enum decla-ration. The second one de�nes a function whichtranslates an enum declaration into a static �nal�eld declaration.
3.4 Parser design
Code generation is not the only part of EPP writ-ten in Ld-2. The parser itself is basically writtenin a recursive descent style [ASU87], using the sys-tem mixin feature. Each function which parsesa non-terminal consists of nested if-then-else
branched by the value of a look-aheaded token.The plugin programmer can add new else-if
clauses to the methods in order to add new op-erators or new statements. As shown in �gure 4, itis possible to manipulate the abstract syntax treeof the program without special problems. The �-nal parser is composed of the original parser plusseveral patches in the order chosen for the compo-sition of system mixins.
4 Beyond system mixins: an
architecture for the weaver
From their primary objectives, most aspects seemto be domain dependent. Most probably, aspectscan be grouped in families from which basic brickscould be extracted for describing their commonpoints. Aspects are also fairly specialized, henceavoiding combinatory explosion should also be aconcern of weaver programmers. Our position isthat these basic bricks should not be classes butsystem-wide mixins (used in an AOP fashion ornot). As a side e�ect, using mixins is a good wayto preserve alternative designs for weavers, andpotentially to �ne-tune aspect implementations atrun-time. For these reasons, we will essentially fo-cus on the use of system-wide mixins for designingweavers.
#epp "Symbol"
#epp "SystemMixin"
#epp "AutoSplitFiles"
#epp "BackQuote"
package enum;
import epp.*;
SystemMixin enum {
class Epp {
extend Tree classBodyDeclarationTop() {
if (lookahead() == :enum) {
matchAny();
TreeVec tvec = new TreeVec();
match(:"{");
while (true){
if (lookahead() == :"}") break;
tvec.add(identifier());
if (lookahead() == :"}") break;
match(:",");
}
matchAny();
return new Tree(:enum, tvec);
} else {
return original();
}
}
extend void initMacroTable() {
original();
defineMacro(:enum, new EnumMacro());
}
}
}
class EnumMacro extends Macro {
public Tree call(Tree tree){
Tree[] args = tree.args();
int c = 0;
TreeVec top =
(TreeVec)Dynamic.get(:beginningOfClassBody);
for (int i = 0; i < args.length; i++){
top.add(
`(decl
(modifiers
(id public) (id static) (id final))
(id int)
(vardecls
(varInit ,(args[i])
,(new LiteralTree(:int,
Integer.toString(c++))))))
);
}
return `(emptyClassBodyDeclaration);
}
}
Figure 4: The source code of enum plugin.
5
We have experimented with Ld-2 system mixins�rst in the Lods compiler kit [IHT+96] and morerecently for programming EPP extension pluginsand have found them a very suitable and simpletool for improving program organization.However, they provide only a limited form of
compositionality. The standard composition ruleof mixins is a simple, additive fusion of constructsin the order explicitly determined by the program-mer (system mixin dependencies). Of course, eachsystem mixin can itself de�ne additional classeswhich can be extended by other system mixins:this slightly enhances the model compositionalityand could permit to program aspects of systemmixins (themselves aspects or parts of aspects).Improving composition capabilities should enhancethe reusability of system mixins.Moreover, de�ning a general architecture of as-
pects is very desirable: it would document theweaver and could keep knowledge about good orbad designs (for performance improvement or com-patibility for instance: e.g. which aspects shouldnot be used together ?).
4.1 Successive re�nement approach
A �rst approach to introducing more composition-ality in our design is to build a weaver as the succes-sive application of smaller weavers, that is by ap-plying a re�nement process: the original program(possibly written using several languages) is trans-formed into simpler forms by the repeted applica-tion of simple transformations. In this approach,the �nal program is the result of a series of rewrit-ings.This approach can be re ective if the process
applied at each step is the same: see for instancecompile-time MOPs with an recursive generationof meta-objects.The speci�cation of the di�erent re�nements is
quite simple in itself, especially in a meta-objectarchitecture where each meta-object is a modularunit. However, global interactions of several mix-ins/aspect descriptions is not explicitable (exceptmaybe by introducing group re ection, but whichmight then result in di�erent implementations) andthe composite architecture is not directly visible oreven representable in a detailed way, apart fromthe succesive weavers applied.
4.2 Relational approach
This is why we are currently studying the intro-duction of a notion of relation connecting system
mixins and explicitly conveying the compositiondescription.The purpose of this approach should be to ex-
pose all connections between components of aweaver, which we feel is especially important if weadopt a mixin-based solution.Similar approaches have been undertaken like
pattern languages [KC97] which can be used tode�ne relations between di�erent patterns; seman-tic nets are another example of such compositionmodel.In EPP, plugins must be assembled in a de-
termined order which is speci�ed in a setup list;this list can be seen as a set of precedence rela-tions between the di�erent plugins. Other relationsare most probably interesting: policy for mergingseveral plugins (addition, replacement, partial re-placement, etc.), contracts to ensure the delivery ofinformation between system mixins (in a data ow-driven fashion), logical assertions, and so on. Re-lations are probably not only two-party but moreprobably multi-party: think for instance of how tocombine several overlapping system mixins to forman aspect.It is possible to use relations to represent possi-
ble or unacceptable design alternatives, especiallyin a mixin approach as we noted; the program-mer could be able to select among a set of mixinstrategies to implement his plugins (aspects de-scriptions).Introducing such complex relations would prob-
ably also mean adding an interface to system mix-ins for connecting related types of relations. Sinceextended plugins can be very general, these inter-faces should also be parametric on the relations ininput: this would permit the most abstract de�ni-tion to be possible. For instance, if an informationis expected by a plugin, it could be parameterizedto o�er pattern-like generative properties. Com-ponent litterature should probably be reread withaspects in mind instead of direct composition ofcomponents.The granularity of extended plugins certainly in-
uences their reuse, but in this approach, theircomposability essentially depends on the kind ofrelations that they can support and establish withother extended plugins. That way, building an as-pectual weaver would be nearly transformed intomerely connecting them with relations.A relational approach is probably more di�cult
to design than a re�nement one (that we can pro-gram now with existing tools), but would surelybring important bene�ts for code organization.As a side note, it might well be possible to use
6
this approach with the previous one. The formerapproach could be an especially easy way to imple-ment aspects able to survive weaving and providingrun-time adaptations as suggested in [MJV+97].
4.3 Example sketch
In parallel object-oriented languages, guards aregood instances of aspects. They can either be im-plemented as an usual extension for active objectlanguages (possibly using re exive techniques); orguards in themselves can be a program describingthe synchronization of all components of the sys-tem, separately from the program, in relation withobjects decomposition (for a more concrete exam-ple, have a look at [LK97]).Many kinds of guards can be described: the term
essentially speci�es the protection of a routine bysome test, but it is possible to specify that restric-tions be incrementally added (e.g. [Fro92]) or tode�ne guards conditions exclusively expressed onsynchronizations variables, etc.De�ning an aspect language for each of these
di�erent guards is possible but clearly restrictive.Moreover it is not informative as to what are thepossibilities for implementing guards. On the con-trary, it is rather natural to construct more ba-sic modules for describing all possible guard lan-guages, like for instance:
- methods listing, de�ning how to relate somepiece of code with any method;
- synchronization variables, providing a declar-ative framework for de�ning synchronizationvariables;
- condition restriction, de�ning how to checkthat conditions are increasingly strengthened;
- etc.
These modules correspond to di�erent choicesof implementation for guards, but they cannot becombined in an arbitrary manner; they are alsomore general than a direct implementation of aspeci�c type of guard since no commitment to acomplete combination of their di�erent features isdone by default. A guard aspect would providea language for associating the e�ective service ofa method request with conditions: such an aspectlanguage could, among other possible solutions, de-pend on modules like method listing and synchro-
nization variable.Fig. 5 represents a possible con�guration where
we would de�ne the synchronization variables based
guard with a parameter concerning the method itcontrols. A relation would be de�ned to express
that the aspect language has to take the method
listing plugin's output and use it to replace theparameter in the guard plugin: for every methodlisted, a new guard would be produced (in the ab-sence of a speci�cation, the default behavior beingto preserve the method service untouched). Theinput and output arrows do not have the samemeaning as the other ones, since they in fact repre-sent �les that are used as input/ouput by run-timecomponents (run-time meaning weaver run-time,not �nal program run-time).The usefulness of a relational model depends
probably on what relations are expressible and easyto understand at the same time (and on what kindis not).
5 Visualization and docu-
mentation issues
An important purpose of modularizing the weaverdescription is to be able to represent and documentaspects interactions. Using diagrams and provid-ing a visual interface for assembling them into aweaver is important in this respect.Many examples (e.g. JavaBeans for components
assembly and event dispatch description, KLIEG[STST97] for describing behavioural patterns, ...)show the interest of visual environments for com-ponent assembly. In an aspect-oriented approach,visual tools could be developped for programmingaspects (user-oriented) or for coordinating aspectdescriptions in the weaver (for advanced users andfor user documentation).In relation with the study of relations, we intend
to provide an environment for composing systemmixins with a graphical interface close to Fig. 5.For instance, in EPP, instead of writing the pluginsetup by hand, the user would be able to graphi-cally build it as a graph of precendence relationsbetween plugins.Is a graphical description really enough if we
want to deal with libraries of elementary compo-nents for aspect description (especially, what aboutthe size of such libraries) ?Textual documentation is a very important part
of software. Can documentation or speci�cation(think of assertions for instance) be consideredas aspects ? For instance, literate programming[Knu92] relies on separate de�nition of documen-tation through a kind of anchoring technique whichallows to write pseudo-code and to reference otherparts of a \program". Its intent is however no-tably di�erent from AOP, since it is presented as
7
Figure 5: Synchronization variable based guard: relational graph of plugins composition
\the combination of documentation and source to-gether in a fashion suited for reading by humanbeings", but should there be a special organiza-tion for aspects or aspect-weaving documentation? How to document aspects, and more speci�callythe integration of aspects ?
To be able to use an aspect correctly, it shouldbe available with lots of informations. The weaverpart may need a documentation close to that ofpatterns (which seem to share many similarities)while an aspect could sometimes be documentedby a formal model.
6 Conclusion
We described the extensible pre-processor kit EPP,a generic extensible preprocessor for Java, and itsmodule description language Ld-2 which providesan aspect-oriented construct: system mixins. EPPis extensible through plugin modules written in Ld-2; among other things, these plugins can introducenew grammar rules in the original language.
We have already used EPP for writing severallanguage extensions and think that aspect weavingimplementations could be treated as preprocessingextension composition issues. Part of our designphilosophy is: developing a tool simple enough forbeing used by the average programmer yet unre-strictive enough to be extended in many ways.
We are currently working on the extension of sys-tem mixin composition capabilities and the possi-bility of a visual support environment for compos-ing them. We suggested that aspect descriptionsbe composed to form a weaver from system-widemixin building blocks and described two major ap-proaches to their composition: a re�nement-based
process or a relational design.We plan to experiment with our environment
(especially the second approach), especially to testthe interest of the graphical tool for reuse. Weexpect from these experiments a better insighton common characteristics of aspects which mighthelp design speci�c mixins and relations, maybefor adressing speci�c families of problems.
References
[ASU87] A.V. Aho, R. Sethi, and J.D. Ullmann.Compilers: Principles, Techniques andTools. Addison-Wesley Publishing com-pany, 1987.
[B+94] F. Bodin et al. Sage++: A Class Libraryfor Building Fortran and C++ Restructur-ing Tools. In Proc. of Object-Oriented Nu-merics Confs., Oregon, April 1994.
[BC90] G. Brachaand W. Cook. Mixin-based Inheritance. InProc. of ECOOP/OOPSLA'90, 1990.
[C+97] D. Caromel et al. Europa Paral-lel C++ version 2.1. In Future Di-rections for Parallel C++, June 1997.http://www.dcs.kcl.ac.uk/Future Directions/.
[Chi95] S. Chiba. A Metaobject Protocol forC++. In Proceedings of OOPSLA'95, vol-ume 30(10) of ACM Sigplan Notices, pages285{299, Austin, Texas, October 1995.ACM Press.
[Fro92] Svend Frolund. Inheritance of synchro-nization constraints in concurrent object-oriented programming languages. InO. Lehrmann Madsen, editor, Proceedingsof the ECOOP'92, volume 615 of LectureNotes in Computer Science, pages 185{196,
8
Utrecht, the Netherlands, July 1992. Euro-pean Conference on Object-Oriented Pro-gramming, Springer-Verlag.
[GHJV93] Erich Gamma, Richard Helm, Ralph John-son, and John Vlissides. Design patterns:Abstraction and reuse in object-orienteddesigns. In O. Nierstrasz, editor, Proceed-ings of ECOOP'93, Berlin, 1993. Springer-Verlag.
[GJG96] J. Gosling, B. Joy, and Steele. G. The JavaLanguage Speci�cation. Java Series. SunMicrosystems, 1996.
[IHT+96] Yuuji ICHISUGI, Satoshi HIRANO, Hi-toshi TANUMA, Kuniyasu SUZAKI, andMichiharu TSUKAMOTO. Compiler Wid-gets | Reusable and Extensible Parts ofLanguage System | (in Japanese). In The11th workshop of object oriented computingWOOC'96, Japan Society of Software Sci-ence and Technology, March 1996.
[IR97] Yuuji Ichisugi and Yves Roudier. The ex-tensible java preprocessor kit and a tinydata-parallel java. In Yutaka Ishikawa,Rodney R. Oldehoeft, John V. W. Reyn-ders, and Marydell Tholburn, editors, pro-ceedings of ISCOPE'97 (International Sci-enti�c Computing in Object-Oriented Par-allel Environments Conference), December8 - 11, 1997, Marina del Rey, California,USA., number 1343 in LNCS, pages 153{160. Springer-Verlag, 1997.
[Ish94] Y. Ishikawa. Meta-level Architecture forExtendable C++, Draft Document. Tech-nical Report Technical Report TR-94024,Real World Computing Partnership, 1994.
[KC97] Norman L. Kerth and Ward Cunningham.Using patterns to improve our architecturalvision. IEEE Software, pages 53{59, Jan-uary/February 1997.
[KdRB91] Gregor Kiczales, Jim des Rivi�eres, and DanBobrow. The Art of the Meta Object Pro-tocol. MIT Press, 1991.
[KK97] A. Kumeta and M. Komuro. Meta-Programming Framework for Java. In The12th workshop of object oriented computingWOOC'97, Japan Society of Software Sci-ence and Technology, March 1997.
[Knu92] Donald E. Knuth. Literate Programming.Technical report, Stanford University Cen-ter for the Study of Languages and Infor-mation, Leland Stanford Junior University,1992.
[LK97] Cristina Videira Lopes and Gregor Kicza-les. D: A Language Framework for Dis-tributed Programming. Technical ReportSPL97-010 P9710047, Xerox PARC, Febru-ary 97.
[MJV+97] Frank Matthijs, Wouter Joosen, Bart Van-haute, Bert Robben, and Pierre Verbaeten.Aspects should not die. In ECOOP'97workshop on aspect-oriented programming,1997.
[RI97a] Yves Roudier and Yuuji Ichisugi. Integrat-ing data-parallel and reactive constructsinto java. In proceedings of the 2nd France-Japan Workshop on Object-Based Paralleland Distributed Computing (OBPDC'97),Toulouse, France, October 1997.
[RI97b] Yves Roudier and Yuuji Ichisugi. Javadata-parallel programming using an ex-tensible preprocessor. In proceedings ofSWOPP'97 (Summer united WOrkshopson Parallel, distributed and cooperativeProcessing), Kumamoto, Japan, pages 85{90, June 1997.
[Ste90] G.L. Steele. Common Lisp the Language,2nd edition. Digital Press, 1990.
[STST97] Etsuya Shibayama, Masashi Toyoda, Bun-tarou Shizuki, and Shin Takahashi. Vi-sual Abstractions for Object-Based Par-allel Computing. In proceedings of the2nd France-Japan Workshop on Object-Based Parallel and Distributed Computing(OBPDC'97), Toulouse, France, October1997.
9
1
Extending Aspect-Oriented-Programming In Order ToFlexibly Support Workflows
R. Schmidt, U. Assmann,Forschungszentrum Informatik (FZI) and Universität Karlsruhe
The problemAspect-Oriented Programming [KILL97], [Kicz97] has been used to introduce a new unit of modularity forthe systemic, non-functional concerns of applications such as error-handling, synchronization, etc. Theaspect decompositions of the problem domain have been identified as being of importance [Berg97], buthave not been further developed yet. Furthermore, although aspect-oriented-programming separates thedesign, specification and implementation of different aspects, it still follows the classical software designcycle. Therefore it is not possible to change an implementation without running through the complete designcycle. Frequent changes to implementations are necessary in many application domains, such as workflowprocessing.
Workflows are an important means for supporting process-based cooperations such as business processes,software development etc. They are formally defined by a workflow model which can be separated into so-called workflow-aspects, representing discrete modelling domains [Jabl95]. One important workflow aspectis the functional aspect, describing the workflow’s decomposition into sub-workflows. It should not beconfused with the functional aspect in Aspect-Oriented Programming. Other aspects are the control aspect,responsible for directing the execution of workflows, the data aspect, covering the data exchange betweensub-workflows, the operational aspect, describing the operations performed in the sub-workflows; and theorganizational aspect, representing the relationship to the organizational structure of the enterprise. Theseaspects are necessary to execute a workflow and are called imperative aspects. There are also workflowaspects, whose specification is not necessary to execute the workflow, but increase the quality of it’sexecution. These workflow aspects are called optional aspects. One example is the persistence aspect,covering the persistence of workflow data.
The development of software architectures for supporting workflows is driven by the requirement to flexiblyadapt to workflow changes. Since business processes often have to be changed due to market requirements,the workflows implementing the business processes have to be changed, also. Traditional softwaredevelopment, and even object-oriented methods have failed to fulfill this requirement. Using this “direct”approach, the workflow aspects are not dealt with separately, but tangled in the implementation. If, forexample, the control flow in an workflow has to be adapted, all participating objects have to be changed,because the control flow is embedded in each of them. To overcome the deficiencies of the directimplementation, workflow-management-systems (wfms) [Jabl95] have been developed. They allow thedefinition, execution and monitoring of workflows with both human and machine-based actors. Basically,wfms represent a virtual machine. A formal model of the workflow is interpreted, executed and supervisedby a so-called workflow-engine. The virtual machine approach allows the easy adaption of workflowchanges by changing the workflow model represented in the wfms. This is possible, because the differentaspects of the workflow are not firmly connected through the virtual machine. For example, because thecontrol aspect is kept separate from the single workflow operations, it is possible to rearrange flexibly thesingle workflow operations to reflect workflow changes. However, the flexibility gained by interpreting theworkflow is paid for dearly in the form or reduced performance which is further diminished by thecentralized workflow engine, which hampers the enterprise-wide use of wfms.
Many approaches to create new wfms-architectures try to circumvent these deficiencies. Some try to applynew processing models, such as an event-based one, or they attempt to go way back to the directimplementation, to achieve higher performance. Event-based support for workflows has already beenproposed by [ChRa90]. According to this approach, workflows are transformed into event-dependencies.
2
Although this approach seems promising, one has to realize, that the problem of distributing workflowexecution has not been solved by replacing it by the problem of distributed processing of eventdependencies.
An approach which reverts back to direct workflow support is Meteor2 [DKMS96]. Meteor2 avoids centralbottlenecks by distributing the processing of workflows to task-managers which supervise the execution ofthe parts of the workflow called tasks. Task-managers are activated by their predecessor task managers andactivate consecutive task-managers upon the fulfillment of certain conditions. Task-managers are created by“compiling” the task’s definition. Therefore, in order to adapt to workflow changes, old task managers haveto be replaced by new ones, reflecting the changes. This approach creates a number of problems. First,generating a new version of the task-manager requires completely running through the software developmentprocess. Second, exchanging the task-managers means a great amount of effort, especially if this has to bedone system that is running. It is questionable, whether or not all task-managers can be replaced at once,therefore mechanisms are required which enable the coexistence of old and new versions. Third, changeshave to be coordinated, for example, if task-managers participate in different workflows. In summary, if onereverts to direct workflow support, more and more of the deficiencies of this approach appear.
Therefore, designing architectures for workflow support creates a dilemma. Approaches based on virtualmachines are flexible in adapting to workflow changes, but suffer in terms of performance. Architectures thatdirectly implement workflows offer good performance, but are inflexible in adapting to workflow changes.Existing approaches fall in-between the two extremes when trying to find a solution, but never identifyingthe main reason for the dilemma, which is the fact that the aspects in the “direct” workflow implementationare tangled togehter making it impossible to treat them separately.
PositionOur thesis is, that combining Aspect-Oriented Programming and the decomposition of workflows intodifferent workflow aspects allows an escape from this dilemma. However, in order to fully solve the problemof flexibly and effectively supporting workflows, Aspect-Oriented Programming has to be extended withideas found in component-based technologies such as JavaBeans [Beans] or ActiveX/DCOM [Chap96]. Ourvision is to fuse Aspect-Oriented Programming and component-oriented systems by paying special attentionto domain-specific aspect-oriented models, such as workflow models, in order to obtain the best of bothworlds.
Figure 1: Workflow-support through aspect-oriented-programming
Aspect weaver
Aspect implementations
Workflow application
Aspect specifications
Workflow model
3
A first step towards realizing this vision is made by viewing the decomposition of workflows into workflowaspects, as an decomposition of the problem domain into different aspects, as proposed by [Berg97]. Startingwith the workflow model, the aspect specifications are made. The aspect specifications are the basis for theimplementation aspect implementations. These implementations, which still are not compiled, are combinedby the aspect weaver to an workflow application. It is important to note that in the workflow application, theaspects are no longer dealt with separatly.
Supporting workflows in this way, allows one to benefit from the many advantages of Aspect-OrientedProgramming. Workflow changes can be adopted much easier, because the aspects are dealt with separately.However, the whole software development cycle still has to be run through, because it is not possible toexchange parts of the workflow application, to represent changes in the workflow. Aspect-OrientedProgramming maintains the separation of aspects until the aspect-weaver combines the different aspectimplementations. However, in the workflow application the aspects are tangled together again.
The exchange or modification of aspect implementations in workflow applications is possible with themechanisms found in component-based frameworks such as Enterprise JavaBeans [Beans] orActiveX/DCOM [Chap96]. The term “component” used in this context should not be confused with thecomponents and connectors found in architecture definition languages [Medv97]. Component-basedframeworks aim at enabling the cooperation of independently developed software-units, called components,even across computer and network boundaries. Furthermore, they want to enable the independent evolutionof components. Architecture definition languages [Med97] and architectural styles are description modelsand aim at the structural description of software systems. They try to give a more abstract view of softwaresystems than object-oriented methods do, for example, [GaSh93] and allow analyses with broader view. Thescope of component-based frameworks is the single component, whereas architecture definition languagestake the whole system into consideration.
Two concepts in component-based frameworks can be used to exchange aspect-implementations even in theapplication: The first concept is that of strong interfaces that completely hide the implementation and theimplementation model of the aspect from other aspects (In ActiveX/DCOM for example, interfaces aredefined at the binary level, although more comfortable language adaptations exist). Therefore, one aspectimplementation can be replaced by another one, as long as the same interface is supported. The secondconcept is implicit interface invocation. In a component-based framework, the component supporting aninterface is never directly addressed. This would imply that the user of the component has to know theidentity and the location of a component. Therefore, the user of a component only specifies the interfacerequired and the component-based framework returns a reference to a component providing the interface.This reference may be a component but also an representative, such as a proxy. The user of the componentdoes not see any difference. The information about the interfaces and the location of a componentimplements is stored in a registry or repository and not in the components themselves. An application builtfrom aspects implemented as components differs from applications built with Aspect-OrientedProgramming. The aspects implemented as components do not address one another directly, but address eachother using the indirection mechanisms described above. Therefore, it is possible to exchange aspectimplementations flexibly and even to relocate them to another computer using implicit invocation. Thecomponents composing the application, may not form a single executable, but can be distributed acrossdifferent computers.
4
Figure 2: Component-based Aspect-weaving
Extending Aspect-Oriented Programming with the concepts of component-based frameworks changesAspect-Oriented Programming in the following manner (see Figure 2). The different aspects of theapplications are not directly combined by the aspect-weaver, but are first compiled into aspect-specificcomponents, containing the implementation of only one aspect. Then the aspect-specific-components arecombined with an so-called component-weaver. Also pre-fabricated components can be used, which areselected using the aspect specification. The use of pre-fabricated components makes it necessary, forweaving information to be provided for the component-weaver, because these components are generic andcontain no information about how to connect with the other components. Finally, the component-weavercreates an implementation consisting of the aspect-specific components, glued together as made possible bycomponent-based frameworks. Therefore, components can easily be replaced to reflect aspect changes.
Central to this concept is the component-weaver, which has to work differently from the aspect weaverbecause components do not allow access to their implementations details, such as their source code. Thecomponent-weaver uses two mechanisms: Introspection allows one to gain knowledge about thecomponent’s interfaces without knowing its implementation. For example, Java Beans provides twomechanisms for introspection, reflection and the BeanInfo class. Reflection allows to know about all methodsof a component without further programming. The BeanInfo class gives complex information about a Beancomponent, but has to be implemented explicitly. Specialization allows a component to be changed withoutaccess to its implementation. Specialization in Java Beans is supported by property sheets and customizers.Property sheets offer a simple specialization mechanism which sets the parameters of the Bean. Complexspecializations can be done by customizers. Both introspection and specialization are used by the componentweaver to combine the aspect implementations. The introspection mechanisms give the component weaverinformation about the connection points of the component, that means, how other componentimplementations can be connected to the component. The specialization mechanisms are used to connect onecomponent to another component.
Component weaver
Components
Implementation
Component-based framework
Easy exchange of aspect implementations
Pre-fabricated Components
Aspect- implementation
Aspect- specification
Weaving information
selection
5
Combining the beneficial portions of other approaches results in our overall approach which extends Aspect-Oriented Programming. It is illustrated in Figure 3). The different workflow-aspects from the workflowmodel are implemented as components which contain introspection and specialization mechanisms, allowingthem to be used with a component weaver. Not all aspects have to be implemented from scratch, becausegeneric workflow functionality may also be introduced by adding pre-fabricated components. They may beselected from a component repository or even a component market, using the specification of the workflowmodel. The aspect-specific components are put into the component-weaver, which combines them into acomponent-based workflow application. Therefore, components can even be replaced in the implementationwithout running through the whole edit-compile cycle, as would be necessary in standard Aspect-OrientedProgramming. If, for example, the control flow of the workflow changes, one or several componentsreflecting these changes may be introduced into the application.
Figure 3: Using Component-weaving for workflow support
At first glance the architecture presented here offers the distributed, non-interpretative processing ofworkflows. It provides an escape from the dilemma of workflow architecture because it combines theperformance of the direct workflow support with the flexibility of the virtual machine approach. There is nocentralized interpretation of a workflow model and workflow changes can be easily integrated by exchangingcomponents.
Under closer scrutiny, the architecture demonstrates that aspect decompositions of the problem domain are avaluable extension of Aspect-Oriented Programming. Through the aspect decomposition of the problemdomain, additional aspects can be separated, which were tangled before. Furthermore, the domain presentedhere, workflow support, shows that there is a need to introduce mechanism for system evolution into Aspect-Oriented Programming, because the flexible support of changes is necessary to effectively supportapplications in many domains, not only in workflow support. However, this is only possible, if the separationof aspects is maintained, not only in the implementation phase, but also in the applications.
Not only Aspect-Oriented Programming can profit from the extensions presented in this paper. Aspect-Oriented Programming can give valuable hints about how to organize applications in modern component-based frameworks such as ActiveX/DCOM or JavaBeans, which are playing an increasingly important rolein application development. Application development for component-oriented systems should start with anaspect-separated domain model, such as an workflow model. Ideally components should only implement
Component weaver
Components
Workflow Application
Pre-fabricated Components
Aspect- implementation
Workflow Aspect-specification
Weaving information
selection
Workflow model
6
functionality belonging to one aspect of an application, and applications should be composed of aspect-separated components. By applying the concept of Aspect-Oriented Programming, there is a much betterchance that components become truly reusable, because they only have to fulfill the requirements of oneaspect and not the requirements of several aspects. Component-oriented systems built in an aspect-separatedmanner can then be expected to become more flexible, because changes which concern only one aspect, willonly influence the implementations of one aspect.
References[AAAM97] G. Alonso, D. Agrawal, A. El Abbadi, C. Mohan: Functionality and Limitations of Current
Workflow Management Systems. To appear in IEEE Expert (Special Issue on CooperativeInformation Systems), 1997.
[AsSc97] U. Aßmann, R. Schmidt: Towards a Model For Composed Extensible Components. WorkshopFoundations of Component-Based Systems, Proceedings, Zurich, SwitzerlandSeptember 26, 1997
[Berg97] L. Bergmans: Aspects of AOP: Scalability and application to domain modelling. TRESE project,University of Twente & STEX. http://www.parc.xerox.com/spl/projects/aop/aop-meeting-pps/bergmans.html
[Beans] Javasoft: Java Beans Specification 1.0 A. http://splash.javasoft.com/beans/-beans.100A.pdf[Chap96] D. Chappell: Understanding ActiveX and OLE. Microsoft Press. Redmond 1996[ChRa90] P.K. Chrysanthis, K. Ramamritham: ACTA: A Framework for Specifying and Reasoning about
Transaction Structure and Behaviour, Proc. ACM SIGMOD International Conference on theManagement of Data, Atlantic City, NJ, S. 194-203, Mai 1990
[CiSc96] O. Ciupke, R. Schmidt: Components As Context-Independent Units of Software. WCOP 96,Linz 1996. Special Issues in Object-Oriented Programming. Workshop Reader of the 10th
European Conference on Object-Oriented Programming ECOOP96. Dpunkt.verlag, Verlag1996
[GaSh93] D. Garlan, M. Shaw. An Introduction to Software Architecture: Advances in SoftwareEngineering and Knowledge Engineering, volume I. World Scientific Publishing, 1993
[GeHS95] D. Georgakopoulos, M. Hornick, A. Sheth: An Overview of Workflow Management: FromProcess Modelling to Workflow Automation Infrastructure. In Distributed and ParallelDatabases, Kluwer Academic Publishers, September 1995.
[Jabl95] Jablonski, S.: Workflow-Management-Systeme. International Thomson Computer Press. Bonn1995
[Kicz96] G. Kiczales: Aspect-oriented programming. ACM Computing Surveys, 28(4), Dec. 1996.[KILL97] G. Kiczales, J. Irwin, J. Lamping, J.M. Loingtier, C. V. Lopes, C. Maeda, a. Mendhekar: Aspect-
Oriented Programming. Position Paper from the Xerox Parc Aspect-Oriented ProgrammingProject.
[LoWa95] P.C. Lockemann, H. D. Walter: Object-Oriented Protocol Hierarchies for Distributed WorkflowSystems. In [PaTo95].
[Medv97] N. Medvidovic. A Classification and Comparision Framework for Software ArchitectureDespcription Languages. Technical Report. UCI-ICS-97-02, University of Californica, Irvine,January 1997
[PaTo95] R. Pareschi, M. Tokoro: TAPOS Theory And Practice of Object Systems. John Wiley, New York.Volume 1(1) SPECIAL ISSUE: 1995 European Conference of Object Oriented Programming
[Schm97] R. Schmidt: Component-based systems, composite applications and workflow-management.Workshop Foundations of Component-Based Systems, Proceedings, Zurich, SwitzerlandSeptember 26, 1997
Assessing Aspect-Oriented Programming and Design
Robert J. Walker, Elisa L. A. Baniassad, Gail C. Murphywalker, bani, murphy @cs.ubc.ca
Department of Computer ScienceUniversity of British Columbia
Vancouver, BC V6T 1Z4
March 6, 1998
Abstract
Aspect-oriented programming is a new software design andimplementation technique proposed by researchers at XeroxPARC. This project is assessing the claims of aspect-orientedprogramming to improve the software development cycle forparticular kinds of applications. The project is divided intothree experiments, the first of which has been completed.These experiments have been designed to investigate, sepa-rately, such characteristics of aspect-oriented development asthe creation of new aspect-oriented programs and ease of de-bugging aspect-oriented programs.
1 Introduction
Two of the most important and most difficult questions one canask about a new design or programming approach are whetherthe approach is useful and whether the approach is usable.One way to evaluate these questions is to make the design orprogramming approach immediately accessible to the greatercommunity and to simply see whether the approach sinks orswims. Although ultimately the goal is to positively affect thegreater community through the adoption of the approach, thisstrategy has many pitfalls: useful techniques that are not quiteusable can be lost, and usable techniques that are not partic-ularly useful can mask the adoption of other, perhaps morepowerful, techniques. Aspect-oriented programming is a newsoftware design and implementation technique proposed by re-searchers at Xerox PARC[2].
This technique is in its infancy. The aspect-oriented ap-proach claims to make it easier to reason about, develop andmaintain certain kinds of application code while maintaininghighly efficient code. To better understand the usefulness andusability of the aspect-oriented approach, we are currently con-ducting three experiments. These experiments are designed
Submission to 1998 International Workshop on Software Engineering
to investigate such characteristics of aspect-oriented develop-ment as the creation and ease of debugging programs built withaspect-oriented design and programming. The experiments in-vestigate aspect-oriented design and programming as repre-sented in AspectJ , an aspect-oriented variant of Java devel-oped at Xerox PARC.
In conducting software engineering experiments, we areconstrained by four factors: the pool of potential participantsavailable to us is very small, the amount of time each partic-ipant can devote to an experiment is very short, especially incomparison to typical development times of even tiny applica-tions, the cost of running and analyzing experiments is high,and since the evaluation of an aspect-oriented approach is com-plex, some precision of measurement needs to be forfeited in fa-vor of realism[3]. As a result, our “experiments” were set up assemi-controlled empirical studies rather than statistically validexperiments.
This report describes the results of a pilot study and the firstexperiment. The pre-study was used to test our experimentdesign in the context of investigating whether aspect-orientedprogramming eases the creation of correct program. The firstexperiment studied the ease of debugging such a program. Thetwo experiments which have yet to begin are designed to inves-tigate the ease of change of an existing program and the ease ofdesign and implementation of a new program.
2 Pilot Study
Before designing our set of experiments, it was necessary tounderstand how difficult a problem we could realistically aska participant to tackle in a period of no more than four hours.We also used this pilot study to determine better methods oftraining and questioning our participants.
The experimental question approached in the pilot study was
AspectJ is a trademark of Xerox Corporation.Java is a registered trademark of Sun Microsystems.
1
whether, in the context of AspectJ, the combination of JCorefor component programming and COOL as a synchroniza-tion aspect language eases the creation of multi-threaded pro-grams compared to programming in the Java object-orientedlanguage.
The basis of this experiment was to select a small program-ming problem with concurrency, and then have several Java-knowledgeable programmers attempt to produce a solution tothe problem, some working in Java, others in AspectJ. Since wewere working within a small community from which to drawparticipants we ranked the participants and chose the least qual-ified for this pilot study. We held the following questions inmind while watching and annotating the video-tapes of the ses-sions:
Can programmers working with an aspect-oriented lan-guage produce a “correct” program in less time than pro-grammers working with an object-oriented language?
Do programs produced with an aspect-oriented program-ming language have fewer bugs than programs createdwith an object-oriented programming language?
2.1 Format
A pilot study session proceeded in stages. First, we requiredthat the experimental participant review materials on concur-rent programming. If the participant was to use AspectJ, theexperimenter would introduce the concepts of aspect-orientedprogramming and provide the participant with an opportunityto become familiar with AspectJ; otherwise, they were givenmaterial describing Java synchronization usage [1]. Partic-ipants using AspectJ were required to examine an examplepiece of code to ensure that they were familiar with the syntaxof the language. Finally, the participants were told the problem,provided a programming environment, were given 1.5 hoursto complete the assigned task, and were asked to think aloudwhile we video-taped their progress. Twice during each ses-sion, the invigilator asked the participant a set of questions.
The programming problem chosen for the experiment was asimple version of a non-audio karaoke machine in which textat the bottom of a small window scrolls from right to left and aball bounces straight up and down above the text. The problemwas to synchronize the ball and the text such that the ball wouldbounce on the start of each word. The text or the ball couldbe paused to permit this to happen. The participants were pro-vided with a skeleton program from which to begin that con-tained the basic functionality to make the ball bounce and thetext scroll.
Six participants took part in the experiment, three used Javato program their solution and three were given AspectJ.
Correct here is used to mean a program that meets the specification givenfor the program.
2.2 Results
None of the six participants in the experiment were able to pro-duce a solution to the programming problem in the time pro-vided, although two came close (one Java, one AspectJ). Weanalyzed this pilot study to learn how to conduct subsequentstudies; for this reason we did not go to great lengths to guar-antee the abilities of our participants. In addition, the difficultyof the task was greater than we had expected: aside from the ba-sic point of encoding the necessary synchronization, the meansfor completing the non-synchronized aspects of the program,the semantics of the problem domain, and the functionality ofthe existing code (written by someone else) needed to be un-derstood first. One and a half hours was unreasonably short.
The following lessons are among those we were able to takeaway from this pilot study:
Participant training with and set-up of the programmingenvironment is necessary. It is impossible to test useful-ness when usability is at a minimum. To address this, wemodified our experiment design by ensuring that all par-ticipants were given a thorough lesson on how to use theenvironment.
All participants must be given lengthy exposure to thesynchronization mechanisms provided by the languagethey are given to use. After this exposure they should betested to ensure they know the information necessary toperform the experiment task. Subtle differences in syn-chronization constructs can be a great hindrance to some-one attempting to use a language in which they have notfrequently programmed synchronization, even if they areotherwise familiar with synchronization concepts. In thefirst experiment we ensured that all participants spent thesame amount of time reading the synchronization docu-mentation, and asked them to describe the basic conceptsnecessary for completion of the experiment task.
An interesting observation was that, among the participants,only the two near-successful ones pursued a course of actionexpressing a separation of concerns: get the code to work with-out synchronization first, then add the synchronization.
2.3 Participants’ Comments
In general the participants that used AspectJ liked the methodeven though they were unable to complete the problem. Weasked each of the AspectJ participants if they had any com-ments about aspect-oriented programming in general.
“Well, [it was] just the way I imagined that [aspect-oriented programming] would be used in a specificprogram. I thought it was really cool, because I could
2
concentrate on what I was doing now, on the func-tionality that it would have by itself, as opposed tohow to synch it up with the other object.”
“Ultimately, I guess the idea is that the objects couldbe separated so you could change how the coordi-nation was done without messing with the objects.I always like that, changing one little thing withouttouching what’s going on in the other place. It has areally elegant nature to it.”
2.4 Pilot Study Critique
Problems involving concurrency are hard to solve. One inter-pretation of the results of this experiment is that the supportfor concurrency in AspectJ did not ease the difficulty of theprogramming problem sufficiently such that it could be solvedwith the aspect-oriented approach when it could not be solvedwith the object-oriented (Java) approach. This result is not sur-prising in that aspect-oriented programming is meant to easethe expression of the solution to the problem rather than to nec-essarily help the software engineer design the solution. Fromthe participants comments, it appears that many of them haddifficulty framing an appropriate solution in the time available.
The participant who made the most progress on the problemwas a participant using the aspect-oriented approach. Only afew small changes were necessary to the coordinator code pro-duced by this participant to produce a solution to the problem:the changes were all of the same nature — an attempt to coor-dinate on objects rather than classes.
Running Time
The participants were given 1.5 hours to program a solution tothe given problem. Given that no participant was able to solvethe problem, it is clear that either the problem was too com-plex, or insufficient time was provided to the participants. Wehad thought that 1.5 hours to solve the problem from a givencode base would be reasonable given that the initial solutionwas coded, from scratch, in just over 2 hours; however, this didnot include the many hours spent discussing the semantics ofthe karaoke machine synchronization during the design of thepilot study.
This problem could be mitigated in two ways. First, addi-tional dry-runs could be held to try and gauge if the experimen-tal running time is reasonable. Second, the experimental pro-cedure could have called for giving participants as much timeas they needed up to some (reasonably) large maximum such as3 hours. However, given that only two of the six participantswere pursuing approaches likely to be successful, it is unclearthat additional time alone would necessarily lead to more con-sistent (and interpretable) results. Alternatively, a more stan-dard problem based on readers and writers might have been
chosen. One advantage of choosing a non-standard problemlike karaoke was that the participants could not simply providea ’textbook’ solution.
Code Skeleton
To focus the participants’ efforts on concurrency we providedthem with a code skeleton from which to start programming.This code skeleton lacked any synchronization and also lackedsome of the functionality necessary so as to allow the partici-pant some flexibility in pursuing a solution. In retrospect it isclear we did not provide a sufficient overview of the existingcode or sufficient time for the participant to review the codeand ask questions. A specific period of time for review andquestions might have mitigated problems arising from a lackof understanding of the given code skeleton.
Participant Selection
Since this was seen as a pilot study and we had a limited num-ber of potential participants we put the programmers with lessexperience in this study. All participants were asked prior toselection whether they were familiar with the concepts of con-currency and Java; however, since the aim of this pilot studywas mainly to gain experiment design information, stress wasnot placed on the screening of participants. We relied on in-terviewing and questioning of the participants on these topicsrather than on a specific pre-test.
More than one participant also spent a significant amount ofthe experiment time trying to understand syntax errors, bothfrom Java and AspectJ. The latter have since been clarified viaimprovements in the AspectJ weaver.
3 Experiment 1: Ease of Debugging
The intent of this experiment was to learn whether the separa-tion of concerns provided in aspect-oriented programming en-hanced users ability to find and fix functionality errors (bugs)present in a multi-threaded program. In terms of AspectJ, thequestion was whether the combination of JCore for the compo-nent programming and COOL as a synchronization aspect lan-guage eased the debugging of multi-threaded programs, com-pared to the ability to debug the same program written in Java.
A 600 line, multi-threaded, program was created, andthree synchronization bugs were introduced. Then, pairs ofprogrammers, knowledgeable in multi-threaded programmingtechniques and object-oriented programming, attempted to fixthe three bugs. Three of the pairs worked with AspectJ, threewith Java. The solutions to the program were compared in thefollowing ways:
3
Can programmers working with an aspect-oriented pro-gramming language debug a multi-threaded program inless time than programmers working in an object-orientedlanguage?
Are programmers debugging an aspect-oriented program-ming language able to more quickly and easily identifythe cause of a bug in a multi-threaded program than in onewritten in an object-oriented language?
3.1 Format
The program provided to the participants was a simple digitallibrary consisting of 6 classes, 3 of which required coordina-tion. The library had two main actors: readers and libraries.The readers would make requests to libraries for a particularbook. Libraries would search within their internal repositoriesfor the book, and also ask remote libraries to do the same. Eachreader could query one library, and each library could directlyquery at least one other. Three synchronization bugs were in-serted into the code.
The participants worked in pairs . In each pair, one partici-pant had control of the computer with the programming prob-lem, and the other had access to a report describing the symp-toms of the bugs, and on-line documentation. They were thenasked to fix each bug in turn,
The bugs were cascading, meaning that the symptoms of thefirst hid the symptoms of the second, and the second hid thoseof the third. In the first bug only one reader would make a re-quest and then they system would halt. The participants had toremove a per-class self-exclusive coordination on the run()method of theReader class so that more than one reader couldrun. In the second problem, two readers would make requestsand then the system would deadlock. The participants were re-quired to determine that the deadlock occurred when two li-braries each tried to do a remote-search on the other at the sametime. They then had to remove a per-object self-exclusive coor-dination on the remoteSearch() method of the Libraryclass so that the system would no longer deadlock. The thirdbug was that more than one reader was able to check out thesame book from the same library. For this problem, the partici-pants had to add a per-object self-exclusive coordination on thecheckOut()method of the Library class so that only onereader could check out a book at a particular library at a time.
To compare Java with AspectJ, a pair of synchronizationlock classes were built which were identical in functionalitywith the woven output from AspectJ source code. This allowedthe true aspect-oriented properties of COOL, as opposed toits library-like functionality, to be compared with non-aspect-oriented Java code.
Participants were graduate students in computer science, and an under-graduate in computer engineering.
The experiment consisted of six pairs of participants, threeworked with Java and the others with AspectJ. All of the pairswere given time to train to familiarize themselves with the lan-guages they were to be using; 1.5 hours were allowed each pairto code their solution. Each of the pairs were to be asked for re-ports of their progress either after they had coded each of thesolutions, or at 1/2 hour intervals, whichever came first.
3.2 Results
In each the AspectJ and Java groups, all of the pairs of partic-ipants were able to find and correct all three of the bugs. Weexamined the performance of the pairs by comparing the timeit took them to fix each of the bugs, how many times they builtand ran the program, how many times they examined the se-mantics of the core functionality of the program, if they mixedsynchronization and core functionality issues, if they searchedfor a synchronization solution by modifying the core function-ality, and also the number of times the pairs changed the filethey were examining while reaching their solution. We firstdiscuss each data element in isolation, and then correlate andsummarize the results.
Time
The completion times for each of the three bugs are shownin Figure 1. The largest difference in completion times waswith respect to the first bug; the AspectJ teams clearly repairedthe bug faster than the Java ones. For the second and thirdbugs, there was a smaller difference. When examining thetime information in isolation we are unable to draw any def-inite conclusions. The quicker AspectJ time in the first bugcould be attributed to any number of factors, and could implythat COOL is an easier language to quickly understand, or thatthe bug was more obvious when using COOL than Java. In thedata correlation section the distribution of completion times isdiscussed with relation to the amount of programming under-standing necessary to complete the programming task.
1 403530252015105
Bug 1
Bug 2
Bug 3
minutes
AspectJ
Java
Figure 1: Completion times
4
Switching Between Files
We were interested in determining if, for bugs where more se-mantic analysis was being performed on the code, users had toswitch between files more using AspectJ because of the needfor context of the synchronization code. For this reason, werecorded the number of times the pairs switched the file theywere examining. Figure 2 shows that the AspectJ pairs madefewer file switches than the Java group for bug 1, more forbug 2 and slightly less for bug 3.
AspectJ
Java
Bug 3
Bug 2
Bug 1
0 1 2 3 4 5 6 87file switches
Figure 2: Number of file switches
Instances of Semantic Analysis
The histograms shown in Figure 3 highlight the difference innumber of instances of semantic analysis over the nine ses-sions. To determine the number of instances of semantic anal-ysis we recorded the number of times participants said some-thing to the effect of “let’s find out what this does...”. This in-dicates that the Java pairs spent more time analyzing the actualbehavior of the code than the AspectJ pairs did. In the AspectJsession with the most instances of semantic analysis, the groupmembers openly disagreed as to how much semantic analysiswas necessary to solve the second bug:
A: ...we know it’s in the COOL file...B: But we have to know what they do before chang-ing anything.
AspectJ
JavaBug 1
Bug 2
Bug 3
0 81 2 3 4 5 76
instances of analysis
Figure 3: Instances of semantic analysis
Builds
For the first and third bugs, there was only one build per bugwith the exception of one Java pair for the first bug, who builtand executed five times, and one Java pair in the third bug,who built and executed twice. There was no direct correlationbetween builds and instances of semantic analysis; however,there was a slight correlation between the number of builds per-formed and the number of file switches.
Mixing Concurrency and Functionality Issues
In each of the AspectJ and Java groups, one group attempted tosolve the synchronization bug with a change to the core func-tionality of the code.
Granularity Analysis
Since AspectJ synchronization is fixed at a method-level gran-ularity, users of Java have an opportunity to think about thegranularity of locks that AspectJ users do not. To collect theinstances of this we noted when the users attempted to movelocks around within a method, hence implementing a finergranularity of locking than the original method granularity.Only one Java pair investigated locking granularity in the firstbug, one in the second, and two in the third. None of the As-pectJ participants questioned the synchronization granularityimposed by COOL.
Correlation of Data
When examined in isolation, the increase in number of fileswitches made by the AspectJ pairs versus the less significantincrease for the Java pairs from the first to the second bug maybe explained by the fact that the Java groups had done exten-sive initial file investigation in solving the first bug.
However, the AspectJ group spent less time performing se-mantic analysis than the Java group did. This could explainwhy the times for the Java pairs never caught up to those ofthe AspectJ group. The Java group’s general lack of regard forthe granularity of locks removes this as an explanation for theextra time spent. One other point must be clarified regardingtime: Both the AspectJ and Java pairs spent relatively equaltime in building and executing their program. The additionaltime for weaving AspectJ was negligible.
The number of instances of semantic analysis somewhat ex-plain the number of file switches made by the AspectJ pairs. Inthe second bug (the bug with the highest average of semanticanalysis instances) the most file switching occurred. We be-lieve that there were less file switches by AspectJ pairs thanJava pairs on bug 2 because less semantic analysis was per-formed to solve the bug.
5
Participants’ Thoughts
We asked the AspectJ users what they thought about the sep-aration of the synchronization code from the rest of the core.Two of the three groups were enthusiastic and noted that theydid not want the code for the coordination in-line:
I’d much rather have it separated like this. I reallywould. ... I would rather not look at the details
It meant that since [the problems] were just synchro-nization problems we just had to look at the partsthat were related to synchronization. We could havespent lots of time looking at the non-synchronizationparts, at one point we did look briefly, but it wasclear there was nothing about synchronization in thatcode, and the only way to deal with synchronizationwas to look in the COOL files.
The other group felt that COOL provided a handy way ofsummarizing coordination of and between methods, but wereunhappy with the actual separating out of the coordinationcode.
The only place I can see there could be an advan-tage is if you know that you have some modules youare working with that are tested and you are sure youcan limit the bugs to synchronization issues in whichcase you don’t really have to understand the code.
They would have opted instead for the COOL code to havebeen inserted in pertinent places throughout the code so thatthe user could see in once glance both the coordination and themethod at the same time. Interestingly, this pair (the third As-pectJ pair) switched less between files in total than any of theJava pairs.
We asked the Java groups how they mentally separatedthe synchronization code from the core code. One partici-pant noted that when looking at Java synchronization codethey made no algorithmic differentiation between the synchro-nization code and the core code. They continued by dis-cussing the need for some abstraction of the synchronizationthat was higher level than the locking available through Java.”Some way of specifying that you have certain constraints be-tween methods within classes or objects, instead of using thisscheme”. They noted that this shortcut for locking would saveboth five lines of code and save you looking at the code itself.We admit that this is speculative since the Java people had noexperience with the real separation.
4 Summary
With the first of our three experiments, we were able to obtaininteresting indications about the use of aspect-oriented pro-
gramming versus object-oriented programming. We noted thatusers of the aspect-oriented programming language AspectJwere able to complete debugging tasks with fewer instances ofsemantic analysis which seemed to lead directly to less switch-ing between files, indirectly to fewer builds, and ultimately toquicker completion times.
We used a pilot study to gather a set of guidelines about thedesign of further studies, and used those guidelines in design-ing the first main experiment. The ability of one participantto come close to an appropriate solution with a coordinatordemonstrates it is possible to learn the approach quickly andapply it.
The first experiment highlighted the usefulness of being ableto easily express and understand synchronization code. Welearned that there are times at which it is useful for synchro-nization code to be embedded in the core functionality, but thatat times work can be speeded considerably (as in bug 1) whensynchronization code is separated from the rest.
5 Acknowledgments
We would like to thank the Xerox Embedded ComputationArea group for their comments on the experiment concepts andthe use of the AspectJ weaver, the anonymous participants whotook part in the sessions, and Robert Rekrutiak and Paul Nalosfor their work on experiment setup.
Funding provided by Xerox Corporation and a UBC Gradu-ate Fellowship.
References
[1] K. Arnold and J. Gosling. The JavaTM Programming Lan-guage. Addison-Wesley, 1996.
[2] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda,C. Lopes, and J. Irwin. Aspect-oriented programming. InECOOP ’97 - Object-Oriented Programming. 11th Euro-pean Conference Proceedings. Jyvaskyla, Finland, pages220–242, June 1997.
[3] Joseph E. McGrath. Methodology matters: Doing re-search in the behavioral and social sciences. In Ronald M.Baecker, Jonathan S. Grudin, William A. S. Buxton, andSaul Greenberg, editors, Readings in Human-ComputerInteraction: Toward the Year 2000, pages 152–169. Mor-gan Kaufmann, San Francisco, 2nd edition, 1995.
