Abstract Metamodels, like many other software artifacts, evolve and exist in multiple versions. As a result, their instances, i.e., models, can become outdated and require adaptation. This process is known as model co-evolution. Co-evolution, however, typically uses an all-or-nothing approach that overlooks four key aspects: (a) preserving the history of the metamodel, (b) retaining the model’s history before co-evolution, (c) supporting the coexistence of models across multiple metamodel versions to allow delayed co-evolution and (d) lack of traceability between model and metamodel changes. In this paper, we introduce a novel, operation-based approach that supports versioning, records the complete history of metamodels and models, and enables the coexistence of different metamodel versions. Our approach allows engineers to delay model co-evolution without losing a model’s history. It further enables both forward co-evolution and reverse de-evolution of models. In addition to that, it establishes cross-layer traceability by linking model changes back to their corresponding metamodel changes, thus improving the maintainability and understandability of evolving systems. We evaluated our approach empirically using metamodels from different domains, demonstrating that it accurately records both model and metamodel histories, supports de-evolution, and correctly traces over 17 million model changes to their metamodel origins. Scalability measurements show that our approach handles co-evolution even in large-scale scenarios, successfully evolving models with over 88,000 elements and 2 million properties while tracking nearly 500,000 changes.

In safety-critical engineering domains, engineering processes guide developers toward producing systems that adhere to stringent standards of safety and quality, while also allowing for the inherent flexibility of creative tasks. Process compliance focuses on ensuring that the engineering work-as manifested in the creation, tracking, and tracing of engineering artifacts-follows the described processes as closely as possible. The sequence of process steps is typically described using temporal process constraints over engineering artifact metadata (e.g., a requirement must transition from ‘draft’ to ‘ready for review’). Existing approaches, however, lack support for checking temporal constraints during development and rely on manual checks, resulting in delayed feedback when deviations occur. In this paper, we present an automated, incremental constraint checking approach that can evaluate temporal constraints across inter-related artifacts upon every artifact change, enabling timely feedback on process deviations. Our approach includes an incremental checking mechanism for temporal process constraints, and the ability to dynamically evaluate and integrate the history of artifacts as they become relevant for the constraints. Temporal constraints are expressed in the Object Constraint Language (OCL) extended with operators from Linear Temporal Logic (LTL). We demonstrate the ability of our approach to support a wide range of higher-level temporal patterns. We show that for constraints in an industry-derived use case, we can detect a significant number of temporal process constraint violations, some remaining unfulfilled after the end of the development process. We also find that, in this use case, the average evaluation for a single constraint operator takes around 0.3 milliseconds.

Just-in-time defect prediction (JIT-DP) aims to predict the likelihood of code changes resulting in software defects at an early stage. Although code change metrics and semantic features have enhanced prediction accuracy, prior research has largely ignored code refactoring during both the evaluation and methodology phases, despite its prevalence. Refactoring and its propagation often tangle with bug-fixing and bug-inducing changes within the same commit and statement. Neglecting refactoring can introduce bias into the learning and evaluation of JIT-DP models. To address this gap, we investigate the impact of refactoring and its propagation on six state-of-the-art JIT-DP approaches. We propose Code chAnge Tactics (CAT) analysis to categorize code refactoring and its propagation, which improves labeling accuracy in the JIT-Defects4J dataset by $\mathbf{1 3. 7}$. Our experiments reveal that failing to consider refactoring information in the dataset can diminish the performance of models, particularly semantic-based models, by $\mathbf{1 8. 6}$ % and $\mathbf{3 7. 3} \%$ in F1-score. Additionally, we propose integrating refactoring information to enhance six baseline approaches, resulting in overall improvements in recall and $\mathbf{F 1}$-score, with increases of up to $43.2 \%$ and $32.5 \%$, respectively. Our research underscores the importance of incorporating refactoring information in the methodology and evaluation of JIT-DP. Furthermore, our CAT has broad applicability in analyzing refactoring and its propagation for software maintenance.

One of the most important artifacts of Model-Driven Engineering (MDE) are metamodels. Like other software artifacts, they are expected to evolve. Consequently, their models thus become invalid and need to be fixed. The usual strategy is to adapt those models based on changes made to the metamodel, i.e., co-evolution. Co-evolution, however, depends on correctly recorded changes since even small deviations can impact the models that will be evolved. One problem is that those changes are usually not preserved or complete. The reason is that the most common way to record the history of metamodels is by using text-based version control systems, i.e., Git. This, however, hinders the detection of the concrete changes made to the metamodel, which are used for co-evolution. This aspect leads to problems in maintaining and evolving metamodels and their models in practice. In this paper, we propose a novel approach that allows engineers to reconstruct the history of metamodels with the help of ChangeTrees. These ChangeTrees recommend possible sequences of changes between two metamodel versions, i.e., evolved metamodels. We conducted an empirical study that detected changes to eight different metamodels across varying domains. The results show that our approach can correctly reconstruct the metamodel's history by detecting all possible changes between the two versions. Furthermore, performance results show that, in the worst case, our approach required 15.65 seconds to detect and generate a ChangeTree of a metamodel with more than 351 changes applied to it (between two versions), leading to 11,268 branching change paths (alternative sequences of changes).

Abstract In safety‐critical systems engineering, regulations such as Automotive SPICE, ISO26262, or ED‐109A mandate software quality assurance measures to provide evidence that the developed system is high quality. The constraints that define quality assurance conditions during the engineering life cycle are often non‐trivial. This paper addresses the challenges, engineers face who are unfamiliar with the precise constraints of various projects (e.g., when newly joining a company or switching between departments). Understanding how to fulfill a constraint is a time‐consuming and challenging task as an engineer needs to determine the most suitable option (out of potentially many) to fulfill a constraint violation. To this end, we propose a guidance action ranking framework to provide engineers with the most relevant guidance actions. Our primary ranking algorithm analyzes in the background the actions that engineers have made in the past to resolve a constraint violation without requiring explicit feedback from them. We evaluated our framework on two real‐world data sets: an open‐source drone management and an industrial air traffic control software system. Concretely, we replay past engineering activities and measured whether, in the case of a constraint violation, our suggested guidance actions were indeed selected by the engineer. The evaluation results revealed that learning from prior guidance actions effectively identifies the most appropriate guidance actions (ranked top 1 or 2) when compared to ranking algorithms based on action simplicity and artifact property change frequency. Specifically, we achieve a median MRR of 0.95 for the first case study and 0.94 for the second case study: an improvement of 80% and 100% over the baseline. Additionally, we observed that the simplicity of a guidance action does not reliably indicate its suitability for fulfilling a constraint, whereas learning from prior change operation property out‐performed simplicity‐based ranking but did not surpass guidance frequency‐based ranking.

ABSTRACT This paper addresses the challenge of automating process‐centric quality assurance (QA) in safety‐critical domains, where compliance with regulations is crucial. Currently, QA engineers manually check compliance using tedious methods like browsing engineering artifacts and ad‐hoc scripts. Automated support could improve efficiency, but it requires constraints to be written in structured, executable forms (e.g., in the Object Constraint Language, OCL), whereas engineers prefer natural language. To bridge this gap, we propose the use of large language models (LLMs) to generate OCL from natural language, enhanced by schema‐based prompting and domain‐specific language (DSL)–based repairs. Unlike prior work focused on UML models, this work applies OCL to software process QA. Evaluating six LLMs, we find o1‐mini and Codestral perform best, with our automatic repairs ensuring constraint executability for 22%–44% of an LLM's generated OCL constraints that would otherwise remain nonexecutable due to errors.

ABSTRACT Users of software applications use issue tracking systems (ITSs) to file enhancement reports, which leads to a large quantity of user requests. These reports play a pivotal role in shaping software requirements and continuous product improvement. However, the manual evaluation of these reports by developers and maintainers can be a time‐consuming and labor‐intensive process due to the constant influx of enhancement requests. Timely handling and implementation of these enhancement reports are crucial for enhancing user satisfaction and product competitiveness. In response to this challenge, research has concentrated on automated methods to predict which enhancement reports are likely to gain approval, aiming to maximize the value extracted from user feedback. Nevertheless, existing approaches still fall short in delivering practical results. In this paper, we introduce a novel creator profile‐based approach designed to uncover the dependency between creators' identity and the value of enhancement reports, ultimately enhancing prediction accuracy. Firstly, we present the concept of a “creator profile” and outline a comprehensive methodology for generating creator profiles from the dataset. We then demonstrate how creator profiles can be effectively applied to the task of predicting the approval of enhancement reports. Subsequently, we assess the performance of our approach using a dataset of 40,551 enhancement reports collected from ITSs. The experimental results indicate a substantial improvement over the existing state of the art, particularly in predicting approved reports. For cross‐application prediction, the accuracy reaches 80.7%, while for non–cross‐application prediction, the overall accuracy is 83.6%. In essence, with the proposed approach, over 80% of user requests can be automatically identified for exacting valuable user requirements, which significantly reduces labor costs. The replication package is available at https://github.com/feifeiniu‐se/approval_prediction .

practice to create software-intensive systems in several domains (e.g., aerospace, automotive, and robotics). However, when multiple engineers work concurrently, keeping all model artifacts synchronized and consistent is difficult. This is even harder when the engineering process relies on a myriad of tools and domains (e.g., mechanic, electronic, and software). Existing work tries to solve this issue from different perspectives, such as using trace links between different artifacts or computing change propagation paths. However, these solutions mainly provide additional information to engineers, still requiring manual work for propagating changes. Yet, most modeling tools are limited regarding the traceability between different domains, while also lacking the efficiency and granularity required during the development of software-intensive systems. Motivated by these limitations, in this work, we present a solution based on what we call "reactive links", which are highly granular trace links that propagate change between property values across models in different domains, managed in different tools. Differently from traditional "passive links", reactive links automatically propagate changes when engineers modify models, assuring the synchronization and consistency of the artifacts. The feasibility, performance, and flexibility of our solution were evaluated in three practical scenarios, from two partner organizations. Our solution is able to resolve all cases in which change propagation among models were required. We observed a great improvement of efficiency when compared to the same propagation if done manually. The contribution of this work is to enhance the engineering of software-intensive systems by reducing the burden of manually keeping models synchronized and avoiding inconsistencies that potentially can originate from collaborative engineering in a variety of tool from different domains.

Software modernization is a common activity in software engineering, since technologies advance, requirements change, and business models evolve. Differently from conventional software evolution (e.g., adding new features, enhancing performance, or adapting to new requirements), software modernization involves re-engineering entire legacy systems (e.g., changing the technology stack, migrating to a new architecture style, or programming paradigms). Given the pervasive nature of software today, modernizing legacy systems is paramount to provide customers with competitive and innovative products and services, while keeping companies profitable. Despite the prevalent discussion of software modernization in gray literature, and the many papers in the literature, there is no work presenting a “big picture” of contemporary software modernization, describing challenges, and providing a well-defined research agenda. The goal of this work is to describe the state of the art in software modernization in the past 10 years. We collect the state of the art by performing a rapid review (searching five digital libraries), identifying potential 3,460 studies, leading to a final set of 126. We analyzed these studies to understand which strategies are employed, the driving forces that lead organizations to modernize their systems, and the challenges that need to be addressed. The results show that studies in the last 10 years have explored eight strategies for modernizing legacy systems, namely cloudification, architecture redesign, moving to a new programming language, targeting reuse optimization, software modernization for new hardware integration, practices to leverage automation, database modernization, and digital transformation. Modernization is triggered by 14 driving forces, with the most common ones being reducing operational costs, improving performance and scalability, and reducing complexity. In addition, based on the analysis of existing literature, we present a detailed discussion of research opportunities in this field. The main challenges are providing tooling support, followed by defining a modernization process and considering better evaluation metrics. The main contribution of our work is to equip practitioners and researchers with knowledge of the current state of contemporary software modernization so that they are aware of practices and challenges to be addressed when deciding to modernize legacy systems.

With AI increasingly affecting software systems, there is a pressing need to prepare the next generation of software engineers to build AI-intensive systems proficiently. This work outlines our instructional approach in the “Engineering of AI-intensive Systems” course for postgraduate computer science students to bridge the knowledge gap between software engi-neering (SE) and artificial intelligence (AI) disciplines. Our paper elaborates on the course's framework, pedagogical strategies, and evaluation methods, emphasizing the benefits of this interdisci-plinary educational model.

Traceability allows stakeholders to extract and comprehend the trace links among software artifacts introduced across the software life cycle, to provide significant support for software engineering tasks. Despite its proven benefits, software traceability is challenging to recover and maintain manually. Hence, plenty of approaches for automated traceability have been proposed. Most rely on textual similarities among software artifacts, such as those based on Information Retrieval (IR). However, artifacts in different abstraction levels usually have different textual descriptions, which can greatly hinder the performance of IR-based approaches (e.g., a requirement in natural language may have a small textual similarity to a Java class). In this work, we leverage the consensual biterms and transitive relationships (i.e., inner- and outer-transitive links) based on intermediate artifacts to improve IR-based traceability recovery. We first extract and filter biterms from all source, intermediate, and target artifacts. We then use the consensual biterms from the intermediate artifacts to enrich the texts of both source and target artifacts, and finally deduce outer and inner-transitive links to adjust text similarities between source and target artifacts. We conducted a comprehensive empirical evaluation based on five systems widely used in other literature to show that our approach can outperform four state-of-the-art approaches in Average Precision over 15% and Mean Average Precision over 10% on average.

Metamodels like many other software artifacts, are expected to evolve and exist in different versions. Consequently, the instances of these metamodels (models), become invalid and need fixing. The usual strategy for this is adapting models based on changes made to the metamodels, i.e., co-evolution. However, co-evolution usually adopts an all-or-nothing strategy that overlooks three important aspects: (a) preserving the history of the metamodel, (b) preserving the model's history before the co-evolution, and (c) supporting models to co-exist for different metamodel versions and delay their co-evolution. These aspects lead to problems for maintaining models in practice since often co-evolution gets driven by customer needs, e.g., the customer decides when to update. In this paper, we propose a novel approach that allows the creation of a metamodel version and records the history of metamodels and models by adopting an operation-based infrastructure. These metamodel versions allow engineers to delay the co-evolution of certain models by having co-existing metamodel versions. This notion of co-existence, in addition to the operation-based infrastructure, helps to preserve the complete history of metamodel and models, i.e., the history before and after co-evolving a model. To evaluate our approach, we conducted an empirical study, where we co-evolved models of varying domains. The results show that our approach correctly records the history of the metamodel and model. Furthermore, we measured the performance during co-evolution while having all versions co-existing in the same space. It shows that in the worst case, our approach required 887.91 seconds to co-evolve a model with more than 88,000 elements and 2,000,000 properties.

