DOCSLIB.ORG

From Composition Filters to Aspectj: a Platform Specificmodel Transformation

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
From Composition Filters to Aspectj: a Platform Specificmodel Transformation Journal of Computing and Information Technology - CIT 14, 2006, 2, 111–131 111 doi:10.2498/cit.2006.02.03 From Composition Filters to AspectJ: A Platform SpecificModel Transformation Djamel Meslati1, Mohamed T. Kimour1 and Sa¨ıd Ghoul2 1 Laboratory of Research on Computer Science (LRI), University of Annaba, Algeria 2 Computer Science Department, Philadelphia University, Amman, Jordan Both model-driven architecture MDA and aspect- model that has the salient characteristic that it oriented programming AOP are promising paradigms can be executed by a machine 7, 16, 17 . that are very attractive for the software engineering com- munity. While the former is an approach to application A metamodel is a special kind of model that design and implementation using models as first class entities, the latter advocates the separation of concerns specifies the abstract syntax of a modeling lan- as an approach to tackle most software development guage. In the MDA context, each model is an and maintenance problems. MDA and AOP can be instance of a metamodel that is described us- related in various ways and their combination seems ing the OMG MOF Object Management Group to be a promising issue. In this article, we focus on the transformation of two AOP approaches, composition Meta Objet Facility19 . A transformation is filters CF and ASPECTJ, considered as platform specific the process that converts one model to another metamodels within the MDA context. We propose a model of the same system according to some transformation of CF models into ASPECTJ models using a syntax-directed translation and a set of transformation description which, in turn, is a model and an templates. In addition to being easy to implement, instance of some metamodel 14, 18 . our transformation approach covers the most important concepts of CF. Broadly speaking, MDA is an approach where models are first class entities 8, 14 . A software Keywords: aspect-oriented programming,ASPECTJ, com- system can be seen as a collection of models of position filters, model-driven architecture, model trans- formation. various abstraction levels where each describes the system from some viewpoint and, conse- quently, most engineering tasks can be consid- ered as modeling and transforming models. 1. Introduction In order to promote interoperability and porta- bility, the MDA approach puts the emphasis on Model-driven architecture is an approach to sys- two kinds of models with respect to specific tem development that provides means for us- platforms: the platform independent models ing models to direct the course of systems un- PIM and the platform specific models PSM . derstanding, design, construction, deployment, Within each of these abstractions, there can be a operation, maintenance and modification 18 . number of refinements for example, many lev- The core concepts of MDA are models, meta- els of platform independent models14 .For models and transformations. A model is a rep- example, a program is a PSM obtained through- resentation of a part of the function, structure out a cascade of models and transformations. At and or behavior of a system. A model spec- the top, we find a use case PIM that highlights ification can be formal when it is based on a aspects of the system corresponding to the user language that has a well defined syntax, seman- view. Then, the use case PIM is transformed tics and possibly rules to analyze its constructs to extract objects and classes which form an- 17 . Under this definition, a source code is a other PIM. The last transformation might be a 112 From Composition Filters to AspectJ: A Platform Specific Model Transformation JAVA model which is specific to a JAVA platform sibility, simplifies component integration and i. e. the JAVA virtual machine . Notice that a decreases invasive changes 2, 12, 20 . “platform specific” is meaningful only relative Today, a large amount of literature is devoted to a particular point of view 8 . For example, to three SOC approaches: composition filters the JAVA program is a PSM when considering a CF 5 ,ASPECTJ 12 and hyperspace ap- specific JAVA platform, while it is a PIM when proach 20 . They aim at providing better con- considering the specific operating systems on cepts and mechanisms to appropriately sepa- which the JAVA virtual machine is implemented. rate the software concerns from the business In the MDA approach, transformations can be logic. Unfortunately, each approach has its own of various types such as merging or composing philosophy and concepts. An approach might models, but usually they convert models offer- be suitable from some point of view, but in- ing a particular view from one level of abstrac- appropriate from another. Consequently, pro- tion to a less abstract one e.g. PIM to PSM or viding an environment where multiple AOP ap- PIM to PIM , by adding more details supplied proaches can be used simultaneously is a worthy by the transformation rules 14 . Transforma- goal. This article is an attempt towards this goal tions between models are needed because: that focuses only on the transformation of CF models to ASPECTJ models. Our interest in CF Metamodels use various modeling concepts and ASPECTJ results from the fact that they are and notations to highlight one or more views both AOP approaches. within a model, depending on what is rele- The remainder of this article is composed of vant at any point in time 18 . six sections. Sections 2 and 3 describe, re- Metamodels influence the modeling task and spectively CF and ASPECTJ metamodels in an the perception we have of the real world. intuitive way. In section 4 we give the motiva- Thus it is beneficial to use various metamod- tions of the work and in section 5 we present els to capture the real world subtle situations CF to ASPECTJ transformation. Section 6 dis- during the engineering tasks 8 . cusses related work, and section 7 conclusion and future work. According to “divide and conquer” princi- ple, the engineering tasks can be simpli- fied if complex system models are com- posed or merged from less complex models 2. The Composition Filters Metamodel using transformations that supply necessary details. 2.1. Principle and Goals In this article, we focus on the transformation of two AOP approaches, CF and ASPECTJ, by CF considers a system as a set of objects that considering them as two platform specific meta- interact with each other to achieve a common models within the MDA context. This work is a task. Most interactions are done by sending and part of an ongoing one that aims to construct an receiving messages and CF intervenes during MDA environment where software developers these interactions 3, 6 . It provides an object can use multiple AOP metamodels, during the with an interface containing filters that inter- engineering tasks, and freely switch from one cept and manipulate messages in various forms, another, using automated tools that preserve the modifying their scope and expected behavior. concerns’ traceability. The former consists of delegating messages to other objects i. e. changing the target object AOP is a particular separation of concerns ap- to which the message is sent, whereas the lat- proach SOC , where a system can be seen as ter consists of substituting a message selector composed of business logic and concerns such with another i. e. replacing the name of the as synchronization, security, persistence, etc. It method to be called with the name of another is now commonly admitted that an appropri- one to be called instead. By controlling mes- ate separation of concerns have an influence on sages changing their targets and or selectors the development and maintenance processes. It and through a well-constructed interface, CF reduces the software complexity and code tan- provides suitable solutions to many problems gling, facilitates reuse, improves comprehen- see 2 ,suchas: From Composition Filters to AspectJ: A Platform Specific Model Transformation 113 Dynamic inheritance by enabling and dis- Input filters: A set of declarative specifica- abling inheritance relation between classes tions that handle the incoming messages. at runtime Output filters: A set of declarative specifi- Modeling of state dependent behaviors where cations that handle the outgoing messages. the behavior of an object changes according to its state Object without filters History sensitivity where the behavior of an Received messages Control Flow object depends on its previous behaviors Kernel object Method Reference Providing multiple views of the same object Method Instance see example in 2.3 Variable Method Behavior coordination and synchronization Instance Variable Tracing of programs during the development One of the CF strengths is the use of a uniform Sent messages filtration mechanism to resolve the above prob- CF object lems. From this point of view, CF is easy to Received messages Input Filter understand and work with as it only adds few Input Filter CF Interface concepts to the object metamodel. Input Filter Kernel object Method Instance Variable 2.2. Basic Concepts Instance Variable Instance Variable Method Instance messages Delegated Variable CF adds to an object a wrapping layer called Method Internal Instance Object External interface that traps incoming and outgoing Internal Object Condition Variable InternalIt Object messages. Figure 1 depicts the contents of an Object External interface added to a kernel object. We refer to Condition Object object or class with a CF interface by CF object Instance Variable Instance Variable External respectively CF class . Instance Variable Object A CF interface is composed of the following parts: Output Filter Output Filter Internal objects are objects whose methods Output Filter Sent messages are used to compose the behavior of the CF object. Messages received by a CF object can be delegated to internal objects instead Fig. 1. An object before and after adding a CF interface.
Load more

