Complexity metrics for formally specified business

Complexity metrics for formally specified business requirements

Geert Poels Research assistant of the Fund for Scientific Research - Flanders department of applied economic science, Katholieke Universiteit Leuven, Belgium Naamsestraat 69, B-3000 Leuven, Belgium tel: +32 16 32 68 91 / fax: +32 16 32 67 32 / e-mail: [email protected] Prof. dr. Guido Dedene Professor of Management Information Systems department of applied economic science, Katholieke Universiteit Leuven, Belgium Naamsestraat 69, B-3000 Leuven, Belgium tel: +32 16 32 68 75 / fax: +32 16 32 67 32 / e-mail: [email protected]

Abstract According to the Zachman framework for system architecture, business requirements and user information requirements should be separately modelled to enhance the maintainability and adaptability of the information systems and to improve the flexibility of the system development process. The measurement of business requirements is largely an unexplored field since requirements specification measures (e.g., function points) have focused almost exclusively on user information requirements. However, as a problem domain model, business requirements are worth measuring. In this paper a measurement model is presented that builds upon a formal specification language. The model allows to define meaningful viewpoints on business requirements complexity. Using a Measure Theoretic approach, a number of complexity measures are defined in an attempt to extent the life cycle coverage of software measurement to the business requirements specification phase.

Author Biographies Geert Poels works as a research assistant at the Fund for Scientific Research - Flanders, and is a PhD candidate at the Katholieke Universiteit Leuven. His research interests are function point analysis, object-oriented metrics, and formal software measurement foundations. Currently, he is conducting research on formal measurement of object-oriented specifications for software. Guido Dedene is Professor in Management Information Systems at the Department of Applied Economics at the Katholieke Universiteit Leuven. His lecturing and research activities concentrate on formal methods for systems development and quantitative systems management techniques. Guido is also director of European Services for GUIDE and SHARE Europe.

1

1. Introduction The ultimate goal of software development is to deliver software that satisfies the user requirements of quality, costs and schedule. Since traditional software development does not always achieve this goal, new software development approaches have been explored. One approach, called model-driven software development, is based on the Zachman framework for application development [14]. Model-driven software development focuses essentially on the business requirements of the system. These requirements determine the business functioning in terms of business entities, events and rules. In a library for example, books cannot be borrowed unless they are catalogued. Another requirement might stipulate that loans can be renewed. Once the business requirements have been specified, the information requirements of the system users are taken into account. In a library environment, example information needs are ‘is book x on loan ?’, ‘who has borrowed book y ?’ or ‘when does loan z expires ?’. These requirements are often more volatile than the business requirements, leading to frequent changes in the specifications and design. Especially, scope creep is an important phenomenon of information system development. Often, it is only during the later phases of the software development life cycle (e.g., after a prototype system has been shown to the users) that the user information needs are completely specified. Unless a significant BPR-project is planned, business requirements do not change. When business requirements instead of user information requirements are taken as a starting point for information system development, the development process becomes more flexible, and the specifications themselves more adaptable and maintainable. Business requirements are captured in a business model, which becomes the kernel of the information system. Around this kernel, a function model is specified containing the functions that meet the user information requirements. These functions are easily plugged in and out the business model, ensuring flexibility, adaptability and maintainability. Taken together, the business model and the function model build the abstract information system. The technology model allows to transform this abstract system into a concrete information system, depending on the technology chosen. The same abstract system can be transformed into different concrete systems, each implemented in a particular technology. Separating the technology model from the business and function models further enhances the above mentioned quality characteristics. Figure 1 shows the relationships between the different models to represent the system’s architecture.

S C O P E

ABSTRACT SYSTEM Function Model Business Model

CONCRETE SYSTEM

CONCRETE SYSTEM

CONCRETE SYSTEM

Figure 1: System architecture model-driven software development Present frameworks and instruments for specifications measurement do not distinguish the business and function abstraction layers. Function points [1], being a popular ‘software metric’ today, explicitly measure the software from the user’s point of view. A business model representation of the system is not sufficient to calculate the function point count since it does not show input, output and inquiry functions. Software attributes such as user functionality, functional size and length are therefore not considered to be relevant attributes of business requirements specifications. On the other hand, there might exist an attribute worth measuring. This attribute is called ‘the complexity of the underlying problem’ [6]. The specifications of the business requirements are clearly

2

a model of the problem domain. If the complexity of these specifications is measured, then in fact the complexity of the business requirements (i.e., the underlying problem) is measured. In this paper an approach is presented to measure the complexity of the business requirements. First, a measurement model is defined that captures the business requirements. The measurement model describes how to consistently specify business requirements. Current methods for conceptual business modelling offer a bundle of specification techniques to describe the different views (i.e., static, dynamic and interaction) on the same business reality. Few methods include a formal procedure for checking the consistency and correctness of the different views [11]. The approach to business requirements specification taken here is based on the M.E.R.O.DE. process algebra [5, 11]. It is an object-oriented specification technique that guarantees model consistency and correctness. Since syntax and semantics of the technique have been defined, it is particularly suited to be supported by CASE-tools. Moreover, its formal definition allows to rigorously define measurement instruments. To ensure the validity of the proposed measures, precise definitions of complexity and its measures are presented. These definitions are based on basic measurement concepts of Measure Theory (e.g., [4]). Basically our viewpoint on complexity can be described as follows. The more the business requirements can be simplified, the more complex they are. Therefore it is required that the business requirements are specified in a formal and consistent manner to identify those parts that can be simplified without essentially changing the problem at hand. Of course, other viewpoints on complexity can be expressed. Since the acceptance or rejection of a measure depends on the viewpoint on the attribute that is measured, it is not expected that everyone will agree with the measures proposed here. On the other hand, the solution to the problem of business requirements measurement that we offer is an attempt to extent the life cycle coverage of software measurement to the requirements specification phase. In section 2 the business requirements specification technique and the measurement model are described. Sections 3 and 4 present formal definitions of the complexity attribute that is measured, as well as the complexity measure definitions. Finally, in section 5 the approach is evaluated and some application frameworks for the measures are described.

2. Formally specifying the business model While the specification techniques presented here were specifically developed for the M.E.R.O.DE. methodology [5], the view on business requirements is high-level and general. Basically, the business functioning is modelled through a set of business event types (called the universe of event types) and a set of business object types, occurrences of which participate in occurrences of the event types. The formal specification of an object type consists of the set of business event types participated in and a mathematical expression of the business rules prescribing the sequence of participation in the event types (section 2.1.). The business model is essentially a classification schema of object types that combines the dynamic and interaction view on the business requirements, such as modelled by the object type’s specifications, with a static view (e.g., an (E)ER-schema). The classification schema used is the existence dependency lattice, presented in section 2.2..

2.1. The formal specification of business object types Suppose the set A is the universe of event types corresponding to some business that must be modelled. The power set of A is denoted by P(A). The alphabet of an object type is the set of business event types participated in. For every object type in the business model with alphabet α, it holds that α ∈ P(A). A set of regular expressions over A can be built by the operators ‘.’ (sequence), ‘+’ (selection) and ‘*’ (iteration). The set of all regular expressions over A is denoted by R*(A). For each business object type the sequence constraints on participation in event types are modelled by a regular expression over A1. Hence, if e is the regular expression describing the sequence constraints of an object type, it holds that e ∈ R*(A).

1

Regular expressions are mathematically equivalent to structure diagrams and state transition diagrams.

3

