Search

In this paper, we report on a case study in an industrial setting where code is generated from models, and, for various reasons, that generated code is then manually modified. To enhance the maintainability of both models and code, consistency between them is imperative. A first step towards establishing that consistency is to identify the manual changes that were made to the code after it was generated and deployed. Identifying the delta is not straightforward and requires pre-processing of the artifacts. The main mechanics driving our solution are higher-order transformations, which make the implementation scalable and robust to small changes in the modeling language. We describe the specific industrial setting of the problem, as well as the experiences and lessons learned from developing, implementing, and validating our solution together with our industrial partner.

The software system controlling a train is typically deployed on various hardware architectures and must process various signals across those deployments. The increase of such customization scenarios and the needed adherence of the software to various safety standards in different application domains has led to the adoption of product line engineering within the railway domain. This paper explores the current state-of-practice of software product line development within a team developing industrial embedded software for a train propulsion control system. Evidence is collected using a focus group session with several engineers and through inspection of archival data. We report several benefits and challenges experienced during product line adoption and deployment. Furthermore, we identify and discuss improvement opportunities, focusing mainly on product line evolution and test automation.

Eventual consistency between design and implementation is imperative for the quality and maintainability of software systems. Towards achieving this consistency, engineers can analyze the gaps between models and corresponding code to gain insights into differences between design and implementation. Due to the different levels of abstraction of the involved artifacts, this analysis is a complex task to automate. We study an industrial MBSE setting where we aim to provide model-code gap analysis between SysML system models and corresponding C/C++ code through structural consistency checks. To this end, we propose an extension of the OpenMBEE platform, to include code as one of the synchronized development artifacts in addition to models and documentation. In this paper, we outline our initial research idea to include code as a view in this platform and we propose to explicitly link the code to generated documentation, and thereby to the model.

Recent years have seen an increasing attention to social aspects of software engineering, including studies of emotions and sentiments experienced and expressed by the software developers. Most of these studies reuse existing sentiment analysis tools such as SentiStrength and NLTK. However, these tools have been trained on product reviews and movie reviews and, therefore, their results might not be applicable in the software engineering domain. In this paper we study whether the sentiment analysis tools agree with the sentiment recognized by human evaluators (as reported in an earlier study) as well as with each other. Furthermore, we evaluate the impact of the choice of a sentiment analysis tool on software engineering studies by conducting a simple study of differences in issue resolution times for positive, negative and neutral texts. We repeat the study for seven datasets (issue trackers and Stack Overflow questions) and different sentiment analysis tools and observe that the disagreement between the tools can lead to diverging conclusions. Finally, we perform two replications of previously published studies and observe that the results of those studies cannot be confirmed when a different sentiment analysis tool is used.

In model-based development projects, models at different abstraction levels capture different aspects of a software system, e.g., specification or design. Inconsistencies between these models can c ...