Effects of stability on model composition effort: an exploratory study

Model composition plays a central role in many software engineering activities, e.g., evolving design models to add new features. To support these activities, developers usually rely on model composition heuristics. The problem is that the models to-be-composed usually conflict with each other in several ways and such composition heuristics might be unable to properly deal with all emerging conflicts. Hence, the composed model may bear some syntactic and semantic inconsistencies that should be resolved. As a result, the production of the intended model is an error-prone and effort-consuming task. It is often the case that developers end up examining all parts of the output composed model instead of prioritizing the most critical ones, i.e., those that are likely to be inconsistent with the intended model. Unfortunately, little is known about indicators that help developers (1) to identify which model is more likely to exhibit inconsistencies, and (2) to understand which composed models require more effort to be invested. It is often claimed that software systems remaining stable over time tends to have a lower number of defects and require less effort to be fixed than unstable systems. However, little is known about the effects of software stability in the context of model evolution when supported by composition heuristics. This paper, therefore, presents an exploratory study analyzing stability as an indicator of inconsistency rate and resolution effort on model composition activities. Our findings are derived from 180 compositions performed to evolve design models of three software product lines. Our initial results, supported by statistical tests, also indicate which types of changes led to lower inconsistency rate and lower resolution effort.     

Refining code ownership with synchronous changes

When mining software repositories, two distinct sources of information are usually explored: the history log and snapshots of the system. Results of analyses derived from these two sources are biased by the frequency with which developers commit their changes. We argue that the usage of mainstream SCM (software configuration management) systems influences the way that developers work. For example, since it is tedious to resolve conflicts due to parallel commits, developers tend to minimize conflicts by not contemporarily modifying the same file. This however defeats one of the purposes of such systems. We mine repositories created by our tool Syde, which records changes in a central repository whenever a file is compiled locally in the IDE (integrated development environment) by any developer in a multi-developer project. This new source of information can augment the accuracy of analyses and breaks new ground in terms of how such information can assist developers. We illustrate how the information we mine provides a refined notion of code ownership with respect to the one inferred by SCM system data. We demonstrate our approach on three case studies, including an industrial one. Ownership models suffer from the assumption that developers have a perfect memory. To account for their imperfect memory, we integrate into our ownership measurement a model of memory retention, to simulate the effect of memory loss over time. We evaluate the characteristics of this model for several strengths of memory.     

An empirically-based characterization and quantification of information seeking through mailing lists during Open Source developers’ software evolution

ContextSeveral authors have proposed information seeking as an appropriate perspective for studying software evolution. Empirical evidence in this area suggests that substantial time delays can accrue, due to the unavailability of required information, particularly when this information must travel across geographically distributed sites.ObjectiveAs a first step in addressing the time delays that can occur in information seeking for distributed Open Source (OS) programmers during software evolution, this research characterizes the information seeking of OS developers through their mailing lists.MethodA longitudinal study that analyses 17 years of developer mailing list activity in total, over 6 different OS projects is performed, identifying the prevalent information types sought by developers, from a qualitative, grounded analysis of this data. Quantitative analysis of the number-of-responses and response time-lag is also performed.ResultsThe analysis shows that Open Source developers are particularly implementation centric and team focused in their use of mailing lists, mirroring similar findings that have been reported in the literature. However novel findings include the suggestion that OS developers often require support regarding the technology they use during development, that they refer to documentation fairly frequently and that they seek implementation-oriented specifics based on system design principles that they anticipate in advance. In addition, response analysis suggests a large variability in the response rates for different types of questions, and particularly that participants have difficulty ascertaining information on other developer’s activities.ConclusionThe findings provide insights for those interested in supporting the information needs of OS developer communities: They suggest that the tools and techniques developed in support of co-located developers should be largely mirrored for these communities: that they should be implementation centric, and directed at illustrating “how” the system achieves its functional goals and states. Likewise they should be directed at determining the reason for system bugs: a type of question frequently posed by OS developers but less frequently responded to.     

Inconsistency management for multiple-view software developmentenvironments

Developers need tool support to help manage the wide range of inconsistencies that occur during software development. Such tools need to provide developers with ways to define, detect, record, present, interact with, monitor and resolve complex inconsistencies between different views of software artifacts, different developers and different phases of software development. This paper describes our experience with building complex multiple-view software development tools that support diverse inconsistency management facilities. We describe software architectures that we have developed and user interface techniques that are used in our multiple-view development tools, and we discuss the effectiveness of our approaches compared to other architectural and HCI techniques     

Architecture‐driven assistance for fault‐localization tasks

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.     

Facilitating collaboration in lecture‐based learning through shared notes using wireless technologies

