No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
Measuring the Superfluous Functionality in Software Components
Abstract
One of the drawbacks of a pragmatic, white box approach to the reuse of software is that reusable components often have more built-in functionality than is needed for a particular (re)usage scenario. This functionality either has to be invasively removed by changing the source code of the component, with the corresponding risk of errors, or has to be incorporated into a new project where it essentially pollutes the code base. While this may not be an immediate problem, over time such unneeded, polluting functionality can decrease the understandability of software and make it harder to maintain. The degree of superfluous functionality built into a component, when considered for a new use for which it was not initially intended, is therefore a useful metric which should be taken into account when choosing components to reuse. For example, it can be used as an input for a code search engine's ranking algorithm. In this paper we present a family of metrics for measuring the superfluous functionality within software components from the perspective of specific (re)use scenarios, describe how these metrics can be calculated, and investigate their utility as a differentiating measure to help developers choose which components to reuse.
... Bajracharya et al. 2006;Reiss 2009;Hummel 2008) primarily find and rank reuse candidates based on keyword and text-matching techniques adapted from the field of information retrieval (Manning et al. 2008). Desired quality criteria (e.g., indicated by software metrics) cannot be specified directly by the developer in the search process, and if they are supported at all, metrics are measured on the entire functionality provided by the candidate not just on the functionality the developer is specifically interested in using (Kessel and Atkinson 2015a). While numerous ranking approaches have been proposed, for example Inoue et al. (2005), Holmes et al. (2006), McMillan et al. (2011), Kessel and Atkinson (2015a), and Stolee et al. (2015), none is able to rank components using a combination of nonfunctional properties such as performance or maintenance (as measured, for example, by well-known quality characteristics/attributes defined by ISO/IEC 9126 (ISO/IEC 2001/2002 or its successor ISO/IEC 25010:2011 (ISO/IEC 2011)). ...
... Desired quality criteria (e.g., indicated by software metrics) cannot be specified directly by the developer in the search process, and if they are supported at all, metrics are measured on the entire functionality provided by the candidate not just on the functionality the developer is specifically interested in using (Kessel and Atkinson 2015a). While numerous ranking approaches have been proposed, for example Inoue et al. (2005), Holmes et al. (2006), McMillan et al. (2011), Kessel and Atkinson (2015a), and Stolee et al. (2015), none is able to rank components using a combination of nonfunctional properties such as performance or maintenance (as measured, for example, by well-known quality characteristics/attributes defined by ISO/IEC 9126 (ISO/IEC 2001/2002 or its successor ISO/IEC 25010:2011 (ISO/IEC 2011)). ...
... Since it basically only returns components that pass a test supplied by the user as a search query, test-driven search guarantees results of very high, and arguably perfect, precision depending on the quality of the test query. If the test is regarded as the definitive description of what functionality is required, as in test driven development (Beck 2003), then by definition test-driven searches have 100 percent precision (Hummel and Janjic 2013;Kessel and Atkinson 2015a). To our knowledge, only two test-driven search engine implementations have been described in the literature to date, Reiss' S6 (Reiss 2009) and merobase (Hummel 2008) with its IDE companion CodeConjurer . ...
One of the biggest obstacles to software reuse is the cost involved in evaluating the suitability of possible reusable components. In recent years, code search engines have made significant progress in establishing the semantic suitability of components for new usage scenarios, but the problem of ranking components according to their non-functional suitability has largely been neglected. The main difficulty is that a component’s non-functional suitability for a specific reuse scenario is usually influenced by multiple, “soft” criteria, but the relative weighting of metrics for these criteria is rarely known quantitatively. What is required, therefore, is an effective and reliable strategy for ranking software components based on their non-functional properties without requiring users to provide quantitative weighting information. In this paper we present a novel approach for achieving this based on the non-dominated sorting of components driven by a specification of the relative importance of non-functional properties as a partial ordering. After describing the ranking algorithm and its implementation in a component search engine, we provide an explorative study of its properties on a sample set of components harvested from Maven Central.
Pragmatic software reuse, in which existing software components are invasively adapted for use in new projects, involves three main activities andash; selection, adaptation and integration. Most of the academic research into pragmatic research to date has focused on the second of these activities, adaptation, especially the definition of reuse plans and verification of invasive changes, even though the selection activity is arguably the most important and effort-intensive of the three activities. There is therefore a great deal of scope for improving the level of support provided by software search engines and recommendation tools to pragmatic reusers of software components. Test-driven search engines are particularly promising in this regard since they possess the inherent ability to "evaluate" components from the perspective of users' reuse scenarios. In this paper we discuss some of the main issues involved in improving the selection support for pragmatic reuse provided by test-driven search engines, describe some new metrics that can help address these issues, and present the outline of an approach for ranking software components in search results.
A large amount of open source code is now available online, presenting a great potential resource for software developers. This has motivated software engineering researchers to develop tools and techniques to allow developers to reap the benefits of these billions of lines of source code. However, collecting and analyzing such a large quantity of source code presents a number of challenges. Although the current generation of open source code search engines provides access to the source code in an aggregated repository, they generally fail to take advantage of the rich structural information contained in the code they index. This makes them significantly less useful than Sourcerer for building state-of-the-art software engineering tools, as these tools often require access to both the structural and textual information available in source code.We have developed Sourcerer, an infrastructure for large-scale collection and analysis of open source code. By taking full advantage of the structural information extracted from source code in its repository, Sourcerer provides a foundation upon which state-of-the-art search engines and related tools can easily be built. We describe the Sourcerer infrastructure, present the applications that we have built on top of it, and discuss how existing tools could benefit from using Sourcerer.
BackgroundMany papers are published on the topic of software metrics but it is difficult to assess the current status of metrics research.AimThis paper aims to identify trends in influential software metrics papers and assess the possibility of using secondary studies to integrate research results.MethodSearch facilities in the SCOPUS tool were used to identify the most cited papers in the years 2000–2005 inclusive. Less cited papers were also selected from 2005. The selected papers were classified according factors such as to main topic, goal and type (empirical or theoretical or mixed). Papers classified as “Evaluation studies” were assessed to investigate the extent to which results could be synthesized.ResultsCompared with less cited papers, the most cited papers were more frequently journal papers, and empirical validation or data analysis studies. However, there were problems with some empirical validation studies. For example, they sometimes attempted to evaluate theoretically invalid metrics and fail to appreciate the importance of the context in which data are collected.ConclusionsThis paper, together with other similar papers, confirms that there is a large body of research related to software metrics. However, software metrics researchers may need to refine their empirical methodology before they can answer useful empirical questions.
Our goal is to use the vast repositories of avail- able open source code to generate specific functions or classes that meet a user's specifications. The key words here are specifications and generate. We let users specify what they are looking for as precisely as possible using keywords, class or method signatures, test cases, contracts, and security constraints. Our system then uses an open set of program transforma- tions to map retrieved code into what the user asked for. This approach is implemented in a prototype sys- tem for Java with a web interface. 1. Motivation
In order to perform meaningful experiments in optimizing compilation and run-time system design, researchers usually rely on a suite of benchmark programs of interest to the optimization technique under consideration. Programs are described as numeric, memory-intensive, concurrent, or object-oriented, based on a qualitative appraisal, in some cases with little justification. We believe it is beneficial to quantify the behaviour of programs with a concise and precisely defined set of metrics, in order to make these intuitive notions of program behaviour more concrete and subject to experimental validation. We therefore define and measure a set of unambiguous, dynamic, robust and architecture-independent metrics that can be used to categorize programs according to their dynamic behaviour in five areas: size, data structure, memory use, concurrency, and polymorphism. A framework computing some of these metrics for Java programs is presented along with specific results demonstrating how to use metric data to understand a program's behaviour, and both guide and evaluate compiler optimizations.
This paper describes an algorithm for slicing class hierarchies in C++ programs. Given a C++ class hierarchy (a collection of C++ classes and inheritance relations among them) and a program P that uses the hierarchy, the algorithm eliminates from the hierarchy those data members, member functions, classes, and inheritance relations that are unnecessary for ensuring that the semantics of P is maintained.Class slicing is especially useful when the program P is generated from a larger program P' by a statement slicing algorithm. Such an algorithm eliminates statements that are irrelevant to a set of slicing criteria---program points of particular interest. There has been considerable previous work on statement slicing, and it will not be the concern of this paper. However, the combination of statement slicing and class slicing for C++ has two principal applications: First, class slicing can enhance statement slicing's utility in program debugging and understanding applications, by eliminating both executable and declarative program components irrelevant to the slicing criteria. Second, the combination of the two slicing algorithms can be used to decrease the space requirements of programs that do not use all the components of a class hierarchy. Such a situation is particularly common in programs that use class libraries.
The software reuse strategies for improving software development efficiency and black box reuse with component markets is discussed. The broad reuse strategies includes white broad reuse, black box reuse with in house component development and black box reuse with component procured from the market place. It is observed that in choosing among the reuse strategies organizations are confronted with a trade-off between component acquistion costs and component customization costs. It is argued that component market could play an important role in making well written components available to developers and supply chains perform the dual role of market mediation and distribution.
A case is presented for the use of conventional and interface slicing as enabling mechanisms for numerous reverse engineering and reengineering tasks. The authors first discuss the applicability of conventional slicing to algorithm extraction and design recovery at statement-level granularity. They then present interface slicing and show how it provides similar capabilities at module-level granularity. Module is a general term for a collection of subprograms, possibly with information hiding mechanisms: It includes but is not limited to Ada packages. Component refers to a module in a reuse repository. A component is thus a code asset of a repository, possibly also incorporated into a program. Ada is used for the example, as Ada's features facilitate the types of transformations which are invoked
Accelerating the software development process by assembling new applications from existing software assets has been a goal of the IT industry for many years. However, most of today's systematic software reuse uses heavyweight approaches such as product-line engineering. Now, with the explosion in open source software repositories and the advent of a new generation of powerful software search engines, this is set to change. Code Conjurer is an Eclipse plug-in that extracts interface and test information from a developer's coding activities and uses this information to issue test-driven searches to a code-search engine. It presents components matching the developer's needs as reuse recommendations without disturbing the development work. Automated dependency resolution then allows selected components to be woven into the current project with minimal manual effort.
Construct validity is about the question, how we know that we're measuring the attribute that we think we're measuring? This is discussed in formal, theoretical ways in the computing literature (in terms of the representational theory of measurement) but rarely in simpler ways that foster application by practitioners. Construct validity starts with a thorough analysis of the construct, the attribute we are attempting to measure. In the IEEE Standard 1061, direct measures need not be validated. "Direct" measurement of an attribute involves a metric that depends only on the value of the attribute, but few or no software engineering attributes or tasks are so simple that measures of them can be direct. Thus, all metrics should be validated. The paper continues with a framework for evaluating proposed metrics, and applies it to two uses of bug counts. Bug counts capture only a small part of the meaning of the attributes they are being used to measure. Multidimensional analyses of attributes appear promising as a means of capturing the quality of the attribute in question. Analysis fragments run throughout the paper, illustrating the breakdown of an attribute or task of interest into sub-attributes for grouped study.
In recent years, searching for source code on the web has become increasingly common among professional software developers and is emerging as an area of academic research. This volume surveys past research and presents the state of the art in the area of "code retrieval on the web." This work is concerned with the algorithms, systems, and tools to allow programmers to search for source code on the web and the empirical studies of these inventions and practices. It is a label that we apply to a set of related research from software engineering, information retrieval, human-computer interaction, management, as well as commercial products. The division of code retrieval on the web into snippet remixing and component reuse is driven both by empirical data, and analysis of existing search engines and tools. Contributors include leading researchers from human-computer interaction, software engineering, programming languages, and management. "Finding Source Code on the Web for Remix and Reuse" consists of five parts. Part I is titled "Programmers and Practices," and consists of a retrospective chapter and two empirical studies on how programmers search the web for source code. Part II is titled "From Data Structures to Infrastructures," and covers the creation of ground-breaking search engines for code retrieval required ingenuity in the adaptation of existing technology and in the creation of new algorithms and data structures. Part III focuses on "Reuse: Components and Projects," which are reused with minimal modification. Part IV is on "Remix: Snippets and Answers," which examines how source code from the web can also be used as solutions to problems and answers to questions. The book concludes with Part V, "Looking Ahead," that looks at future programming and the legalities of software reuse and remix and the implications of current intellectual property law on the future of software development. The story, "Richie Boss: Private Investigator Manager," was selected as the winner of a crowdfunded short story contest." © Springer Science+Business Media New York 2013. All rights are reserved.
In this introductory chapter, we map out code retrieval on the web as a research area and the organizational of this book. Code retrieval on the web is concerned with the algorithms, systems, and tools to allow programmers to search for source code on the web and the empirical studies of these inventions and practices. It is a label that we apply to a set of related research from a software engineering, information retrieval, human-computer interaction, management, as well as commercial products. The division of code retrieval on the web into snippet remixing and component reuse is driven both by empirical data, and analysis of existing search engines and tools. © Springer Science+Business Media New York 2013. All rights are reserved.
The applicability of software reuse approaches in practice has long suffered from a lack of reusable material, but this situation has changed virtually over night: the rise of the open source movement has made millions of software artifacts available on the Internet. Suddenly, the existing (largely text-based) software search solutions did not suffer from a lack of reusable material anymore, but rather from a lack of precision as a query now might return thousands of potential results. In a reuse context, however, precisely matching results are the key for integrating reusable material into a given environment with as little effort as possible. Therefore a better way for formulating and executing queries is a core requirement for a broad application of software search and reuse. Inspired by the recent trend towards test-first software development approaches, we found test cases being a practical vehicle for reuse-driven software retrieval and developed a test-driven code search system utilizing simple unit tests as semantic descriptions of desired artifacts. In this chapter we describe our approach and present an evaluation that underlines its superior precision when it comes to retrieving reusable artifacts.
Traditional industrial practice often involves the ad hoc reuse of source code that was not designed for that reuse. Such pragmatic reuse tasks play an important role in disciplined software development. Pragmatic reuse has been seen as problematic due to a lack of systematic support, and an inability to validate that the reused code continues to operate correctly within the target system. Although recent work has successfully systematized support for pragmatic reuse tasks, the issue of validation remains unaddressed. In this paper, we present a novel approach and tool to semi‐automatically reuse and transform relevant portions of the test suite associated with pragmatically reused code, as a means to validate that the relevant constraints from the originating system continue to hold, while minimizing the burden on the developer. We conduct a formal experiment with experienced developers, to compare the application of our approach versus the use of a standard IDE (the ‘manual approach’). We find that, relative to the manual approach, our approach: reduces task completion time; improves instruction coverage by the reused test cases; and improves the correctness of the reused test cases. Copyright © 2012 John Wiley & Sons, Ltd.
Many software reuse tasks involve reusing source code that was not designed in a manner conducive to those tasks, requiring that ad hoc modifications be applied. Such pragmatic reuse tasks are a reality in disciplined industrial practice; they arise for a variety of organizational and technical reasons. To investigate a pragmatic reuse task, a developer must navigate through, and reason about, source code dependencies in order to identify program elements that are relevant to the task and to decide how those elements should be reused. The developer must then convert his mental model of the task into a set of actions that he can perform. These steps are poorly supported by modern development tools and practices.
We provide a model for the process involved in performing a pragmatic reuse task, including the need to capture (mentally or otherwise) the developer's decisions about how each program element should be treated: this is a pragmatic-reuse plan. We provide partial support for this model via a tool suite, called Gilligan; other parts of the model are supported via standard IDE tools. Using a pragmatic-reuse plan, Gilligan can semiautomatically transform the selected source code from its originating system and integrate it into the developer's system.
We have evaluated Gilligan through a series of case studies and experiments (each involving industrial developers) using a variety of source systems and tasks; we report in particular on a previously unpublished, formal experiment. The results show that pragmatic-reuse plans are a robust metaphor for capturing pragmatic reuse intent and that, relative to standard IDE tools, Gilligan can (1) significantly decrease the time that developers require to perform pragmatic reuse tasks, (2) increase the likelihood that developers will successfully complete pragmatic reuse tasks, (3) decrease the time required by developers to identify infeasible reuse tasks, and (4) improve developers' sense of their ability to manage the risk in such tasks.
Call graph construction for object-oriented programs is often difficult and expensive. Most sound and precise algorithms analyze the whole program including all library dependencies. The separate compilation assumption makes it possible to generate sound and reasonably precise call graphs without analyzing libraries. We investigate whether the separate compilation assumption can be encoded universally in Java bytecode, such that all existing whole-program analysis frameworks can easily take advantage of it. We present and evaluate Averroes, a tool that generates a placeholder library that overapproximates the possible behaviour of an original library. The placeholder library can be constructed quickly without analyzing the whole program, and is typically in the order of 80 kB of class files (comparatively, the Java standard library is 25 MB). Any existing whole-program call graph construction framework can use the placeholder library as a replacement for the actual libraries to efficiently construct a sound and precise application call graph. Averroes improves the analysis time of whole-program call graph construction by a factor of 4.3x to 12x, and reduces memory requirements by a factor of 8.4x to 13x. In addition, Averroes makes it easier for whole-program frameworks to handle reflection soundly in two ways: it is based on a conservative assumption about all behaviour within the library, including reflection, and it provides analyses and tools to model reflection in the application. The call graphs built with Averroes and existing whole-program frameworks are as precise and sound as those built with Cgc. While Cgc is a specific implementation of the separate compilation assumption in the Doop framework, Averroes is universal to all Java program analysis frameworks.
An account of new measure of coupling and cohesion developed to assess the reusability of Java components is proposed in this paper. These measures differ from the majority of established metrics in two respects: they reflect the degree to which entities are coupled or resemble each other, and they take account of indirect couplings or similarities. An empirical comparison of the new measures with eight established metrics is described. The new measures are shown to be consistently superior at measuring component reusability.
Software reengineering is a costly endeavor, due in part to the ambiguity of where to focus reengineering effort. Coupling and Cohesion metrics, particularly quantitative cohesion metrics, have the potential to aid in this identification and to measure progress. The most extensive work on such metrics is with slice-based cohesion metrics. While their use of semantic dependence information should make them an excellent choice for cohesion measurement, their wide spread use has been impeded in part by a lack of empirical study.
Recent advances in software tools make, for the first time, a large-scale empirical study of slice-based cohesion and coupling metrics possible. Four results from such a study are presented. First, “head-to-head” qualitative and quantitative comparisons of the metrics identify which metrics provide similar views of a program and which provide unique views of a program. This study includes statistical analysis showing that slice-based metrics are not proxies for simple size-based metrics such as lines of code. Second, two longitudinal studies show that slice-based metrics quantify the deterioration of a program as it ages. This serves to validate the metrics: the metrics quantify the degradation that exists during development; turning this around, the metrics can be used to measure the progress of a reengineering effort. Third, baseline values for slice-based metrics are provided. These values act as targets for reengineering efforts with modules having values outside the expected range being the most in need of attention. Finally, slice-based coupling is correlated and compared with slice-based cohesion.
Software reuse is the process of creating software systems from existing software rather than building software systems from scratch. This simple yet powerful vision was introduced in 1968. Software reuse has, however, failed to become a standard software engineering practice. In an attempt to understand why, researchers have renewed their interest in software reuse and in the obstacles to implementing it.
This paper surveys the different approaches to software reuse found in the research literature. It uses a taxonomy to describe and compare the different approaches and make generalizations about the field of software reuse. The taxonomy characterizes each reuse approach in terms of its reusable artifacts and the way these artifacts are abstracted, selected, specialized, and integrated .
Abstraction plays a central role in software reuse. Concise and expressive abstractions are essential if software artifacts are to be effectively reused. The effectiveness of a reuse technique can be evaluated in terms of cognitive distance —an intuitive gauge of the intellectual effort required to use the technique. Cognitive distance is reduced in two ways: (1) Higher level abstractions in a reuse technique reduce the effort required to go from the initial concept of a software system to representations in the reuse technique, and (2) automation reduces the effort required to go from abstractions in a reuse technique to an executable implementation.
This survey will help answer the following questions: What is software reuse? Why reuse software? What are the different approaches to reusing software? How effective are the different approaches? What is required to implement a software reuse technology? Why is software reuse difficult? What are the open areas for research in software reuse?
It is argued that the problem with software engineering is not a lack of reuse, but a lack of widespread, systematic reuse. The reuse research community is focusing on formalizing reuse because it recognizes that substantial quality and productivity payoffs will be achieved only if reuse is conducted systematically and formally. The history of reuse, which is characterized by this struggle to formalize in a setting where pragmatic problems are the norm and fast informal solutions usually take precedence, is reviewed. Several reuse methods are discussed.< >
Collections of already developed programs are important resources for efficient development of reliable software systems. In this paper, we propose a novel graph-representation model of a software component library (repository), called component rank model. This is based on analyzing actual usage relations of the components and propagating the significance through the usage relations. Using the component rank model, we have developed a Java class retrieval system named SPARS-J and applied SPARS-J to various collections of Java files. The result shows that SPARS-J gives a higher rank to components that are used more frequently. As a result, software engineers looking for a component have a better chance of finding it quickly. SPARS-J has been used by two companies, and has produced promising results.
Test-driven reuse: Key to improving precision of search engines for software reuse
- O Hummel
- W Janjic
Network Working Group 2006. S. Josefsson. The base16 base32 and base64 data encodings (rfc 4648)
- S Josefsson