Aspect] is a simple and practical aspect-oriented extension to Java With just a few new constructs, AspectJ provides support for modular implementation of a range of crosscutting concerns. In AspectJ's dynamic join point model, join points are well-defined points in the execution of the program; pointcuts are collections of join points; advice are special method-like constructs that can be attached to pointcuts; and aspects are modular units of crosscutting implementation, comprising pointcuts, advice, and ordinary Java member declarations. AspectJ code is compiled into standard Java bytecode. Simple extensions to existing Java development environments make it possible to browse the crosscutting structure of aspects in the same kind of way as one browses the inheritance structure of classes. Several examples show that AspectJ is powerful, and that programs written using it are easy to understand.

An overview of AspectJ

Inevitably, reading is one of the requirements to be undergone. To improve the performance and quality, someone needs to have something new every day. It will suggest you to have more inspirations, then. However, the needs of inspirations will make you searching for some sources. Even from the other people experience, internet, and many books. Books and internet are the recommended media to help you improving your quality and performance.

Feature-Oriented Software Product Lines

Software-product-line engineering has gained considerable momentum in recent years, both in industry and in academia. A software product line is a family of software products that share a common set of features. Software product lines challenge traditional analysis techniques, such as type checking, model checking, and theorem proving, in their quest of ensuring correctness and reliability of software. Simply creating and analyzing all products of a product line is usually not feasible, due to the potentially exponential number of valid feature combinations. Recently, researchers began to develop analysis techniques that take the distinguishing properties of software product lines into account, for example, by checking feature-related code in isolation or by exploiting variability information during analysis. The emerging field of product-line analyses is both broad and diverse, so it is difficult for researchers and practitioners to understand their similarities and differences. We propose a classification of product-line analyses to enable systematic research and application. Based on our insights with classifying and comparing a corpus of 123 research articles, we develop a research agenda to guide future research on product-line analyses.

https://www.infosun.fim.uni-passau.de/publications/docs/TAK14.pdf

A Classification and Survey of Analysis Strategies for Software Product Lines

Over more than two decades, numerous variability modeling techniques have been introduced in academia and industry. However, little is known about the actual use of these techniques. While dozens of experience reports on software product line engineering exist, only very few focus on variability modeling. This lack of empirical data threatens the validity of existing techniques, and hinders their improvement. As part of our effort to improve empirical understanding of variability modeling, we present the results of a survey questionnaire distributed to industrial practitioners. These results provide insights into application scenarios and perceived benefits of variability modeling, the notations and tools used, the scale of industrial models, and experienced challenges and mitigation strategies.

https://gsd.uwaterloo.ca/sites/default/files/2013-vamos-survey.pdf

A survey of variability modeling in industrial practice

Variability modeling is essential for defining and managing the commonalities and variabilities in software product lines. Numerous variability modeling approaches exist today to support domain and application engineering activities. Most are based on feature modeling (FM) or decision modeling (DM), but so far no systematic comparison exists between these two classes of approaches. Over the last two decades many new features have been added to both FM and DM and it is tough to decide which approach to use for what purpose. This paper clarifies the relation between FM and DM. We aim to systematize the research field of variability modeling and to explore potential synergies. We compare multiple aspects of FM and DM ranging from historical origins and rationale, through syntactic and semantic richness, to tool support, identifying commonalities and differences. We hope that this effort will improve the understanding of the range of approaches to variability modeling by discussing the possible variations. This will provide insights to users considering adopting variability modeling in practice and to designers of new languages, such as the new OMG Common Variability Language.

/pdf/cool-features-and-tough-decisions-a-comparison-of-51gn5ncq6c.pdf

Cool features and tough decisions: a comparison of variability modeling approaches

Much system software can be configured at compile time to tailor it with respect to a broad range of supported hardware architectures and application domains. A good example is the Linux kernel, which provides more than 10,000 configurable features, growing rapidly.From the maintenance point of view, compile-time configurability imposes big challenges. The configuration model (the selectable features and their constraints as presented to the user) and the configurability that is actually implemented in the code have to be kept in sync, which, if performed manually, is a tedious and error-prone task. In the case of Linux, this has led to numerous defects in the source code, many of which are actual bugs.We suggest an approach to automatically check for configurability-related implementation defects in large-scale configurable system software. The configurability is extracted from its various implementation sources and examined for inconsistencies, which manifest in seemingly conditional code that is in fact unconditional. We evaluate our approach with the latest version of Linux, for which our tool detects 1,776 configurability defects, which manifest as dead/superfluous source code and bugs. Our findings have led to numerous source-code improvements and bug fixes in Linux: 123 patches (49 merged) fix 364 defects, 147 of which have been confirmed by the corresponding Linux developers and 20 as fixing a new bug.

Feature consistency in compile-time-configurable system software: facing the linux 10,000 feature problem