This paper reports a case study for developing lecture teaching in higher education by connecting simultaneously the benefits of face‐to‐face teaching and social software for capturing and sharing students' lecture notes. The study was conducted with 12 university students taking a degree course on pre‐primary education. Data were collected on (1) the nature of the shared lecture notes produced by the students; and (2) their experiences in creating and sharing lecture notes. Students wrote 367 notes in eight lecture sessions. Discourse analysis revealed five types of notes: reproducing lecture content; summarizing lecture content; connecting key concepts; developing lecture content; questions arising from lecture content. Content analysis revealed those aspects of the lectures developed through the shared notes. Discussions with four students at the end of the course explored their experiences of using the shared notes. The results are discussed in the context of changes to the cultural ecology of learning.     

An in-depth study of the promises and perils of mining GitHub

With over 10 million git repositories, GitHub is becoming one of the most important sources of software artifacts on the Internet. Researchers mine the information stored in GitHub’s event logs to understand how its users employ the site to collaborate on software, but so far there have been no studies describing the quality and properties of the available GitHub data. We document the results of an empirical study aimed at understanding the characteristics of the repositories and users in GitHub; we see how users take advantage of GitHub’s main features and how their activity is tracked on GitHub and related datasets to point out misalignment between the real and mined data. Our results indicate that while GitHub is a rich source of data on software development, mining GitHub for research purposes should take various potential perils into consideration. For example, we show that the majority of the projects are personal and inactive, and that almost 40 % of all pull requests do not appear as merged even though they were. Also, approximately half of GitHub’s registered users do not have public activity, while the activity of GitHub users in repositories is not always easy to pinpoint. We use our identified perils to see if they can pose validity threats; we review selected papers from the MSR 2014 Mining Challenge and see if there are potential impacts to consider. We provide a set of recommendations for software engineering researchers on how to approach the data in GitHub.     

Replaying development history to assess the effectiveness of change propagation tools

As developers modify software entities such as functions or variables to introduce new features, enhance old ones, or fix bugs, they must ensure that other entities in the software system are updated to be consistent with these new changes. Many hard to find bugs are introduced by developers who did not notice dependencies between entities, and failed to propagate changes correctly. Most modern development environments offer tools to assist developers in propagating changes. For example, dependency browsers show static code dependencies between source code entities. Other sources of information such as historical co-change or code layout information could be used by tools to support developers in propagating changes. We present the Development Replay (DR) approach which empirically assess and compares the effectiveness of several not-yet-existing change propagation tools by reenacting the changes stored in source control repositories using these tools. We present a case study of five large open source systems with a total of over 40 years of development history. Our empirical results show that historical co-change information recovered from source control repositories along with code layout information can guide developers in propagating changes better than simple static dependency information.

A methodology to infer and refactor an object‐oriented model from C applications

When analyzing legacy code, generating a high‐level model of an application during the reverse engineering process helps the developers understand how the application is structured and how the dependencies relate the different software entities. Within the context of procedural programming languages (such as C), the existing approaches to get a model of the code require documentation and/or implicit knowledge that stakeholders acquire during the software building. These approaches use the code itself to build a syntactic model where we see the different software artifacts, such as variables, functions, and modules. However, there is no supporting methodology to detect and analyze if there are relationships/dependencies between those artifacts, such as which variable in a module is declared using an abstract data type described in another one, or which are the functions that are using parameters typed with an abstract data type; or any design decision taken by original developers, such as how the developer has implemented functions in different modules. On the other hand, current developers use object‐oriented (OO) paradigm to implement not only business applications but also useful methodologies/tools that allow semiautomatic analysis of any application. We must remark the legacy procedural code still has worth and is working in several industries, and as any evolving code, the developers have to be able to perform maintenance tasks minimizing the limitations offered by the language. Based on useful properties that the OO paradigm (and their supporting analysis tools) provide, such as UML models, we propose M2K as a methodology to generate a high‐level model from legacy procedural code, mainly written in Ansi C. To understand how C‐based applications were implemented is not a new problem in software reengineering. However, our contribution is based on building an OO model and suggesting different refactorings that help the developer to improve it and to eventually guide a new implementation of the target application. Specifically, the methodology builds cohesive software entities mapped from procedural code and makes the coupling between C entities explicit in the high‐level model. The result of our methodology is a set of refactored class candidates: a structure that groups a set of variables and a set of functions obtained from the C applications. Based on the class candidate model, we propose refactorings based on OO design principles to improve the design of the application. The most relevant design improvements were obtained with algorithm abstraction by applying the strategy pattern, attributes/methods relocalization, variables types generalization, and removing/renaming methods/attributes. Besides a methodology and the supporting tool, we provide 14 case studies based on real projects implemented in C, and we showed how the results validate our proposal.     

Privacy and security constraints for code contributions

