Feature diagrams are a popular means for documenting variability in software product line engineering. When examining feature diagrams in the literature and from industry, we observed that the same modelling concepts are used for documenting two different kinds of variability: (1) product line variability, which reflects decisions of product management on how the systems that belong to the product line should vary, and (2) software variability, which reflects the ability of the reusable product line artefacts to be customized or configured. To disambiguate the documentation of variability, we follow previous suggestions to relate orthogonal variability models (OVMs) to feature diagrams. This paper reuses an existing formalization of feature diagrams, but introduces a formalization of OVMs. Then, the relationships between the two kinds of models are formalized as well. Besides a precise definition of the languages and the links, the important benefit of this formalization is that it serves as a foundation for a tool supporting automated reasoning on variability. This tool can, e.g., analyse whether the product line artefacts are flexible enough to build all the systems that should belong to the product line. MotivationMany industry sectors face the challenge of how to satisfy the increasing demand for individualized software systems and software-intensive systems. The software product line (PL) engineering paradigm (SPLE, see [24]) has proven to empower organizations to develop a diversity of similar systems at lower cost, in shorter time, and with higher quality when compared with the development of single systems [24].Key to SPLE is to exploit the commonalities of the systems that belong to the PL and to handle the variation (i.e., the differences) between those systems. Commonalities are properties and qualities that are shared by all systems of the PL [14]; e.g., all mobile phones let users make calls. Two Kinds of VariabilityIn SPLE, two kinds of variability can be distinguished: Software variability and PL variability.Software variability refers to the "ability of a software system or artefact to be efficiently extended, changed, customized or configured for use in a particular context" [31]. This kind of variability is well known from the development of single systems. As examples, an abstract Java super-class allows different specializations to be used where the superclass is used; an interface allows different implementations to be chosen.PL variability [14,24,21] is specific to SPLE and describes the variation between the systems that belong to a PL in terms of properties and qualities, like features that are provided or requirements that are fulfilled. It is important to understand that defining PL variability, i.e., determining what should vary between the systems in a PL and what should not, is an explicit decision of product management (see [21,24]). As an example, product management might have decided that the mobile phones of their PL should either offer the GSM or the UMTS protocol.A chal...

Future software systems will operate in a highly dynamic world. Systems will need to operate correctly despite of unespected changes in factors such as environmental conditions, user requirements, technology, legal regulations, and market opportunities. They will have to operate in a constantly evolving environment that includes people, content, electronic devices, and legacy systems. They will thus need the ability to continuously adapt themselves in an automated manner to react to those changes. To realize dynamic, self-adaptive systems, the service concept has emerged as a suitable abstraction mechanism. Together with the concept of the service-oriented architecture (SOA), this led to the development of technologies, standards, and methods to build service-based applications by flexibly aggregating individual services. This article discusses how those concepts came to be by taking two complementary viewpoints. On the one hand, it evaluates the progress in software technologies and methodologies that led to the service concept and SOA. On the other hand, it discusses how the evolution of the requirements, and in particular business goals, influenced the progress towards highly dynamic self-adaptive systems. Finally, based on a discussion of the current state of the art, this article points out the possible future evolution of the field

No abstract

Software product line engineering has proven to empower organizations to develop a diversity of similar software-intensive systems (applications) at lower cost, in shorter time, and with higher quality when compared with the development of single systems. Over the last decade the software product line engineering research community has grown significantly. It has produced impressive research results both in terms of quality as well as quantity. We identified over 600 relevant research and experience papers published within the last seven years in established conferences and journals. We briefly summarize the major research achievements of these past seven years. We structure this research summary along a standardized software product line framework. Further, we outline current and future research challenges anticipated from major trends in software engineering and technology.

No abstract

Abstract-Cloud controllers support the operation and quality management of dynamic cloud architectures by automatically scaling the compute resources to meet performance guarantees and minimize resource costs. Existing cloud controllers often resort to scaling strategies that are codified as a set of architecture adaptation rules. However, for a cloud provider, deployed application architectures are black-boxes, making it difficult at design time to define optimal or pre-emptive adaptation rules. Thus, the burden of taking adaptation decisions often is delegated to the cloud application. We propose the dynamic learning of adaptation rules for deployed application architectures in the cloud. We introduce FQL4KE, a self-learning fuzzy controller that learns and modifies fuzzy rules at runtime. The benefit is that we do not have to rely solely on precise design-time knowledge, which may be difficult to acquire. FQL4KE empowers users to configure cloud controllers by simply adjusting weights representing priorities for architecture quality instead of defining complex rules. FQL4KE has been experimentally validated using the cloud application framework ElasticBench in Azure and OpenStack. The experimental results demonstrate that FQL4KE outperforms both a fuzzy controller without learning and the native Azure auto-scaling.

In practice, available testing budgets limit the number of test cases that can be executed. Thus, a representative subset of all possible test cases must be chosen to guarantee adequate coverage of a test object. In risk-based testing, the probability of a fault and the damage that this fault can cause when leading to a failure is considered for test case prioritization. Existing approaches for riskbased testing provide guidelines for deriving test cases. However, those guidelines lack the level of detail and precision needed for automation. In this contribution, we introduce the risk-based testing technique RiteDAP, which automatically generates system test cases from activity diagrams and prioritizes those test cases based on risk. The results of applying the technique to a practical example are presented and the ability of different prioritization strategies to uncover faults is evaluated.

Service-based applications have to continuously and dynamically selfadapt in order to timely react to changes in their context, as well as to efficiently accommodate for deviations from their expected functionality or quality of service. Currently, self-adaptation is triggered by monitoring events. Yet, monitoring only observes changes or deviations after they have occurred. Therefore, selfadaptation based on monitoring is reactive and thus often comes too late, e.g., when changes or deviations already have led to undesired consequences. In this paper we present the PROSA framework, which aims to enable proactive selfadaptation. To this end, PROSA exploits online testing techniques to detect changes and deviations before they can lead to undesired consequences. This paper introduces and illustrates the key online testing activities needed to trigger proactive adaptation, and it discusses how those activities can be implemented by utilizing and extending existing testing and adaptation techniques.