Free and open source software (FOSS) plays an important role in source code reuse practice. They usually come with one or more software licenses written in the header part of source files, stating ...the requirements and conditions which should be followed when been reused. Removing or modifying the license statement by re-distributors will result in the inconsistency of license with its ancestor, and may potentially cause license infringement. In this paper, we describe and categorize different types of license inconsistencies and propose a method to detect them. Then we applied this method to Debian 7.5 and a collection of 10,514 Java projects on GitHub and present the license inconsistency cases found in these systems. With a manual analysis, we summarized various reasons behind these license inconsistency cases, some of which imply potential license infringement and require attention from the developers. This analysis also exposes the difficulty to discover license infringements, highlighting the usefulness of finding and maintaining source code provenance.
Defects in spacecraft software may result in loss of life and serious economic damage. To avoid such consequences, the software development process incorporates code review activity. A code review ...conducted by a third-party organization independently of a software development team can effectively identify defects in software. However, such review activity is difficult for third-party reviewers, because they need to understand the entire structure of the code within a limited time and without prior knowledge. In this study, we propose a tool to visualize inter-module dataflow for source code of spacecraft software systems. To evaluate the method, an autonomous rover control program was reviewed using this visualization. While the tool does not decreases the time required for a code review, the reviewers considered the visualization to be effective for reviewing code.
Once a software product has been released, a large number of software products may be derived from an original single product. Management and maintenance of product variants are important, but those ...are hardly cared because developers do not make efforts for the further maintainability in the initial phase of software development. However, history of products would be lost in typical cases and developers have only source code of products in the worst case. In this paper, we approximate the evolution history of software products using source code of them. Our key idea is that two successive products are the most similar pair of products in evolution history, and have many similar source files. We did an experiment to compare the analysis result with actual evolution history. The result shows 78% (on average) of edges in the extracted trees are consistent with the actual evolution history of the products.
It is not always easy for an Android user to choose the most suitable application for a particular task from the great number of applications available. In this paper, we propose a semi-automatic ...approach to extract feature names from Android applications. The case study verifies that we can associate common sequences of Android API calls with feature names.
Debugging is an important task to identify the defects in the software. Especially, logging is an important feature of a software system to record runtime information. Detailed logging allows ...developers to collect run-time information when they cannot use an interactive debugger, such as continuous integration and web application server cases. However, extensive logging leads to larger execution traces because few instructions can be repeated many times. In our previous work, to record detailed program behavior within limited storage space constraints, we proposed near-omniscient debugging, which is a methodology that records and visualizes an execution trace using fixed size buffers for each observed instruction. In this paper, we evaluate the effectiveness of near-omniscient debugging in recording infected states while reducing the size of execution traces. We conduct experiments on the Defects4J dataset and evaluate the effectiveness based on the completeness, trace size and runtime overhead. The result shows that near-omniscient debugging can completely record infected states for nearly 80 percent of bugs (with a buffer size of 1024 events). The size of execution traces can be reduced by a factor of one thousand for large repetitive executions.
•Effectiveness evaluation of near-omniscient debugging with 831 actual bugs.•Keeping the majority of infected states.•Predictable trace size from the number of methods.•Reducing execution time significantly when all tests are executed.
•Detailed logging leads to larger execution traces.•Proposed method records a compact execution trace using fixed size buffers.•The execution trace is compact but keeps data dependency.•Debugging ...actual defects is possible on a HTML-based viewer.
Logging is an important feature of a software system to record run-time information. Detailed logging allows developers to collect run-time information in situations where they cannot use an interactive debugger, such as continuous integration and web application server cases. However, extensive logging leads to larger execution traces because few instructions can be repeated many times. This paper presents our tool NOD4J, which monitors a Java program's execution within limited storage space constraints and annotates the source code with observed values in an HTML format. Developers can easily investigate the execution and share the report on a web server. We show two examples that our tool can debug defects using incomplete execution traces.
PDF
