Abstract There In this paper, we propose a mathematical framework which is generic, because it is not specific to any particular software artifact, and rigorous, because it is based on precise mathematical concepts. This framework defines several important measurement concepts (size, length, complexity, cohesion, coupling  Many concepts have been introduced through the years to define the characteristics of the artifacts produced during the software process. For instance, one speaks of size and complexity of software specification, design, and code, or cohesion and coupling of a software design or code. Several techniques have been introduced, with the goal of producing software which is better with respect to these concepts. As an example, Parnas [P72] design principles attempt to decrease coupling between modules, and increase cohesion within modules. These concepts are used as a guide to choose among alternative techniques or artifacts. For instance, a technique may be preferred over another because it yields artifacts that are less complex; an artifact may be preferred over another because it is less complex. University of Maryland CS-TR-3368 -2 definition of relevant concepts (i.e., classes of software characterization measures) is the first step towards quantitative assessment of software artifacts and techniques, which is needed to assess risk and find optimal trade-offs between software quality, schedule and cost of development. To capture these concepts in a quantitative fashion, hundreds of software measures have been defined in the literature. However, the vast majority of these measures did not survive the proposal phase, and did not manage to get accepted in the academic or industrial worlds. One reason for this is the fact that they have not been built using a clearly defined process for defining software measures. As we propose in [BMB94(b)], such a process should be driven by clearly identified measurement goals and knowledge of the software process. One of its crucial activities is the precise definition of relevant concepts, necessary to lay down a rigorous framework for software engineering measures and to define meaningful and well-founded software measures. The theoretical soundness of a measure, i.e., the fact that it really measures the software characteristic it is supposed to measure, is an obvious prerequisite for its acceptability and use. The exploratory process of looking for correlations is not an acceptable scientific validation process in itself if it is not accompanied by a solid theory to support it. Unfortunately, new software measures are very often defined to capture elusive concepts such as complexity, cohesion, coupling, connectivity, etc. (Only size can be thought to be reasonably well understood.) Thus, it is impossible to assess the theoretical soundness of newly proposed measures, and the acceptance of a new measure is mostly a matter of belief. To this end, several proposals have appeared in the literature [LJS91, TZ92, W88] in recent years to provide desirable properties for software measures. These works (especially [W88]) have been used to "validate" existing and newly proposed software measures. Surprisingly, whenever a new measure which was proposed as a software complexity measure did not satisfy the set of properties against which it was checked, several authors failed to conclude that their measure was not a software complexity measure, e.g., [CK94, H92] . Instead, they concluded that their measure was a complexity measure that does not satisfy that set of properties for complexity measures. What they actually did was provide an absolute definition of a software complexity measure and check whether the properties were consistent with respect to the measure, i.e., check the properties against their own measure. This situation would be unacceptable in other engineering or mathematical fields. For instance, suppose that one defines a new measure, claiming it is a distance measure. Suppose also that that measure fails to satisfy the triangle inequality, which is the characterizing property of distance measures. The natural conclusion would be to realize that that is not a distance measure, rather than to say that it is a distance measure that does not satisfy the conditions for a distance measure. However, it is true that none of the sets of properties proposed so far has reached so wide an acceptance to be considered "the" right set of necessary properties for complexity. It is our position that this odd situation is due to the fact that there are several different concepts that are still covered by the same word: complexity. Within the set of commonly mentioned software characteristics, size and complexity are the ones that have received the widest attention. However, the majority of authors have been inclined to believe that a measure captures either size or complexity, as if, besides size, all other concepts related to software characteristics could be grouped under the unique name of complexity. Sometimes, even size has been considered as a particular kind of complexity measure. Actually, these concepts capture different software characteristics, and, until they are clearly separated and their similarities and differences clearly studied, it will be impossible to reach any kind of consensus on the properties that characterize each concept relevant to the definition of software measures. The goal of this paper is to lay down the basis for a discussion on this subject, by providing properties for a-partial-set of measurement concepts that are relevant for the definition of software measures. Many of the measure properties proposed in the literature are generic in the sense that they do not characterize specific measurement concepts but are relevant to all syntactically-based measures (see [S92, TZ92, W88]). In this paper, we want to focus on properties that differentiate measurement concepts such as size, complexity, coupling, etc. Thus, we want to identify and clarify the essential properties behind these concepts that are commonplace in software engineering and form important classes of measures. Thus, researchers will be able to validate their new measures by checking properties specifically relevant to the class (or concept) they belong to (e.g., size should be additive). By no means should these properties be regarded as the unique set of properties that can be possibly defined for a given concept. Rather, we want to provide a theoretically sound and convenient solution for differentiating a set of well known concepts and check their analogies and conflicts. Possible applications of such a framework are to guide researchers in their search for new measures and help practitioners evaluate the adequacy of measures provided by commercial tools. We also believe that the investigation of measures should also address artifacts produced in the software process other than code. It is commonly believed that the early software process phases are the most important ones, since the rest of the development depends on the artifacts they produce. Oftentimes, the concepts (e.g., size, complexity, cohesion, coupling) which are believed relevant with respect to code are also relevant for other artifacts. To this end, the properties we propose will be general enough to be applicable to a wide set of artifacts. The paper is organized as follows. In Section 2, we introduce the basic definitions of our framework. Section 3 provides a set of properties that characterize and formalize intuitively relevant measurement concepts: size, length, complexity, cohesion, coupling. We also discuss the relationships and differences between the different concepts. Some of the best-known measures are used as examples to illustrate our points. Section 4 contains comparisons and discussions regarding the set of properties for complexity measures defined in the paper and in the literature. The conclusions and directions for future work come in Section 5. Before introducing the necessary properties for the set of concepts we intend to study, we provide basic definitions related to the objects of study (to which these concepts can be applied), e.g., size and complexity of what? Two of the concepts we will investigate, namely, size (Section 3.1) and complexity (Section 3.3) are related to systems, in general, i.e., one can speak about the size of a system and the complexity of a system. We also introduce a new concept, length (Section 3.2), which is related to systems. In our general framework-recall that we want these properties to be as independent as possible of any product abstraction-, a system is characterized by its elements and the relationships between them. Thus, we do not reduce the number of possible system representations, as elements and relationships can be defined according to needs. A system S will be represented as a pair <E,R>, where E represents the set of elements of S, and R is a binary relation on E (R ⊆ E × E) representing the relationships between S's elements. Given a system S = <E,R>, a system m = <E m ,R m > is a module of S if and only if E m ⊆ E, R m ⊆ E × E, and R m ⊆ R. As an example, E can be defined as the set of code statements and R as the set of control flows from one statement to another. A module m may be a code segment or a subprogram. The elements of a module are connected to the elements of the rest of the system by incoming and outgoing relationships. The set InputR(m) of relationships from elements outside module m = <E m ,R m > to those of module m is defined as InputR(m) = {<e 1 ,e 2 > ∈ R| e 2 ∈ E m and e 1 ∈ E -E m } The set OutputR(m) of relationships from the elements of a module m = <E m ,R m > to those of the rest of the system is defined as OutputR(m) = {<e 1 ,e 2 > ∈ R| e 1 ∈ E m and e 2 ∈ E -E m } ◊ University of Maryland CS-TR-3368 -4 We now introduce inclusion, union, intersection operations for modules and the definitions of empty and disjoint modules, which will be used often in the remainder of the paper. For notational convenience, they will be denoted by extending the usual set-theoretic notation. We will illustrate these operations by means of the system S = <E,R> represented in Figure 1 , where E = {a,b,c,d,e,f,g,h,i,j,k,l,m} and R = {<b,a>,<b,f>,<c,b>,<c,d>,<c,g>,<d,f>,<e,g>,<f,i>, <f,k>,<g,m>,<h,a>,<h,i>,<i,j>,<k,j>,<k,l>}. We will consider the following modules -m 1 = <E m1 ,R m1 > = <{a,b,f,i,j,k},{<b,a>,<b,f>,<f,i>,<f,k>,<i,j>,<k,j>} (area filled with ) -m 2 = <E m2 ,R m2 > = <{f,j,k},{<f,k>,<k,j>} (area filled with ) -m 3 = <E m3 ,R m3 > = <{c,d,e,f,g,j,k,m},{<c,d>,<c,g>,<d,f>,<e,g>,<f,k>,<g,m>, <k,j>}> (area filled with ) -m 4 = <E m4 ,R m4 > = <{d,e,g},{<e,g>}> (area filled with ) Inclusion. Module m 1 = <E m1 ,R m1 > is said to be included in module m 2 = <E m2 ,R m2 > (notation: m 1 ⊆ m 2 ) if E m1 ⊆ E m2 and R m1 ⊆ R m2 . In Figure 1 , m 4 ⊆ m 3 . Union. The union of modules m 1 = <E m1 ,R m1 > and m 2 = <E m2 ,R m2 > (notation: m 1 ∪ m 2 ) is the module <E m1 ∪ E m2 ,R m1 ∪ R m2 >. In Figure 1 , the union of modules m 1 and m 3 is module m 13 = <{a,b,c,d,e,f,g,i,j,k,m}, {<b,a>,<b,f>,<c,d>,<c,g>,<d,f>,<e,g>,<f,i>, <f,k>,<g,m>,<i,j>,<k,j>} (area filled with or or ). Intersection. The intersection of modules m 1 = <E m1 ,R m1 > and m 2 = <E m2 , R m2 > (notation: m 1 ∩ m 2 ) is the module <E m1 ∩ E m2 ,R m1 ∩ R m2 >. In Figure 1 , m 2 = m 1 ∩ m 3 . Empty module. Module <∅,∅> (denoted by ∅) is the empty module. Since in this framework modules are just subsystems, all systems can theoretically be decomposed into modules. The definition of a module for a particular measure in a specific context is just a matter of convenience and programming environment (e.g., language) constraints. University of Maryland CS-TR-3368 -5 The other two concepts we will investigate, cohesion (Section 3.4) and coupling (Section 3.5), are meaningful only with reference to systems that are provided with a modular decomposition, i.e., one can speak about cohesion and coupling of a whole system only if it is structured into modules. One can also speak about cohesion and coupling of a single module within a whole system. The 3-tuple MS = <E,R,M> represents a modular system if S = <E,R> is a system according to Definition 1, and M is a collection of modules of S such that ∀ e ∈ E ( ∃ m ∈ M (m = <E m ,R m > and e ∈ E m ) ) and ∀ m 1 ,m 2 ∈ M (m 1 = <E m1 ,R m1 > and m 2 = <E m2 ,R m2 > and E m1 ∩ E m2 = ∅) i.e, the set of elements E of MS is partitioned into the sets of elements of the modules. We denote the union of all the R m 's as IR. It is the set of intra-module relationships. Since the modules are disjoint, the union of all OutputR(m)'s is equal to the union of all InputR(m)'s, which is equal to R-IR. It is the set of inter-module relationships. As an example, E can be the set of all declarations of a set of Ada modules, R the set of dependencies between them, and M the set of Ada modules. Figure 2 shows a modular system MS = <E,R,M>, obtained by partitioning the set of elements of the system in Figure 1 in a different way. In this modular system, E and R are the same as in system S in Figure 1 , and M = {m 1 ,m 2 ,m 3 }.
In that work, we used a different model for module representation (based on LDL) and formally proved that the measures proposed respect the properties of the framework by REF .
Property-based Software Engineering Measurement
IEEE Transactions on Software Engineering
Computer Science