towards a size measurement framework for object

TOWARDS A SIZE MEASUREMENT FRAMEWORK FOR OBJECT-ORIENTED SPECIFICATIONS Geert Poels Research Assistant of the Fund for Scientific Research - Flanders Department of Applied Economic Sciences Katholieke Universiteit Leuven Naamsestraat 69 B-3000 Leuven Belgium [email protected] I.

INTRODUCTION

specific notion of complexity, i.e., problem complexity [9, p. 245]. The length of a software product refers to the number of elements used to specify it. The extent of external reuse is the relative size of the product that is reused from other products. Functionality has been measured using function points [2], object points [3] and specification weight metrics [7], but as far as we know, a formal definition of the attribute has not been presented in the literature.

Software offers a solution to a user-defined problem. The software specifications are a model of this problem. They precisely describe the software requirements and constrain the search for solutions. The characteristics of the problem that software must solve are expected to determine to a considerable degree the characteristics of the software and its development process, as well as the amount of development resources that is consumed. The problem characteristics are reflected by the characteristics of the specifications that model the problem. It is therefore worthwhile to measure software specifications.

In this paper a size measurement framework is presented for object-oriented specifications. The measurement of size sub-attributes of object-oriented specifications has not received the same attention as the measurement of the structure (e.g., coupling, cohesion, internal reuse) of object-oriented systems, in particular object-oriented designs (cf. for instance the MOOD [1], MOOSE [6] and QMOOD [4] OOD metric suites). To the best of our knowledge and with the exception of [12], fundamental questions such as ‘what is the size of object-oriented specifications?’ and ‘how to measure the size of object-oriented specifications?’ have not been satisfactorily answered.

Object-oriented specifications model a problem as a collection of interrelated and interacting objects. The core of the object-oriented specifications is the set of 1 objects that correspond to domain entities. These objects are interrelated by means of semantic relationships such as aggregation and generalisationspecialisation. They interact when they are involved in the same business event. A software measurement framework is an instrument to organise the measurement of software products, processes and resources. Basically, it is a classification of software entities along a number of dimensions that are used to identify measurement objects, attributes, systems and models. Each entity is characterised by a number of attributes. The classification of software entities helps to identify the attributes that are relevant for measurement. Entities characterised by such measurement attributes are called measurement objects. Measurement systems are measurement objects that contain (physically or abstract) other measurement objects. Measurement models are relationships between measurement attributes within and across measurement systems.

Apart from the size measurement framework we present a formal size measure definition approach based on the mathematical definition of distance. It is shown that size sub-attributes can be defined in terms of distances between measurement objects and that metrics, i.e., measures of distance, can be used to measure size. In section 2 the framework dimensions and elements are discussed. Our distance-based approach to software size measurement is presented in section 3. The actual size measure definitions are given in section 4. In section 5 our research is compared to related work. Finally, in section 6 conclusions are drawn and future research directions are indicated. II. CLASSIFICATION DIMENSIONS AND FRAMEWORK ELEMENTS

All framework elements play a role in the definition of software measures. A measure quantifies or qualifies a measurement attribute of a measurement object. Measurement systems help to derive measure properties by comparing the measurements of container and contained measurement objects. Finally, measurement models allow measurement attributes to be measured indirectly.

Our focus of research is the size measurement of object-oriented specifications. The primary software entities we wish to measure are the objects that represent domain entities. These objects have features, representing domain entity properties, and they are part of an object-oriented system that represents the domain. A first classification dimension refers to the granularity of the object-oriented specification product that is measured. Example levels on this granularity dimension include the feature, object and system level. The specification products at the different granularity levels are related through physical containment relationships: systems contain objects, objects contain features.

Generally, software products have two types of internal attributes: size and structure [9, p. 279]. According to Fenton and Pfleeger, size is a multi-dimensional attribute having sub-attributes such as length, functionality, the extent of external reuse and even a 1

A domain model is also called an enterprise model, an entity object model or a business model [19].

1

