本文挡描述的是Logiscope——Audit中函数作用域常用度量元的具体含义。

对每个度量元的解释分为以下几部分：

首先是该度量元的原文名称，后面是该度量元的代号，跟在后面的是Audit质量模型为该度量元设的参考值（用中括号括起。当然，对于这个范围值，我们可以对它进行修改），再往下就是对该度量元含义的具体解释。

2函数度量元

下面分别介绍函数作用域中各个度量元的具体含义。注意，下面讨论的所有问题都是站在一个函数的角度上的，这一点对于我们理解这些度量元很重要。

2.1 "Cyclomatic Number" : ct_vg       [ 1   ,  10 ]      

度量元名称：函数的圈复杂度。

解释说明：

函数圈复杂度的计算方法为：将函数流程图中各节点（开始和结束结点除外）的引出边的数量减去一后的值相加，最后再在这个和的基础上加一。可见，当一个函数中条件判断的地方越多时，它的ct_vg就会越大。

如果该值过大，会增大函数的复杂性，影响我们对函数的理解。

2.2 "Number of Branches" : ct_bran    [ 0 ,   0 ]     

度量元名称：函数中非结构化语句的数量。

解释说明：

非结构化语句包括：goto语句、在循环中使用的break、continue语句。

该度量元是为了使程序编写符合结构化的要求。

2.3 "Number of Declared Variables" : dc_lvars    [  0  ,   5 ]

度量元的名称：函数中定义的变量的数量。

解释说明：

在函数体内部定义的变量的数量。函数中局部变量定义的过多，会增大代码的复杂性，影响对函数的理解。

2.4 "Number of parameters" : ic_param       [ 0   ,   5 ]

度量元的名称：函数参数的数量。

解释说明：

函数的参数过多，会使函数易于受外部（其他部分的代码）变化的影响，从而影响维护工作。

函数的参数过多也会增大测试的工作量。

2.5 "Number of Direct Calls" : dc_calls    [ 0 ,   5 ]

度量元的名称：函数中调用其它函数的数量。

解释说明：

在函数体中调用其它函数的数量，对同一函数的多次调用计为一次。

该值过大，首先是会使函数易于受外部（其他部分的代码）变化的影响，从而增加维护工作的工作量。

其次，该值过大，也会增加阅读程序的人在理解程序上的困难。

2.6 "Number of Exits" : ct_exit    [ 0  ,   1]

度量元的名称：函数出口的数量。

解释说明：

也就是函数体中退出点的数量。

在一个函数中存在一个以上的出口会增加函数出错的可能性，建议单出口。

2.7 "Number of Distinct Uses of External Attributes" : ic_varpe    [ 0 ,  2 ]

度量元的名称：函数中使用其它类的数据成员的数量。

解释说明：

所谓函数中使用的其它类的数据成员的数量，也就是在函数体中对外部类（与该函数所属的类不是同一个类）的数据成员的使用数量，对同一数据成员的多次使用计为一次。

这个度量元的用意也很好理解，就是为了尽量减少函数与其它类的耦合关系。

2.8 "Number of paths" : ct_path    [ 1  ,   60 ]

度量元的名称：函数中执行路径的数量。

解释说明：

函数中执行路径过多，会极大的增大测试的工作量。

2.9 "Number of Statement"  : lc_stat [  1 ,  20 ]

度量元的名称：函数中的可执行语句数.

解释说明：

函数中的可执行语句数过多，意味着函数的功能可能不单一，同时也会增加函数的复杂性。

2.10 "Average size of statements"    :  AVGS    [  1.00 ,   9.00 ]

度量元的名称：语句平均承载的信息量。

解释说明：

该度量元计算在一个函数中，平均每个可执行语句所包含的操作符和操作数的数量。

该度量元的计算公式为：

AVGS = (N1 + N2) / (lc_stat )

其中：

         N1 是该函数中的操作符的数量,

         N2 是该函数中的操作数的数量,

         lc_stat  是函数中可执行语句的数量.

如果平均每个可执行语句所包含的操作符和操作数的数量较多时，也就是说当程序语句比较长时，会增大阅读者理解程序的难度。应该将较长的语句分解为几个较短的语句，以此来降低程序的复杂性。

