Microservice-oriented Product Line Architecture Design

The Product Line Architecture (PLA) can be improved by taking into account key factors such as feature modularization, and by continuously evaluating its design according to metrics. Search-Based Software Engineering (SBSE) principles can be used to support an informed-design of PLAs. However, existing search-based design works address only traditional software design not considering intrinsic Software Product Line aspects. This paper presents MOA4PLA, a search-based approach to support the PLA design. It gives a multi-objective treatment to the design problem based on specific PLA metrics. A metamodel to represent the PLA and a novel search operator to improve feature modularization are proposed. Results point out that the application of MOA4PLA leads to PLA designs with well modularized features, contributing to improve features reusability and extensibility. It raises a set of solutions with different design trade-offs that can be used to improve the PLA design.

Software Product Lines (SPLs) is a reuse approach in which a family of products is generalized in a common architecture that can be adapted to different clients. The Product Line Architecture (PLA) is one of the most important artifacts of a SPL. PLA design requires great human effort as it involves several factors that are usually in conflict. To ease this task, PLA design can be formulated as an optimization problem with many factors, i.e, as a multi-objective optimization problem. In this context, the MOA4PLA approach was proposed to optimize PLA design using search algorithms and metrics specific to the context. This approach supported by OPLA-Tool has already been used in several works demonstrating its applicability. However, MOA4PLA does not take into account aspects that are subjective, such as the preferences of a particular Decision Maker (DM). To do so, this paper presents a proposal to incorporate the user preferences in the optimization process performed by MOA4PLA, through an interactive process in which the DM subjectively evaluates the solutions in processing time. Thus, the solutions generated can be better suited to the DM's needs or preferences. In order to allow the user interaction, modifications were made in MOA4PLA and implemented in the OPLA-Tool. Aiming at an initial validation of the proposal, an exploratory study was carried out, composed of two experiments: a qualitative and a quantitative. These experiments were realized with the participation of a software architect. Empirical results pointed out that the proposed interactive process enables the generation of PLAs that are in accordance with the architect's preferences. Another significant contribution are the lessons learned on how to improve the interactive process.

The software product line (PL) architecture (PLA) is one of the most important PL core assets as it is the abstraction of the products that can be generated, and it represents similarities and variabilities of a PL. Its quality attributes analysis and evaluation can serve as a basis for analyzing the managerial and economical values of a PL. We proposed metrics for PLA complexity and extensibility quality attributes. This paper is concerned with the empirical validation of such metrics. As a result of the experimental work we can conclude that the metrics are relevant indicators of complexity and extensibility of PLA by presenting their correlation analysis.

The Product Line Architecture (PLA) design is a complex task, influenced by many factors such as feature modularization and PLA extensibility, which are usually evaluated according to different metrics. Hence, the PLA design is an optimization problem and problems like that have been successfully solved in the Search-Based Software Engineering (SBSE) area, by using metaheuristics such as Genetic Algorithm. Considering this fact, this paper introduces a tool named OPLA-Tool, conceived to provide computer support to a search-based approach for PLA design. OPLA-Tool implements all the steps necessary to use multi-objective optimization algorithms, including PLA transformations and visualization through a graphical interface. OPLA-Tool receives as input a PLA at the class diagram level, and produces a set of good alternative diagrams in terms of cohesion, feature modularization and reduction of crosscutting concerns.

A software product line (SPL) usually involves a shared set of core assets and a series of application products. To ensure consistency, the evolution of the core assets and all the application products should be coordinated and synchronized under a unified evolution process. Therefore, SPL evolution often involves cross-product propagation and synchronization besides application derivation based on core assets, presenting quite different characteristic from the evolution of individual software products. As software architectures, including the product line architecture (PLA) and application architectures, play a central role in SPL engineering and evolution, architecture-based evolution analysis is a natural way for analyzing and managing SPL evolution. In this paper, we explore common practices of architecture evolution and the rationale behind in industrial SPL development. To this end, we conduct a case study with Wingsoft examination system product line (WES-PL), an industrial product line with an evolution history of eight years and more than 10 application products. In the case study, we reviewed the evolution history of WES-PL architecture and analyzed several typical evolution cases. Based on the historical analysis, we identify some special problems in industrial SPL practice from the aspect of architecture evolution and summarize some useful experiences about SPL evolution decisions to complement classical SPL methodology. On the other hand, we also propose some possible improvements for the evolution management in WES-PL.

