Table 4 - uploaded by Paulo Borba
Content may be subject to copyright.
Source publication
Variability management allows product customization by specifying variation points and composition rules related to feature models and product configurations. This is an interesting kind of crosscutting concern, since a feature might require variation points to be spread into different artifacts of each Software Product Line model (requirements, de...
Context in source publication
Context 1
... section aims at evaluating how the results of DSMs and quantitative analysis may be related to the flexibility, which is quantified by introducing some common SPL incre- ments. The new version of MMS product line introduces a new structured data operation, allowing a subscriber to make a call for a number embedded in a message; introduces a new content type, allowing a subscriber to attach emotion icons to messages; and defines a new product with the configura- tion presented by Table 4. ...
Similar publications
Variability management is a common challenge for Software Product Line (SPL) adoption, since developers need suitable mechanisms for describing or implementing different kinds of variability that might occur at different SPL views (require-ments, design, implementation, and test). In this paper, we present an approach for use case scenario variabil...
Citations
... Bonifácio et al. [13,15] propose a framework for modeling the composition process of scenario variability mechanisms (MSVCM). They provide a weaver (configurator) that takes a PL use case model, a feature model, a product configuration, and configuration knowledge as input. ...
... If the cardinality constraint is satisfied, the algorithm checks if d contradicts any prior decision (Lines 10-29); otherwise, the analyst is asked to update decision d for the cardinality constraint (Line 31). We call some check functions (i.e., checkConflictingVP, checkRe-quiringVP, checkRequiredVP, checkConflictingUC, check-RequiringUC, and checkRequiredUC) to determine whether the propositional logic formulas, derived from the dependencies to/from the diagram elements decided in d, are satisfied by d and set of prior decisions DC (Lines [10][11][12][13][14][15][16][17][18][19][20]. If there is a formula not satisfied, there is at least one prior decision that is contradicting d. ...
In many domains such as automotive and avionics, the size and complexity of software systems is quickly increasing. At the same time, many stakeholders tend to be involved in the development of such systems, which typically must also be configured for multiple customers with varying needs. Product Line Engineering (PLE) is therefore an inevitable practice for such systems. Furthermore, because in many areas requirements must be explicit and traceability to them is required by standards, use cases and domain models are common practice for requirements elicitation and analysis. In this paper, based on the above observations, we aim at supporting PLE in the context of use case-centric development. Therefore, we propose, apply, and assess a use case-driven configuration approach which interactively receives configuration decisions from the analysts to generate product-specific (PS) use case and domain models. Our approach provides the following: (1) a use case-centric product line modeling method (PUM), (2) automated, interactive configuration support based on PUM, and (3) an automatic generation of PS use case and domain models from Product Line (PL) models and configuration decisions. The approach is supported by a tool relying on Natural Language Processing (NLP) and integrated with an industrial requirements management tool, i.e., IBM DOORS. We successfully applied and evaluated our approach to an industrial case study in the automotive domain, thus showing evidence that the approach is practical and beneficial to capture variability at the appropriate level of granularity and to configure PS use case and domain models in industrial settings.
... Many proposed use case-driven configuration approaches [5,6,16,18,17,2] require that feature models be traced to use case diagrams and specifications. The analysts need to establish traces between feature models and use cases. ...
Product Line Engineering (PLE) is becoming a common practice in industry to enhance product quality, to reduce development costs, and to improve time-to-market. At the same time, many development contexts are use case-driven and this strongly influences their requirements engineering and system testing practices. In this PhD project, we aim to achieve automated and effective change management in a product family within the context of use case-driven development and system testing. To this end, we first provide a modeling method for capturing variability information explicitly in Product Line (PL) use case and domain models. Then, we propose an automated configuration approach to automatically generate Product Specific (PS) use case and domain models from PL models. In addition, we plan to provide a change impact analysis approach for PL use case and domain models and automated regression test selection for system test cases derived from PL use case models.
... Furthermore, Bonifacio and Borba (2009) applied their approach in different case studies where they achieved a better feature modularity and scenario cohesion . Then, the use of aspect-oriented use cases modelling has good benefits when we have homogeneous crosscutting features and several variants for a scenario (Bonifácio and Borba 2009; Bonifácio et al. 2008). Although some templates (Choi et al. 2008; Gallina and Guelfi 2007; Nguyen 2009; Oliveira et al. 2013) have been proposed based on previous ones, these studies do not empirically compare their proposed templates with previously defined ones. ...
... An exception is the template of Bonifacio and Borba. These authors first report the benefits of the separation of concerns by comparing their approach with other techniques for handling scenario variability management (Bonifácio et al. 2008), and after that, they describe an approach for use case scenario variability management (Bonifácio and Borba 2009). On the other hand, there is some empirical work with the templates identified in this SM (Alferez et al. 2014; Nakanishi et al. 2007; Oliveira et al. 2014). ...
Use case templates can be used to describe functional requirements of a Software Product Line. However, to the best of our knowledge, no efforts have been made to collect and summarize these existing templates and no empirical evaluation of the use cases’ comprehensibility provided by these templates has been addressed yet. The contributions of this paper are twofold. First, we present a systematic mapping study about the SPL variability description using textual use cases. From this mapping, we found twelve SPL use case templates and observed the need not only for the application of these templates in real SPL but also for supporting tools. Secondly, this work presents an evaluation of the comprehensibility of SPL use cases specified in these templates through a controlled experiment with 48 volunteers. The results of this experiment show that the specification of variabilities in the steps’ numeric identifiers of the textual use cases is better to the use case understanding than the other approaches identified. We also found evidence that the specification of variabilities at the end of the use cases favors the comprehension of them and the use of questions associated to the variation points in the use cases improves the understanding of use cases. We conclude that each characteristic of the existing templates has an impact on the SPL use case understanding and this should be taken into account when choosing one.
... In the literature, two research directions were investigated in this context. The first direction focuses on identifying crosscutting features within the variability features (e.g., Features X and Y inFigure 1. [6] [7] [8] [9]. However, this work ignores other types of crosscutting features within the commonality or across the commonality and variability layers. ...
... Accordingly, in this paper, we investigate the concept of Aspectual Feature (AF) as another grouping dimension that can be used in conjunction with the traditional commonality and variability dimension used in most SPL techniques. Recent work reported in [6], [7], [8], and [9] focuses on To this end, we propose a new approach, namely, the Aspectual Product Line Engineering (APPLE) approach based on the theory of Formal Concept Analysis (FCA) for identifying, modeling, and implementing AFs to enhance the reuse of SPLs. In addition, we present a CASE tool for implementing the APPLE approach and demonstrate its use via a case study. ...
Software Product Lines (SPL) exploits reuse by identifying, modeling, and systemically reusing software features to develop different but related software systems. Successful reuse of a product line depends greatly on the modularity of the features that characterize the product line. Traditionally, features in SPL are grouped along the dimension of commonality and variability. However, this single dimension
grouping overlooks the crosscutting nature of some features in the system, which negatively impacts the reusability and modularity of the product line architecture.
In this paper we address this particular problem by investigating the concept of Aspectual Feature (AF) as another grouping dimension that can be used in SPLs. To this end, the paper proposes the Aspectual Product Line Engineering (APPLE) approach for identifying, modeling, and implementing AFs to enhance the reuse of SPLs. A tool support for implementing the APPLE approach is also presented
and demonstrated through a case study.
In the Software Product Line (SPL) paradigm, the variability description is an important issue for the requirements engineering process. In this scenario, there are several approaches in the literature focusing on how to describe variability in use cases. However, to the best of our knowledge, no efforts have been made to collect and summarize the existing templates for textual use case description in the SPL paradigm. This paper addresses this gap, presenting a systematic mapping study about SPL variability description in textual use cases. We found with this mapping, nine use case templates and four different ways to describe SPL variabilities in a use case description. From these templates, only one deal with the five variability types identified and we did not find any experimental study comparing these templates in terms of ease of use or comprehensibility.
Variability management is a common challenge for Software Product Line (SPL) adoption, since developers need suitable mechanisms for describing or implementing different kinds of variability that might occur at different SPL views (require-ments, design, implementation, and test). In this paper, we present an approach for use case scenario variability man-agement, enabling a better separation of concerns between languages used to manage variabilities and languages used to specify use case scenarios. The result is that both represen-tations can be understood and evolved in a separated way. We achieve such goal by modeling variability management as a crosscutting phenomenon, for the reason that artifacts such as feature models, product configurations, and con-figuration knowledge crosscut each other with respect to a SPL specific member. Additionally, we believe that our pro-posed framework might be customized to describe variability mechanisms in other SPL artifacts, being a contribution for automatic product generation and traceability.
Modularization is an essential part of a software program that ensures software maintainability. However, object oriented programs still can't achieve the higher level modularization since it still contain extensive amount of crosscutting concerns. Crosscutting concerns refer to common functionality that does exist in software programs. Separation of concern (SoC) is essential elements of aspect oriented paradigm whereby it has viewed as a way to modularize the existing object oriented programs. Since there are various crosscutting concerns exist, the SoC from base functionality become tedious process. In fact, the process of identifying crosscutting concern for legacy system notably difficult and time consuming. Moreover, crosscutting concern generalization hard to be achieved due to it contain more domain specific concerns. This triggers a need for a literature survey in which it collect and review articles which indicate the usage of crosscutting concerns that exist in software programs in regards of domains. There are five main domains has been specifically retrieved from previous studies. The outcome of the evidence based survey grouped as a domain library which known as Crosscutting Concern Domain Library Listing (CCDLL). CCDLL emphasize on the usage to software practitioner in order to collectively reuse the crosscutting concerns with regards to the domains.
Variability management is a common challenge for Software Product Line (SPL) adoption, since developers need suit- able mechanisms for specifying and implementing variabil- ity that occurs at different SPL artifacts (requirements, de- sign, implementation, and test). In this paper, we present a novel approach for use case scenario variability manage- ment, enabling a better separation of concerns between lan- guages used to manage variabilities and languages used to specify use case scenarios. The result is that both represen- tations can be understood and evolved in a separate way. We achieve such a goal by modeling variability management as a crosscutting phenomenon, for the reason that artifacts such as feature models, product configurations, and config- uration knowledge crosscut each other with respect to each specific SPL member. After applying our approach to dif- ferent case studies, we achieved a better feature modularity and scenario cohesion.
