Supporting feature model evolution by suggesting constraints from code-level dependency analyses

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.

Static code analysis is a very important stage in the development and implementation of software, and it needs to be used to obtain a better code. The most complicated in static analysis is the analysis of source code, and further analysis. Analysis of the source code can be done multiple times and expand the set of necessary grammar. The main goal was and remains to provide a solution to reduce the time needed for a global reassessment of static analysis at code level after a change.The main problem when using static code analysis is to build an abstract semantic graph, because each software solution is provided with a separate data warehouse. The proposed solution proposes to use as a database repository using graphs. Thus, the storage mechanisms of the created abstract semantic graph have been simplified, which in turn, in addition to increasing the clarity of the information we store, provides convenient ways to further work with the stored information.The developed solution can transform a rather large source repository into a graphic representation and maintain it later. It is found that the approach is suitable for carrying out code compliance checks and for performing static analysis tests on a graphic representation. This approach also uses advanced file-level detailing, accelerating static analysis. Based on my measurements, the frameworks are fast enough to help their users quickly change the repository of codes.This article confirms the thesis about the possibility of storing an abstract semantic graph in a graph database, and after refinement, if it contains sufficient transformations and requests for language processing, can become a complete transport for communication between various static analysis tools that usually perform one of two the functions of verification either for quality or for vulnerability, thereby making a unified creation of an abstract semantic graph.As an improvement it is necessary to consider the possibility of incremental analysis – the analysis of changes in the code, in order to minimize resource costs for a rather resource intensive operation of the structure of the abstract semantic graph.Manuscript received 09.06.2020

Feature models are frequently used to capture the knowledge about configurable software systems and product lines. However, feature modeling of large-scale systems is challenging as many models are needed for diverse purposes. For instance, feature models can be used to reflect the perspectives of product management, technical solution architecture, or product configuration. Furthermore, models are required at different levels of granularity. Although numerous approaches and tools are available, it remains hard to define the purpose, scope, and granularity of feature models. In this paper we thus present experiences of developing feature models for two large-scale industrial automation software systems. Specifically, we extended an existing feature modeling tool to support models for different purposes and at multiple levels. We report results on the characteristics and modularity of the feature models, including metrics about model dependencies. We further discuss lessons learned during the modeling process.

Feature models are widely used for describing the variability of a software product line. A feature model contains a tree of features and a set of constraints over these features, which define valid feature combinations. In the industrial practice, large feature models containing hundreds of features and constraints are common. Furthermore, in a hierarchical product line a feature model can be related to other feature models through inter-model constraints. Due to the model size and complexity, understanding industrial feature models is a challenging task.In this paper, we describe the feature model understanding challenges reported by feature model developers at Robert Bosch GmbH. To support the developers in model understanding, we extend the idea of a feature implication graph to feature relation graph by abstracting groups of implications to feature relations. A transitively closed relation graph shows all modeled and implicit feature relations and spans all related feature models. The graph is also used to identify modeling problems, such as false optional or dead features, and to show the derivation of any implicit relation or problem from the modeled constraints. In a case study at Bosch, we evaluate the use of feature relation graph for model understanding. We propose further use cases of the graph, supporting model maintenance, evolution and configuration.

[Context and Motivation] Organizations pursuing software product line engineering often use feature models to define the commonalities and variability of software-intensive systems. Frequently, requirements-level features are mapped to development artifacts to ensure traceability and to facilitate the automated generation of downstream artifacts. [Question/Problem] Due to the continuous evolution of product lines and the complexity of the artifact dependencies, it is challenging to keep feature models consistent with their underlying implementation. [Principal Ideas/Results] In this paper, we outline an approach combining feature-to-artifact mappings and artifact dependency analysis to inform domain engineers about possible inconsistencies. In particular, our approach uses static code analysis and a variation control system to lift complex code-level dependencies to feature models. [Contributions] We demonstrate the feasibility of our approach using a Pick-and-Place Unit system and outline our further research plans.

Creating products according to own needs is omnipresent on the Internet. We choose the properties we want to have in a product from a product configurator, such as a car or printer configurator. The underlying models from the configurators are hidden. The migration of legacy configurators into feature models is meaningful to use the advantages of software configurations for product configurators. We introduce an abstraction level and assumptions for product configurators to readout information needed for a feature model. Furthermore, we develop an algorithm called FeatureDiagramSynthesizer. The algorithm consists of two parts which are finding features and adding constraints. For the algorithm, different strategies are used to create the feature model from a product configurator. Moreover, we implement the extensible algorithm FeatureDiagramSynthesizer and a prototype for the product configurator from Ricoh. Based on our developed algorithm, it is only basically possible to readout a feature models from product configurators which fulfill our assumptions.

