Assisting and automating software engineering tasks is a state-of-the-art way to support stakeholders of development projects. A common assistance function of IDEs is the auto-completion of source code. Assistance functions, such as auto-completion, are almost entirely missing in modeling tools though auto-completion in general gains continuously more importance in software development. We analyze a user’s performed editing operations in order to anticipate modeling activities and to recommend appropriate auto-completions for them. Editing operations are captured as events and modeling activities are defined as complex event patterns, facilitating the matching by complex-event-processing. The approach provides adapted auto-completions reactively upon each editing operation of the user. We implemented theRapMODprototype as add-in for the modeling tool Sparx Enterprise Architect™ . A controlled user experiment with 37 participants performing modeling tasks demonstrated the approach’s potential to reduce modeling effort significantly. Users having auto-completions available for a modeling scenario performed the task 27 percent faster, needed to perform 56 percent less actions, and perceived the task 29 percent less difficult.

Many guidelines for safety-critical industries such as aeronautics, medical devices, and railway communications, specify that traceability must be used to demonstrate that a rigorous process has been followed and to provide evidence that the system is safe for use. In practice, there is a gap between what is prescribed by guidelines and what is implemented in practice, making it difficult for organizations and certifiers to fully evaluate the safety of the software system. In this paper we present an approach, which parses a guideline to extract a Traceability Model depicting software artifact types and their prescribed traces. It then analyzes the traceability data within a project to identify areas of traceability failure. Missing traceability paths, redundant and/or inconsistent data, and other problems are highlighted. We used our approach to evaluate the traceability of seven safety-critical software systems and found that none of the evaluated projects contained traceability that fully conformed to its relevant guidelines.

Auto-completion of textual inputs when using IDEs benefits software development experts and novices. Researchers demonstrated that auto-completion is beneficial for graphical modeling tasks as well. However, supporting software development by auto-completing UML modeling activities remains largely unexplored by research and unsupported by modeling tools. By matching editing operations to activity patterns, partly performed modeling activities can be recognized and automatically completed. This paper proposes an approach that computes auto-completions for partly performed modeling activities while a developer is creating or evolving UML models. Selected auto-completions can be previewed and adjusted before being executed. We claim, that this approach can improve developers' modeling efficiency. Therefore, we assessed our approach based on a catalog of common modeling activities for structural UML models and found that effort for conducting defined modeling activities can be reduced significantly.

Effective requirements traceability supports practitioners in reaching higher project maturity and better product quality. Researchers argue that effective traceability barely happens by chance or through ad-hoc efforts and that traceability should be explicitly defined upfront. However, in a previous study we found that practitioners rarely follow explicit traceability strategies. We were interested in the reason for this discrepancy. Are practitioners able to reach effective traceability without an explicit definition? More specifically, how suitable is requirements traceability that is not strategically planned in supporting a project's development process. Our interview study involved practitioners from 17 companies. These practitioners were familiar with the development process, the existing traceability and the goals of the project they reported about. For each project, we first modeled a traceability strategy based on the gathered information. Second, we examined and modeled the applied software engineering processes of each project. Thereby, we focused on executed tasks, involved actors, and pursued goals. Finally, we analyzed the quality and suitability of a project's traceability strategy. We report common problems across the analyzed traceability strategies and their possible causes. The overall quality and mismatch of analyzed traceability suggests that an upfront-defined traceability strategy is indeed required. Furthermore, we show that the decision for or against traceability relations between artifacts requires a detailed understanding of the project's engineering process and goals; emphasizing the need for a goal-oriented procedure to assess existing and define new traceability strategies.

traceMaintainer is a tool that maintains post-requirements traceability amongst the elements of structural UML models. The maintenance of traceability relations is based upon predefined rules. Each rule recognizes a development activity applied to a model element. traceMaintainer carries out associated traceability updates in the background after an activity has been completed, requiring minimal manual effort and limited interaction with the developer. Currently, traceMaintainer can be used with two commercial software development (CASE) tools to update the traceability relations stored within them, while the underlying approach extends further to maintaining traceability within a heterogeneous and distributed environment of tools.