2.11 "Vocabulary frequency":  VOCF                  [  1.00   ,   4.00 ]

度量元的名称：词汇频率。

解释说明：

    该度量元表示的是在一个函数中，相同的操作符和操作数出现的频率。

该度量元的计算公式为：

VOCF = (N1+N2) / (n1+n2)

其中：

       N1 是该函数中的操作符的数量，包括重复出现的；

       N2 是该函数中的操作数的数量，包括重复出现的；

       n1 是该函数中不同的操作符的数量,

       n2 是该函数中不同的操作数的数量,

当一个函数VOCF的值较高时，说明在这个函数中可能包含重复的或类似的语句。如果确实是这种情况，建议将这些反复使用的语句分离出来，写成一个单独的函数，从而增加了程序的简明、清晰程度，也为以后修改这个函数带来了方便。

2.12 "Comments frequency": COMF [  0.20  ， +oo ]

度量元的名称：函数的注释比率。

解释说明：

    函数中的注释块的数量与函数中的可执行语句的数量之比。

该度量元的计算公式为：

COMF = (lc_bcom + lc_bcob) / (lc_stat )

其中：

       lc_bcom 是函数体中注释块的数量,

       lc_bcob 是函数体前注释块的数量（值只能为 0 或 1）,

       lc_stat  是函数中可执行语句的数量.

这个度量元能反映出程序的开发者是否对程序进行了认真的注释。如果函数的注释写的比较充分，那么在我们进行测试工作和维护工作需要理解程序代码时是非常有用的。

这个度量元检测的是注释块的数量，而不是注释行的数量，这种注释量的计算方法我认为更科学。

2.13 "Number of levels":   LEVL = ct_nest + 1          [ 1 ，4 ]

度量元的名称：函数中具有嵌套的控制结构的最大的嵌套层数再加一。

解释说明：

该度量元的计算公式为：

LEVL = ct_nest + 1

其中：ct_nest：函数中控制结构嵌套的最大嵌套层数。

函数中具有嵌套的控制结构的最大的嵌套层数再加一。该值越大，说明函数越复杂，越难于理解。

2.14 "Fan In": FAN_IN        [  0   ，4 ]

度量元的名称：扇入

解释说明：

该度量元的计算公式为：

FAN_IN = ic_usedp + ic_varpi

其中：       ic_usedp 是函数参数的个数；

        ic_varpi 是函数对本类中数据成员的使用次数。

这个度量元反映的是函数需要输入的数据量。 如果函数需要输入的数据过多，那么阅读者对函数进行理解时会变的困难，并且外部变化对函数的影响也会较大。

2.15 "Fan Out": FAN_OUT    [  0  ，     4 ]

度量元的名称：扇出

解释说明：

该度量元的计算公式为：

FAN_OUT = ic_paradd +ic_varpe

其中：       ic_paradd  是传址参数的个数；

ic_varpe   是函数对外部类数据成员的使用次数。

这个度量元反映的是函数的输出数据量。如果函数输出的数据量过多，那么对这个函数进行理解分析时会很困难。同时，函数输出的数据量越大，这样的函数对系统的影响也会越大，所以应该加以限制。

2.16 " Number of callers ": dc_calling   [  0  ， 7 ]

度量元的名称：被调用次数

解释说明：

该项度量元表示的是：调用了该函数的函数的个数。

一个函数，调用它的函数越多，则对该函数的可靠性要求的越高，它一旦发生问题，引发的后果就越严重。系统中这样的函数越多，出现问题的可能性就越大，所以应该加以限制。

2.17 "Number of relative call graph levels": cg_levels   [  1  ， 12 ]

度量元的名称：调用层次数

解释说明：

该项度量元表示的是：在该函数的调用关系图中，函数调用关系的层次数。

比如图2-1的这个的函数调用关系图中，函数Fun2( )的cg_levels的值为3。

图 2-1 函数调用关系图

2.18 "Relative call graph Hierarchical complexity": cg_hiercpx   [  1.0  ， 5.0 ]

度量元的名称：每层平均函数个数

解释说明：

该项度量元表示的是：在该函数的调用关系图中，平均每一层上的函数个数。

比如图2-1的函数调用关系图中，函数Fun2( )的cg_hiercpx的值为4 / 3 = 1.3。