The architectural properties of product‐line architecture (PLA) design have been successfully optimised by multi‐objective genetic algorithms (GAs). Memetic algorithms (MAs) extend GA by adding a local search after the global search process. MA outperformed GA in the context of class modelling, software testing and the next release problem. However, no studies on the application of MAs for PLA design optimisation were found in the literature. In light of this, the authors performed an exploratory study, where MA was used to apply design patterns for a search‐based PLA design (SBPD) and achieved promising results. From the obtained results, they adjusted the MA‐based implementation. This study aims at investigating if the MA is more profitable to SBPD than GAs. Two empirical studies that involve four PLA designs were carried out for this task by varying the pair of objective functions. Empirical results show that MA achieved satisfactory solutions, despite being influenced by the original PLA design.

This paper addresses the problem of supporting usability in the early stages of a product line architecture design. The product line used as an example is intended to support a variety of different products each with a radically different user interface. The development cycles for new products varies between three years and five years and usability is valued as an important quality attribute for each product in the line.Traditionally, usability is achieved in a product by designing according to specific usability guidelines, and then performing user tests. User interface design can be performed separately from software architecture design and prototyping, but user tests cannot be performed before detailed UI design and prototyping. If the user tests discover usability problems leading to required architectural changes, the company would not know about this until two years after the architecture design was complete. This problem was addressed by identifying a collection of 19 well known usability scenarios that require architectural support. In our example, the stakeholders for the product line prioritized three of these scenarios as key product-line scenarios for improving usability. For each of these three chosen product-line scenarios we developed an architectural responsibility pattern that provided support for the scenario. The responsibilities are expressed in terms of architectural requirements with implementation details and rationales. The responsibilities were embodied in a web based tool for the architects.The two architects for the product line developed a preliminary design and then reviewed their design against the responsibilities supporting the scenarios. The process of review took a day and the architects conservatively estimated that it saved them five weeks of effort later in the project.

Software architecture has been a key research area in the software engineering community due to its significant role in creating high-quality software. The trend of developing product lines rather than single products has made the software product line a viable option in the industry. Software product line architecture (SPLA) is regarded as one of the crucial components in the product lines, since all of the resulting products share this common architecture. The increased popularity of software product lines demands a process maturity evaluation methodology. Consequently, this paper presents an architecture process maturity model for software product line engineering to evaluate the current maturity of the product line architecture development process in an organization. Assessment questionnaires and a rating methodology comprise the framework of this model. The objective of the questionnaires is to collect information about the SPLA development process. Thus, in general this work contributes towards the establishment of a comprehensive and unified strategy for the process maturity evaluation of software product line engineering. Furthermore, we conducted two case studies and reported the assessment results, which show the maturity of the architecture development process in two organizations.

This paper focuses on an industrial experience with software product lines of analytics-enabled solutions, specifically the evolution of the software product line architecture for a Subject Matter Expert Workbench toolset which supports analytic plugins for multiple software product lines. As context, the toolset product line was intended for integration of expert knowledge into a family of industrial asset health applications at runtime. The toolset architecture is now being evolved to build and manage plugins for multiple Industrial Analytics solutions (software systems and services) beyond asset health. This evolution is driving changes in the desired architecture qualities of the toolset; widening the stakeholder pool and influencing priorities; affecting the architecture tradeoffs and decisions; and triggering updates to the product line architecture, the guidance for applying it, and the current prototype of the toolset. We describe our experiences in handling this evolution, assess lessons learned, and discuss potential relevance to other product line scenarios.

Search-based algorithms have been successfully employed in Product Line Architecture (PLA) design in the seminal approach named Multi-Objective Approach for Product-Line Architecture Design (MOA4PLA). This approach generates a set of alternative PLA designs, which optimize different architectural properties. In addition to these properties, the alternative PLA designs should have as few architectural smells as possible. Architectural smells can negatively impact PLA variability, PLA extensibility, SPL maintainability, and other non-functional attributes. However, one of the main findings of a previous study is that the tool that automates the application of MOA4PLA adversely introduces architectural smells in the automatically generated solutions. In this work, we present OPLA-Tool-ASP, which is a tool that implements guidelines to detect and prevent the architectural smells Unused Interface, Unused Brick, Concern Overload, and Link Overload in the context of MOA4PLA. An empirical study was carried out to assess the effectiveness of OPLA-Tool-ASP in preventing the aforementioned smells in the resulting PLA designs. The obtained results pointed out that the proposed tool is effective in both preventing the smells and improving the architectural properties selected for optimization.

