面向对象软件度量技术的分析与综述—-整理

目录

 

摘要2

1     引言3

2  面向对象软件度量4

2.1 面向对象的特征4

2.2 面向对象软件度量方法4

2.2.1 面向类的度量——CK度量集5

2.2.2 MOOD度量6

2.2.3 UML度量8

3未来的发展趋势9

参考文献:10

 


 

面向对象软件度量技术的分析与综述

 

摘要软件的开发要保证其具备良好的质量,软件度量技术是其重要的方法。随着面向对象技术的发展,传统的软件度量技术很难适用于最新的面向对象软件,而面向对象软件度量技术就可以规范化帮助测评软件产品的质量程。文中分析了软件度量理论,讨论了当今流行的三大面向对象软件度量方法,并指出不足,以及未来的发展趋势。

 

关键词:面向对象  软件度量  度量方法 CK MOOD UML

 

Analyze and Review on The Measurement

in Object-oriented Software

 

Abstract:Ensuring the development of software tohave good quality,software metrics technologies should be animportant method. With the development of object-oriented technology,the traditional software metrics technologies are difficultto apply to the new object-oriented software,andobject-oriented software metrics technology can help evaluate standardizationof software product quality process. This paper the theory of software metricsis analyzed,the three popular object-oriented softwaremetrics methods currently are discussed,theexisting problems are pointed out and future development direction aresuggested.

 

Key words:Object-oriented ;Software metrics technologies ;The measurement in software;CK ;MOOD; UML;


 

1           引言

    从60年代爆发软件危机,诞生了软件工程这一新兴学科以来,软件工程的研究

不断前进,一方面积累了一大批的成果,形成成熟的传统软件工程技术;另一方面不断引入新的工程方法,使之日益完善。但是这并不意味着软件危机的终结:

1.软件成本和进度的估计较以前有了很大的进步,但依然不能保证十分准确,

仍然有改进的空间;

2.用户对正在使用的软件不满,需求没有完全的保障;

3.软件的可靠性不高,质量得不到有效保证;

4.软件的维护费用太高;

5.软件的成本高居不下。

软件工程的研究依然面临着两大问题:

(l)如何合理、有效、快速的构造应用系统;

(2)如何保证开发出来的产品具备令人满意的质量。

正如之前所言,软件质量问题是一直困扰软件开发和应用领域的重要问题。它涉及到人员和管理问题、开发过程问题 ,并最终归结为产品质量问题。评估最终软件产品质量可分为定性和定量两个方面 ,软件质量的定量度量是软件质量保障的一种重要手段 ,对软件的质量给出了客观性的评价。IEEE 在“Standard for software Quality Met2ricsMethodelogy , IEEE Std ,1061 – 1992 ,1993”中 ,对度量给出了定义: “度量是一个函数 ,它的输入是软件数据 ,输出是单一的数值 ,能用以解释软件所具有的一个给定谁能给对质量影响的程度”[1]。软件度量是针对计算机软件的度量 ,是对一个软件系统、组件或过程具有的某个给定属性的度的一个定量测量。通

过度量 ,可以对软件给出客观的评价,可用于指出软件属性的趋势 ,并可针对性地进行改善。其为软件工程的一个重要的、得到长期关注的研究领域,是评估和预测软件开发活动的一项重要措施和有效方法,其根本目的就是为开发高质量的软件提供指导2

自 Rubey 等人于1968年提出软件度量学的概念开始,人们对软件度量的研究和应用已经四十余年。众多学者对它作过专门的研究,主要从结构化程序度量(1968年3~至今)、面向对象软件度量(1989年4~至今)和 UML 模型度量(1996年5~ 至今)等三个方面开展研究,既取得了丰硕的理论研究成果,提出了代码行数(LOC)、McCabe 着色图法、软件科学法、功能点法等经典的结构化程序度量方法,又开发了一系列实用工具,如 LOC 计算工具 Microsoftline of code LOC Counter、LocMetrics、SourceCode Line Counter 和 CCCC 等,并将其应用到诸如缺陷检测、开发工作量估计和系统维护等软件工程的各个领域,得到了广大软件工程领域研究者与开发人员的高度重视。

任何一种项目都是可以用某种方法来度量的,而且总会比根本不度量好得多[6]

随着面向对象技术的高度发展,面向对象的软件学具有很多新特征。一方面,由于面向对象软件开发不再是基于功能分解和数据流程,从而使得传统软件度量不再适用于面向对象的软件度量,当前学术界和产业界急需能定量、定性分析面向对象软件质量的套件出现,并附带一套行之有效的标准;另一方面,在为了保证软件质量的前提下,要尽量减少对面向对象软件度量的繁琐工作量,让其度量具有更智能、更标准,能提交出一套改善软件的方案,可以帮助人员控制、安排软件开发过程并利用反馈信息对软件进行改善。从而提高软件质量,因此,面向