In regulation-intensive domains, software engineering organizations need to demonstrate compliance with process and traceability guidelines. To this end, novel approaches have emerged that support these activities via the automatic checking of constraints. Yet, engineers still need to decide how to fix violated constraints. While some general-purpose state-of-the-art constraint-checking approaches provide basic support for fixing constraint violations, the provided fixing recommendations often lack crucial details. The approaches typically do not analyze the overall constraint to identify which constraint sub-expressions put a restriction on the possible fixing action. For example, a fix suggests “set the parent of requirement R1 to an issue” rather than additionally stating that the “issue needs to be of type ’Change Request’ and in state ’Released” ’. Engineers, therefore, require mental effort to identify such restrictions by analyzing the constraint in detail or require extra time to try out which action completely fixes the constraint violation.

Refining high-level requirements into low-level ones is a common task, especially in safety-critical systems engineering. The objective is to describe every important aspect of the high-level requirement in a low-level requirement, ensuring a complete and correct implementation of the system's features. To this end, standards and regulations for safety-critical systems require reviewing the coverage of high-level requirements by all its low-level requirements to ensure no missing aspects.

Consistency maintenance is paramount for software engineering, as it improves/guarantees the quality of artifacts (e.g., models) during maintenance and evolution. To perform this maintenance, consistency rules (CR) are commonly defined and applied to evaluate model elements according to desired properties. By empirical studies, it is known that CRs commonly evaluate similar model elements (e.g., multiple CRs checking the consistency of a UML class). Thus, we hypothesize that CRs can be used as a means to identify dependencies among inconsis-tencies and support consistency maintenance tasks. Currently, however, no study investigates to what extent dependencies can be identified and how they can be used to repair inconsistencies. In this paper, we explore dependencies between CRs to identify and group dependent inconsistencies. For that, we define a metamodel that allows dependencies to be expressed. Further-more, we propose a consistency maintenance and dependency analysis mechanism that uses such a metamodel. Additionally, the approach generates repairs for the inconsistencies, considering the groups of dependencies to identify overlapping and conflicting repairs. To evaluate the approach, we conducted an empirical study with 48 UML models and 27 CRs. The results show that our approach identifies dependencies between inconsistencies (46 % of the inconsistencies have dependencies), within a reasonable time, 10ms on average in the worst case. Results also show that dependent inconsistencies can be grouped and used together to identify repairs that are either overlapping (26 % on average) or conflicting (58 % on average).

Refinement guarantees that the concrete version of a model does not violate the constraints introduced at the abstract level. The peculiarity of refinement, however, is that we have no guarantee about the preservation of the behavior of the model. For example, a trace (a set of desirable states and transitions) created on the abstract model may not replay on the concrete model. Its manual recreation, usually via animation, is necessary to run the trace, as the model may have changed significantly during refinement. However, this is a labor-intensive and error-prone task. To this end, this article presents an automatic trace refining technique and tool called BERT (B and Event-B Trace Refinement Technique) that allows modelers to ensure the behavioral integrity of high-level traces at the concrete level. The cost- and time-effectiveness of BERT are shown in industrial-strength case studies from the automotive and aviation domains.

Software engineering organizations in safety-critical domains require rigorous processes that include explicit software quality assurance measures (QA) to achieve high-quality and safe engineering artifacts. One major challenge for engineers is adhering to the correct process that is applicable in their specific working context, to understand which steps are ready to start, what actions are missing to complete their step, and when rework has happened. In this paper, we propose and evaluate ProGuide, a framework that provides actionable, light-weight process guidance by continuously assessing pre-conditions, post-conditions, and QA constraints. In case of a violation, it provides concrete repair actions. Evaluation on a safety-critical open source system and engineers from our industry partner Bosch showed that repairs are complete and small in number, and resulted in less frustration and fewer mistakes compared to being provided with no process guidance. Editor’s note: Open Science material was validated by the Journal of Systems and Software Open Science Board.

Summary In software development, developer turnover is among the primary reasons for project failures, leading to a great void of knowledge and strain for newcomers. Unfortunately, no established methods exist to measure how the problem domain knowledge is distributed among developers. Awareness of how this knowledge evolves and is owned by key developers in a project helps stakeholders reduce risks caused by turnover. To this end, this paper introduces a novel, realistic representation of problem domain knowledge distribution: the ConceptRealm. To construct the ConceptRealm, we employ a latent Dirichlet allocation model to represent textual features obtained from 300 K issues and 1.3 M comments from 518 open‐source projects. We analyze whether the newly emerged issues and developers share similar concepts or how aligned the individual developers' concepts are with the team over time. We also investigate the impact of leaving developers on the frequency of concepts. Finally, we also evaluate the soundness of our approach on a closed‐source software project, thus allowing the validation of the results from a practical standpoint. We find out that the ConceptRealm can represent the problem domain knowledge within a project and can be utilized to predict the alignment of developers with issues. We also observe that projects exhibit many keepers independent of project maturity and that abruptly leaving keepers correlates with a decline of their core concepts as the remaining developers cannot quickly familiarize themselves with those concepts.

Abstract The quality of a pull request is the primary factor integrators consider for its acceptance or rejection. Code smells indicate sub‐optimal design or implementation choices in the source code that often lead to a fault‐prone outcome, threatening the quality of pull requests. This study explores code smells in 21k pull requests from 25 popular Java projects. We find that both accepted (37%) and rejected (44%) pull requests have code smells, affected mainly by god classes and long methods. Besides, we observe that smelly pull requests are more complex and challenging to understand as they have significantly large sizes, long latency times, more discussion and review comments, and are submitted by contributors with less experience. Our results show that features used in previous studies for pull request acceptance prediction could be potentially employed to predict smell in incoming pull requests. We propose a dynamic approach to predict the presence of such code smells in the newly added pull requests. We evaluate our approach on a dataset of 25 Java projects extracted from GitHub. We further conduct a benchmark study to compare the performance of eight machine learning classifiers. Results of the benchmark study show that XGBoost is the best‐performing classifier for smell prediction.

Repairing design models is a laborious task that requires a considerable amount of time and effort from developers. Repair recommendation (RR) approaches focus on reducing the effort and improving the quality of the repairs performed. Such approaches have been evaluated in terms of scalability, correctness, and minimalism. These evaluations, however, have not investigated how developers can benefit from using RRs and how they perceive the difficulty of applying RRs. Investigating and discussing the use of RRs from the developers’ perspective is important to demonstrate the benefits of applying such approaches in practice. We explore this opportunity by conducting a controlled experiment carried out with 24 developers where they repaired UML design models in eight different tasks, with and without RRs. The findings indicate that developers can benefit from RRs in complex tasks by improving their effectiveness and efficiency. The results also evidence that the use of RRs does not impact the developers’ perceived difficulty and confidence when repairing models. Furthermore, our findings show that not all developers choose the same RR, but rather, have varied preferences. Thus, the provision of RRs leads to developers considering additional alternatives to repair an inconsistency.

A large number of bug reports are created during the evolution of a software system. Locating the source code files that need to be changed in order to fix these bugs is a challenging task. Information retrieval-based bug localization techniques do so by correlating bug reports with historical information about the source code (e.g., previously resolved bug reports, commit logs). These techniques have shown to be efficient and easy to use. However, one flaw that is nearly omnipresent in all these techniques is that they ignore code refactorings. Code refactorings are common during software system evolution, but from the perspective of typical version control systems, they break the code history. For example, a class when renamed then appears as two separate classes with separate histories. Obviously, this is a problem that affects any technique that leverages code history. This paper proposes a refactoring-aware traceability model to keep track of the code evolution history. With this model, we reconstruct the code history by analyzing the impact of code refactorings to correctly stitch together what would otherwise be a fragmented history. To demonstrate that a refactoring aware history is indeed beneficial, we investigated three widely adopted bug localization techniques that make use of code history, which are important components in existing approaches. Our evaluation on 11 open source projects shows that taking code refactorings into account significantly improves the results of these bug localization techniques without significant changes to the techniques themselves. The more refactorings are used in a project, the stronger the benefit we observed. Based on our findings, we believe that much of the state of the art leveraging code history should benefit from our work.

Bug localization is the task of recommending source code locations (typically files) that probably contain the cause of a bug and hence need to be changed to fix the bug. Along these lines, information retrieval-based bug localization (IRBL) approaches have been adopted, which identify the most bug-prone files from the source code space. In current practice, a series of state-of-the-art IRBL techniques leverage the combination of different components, e.g., similar reports, version history, code structure, to achieve better performance. ABLoTS is a recently proposed approach with the core component, TraceScore, that utilizes requirements and traceability information between different issue reports, i.e., feature requests and bug reports, to identify buggy source code snippets with promising results. To evaluate the accuracy of these results and obtain additional insights into the practical applicability of ABLoTS, supporting of future more efficient and rapid replication and comparison, we conducted a replication study of this approach with the original data set and also on an extended data set. The extended data set includes 16 more projects comprising 25,893 bug reports and corresponding source code commits. While we find that the TraceScore component as the core of ABLoTS produces comparable results with the extended data set, we also find that the ABLoTS approach no longer achieves promising results, due to an overlooked side effect of incorrectly choosing a cut-off date that led to training data leaking into test data with significant effects on performance.

Along the process of engineering a safety-critical system, software engineers produce various artifacts, ranging from requirements and change requests to source code and test cases. In order to aid the development of the system and to adhere to the complex safety regulations and standards in place, engineers are often required to maintain bidirectional and consistent traceability between the produced artifacts. However, such artifacts are rarely maintained in one single tool. Because of that, the cross-tool bidirectional traces have to frequently be manually maintained, which can easily become a very time-consuming or infeasible task. Through interviews and observations at our industry partners in regulated domains, we observed that a number of different strategies are used to deal with this challenge. The use of naming conventions, querying, or URL links is observed in the industry. However, they have their shortcomings and hinder engineers from realizing the full potential that traceability can offer. Knowing the challenges in the industry, we explored existing literature. A range of approaches in the literature aims at dealing with traceability, but often they are context-specific and not easily transferable into practice. Given this gap between the state-of-the-art and industry needs, we performed interviews with our industry partners and analyzed tertiary studies from the literature to obtain a better understanding of what traceability properties are needed to unleash the potential of traces. We identified properties that represent the shared challenges between the related work and the industry requirements: discoverability, type checks, flexibility, navigability, and extensibility. While each property is addressed by a subset of the available solutions, we propose a novel traceability approach to support all of them in a single tool.

Preprocessor-based software product lines (SPLs) are used to deal with evolution in space, in which features (so-called configuration options)—annotated in source code with #ifdefs—are included, removed, and systematically reused. Inevitably, feature implementations also evolve over time, i.e., when existing features are revised. Nowadays, Version control systems (VCSs) are well-integrated into SPL development processes for versioning support of releases. Changes to existing features in one version, a.k.a. release of an SPL, usually developed in a branch, frequently need to be propagated to other active releases. However, there is no automated support for analyzing and propagating features in SPL releases. For instance, VCSs can only propagate changes at the commit level, but miss support at the feature level, i.e., the building blocks of SPLs. Manually analyzing and propagating a version of a feature, i.e., a feature revision, through #ifdefs is risky, time-consuming, and error-prone because a feature can be interacting with multiple features and it can be spread in multiple blocks of code across different files. We thus present a novel and tool-supported approach for the analysis and propagation of feature revisions. We evaluated our approach quantitatively by computing its correct behavior and runtime. Our approach analyzes and propagates a feature implementation in ≈63 seconds, with, on average, precision and recall of 99%. In total, we propagated 3,134 features in space and time between 200 pairs of releases on four real-world preprocessor-based SPLs. In addition, we qualitatively evaluated the usefulness of our tool support by conducting interviews with five experienced core developers of three popular preprocessor-based SPLs. The qualitative results confirm that our tool support is useful to speed up the analysis and propagation of feature revisions.

When dealing with safety–critical systems, various regulations, standards, and guidelines stipulate stringent requirements for certification and traceability of artifacts, but typically lack details with regards to the corresponding software engineering process. Given the industrial practice of only using semi-formal notations for describing engineering processes – with the lack of proper tool mapping – engineers and developers need to invest a significant amount of time and effort to ensure that all steps mandated by quality assurance are followed. The sheer size and complexity of systems and regulations make manual, timely feedback from Quality Assurance (QA) engineers infeasible. In order to address these issues, in this paper, we propose a novel framework for tracking, and “passively” executing processes in the background, automatically checking QA constraints depending on process progress, and informing the developer of unfulfilled QA constraints. We evaluate our approach by applying it to three case studies: a safety–critical open-source community system, a safety–critical system in the air-traffic control domain, and a non-safety–critical, web-based system. Results from our analysis confirm that trace links are often corrected or completed after the work step has been considered finished, and the engineer has already moved on to another step. Thus, support for timely and automated constraint checking has significant potential to reduce rework as the engineer receives continuous feedback already during their work step.

In large code bases, locating the elements that implement concrete features of a system is challenging. This information is paramount for maintenance and evolution tasks, although not always explicitly available. In this work, motivated by the needs of locating features as a first step for feature-based Software Product Line adoption, we propose a solution for improving the performance of existing approaches. For this, relying on an automatic feature localization approach to locate features in single-systems, we propose approaches to deal with feature localization in the context of families of systems, e.g., variants created through opportunistic reuse such as clone-and-own. Our feature localization approaches are built on top of Spectrum-based feature localization (SBFL) techniques, supporting both dynamic feature localization (i.e., using execution traces as input) and static feature localization (i.e., relying on the structural decomposition of the variants’ implementation). Concretely, we provide (i) a characterization of different settings for dynamic SBFL in single systems, (ii) an approach to improve accuracy of dynamic SBFL for families of systems, and (iii) an approach to use SBFL as a static feature localization technique for families of systems. The proposed approaches are evaluated using the consolidated ArgoUML SPL feature localization benchmark. The results suggest that some settings of SBFL favor precision such as using the ranking metrics Wong2, Ochiai2, or Tarantula with high threshold values, while most of the ranking metrics with low thresholds favor recall. The approach to use information from variants increase the precision of dynamic SBFL while maintaining recall even with few number of variants, namely two or three. Finally, the static SBFL approach performs equally in terms of accuracy to other state-of-the-art approaches, such as Formal Concept Analysis and Interdependent Elements.