Definition 1: business object types A business object type P is a tuple ∈ such that e is not in deadlock and every event type in α occurs at least once as an operand in e. To select the alphabet and regular expression of a business object type, the selector functions SA and SR are defined: SA: → P(A): P → α SR: → R*(A): P → e It is further required that for each object type it must be possible to create and end occurrences2. Hence, for the object type P, the alphabet SAP is partitioned into the three disjoint subsets c(P), m(P) and d(P) where c(P) = {a ∈ A  a creates an occurrence of type P} ⊆ SAP m(P) = {a ∈ A  a modifies an occurrence of type P} ⊆ SAP d(P) = {a ∈ A  a ends an occurrence of type P} ⊆ SAP and c(P) and d(P) may not be empty. Based on these three subsets the default sequence constraints are given by ∑c(P) . (∑m(P))* . ∑d(P). First, an object is created by an event belonging to one of the create event types. Next, an iteration of modify events occurs. Each modify event belongs to a modify event type. Finally, the life of the occurrence is ended by an event belonging to one of the end event types. The actual sequence constraints of an object type cannot be less deterministic than this default. The regular expression SRP may impose additional sequence constraints on the life of objects (e.g., modify events of type X cannot occur before modify events of type Y). Object interaction happens by means of common events participated in. Consider for example a very simple library circulation business3. Persons that wish to borrow books must first become members of the library. Next they can borrow books, renew the books they have in loan or return the books. After a book has been acquired by the library, it must first be catalogued. Next it can be borrowed. A book can be sold by the library after it is returned, or it can get lost while on loan. There are obviously two object types, MEMBER and BOOK, that must be specified. The specifications are: BOOK = MEMBER = For example, the regular expression of BOOK specifies that books must first be acquired. Next, a cataloguenumber must be assigned. Once catalogued they can be zero, one or more times borrowed, renewed or returned. Finally, they are either lost or sold. Note that it is not specified that catalogued books must first be borrowed, then renewed (zero, one or more times) and then returned by the member since they can get lost while on loan (i.e., before they are returned). An example sequence of events for a book x is: acquire . catalogue . borrow . renew . renew . return . borrow . lose. The object interaction between an occurrence of MEMBER and an occurrence of BOOK happens through events of the types borrow, renew, return and lose. However, a member cannot return, renew or lose a book unless this book was first borrowed by that member. Hence, to further specify the object interaction, contract object types are specified [12]. The contract between a member and a book is a loan. LOAN = Note that a book cannot be sold while still on loan. However, after it is borrowed it can get lost.

2.2. An object classification schema The object types in a business model are related. The classification schema used in M.E.R.O.DE. is the existence dependency relation. Object type P is existent dependent of object type Q if the life of each occurrence p of type P is embedded in the life of one single and always the same occurrence q of type Q. The object p is called the 2 3

To end an occurrence means to put the object in an archive, not to delete it. Of course this is a toy example, appropriate for illustrative purposes only.

4

marsupial object. The object q is called the mother object. Formally, we write P ← Q if P is existent dependent of Q. Contract object types are existent dependent of the object types they relate. A loan is existent dependent of a book and a member. The loan cannot be created if the member and the book don’t exist. On the other hand, if the book is sold or lost, or the member ends membership, the life of the loan object must also end. Finally, the loan always relates one particular member to one particular book. Figure 2 shows the object-relationship diagram of the simple library circulation business.

MEMBER

BOOK

LOAN

Figure 2: Object-Relationship Diagram of a simple library circulation business According to the M.E.R.O.DE. process algebra, if P ← Q the following rules apply [12]: • Propagation rule: SAP ⊆ SAQ Existence dependent objects cannot participate in events without the mother having knowledge of this event. • Type of involvement rule: c(P) ⊆ c(Q) ∪ m(Q) and m(P) ⊆ m(Q) and d(P) ⊆ m(Q) ∪ d(Q) A marsupial cannot be created before its mother exists nor can it exist after its mother has ended. • Restriction rule: SRP may not be less deterministic than SRQ4 Any sequence of events in which a marsupial participates that is not acceptable from the point of view of the mother, must be rejected.

3. The complexity of an object type The object types, such as defined in the previous section, each model a part of the business requirements in the problem domain. In this section, for each object type minimal specifications are identified. If these minimal specifications are not fulfilled, the object type is no longer valid according to the process algebra rules. The difference between these minimal specifications and the ‘full’ specifications of the object types determines their complexity. A formal definition of this viewpoint on complexity is given below. Definition 2: the complexity of a business object type Suppose the conceptual schema M,← consists of the set of object types M ⊆ and the existence dependency lattice ← on M. The complexity of an object type P = ∈ M is defined as the distance5 between and , where are the minimal specifications of P to be a valid object type in M,←. The larger this distance, the more complex the object type. First, the minimal specifications need to be defined (section 3.1.). Next, the distance between and must be measured (section 3.2.).