Abstraction \ Granularity feature object system object type conceptual schema process algebra variable, method object class OOAD schema OOAD figure 1: classification of MERODE domain modelling products of these methods. The Eiffel assertion construct is used to model sequence constraints. Object-oriented mechanisms such as information hiding (the separation of the public interface from the implementation and private interface), polymorphism (the differences in the method bodies of separate object classes triggered by the same business event type), inheritance (the 3 inheritance of features from parent object classes) and 4 abstraction (the definition of variables as mother object classes) are supported. The set of object classes builds the OOAD schema.

A second classification dimension refers to the abstractions used to model features, objects and systems. Objects are specified in abstract data types (ADTs). The internal view of an ADT contains both the implementation and the interface of the ADT. The external view contains only the public interface of the ADT. An object life cycle model (e.g., a finite state machine) is another object abstraction. It captures the sequence constraints on the participation of objects in business events. Also at the feature and system granularity levels a number of abstractions are used. The models at different levels in the abstraction dimension are related through abstract containment relationships, e.g., the internal view of an ADT ‘contains’ the external view. The abstraction dimension is also useful to incorporate a time dimension into the size measurement framework. For instance, the external view of an ADT is specified before the internal view.

The classification of the MERODE domain modelling products is shown in fig. 1. The abstraction dimension contains two levels: a process algebra level and an OOAD level. The OOAD level could be further refined into an external and an internal view level, but such a distinction is not a characteristic of MERODE. Note that at the process algebra abstraction level there are no 5 specification products at the feature level of granularity .

To illustrate the classification of object-oriented specification products the framework is tailored to a specific object-oriented domain modelling method. The Model-driven Existence dependency Relationship Object-oriented DEvelopment method (MERODE) [19] includes techniques for domain modelling that combine formal specification techniques with object-oriented analysis and design (OOAD) constructs and mechanisms. It is a non-commercial method that provides an excellent basis for research on objectoriented development.

According to Fenton and Pfleeger software product size is a multi-dimensional attribute having sub-attributes such as length (physical size), functionality (the amount of function delivered to the software users) and complexity (of the problem software tries to solve) [9, p. 245]. As the extent of external reuse is often expressed as the relative size of the software product that is reused from other software products, it may be considered a size sub-attribute. Hence, for a software product P

In MERODE a domain is first modelled as a set of interacting and interrelated object types, specified using a formal process algebra. Let A be the universe of business event types relevant for the domain. An object type P is a tuple ∈ , where P(A) is the power set of A and R*(A) is the set of regular expressions over A built by means of the “.” (sequence), “+” (selection) and “*” (iteration) operators. The first component of the tuple (α) is called the alphabet of the object type. It is the set of all business event types in which the object type is involved. The second component (e) is the regular expression of the object type. It specifies the sequence constraints on the participation of object type occurrences, i.e., objects, in business events. Objects interact through the joint participation in business events. MERODE object types are related by means of existence dependency and generalisation-specialisation relationships. A conceptual schema is essentially a set of object types M ⊆ onto which an existence dependency relation ← ⊆ M × M and a generalisation-specialisation relation < ⊆ M × M is defined.

Size(P) = f(Length(P), Functionality(P), Complexity(P), External_Reuse(P)) (def. 1) All of these size sub-attributes are relevant for MERODE domain models. The length or physical size of a domain entity is a function of the number of its properties. Therefore, the length of the objects that represent domain entities is a function of the number of elements used to specify these objects. Intuitively, the functionality of a domain is the amount of business functioning. The functioning of the business results in changes inflicted upon the state of the domain entities. Hence, specification products that represent domain entities and that have a state that may change as a result of business functioning (i.e., through the participation in business events) are characterised by the functionality attribute. Generally, such software products are specified at the object granularity level. The complexity of a domain is a function of the business rules. An important class of business rules, the sequence constraints, is modelled in the life cycle models of objects. Therefore, problem complexity is a relevant attribute at the object granularity level. The extent of external reuse is most relevant at the system level of granularity as it refers to the relative size of the system that is reused from other domain models.

