An overview of metrics-based approaches to support software components reusability assessment <s> Metrics ill-definition <s> I. INTRODUCTION. II. OO SOFTWARE METRICS. Project Metrics. Average number of support classes per key class.Average man-days per application class.Average number of classes per developer.Number of major iterations.Number of subsystems.Number of contracts completed.Design Metrics. Average method size.Average number of methods per class.Average number of instance variables per class.Class hierarchy nesting level.Method complexity.Number of methods overridden, inherited, and added by a subclass.Global usage.Instance variable usage.Average number of comment lines per class/method.Number of problem reports per class or contract.Number of times a class is reused.Number of classes/methods thrown away. III. APPENDICES. Project Experience Database. SmallTalk Projects.C++ Projects.Metrics Form. Metrics Tools. <s> BIB001 </s> An overview of metrics-based approaches to support software components reusability assessment <s> Metrics ill-definition <s> Metrics have long been used in software engineering to measure, evaluate, and improve software products and processes. Many metrics have been developed and their subsequent use in different settings has led to varying levels of success. Software architecture is a discipline in which few metrics have been applied, a surprising fact given the important role that software architecture plays in software development. Software product line architectures represent one area of software architecture in which metrics can be of especially great use. The critical importance of the structure defined by a product line architecture requires that its properties be meaningfully assessed and that informed architectural decisions be made to guide its evolution. In this paper, we present several novel metrics that we have designed to address this issue. These metrics are based on the concept of service utilization and are designed to take into account the context in which individual architectural elements are placed. We show the utility of the metrics by applying them in a case study involving a digital library product line architecture. In doing so, we demonstrate how the metrics illustrate deficiencies that, when addressed, improve the overall structural quality of the product line architecture. <s> BIB002 </s> An overview of metrics-based approaches to support software components reusability assessment <s> Metrics ill-definition <s> Recently the awareness of the importance of replicating studies has been growing in the empirical software engineering community. The results of any one study cannot simply be extrapolated to all environments because there are many uncontrollable sources of variation between different environments. In our work, we have reasoned that the availability of laboratory packages for experiments can encourage better replications and complementary studies. However, even with effectively specified laboratory packages, transfer of experimental know-how can still be difficult. A cooperation between Brazilian and American researchers addressing effective running of replications was formed in 1999. One of the specific issues being addressed is the problem of transferring tacit knowledge. We discuss what we learned about the tacit knowledge transfer problem and the evolution of laboratory packages in the description of a replication performed in Brazil using a PBR (Perspective Based Reading) laboratory package; also how further issues are addressed. <s> BIB003 </s> An overview of metrics-based approaches to support software components reusability assessment <s> Metrics ill-definition <s> Software industries are striving for new techniques and approaches that could improve software developer productivity, reduce time-to-market, deliver excellent performance and produce systems that are flexible, scalable, secure, and robust. Only software components can meet these demands and following this; component-based software engineering (CBSE) has emerged, which has generated tremendous interest in software development community. The paradigm shift to software components appears inevitable, necessitating drastic changes to current software development and business practices. The scope of this paper is to suggest few necessary guidelines for deriving component-based metrics. The paper discusses issues related to component-based development (CBD) and suggests a general definition of software component based on several existing definitions. Further, the paper outlines the necessity of component measurement and also discusses the limitations of traditional software metrics for component-based development (CBD) systems. Finally, this paper also suggest few necessary guidelines for CBD measurement and proposes some relevant metrics applicable to CBD systems, which after proper quantification and validation may help guiding risk and quality management of component-based systems. <s> BIB004
The metrics ill-definition problem occurs due to several reasons. Metrics definitions are often presented without the corresponding context. Without expressing which is the underlying metamodel upon which the concepts and their interrelationships are defined, metrics definitions become subjective, as different interpretations on which those concepts are and on how to perform the measurements are possible. Finally, metrics definitions are performed without an underlying formal approach that uses the previously mentioned metamodel as contextual input. The formal specification of metrics should address not only how the underlying concepts are accounted for and their interrelationships are traversed to collect the required metrics, but also the pre-conditions that must be met to allow the collection of such metrics. Without clear and precise definitions of metrics, it may be impossible to consistently develop tools to collect those metrics, or to discuss their properties in a mathematically sound way. The usage of natural language is a typical metrics definition problem. One of the first books on metrics for object-oriented design contained natural language definitions for all its metrics BIB001 . While this may be considered helpful as a first glimpse on the metric's objective, the absence of a formal definition may hamper its systematic and repetitive collection and validation by different researchers or practitioners. Consider the following natural language definitions, borrowed from BIB004 : The first definition is a typical example of a "wish list" metric proposal. Although it contains an intuition to the authors' intentions when defining it, the description is too vague with respect to how the interfaces complexity should be measured. The second definition is more objective, in the sense that it implies that the metric is defined as a ratio between used and available resources. It completely omits which resources should be measured and how they could be measured. For the sake of argument, assume that we wish to instantiate the second metric by computing CRUM considering memory as the resource under scrutiny. Which would be the conditions for performing the measurement? Should we consider the average memory used by the component during its lifetime, its highest value during a particular period of usage, or any other option? Should we consider the total physical memory of the target computer as a baseline, or discount the memory used by other applications, namely the operating system being run by that computer? There are too many points of uncertainty in this kind of definition, leading to points of variation in the implementation of tools for collecting them. Note that even the apparently trivial LOC definition as a count of lines of code is susceptible to different interpretations, in part due to its vulnerability to coding style options. When analyzing a source code file, should we make a simple count of lines, or should we omit, for instance, blank lines? Should comment lines be counted as well, or omitted? How do we deal with text wrapping? Should we pre-process the source code to ensure a uniform formatting style? Although in principle one can always detail all the counting rules down to their most intricate details, natural language definitions of metrics are often incomplete and ambiguous. A consequence is that different tools collecting allegedly the same metric may provide different values for that metric, while analyzing the same artefact. This hampers the comparability of metrics collected by independent teams using different tools. Results interpretation may also be flawed, due to these potentially different interpretations of the natural language definitions. A common approach to increase the quality of metrics specifications is to use a combination of set theory and simple algebra to define metrics. Consider the following example, borrowed from Hoek et al. BIB002 , for the provided (PSU x ) service utilization metric. Total Actual x P P PSU = Hoek et al. define a service as follows: "Under the term service, we include such things as public methods or functions, directly accessible data structures, and any other kind of publicly accessible resource one may be able to express in an ADL." Their intention is to define these metrics in a generic way, so that they are not tied to any particular ADL (Architecture Description Language), or service. The price to pay for this option is that different implementations will consider different kinds of services as relevant. Although the metrics formulas are objective, the selection of the elements to be included in such formulas is ambiguous, making these metrics ill-defined. The alternative is to use a formal approach to define metrics. Dumke et al. proposed a taxonomy for formal approaches to software measurement  , as well as a discussion on their strengths and weaknesses. The categories include algebraic, axiomatic, functional, rule-based, structurebased, information-theoretical, and statistical approaches. In our opinion, their taxonomy lacks cohesion, in the sense that some of the former 6 groups of approaches concern metrics definition, while the latter (statistical) is mostly concerned with how to treat data obtained from those metrics. The main shortcoming of formal approaches to metrics definition is that understanding them requires mathematical skills that are often not held by common practitioners. None of the reviewed proposals includes a formal definition of metrics. In some cases, the author's intentions were clearly to leave the metrics definitions abstract enough for readers to adapt those definitions to their own context (e.g. Hoek's metrics). There is a fairly balanced distribution between whish-lists (3), informal definitions (3) and semi-formal definitions (4) of metrics. Since the majority of definitions are too informal, replicated experiments aimed at validating these proposals are bound to have difficulties related to the tacit knowledge problem: insufficient information provided by the original authors of an experiment causes difficulties in its replication. In this case, the tacit knowledge concerns the definition of the metrics, where non-stated assumptions may lead to different interpretations of the original metrics definitions. While the tacit knowledge problem, as describer by Shull et al. BIB003 is wider (it refers to all relevant information for replicating an experiment, from its requirements statement to the results packaging, which is not clearly specified in the experiment reporting, leading to possibly wrong assumptions by those who attempt to replicate the experiment, with respect to what was really done in the original experiment), it could be mitigated, in what concerns metrics definition, by providing a formal definition of all the defined metrics.