This article presents a systematic mapping study on the model-driven engineering of safety and security concerns in software systems. Combined modeling and development of both safety and security concerns is an emerging field of research as both concerns affect one another in unique ways. Our mapping study provides an overview of the current state of the art in this field. This study carefully selected 143 publications out of 27,259 relevant papers through a rigorous and systematic process. This study then proposes and answers questions such as frequently used methods and tools and development stages where these concerns are typically investigated in application domains. Additionally, we identify the community's preference for publication venues and trends. The discussion on obtained results also features the gained insights and future research directions.

There are many repair alternatives for resolving model inconsistencies, each involving one or more model changes. Enumerating them all could overwhelm the developer because the number of possible repairs can grow exponentially. To address this problem, this paper focuses on the immediate cause of an inconsistency. By focusing on the cause, we can generate a repair tree with a subset of repair actions focusing on fixing this cause. This strategy identifies model elements that must be repaired, as opposed to additional model elements that may or may not have to be repaired later. Furthermore, our approach can provide an ownership-based filter for filtering repairs that modify model elements not owned by a developer. This filtering can further reduce the repair possibilities, aiding the developer when choosing repairs to be performed. We evaluated our approach on 24 UML models and four Java systems, using 17 UML consistency rules and 14 Java consistency rules. The evaluation data contained 39,683 inconsistencies, showing our approach's usability as the repair trees sizes ranged from five to nine on average per model. Also, these repair trees were generated in 0.3 seconds on average, showing our approach's scalability. Based on the results, we discuss the correctness and minimalism with regard to the cause of the inconsistency. Lastly, we evaluated the filtering mechanism, showing that it is possible to further reduce the number of repairs generated by focusing on ownership.

Abstract Semantic clone detection is the process of finding program elements with similar or equal runtime behavior. For example, detecting the semantic equality between the recursive and iterative implementation of the factorial computation. Semantic clone detection is the de facto technical boundary of clone detectors. In recent years, this boundary has been tested using interesting new approaches. This article contributes a semantic clone detection approach that detects clones which have 0 % syntactic similarity. We present Semantic Clone Detection via Probabilistic Software Modeling (SCD-PSM) as a stable and precise solution to semantic clone detection. PSM builds a probabilistic model of a program that is capable of evaluating and generating runtime data. SCD-PSM leverages this model and its model elements for finding behaviorally equal model elements. This behavioral equality is then generalized to semantic equality of the original program elements. It uses the likelihood between model elements as a distance metric. Then, it employs the likelihood ratio significance test to decide whether this distance is significant, given a pre-specified and controllable false-positive rate. The output of SCD-PSM are pairs of program elements (i.e., methods), their distance, and a decision on whether they are clones or not. SCD-PSM yields excellent results with a Matthews Correlation Coefficient greater than 0.9. These results are obtained on classical semantic clone detection problems such as detecting recursive and iterative versions of an algorithm, but also on complex problems used in coding competitions.

Software systems are becoming increasingly configurable. A paradigmatic example is the Linux kernel, which can be adjusted for a tremendous variety of hardware devices, from mobile phones to supercomputers, thanks to the thousands of configurable features it supports. In principle, many relevant problems on configurable systems, such as completing a partial configuration to get the system instance that consumes the least energy or optimizes any other quality attribute, could be solved through exhaustive analysis of all configurations. However, configuration spaces are typically colossal and cannot be entirely computed in practice. Alternatively, configuration samples can be analyzed to approximate the answers. Generating those samples is not trivial since features usually have inter-dependencies that constrain the configuration space. Therefore, getting a single valid configuration by chance is extremely unlikely. As a result, advanced samplers are being proposed to generate random samples at a reasonable computational cost. However, to date, no sampler can deal with highly configurable complex systems, such as the Linux kernel. This paper proposes a new sampler that does scale for those systems, based on an original theoretical approach called extensible logic groups. The sampler is compared against five other approaches. Results show our tool to be the fastest and most scalable one.

Traceability approves trace links among software artifacts based on whether two artifacts are related by system functionalities. The traces are valuable for software development, but are difficult to obtain manually. To cope with the costly and fallible manual recovery, automated approaches are proposed to recover traces through textual similarities among software artifacts, such as those based on Information Retrieval (IR). However, the low quality & quantity of artifact texts negatively impact the calculated IR values, thus greatly hindering the performance of IR-based approaches. In this study, we propose to extract co-occurred word pairs from the text structures of both requirements and code (i.e., consensual biterms) to improve IR-based traceability recovery. We first collect a set of biterms based on the part-of-speech of requirement texts, and then filter them through the code texts. We then use these consensual biterms to both enrich the input corpus for IR techniques and enhance the calculations of IR values. A nine-system-based evaluation shows that in general, when solely used to enhance IR techniques, our approach can outperform pure IR-based approaches and another baseline by 21.9% & 21.8% in AP, and 9.3% & 7.2% in MAP, respectively. Moreover, when used to collaborate with another enhancing strategy from different perspectives, it can outperform this baseline by 5.9% in AP and 4.8% in MAP.

As the engineering world moves towards collaborative model-driven development, it is becoming increasingly difficult to keep all model artifacts synchronized and consistent across a myriad of tools and domains. The existing literature proposes a variety of solutions, from passive trace links to computing change propagation paths. However, these solutions require manual propagation and the use of a limited set of tools, while also lacking the efficiency and granularity required during the development of complex systems. To overcome these limitations, this paper proposes a solution based on reactive propagation links between property values across multi-domain models managed in different tools. As opposed to the traditional passive links, the propagation links automatically react to changes during engineering to assure the synchronization and consistency of the models. The feasibility and performance of our solution were evaluated in two practical scenarios. We identified a set of change propagation cases, all of which could be resolved using our solution, while also rendering a great improvement in terms of efficiency as compared to manual propagation. The contribution of our solution to the state of the practice is to enhance the engineering process by reducing the burden of manually keeping models synchronized, eliminating inconsistencies that can be originated in artifacts managed in a variety of tool from different domains.

Abstract Software companies commonly develop and maintain variants of systems, with different feature combinations for different customers. Thus, they must cope with variability in space. Software companies further must cope with variability in time, when updating system variants by revising existing software features. Inevitably, variants evolve orthogonally along these two dimensions, resulting in challenges for software maintenance. Our work addresses this challenge with ECSEST (Extraction and Composition for Systems Evolving in Space and Time), an approach for locating feature revisions and composing variants with different feature revisions. We evaluated ECSEST using feature revisions and variants from six highly configurable open source systems. To assess the correctness of our approach, we compared the artifacts of input variants with the artifacts from the corresponding composed variants based on the implementation of the extracted features. The extracted traces allowed composing variants with 99-100% precision, as well as with 97-99% average recall. Regarding the composition of variants with new configurations, our approach can combine different feature revisions with 99% precision and recall on average. Additionally, our approach retrieves hints when composing new configurations, which are useful to find artifacts that may have to be added or removed for completing a product. The hints help to understand possible feature interactions or dependencies. The average time to locate feature revisions ranged from 25 to 250 seconds, whereas the average time for composing a variant was 18 seconds. Therefore, our experiments demonstrate that ECSEST is feasible and effective.

Abstract Engineering projects involve a variety of artifacts such as requirements, design, or source code. These artifacts, many of which tend to be interdependent, are often manipulated concurrently. To keep artifacts consistent, engineers must continuously consider their work in relation to the work of multiple other engineers. Traditional consistency checking approaches reason efficiently over artifact changes and their consistency implications. However, they do so solely within the boundaries of specific tools and their specific artifacts (e.g., consistency checking between different UML models). This makes it difficult to examine the consistency between different types of artifacts (e.g., consistency checking between UML models and the source code). Global consistency checking can help addressing this problem. However, it usually requires a disruptive and time-consuming merging process for artifacts. This article presents a novel, cloud-based approach to global consistency checking in a multi-developer/-tool engineering environment. It allows for global consistency checking across all artifacts that engineers work on concurrently. Moreover, it reasons over artifact changes immediately after the change happened, while keeping the (memory/CPU) cost of consistency checking minimal. The feasibility and scalability of our approach were demonstrated by a prototype implementation and through an empirical validation.

Requirement-to-code traces reveal the code location(s) where a requirement is implemented. Traceability is essential for code evolution and understanding. However, creating and maintaining requirement-to-code traces is a tedious and costly process. In this paper, we introduce TraceRefiner, a novel technique for automatically refining coarse-grained requirement-to-class traces to fine-grained requirement-to-method traces. The inputs of TraceRefiner are (1) the set of requirement-to-class traces, which are easier to create as there are far fewer traces to capture, and (2) information about the code structure (i.e., method calls). The output of TraceRefiner is the set of requirement-to-method traces (providing additional, fine-grained information to the developer). We demonstrate the quality of TraceRefiner on four case study systems (7-72KLOC) and evaluated it on over 230,000 requirement-to-method predictions. The evaluation demonstrates TraceRefiner's ability to refine traces even if many requirement-to-class traces are undefined (incomplete input). The obtained results show that the proposed technique is fully automated, tool-supported, and scalable.

The Assembly Line Balancing Problem (ALBP) is of great relevance for manufacturing companies improving the line efficiency and productivity and thus maximizing production profits. Multiple exact, heuristic and meta-heuristic methods have been applied to solve the ALBP. These optimization methods consist in producing a feasible line balance, i.e. the partitioning of assembly tasks among available work stations based on, among others, the precedence graph. Such a graph describes the technological and organizational precedence constraints between tasks. Unfortunately, the assembly precedence relations, in the automotive and related industries for example, are often outdated, incomplete or altogether unavailable. This limits the applicability of the available approaches to real-world assembly systems. Grounded in an industry use-case, we propose a novel approach for the assistance in the upfront assignment of assembly tasks to stations. We recommend station assignments relying on historical data of prior feasible assembly balances of different products. We evaluate our approach against real industry data. On average, our approach is able to provide station assignment recommendations for 91% of the tasks at 82% precision.

Cyber-physical production systems are composed of a multitude of subsystems from diverse vendors and integrators, connected in a distributed fashion. An undesirable phenomenon in one system might cause a misbehavior in another connected system. Searching for the root cause of this misbehavior quickly becomes very tedious as many possible search directions exist. This paper proposes an approach and algorithm to tie together information available in design-time and runtime models. This then allows, in conjunction with observed and desired status of a system, to recommend search options and concrete solution steps to guide workers along the fixing process without being overwhelmed by the complexity of the overall system of systems. We demonstrate the feasibility of our approach using a lab-scal production cell model.

This paper proposes a recommendation approach for issues (e.g., a story, a bug, or a task) prioritization based on natural language processing, called NLP4IP. The proposed semi-automatic approach takes into account the priority and story points attributes of existing issues defined by the project stakeholders and devises a recommendation model capable of dynamically predicting the rank of newly added or modified issues. NLP4IP was evaluated on 19 projects from 6 repositories employing the JIRA issue tracking software with a total of 29,698 issues. A comprehensive benchmark study was also conducted to compare the performance of various machine learning models. The results of the study showed an average top@3 accuracy of 81% and a mean squared error of 2.2 when evaluated on the validation set. The applicability of the proposed approach is demonstrated in the form of a JIRA plug-in illustrating predictions made by the newly developed machine learning model. The dataset has also been made publicly available in order to support other researchers working in this domain.

Feature annotation based on preprocessor directives is the most common mechanism in Highly-Configurable Software Systems (HCSSs) to manage variability. However, it is challenging to understand, maintain, and evolve feature fragments guarded by #ifdef directives. Yet, despite HCSSs being implemented in Version Control Systems, the support for evolving features in space and time is still limited. To extend the knowledge on this topic, we analyze the feature life cycle in space and time. Specifically, we introduce an automated mining approach and apply it to four HCSSs, analyzing commits of their entire development life cycle (13 to 20 years and 37,500 commits). This goes beyond existing studies, which investigated only differences between specific releases or entire systems. Our results show that features undergo frequent changes, often with substantial modifications of their code. The findings of our empirical analyses stress the need for better support of system evolution in space and time at the level of features. In addition to these analyses, we contribute an automated mining approach for the analysis of system evolution at the level of features. Furthermore, we also make available our dataset to foster new studies on feature evolution in HCSSs.

Regulations, standards, and guidelines for safety-critical systems stipulate stringent traceability but do not prescribe the corresponding, detailed software engineering process. Given the industrial practice of using only semi-formal notations to describe engineering processes, processes are rarely "executable" and developers have to spend significant manual effort in ensuring that they follow the steps mandated by quality assurance. The size and complexity of systems and regulations makes manual, timely feedback from Quality Assurance (QA) engineers infeasible. In this paper we propose a novel framework for tracking processes in the background, automatically checking QA constraints depending on process progress, and informing the developer of unfulfilled QA constraints. We evaluate our approach by applying it to two different case studies; one open source community system and a safety-critical system in the air-traffic control domain. Results from the analysis show that trace links are often corrected or completed after the fact and thus timely and automated constraint checking support has significant potential on reducing rework.

Unforeseen situations on the shopfloor cause the assembly process to divert from its expected progress. To be able to overcome these deviations in a timely manner, assembly process monitoring and early deviation detection are necessary. However, legal regulations and union policies often limit the direct monitoring of human-intensive assembly processes. Grounded in an industry use case, this paper outlines a novel approach that, based on indirect privacy-respecting monitored data from the shopfloor, enables the near real-time detection of multiple types of process deviations. In doing so, this paper specifically addresses uncertainties stemming from indirect shopfloor observations and how to reason in their presence.

As manufacturing companies move towards producing highly customizable products in small lot sizes, assembly workers remain an integral part of production systems. However, with workers in the loop, it is necessary to monitor the production process for timely detection of deviations and timely provisioning of worker assistance. Grounded in an industrial case study describing the assembly of construction vehicles, we outline a generic heuristic-based approach for monitoring progress in human-intensive assembly systems. Specifically, we highlight the challenges in dealing with uncertainty stemming from the limitations in accurately, timely, and completely observing human physical assembly steps. We discuss a motivating example to showcase these challenges and present a set of heuristics that manages to accurately infer assembly progress from indirect and incomplete observations of deviating worker behavior. Validated against ground truth obtained from a real industrial assembly line, on average our approach correctly estimates completion times for steps that are associated with shopfloor observations within 14 seconds or less of their true value.

