Complexity Metrics for Component-based Software Systems

Transcription

1 Coplexity Metrics for Coponent-based Software Systes International Journal of Digital Content Technology and its Applications. Volue 5, Nuber 3, March 2011 Coplexity Metrics for Coponent-based Software Systes 1* Jianguo Chen; 2 Hui Wang; 3 Yongxia Zhou; 4 Stefan D. Bruda 1,2,3 College of Inforation Engineering, China Jiliang University, Hangzhou , China * gchen@clu.edu.cn, @qq.co, zhouyongxia@clu.edu.cn 4 Departent of Coputer Science, Bishop s University, Sherbrooke J1M 1Z7, Canada bruda@cs.ubishops.ca doi: /dcta.vol5. issue3.24 Abstract In recent years, the software engineering counity has put considerable efforts into the design and developent of coponent-based software syste (CBSS) in order to anage the software increasing coplexity and to axiize the reuse of code. This paper presents soe of such efforts by investigating the iproved easureent tools and techniques, i.e., through the effective software etrics. Upon the research on the classical evaluation easures for software systes, we argue the traditional etrics are not suitable for CBSS. Therefore we provide an account of novel software easures for coponent by adequate coupling, cohesion and interface etrics. The coplexity etrics cobined with three etrics on the CBSS level is also investigated. The advantages of our ethod are discussed as well through a case study in this paper. Keywords: Coplexity Metrics, Coupling, Cohesion, Interface, Coponent-based Software Syste 1. Introduction The core of coponent-based software syste (CBSS), as known as coponent-based software engineering (CBSE), is to reuse software coponents. The pressure for reducing software developent life cycles and costs has lead to an increasing interest in CBSS that not only facilitates the process of software developent but also changes the ways to develop software applications. Nowadays CBSS is getting accepted in the industry as a new effective software developent paradig [1]. Most of the CBSS research has been inclined towards ethods and approaches in the developent and in coparison of software systes [2]. Soe work tries to evaluate the coplexity of tools used to create the software artifacts [3]. A very little work has been ade for the developent of easures/etrics that can be used to evaluate the coplexity of coponents being developed, and the software quality using coponent integration [4]. However, any of software failures are caused by the inherent coplexity of the software developent process. One solution to aeliorate such failures can be achieved by iproving our software anageent capabilities by the developent of iproved software etrics and iproved utilization of such etrics. Software etrics as a subect area is near 40 years old, but it has barely penetrated into the ainstrea of software engineering. A key reason for this is that ost software etrics activities have issed the ost iportant requireent: providing inforation to support quantitative anagerial decision-aking during the software lifecycle. This paper will attept to provide the quantitative software etrics for CBSS. Software etrics can usually be classified as being one of two types: (1) process etrics - They are quantifiable attributes of the developent or aintenance processes and their environent; (2) product etrics - they are quantifiable features of the software product. Both process and product etrics ay be further categorized as: (1) result etric - quantifies soe attributes of a copleted proect, or part proect; (2) predictor etric - is used to ake an estiate of the value of a result etric. This paper will discuss the product etrics on coponent and CBSS levels with the further category in the result etric. Two coon vulnerabilities related product etrics are coupling and cohesion both at the stages of design and code. In general, the coupling between coponents is the degree of utual interdependence and the coponent cohesion is the property of connectivity aong the aggregate eleents of a single

