January 4, 1992

A Software Complexity Model of Object-Oriented Systems

David P. Tegarden Information and Decision Sciences School of Business and Public Administration California State University San Bernadino, California 92407-2397 tegarden@gallium.csusb.edu (714) 880-5792 Steven D. Sheetz Graduate School of Business University of Colorado Boulder, Colorado 80309-0419 SHEETZ_S@CUBLDR.COLORADO.EDU (303) 492-4405 David E. Monarchi Graduate School of Business University of Colorado Boulder, Colorado 80309-0419 MONARCHI_D@CUBLDR.COLORADO.EDU (303) 492-7584 ABSTRACT A model for the emerging area of software complexity measurement of OO systems is required for the integration of measures defined by various researchers and to provide a framework for continued investigation. We present a model, based in the literature of OO systems and software complexity for structured systems. The model defines the software complexity of OO systems at the variable, method, object, and system levels. At each level, measures are identified that account for the cohesion and coupling aspects of the system. Users of OO techniques perceptions of complexity provide support for the levels and measures. KEYWORDS: Object-Oriented Systems, Software Metrics, Software Measurement, Software Quality Send Comments to Steven D. Sheetz at the above address. Revised for: Decision Support Systems: The International Journal (1/93)

2 1. Introduction Among the many claimed benefits of Object-Oriented (OO) systems are faster development, higher quality, easier maintenance, reduced costs, increased scalability, better information structures, and increased adaptability [51]. One of the primary reasons for these claims is that OO approaches control complexity of a system by supporting hierarchical decomposition through both data and procedural abstraction [7]. However, as Brooks points out, "The complexity of software is an essential property, not an accidental one" [10]. The OO decomposition process merely helps control the inherent complexity of the problem; it does not reduce or eliminate the complexity. Measurement of the software complexity of OO systems has the potential to aid in the realization of these expected benefits. Measurement of software complexity has been of great interest to researchers in software engineering for some time [6, 22, 35]. Software complexity has been shown to be one of the major contributing factors to the cost of developing and maintaining software [20]. According to Coad and Yourdon [15], a good OO design is one that allows trade-offs of analysis, design, implementation and maintenance costs throughout the lifetime of the system so that the total lifetime costs of the system are minimized. Software complexity measurement can contribute to making these cost trade-offs in two ways. These are: 1) To provide a quantitative method for predicting how difficult it will be to design, implement, and maintain the system. To provide a basis for making the cost trade-offs necessary to reduce costs over the lifetime of the system.

2)

We propose a model of the software complexity of OO systems described at four levels: variable, method, object, and system. Figure 1 shows the levels and the relationships between

3 the levels. At each level, measures are identified to account for the cohesion (intra) and coupling (inter) aspects of the system at that level. The measures account for both procedural and data characteristics of an OO system, and are applicable throughout the lifetime of an OO system. Together the measures provide analysts, designers, and programmers using OO techniques the ability to identify which components of an OO system are the most complex, and may therefore require additional analysis, design, or testing. 1.1. Related Work Traditional systems have been the focus for most of the past work on software complexity measurement [16, 22, 35, 54]. Recently there has been increasing interest in software complexity measurement of OO systems [11, 13, 31, 37, 38, 39, 40, 47, 52]. These researchers have applied traditional complexity metrics to OO systems [52], identified new metrics for OO systems [13, 31, 40, 44, 47], or considered both approaches [37, 38, 39]. The proposed model and measures fall into the last category. Measures that correspond to those identified by these researchers are included in the set of proposed measures. What has been lacking in the previous research is a framework for the organization and investigation of the identified measures. The levels defined in the proposed model specifically address this issue. Work in other areas of OO system measurement includes measures of object reuse [5, 23, 24, 34], measures of OO CASE effectiveness [1, 2], and planning and estimation models [28, 32]. The next section of the paper provides background for the model and measures. The following section presents the model and the set of measures identified for each level. The final section contains a summary and identifies future research directions.

4 2. Background 2.1. Definition of Software Complexity Software complexity measurement is an area of software engineering concerned with the measurement of factors that affect the cost of developing and maintaining software. Zuse [54] states that the term "software complexity" is poorly defined and that software complexity measurement is a misnomer. He offers a definition of software complexity that is consistent with our approach: The true meaning of software complexity is the difficulty to maintain, change and understand software. It deals with the psychological complexity of programs. [54] Three specific types of psychological complexity that affect a programmer's ability to comprehend software have been identified [12, 16]: problem complexity, system design complexity, and procedural complexity. Problem complexity is a function of the problem domain. Simply stated, it is assumed that complex problems are more difficult for a programmer to comprehend than simple problems. Since this type of complexity is impossible to control, it generally is ignored in software engineering. System design complexity addresses the mapping of a problem space into a given representation. Structural complexity and data complexity are the two types of system design complexity defined for structured systems [12]. Structural complexity addresses the concept of coupling. Coupling measures the interdependence of modules of source code, e.g., C functions calling other C functions. It is assumed that the more coupling between modules, the more difficult it is for a programmer to comprehend a given module.

5 Data complexity addresses the concept of cohesion. Cohesion measures the

intradependence of a module. In this case, it is assumed that the more cohesive a module, the easier it is for a programmer to comprehend the module [49]. Structural and data complexity measures are based on the module's fan-in, fan-out, and number of input/output variables [3, 11, 25]. The complexity of a system is based on the sum of the structural and data complexity for all modules in the system [12]. These measures address information system complexity at the system and module levels. This multiple level approach with an emphasis on cohesion and coupling provides a basis in traditional software measurement for the proposed software complexity model of OO systems. Procedural complexity is associated with the logical structure of a program. This

approach to complexity measurement assumes that the length of the program (number of tokens or the lines of code) [22] or the number of logical constructs (sequences, decisions, or loops) [35] that a program contains determines the complexity of the program [12]. In this paper, we address system design complexity for OO systems. 2.2. Desirable Properties of Software Measures Many authors propose desirable properties of measures for effective evaluation of software complexity [18, 35, 53]. We believe two essential properties should be used to create a set of measures of software and designs. First, the measures should be applicable throughout the system development process. Many procedural complexity measures, such as lines of source code, that have an inherent dependence on completing significant portions of the development effort before the measure can be applied ignore potential opportunities to control software

6 complexity in the early phases of the development process. Second, the measures should be intuitive in nature. By intuitive, we mean that analysts, designers, and programmers can agree on the reasonableness of both aggregate and component measures. 2.3. Characteristics of Good OO Systems Design Criteria for a good OO design have been identified using the concepts of coupling, cohesion, reuse, clarity, depth of the generalization-specialization hierarchy, simplicity, and size [15]. Other researchers have identified the need for measures for the evaluation of an object. The measures identified include the concepts of coupling, cohesion, sufficiency, completeness, and primitiveness [7]. Clarity, simplicity, sufficiency, completeness, and primitiveness are

associated with the comparison of a design or software to the problem domain requirements and therefore, problem complexity. It is not clear how they can be measured from available static representations (source code or designs); therefore, we do not address them further. Two types of coupling (interaction and inheritance) and three types of cohesion (service, class, and generalization-specialization) have been identified [15]. In this paper, we propose measures of interaction coupling, inheritance coupling, service cohesion, and class cohesion. Generalization-specialization cohesion requires domain specific knowledge and, therefore, is associated with problem complexity, not system design complexity. In addition, measures of the depth and size of the generalization-specialization hierarchy for an OO system are proposed. Each of these measures can be calculated from the available static representations of an OO system.

7 2.4. Software Design Fundamentals Emphasized by OO Systems OO systems emphasize three software design fundamentals that are useful in controlling software complexity: polymorphism, encapsulation, and inheritance. Each of these is described below. 2.4.1. Polymorphism Polymorphism means having the ability to take several forms. In OO systems,