2.19 " Relative call graph Structural complexity ": cg_strucpx   [  0.0  ， 3.0 ]

度量元的名称：函数平均调用数量

解释说明：

该项度量元表示的是：在函数的调用关系图中，每个函数的平均调用数量。

比如图2-1的函数调用关系图中，函数Fun2( )的cg_strucpx的值为3 / 4 = 0.75。

2.20 "Number of relative call graph call-paths":IND_CALLS   [  1  ， 30 ]

度量元的名称：调用路径数量

解释说明：

该项度量元表示的是：在该函数的调用关系图中，从该函数到每个叶子函数的不同路径数量之和。

比如图2-1的函数调用关系图中，函数Fun2( )的IND_CALLS的值为2。

2.21 "Relative call graph System testability":cg_testab   [  0.0  ， 1.0 ]

度量元的名称：函数调用关系的易测性

解释说明：

该项度量元表示的是：对该函数的函数调用关系进行测试时的工作量。

本文挡描述的是Logiscope——Audit中常用的系统度量元的具体含义。

对每个度量元的解释分为以下几部分：

首先是该度量元的原文名称，后面是该度量元的代号，跟在后面的是Audit质量模型为该度量元设的参考值（用中括号括起。对于这个范围值，我们可以对它进行修改），再往下就是对该度量元含义的具体解释。

2系统度量元

下面介绍系统作用域中各个度量元的具体含义。注意，下面讨论的所有问题都是站在整个系统（或子系统）的角度上的，这一点对于我们理解这些度量元很重要。

2.1 "Coupling Factor" : ap_cof     [0.03 ,   0.18]

度量元名称：类耦合因素。

解释说明：

该度量元的计算方法为：

                   类的总数

ap_cof = （∑ Ci与其他的类发生耦合关系的数量）/ 类的总数*（类的总数 — 1）

                     i = 1

( 注：Ci表示第i个类 )

当某一个类有以下情形之一时，该类与其他类的耦合关系的数量加一：

       1 在该类的类函数中调用了另一个类的成员函数。

       2 该类通过友员的方法调用另一个类中的可见或不可见的函数。

       3 在该类中调用了另一个类的构造/析构函数。

       4 该类中将另一个类作为数据成员或作为类函数中的参数。

2.2 "Method Inheritance Factor" : ap_mif  [ 0.6 ,   0.8]

度量元名称：类函数继承的比率。

解释说明：该度量元是一个比值。

分子为：在系统所有类的成员函数中，由父类继承来的成员函数的数量总和。

分母为：系统所有类的成员函数的总和（包括自己定义的和从父类继承而来的）。

2.3 "Attribute Inheritance Factor" : ap_aif  [0.3 ,  0.6]

度量元名称：类数据成员继承的比率。

解释说明：  该度量元是一个比值。

分子为：在系统所有类的数据成员中，由父类继承来的数据成员的数量总和。

分母为：系统所有类的数据成员的总和（包括自己定义的和从父类继承而来的）。

2.4 "Polymorphism Factor" : ap_pof     [ 0.3 ,   1.0 ]

度量元名称：类的多态性因素。

解释说明：该度量元是一个比值。

分子为：在系统所有类的成员函数中，重载的函数的数量总和。

分母为：

                系统中类的总数

∑（Ci中未被重载的成员函数的数量* Ci子类的个数）

                  i = 1

( 注：Ci表示第i个类 )

2.5  "Attribute Hiding Factor" : ap_ahf [0.7 1.0 ]

度量元名称：类对其数据成员的保护程度。

解释说明：该度量元是一个比值。

分子为：在系统所有类的数据成员中，属于Private型数据成员的总数。

分母为：系统所有类的数据成员的总和。

2.6 "Average coupling between objects": AVG_CBO           [0.0 , 10.0 ]

度量元名称：系统中类耦合的平均值。

解释说明：

计算公式为：

AVG_CBO = ap_cbo / ap_clas

其中：ap_cbo 的值由以下两部分组成：

1在一个类的成员函数中调用不属于该类的函数，在系统中，这种情况出现一次，ap_cbo的值加一。

            2类中类类型数据成员的数量。在系统中，这种情况出现一次，ap_cbo的值加一。

         ap_clas：系统中类的数量。

如果该值过高，则说明系统中类与类之间的耦合较强，这会使对系统进行更改工作时变的非常困难。

2.7 "Number of Levels in the Inheritance Graph" : ap_inhg_levl     [ 1 ,  4 ]

度量元名称：类继承图的深度。

解释说明：在系统中所有的类继承图中，最大继承层次的数量。

2.8 "Method Hiding Factor" : ap_mhf [ 0.1 ， 0.4 ]

度量元名称：类成员函数的私有情况。

解释说明：

该度量元的计算公式为：

                               类总数 类i中函数个数

ap_mhf =（∑ [ ∑（ 1 – V( m ) ）]）/ （系统中类成员函数数量的总和）

                                     i = 1  m=1

其中V( m )的值为：

    当该函数为 public型时，V( m ) = 1

    当该函数为 private型时，V( m ) = 0

    当该函数为 protected型时，V( m ) = ( 由该类派生的类的个数 ) /（类总数 – 1 ）

2.9 "Hierarchical Complexity of the Inheritance Graph" : ap_inhg_cpx    [ 1.0 ,  2.0 ]

度量元名称：类继承图的层次复杂性。

解释说明：

它的计算公式为：

ap_inhg_cpx == SUM( N * I ) / SUM( N )

其中：SUM表示取和，       I为类继承图中的层次序号（1，2，3…），N 为继承图中第I层中的结点个数。例如下面这样的一个继承关系：

 

则 ap_inhg_cpx = （ 1* 1 + 2*3 + 3*1 ）/ （1 +  3  +  1 ）= 2.0。由计算公式可以看出，多继承很影响该度量元的得分，所以尽量避免多重继承。

该度量元是类继承关系的图形结构的表示，它的目的是测量类继承关系的复杂性。如果改值大于二，则表明类的继承关系过于复杂。

2.10 "Ratio of repeated inheritances in the application": URI_Ratio       [ 0.0 ,  10.0 ]

度量元名称：重复继承的类的数量占系统中类继承关系数量的比率。

解释说明：重复继承的类的数量占系统中类继承关系数量的比率。

该度量元的计算公式为：

URI_Ratio = (ap_inhg_uri * 100) / ap_inhg_edge

其中：ap_inhg_uri ：系统中重复继承的“类对”的数量。

          ap_inhg_edge：系统中类的继承关系图中边的数量。

那么，何为重复继承呢？重复继承指某一个类对同一个类继承两次。下面举一个例子。

比如：

 
在这个例子中, 类E通过类对 (B,C)、(C,D)、(B,D)对类A重复继承。则ap_inhg_uri的值为3。ap_inhg_edge的值为6。所以URI_Ratio = (3 * 100) / 6 = 50.0

过多的重复继承会导致程序变的复杂，还可能发生函数命名冲突（ 类E中的函数就可能会有命名冲突）。所以在组织程序时，提倡单继承，避免使用多继承类。

2.11 "Percentage of non-member functions": NMM_Ratio    [ 0.0 ,  10.0 ]

度量元名称：独立于类的函数的比率。

解释说明：

系统中非成员函数（独立于类的函数）占系统中函数总数的比率。

该度量元的计算公式为：

NMM_Ratio =( ( ap_func - ap_nmm )  /  ap_func) * 100

其中：ap_func：系统中总的函数数量（包括游离于类之外的全局函数）。

          ap_nmm ：系统中各个类的成员函数的数量之和。

如果该度量元的值过大的话，说明该程序设计不符合面向对象的思想。

2.12  "Average of the VG of the application's functions":  AVG_VG     [ 1.0 ,  5.0 ]

度量元名称：系统中每个函数的平均圈复杂度。

解释说明：

该度量元的计算公式为：

AVG_VG = ap_vg / ap_func

其中：ap_vg  ：系统中各函数的圈复杂度的总和（关于函数的圈复杂度的计算方法请参见〈〈Logiscope函数度量元〉〉文挡）。

      ap_func：系统中函数的数量（包括成员函数和非成员函数）

如果该值过高，则说明系统中有大量函数的圈复杂度的值过高，也就是说系统中有大量过于复杂的函数。由于函数的复杂性过高，对于系统的维护工作是很不利的。

2.13  " Ratio of recursive edges on the call graph ":  RECU_Ratio     [ 0.0 ,  5.0 ]

度量元名称： 递归调用的百分比。

解释说明：

该度量元的计算公式为：

RECU_Ratio = (ap_cg_cycle * 100) / ap_cg_edge

其中：

ap_cg_cycle  ：函数调用流程图中递归调用的数量。

    ap_cg_edge  ：函数调用流程图中边的数量。

2.14  " Number of Levels in the Call Graph ":  ap_cg_levl     [ 2 ,  9 ]

度量元名称： 函数调用流程图的最大层次数。

解释说明：

在系统所有的函数调用流程图中，最大的层次数。

本文挡描述的是Logiscope——Audit中常用的类度量元的具体含义。

对每个度量元的解释分为以下几部分：

首先是该度量元的原文名称，后面是该度量元的代号，跟在后面的是Audit质量模型为该度量元设的参考值（用中括号括起。当然，对于这个范围值，我们可以对它进行修改），再往下就是对该度量元含义的具体解释。

2类度量元

下面分别介绍类作用域中中各个度量元的具体含义，注意，下面讨论的所有问题都是站在一个类的角度上的，这一点对于我们理解这些度量元很重要。

2.1 "Class Comments Frequency": COMFclass      [ 0.2,  +oo ]

度量元的名称：类注释频度

解释说明：

该度量元表示类中注释的频度。所谓类的注释，只限于类定义的中的注释，不包括类实现中的注释。

该度量元的计算公式为：

COMFclass =

(cl_bcom + cl_bcob) / (cl_func_publ + cl_func_prot + cl_data_prot + cl_data_publ)

其中：

cl_bcom：     类前的注释数量（只能为1或0）

cl_bcob：     类定义中的注释数量

cl_func_publ：类中public成员函数的数量

cl_func_prot：类中protected成员函数的数量

cl_data_prot：类中protected数据成员的数量

cl_data_publ：类中public数据成员的数量

2.2 "Fan out value of a class":   FAN_OUTclass   [ 0,  20 ]

度量元的名称：类的扇出值。

解释说明：

该度量元的计算公式为：

FAN_OUTclass = cl_data_prot + cl_data_publ +cl_usedp + cl_data_vare

其中：cl_data_prot： 类中protected数据成员的数量之和，

          cl_data_publ： 类中public数据成员的数量之和,

          cl_usedp：    类函数所使用的参数的数量之和，

cl_data_vare   类函数中使用的外部类的数据成员的数量之和。

   这个度量元反映了类对外的数据输出量，其值越大，就说明这个类对整个系统的影响越大。

2.3 "Fan in of a class":   FAN_INclass       [ 0,  15 ]

度量元的名称：类的扇入值。

解释说明：

该度量元的计算公式为：

FAN_INclass = cl_data_prot + cl_data_publ + cl_usedp + cl_data_vari

其中：

cl_data_prot： 类中protected数据成员的数量，

      cl_data_publ： 类中public数据成员的数量,

      cl_usedp：    类函数所使用的参数的数量之和，

cl_data_vari： 类函数中使用本类的属性的次数之和

    这个度量元反映了类通过其数据成员和成员函数参数而引进的数据输入量，其值越大，该类日后需要频繁修改的可能性就越大。

2.4 "Number of Dependent Methods" : cl_dep_meth  [0,  6 ]

度量元的名称：类对其他模块的依赖性。

解释说明：

该度量元表示，在一个类中，要依赖于本类之外的其他模块才能实现功能的类函数的个数。符合这样的条件的函数包括：

1 在该函数中调用了其它类的类函数。

         2 在该函数中使用了其它类的数据成员。

         3 在该函数的参数中有其它类的类类型的参数。

         4 在该函数中有一个其它类的类类型的变量。

该度量元的目的是控制类与类之间的耦合程度。

2.5 "Number of Base Classes" : in_bases    [ 0,  3 ]

度量元的名称：基类的数量

解释说明：

该类基类的数量，基类包括其类继承图中所有的父类。当MFC类库中的类作为父类时，则该MFC类的基类的数量不再计入其中。在下图中，class 4的in_bases为4。

2.6 "Weighted Methods Per Class" : cl_wmc  [ 0,   25 ]