2 Coplexity Metrics for Coponent-based Software Systes International Journal of Digital Content Technology and its Applications. Volue 5, Nuber 3, March 2011 coponent. It is believed that high coupling and low cohesion ake understanding, developing, testing, and aintaining CBSS difficult, leading to the introduction of vulnerabilities [5]. In CBSS, after coponents have been created or possibly reusable coponents have been extracted, these coponents ust be evaluated and certified through a software etrics syste because the predictability of syste quality attributes will depend on the quality attributes of the constituent coponents. Therefore coponent evaluation becoes a very iportant task for CBSS. The widespread reuse of a software coponent with poor quality ay literally lead to vulnerabilities or even disasters. On the other hand, the evaluation should also be perfored on asseblies, rather than only on individual coponents. The overall quality of the produced syste, rather than the individual quality of the coponents, is ore iportant. Therefore, in this paper, we will investigate the software etrics on the coponent and CBSS levels. We will begin by discussing the ost coonly used software etrics and review their use in constructing odel developent process. More iportantly, our focuses will first be on the evaluations in the individual coponent such as cohesion etrics, coupling relations and interface coplexity between the coponents. Then the focus should shift to the overall best solution of CBSS with the individual coponent assessent acting as a part of the coponent assebly evaluation. The rest of this paper is organized as follows. We briefly introduce coon traditional software etrics and their properties in section 2. Section 3 discusses the coponent s definition and the etrics on the coponent level, including coupling, cohesion and interface etrics. In Section 4, we will present coponent assebly etrics, i.e., etrics on the syste level. Section 5 is a case study. The related works are discussed in section 6, followed by a suary of the key ideas in this paper in section Coon traditional software etrics As applied to the software product, software etrics that are usually related to the software quality basically easure or quantify the characteristics of the software. Traditional etrics have been applied to the easureent of software coplexity of structured systes since Soe coon traditional software etrics are: 1) source lines of code (SLOC); 2) cycloatic coplexity; 3) function point analysis (FPA); 4) bugs per lines of code; and 5) code coverage Source lines of code The siplest software etric is the nuber of lines of code (LOC or KLOC for thousands of lines of code) used to easure the size of a software progra by counting the nuber of lines in the text of the progra's source code. It was, and still is, used routinely to predict the aount of effort that will be required to develop a progra, i.e., Effort = f (LOC), as well as to estiate prograing productivity such as LOC/person-onth or cost ($/LOC) once the software is produced. However, differences in underlying definitions and counting techniques ay ake LOC ipossible to copare. If different prograing languages are involved, etrics involving LOC, if not carefully interpreted, will lead to incorrect conclusions and thereby conceal the real significance of the data. Therefore, the need for ore discriinating etrics to easure the coplexity of software becoes especially urgent with the increasing diversity of prograing languages Cycloatic coplexity Cycloatic coplexity directly easures the nuber of linearly independent paths through a progra's source code. It is used to easure code coplexity by taking into account the progra flow graph under the assuption that the effective coplexity of a progra lies in its structure rather than in a ere stateent count. Given any coputer progra, we can draw its control flow graph that ay consist of several sub-graphs. In each sub-graph, each node corresponds to a block of sequential code and each arc

3 Coplexity Metrics for Coponent-based Software Systes International Journal of Digital Content Technology and its Applications. Volue 5, Nuber 3, March 2011 corresponds to a branch or decision point in the progra. The cycloatic coplexity can be coputed as (1) [6]: where M = cycloatic coplexity. E = the nuber of edges of the graph. N = the nuber of nodes of the graph. P = the nuber of sub-graphs. M = E N + 2P (1) 2.3. Function point analysis A function point is a unit of easureent to express the aount of functionality the syste provides to the user. FPA etric is to copute the total function point value for the syste based upon the nuber of user inputs, outputs, files, inquiries and interfaces [7]. These function-point counts are then weighed (ultiplied) by their degree of coplexity, e.g., the weights for the five counts can be 4, 5, 10, 4 and 7at the average coplexity, respectively: FPA = 4*input + 5*output + 10*files + 4*inquiries + 7*interfaces (2) 2.4. Bugs or faults per line of code The nuber of bugs or defects observed in a software product provides a etric of software quality. Soe alternative easures have been proposed since there is no effective procedure for counting the bugs or defects in the progra: (1) nuber of design changes, (2) nuber of errors detected by code inspectors, (3) nuber of errors detected in progra tests and (4) nuber of code changes required Code coverage Code coverage, an indirect easure of quality, is a quantitative easure used in software testing. It easures the code lines that are executed for a given set of software tests and describes the degree to which the source code of a progra has been tested. Meanwhile, it finds areas of a progra not exercised by a set of test cases and asks for additional test cases to increase coverage. It is a for of testing that inspects codes directly and is therefore a for of white box testing Liitations of traditional software etrics Traditional software etrics are usually applicable to sall progras, whereas the etrics for CBSS should depend ainly on the granularity and interoperability aspects of the coponents. Size of a coponent is norally not known to the coponent developers, whereas ost of the traditional size etrics such as SLOC and bugs (faults)/code line and code coverage are based on lines of code, which is not applicable to CBSS. Traditional cycloatic coplexity etric suite cannot be applicable either in CBSS because operator and operand counts are not known in CBSS and the nuber of linearly independent paths cannot be easured. FPA depends on the weights that were developed in a particular environent, which arises about the validity of this ethod for general application even though soe iproved easures like adusting the counting ethod have been taken. There are any inherent differences in CBSS and non-cbss so that the traditional software etrics are inappropriate for CBSS [8]. Besides, the traditional software etrics do not address the interface coplexities and integration-level etrics, which are also not applicable to CBSS

