DOCSLIB.ORG

Testing Aspect-Oriented Software

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Testing Aspect-Oriented Software Project Report Testing Aspect-Oriented Software Fayezin Islam MSc in Advanced Software Engineering 2006/2007 School of Physical Sciences and Engineering King’s College London Supervised by Professor Mark Harman Acknowledgements First I would like to thank my project supervisor Prof. Mark Harman, Head of Software Engineering, King’s College London for his constant guidance and support throughout this project. I would also like to thank Dr. Tao Xie, Assistant Professor at Department of Computer Science, North Carolina State University for his valuable support during the selection and progress of this project. I would also like to thank all members of CREST (Centre for Research on Evolution Search and Testing) at King’s College London, especially Kiran Lakhotia for his help during the course of this project. I would like to pass my heartfelt thanks to Stefan Wappler from Daimler Chrysler for supporting this project with his work on evolutionary testing. Finally, I would like to acknowledge my fellow Msc colleagues, especially Syed Islam and Ashraful Hassan for their views, help and suggestions during project meetings and presentations. i Abstract Aspect-oriented programming is a new programming paradigm that helps to separate cross-cutting concerns which cannot be efficiently dealt by object-oriented programming. Most research on the area of aspect-oriented programming concentrates on development of strategies to handle these cross-cutting concerns. The area of research is still new and very few research papers talk about testing aspect-oriented programs. Even fewer paper talks about automated testing of aspect- oriented programs. This project presents a novel framework that aids the automated testing of aspect-oriented programs. It converts aspect-oriented programs into equivalent object-oriented programs for testing using existing object-oriented testing tools. This framework was implemented with the development of a software tool called EvolutionaryAspectTester (EAT). EAT facilitates the evolutionary and random testing of aspect-oriented programs. It identifies target branches within aspects for automated testing. EAT also implements an extended version of the proposed framework that enables evolutionary testing of aspect-oriented programs with input domain reduction technique. EAT is the first evolutionary testing tool developed for testing aspect-oriented programs. The results of produced by this project were obtained from three studies performed on a collection of 14 aspect-oriented programs performing a variety of different tasks. The first study involved comparing evolutionary and random testing techniques to evaluate which technique was superior for testing aspect-oriented programs. The study revealed that evolutionary testing achieves better code coverage when compared to random testing and also takes less effort at the same time. The second study finds the impact of input domain reduction on evolutionary testing of aspect-oriented programs. The results show evidence to support the claim that input domain reduction makes evolutionary testing more efficient taking less effort to cover branches. An improvement in code coverage for non-target branches while testing individual branches were also observed. The third study reveals the impact of testing aspectual branches in contract to testing all branches in the program. The results clearly state a drastic reduction in effort for testing individual classes and the overall program while maintaining at least the same level of code coverage if not more. These claims are valid for aspect-oriented programming and as well as object-oriented programming since aspect- oriented programs were converted into equivalent object-oriented programs for testing. This project lays the foundation for automated testing of aspect-oriented programs. It proves that it is possible to automate the testing process for aspect-oriented programs and performs the first every study where evolutionary testing has been applied to aspect-oriented programs. Future work beyond this project would involve implementing other testing techniques using this framework and comparison of these techniques to evaluate their effectiveness for testing aspect-oriented programs. ii Table of Contents Acknowledgements i Abstract ii Table of Contents iii List of Tables vi List of Figures vii Chapter 1: Introduction 1 1.1 Background 1 1.2 Aim 2 1.3 Objectives 2 1.4 Scope 2 Chapter 2: Literature Review 3 2.1 Overview 3 2.2 Software Testing 3 2.2.1 Random Testing 3 2.2.2 Program Slicing 4 2.2.3 Input Domain Reduction 4 2.2.4 Evolutionary Testing 5 2.2.5 EvoUnit – Evolutionary Class Tester 6 2.3 Aspect-Oriented Programming 6 2.3.1 AspectJ: AOP Extension to Java 7 2.4 Testing Aspect-Oriented Software 8 2.4.1 Related Work 9 2.2.2 Automated Testing of Aspect-Oriented Software 10 2.7 Conclusion 10 Chapter 3: Research Questions 11 3.1 Random Testing vs. Evolutionary Testing 11 3.1.1 Which technique achieves better branch coverage in aspects? 11 3.1.2 Which technique takes less effort to test aspect-oriented programs? 11 3.2 Impact of Input Domain Reduction on Evolutionary Testing 11 3.2.1 What is the impact on effort for testing branches with input domain reduction? 11 3.2.2 What is the impact on overall code coverage with input domain reduction? 11 3.3 Testing Aspect-Oriented Programming Specific Structures 11 3.3.1 What effect do testing AOP specific structures have on effort? 11 3.3.2 What is the impact of testing AOP specific structures on code coverage? 11 Chapter 4: Framework 12 4.1 Overview 12 4.2 Framework for Automated Testing of Aspect-Oriented Programs 12 4.3 Input Domain Reduction Framework for Evolutionary Testing 13 4.6 Conclusion 14 iii TABLE OF CONTENTS Chapter 5: Software Specification 15 5.1 Overview 15 5.2 Functional Requirements 15 5.2.1 Software Input 15 5.2.1 Software Output 15 5.2.1 Software Components 16 5.3 Non-Functional Requirements 17 5.2.1 Reliability 17 5.2.1 Performance 17 5.2.1 Storage 17 5.6 Conclusion 17 Chapter 6: Design & Implementation 18 6.1 Overview 18 6.2 Component Connection Architecture 18 6.3 Algorithms 19 6.4 Tool Implementation 22 6.4.1 Jusc Modification 22 6.4.2 Indus Slicer Modification 22 6.4.3 Software Output 23 6.5 Conclusion 30 Chapter 7: Empirical Study 31 7.1 Test Subjects 31 7.2 Random Testing vs. Evolutionary Testing 32 7.2.1 Research Questions 32 7.2.2 Metrics and Measures 32 7.2.3 Experimental Steps 32 7.2.4 Experiment Results 33 7.2.5 Summary of Findings 37 7.3 Impact of Input Domain Reduction on Evolutionary Testing 38 7.3.1 Research Questions 38 7.3.2 Metrics and Measures 38 7.3.3 Experimental Steps 38 7.3.4 Experiment Results 39 7.3.4 Statistical Analysis 48 7.3.5 Summary of Findings 50 7.4 Testing AOP Specific Structures 51 6.4.1 Research Questions 51 6.4.2 Metrics and Measures 51 6.4.3 Experimental Steps 51 6.4.4 Experiment Results 52 6.4.4 Statistical Analysis 56 6.4.5 Summary of Findings 58 7.5 Threats to Validity 59 Chapter 8: Project Review 60 8.1 Future Work 60 8.2 Conclusion 61 References and Bibliography 63 iv TABLE OF CONTENTS Appendices Appendix A: Experiment Results A-1 Appendix B: Instruction Manual B-1 Appendix C: Program Code C-1 v LIST OF TABLES List of Tables Table Index: Chapter 6: Design & Implementation 6.1 Algorithms for AspectJ Compiler & Code Converter Component 19 6.2 Algorithm for Java Compiler Component 19 6.3 Algorithm for Branch Identifier Component 20 6.4 Algorithm for Code Slicer Component 20 6.5 Algorithms for Code Parser & Code Transformer Components 21 6.6 Algorithms for Test Goal Generator & Test Goal Runner Components 21 6.7 Algorithm for Coverage Calculator Component 21 Chapter 7: Empirical Study 7.1 AspectJ Test Subjects 31 7.2 Classes under Test 33 7.3 Branches with Irrelevant Parameters 39 7.4 Irrelevant Parameter Count 40 7.5 Branches with Effort Increase 44 7.6 Coverage Comparison with Random Testing 47 7.7 Effort Reduction 49 7.4 Target Branches Reduction 53 7.5 Effort Reduction in Classes 57 7.6 Coverage Comparison with Random Testing 47 Appendix A: Experiment Results A.1 Effort Reduction in Classes A-1 A.2 Coverage Improvement in Programs A-1 A.3 Coverage Improvement in Branches A-3 A.4 Effort Reduction in Branches A-4 A.5 Effort for branch DCM7F A-5 A.6 Effort for branch DCM11F A-5 A.7 Effort for branch DCM11T A-5 A.8 Effort for branch DCM13F A-5 A.9 Effort for branch DCM5F A-6 A.10 Effort for branch DCM19F A-6 A.11 Effort for branch DCM20T A-6 A.12 Effort for branch NullCheck1F A-6 A.13 Effort for branch Queue0T A-7 A.14 Effort for branch Queue3T A-7 A.15 Effort for branch Queue4T A-7 A.16 Effort for branch Queue5F A-7 A.17 Effort Reduction in Branches A-8 A.18 Coverage Improvement in Programs A-9 vi List of Figures Figure Index: Chapter 2: Literature Review 2.1 Backward Slicing Example 4 2.2 Pictorial Representation of Approximation Level for Fitness Calculations 5 2.3 Aspects cross-cutting classes in Figure editor program 7 2.4 Sample AspectJ Code for Hello Program 8 Chapter 4: Framework 4.1 Framework for Automated Testing of Aspect-oriented programs 12 4.2 Framework for Input Domain Reduction for Evolutionary Testing of Aspect-oriented programs 13 Chapter 6: Design & Implementation 6.1 Software Component Connection Architecture 18 6.2 Screenshot of branch list output file 24 6.3 Screenshot of slice output 25 6.4 Screenshot of info file 25 6.5 Screenshot of test goal list file 26 6.6 Screenshot of effort list file 27 6.7 Screenshot of runtime list file 28 6.8 Screenshot of iteration coverage report file 29 6.9 Screenshot of overall coverage report file 29 Chapter 7: Empirical Study 7.1 Effort reduction in Classes 34 7.2 Effort reduction in Programs 35 7.3 Coverage Comparison in Programs 36 7.4 Input Domain Reduction 42 7.5 Effort reduction in Branches 43 7.6 Effort reduction in Programs 45 7.7 Branch Coverage Improvement 46 7.8 Effort reduction in Classes 54 7.9 Effort reduction in Programs 55 7.10 Coverage Improvement in programs 56 vii CHAPTER 1: INTRODUCTION Chapter-1 Introduction 1.1 Background Aspect-oriented Programming (AOP) is a new technology that helps programmers to separate cross- cutting concerns known as aspects.
Load more

