An exploratory study of the effect of aspect-oriented programming on maintainability

In this paper we describe an exploratory assessment of the effect of aspect-oriented programming on software maintainability. An experiment was conducted in which 11 software professionals were asked to carry out maintenance tasks on one of two programs. The first program was written in Java and the second in AspectJ. Both programs implement a shopping system according to the same set of requirements. A number of statistical hypotheses were tested. The results did seem to suggest a slight advantage for the subjects using the object-oriented system since in general it took the subjects less time to answer the questions on this system. Also, both systems appeared to be equally difficult to modify. However, the results did not show a statistically significant influence of aspect-oriented programming at the 5% level. We are aware that the results of this single small study cannot be generalized. We conclude that more empirical research is necessary in this area to identify the benefits of aspect-oriented programming and we hope that this paper will encourage such research.

An empirical analysis of package-modularization metrics: Implications for software fault-proneness

ContextIn a large object-oriented software system, packages play the role of modules which group related classes together to provide well-identified services to the rest of the system. In this context, it is widely believed that modularization has a large influence on the quality of packages. Recently, Sarkar, Kak, and Rama proposed a set of new metrics to characterize the modularization quality of packages from important perspectives such as inter-module call traffic, state access violations, fragile base-class design, programming to interface, and plugin pollution. These package-modularization metrics are quite different from traditional package-level metrics, which measure software quality mainly from size, extensibility, responsibility, independence, abstractness, and instability perspectives. As such, it is expected that these package-modularization metrics should be useful predictors for fault-proneness. However, little is currently known on their actual usefulness for fault-proneness prediction, especially compared with traditional package-level metrics.ObjectiveIn this paper, we examine the role of these new package-modularization metrics for determining software fault-proneness in object-oriented systems.MethodWe first use principal component analysis to analyze whether these new package-modularization metrics capture additional information compared with traditional package-level metrics. Second, we employ univariate prediction models to investigate how these new package-modularization metrics are related to fault-proneness. Finally, we build multivariate prediction models to examine the ability of these new package-modularization metrics for predicting fault-prone packages.ResultsOur results, based on six open-source object-oriented software systems, show that: (1) these new package-modularization metrics provide new and complementary views of software complexity compared with traditional package-level metrics; (2) most of these new package-modularization metrics have a significant association with fault-proneness in an expected direction; and (3) these new package-modularization metrics can substantially improve the effectiveness of fault-proneness prediction when used with traditional package-level metrics together.ConclusionsThe package-modularization metrics proposed by Sarkar, Kak, and Rama are useful for practitioners to develop quality software systems.     

An empirical validation of object-oriented metrics in two different iterative software processes

Object-oriented (OO) metrics are used mainly to predict software engineering activities/efforts such as maintenance effort, error proneness, and error rate. There have been discussions about the effectiveness of metrics in different contexts. In this paper, we present an empirical study of OO metrics in two iterative processes: the short-cycled agile process and the long-cycled framework evolution process. We find that OO metrics are effective in predicting design efforts and source lines of code added, changed, and deleted in the short-cycled agile process and ineffective in predicting the same aspects in the long-cycled framework process. This leads us to believe that OO metrics' predictive capability is limited to the design and implementation changes during the development iterations, not the long-term evolution of an established system in different releases.     

An aspect-oriented methodology for designing secure applications

We propose a methodology, based on aspect-oriented modeling (AOM), for incorporating security mechanisms in an application. The functionality of the application is described using the primary model and the attacks are specified using aspects. The attack aspect is composed with the primary model to obtain the misuse model. The misuse model describes how much the application can be compromised. If the results are unacceptable, then some security mechanism must be incorporated into the application. The security mechanism, modeled as security aspect, is composed with the primary model to obtain the security-treated model. The security-treated model is analyzed to give assurance that it is resilient to the attack.     

An empirical study of FORTRAN programs

