(COSTAGLIOLA ET AL: CLASS POINT: AN APPROACH FOR THE SIZE ESTIMATION OF OSJECT-ORIENTED SYSTEMS ss Object Point count is very similar to FP, but objects are taken as the basis of the counting process. However, such objects are not directly elated to “objects” in the OO methodology, bbut rather refer to screens, reports, or 3GL modules. Fetcke et al. propose a method based on rules which map use case ‘models in the Jacobson OOSE method to concepts of FPA [30]. Their proposal is based on the standard FPA defined in the IFPUG Counting Practices Manual (IFPUG 1994), and is described through three industrial case studies that adopted the OOSE approach. Predictive Object Points (POPS) represent another system- level measure for effort prediction, which adopts a counting scheme analogous to FPs. It was proposed by Minkiewicz as 2 suitable combination of well-known OO measures [57] POPs counting is based on the WMC measure applied to top level classes, and combines such information with the average depth of the inheritance tree and the average NOC. In order to compute the WMC value, each method is ‘weighted by a complexity determined by the type of method (constructor, destructor, modifier, selector, itera- tor), by the number of properties the method affects and the number of serviees it provides to the system. As pointed out by the author, detailed information required by the POP counting for determining complexity of methods is not available in early stages of the software development process. As a solution, he proposes to approximate such values on the basis of the available information. Closely related to the POP approach, is the method! proposed forthe definition of Object-oriented’ Function Paints (OFPs) in (3). ‘The method is characterized by a mapping of FP concepts (ogical files and transactions) to OO concepts (classes and methods), and by a flexible method for handling specific (00 concepts like inheritance and aggregation. With respect to Minkiewice’s approach, the complexity of methods is determined only by the information contained in their signatures. In particular, data referenced in it are counted and classified as simple items or complex items, depending fon whether they refer to elementary data types or class types. Then, the complexity level of each method is determined by exploiting the IFPUG tables for transactions and by considering simple and complex items as DET and TR elements of traditional FP. Similarly, the complexity of cach clas is classified as low, average or high using [EPUG standard tables for logical files 3 THE CLass Point APPROACH In this section, we present the Class Point approach, which provides a system-level estimation of the size of OO products. It has been conceived by recasting the ideas tunderlying the FP analysis within the OO paradigm and by suitably: combining well-known OO measures. The basic ideas of the Class Poixt method were frst proposed in [26], and later refined giving rise to the definition of two measures, CP, and CP;, which are presented in what follows. Indeed, the aim of the proposed approach is to provide a method which allows us to refine estimates throughout the development and to exploit new informa- tion as it is available. As a matter of fac, the CP; measure was conceived to provide an initial size estimation at the beginning of the development process. Such an estimation TABLE 1 ‘The Class Point Method 1. Information processing size estimation: asidentification and classification of classes be evaluation of complexity level of each class ceestimation of the Total Unadjusted Class Point 2. Technical complexity factor estimation 3. Final Class Point evaluation ‘can be further detailed by applying CP:, whose computa tion requires data that are usually available later in the development process. As opposed to the other adaptations of FP, when conceiving the Class Point approach as an extension of F, we decided against using one-to-one mappings from FP logical files and transactions to classes and methods, respectively. In the procedural paradigm, data and opera- tions are indeed separate from each other. However, in the 00 paradigm, operations are tightly related to the data they manipulate and are therefore embedded in the concept of a class. Asa consequence, the Class Point! method is especially. focussed on classes, which are the entities the method should count and weigh on the basis of their complexity levels, as was the case for functions in FPA. The complexity Tevel of each class is derived from the information about the local methods in the class, about the interaction of the class with the rest of the system, and, when available, about the attributes. Moreover, while the classification of data function types and transaction function types in FPA was especially conceived for business applications, the categor~ ization of classes in the Class Point measures is independent ‘of any application typology. To some extent, our approach, is similar to POP counting, with the main difference lying in the fact that we distinguish among categories of classes, rather than classifying methods. Another point of distine- tion with respect to POPs is that data are also taken into account in the Class Point measures, and the information needed to perform the counting is usually available at the design phase rather than being replaced by estimated values. In Section 3.1, we describe the Class Point approach which underlies the estimation of the CP; and CPs measures. In Section 3.2, we describe the process that led to the definition of the proposed measures, 3.1 The Class Point Method ‘The process of Class Point size estimation is composed of three main phases, corresponding to analogous phases in the FP approach. A sketch of the method is shown in Table 1. 3.1.1 Identification and Classification of User Classes During the first step of the Class Point counting, the design specifications are analyzed in order to identify and classify the classes. Generally, four types of system components canPy IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL 31, No.1, JANUARY 2008 TABLE 2 Evaluating the Complexity Level ofa Class for CP, [Link] 53-8NEM >9NEM [Link] Low Low Average 2-3NSR Low Average High 2ANSR Average High High be distinguished, namely the problem domain type (PD), the human interaction type (HIT), the data management type (DMT), and the task management type (TMT). The PDT component contains clases representing, real-world entities in the application domain of the system. ‘Thus, taking as an example a distributed information system for accident management as described in [19], typical PDT classes are Incident, FeldOfier, and EmergencyReport. The classes of HIT type are designed to satisfy the need for information visualization and huaman-compaiter interaction, With regard to the previous example, the classes Emegen eyReportForm and. ReporiEmergencyButton belong, to this type. The DMT component encompasses the classes that offer functionality for data storage and retrieval. In the example, a. DMT. component isthe Incident Management Subsystem containing classes responsible for issuing SOL {queries in order to store and retrieve records representing Incidents in the database. Finally, TMT classes are designed for task management purposes, thus they are responsible for the definition and control of tasks such as. Manage- EmergencyControl and. ReportEmergencyContrl. Moreover, such component also includes classes responsible for the Communication betvreen subsystems allocated to diferent computers, and classes responsible forthe communication with external systems. As a matter of fact, Message and Connection are typical classes falling within this component. “The above classification was fist suggested by Coad and [Nicola in order to facilitate the modification and the reuse of classes [22]. However, such class typologies can be detected in any OO system, independently of the applica- tion domain and of the design methodology adopted (eg, 12) 18) (22,123) 137), [66 3.1.2 Evaluation of a Class Complexity Level In the Class Point approach, the behavior of each class ‘component is taken into account in order to evaluate its complexity level. The difference between the CP, and CP; ‘measures lies in the way such a complexity level is determined. In particular, in CP; the number of extemal methods and the number of services requested are taken into account; whereas, in CPs, the number of attributes is, also exploited. ‘The Number of External Methods (NEM) measures the size of the interface of a class and is determined by the number of locally defined public methods. The Number of Services Requested (NSR) provides a measure of the interconnection ‘of system components, Its again applicable toa single class. and is determined by the number of different services requested from other classes, Both measures are available in. design documentation. Indeed, activities that characterize any OO design process include the identification of the classes with their attributes and methods, and the construc tion of interaction (or collaboration) diagrams. showing which external services are needed for a class to perform the expected tasks [67]. A measure similar to NSR- was proposed by Li and Henry. Such a measure, named Message Passing Coupling (MPC), was introduced in [50], [51] to measure the interdependence among classes determined by the number of messages sent by each class. Compared to ‘MPC, the NSR counting, requires less detail and can be performed during analysis and early design. As for CF%, the complexity level of a class is assigned based on the NSR and NEM range values according to Table 2. Each class is then weighted in agreement with its type and ts level of complexity. For example, if a class has more than nine NEM and the NSR value is not less than 2, it is assigned a high complexity level. The rationale behind Table 2 will be made clear in Section 3.2 ‘When computing CP;, the number of attributes is also taken into account in order to evaluate the complexity level of a. class, Thus, in CP, the measure NOA has been considered as an additional parameter giving rise to Tables 3a, 3b, and 3c. Each table is related to a fixed NSR range and indexed on NEM and NOA. 3.1.3 Estimating the Total Unadjusted Class Point ‘Once the complexity level of each identified class has been established, we are ready to compute the Total Unadjusted Class Point value (TUCP). To this aim one needs to fll in the TUCP table (see Table 4). Fach entry in the table expresses the weighted number of classes whose typology and complexity level are given by the corresponding row and column, respectively. ‘Thus, the TUCP is computed as the weighted total of the four components of the application where 21 is the number of classes of component type i (problem domain, human interaction, etc.) with complexity level j (low, average, or high), and w,; is the weighting value for type i and complexity level j. 3.1.4 Technical Complexity Factor Estimation ‘The Technical Complexity Factor (TCF) is determined by assigning the degree of influence (ranging from 0) to 5) that 18 general system characteristics have on the application,(COSTAGLIOLA ET AL: CLASS POINT: AN APPROACH FOR THE SIZE ESTIMATION OF OSJECT-ORIENTED SYSTEMS o TABLE 3 CP, Evaluation of the Complexity Level of a Cass [Link] 0-SNOA 6-9 NOA > 10 NOA [Link] Low. Low Average 5-8NEM Low Average High >9NEM Average High High 5 [Link] [Link] 5-8NOA 29NOA 0-3. NEM Low Low Average 4-7NEM Low Average High >[Link] Average High High © SSNSR [Link] [Link] =8NOA [Link] Low Low Average 3-6NEM Low Average High >[Link] Average High High © TABLE 4 Evaluating the TUCP System Component Type | Description PDT | Problem Domain | Tir Toman Tneraction DMT Data Management TMT Task Management TUCP Total Unadjusted Class Point from the designer's point of view. The estimates given for the degrees of influence are recorded in the Processing Complexity table illustrated in Fig. 1. The sum of the influence degrees related to such general system character istics forms the Total Degree of Influence (TDI), which is used to determine the TCF according to the following formula: TCF = 059 + (001'TD)). ‘The final value of the Adjusted Class Point (CP) is obtained by multiplying the Total Unadjusted Class Point value by TCF op= VCP'TCF. The CP count can vary with respect to the unadjusted count from ~45 percent (corresponding to a null TD) to +45 percent (corresponding to all degrees set to 5), due to the adjustment factor. A Class Point calculation worksheet ig. 6) is shown in the Appendix. It is worth noting that the Technical Complexity Factor is determined by taking into account the characteristics that are considered in the FP method and some additional characteristics especially conceived for object-oriented systems, namely: 15, User Adaptivity 16, Rapid Prototyping, 17, Multiuser Interactivity 18, Multiple Interfaces ‘The introduction of the above additional characteristics hasbeen motivated by the observation that object-orientation,ss IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL 31, No.1, JANUARY 2008 1D __| System Character D1_|_1_| system Characterist DI C1 | Data Communication C10 | Reusabitity c2__| Distributed Functions C11 | Installation ease €3__ | Performance C12 | Operational ease C4 | Heavily used configuration C13 | Multiple sites ha C5 | Transaction rate w= | C14 | Facilitation of change Ga C6 | Online data entry C15 | User Adaptivity ca C7 | End-user efficiency C16 | Rapid Prototyping cn c8__| Online update ve | C17 | Multiuser Interactivity = c9_| Complex processing C18 | Muttipte interfaces sss TDI ‘Total Degree of Influence ees = DIValues: * Not present or no influence * Insignificant influence + Moderate influence Fig, 1. The Processing Complexity table. represents the most appropriate paradigm for the develop- ment of effective graphical user interfaces (GUIs). Itis widely recognized that the components of a graphical user interface are better represented by objects and their direct manipula- tion is naturally supported [53]. Also, an OO user interface is, easier to connect with an application that is designed and implemented in an OO manner and the reuse of software components is facilitated, In spite of the availability of powerful and useful object- ‘oriented tools for building interactive graphical applications 11), 201, (37), (39, [47], [48], [53], [63], the development of these modern interfaces often requires the major part of software project resources due to the costs of their design, implementation, debugging and modification [62], [63} ‘Thus, the use of a good size estimation is strongly recommenced for an appropriate planning of the inter~ active software project development. Table 5 contains the guidelines that should help to determine the influence degree of each of the introduced factors, 3.2 The Class Point Definition—An Expert-Based Process In this section, we describe the process that has led us to the definition of the Class Point measures. It has been supported by the judgments of a group of 12 engineers with experience in the development of interactive OO applications, who joined us in several discussions. Concerning the complexity level of a class, we have ‘observed that the class behavior can be characterized in terms of its methods, its attributes, and its interaction with other classes. Such consideration was also supported by an analysis of Bunge's ontology. In recent years, much interest thas been devoted to the application of such an ontology in. ‘Average influence Significant influence =3 4 Strong influence, throughout = 5 the context of objectorientaion [21]. As a matter of fact, Bunge's properties provide the basis forthe notion of object and are concerned with meaning and definition of representations of the world. These representations consist cof concepts and things, named substantial individuals, each characterized by certain inherent properties. This leads to the definition of an abject as a substantial individual with its finite collection of propestes viewed as a whole. In terms of objectorientation, the set of properties of an object corresponds to the set of methods and instance variables assigned to it The object itself is viewed as a representation ‘of the application domain that includes its properties. For ‘our purposes, special attention has been put on Bunge's definition of the complexity of an objec as the “numerosity ‘ofits composition.” Inthe context of objec-orientation, this concept corresponds to the complexity of an object class, which can therefore be defined as the number of properties attached to the class. Chidamber and Kemerer exploited the previous definition of object complexity in order to define their WMC measure. Nevertheless, in their interpretation of Bunge's definition, the properties of a class that actually contribute to its complexity are methods. They decided not to consider attributes in the complexity evaluation, arguing that these are less time consuming than methods. However, ‘our viewpoint is that two classes having the same number fof methods and different numbers of attributes cannot be equally time consuming. Still, being aware that the attributes of a class may not be available in early design, in the CP; measure such information is not considered for determining the complexity level. On the contrary, the evaluation of the complexity level in the CP; measure does exploit the number of attributes to get a more accurate estimation, when such information is available.(COSTAGLIOLA ET AL: CLASS POINT: AN APPROACH FOR THE SIZE ESTIMATION OF OSJECT-ORIENTED SYSTEMS so TABLE 5 Guidelines to Determine the Influence Degree of the Introduced Factors Adapivag ‘0~ No adapiivity capability required forthe given application, 1. The system should be able to adjust the form of output in response to a change in input. The system’ should have a limited variety of behaviors. 2. The system should be able to have a dialogue record, which allows it to respond to sequences of stimuli rather than just individual input. 3- The system should be able to have a dialogue record, which allows it to adapt in response toa history of} the interaction 4 The system should be able to monitor the effects of the adaptation on the subsequent interaction and evaluate this through trial and erro, by selecting from a range of possible outputs for any given input 5 The system should have inference mechanisms to abstract from the dialogue record and capture a design| or intentional interpretation of the interaction. ‘Rapid Protonyping ‘0— No prototyping is required forthe given application 1 — Paper mock-ups are required to realize Scenario tests 2~ A user interface prototype is required, which presents an interface for some use cases, with no] Tunctionalty, to realize a usability tes. 3 ~ A user interface prototype is required, which presents an interface for most use cases, with no] Tunctionality, to realize a usability tes 4—A functional prototype, implementing key aspects of the system, is required to receive feedback from end-users. 5— A functional prototype, implementing key aspects ofthe system, is required to receive feedback from] end-users. The modified version will be resubmitted to users’ validation ‘Multiple ‘A score for each of the following items Interfaces . ‘A lexical customization i required, where user can only adjust the position of some widgets on the! sereen or redefine command names. The structure of the interaction is unchanged. Different interfaces for novice and experienced users are required, Different interfaces are required based on users’ cultural, educational, and employment background. Accessible interfaces are required to cope with different types of disabilities Different interaction platforms have to be considered. Multiuser ‘A score for each of the following items Interactivity | ‘The system should provide replicated windows on multiple workstations. Heterogeneous hardware environments should be considered ‘The system should provide simple control ofthe order of interaction among users. ‘The system should provide control ofthe simultanety of interaction among users. ‘The system should provide sophisticated process synchronization and control of the order and! simultaneity of interaction among users. 1. The guidelines fr adaptivity have been inspired by the taxonomy of adaptive systems suggested in [65]. “Major objects of discussion with OO engineers have been the assignment of the weights 1; involved in the computa- tion of the Total Unadjusted Class Point value (TUCP), and the definition of the Technical Complexity Factor. Each engineer was asked to estimate the weights of the three complexity levels for each component type. The process started from four triplets of weights we submitted to the engineers. Such initial values were determined by analyzing effort information about several classes of each, typology and assigning a weight to each class based on that information. For each typology, we first averaged the assigned weights, and then averaged all the weights below the resulting value, and all the weights above, so as to have initial low, average, and high weights. Engineers analyzed those values and their own adjustments were compared and discussed until consensus was reached, resulting in the ‘weights shown in Table 4. ‘AS for the Technical Complexity Factor, while retaining the original 14 factors of Function Point analysis, we indicated three additional factors to be included for interactive applications, namely, User Adaptivity, Rapid Prototyping, and Multiple Interfaces, Indeed, the user-centered approach, that should be adopted in the GUI design process naturally requires that much of the development effort is devoted to achieve a high degree of usability of the interface in order to meet user's needs and preferences. Therefore, it is widely recognized that prototyping is essential for GUI develop- ment. Users should be able to experiment with the prototype and provide feedback to improve the design. Further effort could also be necessary to provide the interface with user adaptivity capabilities and to design multiple interfaces to the same application. This might be required to allow the user to choose the type of interaction that best suits his/her needs, experience, and capabilites. ‘The engineers were asked to express their opinions on the proposed factors, They confirmed that the presence of such factors could considerably affect the development cffort of an interactive application. Moreover, during the discussions with the subjects, an additional factor, ‘Multiuser Interactivity, was identified. Such a proposal ‘originated from the observation that during the creation of a multiuser interface several specific issues must be« IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL 31, addressed in order to enable users to simultaneously interact with a common user interface. These involve process synchronization, replicated window management, ‘multiuser event handling, etc. [47]. Our proposal of the additional factors has also been encouraged by general considerations about the genesis and evolution of the Technical Complexity Factor in Function Point counting. In the original definition of the method, Albrecht proposed 10 application characteristics for general systems, for a maximum value adjustment factor of 25 percent. The refinement of the model suggested in 1983 considers 14 application general systems characteristics, for a max- imum value adjustment factor of 35 percent, which corresponds to the standardized version of the counting, However, in the literature different opinions have been expressed on the Technical Complexity Factor [38}, [40], [43], {46}, [68]. In particular, the empirical analysis performed by Kemerer revealed that the application of the Processing Complexity Factor to the raw Function Point measure can have little impact on the performance of Function Points in the cost estimation process [43]. Similar conclusions were drawn by Jefferey et al, starting from a comparative analysis of FP counting and the variation proposed by Jones in [40]. Indeed, in [38], they deduced that further investigation is needed to determine whether other factors should be included, or whether the original factors should be replaced with other environment variables. Analogous issues were addressed by Symons, who argued that “The restriction to 14 factors seems unlikely to be satisfactory for all time. Other factors may be suggested now, and others ‘will surely arise in the future. A more open-ended approach seems desirable [68].” We especially agree with the latter opinion and suggest the above factors as the most appropriate to adequately perform Class Point counting ‘when dealing with OO interactive applications. 4 THEORETICAL VALIDATION Several measures have been defined so far in order to ‘measure internal atributes of software systems. However, a software measure can be acceptable and effectively usable only if its usefulness has been proven by means of a validation process. The aim of such a process is to show that {a measure really measures the attribute that is supposed to and it is practically useful. tis widely acknowledged that two kinds of validation are needed, namely theoretical and empirical validation. The former is a basic step in the validation process and should allow one to prove that a measure satisfies properties characterizing the Concept (€- size, complexity, coupling, etc.) it is supposed to [9 If this is the case, the usefulness of the measure ean be verified by carrying out an empirical validation process, which usually exploits statistical analysis techniques. Several researchers have defined measurement theoretical principles that software measures should adhere to in order to be valid [29], [72], [73]. However, as suggested by Briand et al. in [10], the software engineering community might benefit from the adoption of a more pragmaticapproach, able to provide more practical results. Similar considerations have led several authors to provide guidelines and frame- ‘works for theoretical and empirical validation of measures No.1, JANUARY 2008 a rt—SSC‘C ‘CCN tusburs shoul cbey certain furdametal properties and Iensures of infernal atbutts shouldbe validated emp cally again! extemal atic. th this section we focus om the theoretical validation process and consider the general framework proposed by Brion etl 9} The ramenork contributes othe definition ta firmer theoretical ground of software measurement by providing convenient and intuitive properties for several hr ———". Ceftesion and coupling The generality ofthe approach iadus tothe fact that the properties chracterzing these concepts tre independent of te software artifacts (eg, software Specification, cesign, coe) the concepts ae applied to. Th the following, the uoretcal validation performed by evaluating the Cl Pont approach against the proper te proposed in [9 which ure specie for size measure We ony consider the C7 measure since the coresponding, theoretical validation proces can also be applied to CP, as nes Tn [three properties are defined, which ae pectic to the size measures, namely, Nonnegaity, Nall Vale, and Module Atty. tis worth noting tha stich propertis are rewctary but at uficient. Sil they consizn te earch for mesbures and “make the measure definition process Imoterigorous and less exploratory.” fore describing the analyis proces we performed on the CP, measure let us report the definitions ofthe genera ee eee re ae supped to very. n the eamework aspen is characte ized avast of elaments and a set of eatonships between those elements, formalized in the following definition Definition 1 [9k Representation of Sysems and Modules, ‘A epter 5 il be representa os a pair < E,R-> wher BE rpesens the sl of elements of 8 nnd Tet binary rr between $9 eames, Given & sytem S=
, 2 Fn > 1B 8 module ofS ff and ony Em CE, Ry © Eg Byy ant Mee Be The cements of Imule ve womeced1 eelements ofthe rest of The Syston by incoming. and ongoing, reaonsipe. The eet RR rg ee ies de smo ths of mobile m 6 dened as Input Rn) = {< 1,62 >€ Rlex € Eq and e: € E~ By). The set Output Rm) of relationships from the elements of a module m to those of the rest of the system is defined as Output Rim) = {< e1,¢2 >€ Rler € Ey anud eg € EB Ey} ‘The basic properties of size measures are very intuitive; they ensure that the size cannot be negative, it is null when the system has no element, and it can be obtained as the ‘sum of the size of its modules when they are disjoint. More formally Property Size 1: (Nonnegativity). The size of a system S = is nonnegative Size(S) > 0.