Recommended publications
  • 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]
  • 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]
  • Oracle FLEXCUBE Private Banking Release Notes
    Product Release Notes Oracle FLEXCUBE Private Banking Release 12.1.0.0.0 [April] [2016] Product Release Notes Table of Contents 1. INTRODUCTION ........................................................................................................................................... 1-1 1.1 PURPOSE ..................................................................................................................................................... 1-1 1.2 BACKGROUND/ENVIRONMENT ................................................................................................................... 1-1 1.3 THIRD PARTY SOFTWARE DETAILS ............................................................................................................ 1-2 1.4 RELEASE CONTENTS ................................................................................................................................... 1-4 1.5 PRODUCT DOCUMENTATION ....................................................................................................................... 1-5 2. COMPONENTS OF THE RELEASE ........................................................................................................... 2-1 2.1 DOCUMENTS ACCOMPANYING THE SOFTWARE ............................................................................................ 2-1 2.2 SOFTWARE COMPONENTS ........................................................................................................................... 2-1 1. Introduction 1.1 Purpose Purpose of this Release Note is to highlight the
    [Show full text]
  • Eclipse Governance Structure
    Eclipse Governance Structure Board of Directors A p p rov es S trateg y , P lans, P olicies E clip se M anag em ent O rg aniz ation E stab lish es th e R oadm ap , Bu ilds th e P latform , Deliv ers th e V ision R eq u irem ents C ou ncil P rop oses T h em es M em b ersh ip at L arg e & P riorities A p p rov es V ision, By law s Bu ilds th e E cosy stem P lanning C ou ncil A rch itectu re C ou ncil E stab lish es P latform Defines & M aintains R elease P lan A rch itectu re S u b com m ittee A S u b com m ittee B P M C 1 P M C 2 P M C 3 P M C 4 P M C 4 P M C 5 P M C 6 P M C 7 Project Management Committees Eclipse Foundation, Inc. Eclipse Development Roadmap ° http://www.eclipse.org/org/councils/roadmap.html ° Communicate the direction and timetable of the Eclipse projects ° Solicits for input from key stakeholders ° Create an open predictable environment to enable planning for commercial adoption ° Predictable schedule of new releases ° Understand technology direction ° Eclipse Roadmap consists of: ° Themes and Priorities ° Schedules ° Architecture Plan ° Will be update every 6 months ° First iteration done March 2005 Eclipse Foundation, Inc. Eclipse Roadmap: Development Councils Strategic Members PMC T&P’s Requirements Council Add-in Providers Market research T h P e r m io e ri s & ti s e & e s s e m ti e ri h o T ri P Platform Release Planning Architecture Council Architecture Plan Council P P M M C C P A l r a c n h s Eclipse Foundation, Inc.
    [Show full text]
  • Creating a Modular Aspectj Foundation for Simple and Rapid Extension Implementation By
    Creating a Modular AspectJ Foundation for Simple and Rapid Extension Implementation by Hristofor Mirche E!I FM" E#AMI$A"I%$ C%MMI""EE dr& C&M& 'oc(isch prof&dr&ir& M& A(sit )*&*+&,*-. Abstract "he current state of aspect/oriented programming 0A%1) has raised concerns regarding arious limitations that A%1 languages ha e& "he issue is that A%1 languages are not robust enough 3hen the basis program is changed& "here are many ne3 proposals for A%1 languages 3ith ne3 features that attempt to restrict or gi e more expressi eness to the programmer in order to force a ne3 context 3here the problems can be mitigated& Some of those languages are designed as extensions of AspectJ. Existing open AspectJ compilers can be used for implementing such an extension, but this can 5uic(ly become a complicated task of extending the complex processes of lexing4 parsing and 3ea ing4 of 3hich the compilers o6er lo3/le el abstractions& "hus4 there is a need for an easily extensible AspectJ foundation for a simpler and faster de elopment of language extensions& !e ha e de eloped such a foundation and in this thesis 3e describe the design of the implementation. !e pro ide an o er ie3 of a testing process to determine its alidity& Finally4 3e implement one proposal for an AspectJ extension and e aluate the extensibility and ease of use of our foundation in comparison to other existing AspectJ compilers& -& Introduction Moti ation& An easy approach to implement an aspect/oriented language 3ould be to extend an existing A%P compiler& "his is not al3ays the best approach4
    [Show full text]
  • Developing Java™ Web Applications
    ECLIPSE WEB TOOLS PLATFORM the eclipse series SERIES EDITORS Erich Gamma ■ Lee Nackman ■ John Wiegand Eclipse is a universal tool platform, an open extensible integrated development envi- ronment (IDE) for anything and nothing in particular. Eclipse represents one of the most exciting initiatives hatched from the world of application development in a long time, and it has the considerable support of the leading companies and organ- izations in the technology sector. Eclipse is gaining widespread acceptance in both the commercial and academic arenas. The Eclipse Series from Addison-Wesley is the definitive series of books dedicated to the Eclipse platform. Books in the series promise to bring you the key technical information you need to analyze Eclipse, high-quality insight into this powerful technology, and the practical advice you need to build tools to support this evolu- tionary Open Source platform. Leading experts Erich Gamma, Lee Nackman, and John Wiegand are the series editors. Titles in the Eclipse Series John Arthorne and Chris Laffra Official Eclipse 3.0 FAQs 0-321-26838-5 Frank Budinsky, David Steinberg, Ed Merks, Ray Ellersick, and Timothy J. Grose Eclipse Modeling Framework 0-131-42542-0 David Carlson Eclipse Distilled 0-321-28815-7 Eric Clayberg and Dan Rubel Eclipse: Building Commercial-Quality Plug-Ins, Second Edition 0-321-42672-X Adrian Colyer,Andy Clement, George Harley, and Matthew Webster Eclipse AspectJ:Aspect-Oriented Programming with AspectJ and the Eclipse AspectJ Development Tools 0-321-24587-3 Erich Gamma and
    [Show full text]
  • Flexibility at the Roots of Eclipse
    6°ÊÈ >ʽäÇ Dynamic Wizard Modeling with GMF Introduction to the Using GMF to Build a Dynamic Wizard Generic Eclipse Framework and a Graphical Editor Modeling System Developing a Deploying the BIRT Graphical Modeling Viewer to JBoss Tool for Eclipse Disseminate Report Content to an Application Server Subversive The Eclipse Enabling Plug-In for Integration and Subversion Interoperability for Eclipse based Development An Introduction to the Corona Project Flexibility at the Roots of Eclipse Solving the GUI Dilemma: SWTSwing and Eclipse on Swing 6°ÊÈ >ʽäÇ Vol.6 January 2007 Dynamic Wizard Modeling with GMF Introduction to the Using GMF to Build a Dynamic Wizard Generic Eclipse Table of Contents Framework and a Graphical Editor Modeling System Developing a Deploying the BIRT Graphical Modeling Viewer to JBoss Tool for Eclipse Disseminate Report Content to an Application Server Subversive The Eclipse Enabling Plug-In for Integration and Subversion FEATURES Interoperability for Eclipse based Development An Introduction to the Corona Project Flexibility at the Roots of Eclipse 29 Flexibility at the Roots of Eclipse Solving the GUI Dilemma: SWTSwing and Eclipse on Solving the GUI Dilemma: Swing SWTSwing and Eclipse on Swing No trench in the world of Java is deeper then that between SWT and Swing or Eclipse and Sun. Unity is only found in the knowledge that everybody suff ers from this argument. But how to end this almost religious battle over the righteous GUI-toolkit? How to bang their heads together if they only know DEPARTMENT one point of view—for them or against them! Th e sister projects SWTSwing and Eclipse on Swing News & Trends (EOS) achieve this trick.
    [Show full text]
  • Understanding and Characterizing Changes in Bugs Priority: the Practitioners’ Perceptive
    Understanding and Characterizing Changes in Bugs Priority: The Practitioners’ Perceptive Rafi Almhana Thiago Ferreira Marouane Kessentini Tushar Sharma Dept. of Computer Science Dept. of Computer Science Dept. Computer Science Research Scientist University of Michigan University of Michigan University of Michigan Siemens Corporate Technology [email protected] [email protected] [email protected] [email protected] Abstract—Assigning appropriate priority to bugs is critical for for automated validation of bug priority change requests, and timely addressing important software maintenance issues. An better documentation of these changes. The goal of this paper underlying aspect is the effectiveness of assigning priorities: if is to characterize the overall change process of bugs’ priority. the priorities of a fair number of bugs are changed, it indicates delays in fixing critical bugs. There has been little prior work We advocate that a critical and fundamental step in provid- on understanding the dynamics of changing bug priorities. In ing efficient support for managers and developers to enable this paper, we performed an empirical study to observe and them to validate bugs priority change is to understand the understand the changes in bugs’ priority to build a 3-W model bugs priority dynamics; it involves discover and characterize on Why and When bug priorities change, and Who performs the Why When Who change. We conducted interviews and a survey with practitioners and bug priorities change, and performs the as well as performed a quantitative analysis containing 225,000 change. Thus, the primary goal of this paper is to observe bug reports, developers’ comments, and source code changes and understand the changes in bugs priority to build a 3- from 24 open-source systems.
    [Show full text]
  • The Spring IDE Plug-In for Eclipse
    Minter_685-4App.fm Page 229 Wednesday, November 7, 2007 1:49 PM APPENDIX ■ ■ ■ The Spring IDE Plug-in for Eclipse The Spring IDE plug-in for Eclipse enhances the Eclipse environment by providing a variety of features that make it easier to work with Spring projects. The Spring IDE provides tools for creating, validating, viewing, and editing your Spring configuration files. A particu- larly attractive feature is the provision of autocompletion when editing bean definitions. Although the Spring IDE is a separate project from Spring itself, there are developers who participate in both projects, so there is excellent support for the latest Spring features. In this appendix, I discuss the installation of the Spring IDE and then briefly present the features related to editing and viewing bean and Spring Web Flow definitions. It is not possible to discuss all of the Spring IDE features in depth in this appendix. I would recommend installing and working with the plug-in initially as an aid to the creation of bean definition files. The autocompletion feature works in a manner nearly identical to the Java source autocompletion features. After you are familiar with these aspects of the plug-in, you should visit the Spring IDE website (http://springide.org/) to learn more about the tool. Installing the Plug-in Although it is possible to download the Spring IDE components and install them manually, by far the easiest way to install the Spring IDE into Eclipse is to use the built-in Software Updates feature of the Eclipse environment. Version 2 of the Spring IDE supports versions of Spring up to and including Spring 2.1 and up to version 1 of Spring Web Flow.
    [Show full text]
  • A Domain Specific Aspect Language for IDE Events Johan Fabry, Romain Robbes, Marcus Denker
    DIE: A Domain Specific Aspect Language for IDE Events Johan Fabry, Romain Robbes, Marcus Denker To cite this version: Johan Fabry, Romain Robbes, Marcus Denker. DIE: A Domain Specific Aspect Language for IDE Events. Journal of Universal Computer Science, Graz University of Technology, Institut für Informa- tionssysteme und Computer Medien, 2014, 20 (2), pp.135-168. hal-00936376 HAL Id: hal-00936376 https://hal.inria.fr/hal-00936376 Submitted on 25 Jan 2014 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. DIE: A Domain Specific Aspect Language for IDE Events Johan Fabry, Romain Robbes (PLEIAD Lab, Computer Science Department (DCC), University of Chile, Santiago, Chile {jfabry / rrobbes}@dcc.uchile.cl) Marcus Denker (RMoD, INRIA Lille Nord Europe Lille, France [email protected]) Abstract Integrated development environments (IDEs) have become the primary way to develop software. Besides just using the built-in features, it becomes more and more important to be able to extend the IDE with new features and extensions. Plugin architectures exist, but they show weaknesses related to unanticipated extensions and event handling. In this paper, we argue that a more general solution for extending IDEs is needed.
    [Show full text]