Applying Reverse Engineering Techniques to Verify the Estimation of Software Code Size using COSMIC Full Function Point

Transcription

1 Applying Reverse Engineering Techniques to Verify the Estimation of Software Code Size using COSMIC Full Function Point DOWMING YEH, YI-HONG CHEN, CHIH-YING YANG Department of Software Engineering National Kaohsiung Normal University No.62, Shenzhong Rd., Yanchao Dist., Kaohsiung TAIWAN {e007926, Abstract: - Software size estimation is an important task for a successful software development. There are a number of systematic methods to estimate the size of software systems, in which the function point analysis has achieved wide acceptance. Among various function point analysis methods, COSMIC-FFP is a relatively new approach and its application is also relatively easier than most methods. The estimation is based on requirement analysis artifacts such as use cases, sequence diagrams, or class diagrams. However, these artifacts are often insufficient to verify the precision of the estimation methods, let alone adjust these methods to different domains and organizations. In this study, we develop a tool that reverse engineers the Java source code to retrieve information in the level of detailed sequence diagrams and calculates the function points. Then regression analyses are applied to verify the applicability of function point estimation methods to a particular system. Key-Words: Software Size Estimation, Function Points, Reverse Engineering, Regression Analysis. 1 Introduction Software size estimation is an important task for a successful software development. It provides the starting point for other tasks such as cost estimation, development arrangement and human resource allocation in the early beginning of a project [1]. Software size estimation is almost always dependent on the experiences of the estimating engineers from similar projects in which they were involved. However, estimate approaches guided by human intuition or without concrete historical data can easily lead to inaccurate estimation of the size. There are a number of systematic methods to estimate the size of software systems, in which the function point analysis has achieved wide acceptance in estimating the scale of enterprise information systems. Function point analysis is a size estimation method that breaks down a software system into various parts that correspond to the definition of function points. Such decomposing process usually proceeds iteratively to reach the abstraction level of function points. Each component then is assigned a function point value based on its complexity and function type. Some analysis methods such as IFPUG then multiply the summation of function point with an influence adjustment factor to produce the final function points. The usage of function point is promoted by many industry experts for its advantages over approaches based on lines of code since it is independent of implementation details such as programming language. Based on the size estimation, function point analysis can also predict the human resource cost and duration of the project. Although there are standard methods, considerable experience is often required to apply these methods to calculate the estimated function point value with some precision from requirement specification [2]. Therefore, academia and industry are working to propose all sorts of methods and develop tools so that even a novice can follow certain steps to carry out the estimation work and still get fairly reliable results without extensive experience. Besides obtaining a count of function points with some accuracy and reliability, it is often necessary to transform the function point value into the number of lines of code (LOC) of the targeted software. To estimate the effort for building a software system, most models such as COCOMO take LOC as the unit of software size instead of function points. In embedded software, function points must also be converted to LOC to estimate the amount of memory needed. ISBN:

2 Such conversion is not straight forward. The factors affecting the LOC corresponding to a function point unit include the experience of the development team, programming language, application domain, and development method [3]. The sources of these methods are outcomes from requirement analysis, mostly use cases, sequence diagram or class diagram. During the requirement analysis phase, these artifacts may not be complete or sufficiently refined to support rigor measurement and analysis of function points [4]. Even when the project is completed, some of the artifacts may still be incomplete or insufficiently refined, making the postmortem analysis difficult to proceed. So how to construct these artifacts thoroughly in more details is the key to validate these methods. Since the class diagrams, sequence diagrams obtained from reverse engineering the source code contain more lower-level details than that generated in the requirement phase, we can use these diagrams to retrieve relevant information to calculate the associated function point size. In this work, a tool was developed to apply reverse engineering techniques on the source code of object-oriented systems to retrieve information in the level of sequence diagrams. The tool, then, based on specific rules, calculates the function points from the recovered information, and apply regression analysis to verify the applicability of function point estimation methods and learn the extent of possible deviation of the application of a function point size estimation method on the system. 2 Function Points Analysis A function point analysis method commonly used in the early days is the Use Case Points, proposed by Karner [5]. Some tools have been developed to compute Use Case Points, but they can only be produce basic IFPUG function points from Unified Modeling Language use cases [6]. The complexity classification of function points still must be completed manually. There are other function point size measurement procedures, and most of them are not yet augmented with automated tools [7] [8] [9] [10] [11]. Worse still, estimation results from most of these methods are not analyzed quantitatively so that the reliability and the accuracy of their results cannot be verified. Among various function point analysis methods, COSMIC-FFP (The Common Software Measurement International Consortium Full Function Points) is a relatively new approach and its application is also relatively easier than most methods. Moreover, it reliability or reproducibility by different estimators is reported in several studies [8] [12]. COSMIC-FFP is based on the experience of earlier function point analysis method and is intended to apply to a wider application spectrum other than traditional information systems, for example, real-time systems. The calculation of COSMIC-FFP is quite simple and straightforward. COSMIC-FFP exhibits object-oriented traits by looking at the system from the data aspect as well as the function aspect. Its definition of a data unit is called data group, which is equivalent to the normalized entity in information systems. One can also use a more elaborated data unit called attribute and it is equivalent to the normal definition of attribute in information systems. System function is modeled through functional processes, which can be further divided into two sub-processes: data movement and data manipulation sub-processes. Data movement subprocess is the main subject for function point computation. It can be divided into four categories: Entry data movement from a user to a function process; Exit data movement from a function to a user; Read data movement from a persistent storage to a function process. The persistent storage must be a part of the system; Write data movement from a functional process to a persistent storage. Again, the persistent storage must be a part of the system. In a functional process, the numbers of data group movement for the aforementioned four categories is presented as the function points, in a unit called Cfsu (COSMIC functional size unit). For functional process involves complex computation, it is suggested to count additional function points for the data manipulation sub-process. But there is no precise instruction on how to calculate such additional function points. All in all, the principle of this method is quite intuitive and simple, but the premise is a functional specification with certain details. To deal with estimation in the initial stage, it is recommended to first find out all functional processes, categorize them according to their complexity, and then set their function point value to the average size of a functional process obtained from historical statistics. In this research, we use COSMIC-FFP method to do the function points estimation. ISBN:

3 3 Reverse Engineering To constructed fine-grained sequential diagram or class diagram of an object-oriented systems (sequence diagram), we need the detailed structure and behavior information of the system. Without such information, one can only resort to reverse engineering the source to obtain as much information available as possible. Many CASE tools are equipped with some reverse engineering capabilities to extract basic static object-oriented architecture of the system, such as class diagrams. However, there are still some details need a breakthrough, such as how to distinguish the aggregation relationship from a general association relationship [13]. In terms of size estimation, sequence diagrams provide more important information than class diagrams since they describe the functional behavior of a system [8] [9] [10]. Compared to the reverse engineering of system structures, reverse engineering of the system behavior is more difficult. There are two major challenges, one for detecting control flow that corresponds to two major interaction operator, alt and loop, in the sequence diagram and the other for the merger of various execution trace [14] [15]. The detection of control flows can be determined statically by analyzing the control structure in the source code. Merging execution trace analysis can also be analyzed in a static manner, but the results are not complete [16]. As we aim to achieve the information related to estimating function point size rather than a concise sequential diagram, there is actually no need to overcome this challenge as described in the following sections. 2.1 Generating Sequence Diagrams A message in a sequence diagram corresponds to a method invocation in the source code. Therefore, if call graphs among various classes of objects are established, we can choose some methods in the source, say m, as the first message in a sequential diagram, produce a series of message interactions from method invocation, and the result is a sequence diagram describing the sequence of messages after the first message m. The call graphs can be constructed statically, for example, from the pointsto method by Rountev [17]. Let us illustrate through the following code as an example: class X {... class A { public void m(x a, int b) { a.p1(); X c = this.m2(a); c.p4(); X d = this.m4(); d.p6(); X e = d; if (b > 0) { e = new X(); e.p7(); e.p8(); public X m2(x f) { f.p2(); X q = this.m3(f); return q; public X m3(x g) { g.p3(); return g; public X m4() { this.fld.p5(); return this.fld; private X fld = new X(); Assuming that all methods of class X do not call any other method, and the method m was chosen as the starting point for analysis of a sequence diagram, the generated diagram is shown in Fig. 1. The opt part marked in Fig. 1 represents the optional behavior under certain condition. This can be generated by statically analyzing the conditional structure in the source code. From the purpose of calculating function points, such structure need not be distinguished since function point values in different options are summed up to account for the final function point value. Fig. 1 Converted sequence diagram (source: [13]). ISBN:

4 The sequential diagram in Fig. 1 is not entirely correct. Under further examination, one can find that objects a, f, g, c are in fact the same, and object fld, d can also be merged into one object. But from the view-point of functional point computing, merging or not and will not cause different results because the only concern is the number of messages transmitted in the sequence diagram and the recipients of messages are of no difference. Therefore, there is no need for complex analysis to merge different object name. The analysis simply uses the names of objects in the source code directly as this example shows to compute the size of function points. 2.1 Calculating Function Point Values The calculation of function point values from sequence diagram is based on that proposed by Jenner. Arrows directing from actors to interface objects correspond to the Cosmic FFP entries; while Arrows emitting from interface objects to actors correspond to the Cosmic FFP exits. Arrows between the objects in the system corresponds to the reads or the writes, but arrows representing returning values will not be considered. Let's take the sequence diagram in Fig. 1 to illustrate. There are one entries, twelve reads or write. Therefore, the total number of the Cosmic FFP is 13 Cfsus (Cosmic Functional Size Unit). That is, disregarding different categories of functional sub-process, the total number of the Cosmic FFP is the number of messages in the sequence diagram (except those returning messages). Finally, a regression analysis is performed on calculated function point values and the corresponding lines of source code from various sequence diagrams. The result from the analysis would reveal how many numbers of LOC are approximately equal to one unit of Cosmic-FFP and the possible deviation from such an approximation. 4 Design and Implementation The system architecture of the tool is shown in Fig. 2. The function point analysis tool is implemented in Ruby for its strong regular expression processing capability. Currently, only systems implemented in Java can be analyzed by our tools. The Java source code is first analyzed by the SFIM module to generate profiles for all methods. The profile of a method includes its name, the return type, argument types, lines of code of its body (without comments), as well as what class and package the method belongs to. Fig. 2 System architecture. Then, the engineer selects one of the functional processes (system functionalities, if you will), inputs the starting method and the associated class to the function point analysis tool. The function point analysis module then starts counting all the function points in the functional process. During the process of counting function points, the LOC of each called method are also summed up by consulting the profile of the method. The analysis result consists of the total function points in the process, and the total LOC in the process. There is, however, a complication in the function point analysis that results from the polymorphism feature in Java. That is, for polymorphic methods, the called method cannot be determined statically. It depends on the instantiation of the object at the run time. To deal with polymorphic methods, we sum up all the function points of these polymorphic methods since polymorphism is actually a selection mechanism that evokes an appropriate method based on the class type of the current object. After collecting sufficient analysis results, RAM module performs statistical analysis to build a regression model. The function point values serve as independent variables in the regression analysis, and the value of LOC is the dependent variable. The model represents a regression model of software size based on COSMIC-FFP. 5 Case Studies The first case study is a complexity analysis tool from another project in our laboratory. The data for the regression analysis consist of 13 records of functional processes in the tool, which were collected by the process described in the previous section. Next, we perform regression analysis on these values. The intercept constant is set to zero since no function point means no LOC. The F test examines the validity of the overall regression model with the Analysis of Variance (ANOVA). If the P-Value of the F test is less than a designated significant level, usually 0.05, then there is a linear relationship between independent variables and the dependent variables. On the other ISBN:

5 hand, if the P-value is greater than or equal to 0.05, the linear regression relationship is not supported. The regression model is shown in Table 1. The P-value of the F test is 9.34E-05, less than So, the linear relationship of the model is established. The coefficient of determination, which indicates the goodness of fit for the model, is The slope coefficient is 39.08, which means that a function point could be estimated to be equal to 39 LOC for the first case. Table 1 The First Regression Model. coefficient standard error t test P-value intercept 0 #N/A #N/A #N/A X E-05 The second case study is an open-source online chat system from SourceForge. The P-value of the F test is 9.337E-05, less than So, the linear relationship of our model is established. We are not familiar with the system, so we randomly select 24 methods as the starting method to perform the analysis. The regression model is shown in Table 2. The P-value of the F test is 1.32E-28, less than Again, the linear relationship is established. The coefficient of determination is , and a function point is estimated to around 24 LOC. Table 2 The Second Regression Model. coefficient standard error t test P-value intercept 0 #N/A #N/A #N/A X E-29 The results of two case studies suggest that different kinds of applications can influence the residuals between actual software code size and estimated software code size shall significantly. The software in the first case study involves complex decisions and computations. In such case, it is suggested to count additional function points. Our results confirm the necessity of adjustment. However, there is no precise instruction on how to calculate additional function points [18]. Therefore, our static analysis fails to account for this part, thus the precision of the estimated values can only reach about 75%. On the other hand, there is no complex decision and computation in second system and the precision of the estimated values reach a high value of 99.6%. The correlation between Cosmic function point and actual software code size is noted by Lind and Heldal [3]. They develop a linear model to estimate software code size from function point. However, their function point calculation is based on component diagrams which cannot convey behavior specification as sequence diagram, and thus fails to capture function points inside a component. As a result, the number of LOC for a function point, 148, is much higher in their case. However, the subject of their study is electronic control units of a distributed network in a vehicle which may be more isolated and simpler in behavior. They also find that different development teams would affect software code size by investigating another development team that develops software components of different electronic control units. Although there is also high correlation for the second team, it is also clear that the linear model developed for one development team will not perform well for the other development team, just as in our case. 6 Conclusions Among various function point analysis methods, COSMIC-FFP is an approach more suitable for object-oriented systems and its estimation is simple and straightforward. However, it is based on outcomes from requirement analysis which may be incomplete or insufficiently refined, making the postmortem analysis difficult to proceed. We develop a tool to apply reverse engineering techniques on the source code of object-oriented systems to retrieve information in the level of sequence diagrams. The tool, then, based on specific rules, calculate the function points from the recovered information. Then, function points and the corresponding numbers of LOC are analyzed to produce regression models. Two study cases are presented to verify the effectiveness of our method. The result shows that different kinds of applications can influence the accuracy of the COSMIC-FFP method significantly. For systems without complex decision and computation, the goodness of fit for the model reaches a very high value, and such information can be consulted to adjust the estimation when applied to a new but similar system. The estimation of systems involves complex decisions and computations may suffer from the lack of a mechanism which adjusts the weighting of function points. In the future, we plan to establish a model combining a software size estimation model combining COSMIC-FFP function points with some complexity factors. Acknowledgements This work was supported in part by the R.O.C. Ministry of Science and Technology under Grant MOST E ISBN:

6 References: [1] Fenton, N., Software measurement: A necessary scientific basis.software Engineering, IEEE Transactions on, 20(3), [2] Jeng, B., Yeh, D., Wang, D., Chu, S. L., Chen, C. M., A Specific Effort Estimation Method Using Function Point. Journal of Information Science and Engineering, 27(4), [3] Lind, K., Heldal, R., Estimation of realtime software code size using COSMIC FSM. In Object/Component/Service-Oriented Real- Time Distributed Computing, ISORC'09. IEEE International Symposium on (pp ). IEEE. [4] Bévo, V., Lévesque, G., Abran, A., UML notation for functional size measurement method. In Proc. 9th International Workshop on Software Measurement, Canada (pp ). [5] Karner, G., Resource estimation for objectory projects. Objective Systems SF AB, 17 [6] Clemmons, R. K., Project estimation with use case points. The Journal of Defense Software Engineering, [7] Bertolami, M. A., Oliveros, A., Estimate of the functional size in the requirements elicitation. Journal of Computer Science & Technology, 5. [8] Condori-Fernández, N., Abrahão, S., Pastor, O., On the estimation of the functional size of software from requirements specifications. Journal of Computer Science and Technology, 22(3), [9] Habela, P., Głowacki, E., Serafinski, T., Subieta, K Adapting the Use Case Model for COSMIC FFP-Based Measurement. COSMIC Function Points: Theory and Advanced Practices,204. [10] Jenner, M. S., COSMIC-FFP and UML: Estimation of the Size of a System Specified in UML Problems of Granularity. In Proc. the Fourth European Conference on Software Measurement and ICT Control (pp ). [11] Tavares, H., Carvalho, A., Castro, J., Function points measurement from requirement specification. In Proc. 5th Workshop Engineering Requirements, Valency, Spain (pp ). [12] Top, O. O., Demirors, O., Ozkan, B., Reliability of COSMIC functional size measurement results: A multiple case study on industry cases. In Software Engineering and Advanced Applications, SEAA'09. 35th Euromicro Conference on (pp ). IEEE. [13] Yeh, D., Sun, P. C., Chu, W., Lin, C. L., Yang, H., An empirical study of a reverse engineering method for the aggregation relationship based on operation propagation. Empirical Software Engineering, 12(6), [14] Lo, D., Maoz, S., Khoo, S. C., Mining modal scenario-based specifications from execution traces of reactive systems. In Proceedings of the twenty-second IEEE/ACM international conference on Automated software engineering (pp ). ACM. [15] Ziadi, T., Da Silva, M. A. A., Hillah, L. M., Ziane, M., A fully dynamic approach to the reverse engineering of UML sequence diagrams. In Engineering of Complex Computer Systems (ICECCS), th IEEE International Conference on (pp ). IEEE. [16] Rountev, A., Milanova, A., Ryder, B. G., Points-to analysis for Java using annotated constraints. In ACM SIGPLAN Notices (Vol. 36, No. 11, pp ). ACM. [17] Rountev, A., Connell, B. H., Object naming analysis for reverse-engineered sequence diagrams. In Proceedings of the 27th international conference on Software engineering (pp ). ACM. [18] Dowming Yeh, Yi-Hong Chen, Chih-Ying Yang, Li-Wei Chen, Ying-Hsiu Wang, and Kai- Wei Chen, Applying reverse engineering and complexity analysis to refine a cost estimation model based on function point. International Computer Symposium 2014, Taichung, Taiwan. ISBN: