A software complexity model of object-oriented systems

Syst0m Decision Support Systems 13 (1995) 241-262 ELSEVIER A software complexity model of object-oriented systems D a v i d P. T e g a r d e n a, * S t e v e n D . S h e e t z b D a v i d E . M o n a r c h i c a The R.B. Pamplin College of Business, Virginia Tech, Blacksburg, VA 24061-0101, USA b Graduate School of Business, University of Colorado, Boulder, CO 80309-0419, USA c Graduate School of Business, University of Colorado, Boulder, CO 80309-0419, USA 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 I. Introduction Among the many claimed benefits of ObjectOriented (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, " T h e complexity of software is an essential property, not an accidental one" [10]. The O O 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 * Corresponding author. 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. (2) To provide a basis for making the cost tradeoffs necessary to reduce costs over the lifetime of the system. 0167-9236/95/$09.50 © 1995 Elsevier Science B.V, All rights reserved SSDI 0167-9236(93)E0045-F 242 D.P. Tegarden et aL / Decision Support Systems 13 (1995) 241-262 System Level Complexity Object Level Complexity Vaziable Level Complexity Method Level Complexity Contributes To 40,47,52]. These researchers have applied traditional complexity metrics to O O systems [52], identified new metrics for O O 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. Fig. 1. Model of software complexity of object-oriented systems. 2. Background We propose a model of the software complexity of O O systems described at four levels: variable, method, object, and system. Fig. 1 shows the levels and the relationships between 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 O O system, and are applicable throughout the lifetime of an O O system. Together the measures provide analysts, designers, and programmers using OO techniques the ability to identify which components of an O O 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 O O systems [11,13,31,37,38,39, 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 D.P. Tegarden et aL / Decision Support Systems 13 (1995) 241-262 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. 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 i n p u t / o u t p u t 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 O O systems. 2.2. Desirable properties o f software measures Many authors propose desirable properties of measures for effective evaluation of software 243 complexity [18,35,53]. We believe two essential properties should be used to c~eate 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 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 o f good O 0 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 O O system are proposed. Each of these measures can be calculated from the available static representations of an OO system. 244 D.P. Tegarden et al. / Decision Support Systems 13 (1995) 241-262 2. 4. Software design fundamentals emphasized by O 0 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. 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.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 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. 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 behaviour. According to Brodie and Ridjanovic [9], The separate treatment of structure and behaviour 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 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 employ- D.P. Tegarden et al. /Decision Support Systems 13 (1995) 241-262 ees. Existing programming languages and O O 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 O O 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 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, " T h e 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. - 245 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 O O 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], inp u t / o u t p u t variables [11], and intra- and intermodule complexity [12]. 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 i n p u t / o u t p u t 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]. 246 D.P. Tegarden et al. / Decision Support Systems 13 (1995) 241-262 3. Model of complexity for O 0 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 measured at the object level. Complexity at the object level influences complexity at the system level. 3.1. Levels of software complexity for O0 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 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. Group agreement on category importance was moder- D.P. Tegarden et al. / Decision Support Systems 13 (1995) 241-262 ately-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. 247 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 solu- Table 1 Perceptions of complexity categories Category name (code) Definition Class design (CD) 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. Structure (ST) Relationships between classes, objects, and instances. The static structure of the system. Includes "a kind of" and "a part of" structures. Problem domain (PD) 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. Solution domain (SD) Graphical user interface, programming language, platform (hardware and software), and network. Method design (MD) The length of the method in lines of code, number of arguments, and placement of the methods in appropriate classes within the class hierarchy. Message passing (MP) Dynamic relationships between objects. Communication. Reusability (RE) Reusing existing stuff in this application. Project management (PM) Project management constraints, people management, choice of standards, consistency of conventions, and selection of methodologies and tools. Methodology/Tools (MT) The analysis and design notation, debugging and navigation tools, etc. Testing tools, documentation, general programming tools. Maintenance (MA) Modification after release. 248 D.P. Tegarden et al. / Decision Support Systems 13 (1995) 241-262 tion 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 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. 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 imple- mentation 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, a n d / o r 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 inter-orientation. 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. 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 increases in software complexity [12,25]. Extension of these ideas to OO systems seems appropriate. Third, in the study of users perceptions of OO system complex- D.P. Tegarden et al. / Decision Support Systems 13 (1995) 241-262 249 Table 2 Measures and supporting concepts VARIABLE LEVEL CATEGORY CODES CD 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 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 MA MP MD PROPORTION MT PD PM RE SD ST AGREEMENT 7 1.000 5 0.476 6 0.714 6 0.714 5 0.524 1 0.476 NA NA 5 1 1 1 0.476 (/.476 0.714 0.714 6 5 0.714 0.524 1 1 0.714 0.476 1 0.714 1 0.714 NA NA 6 5 0.714 0.524 1 1 0.714 0.714 1 0.476 0.714 250 D.tL Tegarden et al. /Decision Support Systems 13 (1995) 241-262 Table 2 (continued) VARIABLE LEVEL CATEGORY CODES CD 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 arguments passed to subject 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 MA MP MD PROPORTION MT PD PM RE SD ST AGREEMENT 0.476 NA NA 0.714 0.714 0.714 0.476 0.714 0.714 0.524 0.714 0.476 0.714 0.714 0.524 NA NA NA NA 1 1 1 2 1 0.714 0.714 0.476 0,524 0.714 0.714 0.476 0.524 0.714 0.714 D.P. Tegarden et al./Decision Support Systems 13 (1995) 241-262 251 Table 2 (continued) VARIABLE LEVEL CATEGORY CODES CD 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 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 MA MP PROPORTION MD MT PD PM RE SD ST AGREEMENT 1 (I.714 1 5 0.714 0.476 1 0.476 0.714 NA NA NA 1 6 0.714 1 1 1 6 6 5 0.714 0.714 0.476 2 1 5 6 0.524 0.714 1 5 0.476 2 1 5 6 0.524 0.714 1 1 1 5 6 6 0.476 0.714 0.714 1 0.714 0.714 1 0.714 0.714 1 1 0.714 0.714 6 6 ity, 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 t h e s e c o n c e p t s b e l o n g e d in o n e c a t e g o r y v e r s u s the other categories. This implies that the group h a d a c o m m o n u n d e r s t a n d i n g of the c o n c e p t indi- D.P. Tegarden et al. / Decision Support Systems 13 (1995) 241-262 252 cating 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 O 0 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 O O system, i.e., the amount of use and sharing of data throughout the system. Measures of polymorphism, fan-in, fan-out, and fandown 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 Table 3 Variable level m e a s u r e definitions Measure Definition Variable polymorphism T h e n u m b e r of objects in which the variable n a m e is defined. Fan-in T h e n u m b e r of methods that access the variable. Fan-out T h e n u m b e r of different kinds of objects or pointers to objects that can be accessed through the variable. Fan-down T h e n u m b e r subclasses that inherit the variable. 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 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 D.P. Tegarden et al. /Decision Support Systems 13 (1995) 241-262 253 of the column, otherwise it contains a zero. Fandown is the sum of the cells across the row of the variable. O t h e r research on the m e a s u r e m e n t of O O software complexity has not p r o p o s e d measures of the complexity of variables. This an i m p o r t a n t c o m p o n e n t of O O systems that should be part of a comprehensive software complexity model for O O systems. of interaction coupling [15]. Intervariable complexity (coupling) for variables is m e a s u r e d by the fan-in, fan-out, and variable polymorphism measures. The complexity m e a s u r e d by the fan-in and fan-out measures increase intervariable complexity and the variable polymorphism measure decreases intervariable complexity. 3.2.1. Effects on uariable leuel cohesion and coupling As stated above the concept of variable level complexity in an O O system seems reasonable. The measures defined for this level should be consistent with those defined at the m e t h o d and object levels. Encapsulation is important in O O systems and provides support of the intra- (within the module, i.e., m e t h o d or object) and interorientation. First, given the p r o m i n e n c e of variables in many O O a p p r o a c h e s it seems reasonable that an intra- and inter-approach should be applied to the evaluation of the complexity associated with variables. F u r t h e r m o r e , 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 c o m p o n e n t of the complexity of a structured system. Fan-in and fan-out, as defined for mod- 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 O O systems due to the p r o m i n e n c e of the role of variables in O O analysis and design. F o r variables, cohesiveness is the degree to which the variable is used for a single purpose. Intravariable complexity (cohesion) is m e a s u r e d by the fan-out, fan-down, and variable polymorphism measures. F u r t h e r m o r e , the complexity c a p t u r e d by all three measures increases intravariable complexity and therefore reduce the amount of cohesiveness of the variable. If two variables are accessed by the same method(s), they are connected. This is a m e a s u r e 3.2.2. Justification o f measures o f t,ariable lez~el complexity Table 4 Method level measure definitions Measure Definition Method polymorphism The number of objects in which a method name is defined. Fan-in The number of methods that send messages to the method. Fan-out The number of methods that receive messages from the current method, regardless of where the receivingmethod is defined. Input/output variables Arguments passed to method The number of arguments passed to the method as part of a message. Arguments returned to method The number of messages sent by the method that result in an object being returned. Arguments passed by method The number of arguments passed as part of a message by the method to other methods. Objects returned by method The number of messages that the method returns an object to as a result of the method. Object variables accessed The number of object variables accessed by the method. Fan-down The number of subclasses that inherit the method. 254 D.P. Tegarden et al. / Decision Support Systems 13 (1995) 241-262 ules, have been used by several researchers [3,12,25]. Extension of these ideas to variables in an O O 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 (fan-in) 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). 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 O 0 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 i n p u t / o u t p u t 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 systems. This differentiation is not common among measures of structured systems. However, given the extensive nature of and the reuse intended for most O O 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 i n p u t / o u t p u t 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. To obtain a response from the messages sent, D.P. Tegardenet al. / Decision Support Systems 13 (1995) 241-262 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 O O 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 other measures defined at the method level. The complexity measured by method polymorphism, fandown, and the number of i n p u t / o u t p u t variables increase the intra-method complexity of the method. This is due to the requirement that the programmer must maintain consistent semantics 255 across the system when polymorphism is used. The effects of changing the current method on objects lower in the object hierarchy and all inp u t / o u t p u t 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. Intra-method 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 intermethod complexity consists of the complexity measured by number of i n p u t / o u t p u t 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 i n p u t / o u t p u t 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 I n p u t / O u t p u t Variables), polymorphism (method polymorphism), or inheritance (fan-down). 1 3.3.2. Justification of measures of method level complexity Justifications for the method level measures are similar to those presented for the intra- and 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 1 Another possible measure to consider the effects of inheritance is Moreau's shortest path to method definition [37,39]. 256 D.P. Tegarden et al. /Decision Support Systems 13 (1995) 241-262 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 O 0 systems At the object level measures are defined to account for the complexity of an individual ob- ject. These measures are described in six groups: polymorphism, message passing, i n p u t / o u t p u t 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 ob- Table 5 Object level measure definitions Measure Definition Object polymorphism The normalized sum of method and variable polymorphism for each method and variable in the object. Message passing Used-by The number of objects that use the object. Uses The number of objects that are used by the object. Fan-in The number of unique messages sent from all other objects to the object. Fan-out The number of unique messages that the object sends to all other objects. Input/output variables Arguments passed to object The number of arguments passed to the object as part of a message. Arguments returned to object The number of messages sent by the object that result in an object being returned. Arguments passed by object The number of arguments passed as part of a message by the object to other objects. Objects returned by object 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. Fan-up The number of objects above the object in the object hierarchy, i.e. the number of superclasses. Object-to-root depth The maximum number of levels in the object hierarchy that are above the object. Object-to-leaf depth The maximum number of levels in the object hierarchy that are below the object. Inheritance conflicts Local-to-parent conflicts The number of properties defined in the object which have the same name as an inherited property. Parent-to-parent conflicts The number of properties defined in multiple parents of the object which have the same name. D.P. Tegardenet al. /Decision Support Systems 13 (1995) 241-262 ject's use of other objects through message passing (see Table 5). The fan-in and fan-out measures are identical to the message domain size and the message vocabulary size measures proposed by M o r e a u [38]. The next category, i n p u t / o u t p u t variables, consists of two groups: input and output. Each group at the object level is computed in a m a n n e r similar to the corresponding group at the method level, except that the object is the focus. The n u m b e r of arguments passed to the object and the n u m b e r of messages that return an object to the object are the n u m b e r 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 n u m b e r of i n p u t / output variables represent the amount of information that flows through the object. The measures of fan-down, fan-up, object-toroot 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 n u m b e r of parents in the inheritance lattice measures proposed by Moreau [37]. The number of immediate children measure proposed by Chidamber and K e m e r e r [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 p r o g r a m m e r must decide which of the methods or variables to use. This requires additional effort as c o m p a r e d 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). Due to the importance of inheritance in controlling the complexity of an O O system, we also include measures that differentiate between local, inherited, and subclass properties. These 257 Table 6 Object measure effect on intra-object complexity(cohesion) Measure Increase Decrease Object polymorphism X Fan-out X Unique messages sent X Arguments passed to object X Objects returned to object X Arguments passed by object X Objects returned by object X Fan-down X Fan-up X Object-to-root depth X Object-to-leaf depth X Local-to-parent conflict X Parent-to-parent conflict X measures include the number of properties (variables and methods) defined in the object, the interaction between them, the n u m b e r 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 p r o g r a m m e r 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 p r o g r a m m e r does not have to worry about syntactical name conflicts between objects. Therefore, the complexity measured by 258 D.P. Tegardenet al. / Decision Support Systems 13 (1995) 241-262 Table 7 Object measure effects on inter-object complexity(coupling) Measure Increase Decrease Object polymorphism X Fan-in X Fan-out X Unique messages received X Unique messagessent X Arguments passed to object X Objects returned to object X Arguments passed by object X Objects Returned by Object X Fan-down X Fan-up X Object-to-rootdepth X Object-to-leafdepth X Local-to-parentconflict X Parent-to-parent conflict X object polymorphism decreases inter-object complexity. Similar arguments can be made for each of the proposed measures. 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]. L c o M 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 inter- connections 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 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 i n p u t / o u t p u t variables), polymorphism (object polymorphism), or inheritance (fan-down 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 o f measures o f object level complexity Justifications for the object level measures are similar to those presented for the intra- and D.P. Tegarden et al. /Decision Support Systems 13 (1995) 241-262 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 O O software complexity measures has been on objects. The concepts of inherited versus local variables and methods is implied throughout the O O 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 coupling ratios defined above. Together these measures represent a detailed view of the complexity of each object in a system. Most object level measures are supported by concepts identified by the perceptions study (see Table 2). This provides additional justification for these measures. 3.5. System level measures for O 0 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, 259 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 O O 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 interaction coupling). We also can look at the average level of inheritance coupling and class cohesion contained in an O O system. 3.5.1. Justification o f measures o f system level complexity Justifications for the system level measures also are supported by O O literature, software measure literature, and the perceptions of users Table 8 System level measure definitions Measure Definition Classes The number of classes in the system. Concrete classes The number of classes that can be instantiated in the system. Abstract classes The total number of classes minus the number of concrete classes in the system. Max depth of inherit hierarchy The number of levels from the root(s) of the object inheritance hierarchy to the leaf that is the furthest away. Max breadth of inherit hierarchy The maximum number of classes at any one level in the object hierarchy. Inheritance links The number of inheritance links in the system. Uses links The number of uses links in the system. Messages The number of unique messages sent between objects in the system. Methods The number of methods defined in the system. 260 D.P. Tegarden et al. / Decision Support Systems 13 (1995) 241-262 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. 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 Object-Oriented 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). [2] 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. [3] L.A. Belady and C.J. Evangelisti, System Partitioning and its Measure, The Journal of Systems and Software, vol. 2 (1981) 23-29. [4] R. Ben-Haten, Making All Types Typedefed, ACM Sigsoft Software Engineering Notes, vol. 17, no. 2 (Apr 1992) 72-3. [5] 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). [6] B.W. Boehm, Software Engineering, IEEE Transactions on Software Engineering, vol. C-25 (Dec. 1976) 12211241. [7] G. Booch, Object-Oriented Design with Applications (The Benjamin/Cummings Publishing Company, Redwood City, CA, 1991; ISBN: 0-8053-0091-0). [8] D.L. Brandl, Quality Measures in Design: Finding Problems Before Coding, ACM Sigsoft Software Engineering Notes, vol. 15, no. l(Jan 1990) 68-72. [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). [10] F.P. Brooks, No Silver Bullets: Essence and Accidents of Software Engineering, Computer, Vol. 20, No. 4 (Apr 1987) 10-19. [11] D.N. Card and W.W. Agresti, Measuring Software Design Complexity, The Journal of Systems and Software, vol. 8 (1988) 185-197. [12] D.N. Card and R.L. Glass, Measuring Software Design Quality (Prentice Hall, Englewood Cliffs, NJ, 1990; ISBN: 0-13-568-593-1). [13] 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. [14] P. Coad and E. Yourdon, Object-Oriented Analysis 2nd Ed. (Yourdon Press, Englewood Cliffs, NJ, 1991; ISBN: 0-13-629981-4). [15] P. Coad and E. Yourdon, Object-Oriented Design D.P. Tegarden et al. /Decision Support Systems 13 (1995) 241-262 [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] (Yourdon Press, Englewood Cliffs, NJ, 1991; ISBN: 0-13630070-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-8053-2162-4). C.W. Emory and D.R. Cooper, Business Research Methods, 4th Ed. (Irwin, Homewood, IL, 1991, ISBN: 0-25609265-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-20113688-0). M.H. Halstead, Elements of Software Science (NorthHolland, 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, N J, 1991, ISBN: 0-13-926940-1). B. Henderson-Sellers, Managing and Measuring ObjectOriented 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/Addison-Wesley, Reading, MA, 1992, ISBN: 0-201-54435-0). R.L. Jenson and J.W. Bartley, Parametric Estimation of Programming Effort: An Object-Oriented 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 (Addison-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 Hierar- [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] 261 chies 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. T.J. McCabe, A Complexity Measure, 1EEE Transactions on Software Engineering, vol. SE-2 (Dec. 1976) 308-320. B. Meyer, Eiffel: The Language (Prentice Hall, Englewood Cliffs, NJ, 1991, ISBN: 0-13-247925-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 (Addison-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 Modelling and Design (Prentice Hall, Englewood Cliffs, NJ, 1991; ISBN: 0-13629481-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). 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). 262 D.P. Tegarden et al. /Decision Support Systems 13 (1995) 241-262 [49] W.P. Stevens, G.J. Myers, and L.L. Constantine, Structural Design, IBM Systems Journal, vol. 13, no. 2 (Jun. 1976) 113-129. [50] B. Stroustrup, The C + + Programming Language, 2nd Ed. (Addison-Wesley, Reading, MA, 1991; ISBN: 0-20153992-6). [51] D.A. Taylor, Object-Oriented Technology: A Manager's Guide (Addison-Wesley, Reading, MA, 1990; ISBN: 0201-56358-4). [52] 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). [53] E. Weyuker, Evaluating Software Complexity Measures, IEEE Transactions on Software Engineering, vol. 14 (Sep. 1988) 1357-1365. [54] H. Zuse, Software Complexity Measures and Models (de Gruyter and Co., New York, NY, 1990; ISBN: 0-89925640-6).