polymorphism allows the implementation of a given operation to be dependent on the object that "contains" the operation. For example, a "compute-pay" operation can be implemented differently based on the employee's object type, e.g., part-time, hourly, or salaried. When a new type of employee is created, e.g., student, the programmer simply creates a new type of employee object and a new "compute-pay" operation in the new object. The "compute-pay" operations of the other types of employee are not affected by the payment operation implementation required for the new type of employee. This reduces complexity by isolating the effect of changes and providing highly consistent semantics across the interfaces to all employee objects. Thus,

polymorphism is a mechanism that can be used to control the complexity of an OO system. In contrast, structured systems often have all compute pay operations contained in one program. The program must be capable of differentiating between the different types of employees and applying the appropriate operation. Adding new types of employees may require existing code to be changed. The use of polymorphism also can increase the complexity of an OO system [42]. For example, if the "compute-pay" operation in one type of employee object is implemented to print employee descriptive information or some other function, i.e., not compute the pay of the

8 employee, then semantic consistency across the interfaces of the employee objects no longer exists. The programmer may no longer assume that all operations with the same name perform the same generic function. The semantics of each individual implementation of an operation must be determined. This increases the difficulty of understanding the employee objects. When used this way, polymorphism can lead to the same type of software engineering problems created by the unconstrained use of goto statements [42]. The key to controlling an OO system's complexity through the use of polymorphism is to ensure that all operations with the same name are semantically consistent. 2.4.2. Encapsulation (Information Hiding) OO systems integrate both the structural (data) and behavioral (procedural) aspects of a program, while structured systems force an artificial separation of the structure from behavior. According to Brodie and Ridjanovic [9], The separate treatment of structure and behavior complicates design, specification, modification, and semantic integrity analysis. Encapsulation allows programmers to modify the implementation of an object while avoiding the creation of unwanted side effects in other objects by hiding the implementation detail behind a public interface (protocol). This reduces complexity by ensuring that changes to the internal operations of an object, i.e., those that do not modify the public interface, are contained within that object. 2.4.3. Inheritance An inheritance mechanism is considered important due to the potential for reuse. Inheritance allows programmers to define objects incrementally by reusing previously defined objects as the basis for new objects. There have been many different types of inheritance

9 mechanisms associated with OO systems [33]. The most common inheritance mechanisms

include different forms of single and multiple inheritance. Single inheritance allows a subclass to have only a single parent class. The subclass extends the parent's definition. For example, when defining a new type of employee, e.g.,

student, the new employee type can inherit the common characteristics of being an employee from a generic type of employee. Using this approach, the programmer only needs to be

concerned with the difference between student employees and generic employees. Existing programming languages and OO methodologies permit extending the parent's definition including the redefinition of some or all of the parent's properties [8, 14, 21, 27, 29, 36, 41, 45, 51]. With redefinition capabilities, it is possible to introduce an inheritance conflict, i.e., a property of a subclass with the same name as a property of a parent class. Multiple inheritance occurs when a subclass may inherit from more than one parent class. In this situation, the types of inheritance conflicts are multiplied. In addition to the possibility of having an inheritance conflict between the subclass and one (or more) of its parent classes, it is now possible to have conflicts between two (or more) parent classes. Inheritance conflicts increase the difficulty of understanding an inheritance structure and individual objects in the structure. Thus, there is a risk of increasing the complexity of an OO system, instead of

decreasing it, through the use of inheritance. Snyder [48, 49] points out that the underlying cause of the inheritance conflict problem is that most inheritance mechanisms violate encapsulation. For example, when the definition of a superclass is modified, all of its subclasses are affected. This may introduce additional

inheritance conflicts in one (or more) of the superlcass's subclasses. Therefore, programmers

10 must be aware of the effects of the modification not only in the superclass, but in each subclass that inherits the modification. Rumbaugh, et al., [45] suggest the following rules when using inheritance. Query operations should not be redefined; Operations should only be redefined if the overriding operation restricts the semantics of the inherited operation; Redefining operations should never change the protocol or the underlying semantics of the inherited operation;

However, as they point out, "The implementation and use of many existing object-oriented languages violates these principles." [45,p. 65] Thus, inheritance conflicts caused by redefinition capabilities and multiple inheritance mechanisms must be addressed when considering the overall complexity of an individual object or OO system. Another concern related to using inheritance occurs when a subclass does not utilize all of its superclass(es)' properties. It has been suggested that this may indicate a subclass that has been misclassified in the inheritance network [15]. This also demonstrates that the use of

inheritance may work to increase the complexity of an OO system. 2.5. Measures Based on Information Flow and Data Bindings Measures that address system design complexity for structured systems that also are consistent with the characteristics of good OO systems design, the desirable properties of software measures, and the software design fundamentals presented above are based on information flow and data bindings. The measures defined by research on information flow and data bindings include fan-in and fan-out [3, 25], data bindings [26], input/output variables [11], and intra- and inter-module complexity [12].

11 Fan-in is the number of modules that call a module; fan-out is the number of modules that a module calls. It has been stated that the complexity of a structured system is proportional to the number of connections between modules in the system [3, 25], i.e., the higher the coupling of modules in a system the more complex the system. The complexity of a system also has been described as a function of the amount of work that the system's individual modules perform. Data bindings and the number of input/output

variables describe the amount of work an individual module performs [11, 26]. These measures address the cohesion of a module. Card and Agresti [11] state that a system's complexity is best described by combining the above. This combination results in an intra-module (data) and inter-module (structural)

complexity for each module in a system. The overall complexity of a structured system is then defined as the sum of the average complexities (intra- and inter-) of each module. By identifying both module level complexity and system level complexity, the overall amount of complexity can be represented for a given system [12]. 3. Model of Complexity for OO Systems The four level model explicitly addresses the inherent components of OO systems including variables, methods, and objects, as well as the overall system. The proposed measures account for the cohesion (intra-) and coupling (inter-) aspects of the system at each level (see Fig. 1). The combined set measures from all levels results in a representation of OO system software complexity applicable throughout the lifetime of an OO system. Variable level complexity and method level complexity contribute to, i.e., influence by increasing or decreasing, the complexity

12 measured at the object level. Complexity at the object level influences complexity at the system level. 3.1 Levels of Software Complexity for OO Systems Similar to the system and module levels of software complexity defined for structured systems [12], the complexity of OO systems can be represented by a set of measures defined at different levels. For OO systems the variable, method, object, and system levels are necessary. The linear model of system design complexity for structured systems provides support for the existence of a similar model of OO systems complexity. 3.1.1. Definitions of the Levels Variable level complexity is associated with the definition and use of variables throughout the system. Method level complexity is associated with the definition and use of methods throughout the system. Object level complexity combines variable and method complexity with measures of the inheritance structure. System level complexity provides high level

representations of OO system size and organization. Aggregate measures for each level should provide the basis for complexity tradeoffs. However, due to the lack of a theory of OO software construction and evolution, aggregate measures and operational rules for making complexity tradeoffs must be determined empirically [19, 45]. 3.1.2. Justification of the Levels Each level of complexity can be justified from the literature on OO systems, the literature on software measures, and the perceptions of users of OO techniques. The literature of OO systems and software measures was presented in the background sections of this paper (See

13 section 2) and are mentioned only briefly here. The perceptions of users of OO techniques are discussed in more detail. First, many OO analysis and design techniques identify variables, methods, and objects as components of OO systems [7, 14, 15, 45] because each of these concepts is inherent to OO systems. Assuming that some combination of these components is a "system", all four levels are justified from the literature on OO systems. Second, as stated above, previous literature on software measurement provides support for the idea of levels of complexity [11, 12]. This literature also identifies measures of data bindings [26], module cohesion and coupling [3, 25], and summation across structure diagrams [25]. These ideas correspond directly to the variable, method, and object levels of the proposed model. Abstraction of these concepts to the system level is also reasonable based on software measures developed for structured systems [11, 12]. Finally, a study of users of OO techniques perceptions of OO software complexity was undertaken. Seven graduate students in information systems who had completed a course in OO techniques that required analysis, design, and programming participated in the study. The group identified 148 concepts that they believed contributed to the complexity of OO systems. Classification of the 148 concepts by the authors, using a content analysis approach [17, 30], identified 11 concepts that contained a reference to the variable level, 17 concepts that contained a reference to the method level, 41 concepts that contained a reference to the object level, and 13 concepts that contained a reference to the system level. From the 148 concepts the group identified 10 categories that organized the concepts by similarity. The categories were then ranked by their importance to OO system complexity.