对象软件度量的研究对软件缺陷检测、开发工作量评估和后期软件系统维护等软件工程问题具有非常重要的意义。

2 面向对象软件度量

面向对象软件度量最初由Morris3于 1989 年提出,之后Chidamber 等人在 1994 年提出的 CK 度量集奠定了面向对象软件度量的基石。Aggarwal 等人将面向对象软件度量方法划分为耦合性度量、内聚性度量、继承度量、规模度量、信息隐藏度量、多态度量、复用度量七种类型;Zhou等人将其划分为耦合性度量、内聚性度量和继承度量三种类型。弓惠生等人分别对面向对象软件度量进行了综述分析,但未包含面向对象软件度量最新的研究成果。

面向对象软件度量强调是要将面向对象的特性、函数和数据结合为一个整体,才能定性和定量地预测其在软件质量中的作用,国内外普遍认为一个度量方法要得到推广需具备四个必要条件,即良好的度量方法的定义、度量方法的理论验证、度量方法的实验验证和度量方法的辅助工具。

2.1 面向对象的特征

面向对象注重程序的灵活性、可扩展性等,所以,面向对象具有抽象、继承、封装、多态四大特性。

(1)抽象:抽象就是忽略一个主题中与当前目标无关的那些方面,以便更充分地注意与当前目标有关的方面。抽象并不打算了解全部问题,而只是选择其中的一部分,暂时不用部分细节。抽象包括两个方面,一是过程抽象,二是数据抽象。

(2)继承:继承是一种联结类的层次模型,并且允许和鼓励类的重用,它提供了一种明确表述共性的方法。对象的一个新类可以从现有类中派生,这个过程称为类继承。新类继承了原始类的特性,新类称为原始类的派生类(子类),而原始类称为新类的基类(父类)。派生类可以从它的基类那里继承方法和实例变量,并且类可以修改或增加新的方法使之更适合特殊的需要。

(3)封装:封装是把过程和数据包围起来,对数据的访问只能通过已定义的界面。面向对象计算始于这个基本概念,即现实世界可以被描绘成一系列

完全自治、封装的对象,这些对象通过一个受保护的接口访问其他对象。

(4)多态性:多态性是指允许不同类的对象对同一消息做出响应。多态性包括参数化多态性和包含多态性。多态性语言具有灵活、抽象、行为共享、代

码共享的优势,很好的解决了应用程序函数同名问题。

2.2 面向对象软件度量方法

     面向对象方法的中心思想是将对象(数据和方法的集合)来模拟整个现实而并非以前常用的传统设计将数据和方法都分开来设计,传统的度量方法只是使用于对象内部特定的方法,面向对象技术产生的软件是需要对新的特征来度量反映这些关系。下面就来讨论分析一下当今比较流行的三个面向对象软件度量的方法:CK度量集、MOOD度量、UML度量。

2.2.1 面向类的度量——CK度量集

Chidamber和Kemerer7在1994年发表论文阐述和定义了CK度量集,奠定了面向对象软件度量学理论基础。

(1)   CK度量方法的分析:

 CK度量法提出了六个面向对象系统的基于类设计的度量。此六项指标,为

DIT、LCOM、WMC、NC、RFC和CBO。

① 每 个类的加权方法数 WMC(Weighted Methods for per Class)。

如果类C有 M1,M2… Mn共 n 个方法,且设C1,C2… Cn是这些方法的复杂度,则每个类的WMC为:WMC =,其中方法的复杂度可以用

特定的复杂性进行度量(如McCabe结构复杂性度量)。若所有方法的复杂度为1,则WMC= n ,即类中方法数总和。此外,方法的数目越多,继承树越复杂。WMC是开发和维护的时间和精力的代价指示表,WMC越大表示对子类影响就越大,其通用性和可复用性就越差。因此,WMC应保持合理的低值。

 

② 继承树的深度DIT(Depth of the Inheritance Tree)

DIT是类在继承树的最大深度,根节点的值为0,以下各级依次递增。DIT越大,则其继承方法数目越多,设计越复杂,方法的重用越多。

 

    ③ 孩子的数目NC(Number of Children)

NOC是继承树中一个类的直接孩子的数目。随着子女数量的增加,复用也会增加。NOC越大,则重用越好,但其父类的抽象性可能减弱,且整个测试工作量也增加。

 

