A Unique Complexity Metric

7 downloads 0 Views 235KB Size Report
Software engineers plan 'how' an information system should be developed in .... for quantification; (2) Empirical binary relations showing the intuitive knowledge.
A Unique Complexity Metric Sanjay Misra and Ibrahim Akman Department of Computer Engineering, Atilim University, Ankara, Turkey [email protected], [email protected]

Abstract. Metrics, in general, are defined as “a quantitative measure of the degree to which a system, component, or process possesses a given attribute”. Complexity metrics are used to predict critical information about reliability and maintainability of software systems. This paper proposes complexity metric, which includes all major factors responsible for complexity. We validated our metric against the principles of measurement theory since the measurement theory has been proposed and extensively used in the literature as a means to evaluate the software engineering metrics. The scale of the metric is investigated through Extensive structure. It is found that the proposed measure is on ratio scale. The applicability of the proposed measure is tested through test cases and comparative study. Keywords: Software complexity metric, evaluation criteria, measurement theory, scale, extensive structure.

1 Introduction The key element of any engineering process is measurement. Engineers use measures to better understand and assess the quality of engineered products or systems that they built. However, absolute measures are uncommon in software engineering [15]. Instead, software engineers attempt to derive a set of indirect measures that lead to metrics that provide an indication of quality of some representation of software. Software engineers plan ‘how’ an information system should be developed in order to achieve its quality objectives. The quality objectives may be listed as performance, reliability, availability and maintainability [16], and are closely related to software complexity. Complexity is defined by IEEE [6] as “the degree to which a system or component has a design or implementation that is difficult to understand and verify” Over the years, research on measuring the software complexity has been carried out to understand, what makes software products difficult to develop, maintain, or use. Major complexity measures of software that refer to effort, time and memory expended have been used in the form of different software metrics. Cyclomatic number [9], Halstead programming effort [5], data flow complexity measures [14], cognitive complexity measures [11], [12,] [19], [20] are examples to such metrics. These metrics calculate the complexity of software from the code and measures only specific internal attributes like size, algorithm complexity, control flow structures etc. In all above mentioned complexity metrics, they attempt to quantify the primitives which make software difficult to understand. For many of them, the developer’s claim that their O. Gervasi et al. (Eds.): ICCSA 2008, Part II, LNCS 5073, pp. 641–651, 2008. © Springer-Verlag Berlin Heidelberg 2008

642

S. Misra and I. Akman

complexity metric based on an internal attribute is the most accurate predictor of software quality. However, the authors realize that a single internal attribute is not sufficient for measuring the complexity of the code. For measuring the complexity of a code, one must consider most of the internal attributes responsible for complexity. Therefore, the purpose of this paper is to propose a new complexity metric which calculates complexity of the program code by considering all factors responsible for complexity. For this, first we identified the factors which are responsible for the complexity and then established a metric to reflect a proper relationship between these factors. With these features, it is unique metric of its type. We also evaluated and validated our measure against the principles of measurement theory, since the measurement theory has been proposed and extensively used in the literature as a means to evaluate the software engineering metrics. In section 2, unique complexity measure is introduced. The quality of the proposed metric has been evaluated in section 3 against the principle of measurement theory. Experimentation and comparative study are given in section 4. The pros cons and future work is discussed in section 5. The last section 6 includes the conclusions drawn.

2 Unique Complexity Metric Complexity of a code is directly dependent on the understandability of the code and relates to ease of comprehension. All the factors that makes program difficult to understand are responsible for complexity. When we analyze a program code we find that that number of lines (size), total occurrence of operators and operands (size), numbers of control structures (control flow structuredness), function call (coupling) are the factors which directly affect the complexity. In general, these primitives are measured independently by different complexity measures and each one of these is assumed to represent overall complexity of the software. When we look at most of the known complexity measures, we can observe the close relation between number of lines, operator and operand counts, and basic control structures. Consequently, these primitives of software may constitute the components of a unified, comprehensive complexity measure. In our opinion, the complexity of a software system depends on following factors: 1. 2.

3.

Complexity of program depends on the size of the code. Therefore, the complexity due to any single line of code is assumed to be 1 unit. Complexity of program depends on the size of the code. We suggest that the size of the code can be measured by total occurrence of operators and operands. Therefore, the complexity due to ith line of the code can be calculated as SOO i = N i1 + N i 2 Where Ni1: The total number of occurrences of operators at line i, Ni2: The total number of occurrences of operands at line i, Complexity of the program is directly proportional to the cognitive weights of Basic Control Structures (BSC). Cognitive weight of software [19] is the extent of difficulty or relative time and effort for comprehending given software modeled by a number of basic control structures (BCS’s). BCS’s, sequence, branch