14 Group agreement on category importance was moderately-high, Kappa coefficient of concordance K=.70, p=.10. The categories are ranked in order of importance and presented, with their

definitions, in Table 1. Each participant then was asked to place each concept in the category that he or she believed it belonged. High levels of agreement, 6 or 7 participants, existed on 40% (59) of the concepts and most concepts, 80% (118), were placed in the ten categories by 4 or more participants, showing a high degree of face validity. Only 4 of the 148 concepts were not assigned to some category by all participants. The overall K, Kappa coefficient of agreement for all concept categorizations, score is .50 indicating a moderate level agreement about the categorization of the concepts. This result is significantly different from 0 agreement, with a calculated Z=69.23, p < .001. Review of the definitions in Table 1 shows that the class design, structure, method design, and message passing are associated with the static representations of OO systems. The class design and method design categories contain concepts that apply to the variable level; the method design and message passing categories contain concepts that apply to the method level; the class design, message passing, and structure categories contain concepts that apply to the object level; and the structure, class design, and message passing categories contain concepts that apply to the system level. These categories were ranked in the top half of categories on importance to OO system complexity (see Table 1). It should be noted that some categories, (i.e., maintenance, project management, methodology and tools, problem domain, reusability, and solution domain), contain few concepts that apply to the proposed levels. This is an indication that the group perceived OO system complexity as consisting of components that involve all aspects of the development process. The

15 current model involves only those categories that apply to static representations of OO systems, i.e., designs and code. So, the notion of levels of complexity is supported by the literature on OO systems, the literature on software measures, and the perceptions of potential users of OO software complexity measures. 3.1.3. Usefulness of the Levels The model shows relationships that provide the basis for suggesting that a rationale exists for making complexity tradeoffs between levels to rearrange (and thereby reduce) the complexity of an OO system. Complexity tradeoffs involve increasing complexity in one level (or measure) to reduce complexity in another level (or measure). The ability to measure in what part of the system the complexity inherent to a problem exists is essential to controlling the complexity of OO systems and the development of complexity tradeoff criteria. The model provides measures for making two types of complexity tradeoffs throughout the development of an OO system: design and implementation. Design tradeoffs are associated with design decisions of the system. Tradeoffs of this type include manipulating object, variable, and method levels to move complexity from the object level to the variable and method levels (or vice versa), controlling inter-object measures, and determining the number of abstract versus concrete classes at the system level. Decisions to have many classes with few methods and variables or few classes with many methods and variables in each, or to have deep versus broad inheritance structures are examples of design tradeoffs. These tradeoffs affect the measures, which should reflect the complexity of the design representations of OO systems.

16 Implementation tradeoffs occur when coding details are decided. These tradeoffs include controlling intra-object measures. The number of properties to inherit is an example of an implementation complexity tradeoff. Implementation tradeoffs allow control of the complexity of code representations of OO systems. The levels also provide a framework for the classification of measures defined by previous and future research on the software complexity of OO systems. Measures defined by previous research [13, 37, 38, 39] are included at the appropriate levels in the model. 3.1.4. Justification of Measures at the Levels Each measure at each level can be justified from the literature on OO systems, the literature on software measures, and/or the perceptions of complexity held by users of OO techniques. For example, intra- and inter- complexity can be justified in the following ways. First, as stated earlier the concept of encapsulation is important in OO systems. An encapsulation focus results in both an intra- (within the module, i.e., method or object) and interorientation. This is due to "hiding" things inside the method or object (intra-) and allowing communication between methods or objects (inter-) only through message passing with arguments. When combined with the focus on variables, methods, and objects inherent to OO approaches it seems reasonable that an intra- and inter- approach should be applied to the evaluation of the complexity associated with each level. As presented above various concepts of cohesion and coupling have been proposed for OO systems [15]. Software measures have been proposed for OO systems [37, 38, 39] and individual objects [13]. This is additional support for the system and object levels, and for the need of an overall model to aid the investigation of OO system complexity.

17 Second, structural complexity (inter-module complexity) [12] has been identified as an important component of the complexity of a structured system. Fan-in and fan-out, as defined for modules, have been used by several researchers [3, 12, 25] to examine the flow of information through a module. Increases in fan-in and fan-out have been associated with Extension of these ideas to OO systems seems

increases in software complexity [12, 25]. appropriate.

Third, in the study of users perceptions of OO system complexity, 95 of the 148

concepts (64%) were placed in the same category by 5 or more of the 7 participants (71%). That is, the participants agreed that these concepts belonged in one category versus the other categories. This implies that the group had a common understanding of the concept indicating that the concept was important. Of these 95 concepts, 28 were placed in categories associated with the designs and software of an OO system. These concepts from the class design, structure, method design, and message passing categories were mapped to the variable, method, object, and system levels measures by the authors using a content analysis approach [17, 30]. If the concept contained a word or phrase that was also in the definition of the measure, the concept was said to support the measure. This provides additional justification for the measures identified. The mapping is presented in Table 2 and referred to throughout the following discussion of the measures at each level of the model. 3.2. Variable Level Measures for OO Systems Data management and manipulation represent a large percentage of activities required of most information systems. Measures at this level identify an important component of the

software complexity of an OO system, i.e., the amount of use and sharing of data throughout the

18 system. Measures of polymorphism, fan-in, fan-out, and fan-down are defined to describe

complexity at the variable level (see Table 3). Usually polymorphism is not associated with variables. However, the potential for

semantic consistency problems is just as high for variables as it is for methods. A simple technique for counting variable polymorphism is to create a variable polymorphism matrix (VPM). In a VPM the rows are identified by unique variable name without the object name prefix and the columns are identified by the object name. Each cell contains a one if the variable name of the row is defined in the object of the column, otherwise it contains a zero. The sum of the cells in the row is variable polymorphism. If variable polymorphism is greater than one, the variable is polymorphic. The higher the value of this measure the more important it is for developers to ensure that polymorphism is used appropriately, i.e., with semantic consistency. Measures representing the use of the variable by methods and the objects that the variables can reference also are required. These measures consist of the fan-in and fan-out of the variable (see Table 3). Fan-in can be calculated through the creation of the method-to-variable connection matrix (MVCM). In the MVCM the rows are identified by the combination of object name and method name and the columns are identified by the combination of object name and variable name. Each cell of the matrix contains a one if the method of the row accesses the variable of the column. The sum of the cell values down each column is the fan-in of the variable. A simple technique for calculating fan-out is through the creation of a variable-to-object connection matrix (VOCM). In a VOCM, the rows are identified by the combination of object name and variable name. The columns of the VOCM are identified by the objects that make up the system. Each cell of the matrix contains a one if the variable of the row can be assigned