④ 对象类之间的耦合CBO(Coupling Between Object classes)

一个类的CBO是它与其它类有耦合关系类的数目。若CBO越大,则对模块化的设计和阻碍复用,所以类的可重用性可能减弱,且修改和测试越复杂。通常,每个类的CBO值应该保持适当的低值。这与传统软件中减少耦合性的一般性指导原则是一致的。

⑤ 对类的相应RFC(Response For a Class)

类的相应集是“该类的某对象接受到消息,作出响应而可能执行的一组方法”[8]。设 Ms(C) 是类C中所有方法的集合,Mr(C) ={ Mj| Mj被 Mi调用,Mi∈ Ms(C) },则:RFC=| Ms(C) |+| Mr(C) |,即 RFC=|Ms(C) ∪Mr(C) |。它明确包含了在此类外部被调用的方法集,也就是所在类和其他类通信的一个度量。若RFC越大,则类的复杂度越大,且对该类进行测试和调试越复杂。

⑥ 方法内聚缺乏度LCOM(Lack of Cohesion in Methods)

        类中的每个方法访问一个或者是多个属性,LCOM是访问一个或多个属性的方法的数量。若没有方法访问相同的属性,则LCOM=0。若LCOM越大,则类设计的复杂度越大,开发过程出错的可能性越大,因此类可以分解成两个或

多个子类。虽然有些情况下LCOM取高值有其理由,但是,总是希望保持高内聚,既保持LCOM的低值。

(2)   CK度量方法的不足:

第一,C&K度量方法也停留在定义阶段,术语定义都没有达到精确的

标准,比如CBO没有考虑到各种耦合关系种类。

第二,C&K度量方法是从类的角度对程序的面向对象特征进行度量,它不是系统级的度量;其次,C&K度量方法缺乏多态性指标,无法很好地兼顾传统面向对象度量理论,面向对象程序级的研究尚未涉及,而且对对象的属性也没有很好定义。

第三,某些度量太理想化,在实际应用中是很难达到设计的目的,如LCOM

在定义中是不能达到0,且按公式LCOM=(2| P |/(n *(n -1)))得到的效果才是最合理的。

所以,C&K还有在面向对象软件度量中要还需要进行进一步研究。

2.2.2 MOOD度量

F.B.Abreau领导的MOOD项目组1994年第一次提出MOOD度量,Harrison、Counsell和Nithi在《An Evaluation of the MOOD set of object Oriented SoftwareMetrics》一文中对此进行了详细论述。MOOD度量是针对面向对象系统提出的,由六个系统一级的度量组成,各度量的计算都以熵的形式给出,分子是系统中特定机制的实际使用次数,分母是同样机制的最大可能的使用次数,每个度的取值都界于0~1之间,这是方便对度量值的评估。

(1)MOOD度量方法的分析:

① 封装性度量。

用AHF(属性隐蔽因子)和MHF(方法隐蔽因子)对封装性进行度量,MHF=

其中Md(Ci)表示类Ci中的方法数目,V(Mmi)=,其中TC表示系统中所有类的数目。若 Mmi定义为公共成员时,V(Mmi) =1;若 Mmi定义为私有成员时,V(Mmi) =0。

数据封装经常被用于衡量一个语言隐藏具体实现的能力,通常可以用信息隐藏来定义AHF和MHF使用类的属性和方法,以此对其他类代码的可见性来度量信息进行隐藏,值越大,表明隐蔽性越高。

② 继承性度量。

用AIF(属性继承因子)和MIF(方法继承因子)度量继承性。MIF和AIF越大,表明系统中方法或属性的继承性越高。

其 中 Ma(Ci) = Mi(Ci) +Md (Ci) ,Md (Ci) 声明类中方法的数目,Ma(Ci)表示类 Ci中可以调用方法的数目,Mi(Ci) 表示类 Ci继承下来的方法数目。

其中Aa(Ci) =Ai(Ci) +Ad (Ci) ,Ad (Ci) 声明在一个类中属性的数目,Aa(Ci) 表示类 Ci中可以调用属性的数目Ai(Ci)表示类 Ci继承下来的属性数目。

③ 耦合性度量。

用CF(耦合因子)度量耦合性。

,

其中

系统的CF值越大,系统的封装性越差,可理解程度越低,维护困难越大,潜在的可复用性将受到伤害但不能认为凡是耦合度越高的系统就越复杂。

④ 多态性度量。

用PF(多态因子)度量多态性。

其中Md (Ci)=Mn (Ci) +Mo (Ci) ,Mo (Ci) 表示类 Ci中重载方法的数目Mn (Ci) 表示类 Ci中定义新方法的数目DC (Ci) 表示类 Ci中的所有子类数目。PF表示系统中所有类的方法使用多态机制的程度。PF值越大,类之间发生耦合越频繁。