Software engineers use requirement-to-method trace matrices to indicate the methods implementing different system requirements. Requirement-to-method trace matrices pinpoint the exact method implementing each requirement, which facilitates software maintenance and bug fixing. The code structure of a system can be used to make predictions about requirement-to-method traces. In this paper, we present a data set documenting the requirement-to-method traces as well as the code structure (methods, variables, etc.) for four open source systems. The code structure was obtained by parsing the systems under consideration and extracting the methods, variables, etc. The requirement-to-method trace matrices were obtained by resorting to students as well as to the original developers of the systems who provided us with the list of requirement-to-method traces.

Abstract Software Product Lines (SPLs) make it possible to configure a single system based on features in order to create many different variants and cater to a wide range of customers with varying requirements. This configuration space is often modeled using Feature Models (FMs). However, in practice, the SPL (and consequently the FM) is often created after a set of variants has already been created manually. Automating the task of reverse engineering a feature model that describes a set of variants makes the process of adopting an SPL easier. The genetic programming pipeline is a good fit for feature models and has been shown to produce good reverse engineering results. In this paper, we replicate the results of such an existing approach with a larger set of feature models and investigate the effects of various genetic programming parameters and operators on the results. The design of our replication experiments employs three perspectives: duplicate the exact conditions using various features models, study the interaction of two parameters of the genetic programming approach, and optimize the values for the population and generation parameters and for the mutation and crossover operators. Results reinforce the previously obtained outcome, the original study being confirmed. The relations between the number of features and number of generations, respectively number of features and size of populations were also investigated and best values based on obtained results are provided. The current study also aimed to optimize various parameters of the genetic programming approach, the interpretation of those experiments discovering concrete values.

Abstract In today's engineering projects, companies continuously have to adapt their systems to changing customers or dynamic market requirements. This requires a flexible, iterative development process in which different parts of the system under construction are built and updated concurrently. However, concurrent engineering becomes quite challenging in domains where different engineering artifacts from different disciplines come into play, such as safety‐critical cyber‐physical systems, where the involved engineering artifacts are quite heterogeneous in nature. In such systems, it is of utmost importance that different artifacts remain consistent in order to guarantee a correctly functioning end product. In this article, we discuss our experiences (with a leading company working in the areas of production automation and product processing) in maintaining the consistency between electrical models and the corresponding software controller, when both are subject to continuous changes. The article discusses how we let engineers describe the relationships between electrical models and the corresponding software controller code in the form of links and consistency rules. Additionally, we demonstrate that how our approach, through a process of continuous consistency checking, notifies engineers about the erroneous impact of their changes in various engineering artifacts.

Developers change models with clear intentions-e.g., for refactoring, defects removal, or evolution. However, in doing so, developers are often unaware of the consequences of their changes. Changes to one part of a model may affect other parts of the same model and/or even other models, possibly created and maintained by other developers. The consequences are incomplete changes and with it inconsistencies within or across models. Extensive works exist on detecting and repairing inconsistencies. However, the literature tends to focus on inconsistencies as errors in need of repairs rather than on incomplete changes in need of further propagation. Many changes are non-trivial and require a series of coordinated model changes. As developers start changing the model, intermittent inconsistencies arise with other parts of the model that developers have not yet changed. These inconsistencies are cues for incomplete change propagation. Resolving these inconsistencies should be done in a manner that is consistent with the original changes. We speak of consistent change propagation. This paper leverages classical inconsistency repair mechanisms to explore the vast search space of change propagation. Our approach not only suggests changes to repair a given inconsistency but also changes to repair inconsistencies caused by the aforementioned repair. In doing so, our approach follows the developer's intent where subsequent changes may not contradict or backtrack earlier changes. We argue that consistent change propagation is essential for effective model-driven engineering. Our approach and its tool implementation were empirically assessed on 18 case studies from industry, academia, and GitHub to demonstrate its feasibility and scalability. A comparison with two versioned models shows that our approach identifies actual repair sequences that developers had chosen. Furthermore, an experiment involving 22 participants shows that our change propagation approach meets the workflow of how developers handle changes by always computing the sequence of repairs resulting from the change propagation.

Cyber physical production systems (CPPS) focus on increasing the flexibility and adaptability of industrial production systems, systems that comprise hardware such as sensors and actuators in machines as well as software controlling and integrating these machines. The requirements of customised mass production imply that control and integration software needs to be adaptable after deployment in a shop floor (factory), possibly even without interrupting production. Today, software frameworks provide support to model and execute manufacturing processes. They, however, provide little support for reuse. In this paper, we present a framework based on capabilities, which supports manufacturing process templates. These templates are bound/allocated to a specific shopfloor setup, a specific set of machines, and executed using a distributed set of process engines. This enables the reuse of manufacturing processes, as well as transmitting and executing changed processes. The framework is implemented using the Eclipse Milo implementation of OPC UA in Java. It is used to control a lab-scale modular shopfloor programmed in IEC61499 and Java.

The new era of Industry 4.0 is leading towards self-learning and adaptable production systems requiring efficient and intelligent decision making. Achieving high production rate in a short span of time, continuous improvement, and better utilization of resources is crucial for such systems. This paper discusses an approach to achieve production optimization by finding optimal sequences of orders, which yield high throughput using reinforcement learning. The feasibility of our approach is evaluated by simulating a plant modelled on a higher level of abstraction taken from a real assembly line. The applicability of the proposed approach is demonstrated in the form of code utilizing the simulation model. The obtained results show promising accuracy of sequences against corresponding throughput during the simulation process.

Organizational factors such as team structure, coordination among engineers, or processes have a significant impact on software quality and development progress. Projects often take much longer to complete than planned and miscommunications among engineers are common. Yet, the process for exploring the project-specific or organization-specific root causes why this happens is still poorly supported. Investigations are cumbersome and require significant effort. In the context of this industrial case study, our industry partner was interested in measuring and assessing how the organization structure and issue handling processes ultimately affected software quality and time. Reducing the effort of such investigations/retrospectives and speeding up fact finding is important as it allows for more frequent, informed engineering process improvements and feedback to managers, team leads, and engineers. This paper describes our approach of pairing process metrics with visual historical inspection of issues. Stakeholders such as managers, team leads, or quality assurance engineers inspect metrics (and deviations from expected values) for individual issues and utilize a historical visualization of the affected (and related) issues to obtain insights into the reason for the metric (deviation) and its root cause. We demonstrate the usefulness of our approach based on our ProcessInspector prototype providing access to data on four real industry projects and a qualitative evaluation with team leads and group leads from our industry partner.

Several researchers have studied that developers contributing to open source systems tend to self-organize in "emerging" teams. The structure of these latent teams has a significant impact on software quality, with development teams structure somewhat reflected in the way developers communicate and contribute in the subsystems of a system. Therefore, in order to study socio-technical interactions as well as the software evolution dynamics of open source systems, in this paper, we present a novel dataset, gathered from 20 open source projects, which report the developers' activities in the scope of commits and issues at the level of subsystems. Thus, the new, generated dataset comprises of emerging and explicit links among developers, commits, issues, and source code artifacts, with data grouped around the subsystems point of view, which can be used to better study the system dynamics behind the extracted sociotechnical interactions.

Security-and safety-critical cyber-physical systemsCyber-physical systems (CPSs) are physical embedded systems with enhanced operations for monitoring, coordination, control, and integration by a computing and communication core. 1 Examples of CPSs include transportations systems, 2 medical systems, 3 and manufacturing systems.4 A CPS can be security-critical, safety-critical, or both.A CPS communicating with the outside world and thus opening an attack vector through the communication channel is considered to be a security-critical CPS.On the other hand, a CPS is considered to be safety-critical if it can harm its environment, eg, a malfunctioning autonomous vehicle might harm its passengers.5 A CPS dealing with both security and safety concerns is considered to be a security-and safety-critical CPS.Contemporary systems and software engineering methods often prove inadequate for the trustworthy and reliable design and engineering of CPSs.Traditional engineering deals with security and safety issues as separate problems.However, given the coordination and communication features of CPSs, such a ''separation-of-concerns'' approach is no longer adequate.We need integrated methods to deal with security and safety concerns within CPSs.

Most engineering tools do not provide much support for collaborating teams and today's engineering knowledge repositories lack flexibility and are limited. Engineering teams have different needs and their team members have different preferences on how and when to collaborate. These needs may depend on the individual work style, the role an engineer has, and the tasks they have to perform within the collaborating group. However, individual collaboration is insufficient and engineers need to collaborate in groups. This work presents a collaboration framework for collaborating groups capable of providing synchronous and asynchronous mode of collaboration. Additionally, our approach enables engineers to mix these collaboration modes to meet the preferences of individual group members. We evaluate the scalability of this framework using four real life large collaboration projects. These projects were found from GitHub and they were under active development by the time of evaluation. We have tested our approach creating groups of different sizes for each project. The results showed that our approach scales to support every case for the groups created. Additionally, we scouted the literature and discovered studies that support the usefulness of different groups with collaboration styles.

Variability models are broadly used to specify the configurable features of highly customizable software. In practice, they can be large, defining thousands of features with their dependencies and conflicts. In such cases, visualization techniques and automated analysis support are crucial for understanding the models. This paper contributes to this line of research by presenting a novel, probabilistic foundation for statistical reasoning about variability models. Our approach not only provides a new way to visualize, describe and interpret variability models, but it also supports the improvement of additional state-of-the-art methods for software product lines; for instance, providing exact computations where only approximations were available before, and increasing the sensitivity of existing analysis operations for variability models. We demonstrate the benefits of our approach using real case studies with up to 17,365 features, and written in two different languages (KConfig and feature models).

Traceability recovery allows developers to extract and comprehend the trace links among software artifacts (e.g., requirements and code). These trace links can provide important support to software maintenance and evolution tasks. Information Retrieval (IR) is now widely accepted as the key technique of semi-automatic tools to recover candidate trace links based on textual similarities among artifacts. However, the vocabulary mismatch problem between different artifacts hinders the performance of these IR-based approaches. Thus, a growing body of enhancing strategies were proposed based on user feedback. They allow to adjust the textual similarities of candidate links after users accept or reject part of these links. Recently, several approaches successfully used this strategy to improve the performance of IR-based traceability recovery. However, these approaches require a large amount of user feedback, which is infeasible in practice. In this paper, we propose to improve IR-based traceability recovery by introducing only a small amount of user feedback into the closeness analysis on call and data dependencies in code. Specifically, our approach iteratively asks users to verify a chosen candidate link based on the quantified functional similarity for each code dependency (called closeness) and the generated IR values. The verified link is then used as the input to re-rank the unverified candidate links. An empirical evaluation based on five real-world systems shows that our approach can outperform four baseline approaches by using only a small amount of user feedback.

When software models change, developers often fail in keeping them consistent. Automated support in repairing inconsistencies is widely addressed. Yet, merely enumerating repairs for developers is not enough. A repair can as a side effect cause new unexpected inconsistencies (negative) or even fix other inconsistencies as well (positive). To make matters worse, repairing negative side effects can in turn cause further side effects. Current approaches do not detect and track such side effects in depth, which can increase developers' effort and time spent in repairing inconsistencies. This paper presents an automated approach for detecting and tracking the consequences of repairs, i.e. side effects. It recursively explores in depth positive and negative side effects and identifies paths and cycles of repairs. This paper further ranks repairs based on side effect knowledge so that developers may quickly find the relevant ones. Our approach and its tool implementation have been empirically assessed on 14 case studies from industry, academia, and GitHub. Results show that both positive and negative side effects occur frequently. A comparison with three versioned models showed the usefulness of our ranking strategy based on side effects. It showed that our approach's top prioritized repairs are those that developers would indeed choose. A controlled experiment with 24 participants further highlights the significant influence of side effects and of our ranking of repairs on developers. Developers who received side effect knowledge chose far more repairs with positive side effects and far less with negative side effects, while being 12.3% faster, in contrast to developers who did not receive side effect knowledge.

Implementing a change is a challenging task in complex, safety-critical, or long-living software systems. Developers need to identify which artifacts are affected to correctly and completely implement a change. Changes often require editing artifacts across the software system to the extent that several developers need to be involved. Crucially, a developer needs to know which artifacts under someone else's control have impact on her work task and, in turn, how her changes cascade to other artifacts, again, under someone else's control. These cross-task dependencies are especially important as they are a common cause of incomplete and incorrect change propagation and require explicit coordination. Along these lines the core research question in this paper is: how can we automatically detect cross-task dependencies and use them to assist the developer? We introduce an approach for mining such dependencies from past developer interactions with engineering artifacts as the basis for live recommending artifacts during change implementation. We show that our approach lists 67% of the correctly recommended artifacts within the top-10 results with real interaction data and tasks from the Mylyn project. The results demonstrate we are able to successfully find not only cross-task dependencies but also provide them to developers in a useful manner.

Design patterns are elegant and well-tested solutions to recurrent software development problems. They are the result of software developers dealing with problems that frequently occur, solving them in the same or a slightly adapted way. A pattern's semantics provide the intent, motivation, and applicability, describing what it does, why it is needed, and where it is useful. Consequently, design patterns encode a well of information. Developers weave this information into their systems whenever they use design patterns to solve problems. This work presents Feature Maps, a flexible human-and machine-comprehensible software representation based on micro-structures. Our algorithm, the Feature-Role Normalization, presses the high-dimensional, in homogeneous vector space of micro-structures into a feature map. We apply these concepts to the problem of detecting instances of design patterns in source code. We evaluate our methodology on four design patterns, a wide range of balanced and imbalanced labeled training data, and compare classical machine learning (Random Forests) with modern deep learning approaches (Convolutional Neural Networks). Feature maps yield robust classifiers even under challenging settings of strongly imbalanced data distributions without sacrificing human comprehensibility. Results suggest that feature maps are an excellent addition in the software analysis toolbox that can reveal useful information hidden in the source code.