19 a value from the domain of the object of the column. The sum of the cell values across each row results in the fan-out of the variable. Inheritance of a variable requires a programmer to consider those objects that inherit the variable when developing or maintaining method(s) that access the variable contained in those objects. Fan-down can be measured through the creation of a variable inheritance matrix (VIM). Each row of the VIM is identified by the combination of object name and variable name, and each column of the matrix is identified by object name. Each cell of the matrix contains a one if the variable of the row is inherited by the object of the column, otherwise it contains a zero. Fan-down is the sum of the cells across the row of the variable. Other research on the measurement of OO software complexity has not proposed measures of the complexity of variables. This an important component of OO systems that should be part of a comprehensive software complexity model for OO systems. 3.2.1. Effects on Variable Level Cohesion and Coupling The concepts of cohesion and coupling are not normally defined for variables in structured systems. Possibly, due to the focus on the processes that the system must perform. However, measures of this type are important for variables in OO systems due to the prominence of the role of variables in OO analysis and design. For variables, cohesiveness is the degree to which the variable is used for a single purpose. Intravariable complexity (cohesion) is measured by the fan-out, fan-down, and variable polymorphism measures. Furthermore, the complexity captured by all three measures increases intravariable complexity and therefore reduce the amount of cohesiveness of the variable.

20 If two variables are accessed by the same method(s), they are connected. This is a measure of interaction coupling [15]. Intervariable complexity (coupling) for variables is

measured by the fan-in, fan-out, and variable polymorphism measures. The complexity measured by the fan-in and fan-out measures increase intervariable complexity and the variable polymorphism measure decreases intervariable complexity. 3.2.2. Justification of Measures of Variable Level Complexity As stated above the concept of variable level complexity in an OO system seems reasonable. The measures defined for this level should be consistent with those defined at the method and object levels. Encapsulation is important in OO systems and provides support of the intra- (within the module, i.e., method or object) and inter- orientation. First, given the prominence of variables in many OO approaches it seems reasonable that an intra- and inter- approach should be applied to the evaluation of the complexity associated with variables. Furthermore, an increase in the number of methods that use a variable (variable fan-in) should be associated with these constructs. Second, structural complexity (inter-module complexity) [12] has been identified as an important component of the complexity of a structured system. Fan-in and fan-out, as defined for modules, have been used by several researchers [3, 12, 25]. Extension of these ideas to variables in an OO system seems appropriate and straightforward. The number of methods that use a variable (variable fan-in) is very similar to the number of modules that call a module (fanin) and the number of objects that are accessed through a variable (variable fan-out) is similar to the number modules called by a module (fan-out).

21 Third, in the study of users perceptions of OO system complexity one concept (use of class variables) was identified that is associated with variable fan-in and variable fan-out. This shows that users of OO techniques consider the use of variables to be important. The group provided no indication as to whether an increase in the use of class variables increased or decreased the complexity of the system. The participants identified other concepts that apply to measures at the variable level. The measures and concepts are presented in Table 2. 3.3. Method Level Measures for OO Systems All operations performed by the system are implemented as methods. At the method level the measures of method polymorphism, fan-in, fan-out, the number of input/output variables accessed, and fan-down are defined to describe the complexity of a method (see Table 4). The measures are calculated with a set of matrices similar to those presented at the variable level. Method polymorphism is defined and calculated similar to variable polymorphism. If method polymorphism is greater than one then the method is polymorphic. Methods that use other methods in the same object in which the method is defined versus using methods defined in other objects require different programmer actions. This differentiation is important due to the increased amount of effort required by a programmer to use methods that are defined in objects that are not part of the current object. At the minimum, the programmer must obtain the public interface of the object that contains the method, select a message from the interface, and determine what available variables are appropriate arguments for the message. Therefore, it is more difficult to use a method defined outside the current object. This is similar to differentiating between the use of local functions versus shared library functions in traditional

22 systems. This differentiation is not common among measures of structured systems. However, given the extensive nature of and the reuse intended for most OO class libraries, a distinction between these types of messages is appealing. To account for this increase in complexity we rely on the idea that sending a message to another object requires a pointer to that object. The value of this pointer must be contained in a variable; therefore, fan-out at the variable level captures additional complexity involved with sending messages to other objects. The number of input/output variables accessed for OO systems at the method level consists of five parts: the number of arguments passed to the method, the number of messages that return an object to the method, the number of arguments passed to other methods, the number of messages that require the method to return an object, and the number of object variables accessed (see Table 4). These measures can be organized into three groupings: input, output, and object variables. Together these measures represent the flow of information through the method. The input variable grouping is composed of the number of arguments passed to the method as part of an invoking message and the number of messages sent by the method that result in an object being returned. The arguments passed to the method contain the data from the sending method that the receiving method needs to perform the operation for which it was defined. Each of these arguments becomes a local variable within the method providing the basis for calculation and flow of control. In addition to the data passed to the method as part of the message, additional data may be required to complete the operations defined in the method. These data may be obtained by sending messages to another object. The objects returned to the method as a result of these messages also are inputs to the method.

23 To obtain a response from the messages sent, the messages must include the arguments required by the receiving methods. The method sending the message must provide these

arguments. The output variable grouping addresses this need. It is composed of the number of arguments passed by the method as part of a message and the number of messages received by the method that require an object be returned. In addition to the data passed to and returned by the method, variables defined as part of the object can be accessed. With the assumption that the programmer must understand the entire object to modify the methods contained in the object, there is no need to differentiate between inputs and outputs for object variables as the complexity associated with the variable must be overcome only the first time the variable is used or assigned. Like the variable level, the method level also must address the use of inheritance. This is done through the fan-down measure. Fan-down (see Table 4) at the method level is defined and calculated in the same manner as at the variable level. We assume that when a method will be inherited and used by other objects, a programmer must consider those objects when developing or maintaining the method. Other research on the measurement of OO software complexity has proposed procedural complexity measures for methods in OO systems [40], including cyclomatic complexity [35] and lines of code. Viewing methods from a design perspective is an important component of OO systems that should be part of a comprehensive software measurement model of OO systems. 3.3.1. Effects on Method Level Cohesion and Coupling The set of measures defined for intra-method complexity applies to the concept of service cohesion [15]. These measures include an extension of data complexity [12] to OO systems and