A Unique Complexity Metric

643

and iteration [19] are basic logic building blocks of any software and their weights are one, two and three respectively. These weights are assigned on the classification of cognitive phenomenon as discussed by Wang [19]. He proved and assigned the weights for sub conscious function, meta cognitive function and higher cognitive function as 1, 2 and 3 respectively. In fact, cognitive weights correspond to the number of executed instructions. The details of the weights for different BCS’s are given in Table-1, see [19]. Table 1. Basic Control Structures and their weights Category Sequence Branch Iteration

Embedded Component

Basic Control Structures Sequence If-Then-Else Case For-do Repeat-until While-do Function Call Recursion

Cognitive Weight 1 2 3 3 3 3 2 3

As a result, the cognitive complexity due to ith line of the code, CWi, can be weighted as in Table-1. Using the above considerations, we propose the following model to establish a proper relationship among internal attributes of software. n

UniqueComplexityMetric = ∑ (1 + SOOi *CWi )

(1)

i =1

where unique complexity metric (UCM) of the software code is defined as the sum of complexity of its n modules and module i consists of mi line of code. The unit of the UCM is given Complexity Units (CU) in terms of positive number. In Equation-1, the SOOi is multiplied by CWi because of the structural weight of the line. For a simple program having only basic control structure the “sequence”, CWi will not have any additional contribution. Therefore, for such lines the complexities are only due to SOOi. Note that in our context, although the concept of cognitive weights is referred in the formulation, the only aspect of cognitive weight idea is used as a multiplier. By this way, the scale compatibility of SOO and CW are achieved. For illustrative purpose, an algorithm written in C that finds the sum of n integers corresponding UCM calculations are given in section 4.

3 Theoretical Validation of the Complexity Measure Practical success of any proposed metric depends on the establishment of (1) its validation, (2) understandability by its users and (3) tight link between the metric and the attribute that it is intended to measure. The establishment of (2) and (3) highly

644

S. Misra and I. Akman

depends on the validation. Therefore, a new metric must be evaluated formally and practically for its validation. In order to make the software discipline more and more mature, tools provided by Measurement Theory (MT) [2] should be used. Several researchers’ proposed different validation criteria based on measurement theory [2, 3, 4, 8, 13, 18 and 21]. However, in general all of them suggest that the metric should fulfill some basic requirements based on measurement theory perspective. Amongst available validation criteria, the framework given by Morasca [13] is reported to be more practical. As a consequence, we will define the basics of MT and evaluate the proposed metric formally from MT perspective in section 3.1. We applied admissible transformation and extensive structure to investigate the scale of the UCM in section 3.2. 3.1 UCM and Measurement Theory The components of the qualified system are (1) Entities whose attributes are targeted for quantification; (2) Empirical binary relations showing the intuitive knowledge about the attributes and (3) Binary operations describing the production of new entities from the existing ones. These components are reflected in the following definitions [13]. Definition 1. (Empirical Relational System-ERS) For a given attribute, an Empirical Relational System is an ordered tuple ERS= where E : the set of entities, R1, ..., Rn denote n empirical relations such that each Ri has an arity ni, and Ri ⊆ Eni. o1, ...,.. om denote m empirical binary operations on the entities that produces new entities from the existing ones, so oj: E×E→E and the operations are represented with an infix notation, for example, ek= ei oj el. According to this definition, the components of the quantification system are the values representing the decided quantities; the binary relations showing the dependencies among them and the binary operations describing the production of new values from the existing ones. For UCM, the entities are the program bodies. The only empirical relation is assumed to be more_or_equal_complex and the only empirical binary operation is the concatenation of program bodies. This can be explained by a solid example. Assume that a program body P is given and a new program body Q is obtained by simply duplicating P. One may easily establish the relation more_or_equal_complex between P and Q. Definition 2. (Numerical Relational System-NRS) A Numerical Relational System is an ordered tuple NRS= where V : the set of values, S1, ..., Sn denote n relations such that the arity of Si is equal to the arity of Ri, and Si ⊆ Vni and p1, ..., pm denote m numerical binary operations on the values that produce new values from the existing ones, so pj: V × V →V and the operations are represented with an infix notation, for example, vk= vi pj vl. For UCM, V is the set of positive integers, the binary relation is assumed to be the numerical binary operation is the addition (i.e. +) of two positive integers.