Nearly ten years after its first presentation and five years after its first application to operating systems, the suitability of Aspect-Oriented Programming (AOP) for the development of operating system kernels is still highly in dispute. While the AOP advocacy emphasizes the benefits of AOP towards better configurability and maintainability of system software, most kernel developers express a sound skepticism regarding the thereby induced runtime and memory costs: Operating system kernels have to be lean and efficient.We have analyzed the runtime and memory costs of aspects in general, on the level of μ-benchmarks, and by refactoring and extending the eCos operating system kernel using AspectC++, an AOP extension to the C++ language. Our results show that most AOP features do not induce a intrinsic overhead and that the actual overhead induced by AspectC++ is very low. We have also analyzed a test case with significant aspect-related costs. This example shows how the structure of the underlying kernel can have a negative impact on aspect implementations and how these costs can be avoided by an aspect-aware design.Based on this analysis, our conclusion is that AOP is suitable for the development of operating system kernels and other kinds of highly efficient infrastructure software.

/pdf/a-quantitative-analysis-of-aspects-in-the-ecos-kernel-5gm4322ulu.pdf

A quantitative analysis of aspects in the eCos kernel

With more than 11,000 optional and alternative features, the Linux kernel is a highly configurable piece of software. Linux is generally perceived as a textbook example for preprocessor-based product derivation, but more than 65 percent of all features are actually handled by the build system. Hence, variability-aware static analysis tools have to take the build system into account.However, extracting variability information from the build system is difficult due to the declarative and turing-complete make language. Existing approaches based on text processing do not cover this challenges and tend to be tailored to a specific Linux version and architecture. This renders them practically unusable as a basis for variability-aware tool support -- Linux is a moving target!We describe a robust approach for extracting implementation variability from the Linux build system. Instead of extracting the variability information by a text-based analysis of all build scripts, our approach exploits the build system itself to produce this information. As our results show, our approach is robust and works for all versions and architectures from the (git-)history of Linux.

/pdf/a-robust-approach-for-variability-extraction-from-the-linux-1y2c2izqlj.pdf

A robust approach for variability extraction from the Linux build system

The economy of mechanism security principle states that program design should be kept as small and simple as possible. In practice, this principle is often disregarded to maximize user satisfaction, resulting in systems supporting a vast number of features by default, which in turn offers attackers a large code base to exploit. The Linux kernel exemplifies this problem: distributors include a large number of features, such as support for exotic filesystems and socket types, and attackers often take advantage of those. A simple approach to produce a smaller kernel is to manually configure a tailored Linux kernel. However, the more than 11,000 configuration options available in recent Linux versions make this a time-consuming and non-trivial task. We design and implement an automated approach to produce a kernel configuration that is adapted to a particular workload and hardware, and present an attack surface evaluation framework for evaluating security improvements for the different kernels obtained. Our results show that, for real-world server use cases, the attack surface reduction obtained by tailoring the kernel ranges from about 50% to 85%. Therefore, kernel tailoring is an attractive approach to improve the security of the Linux

/pdf/attack-surface-metrics-and-automated-compile-time-os-kernel-54w904ql8t.pdf

Attack Surface Metrics and Automated Compile-Time OS Kernel Tailoring.

Context Software ecosystems are increasingly popular for their economic, strategic, and technical advantages. Application platforms such as Android or iOS allow users to highly customize a system by selecting desired functionality from a large variety of assets. This customization is achieved using variability mechanisms. Objective Variability mechanisms are well-researched in the context of software product lines. Although software ecosystems are often seen as conceptual successors, the technology that sustains their success and growth is much less understood. Our objective is to improve empirical understanding of variability mechanisms used in successful software ecosystems. Method We analyze five ecosystems, ranging from the Linux kernel through Eclipse to Android. A qualitative analysis identifies and characterizes variability mechanisms together with their organizational context. This analysis leads to a conceptual framework that unifies ecosystem-specific aspects using a common terminology. A quantitative analysis investigates scales, growth rates, and—most importantly—dependency structures of the ecosystems. Results In all the studied ecosystems, we identify rich dependency languages and variability descriptions that declare many direct and indirect dependencies. Indirect dependencies to abstract capabilities, as opposed to concrete variability units, are used predominantly in fast-growing ecosystems. We also find that variability models—while providing system-wide abstractions over code—work best in centralized variability management and are, thus, absent in ecosystems with large free markets. These latter ecosystems tend to emphasize maintaining capabilities and common vocabularies, dynamic discovery, and binding with strong encapsulation of contributions, together with uniform distribution channels. Conclusion The use of specialized mechanisms in software ecosystems with large free markets, as opposed to software product lines, calls for recognition of a new discipline—variability encouragement.

/pdf/variability-mechanisms-in-software-ecosystems-3i9sqg8ay6.pdf

Reinhard Tartler

Papers

Feature consistency in compile-time-configurable system software: facing the linux 10,000 feature problem

A quantitative analysis of aspects in the eCos kernel

A robust approach for variability extraction from the Linux build system

Attack Surface Metrics and Automated Compile-Time OS Kernel Tailoring.

Variability Mechanisms in Software Ecosystems