Class Point: An Approach for the Size Estimation of Object-Oriented Systems

In this paper, we present an FP-like approach, named class point, which was conceived to estimate the size of object-oriented products. In particular, two measures are proposed, which are theoretically validated showing that they satisfy well-known
of 24
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
  See discussions, stats, and author profiles for this publication at: Class point: An approach for the size estimationof object-oriented systems  Article   in  IEEE Transactions on Software Engineering · February 2005 DOI: 10.1109/TSE.2005.5 · Source: IEEE Xplore CITATIONS 95 READS 56 4 authors: Gennaro CostagliolaUniversità degli Studi di Salerno 200   PUBLICATIONS   1,531   CITATIONS   SEE PROFILE F. FerrucciUniversità degli Studi di Salerno 68   PUBLICATIONS   589   CITATIONS   SEE PROFILE Genoveffa TortoraUniversità degli Studi di Salerno 406   PUBLICATIONS   8,470   CITATIONS   SEE PROFILE Giuliana VitielloUniversità degli Studi di Salerno 146   PUBLICATIONS   921   CITATIONS   SEE PROFILE All content following this page was uploaded by F. Ferrucci on 27 October 2012. The user has requested enhancement of the downloaded file. All in-text references underlined in blue are added to the srcinal documentand are linked to publications on ResearchGate, letting you access and read them immediately.  Class Point: An Approach for the SizeEstimation of Object-Oriented Systems Gennaro Costagliola,  Member  ,  IEEE  , Filomena Ferrucci,Genoveffa Tortora,  Senior Member  ,  IEEE Computer Society  , and Giuliana Vitiello Abstract —In this paper, we present an  FP  -like approach, named  Class Point  , which was conceived to estimate the size of object-oriented products. In particular, two measures are proposed, which are theoretically validated showing that they satisfy well-knownproperties necessary for size measures. An initial empirical validation is also performed, meant to assess the usefulness andeffectiveness of the proposed measures to predict the development effort of object-oriented systems. Moreover, a comparativeanalysis is carried out, taking into account several other size measures. Index Terms —Object-oriented systems, size measures, Function Point Analysis, theoretical validation, empirical validation, effortprediction model.  1 I NTRODUCTION I N  recent years, many software measures have beendefined to gather information about relevant aspects of software products. Software product measures quantifyproperties, which are usually classified as internal andexternal attributes. Internal attributes of a product can bemeasured in terms of the product itself, i.e., independentlyfrom its behavior (e.g., size, complexity, modularity). Onthe contrary, external attributes usually denote propertiesthat can be measured by taking into account how theproduct relates to its environment [29]. Examples of external attributes are reliability, understandability, andmaintainability. Since external attributes depend not onlyon the considered product but also on its behavior in itsenvironment, they are hard to quantify. For that reason, thecurrent trend is to investigate measures for quantifyinginternal attributes and to establish models, which correlateexternal attribute measures with the internal attribute ones.Software size represents one of the most interestinginternal attributes of a product. It has been employed inseveral effort/cost models as a predictor of the effort andcost needed to design and implement the software (see, e.g.,[6], [29], [42], [64]). Thus, size evaluation is one of the main tasks for planning software project development withreliable cost and effort estimations. Several measures have been defined so far in order to estimate the size of softwaresystems. Among them,  Function Points  ( FPs ) have achieveda wide acceptance in the estimation of the size of businesssystems and to indirectly predict the effort, cost, andduration of their projects [2], [27], [42]. The method provides an estimation of software size by measuring thefunctionality of the system to be developed. This allows Function Point Analysis  ( FPA ) to be applied in the earlyphases of the lifecycle, which is the main reason for thesuccess of the method.Although the applicability of   FPA  is limited to procedur-al business systems, many researchers agree that the FP  method can be generalized in order to be successfullyused for other types of systems (e.g., engineering, scientificand real-time systems) and for different programmingparadigms [4], [6], [27], [31], [35], [68], [70]. In this paper, we present an  FP -like approach, named Class Point , which was conceived to estimate the size of object-oriented products, based on design documentation.In particular, two measures are proposed, named  CP  1  and CP  2 .  CP  1  is meant to be used at the beginning of thedevelopment process to carry out a preliminary sizeestimation, which can be later refined by applying  CP  2 when more information is available.The idea underlying the  Class Point  method is thequantification of classes in a program in analogy to thefunction counting performed by the  FP  measure. This ideaderives from the observation that in the proceduralparadigm the basic programming units are functions orprocedures; whereas, in the object-oriented paradigm, thelogical building blocks are classes, which correspond toreal-world objects and are related to each other.The  Class Point  size estimation process is structured intothree main phases, corresponding to analogous phases inthe  FP  approach. During the first step the design specifica-tions are analyzed in order to identify and classify theclasses into four types of system components, namely theproblem domain type, the human interaction type, the datamanagement type, and the task management type.During the second step, each identified class is assigneda complexity level, which is determined on the basis of thelocal methods in the class and of the interaction of the classwith the rest of the system. This is achieved by exploitingsuitable measures for OO classes. The measures and theway they are used to carry out this step represent the 52 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 31, NO. 1, JANUARY 2005 .  The authors are with the Dipartimento di Matematica e Informatica,Universita` of Salerno, Via Ponte Don Melillo, 84084 Fisciano, SA, Italy.E-mail: {gcostagliola, fferrucci, tortora, gvitiello} Manuscript received 7 Jan. 2004; revised 23 June 2004; accepted 13 Dec. 2004; published online 9 Feb. 2005.Recommended for acceptance by L.C. Briand.For information on obtaining reprints of this article, please send e-mail, and reference IEEECS Log Number TSE-0006-0104. 0098-5589/05/$20.00    2005 IEEE Published by the IEEE Computer Society  substantial difference between  CP  1  and  CP  2 . Indeed, in  CP  1 the complexity level of each class is determined on the basisof the  Number of External Methods  ( NEM ) [33], [50], [51], and the  Number of Services Requested  ( NSR ). The  NEM  measureallows us to estimate the size of the interface of a singleclass in an object-oriented system and is given by thenumber of local methods which are public.  NSR  provides ameasure for the interconnection of system components. It isagain applicable to a single class and is determined by thenumber of different services requested to other classes. In CP  2 , besides the above measures, the  Number Of Attributes ( NOA ) [33] measure is taken into account in order toevaluate the complexity level of each class. Once acomplexity level of each class has been assigned, suchinformation and its type are used to assign a weight to theclass. Then, the  Total Unadjusted Class Point  value ( TUCP ) iscomputed as a weighted sum. Finally, the  Class Point  valueis determined by adjusting the  TUCP  with a value obtained by considering global system characteristics as in  FPA .In the paper, we also report on the results of twocomplementary validations, which have been performed onthe proposed measures, namely, the theoretical and theempirical one. In fact, it is widely acknowledged that asoftware measure can be acceptable and effectively usableonly if its usefulness has been proven by means of avalidation process. The aim of such a process is to show thatthe measure really measures the attribute it is supposed toand that it is practically useful. The proposed  Class Point measures have been theoretically evaluated against well-known properties, namely, the desirable size propertiesdefined by Briand et al. [9]. Moreover, an empirical study has been performed to investigate the usefulness of the Class Point  approach as a means to estimate the effort of OOproducts. It is indeed an initial study based on data derivedfrom 40 students’ projects, on which a linear regressionanalysis, based on a 4-fold cross validation technique, has been carried out. The results of such an analysis indicatethat each of the variables  CP  1  and  CP  2  exhibits a highcorrelation with the development effort. Moreover, it turnsout that the proposed measures can effectively be usedduring the design phase to predict the effort values with ahigh degree of confidence. In particular, the results of theempirical analysis show a better performance of the CP  2  measure than the  CP  1  one. This further supports theintuition that attributes can profitably be exploited in theestimation of system size. On the other hand, the number of attributes of each class may not be very accurate early in thedevelopment process, and it is likely to be available later inthe process than the number of external methods andrequested services. Thus,  CP  1  can be used to obtain apreliminary estimation and  CP  2  to refine such estimationwhen the number of attributes is available. The empiricalanalysis has also shown that both measures exhibit a betterpredictive capability than the single basic measuresinvolved in the  Class Point  counting, as well as with respectto some measures obtained by merely summing up the basic ones.The remainder of the paper is organized as follows: InSection 2,  Function Point Analysis  is recalled together withsome OO size measures. A detailed description of the Class Point  approach is given in Section 3. Section 4 dealswith the theoretical validation of the  Class Point  measures;whereas, in Section 5, the results of the empirical analysisare given. Finally, Section 6 contains some concludingobservations and suggests further aspects to be investigated. 2 S IZE  M EASURES In this section, we recall the basic concepts underlying the FP  method and describe some size measures conceived forthe OO paradigm. 2.1 Function Point Analysis Not long ago, the  Lines of Code  ( LOC ) count was the onlysoftware size measure used for defining product measures.In spite of the simplicity and familiarity of this counting, LOC  could only be computed once the software productwas available and could not be used for predicting the sizeof the software under development. The need to estimatesoftware size in the early phases of the lifecycle hasmotivated the investigation of more accurate softwaresizing techniques. One such technique is the  Function Point method, which was introduced by Albrecht [2] to measurethe size of a data-processing system from the end-user’spoint of view. The srcinal definition of the method has been modified several times, resulting in different versionsof the counting procedure. Since 1986, the  InternationalFunction Point User Group  ( IFPUG ) has been operating withthe aim of defining the standard for the method andpopularizing it all over the world. The current standardversion is reported in the IFPUG Counting PracticesManual [34].The  FP  method can be applied throughout the develop-ment process, starting from early requirements definition. Itdetermines the size of a system by performing a sequence of steps. The analysis starts with the identification of allfunctions. Each function is classified as belonging to one of the following function types: external input ( EI  ), externaloutput ( EO ), external inquiry ( EQ ), internal logical file ( ILF ),and external interface file ( EIF ). The first three classes of functions fall within the transaction function typology,while the last two, referring to the logical files, areconsidered data function types. Each function is thenweighted based on its type and on the level of itscomplexity, in agreement with standard values as specifiedin the Counting Practices Manual. As an example, fortransactions ( EI  ,  EO , and  EQ ), the rating is based on thenumber of   Data Element Types  ( DETs ) and  Referenced FileTypes  ( FTRs ). A  DET   is a unique, nonrepeated fieldrecognized by the user. An  FTR  can be an  ILF  referencedor maintained by the transaction or an  EIF  read by thetransaction. Thus, if an external inquiry has more than 16 DETs  and at least two  FTRs , it is assigned a high complexitylevel and a weight value equal to 6.The weighted total of the five components of theapplication is then multiplied by the  Value AdjustmentFactor , which is computed on the basis of the degree of influence that each of 14 general system characteristics islikely to have on the application. The adjustment factorcauses the  FP  count to vary with respect to the unadjustedcount from -35 percent (corresponding to a null degree of  COSTAGLIOLA ET AL.: CLASS POINT: AN APPROACH FOR THE SIZE ESTIMATION OF OBJECT-ORIENTED SYSTEMS 53  influence for all the 14 characteristics) to +35 percent(corresponding to all degrees set to 5).During the last few years, the  FP  measure has gainedincreasing approval by application developers. They haveexploited the  FP  count in order to profitably estimateproductivity, in terms of   Function Points  per person-month,and quality, in terms of the number of defects per functionpoint with respect to requirements, design, coding, and userdocumentation phases. Besides its early applicability, thesuccess of   Function Points  for measuring the size of a systemis due to its independence from the language and the toolsused throughout the lifecycle.The appealing features of the approach have motivatedseveral proposals meant to exploit the main ideas of themethod in order to predict the size of object-orientedsystems. In the following section, we describe severaladaptations of the  FP  method to OO systems, besides othersize measures conceived for object-orientation. 2.2 Size Measures for OO Systems The widespread use of object-oriented methodologies insoftware development has motivated the investigation of product measures that allow us to monitor, test, andsupport the development and the maintenance of softwarein OO environments. Indeed, existing software size mea-sures for the procedural paradigm turn out to no longer besuitable to capture specific object-oriented features, such asclasses, inheritance, encapsulation, and message passing.In [50], [51], two size measures, named  Size 1  and  Size 2 ,were considered for the OO paradigm.  Size 1  is defined asthe number of noncommented lines of source code. Itrepresents the Lines Of Code count for the OO paradigmand then it is subject to the same criticisms, namely, the lackof standardization, the language dependency, and theinadequacy for early phases of the software lifecycle. The Size 2  measure is closer to the OO methodology and it is based on a less ambiguous count which can also be carriedout in the design phase.  Size 2  is defined as the total count of the number of data attributes and the number of external(or public) local methods in a class, more precisely, Size 2  ¼  NOA þ NEM; where  NOA  is the number of attributes of the class and NEM   is the number of external methods of a class, i.e.,methods which are available through the class interface tomembers of other classes [33]. Thus, the definition of   Size 2 does not include private methods. An immediate simpleextension of class size definition has been provided in [33],as the sum of the number of all the local methods and thenumber of attributes of the class, more formally, S  C   ¼  NOA þ NOM; where  NOM   is the number of local methods (i.e.,  NOM  includes also nonpublic methods).In [21], Chidamber and Kemerer have defined a set of six measures for assessing the design of OO systems, withspecial reference to the identification, the semantics, and therelationships steps of Booch’s design methodology [7].Among them, the  Weighted Methods per Class  ( WMC ), the Number Of Children  ( NOC ), and the  Response For a Class ( RFC ) measures can be used as size measures, as pointedout in [9].  WMC  is given by the summation of the staticcomplexities of all the local methods. Since the complexityof a method can be evaluated by using any traditional staticcomplexity measure,  WMC  is actually a family of measures.In particular, when all the methods in a class are consideredto be equally complex,  WMC  boils down to the  Number Of local Methods  of a class, i.e.,  NOM  .The measure  NOC  is given by the number of directsubclasses of a class. It estimates the number of subclasses,which will inherit the methods of the parent class.  RFC  isthe number of methods local to a class plus the number of nonlocal methods which are called by a local method. Thismeasure of the potential communication among classesprovides information about the testing and debuggingefforts that may be required by an object.All the previous measures provide a class-level measure-ment. As a consequence, they are more useful forproductivity analysis once the software has been realized but less profitable for effort prediction [57]. Indeed, such atask is better supported by an overall view of the system asprovided by system-level measures [32]. For that reason,several system-level measures have been defined [15], [16], [17], [18], [54], [60]. Most of them derive measures from class-level ones. For instance, as suggested by Henderson-Sellers, we can sum the class-level values across the system[33]. Lorenz and Kidd have also elaborated a set of system-level measures, including the average method size over thesystem, the average number of methods per class, and theaverage number of instance variables per class [54].The  System Meter  method is another system-levelapproach to size measurement, especially conceived for business models [60]. A business modeling language,named  DOME , is used to distinguish among  language , library , and  project-specific Description Objects , thus givingspecial relevance to reusable components in the measure-ment process. Like  FPA , the method can be applied to anymanagement information system. However,  System Meter  isespecially directed to object-oriented development pro-cesses and empirical studies have suggested that it predictsdevelopment effort more precisely than  FPA  [61].Nesi and Querci present a set of size/complexitymeasures specifically targeted at effort estimation andprediction. Some of these measures are obtained bycombining existing measures, so as to enhance theireffort predictive capability. Three different levels areconsidered, namely, method, class, and system, and foreach level measures are defined in terms of measures of lower levels [64].In the last years, other size measures have beensuggested as adaptations of the  FP  method to OO systems[6], [27], [35], [42], [68], [69]. In particular, Whitmire proposes the application of his  3D Function Points  toobject-oriented software systems, by considering each classas an internal file and messages sent across the system boundary as transactions [71]. However,  3D Function Points require a greater degree of detail in order to determine sizeand consequently make early counting more difficult.The ObjectPoint measureisanotheradaptationof  FP ,usedin the improved COCOMO 2.0 estimation technique [6]. The 54 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 31, NO. 1, JANUARY 2005  Object Point  count is very similar to  FP , but objects are takenas the basis of the counting process. However, such objectsare not directly related to “objects” in the OO methodology, butratherrefertoscreens,reports,or3GLmodules.Fetckeetal. propose a method based on rules which map use casemodels in the Jacobson OOSE method to concepts of   FPA [30]. Their proposal is based on the standard  FPA  defined inthe IFPUG Counting Practices Manual (IFPUG 1994), and isdescribed through three industrial case studies that adoptedthe OOSE approach. Predictive Object Points  ( POPs ) represent another system-level measure for effort prediction, which adopts a countingscheme analogous to  FPs . It was proposed by Minkiewicz asa suitable combination of well-known OO measures [57]. POPs  counting is based on the  WMC  measure applied to toplevel classes, and combines such information with theaverage depth of the inheritance tree and the average  NOC .In order to compute the  WMC  value, each method isweighted by a complexity determined by the type of method (constructor, destructor, modifier, selector, itera-tor), by the number of properties the method affects and thenumber of services it provides to the system. As pointed out by the author, detailed information required by the  POP counting for determining complexity of methods is notavailable in early stages of the software developmentprocess. As a solution, he proposes to approximate suchvalues on the basis of the available information. Closelyrelated to the  POP  approach, is the method proposed for thedefinition of   Object-oriented Function Points  ( OFPs ) in [3].The method is characterized by a mapping of   FP  concepts(logical files and transactions) to OO concepts (classes andmethods), and by a flexible method for handling specificOO concepts like inheritance and aggregation. With respectto Minkiewicz’s approach, the complexity of methods isdetermined only by the information contained in theirsignatures. In particular, data referenced in it are countedand classified as simple items or complex items, dependingon whether they refer to elementary data types or classtypes. Then, the complexity level of each method isdetermined by exploiting the IFPUG tables for transactionsand by considering simple and complex items as  DET   and FTR  elements of traditional  FP . Similarly, the complexity of each class is classified as low, average or high using  IFPUG standard tables for logical files. 3 T HE  C LASS  P OINT  A PPROACH In this section, we present the  Class Point  approach, whichprovides a system-level estimation of the size of OOproducts. It has been conceived by recasting the ideasunderlying the  FP  analysis within the OO paradigm and bysuitably combining well-known OO measures. The basicideas of the  Class Point  method were first proposed in [26],and later refined giving rise to the definition of twomeasures,  CP  1  and  CP  2 , which are presented in whatfollows. Indeed, the aim of the proposed approach is toprovide a method which allows us to refine estimatesthroughout the development and to exploit new informa-tion as it is available. As a matter of fact, the  CP  1  measurewas conceived to provide an initial size estimation at the beginning of the development process. Such an estimationcan be further detailed by applying  CP  2 , whose computa-tion requires data that are usually available later in thedevelopment process.As opposed to the other adaptations of   FP , whenconceiving the  Class Point  approach as an extension of   FP ,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 theOO paradigm, operations are tightly related to the data theymanipulate and are therefore embedded in the concept of aclass. As a consequence, the  Class Point  method is especiallyfocussed on classes, which are the entities the methodshould count and weigh on the basis of their complexitylevels, as was the case for functions in  FPA . The complexitylevel of each class is derived from the information about thelocal methods in the class, about the interaction of the classwith the rest of the system, and, when available, about theattributes. Moreover, while the classification of datafunction types and transaction function types in  FPA  wasespecially conceived for business applications, the categor-ization of classes in the  Class Point  measures is independentof any application typology. To some extent, our approachis similar to  POP  counting, with the main difference lying inthe fact that we distinguish among categories of classes,rather than classifying methods. Another point of distinc-tion with respect to  POPs  is that data are also taken intoaccount in the  Class Point  measures, and the informationneeded to perform the counting is usually available at thedesign phase rather than being replaced by estimatedvalues.In Section 3.1, we describe the  Class Point  approachwhich underlies the estimation of the  CP  1  and  CP  2 measures. In Section 3.2, we describe the process that ledto 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 inthe  FP  approach. A sketch of the method is shown inTable 1. 3.1.1 Identification and Classification of User Classes  During the first step of the  Class Point  counting, the designspecifications are analyzed in order to identify and classifythe classes. Generally, four types of system components can COSTAGLIOLA ET AL.: CLASS POINT: AN APPROACH FOR THE SIZE ESTIMATION OF OBJECT-ORIENTED SYSTEMS 55 TABLE 1The  Class Point   Method
Similar documents
View more...
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!