UML-Based Software Product Line Engineering with SMarty

Software product lines (SPL) has been consolidated in the last decades as a de facto and non-opportunistic way of mass customization and reuse of software artifacts to produce specific products. Over the years, SPLs and their construction processes have evolved based on several seminal works and technologies. In this chapter, we characterize an SPL, present its terminology, chronologically present its first construction methodologies and second-generation ones, and describe SPL development approaches. We conclude the chapter with final remarks and considerations for the next chapters.

Variability makes it possible to easily change and adapt software systems for specific contexts in a preplanned manner. It has been considered in several research topics, including self-adaptive systems, large-scale enterprise systems, and system-of-systems, and was mainly consolidated by the Software Product Line (SPL) engineering. SPL manages a common platform for developing a family of products with reduced time to market, better quality, and lower cost. Variability in the SPL must be clearly identified, modeled, evaluated, and instantiated. Despite the advances in this field, managing the variability of systems is still challenging for building software-intensive product families. One difficulty is that the software architecture, the cornerstone of any design process, is usually defined with notations and languages lacking accurate forms to describe the variability concerns of software systems. Hence, in this chapter, we analyze approaches used for describing software variability in SPL, paying special attention to the architecture.

The architecture of a Software Product Line (or Product Line Architecture, PLA) is one of the most important assets of a Software Product Line (SPL) as it represents an abstraction of all the products that can be generated in an SPL. Furthermore, the PLA is crucial for the development and evolution of an SPL. It represents the architecture of all potential products from a specific product line domain. The PLA addresses the SPL design decisions by explicitly representing similarities between product variants as well as the desired variability between them. A PLA differs from a single-product architecture in two aspects: (1) scope, i.e., the PLA describes broad design decisions relevant to related products for a given domain; (2) completeness, i.e., the PLA captures only parts of single products (which do not have unspecified or “variable” parts). Designing PLAs involves various activities and techniques, such as business case analysis, scope analysis, architectural design based on functionalities, and architecture transformation. When designing a PLA, it is important to explicitly accommodate variability (typically in the form of “variation points” in the architecture). Also, the design of a PLA needs to explicitly address quality attributes, such as complexity, extensibility, and reusability. These quality attributes are then used to evaluate the PLA to ensure (a) a PLA that supports product derivation and (b) a PLA that helps product variants meet the quality goals relevant in a domain (e.g., performance, security). Therefore, this chapter provides essential concepts on PLA, its design and variability issues. Finally, we present the design of a PLA aiming at illustrating the main concepts addressed in this chapter.

In this chapter we present the Stereotype Management of Variability (SMarty) approach, its UML 2 compliant profile, and its process to guide users at identifying and representing variabilities in UML-based Software Product Lines (SPL). UML plays a central role as it is the standard modeling language and it is used from now in this book, as well as it represents design decisions on SPLs. Therefore, we discuss important concepts on UML-based SPLs in the context of the SMarty supported diagrams. In addition, we present in detail the SMarty approach.

In this chapter we present how to design use case, class, component, activity, and sequence diagrams using the SMarty approach. Based on the SMartyProcess and its guidelines, we demonstrate how to apply the stereotypes of the SMartyProfile, as well as how to trace the modeled elements, and how to configure SPL specific products. To do so, we use the SMartyModeling, an environment created to aid users on modeling according to any MOF-based metamodel, especially using SMarty.

The SPL Architecture (PLA) is one of the main artifacts of an SPL. It represents an abstraction of all possible products that can be generated from an SPL. Important PLA requirements include (i) remain stable during the SPL lifetime, (ii) easy integration of new features during the architecture life cycle, and (iii) explicit representation of variability for providing reuse. Therefore, this chapter presents the SMartyComponents process for designing UML-based PLAs. SMartyComponents is based on the UML Components process and provides systematic activities to modeling component-based PLAs based on the SMarty approach, mainly focused on component diagram elements, such as components, interfaces, ports, and operations according to the standard UML metamodel. Workflows of SMartyComponents include: Requirements Workflow and Specification Workflow. The former is composed of activities as Develop Business Concept Model, Develop Business Processes, and Identify Use Cases. The latter activities are Component Identification, Component Interactions, and Component Specification. The main product developed using SMartyComponents is a component-based PLA with variabilities modeled in components, interfaces, ports, and operations.

Software inspection is a rigorous special type of software review among the several verification and validation activities. It has a well-defined process that conducted all life cycle artifacts for different domains. The inspection’s main objective is to detect and reduce the number of defects aiming to guarantee and control a specific SPL’s quality or their products generated. Despite the several software inspection techniques available in the literature, few techniques inspect SPL modeled using UML variability diagrams. Therefore, this chapter presents SMartyCheck, a checklist-based software inspection technique that encompasses defect types taxonomy; and SMartyPerspective, a perspective-based software inspection that enables detecting defects using distinct scenarios and roles in SMarty diagrams. SMartyCheck and SMartyPerspective were evaluated in several empirical studies by undergraduate, graduate students, researchers, and experts, which provided a body of knowledge of their feasibility (quality) and effectiveness (productivity).

The use of test approaches in software development to ensure quality and safety has grown considerably among model processes in recent decades. Software Product Line (SPL) as seen in previous chapters aims at reusing software components, thus obtaining greater productivity, reducing time and cost. The characteristic that differentiates a product from the others in a core of a product line is called variability. To test a set of products from an SPL is a great challenge since to cover all the functions or variabilities of a group of products could be exhaustive, and this might not be feasible, regardless of the size of the generated products. The analysis and management of variabilities are important since a variability represents different types of variations under different levels and with different types of dependencies. One of the management approaches to deal with variability is Stereotype-based Management of Variability (SMarty), which has been discussed in previous chapters. In order to deal with testing of the wide variety of variations, Model-Based Testing (MBT) has been an approach that can be used in conjunction with SPL. MBT is a software testing technique to generate test cases based on system models that describe aspects (usually functional) of the system under test. The use of MBT in SPL can provide several advantages, for example, contributes to reduce the likelihood of misinterpretation of system requirements by a test engineer, decreases testing time in SPL projects, brings greater traceability between functional requirements and generated test cases, and facilitates the maintenance of test artifacts. In this chapter, we present two MBT approaches to generate functional test cases and scripts to test products derived from SPLs: SPLiT-MBt and SMartyTesting. Thus, test cases to verify products common functionalities are generated based on the reuse inherent to SPLs. In order to demonstrate the applicability of our two methods, we perform examples of use to test academic SPLs.

In software product line (SPL), metrics are used to evaluate different artifacts such as the product-line architecture (PLA). When the PLA’s evaluation is conducted using metrics, it allows for the analysis of quality attributes (QAs). The QAs are represented in an isolated way or using quality models (QM). There are different QM published in the literature. ISO/IEC 25010 is one of these models that considers the following QAs: functional suitability, reliability, performance efficiency, usability, security, compatibility, maintainability, and portability. For instance, maintainability is an important attribute in the SPL context. According to the literature, 92% of the measures defined to evaluate the SPL’s artifacts consider attributes related to maintainability. Despite the number of measures related to maintainability, it is observed a lack of measures and metrics associated with QA and QM. These metrics could aid in the PLA’s evaluation. The observed lack motivates the development of the SMartyMetrics, a framework with measures and metrics associated with the attribute maintainability to support PLA evaluations. A structure with attributes was developed, to systematize the association between attributes and measures/metrics. The framework also provides a set of guidelines to use it at the level of SPL, PLA, measures/metrics, and constraints.

The architecture of a software product line is an important artifact which represents an abstraction of the products that can be generated. It is crucial to evaluate the quality attributes of a product line architecture to improve the product line process, in terms of productivity and reduction of the time to market. The evaluation of PLA can serve as a basis to analyze the managerial and economical values of a product line for software managers and architects. Current research on the evaluation of product line architecture does not take into account metrics directly obtained from UML models and their variabilities. In this context, used metrics are difficult to be applied in general and to be used for quantitative analysis. This chapter presents a Systematic Evaluation Method for UML-based Software Product Line Architectures (SystEM-PLA), which provides a methodology to (i) estimate and analyze products; (ii) use UML-based metrics in a composition related to quality attributes; (iii) perform feasibility and trade-off analysis, and (iv) facilitate the evaluation of product line architecture. An example using the SEI’s Arcade Game Maker (AGM) software product line is presented and illustrates SystEM-PLA activities. Metrics for complexity and extensibility quality attributes are used to perform a trade-off analysis.

One of the main core assets of a software product line (SPL) is the product-line architecture (PLA). PLA design can be modeled as a multi-objective problem, influenced by many factors, such as feature modularization, extensibility, and other architectural properties. Due to this, PLA design has been properly optimized in the search-based software engineering (SBSE) field, by taking into account key factors and by continuously evaluating the architecture according to certain metrics. In this chapter, we present an approach, named MOA4PLA (Multi-Objective Approach for Product-Line Architecture Design). MOA4PLA encompasses a process to give a multi-objective treatment to the design problem, based on specific SPL metrics. It introduces a meta-model to represent the PLA and specific search operators to improve architectural properties of the PLA design, such as feature modularization. We also discuss certain implementation aspects and present an application example.

Feature interaction (FI) can be defined as a situation in which a feature influences positively or negatively on the behavior of another feature. The FI problem has been a challenging subject for decades because it is not easy to predict, identify, and resolve interactions among features. A common occurrence is the impact of a feature on another one, leading to unexpected behavior, for instance, a feature can influence, activate, or replace the behavior of other feature, or even an unwanted behavior, known as bad feature interaction. In this chapter, we present an approach to identify possible feature interaction in the software product-line architecture design as well as an automatic way to prevent feature interaction by means of search-based algorithms. Such kind of algorithm is used to improve the feature modularization degree of the product-line architecture leading to low feature interaction on the architectural elements.

The advent of mobile devices in all social classes leads us to new possibilities of interaction, including in the educational context, where mobile learning (m-learning) applications have become powerful teaching and learning tools. Such applications, even having many benefits and facilities, also present problems and challenges, especially regarding their development, reuse, and architectural standardization. On the other hand, the adoption of the systematic reuse concept has been consolidated, making approaches such as software product lines (SPL) interesting alternatives for these gaps. This paradigm favors the abstraction of the similarities and variabilities of a domain and its products, promoting the reuse of core assets and, consequently, reducing the development time and cost (from the break-even point) of the generated solutions. Thus, to systematically explore the variabilities of m-learning applications domain, an SPL, called M-SPLearning, was proposed. First, we analyze the existing adoption models in the literature, allowing us to identify the most appropriate approach to the context of our SPL. Then, the main features of m-learning applications were defined with the support of a previously defined requirements catalog. As a result, the domain engineering and application engineering phases were conducted for M-SPLearning. In the context of domain engineering, the Stereotype-based Management of Variability (SMarty) approach was fundamental in the representation of similarities and variabilities with regard to architecture, components, and production plan, synthesizing the features of this domain through UML diagrams. Regarding application engineering, we present the dynamics of M-SPLearning’s operation, generating m-learning applications according to the selected variabilities through a web application, in other words, a user interface (UI) for the generation of products. Finally, M-SPLearning had its products experimentally evaluated in the context of a real software development company, providing statistical evidence that SPL can improve time-to-market and quality (measured by the number of bugs) in the domain of m-learning applications. Therefore, in this chapter, M-SPLearning is presented from the analysis and design phases to the generation of its products. In particular, we highlight the use of SMarty and its importance in M-SPLearning application engineering. In this sense, we discussed the importance of managing variability and how approaches such as SMarty can contribute to SPL design and demystify the adoption of this reuse strategy.

Software testing is a fundamental activity to improve software quality. However, software testing is one of the most time-consuming and expensive activities of the software development process. Therefore, several testing tools have already been developed to support software testing, including tools for model-based testing (MBT), which is a testing technique to automatically generate testing artifacts from the system model. Some of the advantages of MBT include lower cost and less effort to generate test cases. Therefore, in the last years, a diversity of commercial, academic, and open-source tools to support MBT has been developed to better explore these advantages. Although several testing tools to support MBT were produced in the past years, most of them have been individually and independently developed based on a single architecture. Therefore, it is difficult to integrate, evolve, maintain, and reuse them. One strategy that could minimize those problems would be to use software product lines (SPL), which allows to systematically generating software products at lower costs, in a shorter time, and with higher quality. Therefore, this chapter presents an SPL for testing tools that support MBT (PLeTs (This chapter is an expanded version of previously published paper Rodrigues et al. (PLeTs - Test Automation using Software Product Lines and Model-Based Testing. In: Proceedings of the 22th International Conference on Software Engineering and Knowledge Engineering, pp. 483–488, 2010.))) and how we applied the Stereotype-based Management of Variability (SMarty) approach to manage and resolve the dependencies among components and to represent the variability in PLeTs architecture. PLeTs is a component-based SPL developed to automatically generate MBT tools. The PLeTs MBT tools aim to automate any of the test activities of MBT, for example, the generation of test cases and/or test scripts based on the system model. Basically, PLeTs MBT tools receive, as input, a system model, generate the test cases/scripts, execute the test scripts, and then compare the produced results. Since PLeTs can generate tools that connect to any commercial testing tool, a software testing team can incorporate their own testing tools, hence reducing effort and investment. In a nutshell, the main PLeTs goal is to reuse SPL artifacts and use existing testing tools to ease the development of new MBT tools.

In recent years, software product line engineering (SPLE) has emerged as a promising reusability approach that brings out some important benefits, e.g., it increases the reusability of its core assets while decreasing the time to market. The SPL approach focuses mainly on a two-life cycle model: domain engineering, where the SPL core asset is developed for reuse, and application engineering, where the core asset is reused to generate specific products. It is important to highlight that the success of the SPL approach depends on several principles, in particular variability management. Although the SPL engineering brings out important benefits, it is clear the lack of environments aimed at automating the overall SPL life cycle, including (i) configuration of feature model (FM); (ii) configuration of products; and (iii) generation of products. Literature and industry present several important tools that encompass part of the SPL development life cycle, such as SPLOT and pure::variants. The plugin approach has also received an increasing attention in the development of SPLs. Some SPL-based approaches are characterized by the development of different applications through the selection/development of different sets of plugins. Although the use of plugins to develop SPL products is a promising approach and several works have been published in recent years, there is no tool to fully support plugin-based SPLs. This chapter presents PlugSPL (This chapter is an expanded version of a previously published paper Rodrigues et al. (Plugspl: An automated environment for supporting plugin-based software product lines. In: SEKE, pp. 647–650, 2012).), an automated environment to support the overall plugin-based SPL life cycle. PlugSPL is a modular environment, written in C#, in which a test manager can design an SPL using the SMarty approach, configure and develop its components, define a valid product configuration, and generate a product. Although there are tools that partially give support to the SPL life cycle as, for instance, pure::variants, to the best of our knowledge, there was no tool that supported plugin-based SPLs and the overall SPL life cycle. Furthermore, there are tools to design FMs, but most of them use different notations and file formats. PlugSPL provides capabilities with regard to creating or import/export FMs from/to other tools and uses a commonly used file format. Therefore, there is no need to incorporate other tools/environments into PlugSPL. Although PlugSPL is a flexible environment for modeling FMs, its most significant benefit is supporting the generation of SPL products based on its FM. Moreover, PlugSPL automatically generates an abstract class structure, which can be used to develop third-party plugins. A PlugSPL application example is presented for deriving MBT tools from the PLeTs product line.

The evolution of hardware platforms has led to the move of a large amount of functionality to embedded software systems. Thus, the software has become increasingly complex. Several techniques have been proposed over the years for dealing with this complexity. Software product line (SPL) and model-driven engineering (MDE) can enhance the development of complex embedded systems by using different specification languages according to the abstraction levels and controlling variability across development. This chapter describes SyMPLES: an approach that combines MDE and SPL to deal with the complexity of embedded systems software. SyMPLES includes two SysML extensions, created using UML profiling mechanism both to associate SysML blocks with the main classes of functional blocks and to express SPL variability concepts using SMarty approach. SyMPLES also provides a model transformation that transforms the SysML SPL into Simulink models, speeding up the development process. Lastly, this chapter shows how an approach like SyMPLES can be validated to ensure the quality of its products.