In the domain of industrial automation many companies nowadays need to serve a mass market while at the same time customers demand individual customer-specific solutions. Such customizations often apply to individual products only but may also be needed at the level of product lines for whole market segments. To handle this problem, development is frequently organized in software ecosystems (SECOs), i.e., interrelated software product lines involving internal and external developers. This paper introduces an approach supporting feature-oriented, distributed development and evolution in industrial SECOs. It is common industrial practice to first derive initial products from a product line, then adding and adapting features to satisfy individual customer requirements, possibly followed by merging back these changes into the original product line. Our approach goes beyond this practice and also allows to share new or updated features by transferring them to other product lines in the ecosystem. This is for instance useful when a feature developed in an individual customer project becomes relevant for another market segment or when updates of features need to be transferred to related products in the ecosystem. We describe and motivate research challenges based on the industrial ecosystem of an industry partner. We outline the key elements and operations of our approach, including an implementation in our FORCE2development environment. We demonstrate application scenarios from the well-known Pick-and-Place Unit (PPU) system as a proof of concept.

Developers commonly define tasks to help coordinate software development efforts---whether they be feature implementation, refactoring, or bug fixes. Developers establish links between tasks to express implicit dependencies that needs explicit handling---dependencies that often require the developers responsible for a given task to assess how changes in a linked task affect their own work and vice versa (i.e., change propagation). While seemingly useful, it is unknown if change propagation indeed coincides with task links.

Robust and effective support for the detection and management of software features and their interactions is crucial for many development tasks but has proven to be an elusive goal despite extensive research on the subject. This is especially challenging for variable systems where multiple variants of a system and their features must be collectively considered. Here an important issue is the typically large number of feature interactions that can occur in variable systems. We propose a method that computes, from a set of known source code level interactions of n features, the relevant interactions involving n+1 features. Our method is based on the insight that, if a set of features interact, it is much more likely that these features also interact with additional features, as opposed to completely different features interacting. This key insight enables us to drastically prune the space of potential feature interactions to those that will have a true impact at source code level. This substantial space reduction can be leveraged by analysis techniques that are based on feature interactions (e.g Combinatorial Interaction Testing). Our observation is based on eight variable systems, implemented in Java and C, totaling over nine million LoC, with over seven thousand feature interactions.

Transformations constitute significant key components of an automated model-driven engineering solution. As metamodels evolve, model transformations may need to be co-evolved accordingly. A conducted experiment on transformations' co-evolution highlighted the existing gap in the literature where only limited few co-evolution scenarios are covered without supporting alternatives that occur in practice. To make matters worse, when a developer needs to drift apart from the proposed co-evolution, no automatic support is provided to the developer. This paper first proposes a change propagation-based co-evolution of transformations. The premise is that knowledge of the metamodel evolution can be propagated by means of resolutions to drive the transformation co-evolution. To deal with particular cases where developers must drift from the proposed resolutions, we introduce a composition-based mechanism that allows developers to compose resolutions meeting their needs. Our work is evaluated on 14 case studies consisting in original and evolved metamodels and ETL Epsilon transformations. A comparison of our co-evolved transformations with the 14 versioned ones showed the usefulness of our approach that reached an average 96% of correct co-evolution. On three other case studies, our composition-based co-evolution showed to be useful to eight developers in selecting resolutions that best meet their needs. Among the applied resolutions, four developers applied six resolutions that were the direct result of a composition.

The use of software has become ubiquitous and prevalent in modern medical devices such as hemodialysis machines. Consequently, the failure rate of medical devices due to software faults is also increasing. While next-generation software-intensive medical devices contribute to providing better health care and ease of use, their development is becoming unprecedentedly complex and challenging. The critical nature of this domain - particularly its direct implications on health and safety - requires extraordinary measures to ensure the correct and reliable function of such systems. Formal methods are proven to provide approaches, techniques, and tools for correct engineering of software and systems. However, their use in the contemporary medical software engineering is still marginal. In order to promote the use of (state-based) formal methods and showcase their effectiveness in design and development of critical medical devices, we present the hemodialysis case study challenge problem in this article. We also analyze the novelties and limitations of several solutions implementing the case study and explore research challenges that still need to be addressed in future.

Fast changing hardware and software technologies in addition to larger and more specialized customer bases demand software tailored to meet very diverse requirements. Software development approaches that aim at capturing this diversity on a single consolidated platform (i.e. software product lines [5]) often require large upfront investments of time and money. Alternatively, companies resort to developing one variant of a software product at a time by reusing as much as possible from already existing product variants (i.e. clone-and-own [2]). However, identifying and extracting the parts to reuse is an error-prone and inefficient task. Hence, more disciplined and systematic approaches are needed to cope with the complexity of developing and maintaining sets of product variants. Such approaches require detailed information about the product variants, the features they provide and their relations.

Abstract Existing studies have shown that structural dependencies within code are good predictors for code actual change impact set—a set of entities that repeatedly changing together to ensure a consistent and complete change. However, the result is far from ideal, particularly when insufficient historical data are available at an early stage of software development. This paper demonstrates that a better understanding of data dependencies in addition to call dependencies greatly improves actual change impact set prediction. We propose a new approach and tool (namely, CHIP) to predict software actual change impact sets leveraging both call and data sharing dependencies. For this purpose, CHIP employs novel extensions (dependency frequency filtering and shared data type idf filtering) to reduce false positives. CHIP assumes that developers know initial places where to start making changes in the source code even though they may not know all changes. This approach has been empirically evaluated on 4 large‐scale open source systems. Our evaluation demonstrates that data sharing dependencies have a complementary impact on software actual change impact set prediction as compared with predictions based on call dependencies only. CHIP improves the F2‐score compared with the predictors using both Program Dependence Graph and evolutionary couplings.

Abstract Software product lines (SPLs) are families of related systems whose members are distinguished by the set of features they provide. Over 2 decades of research and practice can attest to the substantial benefits of applying SPL practices such as better customization, improved software reuse, and faster time to market. Software product line engineering (SPLE) refers to the paradigm of developing SPLs. Typical SPLE efforts involve a large number of features that are combined to form also large numbers of products, implemented using multiple and different types of software artifacts. Because of the sheer amount of information and its complexity, visualization techniques have been used for different SPLE activities. In this paper, we present an extended systematic mapping study on this subject. Our research questions aim to gather information regarding the techniques that have been applied, at what SPLE activities, how they were implemented, the publication fora used, the methods of empirical evaluation, and the provenance of the evaluation examples. Our driving goal is to identify common trends, gaps, and opportunities for further research and application.

Summary After a number of success stories in safety‐critical domains, we are starting to witness applications of formal methods in contemporary systems and software engineering. However, one thing that is still missing is the evaluation criteria that help software practitioners choose the right formal method for the problem at hand. In this paper, we present the criteria for evaluating and comparing different formal methods. The criteria were chosen through a literature review, discussions with experts from academia and practitioners from industry, and decade‐long personal experience with the application of formal methods in industrial and academic projects. The criteria were then evaluated on several model‐oriented state‐based formal methods. Our research shows that besides technical grounds (eg, modeling capabilities and supported development phases), formal methods should also be evaluated from social and industrial perspectives. We also found out that it is not possible to generate a matrix that renders the selection of the right formal method an automatic process. However, we can generate several pointers, which make this selection process a lot less cumbersome.

Metamodels, like any other software artifacts evolve throughout time. As a consequence, all dependent artifacts may need to be co-evolved accordingly, including model transformations. Transformations are a key component of an automated development solution, thus it is crucial to automate their co-evolution while guaranteeing that they remain correct. However, there is little known about what aspects and characteristics must be automated in a manual co-evolution and in particular how it should be correctly automated. Few approaches exist, but it is not clear to what extent those approaches are able to automate the manual co-evolution of model transformations. In this paper, we report on an exploratory experiment we conducted to better understand the co-evolution of transformations in practice and to assess the usefulness of the current existing techniques. 15 participants were involved in our experiment to monitor how they co-evolve transformation rules in response to metamodel evolution. Our analysis results show that while existing approaches support the user with an automatic impact analysis, they do not consider proposing a very large spectrum of alternative resolutions. Among the 14 resolutions that occurred in our experiment, on average only 4 (up to 6) were supported by the existing approaches.

A common task performed in model-driven software engineering is evolving models. This task is typically performed manually during the design or implementation phase of software projects and is known to cause inconsistencies. Despite extensive research on consistency checking, existing approaches either provide abstract (i.e., incomplete) repairs only, or they require manually predefined strategies on how to repair inconsistencies. In this paper, we present a novel approach that provides concrete (i.e., executable) repairs without the need of predefined repair strategies. Furthermore, our approach proposes functions which automate the generation of concrete repairs at runtime. An empirical assessment of the approach on six case studies from industry, academia and GitHub demonstrates its feasibility, and shows that the provided concrete repairs are relevant and can fix their corresponding inconsistencies automatically.

The reuse of code fragments by copying and pasting is widely practiced in software development and results in code clones. Cloning is considered an anti-pattern as it negatively affects program correctness and increases maintenance efforts. Programmable Logic Controller (PLC) software is no exception in the code clone discussion as reuse in development and maintenance is frequently achieved through copy, paste, and modification. Even though the presence of code clones may not necessary be a problem per se, it is important to detect, track and manage clones as the software system evolves. Unfortunately, tool support for clone detection and management is not commonly available for PLC software systems or limited to generic tools with a reduced set of features. In this paper, we investigate code clones in a real-world PLC software system based on IEC 61131-3 Structured Text and C/C++. We extended a widely used tool for clone detection with normalization support. Furthermore, we evaluated the different types and natures of code clones in the studied system and their relevance for refactoring. Results shed light on the applicability and usefulness of clone detection in the context of industrial automation systems and it demonstrates the benefit of adapting detection and management tools for IEC 611313-3 languages.

Information Retrieval (IR) identifies trace links based on textual similarities among software artifacts. However, the vocabulary mismatch problem between different artifacts hinders the performance of IR-based approaches. A growing body of work addresses this issue by combining IR techniques with code dependency analysis such as method calls. However, so far the performance of combined approaches is highly dependent to the correctness of IR techniques and does not take full advantage of the code dependency analysis. In this paper, we combine IR techniques with closeness analysis to improve IR-based traceability recovery. Specifically, we quantify and utilize the “closeness” for each call and data dependency between two classes to improve rankings of traceability candidate lists. An empirical evaluation based on three real-world systems suggests that our approach outperforms three baseline approaches.

Fast-changing hardware and software technologies in addition to larger and more specialized customer bases demand software tailored to meet very diverse requirements. Software development approaches that aim at capturing this diversity on a single consolidated platform often require large upfront investments, e.g., time or budget. Alternatively, companies resort to developing one variant of a software product at a time by reusing as much as possible from already-existing product variants. However, identifying and extracting the parts to reuse is an error-prone and inefficient task compounded by the typically large number of product variants. Hence, more disciplined and systematic approaches are needed to cope with the complexity of developing and maintaining sets of product variants. Such approaches require detailed information about the product variants, the features they provide and their relations. In this paper, we present an approach to extract such variability information from product variants. It identifies traces from features and feature interactions to their implementation artifacts, and computes their dependencies. This work can be useful in many scenarios ranging from ad hoc development approaches such as clone-and-own to systematic reuse approaches such as software product lines. We applied our variability extraction approach to six case studies and provide a detailed evaluation. The results show that the extracted variability information is consistent with the variability in our six case study systems given by their variability models and available product variants.

In today's engineering projects, companies continuously have to adapt their systems to changing customer or market requirements. This requires a flexible, iterative development process in which different parts of the system under construction are built and updated concurrently. However, concurrent engineering is quite problematic in domains where different engineering domains and different engineering tools come together. In this paper, we discuss experiences with Van Hoecke Automation, a leading company in the areas of production automation and product processing, in maintaining the consistency between electrical models and the corresponding software controller when both are subject to continuous change. The paper discusses how we let engineers describe the relationships between electrical model and software code in form of links and consistency rules, and how through continuous consistency checking our approach then notified those engineers of the erroneous impact of changes in either electrical model or code.

Today's software projects face an environment of continuous change and evolution. In order to handle evolution in development environments (e.g., requirements, technology) effectively, over the last decades well-established development processes have been adapted significantly and new process models have been proposed. For example, there is a wide range of agile processes which are risk-driven and which not only handle but embrace frequent change. However, agile and risk-driven processes still suffer from a lack of support for automatic and generic identification of certain risks.

Software developers work concurrently on different kinds of development artifacts such as requirements, architecture, design, or source code. To keep these development artifacts consistent, developers have a wide range of consistency checking approaches available. However, most existing consistency checkers work best in context of single tools and they are not well suited when development artifacts are distributed among different tools and are being modified concurrently by many developers.

Robust and effective support for the detection and management of features and their interactions is crucial for many software development tasks but has proven to be an elusive goal despite the extensive research and practice on the subject. Providing the required support becomes even more challenging with variable software whereby multiple variants of a system and their features must be collectively considered. An important premise to provide better support for feature interactions in variable systems is the need of a deeper understanding on how features interact at different levels starting from the source level. In this context, recent work has looked at feature interactions from different angles and for different purposes, for instance for developing performance models, extracting interfaces for maintenance or describing feature evolution patterns. However, there is a gap in understanding how features interact in fact at the source level in contrast with how features ought to interact according to variability models that describe the valid combinations of features in variable software systems. In this paper we perform an empirical study to explore this gap. We use seven case studies, implemented in Java and C, totalling over nine million LoC, and analysed over seven thousand feature interactions. Our study revealed important inconsistencies between how feature interactions occur at source level and how they are modeled, and corroborated that the majority of source level interactions involve less than three features. We discuss the implications of our findings and avenues for further research.

Software Product Lines (SPLs) are families of related systems whose members are distinguished by the set of features they provide. To effectively evolve and maintain SPLs it is vital to understand how features are implemented and how they interact at different levels from source code to runtime. However the large number of features and the complex nature of interactions in typical SPLs make maintenance and evolution tasks challenging, and demand robust tool support for the software engineers to carry out these tasks. In this paper we present the first results of our ongoing work to address this need. We put forward four visualizations that focus on features and their interactions at source code level, evaluate them with four case studies, and sketch our future work.

Software Product Lines (SPLs) are families of related systems whose members are distinguished by the set of features they provide. Over two decades of research and practice can attest to the substantial benefits of applying SPL practices such as better customization, improved software reuse, and faster time to market. Typical SPLs involve large number of features which are combined to form also large numbers of products, implemented using multiple and different types of software artifacts. Because of the sheer amount of information and its complexity visualization techniques have been used at different stages of the life cycle of SPLs. In this paper we present a systematic mapping study on this subject. Our research questions aim to gather information regarding the techniques that have been applied, at what stages, how they were implemented, and the publication fora employed. Our goal is to identify common trends, gaps, and opportunities for further research and application.

