DOCSLIB.ORG

An Efficient and Flexible Implementation of Aspect-Oriented

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
An Efficient and Flexible Implementation of Aspect-Oriented An Efficient and Flexible Implementation of Aspect-Oriented Languages Vom Fachbereich Informatik der Technischen Universit¨at Darmstadt genehmigte Dissertation zur Erlangung des akademischen Grades eines Doktor-Ingenieurs (Dr.-Ing.) vorgelegt von Diplom-Informatiker Christoph-Matthias Bockisch geboren in Bielefeld Referentin: Prof. Dr.-Ing. Mira Mezini Korreferent: Prof. dr. ir. Mehmet Ak¸sit Datum der Einreichung: 14. Mai 2008 Datum der mundlichen¨ Prufung:¨ 1. Juli 2008 Erscheinungsjahr 2009 Darmstadt D17 Abstract Compilers for modern object-oriented programming languages generate code in a platform independent intermediate language [LY99, CLI06] preserv- ing the concepts of the source language; for example, classes, fields, meth- ods, and virtual or static dispatch can be directly identified within the in- termediate code. To execute this intermediate code, state-of-the-art im- plementations of virtual machines perform just-in-time (JIT) compilation [DS84, ACL+99, Ayc03] of the intermediate language; i.e., the virtual in- structions in the intermediate code are compiled to native machine code at runtime. In this step, a declarative representation of source language con- cepts in the intermediate language facilitates highly efficient adaptive and speculative optimization of the running program which may not be possible otherwise. In contrast, constructs of aspect-oriented languages|which improve the separation of concerns|are commonly realized by compiling them to con- ventional intermediate language instructions or by driving transformations of the intermediate code, which is called weaving. This way the aspect-oriented constructs' semantics is not preserved in a declarative manner at the inter- mediate language level. This representational gap between aspect-oriented concepts in the source code and in the intermediate code hinders high perfor- mance optimizations and weakens features of software engineering processes like debugging support or the continuity property of incremental compila- tion: modifying an aspect in the source code potentially requires re-weaving multiple other modules [SDR08, RDHN06]. To leverage language implementation techniques for aspect-oriented lan- guages, this thesis proposes the Aspect-Language Implementation Archi- tecture (ALIA) which prescribes|amongst others|the existence of an in- termediate representation preserving the aspect-oriented constructs of the source program. A central component of this architecture is an extensible and flexible meta-model of aspect-oriented concepts which acts as an inter- face between front-ends (usually a compiler) and back-ends (usually a vir- tual machine) of aspect-oriented language implementations. The architecture iii and the meta-model are embodied for Java-based aspect-oriented languages in the Framework for Implementing Aspect Languages (FIAL) respectively the Language-Independent Aspect Meta-Model (LIAM) which is part of the framework. FIAL generically implements the work flows required from an ex- ecution environment when executing aspects provided in terms of LIAM. In addition to the first-class intermediate representation of aspect-oriented con- cepts, ALIA|and the FIAL framework as its incarnation|treat the points of interaction between aspects and other modules|so-called join points|as being late-bound to an implementation. In analogy to the object-oriented terminology for late-bound methods, the join points are called virtual in ALIA. Together, the first-class representation of aspect-oriented concepts in the intermediate representation as well as treating join points as being virtual facilitate the implementation of new and effective optimizations for aspect- oriented programs. Three different instantiations of the FIAL framework are presented in this thesis, showcasing the feasibility of integrating language back-ends with dif- ferent characteristics with the framework. One integration supports static as- pect deployment and produces results similar to conventional aspect weavers; the woven code is executable on any standard Java virtual machine. Two in- stantiations are fully dynamic, where one is realized as a portable plug-in for standard Java virtual machines and the other one, called SteamloomALIA, is realized as a deep integration into a specific virtual machine, the Jikes Research Virtual Machine [AAB+05]. While the latter instantiation is not portable, it exhibits an outstanding performance. Virtual join point dispatch is a generalization of virtual method dis- patch. Thus, well established and elaborate optimization techniques from the field of virtual method dispatch are re-used with slight adaptations in SteamloomALIA. These optimizations for aspect-oriented concepts go be- yond the generation of optimal bytecode. Especially strikingly, the power of such optimizations is shown in this thesis by the examples of the cflow dynamic property [ACH+05b], which may be necessary to evaluate during virtual join point dispatch, and dynamic aspect deployment [MO03]|i.e., the selective modification of specific join points' dispatch. In order to evaluate the optimization techniques developed in this thesis, a means for benchmarking has been developed in terms of macro-benchmarks; i.e., real-world applications are executed. These benchmarks show that for both concepts the implementation presented here is at least circa twice as fast as state-of-the-art implementations performing static optimizations of the generated bytecode; in many cases this thesis's optimizations even reach a speed-up of two orders of magnitude for the cflow implementation and even four orders of magnitude for the dynamic deployment. iv The intermediate representation in terms of LIAM models is general enough to express the constructs of multiple aspect-oriented languages. There- fore, optimizations of features common to different languages are available to applications written in all of them. To proof that the abstractions provided by LIAM are sufficient to act as intermediate language for multiple aspect- oriented source languages, an automated translation from source code to LIAM models has been realized for three very different and popular aspect- oriented languages: AspectJ [KHH+01], JAsCo [VSV+05] and Compose* [BA01, dRHH+08]. In addition, the feasibility of translating from CaesarJ [AGMO06] to LIAM models is shown by discussion. The use of an exten- sible meta-model as intermediate representation furthermore simplifies the definition of new aspect-oriented language concepts as is shown in terms of a tutorial-style example of designing a domain specific extension to the Java language in this thesis. v Zusammenfassung Compiler fur¨ moderne Objekt-orientierte Programmiersprachen generieren Code in einer Plattform-unabh¨angigen Intermediate-Sprache [LY99, CLI06], die die Konzepte der Quell-Sprache erh¨alt; zum Beispiel k¨onnen Klassen, Felder, Methoden und virtueller oder statischer Methodendispatch direkt im Intermediate-Code identifiziert werden. Um diesen Intermediate-Code auszufuhren,¨ fuhren¨ aktuelle Implementierungen von virtuellen Maschinen sogenannte just-in-time (JIT) Compilierung der Intermediate-Sprache durch [DS84, ACL+99, Ayc03]; das bedeutet, dass die virtuellen Instruktionen im Intermediate-Code zur Laufzeit zu nativem Maschinencode compiliert werden. In diesem Schritt erm¨oglicht eine deklarative Repr¨asentation der Konzepte aus der Quell-Sprache in der Intermediate-Sprache h¨ochst effiziente adaptive und spekulative Optimierungen des laufenden Programms, die sonst nicht m¨oglich w¨aren. Im Gegensatz hierzu werden die Konstrukte von Aspekt-orientierten Pro- grammiersprachen { die zu einer besseren \Separation of Concerns" fuhren¨ { ublicherweise¨ dadurch realisiert, dass sie zu herk¨ommlichen Intermediate- Instruktionen compiliert werden oder dass sie Transformationen im Interme- diate-Code bewirken; dies wird \Weben" genannt. Auf diese Weise bleibt die Semantik Aspekt-orientierter Konstrukte auf der Ebene der Intermediate- Sprache nicht deklarativ erhalten. Durch diese Kluft in der Darstellung Aspekt-orientierter Konzepte im Quell-Code und im Intermediate-Code wer- den hoch-performante Optimierungen behindert und Eigenschaften eines Soft- ware-Entwicklungsprozesses geschw¨acht, wie Unterstutzung¨ beim Debuggen oder die Continuity-Eigenschaft von inkremeteller Compilierung: Eine Mod- ifikation an einem Aspekt im Quell-Code zieht m¨oglicherweise das erneute Weben mehrerer anderer Module nach sich [SDR08, RDHN06]. Um die Sprach-Implementierungstechniken fur¨ Aspekt-orientierte Pro- grammiersprachen zu verbessern, wird in dieser Arbeit die Architektur fur¨ Aspekt-Sprachen-Implementierungen (englisch Aspect-Language Implemen- tation Architecture, ALIA) vorgeschlagen, welche unter anderem vorschreibt, dass eine Intermediate-Repr¨asentation existiert, die die Aspekt-orientierten vii Konstrukte aus dem Quell-Programm erh¨alt. Eine zentrale Komponente dieser Architektur ist das erweiterbare und flexible Meta-Model von Aspekt- orientierten Konzepten, das als Schnittstelle zwischen Front-Ends (ublicher-¨ weise ein Compiler) und Back-Ends (ublicherweise¨ eine virtuelle Maschine) von Aspekt-orientierten Sprachimplementierungen dient. Die Architektur und das Meta-Model sind fur¨ Java-basierte Sprachen in dem Framework zum Implementieren von Aspekt-Sprachen (englisch Framework for Implementing Aspect Languages, FIAL) beziehungsweise dem Sprachunabh¨angigen Aspekt- Meta-Model (englisch Language-Independent Aspect Meta-Model, LIAM), das Teil des Frameworks ist, verk¨orpert. FIAL implementiert
Load more

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]
  • Smart Execution of Distributed Application by Balancing Resources in Mobile Devices
    ALMA MATER STUDIORUM - UNIVERSITÀ DI BOLOGNA SCUOLA DI INGEGNERIA E ARCHITETTURA DISI INGEGNERIA INFORMATICA TESI DI LAUREA in Reti di Calcolatori M Smart execution of distributed application by balancing resources in mobile devices and cloud-based avatars CANDIDATO: RELATORE: Giacomo Gezzi Chiar.mo Prof. Ing. Antonio Corradi CORRELATORE: Chiar.mo Prof. Cristian Borcea Anno Accademico 2014/2015 Sessione III 2 Abstract L’obiettivo del progetto di tesi svolto e` quello di realizzare un servizio di livello middleware dedicato ai dispositivi mobili che sia in grado di fornire il supporto per l’offloading di codice verso una infrastruttura cloud. In particolare il progetto si concentra sulla migrazione di codice verso macchine virtuali dedicate al singolo utente. Il sistema operativo delle VMs e` lo stesso utilizzato dal device mobile. Come i precedenti lavori sul computation offloading, il progetto di tesi deve garantire migliori per- formance in termini di tempo di esecuzione e utilizzo della batteria del dispositivo. In particolare l’obiettivo piu` ampio e` quello di adattare il principio di computation offloading a un contesto di sistemi distribuiti mobili, miglio- rando non solo le performance del singolo device, ma l’esecuzione stessa dell’applicazione distribuita. Questo viene fatto tramite una gestione di- namica delle decisioni di offloading basata, non solo, sullo stato del de- vice, ma anche sulla volonta` e/o sullo stato degli altri utenti appartenenti allo stesso gruppo. Per esempio, un primo utente potrebbe influenzare le decisioni degli altri membri del gruppo specificando una determinata richiesta, come alta qualita` delle informazioni, risposta rapida o basata su altre informazioni di alto livello.
    [Show full text]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • Design Pattern Implementation in Java and Aspectj
    Design Pattern Implementation in Java and AspectJ Jan Hannemann Gregor Kiczales University of British Columbia University of British Columbia 201-2366 Main Mall 201-2366 Main Mall Vancouver B.C. V6T 1Z4 Vancouver B.C. V6T 1Z4 jan [at] cs.ubc.ca gregor [at] cs.ubc.ca ABSTRACT successor in the chain. The event handling mechanism crosscuts the Handlers. AspectJ implementations of the GoF design patterns show modularity improvements in 17 of 23 cases. These improvements When the GoF patterns were first identified, the sample are manifested in terms of better code locality, reusability, implementations were geared to the current state of the art in composability, and (un)pluggability. object-oriented languages. Other work [19, 22] has shown that implementation language affects pattern implementation, so it seems The degree of improvement in implementation modularity varies, natural to explore the effect of aspect-oriented programming with the greatest improvement coming when the pattern solution techniques [11] on the implementation of the GoF patterns. structure involves crosscutting of some form, including one object As an initial experiment we chose to develop and compare Java playing multiple roles, many objects playing one role, or an object [27] and AspectJ [25] implementations of the 23 GoF patterns. playing roles in multiple pattern instances. AspectJ is a seamless aspect-oriented extension to Java, which means that programming in AspectJ is effectively programming in Categories and Subject Descriptors Java plus aspects. D.2.11 [Software Engineering]: Software Architectures – By focusing on the GoF patterns, we are keeping the purpose, patterns, information hiding, and languages; D.3.3 intent, and applicability of 23 well-known patterns, and only allowing [Programming Languages]: Language Constructs and Features – the solution structure and solution implementation to change.
    [Show full text]
  • Weaving Eclipse Applications
    Weaving Eclipse Applications Fabio Calefato, Filippo Lanubile, Mario Scalas, 1 Dipartimento di Informatica, Università di Bari, Italy {calefato, lanubile, scalas}@uniba.it Abstract. The Eclipse platform fully supports the ideas behind software components: in addition it also adds dynamic behavior allowing components to be added, replaced or removed at runtime without shutting the application down. While layered software architectures may be implemented by assembling components, the way these components are wired together differs. In this paper we present our solution of Dependecy Injection, which allows to build highly decoupled Eclipse applications in order to implement real separation of concerns by systemically applying Aspect Oriented Programming and the Model-View-Presenter pattern, a variant of the classic Model-View-Controller. Keywords: Eclipse, Aspect Oriented Programming, Dependency Injection. 1 Introduction The Dependency Inversion Principle [19] (DIP) states that (both high and low level) software parts should not depend on each other’s concrete implementation but, instead, be based on a common set of shared abstractions: one application of the DIP is the Dependency Injection, also called Inversion of Control (IoC) [11]. From an architectural perspective, DI allows to explicit the dependencies between software components and provides a way to break the normal coupling between a system under test and its dependencies during automated testing [25]. This is possible because the software is composed by aggregating simpler, loosely coupled objects that are more easily unit-testable [32]. Additionally, by separating the clients by their dependencies, we also make their code simpler because there is no need for them to search for their collaborators.
    [Show full text]
  • Static Versus Dynamic Polymorphism When Implementing Variability in C++
    Static Versus Dynamic Polymorphism When Implementing Variability in C++ by Samer AL Masri A thesis submitted in partial fulfillment of the requirements for the degree of Master of Science Department of Computing Science University of Alberta c Samer AL Masri, 2018 Abstract Software Product Line Engineering (SPLE) creates configurable platforms that can be used to efficiently produce similar, and yet different, product vari- ants. To implement SPLs, multiple variability implementation mechanisms have been suggested, including polymorphism. In this thesis, we talk about the trade-offs of using static versus dynamic polymorphism through a case study of IBM’s open-source Eclipse OMR project. Eclipse OMR is an open-source C++ framework for building robust lan- guage runtimes. To support the diverse languages and architectures targeted by the framework, OMR’s variability implementation uses a combination of build-system variability and static polymorphism. OMR developers now real- ize that their current static polymorphism implementation has its drawbacks and are considering using dynamic polymorphism instead. In order to study the trade-offs of using different kinds of polymorphism in OMR, it is crucial to collect function information and overload/override statistics about the current code base. Hence, we create OMRStatistics,a static analysis tool that collects such information about OMR’s source code. Using the information provided by OMRStatistics, OMR developers can make better design decisions on which variability extension points should be switched from static polymorphism to dynamic polymorphism. In addition, we report on our first hand experience of changing the poly- morphism used in OMR’s variability implementation mechanism from static to dynamic, the challenges we faced in the process, and how we overcame them.
    [Show full text]