A sample of programs, written in FORTRAN by a wide variety of people for a wide variety of applications, was chosen ‘at random’ in an attempt to discover quantitatively ‘what programmers really do’. Statistical results of this survey are presented here, together with some of their apparent implications for future work in compiler design. The principal conclusion which may be drawn is the importance of a program ‘profile’, namely a table of frequency counts which record how often each statement is performed in a typical run; there are strong indications that profile-keeping should become a standard practice in all computer systems, for casual users as well as system programmers. This paper is the report of a three month study undertaken by the author and about a dozen students and representatives of the software industry during the summer of 1970. It is hoped that a reader who studies this report will obtain a fairly clear conception of how FORTRAN is being used, and what compilers can do about it.     

An empirical study of interest-based negotiation

While argumentation-based negotiation has been accepted as a promising alternative to game-theoretic or heuristic-based negotiation, no evidence has been provided to confirm this theoretical advantage. We propose a model of bilateral negotiation extending a simple monotonic concession protocol by allowing the agents to exchange information about their underlying interests and possible alternatives to achieve them during the negotiation. We present an empirical study that demonstrates (through simulation) the advantages of this interest-based negotiation approach over the more classic monotonic concession approach to negotiation.     

An approach to implementation of aspect-oriented programming for C

This paper describes an approach to implementation of aspect-oriented programming (AOP) frameworks for C, outlines traditional AOP facilities for different programming languages, and shows how specific features of C and a build process of C programs affect AOP implementations. Next, we consider additional requirements imposed by a practical application of AOP implementations for C programs. Existing solutions are described and possibility of their use is analyzed. The paper describes a new AOP tool for C that implements the proposed approach and demonstrates its capabilities.     

An empirical study of Java bytecode programs

We present a study of the static structure of real Java bytecode programs. A total of 1132 Java jar‐files were collected from the Internet and analyzed. In addition to simple counts (number of methods per class, number of bytecode instructions per method, etc.), structural metrics such as the complexity of control‐flow and inheritance graphs were computed. We believe this study will be valuable in the design of future programming languages and virtual machine instruction sets, as well as in the efficient implementation of compilers and other language processors. Copyright © 2006 John Wiley & Sons, Ltd.     

An empirical study of fine-grained software modifications

Software is typically improved and modified in small increments (we refer to each of these increments as a modification record—MR). MRs are usually stored in a configuration management or version control system and can be retrieved for analysis. In this study we retrieved the MRs from several mature open software projects. We then concentrated our analysis on those MRs that fix defects and provided heuristics to automatically classify them. We used the information in the MRs to visualize what files are changed at the same time, and who are the people who tend to modify certain files. We argue that these visualizations can be used to understand the development stage of in which a project is at a given time (new features are added, or defects are being fixed), the level of modularization of a project, and how developers might interact between each other and the source code of a system.     

An empirical study of software release notes

Release notes are an important source of information about a new software release. Such notes contain information regarding what is new, changed, and/or got fixed in a release. Despite the importance of release notes, they are rarely explored in the research literature. Little is known about the contained information, e.g., contents and structure, in release notes. To better understand the types of contained information in release notes, we manually analyzed 85 release notes across 15 different software systems. In our manual analysis, we identify six different types of information (e.g., caveats and addressed issues) that are contained in release notes. Addressed issues refer to new features, bugs, and improvements that were integrated in that particular release. We observe that most release notes list only a selected number of addressed issues (i.e., 6-26 % of all addressed issues in a release). We investigated nine different factors (e.g., issue priority and type) to better understand the likelihood of an issue being listed in release notes. The investigation is conducted on eight release notes of three software systems using four machine learning techniques. Results show that certain factors, e.g., issue type, have higher influence on the likelihood of an issue to be listed in release notes. We use machine learning techniques to automatically suggest the issues to be listed in release notes. Our results show that issues listed in all release notes can be automatically determined with an average precision of 84 % and an average recall of 90 %. To train and build the classification models, we also explored three scenarios: (a) having the user label some issues for a release and automatically suggest the remaining issues for that particular release, (b) using the previous release notes for the same software system, and (c) using prior releases for the current software system and the rest of the studied software systems. Our results show that the content of release notes vary between software systems and across the versions of the same software system. Nevertheless, automated techniques can provide reasonable support to the writers of such notes with little training data. Our study provides developers with empirically-supported advice about release notes instead of simply relying on adhoc advice from on-line inquiries.     