To effectively cope with increasing customization demands, companies that have developed variants of software systems are faced with the challenge of consolidating all the variants into a Software Product Line, a proven development paradigm capable of handling such demands. A crucial step in this challenge is to reverse engineer feature models that capture all the required feature combinations of each system variant. Current research has explored this task using propositional logic, natural language, and search-based techniques. However, using knowledge from the implementation artifacts for the reverse engineering task has not been studied. We propose a multi-objective approach that not only uses standard precision and recall metrics for the combinations of features but that also considers variability-safety, i.e. the property that, based on structural dependencies among elements of implementation artifacts, asserts whether all feature combinations of a feature model are in fact well-formed software systems. We evaluate our approach with five case studies and highlight its benefits for the software engineer.

Software reuse has become mandatory for companies to compete and a wide range of reuse techniques are available today. However, ad hoc practices such as copying existing systems and customizing them to meet customer-specific needs are still pervasive, and are generically called clone-and-own. We have developed a conceptual framework to support this practice named ECCO that stands for Extraction and Composition for Clone-and-Own. In this paper we present our Eclipse-based tool to support this approach. Our tool can automatically locate reusable parts from previously developed products and subsequently compose a new product from a selection of desired features. The tools demonstration video can be found here: http://youtu.be/N6gPekuxU6o.

Complex software-intensive systems are often described as systems of systems (SoS) comprising heterogeneous architectural elements. As SoS behavior fully emerges during operation only, runtime monitoring is needed to detect deviations from requirements. Today, diverse approaches exist to define and check runtime behavior and performance characteristics. However, existing approaches often focus on specific types of systems and address certain kinds of checks, thus impeding their use in industrial SoS. Furthermore, as many SoS need to run continuously for long periods, the dynamic definition and deployment of constraints needs to be supported. In this paper we describe experiences of developing and applying a DSL-based approach for monitoring an SoS in the domain of industrial automation software. We evaluate both the expressiveness of our DSL as well as the scalability of the constraint checker. We also describe lessons learned.

Requirements traceability benefits many software engineering activities, such as change impact analysis and risk assessment. However, these activities require complete and correct traceability links which is not trivial, making traceability assessment an important field of study. In recent years, requirements traceability research has focused on using call dependencies within source code to understand how code properties contribute to the implementation of a requirement and to assess whether traceability links are correct and complete. These approaches largely ignore the role of existing data dependencies within the source code. That is, methods may never call each other, but may still depend upon another by sharing data. We identified five research questions and validated them on five software systems, covering 4 to 72 KLOC. We found that data dependencies are as relevant as call dependencies for assessing requirements traceability. Even more interesting, our analyses show that data dependencies complement call dependencies in the assessment. These findings have strong implications on code understanding, including trace capture, maintenance, and validation techniques. Copyright © 2015 John Wiley & Sons, Ltd.

Software Product Lines (SPLs) are families of related software products, each with its own set of feature combinations. Their commonly large number of products poses a unique set of challenges for software testing as it might not be technologically or economically feasible to test of all them individually. SPL pairwise testing aims at selecting a set of products to test such that all possible combinations of two features are covered by at least one selected product. Most approaches for SPL pairwise testing have focused on achieving full coverage of all pairwise feature combinations with the minimum number of products to test. Though useful in many contexts, this single-objective perspective does not reflect the prevailing scenario where software engineers do face trade-offs between the objectives of maximizing the coverage or minimizing the number of products to test. In contrast and to address this need, our work is the first to propose a classical multi-objective formalisation where both objectives are equally important. In this paper, we study the application to SPL pairwise testing of four classical multi-objective evolutionary algorithms. We developed three seeding strategies — techniques that leverage problem domain knowledge — and measured their performance impact on a large and diverse corpus of case studies using two well-known multi-objective quality measures. Our study identifies the performance differences among the algorithms and corroborates that the more domain knowledge leveraged the better the search results. Our findings enable software engineers to select not just one solution (as in the case of single-objective techniques) but instead to select from an array of test suite possibilities the one that best matches the economical and technological constraints of their testing context.

In model-driven engineering, design models allow for efficient designing without considering implementation details. Still, it is crucial that design models and source code are in sync. Unfortunately, both artifacts do evolve frequently and concurrently which causes them to drift apart over time. Even though technologies such as model-to-code transformations are commonly employed to keep design models and source code synchronized, those technologies typically still require unguided, manual adaptations. Hence, they do not effectively prevent inconsistencies from being introduced. In this paper, we outline a novel approach for checking consistency between design models and source code. Our approach aims at detecting inconsistencies instantly and informing developers about a project's consistency status live during development.

Software Product Lines (SPLs) are families of related software systems, which provide different feature combinations. Different SPL testing approaches have been proposed. However, despite the extensive and successful use of evolutionary computation techniques for software testing, their application to SPL testing remains largely unexplored. In this paper we present the Parallel Prioritized product line Genetic Solver (PPGS), a parallel genetic algorithm for the generation of prioritized pairwise testing suites for SPLs. We perform an extensive and comprehensive analysis of PPGS with 235 feature models from a wide range of number of features and products, using 3 different priority assignment schemes and 5 product prioritization selection strategies. We also compare PPGS with the greedy algorithm prioritized-ICPL. Our study reveals that overall PPGS obtains smaller covering arrays with an acceptable performance difference with prioritized-ICPL.

To keep pace with the increasing demand for custom-tailored software systems, companies often apply a practice called clone-and-own, whereby a new variant of a software system is built by coping and adapting existing variants. Instead of a single and configurable system, clone-and-own leads to ad hoc product portfolios of multiple yet similar variants that soon become impossible to maintain effectively. Clone-and-own has widespread industrial use because it requires no major upfront investments and is intuitive, but it lacks a methodology for systematic reuse. In this work we propose ECCO (Extraction and Composition for Clone-and-Own), a novel approach to enhance clone and-own that actively supports the development and maintenance of software product variants. A software engineer selects the desired features and ECCO finds the proper software artifacts to reuse and then provides guidance during the manual completion by hinting which software artifacts may need adaptation. We evaluated our approach on 6 case studies, covering 402 variants having up to 344KLOC, and found that precision and recall of composed products quickly reach a near optimum (>95% reuse).

Software engineering methods for analyzing and managing variable software systems rely on accurate feature-to-code mappings to relate high-level variability abstractions, such as features or decisions, to locations in the code where variability occurs. Due to the continuous and long-term evolution of many systems such mappings need to be extracted and updated automatically. However, current approaches have limitations regarding the analysis of highly-configurable systems that rely on different variability mechanisms. We present a novel approach that exploits the synergies between program analysis and doffing techniques to reveal feature-to-code mappings for highly-configurable systems. We demonstrate the feasibility of our approach with a set of products from a real-world product line in the domain of industrial automation.

Software Product Lines (SPLs) have gained popularity in industry as they foster the reuse of artifacts, such as code, and reduce product development effort. Although some SPLs ensure that only valid products are configurable, those products are not necessarily optimal. For instance, they may include code that is not necessary for providing the desired functionality -- often because of erroneous traceability between features and code. Such unnecessary code may be disallowed in safety critical domains, it may lead to losses in runtime performance, or it may lead to errors during later SPL evolution. In this paper, we present an approach for automatic and incremental product optimization. Our approach leverages product functionality tests to ensure that configured products do not include unnecessary artifacts -- an automatic re-optimization of products after SPL evolution is performed incrementally. The evaluation results show that such a re-optimization takes only milliseconds.

State-of-the-art optimistic model versioning systems, which are critical to enable efficient team-based development of architectural models, are able to detect and help resolve basic conflicts arising during the merging of model versions. However, it is often overlooked that model merging may also cause severe syntactical and semantic inconsistencies. In this paper, we propose an approach to guide the resolution of inconsistencies detected in a merged architectural model. Our approach automatically finds and presents to the software architects all solutions for resolving all inconsistencies arisen during the merging of model versions. For inconsistencies that pre-exist in the model, our approach is able to suggest exactly which model elements should be changed to resolve them. Our approach is built upon a repair generation which can quickly derive resolutions for an inconsistency by examining its static and dynamic structure and forming concrete repair actions from changes in the versions to be merged. An empirical validation on a range of industrial models has demonstrated that our approach is scalable to both large models and large differences between model versions.

Lopez-Herrejon, R. E., Chicano F., Ferrer J., Egyed A., & Alba E. (2013). Multi-objective Optimal Test Suite Computation for Software Product Line Pairwise Testing. 2013 IEEE International Conference on Software Maintenance, Eindhoven, The Netherlands, September 22-28, 2013. 404–407.

Many companies offer a palette of similar software products though they do not necessarily have a Software Product Line (SPL). Rather, they start building and selling individual products which they then adapt, customize and extend for different customers. As the number of product variants increases, these companies then face the severe problem of having to maintain them all. Software Product Lines can be helpful here - not so much as a platform for creating new products but as a means of maintaining the existing ones with their shared features. Here, an important first step is to determine where features are implemented in the source code and in what product variants. To this end, this paper presents a novel technique for deriving the traceability between features and code in product variants by matching code overlaps and feature overlaps. This is a difficult problem because a feature's implementation not only covers its basic functionality (which does not change across product variants) but may include code that deals with feature interaction issues and thus changes depending on the combination of features present in a product variant. We empirically evaluated the approach on three non-trivial case studies of different sizes and domains and found that our approach correctly identifies feature to code traces except for code that traces to multiple disjunctive features, a rare case involving less than 1% of the code.

Software Product Lines (SPLs) are families of related software products. SPL practices have proven substantial technological and economical benefits such as improved software reuse and reduced time to market. Software testing is a key development activity in SPLs, and it is uniquely challenging because of the usually large number of feature combinations present in typical SPLs. Pairwise testing is a combinatorial testing technique that aims at selecting products to test based on the pairs of feature combinations such products provide. Our previous work on evolutionary approaches for SPL testing and their comparative analysis has yielded a large amount of data that prompted us to explore ways by which to convey and represent this information. In this paper we present our early results in this effort. We describe three basic visualization applications to pairwise testing and highlight some of the open questions that we foresee. But most importantly, our driving goal is both to raise the awareness of the visualization problems in this area and to spark the interest of the software visualization community.

When a software engineer finds an inconsistency in a model, then the first question is why? What caused it? Obviously, there must be an error. But where could it be? Or is the design rule erroneous and if yes then which part? The cause of an inconsistency identifies the part of the model or design rule where the error must be. We believe that the visualization of an inconsistency ought to visualize the cause. Understanding the cause is of vital importance before a repair can even be formulated. Indeed, any automation (e.g., code generation, refactoring) has to be considered with caution if it involves model elements that cause inconsistencies. This paper analyzes the basic structure of inconsistent design rules as well as their behavior during validation and presents an algorithm for computing its cause. The approach is fully automated, tool supported, and was evaluated on 14,111 inconsistencies across 29 design models. We found that our approach computes correct causes for inconsistencies, these causes are nearly always a subset of the model elements investigated by the design rules' validation (a naive cause computation approximation), and the computation is very fast (99.8 percent of the causes are computable in < 100 ms).

It is common practice for requirements traceability research to consider method call dependencies within the source code (e.g., fan-in/fan-out analyses). However, current approaches largely ignore the role of data. The question this paper investigates is whether data dependencies have similar relationships to requirements as do call dependencies. For example, if two methods do not call one another, but do have access to the same data then is this information relevant? We formulated several research questions and validated them on three large software systems, covering about 120 KLOC. Our findings are that data relationships are roughly equally relevant to understanding the relationship to requirements traces than calling dependencies. However, most interestingly, our analyses show that data dependencies complement call dependencies. These findings have strong implications on all forms of code understanding, including trace capture, maintenance, and validation techniques (e.g., information retrieval).

Advocates of requirements traceability regularly cite advantages like easier program comprehension and support for software maintenance (i.e., software change). However, despite its growing popularity, there exists no published evaluation about the usefulness of requirements traceability. It is important, if not crucial, to investigate whether the use of requirements traceability can significantly support development tasks to eventually justify its costs. We thus conducted a controlled experiment with 52 subjects performing real maintenance tasks on two third-party development projects: half of the tasks with and the other half without traceability. Our findings show that subjects with traceability performed on average 21% faster on a task and created on average 60% more correct solutions — suggesting that traceability not only saves downstream cost but can profoundly improve software maintenance quality. Furthermore, we aimed for an initial cost-benefit estimation and set the measured time reductions by using traceability in relation to the initial costs for setting-up traceability in the evaluated systems.

Design models must abide by constraints that can come from diverse sources, like their metamodels, requirements, or the problem domain. Software modelers expect these constraints to be enforced on their models and receive instant error feedback if they fail. This works well when constraints are stable. However, constraints may evolve much like their models do. This evolution demands efficient constraint adaptation mechanisms to ensure that models are always validated against the correct constraints. In this paper, we present an idea based on constraint templates that tackles this evolution scenario by automatically generating and updating constraints.

Traces between requirements and code reveal where requirements are implemented. Such traces are essential for code understanding and change management. Unfortunately, traces are known to be error prone. This paper introduces a novel approach for validating requirements-to-code traces through calling relationships within the code. As input, the approach requires an executable system, the corresponding requirements, and the requirements-to-code traces that need validating. As output, the approach identifies likely incorrect or missing traces by investigating patterns of traces with calling relationships. The empirical evaluation of four case study systems covering 150 KLOC and 59 requirements demonstrates that the approach detects most errors with 85-95% precision and 82-96% recall and is able to handle traces of varying levels of correctness and completeness. The approach is fully automated, tool supported, and scalable.

Resolving inconsistencies in software models is a complex task because the number of repairs grows exponentially. Existing approaches thus emphasize on selected repairs only but doing so diminishes their usefulness. This paper copes with the large number of repairs by focusing on what caused an inconsistency and presenting repairs as a linearly growing repair tree. The cause is computed by examining the run-time evaluation of the inconsistency to understand where and why it failed. The individual changes that make up repairs are then modeled in a repair tree as alternatives and sequences reflecting the syntactic structure of the inconsistent design rule. The approach is automated and tool supported. Its scalability was empirically evaluated on 29 UML models and 18 OCL design rules where we show that the approach computes repair trees in milliseconds on average. We believe that the approach is applicable to arbitrary modeling and constraint languages.