4 Coplexity Metrics for Coponent-based Software Systes International Journal of Digital Content Technology and its Applications. Volue 5, Nuber 3, March Coponent definition and etrics 3.1. Coponent definition The traditional software etrics focus on non-cbss and are inappropriate to CBSS ainly because the coponent size is norally not known in advance. Inaccessibility of the source code for soe coponents prevents coprehensive testing. Therefore we will use other etrics to guide the software developent process of CBSS. Software coponent is usually regarded as a part of the starting platfor for service orientation throughout software engineering. In this paper, a coponent can be regarded as a reusable software eleent such as a function, file, class, odule or subsyste. In CBSS, each acquired coponent should be validated at a very early stage in the software developent process such as the design stage and coding one. The quality attributes of the coponent ust be easured using validated etrics that should provide a correct estiate of the attributes. Here we will ainly discuss coponent etrics and syste easures at the design stage of life cycle Coponent general etrics The iportant and relevant etrics applicable for the coponent quality analysis during design stage are [9]: Coponent Size Metric (CSM): CSM should be based on the total nuber of sub-coponents such as classes or use cases. Weighted Methods per Coponent (WMC): the nuber of local ethods defined in the coponent. WMC is related to size coplexity. WMC is the indicator of developent and aintainability coplexity. Depth of Inheritance Tree (DIT): the axiu depth of the coponent in the inheritance tree. The deeper the coponent is in the inheritance hierarchy, the greater the nuber of ethods it is likely to inherit, aking it ore coplex to predict the coponent s behavior. Nuber Of Children (NOC): the nuber of iediate sub-coponents of a coponent or the count of derived coponents. NOC easures inheritance coplexity. Count of Base Coponents (CBC): the nuber of base coponents. Like NOC, CBC easures inheritance coplexity. Response set For a Class (RFC): the set of ethods that can potentially be executed in response to a essage received by an obect of that coponent. RFC is siply the nuber of ethods in the set, including inherited ethods. Additionally, we will present three ore etrics for the coponent in CBSS: coupling, cohesion and interface etrics. Cohesion is a easure of how strongly-related the various responsibilities of a software coponent are. Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa. Interface etric provides an estiate of the coplexity of interfaces Coupling etric Coupling between coponents is the nuber of other coponents coupled to this coponent. In CBSS, coupling will be defined as: two coponents are coupled if and only if at least one of the acts upon the other. Since coupling is the extent to which the coponents are interdependent, a quantitative easure is to count the way in which one coponent ay dependent on the other. In order to develop a coupling etric, we begin by regarding any CBSS as a directed graph. The coponents coprising CBSS are the vertices in the graph. Suppose such a syste coprises a set of coponents C {C 1, C 2, C }. Let M and V be the sets of ethods and instance variables of coponent C. MV,i is the set of ethods and instance variables in class C i invoked by class C. MV, the set of all ethods and instance variables in other coponents, 1 i and i, that are invoked by coponent C, can be defined [10]:

5 Coplexity Metrics for Coponent-based Software Systes International Journal of Digital Content Technology and its Applications. Volue 5, Nuber 3, March 2011 MV 1 M, i i i MV V (3) There are usually two kinds of coupling: afferent coupling and efferent coupling. Afferent coupling is the nuber of other coponents that depend upon sub-coponents within the coponent and is an indicator of the coponent's responsibility. Efferent coupling is the nuber of other coponents that the sub-coponents in the coponent depend upon and is an indicator of the coponent's independence Cohesion etric Cohesion specifies the siilarity of ethods in a coponent. It is a easure of the extent to which the various functions perfored by a coponent are related to one another. Suppose a coponent such as a class has a set of ethod ebers M (C) { 1, 2, } and a set of instance variables V (C) {v 1, v 2,. v n }. E (C) is the set of pairs (v, ) for each instance variable v in V(C) that is used by ethod in M (C). The cohesion etric for a coponent, also naed as Cohesion of Methods (COM), is defined as: 3.5. Interface etric E ( C ) COM ( C ) (4) V ( C ) * M ( C ) Afferent coupling and efferent coupling can also be represented by coponent interface etric (CIM). CIM is defined as three values: Available nuber of incoing interactions (II). Available nuber of outgoing interactions (OI). A ratio of II to OI, i.e., II / OI. Another interface etric related to a coponent is actual interactions etric (AIM) that easures the interface density in a coponent. AIM is the ratio between the actual nubers of interactions over potential ones: AIM (5) II II OI OI, ax,ax Here, II,ax and OI,ax are axiu nubers of input and output interactions in a coponent. We will use AIM instead of CIM as the interface etric for a coponent in this paper Sole coponent coplexity etric If a sole coponent coplexity etric (SCCM) is required, we ay cobine above three coponent etrics with different weights for each etric. SCCM * * MV * COM AIM (6) where α, β and γ are the weighs for the coupling etric, cohesion and interface etrics of coponent with the condition as α + β + γ =

6 Coplexity Metrics for Coponent-based Software Systes International Journal of Digital Content Technology and its Applications. Volue 5, Nuber 3, March Coponent assebly etric Cobining coponent-level etrics to obtain syste level indicators of quality is a challenging issue. Coponent assebly evaluation can be of two types: qualitative or quantitative. The forer can be perfored by an expert, but is prone to be subective since different experts ay produce conflicting evaluations and the coparison between evaluations perfored on different asseblies is difficult. On the other hand, the quantitative evaluation can be obective and repeatable. Through the usage of well-defined etrics, a quantitative quality odel of CBSS ay facilitate the coparison of the results of evaluations perfored on different asseblies. Having established the easures for the strength of coupling between pairs of coponents, the cohesion degree within the coponents and the interface etrics, the final step is to use the as a basis for the easure of the total coplexity of CBSS. This is readily achieved by suing all the easures and dividing by the total nuber of the coponents in CBSS Syste coupling etric The syste coupling etric (SCOUP) for CBSS will be: SCOUP 1 MV (7) Here MV is the coupling etric for coponent and is the nuber of the coponents in CBSS Syste cohesion etric The syste cohesion etric (SCOH) for CBSS is: SCOH 1 COM (8) Siilarly, COM is the cohesion etric for coponent Syste actual interface etric Based on the easureent of actual interactions for a coponent, syste actual interface etric (SAIM) is the integration of the interface etrics of the total nuber of coponents: SAIM 1 AIM (9) 4.4. Sole syste coplexity etric Siilarly, if we need a sole syste coplexity etric (SSCM), we ay cobine above three syste etrics with different weights for each ites. SSCM '* SCOUP '* SCOH '* SAIM (10)

7 Coplexity Metrics for Coponent-based Software Systes International Journal of Digital Content Technology and its Applications. Volue 5, Nuber 3, March 2011 where α, β and γ are the weighs for syste coupling etric, cohesion and interface etrics with the condition as α + β + γ = Case study Suppose we have a CBSS that consists of four coponents as Fig. 1. We know that there are soe interactions between coponent A and B (both directions), fro A to C (single direction), fro A to D (single direction), between B and D (both directions) and fro D to C (single direction). The relative data are assued aong four coponents as Table 1. Figure 1. A CBSS consisting of four coponents Table 1. Raw coplexity data for the coponents Coponent A B C D II ax OI ax E (C) i M V MV,i MV,i MV,i MV,i A 7 6 3, 2 3, 3 4, B 4 5 2, 4 3, C D 6 5 3, 4 4, Two data for MV,i in Table 1 are the nubers of ethods and instance variables in class C i invoked by class C. According to Fig. 1 and Table 1, we ay calculate the coupling and interface etrics on the levels of the individual coponent CBSS Coupling etrics for the coponent and syste According to (3), we will get the coupling etric for each coponent in CBSS, shown in Table 2. Table 2. Coupling etrics for coponent Coponent A B C D i M V MV,i MV,i MV,i MV,i MV A 7 6 3, 2 3, 3 4, B 4 5 2, 4 3, C D 6 5 3, 4 4, Fro (7), the coupling etric for the syste is: SCOUP 1 MV =