In a second modelling phase, the process algebra constructs are transformed into OOAD constructs. Each object type is specified as an ADT (also called object 2 class ) having an interface (variable definitions and method signatures) and an implementation (method bodies). The business event types in the alphabets of the object types correspond to the methods in the object classes. Actually, the business events are the triggers

3

An object class x is a parent object class for an object class y when x is a generalisation of y. 4 An object class x is a mother object class for an object class y when y is existent dependent of x. 5 Event types are not features of object types as there is a many-to-many relationship between these constructs.

2

An object class actually refers to the set of object occurrences of the ADT.

2

III. A DISTANCE-BASED APPROACH TO SOFTWARE PRODUCT SIZE MEASUREMENT

To further structure the size measurement processes and to guide the definition of size measures a number of framework elements need to be defined. These elements and their definitions are: object: a software product • Measurement characterised by one or more attributes that are measured; • Measurement attribute: an attribute of a measurement object that is measured; • Measurement system: a measurement object that contains (physically or abstract) other measurement objects; • Measurement model: a relationship between measurement attributes.

A number of formal software product measurement approaches (e.g., Zuse and Bollmann [25], Grubstake/MOM [11, 13], axiomatic approaches [5, 8, 10, 18, 20, 22, 23]) focus on the structure measurement of program abstractions. Other (axiomatic) approaches specific to object-oriented software measurement require the definition of binary concatenation operations on measurement objects [24]. While such operations can be defined on the syntax of measurement objects (e.g., object classes), they do not correspond to meaningful operations on the domain entities that are represented by these measurement objects. Our distance-based approach to software product measurement is specifically suited for size measurement and it does not require the explicit definition of binary concatenation operations on measurement objects. Therefore it can be used to measure the size of object-oriented specifications.

The measurement objects in the MERODE framework are object types and object classes since these specification products are used to specify objects. Also conceptual schemes and OOAD schemes are measurement objects as they model the entire domain. In principle some size aspects (e.g., length) of feature granularity specification products could also be defined and measured, but we choose to include only methods 6 in our set of measurement objects . The measurement attributes are the size sub-attributes that were considered relevant. Along the granularity dimension, object classes, OOAD schemes and conceptual schemes are measurement systems for respectively methods, object classes and object types. Along the abstraction dimension, an object class is a measurement system for an object type and an OOAD schema is a measurement system for a conceptual schema. In this paper, the discussion on measurement models is limited to those that relate the size of measurement systems to the size of the measurement objects they contain. If it is assumed that relationships between contained measurement objects do not 7 contribute to the size of the measurement system , then this type of measurement model takes the form:

As the size of an object or a system is unrelated to the relationships between its elements (respectively features and objects), the measurement object for size measurement is generally a set of elements or it can be transformed or abstracted into a set of elements. Our distance-based approach requires that for each type of measurement objects t and for each relevant size subattribute s a reference measurement object rst is identified. The reference measurement object rst is the measurement object of type t that has the (theoretical) 8 lowest value of s. For the finite (or countable) set Xt of measurement objects of type t, s is formally defined as: ∀ x ∈ Xt: s(x) is the distance from x to rst (def. 3) A distance-based definition of software product size is formal as it must satisfy a schema of universally accepted, both necessary and sufficient axioms, i.e., non-negativity, identity, symmetry and the triangle inequality. The subjectivity in the size sub-attribute definitions is located within the choice of reference points. The approach is flexible in the sense that different reference measurement objects rst can be chosen for different size sub-attributes s and different types of measurement objects t. Also, the axioms do not require the definition of binary concatenation operations that would be hard to justify in case of the measurement of domain entities. Finally, and most importantly, if Xt is turned into a metric space (Xt, δt), 9 then the metric δt can be used as a measure for s(x) when one argument of the function is x and the other argument is rst.

n

s(y) =

∑

s(xi),

i =1

