Matthias Galster

Variability in Software Systems—A Systematic Literature Review

Context: Variability (i.e., the ability of software systems or artifacts to be adjusted for different contexts) became a key property of many systems. Objective: We analyze existing research on variability in software systems. We investigate variability handling in major software engineering phases (e.g., requirements engineering, architecting). Method: We performed a systematic literature review. A manual search covered 13 premium software engineering journals and 18 premium conferences, resulting in 15,430 papers searched and 196 papers considered for analysis. To improve reliability and to increase reproducibility, we complemented the manual search with a targeted automated search. Results: Software quality attributes have not received much attention in the context of variability. Variability is studied in all software engineering phases, but testing is underrepresented. Data to motivate the applicability of current approaches are often insufficient; research designs are vaguely described. Conclusions: Based on our findings we propose dimensions of variability in software engineering. This empirically grounded classification provides a step towards a unifying, integrated perspective of variability in software systems, spanning across disparate or loosely coupled research themes in the software engineering community. Finally, we provide recommendations to bridge the gap between research and practice and point to opportunities for future research.

A Taxonomy for Identifying and Specifying Non-Functional Requirements in Service-Oriented Development

As in traditional software development, non-functional requirements play also a crucial role in service-oriented development. Non-functional requirements are spread across the entire service-oriented system or within individual services and cannot be allocated to one specific system / service artefact (such as a package, component). This makes them often more difficult to handle than functional requirements. The specifics of service-oriented architectures (in particular highly distributed services) bring up additional difficulties. In this paper, we present a taxonomy for non-functional requirements in a service-oriented context. The taxonomy implements three main categories of non-functional requirements: process requirements, non-functional external requirements, and non-functional service requirements. The taxonomy can be applied with individual services as well as with a service-based system as a whole. This taxonomy is considered as a starting point and check list when handling non-functional issues in service-oriented and particularly highly distributed environments.

Variability in quality attributes of service-based software systems: A systematic literature review

Context: Variability is the ability of a software artifact (e.g., a system, component) to be adapted for a specific context, in a preplanned manner. Variability not only affects functionality, but also quality attributes (e.g., security, performance). Service-based software systems consider variability in functionality implicitly by dynamic service composition. However, variability in quality attributes of service-based systems seems insufficiently addressed in current design practices. Objective: We aim at (a) assessing methods for handling variability in quality attributes of service-based systems, (b) collecting evidence about current research that suggests implications for practice, and (c) identifying open problems and areas for improvement. Method: A systematic literature review with an automated search was conducted. The review included studies published between the year 2000 and 2011. We identified 46 relevant studies. Results: Current methods focus on a few quality attributes, in particular performance and availability. Also, most methods use formal techniques. Furthermore, current studies do not provide enough evidence for practitioners to adopt proposed approaches. So far, variability in quality attributes has mainly been studied in laboratory settings rather than in industrial environments. Conclusions: The product line domain as the domain that traditionally deals with variability has only little impact on handling variability in quality attributes. The lack of tool support, the lack of practical research and evidence for the applicability of approaches to handle variability are obstacles for practitioners to adopt methods. Therefore, we suggest studies in industry (e.g., surveys) to collect data on how practitioners handle variability of quality attributes in service-based systems. For example, results of our study help formulate hypotheses and questions for such surveys. Based on needs in practice, new approaches can be proposed.

Past and future of software architectural decisions - A systematic mapping study

Abstract Context The software architecture of a system is the result of a set of architectural decisions. The topic of architectural decisions in software engineering has received significant attention in recent years. However, no systematic overview exists on the state of research on architectural decisions. Objective The goal of this study is to provide a systematic overview of the state of research on architectural decisions. Such an overview helps researchers reflect on previous research and plan future research. Furthermore, such an overview helps practitioners understand the state of research, and how research results can help practitioners in their architectural decision-making. Method We conducted a systematic mapping study, covering studies published between January 2002 and January 2012. We defined six research questions. We queried six reference databases and obtained an initial result set of 28,895 papers. We followed a search and filtering process that resulted in 144 relevant papers. Results After classifying the 144 relevant papers for each research question, we found that current research focuses on documenting architectural decisions. We found that only several studies describe architectural decisions from the industry. We identified potential future research topics: domain-specific architectural decisions (such as mobile), achieving specific quality attributes (such as reliability or scalability), uncertainty in decision-making, and group architectural decisions. Regarding empirical evaluations of the papers, around half of the papers use systematic empirical evaluation approaches (such as surveys, or case studies). Still, few papers on architectural decisions use experiments. Conclusion Our study confirms the increasing interest in the topic of architectural decisions. This study helps the community reflect on the past ten years of research on architectural decisions. Researchers are offered a number of promising future research directions, while practitioners learn what existing papers offer.

