Code-based analyzers often find too many potentially security-related issues to address them all. Therefore, issues likely to lead to vulnerabilities should be fixed first. Such prioritization requires project-specific knowledge, such as quality requirements, security-related decisions, and design, which is not accessible to code analyzers. We present TraceSEC, an automated technique for prioritizing issues according to their security-related importance to the project. Its core concept is to incorporate available design artifacts and trace links between them, thus considering the project context that the code lacks. We reduce the problem of issue prioritization to a maximum flow problem and quantify the importance of each issue by the flow from user-defined quality aspects to the issue, i.e., quantifying its impact on project-specific security preferences. Our evaluation shows that TraceSEC effectively provides automated prioritization and can be tailored to project-specific quality goals. Its prioritization correlates stronger with manual expert prioritization than SonarQube rule severities, which are commonly used in practice. In particular, TraceSEC has a higher similarity for identifying high-priority issues. TraceSEC scales reasonably well for codebases up to four million lines of code, and the initial setup overhead is likely to be recouped after the first automated prioritization.

Abstract Decision-making systems are prone to discrimination against individuals with regard to protected characteristics such as gender and ethnicity. Detecting and explaining the discriminatory behavior of implemented software is difficult. To avoid the possibility of discrimination from the onset of software development, we propose a model-based methodology called MBFair that allows for verifying UML-based software designs with regard to individual fairness. The verification in MBFair is performed by generating temporal logic clauses, whose verification results enable reporting on the individual fairness of the targeted software. We study the applicability of MBFair using three case studies in real-world settings including a bank services system, a delivery system, and a loan system. We empirically evaluate the necessity of MBFair in a user study and compare it against a baseline scenario in which no modeling and tool support is offered. Our empirical evaluation indicates that analyzing the UML models manually produces unreliable results with a high chance of 46% that analysts overlook true-positive discrimination. We conclude that analysts require support for fairness-related analysis, such as our MBFair methodology.

137

Engineering Cyber-Physical Production Systems (CPPSs) heavily relies on Domain-Specific Languages (DSLs), which are tailored to a specific class of problems inherent to CPPSs. DSLs enable non-programming experts to solve problems in their domain, such as modeling production processes, implementing control software, or managing the variability of production systems. A DSL ecosystem encompasses the entire infrastructure (e.g., libraries and tools) built around its language and contributes to the successful and easy adoption thereof by domain experts. We present a maturity evaluation model for DSL ecosystems serving two aims: to developers, it reveals missing but essential aspects of the ecosystem, and users (e.g., industrial companies) can evaluate the maturity of a DSL ecosystem. We propose criteria to evaluate the maturity of DSL ecosystems and apply them to existing, publicly available DSLs which have been adopted in CPPSs. The results demonstrate that all components of the model are covered and they allow for deriving hypotheses about DSL ecosystems used in CPPSs.

Cyber-Physical Production Systems (CPPSs) are envisioned as next-generation adaptive production systems combining modern production techniques with the latest information technology. A CPPS creates a complex environment between different domains (mechanical, electrical, software engineering), requiring multidisciplinary solutions to tackle growing complexity issues and reduce (maintenance) effort. Software plays an increasingly important role in assuring an effective and efficient operation of CPPSs. However, software engineering methods applied for CPPSs seem to lag behind modern software engineering methods, where tremendous progress has been made in the last years. We initiated the Software Engineering in Cyber-Physical Production Systems Workshop (SECPPS-WS) to analyze and overcome this gap. After two instances with mostly academic participants, we conducted a full-day workshop with nine industry representatives from eight companies that develop and maintain CPPSs. Each industry representative presented their current work and challenges. We collected these challenges and condensed a categorized list of challenges backed by industry statements and literature. This paper presents the resulting list and pointers to (partial) solutions to offer guidance for academia and identify promising research opportunities in this area.

Existing fair exchange protocols usually neglect consideration of cost when assessing their fairness. However, in an environment with non-negligible transaction cost, e.g., public blockchains, high or unexpected transaction cost might be an obstacle for wide-spread adoption of fair exchange protocols in business applications. For example, as of 2021-12-17, the initialization of the FairSwap protocol on the Ethereum blockchain requires the selling party to pay a fee of approx. 349.20 USD per exchange. We address this issue by defining cost fairness, which can be used to assess two-party exchange protocols including implied transaction cost. We show that in an environment with non-negligible transaction cost where one party has to initialize the exchange protocol and the other party can leave the exchange at any time cost fairness cannot be achieved.

Context: Software architecture (SA) as research area experienced an increase in empirical research, as identified by Galster and Weyns in 2016 [1]. Empirical research builds a sound foundation for the validity and comparability of the research. A current overview on the evaluation and replicability of SA research objects could help to discuss our empirical standards as a community. However, no such current overview exists.Objective: We aim at assessing the current state of practice of evaluating SA research objects and replication artifact provision in full technical conference papers from 2017 to 2021.Method: We first create a categorization of papers regarding their evaluation and provision of replication artifacts. In a systematic literature review (SLR) with 153 papers we then investigate how SA research objects are evaluated and how artifacts are made available.Results: We found that technical experiments (28%) and case studies (29%) are the most frequently used evaluation methods over all research objects. Functional suitability (46% of evaluated properties) and performance (29%) are the most evaluated properties. 17 papers (11%) provide replication packages and 97 papers (63%) explicitly state threats to validity. 17% of papers reference guidelines for evaluations and 14% of papers reference guidelines for threats to validity.Conclusions: Our results indicate that the generalizability and repeatability of evaluations could be improved to enhance the maturity of the field; although, there are valid reasons for contributions to not publish their data. We derive from our findings a set of four proposals for improving the state of practice in evaluating software architecture research objects. Researchers can use our results to find recommendations on relevant properties to evaluate and evaluation methods to use and to identify reusable evaluation artifacts to compare their novel ideas with other research. Reviewers can use our results to compare the evaluation and replicability of submissions with the state of the practice.