Recommended publications
  • The Inheritance Anomaly Revisited
    The Inheritance Anomaly Revisited Ryan J. Wisnesky August 2006 Contents Contents i Preface ii Introduction 1 1 The Inheritance Anomaly and Formal Framework 2 1.1 An Overview of the Inheritance Anomaly . 2 1.2 An Overview of the Framework . 4 2 History-based Guard Languages 7 2.1 History-based guard languages . 7 2.2 Two tweaks . 8 2.2.1 The first tweak: Behavior Preservation . 8 2.2.2 The second tweak: Patching the Proof . 10 2.3 Discussion . 13 2.4 Related Work and Future Directions . 13 2.5 Conclusion . 15 3 Intra-object Concurrency 16 3.1 Methods and Messages . 16 3.1.1 New synchronization constructs . 17 3.1.2 Synchronization, Methods, and Messages . 18 3.2 New Types . 19 3.2.1 Mutual Exclusion: TypesS ............................ 20 3.2.2 Mutual Exclusion and Containment: TypesS .................. 24 3.2.3 TypesT,S ...................................... 25 3.3 Conclusion and Related Work . 27 4 Specification Languages 28 5 Overall Conclusion, Future Directions, and a Note on Typing 29 6 Related Work 30 6.1 Core Papers . 30 i 6.2 Concurrent Formal Systems . 31 6.3 Anomaly Avoidance Mechanisms . 33 6.4 Anomaly Generalizations . 36 6.5 Anomaly Experiences . 36 6.6 Surveys . 37 6.7 Aspect-Oriented Programming . 37 6.8 Others............................................ 38 Bibliography 41 ii Introduction The Inheritance Anomaly has been a thorn in the side of the concurrent object-oriented language community for 15 years. Simply put, the anomaly is a failure of inheritance and concurrency to work well with each other, negating the usefulness of inheritance as a mechanism for code-reuse in a concurrent setting.
    [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]
  • The Inheritance Anomaly: Ten Years After
    The inheritance anomaly: ten years after Giuseppe Milicia Vladimiro Sassone Chi Spaces Technologies ltd. University of Sussex, UK Cambridge, UK [email protected] [email protected] ABSTRACT Clearly we must make sure that no object is removed from an The term inheritance anomaly was coined in 1993 by Matsuoka empty buffer and that no object is inserted into a full buffer. In a and Yonezawa [15] to refer to the problems arising by the coexis- sequential setting, the burden of ensuring such constraints resides tence of inheritance and concurrency in concurrent object oriented with the buffer’s user. Indeed the buffer is created and used by languages (COOLs). The quirks arising by such combination have one thread only, which is responsible for the state of the object. been observed since the early eighties, when the first experimen- To facilitate usage, the buffer’s methods might return certain er- tal COOLs were designed [3]. In the nineties COOLs turned from ror codes in case of misuse. This approach is not feasible in a research topic to widely used tools in the everyday programming concurrent setting. The buffer will be used concurrently by mul- practice, see e.g. the Java [9] experience. This expository paper ex- tiple clients, leaving each of them no idea on the buffer’s current tends the survey presented in [15] to account for new and widely state. Although it is possible to envisage ad-hoc protocols among used COOLs, most notably Java and C] [19]. Specifically, we il- clients to keep track of the buffer’s state, such a solution is com- lustrate some innovative approaches to COOL design relying on plex and hardly feasible in practice.
    [Show full text]
  • Source-Code Instrumentation and Quantification of Events Robert E
    Source-Code Instrumentation and Quantification of Events Robert E. Filman Klaus Havelund RIACS Kestrel Technology NASA Ames Research Center, MS 269/2 NASA Ames Research Center, MS 269/2 Moffett Field, CA 94035 U.S.A. Moffett Field, CA 94035 U.S.A +1 650–604–1250 +1 650–604–3366 [email protected] [email protected] ABSTRACT particularly with respect to debugging and validating concurrent Aspect-Oriented Programming is making quantified programmatic systems. assertions over programs that otherwise are not annotated to 2. EVENTS receive these assertions. Varieties of AOP systems are Quantification implies matching a predicate about a program. characterized by which quantified assertions they allow, what they Such a predicate must be over some domain. In the permit in the actions of the assertions (including how the actions quantification/implicit invocation papers, we distinguished interact with the base code), and what mechanisms they use to between static and dynamic quantification. achieve the overall effect. Here, we argue that all quantification is over dynamic events, and describe our preliminary work in Static quantification worked over the structure of the program. developing a system that maps dynamic events to transformations That is, with static quantification, one could reference the over source code. We discuss possible applications of this system, programming language structures in a system. Examples of such particularly with respect to debugging concurrent systems. structures include reference to program variables, calls to subprograms, loops, and conditional tests. Categories and Subject Descriptors Many common AOP implementation techniques can be D.3.3 [Programming Languages]: Language Constructs and understood in terms of quantified program manipulation on the Features – aspects.
    [Show full text]
  • Aspectmaps: a Scalable Visualization of Join Point Shadows
    AspectMaps: A Scalable Visualization of Join Point Shadows Johan Fabry ∗ Andy Kellens y Simon Denier PLEIAD Laboratory Software Languages Lab Stephane´ Ducasse Computer Science Department (DCC) Vrije Universiteit Brussel RMoD, INRIA Lille - Nord Europe University of Chile Belgium France http://pleiad.cl http://soft.vub.ac.be http://rmod.lille.inria.fr of join points. Second, the specification of the implicit invocations is made through a pointcut that selects at which join points the Abstract aspect executes. The behavior specification of the aspect is called the advice. An aspect may contain various pointcuts and advices, When using Aspect-Oriented Programming, it is sometimes diffi- where each advice is associated with one pointcut. cult to determine at which join point an aspect will execute. Simi- The concepts of pointcuts and advices open up new possibil- larly, when considering one join point, knowing which aspects will ities in terms of modularization, allowing for a clean separation execute there and in what order is non-trivial. This makes it difficult between base code and crosscutting concerns. However this sepa- to understand how the application will behave. A number of visu- ration makes it more difficult for a developer to assess system be- alization tools have been proposed that attempt to provide support havior. In particular, the implicit invocation mechanism introduces for such program understanding. However, they neither scale up to an additional layer of complexity in the construction of a system. large code bases nor scale down to understanding what happens at This can make it harder to understand how base system and aspects a single join point.
    [Show full text]
  • Comprehensive Aspect Weaving for Java
    Science of Computer Programming 76 (2011) 1015–1036 Contents lists available at ScienceDirect Science of Computer Programming journal homepage: www.elsevier.com/locate/scico Comprehensive aspect weaving for Java Alex Villazón ∗, Walter Binder, Philippe Moret, Danilo Ansaloni Faculty of Informatics, University of Lugano, CH-6900 Lugano, Switzerland article info a b s t r a c t Article history: Aspect-oriented programming (AOP) has been successfully applied to application code Received 20 July 2009 thanks to techniques such as Java bytecode instrumentation. Unfortunately, with existing Received in revised form 19 October 2009 AOP frameworks for Java such as AspectJ, aspects cannot be woven into the standard Java Accepted 2 December 2009 class library. This restriction is particularly unfortunate for aspects that would benefit Available online 29 April 2010 from comprehensive aspect weaving with complete method coverage, such as profiling or debugging aspects. In this article we present MAJOR, a new tool for comprehensive aspect Keywords: weaving, which ensures that aspects are woven into all classes loaded in a Java Virtual Aspect-oriented programming Aspect weaving Machine, including those in the standard Java class library. MAJOR includes the pluggable Bytecode instrumentation module CARAJillo, which supports efficient access to a complete and customizable calling Profiling context representation. We validate our approach with three case studies. Firstly, we Debugging weave existing profiling aspects with MAJOR which otherwise would generate incomplete Detecting memory leaks profiles. Secondly, we introduce an aspect for memory leak detection that also benefits Recreating crashing conditions from comprehensive weaving. Thirdly, we present an aspect subsuming the functionality Java Virtual Machine of ReCrash, an existing tool based on low-level bytecode instrumentation techniques that generates unit tests to reproduce program failures.
    [Show full text]
  • Approaches to Composition and Refinement in Object-Oriented Design
    Approaches to Composition and Refinement in Object-Oriented Design Marcel Weiher Matrikelnummer 127367 Diplomarbeit Fachbereich Informatik Technische Unversitat¨ Berlin Advisor: Professor Bernd Mahr August 21, 1997 Contents 1 Introduction 4 1.1 Object Orientation 4 1.2 Composition and Refinement 5 2 State of the Art 7 2.1 Frameworks 7 2.1.1 Framework Construction 8 2.1.2 Reusing Frameworks 9 2.2 Design Patterns 10 2.2.1 Reusing Patterns 10 2.2.2 Communicating Patterns 12 2.3 Commentary 13 3 Enhanced Interfaces 14 3.1 Interface Typing 14 3.2 The Refinement Interface 15 3.2.1 Protocol Dependencies 15 3.2.2 Reuse Contracts 18 3.3 Interaction Interfaces 21 3.3.1 Interaction Protocols 21 3.3.2 Protocol Specification and Matching 22 3.4 Commentary 23 4 Orthogonalization 24 4.1 Delegation 24 4.1.1 Prototypes Languages 25 4.1.2 Composition Filters 25 4.2 Mixins 27 4.2.1 Mixins and Multiple Inheritance 28 4.2.2 Nested Dynamic Mixins 28 4.3 Extension Hierarchies 29 4.3.1 Extension Operators 29 4.3.2 Conflicts: Detection, Resolution, Avoidance 30 4.4 Canonic Components 31 4.4.1 Components 31 4.4.2 Views 32 4.5 Commentary 33 1 5 Software Architecture 34 5.1 Architectural Styles 34 5.1.1 Pipes and Filters 35 5.1.2 Call and Return 36 5.1.3 Implicit Invocation 36 5.1.4 Using Styles 37 5.2 Architecture Description Languages 38 5.2.1 UniCon 38 5.2.2 RAPIDE 39 5.2.3 Wright 40 5.2.4 ACME 43 5.3 Commentary 43 6 Non-linear Refinement 45 6.1 Domain Specific Software Generators 45 6.1.1 A Domain Independent Model 46 6.1.2 Implementation 47 6.2 Subject Oriented
    [Show full text]
  • A Comparison of Context-Oriented and Aspect-Oriented Programming
    A comparison of Context-Oriented and Aspect-Oriented Programming Matthias Springer Hasso Plattner Institute, Advanced Modularity, seminar paper Abstract. Aspect-oriented programming and context-oriented program- ming were designed to modularize cross-cutting concerns that would oth- erwise lead to scattered code. We illustrate conceptual differences be- tween aspect-oriented programming and context-oriented programming in order to point out which technique should be used for a given use case. Besides, we motivate that pointcuts and immediate layer activation no- tifications can be useful in context-oriented programming. 1 Software development for mobile devices In this paper, we will compare aspect-oriented programming and context-oriented programming, two techniques for modularizing cross-cutting concerns. We will show two typical use cases in the area of mobile devices, immediate feedback and power management, that we will implement using aspect-oriented programming and context-oriented programming. 1.1 Immediate feedback Haptic feedback and auditive feedback are well-known patterns in human-com- puter interaction [7]. The idea is to provide immediate feedback to user input, such that the user can be certain that the device received the input. In this example the mobile device should vibrate for a quarter of a second after the user touched the touch screen or pressed a keyboard button or another hardware button. Alternatively, the device should play an unobtrusive click sound. 1.2 Power management Figure 1 shows four power states for a mobile device. If the battery charge level is 50% or greater, then the device is in the high battery state. In that state, no power saving mechanisms are activated, i.e.
    [Show full text]
  • 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.
    [Show full text]
  • Open Modules: Reconciling Extensibility and Information Hiding
    Open Modules: Reconciling Extensibility and Information Hiding Jonathan Aldrich School of Computer Science Carnegie Mellon University 5000 Forbes Avenue Pittsburgh, PA 15213, USA [email protected] ABSTRACT nisms are not flexible enough to capture many concerns that Aspect-oriented programming systems provide powerful are likely to change. These concerns cannot be effectively mechanisms for separating concerns, but understanding hidden behind information-hiding boundaries, because they how these concerns interact can be challenging. In partic- are scattered in many placed throughout the system and ular, many aspect-oriented programming constructs can vio- tangled together with unrelated code. Aspect-oriented pro- late encapsulation, creating dependencies between concerns gramming systems provide mechanisms for modularizing a that make software evolution more difficult and error-prone. more diverse set of concerns. However, few aspect-oriented In this paper, we introduce Open Modules, a mechanism programming projects have addressed the problem of pro- for enforcing a strong form of encapsulation while support- viding an encapsulation facility for aspect-oriented program- ing much of the extensibility provided by languages like ming. AspectJ. Open Modules provide extensibility by allowing 2.1 Existing Encapsulation Approaches clients to advise the interface of a module, but enforce encap- sulation by protecting function calls made within the mod- The most widely-used AOP system, AspectJ, leaves Java’s ule from external advice. A module can expose semantically existing encapsulation mechanisms largely unchanged [7]. important internal events to client aspects through pointcuts AspectJ provides new programming mechanisms that cap- in its interface. The module’s implementation can change ture concerns which crosscut Java’s class and package struc- without affecting client advice as long as the semantics of the ture.
    [Show full text]
  • Aspect-Oriented Programming
    Beyond OOP Advanced Separation of Concerns Metaprogramming Reflection Aspect-Oriented Programming Eric Tanter DCC/CWR University of Chile [email protected] Éric Tanter – U.Chile [june | 2005] 1 Contents ● A brief history of programming ● Advanced modularization problems ● Reflection and metaprogramming ● Aspect-oriented programming Éric Tanter – U.Chile [june | 2005] 2 Part I A Quick History of Programming Adapted from Brian Hayes, “The Post-OOP Paradigm”, American Scientist, 91(2), March-April 2003, pp. 106-110 Éric Tanter – U.Chile [june | 2005] 3 Software? ● Real challenge: building the machine ● Software was not important as such ● First programs (40's) ● Written in pure binary: 0s and 1s ● Explicit memory address management Éric Tanter – U.Chile [june | 2005] 4 Then came the assembly... ● Assembly language ● No more raw binary codes ● Symbols: load, store, add, sub ● Converted to a binary program by an assembler ● Calculates memory addresses ● First program to help programming Éric Tanter – U.Chile [june | 2005] 5 ...and then, compilers ● Assembly required knowledge of the specific computer instruction set ● Higher-level languages (e.g. Fortran) ● Think in terms of variables/equations ● Not registers/addresses ● 60's: big projects = late/costly/buggy Éric Tanter – U.Chile [june | 2005] 6 Structured Programming ● Manifesto by Edsger W. Dijkstra: “Go to statement considered harmful” [1968] ● Build programs out of sub-units ● Single entrance point, single exit ● 3 constructs: ● Sequencing, alternation, and iteration ● Proof that
    [Show full text]
  • Aspects and Polymorphism in Aspectj
    Aspects and Polymorphism in AspectJ Erik Ernst David H. Lorenz Dept. of Computer Science, College of Computer & Information Science, University of Aarhus Northeastern University Abogade˚ 34, DK­8200 Arhus˚ N 360 Huntington Avenue 161 CN Denmark Boston, Massachusetts 02115 USA [email protected] [email protected] ABSTRACT ¢ Polymorphic access: A name denotes an object whose dy- There are two important points of view on inclusion or subtype namic type is known only by an upper bound. For example, polymorphism in object-oriented programs, namely polymorphic the predefined reference self in a method in a class C de- access and dynamic dispatch. These features are essential for object- notes an instance of C or some subclass of C. The essence is oriented programming, and it is worthwhile to consider whether that the same code can operate on differently shaped objects they are supported in aspect-oriented programming (AOP). In AOP, because they all satisfy certain constraints (possibly made pieces of crosscutting behavior are extracted from the base code explicit in a statically declared type). and localized in aspects, losing as a result their polymorphic capa- ¢ Dynamic dispatch: When accessing an object polymorphi- bilities while introducing new and unexplored issues. In this paper, cally, a message-send may be resolved by late binding, i.e., we explore what kinds of polymorphism AOP languages should it may call different method implementations for different support, using AspectJ as the basis for the presentation. The results dynamic receiver types. The essence is that the meaning of are not exclusive to AspectJ—aspectual polymorphism may make a name (the method selector) is determined by dynamically aspects in any comparable AOSD language more expressive and selecting the “best” definition from a set of different avail- reusable across programs, while preserving safety.
    [Show full text]