In collaborative software development, developers submit their contributions to repositories that are used to integrate code from various collaborators. To avoid privacy and security issues, code contributions are often reviewed before integration. Although careful manual code review can detect such issues, it might be time-consuming, expensive, and error-prone. Automatic analysis tools can also detect privacy and security issues, but they often demand significant developer effort, or are domain specific, considering fixed framework specific vulnerability sources and sinks. To reduce these problems, in this paper we propose the Salvum policy language to support the specification of constraints that help to protect sensitive information from being inadvertently accessed by specific code contributions. We implement a tool that automatically checks Salvum policies for systems of different technical domains. We also investigate whether Salvum can find policy violations for a number of open-source projects. We find evidence that Salvum helps to detect violations even for well-supported and highly active projects. Moreover, our tool helps to find 80 violations in benchmark projects.     

The Third Design Space: A postcolonial perspective on corporate engagement with open source software communities

Corporations increasingly engage with open source software communities in the co‐creation of software. This collaboration between corporate professionals and open source software community members is strikingly different from the early days of software development where for‐profit firms attempted to dominate and control the industry while attempting to throttle the success of independent developers offering an alternative, open source option. While many metaphors like trading zones, common pool resources and ecosystems have helped understand the phenomenon, the metaphors do not portray what the industry was like before and after the transition. We adopt a postcolonial metaphor as an analytical lens to examine such collaboration based on qualitative data gathered over three years from executives, managers and developers within corporations that engage in open source software development. Drawing on these insights, we then theorize a “Third Design Space,” based on the concept of the third space proposed by Bhabha. This metaphor encourages the cultivation of a new design environment, creation of new design associations and circulation of shared design resources. Together these practices and behaviours make it possible to nurture innovative methods and new rituals for designing software with results and methods that represent a distinct departure from the competitive and proprietary past, even creating innovative artefacts that could not have been created without the Third Design Space.     

开源软件缺陷的跨项目相关问题推荐方法

GitHub是著名的开源软件开发社区,支持开发人员在开源项目中使用问题追踪系统来处理问题.在软件缺陷问题的讨论过程中,开发人员可能指出与该缺陷问题相关的其他项目问题(称为跨项目相关问题),为缺陷问题的修复提供参考信息.然而, GitHub平台中托管了超过2亿的开源项目和12亿个问题,导致人工识别和获取跨项目相关问题的工作极其耗时.提出为缺陷问题自动化推荐跨项目相关问题的方法 CPIRecom.为了构建预选集,采用项目之间历史相关问题对的数量和问题发布时间间隔筛选问题.其次,为了精准推荐,采用BERT预训练模型提取文本特征,分析项目特征.然后使用随机森林算法计算预选问题与缺陷问题的相关概率,最终根据相关概率排名得到推荐列表.模拟CPIRecom方法在GitHub平台的使用情况. CPIRecom方法的平均倒数排名达到0.603,前5项查全率达到0.715.     

GitHub开源软件开发过程中影响因素的相关性分析

截至到目前为止,在GitHub开源软件托管平台上面的项目超过1200万,现有很多研究对GitHub开源软件的开发过程中的影响因素进行了分析,缺乏对影响因素间的相关性进行研究.本文通过分析GitHub开源软件的开发过程,提出了问题解决速度、问题增加速度等影响因素,并对这些影响因素间的相关性进行了分析.经过实验证明了有些影响因素之间存在一定的相关性.同时根据实验的结果还给出了针对GitHub开源软件开发过程的一些建议.     

一种面向缺陷检测过程的警报自动确认方法

静态分析工具能够一定程度上帮助开发者检测代码中的重要错误;然而,可扩展性和不可判定性的存在会影响这些工具的准确率,导致它们无法被用于更广泛的实践中;最近,研究人员开始利用人工智能的技术来提高这些工具的可使用性,通过将正确和错误的警报自动分类,以节省在软件开发过程中人工确认警报所需要的人力和时间的花费;传统的方法主要通过使用手工提取的特征来表示有缺陷的代码片段,难以抓住它们深层次的语义信息;为了克服传统方法的限制,设计并提出了一种创新的特征提取方法,通过收集并提取缺陷模式状态机实例状态转换过程中相关指令集所包含的细粒度的语法、语义信息,并将有效的深度学习框架与之相结合,从而实现跨工程的警报自动确认;在5个开源工程的警报数据集上实验,分别与基于传统度量元的自动确认方法比较,AUC指标提升幅度在1.83%～31.81%之间,表明该方法能够有效提升跨工程警报自动确认的表现。     

语义和句法依赖增强的跨度级方面情感三元组抽取