(2)MOOD度量方法的不足:

第一,MOOD度量没有对最基本的类关系进行研究,对抽象性和复杂性也没有完整的定义。

第二,MOOD度量方法在实际应用中,各项指标都会遇到实际问题的瓶颈。

封装性:系统中至少应包括两个类,否则类中方法和属性无论声明为何种类型,都不会有其它类来访问它;当采用C++开发软件时,程序中可能存在保护成员。由于保护成员被定义为只能被该类的所继承的类访问,其它类无权访问它,因此,Mi值不可能为l或0,只可能介于0和1之间。其计算方式应为 Mi=(TC-IC)/(TC-1),其中,IC是类C的所有导出类的总和;当采用MFC编程时,由于MFC中的类已被封装起来,在编程中只有对其的调用而无法看到其源代码,因而无法直接对其中的方法和属性进行度量,但在使用其它第三方提供的控件或类时,其源代码将出现在源程序中,这时又可以很容易地对其度量,这种度量范围的不一致性将造成度量结果的不一致,这样无法谈论准确性了。

继承性和耦合性:正如A中提到MFC,即使不管MFC中的类,以自创的类作为父类,这样计算就能完成,但其计算结果却存在极大的不合理性,与通

常的经验估计也会有很大的差别,这将大大增加构造自动度量工具的难度;用CF度量时,只能通过分属不同类的对象间的相互调度来判断类间的关系。对于自定义类与MFC类之间的消息传送关系以及MFC内部各类之间的消息传送关系将无法判断。

多态性:当一个系统的MF=0时,即该系统中有继承类时,上式分母部分值为0,这时不能采用PF公式;又如在计算Mn (C) 时,对于基类,其中所有方

法都属于新方法,即Md(Ci) =Mn(Ci) ,而且Mo(C) =0,但由于在源程序中无法找到MFC类库,因而也不能直接对基类进行度量。

其中,MOOD算法集在实际应用中可能出现的问题,并不完全是由于算法本身缺陷所造成的,而是由于应用环境的不同,从而产生了各种困难。对于不能解决的问题,则需进行更加细致的研究。

2.2.3 UML度量

    类图是面向对象的核心,是UML四大核心模型之一,是最重要、最复杂的模型。UML类图复杂性度量符合Abreu等人的观点,可以帮助开发人员从多种具有相同功能的不同设计方案中择优选取。复杂性最低者,为开发高质量的UML类图提供指导。

(1)   UML度量方法的分析:

Rossi等人为了比较不同的面向对象方法与技术之间的复杂性差异,提出了

17个复杂性度量元,并将其分成三类:独立度量元、聚合度量元和方法级度量元。它们分别是:对象类型的个数 n(Ot)、关系类型的个数 n(Rt)、属性类型的个数 n(Pt)、给定对象类型的关系的个数Po(Mt,o)、对象类型的平均属性的个数Po(Mt)、关系类型的属性数量与角色类型数量之和Pr(Mt,e)、关系类型的平均属性的个数Pr(Mt)、可以与特定对象类型相关联的关系类型的个数Ro(Mt,o)、可以与给定对象类型相关联的关系类型的平均个数Ro(Mt)、内部属性和外部属性的复杂度 C(Mt,o)、平均复杂度 C(Mt)、类图的复杂度 C′(Mt)、对象类型的个数总和∑(n(Ot))、关系类型的个数总和(n(Rt))、属性类型的个数总和∑(n(Pt))、对象和关系的复杂度C(M) 、累积复杂度 C′(M) 。

(2)   UML度量方法的不足:

现有的度量方法对各种类间关系复杂度的认识没有达成共识,单是统计定

义指标的个数就有很多,并且这些都还需进一步区分关系的类型;度量元的定义是用自然语言描述的,缺乏形式化描述,这容易产生歧义性,不能为理论验证提供服务、不能很好地与辅助工具衔接,不符合度量形式化定义的目标。缺乏对度量元的理论验证。虽然已经有研究者利用对象约束语言OCL度量集进行了半形式化描述,但还没有完全消除歧义性;也有研究者专门定义了语言来描述度量元,但代价太大,不能广泛应用推广。

建立模型方面也存在如下问题:

第一, 数据源缺乏。因为没有像 NASA 这样的公开数据源可供研究者使用,实验验证工作几乎全部是局限于私有数据源的,其他研究者无法进行重复的科学实验;另外,样本量比较少,最多有35 个类图。而实验不仅需要大量的样本数据,且要求样本数据满足特定的分布,因此实验效果不佳。