≥ and

A Unique Complexity Metric

645

Definition 3. (Measure- m) Measure m is a mapping of entities to the values and it considers neither the empirical nor the numerical knowledge about systems, i.e. m: E→V. The measure for UCM complexity is defined by Equation (1). Note that a measure by itself does not provide any mapping between empirical and numerical knowledge. Definition 4. A measure must satisfy the following two conditions known as Representation Condition: (1)∀i∈1…….n∀∈Eni (∈Ri⇔∈ Si) (2)∀j∈1……m∀∈E×E (m(e1oje2=m(e1)pj m(e2)) The first part of the Representation Condition says that for a given empirically observed relation between entities, there must exist a numerical relation between corresponding measured values and vice versa. In other words, any empirical observation should be measurable and any measurement result should be empirically observable. The second part says a measured value of an entity which is obtained by the application of an empirical binary operation on two entities should be equal to the value obtained by corresponding numerical binary operation executed over individually measured values of entities. In other words, the complexity of the whole should be definable in terms of the complexities of its parts. For UCM, the representation condition requires that (1) if, for any two program bodies, e1 and e2 are in more_or_equal_complex relation (i.e. ∈ more_or_equal_complex) then the measured UCM complexity value of entity e1 should be greater than the measured complexity value of entity e2 (i.e. m(e1) > m(e2)) and vice versa. Considering the program bodies P and Q; if Q is the double of P then the number of BCSs, operators, operands for Q automatically becomes double. Consequently, for part (1) of the condition, it is possible to say that the empirically observed more_or_equal_complex relation between two program bodies leads to a numerical binary relation > among those entities or vice versa. However, part (1) is only satisfied if there are such clear empirically observable relations between program bodies for example P and Q. For part two of the representation condition, we can say that the UCM complexity value of a program body which is obtained by concatenation (i.e. the empirical binary operation) of e1 and e2 is equal to the sum (i.e. the numerical binary operation) of their calculated complexity values. Therefore, UCM satisfies the second part of the representation condition. Overall, then, we can say that UCM satisfies the representation condition. 3.2 Evaluation of Measure Based on Scale In the previous sub-section, we evaluated UCM through the measurement theory. It is identified that the proposed measure is satisfied by the representation condition. Now, there is a need to find out the scale of the proposed measure. There are two ways for getting the scale of the measure: through admissible transformation and extensive structures. Admissible transformation [13] is the simplest way to find the scale of a measure. On the other hand, Zuse [21] has stressed the advantage of using extensive structure because it is one of the most important measurement structures which

646

S. Misra and I. Akman

characterizes empirical conditions of reality, hypothesis of reality and empirical conditions behind the software measure. Therefore, we evaluated UCM by admissible transformation and extensive structure both. 3.2.1 Admissible Transformation Definition 6. A scale is a triple , where ERS is an Empirical Relational System, NRS is a Numerical Relational System, and m is a measure that satisfies the representation condition. For UCM, we already define ERS, NRS and m in previous section. Definition 7. Given a scale , the transformation of a scale f is admissible if m`= f ο m (i.e. m` is the composition of f and m) and is a scale. Based on admissible transformation, four different types of scales can be considered as follows [21]: Nominal scale: each entity is labeled for categories and there is no ordering relation among them. An example of nominal scale is the labeling of given programs according to the name of their authors. Ordinal scale: entities are categorized in the form of total ordering. The associated values make entities comparable. As an example, program bodies can be assigned degrees from 1 to 5 with comparative meanings (e.g. 1 for least reliable to 5 for the most reliable). Interval scale: the difference between the assigned numerical values can be quantified in their amount. A new scale m` from m can only be obtained through transformations of the form m`= a*m + b where a>0. An example can be the scale Celcius that can be converted into Fahrenheit. Ratio scale: the ratio between the numerical values associated to the entities is used for quantification. The form of transformation is: m`= a*m where a>0. The main difference between interval and ratio scale is the existence of true zero-point in ratio scale. An example of ratio scale is the LOC measure of the size of a program body. For case of UCM, it can be very easily proved that for UCM is a ratio scale. Reconsidering the two program bodies P and Q, Q/P =2 and then a=2. This implies that m`= 2*m. Therefore, it can be informally stated that the proposed measure UCM is defined on ratio scale. One way of establishing whether a given scale is a ratio scale or not is to investigate whether the scale’s Empirical Relation System is an Extensive Structure or not. 3.2.2 Extensive Structure Definition 8. Let E be a non-empty set, •≥ a binary relation on E, and o a binary operation on E. The relational system (E, •≥, o) is an Extensive Structure if and only if the following axioms hold for all e1, e2, e3, e4 ∈ Ε. [3, 21]. A1: (E, •≥) is a weak order. A2: e1 o (e2 o e3) ≈ (e1 o e2) o e3 (axiom of weak associativity). A3: e1 o e2 ≈ e2 o e1 (axiom of weak commutativity). A4: e1 •≥ e2 ⇒ e1 o e3 •≥ e2 o e3 (axiom of weak monotonicity).

A Unique Complexity Metric

647

A5: If e1 •> e2 then for any e3, e4 there exists a natural number n, such that n e1 o e3 •> n e2 o e4 where n E denotes the composition of E within itself n times (Archimedean Axiom). In the above definition, the empirical relation "•>" has the meaning "more complex than", the empirical relation "≈" means "as complex as", and the meaning of the empirical relation "•≥" is “more or equal complex than". In addition, the binary operation “o” between two objects is the composition (“concatenation” for the selected example) of two objects. The validity of the above axioms for the empirical relation system (ERS=, o>) defined for UCM should be investigated as follows: A1: There is an order relation between the flowgraph-like entities which is definable for all entities (i.e. complete); any entity is related to itself through the more_or_equal_complex relation (i.e. reflexive), and it is clear that if e1 is more_or_equal_complex than e2 and e2 is more_or_equal_complex than e3 then e1 is also more_or_equal_complex than e3 (i.e. transitive). Therefore, (E, •≥) defines a weak order. A2: The result of a series of concatenations on entities does not depend on the order of execution. Therefore, the concatenation operator of UCM has the weak associativity property and the complexity of UCM will not change. A3: The UCM complexity of two concatenated entities does not depend on their order. Therefore, this axiom is satisfied by UCM. A4: For any two entities e1 and e2, if there is a more_or_equal_complex relation between them (i.e. e1 •≥ e2) then the concatenation of a new entity e3 to both e1 (i.e. e1 o e3) and e2 (i.e. e2 o e3) does not effect the relation between them. Then, this axiom is satisfied. A5: If entity e1 is more_or_equal_complex than e2 then for any e3 and e4, a new more_or_equal_complex relation can established by sufficient number of concatenation; say n times, of e1 and e2 to themselves followed by concatenation of e3 and e4 with them, respectively. This item is also satisfied. As a result, the ERS description of the proposed UCM is an extensive structure. Consequently, UCM is concluded to be on ratio scale.

4 Experimentations through Test Cases and Comparative Study The proposed complexity metric given by equation 1 is demonstrated with the programming example given by the following Table 2. Empirical studies play an important role in the evaluation of software engineering discipline [1]. We have taken different ‘C’ programs from Misra and Mishra [10] for the analysis of the UCM approach. We calculated the Complexity Measure (UCM) for each one of those programs (see Table-4). The complexity values of its components and UCM is given in table 3. A plot for UCM and its component is shown in figure 1. The UCM for all the programs gives higher complexity values. (Figure 1). When we compare UCM with other measures (see table 4), we can conclude that the behavior of UCM is similar to the other complexity metric. However, this is not a surprising result since UCM is a unified complexity metric and its components are mostly overlapping with the other measures like cognitive complexity measure, effort measure

648

S. Misra and I. Akman

and statement counts. When we compare UCM and cognitive functional sixe metric, the missing prospective in cognitive functional size metric is the contribution of sufficient knowledge of information contents. Furthermore, the UCM emerges not only due to cognitive weights but also due to size and number of occurrence of operators and operands. The relatively high values of UCM when compared to cognitive complexity measure (see table 4) for each program are primarily due to the higher number of operators and operands and number of line of code. Table 2. Calculated complexity values for the example program N = 10 Line 1 Line 2 Line 3 Line 4 Line 5 Line 6 Line 7

Sample Algorithm #define N 10 main () { int i, n; int sum=0;

SOOi 2 0 0 3 4 0 3

CWi 1 1 1 1 1 1 1

UCMi 3 1 1 4 5 1 4

Line 8 Line 9

for (i=1;i