Search

End-user programming may utilize Domain-Specific Modeling Languages (DSMLs) to develop applications in the form of models, using only abstractions found in a specific problem domain. Indeed, the productivity benefits reported from Model-Driven Development (MDD) are hard to ignore, and a number of MDD solutions are flourishing. However, not all stories from industry on MDD are successful. End-users, without having software development skills, are more likely to introduce software errors than professional programmers. In this study, we propose and encourage other DSML developers to extend the development of DSML with tool support. We believe the programming tools (e.g., debugger, testing tool, refactoring tool) are also needed for end-users to ensure the proper functioning of the products they develop. It is imperative that domain experts are provided with tools that work on the abstraction level that is familiar to them. In this paper, an industrial experience is presented for building various tools for usage in MDD. Debugger, automated testing infrastructure, refactoring, and other tools were implemented for Sequencer, a DSML. Our experience with the implementation of tool support for MDD confirms that these tools are indispensable for end-user programming in practice, and that implementing those tools might not be as costly as expected.

A code smell is a symptom in the source code that helps to identify a design problem. Several tools for detecting and ranking code smells according to their criticality to the system have been developed. However, existing works assume a centralized development approach, which does not consider systems being developed in a distributed fashion. The main problem in a distributed group of developers is that a tool cannot always ensure a global vision of (smells of) the system, and thus inconsistencies among the rankings provided by each developer are likely to happen. These inconsistencies often cause unnecessary refactorings and might not focus the whole team on the critical smells system-wide. Along this line, this work proposes a multi-agent tool, called D-JSpIRIT, which helps individual developers to reach a consensus on their smell rankings by means of distributed optimization techniques. [ABSTRACT FROM PUBLISHER]

Context: Non-trivial software systems are written using multiple (programming) languages, which are connected by cross-language links. The existence of such links may lead to various problems during software development. There is little empirical evidence on the incidence of these problems and the experiences of professional developers in this field. Aim: We want to provide empirical evidence on multi-language software development, cross-language linking, and tool support in industry, including the views of professional developers on benefits and problems in these areas. Methods: We conducted a survey study to gather responses from 139 professional software developers. Results: Respondents reported an average of 7 languages and 3 linked language pairs per project. Respondents saw benefits of multi-language development for the motivation of developers and the translation of requirements, but problems in understandability and changeability. Over 90% of respondents reported problems related to cross-language linking. Developers universally agree on the usefulness of tool support. Conclusions: Multi-language programming and cross-language linking seem common but lead to several problems. We suggest that future practical as well as research efforts focus on these issues by creating appropriate tool support and by developing better techniques for cross-language linking for improved changeability and understandability. [ABSTRACT FROM AUTHOR]

The need for high-performance computing together with the increasing trend from single processor to parallel computer architectures has leveraged the adoption of parallel computing. To benefit from parallel computing power, usually parallel algorithms are defined that can be mapped and executed on parallel computing platforms. In general, different alternative mappings can be defined each with different performance. For small computing platforms with a limited number of processing nodes, the mapping process can be carried out manually. However, for large-scale parallel computing platforms in which hundreds of thousands of processing nodes are applied, the number of possible mapping alternatives increases dramatically, and the mapping process becomes intractable for the human engineer. To assist the parallel computing engineer, we provide a systematic approach to derive feasible mapping alternatives of parallel algorithms to parallel computing platforms. The approach includes activities for modeling the parallel algorithm and parallel computing platform, generation of feasible mapping alternatives, generation of the deployment code, and finally the deployment of the generated code to the nodes. We evaluate our approach for deriving feasible mapping alternatives for four well-known parallel algorithms. The evaluation is based on both simulations and real executions of the generated mapping alternatives. Copyright © 2016 John Wiley & Sons, Ltd. [ABSTRACT FROM AUTHOR]