度量元的名称：类的圈复杂度。

解释说明：

类中各个成员函数的圈复杂度的总和（关于函数的圈复杂度的计算方法请参见〈〈Logiscope函数度量元〉〉文挡）。

2.7 "Specializability":SPECIAL [ 0,  25 ]

度量元的名称：类功能的专一性。

解释说明：

该度量元的计算公式为：

SPECIAL =  

2 * ( cl_data_publ + cl_data_prot )  +  cl_func_publ + cl_func_prot + 10 *in_bases

其中：cl_data_publ：类中public型的数据成员的数量。

          cl_data_prot：类中protected型的数据成员的数量。

          cl_func_publ：类中public型的成员函数的数量。

          cl_func_prot  类中protected型的成员函数的数量。

          in_bases：    该类的基类的数量（包括直接基类的基类）。

2.8 "Usability": USABLE      [ 0,  10 ]

度量元的名称：类的易用性。

解释说明：

该度量元的计算公式为：

USABLE = (2 * cl_data_publ) + cl_func_publ

其中：

cl_data_publ：      类中public型的数据成员的数量

cl_func_publ：     类中public型的成员函数的数量

该度量元表示了类对外的接口情况，类对外的接口越多，掌握、使用这个类就越困难。

2.9 "Encapsulation rules":   ENCAP       [ 0,  5 ]

度量元的名称：类的封装性。

解释说明：

该度量元的计算公式为：

ENCAP = cl_data_publ + cl_data_vare

其中：cl_data_publ：类中public型的数据成员的数量

          cl_data_vare：在类成员函数中使用的外部类的数据成员的次数之和

2.10 "Number of Direct Users Classes" : cu_cdusers [  0  ,    4  ]

度量元的名称：被其他类使用的次数。

解释说明：

该类被其他类使用的次数 (被同一个类多次使用计为一次).

2.11 "Class Coupling" : cl_cobc    [ 0,  12 ]

度量元的名称：类耦合

解释说明：

该度量元的值，包括以下几种情况之和：

        1 该类直接基类的数量

        2 该类中类类型的数据成员的数量

        3 调用了静态成员函数的成员函数的数量的二倍。

        4有类类型参数的类成员函数的数量的二倍。

        5有类类型变量的类函数数量的三倍。

2.12 "Number of Children" : in_noc     [ 0,  2 ]

度量元的名称：派生类数量。

解释说明：从该类派生的类的数量。只计直接派生类的数量，间接派生不算在内。

2.13 "Rate of class autonomy ": AUTONOM  [30.0,  100.0 ]

度量元的名称：类自治的程度。

解释说明：

该度量元的计算方法为：与其它的类没有牵扯关系的类函数和类数据成员的数量之和，再除以类函数和类数据成员的数量之和的百分比。

该度量元的计算公式为：

AUTONOM =

  100 * ((cl_func_priv + cl_func_prot + cl_func_publ - cl_dep_meth) +

  (cl_data_prot + cl_data_publ + cl_data_priv - cl_data_class))  /

  (cl_func_priv + cl_func_prot + cl_func_publ + cl_data_priv + cl_data_prot + cl_data_publ)

其中：

cl_func_priv ：        类中private型的成员函数的数量。

      cl_func_prot ：        类中protected型的成员函数的数量。

      cl_func_publ ：        类中public型的成员函数的数量。

      cl_data_prot ：         类中protected型的数据成员的数量。

      cl_data_publ ：         类中public型的数据成员的数量。

      cl_data_priv ：         类中private型的数据成员的数量。

      cl_data_class：         类中类类型数据成员的个数.

      cl_dep_meth：          类函数中要依赖本类之外的函数的个数， 这样的函数是指：

                                1 该函数使用了其他类的数据成员

                                2 在该函数中调用了其他类的函数

                                3 该函数有一个其他类类型的实体对象的参数

                                4 该函数中有一个其他类的类类型的变量

2.14  "Number of used Classes" : cu_cdused      [ 0,  4 ]

度量元的名称：使用其它类的数量

解释说明：

在该类中直接使用的其它类的数量。多次使用同一个类计为一次。

2.15 "Testability": TESTAB    [ 0,  100 ]

度量元的名称：易于测试性。

解释说明：