第二, 评价软件质量中易维护性的方法不科学、不客观。用参与者完成软件维护的时间来衡量易维护性,致使文献9实验中西班牙和意大利参与者各自的理解时间模型差异较大

综上,UML度量方法虽集中,应用前景也很可观,但是度量细节存在太多

争议,需要确定的因素有很多。

3未来的发展趋势

软件工程化的目的是产生高质量的软件产品。软件度量是提高和保证软件质量的关键。为了减少软件开发过程的主观性、盲目性,改进软件开发过程,应对软件管理过程和控制过程进行度量。本文分析了三种面向对象系统度量的方法,这些方法很好阐述了度量意义和度量指标,但是它们都是片面的。在实际度量中把系统的面向对象软件度量技术如何统一起来,把度量的方方面面都考虑到,并制定出一个行之有效的标准,这些工作是需要再细化和探索的。

综合以上三大流行面向对象软件度量技术,根据面向对象的特点,在满足传统度量理论的基础上,构造面向对象程序所适用的度量应该遵循以下三个

准则:

     第一,度量需要反映面向对象的特征(封装、继承、多态);

     第二,对于面向对象程序每一个方面的特征,要从单个类和整个面向对象系统两个角度进行度量。单一的度量是不能全面描述面向对象的特征,必须用

一组度量从多个方面来反映;

     第三,由于面向对象语言的特性,对一些传统从软件规模、控制流等方面得出的度量,可能需要进行必要的修正,根据具体问题要构造的度量需要具体考

虑。

    根据以上三个准则,以程序和数据的流程为对象,构造一个完整的面向对象软件度量测评模型,以用来测评软件度量的可行性,如图(1)

    面向对象软件的度量目前仍然处于探讨阶段,所提出的一些方法只是揭示了软件的内部属性,其结果值尚没有与真正需要的外部属性,如复杂性、可

靠性、维护性及可测试性等建立合理的对应关系。因此,关于面向对象度量的研究还有很多工作要做,以后会存在如下几个研究点:

(1)   软件生命周期各个阶段的应用:度量应在各个阶段执行,并发挥作用。

(2)   软件属性的严格定义:有关的经验关系系统还有待进一步研究,要对许多软件属性,尤其是内部属性,如复杂性、可理解性、可维护性等都进行严格的定义,这样才能对其进行有效度量;

(3)   实践应用:将度量应用到软件工程实践中去,用实际数据检验其有效性、合理性和实用性,以指导软件管理人员的工作。这样不但能够检验理论是否可行,还能从应用中提取出定义度量的关键因子;

(4)   自动化支持:真正有用的度量应具有自动化功能,否则就无法收集和计算度量所用的数据。因此,对给定的度量准则,有必要提供相应的工具支持。随着人们对度量意识的统一,自动化工具的支持必将成为以后研究的热点。

 

参考文献:

[1] XieTao , YuanWanghong , MeiHong et al.JBOOMT:Jade Bird bject2Oriented Metric Tool[J ].Chinese Journal of Electronics , 2000 ,9(2)

[2]  周欣,陈向葵,孙家骕,等. 面向对象系统中基于度量的可复用构件获取机制[J]. 电子学报,2003,31(5): 649-653.

[3]  RUBEY R J,HARTWICK RD. Quantitative measurement program

quality[C]/ /Proc of the 23rd ACM National Computer Conference.New York: ACM Press,1968:671-677.

[4] MORRIS K L. Metrics for object-oriented software development environments[D]. Boston: Massachusetts Institute of Technology,1989.

[5]  ROSSI M,BRINKKEMPER S.Complexity metrics for systems developmentmethods and techniques[J].Information Systems,1996,21(2):209-227.

[6] SteveMcConnell 著 裘宗燕等译 Code Complete(第二版).电子工业出版社,2012:677-679.

[7] CHIDAMBER S,KEMERER C. A metricssuite for object-oriented design[J]. IEEE Trans on Software Engineering,1994,20(6): 476-493.

[8] Roger S. Pressman著郑人杰马素霞白晓颖等译.软件工程—实践者的研究方法(第六版) 机械工业出版社 2011,15(4):346-352.

[9] GENERO M,MANSO M E,VISAGGIO CA,et al.Building measure-basedprediction models for UML class diagram maintainability[J]. Empirical Software Engineering,2007,12(5): 517-549.

 

来源:卧浪居士

声明:本站部分文章及图片转载于互联网,内容版权归原作者所有,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2013年9月27日
下一篇 2013年9月28日

相关推荐