scholarly journals Resolving Code Smells in Software Product Line using Refactoring and Reverse Engineering

2020 ◽  
Author(s):  
Sami Ouali
Keyword(s):  
Reverse Engineering ◽  
Source Code ◽  
Software Product Line ◽  
Product Line ◽  
Production Costs ◽  
Code Smells ◽  
Product Lines ◽  
Software Products ◽  
Software Product ◽  
External Behavior

Software Product Lines (SPL) are recognized as a successful approach to reuse in software development. Its purpose is to reduce production costs. This approach allows products to be different with respect of particular characteristics and constraints in order to cover different markets. Software Product Line engineering is the production process in product lines. It exploits the commonalities between software products, but also to preserve the ability to vary the functionality between these products. Sometimes, an inappropriate implementation of SPL during this process can conduct to code smells or code anomalies. Code smells are considered as problems in source code which can have an impact on the quality of the derived products of an SPL. The same problem can be present in many derived products from an SPL due to reuse. A possible solution to this problem can be the refactoring which can improve the internal structure of source code without altering external behavior. This paper proposes an approach for building SPL from source code. Its purpose is to reduce code smells in the obtained SPL using refactoring source code. Another part of the approach consists on obtained SPL’s design based on reverse engineering.

scholarly journals Generating Software Product Line Model by Resolving Code Smells in the Products’ Source Code

2021 ◽  
Vol 12 (1) ◽  
pp. 1-10
Author(s):  
Sami Ouali
Keyword(s):  
Source Code ◽  
Software Product Line ◽  
Product Line ◽  
Production Costs ◽  
Feature Model ◽  
Software Systems ◽  
Code Smells ◽  
Product Lines ◽  
Bottom Up ◽  
Software Product

Software Product Lines (SPLs) refer to some software engineering methods, tools and techniques for creating a collection of similar software systems from a shared set of software assets using a common means of production. This concept is recognized as a successful approach to reuse in software development. Its purpose is to reduce production costs by reusing existing features and managing the variability between the different products with respect of particular constraints. Software Product Line engineering is the production process in product lines and the development of a family of systems by reusing core assets. It exploits the commonalities between software products and preserves the ability to vary the functionalities and features between these products. The adopted strategy for building SPL can be a top-down or bottom-up. Depending from the selected strategy, it is possible to face an inappropriate implementation in the SPL Model or the derived products during this process. The code can contain code smells or code anomalies. Code smells are considered as problems in source code which can have an impact on the quality of the derived products of an SPL. The same problem can be present in many derived products from an SPL due to reuse or in the obtained product line when the bottom-up strategy is selected. A possible solution to this problem can be the refactoring which can improve the internal structure of source code without altering external behavior. This paper proposes an approach for building SPL from source code using the bottom-up strategy. Its purpose is to reduce code smells in the obtained SPL using refactoring source code. This approach proposes a possible solution using reverse engineering to obtain the feature model of the SPL.

scholarly journals Fragment-oriented programming: a framework to design and implement software product line domain components

DYNA ◽  
2018 ◽  
Vol 85 (207) ◽  
pp. 74-83 ◽  
Author(s):  
Daniel Correa ◽  
Raúl Mazo ◽  
Gloria Lucia Giraldo Goméz
Keyword(s):  
Software Product Line ◽  
Preliminary Evidence ◽  
Product Line ◽  
Software Systems ◽  
Software Components ◽  
Product Lines ◽  
Reusable Software ◽  
Software Products ◽  
Manual Intervention ◽  
Software Product

Software product lines facilitate the industrialization of software development. The main goal is to create a set of reusable software components for the rapid production of a software systems family. Many authors have proposed different approaches to design and implement the components of a product line. However, the construction and integration of these components continue to be a complex and time-consuming process. This paper introduces Fragment-oriented programming (FragOP), a framework to design and implement software product line domain components, and derive software products. FragOP is based on: (i) domain components, (ii) fragmentations points and (iii)fragments. FragOP was implemented in the VariaMos tool and using it we created a clothing stores software product line. We derivedfive different products, integrating automatically thousands of lines of code. On average, only three lines of code were manually modified;which provided preliminary evidence that using FragOP reduces manual intervention when integrating domain components.

scholarly journals Taking advantage of the software product line paradigm to generate customized user interfaces for decision-making processes: a case study on university employability