Feature models are commonly used to specify variability in software product lines. Several tools support feature models for variability management at different steps in the development process. However, tool support for test configuration generation is currently limited. This test generation task consists in systematically selecting a set of configurations that represent a relevant sample of the variability space and that can be used to test the product line. In this paper we propose \pw tool to analyze feature models and automatically generate a set of configurations that cover all pair wise interactions between features. \pw tool relies on constraint programming to generate configurations that satisfy all constraints imposed by the feature model and to minimize the set of the tests configurations. This work also proposes an extensive experiment, based on the state-of-the art SPLOT feature models repository, showing that \pw tool scales over variability spaces with millions of configurations and covers pair wise with less configurations than other available tools.

Software product lines are able to describe multiple products sharing a common base of features and are commonly described as feature models. For complex software product lines, automatic analyses are required to ensure validity and to improve the interactive configuration process. Modern SAT solvers are vital components for the validation process of feature models. The increasing variability of software product lines implies the need to use more expressive solvers like SMT solvers. To assist the development of feature modeling tools, we compare SAT and SMT solvers for the automated analysis of feature models. During this thesis, we create an abstract data type to formally define analyses for feature model defects and their explanations. The result shows that SAT solvers are more efficient at detecting the defects, while SMT solvers can find explanations for them multiple times faster. Feature models can be further expanded by attaching attributes to features. Such attributes may contain a numerical value. Additionally, one attribute can be defined for multiple features. In this thesis, we aim to support the interactive configuration process, by providing the range of the sum of values for an attribute. Such ranges depend on the remaining choices in a configuration of the product line. We provide an exact computation using SMT and an approximation using a heuristic. The evaluation results show that an SMT solver is not suitable for supporting interactive configuration. However, the approximated ranges of the provided heuristic were very close to the exact ones.

To increase and maintain web application security, developers could use some different methods, one of them is static code analysis. This method could find security vulnerabilities inside a source code without the need of running the program. It could also be automated by using tools, which considered more efficient than manual reviews. One specific method which is commonly used in static code analysis is taint analysis. Taint analysis usually utilizes source code modeling to prepare the code for analysis process to detect any untrusted data flows into security sensitives computations. While this kind of analysis could be very helpful, static code analysis tool for Laravel-based web application is still quite rare, despite its popularity. Therefore, in this research, we want to know how static code (taint) analysis could be utilized to detect security vulnerabilities and how the projects (Laravel-based) should be modeled in order to facilitate this analysis. We then developed a static analysis tool, which models the application’s source code using AST and dictionary to be used as the base of the taint analysis. The tool first parsed the route file of Laravel project to get a list of controller files. Each file in that list would be parsed in order to build the source code representation, before actually being analyzed using taint analysis method. The experiments was done using this tool shows that the tools (with taint analysis) could detect 13 security vulnerabilities from 6 Laravel-based projects with one False Negative. An ineffective sanitizer was the suspected cause of this False Negative. This also shows that proposed modeling technique could be helpful in facilitating taint analysis in Laravel-based projects. For future development and studies, this tool should be tested with more Laravel and even other framework based web application with a wider range of security vulnerabilities.

The large number of industrial control systems based on PLCs (Programmable Logic Controllers) available at CERN implies a huge number of programs and lines of code. The software quality assurance becomes a key point to ensure the reliability of the control systems. Static code analysis is a relatively easy-to-use, simple way to find potential faults or error-prone parts in the source code. While static code analysis is widely used for general purpose programming languages (e.g. Java, C), this is not the case for PLC program languages. We have analyzed the possibilities and the gains to be expected from applying static analysis to the PLC code used at CERN, based on the UNICOS framework. This paper reports on our experience with the method and the available tools and sketches an outline for future work to make this analysis method practically applicable.

