Quantitative Approaches in Object-Oriented Software Engineering (Innovative Technology Series: Information Systems and Networks)

Quantitative Approaches in Object-oriented Software Engineering This page intentionally left blank INNOUATIVE TECH...

Author: Fernando Brito E. Abreu

54 downloads 699 Views 6MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Quantitative Approaches in

Object-oriented Software Engineering

This page intentionally left blank

INNOUATIVE TECHNOLOGY SERIES INFORMATION SYSTEMS AND NETWORKS

Quantitative Approaches in

Object-oriented Software Engineering

edited by Fernando Brito e Abreu Geert Poels Houari H. Sahraoui Horst Zuse

HPS

HERMES PENTON SCIENCE

First published in 2001 by Hermes Science Publications, Paris First published in 2002 by Hermes Penton Ltd Derived from L 'Objet, Quantitative Approaches in Object-oriented Software Engineering, Vol. 7, no. 4. Apart from any fair dealing for the purposes of research or private study, or criticism or review, as permitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced, stored or transmitted, in any form or by any means, with the prior permission in writing of the publishers, or in the case of reprographic reproduction in accordance with the terms and licences issued by the CLA. Enquiries concerning reproduction outside these terms should be sent to the publishers at the undermentioned address: Hermes Penton Science 120 Pentonville Road London Nl 9JN © Hermes Science Publications, 2001 © Hermes Penton Ltd, 2002 The right of Fernando Brito e Abreu, Geert Poels, Houari A. Sahraoui and Horst Zuse to be identified as the editors of this work has been asserted by them in accordance with the Copyright, Designs and Patents Act 1988.

British Library Cataloguing in Publication Data A CIP record for this book is available from the British Library. ISBN 1 9039 9627 9

Printed and bound in Great Britain by Biddies Ltd, Guildford and King's Lynn www. biddies.co.uk

Contents

Foreword Fernando Brito e Abreu, Geert Poels, Houari A Sahraoui and Horst Zuse 1. A formal approach to building a polymorphism metric Claudia Pons and Luis Olsina 2. A merit factor driven approach to the modularization of object-oriented systems Fernando Brito e Abreu and Miguel Goulao 3.

Object-relational database metrics Mario Piattini, Coral Calero, Houari A Sahraoui and Hakim Lounis

4. Measuring event-based object-oriented conceptual models Geert Poels and Guido Dedene 5.

Class cohesion as predictor of changeability: an empirical study Hind Kabaili, Rudolf Keller and Francois Lustman

VII

1

27 49 69 87

6. Building quality estimation models with fuzzy threshold values Houari A Sahraoui, Mounir Boukadoum and Hakim Lounis

107

Index

127


Foreword

Software internal attributes have been extensively used to help software managers, customers and users to characterize, assess, and improve the quality of software products. Many large software companies have adopted software measures intensively to increase their understanding of how (and how much) software internal attributes affect the overall software quality. Estimation models based on software measures have successfully been used to perform risk analysis and to assess software maintainability, reusability and reliability. However, most measurement efforts have focused on, what we call today, "legacy technology". The OO paradigm provides more powerful design mechanisms. Much work has yet to be done to investigate analytically and/or empirically the relationships between OO design mechanisms, e.g., inheritance, polymorphism, encapsulation, usage, etc., and different aspects of software quality, e.g., modularity, modifiability, understandability, extensibility, reliability, reusability, etc. Furthermore, new technologies, e.g., OO frameworks, OO Analysis/Design patterns, OO architectures, OO components, which take advantage of OO design mechanisms have been proposed in order to improve software engineering productivity and software quality. However, to better understand the pros and cons of these technologies for products developed by using them we must be able to assess the quality of such products via adequate software product measures. A quick look at the literature shows that the work done in the field of quantitative approaches in object-oriented software engineering covers a wide range of topics For this publication, four of them were selected: metrics collection, quality assessment, metrics validation and process management. These four items were identified as key topics during the series of QAOOSE (Quantitative Approaches in Object-Oriented Software Engineering) workshops from which this publication is derived. The first contribution, "A Formal Approach to Building a Polymorphism Metric", proposes a metric that provides an objective and precise mechanism to detect and quantify dynamic polymorphism. This metric is defined using a rigorous formalization of the polymorphism and is validated theoretically. The second, "A Merit Factor Driven Approach to the Modularization of ObjectOriented Systems", presents a quantitative approach for the modularization of object-oriented systems. This approach aims at finding the optimal number of modules using a modularization merit factor and clustering the classes according to this number. The third, "Object-relational Database Metrics", is devoted to the definition and the validation of a suite of metrics for object-relational databases. The definition and the validation (theoretical and empirical) follow a rigorous methodology.

viii

Foreword

The fourth, "Measuring Event-based Object-oriented Conceptual Models", introduces a suite of metrics that covers two important fields of object-oriented technology, namely the early stages of development and dynamic aspects of the design. A first empirical validation of the metrics is presented to show their usefulness. The fifth, "Class Cohesion as Predictor of Changeability: An Empirical Study", describes an investigation on the possibility to use the cohesion metrics as indicators for one of the important quality characteristics, namely the changeability. Although the results didn't demonstrate an evidence of relationship, the authors showed that the problem is related to the definition of the cohesion metrics. The sixth paper, "Building Quality Estimation Models with Fuzzy Threshold Values", proposes an approach for building and using software quality estimation models. This approach is based on a fuzzy logic-based learning algorithm. The main objective is to circumvent one of the major problems with the existing, namely the use of precise metric thresholds values. There are many people to thank for their efforts in the production of this publication, including the external reviewers and specially Bernard Coulange, Guido Dedene, Teade Punter, and Franck Xia for their good work.

Fernando Brito e Abreu FCT/UNL & INESC, Lisboa, Portugal Geert Poels Vlekho Business School, Brussels, Belgique Houari A. Sahraoui IRO, Montreal, Canada Horst Zuse Technische Universitat Berlin, Allemagne

Chapter 1

A formal approach to building a polymorphism metric Claudia Pons Lifia, Universidad National de La Plata, Argentina, Brazil

Luis Olsina GIDIS, Facultad de Ingenieria, UNLPam, Argentina, Brazil

1. Introduction Object-oriented (O-O) software engineers need a better understanding of the desirable and non-desirable characteristics of O-O systems design, and their effect on the quality factor. These properties must represent those characteristics that lead to more understandable, analyzable, extensible and ultimately maintainable software products. The key issues related to the quality assessment of O-O systems are: - It is necessary to determine the desirable and non-desirable characteristics of systems; - There must be a formal definition of these characteristics; - It is necessary to provide mechanisms to detect and quantify the presence of these characteristics; - These mechanisms must be formal and objective. Although quality is not easy to evaluate since it is a complex concept integrated by different characteristics (as efficiency, maintainability, among others), several properties that make for good O-O design have been recognized and widely accepted by the community. Traditional metrics are often quite applicable to OO, but traditional metric suites are not sufficient to measure all OO-specific properties. So, at least, the traditional metric suites must be extended by including new measures (e.g. for polymorphism) to make them useful for measuring OO software. This problem is due to the presence of additional properties that are inherent to the O-O paradigm, such as abstraction, inheritance and polymorphism. These new

2

Quantitative approaches in object-oriented software engineering

concepts are vital for the construction of reusable, flexible and adaptable software products and they must be taken into consideration by O-O software quality metrics. The applicability problem of traditional techniques has been analyzed in the works of Chidamber and Kemerer [CHI 94], Tegarden et al [TEG 92] and Wilde and Huitt [WIL 92] among others. Special metrics for O-O systems have been investigated; see for example the works of Chen and Lu [CHE 93], Kim et al [KIM 94] and Li and Henry [LI 93]. There are numerous proposals addressing the assessment of traditional properties into O-O systems; for example the work of Poulin [POU 97], Briand et al [BRI 97], Price and Demurjian [PR] 97], Benlarbi [BEN 97]. But less work has been done in the field of specific O-O properties; see for example the works of Bansiya [BAN 97] [BAN 99] [BAN 99], Benlarbi and Melo [BEN 99], Abreu and Carapu9a [ABR 94] and Zuse [ZUS 98]. An additional problem is that many of the currently available metrics can be applied only when the product is finished or almost finished, since data is taken from the implementation, so the problems of weakness in quality are detected too late. It is desirable to have a tool that uses information coming from the first stages of the development process (i.e. requirement analysis phases); this would give developers the opportunity to evaluate early and improve the quality of the product in the development process. In this paper, new metrics to measure the quality of an O-O design are defined. These metrics are applied to the conceptual model of a system expressed in the unified modeling language [UML 99], thus permitting an early analysis of the system quality. Although we agree that both the traditional and the specific O-O properties or attributes should be analyzed in assessing the quality of O-O design, our purposes are not to define a complete quality evaluation mechanism (in the sense that it considers every system characteristic), but only to characterize some aspects of the polymorphism attribute. The polymorphism concept can be considered to be one of the key concepts in determining the quality of an O-O design. Regarding the literature, e.g., Benlarbi and Melo [BEN 99], different kinds of polymorphism have been classified, namely: pure, static, and dynamic ones. For instance, considering the latter, for two methods to be polymorphic, they need to have the same name and signature (parameter types and return type) and also the same effects (changing the state of the receiver in the same way and raising the same messages to other objects in the system). Dynamic binding allows one to substitute objects that are polymorphic for each other at runtime. This substitutability is a key concept in O-O systems. Polymorphic systems have several advantages. They simplify the definition of clients, since so long as a client only uses the polymorphic interface, it can substitute an instance of one class for another instance of a class that has the same interface at run-time, because all instances behave the same way. We formally define the dynamic polymorphism concept, giving foundations for its detection and quantification. Thus, the polymorphism measure should be

Building a polymorphism metric

3

combined with the measures of the rest of the properties (such as coupling, cohesion, entropy, etc) with the aim of determining the total quality of the system. However, this metrics combination task is beyond the scope of this work. The structure of this paper is as follows: in the next section, we introduce the M&D-theory, an approach for giving formal semantics to the UML model. In Section 3, we give a formal definition of polymorphism. We define a polymorphism metric and examples in Sections 4 and 5. In the following sections, a conceptual framework for validation is introduced as well as the theoretical validation for that metric suites.

2. The formal domain We first introduce the M&D-theory, a proposal for giving formal semantics to the Unified Modeling Language. The basic idea behind this formalization is the definition of a semantic domain integrating both the model level and the data level. In this way, both static aspects and dynamic aspects of either the model or the modeled system can be described within a first order formal framework. The entities defined by the M&D-theory are classified in two disjoint sets: modeling entities and modeled entities. Modeling entities correspond to concrete syntax of the UML, such as Classes or StateMachine. In contrast, modeled entities, such as Object or Link represent run-time information, i.e. instances of classes and processes running on a concrete system.

2.1. Structure of the theory The M&D-theory is a first-order order-sorted dynamic logic theory consisting of three sub-theories: M&D-theory = UML-theory + SYS-theory + JOINT-theory NOTE.-A first-order order-sorted dynamic logic theory Th consists of a signature E. that defines the language of the theory, and a set of D-axiomas (o: Th = (E, o). A signature E consists of a set of sort symbols S, a partial order relation between sorts Seq of Message currentStates: Instance —»State Actions -.-: Instance, Message -» Modification Axioms Vi:Instance VI:LinkEnd Static axioms [ 1 ] the AttributeLinks matches the declarations in the Classifier. Vleslots(i) (attribute(l)eallArtributes(classifier(i))) [2] symmetry lelinkEnds(i)) in the formal domain that m(xl) is greater than m(x2); and secondly, if m(xl) is greater than m(x2), then it implies ( x2; and the numerical statement is: m(xl) > m(x2), being •> and > the respective relational operators. It is important to notice that empirical statements are

18


not true per se; they can be falsified by means of observations and experiments. On the other hand, for the empirical relation •> (or •>=) there can be several interpretations, according to the case. Examples are: equal or more difficult to understand than; equal or more functional than, equal or higher level of defects than, etc. Moreover, the concepts of empirical and formal relational systems, and the concept of metric (or measure) can be introduced. For instance, for the ranking order, the empirical relational system is defined as: S = (S, •>=); and the numerical relational system is defined as: N = (R, >=), where R is a real number. Then, we can write for the m metric, the following expression [ZUS 98]:

where a metric is a correspondence (or mapping) m: S -> R in which the (1) expression is fulfilled for all xl, x2 that belong to S.

6.2. Some classes of the empirical domain: entity and attribute From the evaluation standpoint, in the empirical domain, we have basically the Entity and Attribute classes. The Entity class can be decomposed primarily in three main sub-classes of interest to evaluators, that is to say: a) Process: it is the entity possibly compound of other sub-processes and activities (or tasks), used primarily to produce artifacts; b) Artifact: it is the temporary or persistent entity representing the product of performing a process, and c) Resource: it is an entity required by (or assigned to) a process as input to produce some specified output (project resources are: human, monetary, materials, technological, temporal). The Attribute class represents what is observed and attributed regarding what is known of an entity of the real world, being an object of interest for evaluation. Attributes can be measured by direct or indirect metrics. For a given attribute, there is always at least an empirical relationship of interest that can be captured and represented in the numerical (formal) domain, enabling us to explore the relationship mathematically. There can be a many-to-many relationship between Entity and Attribute classes. That is, an entity can possess several attributes as long as an attribute can belong to several entities [KIT 95]. In the present work, for example, an O-O design specification of a software system is an artifact or product, and polymorphismjneasure is an indirect attribute. It is important to note that a metric of a direct attribute of an entity involves no other attribute measure (such as the number of classes or number of methods of an inheritance hierarchy). However, we can obtain values from equations involving for example two or more direct attributes measures. Hence, we have an Attribute Association in the empirical domain that is formalized by an Equation in the formal domain (such as the polymorphism_measure formula of Section 4).


19

6.3. Some classes of the formal domain: value, unit, scale type, and measurement tool A Scale Type and Unit should be considered in order to obtain magnitudes of type Value when a specific Attribute of a given Entity is measured. A Unit of measure determines how the attribute of such entity should be quantified. Therefore, the measured value can not be interpreted unless we know to what entity it is applied, to what attribute it is measured and in what unit it is expressed (i.e., the empirical and formal relational systems should be clearly specified). On the one hand, Value (or scale) and Scale Type are two different classes that are frequently confused. The concept of scale is defined by the triple (S, N, m) - see (2) above. So the scale is defined by a homomorphism. Clearly, it can be noted that the empirical relational system S, the numerical relational system N, and the metric m are needed in order to obtain a value or scale. On the other hand, a scale type is defined by admissible transformations. An admissible transformation is a conversion rule f in which are given two measures m and m', it holds that m' = f m. For example, admissible transformations are m' = a m + b, with a > 0 and b e R; m' = a m, among others. The scale type does not change when an admissible transformation is performed. Besides, the scale type of a measure affects the sort of arithmetical and statistical operations that can be applied to values. Scale types are hierarchically ordered as nominal, ordinal, interval, ratio and absolute scales and can been seen as keywords describing certain empirical knowledge behind values, as stated by Zuse. For example, the nominal scale type implies a very simple empirical condition: the equivalence relationship. Let the empiric relational system be (S, «), and given an observable attribute so that xl, x2 belong to S; a function m: S -> R, then exists so that: is a nominal value. In addition, for the ordinal scale type, the empirical relational system of the nominal one is extended to reflect the ordinal scale as expressed in (2). Zuse indicates that the weak order is a prerequisite for ranking order measurement, which is transitive and complete. So we can express these properties as:

Moreover, the ratio scale type is a very well known one in physics and traditional sciences; e.g., for longitude, money measures, among others. Zuse says, "we want to have something above poor ranking or comparing of objects. We want to be additive in the sense that the combination of two objects is the sum of their measurement values'". The idea of a ratio scale is linked to additive and non-additive properties. An additive ratio scale is represented by:

20


Therefore, (S, •>=, o) is a closed extensive structure if there exists a function m on S such that for all xl, x2 belonging to S,

Also, a function m' exists that is the admissible transformation, i.e.: m'(x) = a m(x) with a > 0. Furthermore, the author defines the modified extensive structure and the empirical conditions where specific axioms must be satisfied (see Chapter 5). Finally, for an absolute scale type the only admissible transformation is identity, as we will exemplify for some polymorphic metrics, in Section 7. On the other hand, regarding the conceptual classes of the framework, obtaining the measured value can be done either manually or automatically by using partially or totally a Measurement Instrument (a software tool). This instrument can be optional, however. Automated data gathering is more objective and reliable.

7. Validation of the polymorphism metric There are two strategies to corroborate or falsify the validity of metrics: the theoretical and the empirical validation. Theoretical validation is mainly based on mathematical proofs that allow us to formally confirm that the measure does not violate the properties of the relational systems, the conceptual models and criteria. On the other hand, the empirical validation consists frequently of the realization of experiments and observations on the real world in order to corroborate or falsify the metric or model. In addition, validation approaches can be classified according to the type of attribute that is taken into account. From this point of view a metric is valid internally or "valid in the narrow sense" [FEN 97], if it analyses attributes that are inherent of the entity (product, process or resource), while a metric is valid externally or "valid in the wide sense" if it considers higher level characteristics (such as cost, quality, maintainability, etc) both for assessment and for prediction purposes. In this section, we analyze some aspects of the theoretical validation for the polymorphism metrics discussed and exemplified in Sections 4 and 5. These direct and indirect metrics embrace internal attributes of a product. In a general sense, the [KIT 95] assumption is that in order for a measure to be valid these two conditions must be held: 1) the measure must not violate any necessary property of its elements (i.e., the classes and relationships); 2) each model used in the process must be valid. The structural framework of [KIT 95] can be combined with the axiomatic framework of [ZUS 98] to yield a wider validation framework, [OLS 00]. Regarding the proposed conceptual framework in order to decide whether a metric is valid, it is necessary at least to check:


21

-Attribute validity, i.e., whether the attribute is actually exhibited by the entity being measured. For a given attribute, there is always at least an empirical relationship of interest that can be captured and represented in the formal domain, enabling us to explore the relationship analytically. This can imply both a theoretical and an empirical validation; - Unit and Scale Type validity, i.e., whether the measurement unit and scale type being used are an appropriate means of quantifying the internal or external attribute. As stated before, when we measure a specific attribute of a particular entity, we consider a scale type and unit in order to obtain magnitudes of type value. Thus, the measured value can not be interpreted unless we know to what entity it is applied, to what attribute it is measured and in what unit it is expressed (i.e., the empirical and formal relational systems should be clearly specified). On the other hand, a scale type is defined by admissible transformations of measures; -Instrument validity, i.e., whether any model underlying a measuring tool is valid and the instrument is properly calibrated; - Protocol validity, i.e., whether an acceptable measurement protocol has been used in order to guarantee repeatability and reproducibility in the measurement process. Regarding the polymorphismjneasure, some empirical considerations should be made. As aforementioned, the tthierarchies(S) function returns the collection containing all the disjoint hierarchies defined in S. This guarantees, for example, that the intersection between two hierarchies gives the empty set. In addition, we are only considering tree hierarchies which allow us to model single inheritance (Java and Smalltalk languages, among others, only support single inheritance). In order to try to guarantee the ratio scale for the polymorphismjneasure metric, we started to investigate the modified extensive structure and the additive properties discussed in [ZUS 98]. However, the initial results indicate that the metric does not accomplish the independence condition Cl, and the axiom of weak monotonicity. Hence, for that metric the absolute scale has in principle been validated as follows: Theorem 7.1: The scale type of the polymorphismjneasure is absolute. Proof: Let m = A/B be the metric, and let A, B be absolute values

[3]

where A represents the polymorphicjnethods attribute; and B represents the total number of methods of a hierarchy (#methods(h)). A 0 Replacing (3) in (4), the following equation is obtained: m = c B/B = c.

[4]

22


The resulting m is an absolute scale. Besides, percentage measures can be used as an absolute scale, but they do not assume an extensive structure - as indicated by [ZUS 98], p. 237-238. Attribute #classes (h)

Scale Type Absolute

#methods (h)

width(h)

#hierarchies (S)

Polymorphic methods

Absolute

Polymorphism Absolute measure

Unit

Some Criteria and Properties that Apply

Number of classes in h Total number of methods in h (regarding bags) Number of polymorphic methods

• These internal attributes are exhibited in OO design and implementation specifications. They are direct metrics. S Different hierarchy specifications may have different number of classes, methods, etc. for the respective attribute. Conversely, different hierarchy specifications may have the same number of classes, methods, etc. S The unit and scale type are defined and confirmed. The admissible transformation is the identity, i.e. m(x)=x. Accordingly, they are obtained by counting elements where an absolute scale is generally implied (but not always).

Number of hierarchies in the S specification Number of polymorphic methods * Number of classes

[(Number of polymorphic methods * Number of classes) / Total number of methods to h], It represents the degree of polymorphic methods of an inheritance hierarchy

S It is an indirect metric. The equation is shown in Section 4. v' The unit and scale type is defined. The admissible transformation is the identity, i.e. m(x)=x. So, it yields an absolute scale regarding the following combination rule: m(xl o x2) = m(xl) * m(x2). •S It is an indirect metric. The equation is shown in Section 4. S It fulfills that a greater number of polymorphic methods with regard to the total amount of methods of a hierarchy lead to a higher degree of polymorphism -hence, the specification can be more understandable and reusable). The absence of polymorphic methods in a hierarchy yields a zero value. Conversely, the 1 value (or 100%) means that all methods are polymorphic. •S The unit and scale type are defined. It yields an absolute scale as demonstrated by the theorem 7. 1.

Figure 5. Descriptions of theoretical validity for the polymorphism_measure and its elements

•


23

Figure 5 shows descriptions of the theoretical validity for a set of used functions for the metric. The target entity is an O-O design specification or a source code of an O-O program. The instrument validity is applicable because data collection and calculations can be carried out automatically (the underlying algorithm is supported by the recursive model). Ultimately, the measure of polymorphism of a set of disjoint hierarchies defined in the S specification is computed by making an average as shown in Section 4. This statistical analysis is allowed to magnitudes of an absolute scale type.

8. Concluding remarks Although quality is not easy to evaluate since it is a complex concept compound with different characteristics (see, for example, the ISO 9126 quality standard [ISO 91]), several attributes that make a good O-O design have been recognized and widely accepted by the software engineering community. We agree that both the traditional and the new O-O properties or attributes should be analyzed in assessing the quality of O-O design. On the other hand, further work should be carried out in order to map and correlate O-O metrics to quality characteristics such as those prescribed in the ISO standard. However, as an initial step in that direction, we believe that it is also necessary to pay attention to the concepts and metrics for polymorphism, since it should be considered to be one of the metrics that influences the quality of an O-O software system. In this paper, we have given a rigorous definition of polymorphism in the framework of the M&D-theory [PON 99]. Accordingly, on top of this formalization, we have proposed a metric for measuring polymorphism that provides an objective and precise mechanism to detect and quantify dynamic polymorphism. In addition, initial efforts have been made in order to validate the discussed metrics regarding the theoretical validation framework. Furthermore, it is important to note that the analyzed metric takes information coming from the first stages of the development lifecycle gives developers the opportunity to early evaluate and improve some attributes of the quality of the software product.

9. References [ABR 94] ABREU, F.B., CARAPUQA, R., "Object Oriented Software Engineering: Measuring and controlling the development process", 4th International Conference on Software Quality, Virginia, USA, 1994. [BAN 97] BANSIYA, J., "Assessing quality of object-oriented designs using a hierarchical approach", OOPSLA '97 Workshop#12 on Object-oriented design quality, Atlanta, USA, October 1997.

24


[BAN 99] BANSIYA, J. DAVIS, C. ETZKORN L., LI, W., "An entropy-based complexity measure for object oriented designs", Theory and Practice of Object Oriented Systems, 5(2), 1999. [BEN 97] BENLARBI, S., "Object-oriented design metrics for early quality prediction", OOPSLA '97 Workshop#12 on Object-oriented design quality, Atlanta, USA, October 1997. [BEN 99] BENLARBI, S., MELO, W. "Polymorphism measures for early risk prediction", In International Conference of Software Engineering (ICSE'99), Los Angeles, CA, USA, 1999. [BRI 97] BRIAND, L. DEVANBU P., MELO, W., "An investigation into coupling measures for C++", In International Conference of Software Engineering (ICSE'97), Boston, USA, May 1997. [CHI 94] CHIDAMBER S., KEMERER, C., "A metric suite for object oriented design", IEEE Transaction on Software Engineering, 20, 1994. [CHE 93] CHEN J., Lu, J., "A new metric for object oriented design". Information and Software Technology, 35. 1993. [FEN 97] FENTON, N.E.; PFLEEGER, S.L., Software Metrics: a Rigorous and Practical Approach, 2nd Ed., PWS Publishing Company. 1997. [HAR 00] HAREL, D., KOZEN, D., TIURYN, J. Book on Dynamic Logic, to appear, 2000. [ISO 91] ISO/IEC 9126, International Standard Information technology - Software product evaluation - Quality characteristics and guidelines for their use, 1991. [KIM 94] KIM, E. CHANG, o. KUSUMOTO, s. KIKUNO, T., "Analysis of metrics for object oriented program complexity", Procs. 18lh Annual International Computer Software and applications Conference, COMPSAC'94. [KIT 95] KITCHENHAM B., PFLEEGER s. L., FENTON N., "Towards a Framework for Software Measurement Validation", IEEE Transactions on Software Engineering, 21(12), p. 929944, 1995. [LAL 94] LALONDE, WILF, Discovering Smalltalk, Addison Wesley. 1994. [LI 93] LI W., HENRY S., "Object oriented metrics that predict maintainability", The Journal of Systems and Software, #23. 1993. [OLS 00] OLSINA L., PONS C, Rossi G., "Towards Metric and Model Validation in Web-site QEM", In Proceedings of VI CACIC (Argentinean Congress of Computer Science), Ushuaia, Argentina, 2000. [PON 99a] PONS C. , BAUM G., FELDER M., "Foundations of Object-oriented modeling notations in a dynamic logic framework", In Fundamentals of Information Systems, Chapter 1, T.Polle, T.Ripke, K.Schewe Editors, Kluwer Academic Publisher, 1999. [PON 99b] PONS C., Ph.D Thesis, Faculty of Science, University of La Plata, Buenos Aires, Argentina, http://www-lifia.info.unlp.edu.ar/~cpons/ (1999). [POU 97] POULIN J., Measuring Software Reuse-Principles and Practices and Economical Models, Addison Wesley. 1997.


25

[PRI 97] PRICE M., DEMURJIAN, S., "Analyzing and measuring reusability in object-oriented design", in Proceedings OOPSLA '97, Atlanta, USA, 1997. [TEG 92] TEGARDEN, D. SHEETZ S., MONARCHI, D., "Effectiveness of traditional software metrics for object-oriented systems", 25th Annual Conference of System Science, Maui, HI., 1992. [UML 99] UML 1.3, Object Management Group, The Unified Modeling Language (UML) Specification - Version 1.3, in http://www.omg.org (1999). [WIE 98] WIERINGA R., BROERSEN, J., "Minima! Transition System Semantics for Lightweight Class and Behavior Diagrams", In PSMT Workshop on Precise Semantics for Software Modeling Techniques, Ed: M.Broy, D.Coleman, T.Maibaum, B.Rumpe, Technische Universitat Munchen, Report TUM-I9803, April 1998. [WIL 92] WILDE N., HUITT, R., "Maintenance support of object-oriented programs", IEEE Transactions on Software Engineering, 18, 1992. [WOO 97] WOOLF, B., "Polymorphic hierarchy", The Smalltalk Report, January 1997. [ZUS 98] ZUSE, H., A Framework of Software Measurement, Walter de Gruyter, Berlin-NY. 1998.


Chapter 2

A merit factor driven approach to the modularization of object-oriented systems Fernando Brito e Abreu and Miguel Goulao Software Engineering Group, FCT/UNL and INESC, Lisbon, Portugal

\. Introduction Modularity is an essential aspect of all engineering domains. It allows, among other things: (i) design and development of different parts of the same system by different people, often belonging to distinct organizations, (ii) the handling of the complexity of large systems by splitting loosely coupled parts that can be better understood individually, (iii) the testing of systems in a parallel fashion (different people simultaneously), (iv) substitution or repair of defective parts of a system without interfering with other parts, (v) the reuse of existing parts in different contexts, (vi) the division of the system in configuration units to be put under configuration control and (vii) restriction of defect propagation. The architecture of a software system is determined, at the more abstract level, by a set of modules and by the way they are glued together [SCH 96, p. 9]. Generically, a module can be an aggregate of algorithms' implementations and data structures that interact somehow to deliver a given kind of functionality. Each module can have its own state, shared or not, and needs the collaboration of other modules to deliver its functionality. A module should have a clear interface. A protocol should be offered to other modules, by means of some exporting mechanism that makes its interface available. It is desirable, for reasons thoroughly discussed in the software engineering literature, that modules be highly cohesive and loosely coupled [GHE 91, JAC 92, PRE 00, SOM 00]. If we consider a module to be, as we shall henceforth, a set of classes, then intramodular coupling, that is, the coupling among the classes belonging to the module, can represent module cohesion. Complementarily occurs when we talk about module coupling by which we mean inter-modular couplings, that is, those that cross module borders. These may correspond to dependencies of internal classes (those belonging to the module) on external ones, or the other way round. Modularization can be flat

28


or hierarchical (i.e. modules containing other modules). An objective criterion for modularization should be made explicit in the software documentation. With hierarchical modularization that criterion can be different at each modularization level. Modularity is an internal quality characteristic that influences external software quality characteristics, as suggested in [ISO 9126], and it can be observed at different levels of abstraction [CON 90]. During requirements specification and detailed analysis, modules are usually black boxes that facilitate the dialog and understanding between domain experts and analysts. At design level, modularity is traditionally associated with the identification of subsystems and abstract data types [EMB 88]. Software components, which are usually built as an encapsulated set of interrelated classes, can also be seen as reusable modules [SZY 98]. At source code level, modules usually correspond to operating system files, allowing separate compilation and favoring incremental development. That is why these modules are often called compilation units. At executable code level, modularity also plays an important role, as with overlays or dynamic linked libraries. In this paper we will be mainly concerned with the design level for object-oriented systems. The object-oriented paradigm, along with the spreading availability of processing power, has allowed the conception of increasingly large and complex software systems. These must be developed and integrated modularly. Although the need to aggregate classes seems to be consensual, there is, however, a lack of terminological uniformity in the designation of those aggregates or clusters, as we will see later. In C++ programming language, namespaces support modularization by providing a mechanism for expressing logical grouping [STR 97]. Packages are an important modularization mechanism in Java. They may contain any combination of interfaces (defining types) and implementations (classes) [GOS 96]. In Smalltalk development environments, such as Envy, there is also modularization support through the use of packages. During runtime, those packages are loaded in a specific order, starting with the kernel one, which defines all the primitives. In the Delphi language, an extension of Pascal for object-oriented programming, modules are called units [CAN 96]. Bertrand Meyer, the creator of the Eiffel language, empathizes a modularization abstraction, the cluster, which is the basis of his Cluster Model [MEY 95]. In OMT (Object Modeling Technique) the modularization unit is called subsystem [RUM 91]. In Objectory the same denomination is used [JAC 92]. Grady Booch proposes the word category in his method [BOO 94]. Meilir Page-Jones talks about domains and sub-domains [PAG 95]. The word package is again used in UML (Unified Modeling Language) [BOO 97] and in the Catalysis approach, where it designates any container of developed artifacts [SOU 98, p. 18]. These kinds of modules can contain classes, component specifications, component

Approach to OO systems modularization

implementations, reusable frameworks, modularization) and other deliverable types.

nested

packages

29

(hierarchical

In the above references we could only find qualitative indications to the need of modularization or, at most, some vague guidelines for grouping classes. We will show that the determination of an optimal modularization solution is feasible. This kind of information is obviously useful during the initial design phase. On the other hand, large software systems usually evolved incrementally from smaller ones. Although the initial architecture may have been acceptable, the evolution over time often causes modularity degradation, especially if the underlying criterion was not clearly enforced. At a certain time a modularity reengineering action will be required. Being able to assess the need for such action and to point out the optimal solution were some of the driving forces for the work presented herein. This paper is organized as follows. Section 2 introduces the problems faced in a quantitative approach to software modularization and proposes a theoretical framework to support it. Section 3 describes the methodological approach adopted in a large scale experiment using the proposed framework. In Section 4 the data collected in the experiment is analyzed and discussed. Related and future works are identified in the last two sections.

2. The quantitative way 2.1. How much modularity? Ivar Jacobson mentions that an object module usually has 1 to 5 classes, although he reports on a system developed with Objectory where he had as many as 17 classes [JAC 92, p. 145]. On the other hand, Bertrand Meyer advocates that software systems should be divided into modules (clusters), typically with 5 to 40 classes each and developed by 1 to 4 people [MEY 95].Also, according to him, that dimension should be such that the cluster would play an important role in the system, but not too big that it hinders its understanding by just one person after some effort. Here, as in most references on the subject, the brief quantitative citations have no supporting evidence. In a well-known reference book, Meyer recognizes that the criteria, rules and principles of software modularity are usually introduced only through qualitative definitions, although some of them may be amenable to quantitative analysis [MEY 97, p. 65]. We hope to prove that in this contribution. The question then is: given a system, to what degree should you decompose it, that is, how many modules should you consider? This question leads to the following one: how disparate in size should the modules in a given system be? There is not an answer for these questions unless we define a quantitative criterion for system sectioning. It is acceptable that the number of modules should somehow be proportional to the system size (e.g. expressed in number of classes).

30


However, such an assertion is not of a great help since the proportionality constant is not known, nor is it likely that the module density (classes per module) should be uniform. At the coding level we often find the classes completely separate (e.g. one .h and one .cpp file per class in C++). If we consider the class to be our atomic part on which modularity is concerned, this situation can be seen as the radical expression of the following criteria to define the optimal modularization size: Strawman Criterion A - The number of modules should be the maximum allowed. Since the idea of modularization is that of grouping related items (and obviously splitting the unrelated ones), criterion A is not acceptable. On the other hand, if we consider the software engineering literature, we could easily be tempted to define another criterion: Strawman Criterion B - The number of modules should be the one that maximizes the coupling among classes within each module and minimizes the coupling for those belonging to different modules. Although appealing, this assertion is nothing but a fallacy: the above number is always 1 (one module). Indeed, for a given system, starting with the extreme situation of one class per module and whatever aggregation sequence is adopted, when we reduce the number of clusters by grouping classes, the coupling between the classes within each module increases monotonically. Meanwhile, the coupling among classes belonging to different modules decreases monotonically as well(in the limit, with only one module, it equals zero)! Criterion B therefore contradicts the idea of modularization itself.

2.2. How to aggregate classes in modules? When the number of modules is fixed we get to the problem of finding the optimal grouping of classes. In the Catalysis approach the authors recognize that it is important to restrict the module (package) dependencies [SOU 98]. Again we are in presence of another qualitative statement. The authors do not explain how to achieve that reduction! The grouping problem is the aim of Cluster Analysis, a subject concerned with the classification of similar items into groups [KAU 90, ROM 90]. Cluster analysis techniques have been used in many areas such as economics, geology, botany, pattern matching and so on. The objective of clustering techniques is the grouping of items in such a way that the relations between items in the same group are stronger than the relations with items in other groups. In order to cluster a group of items, two things are required: some measure of the way each item relates to the others and a method to group them. The expression of


31

"how far" two items are, is known as the dissimilarity or distance between them. Dissimilarities can be obtained in several ways. They are often based on the values of variables that represent certain item properties. The dissimilarities between each pair of classes are usually summarized in a dissimilarities matrix, a square symmetric matrix with zeros on the main diagonal. Besides a distance measure, one also needs an algorithm to drive the clustering process, a clustering method. We have used seven well-known hierarchical agglomerative clustering methods: Single linkage, Complete linkage, Between groups linkage, Within groups linkage, Centroid, Median and Ward's methods [KAU 90]. Agglomerative methods start with all items in separate clusters and proceed in iterations joining them until the defined number of clusters is reached. In Table 1 we provide a brief description of the clustering methods we use. For all the previous methods, the clusters to be merged in each stage are the ones whose distance (as defined in the second column of Table 1) is the shortest. We also used the Ward clustering method, which is somewhat different from the others. It departs from the consideration that at each stage the loss of information that results from the grouping of individuals into clusters can be measured by the total sum of squared deviations of every point from the mean of the cluster to which it belongs. So, this method calculates, for each case, the squared Euclidean distance to the cluster means; these distances are summed for all the cases; at each step, the two clusters that result in the smallest increase in the overall sum of the squared withincluster distance are combined. Table 1. Clustering methods Method name

The distance between two groups is ...

Single linkage

. . . the distance between their closest members.

(nearest neighbor) Complete linkage (furthest neighbor) Between-groups linkage (group average)

. . . the distance between their most remote pair of items (opposite of single linkage). ... the average of the distances between all pairs of individuals in the two groups.

Within-groups linkage

... the average of the distances between all pairs of cases in the cluster that would result if they were combined.

Centroid

... the distance between the group centroids, that is the distance between their means, for all of the items.

Median

. . . similar to the centroid but it weights equally the two groups to combine, in the calculation of the centroid.

32


Due to the nature of our problem - clustering classes in modules - we have to identify how to express the dissimilarities among the classes. Although the solution to this problem has been pointed out long ago, based upon the cohesion (intramodular coupling) and inter-modular coupling [STE 74], we have not yet seen it applied elsewhere in a quantitative way to object-oriented systems by using cluster analysis. Therefore we state the following modularization criterion: Woodenman Criterion C - Given a constant number of classes and modules, the aggregation of classes should be the one that maximizes the coupling among classes within each module and minimizes it for classes belonging to different modules. The coupling between two classes can be characterized by the number of coupling instances discriminated by type. Several authors have proposed coupling taxonomies in the realm of the OO paradigm [BR1 99, HIT 96, LOU 97, POE 98]. In [ABR 00] we have introduced another taxonomy with GOODLY in mind. GOODLY (a Generic Object Oriented Design Language? Yes!) is an intermediate formalism used to specify the design of systems built according to the object oriented paradigm [ABR 99]. The taxonomy used includes the following coupling categories: Direct Inheritance (DI), Class Parameter (CP), Attribute Type (AT), Employed Attribute (EA), Parameter in Operation (PO), Parameter in Message (PM), Parameter in Call (PC), Return in Operation (RO), Return in Message (RM), Return in Call(RC), Local Attribute in Operation (LA) and Message Recipient (MR). The more coupling instances there are between two classes, the stronger is their interconnection strength, which we call affinity. We hypothesize that different coupling types may contribute differently to the affinity. We have used several schemes of combination of the available coupling information to derive different affinity values. These schemes were named as Unweighted Binary (UB), Weighted Binary (WB), Unweighted Additive (UA), Weighted Additive (WA) and Unweighted Multiplicative (UM). Their exact mathematical definition can be found in Table 2.


33

Table 2. Affinity rating schemes Scheme

Definition MR

Unweighted

A UB ( I, J) = E. Ccc(i,j)

Binary

cc=DI MR A wB (i, J) = Ea cc C cc(i , J) cc=DI MR

Weighted Binary Unweighted

A UA (i, J)= E N C C (i, J)

Additive

cc=DI MR

Weighted Additive

AWA(i, j) =

Ea c c N c c (i,j)

cc=DI

MR

Unweighted A

Multiplicative

U M ( i , J)

= Yl N cc(i, J) cc=DI

where: acc - positive non-null weight associated with a given "CC" coupling category; Ccc(i, J) - predicate with values 1 or 0 stating whether classes "i" and "j" are coupled by at least one CC type of coupling or not; Ncc(i,j) - number of instances of CC coupling type, between classes "i" and "j". In the multiplicative schemes, only terms with non-zero Ncc(i, j) value are considered. The weights used in some of these rating schemes (the "weighted" ones, obviously) vary in the range [1, 10] and are calculated with information extracted from the original solution. Each weight for a given coupling category is given by:

10 1

a,.,. =

CI

Round(0,5 +10 x CC

+ CI

=0

CI

=0

CCIN =0^ CI

CCOUT

otherwise

CCIN

CCIN

CI cCCIN # 0 ^ CIccout

CCOUT

where CI CCIN and CIcCOUT are, respectively, the number of intra-modular and inter-modular coupling instances for that category in the original modularization

34


proposal. This technique partially preserves the original modularization criteria, at least as their developers perceived it. From the affinity values A(i, j), we calculate the dissimilarities D(i,j) among classes using the following transformation:

This standardization transformation guarantees that D(i, J) e[0, 1]. Classes with low affinity have high dissimilarity and vice-versa. With couplings rated according to the proposed schemes, and using this transformation, we can produce 5 dissimilarity matrices, one for each distinct scheme. Since we use 7 clustering methods, we obtain 35 distinct modularization solutions for a given number of modules. If we vary the number of modules in the interval J1, NC/, where NC is the total number of classes, then the number of configurations NS to evaluate, in order to select the best one, is given by:

For instance, a system with 100 classes would have 3430 alternatives. This takes us back to the problem of finding an adequate criterion to select the best among these alternatives.

2.3. A dual decision modularization criterion Criterion C is incomplete since it implies that we already know how many clusters we should have. To solve the problem of finding the most adequate number of clusters, we herein propose the following quantitative modularization criterion: Ironman criterion D - The number of modules should maximize the Modularization Merit Factor. The Modularization Merit Factor, henceforth designated by the MMF acronym, is defined as:

where: ICD = CCIN / CCTOT = Intra-modular Coupling Density AMM = NC / NM = Average Module Membership


35

CCIN = Class Couplings within modules CCOUT = Class Couplings between modules CCTOT = CC1N + CCOUT = Total class couplings NM = Number of Modules NC - Number of Classes The rationale for this metric is the following: 1. when NM and NC are held constant, the modularization will be better if the Intra-modular Coupling Density (ICD) increases; 2. when NC and ICD are held constant, the modularization will be better if the number of modules (NM) increases; in other words, we should split the system as much as possible, as long as ICD is not sacrificed (reduced); 3. when NM and ICD are held constant, the modularization will be worst when the number of classes increases, because we would then be increasing the average module membership without increasing ICD.

Figure 1. MMF versus number of modules

Figure 1 shows the dependency of MMF and its components (intra-modular coupling density and the inverse of the average module membership) on the number of modules for a fixed number of classes. The values were taken from one system of our sample described in Appendix A. The MMF curves for the other systems have similar shapes, all with an identifiable maximum. Notice that ICD E [0,1] and 1/AMM e [0,1]. Therefore, MMF is necessarily restrained to the interval [0,1]. Criterion D does not account for the dispersion on the module sizes. If we simply use it to seize the best solution, the distribution of the module sizes would be highly skewed since the maximization of ICD would lead to a situation where we would have one module with a large membership and all the rest with very few classes, often only one. This configuration still guarantees that the average module

36


membership (AMM) is kept low, but does not consider its dispersion, as mentioned previously. Therefore, we add a second modularization criterion: Ironman criterion E - The dispersion of the module size in the system should be constrained. We have chosen a common dispersion measure, the standard deviation, and applied its formula considering that we are dealing with the complete population of modules. We then obtain the following formula where CMm is the number of classes in module m.

To find the most adequate solution we are faced with a multiple decision criteria problem. Our approach to this problem was to apply first the MMF-based criterion to select a subset of the best modularization solutions (e.g. 10% of the generated alternatives) and then apply the second criterion to this subset to derive the proposed "best" solution. This order reflects our view that criterion D is more important than criterion E.

3. The methodological approach 3.1. Hypothesis We hypothesized that current software systems are far from taking full advantage of the modularization mechanisms provided by OO design (a). The defined theoretical framework to guide the process of partitioning OO systems into clusters showed that this task is feasible. Our experiment aimed at demonstrating that, with appropriate tool support, this task is also easy to accomplish (b). All of the mentioned clustering methods and affinity rating schemes were tried. It is likely that the selection of a particular clustering method has an impact on the computed cluster organization (c). A similar reasoning can be applied to affinity rating schemes (d).

3.2. The experiment To evaluate these hypotheses we designed and conducted a controlled experiment. This experiment consisted basically on computing optimal


37

modularization solutions for a relatively large set of OO software systems and then evaluating how far the original modularization solutions were from them. While doing so, the feasibility and easiness hypothesis (b) was evaluated. After completing the computation of the MMFs for all the systems in our sample, we used data analysis techniques to discuss hypotheses (a), (c) and (d).

Figure 2. The MOTTO tool

The MOTTO tool was used to compute a range of the best values for MMF while applying criterion D and then, from that range, selecting the optimal value for MMF based on the application of criterion E. MOTTO (Modularization Trial Tool for Object Oriented systems) was developed at INESC and is used in conjunction with MOODK1T G2 described elsewhere [ABR 00] and SPSS, a commercial statistical package tool. MOODKIT G2 generates GOODLY code both from design models or code. The same tool produces the coupling relations information that serves as input for MOTTO. The latter then computes the dissimilarity matrices for the selected rating schemes and generates SPSS scripts for the requested cluster methods and for the given cluster number interval. A SPSS batch facility is then invoked by MOTTO to compute alternative clustering solutions. These are then used by MOTTO to generate matrices of MMF values (one for each cluster number) that are then used to apply the mentioned criteria to derive the optimal solution.

38


3.3. Experimental design 3.3.1. Data The input to this experiment consists on a sample of specifications of OO systems briefly described in Appendix A. The columns represent the system name, type (Application, LIBrary and Environment), the formalism from which the GOODLY code was generated, and counts of classes and couplings and two other columns that will be explained later in this paper. However, the bulk of the input data consists of typified class coupling instances that are used to calculate the affinity between classes and, from those, the dissimilarities matrix required as input by the clustering methods. 3.3.2. Threats to internal validity A possible threat to this sort of experiment is the existence of unknown factors that may influence the MMF values. By conducting an experiment that is fully reproducible (in the sense that given the same inputs, i.e., the analyzed systems, the results of the experiment described are always the same) this risk is somewhat minimized. Nevertheless, there is a potential problem in the experiment design: all the original systems are converted from their source formalism to GOODLY. For instance, Smalltalk is a weakly typed language while GOODLY is a strongly typed one. To be able to fully capture the exact class couplings in the translation from Smalltalk to GOODLY would require a much more powerful type inference mechanism than the one available in MOODK1T G2. Any loss of information caused by the conversion may have an effect on the conclusions derived from the analysis of theGOODLYAversion of the specification. 3.3.3. Threats to external validity Since one goal is to generalize the results of this experiment, the representativity of our sample is a main concern here. To mitigate this problem, we chose a relatively large sample comprising 21 OO systems, totaling 1224 classes. The following criteria were used while selecting the cases: - systems should have some diversity; this is achieved with specifications of different programming languages, different types (libraries, environment, or applications), different application domains and different sizes; - systems should be in use for several years or be produced in a recognized academic setting, so that their design structure would have been as carefully engineered or had time to be refined by human experts. 3.3.4. Analysis Strategy Our first step is to analyze some descriptive statistics on the computed merit factors. This is important as it allows us to choose adequate statistical tests to explore our hypotheses. Possible relationships between MMF and the configuration


39

options available for their computation (clustering methods and affinity rating schemes) are also investigated, using standard analysis of variance methods (hypothesis (c) and (d)). The distance between the proposed optimal solution and the implemented one is then computed. This allows us to test hypothesis (a).

3.4. Conducting the experiment The experiment consists of computing the MMFs for our systems sample. The experimental process is relatively straightforward as most tasks are fully automated by the MOTTO tool. To provide the reader with an idea of the time involved in computing the best MMF for a given system, here is an example: suppose an experienced MOTTO user wishes to compute the best MMF for a given combination of clustering method and weighting scheme. On a Pentium III @500MHz, with 256Mb of RAM and 1Gb of virtual memory, the times presented in Table 3 were registered for 3 different systems. These elapsed times include the minimum required user interaction with the tool. It should be noted that for these three examples the amount of human interaction with MOTTO is the same. It consists in selecting a specification and then launching in sequence all the production commands needed to compute the best MMF. Table 3. MOTTO benchmark System Structure Stix GNUSmallTalk

Classes 14 110 246

Couplings 713 4119 6934

Elapsed time 00m:28s 02m:50s llm:29s

4. Data analysis 4.1. Choosing a clustering method Seven clustering methods are used in this experiment. Different clustering methods may point to different clustering solutions and therefore to different MMFs. We can speculate that some methods lead to better solutions than others. As a null hypothesis (H0), we assume that there are no significant differences between the MMFs computed by all the methods. The alternative hypothesis (H1 is that there are significant differences for at least one of the methods.

40


We use a one way analysis of variance (ANOVA) of the best MMFs obtained with each clustering method, to test the null hypothesis. Table 4 presents the results of this test. Table 4. ANOVA test for clustering methods

dof Between Groups Within Groups Total

6 876 882

F Sig. Sum of Mean Squares Square .439 47.936 .000 2.633 .009 8.009 10.642

Table 4 gives us diagnostics concerning between-groups variance and within groups variance. The first data column gives us the degrees of freedom (dof) connected with both the between-groups variance (number of groups - 1) and the within-groups variance (number of observations - number of groups). The sum of squares is presented next to the mean square. The statistic to check the null hypothesis is the ratio between the mean squares between groups and the mean squares within groups. The high value for the F statistic allows us to reject the null hypothesis. The significance of the test tells us that the probability that these results occurred by chance is approximately zero. Therefore, we can reject H0 and assume H1 the coupling method chosen has an influence in the value of the MMF. A Tukey-HSD (Tukey's Honestly Significant Difference) test with a .050 significance level will show where the difference discovered with the ANOVA really occurs (Table 5). The rows in Table 5 display the mean for the best MMF obtained with the corresponding clustering method within our sample of systems. Methods are grouped in homogeneous subsets (columns 1 through 4). There, we can observe that the SL (Single Linkage) method is the one that provides the best coupling solutions, according to MMF.


41

Table 5. Tukey-HSD test for clustering methods

Clustering Method CL WM WG BG MM CM SL

Subset for alpha = .05 2 3 1 4 .229 .232 .265 .286 .326 .341 .387

At the other extreme, CL (Complete Linkage) and WM (Ward Method) provide the less optimized solutions. The conclusion is that if we were to select only one of the clustering methods based on the MMFs obtained with this sample of OO systems, then SL would be the preferred one. The SL method defines the distance between groups as the distance between their closest members. 4.2. Choosing an affinity rating scheme The MOTTO tool provides 6 different affinity rating schemes. We hypothesize that different schemes may lead to different coupling solutions. A similar approach to the one used with the clustering method can shed some light on this issue. As a null hypothesis, we will assume the rating scheme has no influence in the MMF. The alternative hypothesis states that that influence exists.

Table 6 presents the results of the ANOVA test. Table 6. ANOVA test for affinity rating schemes

df

Between Groups Within Groups Total

F Sum of Mean Sig. Squares Square 5 1.077 .215 19.734 .000 877 9.565 .011 882 10.642

42


The F statistic value and its significance level confirm that we can reject our null hypothesis. As expected, the chosen rating scheme does have an influence on the selected cluster solutions and, consequently, on the MMF. A Tukey-HSD test (Table 7) shows that the binary schemes seem to lead to lower MMFs than their multiplicative and additive counterparts. Another interesting feature about this is that all the unweighted schemes had a slight advantage when compared to their weighted peers. Although the gap is relatively small, the whole purpose of including weights is to improve the performance of the rating schemes. In short, these results suggest that the weights need some calibration to become more effective. Table 7. Tukey-HSD test for affinity rating schemes

Affinity Rating Scheme WB UB WM WA UM UA

Subset for alpha = .05 1 .235 .263

2

.299 .321 .324 .329

4.3. Modularization usage level Earlier in this paper, we hypothesized that current software systems are far from taking full advantage of the modularization mechanisms provided by OO design. We computed the optimal couplings for our sample of software systems, OPT_MMF, and then defined IMP_MMF as the MMF computed for the implemented system. These values are represented in Appendix A. Figure 3 represents the IMP_MMF score against the optimal OPTJVIMF, in each pair of vertical bars. The vertical scale represents the MMF score, which can theoretically vary between 0 and 1. We can observe that the large majority of the systems obtain a significantly lower score with IMP_MMF. About 20% of the implementations use a larger number of modules than the one required by the optimal modularization. This means that classes are scattered throughout an excessive number of modules, thus creating unnecessary coupling between modules relationships. The majority of systems, however, should be split into more modules. Indeed, about 80% of the implementations had some classes with low affinity stored into the same module. This reduces the cohesion within the modules.


43

Figure 3. Implemented versus optimal MMF

5. Related work 5.1. Cluster analysis in procedural systems Clustering techniques have been applied in system structure recovering and identification of abstract data types in the context of reengineering of procedural based systems. They derive some similarity or dissimilarity measures based on the sharing of characteristics such as data structures or the existence of procedural calls. A study to evaluate module-generating techniques, to help reducing the scope of errors, is presented in [HUT 85]. Four types of data bindings are used there to determine how two procedures are related. Two dissimilarity measures are presented and the authors use single linkage and a variation of this method to do the clustering. In [SCH 91] a tool is presented for maintaining large software systems. The tool supports the grouping of related procedures into modules. The author proposes a similarity measure for procedures that is a function of the design information they share. A clustering algorithm is used to group related procedures into modules. The tool also allows finding procedures that seem to have been assigned to the wrong module. The approach presented in [KUN 96] proposes a measure to evaluate the design of distributed applications, with several communicating processes. The similarity measure between pairs of processes uses data types related to communication. The

44


author also applied hierarchical clustering algorithms for automatic generation of process hierarchies. Cluster analysis was also used in [PER 98] to derive hierarchies of modules. Procedures are related using a dissimilarity measure that uses characteristics shared by the procedures. Several clustering algorithms were implemented in a tool that allows the specification of groups of characteristics to be considered in each analysis. None of the works mentioned refer to object-oriented software systems. 5.2. Modularity analysis in OO systems The evaluation of modularity in OO systems is a current research topic. In [POE 98] a modularity assessment technique based on the coupling strength of MERODE domain object classes is used. MERODE is an OO approach to modeldriven development [SNO 98]. Two metrics for evaluating the modularity of OO frameworks: Variation points as Interfaces (VI) and Interface Coupling (1C) are proposed in [PRE 98]. None of those studies employs clustering techniques. 6. Future work This paper described the steps followed while using cluster analysis techniques and class-coupling information to obtain modularization solutions in the realm of object-oriented systems. The approach presented can be used both in the initial design phase and in the reengineering of object-oriented legacy systems, allowing identification of illdefined modularization situations and proposing alternative ones. Although cluster analysis techniques have been applied in procedural systems, we have not yet seen them applied in the context of OO systems. We hope this paper will contribute to foster this research area. We plan to apply other multiple decision criteria techniques, currently used in the operations research world, to the problem we described in this paper. The approach advocated here considers structural coupling only, and that may not match semantic coupling. We argue, but cannot prove here, that the latter causes the appearance of the former in coupling relations such as inheritance, aggregation or message passing ones. On the other hand, counter example situations may arise. In a graphical widgets library, for instance, the Arc and Rectangle classes could be completely apart but still it could make sense to include them in the same module since they both are two-dimension geometric figures. Nevertheless, our approach is


45

completely generic and applicable as long as it will be possible to express quantitatively the semantic association between each pair of classes. The work presented does not yet consider hierarchical modularization, which is a very important aspect when considering very large systems. Here we could argue that we could apply our approach in a stepwise manner, by first splitting the system into a given number of subsystems (e.g. fixing its number), and then applying the same approach again within each subsystem to identify nested packages. In the near future we intend to apply this nested approach, possibly using different criteria at each abstraction level.

7. References [ABR 99] F. B. ABREU, L. M. OCHOA, M. A. GOULAO, "The GOODLY Design Language for MOOD2 Metrics Collection", presented at the ECOOP Workshop on Quantitative Approaches in Object-Oriented Software Engineering, Lisboa, Portugal, 1999. [ABR 00] F. B. ABREU, G. PEREIRA, P. SOUSA, "A Coupling-Guided Cluster Analysis Approach to Reengineer the Modularity of Object-Oriented Systems", presented at the 4th European Conference on Software Maintenance and Reengineering (CSMR'2000), Zurich, Switzerland, 2000. [BOO 94] G. BOOCH, Object Oriented Analysis and Design with Applications, 2nd ed. Redwood City, LA, USA, The Benjamin Cummings Publishing Company Inc, 1994. [BOO 97] G. BOOCH, I. JACOBSON, J. RUMBAUGH, "UML Semantics", Rational Software Corporation Version 1.0, January 1997. [BRI 99] L. BRIAND, J. W. DALY, J. K. WUST, "A Unified Framework for Coupling Measurement in Object-Oriented Systems", IEEE Transactions on Software Engineering, Vol. 25, No. 1, 1999. [CAN 96] M. CANTU, Mastering Delphi 2 for Windows 95/NT, Sybex, 1996. [CON 90] L. L. CONSTANTINE, "Object-oriented and function-oriented software structure", Computer Language, Vol. 7, p. 34-56, January, 1990. [EMB 88] D. W. EMBLEY, S. N. WOODFIELD, "Assessing the Quality of Abstract Data Types Written in Ada", presented at the International Conference on Software Engineering (10th ICSE), 1988. [GHE 91] C. GHEZZI, M. JAZAYERI, D. MANDRIOLI, Fundamentals of Software Engineering. Englewood Cliffs, NJ, USA, Prentice Hall, 1991. [GOS 96] J. GOSLING, F. YELLIN, The Java Application Programming Interface, Vol. #1 (Core Packages)/#2 (Window Toolkit and Applets), Reading, Massachussets, USA, Addison-Wesley, 1996. [HIT 96] M. HITZ, B. MONTAZERI, "Measuring Coupling in Object-Oriented Systems", Object Currents, April, 1996.

46


[HUT 85] D. H. HuTCHENS,V. R. BASILI, "System Structure Analysis: Clustering with Data Bindings", IEEE Transactions on Software Engineering, Vol. 11, No. 8, p. 749-757, August, 1985. [ISO 9126] ISO9126, Information Technology - Software Product Evaluation - Software Quality Characteristics and Metrics, Geneva, Switzerland, ISO. [JAC 92] I. JACOBSON, M. CHRISTERSON, P. JONSSON, G. OVERGAARD, Object-Oriented Software Engineering- A Use Case Driven Approach, Reading, MA, USA/Wokingham, England, Addison-Wesley/ACM Press, 1992. [KAU 90] L. KAUFMA, P. J. ROUSSEEUW, Finding Groups In Data: An Introduction To Cluster Analysis, John Wiley and Sons, 1990. [KUN 96] T. KUNZ, "Evaluating Process Clusters to Support Automatic Program Understanding", presented at the 4th Workshop on Program Comprehension, 1996. [LOU 97] H. LOUNIS, H. SAHRAOUI, W. MELO, "Defining, Measuring and Using Coupling Metrics in OO Environment", presented at the OOPSLA Workshop on Object Oriented Product Metrics, Atlanta, USA, 1997. [MEY 95] B. MEYER, Object Success - A Manager's Guide to Object Orientation, its Impact on the Corporation, and its Use for Reengineering the Software Process, Prentice Hall International, 1995. [MEY 97] B. MEYER, Object-Oriented Software Construction, 2nd ed. Upper Saddle River, NJ, USA, Prentice Hall PTR, 1997. [PAG 95] M. PAGE-JONES, What Every Programmer Should Know about Object-Oriented Design, New York, USA, Dorset House, 1995. [PER 98] G. M. PEREIRA, Reengenharia da Modularidade de Sistemas de Informacao, in Departamento de Engenharia Electrotecnica e Computadores. Lisboa, Portugal: master thesis, IST/UTL, 1998. [POE 98] G. POELS, "Evaluating the Modularity of Model-Driven Object-Oriented Software Architectures", presented at the ECOOP Workshop on Techniques, Tools and Formalisms for Capturing and Assessing Architectural Quality in Object-Oriented Software, Brussels, Belgium, 1998. [PRE 98] P. PREDONZANI, G. Succi, A. VALERIO, "Object-oriented frameworks: architecture adaptability", presented at the ECOOP Workshop on Techniques, Tools and Formalisms for Capturing and Assessing Architectural Quality in Object-Oriented Software, Brussels, Belgium, 1998. [PRE 00] R. S. PRESSMAN, Software Engineering: A Practitioner's Approach (European Adaptation), 5th ed., McGraw-Hill Book Company, 2000. [ROM 90] H. C. ROMESBURG, Cluster Analysis for Researchers, Malabar, Florida, USA, Robert E. Krieger Publishing Company, 1990. [RUM 91] J. RUMBAUGH, M. BLAHA, W. PREMERLANI, F. EDDY, W. LORENSEN, ObjectOriented Modelling and Design, Englewood Cliffs, NJ, EUA, Prentice Hall, 1991.


47

[SCH 96] S. R. SCHACH, Classical and Object-Oriented Software Engineering, 3rd ed. Burr Ridge, Illinois, USA, Richard D. Irwin, 1996. [SCH 91] R. W. SCHWANKE, "An Intelligent Tool For Re-enginnering Software Modularity", presented at the 13th International Conference on Software Engineering (ICSE'91), 1991. [SNO 98] M. SNOECK, G. DEDENE, "Existence Dependency: The Key to Semantic Integrity Between Structural and Behavioral Aspects of Object Types", IEEE Transactions on Software Engineering, Vol. 24, No. 4, April, 1998. [SOM 00] I. SOMMERVILLE, Software Engineering, 6th ed., Addison-Wesley Longman, 2000. [SOU 98] D. F. D'SOUZA, A. C. WILLS, Objects, Components and Frameworks with UML: The Catalysis Approach, Reading, Massachussets, Addison Wesley Longman, 1998. [STE 74] W. P. STEVENS, G. J. MYERS, L. L. CONSTANTINE, "Structured Design", IBM Systems Journal, Vol. 13, No. 2, p. 115-139, 1974. [STR 97] B. STROUSTRUP, The C++ Programming Language, 3rd ed. Reading, Massachusetts, USA, Addison-Wesley Publishing Company, 1997. [SZY 98] C. SZYPERSKI, Component Software: Beyond Object-Oriented Programming, New York, ACM Press/Addison-Wesley, 1998.

Appendix A Specification

Type

Formalism

Classes Total couplings MMF cur MMF opt

Allegro

APP

Eiffel

33

3534

0.061

0.535

Port of the Allegro game programming library to the SmallEiffel Eiffel Compiler. Bast

APP

SmallTalk

38

587

0.102

0.380

Object-oriented framework for building fault-tolerant distributed applications. Blox

APP

SmallTalk

42

1264

0.048

0.365

GUI building block tool kit. It is an abstraction on top of the platform's native GUI toolkit that is common across all platforms. BoochApp

APP

Eiffel

18

115

0.000

0.634

2894

0.014

0.449

Small application to test the BoochTower library. BoochTower

LIB

Eiffel

130

Library of structure components such as bags, graphs, lists, stacks, strings, trees... Canfield

APP

Eiffel

9

47

0.000

0.439

APP

SmallTalk

20

26

0.154

0.364

12

52

0.018

0.373

A solitaire game. Cxtnsn

C based extensions to GNU Smalltalk. dinamico

LIB

Delphi

Abstract Data Types library.

48


Ems APP Eiffel 111 3370 0.022 0.436 Lexical analyzer that takes a list of classes in input and returns the analysis to the standard output. 18

146

0.164

0.377

Gma LIB Delphi 46 Graphics package developed in Delphi.

139

0.231

0.407

GNU_SmallTalk ENV SmallTalk 246 6934 Implementation of Smalltalk-80 under GNU's public license.

0.013

0.408

GPCardGames APP SmallTalk Implementation of card games.

0.063

0.422

funcao3d APP 3D functions viewer.

Delphi

20

362

Gobo LIB Eiffel 119 4563 0.034 0.467 Eiffel libraries portable across various Eiffel compilers including: a Kernel Library, a Structure Library and an Utility Library. SIG_Container LIB Eiffel Containers library for SIG Eiffel.

47

1215

0.042

0.396

SIG_DateTime LIB Eiffel Date and Time library for SIG Eiffel.

20

929

0.153

0.549

SIG_Eiffel ENV Eiffel 79 SIG Eiffel programming environment.

7531

0.030

0.478

SIG_Libraries LIB Libraries for SIG Eiffel.

2509

0.035

0.452

Eiffel

34

Stix APP SmallTalk 110 4119 0.018 0.414 SmallTalk Interface to the X protocol layer that underlies all of X Windows. Structure LIB Eiffel 14 713 A data structure library based on circular-linked-lists.

0.098

0.525

Yoocc LIB Eiffel 58 457 0.054 0.461 Compiler-compiler that uses an extended parse library which derives from the ISE Eiffel parse library. Legend: MMF cur - Current (observed) MMF

MMFopt - Optimal MMF

Chapter 3

Object-relational database metrics Mario Piattini and Coral Calero Dept of Computer Science, University of Castilla-La Mancha, Spain

Houari Sahraoui Dept d'Informatique et Recherche Operationelle, Universite de Montreal, Canada

Hakim Lounis Dept d'Informatique, Universite de Quebec, Montreal, Canada

1. Introduction Metrics for databases have been neglected in the metric community ([SNE 98]). Most all of the metrics proposed from the McCabe ([MCA 76]) famous cyclomatic number until today have been centered in measuring programs complexity. However, in modern information systems (IS) databases have become a crucial component, so there is a need to propose and study some measures to assess its quality. It is important that databases are evaluated for every relevant quality characteristic using validated or widely accepted metrics. These metrics could help designers to choose the most maintainable, among semantically equivalent alternative schemata. Moreover, the object-relational databases will replace relational systems to become the next great wave of databases ([STO 99]) so it is fundamental to propose metrics for control of the quality of this kind of databases. Database quality depends on several factors, one of which is maintainability ([ISO 94]). Maintenance is considered the most important concern for modern IS departments and requires greater attention by the software community ([FRA 92], [MCL 92], [PIG 97]). Maintainability is affected by understandability, modifiability and probability which depend on complexity ([LI 87]). Three types of complexity can be distinguished (HEN 96]): human factor complexity, problem complexity and product complexity. We focus our work in this last kind of complexity. We have put forward different measures (for internal attributes) in order to measure the complexity that affects the maintainability (an external attribute) of the objectrelational databases which is useful for control of its quality.

50


In this contribution we present, in Section 2, the framework used for metrics definition, metrics proposed for object-relational databases appear in Section 3. In Section 4 we present the formal verification of some of the metrics. We discuss two experiments made to validate our metrics in Section 5. In this section both experiments and the results obtained for each are described. Finally, conclusions and future work are discussed in the last section.

2. A framework for developing and validating database metrics As stated previously, our goal is to define metrics for controlling objectrelational databases maintainability, through metrics that capture complexity. But metrics definition must be made in a methodological way; it is necessary to follow a number of steps for ensure the reliability of the proposed metrics. Figure 1 presents the method we apply for the metrics proposal. The first step is the metrics proposal. This step must be made taking into account the specific characteristics of the object-relational databases and the experience of database designers and administrators of these databases. One methodological way to create the metrics proposal is by following the Goal-Question-Metric (GQM) approach. The goal of this approach is based in the fact that any metric can be defined by a top-down design with three levels, the conceptual level (Goal) where the objectives are defined, the operational level (Question) where the questions are made and the quantitative level where the metrics are defined. In this way, the goal is defined by a set of questions and every question is redefined through a set of metrics.

Figure 1. Steps followed in the definition and validation of the database metrics

Object-relational database metrics

51

It is also important to validate the metrics from a formal point of view in order to ensure its usefulness. Several frameworks for measuring characterization have been proposed. Some of them ([BRI 96], [WEY 88], [BRI 97]) are based on axiomatic approaches. The goal of these approaches is merely definitional by proposing formally desirable properties for measures for a given software attribute, so axioms must be used as guidelines for the definition of a measure. Others ([ZUS 98}) are based on measurement theory which specifies the general framework in which measures should be defined. However, research is needed into aspects of software measurement, ([NEI 94]), both from the theoretical but also from a practical point of view ([GLA 96]). So it is necessary to do experiments to validate the metrics. Empirical validation can be used to investigate the association between proposed software metrics and other indicators of software quality such as maintainability ([HAR 98]). So, the goal is to prove the practical utility of the proposed metrics. There are a lot of ways to do so but basically we can divide the empirical validation in two: experimentation and case studies. Experimentation is usually carried out using controlled experiments and the case studies usually work with real data. Both of them are necessary, the controlled experiments for a first approach and the case studies for reinforcing the results. In both cases, the results are analyzed using either statistical tests or advanced techniques. Also, it is necessary to replicat the experiment because with isolated experimental results it is difficult to understand how widely applicable the results are and, thus, to assess the true contribution to the field ([BAS 99]). As we can see in Figure 2, the process of defining and validating database metrics is evolutionary and iterative. As a result of the feedback, themetrics could be redefined by discarding, depending on the theoretical, empirical or psychological validations. In the rest of this paper we will demonstrate the different steps of the framework applied to obtain metrics for object-relational databases.

3. Object-relational metrics definition One of the problems of relational databases is related to representativeness limitations (complex elements which are present in several domain like graphics, geography are hard to represent). On the other hand, object oriented (OO) databases are not enough mature to be accepted, and it is really difficult to convert relational specialists and to convince managers to adopt this new paradigm with all the possible risks involved. From this point of view, the object-relational paradigm proposes a good compromise between both worlds. Object-relational databases combine traditional database characteristics (data model, recovery, security, concurrency, high-level language, etc) with object-oriented principles (e.g. encapsulation, generalization, aggregation, polymorphism etc). These products offer the possibility of defining

52


classes or abstract data types, in addition to tables, primary and foreign keys and constraints', as do relational databases. Furthermore, generalization hierarchies can be defined between classes (super and subclasses) and between tables, subtables and supertables. Table attributes can be defined in a simple domain, e.g. CHAR(25), or in a user-defined class as a complex number or image. In Figure 2 we present an example of two objectrelational tables definition. In this example we can notice that part of the data is expressed using relational concepts (tables, primary and foreign keys and references) and the other part using OO concepts (types, and methods). The richness of the resulting model somewhat increases its complexity ([STO 99]). For this reason it is very important to have metrics that allow for the complexity of this kind of databases to be controlled. CREATE TABLE subs( idsubs INTEGER, name VARCHAR(20), subs_add address, PRIMARY KEY (idsubs));

CREATE TYPE address AS( street CHAR(30), city CHAR(20), state CHAR(2), zip INTEGER);

CREATE TABLE dep( iddep INTEGER, name VARCHAR(20), depjoc location, budget DECIMAL (8,2), PRIMARY KEY (iddep));

CREATE TYPE location AS( building CHAR(4), office CHAR(4), table CHAR(4);

CREATE TABLE subs-dep( idsubs INTEGER, iddep INTEGER PRIMARY KEY (idsubs,iddep), FOREIGN KEY idsubs REFERENCES subs(idsubs) FOREIGN KEY iddep REFERENCES dep(iddep)); CREATE TABLE employee( idemp INTEGER, name VARCHAR2(40), emp_date date, emp_loc location, emp_add address, manager INTEGER, dep INTEGER, PRIMARY KEY (idemp), FOREIGN KEY manager REFERENCES employee(idemp), FOREIGN KEY dep REFERENCES dep(iddep));

Figure 2. Example of table definition in SQL: 1999 I. In this first approximation constraints are not considered for measure purposes.


53553

For this kind of database we can propose table related metrics (when we apply the metrics to a table) and schema oriented metrics (when the metrics are applied to the schema).

3.1. Table level metrics At the table level we propose, T being a table, the metrics DRT(T), RD(T), PCC(T), NIC(T), NSC(T) and TS defined as follows: - DRT(T) metric. Depth of relational tree of a table T (DRT(T)) is defined as the longest referential path between tables, from the table T to any other table in the schema database - RD(T) metric. Referential Degree of a table T (RD(T)) is defined as the number of foreign keys in the table T. - PCC(T) metric. Percentage of complex columns of a table T. -NIC(T) metric. Number of involved classes. This measures the number of all classes that compose the types of the complex columns of T using the generalization and the aggregation relationships. - NSC(T) metric. Number of shared classes. This measures the number of involved classes for T that are used by other tables. - TS metric. The table size metric is defined as the sum of the total size of the simple columns (TSSC) and the total size of the complex columns (TSCC); each of these complex columns can be a class or an user defined type UDT) in the table:

We consider that all simple columns have a size equal to one, then the TSSC metric is equal to the number of simple attributes in the table (NSA).

And the TSCC is defined as the sum of each complex column size (CCS): NCC being the number of complex columns in the table. The value for CCS is obtained by:

SHC being the size of the hierarchy above which the column is defined and NCU is the number of columns defined above this hierarchy. This expression arises from the fact that the understandablility is less if more than one column is defined above

54


the same class. If the number of columns that are defined above a class is greater than one, the complexity of this class decreases (in respect to each column, but not for the total columns) and this fact must be acknowledged when we calculate the complexity of a class. The SHC may be defined as the sum of each class size in the hierarchy (SC): NCH being the number of classes in the hierarchy. The size of a class is defined as:

SAC being the sum of the size attributes of the class, SMC the size methods of the class and NHC the number of hierarchies to which the class pertains. The attributes of a class may also be simple or complex (which can be a class or an UDT), then the SAC is defined as the sum of the simple attributes size (SAS, that have size equal to one; then the metric corresponds to the number of simple attributes) and the complex attributes size (CAS) in the class.

and the SMC is calculated with the version of the cyclomatic complexity of McCabe given by ([LI 93]): NMC being the number of methods in the class

3.2. Schema level metrics At the schema level, we can apply the next metrics: -DRT metric. Depth of referential Tree, defined of the longest referential path between tables in the database schema. — RD metric. Referential Degree is defined as the number of foreign keys in the schema database. — PCC metric. Percentage of complex columns in the schema database. — NIC metric. Number of involved classes, number of all classes that composes the types of the complex columns, using the generalization and aggregation relationships of all tables in the schema. - NSC metric. Number of shared classes, number of shared classes by tables of the schema.


55

- SS metric. Size of a schema defined as the sum of the tables size (TS) in the schema: NT being the number of tables in the schema.

3.3. Example We present the values for the different metrics for the example presented in Figure 2. Let us assume that the date type has a size equal to one. We can calculate the values for the address and location classes as:

And with these values we can obtain the values shown in Table 1 for each column size of each table: Table 1. Size for each column

SUBS

DEP

SUBS_DEP

EMPLOYEE

Column name

Column type

Column size

idsubs

Simple

name

Simple

subs add

Complex

iddep

Simple

1 1 2 1 1 1.5 1 1 1 1 1 1 1.5 2 1 1

name

Simple

dep_loc

Complex

budget

Simple

idsubs

Simple

iddep

Simple

idemp

Simple

name

Simple

emp date

Simple

emp_loc

Complex

emp_add

Complex

manager

Simple

dep

Simple

56

Quantitative approaches in object-oriented software engineering With these data, we obtain the following values for the table size metric:

The other metrics for the tables are summarized in Table 2. Table 2. Metric values for the example of Figure 2 SUBS

TS RD DRT PCC NIC NSC

4 0 0 33% 1 1

DEP 4.5 0 0 25% 1 1

SUBS DEP

EMPLOYEE

2 2 1 0% 0 0

8.5 2 2 28.57%

2 2

4. Object-relational metrics formal verification As we have said previously, it is important to validate the metrics from a formal point of view in order to ensure its usefulness and there are two main approaches to carrying it out: axiomatic approaches (the goal of these approaches is merely definitional by proposing formally desirable properties for measures) and the formal frameworks based on measurement theory which specify the general framework in which measures should be defined. The strength of measurement theory is the formulation of empirical conditions from which we can derive hypotheses of reality. Measurement theory gives clear definitions of terminology, a sound basis of software measures, criteria for experimentation, conditions for validation of software measures, foundations of prediction models, empirical properties of software measures, and criteria for measurement scales. In this section we present the formal verification of the TS, the RD and the DRT metrics made in the formal framework proposed by Zuse ([ZUS 98]) and based on measurement theory. All the information related to this framework can be found in ([ZUS 98]).


57

For our purposes, the Empirical Relational System could be defined as:

Where R is a non-empty set of relations (tables), • >= is the empirical relation "more or equal complex than" on R and o is a closed binary (concatenation) operation on R. In our case we will choose natural join as the concatenation operation. Natural join is defined generally as ([ELM 99]):

Where <listl> specifies a list of i attributes of R and <list2> is a list of i attributes of S. These lists are used in order to make the comparison equality conditions between pairs of attributes. These conditions are afterwards related with the AND operator. Only the list corresponding to the R relation is preserved in Q. Depending on the characteristics of the combined tables, natural join can be derived in Cartesian product. Furthermore, it is possible to make the natural join through foreign key-primary key or between any columns of two tables defined over the same domain. All these characteristics of the natural join will be useful in order to design the combination rule of the metrics.

TS metric formal verification The TS (table Size) measure is a mapping: TS: R -> SR such that the following holds for all relations Ri and Rj e R: Ri • >= RjTS(Ri) >= TS(Rj). In order to obtain the combination rule for TS when we combine tables by natural join we may think that if the combined tables have no common columns, the attributes of the table obtained is the union of the attributes of the two table combined and the size will be the sum of each attribute size, but if the tables have any common column, the size of the tables obtained will be the sum of each size attribute minus the size of the duplicate simple column (by definition we must subtract only the simple column size because on the size of a complex column is reflected whether the hierarchy, by which the column is defined, is shared by more than one column). So, we can define the combination rule for TS as:

Where SASC(RiuRj) is the size of the common simple attributes of Ri and Rj. We can rename this last expression as v (being v a variable) and define the combination rule for TS as:

TS fulfils the first axiom of weak order, because if we have two relations RI and R2, it is obvious that TS(R1) >= TS(R2) or TS(R2) >= TS(R1) (completeness) and let

58


Rl, R2 and R3 three relations, transitivity is always fulfilled: TS(R1) >= TS(R2) and TS(R2) >= TS(R3), then TS(R1) >= TS(R3). TS does not fulfil positivity, because if we combine a relation Rl with itself without cycles: TS(R1 o Rl) is not greater than TS(R1). But it fulfils weak positivity, because it is always true that: TS(R1 o R2) >= TS(R1) for all Rl, R2 e R. TS fulfils associativity and commutativity (axioms 3 and 4), because the natural join operation is associative and commutative. TS does not fulfil weak monotonicity because if we have two tables (Rl and R2) with the same number of attributes with the same size and we combine every one of these tables with a third table (R3) that has one common attribute with the first table (Rl) and none common attribute with the second table (R2), the table that results of Rl o R3 will have less size than the table that results of R2oR3. Due to the fact that the number of attributes varies when we combine one table with itself, we can conclude that the metric is not idempotent and is necessary to prove the Archimedean axiom. In order to prove that the Archimedean axiom is not fulfilled it is important to observe that when two tables are combined by natural join successively, the number of attributes vary and also the size. Moreover, the tables obtained in successive concatenations will be the same as those obtained in the first concatenation. Then, if we have four tables Rl, R2, R3 and R4, and R3 has three attributes and a size equal to three, R4 has two attributes and a size equal to two, Rl has three attributes (one of them common with R3) and a size equal to three and R2 has four attributes and a size equal to four, and we make the concatenation R3o Rl (that is equal to the concatenation R3oR21oRlo...), obtaining a table with five attributes and a size equal to 5, and we make the concatenation R4 oR2 (that is equal to the concatenation R4oR2oR2o...), obtaining a table with six attributes and a size equal to six, the Archimedean axiom is not accomplished. So, the measure TS does not assume an extensive structure. Would TS verify the independence conditions?. As we have seen the metric does not accomplish the axiom of weak monotonicity, and then it can accomplish neither independence conditions. In fact, this type of combination rules does not assume the independence conditions. The part -v rejects the condition Cl that implies the rejection of the axiom of weak monotonicity, monotonicity and extensive structure. Then we must consider if TS fulfils some of the modified relations of belief. MRB1 is fulfilled because of giving two relations Rl and R2 e 3 (3 is the set of all the possible relations made with the attributes of the relational schema) TS(R1) >=


59

MRB2 is also fulfilled (transitivity of natural join). For MRB3 we will consider that a relation Rl 3 R2 if all the attributes of R2 are present in Rl. In this case it is evident that TS(R1) >= TS(R2), and MRB3 is fulfilled. MRB4 is fulfilled because if a relation Rl > R2 then TS(R1) > TS(R2) and TS(R1 U R3) > TS(R2 U R3), being Rl n R3 = 0. If the relations Rl and R3 do not have any attribute in common, adding the attributes of R3 to both Rl and R2, (if Rl subsumes R2), then the number of attributes of Rl and R3 is greater than the number of attributes of R2 and R3, and also their size. MRB5 is fulfilled because a relation must always have zero or more attributes; the size must then be equal or greater than zero. In summary, we can characterize TS as a measure above the level of the ordinal scale, assuming the modified relation of belief. The validation of the other metrics can be made following the same steps: defining the combination rule for the metric and proving the different properties in order to obtain the appropriate scale for the metric.

5. Object-relational metrics empirical validation In this section, we present the experiment developed in order to evaluate whether the proposed measures can be used as indicators for estimating the maintainability of an OR database.

5.1. Data Collection Five object-relational databases were used in this experiment with the average of 10 relations per database (ranging from 6 to 13). These databases were originally relational ones. For the purpose of the experiment, they were redesigned as OR databases. A brief description of these databases is given in Table 3.

60


Table 3. Databases used in the experiment Database

Number of tables

Average attributes/table

Average complex attributes/table

Airlines

6

4.16

1.83

Animals

10

2.7

0.6

Library

12

2.91

0.75

Movies

9

4.33

0.88

Treebase

13

3.46

0.86

Five people participated in the experiment the first time we conducted it (Canadian experiment): one researcher, two research assistants and two graduate students. All of them are experienced in both relational databases and objectoriented programming. In the first experiment, one person did not complete the experiment, and we had to discard his partial results. So, in the replication (Spanish experiment) only four people made the experiment. All of them are also experienced in both relational databases and object-oriented programming The people were given a form, which include for each table a triplet of values to compute using the corresponding schema. These values are those of three measures TS, DRT and RD. Our idea is that to compute these measures, we need to understand the subschema (objects and relations) defined by the table concerned. A table (and then the corresponding subschema) is easy to understand if (almost) all the people find the right values of the metrics in a limited time (2 minutes per table). We wanted to measure understandability; we decided to give our people a limited time to finish the tests they had to carry out and then use all the tests that had been answered in the given time and in a correct way (following all the indications given for the development of the experiment). So, our study would focus on the number of metrics correctly calculated. Formally, a value 1 is assigned to the maintainability of a table if at least 10 of 12 measures are computed correctly in the specified time (4 people and 3 measures). A value 0 is assigned otherwise. The tables are given to the people in a random order and not by database.

5.2. Validation Technique To analyze the usefulness of the metrics proposed, we used two techniques: C4.5 ([QUI 93]), a machine learning algorithms and RoC ([RAM 99]), a robust Bayesian classifier. C4.5 belongs to the divide and conquer algorithms family. In this family, the induced knowledge is generally represented by a decision tree. The principle of this approach could be summarized by this algorithm:


61

If the examples are all of the same class Then - create a leaf labelled by the class name; Else - select a test based on one attribute; - divide the training set into subsets, each associated with one of the possible values of the tested attribute; - apply the same procedure to each subset; Endif. The key step of the algorithm above is the selection of the "best" attribute to obtain compact trees with high predictive accuracy. Information theory-based heuristics have provided effective guidance for this division process. C4.5 induces Classification Models, also called Decision Trees, from data. It works with a set of examples where each example has the same structure, consisting of a number of attribute/value pairs. One of these attributes represents the class of the example. The problem is to determine a decision tree that correctly predicts the value of the class attribute (i.e., the dependent variable), based on answers to questions about the nonclass attributes (i.e., the independent variables). In our study, the C4.5 algorithm partitions continuous attributes (the database metrics), finding the best threshold among the set of training cases to classify them on the dependent variable (i.e. understandability of the database schemes). RoC is a Bayesian classifier. It is trained by estimating the conditional probability distributions of each attribute, given the class label. The classification of a case, represented by a set of values for each attribute, is accomplished by computing the posterior probability of each class label, given the attributes values, by using Bayes' theorem. The case is then assigned to the class with the highest posterior probability. The simplifying assumptions underpinning the Bayesian classifier are that the classes are mutually exclusive and exhaustive and that the attributes are conditionally independent once the class is known. RoC extends the capabilities of the Bayesian classifier to situations in which the database reports some entries as unknown. It can then train a Bayesian classifier from an incomplete database. One of the great advantages of C4.5 compared with RoC is that it produces a set of rules, directly understandable by software manager and engineers.

5.3. Results As specified in the validation technique section, we applied RoC and C4.5 to evaluate the usefulness of the OR metrics in estimating the maintainability of the tables in an OR schema.

62


5.3.1. RoC technique Using the cross-validation technique, the algorithm RoC was applied 10 times on the 50 examples obtained from the 50 tables of the five schematas (500 cases). 369 cases were correctly estimated for the Canadian experiment (accuracy 73.8%) and 407 cases for the Spanish one (accuracy 81.4%) and all the other cases in both experiments were missclassified. Contrary to C4.5, RoC does not propose a default classification rule which guaranteed a coverage of all the proposed cases. However, in this experiment, it succeeded in covering all the 500 cases (coverage of 100%). These results are summarized in the Table 4. Table 4. RoC quantitative results with data from Spain and from Canada Spain

Canada

Correct:

407

369

Incorrect:

93

131

Not classified:

0

0

Accuracy:

81.4%

73.8%

Coverage:

100.0%

100.0%

RoC produces the model presented in Figure 3 with the Canadian data. From this model, it is hard to say which metric is more relevant than another in an absolute manner. However, we can notice that when TS is smaller, the probability that the table is understandable is higher (for example 55% for TS 10). Inversely, the same probability increases when estimating the tables that are not understandable (varying from 13.6% for TS 10).


63

Figure 3. The model generated by RoC with data from Canada

For DRT and RD, it is hard to draw a conclusion since no uniform variation is shown. This can be explained by the fact that for the sample used in this experiment, the values of DRT and RD are in defined in a narrow range ([0, 3] and [0, 5]). RoC produces the model presented in Figure 4 with the Spanish data. The conclusions from this second model are the same as the first one because the models are very similar.

64


Figure 4. The model generated by RoC with data from Spain

5.3.2. C4.5 technique The results obtained for the Canadian experiment are shown in Table 5. The model of C4.5 was very accurate in estimating the maintainability of a table, 94% and represent a high level of completeness (up to 100% for not understandable tables) and correctness (up to 100% for understandable tables). Table 5. C4.5 quantitative results from the Canadian experiment Predicted maintainability 0 1 Real Maintainability

0 1 Correctness Accuracy = 94°/o

28 3

0 19

90.32%

100%

Completeness 100% 86.36%


65

And the rules obtained with C4.5 are: Rule 1: TS class 1

[84.1%]

Rule 2: TS 1 -> class 1

[82.0%]

Rule 7: TS class 1 [82.0%] Rule 5: TS > 9 -> class 0

[82.2%]

Rule 6: DRT > 2 -> class 0

[82.0%]

Default class: 0

Figure 5. C4.5 estimation model from the Canadian data

TS seems to be an important indicator for the maintainability of the tables. Rules 1, 2 and 7, which determine if a table is maintainable, all state as part of the conditions that TS must be small. Inversely, in rule 5, it is stated a large size is sufficient to declare the table as not understandable. A small DRT is also required for rules 1 and 7 as partial condition to classify the table as understandable. At the same time, a high value of DRT means that the table is hard to understand (rule 6). RD does not represent an interesting indicator. The results obtained for the Spanish experiments are shown in Table 6. In this case the accuracy in estimating the maintainability was 94% and the levels of completeness and correctness were smaller than the Canadian experiment but were also very high. Table 6. C4.5 quantitative results from the Spanish experiment

Real Maintainabilty

0 1 Correctness Accuracy = 92%

I |

Predicted maintainabilty 0 1 21 I 1 3 | 25 87.5% 96.15%

I [

Completeness 95.45% 89.29%

66


And the rules obtained with C4.5 are: Rule 1: TS 5 A PCC class 0

[82.3%]

Rule 2: DRT>2 -> class 0

[66.2%]

Default class: 1

Figure 6. C4.5 estimation model from the Spanish data The model rule is smaller than the one of the first experiment but it confirms that (at least for the sample studied) TS and DRT are good indicators and not RD. Both experiments and both techniques establish that the table size metric (TS) is a good indicator for the maintainability of a table. The depth of the referential tree metric (DRT) is also presented as an indicator by C4.5 on both experiments, and the referential degree metric (RD) does not seem to have a real impact on the maintainability of a table.

6. Conclusions and future work It is important that software products, and obviously databases, are evaluated for all relevant quality characteristics, using validated or widely accepted metrics. However, more research is needed into the aspects of software measurement ([NEI 94]), both from a theoretical and from a practical points of view ([GLA 96]). We think it is very interesting to dispose of metrics for object-relational databases. These metrics can be used to flag outlying schemata for special attention; a strong requirement for low testing and maintenance costs would argue for justifying extra managerial attention to a quite significant fraction of object-relational database schemata. We have put forward different proposals (for internal attributes) in order to measure the complexity that affects the maintainability (an external attribute) of the relational database schemata and consequently control its quality. These metrics were developed and characterized in accordance with a set of sound measurement principles, applying the formal framework proposed by Zuse ([ZUS 98]), in order to obtain the scales to which the metrics pertain. ' We have carried out experiments to validate the proposed metrics, but others are being developed at this moment. However, the controlled experiments have problems (such as the large number of variables that cause differences, or the fact that these


67

experiments deal with low level issues, microcosms of reality and small sets of variables) and limits (e.g. they do not scale up, are performed in a class in training situations, are made in vitro and face a variety of threats of validity). Therefore, it is convenient to run multiple studies, mixing controlled experiments and case studies ([BAS 99]). For these reasons, a deeper empirical evaluation is under way in collaboration with industrial and public organizations in "real" situations.

7. References [AND 83] ANDERSON, J.R. (1983), The Architecture of Cognition, Cambridge, MA, Harvard Universitiy Press. [BAS 99] BASILI, V.R., SHULL, F., LANUBILLE, F. (1999), "Building Knowledge through families of experiments", IEEE Transactions on Software Engineering, July/August, No. 4. p. 456473. [BRI 96] BRIAND, L.C., MORASCA, S., BASILI, V. (1996), "Property-based software engineering measurement", IEEE Transactions on Software Engineering, 22(1), p. 68-85. [BRI 97] BRIAND L.C., MORASCA S. (1997), "Towards a Theoretical Framework for Measuring Software Attributes", Proceeding of the Fourth International, Software Metrics Symposium, p. 119-126. [ELM 99] ELMASRI, R., NAVATHE, S. (1999), Fundamentals of Database Systems, Third edition, Addison-Wesley, Massachussets. [FRA 92] FRAZER, A. (1992), "Reverse engineering-hype, hope or here?", in P.A.V. Hall, Software Reuse and Reverse Engineering in Practice, Chapman & Hall. [GLA 96] GLASS, R. (1996), "The Relationship Between Theory and Practice in Software Engineering", IEEE Software, November, 39 (11), p. 11-13. [HAR 98] HARRISON, R., COUNSELL, S.. NITHI, R. (1998), "Coupling metrics for ObjectOriented Design", 5th. International Symposium on Software Metrics, IEEE Computer Society, Bethesda, Maryland, 20-21 November. [HEN 96] HENDERSON-SELLERS, B. (1996), Object-oriented Metrics - Measures of complexity, Prentice-Hall, Upper Saddle River, New Jersey. [ISO 94] ISO, (1994), "Software Product Evaluation-Quality Characteristics and Guidelines for their Use", ISO/I EC Standard 9126, Geneva. [LI 87] LI, H.F., CHEN, W.K., "An empirical study of software metrics", IEEE Trans, on Software Engineering, (1987), 13 (6), p. 679-708. [LI 93] LI, W., HENRY, S. (1993). "Object-Oriented metrics that predicts maintainability", J. Sys. Software,23,p. 111-122. [MCA 76] McCABE. T.J. (1976), "A complexity measure", IEEE Trans. Software Engineering 2(5), p. 308-320.

68


[MCL 92] McCLURE, C. (1992), The Three R's of Software Automation: Re-engineering, Repository, Reusability, Englewood Cliffs, Prentice-Hall. [NEI 94] NEIL, M. (1994), "Measurement as an Alternative to Bureaucracy for the Achievement of Software Quality", Software Quality Journal 3 (2), p. 65-78. [PIG 97] PlGOSKl, T.M. (1997), Practical Software Maintenance, Wiley Computer Publishing, New York, USA. [QUI 93] QUINLAN, J.R., (1993), C4.5: Programs for Machine Learning, Morgan Kaufmann Publishers. [RAM 99] RAMONI, M., SEBASTIANI, P. (1999), "Bayesian methods for intelligent data analysis", In M. Berthold and D.J. Hand, editors, An Introduction to Intelligent Data Analysis, New York, Springer. [SIA 99] SIAU, K. (1999), "Information Modeling and Method Engineering: A Psychological Perspective", Journal of Database Management 10 (4), p. 44-50. [SNE 98] SNEED, H.M., FOSHAG, O., "Measuring Legacy Database Structures", Proc of The European Software Measurement Conference FESMA 98, (Antwerp, May 6-8, 1998), Coombes, Van Huysduynen and Peeters (eds.), p. 199-211. [STO 99] STONEBRAKER, M., BROWN, P., Object-Relational DBMSs tracking the next great wave, (California, 1999), Morgan Kauffman Publishers. [WEY 88] WEYUKER, E.J. (1988), "Evaluating software complexity measures", Transactions on Software Engineering, Vol. 14(9), p. 1357-1365.

IEEE

[ZUS 98] ZUSE, H. (1998), A Framework of Software Measurement, Berlin, Walter de Gruyter.

Chapter 4

Measuring event-based object-oriented conceptual models Geert Poels Vlekho Business School, University of Sciences and Arts, Belgium

Guido Dedene IS Group, Dept. Applied Economics, Katholieke Vniversiteit Leuven, Belgium

1. Introduction A decade of research into object-oriented software measurement has produced a large number of measures for object-oriented software models and artefacts. Zuse provides a list of no less than 137 of such measures and estimates the actual number of measures at more than three hundred [ZUS 98]. In spite of these research efforts there are still areas that remain largely untouched by object-oriented software measurement research. In this paper we present an approach that addresses two of these research 'niches'. A first problem area, identified during the 1999 ECOOP International Workshop on Quantitative Approaches in Object-Oriented Software Engineering [BRIT 99], concerns the lack of measures for models that capture the dynamic aspects of an object-oriented software system. A typical measure suite for object-oriented software, like for instance MOOSE [CHI 94], focuses on the data and function dimensions of software, but ignores the behaviour dimension as captured by behavioural models like state-transition diagrams and activity diagrams. Moreover, object-interaction characteristics such as interaction coupling [EDE 93] or dynamic coupling [BRIT 96] have only been measured on the basis of collaboration diagrams and message sequence diagrams. Coupling between objects has not been measured using object-interaction diagrams that are based on other object-communication mechanisms, like event broadcasting. A second problem area concerns the lack of measures for object-oriented software specifications [BRIA 99a]. Although industry begs for measurement instruments that can be applied in the early phases of the development process (mainly for early quality control and project budgeting decisions), nearly all published object-oriented software measures can only be used after (high-level)

70


system design. Some exceptions known to us are measures for object-oriented analysis models (e.g. task points [GRA 95] for Graham's SOMA, the QOOD measure suite [BAD 95] for Coad and Yourdon's OOA, and the complexity measures presented in [GEN 99] for Rumbaugh's OMT). We believe these two problem areas to be somewhat related. Modern, UMLcompliant approaches towards domain analysis, object-oriented analysis and design, and component-based software engineering, like for instance Catalysis [DSO 99], put emphasis on both the static and dynamic aspects of a domain or software system. However, in an object-oriented implementation the dynamic aspects become somewhat subordinate to the static aspects. Many of the 'rules' that were explicitly captured during behavioural and object-interaction modelling are translated into class invariants or into preconditions and postconditions that are attached to specific methods within the class definitions. Strangely enough, these types of assertions have not received the attention of research into object-oriented design and code measurement either. In this paper, we present part of a framework for measuring object-oriented conceptual models. Conceptual modelling is used to model, structure and analyse a (part of a) domain 1 , irrespective of the software system that must be built. Defining a domain model is part of the requirements engineering step in the development of a software system. All the rules described in the domain model have to be supported by the system. Object-oriented analysis in general also aims at modelling and analysing the specific system requirements (user interface, data storage, workflow aspects, quality requirements, etc). The conceptual model can be considered as an early object-oriented analysis artefact. As a consequence, our framework is suited for early measurement. Conceptual models are combinations of different sub-models. Generally, three sub-models are distinguished: a structural model (e.g. class diagram), an objectinteraction model (e.g. message sequence chart) and a set of object-behaviour models (e.g. finite state machines). The part of the framework presented in this paper focuses on the object-interaction model. To model the interaction (and communication) between objects the framework assumes the event broadcasting mechanism, which from a conceptual modelling point of view is to be preferred

1. The term "conceptual modelling", as used in this paper, does not necessarily refer to the concept of domain analysis or engineering. Domain analysis methods like FODA [KAN 90] are used to derive models that are common to a collection of individual organisations. An analysis of the similarities and differences between the individual enterprise models (also called business models) plays a crucial role in such methods. When we use the term "domain" or "domain model" in this paper, we mean a "domain" in a more general sense. It can refer to a real domain model (e.g. stock/inventory management, front office, manufacturing) as well as to an enterprise model that is specific to a particular organisation.

Measuring event-based OO conceptual models

71

above the message passing mechanism 2 . The cornerstone of the measurement framework is a formally defined object-interaction model based on event broadcasting, called the object-event table (OET). The OET provides a formal basis for a suite of measures that is defined in terms of (common) event participations. In Section 2 the object-event table is presented. A compact suite of measures, including size, coupling, inheritance, specialisation, propagation and polymorphism measures is presented in Section 3. The results of a first measure validation experiment are briefly discussed in Section 4. Finally, Section 5 contains conclusions and topics for further research. 2. The object-event table In conceptual modelling, the events that are modelled are real-world events, sometimes also referred to as business events. Real-world events are characterised by the following properties: - A real-world event corresponds to something that happens in the real world. This 'real world' is the universe of discourse, i.e. the domain or relevant part of the domain that must be modelled; - A real-world event has no duration, i.e. it occurs or is recognised at one point in time; - The real-world events that are identified during conceptual modelling are not further decomposable. They are defined at the lowest level of granularity and cannot be meaningfully split into other, more fine-grained, events. It is common to model events as event types, rather than referring to specific event occurrences. Since real-world events are the focal point in event-based conceptual modelling, a notation is needed to designate the set of event types that is relevant for a particular universe of discourse. We use A to denote the universe of event types associated with some universe of discourse. All event types relevant to the universe of discourse are elements of A An example is presented of a simplified loan circulation process in the context of a library. Assume that the scope of the LIBRARY conceptual model is initially delimited such that the universe of event types is A = {start member ship, end member ship, acquire, catalogue, borrow, renew, return, sell, reserve, cancel, fetch, lose} 2. In reality, objects do not pass messages to each other. For instance, if a person rents a car, then the person does not send a "rent"' message to the car, nor the other way round. However, both objects (person and car) are involved in the same real-world event, i.e. the renting of the car by the person. The event broadcasting mechanism simultaneously notifies all participating objects of the event occurrence, without deciding on an order yet as with message passing (e.g. the person notifies the car or the car notifies the person). Compared to message passing, the event broadcasting mechanism leads to more maintainable and reusable conceptual models [SNO 00].

72


A conceptual model also identifies the entities (persons, things, etc) in the universe of discourse that participate in real-world events. Such entities are said to be "relevant to" the universe of event types A. In object-oriented conceptual modelling these entities are represented as objects. Objects are characterised as follows: - Each object in the conceptual model corresponds to a real-world concept; - Objects are described by a number of properties. The properties of an object are specified in an object type (e.g. a UML classifier with an stereotype); - Objects exist for a certain period of time; - An object always participates in at least two real-world events: a creating event and an ending event. The participation in the ending event does not imply that the object is physically destroyed. It means that the object can no longer participate in real-world events. For instance, a loan object that has 'ended' can still be kept in a data warehouse where it can participate in system events (e.g. move_to_warehouse, remove from warehouse). However, the loan itself no longer exists. Objects have a state and a set of operations. Although the specific form of communication (e.g. message passing) is not relevant for conceptual modelling, we assume that for each type of event that an object participates in, there is an operation specified in the object type. The state of an object is represented by its values for the attributes that have been specified in the object type. These attributes must be seen as abstract attributes, i.e. they must not necessarily be stored attributes in the class definition of the object. The effect of an event participation is modelled by specifying how the operation that is triggered by the event affects the state of the participating object. The set of operations/triggering event types for an object type is called its alphabet. It is a subset of the universe of event types. Event participations are modelled using an object-event table (OET). The type of involvement of an event participation is create (C), modify (M), or end (E). A modifying event type for an object type does not create object instances of the type, nor does it end their lives. A modifying event may however change the state of an object. Table 1 contains the OET for LIBRARY. Apart from a type of involvement indication, we also indicate the type of provenance of an event participation. An operation/event type in the alphabet of an object type is either acquired through propagation (A) (cf. infra), inherited (I), or specialised, i.e. inherited in a specialised version (S) (cf. infra). The class of "own" event types (O) completes the partitioning. To formally define the measures in the next section, the notion of object-event table is formalised [SNO 99]. The set of object types relevant to the universe of event types A is denoted by a capital T.


73

Let A be the universe of event types and T be the set of object types. The object-event table is a map When the tabular representation of the object-event table as used to denote We define the partial maps tP and TI that return the type of provenance and the type or involvement as Definition 1. Definition of the object-event table

Event-based conceptual modelling is also concerned with modelling the static structure of the universe of discourse. This means that associations between object types, with their optionalities and cardinalities, are identified. A key feature of event-based conceptual modelling is that the effect of associations on event participation is explicitly modelled. One type of association is specialisation. One object type can specialise another object type. A subtype inherits the alphabet of its supertype3. It may also extend this alphabet, by participating in additional types of event. We also allow for event type specialisation, i.e. objects of a subtype may participate in events of a type that specialises an event type in the alphabet of the supertype (cf. Table 1)4.

3. By convention, the inherited operations are explicitly specified in the subtype. This does not mean that they must be implemented in the class definition of the subtype. Conceptual modelling is not concerned with issues regarding implementation inheritance. 4. The operations of the supertype that are specialised are not included in the subtype. Note that some object-oriented analysis methods (e.g. Catalysis) do not support event type/operation specialisation.

74


J O

acquire acquire volume acquire copy catalogue sell sell volume sell copy reserve cancel fetch start membership end membership borrow create not renewable In create renewable loan return lose lose volume lose copy renew

O/C O/M O/E

>• 0,

O U

O/C O/E O/E

A/M A/M A/M O/C O/E A/M A/M

< q

RENEWABLE_LOAN

2

NOT_RENEWABLE_LOAN

UJ

MEMBER

S

UJ

RESERVATION

Table 1. Object-event table for LIBRARY (rows represent event types, columns represent object types)

s/c I/M

S/C I/M

S/E S/E A/M A/M A/M

A/M A/M

A/M A/M

A/E A/E A/M

A/M A/M A/M A/M A/M A/M

O/C O/C S/C O/E O/E

I/E

S/C I/E

S/E S/E O/M

For the other types of association we follow a modelling strategy that factors all associations into binary existence dependency associations [SNO 99]. Such associations put special restrictions on optionalities and cardinalities 5 . Moreover, they allow a formal definition of "propagation" of operations. It is required that an object (hereafter called the master object) participates in all events in which its existence dependent objects participate. All these event participations are propagated from the existence dependent object to the master object (cf. Table 1). The

5. The association is mandatory and has a cardinality of one for the existence dependent object type. Moreover, during its life, an existence-dependent object is always associated to the same object.


75

operations in the existence dependent object type are also propagated into the master object type6. Figure 1 shows the structural model of LIBRARY. Note that the object type ITEM has two subtypes: VOLUME and COPY. If we assume that volumes can be borrowed, but their loans cannot be renewed, then the object type LOAN must also be specialised.

Figure 1. Structural model for LIBRARY

3. An OET-based measure suite For the measure definitions, assume a universally qualified conceptual model S with universe of event types A, set of object types T relevant to A, and an objectevent table T. We use the symbol # for the cardinality of a set.

6. This does not mean that all propagated operations must also be implemented in the class definition of the master object type.

76


3.1. Size measures Informally, the size of a software artefact is a function of the number of finergrained elements that are used to define, specify, build or compose it [FEN 97]. Size can be expressed and measured in terms of event participations. There are good reasons to do so. The more event types an object type is involved in, the more operations must possibly (but not necessarily) be implemented in the class definition. Hence, the count of event participations provides an early size estimate for classes. Early size estimates are useful (and essential) for project budgeting purposes. They are the basis for effort and cost estimates, and for pricing, outsourcing and scheduling decisions. Table 2. Size measures based on the OET MEASUREMENT OBJECT

Object type: P e T Conceptual model: S

MEASURE DESCRIPTION Count of Event Participations Level of Object-Event Interaction

MEASURE DEFINITION CEP(P) = #{e e ] i(e, P ) * ( ' V ')} LOEI(S)= E CEP(P) Pe T

3.2. Coupling measures Coupling can be described as the degree of interdependence between software artefacts (e.g. modules, classes, components, etc) [FEN 97]. The main arguments in favour of low coupling are that the stronger the coupling between software artefacts, (i) the more difficult it is to understand individual artefacts, and hence to maintain them; (ii) the larger the extent of (unexpected) change and defect propagation effects across artefacts, and consequently the more testing required to achieve satisfactory reliability levels; (iii) the lower the reusability of individual artefacts. We therefore need to assess, and if needed reduce, the level of coupling in a software system. The earlier this is done the better. Traditionally, coupling in object-oriented software has been measured in terms of message passing [BRIA 99b] (e.g. the Message Passing Coupling (MPC) measure [LI 93]). In conceptual modelling we do not wish to decide yet whether object communication will be based on message passing. In our opinion, it might thus be useful to express coupling in terms of common event participations. Object types are then coupled if their instances participate in the same types of event.


77

Table 3. Coupling measures based on the OET MEASUREMENT OBJECT

Object type: P e T Conceptual model: S

MEASURE DESCRIPTION Count of Coupled Object types Level of Object type Coupling

MEASURE DEFINITION CCO(P) = #{Q e T- {P} 3e e A: T(e,P) # (' ' ' ' )^ (e, Q)* (' ',' ')} LOC(S)=

E

CCO(P)

PeT

The OET provides also the basis to measure specific types of coupling, related to the dynamic behaviour of objects. An example is synchronisation-based coupling. In LIBRARY, RESERVATION and RENEWABLE_LOAN are not (directly) related through associations (cf. Figure 2). However, their alphabets contain the common event type fetch. A RESERVATION object and a RENEWABLEJLOAN object synchronise their lives when they participate in the same fetch event (i.e. the fetch ends the life of a RESERVATION object and creates a new RENEWABLE_LOAN object). Table 4. Measures for synchronisation-based coupling MEASUREMENT OBJECT

Object type: P e T

Conceptual model: S

MEASURE DESCRIPTION Count of Synchronisation-based Coupled Object types Level of Synchronisation-based Object type Coupling

MEASURE DEFINITION CSCO(P) = #{Q e T-{P} 3 e e A: (T,(e,P) = C A T,(e,Q) = E) v (ti(e, P) = E A T,(e,Q) = C)} LSOC(S)=

E

CSCO(P)

Per

3.3. Inheritance, specialisation and propagation measures Several measures for quantifying the absolute or relative amount of inherited properties in an object-oriented system have been proposed7. The measures proposed in the literature are generally design or code measures that consider the inheritance of class methods. During conceptual modelling, models are built using 7. Examples include MIF (i.e. the Method Inheritance Factor which is the ratio of the count of all inherited methods in the classes of a system to the count of all available methods in the classes of the system [BRIT 94]). NIM, NAM and NOM) (i.e. Number of Inherited/Added/Overriding Methods [TEG 95]), and MFA (i.e. Measure of Functional Abstraction which is the ratio of the number of methods inherited by a class to the total number of methods accessible by member methods of the class [BAN 97]).

78


type definitions, rather than class definitions, and consequently it has not been decided yet which operations must be implemented, or inherited, overridden, etc. Nevertheless, early estimates of the degree of inheritance can be obtained by considering the type of provenance of event participations. Generally, operations that correspond to "own" or specialised event participations are implemented as class methods, whereas inherited operations are not (unless there is a need to override the method body in the subclass). As far as we know, there are no measures to assess the degree of propagation of operations. Nevertheless, propagation of operations is not an exclusive characteristic of existence dependency associations. For instance, in the context of the IS-PARTOF relation operations might also propagate from the aggregate to the parts (e.g. cascading deletes), at least from a conceptual modelling point of view. Having an idea of the (relative) amount of propagated operations in an object type is useful, as these operations must not necessarily be implemented as methods in the own class definition. Table 5. Inheritance, specialisation and propagation measures based on the OET MEASUREMENT OBJECT

Object type: P € T

MEASURE DESCRIPTION

MEASURE DEFINITION

Degree Of Inheritance Degree Of Specialisation

Conceptual model: S

Degree Of Propagation Degree Of Inheritance

Degree Of Specialisation

Degree Of Propagation

PeT

3.4. Polymorphism measures Literally, polymorphism refers to the ability to take different forms. The general idea of polymorphism is that different classes define a method with the same name


79

and signature, but with a different implementation. Mostly, polymorphism is then considered (and measured) in the context of inheritance, overriding and dynamic binding [PER 99]. However, methods with the same name and signature may also appear in classes not related through inheritance (i.e. reciprocal or simultaneous polymorphism) [BEN 99]. A potential polymorph situation exists when more than one object type is involved in the same event type. So, the number of potential polymorph situations is easily measured from the perspective of the event types. The type of provenance indications further allows distinguishing specific types of polymorphism, like noninheritance-related polymorphism. The following table presents the degree of polymorphism measures. They are relative measures, i.e. they relate the actual number of potential polymorph situations of the type considered to the maximum number of such situations. Note that polymorphism is only defined for conceptual models. Table 6. Polymporhism measures based on the OET MEASUREMENT OBJECT

Conceptual model: S

MEASURE DESCRIPTION Degree of Polymorphism

MEASURE DEFINITION DPO(S) = (E # { P e T\ ee/l

T(e,P)#(' ' ' ' ) } - # A)/ LOEI(S) Degree of Noninheritance-related Polymorphism

DNPO(S)-(E

#{P e T\

ee/l

T P (e,P)e {O,A,S} }-# A)/ (LOEI(S)-E # { P e T | TP(e,P) = I}) ee A

4. A first measure validation experiment This section briefly describes a controlled experiment that was conducted at the College of Information and Computing Sciences, Saint Louis University, Baguio City, The Philippines, during a guest professorship of one of the authors in April May 2000. This synthetic environment experiment was inspired by a number of similar experiments with object-oriented software [DAL 96], [CAR 98], [HAR 99]8. One of the goals of the experiment was to gather empirical evidence on the

8. Time and budgeting constraints prohibit controlled software engineering experimentation in a realistic setting. Usually a synthetic environment (i.e. the classroom) is used and the subjects involved in the experiments are students [ZEL 97].

80


usefulness of the inheritance, propagation and synchronisation-based coupling measures as maintainability indicators.

4.1. Design of the experiment The experiment was not directly intended as a measure validation study. Its primary purpose was an experimental investigation into the maintainability of eventbased object-oriented conceptual models. Indirectly, however, the experiment was also meant to gather empirical evidence on the usefulness of some of the measures in the OET-based measure suite as indicators of conceptual model maintainability. The initial set-up of the experiment was ambitious. We wished to compare the maintainability of conceptual models that were characterised by different inheritance structures, different propagation structures and different amounts of synchronisation constraints. Based on our experiences with event-based object-oriented conceptual modelling we expected that models with extensive use of inheritance or propagation, or with many synchronisation constraints were more difficult to maintain. In order to test this hypothesis we designed three related experiments. In each of these subexperiments we used four different conceptual models of a same domain description. The models were different in the sense that they had a different structure, respectively inheritance structure, propagation structure and number of synchronisation constraints, i.e. respectively with 0, 1, 2 or 3 levels of inheritance depth, 0, 1, 2 or 3 levels of propagation depth, and 0, 1, 2 or 3 synchronisation constraints. Taking account of symmetries, this set-up resulted in six hypothesis sets for each sub-experiment, each with a null hypothesis and an alternate hypothesis: - H0ij: The maintainability of conceptual models with i and j levels of inheritance depth (i and j levels of propagation depth, i and j synchronisation constraints) is not significantly different; - H i i j The maintainability of conceptual models with i and j levels of inheritance depth (i and j levels of propagation depth, i and j synchronisation constraints) is significantly different; where i, j e {0, 1, 2, 3} and i #j. Care was taken that the alternative models of a same domain description were as much as possible identical, except for the factor we wished to test. The models included (apart from an OET) a structural model (i.e. object type diagram) and object-behavioural models (i.e. JSD structure diagrams). The required tasks involved answering a number of questions to assess a person's understanding of the model and applying changes or extensions to the models. We also took care that the questions and maintenance tasks that had to be performed on the models were identical, given a few minor details that in our opinion would not affect the outcome of the experiment. As dependent variables we used the number of correct answers as a measure of understandability and the correctness and completeness of the


81

maintenance tasks as measures of modifiability9. The correctness and completeness ratios are shown below: ^ number of correct modifications Correctness — number of modifications applied Completeness

number of correct modifications number of modifications required

The subjects were graduate students in the Master of Information Technology program of Saint Louis University. They were all enrolled in the same software engineering course taught by one of the authors during a guest professorship at Saint Louis University. All students had more or less the same educational background and had taken the same courses as a prerequisite for the Masters program. There were some notable differences with respect to age and working experience, but these were not directly related to software engineering. During the course all students had been introduced to event-based object-interaction models, object-behavioural models and structural modelling, and they had performed tasks similar (but not identical) to the ones required by the experiment. In each sub-experiment, we used a between-subjects design with one independent variable (e.g. the number of levels in the inheritance structure) and four groups of students. In total 16 students participated in the experiment. These students were randomly allocated to the four groups10. In each sub-experiment, each group was assigned a different model and subjects were asked to answer the questions and perform the required maintenance tasks. This effectively gave us for each sub-experiment four data points per group, per dependent variable. We could have increased the number of data points per group by using a within-subjects design, but we chose not to do so in order to avoid possible learning effects. A more detailed description of the design of the experiment is outside the scope of this paper, but can be found in [POE 2001].

4.2. Analysis and discussion of results After collecting the data from our experiment we applied analysis of variance (ANOVA) tests. The results of these tests were disappointing. For understandability there were no statistical significant differences between groups using 95% and 90% confidence intervals, suggesting that inheritance depth, propagation depth and the 9. Though some tasks involved changing the model and other tasks involved extending the model, we did not separate changeability from extensibility in the analysis of the results. 10. Given the small number of participants, a matched-groups design or a randomised block design would have been preferred to account for individual differences in ability between subjects. At the outset we had expected a far greater number of students to participate in the experiment, which is why we overlooked this aspect.

82


amount of synchronisation constraints have no effect on the ease of understanding the model. For modifiability the ANOVA tests indicated the presence of statistical significant differences, though in several cases only when using a 90% confidence interval. Next we applied t-tests for differences in mean values between each pair of groups, and these tests again revealed some significant differences using a 95% confidence interval, meaning that some of the alternate hypotheses could be accepted. Overall, the analysis results did not allow to draw definite conclusions, let alone to determine anything like an optimal level of inheritance depth, propagation depth or an optimal number of synchronisation constraints. At the end of the experiment we only had four data points per group for each of the understandability and modifiability indicators, in each of the three subexperiments. The overall trend in the data (though not always statistically significant) was that the lower levels of inheritance and propagation depth seemed to offer better perspectives for modifiability. The same was true for the amount of synchronisation constraints. We therefore rearranged our data such that in each subexperiment the completeness and correctness scores of the combined groups "0" and "1" were compared to those of the combined groups "2" and "3". Now, all twotailed unpaired t-tests indicated a statistical significant difference (using a 95% confidence interval) in completeness and correctness scores for each of the independent variables tested (i.e. inheritance depth, propagation depth, number of synchronisation constraints), but again only for modifiability. We therefore conclude from our experiment that models with moderate levels of inheritance depth, propagation depth and synchronisation constraints are easier to modify than models with extensive use of these structures.

4.3. OET-based measures as modifiability indicators Genero et al. suggest controlled experimentation as a technique to validate conceptual model measures [GEN 00]. In our opinion, a controlled experiment "where different values of all the metrics are considered in different conceptual models" is difficult to achieve. When initially designing our experiments we tried to vary the value of target measures like DOI and DOP, but the resulting conceptual models were artificial and not suited to be used as experimental material. It is true that the four different levels of inheritance depth, propagation depth and synchronisation constraints in the final models do indeed result in different (i.e. increasing) values of DOI, DOP and LSOC, but this is not the same as really controlling the values of these measures. The intervals between measurement values in consecutive models are for instance not equal, as would be desirable in a controlled experiment. Nevertheless, the results of the experiment provide empirical evidence on the usefulness of the DOI, DOP and LSOC as modifiability indicators, as an extensive use of inheritance, propagation and synchronisation constraints is generally accompanied by higher values for these measures.


83

5. Conclusions and topics for further research This paper presented part of a framework for the measurement of object-oriented conceptual models. Conceptual modelling is part of the requirements engineering process and as such our work addresses the need for measurement support in the early stages of system development. The cornerstone of the measurement framework is the object-event table. In fact, to measure characteristics related to the data, function, as well as dynamic behaviour dimensions of object-oriented conceptual models, the framework assumes that the object-event interactions are somehow modelled. Information regarding such interactions is normally available when modelling and analysing a domain. But even if a method does not prescribe the use of an object-event table or an equivalent object-event interaction model, this information can easily be derived, as long as the method does not ignore behavioural aspects altogether. Some behavioural aspects cannot be modelled in an object-event table. The types of involvement indications of the event participations specify a default life cycle for the domain objects. The domain might impose additional constraints on the life cycle of objects, which are not modelled in the object-event table. These constraints on the order in which objects participate in events are specified by means of objectbehavioural models (e.g. Finite State Machines, JSD structure diagrams, regular expressions over a process algebra). Measures for dynamic behaviour characteristics can be defined that complement the dynamic model measures presented in this paper. For instance, in [POE 99a] we have developed the Object Life Cycle Complexity measure, which is used to assess the complexity of life cycle constraints, using the default life cycle constraints in the object-event table as a basis for comparison. This paper did not address the issue of measure validity. Regarding the theoretical validity of the measures we must note that the direct measures (e.g. CEP, CCO, CSCO) have been developed using distance-based software measurement, a Measurement Theory-based approach described in [POE 00]. This approach uses an advanced measurement theoretic structure, i.e. the segmentally additive proximity structure [SUP 89], to model attributes (i.e. characteristics) of software models and artefacts. The corresponding measures, which are formally based on the concept of 'metric with additive segments', are defined using a constructive stepwise procedure provided by the approach. It was proven in [POE 99b] that the resulting measures are characterised by the ratio scale type. As a consequence, indirect measures (e.g. LOEI, LOC, DOI, DPO etc) that are derived from distance-based defined direct measures are also characterised by the ratio scale type (at least 'in a wide sense' as defined in [ROB 79]). Regarding the usefulness of the measures we must note that a series of empirical investigations has been planned. Results of a first controlled experiment to assess the impact of inheritance, propagation and synchronisation on the understandability,

84


changeability and extensibility of object-oriented conceptual models have briefly been discussed in the paper. The ultimate goal of the empirical research is to examine whether the measures can indeed be used as early effort and quality predictors, and whether dynamic aspects of software are related to these variables.

6. References [BAD 95] BADRI L., BADRI M., FERDENACHE S., "Towards Quality Control Metrics for Object-Oriented Systems Analysis", Proceedings of TOOLS Europe '95, Versailles, March 1995, p. 193-206. [BAN 97] BANSIYA J., DAVIS C., An Object-Oriented Design Quality Assessment Model, technical report, August 1997, Computer Science Department, University of Alabama. [BEN 99] BENLARBI S., MELO W.L., "Polymorphism Measures for Early Risk Prediction", Proceedings of the 21st International Conference on Software Engineering ICSE'99, Los Angeles, May 1999, p. 334-344. [BRIA 99a] BRIAND L., ARISHOLM E., COUNSELL S., HOUDEK F., THEVENOD-FOSSE P., Empirical Studies of Object-Oriented Artifacts, Methods, and Processes: State of The Art and Future Directions, technical report IESE 037.99/E, 1999, Fraunhofer Institute for Experimental Software Engineering. [BRIA 99b] BRIAND L.C., DALY J.W., WUST J.K., "A Unified Framework for Coupling Measurement in Object-Oriented Systems", IEEE Transactions on Software Engineering, Vol. 25, No. 1, 1999, p. 91-121. [BRIT 94] BRITO E ABREU F., CARAPUcA R., "Object-Oriented Software Engineering: Measuring and Controlling the Development Process", Proceedings of the 4th International Conference on Software Quality ICSQ '94, McLean, VA, October 1994. [BRIT 96] BRITO E ABREU F., ESTEVES F., GOULAO M., "The Design of Eiffel Programs: Quantitative Evaluation using the MOOD Metrics", Proceedings TOOLS'96, Santa Barbara, Calif, July 1996. [BRIT 99] BRITO E ABREU F., ZUSE H., SAHRAOUI H., MELO W., "Quantitative Approaches in OO Software Engineering, Springer Verlag", Lecture Notes in Computer Science, ECOOP '99 workshop reader, 1999. [CAR 98] CARTWRIGHT M., SHEPPERD M., An Empirical View of Inheritance, technical report ESERG: TR98-002, 1998, Department of Computing, Bournemouth University. [CHI 94] CHIDAMBER S.R., KEMERER C.F., "A Metrics Suite for Object Oriented Design", IEEE Transactions on Software Engineering, Vol. 20 No. 6, 1994, p. 476-493. [DAL 96] DALY J., BROOKS A., MILLER J., ROPER M., WOOD M., "An Empirical Study Evaluating Depth of Inheritance on the Maintainability of Object-Oriented Software", Empirical Software Engineering, An International Journal, Vol. 1, No. 2, 1996, p. 109132. [DSO 99] D'SOUZA D.F., WILLS A.C., Objects, Components, and Frameworks with UML: the Catalysis Approach, Addison-Wesley, 1999.


85

[EDE 93] EDER I, KAPPEL G., SCHREFL M., Coupling and Cohesion in Object-Oriented Systems, technical report 2/93, 1993, Department of Information Systems, Johannes Kepler University of Linz. [FEN 97] FENTON N.E., PFLEEGER S.L., Software Metrics: A Rigorous & Practical Approach, London, PWS Publishing Company, 1997. [GEN 99] GENERO M., MANSO M.E., PIATTINI M., GARCIA F.J., "Assessing the Quality and the Complexity of OMT Models", Proceedings of the 2nd European Software Measurement Conference FESMA '99, Amsterdam, October 1999, p. 99-109. [GEN 2000] GENERO M., JIMENEZ L., PIATTINI M., "Measuring the Quality of Entity Relationship Diagrams", Proceedings of the 19th International Conference on Conceptual Modeling ER '2000, Salt Lake City, Utah, October 2000, Springer Verlag, Lecture Notes in Computer Science, Vol. 1920, p. 513-526. [GRA 95] GRAHAM I.. Migrating to Object Technology, Addison-Wesley, 1995. [HAR 99] HARRISON R., COUNSELL S.J., NITHI R.V., "Experimental assessment of the effect of inheritance on the maintainability of object-oriented systems", Proceedings of the 3rd International Conference on Empirical Assessment & Evaluation in Software Engineering EASE '99, Keele, UK, 1999. [KAN 90] KANG K.C., COHEN S.G., HESS J.A., NOVAK W.E., PETERSON A.S., FeatureOriented Domain Analysis (FODA) Feasibility Study, technical report CMU/SEI-90-TR21 (ESD-90-TR-222), November 1990, Software Engineering Institute, Carnegie-Mellon University. [LI 93] LI W., HENRY S., "Object-Oriented Metrics that Predict Maintainability", Journal of Systems and Software, Vol. 23, No. 2, 1993, p. 111-121. [PER 99] PERIYASAMY K., LIU X., "A New Metrics Set for Evaluating Testing Efforts for Object-Oriented Programs", Proceedings of TOOLS'99, Santa Barbara, Calif, August 1999, p. 84-93. [POE 99a] POELS G., "On the Use of a Segmentally Additive Proximity Structure to Measure Object Class Life Cycle Complexity", DUMKE, R., ABRAN, A. (eds.). Software Measurement: Current Trends in Research and Practice, Wiesbaden, Deutscher Universitats Verlag, 1999, p. 61-79. [POE 99b] POELS G., DEDENE G., "Modelling and measuring object-oriented software attributes with proximity structures". Proceedings of the 3rd International ECOOP Workshop on Quantitative Approaches in Object-Oriented Software Engineering WQAOOSE'1999, Lisbon, June 1999, p. 1-22. [POE 00] POELS G., DEDENE G., "Distance-based software measurement: necessary and sufficient properties for software measures". Information and Software Technology, Vol. 42, No. L 2000, p. 35-46. [POE 01] POELS G., DEDENE G., "Evaluating the Effect of Inheritance on the Modifiability of Object-Oriented Business Domain Models", Proceedings of the 5th European Conference on Software Maintenance and Reengineering CSMR '2001, Lisbon, March 2001, p. 20-29.

86


[ROB 79] ROBERTS F.S., Measurement Theory with Applications to Decisionmaking, Utility, and the Social Sciences. Addison-Wesley, 1979. [SNO 99] SNOECK M., DEDENE G., VERHELST M, DEPUYDT A., Object Oriented Enterprise Modelling with MERODE, Leuven, Academic Press, 1999. [SNO 00] SNOECK M., POELS G., "Improving the Reuse Possibilities of the Behavioural Aspects of Object-Oriented Domain Models", Proceedings of the 19th International Conference on Conceptual Modeling ER'2000, Salt Lake City, Utah, October 2000, Springer Verlag, Lecture Notes in Computer Science, Vol. 1920, p. 423-439. [SUP 89] SUPPES P., KRANTZ D.M., LUCE R.D., TVERSKY A., Foundations of Measurement: Geometrical, Threshold, and Probabilistic Representations, San Diego. Academic Press, 1989. [TEG 95] TEGARDEN D.P.. SHEETZ S.D., MONARCHI D.E., "A Software Complexity Model of Object-Oriented Systems", Decision Support Systems: An International Journal, Vol. 13, 1995, p. 241-262. [ZEL 97] ZELKOWITZ M.V., WALLACE D., "Experimental Validation in Software Engineering". Proceedings of the 1st International Conference on Empirical Assessment & Evaluation in Software Engineering EASE '97, Keele, UK, March 1997. [ZUS 98] ZUSE H., A Framework for Software Measurement, Berlin, Walter de Gruyter, 1998.

Chapter 5

Class cohesion as predictor of changeability: an empirical study Hind Kabaili, Rudolf Keller and Frangois Lustman Departement IRO, Universite de Montreal, Canada

1. Introduction The use of object-oriented (OO) technology for developing software has become quite widespread. Researchers assert that OO practice assures good quality software. By quality software, they mean 'maintainable, reusable, and easily extensible'. Industrial buyers want to be sure of the quality of the product they acquire. For this, they need OO measures, to evaluate the software they want to buy. For various reasons, Bell Canada, the industrial partner in this project1, is interested in buying large-scale software rather than developing it. It needs to be sure of the quality of the systems it acquires. As part of the project, design properties are investigated as changeability indicators. To assess with some objectivity the quality of a design, we need to quantify design properties. The best known and most used design properties in OO design are coupling and cohesion. In the realm of OO systems, experiments have been conducted showing that coupling between classes is an indicator of changeability. Chaumun et al observed a high correlation between changeability and some coupling metrics, across different industrial systems and across different types of change [CHA 00]. However, measuring coupling is difficult and time consuming since it is an inter-class property. In fact, to measure it, the knowledge of the whole system and of all links between classes must be mastered. Cohesion is an intra-class property; to measure it we only need to consider the studied class. Also, a widely held belief in the design community states that high cohesion is related to low coupling. Because of this supposed relationship, we decided to investigate cohesion as a changeability indicator.

1. This research was supported by the SPOOL project organized by CSER (Consortium for Software Engineering Research) which is funded by Bell Canada, NSERC (National Sciences and Research Council of Canada), and NRC (National Research Council of Canada).

88


Module cohesion was introduced by Yourdon and Constantine as "how tightly bound or related the internal elements of a module are to one another" [YOU 79]. A module has a strong cohesion if it represents exactly one task of the problem domain, and all its elements contribute to this single task. They describe cohesion as an attribute of design, rather than code, and an attribute that can be used to predict reusability, maintainability, and changeability. However, these assumptions have never been supported by experimentation. In this work, we try to find out if cohesion can be used to predict the changeability of an OO system. By changeability of a system, we mean its capacity to absorb changes. Due to the belief that cohesion and coupling are related, we decided to correlate these two design properties. By showing this correlation, we will be able to assert that cohesion is a changeability indicator, too. Given the negative result of this shortcut experimentation, we conduct a second experimentation. A change impact model was used to calculate the changeability of the test systems, and thus to test the relationship between cohesion and impact of change. The paper is organized as follows. Section 2 presents an overview of cohesion as a design property. Section 3 describes the potential relationship between cohesion and coupling, and the empirical validation. Because of a lack of correlation in the shortcut experimentation, we conducted a direct test between cohesion and changeability and reported it in Section 4. The negative result of the two experimentations led us to investigate the reasons behind this lack of relationship. This investigation is described in Section 5. Section 6, finally, summarizes the work and provides an outlook into future work.

2. Cohesion and cohesion metrics There is a consensus in the literature on the concept of class cohesion. A class is cohesive if it cannot be partitioned into two or more sets defined as follows. Each set contains instance variables and methods. Methods of one set do not access directly or indirectly variables of another set. Many authors have implicitly defined class cohesion by defining cohesion metrics. In the OO paradigm, most of the cohesion metrics are inspired by the LCOM metric defined by Chidamber and Kemerer (C&K) [CHI 94]. According to these authors "if an object class has different methods performing different operations on the same set of instance variables, the class is cohesive". As a metric for assessing cohesion, they define LCOM (Lack of Cohesion in Methods) as the number of pairs of methods in a class, having no common attributes, minus the number of pairs of methods having at least one common attribute. The metric is set to zero when the value is negative. Li and Henry [LI 93] redefine LCOM as the number of disjoint sets of methods accessing similar instance variables.

Class cohesion as predictor of changeability

89

Hitz and Montazeri [HIT 95] restate Li's definition of LCOM based on graph theory. LCOM is defined as the number of connected components of a graph. A graph consists of vertices and edges. Vertices represent methods. There is an edge between 2 vertices if the corresponding methods access the same instance variable. Hitz and Montazeri propose to split a class into smaller, more cohesive classes, if LCOM >1. Bieman and Kang [BIE 95] propose TCC (Tight Class Cohesion) and LCC (Loose Class Cohesion) as cohesion metrics, based on Chidamber and Kemerer's approach. They too consider pairs of methods using common instance variables (constructors and destructors are not taken into account). However, the way in which they define attribute usage is different. An instance variable can be used directly or indirectly by methods. An instance variable is directly used by a method M, if the instance variable appears in the body of the method M. The instance variable is indirectly used if it is directly used by another method M' which is called directly or indirectly by M. Two methods are directly connected if they use directly or indirectly a common attribute. Two methods M and M' are indirectly connected if M is directly connected to M" and M" is directly connected to M'. TCC is defined as the percentage of pairs of methods that are directly connected. LCC counts the pairs of methods that are directly or indirectly connected. We recall that constructors and destructors are not taken into account for computing LCC and TCC. The range of TCC and LCC is always in the [0,1] interval. They propose three ways to calculate TCC and LCC: (1) include inherited methods and inherited instance variables in the analysis, (2) exclude inherited methods and inherited instance variables from the analysis, or (3) exclude inherited methods but include inherited instance variables. In respect to the three ways of calculating their metrics, Bieman and Kang do not express any preference. We opted for evaluating them according to the first way, considering inheritance as an intrinsic facet of OO systems. LCC is an extension of TCC in that additional features are taken into account. LCC being more comprehensive than TCC, we adopted LCC, together with LCOM (original C&K version), as the prime cohesion metrics of our experimentation.

3. Relationship between cohesion and coupling As a principle of good OO design, the components of a class should contribute to one specific task. A non-cohesive class means that its components tend to support different tasks. According to common wisdom, this kind of class has more interactions with the rest of the system than classes encapsulating one single functionality. Thus, the coupling of this class with the rest of the system will be higher than the average coupling of the classes of the system. This relationship between cohesion and coupling means that a non-cohesive class should have a high coupling value. But in spite of the widely-held belief in this relationship, it has never

90


been thoroughly investigated. However, the coupling property has extensively been studied. There is coupling between two classes if one class access or uses some element of the other class. Many metrics that capture interactions between classes have been defined. Chidamber and Kemerer proposed two coupling metrics [CHI 94] that have been validated as fault prone indicators [BAS 96]: - CBO (Coupling between Object Classes): A class is coupled to another one if it uses its member functions and/or instance variables, and vice versa. CBO provides the number of classes to which a given class is coupled; -RFC (Response for a Class): This is the number of methods that can potentially be executed in response to a message received by an object of that class. Briand et al describe coupling as the degree of interdependence among the components of a software system. They defined 18 coupling metrics. This suite takes into account the different OO design mechanisms provided by the C++ language [BRI 97]. While the relationship between cohesion and quality has not been quantitatively assessed, several coupling metrics have been shown to be good quality indicators with respect to some specific quality aspects. We decided to investigate the potential of cohesion metrics as changeability indicators by looking for relationships between cohesion and coupling.

3.1. Selection of metrics To test our hypothesis "low cohesion is correlated with high coupling", we adopted some well-known cohesion and coupling metrics found in the literature. As cohesion metrics, we chose LCC and LCOM (see Section 2.1). For measuring coupling, we adopted CBO and RFC, since these two metrics have been proven to be good indicators of quality [BAS 96] and changeability [CHA 99, CHA 00]. To assess our hypothesis empirically, the following correlation hypotheses must be tested statistically: - For the test system, there is a relationship between the LCC and CBO metrics; - For the test system, there is a relationship between the LCC and RFC metrics; -For the test system, there is a relationship between the LCOM and CBO metrics; -For the test system, there is a relationship between the LCOM and RFC metrics. Thus, in our experiment, we attempted to correlate the LCC and LCOM metrics with the C&K coupling metrics (CBO, RFC) and extend the scope of the LCC and LCOM metrics to the changeability property. During experimentation, we decided to include in our study the NOC (number of children) metric which is usually


91

considered as a coupling metric. Furthermore, we considered four metrics that we derived from the NOC and CBO metrics. Recall that CBO is "approximately equal to the number of coupling with other classes (where calling a method or instance variable from another class constitutes coupling)" [CHI 98]. Below, we present the four metrics, together with the rationale for their consideration: - NOC* (Number Of Children in subtree, also called number of successors in [ABR 93] ): when some component of a class is changed, it may affect not only its children but also the whole subtree of which the changed class is the root. — CBO_NA (CBO No Ancestors: same as CBO, but the coupling between the target class and its ancestors is not taken into consideration): the coupling between the class and its ancestors, taken into consideration by CBO, is irrelevant for change impact, since the ancestors of the target class will never be impacted. To eliminate such "noise", ancestors are excluded in CBO_NA; - CBO IUB (CBO Is Used By: the part of CBO that consists of the classes using the target class): the definition of CBO merges two coupling directions: classes using the target class and classes used by the class. For changeability purposes, the former seems more relevant than the latter one, hence the split; - CBO U (CBO Using: the part of CBO that consists of the classes used by the target class): introduced as a consequence of CBO_IUB, to cover the part of CBO not considered by CBO IUB. In summary, seven metrics were considered: the two C&K coupling metrics (CBO, RFC), one other C&K design metric (NOC) and four changeability-oriented refinements of the C&K metrics suite (NOC*, CBO NA, CBO IUB, CBOJJ). To achieve significant and general results, the data used to test the correlation between cohesion and coupling were collected from three different industrial OO systems, as described below.

3.2. Environment In this section, we first present the three test systems of the experiment. Then, the environment in which the experiment was conducted is described. Finally, we discuss the experimental procedure that was adopted. The systems considered were chosen to meet the objectives of the SPOOL project. They are industrial systems, they vary in size and the domain of at least one of them belong to our research partner area.

92


Table 1. Size metrics of test systems ET+ +

Xforms

System-B

1 117

70 796

291 619

764

3 494

71 209

1 009

12 892

90 426

83

584

1 226

# of methods

450

6 255

8 594

# of variables

1 928

4 460

13 624

2.9 MB

19.3 MB

41.0MB

Lines of code Lines of pure comments Blank lines # of effective classes

Size in repository

The first test system is XForms, which can be freely downloaded from the web [XFO 97]. It is a graphical user interface toolkit for X window systems. It is the smallest of the test systems (see Table 1). ET++, the second test system, is a wellknown application framework [WEI 89]. The version used in the experiment is the one included in the SNiFF+ development environment [TAK 99]. The third and largest test system was provided by Bell Canada, and is called, for confidentiality reasons, System-B. It is used for decision making in telecommunications. Table 1 provides some size metrics for these systems. To calculate the metrics involved in the experimentation, we used the SPOOL environment (see Figure 1). This environment is being developed for the entire SPOOL project and comprises various analysis and visualization capabilities to cope with large-scale software systems [KEL 99]. The environment provides a repository-based solution. A parsing tool, e.g., a compiler front-end, parses the test system source code. GEN++, the C++ implementation of GENOA [DEV 92], was used in this extraction process. The parsed information contains data about all classes and links in the system. This information is captured and fed into a design repository. The schema of the design repository is based on our extended UML (Unified Model Language) metamodel [RUM 99]. The OO database management system POET 5.1 [POE 99] serves as the repository backend, with the schema being represented as a Java 1.1 class hierarchy. Metrics requests are batch-processed using a flexible report generator mechanism. They typically contain information on the metrics as well as on the target class, methods, and variables. This triggers a set of queries corresponding to the specified metrics. The code in these queries uses the metrics request information as parameters to interrogate the repository. Raw results are fetched and processed into ASCII files that obey a specific format and can readily be transferred into spreadsheet programs such as Excel for further statistical processing.


93

Figure 1. Environment for metrics calculation

We collected cohesion metrics values from the three test systems. Furthermore we gathered the values for all seven metrics explained in Section 3.2. For each metric involved in the experimentation, we calculated some descriptive statistics (minimum, maximum, mean, median, and standard deviation; see Appendix A and B). To test the relationship between the cohesion and the coupling metrics we used the Pearson correlation coefficient (see Appendix C). This statistical technique is widely used for measuring the degree of relationship between two variables [SPI 00]. 3.3. Results Descriptive statistics of the three test systems are summarized in Appendices A and B. NOC and NOC* have the same median value for the three systems, 0 for NOC and NOC*. A median of 0 for number of children (NOC) and for NOC* means that for the three systems, half the classes are leaves. Based on this and on the mean value of NOC, it can be stated that classes that do have children have on the average less than two children. These results were found in software systems of different size and application domain, and we conclude that in general inheritance is not strongly used in OO development. Thus, the class trees of such systems will generally be flat.

94


According to C&k [CHI 94] and Bieman and Kang [BIE 95], a class is strongly cohesive when LCC = 1 or LCOM = 0. Appendix A shows the mean value for both LCC and LCOM. Based on the mean value of LCC and LCOM, u(LCC) = 0.62 and H(LCOM) = 5.81, we can conclude that Xforms classes are not so strongly cohesive. For ET++, u(LCC) = 0.42 and u(LCOM) = 89.70. Finally for System-B, u(LCC) = 0.56 and u(LCOM) = 145.73. Based on these values, and referring to the definition of both LCOM and LCC, we concluded that the three test systems classes are not strongly cohesive. Note that a similar reasoning can be used based on the median value of both LCC and LCOM. According to the median value of LCOM, half the classes may be split for Xforms, and more than half for ET++ and System-B. On the other hand, the median values of LCC, for Xforms (0.69) and System-B (0.61), suggest that half the classes have a LCC value bigger that 0.6. This means that half the classes are acceptably cohesive. At this stage we can conclude that there is discrepancy between LCC and LCOM. The Pearson correlation coefficients are presented in Appendix C. According to these coefficient values, no correlation can be claimed between the LCC and LCOM metrics and CBO and RFC (we also checked for outliers). Moreover, no correlation was found between the tested cohesion metrics and the five other metrics of the study. No general conclusion was drawn at this stage. However, these negative results were found for two cohesion metrics and seven coupling metrics (CBO, RFC, NOC, NOC*, CBO_NA, CBO IUB, CBO U), across three industrial systems of different size and origin. Therefore, we put forward the following hypothesis: in general, there is no relationship between these cohesion metrics and coupling metrics. It is early to conclude from the negative results of this experimentation that cohesion is not a changeability indicator. We conducted a second experimentation to correlate cohesion and changeability through a change impact model.

4. Relationship between cohesion and impacts of change 4.1. Change impact model One way assessing the changeability of an OO system is by performing a change impact analysis. In this work, the changeability of OO software is assessed by an impact model defined in [CHA 98] [CKK 99]. Below we detail the changes considered and the links involved, and we introduce the notions of impact and impact expression.


95

4.1.1. Changes A change applies to a class, a variable or a method. Examples are deleting a variable, changing the signature of a method, or removing a class from the list of parents of another class. Thirteen changes have been identified: Variable: addition, deletion, type change, and scope of change. Method: addition, deletion, return type change, implementation change, signature change, and scope change. Class: addition, deletion, and inheritance relationship change. The changes considered in this paper are atomic changes. More complex changes, for instance refactoring operations such as moving a variable or a method along the class hierarchy, or inserting a new class to factor out some common characteristics of a group of classes, will be addressed in future work. In this way, changes can be dealt with at a higher level of abstraction. 4.1.2. Links The following links connect classes one to another. They reflect usual connections in OO systems, and are not specific to any particular OO programming language. S (association): one class references variables of another class. G (aggregation): the definition of one class involves objects of the other class. H (inheritance): one class inherits the features defined in another (parent) class. I (invocation): methods in one class invoke methods defined in another class. Any number and type of links between two classes may be found. Note that instantiation is not a link in its own right, but is taken into account with the invocation link. A change in a class may also have an impact in the same class. The pseudo-link L (local) is introduced to express this. We also consider a special notation commonly used in the Boolean algebra; the prime after a link, means the set of classes not associated with that special link. For example G' means the set of classes that are not associated with the aggregation link to the specified class. 4.1.3. Impact We call impact of a change the set of classes that require correction as a result of that change. It depends on two factors. One is the type of change. For example, a change to a variable type has an impact on all classes referencing this variable whereas the addition of a variable has no impact on those classes. Given a type of change, the other factor is the nature of the links involved. If, for instance, the scope of a method is changed from public to protected, the classes that invoke the method will be impacted, with the exception of the derived classes. Note that we limit ourselves to syntactic impact; considering semantic impact, for instance runtime errors, is beyond the scope of this paper. The impact of change chj to class cli is

96


defined by a set expression E in which the variables are the sets defined by the various links: Impact (cli, chj) = E (S, G, H, I, L) For example, Impact(cli, chj) = SH'+G means that the impacted classes are those associated (S) with, but not inheriting (H') from cli or those aggregated (G) with cli.

4.2. Application to C++ The industrial partner of our project was interested in the evaluation of programs in C++ for which only the code was available. The model was therefore mapped into that language. In the C++ model, a change is a syntactic change to the code, and impact is considered if as a result of the change, the code at some other place, does not recompile successfully. The links identified in the conceptual model exist at the code level, and an additional one, F for friendship is added to reflect the existence of this feature in C++. Changes were enumerated and for each, the impact setexpression was derived by examining all possible combinations of links between a changed class and another class. As an example, the change in a variable scope from public to private (code change from public int v; to private int v;) results in the impact SF', meaning that the impacted classes are those linked to the changed class by association but not by friendship. The 13 changes defined at the conceptual level expanded to 66 changes in C++, and their impact expression was compiled, 12 for variables, 35 for methods, and 19 for classes (see [CHA 98] for the list of changes and impact calculations).

4.3. Empirical validation To test the hypothesis that cohesion is correlated to changeability, we adopted the same cohesion metrics, LCC and LCOM used in the first experimentation (see Section 2.1). For lack of resources, we were unable to investigate the whole list of 66 changes of our impact model for C++ (see Section 2.3). Rather, we limited ourselves to six changes, which we selected according to four criteria. First, there should be at least one change for each component (variable, method, and class). Second, a selected change should indeed have an impact in at least one other class (according to our model, there are 29 changes with no such impact). Third, the impact expression should be different for any pair of changes; since otherwise, we would have obtained duplicate results. And fourth, as an informal criterion, we required the selected


97

changes to be of practical relevance, that is, they should be suitable to be exercised in practice. Table 2 lists the six changes considered and their corresponding impact expressions. Table 2. Investigated changes with impact expressions Change

1. 2. 3. 4. 5. 6.

Variable type change Variable scope change from public to protected Method signature change Method scope change from public to protected Class derivation change from public to protected Addition of abstract class in class inheritance structure

Impact Expression S+L SH'F' I+L

H'lF'

H'F'(S + 1) S+ G+ H+ I+L

In the experiment, we first extracted the LCC and LCOM metrics from the test systems. Next, for each of the six changes considered, and each of the test systems, we determined its test set, that is, the set of classes for which the change is applicable. For example, when considering the method scope change from public to protected (Change #4), only classes with at least one public method were included in the test set. Then, for each class in each test set, the change impact for the given change was calculated, i.e., the number of classes that would be impacted. If the change was one that affected a variable or method component (Changes # 1 through #4), the change impacts for each individual variable or method of the given class were added together, and the total was divided by the number of variables or methods in the class. Once the metrics and impact data were collected, we investigated the correlation between each change impact and each design metric for all the classes involved in the test sets. Then, in each case the correlation coefficient was calculated.

4.4. Results Each of the six changes was applied to each test system. The impact values are presented in Appendix D. The values vary from one system to another, from one change to another, and no general conclusion can be drawn on the impact of a given change. Comparison

98


between changes, however, yields some results. Based on both mean values and median values, a classification of changes by impact comes out. Among the six changes investigated, the most expensive one, across systems, is the addition of an abstract class in the inheritance structure of a class (Change #6). On the other hand, the least expensive one is to change the scope of a method from public to protected (Change #4). This might have been expected, considering their impact expressions. The Pearson correlation coefficients are presented in Appendix E. Two exceptions aside, most correlation coefficients for the two cohesion metrics are weak. The two exceptions are, for Xforms, the correlation coefficients between LCC and the change #1 and between LCC and change #5 are around 0.5. However, there are not significant enough to confirm the correlation hypothesis.

5. Investigation The goal of our study was to find a correlation between cohesion and changeability, but the result was negative. Consequently, we set out to reason about this absence of correlation. We came up with the following two explanations: (1) the cohesion or coupling metrics chosen for the experimentation or the impact of changes are not the right ones, (2) there is no relationship between cohesion and changeability. Explanation (2), being counter to a widely held belief in the design community, was discarded. We then focused our investigation on hypothesis (1). We derived from (1) the following sub-hypotheses: (1A) The LCC and LCOM metrics do not correctly measure cohesion; (1B) The CBO and RFC metrics do not correctly measure coupling; (1C) The change impact model is not correct. The coupling metrics were validated in [HAR 98], and widely used with no major problem reported [BAS 96, CHA 00], thus sub-hypothesis (IB) was rejected. Sub-hypothesis (1C) was also rejected on the grounds that the change impact model is quite well validated [CHA 99]. On the other hand, we questioned the quality of the investigated cohesion metrics (sub-hypothesis (1A)). Intuitively, when they show a high class cohesion (LCC = 1 or LCOM = 0), the classes are probably quite cohesive. However, we were doubtful about the expressiveness of LCOM and LCC in the presence of weak class cohesion. Thus, we set out to study manually various weakly cohesive classes occurring in the three test systems.

5.1. Study of weakly cohesive classes According to the cohesion concept, a weakly cohesive class is designed in an ad hoc manner, and unrelated components are included in the class. The class


99

represents several disparate concepts and may be split into several classes, each one modelling only one single concept. Based on anecdotal evidence, we suspected that, although LCC and LCOM indicate weak cohesion, it might not necessarily be true that the classes at hand must be broken into smaller components. To validate or reject this idea, we decided to manually inspect weakly cohesive classes. We chose from each of the three test systems classes that exhibit weak cohesion (LCC < 0.5 and/or LCOM > 0), to verify if they are real candidates for splitting. After studying these classes, we found that many of them should not be split. We came up with four major reasons for not splitting them. First, some classes had no variables or only abstract methods, yielding low LCC values (and positive LCOM values). Second, we noticed that for some classes, the LCC value is reduced by counting inherited variables or inherited values. For these cases, we calculated LCC without taking into account inherited components, and not surprisingly, we obtained LCC values indicating stronger class cohesion. Third, some classes have multiple methods that share no variables but perform related functionalities. Putting each method in a different class would be counter to good OO design and the very idea of cohesiveness. Fourth, we identified several classes that have numerous attributes for describing internal states, together with an equally large number of methods for individually manipulating these attributes. Based on this analysis, we notice that low values of LCC and high values of LCOM do not assure a weakly cohesive class. We conclude that as measured, LCC and LCOM do in general not reflect the cohesion property of a class.

5.2. Additional cohesion properties The results obtained in our study call for a refinement of the definition of cohesion metrics, in order to better measure the cohesion property as stated by OO design principles. It is our belief that a true cohesion metric will have to go beyond the simple sharing of class variables and capture additional information. Briand et al provide a categorization of cohesion metrics [BRI 98]. LCOM is counted as a cohesion metrics based on common attribute usage in a class. LCC belongs to the cohesion metrics category that is based on both common attribute usage and method invocations within a class. Chae and Kwon, in their recent paper, reflect on the weakness of current research on class cohesion measures [CHE 98]. They observe that existing approaches do not consider the special methods that interact with only part of the instance variables and thus reduce class cohesion. As examples, they mention accessor methods,

100


delegation methods, constructors, and destructors. They propose that special methods be treated such that they do not compromise the value of the cohesion metrics. Furthermore, Chae and Kwon suggest that cohesion metrics take into account additional characteristics of classes, for instance, the patterns of interaction among the members of a class. Their reasoning about special methods confirms the fourth reason we brought up in the previous section. We believe that this work clearly constitutes an improvement in calculating class cohesion. However, it is our contention that we must take into account not only the patterns of interaction among class members, but also the semantics of these interactions. Based on our investigation results, we furthermore assert that cohesion measures must take into account the functionality of class methods as well as the unity of the data that describe the entity modeled by the class.

6. Conclusion In this paper, our major goal was to validate cohesion metrics as changeability indicators. To this end, we tried to correlate cohesion metrics with coupling metrics that had been proven as quality indicators. We chose LCC and LCOM as cohesion metrics, and CBO and RFC were chosen as the primary coupling metrics. We collected data about these metrics on three different industrial systems. Our experimentation showed no correlation between cohesion and coupling metrics chosen. A second experimentation was conducted to correlate cohesion metrics with impact of change. First, a model of software changes and change impact was adapted for C++ language. For practical reasons, we only investigated six changes, chosen to be representative of C++ systems changes. Furthermore, we limited our definition of change impact to recompilation errors. The negative results of the two experimentations led us to think about reasons of the lack of correlation. We suspected that the cohesion metrics used in the experimentation do not reflect the real cohesion of a class. We decided to investigate manually classes with low cohesion metric values. We found that although some classes have low LCC and/or high LCOM, these classes are actually cohesive. A cohesion measure based on the variable sharing aspect is a special way of capturing class cohesion. This restricted definition led to cohesion measures with misleading values in several situations. Such situations occur, for instance, when classes have abstract methods or when a class inherits a large number of methods or instance variables from its superclass. When taking into account these abstract methods or inherited components, the cohesion value of a class is reduced, resulting in misleading class cohesion values. In our belief, class cohesion metrics should not exclusively be based on common attribute usage and method invocation, but also on patterns of interaction between class members, on the functionality of class methods, and on the conceptual unity of its instance variables.


101

Based on these results we came up with two conclusions. The original idea that cohesion is easy to measure must be rejected. And, as long as a new cohesion metric is not defined, taking into account important facets of the cohesion property, actually defined cohesion metrics cannot be trusted as changeability indicators. As future work, we are trying to feed our database with new test systems. In the same direction, we project to extend the change impact model.

7. References [ABR 93] ABREU F. B., "Metrics for Object-Oriented Environment", In Proceedings of the Third International Conference on Software Quality, Lake Tahoe, Nevada, October 4-6, 1993, p. 67-75. [BAS 96] BASILI V., BRIAND L. C, MELO W. L., "A validation of object-oriented design metrics as quality indicators", In IEEE Transactions on Software Engineering, Vol. 22 No 10, p. 751-761, October 1996. [BRI 97] BRIAND L., DEVANBU P., MELO W. L., "An investigation into coupling measures for C++", In Proceedings of the International Conference on Software Engineering (ICSE'97), p. 412-421, Boston, MA, May 1997. [BIE 95] BIEMAN J. M., KANG B. K., "Cohesion and reuse in an object-oriented system", In Proceedings of the Symposium on Software Reusability (SSR '95), p. 259-262, Seattle, WA, April 1995. [BRI 98] BRIAND L. C., DALY J., WUST J., "A unified framework for cohesion measurement in object-oriented systems", In Empirical Software Engineering - An International Journal, Vol. 3, No 1, p. 67-117, 1998. [CHA 98] M. A. Chaumun. Change impact analysis in object-oriented Systems: Conceptual Model and Application to C++, Master's thesis, Universite de Montreal, Canada, November 1998. [CHA 99] Chaumun M. A., Kabaili H., Keller R. K., Lustman F. "A change impact model for changeability assessment in object-oriented systems", In Proceedings of the Third Euromicro Working Conference on Software Maintenance and Reengineering, p. 130138, Amsterdam, The Netherlands, March 1999. [CHA 00] CHAUMUN M. A., KABAILI H., KELLER R. K., LUSTMAN L.,ST-DENIS G., "Design properties and object-oriented software changeability", In Proceedings of the Fourth Euromicro Working Conference on Software Maintenance and Reengineering, p. 45-54, Zurich, Switzerland, February 2000, IEEE. [CHE 98] CHAE H. S., KWON Y. R., "A cohesion measure for classes in object-oriented systems". In Proceedings of the Fifth international Software Metrics Symposium, p. 158166, Bethesda, MD, November 1998. [CHI 94] CHIDAMBER S. R., KEMERER C. F., "A Metrics Suite for Object Oriented Design", In IEEE Transactions on Software Engineering, Vol. 20, No 6, p. 476-493, June 1994.

102


[CHI 98] CHIDAMBER S. R., DARCY D. P., KEMERER C. K., "Managerial use of metrics for object-oriented software: An exploratory analysis", In IEEE Transactions on Software Engineering, Vol. 24, No 8, p. 629-639, August 1998. [DEV 92] DEVANBU P. T., "GENOA - a customizable, language- and front-end independent code analyzer", In Proceedings of the 14lh International Conference on Software Engineering (ICSE'92), p. 307-317, Melbourne, Australia, 1992. [HAR 98] Harrison R., Counsell S.J., Nithi R. , "An Investigation into the Applicability and Validity of Object-Oriented Design Metrics", In Empirical Software Engineering: An InternationalJournal,, p. 255-274, Vol. 3, No 3, 1998. [HIT 95] HITZ M., MONTAZERI B., "Measuring coupling and cohesion in object-oriented systems", Proc. Int. Symposium on Applied Corporate Computing, p. 25-27, October, 1995. [KEL 99] KELLER R. K.., SCHAUER R., ROBITAILLE S., PAGE P., "Pattern-based reverse engineering of design components", In Proceedings of the Twenty-First International Conference on Software Engineering, p. 226-235, Los Angeles, CA, May 1999. [LI 93] LI W., HENRY S., "Object-oriented metrics that predict maintainability", In Journal of Systems and Software, Vol. 23, p. 111-122, February, 1993. [POE 99] POET SOFTWARE CORPORATION, San Mateo, CA. POET Java ODMG Binding. Online documentation, 1999. Available online at . [RUM 99] RUMBAUGH J., JACOBSON I., BOOCH G., The Unified Modeling Language Reference Manual, Addison-Wesley, 1999. [SPI 00] SPIKARD J., Understanding Correlation By Looking At Crime Rates, Available online at: , 2000. [TAK 99] TAKEFIVE GMBH, Salzburg, Austria. SNiFF+ Documentation Set, 1999. Available online at: . [WEI 89] WEINAND A., GAMMA E., MARTY R., "Design and implementation of ET++, a seamless object-oriented application framework", In Structured Programming, Vol. 10, No 2, p. 63-87, April-June, 1989. [XFO 97] XFORMS LIBRARY. Graphical user interface for X. Documentation Set, 1997. Available online at . [YOU 79] YOURDON E., CONSTANTINE L. L., Structured Design, Prentice Hall, Englewood Cliffs, N.J., 1979.

Class cohesion as predictor of changeability Appendix A: Cohesion metrics results for the test systems

System

LCC 0

LCOM

1

208

0.62 0.69

5.81

Std. Dev. Minimum Maximum Mean Median

0.27

25.40

Std. Dev. Minimum Maximum Mean Median

0.31

Std. Dev.

0.31

Minimum

X Forms 83 classes

Maximum Mean Median

ET++ 584 classes

System-B 1226 classes

0

1 0

0 1

4714 89.07

0.42 0.33

6 352.81

0

0 1

11706 145.73

0.56 0.61

10 695.72

Appendix B: Coupling metrics results for the test systems

System

XForms 83 classes

ET++ 584 classes

System-B 1226 classes

Minimum Maximum Mean Median Std. Dev. Minimum Maximum Mean Median Std. Dev. Minimum Maximum Mean Median Std. Dev.

CBO NA

CBO IUB

CBO U

RFC

0 20

0 20

0 19

0 9

0 45

2.57

4.13

3.16

0.98

3.16

6.52

0

4

3

0

4

2

2.34

9.57

3.16

3.16

3.05

1.95

9.85

0 56

0 361

0 301

0 301

0 293

0 76

0 746

0.78

2.09

24.48

19.80

0

24

0

21

3.45

17.05

25.40

22.5 21.5 24.63

5.01

0

21.28

15.89

90.65 36.5 128.98

0 29

0 266

0 707

0 707

0 707

0 93

0.88

3.42

32.49

29.36

7.06

25.77

2735 171.02

0

0

21

18

1

17

47

2.53

18.51

36.14

34.96

29.48

23.95

286.85

NOC

NOC* CBO

0 14

0 60

0.82

0

0

103

104


Appendix C: Correlation coefficient between cohesion and coupling

Cohesion metrics

LCC

LCOM

System

NOC

XForms ET+ + System-B XForms ET+ + System-B

NOC* CBO

-0.09 -0.10 -0.06 0.12 0.30 0.08

-0.15 -0.05 -0.08 -0.01 0.31 0.21

-0.17 -0.11 -0.02 0.06 0.44 0.28

CBO CBO CBO RFC UIB NA U -0.03 -0.22 -0.10 -0.17 0.04 -0.23 -0.10 -0.05 -0.05 -0.03 -0.01 -0.07 0.17 -0.17 0.11 0.33 0.39 0.21 0.45 0.38 0.32 0.07 0.30 0.36

Appendix D: Impacts results for the three test systems

Change

1.

Variable type change

2. Variable scope change

from public to protected

3. Method signature change

4. Method scope change

from public to protected

5.

Class derivation change from public to protected Addition of abstract

6. class in class inheritance structure

System

Min.

Max.

XForms ET+ + System-B XForms ET+.+ System-B XForms ET+ + System-B XForms ET+ + System-B XForms ET+ + Svstem-B XForms ET+ + System-B

1 1 1 0 0 1 1 1 0 0 0 0 0 0

20 81 32 80 52

1 1 1

3.67 17.64 38.60 2.67 16.64 37.39

4 281 291 64 393 743

Mean Median

1.78 2.02 1.46

3.78 1.84 1.19 1.46 1.77 0.18 0.40 0.60 0.32 3.71 4.42 4.90 8.84 11.34

1 1 1 0.672

1 1 1 1 0 0 0 0 0 0

1 2 2

Std. Dev. 3.17 5.97 1.85

12 • 6.21 0.49 1.26 2.06 0.48 1.19 1.79 0.89 16.46 20.03 11.49 31.16 38.20

2. Note that the impact values are calculated as averages (see Section 3.2), and hence a median need not be an integer.


Appendix E: Correlation coefficient between cohesion and impact

Change

1. Variable type change

2.

3.

4.

5.

Variable scope change from public to protected Method signature change Method scope change from public to protected Class derivation change from public to protected

6. Addition of abstract class in class inheritance structure

3. There is one class in the test set.s

System XForms ET+ + System-B XForms ET+ + System-B XForms ET+ + System-B XForms ET+ + System-B XForms ET+ + System-B Xforms ET+ + System-B

LCC -0.52 0.11 -0.06

LCOM 0.11 0.18 0.02

3

1

0.31 -0.10 -0.44 -0.02 -0.07 -0.44 0.25 0.01 -0.52 0.01 -0.01 -0.39 0.03 -0.07

0.06 -0.01 -0.01 0.31 0.21 0.09 0.12 0.13 0.30 0.36 0.05 -0.01 0.34 0.35

105


Chapter 6

Building quality estimation models with fuzzy threshold values Houari A. Sahraoui Departement d'lnformatique, Universite de Montreal, Canada

Mounir Boukadoum and Hakim Lounis Departement d'lnformatique, Universite du Quebec a Montreal, Canada

1. Introduction Object oriented (OO) design and programming have reached the maturity stage, OO software products are becoming more complex and time consuming. It has been estimated as 60% the part devoted to maintenance of the total effort of the software development industry [PRE 97],of which 80% is devoted directly or indirectly to software evolution (adaptive and perfective maintenance) [PIG 97]. Quality requirements are increasingly becoming determining factors in the choice of design alternatives during software development. Indeed, the solutions adopted often depend on whether the designer (programmer) concentrates on reliability, maintainability or reusability. In this context, it is crucial to automate the detection of symptomatic situations (e.g. problematic constructs in the code and/or design) according to some quality characteristic. It is also crucial to find ways to propose alternatives that allow given quality requirements to be reached. Several works have shown that metrics can successfully be used to measure the quality of a system (see, for example, [HEN 96] and [LOR 94]). Software measures have been extensively used to help software managers, customers, and users to assess the quality of a software product. However, most of the quality characteristics are not directly measurable a priori. For example, the maintainability of a software product (which can be measured by the maintenance effort) can only be measured after a certain time in use. On the other hand, even if structural metrics cannot measure these characteristics directly, they can be good indicators of them. In this case, we speak of estimation models. Many large software companies have intensively adopted estimation models to better understand the relationships between software quality and software product internal attributes, in order to improve their software development processes. For instance, software product measures have successfully been used to assess software maintainability and error-proneness. Large

108


software organizations, such as NASA and HP, have been able to estimate costs and delivery time via software product measures. Estimation models can take different forms depending on the building technique that is used. For example, they can be mathematical models (case of statistical techniques like linear and logistic regression). They can also be rule sets or decision trees (case of machine learning algorithms). In all cases, they involve ascribing a value to a quality characteristic based on the values of a set of software measures, and they also involve the detection of design and implementation anomalies early in the software life cycle. They also allow organizations that purchase software to better evaluate and compare the offers they receive. In most techniques, the estimation process depends on threshold values that are derived from a sample base. This dependency raises the problem of representativity for the samples, as these often do not reflect the variety of real-life systems. In this respect, what is needed is not the determination of specific thresholds but the identification of trends. This work circumvents the problem of using precise metric thresholds values associated with estimation models by replacing them with fuzzy thresholds. The paper is organized as follow. Section 2 gives an idea of existing work in the field. In Section 3, we briefly present two examples of techniques to build quality estimation models and we discuss their limits. Our fuzzy logic based approach is described in Section 4. To better illustrate our contribution, we discuss in Section 5 its application to the particular case of assessing class library interface evolution. In Section 6, we introduce a new approach that combines fuzzy logic with domain specific knowledge to improve the estimation accuracy. Finally, Section 7 provides our conclusions.

2. Related work Since an important part of the quality characteristics of software products is not directly measurable a priori, empirical investigations of measurable internal attributes and their relationship to external quality characteristics are crucial for improving the assessment of a software product quality [FEO 00]. In this context, a large number of object-oriented (OO) measures have been proposed in the literature (see, for example, [BRI 97], [CHI 94], [LIH 93] and [BIE 95]). Basili & al show in [BAS 96] that most of the metrics proposed by Chidamber and Kemerer in [CHI 94] are useful for predicting the fault-proneness of classes during the design phase of OO systems. In the same context, Li and Henry have shown that the maintenance effort may be predicted using combinations of metrics collected from the source code of OO components [LIH 93]. In the case of reusable components, Demeyer and Ducasse show in [DEM 99] that, for the particular domain of OO frameworks, size and inheritance metrics are good indicators for the stability of a framework but are not reliable to detect problems. Basili & al [BAS 97] conducted a study to model and understand the cost

Building quality estimation models

109

of rework for a library of reusable software components; a predictive model of the impact of error source on rework effort was built. In the same vein, Price and Demurjian [PRI 97] presented a technique to analyze and measure the reusability of OO designs; a set of eight metrics were derived from the combination of two classifications: general vs. specific, and related to other classes vs. unrelated. These metrics would help evaluate OO systems from a reuse standpoint. For example, a dependency from a General class to another General class in related hierarchies is good for reuse, while a dependency from a General class to a Specific class in related hierarchies is bad for reuse. Close to the technique that we have followed, Genero & al [GEN 00] have proposed a fuzzy regression tree-based approach to empirically assess the quality of entity relationship diagrams, the dominant conceptual modeling method in the database community. In the past, our team has explored both statistical and machine learning techniques as modeling approaches for software product quality. For instance, we have proposed models to measure reusability [MAO 98] and class fault-proneness [BRI 99]. In [DAL 99], we conducted an empirical study of different ML algorithms to determine their capability to generate accurate correctability models. The study was accomplished on a suite of very-well known, public-domain ML algorithms belonging to three different families of ML techniques. The algorithms were compared in terms of their capability to assess the difficulty of correct Ada faulty components.

3. Machine learning based approaches In previous work, we have preferred the use of ML algorithms in order to build software quality predictive models. Our reason was that real-life software engineering data are incomplete, inexact, and often imprecise; in this context, ML could provide good solutions. Another reason was that, somehow, ML produces predictive models with superior quality than models based on statistical analysis. ML is also fairly easy to understand and use. But, perhaps the biggest advantage of a ML algorithm - as a modeling technique- over statistical analysis lies in the fact that the interpretation of production rules is more straightforward and intelligible to human beings than principal components and patterns with numbers that represent their meaning. In this section, we present two popular algorithms, C4.5 and RoC, which represent the Top Down Induction of Decision Trees (TDIDT) and Bayesian approaches to ML. We then outline their limitations when dealing with software quality estimation models. Most of the work done in ML has focused on supervised ML algorithms. Starting from the description of classified examples, these algorithms produce definitions for each class. In general, they use an attribute-value representation language that allows the exploitation of the learning set statistical properties, leading to efficient

110


software quality models. C4.5 is representative of the TDIDT approach [QUI 93]. We used it in past work to generate estimation models in software engineering. This was the case in [MAO 98] where the goal was to assess an empirical value of reusability starting from coupling, inheritance, and complexity metrics on OO systems. C4.5 belongs to the divide and conquer algorithms family. In this family, a decision tree generally represents the induced knowledge. C4.5 works with a set of examples where each example has the same structure, consisting of a number of attribute/value pairs. One of these attributes represents the class of the example. Usually the class attribute takes only the values {true, false}, or {success, failure}. The key step of the algorithm is the selection of the "best" attribute to obtain compact trees with high predictive accuracy. A measure of entropy is used to measure how informative a node is. Given an attribute A that takes on values from a set {ai}i i, n and a probability distribution P={p(a i )} i 1 ,„, where p(a i ) is the probability that A=a i , the information conveyed by this attribute is given by Shannon's entropy:

This notion is exploited to rank attributes and to build decision trees where, at each node, we use the attribute with the greatest discrimination power. Closer to probabilistic approaches, RoC is a Bayesian classifier (see [LAN 92]). It is trained by estimating the conditional probability distributions of each attribute, given the class label. The classification of a case, represented by a set of values for each attribute, is accomplished by computing the posterior probability of each class label, given the attributes values, by using Bayes' theorem. The case is then assigned to the class with the highest posterior probability. The following formula corresponds to the probability of the class value C=cj given the set of attribute values ek={Al=alk, ..., Am=amk}:

The simplifying assumptions underpinning the Bayesian classifier are that the classes are mutually exclusive and exhaustive and that the attributes are conditionally independent once the class is known. Recent empirical evaluations have found the Bayesian classifier to be accurate (see [KOH96]) and very efficient at handling large databases (e.g., data mining tasks). RoC extends the capabilities of the Bayesian classifier to situations in which the database reports some entries as unknown. It can then train a Bayesian classifier from an incomplete database. More information about this process is given in [RAM 98].


111

One of the great advantages of C4.5, when compared to RoC, is that it produces a set of rules that is readily understandable by software managers and engineers. However, our past experience with this ML algorithm, as well as with "classical" ML approaches in general, when applied to production software data, reveals weaknesses in the learning/classification process. One of the main points concerns the fact that the generated estimation models are too specific or precise. This is first due to the algorithms themselves, but also to the non-availability of data sets. The consequence of this situation is that we obtain specific models that are not general enough to be efficiently applicable by software managers. In both C4.5 and RoC, the classification process depends on threshold values that are derived from a learning set. This dependency creates a problem in the light of the representativity of the training samples, which often do not reflect the variety of real-life systems. In this respect, identifying trends as the learning set may be more useful than the determination of specific thresholds. For instance, the previous ML algorithms could induce rules, as the following: "if number of methods of a class C is greater than 20, then class C is hard to maintain". Is it then justified to discuss this value of 20; what does it mean? Can a class that has 19 methods be considered, in this context, as similar to one with 20 methods? Are they simply two large classes or do we have to distinguish between them? Another problem concerns the classification problem itself. During the process of classifying a new case, an algorithm such as C4.5 exploits the first valid path/rule while we would expect it to consider all the valid paths/rules, and then deduce a more consensual result. To address these concerns, we propose the fuzzy logic approach of the next section.

4. A fuzzy logic-based approach (FLAQ) The main cause for the problems outlined above is that, in most decision algorithms based on classical ML approaches, only one rule is activated at a time while traversing the decision tree. As a result, only one branch is followed from any given node, leading to one single leave as a conclusion, and exclusive of all other possible paths. While this approach works well for disjoint classes where different categories can be separated with clearly defined boundaries, it is not representative of most real-life problems where the input information is vague and imprecise, when not fragmentary. For such problems, the idea of setting thresholds at the nodes, and, then, of following decision paths based on whether given input attribute values are above or below the thresholds, may lead to opposite conclusions for any two values that are close to a threshold from opposite directions. In such situations, one would like to be able to: - "Partially" activate a rule; - simultaneously activate several rules.

112


These possibilities are not available from algorithms such as C4.5, RoC, and most algorithms that rely on statistics or classical information theory to build the decision tree. In each case, the tree obtained leads to a set of rules of which only one is validated at a time, and where the antecedent of each rule is evaluated to be either true of false, leading to a consequent that is also either true or false. Because each antecedent consists of a comparison to determine whether a given input is above or below a threshold, the end result is that only one of the leaves in the tree will be reached at any given time, all the other leaves being ignored. On the other hand, the use of a fuzzy decision process allows the simultaneous validation of all the rules; each input value is considered to be both above and below the corresponding threshold, but with gradual and typically different certainties. The end result will be the outcome of combining all of the partial results, each contributing its weight to the decision process. The creation of a fuzzy decision tree follows the same steps as that of a classical decision tree: a training set of examples is used in conjunction with a set of attributes to define the tree based on some metric. As a result, partitions of the attributes are defined and a chain of if-then rules is applied to subsequent inputs in modus-ponens fashion to identify a given class. The differences between the two approaches stem from the metrics used, the way partitions are created and the way the tree obtained is interpreted.

4.1. Creation of a fuzzy decision tree Because we obtained better results using the C4.5 algorithm over RoC, we decided to study a fuzzy version of C4.5. The TDIDT approach can easily be employed in the creation of fuzzy decision trees by using fuzzy entropy to measure the information provided by a node. Fuzzy entropy (also called star entropy) is an extension of Shannon's entropy where classical probabilities are replaced by fuzzy ones [TAN 79]. For an attribute A with values {ai}i 1 „, fuzzy entropy is defined as:

where P*() usually stands for the fuzzy probability defined by Zadeh

Fuzzy probabilities differ from normal probabilities in that they represent the weighted average of a set of values provided by a membership function u. These values represent the degrees of membership of a value a, to the different elements (labels), e,, of a fuzzy set.


113

Figure 1. Basic concepts of fuzzy logic

In a fuzzy decision tree, the processing of input attribute values starts with the fuzzification of each attribute so that it takes values from a discrete set of labels. Each label has an associated membership function that sets the degree of membership of a given input value to that label. Because the membership functions of adjacent labels overlap, this results in the weighted and simultaneous membership to multiple labels of each input value, the degree of membership being equal to the value of the membership function (Figure 1). Contrary to classical methods of converting numerical intervals into discrete partitions, fuzzy partitions are not disjoint and consist, each, of an independent fuzzy kernel and a shared transition region. As a result, the partitioning of a learning set into fuzzy attribute partitions involves both the identification of the partition domains, and the identification of the overlap boundaries. These tasks are often carried out heuristically, using an expert's experience. In this work, they were automated using a clustering algorithm based on mathematical morphology [MAR 96]. The algorithm works by applying a sequence of antagonistic, but asymmetrical filtering operations to the input data, until fuzzy kernels are obtained that mostly include representatives of one class each.

4.2. Fuzzy tree inference for classification Another difference between a classical and a fuzzy decision tree is the decision process that they use. Figure 2 illustrates two binary trees of the same height, where one uses sharp thresholds and the other fuzzy thresholds to process the input data. For the given input, applying the rules of binary inference for the first tree and of fuzzy inference for the second, the conclusion reached by the first tree is that the input data corresponds to class 1 (with no possible assignment to class 0). On the

114


other hand, the fuzzy decision tree leads to the conclusion that the input corresponds to class 0 with truth-value 0.65 and class 1 with truth-value 0.31 The obtained fuzzy results may be defuzzified by computing the center-ofgravity (COG) of classes 0 and 1 considered as singletons (i.e. by computing the average of classes 0 and 1, weighted by their truth values) and then by choosing the class that is closest in value to the obtained COG. Alternately, we may simply select the class with the maximum truth-value. This is the approach used in this work as both methods of defuzzification yield the same result in the case of a decision tree with two classes. Decision example for

Figure 2. Classification using binary inference (left) and fuzzy inference (right)

5. Case study: predicting interface evolution using inheritance aspects Because, we cannot easily measure the ability of a software product to evolve in a direct way, starting from its initial version, an indirect approach is to perform the assessment using the relationships that may exist between evolvability and measurable characteristics such as size, cohesion, coupling or inheritance. In this work, we focused our attention on how inheritance aspects can be good indicators of the interface evolution of an OO class library. More specifically, we investigated whether there is a causal relationship between some inheritance metrics, defined below, and the stability of OO library interfaces.

l.The results where obtained by using the minmax algorithm : minimum truth value along each tree path, maximum truth value for each end leaf.


115

5.1. Working hypothesis Because we cannot easily measure the ability of a software product to evolve in a direct way, starting from its initial version, an indirect approach is to perform the assessment using the relationships that may exist between evolvability and measurable characteristics such as size, cohesion, coupling or inheritance. In this work, we focused our attention on how inheritance aspects can be good indicators of the interface evolution of an OO class library. More specifically, we investigated whether there is a causal relationship between some inheritance metrics, defined below, and the stability of OO library interfaces.

5.2. Identifying changes in library interfaces There have been extensive studies of the impact of changes on object-oriented software. Kung et al [KUN 94] identify 25 types of changes that may occur in an OO class library. The changes may concern data, a method, a class or the class library. In the same way, in [LIO 96], Li and Offutt define another set of change types for OO software. Changes are classified in two categories: change of a method (7 types of changes) and change of a data member (6 types of changes). More recently, Chaumum et al [CHA 00] have expanded this categorization to include changes on classes; 13 types of changes are identified. In the previous projects, the authors were interested in an exhaustive classification of changes to study their impact on software in general. In our work, we were specifically interested in the impact that version changes in a class library may have on systems that use a given version of the library and that are upgraded to the next version. To this end, we identified two categories of changes at the class level, each one organized into types as follows: Let Ci be the interface of a class C in version i of the library and Ci +l be the interface of C in version i+1. Then, the two categories of changes for C are: A. cases:

The interface Ci is no longer valid in version i+1. This happens in four 1. C is removed some public members some protected members some private members

B.

The interface C, is still valid in version

This happen in two cases:

116


These types of change were ranked from worst to best according to the degree of impact of each type. For example, the deletion of a class has a more serious impact than the deletion of a subset of its protected methods. They were subsequently attributed numerical values in ascending order (1 to 6, 5 and 6 being equal), In addition, the types are conservative and exclusive: A change of class is classified into type k only if it cannot be classified into the k-1 previous types. For example, if, for a class C, some public methods are deleted and other public methods are added, C belongs to type 2 and not to type 6. Finally, if a class is renamed, this is considered as a deletion of the class (type 1) and the creation of a new class. In the same way, a change in a method signature is considered as a method deletion. A scope change that narrows the visibility of a method (from public to protected or private and from protected to private) is also considered as a method deletion.

5.3. Defining the inheritance metrics Three aspects of inheritance that may influence the evolution of a class interface are: (1) the location of the class in the inheritance tree; (2) the ancestors and descendants of the class; (3) the addition, inheritance and overwriting of methods. Each of these aspects will be studied in the case of simple inheritance. Table 1. Class location metrics

DIT

Depth of Inheritance Tree

CLD

Class to leaf Depth

PLP

Position in the longest path

Measures the size of the longest path from a class to a root class within the same inheritance tree. Measures the size of the longest path from a class to a leaf class within the same inheritance tree. DIT/(CLD+DIT)

Since the location of a class may be defined with respect to either the root of the inheritance tree or a leaf, we used two metrics, DIT and CLD (see Table 1), to specify its value. On the other hand, it may be more interesting to measure the location of the class relative to the longest path containing the class. Indeed, the information that a class is in the third level of inheritance out of a path of 8 levels is more meaningful than just saying the class is in the third level. This led us to define an additional metric, PLP, to provide this information.


117

Table 2. Class methods-related metrics

NMA

Number of methods added

New methods in a class

NMI

Number of methods inherited

Methods inherited overridden

NMO

Number of methods overridden

Methods overridden

NOM

Number of methods

NMA + NMI +NMO

PMA

Percentage of methods added

NMA/NOM

PMI

Percentage of methods inherited

NMI/NOM

PMO

Percentage of methods overridden

NMO/NOM

and

not

The ancestors and descendents of the class were measured using three standard metrics2, NOC, NOP and NOD (see Table 2 for definitions). Finally, counting the new and the inherited methods was accomplished with the following metrics: NMA, NMI, NMO and NOM (see Table 3 for definitions). In the same way as for the location parameter, the percentages of added, inherited and overridden methods, PMA, PMI and PMO, were introduced to possibly provide more useful information that than just counting absolute numbers. Table 3. Class ancestors/'descendents metrics

NOC NOD NOP

Number of children Number of descendants Number of parents

NOP {0, 1} in the case of simple inheritance

5.4. Application of FLAQ As stated in the Section 5.1, our hypothesis is that inheritance aspects may serve as indicators of library interface stability or, more precisely, that there is a relation between some inheritance metrics and a measure of OO library interface stability.

2. We do not consider the number of ancestors (NOA) since it is equal to DIT in the case of simple inheritance.

118


5.4.1. Data collection To build the estimation model, we studied three versions of a C++ class library called OSE [OSE 99], 4.3, 5.2 and 6.0, and we focused our attention on changes from version 4.3 to version 5.2, and from version 5.2 to version 6. Version 4.3 of the library contains 120 classes while version 5.2 contains 126. For each of the 246 classes (120 + 126), we extracted the change type and the values for the inheritance metrics. Then, we randomly selected 75% of the classes to serve in the learning process and 25% for testing the generated evolvability model. Looking at the distribution of the cases (classes) by change types given in Table 4, we notice that change types 0, 2 and 4 are not sufficiently represented. This observation led us to also consider, in our experiment, the change categories (A and B), as additional factors (see Table 5). Table 4. Distribution of classes by change types

0 1 2 3 4

2 35 2 46 6

2 13 1 17 3

4 48 3 63 9

5 Total

89 180

30 66

119 246

Table 5. Distribution of classes by change categories

O or A 1 or B Total

88 95 183

30 33

63

118 128 246

5.4.2. Building interface evolution models We conducted experiments using both absolute metrics (DIT, CLD, NOC, NOP, NOD, NMA, NMI, NMO and NOM) and relative metrics (PLP, PMA, PMI, PMO) substituted for the corresponding absolute metrics. In addition, we looked at their effect on both change types and categories. This led us to build four prediction models using the FLAQ approach. The models were as follows:


1)

Model A2 based on the 2 categories of changes and the absolute metrics.

2)

Model A6 based on the 6 types of changes and the absolute metrics.

119

3) Model R2 based on the 2 change categories and the set of metrics obtained by combining absolute and relative metrics. 4) Model R6 based on the 6 types of changes and using the same metrics as in model R2. 5.4.3. Results Figure 3 shows one of the four decision trees that were obtained by using FLAQ, the one corresponding to model R2. Each node contains a condition of classification relating to a metric and an interval which defines the values for which there is an uncertainty on the truth of the condition (see Section 4.1). The remaining 3 models are not shown for lack of space but follow similar patterns.

Figure 3. An example of fuzzy decision tree (evolvabiliy estimation model)

One observation that can be drawn from this figure is the absence of class location metrics (DIT, CLD and PLP). This was true for all of the models obtained and leads to the conclusion, within the limited size of our training set, that these metrics may not be good indicators of class interface stability between consecutive library versions. All the others metrics appeared at least in one of the four models and were, therefore, retained as potential indicators.

120


5.4.4. Comparison with "classical" ML techniques To compare the performance of the models obtained with FLAQ with models obtained with C4.5 and RoC, we used the same data and built 4 models using each of these two techniques. All three techniques yielded the same results regarding the relevance of the proposed metrics as indicators; the use of a fuzzy decision tree did not appear to bring improvements over existing ML techniques.

Figure 4. Estimation accuracy rates of class interface stability

We also compared the three techniques from the standpoint of estimation accuracy rates. The comparison was made using the computed estimation accuracy rates obtained with both the training data and the test data. In addition, we compared the loss of accuracy when moving from the learning to the test data. Our results show that for the learning data, C4.5 presents the higher estimation accuracy rates for all four models while FLAQ has comparable rates in most cases as shown in Figure 4; RoC provides the lowest rates. When using the test data, FLAQ has the best rates in the majority of cases while the rates of C4.5 drop by about 12% in three out of the four models. RoC maintains its rates (see Figure 4). Consequently, the results shows that the fuzzy technique improves the estimation accuracy rates either from the perspective of stability as we move from the training to the test data (in comparison to C4.5), or from that of numerical value (in comparison with RoC). This can be explained by the fact that the fuzzy approach


121

modifies C4.5 by keeping its inherent strength at identifying relevant indicators and removing the inconvenience of using absolute threshold values.

6. Towards a domain-Knowledge based approach As stated by Fenton and Neil in [FEN 00], most of the techniques used to build prediction models produce naive models with a single level of decision. This is also true for our approach. For instance, the model of Figure 3 shows a certain correlation between the various inheritance metrics and interface stability, but it is weak at providing evidence for a causal relationship. This limitation of naive models is especially true when the variables under consideration are cognitively distant. As a result, these models are hard to use in making intelligent decisions for software refactoring or redesign. To increase the efficiency of our fuzzy logic based approach, we propose to transform the single level decision models using a causal model approach. As a large part of the relevant data is missing from the sample used for learning, we propose to use domain-specific heuristics for this transformation. An analogy could be made with work in the ML community, where the opposition between weak domain, theory-based learning and strong domain, theory-based learning is stated. Obviously, a learning process based on an available theory domain produces a knowledge that fits more with the perception we generally have about knowledge.

6.1. Overview The idea behind the new approach is to palliate the weaknesses of a naive model at supplying causal relationships by enhancing its operation with heuristic rules. As shown in Figure 5, rather than simply using a naive prediction model, we add domain-specific heuristics to derive the fuzzy rules, in an attempt to create a causal prediction model.

122


Figure 5. Naive to causal model transformation

6.2. Fuzziflcation and rule derivation Metric fuzzyfication in the naive model is carried out in the standard way, according to the algorithm below: /* Fuzzification of the metrics in the naive model */ FOR EACH input metric Mi in the naive model DO FOR EACH condition "Mi comparator valuej " with a partition pj=[valuejl, valuej2] DO 1. Create a fuzzy label labelj 2. Derive the membership function of labelj from pj and the sample data END DO END DO On the other hand, rules derivation is performed both using the set of naive rules and additional constraint based on heuristics. The algorithm is as follows: /* Derivation of the set of naive rules NR */ FOR EACH path of the naive model DO 1. Derive a rule by replacing all the decision nodes by the corresponding fuzzy condition "Ml labelj" with conjunctions.


123

2. Add the derived rule to NR END DO /* Derivation of the causal rules CR */ FOR EACH rule ri in NR DO Derive a set of rules CRi using domain specific heuristics such that: a. There exists a subset of rules ICRi where the conditions are fuzzy conditions of type "Ml labelj" b. There exists a subset of rules FCRi where the conclusions are the estimation of the quality characteristic c. The conditions of each rule in CRi —ICRi are conclusion of rules in CRi d. Each rule in CRi represents a verifiable causal relationship END DO Once these new rules are obtained, causal, multi-layered fuzzy decision trees can be built. We are presently working on such a model.

7. Conclusion and future directions This paper presented a fuzzy-based approach to build interface stability estimation models for OO class libraries. Through an empirical study conducted on three versions of a commercial OO class library, we tried to answer the two following questions: 1. Can inheritance aspects be used as indicators for class library interface stability? 2. Does fuzzy-based learning improve the quality of the estimation models? If we analyze the results, we can say that the answer to question 1, like the models used, comprises uncertainties. The answer is 'Yes' if we consider that the obtained models show that aspects such as types of methods and the ancestors/descendents have a relationship with the categories of changes. It is 'No' if we consider that our sample may not be representative enough to generalize our results, and if we consider that the obtained estimation rates are still not as high as desired (about 60%). The response to the second question is definitely 'Yes'. First, the threshold values in C4.5 and the other "classical" techniques are too specific to the learning sample to be easily generalized; this explains the difference between the learning and the test rates. By changing the threshold values to intervals, we capture trends rather than specific values, thereby increasing the estimation accuracy rates. Finally, this work used a simple fuzzy algorithm for building our estimation models. The use of more comprehensive algorithms that use fuzzy logic to its full

124


potential (e.g. B-trees rather than binary trees, more comprehensive membership functions, etc), and that make use of domain-based heuristics, would probably yield more significant results.

8. References [BRA 95] BRAUN T., DIOT C., HOGLANDER A., ROCA V., An experimental user level of implementation of TCP, rapport de recherche no. 265, septembre 1995, INRIA. [BAS 96] V. R. BASILI, L. BRIAND & W. MELO, "How Reuse Influences Productivity in Object-Oriented Systems". Communications of the ACM, Vol. 30, N. 10, pp. 104-114, 1996. [BAS 97] V. R. BASILI, S. E. CONDON, K EL EMANM, R. B. HENDRICK, & W. MELO, "Characterizing and Modeling the Cost of Rework in a Library of Reusable Software Components", In Proc. of 19th International Conference on Software Engineering, 1997. [BIE 95] J.M. BIEMAN, B.-K. KANG, "Cohesion and Reuse in an Object-Oriented System", in Proc. ACMSymp. Software Reusability (SSR'94), 1995. [BRI 97] L. BRIAND, P. DEVANBU, W. MELO, "An Investigation into Coupling Measures for C++", In Proc. of 19th International Conference on Software Engineering, 1997. [BRI 99] L. BRIAND, J. WUST, S. IKONOMOVSKI, H. LOUNIS, "Investigating Quality Factors in Object-Oriented Designs: an Industrial Case Study", In proceedings of the 21st IEEE International Conference on Software Engineering, 1999. [CHA 00] M. A. CHAUMUN, H. KABAILI, R. K. KELLER, F. LUSTMAN, AND G. ST-DENIS, "Design Properties and Object-Oriented Software Changeability", In Proceedings of the Fourth Euromicro Working Conference on Software Maintenance and Reengineering, 2000. [CHI 94] S.R. CHIDAMBER, C.F. KEMERER, "A Metrics Suite for Object Oriented Design", IEEE Transactions on Software Engineering, 20 (6), 476-493, 1994. [DAL 99] M.A. DE ALMEIDA, H. LOUNIS & W. MELO. "An Investigation on the Use of Machine Learned Models for Estimating Software Correctability", In the International Journal of Software Engineering and Knowledge Engineering, pp. 565-593, vol. 9, number 5, October 1999. [DEM 99] S. DEMEYER, S. DUCASSE, "Metrics, Do they really help ?", In Proc. of LMO, 1999. [FEN 00] N. E. FENTON, M. NEIL, "Software Metrics: Roadmap", In Proc. of the 22nd International Conference on Software Engineering, 2000. [FEO 00] N. E. FENTON N. OHLSSON, "Quantitative Analysis of Faults and Failures in a Complex Software System", In IEEE Transactions on Software engineering, 26(8), 797814, 2000. [GEN 00] M. GENERO, L. JIMENEZ, M. PIATTINI, "Measuring the quality of entity relationship diagrams", In Proc. of 19th International Conference on Conceptual Modeling, 2000.


125

[HEN 96] B. HENDERSON-SELLERS, "Object-Oriented Metrics: Mesures of Complexity", Prentice-Hall, 1996. [KOH 96] R. KOHAVI, "Scaling up the accuracy of naive-Bayes classifiers: a decision-tree hybrid". In Proc. of the 2nd International Conference on Knowledge Discovery and Data Mining, 1996. [KUN 94] D. KUNG, J. GAO, P. HSIA, F. WEN, Y. TOYOSHIMA, & C. CHEN, "Change impact identification in object oriented software maintenance", Proc. of IEEE International Conference on Software Maintenance, 1994. [LAN 92] P. LANGLEY, W. IBA, & K. THOMPSON, "An analysis of Bayesian Classifiers". In Proc. of the National Conference on Artificial Intelligence, 1992. [LIO 96] L. LI, A. J. OFFUTT, "Algorithmic Analysis of the Impact of Change to ObjectOriented Software", Proc. of IEEE International Conference on Software Maintenance, 1996. [LIH 93] W. LI, S. HENRY, "Object-Oriented Metrics that Predict Maintainability", Journal of Systems and Software, 23 (2), 111-122, 1993. [LOR 94] M. LORENZ, J. KlDD, "Object-Oriented Software Metrics: A Practical Approach", Prentice-Hall, 1994. [MAO 98] Y. MAO, H. A. SAHRAOUI & H. LOUNIS, "Reusability Hypothesis Verification Using Machine Learning Techniques: A Case Study", Proc. of IEEE Automated Software Engineering Conference, 1998. [MAR 96] C. MARSALA, B. BOUCHON-MEUNIER. "Fuzzy pardoning using mathematical morphology in a learning scheme", In Proceedings of the 5th Conference on Fuzzy Systems, 1996. [OSE 99] OSE, OSE Online Documentation, Dumpleton Software Consulting Pty Limited, 1999, Available in http://www.dscpl.com.au/ose-6.OA [PIG 97] T. M. PlGOSKl, Practical Software Maintenance, Wiley Computer Publishing, 1997. [PRE 97] R. S. PRESSMAN, Software Engineering, A Practical Approach, fourth edition, McGraw-Hill, 1997. [PRI 97] M. W. PRICE AND S. A. DEMURJIAN, "Analyzing and Measuring Reusability in Object-Oriented Design", In Proc. of OOPSLA '97, 1997. [QUI93] J.R. QUINLAN, C4.5: Programs for Machine Learning, Morgan Kaufmann Publishers, 1993. [RAM 98] M. RAMONI, AND P. SEBASTIANI, "Parameter estimation in Bayesian networks from incomplete databases", Intelligent Data Analysis Journal, 2. 1998. [TAN 79] H. TANAKA, T. OKUDA, K. ASAI, "Fuzzy information and decision in statistical model", In Advances in Fuzzy Set Theory and Applications, pp. 303-320. North-Holland, 1979. [ZAD 68] L. A. ZADEH, "Probability measures of fuzzy events", Journal Math. Anal. Applic., 23. reprinted in Fuzzy Sets and Applications: selected papers by L. A.Zadeh, pp. 45-51, 1968.


Index

affinity rating scheme 41 MOTTO tool 41 attribute 18, 21 classes, entity and 18 empirical domain 18 validity 21 C++ 96 programs in 96 changeability 87, 94 class cohesion as predictor of 87 impact model 94 impacts of 94 cohesion and, 94 change impact model 94 cluster 28, 30, 31, 43 analysis 30 procedural systems in 43 method 31, 39 model 28 cohesion 27, 87, 88, 89, 94 class 87 predictor of changeability 87 et seq coupling and 89 impacts of change 94 metrics 88 module 27 properties 99 collection hierarchy 16 polymorphism 16 conceptual 69, 70 modelling 70 models 69 event-based objectorientated 69 core 11 class 11 interface 11

polymorphism 11 coupling 27, 76, 89 cohesion and 89 measures 76 module 27 criterion 30, 32, 34, 36 dual decision modularization 34 Ironman 34 D 34 E 36 Strawman 30 A 30 B 30 Woodenman 32 C 32 database metrics 49, 50 object-relational 49 et seq validating 50 domain-knowledge based approach 121 domain systems 17, 18, 19, 121 empirical 17, 18 attribute classes 18 entity classes 18 formal and 17 relational systems and 17 formal 17, 19 empirical and 17 relational systems and 17 scale type 19 value 19 knowledge based approach 121 relational and 17 dual decision modularization criterion 34 dynamic polymorphism 2 empirical domain 17, 18, 59

128

Index

attribute classes 18 entity classes 18 formal and 17 relational systems and 17 entities 3, 18 classes 18 attribute 18 empirical domain 18 modeled 3 modeling 3 environment 91 event-based object-orientated conceptual models 69 et seq external validity 38 first measure validation expt. 79 FLAQ 111, 117 application of 117 formal domain 17,19 empirical and 17 relational systems and 17 scale type 19 value 19 formal verification 56, 57 object-relational metrics 56 TS metric 57 fuzzification, rule derivation and 122 fuzzy 107, 111, 112, 113, 117, 122 logic-based approach (FLAQ) 111, 117 application of 117 rule derivation 122 threshold values 107 et seq quality estimation models with 107 et seq tree 112, 113 decision 112 inference 113 impact 95 inheritance 77, 116 measure 77 specialisation and propagation 77 metrics 116 instrument validity 21

integration, advantages of 6 internal validity 38 Ironman criterion 34, 36 D 34 E 36 JOINT-theory 5 sub-theory, the 5 LIBRARY 74, 115 library interfaces 115 identifying changes 115 M&D theory 8 O-O model 8 machine learning based approaches 109 mailboxes 4, 5 sub-theory SYS theory, the 4 measure 16, 75, 76, 77, 78, 79 coupling 76 first 79 validation experiment 79 inheritance 77 OET-based suite, an 75 polymorphism 16, 78 collection hierarchy, in the 16 propagation 77 size 76 specialisation 77 merit factor driven approach 27 modularization of object-orientated systems 27 metrics 1, 12, 16, 49, 50, 51, 53, 54, 56, 57, 59, 88, 90, 116 applying the 16 cohesion 88 databases for 49 validating 50 inheritance 116 metric, validation of 20 object-relational 49, 51, 56, 59 database 49 definition 51 empirical validation 59 formal verification 56

Index

polymorphism 1, 12, 20 schema level 54 selection of 90 table level 53 TS 57 formal verification 57 modeled, modeling entity 3 modularity 29, 44 analysis 44 OO systems in 44 degradation 29 modularization 27, 34, 42 merit factor 27, 34 driven approach 27 object-orientated systems 27 usage level 42 module 27 cohesion 27 coupling 27 MOTTO tool 37, 41 affinity rating scheme 41 object-event table 71 object-oriented systems (OO) 8, 27 et seq, 44, 69, 88 models 8, 69 conceptual 69 event-based 69 M&D theory 8 modularity analysis 44 modularization of 27 et seq merit factor driven approach 27 et seq technology 88 object-relational metrics 49, 51, 56, 59 database 49 definition 51 empirical validation 59 formal verification 56 modifiability indicators 82 OET-based measure suite, an 75 O-O model 8 systems 44

129

polymorphic classes 11 hierarchy 11 methods 9 polymorphism 1, 2, 9, 11, 12, 13, 16, 20,21,78 classes 11 core 11 class 11 interface 11 definition of, 9 dynamic 2 hierarchy 11 identifying 13 measures 16, 78 Collection hierarchy 16 methods 9 metric 1 et seq, 12, 16, 20 applying the 16 validation of 20 procedural systems 43 cluster analysis 43 propagation measures 77 inheritance and specialisation 77 protocol validity 21 quality estimation models, fuzzy threshold values with 107etseq relational systems 17 empirical domain 17 formal domain 17 scale type 19, 21 formal domain 19 unit and 21 validity 21 value 19 schema level metrics 54 size measures 76 specialisation measures 77 inheritance and propagation 77 Strawman Criterion 30 A 30 B 30 sub theory, the 3, 4, 5

130

Index

JOINT-theory 5 SYS-theory 4 mailboxes 5 UML-theory 3 SYS-theory 4 sub-theory, the 4 table level metrics 53, 57 TS metric 57 formal verification 57 UMC theory 3 unified modeling language (UML) 2, 3 modeled entities 3 modeling entities 3 sub theory, the 3 unit validity 21 scale type, and 21

validity 20, 21, 38, 50, 59, 79 attribute 21 database metrics 50 empirical 59 object-relational metrics 59 experiment 79 first measure 79 external 38 instrument 21 internal 38 polymorphism metric, of 20 protocol 21 scale type 21 unit 21 value 19 formal domain 19 type 19 Woodenman Criterion C 32

Quantitative Approaches in Object-Oriented Software Engineering (Innovative Technology Series: Information Systems and Networks)

Industrial Engineering. Innovative Networks

Ontologies in Software Engineering and Software Technology

Trustworthy Compilers (Quantitative Software Engineering Series)

Software Engineering: Modern Approaches

Communicating With Smart Objects: Developing Technology for Usable Persuasive Computing Systems (Innovative Technology Series. Information Systems and Networks)

Constructing Correct Software (Formal Approaches to Computing and Information Technology)

Innovative Information Systems Modelling Techniques

Ontologies for Software Engineering and Software Technology

Fundamental Approaches to Software Engineering

Fundamental Approaches to Software Engineering

Engineering Secure Software and Systems

Software Performance and Scalability: A Quantitative Approach (Quantitative Software Engineering Series)

Millimeter Waves in Communication Systems (Innovative Technology Series)

Semiotics in Information Systems Engineering

Multimedia Management (Innovative Technology Series)

Information Technology in Librarianship: New Critical Approaches

Applied Space Systems Engineering (Space Technology Series)

Software Radio Architecture: Object-Oriented Approaches to Wireless Systems Engineering

Agent Technologies and Web Engineering: Applications and Systems (Advances in Information Technology and Web Engineering Book)

Cases on Strategic Information Systems (Cases on Information Technology Series)

Software & Systems Requirements Engineering: In Practice

Operational Research and Networks (Geographical Information Systems)

New Trends in Software Process Modeling (Software Engineering and Knowledge Engineering) (Series on Software Engineering and Knowledge Engineering)

New Trends in Software Process Modelling (Software Engineering and Knowledge Engineering) (Series on Software Engineering and Knowledge Engineering)

Biomedical Information Technology (Biomedical Engineering)

Software-Enabled Control: Information Technology for Dynamical Systems

Fundamental Approaches to Software Engineering - FASE 2011

Evaluation of Novel Approaches to Software Engineering

Software Engineering and Computer Systems, Part II

Engineering Wireless-Based Software Systems And Applications

Quantitative Approaches in Object-Oriented Software Engineering (Innovative Technology Series: Information Systems and Networks)

Industrial Engineering. Innovative Networks

Ontologies in Software Engineering and Software Technology

Trustworthy Compilers (Quantitative Software Engineering Series)

Software Engineering: Modern Approaches

Communicating With Smart Objects: Developing Technology for Usable Persuasive Computing Systems (Innovative Technology Series. Information Systems and Networks)

Constructing Correct Software (Formal Approaches to Computing and Information Technology)

Innovative Information Systems Modelling Techniques

Ontologies for Software Engineering and Software Technology

Fundamental Approaches to Software Engineering

Fundamental Approaches to Software Engineering

Engineering Secure Software and Systems

Software Performance and Scalability: A Quantitative Approach (Quantitative Software Engineering Series)

Millimeter Waves in Communication Systems (Innovative Technology Series)

Semiotics in Information Systems Engineering

Multimedia Management (Innovative Technology Series)

Information Technology in Librarianship: New Critical Approaches

Applied Space Systems Engineering (Space Technology Series)

Software Radio Architecture: Object-Oriented Approaches to Wireless Systems Engineering

Agent Technologies and Web Engineering: Applications and Systems (Advances in Information Technology and Web Engineering Book)

Cases on Strategic Information Systems (Cases on Information Technology Series)

Software & Systems Requirements Engineering: In Practice

Operational Research and Networks (Geographical Information Systems)

New Trends in Software Process Modeling (Software Engineering and Knowledge Engineering) (Series on Software Engineering and Knowledge Engineering)

New Trends in Software Process Modelling (Software Engineering and Knowledge Engineering) (Series on Software Engineering and Knowledge Engineering)

Biomedical Information Technology (Biomedical Engineering)

Software-Enabled Control: Information Technology for Dynamical Systems

Fundamental Approaches to Software Engineering - FASE 2011

Evaluation of Novel Approaches to Software Engineering

Software Engineering and Computer Systems, Part II

Engineering Wireless-Based Software Systems And Applications

Recommend Documents