(def. 2) where y is a measurement system composed of n measurement objects x1, …, xn and s is a size subattribute relevant to the xi’s. In case of measurement systems based on abstract containment the value of n is equal to one. The measurement model allows s(y) to be measured indirectly. A direct measurement object is a measurement object whose attributes are measured directly. An indirect measurement object is a measurement object whose attributes are measured indirectly, based on a measurement model.

∀ x ∈ Xt: δt(x, rst) measures s(x). (def. 4)

In the next section our distance-based approach to size measurement is presented. In section 4 this approach is illustrated for selected size measurements of MERODE domain modelling measurement objects. 8

It is argued that each set of measurement objects within the software engineering domain is finite [15] or countable infinite [22], as these objects are human fabricated artefacts. 9 A function is a metric if it is invariant to the metric axioms (i.e., non-negativity, identity, symmetry and the triangle inequality).

6

This choice implies that we are not interested in the size of object class variables. 7 Note that this assumption is also made in related work (cf. section 5).

3

∀ P ∈ M: Lc(class(P)) = (variables(class(P)),

IV. THE SIZE MEASUREMENT OF MERODE DOMAIN MODELS

∑

Lf(m))

m ∈ methods ( class ( P ))

The length or physical size of a measurement object is related to the number of elements in its specification. At the process algebra level of abstraction, domain entities are represented by object types. The length of an object type P = is its distance to , i.e., the object type in with the theoretical smallest 10 physical size (actually null size) . In [16] it was proven 11 that the cardinality of the symmetric difference between alphabets and the minimum number of 12 elementary transformations required to take one regular expression to another regular expression are metrics on respectively P(A) and R*(A). Let M ⊆ be a conceptual schema and let Te,e’ be the minimum sequence of elementary transformations that takes e to e’. The length measure Lo for object types is defined as:

(def. 6’) The Lc measure defined in def. 6 differs from that defined in def. 6’ in terms of precision. The size measurement framework can be used to indicate the precision levels of measurement. The granularity precision level of measurement of def. 6 is the object, while it is the feature in def. 6’. Likewise, the abstraction precision level of measurement is the process algebra in def. 5, while it is the OOAD in def. 6 and 6’. Measurement of the same attribute at different levels of precision is particularly useful when there is an implicit time dimension in the classification dimensions. Using def. 2 the length of a conceptual schema (OOAD schema) can be indirectly measured as the sum of the Lo (Lc) measurements for the object types (object classes) in the schema.

∀ P ∈ M: Lo(P) = (α, Te,1) (def. 5)

The distance-based approach allows to measure other size sub-attributes by making an appropriate choice of reference measurement object. For instance, a specific notion of problem complexity, called life cycle complexity, is defined for object types. In MERODE each domain object type’s regular expression cannot be less deterministic than the regular expression that models a trivial life cycle on the alphabet of the object type. The trivial life cycle requires that first object occurrences are created, next their state is modified zero, one or many times, and finally their life is ended. Every sequence constraint that requires more than a trivial life adds to the life cycle complexity of the object type. Therefore, for each object type P = a reference object type trivial(P) = is defined, where e’ defines a trivial life cycle on α. The life cycle complexity of P is the distance from e to e’. If Te,e’ is the minimum sequence of elementary transformations taking e to e’, then a life cycle complexity measure Co can be defined as:

At the OOAD level of abstraction, domain entities are represented by object classes. To each object type P in the conceptual schema corresponds an object class (denoted class(P)) in the OOAD schema. An object class is essentially an encapsulation of methods and 13 variables . The sets of methods and variables of class(P) are denoted respectively by methods(class(P)) and variables(class(P)). The length of class(P) is defined as its distance to class(), where methods(class()) = ∅ and variables(class()) = ∅. Analogous to def. 5 we define the length measure Lc for object classes as: ∀ P ∈ M: Lc(class(P)) = (variables(class(P)), methods(class(P))) (def. 6) In MERODE the methods of domain object classes are ‘unstructured’ sets of statements that modify the object class variables. The length of a method is defined as its 14 distance to an empty method . If for some method m, Lf(m) measures the length of m, then using def. 2, Lc is redefined as:

∀ P ∈ M: Co(P) = Te,e’ (def. 7) Several notions of functionality may be defined. One point of view is that the functionality of an object class is a function of the references to the object class variables that are made within the method implementations. For 15 each object class class(P) we define a set ref(class(P)) = {(m,v) ∈ methods(class(P)) × variables(class(P))  m contains a reference to v}. The functionality of class(P) is defined as the distance from ref(class(P)) to ref(class()) = ∅. The cardinality of the symmetric difference between sets is a metric. Hence, the measure Fc is defined as:

10

The regular expression 1 represents the “do nothing” event type [19]. 11 The symmetric difference between sets X and Y is given by (X - Y) ∪ (Y - X). The cardinality of the symmetric difference between sets is a metric function for sets [21, p. 208]. 12 Elementary transformations on regular expressions add or delete an event type in a sequence or a selection of event types (i.e., a regular expression or part of it). They may also add or delete an iteration on a (part of a) regular expression. Elementary transformations were introduced in [16, 17] as basic units of sequence constraints. 13 We omit here for simplicity’s sake the modelling of sequence constraints, as well as other types of business constraints, at the OOAD level of abstraction. 14 An empty method is a method with no physical size, i.e., an empty set of statements.

∀ P ∈ M: Fc(class(P)) = ref(class(P)) (def. 8)

15

In MERODE the methods of domain object classes contain at most one reference to each of the object class variables. If a method would reference the same variable more than once, then it is more appropriate to define ref(class(P)) as a bag (i.e., a set that may contain duplicate elements).

4

The measurement model of def. 2 can be used to define indirect complexity and functionality measures at the system granularity level. A size sub-attribute that is especially relevant at the system granularity level is the extent of external reuse. This attribute can be defined as the relative size of the conceptual schema (or OOAD schema) that is reused from other domain models.

sub-attribute alternative definitions can be given, based on the choice of reference measurement object. Since the reference measurement object is used as an argument in the metric function, the same function can be used to measure alternative attribute definitions. Other work related to our research is the axiomatic 17 approach to size measurement of Briand, Morasca and Basili [5]. For a generic representation of a software system S = , where E is a set of elements and R is a set of relations on E, a set of 18 axioms is presented that must be satisfied by size measures. Although the axiomatic size definition of Briand, Morasca and Basili is similar to our and Hastings size definition in the sense that relations are not taken into account, no specific measure axioms for size subattributes are presented. Also, the authors of [5] do not claim that their axioms are sufficient to validate size measures. The axioms are merely necessary properties that must be satisfied by any measure if it is to be used to measure their, subjective, point of view on software size. The distance-based approach to size measurement on the other hand presents a set of universal, necessary and sufficient axioms for size measures. Each size sub-attribute is defined as a distance and the subjectivity in the size sub-attribute definitions is strictly limited to the choice of reference points. The metric axioms themselves are not subjective, and they are both necessary and sufficient to check the validity of a function as a measure of distance (and size).

V. COMPARISON TO RELATED WORK The software size measurement framework of Hastings [12] is similar in concept than our framework. It focuses on the measurement of software specifications, it incorporates Fenton’s view of size as a multidimensional attribute having length, functionality and (problem) complexity sub-attributes, and it formally defines these sub-attributes and their measures. Software specifications are modelled using an algebraic specification technique based on ADTs. From a size measurement point of view, the algebraic specification of a system as a set of ADTs corresponds closely to an 16 object-oriented specification of a system . Therefore, Hastings definitions of length, functionality and complexity, as well as his definitions of the size measures, may be used for the MERODE domain modelling constructs at the OOAD abstraction level. On the other hand, we believe that our size measurement framework and size measurement approach are more flexible and generic than the size measurement foundations of Hastings. While Fenton and Pfleeger do not use a measurement model to relate the different size sub-attributes, Hastings defines the size sub-attributes such that