24 other measures defined at the method level. The complexity measured by method polymorphism, fan-down, and the number of input/output variables increase the intra-method complexity of the method. This is due to the requirement that the programmer must maintain consistent semantics across the system when polymorphism is used. The effects of changing the current method on objects lower in the object hierarchy and all input/output variables used by the method must be understood. Furthermore, the complexity measured by fan-out decreases intra-method complexity. It reduces intra-method complexity by deferring work to other methods through message passing in the same manner as calling a module defers the work of a module in structured systems. Intramethod complexity incorporates polymorphic characteristics, data access requirements, and the amount of work deferred for a method to create a value for the internal complexity of each method. Connections between methods are established through message-passing. A measure of inter-method complexity consists of the complexity measured by number of input/output variables, fan-in, fan-out, and method polymorphism. An increase in these measures indicates an increase in inter-method complexity. Fan-in and fan-out have greater effects on inter-method complexity than does the number of input/output variables, and method polymorphism has the least effect. Inter-method complexity is a measure of service coupling [15]. A possible measure of service coupling, applied directly from the literature on software measures for structured systems [25], is the product of fan-in and fan-out. However, this calculation does not take into account parameter passing (see Input/Output Variables), polymorphism (method polymorphism), or inheritance (fan-down). {NOTE: another possible measure to consider the effects of

inheritance is Moreau's shortest path to method definition [37, 39]}.

25 3.3.2. Justification of Measures of Method Level Complexity Justifications for the method level measures are similar to those presented for the intraand inter- measures at all levels and for the specific measures at the variable level. However, the use of measures for modules in structured systems as measures for methods in OO systems is even more straight-forward than for variables, i.e., substitute messages for calls. Counting of input and output arguments is also consistent with measures defined for structured systems [11, 12, 26]. Together these measures represent a detailed view of the

complexity of each method in a system. Most method level measures are supported by concepts identified by the perceptions study (see Table 2). This provides additional justification for measures defined at the method level. 3.4. Object Level Measures for OO Systems At the object level measures are defined to account for the complexity of an individual object. These measures are described in six groups: polymorphism, message passing, input/output variables, inheritance structure, inheritance conflicts, and property definitions (see Table 5). The measures are calculated with a set of matrices similar to those presented at the variable level. Each of these object level groupings and measures associated with individual objects, identified by other researchers, are presented below. Polymorphism at the object level is a measure of the extent to which polymorphism has been used within the object. This measure is calculated from the variable polymorphism and the method polymorphism measures defined above. Fan-in, used-by, fan-out, and uses at the object level measure the use of the object and the object's use of other objects through message passing (see Table 5). The fan-in and fan-out

26 measures are identical to the message domain size and the message vocabulary size measures proposed by Moreau [38]. The next category, input/output variables, consists of two groups: input and output. Each group at the object level is computed in a manner similar to the corresponding group at the method level, except that the object is the focus. The number of arguments passed to the object and the number of messages that return an object to the object are the number of input variables. The number of output variables consists of the number of arguments that the object must pass to other objects as part of sending messages and the number of messages received by the object that require an object be returned to a sending object (see Table 5). Together, the number of input/output variables represent the amount of information that flows through the object. The measures of fan-down, fan-up, object-to-root depth, and object-to-leaf depth address the complexity of the inheritance structure (see Table 5). Fan-down and fan-up are identical to the number of descendants in the inheritance lattice and the number of parents in the inheritance lattice measures proposed by Moreau [37]. The number of immediate children measure proposed by Chidamber and Kemerer [13] is similar to fan-down and depth of inheritance tree measures [13, 31] are similar to object-to-root depth and object-to-leaf depth. The effects of inheritance conflicts also are of interest. An inheritance conflict occurs when a method or variable in one object has the same name as a method or variable in a super object. This is called a conflict because the programmer must decide which of the methods or variables to use. This requires additional effort as compared to using methods or variables that have no conflicts. We define two measures that address the two types of inheritance conflicts:

local-to-parent and parent-to-parent (see Table 5).

27 Due to the importance of inheritance in controlling the complexity of an OO system, we also include measures that differentiate between local, inherited, and subclass properties. These measures include the number of properties (variables and methods) defined in the object, the interaction between them, the number of properties that are inherited by the object, inherited properties use of local properties, inherited properties use of other inherited properties, local property use of inherited properties, the number of properties defined in subclasses of the object, subclass properties use of local properties, and local property use of subclass properties. 3.4.1. Effects on Object Level Cohesion and Coupling Cohesion (intra-object complexity) is a function of the object level measures presented in Table 6; coupling (inter-object complexity) is a function of the object level measures

presented in Table 7. The tables show the effect (increases or decreases) that the complexity associated with each measure has on software complexity at the object level. For example, the complexity measured by object polymorphism increases the intra-complexity of an object, but decreases the inter-complexity of an object. Since polymorphism allows multiple properties with the same name, the programmer must ensure that the semantics of the polymorphic properties be essentially the same. The additional work associated with ensuring similar semantics is internal to the object (intra-object). At the same time, due to encapsulation, the programmer does not have to worry about syntactical name conflicts between objects. Therefore, the complexity measured by object polymorphism decreases inter-object complexity. Similar arguments can be made for each of the proposed measures.

28 The measures of local, inherited, and subclass properties provide a basis for the definition of aggregate measures of class cohesion, inheritance coupling, and interaction coupling at the object level. Three measures are representative of class cohesion [15]. The first is the ratio of actual interconnections between local properties and the potential interconnections between local properties, i.e., the number of references by locally defined methods to locally defined properties (variables and methods) to the potential references by locally defined methods to locally defined properties. The higher the value of this ratio, the more tightly coupled the locally defined properties are and thus the more cohesive the individual object. However, this ratio suffers from its lack of ability to identify isolated sets of properties, i.e., it does not address the possibility of having distinct subsets of interconnections between properties in an object. One measure that addresses this problem is lack of cohesion in methods (LCOM) metric [13, 40]. LCOM is based on the number of distinct subsets of interconnections between methods and variables. However, LCOM cannot be used to show how dense the interconnections are between properties, nor does it address the interconnections between different methods. Furthermore, LCOM is unable to "distinguish between the case where each of the methods operates on unique sets of instance variables and the case where only one method operates on a unique set of variables." [13, p.203] A third potential measure for class cohesion is the number of variables and methods that have no references to them. The more isolated properties, the less cohesive the class [15]. Measures of inheritance coupling [15] include fan-up, fan-down, object-to-root depth, and object-to-leaf depth (see Table 5). In addition to these inheritance structure measures, a ratio of the number of actual interconnections between the local properties and the actual number of

29 interconnections between all of the object's properties [local method references to all properties (local, inherited, or subclass) and inherited and subclass method references to local properties] is possible. This ratio has a range of 0 to 1, with 0 indicating high coupling to the inheritance structure. The one exception to this interpretation is if no methods (local, inherited, or subclass) reference any local property. In this case, the ratio is undefined, and a question is raised about the need for the local properties. This ratio also could be viewed as a measure of class cohesion, e.g., at a value of 1 only local methods access local properties and therefore the class is highly cohesive. Interaction coupling [15] at the object level can be measured partially by computing the product of fan-in and fan-out. However, this calculation does not take into account parameter passing (see input/output variables), polymorphism (object polymorphism), or inheritance (fandown or fan-up). One possible way to include inheritance is to use a distance measure, based on where the method is defined (locally or inherited), as a weighting factor. This distance factor could be based on Moreau's shortest path to the method definition metric [37, 39]. 3.4.2. Justification of Measures of Object Level Complexity Justifications for the object level measures are similar to those presented for the intra- and inter- measures at all levels and for the specific measures at the variable and method levels. In addition, the focus of most previous literature on OO software complexity measures has been on objects. The concepts of inherited versus local variables and methods is implied throughout the OO literature [8, 15]. The extension of these concepts to inherited and local referencers, i.e., those methods that use the variables or methods, provides for the definition of the cohesion and

30 coupling ratios defined above. Together these measures represent a detailed view of the Most object level measures are supported by concepts

complexity of each object in a system.

identified by the perceptions study (see Table 2). This provides additional justification for these measures. 3.5. System Level Measures for OO Systems Measures defined at the system level include the number of classes in the system (total, concrete, and abstract), maximum depth and breadth of the object hierarchy, the number of inheritance and uses links in the system, the number of unique messages sent between objects in the system, and the number of methods in the system (see Table 8). All of these measures except the number of concrete classes, the number of abstract classes, the number of unique messages, and the number of methods defined in the system have been identified by Moreau [37]. Chidamber and Kemerer [13] also identified depth of the hierarchy as an important measure of OO systems. We have identified a set of measures of software complexity at the system level that can be derived from the measures identified in Table 8. These include the ratio of abstract classes to concrete classes, the average number of inheritance links per object, the average number of uses links per object, the average number of unique messages sent per object, and the average number of methods per object. We have also identified a set of software complexity measures based on measures identified at the object level. For example, the average inter-method

complexity for the individual methods defined within all objects (average service coupling) and the average inter-object complexity for the individual objects defined within the system (average

31 interaction coupling). We also can look at the average level of inheritance coupling and class cohesion contained in an OO system. 3.5.1. Justification of Measures of System Level Complexity Justifications for the system level measures also are supported by OO literature, software measure literature, and the perceptions of users of OO techniques. Extension of the arguments at the variable, method, and object levels apply at the system level. Together these measures represent an overall view of the complexity of an OO system. Most system level measures are supported by concepts identified by the perceptions study (see Table 2). This provides additional justification for these measures. 4. Concluding Remarks In this paper we presented a model of software complexity of OO systems. The model identified four levels at which OO systems software complexity can be described: variable, method, object, and system. At each level measures were identified which account for the cohesion and coupling aspects of the system at that level. Most measures identified by previous research [13, 37, 38, 39] on the measurement of software complexity are represented in the model. These measures are consistent with the characteristics of good OO design, the desirable properties of software measures, the three software design fundamentals of OO systems, and the perceptions of software complexity. Based on the simplicity and the comprehensiveness of these measures, additional research activities are warranted, i.e., statistical validation of the measures, and the determination of relationships between the measures and between the levels of complexity of an OO system.

32 This research provides a basis for the definition of appropriate aggregate measures and operationalization of complexity tradeoffs between those measures. This includes the

development of the criteria and methodology to guide the tradeoffs of OO system complexity between the levels of the model, the tradeoffs between the measures within the levels, and the development of planning and estimation approaches based on the model. The ultimate goal of this research is to develop a theoretically based software engineering methodology that provides the minimum OO system complexity solution for a given OO system. References: [1] R.D. Banker, R.J. Kauffman, R. Kumar, Output Measurement Metrics in an ObjectOriented Computer Aided Software Engineering (CASE) Environment: Critique, Evaluation and Proposal, in: J.F. Nunamaker, Jr., Ed., Proceedings of the Twenty-Fourth Hawaii International Conference on System Sciences, Vol. III (IEEE Computer Society Press, Jan. 1991; ISBN: 0-8186-2121-4). R.D. Banker, R.J. Kauffman, R. Kumar, An Empirical Test of Object-based Output Measurement Metrics in a Computer Aided Software Engineering (CASE) Environment, Journal of Management Information Systems, Vol. 8 (Winter 1991-92) 127-50. L .A. Belady and C. J. Evangelisti, System Partitioning and its Measure, The Journal of Systems and Software, vol. 2 (1981) 23-29. R. Ben-Haten, Making All Types Typedefed, ACM Sigsoft Software Engineering Notes, vol. 17, no. 2 (Apr 1992) 72-3. J. M. Bieman, Deriving Measures of Software Reuse in Object-Oriented Systems, Technical Report CS-91-112, Department of Computer Science, Colorado State University (July 1991). B. W. Boehm, Software Engineering, IEEE Transactions on Software Engineering, vol. C-25 (Dec. 1976) 1221-1241. G. Booch, Object-Oriented Design with Applications (The Benjamin/Cummings Publishing Company,Redwood City, CA , 1991; ISBN: 0-8053-0091-0). D.L. Brandl, Quality Measures in Design: Finding Problems Before Coding, Sigsoft Software Engineering Notes, vol. 15, no. 1(Jan 1990) 68-72. ACM

[2]

[3]

[4]

[5]

[6]

[7]

[8]

33 [9] M. L. Brodie and D. Ridjanovic, On the Design and Specification of Database Transactions, in: M.L. Brodie, J. Mylopoulos, and J. W. Schmidt, Eds., On Conceptual Modelling: Perspectives from Artificial Intelligence, Databases, and Programming Languages (Springer Verlag, New York, 1984; ISBN: 0-387-90842-0). F.P. Brooks, No Silver Bullets: Essence and Accidents of Software Engineering, Computer, Vol. 20, No. 4 (Apr 1987) 10-19. D. N. Card and W. W. Agresti, Measuring Software Design Complexity, The Journal of Systems and Software, vol. 8 (1988) 185-197. D. N. Card and R. L. Glass, Measuring Software Design Quality (Prentice Hall, Englewood Cliffs, NJ, 1990; ISBN: 0-13-568-593-1). S. R. Chidamber and C.F. Kemerer, Towards a Metrics Suite for Object Oriented Design, in: A. Paepcke, Ed., OOPSLA '91 Conference Proceedings, ACM SigPlan Notices Vol 26, No. 11 (Nov 1991) 197-211. P. Coad and E. Yourdon, Object-Oriented Analysis 2nd Ed. (Yourdon Press, Englewood Cliffs, NJ, 1991; ISBN: 0-13-629981-4). P. Coad and E. Yourdon, Object-Oriented Design (Yourdon Press, Englewood Cliffs, NJ, 1991; ISBN: 0-13-630070-7). S. D. Conte, H. E. Dunsmore and V. Y. Shen, Software Engineering Metrics and Models (The Benjamin/Cummings Publishing Company,Redwood City, CA, 1986; ISBN: 0-80532162-4). C. W. Emory and D. R. Cooper, Business Research Methods, 4th Ed. (Irwin, Homewood, IL, 1991, ISBN: 0-256-09265-6). L.O. Ejiogu, Software Engineering with Formal Metrics (QED Technical Publishing Group, Boston, MA, 1991; ISBN: 0-89435-329-2). N. E. Fenton, Software Metrics: Theory, Tools, and Validation, Software Engineering Journal, Vol. 5, No. 1 (January 1990) 65-84. R.B. Grady, Practical Software Metrics for Project Management and Process Improvement (Prentice Hall, Englewood Cliffs, NJ, 1992; ISBN: 0-13-720384-5). A. Goldberg and D. Robson, Smalltalk-80: The Language (Addison-Wesley, Reading, MA, 1989, isbn: 0-201-13688-0).

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

34 [22] M. H. Halstead, Elements of Software Science (North-Holland, New York, 1977; ISBN: 0-444-00205-7). B. Henderson-Sellers, Some Metrics for Object-Oriented Software Engineering, in: J. Potter, M. Tokoro, and B. Meyer, Eds., TOOLS6 (Prentice-Hall, Englewood Cliffs, NJ, 1991, ISBN: 0-13-926940-1). B. Henderson-Sellers, Managing and Measuring Object-Oriented Information Systems Development, Workshop on Object-Oriented Software Engineering Practice, Denver, CO (Feb 1992). S. M. Henry, and D. G. Kafura, Software Structure Metrics Based on Information Flow, IEEE Transactions on Software Engineering, vol. SE-7 (Sep. 1981) 510-518. D. H. Hutchens and V. R. Basili, System Structure Analysis: Clustering With Data Bindings, IEEE Transactions on Software Engineering, vol. SE-11 (Aug. 1985) 749-575. I. Jacobson, M. Christerson, P. Jonsson, and G.Overgaard, Object-Oriented Software Engineering: A Use Case Driven Approach (ACM Press/Addision-Wesley, Reading, MA, 1992, ISBN: 0-201-54435-0). R. L. Jenson and J.W. Bartley, Parametric Estimation of Programming Effort: An ObjectOriented Model, Journal of Systems Software, vol. 15 (1991) 107-114. S. E. Keene, Object-Oriented Programming in Common Lisp: A Programmer's Guide to CLOS (Addision-Wesley, Reading, MA, 198992, ISBN: 0-201-17589-4). Kerlinger, Foundations of Behavioral Research (Holt, Rinehart, and Winston, New York, NY, 1964, ISBN: 03-085642-8). J. Keyes. New Metrics Needed for New Generation, Software Magazine, Vol. 12, No. 6 ( May 1992) 42-56. L.A. Laranjeira, Software Size Estimation of Object-Oriented Systems, IEEE Transactions on Software Engineering, vol. 16 (May 1990) 510-22. M. Lenzerini, D. Nardi, and M. Simi, Inheritance Hierarchies in Knowledge Representation and Programming Languages (John Wiley and Sons, West Sussex, England, 1991; ISBN: 0-471-92741-4). J.A. Lewis, S.M. Henry, D.G. Kafura, and R.S. Schulman, An Empirical Study of the Object-Oriented Paradigm and Software Reuse, in: A. Paepcke, Ed., OOPSLA '91 Conference Proceedings, ACM SigPlan Notices Vol. 26, No. 11 (Nov 1991) 184-196.

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

35 [35] T. J. McCabe, A Complexity Measure, IEEE Transactions on Software Engineering, vol. SE-2 (Dec. 1976) 308-320. B. Meyer, Eiffel: The Language (Prentice Hall, Englewood Cliffs, NJ, 1991, ISBN: 0-13247925-7). D.R. Moreau, A Programming Environment Evaluation Methodology for Object-Oriented Systems, unpublished Ph. D. Dissertation, University of Southwestern Louisiana (1987). D. R. Moreau and W. D. Dominick, Object-Oriented Graphical Information Systems: Research Plan and Evaluation Metrics, The Journal of Systems and Software, vol. 10 (1989) 23-28. D. R. Moreau and W. D. Dominick, A Programming Environment Evaluation Methodology for Object-Oriented Systems: Part I - The Methodology, Journal of ObjectOriented Programming, vol. 3 (May/Jun. 1990) 38-52. K. L. Morris, Metrics for Object-Oriented Software Development Environments, unpublished Masters Thesis, M.I.T., Cambridge, MA (1988). L. J. Pinson and R. S. Wiener, Objective-C: Object-Oriented Programming Techniques (Addision-Wesley, Reading, MA, 1991, ISBN: 0-201-50828-1). C. Ponder and B. Bush, Polymorphism Considered Harmful, ACM SigPlan Notices, Vol. 27, No. 6 (June 1992) 76-79. C. Rajaraman and M. R. Lyu, A Study of Coupling in C++ Programs, TOOLS8 (In Press) J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen, Object-Oriented Modeling and Design (Prentice Hall, Englewood Cliffs, NJ, 1991; ISBN: 0-13-629481-9). N. F. Schneidewind, Methodology For Validating Software Metrics, IEEE Transactions on Software Engineering, Vol. 18, No. 5, (May 1992) 410-422. S.D. Sheetz, D.P. Tegarden, I. Zigurs, and K.A. Kozar, Group Support Systems: An Application to Cognitive Mapping, University of Colorado, College of Business and Administration, Faculty Working Paper Series 92-05 (June 1992). A. Snyder, Encapsulation and Inheritance in Object-Oriented Programming Languages, in: N. Meyrowitz, Ed., OOPSLA '86 Conference Proceedings, ACM SigPlan Notices, Vol. 21, No. 11 (Nov. 1986) .

[36]

[37]

[38]

[39]

[40]

[41]

[42]

[43] [44]

[45]

[46]

[47]

36 [48] A. Snyder, Inheritance and the Development of Encapsulated Software Components, in: B. Shriver and P. Wegner, Eds., Research Directions in Object-Oriented Programming (The MIT Press, Cambridge, MA, 1987; ISBN: 0-262-19264-0). W. P. Stevens, G. J. Myers, and L. L. Constantine, Structural Design, IBM Systems Journal, vol. 13, no. 2 (Jun. 1976) 113-129. B. Stroustrup, The C++ Programming Language, 2nd Ed. (Addison-Wesley, Reading, MA, 1991; ISBN: 0-201-53992-6). D.A. Taylor, Object-Oriented Technology: A Manager's Guide (Addison-Wesley, Reading, MA, 1990; ISBN: 0-201-56358-4). D. P. Tegarden, S. D. Sheetz, and D. E. Monarchi, The Effectiveness of Traditional Metrics For Object-Oriented Systems, in: J.F. Nunamaker, Jr. and R.H. Sprague, Eds., Proceedings of the Twenty-Fifth Hawaii International Conference on System Sciences, Vol. IV (IEEE Computer Society Press, Jan. 1992; ISBN:0-8186-2435-3). E. Weyuker, Evaluating Software Complexity Measures, IEEE Transactions on Software Engineering, vol. 14 (Sep. 1988) 1357-1365. H. Zuse, Software Complexity Measures and Models (de Gruyter & Co., New York, NY, 1990; ISBN: 0-89925-640-6).

[49]

[50]

[51]

[52]

[53]

[54]

30
FIGURE 1:
MODEL OF SOFTWARE COMPLEXITY OF OBJECT-ORIENTED SYSTEMS

System Level Complexity

Object Level Complexity Intra Inter

Variable Level Complexity Intra Inter

Method Level Complexity Intra Contributes To Inter

31
TABLE 1: Category Name (Code) Class Design (CD)
PERCEPTIONS OF COMPLEXITY CATEGORIES

Definition Encapsulation, intra class complexity, proper placement of methods and attributes, choice of class protocol. Labels or names of attributes and methods. Number of attributes, etc. Use of global variables, polymorphism, or information hiding. Relationships between classes, objects, and instances. The static structure of the system. Includes "a kind of" and "a part of" structures. Constrains within the domain. Clarity of the requirements document. Interpretation of the problem domain, have you covered all the domain. Stability of the problem. How this domain fits into future problem domains. Graphical user interface, programming language, platform (hardware and software), and network. The length of the method in lines of code, number of arguments, and placement of the methods in appropriate classes within the class hierarchy. Dynamic relationships between objects. Communication. Reusing existing stuff in this application. Project management constraints, people management, choice of standards, consistency of conventions, and selection of methodologies and tools. The analysis and design notation, debugging and navigation tools, etc. Testing tools, documentation, general programming tools. Modification after release.

Structure (ST)

Problem Domain (PD)

Solution Domain (SD)

Method Design (MD)

Message Passing (MP)

Reusability (RE) Project Management (PM)

Methodology/Tools (MT)

Maintenance (MA)

32
TABLE 2: Variable Level Variable Polymorphism synonyms in labels for objects, attributes, .... polymorphism and information hiding Variable Fan-in use of class variables Variable Fan-out use of class variables Variable Fan Down class vs instance variables - what to put in each levels of inheritance Intra-variable Complexity not supported Inter-variable Complexity not supported Method Level Method Polymorphism polymorphism and information hiding overloading methods Method Fan In message passing within or between class structures Method Fan Out message passing within or between class structures use of class variables class vs instance variables - what to put in each Method Fan Down overwriting methods overloading methods Arguments Passed to Method number of arguments in a method Objects Returned to Method number of arguments in a method Arguments Passed by Method not supported
MEASURES AND SUPPORTING CONCEPTS

Category Codes Proportion CD MA MP MD MT PD PM RE SD ST Agreement 7 5 6 6 5 1 . . . . . . . 1 . . . . . . . . . . . . . . 2 . . . . 1 . . . . . . . . . . . . . . . . . . . . . . . 1 . . . . . . . . . . . . . . . . 1 1 . 5 . . 1.000 .476 .714 .714 .524 .476 NA NA

Category Codes Proportion CD MA MP MD MT PD PM RE SD ST Agreement 5 1 . . 1 . . . 6 . 5 . 1 . . . . . . . . 1 . . . . . . . 1 .476 .476 .714

. 6 5

. . .

6 . .

. . 2

. . .

. . .

. . .

. . .

. . .

1 1 .

.714 .714 .524

1 1 1 1 .

. 1 . . .

. . . . .

6 5 6 6 .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

.714 .476 .714 .714 NA

33
TABLE 2: Method Level (Cont.) Objects Returned by Method not supported Object Variables Accessed use of class variables class vs instance variables - what to put in each Intra-method Complexity length of methods length of methods-how much does it do? Inter-method Complexity message path length - number of methods to go through to get something done message passing within or between class structures Object Level Object Polymorphism Polymorphism and information hiding Used not supported Uses not supported Object Fan In message passing within or between class structures Object Fan Out message passing within or between class structures Object Fan Down overwriting methods overloading methods horizontal vs vertical organization multiple inheritance - conflict resolution where to put the objects within the hierarchy Object Fan Up overwriting methods overloading methods horizontal vs vertical organization multiple inheritance - conflict resolution where to put the objects within the hierarchy
MEASURES AND SUPPORTING CONCEPTS

(CONT.)

Category Codes Proportion CD MA MP MD MT PD PM RE SD ST Agreement . 6 5 . . . . . . . . 2 . . . . . . . . . . . . . . . . 1 . NA .714 .524

1 1 1 .

. . . .

. . 5 6

6 6 1 .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . 1

.714 .714 .476 .714

Category Codes Proportion CD MA MP MD MT PD PM RE SD ST Agreement 5 . . . . . . . . . . 6 . . . . 1 . . . . . . . . . . . 1 . . . . . . . . . . 1 .476 NA NA .714

.714

1 1 1 . 2

. 1 . . .

. . . . .

6 5 . . .

. . . . .

. . . 1 .

. . . . .

. . . . .

. . . . .

. . 6 6 5

.714 .476 .714 .714 .524

1 1 1 . 2

. 1 . . .

. . . . .

6 5 . . .

. . . . .

. . . 1 .

. . . . .

. . . . .

. . . . .

. . 6 6 5

.714 .476 .714 .714 .524

34
TABLE 2: Object Level (Continued) Arguments Passed to Object not supported Objects Returned to Object not supported Arguments Passed by Object not supported Objects Returned by Object not supported Object to Root Depth depth of class hierarchy Depth of hierarchies levels of inheritance where to put the objects within the hierarchy Object to Leaf Depth depth of class hierarchy Depth of hierarchies levels of inheritance where to put the objects within the hierarchy Local to Parent Conflict overwriting methods Parent to Parent Conflict multiple inheritance - conflict resolution Intra-object Complexity length of the method - short vs long: how much does it do? length of methods low cohesion within a class Inter-object Complexity message path length - number of methods to go through to get something done message passing within or between class structures
MEASURES AND SUPPORTING CONCEPTS

(CONT.)

Category Codes Proportion CD MA MP MD MT PD PM RE SD ST Agreement . . . . 1 1 1 2 . . . . . . 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6 5 5 NA NA NA NA .714 .714 .476 .524

1 1 1 2

. . 1 .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

6 6 5 5

.714 .714 .476 .524

1 .

. .

. .

6 .

. .

. 1

. .

. .

. .

. 6

.714 .714

1 1 5 1 .

. . . . .

. . . 5 6

6 6 1 1 .

. . . . .

. . . . .

. . . . .

. . . . .

. . 1 . .

. . . . 1

.714 .714 .476 .476 .714

35
TABLE 2: System Level Classes not supported Concrete Classes not supported Abstract Classes not supported Max Depth of Inheritance Hierarchy horizontal vs vertical organization of classes depth of class hierarchy Depth of hierarchies levels of inheritance Max Breadth of Inheritance Hierarchy breadth of class hierarchy horizontal vs vertical organization of classes levels of inheritance Inheritance Links breadth of class hierarchy horizontal vs vertical organization of classes levels of inheritance depth of class hierarchy Depth of hierarchies Uses Links following the flow of control message passing within or between class structures Messages following the flow of control message passing within or between class structures Methods number of methods per class Size of Object Classes
MEASURES AND SUPPORTING CONCEPTS

(CONT.)

Category Codes Proportion CD MA MP MD MT PD PM RE SD ST Agreement . . . 1 1 1 1 . . . . . . 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6 6 5 NA NA NA .714 .714 .714 .476

2 1 1 2 1 1 1 1 . .

. . 1 . . 1 . . . .

. . . . . . . . 6 6

. . . . . . . . 1 .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

5 6 5 5 6 5 6 6 . 1

.524 .714 .476 .524 .714 .476 .714 .714 .714 .714

. .

. .

6 6

1 .

. .

. .

. .

. .

. .

. 1

.714 .714

6 6

. .

. .

. .

. .

. .

. .

. .

. .

1 1

.714 .714

36
TABLE 3: Measure Variable Polymorphism Fan-in Fan-out
VARIABLE LEVEL MEASURE DEFINITIONS

Definition The number of objects in which the variable name is defined. The number variable. of methods that access the

The number of different kinds of objects or pointers to objects that can be accessed through the variable. The number variable. subclasses that inherit the

Fan-down

TABLE 4: Measure Method Polymorphism Fan-in Fan-out

METHOD LEVEL MEASURE DEFINITIONS

Definition The number of objects in which a method name is defined. The number of methods that send messages to the method. The number of methods that receive messages from the current method, regardless of where the receiving method is defined.

Input/Output Variables Arguments Passed to Method Arguments Returned to Method The number of arguments passed to the method as part of a message. The number of messages sent by the method that result in an object being returned. The number of arguments passed as part of a message by the method to other methods. The number of messages that the method returns an object to as a result of the method. The number of object variables accessed by the method. The number of subclasses that inherit the method.

Arguments Passed by Method

Objects Returned by Method

Object Variables Accessed Fan-down

37
TABLE 5: Measure Object Polymorphism
OBJECT LEVEL MEASURE DEFINITIONS

Definition The normalized sum of method and variable polymorphism for each method and variable in the object.

Message Passing Used-by Uses Fan-in Fan-out Input/Output Variables Arguments Passed to Object Arguments Returned to Object The number of arguments passed to the object as part of a message. The number of messages sent by the object that result in an object being returned. The number of arguments passed as part of a message by the object to other objects. The number of messages received that require the object to return an object. Inheritance Structure Fan-down The number of objects below the object in the object hierarchy, i.e., number of subclasses. The number of objects above the object in the object hierarchy, i.e. the number of superclasses. The maximum number of levels in the object hierarchy that are above the object. The maximum number of levels in the object hierarchy that are below the object. The number of objects that use the object. The number of objects that are used by the object. The number of unique messages sent from all other objects to the object. The number of unique messages that the object sends to all other objects.

Arguments Passed by Object Objects Returned by Object

Fan-up

Object-to-Root Depth

Object-to-Leaf Depth

Inheritance Conflicts Local-to-Parent Conflicts The number of properties defined in the object which have the same name as an inherited property. The number of properties defined in multiple parents of the object which have the same name.

Parent-to-Parent Conflicts

38
TABLE 6: Measure Object Polymorphism Fan-out Unique Messages Sent Arguments Passed to Object Objects Returned to Object Arguments Passed by Object Objects Returned by Object Fan-down Fan-up Object-to-Root Depth Object-to-Leaf Depth Local-to-Parent Conflict Parent-to-Parent Conflict
OBJECT MEASURE EFFECT ON INTRA-OBJECT COMPLEXITY

(COHESION) Decrease X X

Increase X X X X X

X X X X X X

TABLE 7: Measure

OBJECT MEASURE EFFECTS ON INTER-OBJECT COMPLEXITY

(COUPLING)

Increase

Decrease X X X

Object Polymorphism Fan-in Fan-out Unique Messages Received Unique Messages Sent Arguments Passed to Object Objects Returned to Object Arguments Passed by Object Objects Returned by Object Fan-down Fan-up Object-to-Root Depth Object-to-Leaf Depth Local-to-Parent Conflict Parent-to-Parent Conflict

X X X X X X X X X X X X

39
TABLE 8: Measure Classes Concrete Classes Abstract Classes Max Depth of Inherit Hierarchy Max Breadth of Inherit Hierarchy Inheritance Links Uses Links Messages Methods
SYSTEM LEVEL MEASURE DEFINITIONS

Definition The number of classes in the system. The number of classes that can be instanciated in the system. The total number of classes minus the number of concrete classes in the system. The number of levels from the root(s) of the object inheritance hierarchy to the leaf that is the furthest away. The maximum number of classes at any one level in the object hierarchy. The number of inheritance links in the system. The number of uses links in the system. The number of unique messages sent between objects in the system. The number of methods defined in the system.