Secure software engineering has emerged in recent decades by encouraging the idea of software security has to be an integral part of all the phases of the software development lifecycle. As a result, each phase of the lifecycle is associated with security-specific best practices such as threat modeling and static code analysis. It was observed that various artifacts (i.e., security requirements, architectural flaws, bug reports, security test cases) generated as a result of security best practices tend to be segregated. This creates a significant barrier to resolve the security issues at the implementation phase since most of them are originated in the design phase. In order to address this issue, this paper presents a knowledge-modeling based approach to semantically infer the associations between architectural level security flaws and code-level security bugs, which is manually tedious. Threat modeling and static analysis are used to identify security flaws and security bugs, respectively. The case study based experimental results revealed that the architectural level security flaws have a significant impact on originating security bugs in the code level. Besides, the evaluation results confirmed the scalability of the proposed approach to large-scale industrial software products.

Feature models (FMs) are a popular formalism for describing the commonality and variability of software product lines (SPLs) in terms of features. SPL development increasingly involves manipulating many large FMs, and thus scalable modular techniques that support compositional development of complex SPLs are required. In this paper, we describe how a set of complementary operators (aggregate, merge, slice) provides practical support for separation of concerns in feature modeling. We show how the combination of these operators can assist in tedious and error prone tasks such as automated correction of FM anomalies, update and extraction of FM views, reconciliation of FMs and reasoning about properties of FMs. For each task, we report on practical applications in different domains. We also present a technique that can efficiently decompose FMs with thousands of features and report our experimental results.

Feature model is a popular formalism for describing the commonality and variability of a software product line in terms of features. Feature models symbolise a presentation of the possible application configuration space, and can be customised based on specific domain requirements and stakeholder goals. As feature models are becoming increasingly complex, it is desired to provide automatic support for customised analysis and verification based on the specific goals and requirements of stakeholders. This paper first presents feature model slicing based on the requirements of the users. We then introduce three-valued abstraction of behaviour models based on the slicing unit. Finally, based on multi-valued model checker, a case study was conducted to illustrate the effectiveness of our approach.

The prevalence and significance of web services in our daily lives make it imperative to ensure that they are – as much as possible – free from vulnerabilities. However, developing a complex piece of software free from any security vulnerabilities is hard, if not impossible. One way to progress towards achieving this holy grail is by using static code analysis tools to root out any common or known vulnerabilities that may accidentally be introduced during the development process. Static code analysis tools have significantly contributed to addressing the problem above, but are imperfect. It is conceivable that static code analysis can be improved by using AI-powered tools, which have recently increased in popularity. However, there is still very little work in analysing both types of tools’ effectiveness, and this is a research gap that our paper aims to fill. We carried out a study involving 11 static code analysers, and one AI-powered chatbot named ChatGPT, to assess their effectiveness in detecting 92 vulnerabilities representing the top 10 known vulnerability categories in web applications, as classified by OWASP. We particularly focused on PHP vulnerabilities since it is one of the most widely used languages in web applications. However, it has few security mechanisms to help its software developers. We found that the success rate of ChatGPT in terms of finding security vulnerabilities in PHP is around 62-68%. At the same time, the best traditional static code analyser tested has a success rate of 32%. Even combining several traditional static code analysers (with the best features on certain aspects of detection) would only achieve a rate of 53%, which is still significantly lower than ChatGPT’s success rate. Nonetheless, ChatGPT has a very high false positive rate of 91%. In comparison, the worst false positive rate of any traditional static code analyser is 82%. These findings highlight the promising potential of ChatGPT for improving the static code analysis process but reveal certain caveats (especially regarding accuracy) in its current state. Our findings suggest that one interesting possibility to explore in future works would be to pick the best of both worlds by combining traditional static code analysers with ChatGPT to find security vulnerabilities more effectively.

Reengineering a legacy product line has been addressed very little by current product line research activities. This paper introduces a method to investigate feature dependencies and interactions, which restricts the variants that can be derived from the legacy product line assets. Reorganizing the product line assets with respect to new requirements requires more knowledge than what is easily provided by the classical feature-modeling approaches. Hence, adding all the feature dependencies and interactions into the feature tree results in unreadable and unmanageable feature models that fail to achieve their original goals.We therefore propose two complementary views to represent the feature model. One view shows the hierarchical refinement of features similar to common feature-modeling approaches in a feature tree. The second view describes what kind of dependencies and interactions there are between various features.We show two examples of feature dependencies and interactions in the context of an engine-control software product line, and we demonstrate how our approach helps to define correct product configurations from product line variants.