VI. CONCLUSIONS The research presented in this paper is a step towards a size measurement framework for object-oriented specifications. A two-dimensional classification framework was proposed to classify the software products associated with the object-oriented specification of a software system. Through the definition of framework elements such as measurement attributes, objects, systems and models, the measurement framework helps to organise and structure the size measurement of specification artefacts. In this paper, the framework was tailored to MERODE, a method to specify a domain model using both a formal specification technique and OOAD constructs.

length(ADT) = functionality(ADT) + complexity(ADT) (def. 9) Although this measurement model might reflect Hastings point of view on specifications size, it is not expected that everyone will agree to this specific size sub-attributes relationship. In fact, Fenton and Pfleeger argue that the size sub-attributes of length, functionality and complexity should be fundamental, i.e., refer to different aspects of software size [9, p. 245]. Our size measurement framework does not involve measurement models that relate different size sub-attributes. Although the application of the framework to a specific situation (e.g., MERODE domain models) might result in length, functionality and complexity measurements that are related, a fixed relationship between the size subattributes, such as in def. 9, is by no means required or needed.

Apart from the size measurement framework, a new approach to size measurement was introduced. The distance-based approach to size measure definition is formal, generic and flexible, and therefore compares favourable to other size measurement approaches. The application of the distance-based approach was demonstrated for the size measurement of MERODE domain models.

Apart from the measurement model of def. 9, another difference with Hastings approach is that our classification framework (fig. 1) is generic in the sense that it can be tailored to diverse, albeit object-oriented or even object-based, specification methods, including the algebraic specifications used in [12]. Also, the distancebased measurement approach is more flexible than the fixed definitions of ADT length, functionality and complexity used by Hastings. Even for the same size

Further research will examine the usefulness of the classification framework and distance-based approach for software structure measurement. We also plan to tailor the size measurement framework to objectoriented models that capture more than just the domain entities.

16

The algebraic specification technique used by Hastings does for instance not support inheritance (and hence differs from an object-oriented specification). However, the size of specifications is not a function of the semantic relationships (e.g., generalisationspecialisation) between system elements (cf. footnote 7).

17

In [5] there are also axioms for a number of software structure attributes such as structural complexity, coupling and cohesion. 18 In [14] Morasca and Briand present different sets of size axioms that depend upon the level of empirical understanding of size as a software attribute.

5

measures research’, Software Engineering Journal, Vol. 5, No. 5, 1990, pp. 246-254. [14] S. Morasca and L.C. Briand, ‘Towards a Theoretical Framework for Measuring Software Attributes’, Proceedings of the IEEE fourth International Software Metrics Symposium (METRICS’97), Albuquerque, NM, USA, November 1997. [15] S. Moser and V.B. Misic, ‘Measuring Class Coupling and Cohesion: A Formal Metamodel Approach’, Proceedings of the Asia Pacific Software Engineering Conference and International Computer Science Conference (APSEC’97), Hong Kong, China, 2 - 5 December, 1997, pp. 31-40. [16] G. Poels and G. Dedene, ‘Formal Software Measurement for Object-Oriented Business Models’, Proceedings of the 7th European Software Control and Metrics Conference (ESCOM’96), Vol. 1, Wilmslow, UK, 15-17 May, 1996, pp. 115-134. [17] G. Poels and G. Dedene, ‘Complexity Metrics for Formally Specified Business Requirements’, Proceedings of the Annual Oregon Workshop on Software Metrics (AOWSM’97), Coeur d’Alene, Idaho, USA, May 1997. [18] R.E. Prather, ‘An Axiomatic Theory of Software Complexity Measure’, The Computer Journal, Vol. 27, No. 4, 1984, pp. 340-347. [19] M. Snoeck and G. Dedene, ‘Existence Dependency: The key to semantic integrity between structural and behavioural aspects of object types’, research paper accepted for publication in IEEE Transactions on Software Engineering, 1997, 37 pp. [20] M. Shepperd and D. Ince, ‘Algebraic validation of software metrics’, Proceedings of the 3rd European Software Engineering Conference (ESEC’91), Milan, Italy, 21-24 October, 1991, pp. 343-363. [21] P. Suppes, D.M. Krantz, R.D. Luce and A. Tversky, Foundations of Measurement: Geometrical, Threshold, and Probabilistic Representations, Vol. 2, Academic Press, San Diego, 1989, 493 pp. [22] J. Tian and M.V. Zelkowitz, ‘A Formal Program Complexity Model and Its Application’, Journal of Systems and Software, Vol. 17, 1992, pp. 253-266. [23] E.J. Weyuker, ‘Evaluating Software Complexity Measures’, IEEE Transactions on Software Engineering, Vol. 14, No. 9, 1988, pp. 1357-1365. [24] H. Zuse, ‘Foundations of Object-Oriented Software Measures’, Proceedings of the IEEE third International Software Metrics Symposium (METRICS’96), Berlin, Germany, March 1996. [25] H. Zuse and P. Bollmann, ‘Software Metrics: Using Measurement Theory to Describe the Properties and Scales of Static Software Complexity Metrics’, ACM SIGPLAN Notices, Vol. 24, No. 8, 1989, pp. 23-33.