8 Coplexity Metrics for Coponent-based Software Systes International Journal of Digital Content Technology and its Applications. Volue 5, Nuber 3, March Cohesion etrics for the coponent and syste According to (4), we will get the cohesion etric for each coponent in CBSS, shown in Table 3. Table 3. Cohesion etrics for coponent Coponent M V E (C) COM A B C D Fro (8), syste cohesion etric (SCOH) will be: SCOH 1 COM = Interface etrics for the coponent and syste According to the definitions for CIM and AIM, see (5), we will have the interface etric for each coponent in CBSS, shown in Table 4. Table 4. Interface etrics for coponent Coponent / A B C D II OI II /,ax,ax II OI i MV,i MV,i MV,i MV,i OI AIM A 3, 2 3, 3 4, B 2, 4 3, C Null 0.87 D 3, 4 4, Fro (9), syste actual interface etric (SAIM) will be: SAIM 1 AIM = Cobined sole syste coplexity etric If we give the weights for syste coupling, cohesion and interface etrics as 0.5, 0.2 and 0.3, fro (10), we will get the SSCM of the exapled CBSS as: SSCM '* SCOUP '* SCOH '* SAIM = Cobined sole coponent coplexity etric Let s go back to copute the sole coponent coplexity etric (SCCM) for CBSS. Fro Table 2 to Table 4, we will have SCCM etrics for each coponent as Table 5 if we assign the coupling, cohesion and interface weights as 0.5, 0.2 and 0.3, referring to (6)

9 Coplexity Metrics for Coponent-based Software Systes International Journal of Digital Content Technology and its Applications. Volue 5, Nuber 3, March 2011 Table 5. Coplexity etrics for the coponent Coponent MV COM AIM SCCM A B C D Fro Table 5, we know that the coponent D has the highest coplexity etric and needs the ost investent such as tie/cost, while coponent C has the lowest coplexity value. The coplexity etric of coponent B is less than that of coponent A. Siilarly as above coparisons of coplexity etrics aong the coponents, the syste coplexity data fro section 5.1 to 5.4 such as 0.95 (SCOUP), 0.47 (SCOH), 1.18 (SAIM) and 0.92 (SSCM) have hardly any eaning for theselves. However, when such data are used to copare the coplexity levels aong several software systes, the developers will know which CBSS needs ore people and ore tie during the coding and testing stages, or they ay expect the vulnerabilities will happen in which coponent according to the coplexity etrics. 6. Related works Soe proposals for software etrics in CBSS both concerning individual coponents and coponent asseblies have been presented [11]. These proposals provide useful insights on the specificities to consider when developing etrics for CBSS. However they do not contribute with concrete etrics. Several authors ade proposals (coponent centric) for the evaluation of coponent interfaces and dependencies [12]. Hoek et al. proposed etrics to assess service utilization in coponent asseblies. Narasihan and Hendradaya introduced etrics to assess coponent integration density and coponent interface density [13]. All above referred etric proposals included inforal specifications to soe extent. Foralization in software etrics for CBSS has begun. Goulao et al. presented foral definition of coposition assessent etrics for CBSS, using an extension of the CORBA Coponent Model eta-odel as the ontology for describing coponent asseblies [14]. We also ade an attept in foral etrics for CBSS and presented the novel direct and indirect coponent coupling etrics with foral specifications [15]. The coplexity etrics presented in this paper provides foral specifications of software etrics and novel quantitative software easures by cobining coupling, cohesion and interface etrics on the levels of the coponent and CBSS. 7. Conclusions The pressure for reducing software developent life cycles and costs has lead to an increasing interest in CBSS. In order to anage the software increasing coplexity and to axiize the reuse of code, adequate etrics to quantify coponent quality on the levels of both individual coponent and syste are necessary. Though there are soe proposals aiing at establishing requisites and guidelines for CBSS etrics, ost current etrics proposals include inforal specifications. Upon the research on the classical evaluation easures for software systes, we argue that the traditional etrics that ainly rely on the lines of codes are not suitable for CBSS. Therefore we provide an account of novel security easures for coponent and CSS by adequate coupling, cohesion and interface etrics in this paper. Our focuses are to evaluate both individual coponent and assebly relation between coponents at the design stage of CBSS developent life cycle. We believe that our efforts ay help to anage the coplexity of CBSS and to validate the coponent/syste at a very early stage in the software developent process. The case study shows that the ethods presented in the paper are effective by coparing the coplexity etrics for each coponent. We believe the coplexity easures for CBSS ust be also useful in a siilar way