In automotive system design, system architects increasingly use model-based approaches for defining product line architectures (PLAs). This trend is strongly supported by the emergence of domain standards like EAST-ADL and AUTOSAR that facilitate a system design approach based on systematic reuse. In our work, we focus on the automated exploration of PLA design spaces by means of multi-objective optimization and ask what are challenges that stakeholders face as part of this design task. Optimizing PLA design spaces shares certain challenges with conventional architecture optimization, like conflicting quality goals and potentially vast design spaces. However, PLA optimization exacerbates these challenges by an additional layer of complexity in the system architecture, due to product line variability in the system. Our main focus in this paper is on achieving a better understanding of the stakeholder requirements on a support infrastructure for automated PLA design space exploration based on PLA system models. We also address the challenges that stakeholders must overcome when integrating such an approach into an existing process landscape. For that purpose, we conducted a study with automotive industry experts and analyzed the findings using the qualitative data analysis methods of Grounded Theory. Based on the study results, we derive a set of challenges for the realization and integration of automated and semi-automated PLA design space exploration in industrial environments.

Product lines are an important system development paradigm in the automotive industry to amortize costs beyond a single product. The paradigm is well established in the mechanical and electrical engineering practise in automotive companies like Bosch. As software is covering more and more functionality in cars, software product lines are getting more attention. The architecture of a software-intensive system is a key asser in developing a software product line.The Architecture Trade-off Analysis Method (ATAM) developed by the SEI assesses the quality of software architecture early in the development process. ATAM is therefore a useful review technique to guarantee important quality attributes of every single product created with the product line architecture later on. This article reports about the experience Bosch made in using ATAM in two cases.Benefits in using ATAM are not only the review results itself but a better documented and better understood architecture. We experienced the most important benefit of ATAM is the rising stakeholder's awareness of architectural decisions, tradeoffs, and risks. It illuminates the software architecture better than any written documentation.Bosch employees are trained in the evaluation roles in order to trasition ATAM to Bosch.The reports conclude with some suggestions fo improving the ATAM itself and the training of ATAM roles.

In the software product line research, product variants typically differ by their functionality and quality attributes are not purposefully varied. The goal is to study purposeful performance variability in software product lines, in particular, the motivation to vary performance, and the strategy for realizing performance variability in the product line architecture. The research method was a theory-building case study that was augmented with a systematic literature review. The case was a mobile network base station product line with capacity variability. The data collection, analysis and theorizing were conducted in several stages: the initial case study results were augmented with accounts from the literature. We constructed three theoretical models to explain and characterize performance variability in software product lines: the models aim to be generalizable beyond the single case. The results describe capacity variability in a base station product line. Thereafter, theoretical models of performance variability in software product lines in general are proposed. Performance variability is motivated by customer needs and characteristics, by trade-offs and by varying operating environment constraints. Performance variability can be realized by hardware or software means; moreover, the software can either realize performance differences in an emergent way through impacts from other variability or by utilizing purposeful varying design tactics. The results point out two differences compared with the prevailing literature. Firstly, when the customer needs and characteristics enable price differentiation, performance may be varied even with no trade-offs or production cost differences involved. Secondly, due to the dominance of feature modeling, the literature focuses on the impact management realization. However, performance variability can be realized through purposeful design tactics to downgrade the available software resources and by having more efficient hardware.

Privacy-enhancing personalized (PEP) systems address individual users' privacy preferences as well as privacy laws and regulations. Building such systems entails modeling two different domains: (a) privacy constraints as mandated by law, voluntary self-regulation, or users' individual privacy preferences, and modeled by legal professionals, and (b) software architectures as dictated by available software components and modeled by software architects. Both can evolve independently, e.g., as new laws go into effect or new components become available. In prior work, we proposed modeling PEP systems using a product line architecture (PLA). However, with an extensional PLA, these domain models became strongly entangled making it difficult to modify one without inadvertently affecting the other. This paper evaluates an approach towards modeling both domains within an intensional PLA. We find evidence that this results in a clearer separation between the two domain models, making each easier to evolve and maintain.

This report explains the challenges experienced as Overwatch Textron Systems transitioned to a software product line approach. Overwatch Textron Systems provides both software products and custom software development in the domain of intelligence planning, collection and analysis to the U.S. Government and its allies. This report: a) Describes the approach taken to transition Overwatch Textron Systems to a product line organization. b) Provides an overview of the Overwatch Textron Systems software product line; the Overwatch Intelligence Center. c) Describes the product line architecture that is key to the Overwatch Intelligence Center software product line. d) Provides a summary of the lessons learned during the transition.