本研究针对目前跨度级别的方面情感三元组抽取模型忽视词性和句法知识的问题且存在三元组冲突的情况, 提出了语义和句法依赖增强的跨度级方面情感三元组抽取模型SSES-SPAN (semantic and syntactic enhanced span-based aspect sentiment triplet extraction). 首先, 在特征编码器中引入词性知识和句法依赖知识, 使模型能够更精准地区分文本中的方面词和观点词, 并且更深入地理解它们之间的关系. 具体而言, 对于词性信息, 采用了一种加权求和的方法, 将词性上下文表示与句子上下文表示融合得到语义增强表示, 以帮助模型准确提取方面词和观点词. 对于句法依赖信息, 采用注意力机制引导的图卷积网络捕捉句法依赖特征得到句法依赖增强表示, 以处理方面词和观点词之间的复杂关系. 此外, 鉴于跨度级别的输入缺乏互斥性的保证, 采用推理策略以消除冲突三元组. 在基准数据集上进行的大量实验表明, 我们提出的模型在效果和鲁棒性方面超过了最先进的方法.     

开源软件社区知识协作网络核心开发者识别

开源软件社区中开发者是流动的,有效识别出核心开发者并对其采取保护措施能够更好地促进社区集体智慧涌现.以开源软件项目AngularJS为例,通过获取开发者在GitHub上的提交记录,抽取开发者协作关系构建知识协作网络,运用社会网络分析的方法,在原有度中心性和介数中心性指标的基础上,将开发者节点的社团结构考虑进来提出新的评价指标.采用TOPSIS多属性决策方法进行核心开发者识别.仿真模拟核心开发者的流失,探究识别效果.研究发现:考虑社团结构的指标和以往指标识别出的核心开发者具有较大的相似性,和真实名单对比均具有一定的准确性,但在重要性排序上考虑社团结构的指标体系识别效果更显著.     

Why and how developers fork what from whom in GitHub

Forking is the creation of a new software repository by copying another repository. Though forking is controversial in traditional open source software (OSS) community, it is encouraged and is a built-in feature in GitHub. Developers freely fork repositories, use codes as their own and make changes. A deep understanding of repository forking can provide important insights for OSS community and GitHub. In this paper, we explore why and how developers fork what from whom in GitHub. We collect a dataset containing 236,344 developers and 1,841,324 forks. We make surveys, and analyze programming languages and owners of forked repositories. Our main observations are: (1) Developers fork repositories to submit pull requests, fix bugs, add new features and keep copies etc. Developers find repositories to fork from various sources: search engines, external sites (e.g., Twitter, Reddit), social relationships, etc. More than 42 % of developers that we have surveyed agree that an automated recommendation tool is useful to help them pick repositories to fork, while more than 44.4 % of developers do not value a recommendation tool. Developers care about repository owners when they fork repositories. (2) A repository written in a developer’s preferred programming language is more likely to be forked. (3) Developers mostly fork repositories from creators. In comparison with unattractive repository owners, attractive repository owners have higher percentage of organizations, more followers and earlier registration in GitHub. Our results show that forking is mainly used for making contributions of original repositories, and it is beneficial for OSS community. Moreover, our results show the value of recommendation and provide important insights for GitHub to recommend repositories.     

Perceived barriers to effective knowledge sharing in agile software teams

While the literature offers several frameworks that explain barriers to knowledge sharing within software development teams, little is known about differences in how team members perceive these barriers. Based on an in‐depth multi‐case study of four software projects, we investigate how project managers, developers, testers and user representatives think about barriers to effective knowledge sharing in agile development. Adapting comparative causal mapping, we constructed causal maps for each of the four roles and identified overlap and divergence in map constructs and causal linkages. The results indicate that despite certain similarities, the four roles differ in how they perceive and emphasize knowledge‐sharing barriers. The project managers put primary emphasis on project setting barriers, while the primary concern of developers, testers and user representatives were project communication, project organization and team capabilities barriers, respectively. Integrating the four causal maps and the agile literature, we propose a conceptual framework with seven types of knowledge‐sharing barriers and 37 specific barriers. We argue that to bridge communication gaps and create shared understanding in software teams, it is critical to take the revealed concerns of different roles into account. We conclude by discussing our findings in relation to knowledge sharing in agile teams and software teams more generally.     

Structurally-Enhanced Approach for Automatic Code Transformation

In software development, developers often need to change or update lost of similar codes. How to perform code transformation automatically has become a research hotspot in software engineering. An effective way is extracting the modification pattern from a set of similar code changes and applying it to automatic code transformation. In the related work, deep-learning-based approaches have achieved much progress, but they suffer from the problem of significant long-term dependency between the code. To address this challenge, an automatic code transformation method is proposed, namely ExpTrans. Based on the graph-based representations of code changes, ExpTrans is enhanced with the structural information of code. It labels the dependency between variables in code parsing and adopts the graph convolutional network and Transformer structure to capture the long-term dependency between the code. ExpTrans is first compared with existing learning-based approaches to evaluate its effectiveness; the results show that ExpTrans gains 11.8%--30.8% precision increment. Then, it is compared with rule-based approaches and the results demonstrate that ExpTrans significantly improves the correct rate of the modified instances.