No abstract

In this age of collaborative software development, the importance of usable APIs is well recognized. There already exists a rich body of literature that addresses issues ranging from how to design usable APIs to assessing qualitatively the usability of a given API. However, there does not yet exist a set of generalpurpose metrics that can be pressed into service for a more quantitative assessment of API usability. The goal of this paper is to remedy this shortcoming in the literature. Our work presents a set of formulas that examine the API method declarations from the perspective of several commonly held beliefs regarding what makes APIs difficult to use. We validate the numerical characterizations of API usability as produced by our metrics through the APIs of several software systems. SOME STRUCTURAL MEASURES OF API USABILITY 77 specified it to be in the published API document, without any judgment regarding what functionality the API offers vis-a-vis the functionality it ought to offer. More specifically, an API of a module is a set of method declarations that an API designer has chosen to list in the API document for that module. In other words, we will only look at the usability of the structure of the API. ¶ Note that we do not attempt to answer the question of whether an API is truly representing the functionality that it is supposed to. Testing an API for what functionality it represents vis-a-vis the capabilities of the module is obviously a very important problem in its own right and orthogonal to the issue of the usability. As the reader will see in what follows, even if an API were to be perfect with regard to the functionality represented by it, it may not be easy to use because of various structural defects.The next section highlights some of the important structural issues that can make it difficult for a client to use an API. Subsequently, we will take up the more significant of these issues and present metrics that measure the usability of an API with respect to those issues. SOME COMMONLY HELD BELIEFS ABOUT WHAT CONSTITUTE DEFECTS IN API METHOD DECLARATIONSWhen the method declarations in an API document possess one or more of the following features, they are generally considered to be a source of frustration for the programmers: S1: Methods with similar names returning different types of valuesIn OO software systems, overloaded methods of the same name but having different return types can be frustrating to the programmers. The problems created by this structural issue have been well discussed in user forums. For instance, see the blog by Abrams [5]:When the overloaded methods return different types, the programmer must remember the associations between the return types and the method signatures for the different overloadings. For example, consider the following two methods defined for the class javax.naming.directory.Attribute in Java 5:The first method add() assumes that there exists an ordered list of attribute values; this method inserts the attribute value supplied through the second argum...

A key aspect of successfully using UML is understanding the semantics of the notations. UML 2 will increase the already substantial collection of notations supported by UML 1.x. At the same time, this will augment the difficulty users experience in understanding semantics. In this paper we propose that while the diverse notations may render concepts differently, the concepts can often be considered semantically equivalent. This gives rise to an architecture where two single abstract syntaxes (structure and behaviour) underpin UML 2's seven concrete syntax. Because there a fewer semantically distinct concepts, this makes UML both easier to understand and substantially easier to implement.

Creation of large numbers of co-existing long-lived isomorphic objects increases the memory footprint of applications significantly. In this paper we propose a dynamic-analysis based approach that detects allocation sites that create large numbers of long-lived isomorphic objects, estimates quantitatively the memory savings to be obtained by sharing isomorphic objects created at these sites, and also checks whether certain necessary conditions for safely employing object sharing hold. We have implemented our approach as a tool, and have conducted experiments on several real-life Java benchmarks. The results from our experiments indicate that in real benchmarks a significant amount of heap memory, ranging up to 37% in some benchmarks, can be saved by employing object sharing. We have also validated the precision of estimates from our tool by comparing these with actual savings obtained upon introducing object-sharing at selected sites in the real benchmarks.

No abstract