4

The restriction rule implies that the sequence constraints on P must at least be as strong as the sequence constraints on Q. 5 A distance can be interpreted as a difference. It is convenient to represent differences between entities as distances in the context of Measure Theory.

5

3.1. The minimal specifications of a business object type According to the process algebra rules, the alphabet of an object type includes the alphabets of its marsupial object types, and at least one create and one end event type. The regular expression of an object type must have at least one operand for each event type in the object type’s alphabet and may not be more deterministic than the regular expressions of the marsupial object types. Formally, the minimal specifications are defined as: Definition 3: the minimal specifications of a business object type ∀ P = ∈ M: ∃ P’ = ∈ : α’ = {c, d} ∪ (



SAQ), where c ∈ c(P) and d ∈ d(P)

Q← P Q ∈M

e’ = ∑c(P’) . (∑m(P’))* . ∑d(P’)6 Note that the minimal specifications of an object type P define an object type P’ that is not (necessarily) an element of M,←. Note also that the minimal specifications are not unique since c(P) and d(P) do not have to be singleton sets. However, it can be shown that to consistently measure the distance between and , it is only required that {c, d} and



SAQ are disjoint sets. This constraint is satisfied if the alphabet of every

Q← P Q ∈M

object type P ∈ M contains one create event type and one end event type that are not elements of the alphabets of P’s marsupial object types Qi ∈ M. A formal proof is outside the scope of this paper. The minimal specifications of the object types in the library example are shown below. The ‘lose’ event type is not present in these specifications since it is an end event type for both BOOK and LOAN object types. BOOK’ = MEMBER’ = LOAN’ = The set of all minimal specifications corresponding to the conceptual schema M,← does not build a valid conceptual schema. The renew event type for example is common to BOOK’ and MEMBER’ although it is not present in LOAN’. Once, the minimal specifications of each object type are identified, complexity is evaluated without regard to the other object types in the schema. In section 4, the complexity of the business requirements is jointly evaluated.

3.2. Measuring distances between business object types To measure the distance between P = and P’ = , the functions δalph: × → Re+ and δseq: × → Re+ are defined. The first function measures the distance between the alphabet specifications. The second function measures the distance between the regular expressions. The function δalph is defined as the cardinality of the symmetric difference between alphabets7: Definition 4: the function δalph ∀ P, P’ ∈ : δalph(P, P’) = SAP ∆ SAP’ If P’ = are the minimal specifications of P = , then δalph(P, P’) = SAP - SAP’ holds since SAP’ ⊆ SAP.

6

The default life cycle expression does not impose any sequence constraints except for those that are needed to model valid object types. The default life cycle expression is never more deterministic than the regular expressions of the marsupial object types. 7 If X and Y are sets, then the symmetric difference X ∆ Y is equal to (X ∪ Y) - (X ∩ Y), i.e., the symmetric difference contains all elements that belong either to X, either to Y, but not to X and Y. The cardinality X of a set X is the number of elements in X.

6

It is slightly more difficult to define a distance function δseq since regular expressions are not sets. The approach taken is similar to the solution to the tree-editing problem [8, 15]. First, a set of elementary transformations is defined. Each elementary transformation is an editing operation on regular expressions. For e, e’ ∈ R*(A): ti(e) = e’ where ti(e) for subscript i = 0, 1, 2, …, 9 is defined as: t0(e) = e . x = e’ t1(e) = x . e = e’ t2(e) = e + x = e’ t3(e) = x + e = e’ t4(e) = (e)* = e’ t5(e) = t5(e’ . x) = e’ t6(e) = t6(x . e’) = e’ t7(e) = t7(e’ + x) = e’ t8(e) = t8(x + e’) = e’ t9(e) = t9((e’)*) = e’ and x ∈ A

(add right sequence event type) (add left sequence event type) (add right selection event type) (add left selection event type) (add iteration) (delete right sequence event type) (delete left sequence event type) (delete right selection event type) (delete left selection event type) (delete iteration)