该度量元的计算公式为：

TESTAB =

    cl_fprot_path + cl_fpriv_path + cl_fpubl_path + cl_data_vare + cl_func_calle

其中：

cl_fprot_path：  类中所有的protected型函数的执行路径总和，

cl_fpriv_path：  类中所有的private型函数的执行路径总和，

cl_fpubl_path：  类中所有的public型函数的执行路径总和。

cl_data_vare ：  类函数中使用的外部类的数据成员的次数之和，

      cl_func_calle：  类函数中对类外部的函数的调用次数之和，

通过观察该度量元的各个组成元素，我们会发现这些都是会对我们需要制定测试用例的数量产生重要影响的数据。

本文介绍了Logiscope——Audit对应于软件质量模型，在质量因素级、质量标准级上的具体实现。需要说明的是，文档中描述的质量模型只涉及了可维护性这个质量因素。根据情况，我们可以制做出不同的质量模型。这篇文档的目的是为了能让大家更好的了解Audit对软件质量模型的实现。

2 质量因素

我们先说质量因素这一级。每个质量因素都由若干个质量标准按权重相加组成。关于这些质量标准的含义，请看本文档第三部分的内容。

2．1 函数作用域

2.1.1函数的可维护性质量因素

该质量因素表示：对函数进行修改时，为防止引发错误，所需要做的工作的难度。其计算公式为：

function_MAINTAINABILITY  =    function_ANALYZABILITY

                                + function_CHANGEABILITY

                                + function_STABILITY

                                + function_TESTABILITY

2.1.2 函数调用复杂性质量因素

该质量因素表示：对函数进行修改时，为防止引发错误，所需要做的工作的难度。其计算公式为：

relativeCall_MAINTAINABILITY  =   relativeCall_ANALYZABILITY

                                      + relativeCall_STABILITY

                                      + relativeCall_TESTABILITY

2．2 类作用域

2.2.1 类的可维护性质量因素

该质量因素表示：对类进行修改时，为防止引发错误，所需要做的工作的难度。其计算公式为：

class_MAINTAINABILITY  =   class_ANALYZABILITY

                            + class_CHANGEABILITY

                            + class_STABILITY

                            + class_TESTABILITY

2.2.2 类的可复用性质量因素

可复用性是指类是否能够被比较容易的复用。其计算公式为：

class_REUSABILITY  =   class_USABILITY

                           + class_SPECIALIZABILITY

                           + class_ANALYZABILITY

2．3 系统作用域

2.3.1系统的可维护性质量因素

该质量因素表示：对程序代码进行修改时，为防止引发错误，所需要做的工作的难度。其计算公式为：

application_MAINTAINABILITY  =  application_ANALYZABILITY

                                    + application_CHANGEABILITY

                                    + application_STABILITY

                                    + application_TESTABILITY

3 质量标准

下面我们讨论软件质量模型中质量标准这一级。质量标准组成了我们上面说到的质量因素。每个质量标准都是由若干个质量度量元按权重相加组成的。关于组成各个质量标准的度量元的含义，请看《Logiscope-Audit函数度量元》、《Logiscope-Audit类度量元》、《Logiscope-Audit系统度量元》这3篇文章的内容。

3．1 函数的质量标准

3.1.1 函数易于测试性质量标准

该质量标准表示：函数被修改后，为保证系统不发生错误，需进行测试的工作量。计算公式为：

function_TESTABILITY  =  dc_calls  +  LEVL  +  ct_path  +  ic_param

3.1.2 函数稳定性质量标准

该质量标准表示：函数之外的代码发生变化之后，导致函数发生错误的可能性。计算公式为：

function_STABILITY  =  dc_calling  +  ic_varpe  +  ct_exit  

+  dc_calls + ic_param

3.1.3 函数适应变化性质量标准

该质量标准表示：当需要更改函数代码、修正函数代码缺陷时，需做的工作量。计算公式为：

function_CHANGEABILITY  =  ic_param  +  dc_lvars  + VOCF  +  ct_bran

3.1.4 函数易于分析性质量标准

该质量标准表示：理解函数所需花费的脑力劳动量，也就是函数的复杂程度。计算公式为：

function_ANALYZABILITY  =  ct_vg  +  lc_stat  +  AVGS  +  COMF

