在Audit的内部定义了大量的质量度量元,度量元是检验一个软件质量好坏的最基本元素。在Logiscope提供的这个默认质量模型文件中,选取的度量元都是为最后评价可维护性提供服务的。通过观察Logiscope.ref质量模型文件,你会发现,度量元都可以量化为数字,允许我们在质量模型文件中为每个度量元设定上限值和下限值。当某一度量元超出我们设定的上限值和下限值的范围时,Audit就认为被检测的代码在该项度量元上不符和要求。
下面举一个度量元的例子:lc_stat度量。该度量元表示函数中可执行语句的数量。lc_stat度量元对于衡量函数的复杂性是很有用的,比如我们可以设定它的上限值为30,下限值为0,即我们规定了:一个函数中可执行的语句数不能超过30条。这就是Audit对质量模型中度量元级的处理方法。
通过这一个个单独的度量元,我们还不能判断程序的可维护性如何,因为过于片面,只有将这些度量元按某种规则组织起来,才能对软件的可维护性作出评价。通过观察Logiscope.ref这个质量模型文件我们会发现,每个质量标准都是由若干个度量元按权相加组成的,质量标准最后也用数字来表示它自己的值。通过质量标准值的大小,Audit给出程序代码遵守该项质量标准的级别。级别共有四个,由高到底依次是 EXCELLENT(优秀)、GOOD(良好)、FAIR(合格)、POOR(不合格)。下面从Logiscope.ref文件中摘录一段,作为如何计算质量标准的例子:
这个质量标准是评价函数的稳定性的。最上面一行是这个质量标准的计算公式:
function_STABILITY = ic_varpe + ct_exit + dc_calls + ic_param
该公式表明,该质量标准由四个度量元所决定,即ic_varpe 、ct_exit、dc_calls、ic_param,每个度量元的权重均为1。该质量标准的最高得分为4分,即当构成该质量标准的四个度量元的值均在我们设定的范围内时,该项质量标准得分为4分,当有三个度量元的值均在我们设定的范围内时,该项质量标准得分为3分,以此类推。最后根据具体的得分,可以判定程序代码在该项质量标准上所处的等级。这就是Audit对质量模型中质量准则级的处理方法,可以看出,质量准则是建立在质量度量元的基础之上的,是比质量度量元更加综合的一级。
最后,综合多个质量标准,得出代码的可维护性质量因素。可维护性因素的计算方法如下:
function_MAINTAINABILITY: component? =? function_ANALYZABILITY
function_CHANGEABILITY
function_STABILITY
function_TESTABILITY
这是在计算函数的可维护性。最上面是计算公式,函数的可维护性由四个质量标准的得分相加得出(质量标准得分的计算方法上面已经说过了)。对于这个例子来说,它的最高得分为12分,最低得分为0分。最后根据具体的得分,可以判定程序代码在可维护性上所处的等级(EXCELLENT、GOOD、FAIR、POOR)。通过层层综合,最后终于得到了可维护性质量因素的结果。
OK,以上通过Audit为我们提供的默认质量模型,讲述了在Audit中由质量度量元、到质量准则、最后到质量因素的逐级评价方法。如果是我们自己制定的质量模型,其原理是完全一样的。
怎么样,这个过程清楚了吗?如果还是有些迷惑,建议你看一看“LogiscopeHOME\Logiscope\Ref\Logiscope.ref”这个文件的内容,那会对你理解这些内容有所帮助。
3.3 作用域的划分
我们在人工分析一个应用程序的代码时,通常先会查看应用程序的总体情况,然后分析应用程序中的各个类(对于使用面向对象这类语言实现的代码来说),进而再分析类中的成员函数。
Audit在分析、显示对代码的审查结果时,也按这种形式进行划分,我们称它为作用域,比如对于C++、Java语言实现的代码,Audit划分的作用域有:应用程序作用域、类作用域、函数作用域。通过它们的名字,你应该可以猜出各个作用域所包含的内容。应用程序作用域针对整个应用程序,类作用域针对系统中的各个类,函数作用域针对系统中的各个函数。
不同作用域之间是彼此独立的,但它们都是遵照我们前面提到的那个质量模型对代码进行分析。
3.4 Audit对代码的处理过程
对于使用Audit的用户来说,输入的是源程序代码,输出的是Audit的分析结果。Audit对代码的处理过程如图所示:
3.5 结束
好了,Audit的测试机理到此就介绍完了。
原文转自:http://www.uml.org.cn/Test/200609075.htm