Different notations can be used to model software processes. This set of notations typically does not have constructs that are appropriate for expressing process variability. Variability in software process models justifies tailoring them to meet the specific goals and characteristics of organizations and projects. Recent studies propose techniques and tools based on software process line (SPrL) to systematically manage the variability found during the maintenance and reuse of software processes. Although this research area is still not consolidated, some approaches found in the literature can be considered promising, as SMartySPEM. This chapter presents an overview of the SPrL by highlighting important aspects for variability management. In this context, an approach called SMartySPEM is presented. It extends the SPEM profile to specify variabilities in SPrLs considering the SMarty approach for variability management.

Software reuse is a way to reduce costs and improve the quality of products. In practice, software reuse is commonly done by opportunistic strategies. In these strategies, the artifacts are simply copied/cloned and modified/adapted to fulfill existing needs. Opportunistic reuse leads to a set of system variants developed independently, generating technical debts. The maintenance and evolution of these independent variants are a costly and difficult task since most of the times the practitioners do not have a global view of such variants nor a clear understanding of the actual structure of the system. In such a case, a systematic reuse approach is paramount. Software product line engineering (SPLE) is a well-established approach to deal with a set of product variants in a specific domain, including systematic reuse in the software development process. One of the main design assets generated during the SPLE is the product line architecture (PLA), which describes how commonalities and variabilities are implemented in an SPL. Designing a PLA from scratch is challenging, since it must contemplate a detailed description of a whole family of products. PLAs can be obtained from existing product variants, requiring less effort and time from practitioners. Commonly, UML class diagrams of system products are available or can be reverse engineered easily. These UML class diagrams are a rich source of information to support PLA creation. In this chapter, we describe our method of reengineering UML class diagram of variants into an initial version of a PLA. Our method relies on a search-based technique to merge a set of UML model variants and insert annotations in model elements to describe the system features they belong to. The output of our method is an annotated UML class diagram that shows the whole structure of product variants that allows practitioners to reason better about the adoption of SPLE, aiding communication among stakeholders, supporting SPLE planning, and helping estimate maintenance, evolution, and testing activities.

The process of experimentation is one of several scientific methods that can provide evidence for a proof of a theory. This process is counterpoint to the real world observation method, thus providing a reliable body of knowledge. However, in the experimentation for emerging areas and in the consolidation process in scientific and industrial communities, such as the software product line (SPL), there has been a constant lack of adequate documentation of experiments that makes it difficult to repeat, replicate, and reproduce studies in SPL. Therefore, this chapter presents a set of guidelines for the quality assessment of SPL experiments with its conceptual model to support the understanding of the proposed guidelines, as well as an ontology for SPL experiments, called OntoExper-SPL, in addition to support the teaching experimentation in SPL. Thus, these points aim to improve the planning, conduction, analysis, sharing, and documentation of SPL experiments, supporting the construction of a reliable and reference body of knowledge in such a context in addition to enabling improvement in the teaching of SPL experiments.

The Stereotype-based Management of Variability (SMarty), presented in Chap. 4, allows the management of variabilities through a UML profile and a process that encompass a set of well-defined guidelines for the identification, representation, and traceability of variabilities in UML models. Thus, in this chapter, we present the experimental studies carried out with the SMarty approach compared to other variability management approaches, in addition to the guidelines created from such experiments for the evolution of SMarty. This chapter was structured according to the guidelines defined by Furtado et al., explaining the methodology applied in each experiment carried out, the objectives with the application of such an experiment, the instrumentation and the hypotheses raised, as well as the statistical tests carried out, with the data obtained through the experiments, to determine the effectiveness of the approaches, the correlation of the participant’s level of knowledge with the effectiveness of the configured product, and the effectiveness in tracking elements between the diagrams.