Object oriented design metrics
These metrics fall in the category of metrics covered by M2DM. M2DM was origi- nally proposed to support the specification and collection of metrics for object-oriented design [Abreu 01b, Abreu 01a] and was used in the formalization of several object- oriented design metrics suites [Baroni 02b, Baroni 03, Baroni 02a]. Although the first metrics formalizations used a metamodel that was based on a research object-oriented design language called GOODLY [Abreu 99], the approach was subsequently ported with success to the UML 1.* metamodel.
M2DM was recently adopted in industry by a UML tool producer11 to add the capability of metrics collection to a UML tool. The tool uses a simplified version of a subset of the UML 2.0 metamodel as a base metamodel upon which OCL expressions are used to support metrics collection.
There are a few proposals by other authors which can be compared to the M2DM approach (and, as such, to ODM). In [Moser 97], Moser and Misic proposed a for- mal metamodel approach to measuring class coupling and cohesion. They used the Z formal notation to define the ontology and the metrics themselves. Their approach is elegant and sound, but the usage of Z is, in our opinion, a drawback with respect to the knowledge transfer to industry, as most practitioners are not comfortable with formal languages. In [Morisio 99], Morisio proposed metrics using OMT scripts upon process models. To make them easier to understand, he translated the definitions also to SQL. Again the main rationale behind ODM applies, although in this case with slightly less formality than our approach, or Moser’s.
11Borland, (http://www.borland.com/), with its Together Architect 2006. The tool uses OCL de-
fined metrics to support heuristic assessment on models. The base metrics set is open, so that users may add new metrics and their corresponding heuristics.
Object-relational database metrics
The usage of different metamodels for the collection of object-oriented design metrics is an instance of a more general property of M2DM (and, consequently, of ODM). The approach is generic in what concerns the domain of application. It has been used to define, collect, and use metrics on other domains, such as that of relational databases [Baroni 05b, Baroni 05a, Calero 05].
Component-based development metrics
In the scope of the work described this dissertation, we use ODM in essentially two different contexts: for process metrics, collected during the development of software components, and for metrics collected on existing component-based systems. The for- mer usage will be presented in detail on chapter 6.
The latter was used in metrics formalization and collection for different types of component technologies (each corresponding to a specific metamodel). We collected metrics on JavaBeans, using the UML 2.0 metamodel, as shown in this chapter, and also on [Goulão 04b, Goulão 04c, Goulão 04a, Goulão 05c]. Corba Components, using the CCM metamodel [Goulão 05b] and component assemblies, using an extended version of the CCM metamodel [Goulão 05a], were also used to explore the versatility of the ODM approach, as we will discuss in chapter 5. Finally, we will use ODM on Eclipse plug-ins, using a metamodel developed for this purpose as the ontology, in chapter 7.
4.6
Conclusions
In this chapter, we presented a metrics formalization and collection technique called Ontology-Driven Measurement (ODM). We exemplified how metrics can be formally defined upon an ontology (in this case, a metamodel), and how they can be computed. Then, we presented an exploratory case study concerning the independent validation of a metrics set and its underlying quality model, proposed by Washizaki et al. for assessing the reusability of JavaBeans. We tested a set of components developed by Washizaki’s team, for educational purposes, against the set of heuristics proposed in their quality model. The results suggest that the heuristics-based quality model may require some calibration, when used with fine-grained components. Perhaps more importantly, at least for the purposes of this dissertation, this exploratory case study was used as a pretext for exercising ODM in the context of software component design analysis. The techniques introduced in this chapter will be further explored in the following chapters.
ODM expressiveness assessment
Contents
5.1 Introduction . . . 152 5.2 A component assembly toy example . . . 152 5.3 Informal description of structural metrics . . . 157 5.4 Metrics definition formalization . . . 168 5.5 Comments on the metrics’ definitions . . . 185 5.6 On the complexity of metamodels . . . 190 5.7 Conclusions . . . 191
Background: If we are to adopt ODM as a metrics definition technique for CBD, it is important to explore the expressiveness of this approach in the context of CBD.
Objective: Our goal is to assess the expressiveness of component metamodels in met- rics formalization, illustrating both the flexibility of ODM and how some common difficulties relating to that expressiveness can be circumvented.
Method: We present the definitions of metrics sets, proposed by several authors, to cover different aspects of component interaction. We formalize those metrics using the UML 2.0 and CCM 3.0 metamodels. We assess the formalization exercise.
Results:Metrics formalization facilitates the identification of shortcomings of the orig- inal metrics definitions. We also identify some limitations in the UML 2.0 and CCM 3.0 metamodels, and propose metamodel extensions to solve them.
Limitations: There are other component models, each with its own constructs, which could have been used in this formalization exercise. A possible extension to this work would be to repeat this formalization with such models.
Conclusions: The formal definition of metrics exposes several shortcomings of their “traditional” definitions, and illustrates the expressiveness and flexibility of the ODM approach using different metamodels.
5.1
Introduction
In the previous chapter we introduced ODM as a rigorous approach to the specification and computation of software metrics. We illustrated the ODM approach by specifying and collecting metrics defined on the interfaces of JavaBeans. The metrics were for- malized using OCL expressions upon the UML 2.0 metamodel. The metrics set used in chapter 4 is a typical example of a set of product metrics defined upon software ar- tifacts (in chapter 4’s case, class diagrams obtained by reverse-engineering the source code of the JavaBeans).
In this chapter we will explore the expressiveness of the ODM approach in the context of CBD. While on the previous chapter the UML 2.0 was used as a metamodel for metrics definition, in this chapter we will show how different metamodels can be used to specify and collect the same metrics.
The focus of this chapter is on the expressiveness of the ODM approach and its suit- ability to metrics definition in different contexts, rather than on the the usefulness of each of the defined metrics. Such usefulness can only be assessed through experimen- tation. Experimentation in CBD will be the focus of chapters 6 and 7.
This chapter is organized as follows: we start by introducing a toy example using both the UML 2.0 and the CCM 3.0 as the specification notations. Then, we informally describe a set of metrics for software components, which includes metrics proposed by several authors. Our presentation of these metrics uses their original specification notations, and highlights the shortcomings of such notations. We use the toy model to illustrate the computation of the presented metrics. The metrics are then formal- ized using the ODM approach, both upon the UML 2.0 metamodel and the CCM 3.0 metamodel. The limitations of these metamodels for the purposes of our formalization effort are discussed, as well as proposals to solve the identified problems. The chap- ter ends with a discussion on the evolution of the complexity of metamodels and its impact on the usability of the ODM approach.