An empirical study of programming language trends

Predicting software engineering trends is a strategically important asset for both developers and managers, but it's also difficult, due to the wide range of factors involved and the complexity of their interactions. This paper reveals some interesting trends and a method for studying other important software engineering trends. This article trades breadth for depth by focusing on a small, compact set of trends involving 17 high-level programming languages. We quantified many of their relevant factors, and then collected data on their evolution over 10 years. By applying statistical methods to this data, we aim to gain insight into what does and does not make a language successful.     

An empirical study of object-oriented system evolution

Software metrics have been used to measure software artifacts statically—measurements are taken after the artifacts are created. In this study, three metrics—System Design Instability (SDI), Class Implementation Instability (CII), and System Implementation Instability (SII)—are used for the purpose of measuring object-oriented (OO) software evolution. The metrics are used to track the evolution of an OO system in an empirical study. We found that once an OO project starts, the metrics can give good indications of project progress, e.g. how mature the design and implementation is. This information can be used to adjust the project plan in real time.We also performed a study of design instability that examines how the implementation of a class can affect its design. This study determines that some aspects of OO design are independent of implementation, while other aspects are dependent on implementation.     

An empirical study of subjective road categorization

Abstract

Driver behaviour will partially be a function of the cognitive schemata by which drivers represent features, functions and operations of traffic system components. This paper uses the Repertory Grid Technique to address the questions: (1) How do drivers internally represent different categories of road? (2) How are those representations mapped on to ‘official’ road categories?

A factor analysis of data obtained from 40 subjects revealed, in answer to question (1), that four factors, namely, ‘safety’; ‘urban/rural’; ‘road boundaries/slip-roads’; and ‘markings’; accounted for 82·3% of the variance. Multidimensional scaling and clustering analyses showed that subjective categorizations of roads are closely related to their objective physical characteristics, but less-well determined by ‘official’ road categories.

Certain features (e.g. slip-roads, markings, obstacle-free boundaries) appear to contribute little to the subjective safety of roads. This suggests that the potential benefits of these safety features may be fully achieved since risk compensation mechanisms will not operate.     

An aspect-oriented approach for the systematic security hardening of code

In this paper, we present an aspect-oriented approach for the systematic security hardening of source code. It aims at allowing developers to perform software security hardening by providing an abstraction over the actions required to improve the security of the program. This is done by giving them the capabilities to specify high-level security hardening plans that leverage a priori defined security hardening patterns. These patterns describe the required steps and actions to harden security code, including detailed information on how and where to inject the security code. We show the viability and relevance of our approach by: (1) elaborating security hardening patterns and plans to common security hardening practices, (2) realizing these patterns by implementing them into aspect-oriented languages, (3) applying them to secure applications, (4) testing the hardened applications. Furthermore, we discuss, in this paper, our insights on the appropriateness, strengths and limitations of the aspect-oriented paradigm for security hardening.     

Stability assessment of aspect-oriented software architectures: A quantitative study

Design of stable software architectures has increasingly been a deep challenge to software developers due to the high volatility of their concerns and respective design decisions. Architecture stability is the ability of the high-level design units to sustain their modularity properties and not succumb to modifications. Architectural aspects are new modularity units aimed at improving design stability through the modularization of otherwise crosscutting concerns. However, there is no empirical knowledge about the positive and negative influences of aspectual decompositions on architecture stability. This paper presents an exploratory analysis of the influence exerted by aspect-oriented composition mechanisms in the stability of architectural modules addressing typical crosscutting concerns, such as error handling and security. Our investigation encompassed a comparative analysis of aspectual and non-aspectual decompositions based on different architectural styles applied to an evolving multi-agent software architecture. In particular, we assessed various facets of components’ and compositions’ stability through such alternative designs of the same multi-agent system using conventional quantitative indicators. We have also investigated the key characteristics of aspectual decompositions that led to (in)stabilities being observed in the target architectural options. The evaluation focused upon a number of architecturally-relevant changes that are typically performed through real-life maintenance tasks.     