The state-based formal methods B and TLA + share the common base of predicate logic, arithmetic and set theory. However, there are still considerable differences, such as the way to specify state transitions, the different approaches to typing, and the available tool support. In this paper, we present a translation from B to TLA + so as to validate B specifications using the model checker TLC . The translation includes many adaptations and optimizations to allow for efficient checking by TLC . Moreover, we present a way to validate liveness properties for B specifications under fairness conditions. Our implemented translator, Tlc4B , automatically translates a B specification to TLA + , invokes the model checker TLC , and translates the results back to B. We use ProB to double check the counter examples produced by TLC and replay them in the ProB animator. Tlc4B can also transmit constant values, precalculated by ProB , to TLC . This allows the user to combine the strength of both tools, i.e. ProB 's constraint solving abilities and TLC 's highly tuned model checking core. Furthermore, we demonstrate an approach to optimize the model checking process by encoding proof information in the translated TLA + specification. We also present a series of case studies and benchmark tests comparing Tlc4B and ProB . [ABSTRACT FROM AUTHOR]

Textual requirements are very common in software projects. However, this format of requirements often keeps relevant concerns (e.g., performance, synchronization, data access, etc.) from the analyst's view because their semantics are implicit in the text. Thus, analysts must carefully review requirements documents in order to identify key concerns and their effects. Concern mining tools based on NLP techniques can help in this activity. Nonetheless, existing tools cannot always detect all the crosscutting effects of a given concern on different requirements sections, as this detection requires a semantic analysis of the text. In this work, we describe an automated tool called REAssistant that supports the extraction of semantic information from textual use cases in order to reveal latent crosscutting concerns. To enable the analysis of use cases, we apply a tandem of advanced NLP techniques (e.g, dependency parsing, semantic role labeling, and domain actions) built on the UIMA framework, which generates different annotations for the use cases. Then, REAssistant allows analysts to query these annotations via concern-specific rules in order to identify all the effects of a given concern. The REAssistant tool has been evaluated with several case-studies, showing good results when compared to a manual identification of concerns and a third-party tool. In particular, the tool achieved a remarkable recall regarding the detection of crosscutting concern effects. [ABSTRACT FROM AUTHOR]

Some of the challenges faced by most software projects are tight budget constraints and schedules, which often make managers and developers prioritize the delivery of a functional product over other engineering activities, such as software documentation. In particular, having little or low-quality documentation of the software architecture of a system can have negative consequences for the project, as the architecture is the main container of the key design decisions to fulfill the stakeholders' goals. To further complicate this situation, generating and maintaining architectural documentation is a non-trivial and time-consuming activity. In this context, we present a tool approach that aims at (i) assisting the documentation writer in their tasks and (ii) ensuring a cost-effective documentation process by means of optimization techniques. Our tool, called SADHelper, follows the principle of producing reader-oriented documentation, in order to focus the available, and often limited, resources on generating just enough documentation that satisfies the stakeholders' concerns. The approach was evaluated in two experiments with users of software architecture documents, with encouraging results. These results show evidence that our tool can be useful to reduce the documentation costs and even improve the documentation quality, as perceived by their stakeholders. Copyright © 2015 John Wiley & Sons, Ltd. [ABSTRACT FROM AUTHOR]

Finding software faults is a problematic activity in many systems. Existing approaches usually work close to the system implementation and require developers to perform different code analyses. Although these approaches are effective, the amount of information to be managed by developers is often overwhelming. This problem calls for complementary approaches able to work at higher levels of abstraction than code, helping developers to keep intellectual control over the system when analyzing faults. In this context, we present an expert-system approach, called FLABot, which assists developers in fault-localization tasks by reasoning about faults using software architecture models. We have evaluated a prototype of FLABot in two medium-size case studies, involving novice and non-novice developers. We compared time consumed, code browsed and faults found by these developers, with and without the support of FLABot, observing interesting effort reductions when applying FLABot. The results and lessons learned have shown that our approach is practical and reduces the efforts for finding individual faults. [ABSTRACT FROM AUTHOR]