An overview of metrics-based approaches to support software components reusability assessment <s> Intent <s> As Component-based Software Development (CBSD) starts to be effectively used, some software vendors have commenced to successfully sell and license commercial off-the-shelf (COTS) components. One of the most critical processes in CBSD is the selection of the COTS components that meet the user requirements. Current proposals have shown how to deal with the functional aspects of this evaluation process. However, there is a lack of appropriate quality models that allow an effective assessment of COTS components. Besides, the international standards that address the software products' quality issues (in particular, those from ISO and IEEE) have shown to be too general for dealing with the specific characteristics of software components. In this position paper we propose a quality model for CBSD based on ISO 9126, that defines a set of quality attributes and their associated metrics for the effective evaluation of COTS components. <s> BIB001 </s> An overview of metrics-based approaches to support software components reusability assessment <s> Intent <s> The last decade marked the first real attempt to turn software development into engineering through the concepts of Component-Based Software Development (CBSD) and Commercial Off-The-Shelf (COTS) components, with the goal of creating high-quality parts that could be joined together to form a functioning system. One of the most critical processes in CBSD is the selection of a set of software components from in-house or external repositories that fulfil some architectural and user-defined requirements. However, there is a lack of quality models and metrics that can help evaluate the quality characteristics of software components during this selection process. This paper presents a set of measures to assess the Usability of software components, and describes the method followed to obtain and validate them. Such a method can be re-used as a pattern for defining and validating measures for further quality characteristics. <s> BIB002
To introduce a quality model as an adaptation of the ISO9126 for componentbased development BIB001 . The adaptation of the ISO quality model consists on assuming that the software will include black-box components and change the quality model accordingly, so that any assessment of reused software takes into account this restriction. A set of metrics to assess the attributes of that quality model is also proposed. Its rationale is that the metrics collection has to be defined considering the information made available by component brokers. While the first attempt at metrics definition covers transversally the quality model, more recent work by the same authors focuses on the usability of components, as perceived by component assemblers  . Technique Although some of the metrics definitions included mathematical formulae, most definitions were informal BIB001  . In BIB002 , where a validation effort for metrics concerning the usability of components is presented, all metrics definitions are presented in natural language. This presentation is complemented by a metamodel describing the information available from COTS vendors that concerns usability. The metrics set includes metrics on not only the COTS components, but also on their documentation. The metrics collection requires a strong manual intervention, as several of the metrics are collected from the analysis of the available documentation of COTS components. The validation was conducted in a series of 5 experiments (one of them was a replica conducted by peers) with a total of 68 subjects that were asked to evaluate a sample of 12 COTS components. The first three experiments concerned a subjective analysis performed by the participants on each of the components in the sample. The remaining two experiments consisted on an assessment of component reusability through the analysis of the performance of users while answering objective questions concerning the availability of specific tasks and services in the components that made up the sample. Subject's performance was measured as a combination of correctness of responses and time required for providing such responses, and was used as an indirect measure of component reusability. To propose a set of guidelines on how to select metrics for black-box components. Technique No actual metrics are defined. Instead, the authors informally present a set of quality attributes that should be evaluated through metrics. To present a metrics set for reusability of JavaBeans. Technique Informal definition of metrics, relying on access to the source code. The metrics in this set are adapted from other contexts, such as OO design (e.g. percentage of public methods) and structured programming (e.g. maximal McCabe complexity number, for a method in the JavaBean class). To define a set of metrics to assess interface complexity, measuring aspects of components' interfaces, such as the interface size, number of distinct arguments in operations, level of repetition of such arguments, the commonality in identifiers, identifier's length and the density of reference arguments. Technique Metrics are defined through a set of mathematical expressions, but the elements of such expressions are informally described. To propose a metrics set for assessing the reusability of JavaBeans. The metrics set is defined in the scope of a quality model for black-box component reusability, considering understandability, adaptability and portability as relevant subcharacteristics. More refined criteria are then defined for each of these subcharacteristics, as well as metrics to assess JavaBeans in light of such criteria. Technique Metrics are defined as ratios of the effective use of a given sort of interface feature (e.g. BeanInfo class, readable properties, writable properties, methods with parameters and methods with no return value) when compared to its potential use. Besides the complexity aspects of interfaces' signature, this proposal also considers constraints upon those interfaces, as well as their packaging, to account for different configurations that the interface may present, depending on the context of use. Technique The overall complexity is defined as the weighted sum of the complexities related to signature, constraints and packaging of the interfaces. For each of these aspects of interface complexity, a definition is also proposed, again using weighted sums of features (e.g. events and operations count, for signature's complexity). Critique Although Gill's proposal has the merit of including constraints and packaging complexities on the assessment, it still lacks any sort of empirical assessment. This hampers the ability of the authors to assign values to the coefficients on their definitions, and, more significantly, our ability to assess the extent to which this approach helps common practitioners to choose among alternative components.  To discuss the requirements for metrics for CB-architectures based on relevant quality aspects. The authors also present a taxonomy on the categories of costs related to software quality, with cost drivers such as quality improvement, low quality prevention, software failures and external costs related to those failures. Technique High level discussion, rather than a concrete proposal. To define coupling and cohesion metrics for CBD. Technique The metrics are defined using an information theory based approach where components and component infrastructures are represented as graphs. To propose a metrics set that allows assessing software product lines based on service utilization. The rationale for their need is that service utilization in product lines implies a degree of optionality among the components that get used in a given configuration. While some services and components will be part of all configurations of that product line, others are optional. Structural variability is also an issue, as the component assembler has to choose among a range of alternative configurations. Product lines are also typically hierarchical, composed of a set of components, each of which with its own internal structure. The combination of the above mentioned constraints violates the assumptions of most structural metrics that the system structure under evaluation is: (i) single -no optionality considered, snapshots of the system are usually evaluated); (ii) fixed -no structural variability, the system structure is assumed to be kept constant throughout the evaluation; and (iii) flat -the implications of the hierarchical decomposition of the system are not considered in the metrics definition. Technique The metrics are defined around the concept of service utilization (the rate of usage of provided and required services of a component). For individual components, metrics are simply ratios of used services (both for required and provided ones), whereas for component architectures which are fixed and flat (assemblies) these ratios are obtained using the sum of used services against the total of available services. To enable the implementation of a Java class retrieval system (SPARS-J) that aids developers finding out relevant classes for reuse through natural language queries. As the results of those queries tend to be too broad, a ranking system is required to sort the search results in a convenient fashion. The approach is inspired by the computation of impact factors of scientific publications (research papers, books, etc.) and the ranking mechanisms used by modern web search engines. Components are ranked with respect to their reuse in an existing software baseline. The most reused components have a higher rank and are thus presented at the top of query results, as they are more likely to be of interest for the practitioner performing the query. Technique The component rank model uses a weighted directed graph representation for software components, where nodes represent the components and edges represent the use relationships among those components. The weight of each node is computed as a function of the weight of its incoming edges. In turn, the weight of each edge is computed as a function of the weight of its origin node and the number of outgoing edges that node contains. The computation of all these weights corresponds to obtaining a stationary distribution of the Markov chain  that the underlying graph models.