10 Coplexity Metrics for Coponent-based Software Systes International Journal of Digital Content Technology and its Applications. Volue 5, Nuber 3, March 2011 The software etrics research for CBSS is still in the early stages in the long run. We will continue our effort in software etrics for CBSS such as to optiize the coupling etric by cobining indirect coupling into direct coupling. More epirical research by applying our novel etrics in the real CBSS systes is also one of our future works. 8. Acknowledgent This study has been carried out as a part of the proect High perforance coputing of realistic fluid based on GPU, financed by the National Nature Science Foundation of China (Grant No ). The research was supported by 2010 returned scholar scientific activity proect selective assistance with the proect title as Research of P2P Network Security Based on Natural Coputation and Trust Manageent, which was funded by the Departent of Huan Resources and Social Security of Zheiang Province. This work was also supported by the key course proect, high education proect and the scientific research startup proect of China Jiliang University Jiliang University, Natural Sciences and Engineering Research Council of Canada and Fond Québécois de recherché sur la nature et les technologies. The coents fro three colleagues are also gratefully acknowledged. 9. References 1. V. P. Venkatesan, M. Krishnaoorthy, A Metrics Suite for Measuring Software Coponents, JCIT, Vol. 4, No. 2, pp , S. Jing, C. Jiang, "An Approach to Predict Perforance of Coponent-based Software with the Palladio Coponent Model and Stochastic Well-fored Nets", AISS, Vol. 2, No. 1, pp , A. A. Toptsis, J. Eilrazan, Cognitive and Usability Perspectives in Software Platfor Libraries, JNIT, Vol. 1, No. 2, pp , L. Kharb, R. Singh, Coplexity etrics for coponent-oriented software systes, ACM SIGSOFT Software Engineering Notes, vol. 33, no. 2, pp.1-3, I. Chowdhury, M. Zulkernine, Can Coplexity, Coupling, and Cohesion Metrics be Used as Early Indicators of Vulnerabilities?, In Proceeding(s) of the SAC 10, pp , T. McCabe, A coplexity easure, IEEE Transactions on Software Engineering, vol. 2, no. 4, pp , C. R. Syons, Function Point Analysis: Difficulties and Iproveent, IEEE Transactions on Software Engineering, vol. 14, no. 1, pp:2-11, M Boxall, S Araban, Interface Metrics for Reusability Analysis of Coponents, Australian Software Engineering Conference (ASWEC'2004), Melbourne, Australia, N. S. Gill, P.S. Grover, Coponent-Based Measureent: Few Useful Guidelines, ACM SIGSOFT Software Engineering Notes, vol. 28, no. 6, pp:1-6, S. R. Chidaber, C. F. Keerer, A Metrics Suite for Obect Oriented Design, IEEE Trans. on Software Eng., vol. 20, no. 6, pp , G. Gui, P. D. Scott, Measuring Software Coponent Reusability by Coupling and Cohesion Metrics, Journal of Coputers, vol. 4, no. 9, pp , S Sedigh-Ali, A Ghafoor, R Paul, Software Engineering Metrics for COTS-Based Systes, IEEE Coputer, vol. 34, no. 5, pp.44-50, V. Narasihan, B. Hendradaya, A New Suite of Metrics for the Integration of Software Coponents, the First International Workshop on Obect Systes and Software Architectures (WOSSA'2004), South Australia, Australia, M. Goulao, F. Abreu, Coposition assessent etrics for CBSS, Software Engineering and Advanced Applications, 31st EUROMICRO, pp , J. Chen, W. K. Yeap, S. D. Bruda, A Review of coupling Metrics for Coponent-Based Developent, In Proceedings of 2009 World Congress on Software Engineering (WCSE 2009), vol. 4, pp.65-69,