Measuring Product Attributes of Object-Oriented Systems Martin Hitz, Behzad Montazeri Institut für Angewandte Informatik und Informationssysteme University of Vienna Rathausstraße 4/3-4 A-1010 Vienna, Austria email:
[email protected]
Abstract The role of internal product attributes for software measures is analyzed. Attributes are classified as “fundamental”, “auxiliary” and “useless” with respect to their relevance for controlling software quality. The impact of inappropriate attributes on the usefulness of resulting metrics is discussed with emphasis on the object-oriented paradigm. We demonstrate that some of the obvious shortcomings of proposed metrics are caused by inconsiderate attribute selections. In the course of this discussion which recurs to commonly accepted frameworks in measure theory, both, well-known attributes and new proposals are treated.
1 Introduction Trying to control software quality - and all related attributes as, e.g., reliability, maintainability, usability and so forth - it is obviously necessary to measure to what extent these attributes are achieved by a certain product. Such measurements are valuable both, in an a posteriori analysis of a finished product, and, even more important, in an a priori manner to control the production process in order to avoid undesirable results in the first place. In this spirit, many software metrics have been established in the past, mainly in the area of traditional (“structured”) software design. Moreover, since the advent of the object-oriented paradigm in software engineering, several authors have already suggested metrics tailored to the specific structure of object-oriented software [2][4][5][10][11]. According to a classification by Bush and Fenton [3], we may distinguish three different types of relevant entities in the domain of software development: Products, processes, and resources. While attributes characterizing process and resource entities may apply also to object-oriented systems without major modifications, product attributes must certainly be specifically (re-)defined for object-oriented products. In fact, such definitions represent a major topic of the articles on object-oriented metrics cited above, framed by attempts to meet measure theoretic requirements as put forward by, e.g., Fenton [6][7]. However, it turns out that in striving for correct measure theoretic construction of metrics, the selection of internal1 product attributes is biased towards easily 1. Internal attributes of a product (process, resource) are those which can be measured purely in terms of the product (process, resource) itself. In contrast, external attributes can only be measured with respect to how the product (process, resource) relates to its environment. -1-
measurable, but not always very relevant attributes. It seems that in many cases, numbers which can easily be derived from a software document are picked up in order to investigate their relationships to external product attributes. Such an approach leads to attributes which - although somehow related - do not necessarily have a causal relation to the external attributes considered. Consequently, they do not qualify as decision variables when trying to improve the external attribute. Thus, many of these attributes are of minor relevance from the designer’s or programmer’s points of view. It should be noted that we do agree with the general requirement that useful software metrics must be easily collectible. This is especially true for CASE environments, where any reasonable metric had best be automatically computable by software tools in order not to represent a bottleneck of the development cycle. However, the task to identify relevant attributes resembles the analysis phase in software engineering: First, we have to reason about what we need without constraining ourselves by implementation oriented details. Once the analysis is completed (i.e., the attributes of interests are defined), we may choose a design variant which best meets our technical constraints (i.e., construct a measure that can be evaluated by a software tool). We all know that the inverse approach of confronting a customer with easily implemented solutions very often misses the point by not solving the customer’s problem. Similarly, easily collectible software metrics may simply not prove useful for control purposes when the attributes measured do not meet some basic requirements. In this paper, we try to shed some light on the selection of attributes for object-oriented software products. We start with an analysis of some well-known object-oriented internal product metrics in Section 2, showing their major shortcomings and how these are related to inappropriate attribute selection. As a result, we propose a classification of attributes with respect to their relevance in order to control product quality. In Section 3, we give examples of “good” attributes, beginning with some attributes taken from the literature (MPC, LCOM, WMC), followed by a series of newly proposed ones (Mutation, Change Dependency Between Classes, Locality of Data). We also suggest ways of measuring these attributes, although our emphasis lies in attribute selection. As a conclusion, we present in Section 4 an overview of the complete process of metrics construction including the new aspects proposed in main part of this article and hint at possible sources of error.
2 Poor Product Attributes Yield Ineffective Software Metrics In order to analyze the weaknesses of many internal attributes discussed in the literature, let us briefly present in Figure 1 a well-known series of attributes and corresponding measures as discussed by Li and Henry [11] and, in part, by Chidamber and Kemerer [4][5]. Figure 1 reflects the general intuition that all the metrics proposed (DIT to SIZE2) are somehow related to the complexity of the classes under consideration. Complexity in turn influences the maintenance effort incurring within a certain period (measured by the process attribute “number of lines changed”). In an empirical analysis in the same paper, Li and Henry show that the internal attributes of Figure 1 are indeed highly -2-
Metrics DIT = Depth in the Inheritance Tree
NOC = Number of Children
MPC = Message Passing Coupling = # of send statements defined in a class
RFC = # of local methods + # of methods called by local methods
LCOM = Lack of Cohesion Of Methods Complexity
# number of lines changed per class in its maintenance history
DAC = # of ADTs defined in a class
WMC = Weighted Method Complexity
NOM = Number of Methods
SIZE1 = # of semicolons per class
SIZE2 = # of methods + # of attributes Fig. 1. Some object-oriented software metrics
correlated with maintenance costs. Although this result seems very promising, we must note the following: • This correlation cannot easily be used as a prediction model, because the dependent variable, as an external product attribute, strongly depends on many other influence factors also, such as psychological complexity of the problem, experience and knowledge of the production team, programming language, tools, and test -3-
strategies. All these factors are very hard to keep constant in different projects, thus rendering prediction based solely on the internal attributes very unreliable. On the other hand, it seems very difficult to measure the environmental factors mentioned in order to build a more comprehensive prediction model. • The model determines maintenance costs per class. However, most metrics are in one way or another functions of class size (e.g., SIZE1 and SIZE2, but also MPC, RFC, DAC, WMC and NOM). An attempt to minimize predicted maintenance costs by minimizing these metrics will thus necessarily lead to smaller classes. Under the constraint of given system requirements, the number of classes will rise in order to fulfill theses requirements. A higher number of classes increases the overall system complexity and may therefore in turn lead to increasing overall maintenance costs. In other words, the correlation of these metrics with maintenance costs on a per class basis does not imply a correlation of these metrics with the overall maintenance costs of a system. As an example, consider a class X with 100 methods yielding a hypothetical maintenance effort of 10. Separating the class’s functionality in two classes X1 and X2 with 60 and 40 methods each might result in maintenance costs of 7 and 5, respectively, thus showing the presumed correlation of the number of methods and maintenance costs on a per class basis. However, the total costs incurring rise from 10 to 12! It is thus evident that maintenance costs per class must be normalized taking into account the size of the class considered, i.e., the costs must be divided by the class size. In order to avoid these problems in the first place, we must distinguish between mere statistical correlations and causal relationships. While a prediction model can be based on the more general statistical relationships, a model used to control the development process should be based on causal relationships. In the sequel, we will distinguish between the following two categories of internal attributes: • Set C contains internal attributes with a causal relationship to the set E of external attributes of interest. They are deemed as fundamental for control purposes. To classify an attribute as a C-attribute, the designer must have a sound idea of the mechanism influencing the E-attribute of interest - observing a statistical correlation between both attributes is not sufficient for this purpose. • NC denotes the set of internal attributes which are statistically correlated to E, but do not have a causal effect on the attributes in E. One should note that there are some attributes in NC which nevertheless prove to be useful in so far as their measures might be used as auxiliary metrics in order to calculate measures for attributes in C. However, as members of NC, they are not considered interesting per se. We therefore distinguish the following subclasses of NC in the sequel: • A, the set of auxiliary attributes, and • U = NC \ A, the set of useless attributes. This classification is of course somewhat fuzzy, but in most cases, it should be possible to assign a given attribute to one of those classes.
-4-
For example, consider DIT and NOC, the inheritance oriented attributes discussed in [2][4][5][11]. We depict the agreed upon relationships in the following figure: Attributes ∈ NC
Attributes ∈ C Coupling: Access to instance variables of the superclass
DIT
Mutation (illoyalty of subclasses, haphazard inheritance): • Disinheritance of inherited properties • Change of inherited behavior • Restriction of inherited behavior
NOC
Attributes ∈ E
Complexity
Maintenance
Relationship Influence Fig. 2. Relationships between attribute classes NC, C, and E
Focussing first on DIT, the depth of the inheritance tree, let us quote Li and Henry [11]: “It seems logical that the lower a class in the inheritance tree, the more superclass properties this class may access due to inheritance. If the subclass accesses the inherited properties from the superclass without using the methods defined in the superclass, the encapsulation of the superclass is violated. One may intuit that the larger the DIT metric, the harder it is to maintain the class.” Analyzing this statement, we may conclude that it is not a high DIT which makes the class hard to maintain or hard to understand, but it is rather the coupling induced by accessing foreign instance variables (thus breaking the encapsulation principle) that deserves the blame. Consequently, we should not measure DIT but rather “Access to superclass variables”. Concentrating on the latter attribute that clearly shows a causal relationship to the external product attributes (and is therefore a member of C, allowing to control the quality of the product), we also get rid of the problems of inconsistent empirical relation systems for DIT: In the literature on object-oriented design principles, there is no agreement about the “optimal” depth of inheritance trees. Moreover, trying to minimize DIT would consequently lead to the guideline “Do not use inheritance at all”, which is obviously counter-intuitive within the object-oriented paradigm. On the other hand, minimizing “Access to superclass variables” leads to the extremal rule “Do not access superclass variables at all”, which has no such paradox appearance. In a similar spirit, DIT does not directly cause misused inheritance (“Mutation” in Figure 2). Consequently, the attribute of interest is mutation rather than DIT. For this attribute, one might argue that it seems to be much harder to measure than DIT and that DIT could be used as an estimate for the former. However, such an estimation -5-
requires both, a measure for mutation and a (unknown!) calibrated estimator which is again heavily context sensitive, i.e., dependent on habits of programmers etc. Mutatis mutandis, all the above arguments apply also to NOC, which by itself does not contribute to low product quality. In our opinion, applying our classification of internal attributes as defined above to the attributes in Figure 1 yields the following sets: C = {MPC, LCOM, WMC} NC = {DAC, NOM, SIZE1, SIZE2, DIT, NOC, RFC} While the members of class C will be dealt with in more detail in Section 3, our assignments of attributes to class NC, are based on the following observations (as to DIT and NOC, cf. the discussion of Figure 2 above): In [11], DAC is considered relevant because “[it] may cause a violation of encapsulation if the programming language permits direct access to the private properties in the ADT”. Thus, DAC in itself does not necessarily contribute to higher maintenance efforts, unless the underlying ADTs are not used appropriately. For NOM, SIZE1, SIZE2, and RFC the general arguments given earlier in this section apply. As indicated, all of these size metrics may however be useful as auxiliary attributes (and can thus be considered members of subclass A). In this classification, we are assessing only the appropriateness of the attributes themselves without taking into account the corresponding measures suggested. These will be discussed in Section 3. We may thus conclude that the first obligation of software measurement is the careful identification of attributes that exhibit (at least intuitively) a strong influence on the external attributes to be controlled. In the next section, we propose some of the Cattributes important for object-oriented development.
3 Examples of Useful Attributes and Their Measures In this section, we discuss some internal attributes which seem to have a strong influence on important external product attributes such as complexity, maintainability, and quality. These internal attributes thus belong to class C as defined in Section 2. We start our enumeration with those attributes taken from Figure 1 which satisfy our requirements: MPC, LCOM, and WMC. We then propose some new attributes: Mutation, change dependency (CDBC), and locality of data (LD). For each of these attributes, we discuss possible measures which will sometimes employ also auxiliary attributes like NOM. In the course of the discussion of measures, we try to conform to the guidelines given by Fenton, especially with respect to the so-called representation condition which demands that any measure preserve all generally accepted empirical relations for the attribute measured [6][7]. However, as we are focusing on the usefulness of attributes here, a thorough presentation of measure theoretic aspects is beyond the scope of this paper. -6-
3.1 Message Passing Coupling (MPC) MPC represents coupling between classes induced by message passing. As most coupling attributes, MPC has certainly direct effects on maintainability, testability, comprehensibility and so forth. However, the measure defined by Li and Henry (the number of send statements defined in a class [11]), seems to be questionable. Given two classes X and Y, with X sending 10 messages to one and the same server class and Y sending 1 message each to 10 distinct server classes, one would empirically conclude that MPC of X is weaker than MPC of Y, although the measure for MPC yields the same value in both cases. Instead of trying to improve this measure here, we refer the reader to sections 3.5 and 3.6, where other coupling-related attributes are discussed, and also to [8], where the object-oriented notion of coupling is dealt with in some more detail. Specifically, it is argued that total coupling between two classes is a function of several different types of links between those classes and that a comprehensive measure for coupling must therefore capture many different empirical relations, the most important of which are: • Access to instance variables constitutes stronger coupling than pure message passing. • Access to instance variables of foreign classes constitutes stronger coupling than access to instance variables of superclasses (a similar argument holds for message passing). • Passing a message with a wide parameter interface yields stronger coupling than passing one with a slim interface. • Violating the Law of Demeter [12][13] yields stronger coupling than restricted (Demeter conforming) message passing. • Couples to the following types of objects should yield increasing coupling values: local objects, method parameters, subobjects of self (= instance variables of class type), subobjects of a super class (= inherited instance variables of class type), global objects. 3.2 Lack of Cohesion in Methods (LCOM) Cohesion is an important attribute corresponding to the quality of the abstraction captured by the class under consideration. Good abstractions typically exhibit high cohesion. The original object-oriented cohesion metric, LCOM, as given by Chidamber and Kemerer [4] represents an inverse measure for cohesion. Its definition has been improved by Li and Henry [11]2 and can be restated as follows3: Let X denote a class, IX the set of its instance variables of X and MX the set of its methods. Consider a simple, undirected graph GX(V, E) with V = MX and E = { | ∃ i∈IX: (m accesses i) ∧ (n accesses i)}. 2. It is interesting to note that the improved version by Chidamber and Kemerer [5] suffers more measure theoretic anomalies than the older improvement by Li and Henry [11]. 3. Although the original ambiguous definition has been clarified by Li and Henry, their settheoretic formulation is still not quite precise. Hence our graph-theoretic version. -7-
LCOM(X) is then defined as the number of connected components of GX (1≤LCOM(X)≤|MX|). With this definition, an LCOM value of k>1 hints at the possibility to split X into k smaller and more cohesive classes. However, the not uncommon design principle to restrict accesses to instance variables to special purpose read/write methods introduces an anomaly of this measure: An otherwise cohesive class would yield very high LCOM-values, as all of the “real” methods would yield isolated nodes in the graph, as they do not directly share any instance variable anymore. To get rid of this anomaly, the definition of GX could be changed as follows: AX= V= E=
set of trivial methods to access instance variables, MX \ AX and { ∈ V×V | ∃ i∈IX: (m accesses i)∧(n accesses i)}.
where “m accesses i” means “method m immediately accesses i or calls the corresponding method in AX. 3.3 Weighted Methods per Class (WMC) WMC is supposed to describe the algorithmic complexity of the class by means of the complexities of all its methods. It is defined as n
WMC =
∑ ci i=1
where n denotes the number of methods of a class and ci the complexity of method i. When all methods are considered equally complex, ci becomes 1 and WMC becomes n. In this case, WMC is measured on an absolute scale but reflects only very roughly the real complexity of the class. However, if we do indeed consider distinct complexity factors ci, the WMC is well defined only if ci have at least an interval scale, otherwise, summing becomes an illegal operation. Thus, although algorithmic complexity of a class is certainly a reasonable attribute in the sense of Section 2 (it directly affects the complexity of the software product), a measure like WMC is tied to the quality of the underlying measure of method complexity. 3.4 Mutation An important aspect of object-oriented software design is the correct employment of inheritance. As we have briefly noted in Figure 2, there are several ways of misusing this feature. Armstrong and Mitchell call such misuses haphazard inheritance defined as follows [1]: “Haphazard inheritance refers to the undisciplined use of inheritance to maximize code reuse. Subclasses are derived using disinheritance and restriction in whatever combination makes the coding quicker. Haphazard inheritance is often a consequence of implementation simulation. [...] In implementation simulation, the programmer inherits the implementation of a class, rather than including an object of the class as one of its instance variables.” In this sense, we may distinguish several variants of class mutation occurring in the course of class derivation:
-8-
Harmless mutation: 1. Protocol extension: A subclass defines new methods in addition to those it inherits. 2. Re-implementation: A subclass changes the implementation of its superclass without altering the inherited behavior (i.e., pre- and postconditions of methods are left unchanged). For example, the code of inherited methods can be re-written to be more efficient. 3. Behavior extension: A subclass extends the behavior of (some of) the inherited methods by relaxing preconditions or by enforcing stronger postconditions. For example, a method which computes floating point numbers to an accuracy of five decimal places might be redefined to compute up to ten decimal places. Harmful mutation (haphazard inheritance): 4. Behavior restriction, behavior modification: Any other change of behavior. 5. Disinheritance: Eliminating inherited properties (usually by some technical trick). Although one might agree that the above list represents a measure of mutation on an ordinal scale, measuring mutation may be difficult, especially as far as the discrimination between cases 2, 3, and 4 above is concerned. In environments where pre- and postconditions of methods represent integrated features of the design and implementation process and may be checked automatically, an evaluation tool for this measure is conceivable, but without such support, one must resort to manual code inspections. However, if one were only interested in the effects of mutation on complexity and maintenance (disregarding other quality aspects of the inheritance hierarchy), it might not be necessary to differentiate between cases 2, 3, and 4. 3.5 Change Dependency Between Classes (CDBC) Another attribute with strong influence on the expected maintenance effort is the change dependency between classes (CDBC), a special kind of coupling called class level coupling by Hitz and Montazeri [8]. When a client class CC employs some service of another class SC (the server class), it becomes more or less vulnerable to changes made to SC. The degree of this change dependency determines the potential amount of follow-up work to be done when class SC is being modified in the course of some maintenance activity. While the actual number of changes necessary to bring class CC to par is not predictable in general, CDBC determines the number of methods to be considered upon such a change of SC. Broadly speaking, CDBC depends on 1. the scope of visibility of the changed server class within the client class (determined by the type of relationship between CC and SC) and 2. the kind of access of CC to SC (interface access or implementation access, see below). Investigating possible relationship types yields Table 1.: Of course, α is only relevant if those parts of SC accessed by CC are in fact subject to change. This motivates the point 2 mentioned above: If SC represents a mature abstraction, its interface is assumed to be much more stable than its implementation. Thus, many of the changes to the implementation of SC can be performed without affecting its interface. We -9-
SC is not used by CC at all SC is the class of an instance variable of CC Local variables of type SC are used within j methods of CC SC is a superclass of CC SC is the type of parameter of j methods of CC CC accesses a global variable of class SC
α = number of methods of CC potentially affected by a change 0 n j n j n
Table 1. Relationship types between CC and SC and their corresponding contribution α to change dependency.
therefore introduce a factor k (0≤k≤1) corresponding to the stability of SC’s interface and multiply the contribution of an access to the interface with 1-k. We can now express CDBC as follows: CDBC ( CC, SC ) = min n,
∑
αi
accesses i to implementation
+ ( 1 – k) ⋅
∑ αi
accesses i to interface
CDBC can be minimized by restricting access to the interface of the server class and restricting the visibility of server classes to small scopes, which may be enforced by language mechanisms like the access specifiers in C++ (public, protected, private). Thus, for designs conforming to the usual guidelines for object-oriented design with stable interfaces and access restricted to the interface only, the change dependency becomes negligeable. We want to point out that although the measure suggested above may be subject to further improvements, the underlying internal attribute itself is certainly highly relevant for controlling the quality of a product in a changing environment, as stressed by Jarke and Pohl [9]. 3.6 Locality of Data (LD) Similar to cohesion, locality of data (LD) represents an attribute directly connected with the quality of the abstraction embodied by a class. Classes with high data locality are more self-sufficient than those with low data locality. This attribute influences external attributes like the class's reuse potential or its testability. We can construct a measure for LD by relating the amount of data local to the class to the total amount of data used by that class. For C++, we can define more precisely for a class C n
∑
Li
=1 LD = i----------------n ∑ Ti i=1
- 10 -
with Mi (1≤i≤n) Li (1≤i≤n)
Ti (1≤i≤n)
methods of class C (excluding all trivial read/write methods for instance variables) set of “local” variables accessed by Mi (directly or via read/write methods). These are: non-public instance variables of class C, inherited protected instance variables of its superclasses, static variables defined locally in Mi set of all variables used in Mi, except for nonstatic local variables defined in Mi
For the sake of robustness of the measure, we excluded all auxiliary variables defined in Mi because they don’t play a major role in a design. A protected instance variable which has been inherited by a class C is local for an object CO of type C (and hence a member of Li), even though it is not declared in class C. Using such a variable by methods of C is harmless with respect to LD (it is only accessible by CO itself) but it is undesirable if we are interested to achieve a low value of CDBC. This example shows that coupling is a multi-dimension attribute which must be divided into more elementary ones4.
4 Conclusion We explained the importance of selecting relevant attributes as a basis for software measurement. We analyzed the usefulness of some object-oriented metric proposals taken from the literature based on their effects on external product attributes. We also presented some proposals for additional attributes pertinent to object-oriented systems which satisfy our usefulness criteria. As the core of our argumentation, we stressed that fundamental internal product attributes must be (at least intuitively) causally related to external attributes. The drawbacks of inadvertent selection of non-causal attributes can be summarized as follows: • Non-causal attributes are not suitable to control the quality of the software product under construction. • As a consequence, such attributes are not likely to be taken seriously by designers and programmers. • It is hard to derive software standards based on non-causal attributes, because of controversial opinions about their effects within the software engineering community. However, as measurement of “useful” attributes may turn out to be somewhat difficult, we present in Figure 3 overleaf a compiled and extended overview of the guidelines for the construction of software measures as put forward in recent publications on measure theoretic aspects of software measurement (e.g., [6], [7]). Revealing the 4. In fact, the first motivation to define LD stemmed from the analysis of a related general coupling measure defined by Stiebellehner [14], who does not distinguish between the distinct aspects of CDBC and LD. - 11 -
possible error exits of the flowchart in Figure 3 will help to analyze and improve previously proposed measures and may guide software scientists in the identification of new attributes and development of corresponding measures to avoid these branches in the first place. References [1] J. M. Armstrong, R. J. Mitchell. Uses and abuses of inheritance. Software Eng. Journal January 1994, 19-26. [2] F. Brito e Abreu, R. Carapuca. Candidate Metrics for Object-Oriented Software within a Taxonomy Framework. J. Systems Software 26, 1994, 87-96 [3] M. Bush, N. E. Fenton. Software Measurement: A conceptual framework. J. Syst. Software 12, 1990, 223-231. [4] S. R. Chidamber, C. F. Kemerer. Towards a Metrics Suite for object-oriented Design. In Proc. OOPSLA '91, ACM 1991, 197-211. [5] S. R. Chidamber, C. F. Kemerer. A metrics suite for object-oriented design. IEEE Trans. Software Eng., vol. 20, no. 6, June 1994, 476-493. [6] N. E. Fenton. Software Measurement: A necessary scientific basis. IEEE Trans. Software Eng., vol. 20, no. 3, March 1994, 199-206. [7] N. E. Fenton. Software Metrics - A Rigorous Approach. Chapman & Hall, 1992. [8] M. Hitz, B. Montazeri. Measuring Coupling and Cohesion In Object-Oriented Systems. Technical Report 950201, Institut für Angewandte Informatik und Informationssysteme, University of Vienna, 1995. [9] M. Jarke, K. Pohl. Requirements engineering in 2001: (virtually) managing a changing reality. Software Engineering Journal, Nov. 1994, 257-266. [10] S. Karunanithi, J. M. Bieman. Candidate Reuse Metrics for Object-Oriented and Ada Software. In Proc. IEEE-CS Symposium, 1993. [11] W. Li, S. Henry. Maintenance Metrics for the Object Oriented Paradigm. In Proc. 1st Int. Software Metrics Symp., Los Alamitos, CA, 1993, IEEE Comp. Soc. Press, 1993, 52-60. [12] K. Lieberherr, I. Holland, Arthur Riel. Object-Oriented Programming: An Objective Sense of Style. In Proc. OOPSLA '88, ACM 1988, 323-334. [13] K. Lieberherr, I. Holland. Assuring Good Style for Object-Oriented Programs. IEEE Software, September 1989, 38-48. [14] J. Stiebellehner. Kopplung in Objektorientierten Systemen - Definition und Bewertung von Kopplungsmaßzahlen. Dissertation, University of Vienna, 1993
- 12 -
Measurement for assessment
Identify the internal attribute of interest (X)
no X ∈ U (useless attributes)
∃ any function of X yielding an attribute interesting by itself ?
no
yes X ∈ A (auxiliary attributes)
Measure for X may not become broadly accepted - a major source of dissatisfaction
Is X interesting by itself? yes X ∈ C (causal attributes) Establish empirical relation system R to capture the intuitive understanding of X
no
Is R complete? yes Find a mapping M into a numerical system Validate M (check the representation condition)
M does not consistently represent the intuitive understanding of X
no
Is representation condition satisfied? yes Determine the scale type for M
Illegal operations can be applied to the measurement results
no
Is the scale type appropriate? yes Measure M for X is ok
Fig. 3. Phases of measurement construction and possible mistakes - 13 -