Given a regular expression e over A, all elementary transformations ti may be applied to e or to any part of e that is a regular expression over A. For e, e’, e” ∈ R*(A): (i) e = e’ . e” ⇒ ti(e) = ti(e’. e”) or ti(e’) . e” or e’. ti(e”) (ii) e = e’ + e” ⇒ ti(e) = ti(e’ + e”) or ti(e’) + e” or e’ + ti(e”) (iii) e = e’* ⇒ ti(e) = ti((e’)*) or (ti(e’))* For example, to take SRBOOK’ to SRBOOK we only need an edit operation to add the catalogue event type: t1(SRBOOK’) = acquire . t1((borrow + renew + return)* . (lose + sell)) = acquire . catalogue . (borrow + renew + return)* . (lose + sell) = SRBOOK. In [9] it was shown that a sequence of elementary operations ti can take every regular expression e ∈ R*(A) to every other regular expression e’ ∈ R*(A). The function δseq is defined as follows: Definition 5: the function δseq Let T be a sequence of ti1, …, tik elementary transformations. A T-derivation from e ∈ R*(A) to e’ ∈ R*(A) is a sequence of regular expressions e0, …, ek such that e = e0, e’ = ek, and tij(ej-1) = ej for 1 ≤ j ≤ k. ∀ P, P’ ∈ : δseq(P, P’) = the length8 of the shortest T-derivation from SRP to SRP’. To illustrate this transformation process let us take SRLOAN’ to SRLOAN. A T-derivation from SRLOAN’ to SRLOAN is borrow . return, borrow . (lose + return), borrow . renew . (lose + return), borrow . (renew)* . (lose + return) This T-derivation with length 3 is the shortest possible. Hence, δseq(LOAN’, LOAN) = 3 In [9] it was shown that the functions δalph and δseq satisfy the axioms of pseudo-metrics in Measure Theory (e.g., [4])9. Hence, they are valid measures of the distance between the specifications of object types. Since the 8

The length of a T-derivation is the number of transformations in the sequence T. A function δ: X × X → Re is a pseudo-metric if and only if ∀ x, y ∈ X: i. δ(x, y) ≥ 0 ii. δ(x, x) = 0 iii. δ(x, y) = δ(y, x) iv. ∀ z ∈ X: δ(x, y) ≤ δ(x, z) + δ(z, y)

9

7

complexity of a business object type is defined as the distance between the specifications of the object type and its minimal specifications, the functions δalph and δseq are also valid complexity measures. Measurement values for the library object types are shown in table 1.

δalph δseq

BOOK 1 1

MEMBER 0 0

LOAN 2 3

Table 1: Complexity of the business object types

4. The complexity of the business requirements In the previous section the complexity of an object type P = ∈ M was defined as the distance between and , where P’ = are the minimal specifications of P to be a valid object type in M,←. This distance is measured by the couple of values (δalph(P, P’), δseq(P, P’)). In this section the complexity of all business requirements that are specified by means of object types, is measured. In other words, the conceptual schema that formally specifies the business model is measured and the relationship between the measurement values of individual object types and the conceptual schema is examined. The complexity of a conceptual schema M,← has two dimensions. First of all it is related to the complexity of its elements. Secondly, this complexity must be evaluated with respect to which elements are part of the schema, and how these elements are interrelated (i.e., how they are positioned into the existence dependency lattice). A formal definition is shown below. Definition 6: the complexity of the business requirements Given the set of object types M ⊆ and the existence dependency lattice ← on M, the complexity of M,← is the distance between the specifications ∈ M and the minimal specifications ∈ , where ∀ P = ∈ M, ∃ P” = ∈ such that α” = {c, d} ∪ (



SAQ”), where c ∈ c(P) and d ∈ d(P)

Q← P Q ∈M

e” = ∑c(P”) . (∑m(P”))* . ∑d(P”) The only difference with the previous definition of the minimal specifications is that these are now determined by the minimal specifications of the other object types in the schema. If the alphabet of the marsupial object types is simpler, so is the alphabet of the mother object types. Therefore the expression SAQ in the previous definition is replaced by the expression SAQ” (i.e., the alphabet of the minimal specifications of Q). Note that the minimal specifications describe a set of object types M” that has the same existence dependency lattice ← as the original set M. Hence, M”,← is also a conceptual schema. The minimal specifications for the library are: BOOK” = MEMBER” = LOAN” = A measure for the complexity of all business requirements, such as captured in a conceptual schema M,←, is defined as: Definition 7: the measure COMP For the set of object types M ⊆ and the existence dependency lattice ← on M: COMP(M,←) = (

∑

P ∈M

δalph(P, P”),

∑

δseq(P, P”))

P ∈M

8

The couple of values (

∑

δalph(P, P”),

P ∈M

∑

δseq(P, P”)) actually measures the distance between M,← and

P ∈M

M”,←. Hence, COMP is a valid complexity measure. As long as the relationship between the components of COMP is not fully determined, it is preferred to represent the complexity as a vector of values, instead of combining them into a scalar value. The validity of a scalar indirect measure based on the two components of COMP depends on this relationship [7]. Further research must examine whether the relationship between the components, which indeed exists, can be analytically defined. The complexity of the library business requirements is given in table 2. The value of COMP(Library) = (7,8).

δalph δseq

BOOK 3 3

MEMBER 2 2

LOAN 2 3

Table 2: Complexity of the business requirements For all Q, where Q ← P, it holds that SAQ” ⊆ SAQ. Therefore, the minimal specifications are ‘smaller than’10 the minimal specifications . As a consequence it holds that (

∑

δalph(P, P”),

P ∈M

∑

P ∈M

δseq(P, P”)) ≥ (

∑

δalph(P, P’),

P ∈M

∑

δseq(P, P’))

P ∈M

meaning that the complexity of the conceptual schema is at least as large as the sum of the complexities of its object types.

5. Conclusion Generally, software measurement serves two purposes: • Measures of software attributes are used in empirical software research to determine the existence, significance and nature of the relationships between these attributes; • In case significant relationships exist between the attributes, measurement values are gathered during software development to guide the development process. In this paper measures are proposed for the complexity of the business requirements specifications. According to the Zachman framework for system architecture, business and user information requirements should be separately modelled to increase the maintainability and adaptability of the information systems and to improve the flexibility of the system development process. Since it captures the problem domain, a model of the business requirements is a software product worth measuring. Current measurement frameworks and instruments for requirements specification measurement, in particular function points [1] and its variants (e.g., Mk. II function points [13]), are not really suited to measure business requirements since they are function-oriented. Other specification measures such as [3] are useful to track the volatility of the requirements. However, the business requirements are relatively stable as compared to the user information needs. Therefore, scope creep measurement is more relevant for the function model. Since business requirements measurement is a largely unexplored field, a measurement model for business requirements is proposed. The model builds upon a process algebra as a formal specification language. In the context of conceptual modelling, such an approach has clear benefits related to model consistency and correctness. In line with the software measurement framework of Fenton [6], a business model is appropriate to measure the complexity of the problem domain. In this paper the complexity attribute has been formally defined in terms of the formal specification language, to allow the definition of complexity measures, whose validity can be shown. The measures themselves are distance metrics satisfying the axioms of pseudo-metrics in Measure Theory. The term ‘metric’ or ‘software metric’ is often misused in the software measurement literature since ‘software metrics’ in general are not distance measures. By defining complexity measures as distance metrics, the 10

‘smaller than’ in this context means that the distance from to is not larger than the distance from to .

9