3.1.5 函数调用可分析性质量标准

该质量标准表示：理解函数的相互调用关系所需花费的脑力劳动量。计算公式为：

relativeCall_ANALYZABILITY  =  cg_strucpx  +  cg_levels

3.1.6函数调用稳定性质量标准

该质量标准表示：对程序（包括本函数体中的代码以及其他函数体中的代码）进行修改时，导致引发意想不到的错误的可能性。其计算公式为：

relativeCall_STABILITY  =  IND_CALLS  +  cg_hiercpx

3.1.7函数调用易于测试性质量标准

该质量标准表示：为了验证程序的正确性，所需测试工作的工作量。其计算公式为：

relativeCall_TESTABILITY  =  cg_testab  +  IND_CALLS

3．2 类的质量标准

3.2.1类可分析性质量标准

该质量标准表示：为了理解类的功能，所需付出的脑力劳动量。其计算公式为：

class_ANALYZABILITY  =  cl_wmc  +  in_bases  +  cl_dep_meth 

+  FAN_Inclass  +  FAN_OUTclass  +  COMFclass

3.2.2 类适应变化性质量标准

该质量标准表示：当需要对类进行修改时，所需付出的工作量。其计算公式为：

class_CHANGEABILITY  =  ENCAP  +  USABLE  +  SPECIAL

3.2.3 类稳定性质量标准

该质量标准表示：当需要对程序进行修改时，为了防止发生错误所需付出的工作量。其计算公式为：

class_STABILITY  =  AUTONOM  +  in_noc  +  cl_cobc  +  cu_cdusers

减少类与类之间的耦合，提高类的封装程度，会提高类的稳定性。

3.2.4 类易于测试性质量标准

该质量标准表示：为了验证程序的正确性，所需测试工作的工作量。其计算公式为：

class_TESTABILITY  =  in_bases  +  TESTAB  +  cu_cdused

3.2.5 类易于使用性质量标准

该质量标准表示：类是否能被使用者容易的理解和方便、安全的使用。其计算公式为：

class_USABILITY  =  USABLE  +  ENCAP  +  AUTONOM

3.2.6  类功能专一性质量标准

该质量标准用于检验类的可复用性。其计算公式为：

class_SPECIALIZABILITY  =  SPECIAL  +  ENCAP  +  AUTONOM

3．3 系统的质量标准

3.3.1 系统可分析性质量标准

该质量标准表示：系统的复杂程度，即系统是否能被较容易的理解。其计算公式为：

application_ANALYZABILITY  =  ap_inhg_levl  +  AVG_CBO  +  ap_aif  

+  ap_mif  +  ap_cof  +  RECU_Ratio

3.3.2 系统适应变化性质量标准

该质量标准表示：当需要对程序进行修改时，为了防止发生错误所需付出的工作量。其计算公式为：

application_CHANGEABILITY  =  ap_inhg_levl  + URI_Ratio + NMM_Ratio

+  ap_pof  +  ap_mif

3.3.3  系统稳定性质量标准

该质量标准表示：当需要对对系统进行修改时，系统发生错误的可能性。其计算公式为：

   application_STABILITY  =  AVG_CBO  +  ap_inhg_cpx  +  ap_mhf 

   +  ap_ahf  +  ap_cof

系统中的各模块之间的耦合越少，则系统的稳定性越好。

3.3.4  系统易于测试性质量标准

该质量标准表示：为了验证系统功能的正确性，所需测试工作的工作量。其计算公式为：

application_TESTABILITY  =  AVG_VG  +  NMM_Ratio  +  ap_mhf  

       +  ap_ahf  +  ap_cg_levl

依照《xx公司编码规范》的要求，测试中心对[被测系统或模块的名称]编码的规范性进行检查。对于编码中不符合《xx公司编码规范》要求的地方，进行报告。

表1-1 背景说明

2检测结果

    下面以表格的形式分别列出各个程序文件中违反《xx公司编码规范》的代码。其中，“编码规范编号”、“编码规范名”指的是该规范在《xx公司编码规范》中的编号和名称，“行号”指违反规范的代码在程序文件中的行号。

2.1文件1

表2-1 文件1中违反编码规范之处

2.2文件2

表2-2 文件2中违反编码规范之处