ACKNOWLEDGMENTS This work was supported by a doctoral research grant from the Fund for Scientific Research - Flanders. REFERENCES [1] F.B. Abreu and R. Carapuça, ‘Object-oriented Software Engineering: Measuring and Controlling the Development Process’, Proceedings of the 4th International Conference on Software Quality (ICSQ’94), McLean, Virginia, USA, October 1994, revised version. [2] A.J. Albrecht and J.E. Gaffney, ‘Software function, source lines of code, and development effort prediction: a software science validation’, IEEE Transactions on Software Engineering, Vol. 9, No. 9, 1983, pp. 639-648. [3] R.D. Banker, R.J. Kauffman and R.J. Wright, ‘An Empirical Test of Object-based Output Measurement Metrics in a Computer-aided Software Engineering (CASE) Environment’, Journal of Management Information Systems, Vol. 8, No. 3, 1991, pp. 127-150. [4] J. Bansiya and C. Davis, ‘An Object-Oriented Design Quality Assessment Model’, research report, Computer Science Department, University of Alabama, 1997, 23 pp. [5] L.C. Briand, S. Morasca and V.R. Basili, ‘PropertyBased Software Engineering Measurement’, IEEE Transactions on Software Engineering, Vol. 22, No. 1, 1996, pp. 68-86. [6] S.R. Chidamber and C.F. Kemerer, ‘A Metrics Suite for Object-oriented Design’, IEEE Transactions on Software Engineering, Vol. 20, No. 6, 1994, pp. 476498. [7] T. DeMarco, Controlling Software Projects: Management, Measurement & Estimation, Yourdon Press, New York, 1982, 284 pp. [8] N. Fenton and A. Melton, ‘Deriving Structurally Based Software Measures’, Journal of Systems and Software, Vol. 12, 1990, pp. 177-187. [9] N.E. Fenton and S.L. Pfleeger, Software Metrics: A Rigorous and Practical Approach, 2nd edition, International Thomson Computer Press, London, 1997, 638 pp. [10] N.E. Fenton and R.W. Whitty, ‘Axiomatic approach to Software Metrication through Program Decomposition’, The Computer Journal, Vol. 29, No. 4, 1986, pp. 330-339. [11] D.A. Gustafson, J.T. Tan and P. Weaver, ‘Software Measure Specification’, ACM Software Engineering Notes, Vol. 18, No. 5, 1993, pp. 163-168. [12] T.E. Hastings, ‘Software Size Measurement Foundations’, research paper, Department of Software Development, Monash University, August 1996, 35 pp. [13] A.C. Melton, D.A. Gustafson, J.M. Bieman and A.L. Baker, ‘A mathematical perspective for software

6