An empirical study into COBOL type inferencing

In a typical COBOL program, the data division consists of 50% of the lines of code. Automatic type inference can help to understand the large collections of variable declarations contained therein, showing how variables are related based on their actual usage. The most problematic aspect of type inference is pollution, the phenomenon that types become too large, and contain variables that intuitively should not belong to the same type. The aim of the paper is to provide empirical evidence for the hypothesis that the use of subtyping is an effective way for dealing with pollution. The main results include a tool set to carry out type inference experiments, a suite of metrics characterizing type inference outcomes, and the experimental observation that only one instance of pollution occurs in the case study conducted.     

Cooperative aspect-oriented programming

Aspect-oriented programming (AOP) seeks to improve software modularity via the separation of cross-cutting concerns. AOP proponents often advocate a development strategy where programmers write the main application (base code), ignoring cross-cutting concerns, and then aspect programmers, domain experts in their specific concerns, weave in the logic for these more specialized cross-cutting concerns. This purely oblivious strategy, however, has empirically been shown to tightly couple aspects to base code in many cases, hindering aspect modularity and reuse. In essence, the more intricate the weaving between the cross-cutting concern and the base code (lexically and/or semantically), the harder it becomes to: (a) robustly specify how to weave the aspects in at the required points, (b) capture interactions between aspects and base code, and (c) preserve the correct weaving as the base code evolves.We propose an alternate methodology, termed cooperative aspect-oriented programming (Co-AOP), where complete lexical separation of concerns is not taken as an absolute requirement. Instead, cross-cutting concerns are explicitly modeled as abstract interfaces through explicit join points (EJPs). Programmers specify where these interfaces interact with base code either through explicit lexical references or via traditional oblivious aspects. This explicit awareness allows base code and aspects to cooperate in ways that were previously not possible: arbitrary blocks of code can be advised, advice can be explicitly parameterized, base code can guide aspects in where to apply advice, and aspects can statically enforce new constraints upon the base code that they advise. These new techniques allow aspect modularity and program safety to increase, and bring us towards a cooperative AOP paradigm.We illustrate our methodology via an example on transactions, and also give an initial evaluation of cooperative AOP through an empirical study on program extensibility comparing both the traditional and cooperative AOP methodologies. Initial results show that cooperative AOP techniques result in code that is less complex with lower overall coupling, facilitating extensibility.     

An empirical study of Android Wear user complaints

Wearable apps are becoming increasingly popular in recent years. Nevertheless, to date, very few studies have examined the issues that wearable apps face. Prior studies showed that user reviews contain a plethora of insights that can be used to understand quality issues and help developers build better quality mobile apps. Therefore, in this paper, we mine user reviews in order to understand the user complaints about wearable apps. We manually sample and categorize 2,667 reviews from 19 Android wearable apps. Additionally, we examine the replies posted by developers in response to user complaints. This allows us to determine the type of complaints that developers care about the most, and to identify problems that despite being important to users, do not receive a proper response from developers. Our findings indicate that the most frequent complaints are related to Functional Errors, Cost, and Lack of Functionality, whereas the most negatively impacting complaints are related to Installation Problems, Device Compatibility, and Privacy & Ethical Issues. We also find that developers mostly reply to complaints related to Privacy & Ethical Issues, Performance Issues, and notification related issues. Furthermore, we observe that when developers reply, they tend to provide a solution, request more details, or let the user know that they are working on a solution. Lastly, we compare our findings on wearable apps with the study done by Khalid et al. (2015) on handheld devices. From this, we find that some complaint types that appear in handheld apps also appear in wearable apps; though wearable apps have unique issues related to Lack of Functionality, Installation Problems, Connection & Sync, Spam Notifications, and Missing Notifications. Our results highlight the issues that users of wearable apps face the most, and the issues to which developers should pay additional attention to due to their negative impact.