2019 ◽  
Vol 5 ◽  
pp. e203 ◽  
Author(s):  
Andrea Vázquez-Ingelmo ◽  
Francisco J. García-Peñalvo ◽  
Roberto Therón
Keyword(s):  
User Interfaces ◽  
Software Product Line ◽  
Domain Engineering ◽  
Product Line ◽  
Product Lines ◽  
Code Generator ◽  
Software Products ◽  
Software Product ◽  
Spanish Universities

University employment and, specifically, employability has gained relevance since research in these fields can lead to improvement in the quality of life of individual citizens. However, empirical research is still insufficient to make significant decisions, and relying on powerful tools to explore data and reach insights on these fields is paramount. Information dashboards play a key role in analyzing and visually exploring data about a specific topic or domain, but end users can present several necessities that differ from each other, regarding the displayed information itself, design features and even functionalities. By applying a domain engineering approach (within the software product line paradigm), it is possible to produce customized dashboards to fit into particular requirements, by the identification of commonalities and singularities of every product that could be part of the product line. Software product lines increase productivity, maintainability and traceability regarding the evolution of the requirements, among other benefits. To validate this approach, a case study of its application in the context of the Spanish Observatory for University Employability and Employment system has been developed, where users (Spanish universities and administrators) can control their own dashboards to reach insights about the employability of their graduates. These dashboards have been automatically generated through a domain specific language, which provides the syntax to specify the requirements of each user. The domain language fuels a template-based code generator, allowing the generation of the dashboards’ source code. Applying domain engineering to the dashboards’ domain improves the development and maintainability of these complex software products given the variety of requirements that users might have regarding their graphical interfaces.

scholarly journals Feature Model Configuration Based on Two-Layer Modelling in Software Product Lines

2019 ◽  
Vol 9 (4) ◽  
pp. 2648
Author(s):  
Elham Darmanaki Farahani ◽  
Jafar Habibi
Keyword(s):  
Product Line ◽  
Feature Model ◽  
Functional Requirements ◽  
Product Lines ◽  
Software Products ◽  
Model Configuration ◽  
Software Product ◽  
Software And Hardware ◽  
Application Requirements

The aim of the Software Product Line (SPL) approach is to improve the software development process by producing software products that match the stakeholders’ requirements. One of the important topics in SPLs is the feature model (FM) configuration process. The purpose of configuration here is to select and remove specific features from the FM in order to produce the required software product. At the same time, detection of differences between application’s requirements and the available capabilities of the implementation platform is a major concern of application requirements engineering. It is possible that the implementation of the selected features of FM needs certain software and hardware infrastructures such as database, operating system and hardware that cannot be made available by stakeholders. We address the FM configuration problem by proposing a method, which employs a two-layer FM comprising the application and infrastructure layers. We also show this method in the context of a case study in the SPL of a sample E-Shop website. The results demonstrate that this method can support both functional and non-functional requirements and can solve the problems arising from lack of attention to implementation requirements in SPL FM selection phase.

scholarly journals CyberSPL: A Framework for the Verification of Cybersecurity Policy Compliance of System Configurations Using Software Product Lines

2019 ◽  
Vol 9 (24) ◽  
pp. 5364 ◽  
Author(s):  
Ángel Jesús Varela-Vaca  ◽  
Rafael M. Gasca ◽  
Rafael Ceballos ◽  
María Teresa Gómez-López ◽  
Pedro Bernáldez Torres
Keyword(s):  
Automated Analysis ◽  
Software Product Lines ◽  
Product Line ◽  
Feature Models ◽  
Product Lines ◽  
Software Products ◽  
Wide Range ◽  
Proposal A ◽  
Software Product ◽  
Real Scenario

Cybersecurity attacks affect the compliance of cybersecurity policies of the organisations. Such disadvantages may be due to the absence of security configurations or the use of default configuration values of software products and systems. The complexity in the configuration of products and systems is a known challenge in the software industry since it includes a wide range of parameters to be taken into account. In other contexts, the configuration problems are solved using Software Product Lines. This is the reason why in this article the framework Cybersecurity Software Product Line (CyberSPL) is proposed. CyberSPL is based on a methodology to design product lines to verify cybersecurity policies according to the possible configurations. The patterns to configure the systems related to the cybersecurity aspects are grouped by defining various feature models. The automated analysis of these models allows us to diagnose possible problems in the security configurations, reducing or avoiding them. As support for this proposal, a multi-user and multi-platform solution has been implemented, enabling setting a catalogue of public or private feature models. Moreover, analysis and reasoning mechanisms have been integrated to obtain all the configurations of a model, to detect if a configuration is valid or not, including the root cause of problems for a given configuration. For validating the proposal, a real scenario is proposed where a catalogue of four different feature models is presented. In this scenario, the models have been analysed, different configurations have been validated, and several configurations with problems have been diagnosed.