Traceability underlies many important software and systems engineering activities, such as change impact analysis and regression testing. Despite important research advances, as in the automated creation and maintenance of trace links, traceability implementation and use is still not pervasive in industry. A community of traceability researchers and practitioners has been collaborating to understand the hurdles to making traceability ubiquitous. Over a series of years, workshops have been held to elicit and enhance research challenges and related tasks to address these shortcomings. A continuing discussion of the community has resulted in the research roadmap of this paper. We present a brief view of the state of the art in traceability, the grand challenge for traceability and future directions for the field.

Tolerating inconsistencies is well accepted in design modeling because it is often neither obvious how to fix an inconsistency nor important to do so right away. However, there are technical reasons why inconsistencies are not tolerated in many areas of software engineering. The most obvious being that common reasoning engines are rendered (partially) useless in the presence of inconsistencies. This paper investigates automated strategies for tolerating inconsistencies during decision-making in product line engineering, based on isolating parts from reasoning that cause inconsistencies. We compare trade offs concerning incorrect and incomplete reasoning and demonstrate that it is even possible to fully eliminate incorrect reasoning in the presence of inconsistencies at the expense of marginally less complete reasoning. Our evaluation is based on seven medium-to-large size software product line case studies. It is important to note that our mechanism for tolerating inconsistencies can be applied to arbitrary SAT problems and thus the basic principles of this approach are applicable to other domains also.

Developing high quality systems depends on developing high quality models. An important facet of model quality is their consistency with respect to their meta-model. We call the verification of this quality the conformance checking process. We are interested in the conformance checking of Product Line Models (PLMs). The problem in the context of product lines is that product models are not created by instantiating a meta-model: they are derived from PLMs. Therefore it is usually at the level of PLMs that conformance checking is applied. On the semantic level, a PLM is defined as the collection of all the product models that can be derived from it. Therefore checking the conformance of the PLM is equivalent to checking the conformance of all the product models. However, we would like to avoid this naïve approach because it is not scalable due to the high number of models. In fact, it is even sometimes infeasible to calculate the number of product models of a PLM. Despite the importance of PLM conformance checking, very few research works have been published and tools do not adequately support it. In this paper, we present an approach that employs Constraint Logic Programming as a technology on which to build a PLM conformance checking solution. The paper demonstrates the approach with feature models, the de facto standard for modeling software product lines. Based on an extensive literature review and an empirical study, we identified a set of 9 conformance checking rules and implemented them on the GNU Prolog constraints solver. We evaluated our approach by applying our rules to 50 feature models of sizes up to 10000 features. The evaluation showed that our approach is effective and scalable to industry size models.

State-of-the-art modeling tools can help detect inconsistencies in software models. Some can even generate fixing actions for these inconsistencies. However such approaches handle inconsistencies individually, assuming that each single inconsistency is a manifestation of an individual defect. We believe that inconsistencies are merely expressions of defects. That is, inconsistencies highlight situations under which defects are observable. However, a single defect in a software model may result in many inconsistencies and a single inconsistency may be the result of multiple defects. Inconsistencies may thus be related to other inconsistencies and we believe that during fixing, one should consider clusters of such related inconsistencies. This paper provides first evidence and emerging results that several inconsistencies can be linked to a single defect and show that with such knowledge only a subset of fixes need to be considered during inconsistency resolution.

This paper presents GoPoMoSA, a Goal-oriented Process Modeling and Simulation Advisor that semi-automatically discovers suitable Software Process Modeling and Simulation (SPMS) techniques for (inexperienced) process modelers to achieve their process modeling goals. GoPoMoSA takes the goal-oriented modeling approach that captures the associations among Process Modeling Stakeholder goals and existing SPMS techniques via Relevant Process Elements modeled in the knowledge graphs. We evaluated the accuracy and feasibility of GoPoMoSA with data collected from 212 published SPMS literatures and a real-world process modeling and simulation case on requirements traceability. Our results show that GoPoMoSA (1) was able to find suitable SPMS techniques based on stakeholder goals with an average of 85.38% accuracy; (2) helped novice process modelers effectively and efficiently achieve their goals.

Traces between requirements and code reveal where requirements are implemented. Such traces are essential for code understanding and change management. Unfortunately, the handling of traces is highly error prone, in part due to the informal nature of requirements. This paper discusses observations on the connectedness between requirements-to-code traces and calling relationships within the source code. These observations are based on the empirical evaluation of four case study systems covering 150 KLOC and 59 sample requirements. We found that certain patterns of connectedness have high or low likelihoods of occurring. These patterns can thus be used to confirm or reject existing traceability - hence they are useful for validating requirements-to-code traces.

For decades now, mainstream development environments provide the same basic automations for navigating source code: mainly searching and the tree exploration of files and folders. This may imply that other automations have little additional value or too steep a learning curve for mainstream adoption. This paper investigates whether source code navigation enriched with traceability benefit basic maintenance tasks such as changing features and fixing bugs in code. To test this, we conducted a controlled experiment with 52 subjects performing real maintenance tasks on two third-party development projects: all with the same navigation tool but half of the tasks with and the other half without traceability navigation. We found that the existence of traceability profoundly affected the quality of the change tasks and fundamentally changed how software engineers navigated through source code. We show that software engineers benefit instantly from traceability, without training, which is to show that the current automations available to software engineers are by no means sufficient or the only easy ones to use.

There are only few methods available that help refining software requirements to software architectures. An example is the CBSP (Component-Bus-System-Property) approach that uses general architectural concerns to classify and refine requirements and to capture architectural trade-off issues and options. This paper reports about experiences of applying CBSP in an industrial project in the area of mobile applications. We illustrate CBSP using project examples. We discuss how the approach was tailored and present extensions we developed. In particular, we show how CBSP can be used together with the Goal-Question-Metric approach to guide architectural decisions. We close our paper with a discussion of lessons learned during this project.

Model-driven engineering has become a popular methodology in software engineering. Most available modeling tools support the creation of models based on a fixed metamodel. Typically, tool users cannot change the metamodel to reflect domain changes or newly emerged requirements. As a consequence, an updated version of the tool with an evolved metamodel must be developed and models as well as constraints that ensure model consistency have to be co-evolved, often manually, to conform to the new metamodel. Both, tool evolution and the necessary co-evolutions, are time consuming and error prone tasks. Furthermore, common tools often restrict the number of metalevels that can be modeled and force modelers to use workarounds to express certain facts. To overcome these issues we present the Cross-Layer Modeler (XLM), a modeling tool that supports multilevel modeling and allows co-evolution of metamodels and models. The XLM automatically performs co-evolution of constraints and gives instant feedback about model consistency. We illustrate the novel modeling approach of our tool and discuss its main capabilities.

More and more frequently successful software systems need to evolve into families of systems, known as Software Product Lines (SPLs), to be able to cater to the different functionality requirements demanded by different customers while at the same time aiming to exploit as much common functionality as possible. As a first step, this evolution demands a clear understanding of how the functional requirements map into the features of the original system. Using this knowledge, features can be refactored so that they are reused for building the new systems of the evolved SPL. In this paper we present our experience in refactoring features based on the requirements specifications of a small and a medium size systems. Our work identified eight refactoring patterns that describe how to extract the elements of features which were subsequently implemented using Feature Oriented Software Development (FOSD) a novel modularization paradigm whose driving goal is to effectively modularize features for the development of variable systems. We argue that the identification of refactoring patterns are a stepping stone towards automating Feature-Oriented Refactoring, and present some open issues that should be addressed to that avail.

The configuration of a product from a product line is a decision-making process that requires humans to answer questions. However, questions and their choices tend to affect one another (e. g., one feature depending on another) and decisions on how questions are answered may render other questions obsolete or reduce their choices. There is thus an ideal order in which questions should be answered to minimize the number of questions that need answering to completely configure a product. Unfortunately, this ideal order differs depending on the product -- which cannot be known a priori. Decision-making is thus characterized by either imposing a predefined order on how questions must be answered (usually done manually by product line engineers) or not imposing any order. Both situations have downsides and this paper thus proposes an alternative: an incremental algorithm and tool-support for automatically optimizing the order of questions with every answer. We evaluated our approach on six models, the largest with over 280 questions, and found that the approach is 78-99% optimal and significantly reduces the number of questions that need to be answered manually. For the creators of product line models, this implies savings in not having to predefine the optimal order which is exponentially complex. For the configurator (decision maker) this implies more freedom in the order in which to answer questions while still benefiting from guidance.

Software models typically contain many inconsistencies and consistency checkers help engineers find them. Even if engineers are willing to tolerate inconsistencies, they are better off knowing about their existence to avoid follow-on errors and unnecessary rework. However, current approaches do not detect or track inconsistencies fast enough. This paper presents an automated approach for detecting and tracking inconsistencies in real time (while the model changes). Engineers only need to define consistency rules-in any language-and our approach automatically identifies how model changes affect these consistency rules. It does this by observing the behavior of consistency rules to understand how they affect the model. The approach is quick, correct, scalable, fully automated, and easy to use as it does not require any special skills from the engineers using it. We evaluated the approach on 34 models with model sizes of up to 162,237 model elements and 24 types of consistency rules. Our empirical evaluation shows that our approach requires only 1.4 ms to reevaluate the consistency of the model after a change (on average); its performance is not noticeably affected by the model size and common consistency rules but only by the number of consistency rules, at the expense of a quite acceptable, linearly increasing memory consumption.

Trace links between requirements and code reveal where requirements are implemented. Such trace links are essential for code understanding and change management. The lack thereof is often cited as a key reason for software engineering failure. Unfortunately, the creation and maintenance of requirements-to-code traces remains a largely manual and error prone task due to the informal nature of requirements. This paper demonstrates that reasoning about requirements-to-code traces can be done, in part, by considering the calling relationships within the source code (call graph). We observed that requirements-to-code traces form regions along calling dependencies. Better knowledge about these regions has several direct benefits. For example, erroneous traces become detectable if a method inside a region does not trace to a requirement. Or, a missing trace (incompleteness) can be identified. Knowledge of requirement regions can also be used to help guide developers in establishing requirements-to-code traces in a more efficient manner. This paper discusses requirement regions and sketches their benefits.

COTS products can play various architectural roles in software systems: as interfaces to problem-specific functionality, as components that provide such functionality itself, and as intermediary connectors and components in more complex systems. In doing so, COTS products impose their own, unique constraints on organization and functionality. Over the last ten years, we have gained considerable experience with adopting, adapting, and living with the limitations of COTS products. Our goal was to adapt the COTS product to make it fit the application rather than adapting the application needs to make them fit the COTS product - thus, in essence, adapting the COTS product without access to its source code or documentation (a unique form of maintenance). We report on a large set of experiences involving eight COTS products and a wide range of COTS-Based Software Systems - most of which were done with and for industrial partners or government agencies. This experience report attempts to both give a feeling for how applications can be augmented with such COTS interfaces and also tries to tease out the specific architectural issues that anyone adapting COTS products is certain to face.

Decision models are widely used in software engineering to describe and restrict decision-making (e.g., deriving a product from a product-line). Since decisions are typically interdependent, conflicts during decision-making are inevitably reached when invalid combinations of decisions are made. Unfortunately, the current state-of-the-art provides little support for dealing with such conflicts. On the one hand, some conflicts can be avoided by providing more freedom in which order decisions are made (i.e., most important decisions first). On the other hand, conflicts are unavoidable at times and living with conflicts may be preferable over forcing the user to fix them right away - particularly, because fixing conflicts becomes easier the more is known about an user's intentions. This paper introduces the C2O (Configurator 2.0) tool for guided decision-making. The tool allows the user to answer questions in an arbitrary order - with and without the presence of conflicts. While giving users those freedoms, it still supports and guides them by 1) rearranging the order of questions according to their potential to minimize user input, 2) providing guidance to avoid follow-on conflicts, and 3) supporting users in fixing conflicts at a later time.

Integrated development environments are widely used in industry and support software engineers with instant error feedback about their work. Modeling tools often react to changes at a coarse level of granularity that make reasoning about errors inefficient and late. Furthermore, there is often a lack of appropriate visualizations of model errors and information on how to fix them. This paper presents the Model/Analyzer tool, an eclipse-based plug-in for the IBM Rational Software Modeler (RSM). The tool lets software engineers define arbitrary design rules and provides instant feedback on their validity in context of a model. Design errors are then visualized together with the information on what parts of the model contributed to them and how to fix them. The tool is fully automated and currently supports OCL and Java as languages for defining the design rules; and UML as the modeling language. The main benefit for the software engineer is the tool's incremental nature if providing instant feedback for many kinds of design errors even for large models.

The complexity of product line variability models makes it hard to maintain their consistency over time regardless of the modeling approach used. Engineers thus need support for detecting and resolving inconsistencies. We describe experiences of applying a tool-supported approach for incremental consistency checking on variability models. Our approach significantly improves the overall performance and scalability compared to batch-oriented techniques and allows providing immediate feedback to modelers. It is extensible as new consistency constraints can easily be added. Furthermore, the approach is flexible as it is not limited to variability models and it also checks the consistency of the models with the underlying code base of the product line. We report the results of a thorough evaluation based on real-world product line models and discuss lessons learned.

Trace links between requirements and code are essential for many software development and maintenance activities. Despite significant advances in traceability research, creating links remains a human-intensive activity and surprisingly little is known about how humans perform basic tracing tasks. We investigate fundamental research questions regarding the effort and quality of recovering traces between requirements and code. Our paper presents two exploratory experiments conducted with 100 subjects who recovered trace links for two open source software systems in a controlled environment. In the first experiment, subjects recovered trace links between the two systems' requirements and classes of the implementation. In the second experiment, trace links were established between requirements and individual methods of the implementation. In order to assess the validity of the trace links cast by subjects, key developers of the two software systems participated in our research and provided benchmarks. Our study yields surprising observations: trace capture is surprisingly fast and can be done within minutes even for larger classes; the quality of the captured trace links, while good, does not improve with higher trace effort; and it is not harder though slightly more expensive to recover the trace links for larger, more complex classes.