Empirically-grounded reference architectures: a proposal

A reference architecture describes core elements of the software architecture for systems that stem from the same domain. A reference architecture ensures interoperability of systems through standardization. It also facilitates the instantiation of new concrete architectures. However, we currently lack procedures for systematically designing reference architectures that are empirically-grounded. Being empirically-grounded would increase the validity and reusability of a reference architecture. We therefore present an approach which helps systematically design reference architectures. Our approach consists of six steps performed by the software architect and domain experts. It helps design reference architectures either from scratch, or based on existing architecture artifacts. We also illustrate how our approach could be applied to the design of two existing reference architectures found in literature.

Difficulty of architectural decisions: a survey with professional architects

Much research exists on architectural decisions, but little work describes architectural decisions in the real-world. In this paper, we present the results of a survey with 43 architects from industry. We study characteristics of 86 real-world architectural decisions and factors that contribute to their difficulty. Also, we compare decisions made by junior architects and senior architects. Finally, we compare good and bad architectural decisions. Survey results indicate that architectural decisions take an average time of eight working days. Dependencies between decisions and the effort required to analyze decisions are major factors that contribute to their difficulty. Compared to senior architects, junior architects spend a quarter of the time on making a decision. Good architectural decisions tend to include more decision alternatives than bad decisions. Finally, we found that 86% of architectural decisions are group decisions.

Variability in software architecture: current practice and challenges

Variability in software-intensive systems is usually understood as the ability of a software artifact to be changed in order to fit different contexts, environments, or purposes. Software architecture on the other hand determines the structure of a software system, and is described in an architecture description. This description includes the major stakeholders of a software system and their concerns. Variability is reflected in and facilitated through the software architecture. The First International Workshop on Variability in Software Architecture (VARSA) was held jointly with WICSA 2011 in Boulder, Colorado. The goal of the workshop was to explore and advance the state-of-the art in variability in software architecture. It featured four research paper presentations, two invited talks, and three working groups that discussed specific topics. This report summarizes the themes of the workshop, presents the results of the working group discussions, and suggests topics for further research.

Systematic selection of software architecture styles

Selecting appropriate styles for software architectures is important as styles impact characteristics of software (e.g. reliability). Moreover, styles influence how software is built as they determine architectural elements (e.g. components, connectors) and rules on how these elements are integrated in the architecture. Therefore this study presents a method, called SYSAS, for the systematic selection of architecture styles. In SYSAS, style selection is based on (a) characteristics of basic architectural elements that are relevant for the developer, and (b) characteristics of the target system that are visible to the end user. The selection procedure requires ratings about the importance of characteristics of architectural elements and results in a ranking of styles. SYSAS can be applied at system level as well as for choosing styles for individual subsystems. A case study is presented to illustrate SYSAS and its applicability and added benefit. Additional case studies are performed to compare results of SYSAS with judgements of experts.

Constraints for the design of variability-intensive service-oriented reference architectures - An industrial case study

Context: Service-oriented architecture has become a widely used concept in software industry. However, we currently lack support for designing variability-intensive service-oriented systems. Such systems could be used in different environments, without the need to design them from scratch. To support the design of variability-intensive service-oriented systems, reference architectures that facilitate variability in instantiated service-oriented architectures can help. Objective: The design of variability-intensive service-oriented reference architectures is subject to specific constraints. Architects need to know these constraints when designing such reference architectures. Our objective is to identify these constraints. Method: An exploratory case study was performed in the context of local e-government in the Netherlands to study constraints from the perspective of (a) the users of a variability-intensive service-oriented system (municipalities that implement national laws), and (b) the implementing organizations (software vendors). We collected data through interviews with representatives from five organizations, document analyses and expert meetings. Results: We identified ten constraints (e.g., organizational constraints, integration-related constraints) which affect the process of designing reference architectures for variability-intensive service-oriented systems. Also, we identified how stakeholders are affected by these constraints, and how constraints are specific to the case study domain. Conclusions: Our results help design variability-intensive service-oriented reference architectures. Furthermore, our results can be used to define processes to design such reference architectures.

Transition from Requirements to Architecture: A Review and Future Perspective

Elicitation, modeling and analysis of requirements are main challenges during software development. In parallel, software architectures have become a well established area in software engineering research and practice. However, there is still a lack of fundamental process models and guidelines for the transition between the two important phases of requirements engineering and software architectures within the software development cycle. Substantial progress has been separately made in both areas but very little research achievements can be found that address the relation between requirements and architectures. When doing a review on existing methods that try to overcome this gap we realized an urgent need for fundamental research in this area. The paper first presents, compares, classifies and evaluates the suitability of current approaches. Then, evaluation criteria and requirements for a transition methodology are defined. Finally, directions for further research are presented