semantics of the measures is determined since they satisfy a number of well-defined axioms. The measurement approach outlined here is therefore similar to other property-based measurement frameworks that are based on Measurement Theory11 (e.g., [2]) or Belief Function Theory (e.g., [16]). As long as functions satisfy the (pseudo)metric axioms, they can be used as business requirements complexity measures. The functions δalph and δseq proposed here, are examples of such functions. Note that the complexity of the business requirements is evaluated with respect to the business entities (modelled as business object types) that can be identified, and the relationships between these entities. A very coarsegrained measure of the problem domain could be the number of object types in the model, which would qualify as a size measure. Other measures can be defined related to the morphology of the existence dependency lattice. However, given a certain size and morphology, the additional information contained in the complexity values is substantial since the contents of the business entities are measured. Therefore, even if models have the same size and morphology, their complexities might still be different. Referring to the purposes of software measurement, the measures can be used in empirical research to examine whether the complexity of the business requirements is related to other software attributes such as development effort and information system maintainability. In case significant relationships exist, the measures can serve as independent variables in prediction systems. However, we do not believe they should be the only predictors of, for instance, development effort. It is obvious that the user information requirements must also be measured to build adequate prediction models. The complexity measures proposed here must rather be regarded as useful complements to other specification measures such as function points. Since a business model describes the problem domain, the measures proposed in this paper do not measure the complexity of the software’s control structure, nor its modularity. High values for the measures can be significant for the quality of the information system, but they can only be reduced by changing the business itself. In fact, another application framework for the measures is the analysis of the business itself. Using the measures, questions like ‘how complex is the problem domain ?’ can be answered. Such questions are relevant for information system development, but also for a number of purposes not necessarily related to software development. Complexity measures may, for example, help evaluate BPR alternatives as a complement to other measurements (e.g., costs, value-added, etc.).

References [1]

[2] [3] [4] [5] [6] [7] [8] [9]

[10]

Albrecht A.J. 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. 6, 1983, pp. 639-648. Briand L.C., S. Morasca and V.R. Basili, ‘Property-Based Software Engineering Measurement’, IEEE Transactions on Software Engineering, Vol. 22, No. 1, 1996, pp. 68-86. Costello R.J. and D. Liu, ‘Metrics for Requirements Engineering’, Journal of Systems and Software, Vol. 29, 1995, pp. 39-63. Debarra G., Introduction to Measure Theory, Van Nostrand Reinhold, 1974. Dedene G. and M. Snoeck, ‘M.E.R.O.DE.: A Model-driven Entity-Relationship Object-oriented DEvelopment method’, ACM SIGSOFT Software Engineering Notes, Vol. 13, No. 3, 1994, pp. 51-61. Fenton N.E., Software Metrics, A Rigorous Approach, Chapman & Hall, London, 1991. Kitchenham B., S.L. Pfleeger and N.E. Fenton, ‘Towards a Framework for Software Measurement Validation’, IEEE Transactions on Software Engineering, Vol. 21, No. 12, 1995, pp. 929-944. Oommen B.J., K. Zhang and W. Lee, ‘Numerical Similarity and Dissimilarity Measures Between Two Trees’, IEEE Transactions on Computers, Vol. 45, No. 12, 1996, pp. 1426-1434. Poels G. and G. Dedene, ‘Formal Software Measurement for Object-Oriented Business Models’, Proceedings 7th European Software Control and Metrics Conference (ESCOM96), Manchester, UK, May 1996, pp. 115-134. Roberts F.S., Measurement Theory with Applications to Decisionmaking, Utility, and the Social Sciences, Addison-Wesley, 1979.

11

It should be noted that Measure Theory is different from Measurement Theory (e.g., [10]), the prevalent theory for software measurement. While Measurement Theory is useful to define software measures, Measure Theory provides definitions for both measures and metrics. Although often used in software measurement, the concept of a software ‘metric’ is not defined in Measurement Theory.

10

[11]

[12] [13] [14] [15] [16]

Snoeck M., On a Process Algebra Approach for the Construction and Analysis of M.E.R.O.DE.-Based Conceptual Models, Phd dissertation, department of computer science, Katholieke Universiteit Leuven, 1995. Snoeck M., ‘Existence Dependency: Conceptual modelling by contract’, DTEW research paper 9640, Katholieke Universiteit Leuven, 1996. Symons C.R., ‘Function Point Analysis: Difficulties and Improvements’, IEEE Transactions on Software Engineering, Vol. 14, No. 1, 1988, pp. 2-11. Zachman J.A., ‘A framework for information architecture’, IBM Systems Journal, Vol. 26, No. 3, 1987, pp. 276-292. Zhang K. and D. Shasha, ‘Simple fast algorithms for the editing distance between trees and related problems’, Siam Journal on Computing, Vol. 18, No. 6, 1989, pp. 1245-1262. Zuse H., ‘Foundations of Object-Oriented Software Measures’, IEEE Third International Software Metrics Symposium, Berlin, March, 1996.

11