An AOP Extension for C++

Total Page:16

File Type:pdf, Size:1020Kb

An AOP Extension for C++ Workshop Aspects AspectC++: Olaf Spinczyk Daniel Lohmann Matthias Urban an AOP Extension for C++ ore and more software developers are The aspect Tracing modularises the implementa- On the CD: getting in touch with aspect-oriented tion of output operations, which are used to trace programming (AOP). By providing the the control flow of the program. Whenever the exe- The evaluation version M means to modularise the implementation of cross- cution of a function starts, the following aspect prints of the AspectC++ Add- in for VisualStudio.NET cutting concerns, it stands for more reusability, its name: and the open source less coupling between modules, and better separa- AspectC++ Develop- tion of concerns in general. Today, solid tool sup- #include <cstdio> ment Tools (ACDT) port for AOP is available, for instance, by JBoss for Eclipse, as well as // Control flow tracing example example listings are (JBoss AOP), BEA (AspectWerkz), and IBM (As- aspect Tracing { available on the ac- pectJ) and the AJDT for Eclipse. However, all // print the function name before execution starts companying CD. these products are based on the Java language. advice execution ("% ...::%(...)") : before () { For C and C++ developers, none of the key players std::printf ("in %s\n", JoinPoint::signature ()); offer AOP support – yet. } This article introduces AspectC++, which is an as- }; pect-oriented language extension for C++. A compil- er for AspectC++, which transforms the source code Even without fully understanding all the syntactical into ordinary C++ code, has been developed as elements shown here, some big advantages of AOP an open source project. The AspectC++ project be- should already be clear from the example. Without gan with a research prototype in 2001 that has gained using this simple aspect, which is only a few lines maturity over the years. Today, the AspectC++ lan- long, one would have to augment all functions of guage and weaver has been successfully applied the program with an additional printf statement to a number of commercial projects in industry and to get the same result. In a large project, a style academia and IDE integration into Eclipse and Micro- guide would have to document this as a require- soft VisualStudio.NET make the first steps child's play. ment and all programmers would have to read and Our AspectC++ introduction will start with an ex- obey this global policy. As a result of this, the AOP ample that can be considered the Hello World of solution saves a lot of time, organisational effort, AOP. It will illustrate the basic language elements like and guarantees that no function will be forgotten. aspects, pointcuts, and advice, which some read- At the same time the code, which is affected by ers might already know from the AspectJ language. the aspect, is completely decoupled from the trac- We will then quickly step beyond these AspectJ-like ing code, i.e. the printf. Not even <cstdio> has language elements by looking into an AspectC++ to be included, because all this is done separately version of the well-known observer pattern and into by the aspect. Generic Advice. This unique AspectC++ feature com- bines the power of aspects with generic and genera- Aspects, advice and pointcuts tive programming in C++. The Tracing example shows most of the language elements that are responsible for these advantag- Tracing – the Hello World of AOP es. We will start with the aspect, which is intended As an introductory example for AOP with AspectC++, as a module for the implementation of a crosscutting we will take a closer look at a very simple aspect. concern. From the syntactical perspective an aspect in AspectC++ is very much like a class in C++. How- Dr. Olaf Spinczyk is the founder and leader of the As- ever, besides member functions and data elements, pectC++ project. Daniel Lohmann uses AspectC++ in his an aspect can additionally define advice. After the research on operating system development and works advice keyword a pointcut expression defines where on the design and evolution of the AspectC++ language the advice should affect the program (the join points), concepts. Both are employed at Friedrich-Alexander while the part that follows the colon defines how the University Erlangen-Nuremberg. Matthias Urban is the program should be affected at these points. This is main developer of the AspectC++ parser. He works a general rule for all kinds of advice in AspectC++. for pure-systems GmbH, where he is responsible for AspectC++ support and the AspectC++ Add-In for Pointcut expressions VisualStudio.NET. Contact with the authors: [email protected], The pointcut expression in the example (where) is [email protected], [email protected] execution("% ...::%(...)"). It means that the advice should affect the execution of all functions that match 68 www.sdjournal.org Software Developer’s Journal 5/2005 Aspect Programming the expression "% ...::%(...)". In "match expressions" the % and �������� ��������� �������� ... characters are used as wildcards. A percent (%) matches any ����������������������� ����������� type (for example "% *" matches any pointer type) and also any sequence of characters in identifiers (for example "xdr _ %" matches all classes, which have a name that starts with xdr _ ). An ellipsis (...) matches any sequence of types or namespaces (for example "int foo(...)" matches any global function which returns an int and is named foo). Eventually, the match expres- ������������ ����������� ���������� sion "% ...::%(...)" matches any function in any class or name- ������ ������ ��������������� space. ������������� ������������� �������������������������������������������� Match expressions represent sets of named program en- ������ tities like functions or classes. Thus, match expressions are already primitive pointcut expressions which describe a set of Figure 1. Crosscutting in the Observer Pattern join points in the static program structure (’static join points‘). However, in our example we want advice for an event in the implement an additional piece of program behaviour. In our dynamic control flow of the program, namely the execution of aspect Trace this behaviour is implemented by the printf() functions. Therefore, the pointcut function execution() is used. statement, which follows before(). Syntactically this looks It yields all function execution join points for the functions like a function body and, indeed, we can understand the ad- given as its argument. vice body as an anonymous member function of the aspect. Instead of before() we could also use after() advice (or both) Advice for dynamic join points in the example. In this case, the advice body would be run af- For dynamic join points AspectC++ supports three types of ter the execution of a function has finished. Anaround() advice code advice called before(), after() and around(). They all body is executed instead of the control flow, which would normally follow the dynamic join point. Listing 1. The Abstract Aspect ObserverPattern Combined pointcut expressions aspect ObserverPattern { Pointcut expressions can be combined by using the set opera- // Data structures to manage subjects and observers tors && (intersection), || (union) and ! (inversion). For ... instance, the expression "% foo(int, ...)" || "int bar(...)" public: matches any global function named foo which takes // Interfaces for each role an int as the first parameter and any global function named struct ISubject {}; bar which returns an int. In conjunction with pointcut func- struct IObserver { tions, we thereby get quite powerful expressions to describe virtual void update(ISubject *) = 0; where advice should affect the program. For instance, we }; might change the pointcut expression for our Tracing aspect as follows: // To be defined by the concrete derived aspect // subjectChange() matches all non-const methods advice call ("% ...::%(...)") pointcut virtual observers() = 0; && within ("Client") : before () { pointcut virtual subjects() = 0; std::printf ("calling %s\n", JoinPoint::signature ()); pointcut virtual subjectChange() = } execution("% ...::%(...)" && !"% ...::%(...) const") The call() function yields all function call join points for && within(subjects()); the given functions. In contrast to execution join points, call join points take effect on the caller side, that is before, // Add new baseclass to each subject/observer class after, or around an actual function call. The within() point- // and insert code to inform observers cut function simply returns all join points in the given class- advice observers() : baseclass(IObserver); es or functions. By giving advice to the intersection of call advice subjects() : baseclass(ISubject); ("% ...::%(...)") (any function call) and within ("Client") (any join point in the class Client), the aspect will now trace advice subjectChange() : after() { only those function calls that are made from a method in the ISubject* subject = tjp->that(); class Client. updateObservers(subject); } Join point API // Operations to add, remove and notify observers In the advice body the expression JoinPoint::signature() void updateObservers(ISubject* sub) { ... } still waits for an explanation. As we know from the example, void addObserver(ISubject* sub, IObserver* ob) { ... } it yields the function name that we print before the function void remObserver(ISubject* sub, IObserver* ob) { ... } execution starts. The static member function signature() }; is defined by the join point API. This is an API defined by AspectC++ that allows aspect code to retrieve
Recommended publications
  • A Brief Introduction to Aspect-Oriented Programming
    R R R A Brief Introduction to Aspect-Oriented Programming" R R Historical View Of Languages" R •# Procedural language" •# Functional language" •# Object-Oriented language" 1 R R Acknowledgements" R •# Zhenxiao Yang" •# Gregor Kiczales" •# Eclipse website for AspectJ (www.eclipse.org/aspectj) " R R Procedural Language" R •# Also termed imperative language" •# Describe" –#An explicit sequence of steps to follow to produce a result" •# Examples: Basic, Pascal, C, Fortran" 2 R R Functional Language" R •# Describe everything as a function (e.g., data, operations)" •# (+ 3 4); (add (prod 4 5) 3)" •# Examples" –# LISP, Scheme, ML, Haskell" R R Logical Language" R •# Also termed declarative language" •# Establish causal relationships between terms" –#Conclusion :- Conditions" –#Read as: If Conditions then Conclusion" •# Examples: Prolog, Parlog" 3 R R Object-Oriented Programming" R •# Describe " –#A set of user-defined objects " –#And communications among them to produce a (user-defined) result" •# Basic features" –#Encapsulation" –#Inheritance" –#Polymorphism " R R OOP (cont$d)" R •# Example languages" –#First OOP language: SIMULA-67 (1970)" –#Smalltalk, C++, Java" –#Many other:" •# Ada, Object Pascal, Objective C, DRAGOON, BETA, Emerald, POOL, Eiffel, Self, Oblog, ESP, POLKA, Loops, Perl, VB" •# Are OOP languages procedural? " 4 R R We Need More" R •# Major advantage of OOP" –# Modular structure" •# Potential problems with OOP" –# Issues distributed in different modules result in tangled code." –# Example: error logging, failure handling, performance
    [Show full text]
  • Weaving Ontology Aspects Using a Catalog of Structural Ontology Design Patterns
    Weaving Ontology Aspects Using a Catalog of Structural Ontology Design Patterns Ralph Schäfermeier and Adrian Paschke Corporate Semantic Web Group, Institute of Computer Science, Freie Universität Berlin, Germany {schaef,paschke}@inf.fu-berlin.de http://www.csw.inf.fu-berlin.de Abstract. Modular development of ontologies proves beneficial at dif- ferent stages of the ontology lifecycle. In our previous work, we proposed aspect-oriented ontology development as a flexible approach to modular ontology development and a-posteriori modularization of existing mono- lithic ontologies, inspired by aspect-oriented programming and based on so called cross-cutting concerns. Similar to other formalisms for mod- ular ontologies (e.g. E-Connections), aspect-oriented ontologies rely on an extension of the used ontology language. This derivation from the standard in turn requires specially adapted tools in order to use these ontologies in applications. In this paper, we present an approach to the recombination of aspect-oriented ontology modules to standard OWL 2 ontologies by using an aspect-weaving service. The weaving service relies on a preconfigured catalog of structural ontology design patterns. We show that the use of the weaving service yields syntactically correct and semantically complete ontologies while still allowing ontology developers to fully benefit from modular ontology development. Keywords: Aspect-Oriented Ontology Development, Aspect-Oriented Programming, Ontology Modularization, Ontology Design Patterns 1 Introduction Modular ontology development has proved beneficial when it comes to improve- ment of reasoning and query result retrieval performance, scalability for ontol- ogy evolution and maintenance, complexity management, amelioration of un- derstandability, reuse, context-awareness, and personalization [17]. A significant amount of research work has been dedicated in the field of ontology modular- ization, and various kinds of approaches tackle the problem from different per- spectives.
    [Show full text]
  • The Machine That Builds Itself: How the Strengths of Lisp Family
    Khomtchouk et al. OPINION NOTE The Machine that Builds Itself: How the Strengths of Lisp Family Languages Facilitate Building Complex and Flexible Bioinformatic Models Bohdan B. Khomtchouk1*, Edmund Weitz2 and Claes Wahlestedt1 *Correspondence: [email protected] Abstract 1Center for Therapeutic Innovation and Department of We address the need for expanding the presence of the Lisp family of Psychiatry and Behavioral programming languages in bioinformatics and computational biology research. Sciences, University of Miami Languages of this family, like Common Lisp, Scheme, or Clojure, facilitate the Miller School of Medicine, 1120 NW 14th ST, Miami, FL, USA creation of powerful and flexible software models that are required for complex 33136 and rapidly evolving domains like biology. We will point out several important key Full list of author information is features that distinguish languages of the Lisp family from other programming available at the end of the article languages and we will explain how these features can aid researchers in becoming more productive and creating better code. We will also show how these features make these languages ideal tools for artificial intelligence and machine learning applications. We will specifically stress the advantages of domain-specific languages (DSL): languages which are specialized to a particular area and thus not only facilitate easier research problem formulation, but also aid in the establishment of standards and best programming practices as applied to the specific research field at hand. DSLs are particularly easy to build in Common Lisp, the most comprehensive Lisp dialect, which is commonly referred to as the “programmable programming language.” We are convinced that Lisp grants programmers unprecedented power to build increasingly sophisticated artificial intelligence systems that may ultimately transform machine learning and AI research in bioinformatics and computational biology.
    [Show full text]
  • Continuation Join Points
    Continuation Join Points Yusuke Endoh, Hidehiko Masuhara, Akinori Yonezawa (University of Tokyo) 1 Background: Aspects are reusable in AspectJ (1) Example: A generic logging aspect can log user inputs in a CUI program by defining a pointcut Login Generic Logging id = readLine(); Aspect Main CUI Aspect cmd = readLine(); pointcut input(): call(readLine()) logging return value 2 Background: Aspects are reusable in AspectJ (2) Example: A generic logging aspect can also log environment variable by also defining a pointcut Q. Now, if we want to log environment variable (getEnv) …? Generic Logging Aspect A. Merely concretize an aspect additionally Env Aspect CUI Aspect pointcut input(): pointcut input(): Aspect reusability call(getEnv()) call(readLine()) 3 Problem: Aspects are not as reusable as expected Example: A generic logging aspect can NOT log inputs in a GUI program by defining a pointcut Login Generic Logging void onSubmit(id) Aspect { … } Main void onSubmit(cmd) GUI Aspect { … } pointcut Input(): call(onSubmit(Str)) logging arguments 4 Why can’t we reuse the aspect? Timing of advice execution depends on both advice modifiers and pointcuts Logging Aspect (inner) Generic Logging abstract pointcut: input(); Aspect after() returning(String s) : input() { Log.add(s); } unable to change to before 5 Workaround in AspectJ is awkward: overview Required changes for more reusable aspect: generic aspect (e.g., logging) two abstract pointcuts, two advice decls. and an auxiliary method concrete aspects two concrete pointcuts even if they are not needed 6 Workaround in AspectJ is awkward: how to define generic aspect Simple Logging Aspect 1. define two pointcuts abstract pointcut: inputAfter(); for before and after abstract pointcut: inputBefore(); after() returning(String s) : inputAfter() { log(s); } 2.
    [Show full text]
  • Towards an Expressive and Scalable Framework for Expressing Join Point Models
    Towards an Expressive and Scalable Framework for expressing Join Point Models Pascal Durr, Lodewijk Bergmans, Gurcan Gulesir, Istvan Nagy University of Twente {durr,bergmans,ggulesir,nagyist}@ewi.utwente.nl ABSTRACT a more fine-grained join point model is required. Moreover, Join point models are one of the key features in aspect- these models are mostly rooted in control flow and call graph oriented programming languages and tools. They provide information, but sometimes a pointcut expression based on software engineers means to pinpoint the exact locations in data flow or data dependence is more suitable. programs (join points) to weave in advices. Our experi- ence in modularizing concerns in a large embedded system This paper proposes an expressive and scalable fine-grained showed that existing join point models and their underlying framework to define join point models that incorporate both program representations are not expressive enough. This data and control flow analysis. One can subsequently specify prevents the selection of some join points of our interest. In a pointcut language which implements (part of) this join this paper, we motivate the need for more fine-grained join point model. Allowing different implementation strategies point models within more expressive source code represen- and language independence is the strength of this model. tations. We propose a new program representation called a program graph, over which more fine-grained join point The paper is structured as follows: First, we will motivate models can be defined. In addition, we present a simple lan- this research with two example concerns we encountered in guage to manipulate program graphs to perform source code our IDEALS[6] project with ASML[2].
    [Show full text]
  • Aspectj in Action, Second Edition
    Introducing AspectJ This chapter covers ■ Writing an AspectJ “Hello, world!” application ■ Becoming familiar with the AspectJ language ■ Weaving mechanisms ■ Integrating with Spring In chapter 1, we focused on general concepts in AOP. With those behind us, we can now look at one specific AOP implementation: AspectJ. AspectJ is an aspect- oriented extension to the Java programming language. Like any AOP implementa- tion, AspectJ consists of two parts: the language specification, which defines the grammar and semantics of the language; and the language implementation, which includes weavers that take various forms such as a compiler and a linker. A weaver produces byte code that conforms to the Java byte-code specification, allowing any compliant Java virtual machine (VM) to execute those class files. The language implementation also offers support for integrated development environments (IDEs), to simplify building and debugging applications. AspectJ started and initially grew as a special language that extends the Java lan- guage with new keywords. It also provided a special compiler that could understand those extensions. But recently, a lot has changed in its form as a language, as well as 27 Licensed to Manning Marketing <[email protected]> 28 CHAPTER 2 Introducing AspectJ in the weaver. First, AspectJ offers an alternative syntax based on the Java annotation facil- ity to express crosscutting constructs. This lets you use a plain Java compiler instead of the special compiler. Second, AspectJ offers new options for weaving classes with aspects. Finally, it has gained a strong foothold in the Spring Framework with several integration options. All these changes have made adoption of AspectJ easier than ever before.
    [Show full text]
  • Flowr: Aspect Oriented Programming for Information Flow Control in Ruby
    FlowR: Aspect Oriented Programming for Information Flow Control in Ruby Thomas F. J.-M. Pasquier Jean Bacon Brian Shand University of Cambridge Public Health England fthomas.pasquier, [email protected] [email protected] Abstract Track, a taint-tracking system for Ruby, developed by the SafeWeb This paper reports on our experience with providing Information project [17]. Flow Control (IFC) as a library. Our aim was to support the use However, we came to realise certain limitations of the mech- of an unmodified Platform as a Service (PaaS) cloud infrastructure anisms we had deployed. For example, to enforce the required by IFC-aware web applications. We discuss how Aspect Oriented IFC policy, we manually inserted IFC checks at selected applica- Programming (AOP) overcomes the limitations of RubyTrack, our tion component boundaries. In practice, objects and classes are the first approach. Although use of AOP has been mentioned as a natural representation of application components within an object possibility in past IFC literature we believe this paper to be the oriented language and it seems natural to relate security concerns first illustration of how such an implementation can be attempted. with those objects. We should therefore associate the primitives and We discuss how we built FlowR (Information Flow Control for mechanisms to enforce IFC with selected objects. Furthermore, we Ruby), a library extending Ruby to provide IFC primitives using wish to be able to assign boundary checks on any class or object AOP via the Aquarium open source library. Previous attempts at without further development overhead. We also wish to be able providing IFC as a language extension required either modification to exploit the inheritance property to define rules that apply to of an interpreter or significant code rewriting.
    [Show full text]
  • Aspect-Oriented Software Development for Real-Time and Internet Applications
    International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056 Volume: 05 Issue: 09 | Sep 2018 www.irjet.net p-ISSN: 2395-0072 Aspect-Oriented Software Development for Real-Time and Internet Applications Ogbonna J. C.1, Nwokoma F. O.2, Nwala K. T.3, Nwandu I. C.4 1,3Reseacher, Dept. of Computer Science, Clifford University Owerrinta, Abia State Nigeria 2,4Reseacher, Dept. of Computer Science, Federal University of Technology Owerri, Imo State Nigeria ---------------------------------------------------------------------***--------------------------------------------------------------------- Abstract - Software development evolution has introduced and increasing the reusability of a software product, which a number of useful software development methods. Efficient in turns results in better software development. modularization of program artifacts that cut across multiple AOP is based on the idea that computer systems are better locations during software development called crosscutting programmed by separately specifying the various concerns concerns have been a major drawback for these software (properties or areas of interest) of a system and some development methods including the almighty Object-Oriented description of their relationships, and then relying on Software Development method. Concerns like recovery, mechanisms in the underlying AOP environment to weave or synchronization, logging, encryption, authentication, compose them together into a coherent program (Elrad, authorization, validation, verification,
    [Show full text]
  • “An Introduction to Aspect Oriented Programming in E”
    “An Introduction to Aspect Oriented Programming in e” David Robinson [email protected] Rel_1.0: 21-JUNE-2006 Copyright © David Robinson 2006, all rights reserved 1 This white paper is based on the forthcoming book “What's so wrong with patching anyway? A pragmatic guide to using aspects and e”. Please contact [email protected] for more information. Rel_1.0: 21-JUNE-2006 2 Copyright © David Robinson 2006, all rights reserved Preface ______________________________________ 4 About Verilab__________________________________ 7 1 Introduction _______________________________ 8 2 What are aspects - part I? _____________________ 10 3 Why do I need aspects? What’s wrong with cross cutting concerns? ___________________________________ 16 4 Surely OOP doesn’t have any problems? ___________ 19 5 Why does AOP help?_________________________ 28 6 Theory vs. real life - what else is AOP good for? ______ 34 7 What are aspects - part II?_____________________ 40 Bibliography _________________________________ 45 Index ______________________________________ 48 Rel_1.0: 21-JUNE-2006 Copyright © David Robinson 2006, all rights reserved 3 Preface “But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub” Paul Graham 1 This paper is taken from a forthcoming book about Aspect Oriented Programming. Not just the academic stuff that you’ll read about elsewhere, although that’s useful, but the more pragmatic side of it as well.
    [Show full text]
  • Model-Based Aspect Weaver Construction
    Model-based Aspect Weaver Construction Suman Roychoudhury1, Frédéric Jouault2,1, and Jeff Gray1 1 University of Alabama at Birmingham, Birmingham, AL 35294 {roychous, gray}@cis.uab.edu 2 ATLAS group (INRIA & LINA), University of Nantes, France [email protected] Abstract. This paper describes an approach that combines model engineering with program transformation techniques to construct aspect weavers for general-purpose programming languages. The front-end of the weaver uses a high-level language (i.e., an aspect language) to specify aspects and is designed with a metamodel-based approach using the AMMA toolsuite. The back-end of the weaver uses transformation rules, which are generated from these high-level aspect specifications, to perform the actual low-level weaving. Both the aspect specification (front-end) and transformation rules (back-end) are captured as models within the AMMA platform. The translation from source aspect model to target transformation model is achieved using ATL, which is a model transformation language. Keywords: model transformation, program transformation, model engineering, aspect-oriented-programming, software engineering. 1 Introduction Program transformation systems have been used in the past to construct aspect weavers for programming languages [1]. Program transformation engines (PTEs) such as the Design Maintenance System (DMS) [2], or ASF+SDF [3], provide direct availability of scalable parsers and an underlying low-level transformation framework to modify source programs. This low-level transformation framework (that generally uses term-rewriting or graph-rewriting techniques to modify base code) can form the basis of constructing aspect weavers [4]. In our previous research, we demonstrated how a term-rewriting PTE like DMS can be used to construct an aspect weaver for a general-purpose programming language (GPL) like ObjectPascal [1].
    [Show full text]
  • Understanding AOP Through the Study of Interpreters
    Understanding AOP through the Study of Interpreters Robert E. Filman Research Institute for Advanced Computer Science NASA Ames Research Center, MS 269-2 Moffett Field, CA 94035 rfi[email protected] ABSTRACT mapping is of interest (e.g., variables vs. functions). The I return to the question of what distinguishes AOP lan- pseudo-code includes only enough detail to convey the ideas guages by considering how the interpreters of AOP lan- I’m trying to express. guages differ from conventional interpreters. Key elements for static transformation are seen to be redefinition of the Of course, a real implementation would need implementa- set and lookup operators in the interpretation of the lan- tions of the helper functions. In general, the helper functions guage. This analysis also yields a definition of crosscutting on environments—lookup, set, and extend—can be manip- in terms of interlacing of interpreter actions. ulated to create a large variety of different language fea- tures. The most straightforward implementation makes an environment a set of symbol–value pairs (a map from sym- 1. INTRODUCTION bols to values) joined to a pointer to a parent environment. I return to the question of what distinguishes AOP lan- Lookup finds the pair of the appropriate symbol, (perhaps guages from others [12, 14]. chaining through the parent environments in its search), re- turning its value; set finds the pair and changes its value A good way of understanding a programming language is by field; and extend builds a new map with some initial val- studying its interpreter [17]. This motif has been recently ues whose parent is the environment being extended.
    [Show full text]
  • Open Modules: Modular Reasoning About Advice
    Open Modules: Modular Reasoning about Advice Jonathan Aldrich December 2004 CMU-ISRI-04-141 Institute for Software Research International School of Computer Science Carnegie Mellon University 5000 Forbes Avenue Pittsburgh, PA 15213-3890 This technical report is an expanded version of a paper submitted for publication. It supercedes Carnegie Mellon University Technical Report CMU-ISRI-04-108, published in March 2004 and revised in July 2004. This work was supported in part by the High Dependability Computing Program from NASA Ames cooperative agreement NCC-2-1298, NSF grant CCR-0204047, and the Army Research Office grant number DAAD19-02-1-0389 entitled ”Perpetually Available and Secure Information Systems.” Abstract Advice is a mechanism used by advanced object-oriented and aspect-oriented programming languages to augment the behavior of methods in a program. Advice can help to make programs more modular by separating crosscutting concerns more effectively, but it also challenges existing ideas about modu- larity and separate development. We study this challenge using a new, simple formal model for advice as it appears in languages like AspectJ. We then add a module system designed to leave program functionality as open to extension through advice as possi- ble, while still enabling separate reasoning about the code within a module. Our system, Open Modules, can either be used directly to facilitate separate, component-based development, or can be viewed as a model of the features that certain AOP IDEs provide. We define a formal system for reasoning about the observational equivalence of programs under advice, which can be used to show that clients are unaffected by semantics-preserving changes to a module’s implementation.
    [Show full text]