Today, programmers benefit immensely from Integrated Development Environments (IDEs), where errors are highlighted within seconds of their introduction. Yet, designers rarely benefit from such an instant feedback in modeling tools. This paper focuses on the refinement of UML-style class models with instant feedback on correctness. Following the Model-Driven Architecture (MDA) paradigm, we strongly believe in the benefit of maintaining high-level and low-level models separately to 1) document the lower level model and 2) continuously ensure the correctness of the low-level model during later evolution (i.e., high- or low-level models may be evolved independently). However, currently the refinement and subsequent evolution lack automated support, let alone an instant feedback on their correctness (i.e., consistency). Traditional approaches to consistency checking fail here because of the computational cost of comparing class models. Our proposed instant approach first transforms the low-level model into an intermediate model that is then easier comparable with the high-level model. The key to computational scalability is the separation of transformation and comparison so that each can react optimally to changes-changes that could happen concurrently in both the high- and low-level class models. We evaluate our approach on eight third-party design models. The empirical data show that the separation of transformation and comparison results in a 6 to 11-fold performance gain and a ninefold reduction in producing irrelevant feedback. While this work emphasizes the refinement of class models, we do believe that the concepts are more generally applicable to other kinds of modeling languages, where transformation and subsequent comparison are computationally expensive.

Our objective is to provide automated support for assisting designers in fixing inconsistencies in UML models. We have previously developed techniques for efficiently detecting inconsistencies in such models and identifying where changes need to occur in order to fix problems detected by these means. This paper extends previous work by describing a technique for automatically generating a set of concrete changes for fixing inconsistencies and providing information about the impact of each change on all consistency rules. The approach is integrated with the design tool IBM Rational Rose . We demonstrate the computational scalability and usability of the approach through the empirical evaluation of 39 UML models of sizes up to 120,000 elements.

Changes are inevitable during software development and so are their unintentional side effects. The focus of this paper is on UML design models, where unintentional side effects lead to inconsistencies. We demonstrate that a tool can assist the designer in discovering unintentional side effects, locating choices for fixing inconsistencies, and then in changing the design model. Our techniques are "on-line, " applied as the designer works, and non-intrusive, without overwhelming the designer. This is a significant improvement over the state-of-the-art. Our tool is fully integrated with the design tool IBM Rational Rosetrade. It was empirically evaluated on 48 case studies.

Large design models contain thousands of model elements. Designers easily get overwhelmed maintaining the consistency of such design models over time. Not only is it hard to detect new inconsistencies while the model changes but it also hard to keep track of known inconsistencies. The UML/analyzer tool identifies inconsistencies instantly with design changes and it keeps track of all inconsistencies over time. It does not require consistency rules with special annotations. Instead, it treats consistency rules as black-box entities and observes their behavior during their evaluation. The UML/Analyzer tool is integrated with the UML modeling tool IBM Rational RoseTMfor broad applicability and usability. It is highly scalable and was evaluated on dozens of design models.

Software development standards demand requirements traceability without being explicit about the appropriate level of quality of trace links. Unfortunately, long-term trace utilizations are typically unknown at the time of trace acquisition which represents a dilemma for many companies. This paper suggests ways to balance the cost and benefits of requirements traceability. We present data from 3 case studies. Lessons learned suggest a traceability strategy that (1) provides trace links more quickly, (2) refines trace links according to user-definable value considerations, and (3) supports the later refinement of trace links in case the initial value considerations change.

Inconsistencies in design models should be detected immediately to save the engineer from unnecessary rework. Yet, tools are not capable of keeping up with the engineers' rate of model changes. This paper presents an approach for quickly, correctly, and automatically deciding what consistency rules to evaluate when a model changes. The approach does not require consistency rules with special annotations. Instead, it treats consistency rules as black-box entities and observes their behavior during their evaluation to identify what model elements they access. The UML/Analyzer tool, integrated with IBM Rational Rose™, fully implements this approach. It was used to evaluate 29 models with tens-of-thousands of model elements, evaluated on 24 types of consistency rules over 140,000 times. We found that the approach provided design feedback correctly and required, in average, less than 9ms evaluation time per model change with a worst case of less than 2 seconds at the expense of a linearly increasing memory need. This is a significant improvement over the state-of-the-art.

The desirability of maintaining multiple stakeholders' interests during the software design process argues for leaving choices undecided as long as possible. Yet, any form of underspecification, either missing information or undecided choices, must be resolved before automated analysis tools can be used. This paper demonstrates how constraint satisfaction problem solution techniques (CSTs) can be used to automatically reduce the space of choices for ambiguities by incorporating the local effects of constraints, ultimately with more global consequences. As constraints typical of those encountered during the software design process, we use UML consistency and well-formedness rules. It is somewhat surprising that CSTs are suitable for the software modeling domain since the constraints may relate many ambiguities during their evaluation, encountering a well-known problem with CSTs called the k-consistency problem. This paper demonstrates that our CST-based approach is computationally scalable and effective-as evidenced by empirical experiments based on dozens of industrial models

No abstract available

Major software development standards mandate the establishment of trace links among software artifacts such as requirements, architectural elements, or source code without explicitly stating the required level of detail of these links. However, the level of detail vastly affects the cost and quality of trace link generation and important applications of trace analysis such as conflict analysis, consistency checking, or change impact analysis. In this paper, we explore these cost-quality trade-offs with three case study systems from different contexts - the open-source ArgoUML modeling tool, an industrial route-planning system, and a movie player. We report the cost-quality trade-off of automated trace generation with the Trace Analyzer approach and discuss its expected impact onto several applications that consume its trace information. In the study we explore simple techniques to predict and manipulate the cost-benefit trade-off with threshold-based filtering. We found that (a) 80% of the benefit comes from only 20% of the cost and (b) weak trace links are predominantly false trace links and can be efficiently eliminated through thresholds.

Requirements traceability (RT) aims at defining and utilizing relationships between stakeholder requirements and artifacts produced during the software development life-cycle and provides an important means to foster software understanding. Although techniques for generating and validating traceability information are available, RT in practice often suffers from the enormous effort and complexity of creating and maintaining traces. This results in invalid or incomplete trace information which cannot support engineers in real-world problems. In this paper we present a tool-supported approach that requires the designer to specify some trace dependencies but eases trace acquisition by generating others automatically. We illustrate the approach using a video-on-demand system and show how the generated traces can be used in various engineering scenarios to improve software understanding. In a case study using an open source software application we demonstrate that the approach is capable of dealing with large-scale systems and delivers valid results.

Software models provide independent perspectives onto software systems. Ideally, all models should use the same model element to describe the same part of a system. Practically, models elements are not shared because of syntactic and semantic differences among modeling notations. Trace dependencies explicitly maintain the commonalities among the distinct model elements.

Software architecture descriptions can play a wide variety of roles in the software lifecycle, from requirements specification, to logical design, to implementation architectures. In addition, execution architectures can be used both to constrain and enhance the functionality of running systems, e.g. security architectures and debugging architectures. Along with others from DARPA's DASADA program we proposed an execution infrastructure for so-called self-healing, self-adaptive systems - systems that maintain a particular level of healthiness or quality of service (QoS). This externalized infrastructure does not entail any modification of the target system - whose health is to be maintained. It is driven by a reflective model of the target system's operation to determine what aspects can be changed to effect repair. We present that infrastructure along with an example implemented in accord with it.

Following the success of the "First Workshop on Scenarios and State Machines: Models, Algorithms, and Tools" held at ICSE 2002 in Orlando [1], this workshop aims at bringing together researchers and practitioners to build a shared understanding on the relation between scenarios and state machines and to gain insight into techniques and tools that may leverage the combination of these approaches to enhance our means for behavior modeling.

Software development artifacts-such as model descriptions, diagrammatic languages, abstract (formal) specifications, and source code-are highly interrelated where changes in some of them affect others. Trace dependencies characterize such relationships abstractly. This paper presents an automated approach to generating and validating trace dependencies. It addresses the severe problem that the absence of trace information or the uncertainty of its correctness limits the usefulness of software models during software development. It also automates what is normally a time consuming and costly activity due to the quadratic explosion of potential trace dependencies between development artifacts.

Requirements traceability (RT) aims at defining relationships between stakeholder requirements and artifacts produced during the software development life-cycle. Although techniques for generating and validating RT are available, RT in practice often suffers from the enormous effort and complexity of creating and maintaining traces or from incomplete trace information that cannot assist engineers in real-world problems. In this paper we will present a tool-supported technique easing trace acquisition by generating trace information automatically. We will explain the approach using a video-on-demand system and show that the generated traces can be used in various engineering scenarios to solve RT-related problems.

Designers can easily become overwhelmed with details when dealing with large class diagrams. This article presents an approach for automated abstraction that allows designers to "zoom out" on class diagrams to investigate and reason about their bigger picture. The approach is based on a large number of abstraction rules that individually are not very powerful, but when used together, can abstract complex class structures quickly. This article presents those abstraction rules and an algorithm for applying them. The technique was validated on over a dozen models where it was shown to be well suited for model understanding, consistency checking, and reverse engineering.

Design traceability has been widely recognized as being an integral aspect of software development. In the past years this fact has been amplified due to the increased use of legacy systems and COTS (commercial-off-the-shelf) components mixed with the growing use of elaborate "upstream" software modeling techniques such as the Unified Modeling Language (UML). The more intensive emphasis on upstream (non-programming) software development issues has, however, widened the gap between software components (e.g., subsystems, modules) and software models (e.g., class diagrams, data flow diagrams), creating the need for a better understanding of the intricacies and interrelationships between the two. This paper demonstrates how observable run-time information of software systems can be used to detect traceability information between software systems and their models. We do this by employing a technique that evaluates the "footprints" that usage scenarios (e.g., test cases) make during the execution of software systems. Those footprints can be compared, resulting in additional traceability information among modeling elements associated with those scenarios. Our approach is tool supported.

The Unified Modeling Language (UML) supports a wide range of diagrams for modeling software development concerns. UML diagrams are independent but connected; their meta-model describes them under a common roof. Despite the advances of UML, we found that the problem of ensuring consistency between UML diagrams has not been solved. We have developed an approach for automated consistency checking, called VIEWINTEGRA.. Our approach provides excellent support for active (preventive) and passive (detective) consistency checking. We make use of consistent transformation to translate diagrams into interpretations and we use consistency comparison to compare those interpretations to other diagrams. Our approach was applied to a number of applications where we found the separation of transformation and comparison to be highly beneficial in addressing consistency-checking scalability and usability issues. The paper introduces our UML-based transformation framework, discusses how it aids comparison, and demonstrates how it improves consistency checking.

It is becoming increasingly desirable to incorporate commercial-off-the-shelf (COTS) tools as software components into larger software systems. Due to their large user base, COTS tools tend to be cheap, reasonably reliable, and functionally powerful. Reusing them as components has the benefit of significantly reducing development cost and effort. Despite these advantages, developers encounter major obstacles in integrating most COTS tools because these tools have been constructed as stand-alone applications and make assumptions about their environment that do not hold when used as part of larger software systems. Most significantly, while they frequently contain programmatic interfaces that allow other components to obtain services from them on a direct call basis, they almost always lack the notification and data synchronicity facilities required for active integration. The authors present an integration framework for adding these notification and data synchronization facilities to COTS tools so that they can be integrated as active software components into larger systems. We illustrate our integration framework through tool suites we constructed around Mathworks' Matlab/Stateflow and Rational's Rose (two widely-used, large COTS tools). Our experience to date is that it is indeed possible to transform standalone COTS tools into software components.

Little guidance and few methods are available to refine a set of software requirements into an architecture satisfying those requirements. Part of the challenge stems from the fact that requirements and architectures leverage different terms and concepts to capture the artifacts relevant to each. We present CBSP (Component-Bus-System- Property), a lightweight approach intended to provide a systematic way of reconciling requirements and architectures. CBSP leverages a simple set of architectural concepts (components, connectors, overall systems, and their properties) to recast the requirements in a way that facilitates their straightforward mapping to architectures. Furthermore, the approach allows us to capture and maintain arbitrarily complex relationships between requirements and architectural artifacts, as well as across different CBSP artifacts. We have extensively applied CBSP within the context of particular requirements and architecture definition techniques, EasyWinWin and C2. We leverage that experience to demonstrate the CBSP method and tool support using a large-scale example that highlights the transition from an EasyWinWin requirements negotiation into a C2-style architectural model.

Software development is a constant endeavor to optimize qualities like performance and robustness while ensuring functional correctness. Architecture Description Languages (ADLs) form a foundation for modeling and analyzing functional and non-functional properties of software systems, but, short of programming, only the simulation of those models can ensure certain desired qualities and functionalities. The paper presents an adaptation to statechart simulation, as pioneered by D. Harel (1987). This extension supports architectural dynamism: the creation, replacement, and destruction of components. We distinguish between design-time dynamism, where system dynamics are statically proscribed (e.g., creation of a predefined component class in response to a trigger), and run-time dynamism, where the system is modified while it is running (e.g., replacement of a faulty component without shutting down the system). Our enhanced simulation language, with over 100 commands, is tool-supported.

When dealing with object-oriented models like class and object diagrams, designers easily get overwhelmed by large numbers of model elements and their interdependencies. To deal with the complexities of large-scale software models, this paper presents rules and methods for automated abstraction. Our approach is tool supported and allows designers to periodically "zoom out" of a model to investigate and reason about its bigger picture. Our technique has also proven to be well-suited for consistency checking and reverse engineering.

A major emphasis in software development is placed on identifying and reconciling architectural and design mismatches. These mismatches happen during software development on two levels: while composing system components (e.g. COTS or in-house developed) and while reconciling view perspectives. Composing components into a system and 'composing' views (e.g. diagrams) into a system model are often seen as being somewhat distinct aspects of software development. However, as this paper shows, their approaches in detecting mismatches complement each other very well. In both cases, the composition process may result in mismatches that are caused by clashes between development artefacts. Our component-based integration approach is more high-level and can be used early on for risk assessment while little information is available. Model-based integration, on the other hand needs more information to start with but is more precise and can handle large amounts of redundant information. This paper describes both integration approaches and discusses their commonalities and differences. Both integration approaches are automatable, and some tool support is already available.

Negotiating requirements is one of the first steps in any software system life cycle, but its results have probably the most significant impact on the system's value. However, the processes of requirements negotiation are not well understood. We have had the opportunity to capture and analyze requirements negotiation behavior for groups of projects developing library multimedia archive systems, using an instrumented version of the USC WinWin groupware system for requirements negotiation. Some of the more illuminating results were: most stakeholder Win Conditions were noncontroversial (were not involved in issues); negotiation activity varied by stakeholder role; LCO package quality (measured by grading criteria) could be predicted by negotiation attributes; and WinWin increased cooperativeness, reduced friction, and helped focus on key issues.