A Generic Process for the Design and Generation of Software Product Line Skeleton Architectures

2014 ◽  
Vol 24 (09) ◽  
pp. 1301-1335
Author(s):  
Maria Eugenia Cabello ◽  
Isidro Ramos ◽  
Oscar Alberto Santana ◽  
Saúl Iván Beristain
Keyword(s):  
Software Architecture ◽  
Software Product Line ◽  
Product Line ◽  
Feature Model ◽  
Software Systems ◽  
Reference Architecture ◽  
Product Lines ◽  
Model Driven ◽  
Software Product ◽  
And Behavior

This paper presents a process, a method and a framework for developing families of software systems in a domain. The process is generic (domain-independent) and produces skeleton software architectures as Software Product Lines. The genericity is supported by the metamodels (abstract languages) that are defined in order to describe the Reference Architecture (structure view, behavior view and variability view) of the system domain. A standardized Production Plan takes the Reference Architecture as input and produces the equivalent Skeleton Software Architecture (component-connector view) using a Feature Model configuration (describing the system to be) as output. This Skeleton Software Architecture includes the structure and behavior of the target software product. A framework has been implemented to support the approach. The process is applied, as an example, to the Diagnostic Expert Systems domain. Our approach is based on Model-Driven Engineering techniques and the Software Product Line paradigm. A domain analysis must be done in order to build the Reference Architecture.

scholarly journals A LITERATURE REVIEW ON FEATURE DIAGRAM PRODUCT COUNTING AND ITS USAGE IN SOFTWARE PRODUCT LINE ECONOMIC MODELS

2013 ◽  
Vol 23 (08) ◽  
pp. 1177-1204 ◽  
Author(s):  
RUBEN HERADIO ◽  
DAVID FERNANDEZ-AMOROS ◽  
JOSE A. CERRADA ◽  
ISMAEL ABAD
Keyword(s):  
Cost Savings ◽  
Economic Models ◽  
Automated Analysis ◽  
Software Product Line ◽  
Product Line ◽  
Product Lines ◽  
Software Product ◽  
Feature Diagram ◽  
The Cost ◽  
Line Engineering

In software product line engineering, feature diagrams are a popular means to represent the similarities and differences within a family of related systems. In addition, feature diagrams implicitly model valuable information that can be used in economic models to estimate the cost savings of a product line. In particular, this paper reviews existing proposals on computing the total number of products modeled with a feature diagram and, given a feature, the number of products that implement it. This paper also reviews the economic information that can be estimated when such numbers are known. Thus, this paper contributes by bringing together previously-disparate streams of work: the automated analysis of feature diagrams and economic models for product lines.

Addressing Non-Functional Properties in Feature Models: A Goal-Oriented Approach

2014 ◽  
Vol 24 (10) ◽  
pp. 1439-1487 ◽  
Author(s):  
Mehdi Noorian ◽  
Mohsen Asadi ◽  
Ebrahim Bagheri ◽  
Weichang Du
Keyword(s):  
Functional Properties ◽  
Product Line ◽  
Feature Model ◽  
Software Systems ◽  
Feature Models ◽  
Target Domain ◽  
Product Lines ◽  
Software Products ◽  
Software Product ◽  
Goal Models

Software Product Line (SPL) engineering is a systematic reuse-based software development approach which is founded on the idea of building software products using a set of core assets rather than developing individual software systems from scratch. Feature models are among the widely used artefacts for SPL development that mostly capture functional and operational variability of a system. Researchers have argued that connecting intentional variability models such as goal models with feature variability models in a target domain can enrich feature models with valuable quality and non-functional information. Interrelating goal models and feature models has already been proposed in the literature for capturing non-functional properties in software product lines; however, this manual integration process is cumbersome and tedious. In this paper, we propose a (semi) automated approach that systematically integrates feature models and goal models through standard ontologies. Our proposed approach connects feature model and goal model elements through measuring the semantic similarity of their annotated ontological concepts. Our work not only provides the means to systematically interrelate feature models and goal models but also allows domain engineers to identify and model the role and significance of non-functional properties in the domain represented by the feature model.

Sign in / Sign up

Export Citation Format

Share Document