【IT168 技术文章】
前言
近年来，面向对象技术已经作为一种有优势的软件工程方法出现。和其他许多新技术一样，面向对象方法的出现使得软件开发人员和他们的经理们必须重新考虑估计他们开发项目的方法。传统的软件度量技术即使进行改善也无法满足度量生产力和预测工作的需要。源代码行和功能点方法都是程序需要将数据和过程分解开的时代特有产物。这和面向对象范畴有冲突。传统的设计技术将数据和过程分离而面向对象技术将他们联合在一起。如果要提供准确的工作预测或生产力跟踪，面对对象度量方法必须有多个尺度（度量维）。计算交付给客户的软件具有功能数非常重要，但对象间交流的信息和通过继承的重用对规模度量也非常重要。本文论述了预测性对象点（PredictiveObjectPointsPOPs），一种包含前面提到的面对对象3个尺度的度量方法。不像传统的度量方法基于结构分析的数据和过程模型，POPs是基于对象和他们的特征。POPs综合了文献中几种流行的度量方法，建立一种适合预测工作量和跟踪生产力的方法。POPs方法的核心是每类加权方法数（WeightedMethodsperClassWMC）。这种方法测量每个顶层类（或者说，每个在用户的视野中清楚的对象）并且根据类的行为（方法）类型不同进行加权。一旦得到WMC的值，POPs方法将把它和有关按类分对象组的信息和对象类之间的关系进行联合计算。接下来本文将论述POPs方法形成过程和有关工作研究结果，并且介绍一个预测性对象点方法应用的例证。通过对一个公用领域的面向对象项目的使用，能指导读者认识计算预测性对象点的机理。
传统的度量有什么错误
传统的度量方法在一些度量过程中还占有一席之地。一些年来，软件开发人员和软件估计人员使用源代码行（SLOC）或者功能点方法估计要建设的面向对象软件项目的工作量，这不是因为他们选用的方法是最好的，但却可能是最适合的，常常在组织面向对象过程不够成熟时他们比较适合。相反地，当组织越来越善于设计和开发面向对象软件时，这些传统的方法变得越来越没有用了，因为每个开发人员的代码行变得和其他人员的不是很相似。变化的原因很明显，他们已经停止了思考每一行代码是怎样和另一行代码相匹配，停止了结构化分析，走向面向对象方法的道路。首先我们不妨想想传统的程序方法和它是怎么发展的。最初，软件开发人员被迫将的软件方案完全分解，因为最早的程序语言需要辛苦地一步一步描写要实现的每一个方案的动作。随着编程的发展，越来越多的一步步描写变成了一个简单的编译命令。但是还需要分解功能业务。结构化分析需要开发人员按过程连续地思考和编程，编写每一行代码，每一个函数和每个子系统，每一个产品，都是一种单一连续思维。在这种对源代码和函数单一的思想下，很容易想到像代码行和功能点这样度量方法。但面向对象技术要求人们完全转变思想。一个方案不再根据需要实现它的步骤进行分解。它宁愿分解成一个个包含在方案的动作者，当然分解出来的动作者必须对方案有作用。方案空间分解为动作者和动作者的行为。既然动作者和他们的行为受他们内部之间相互作用或者环境的影响，所以每一行代码的想法需要考虑许多可能的作用在动作者上的路径。基于连续程序开发模型的度量方法将会错过这种相互作用所导致的复杂性。
相关研究
面向对象度量的研究，无论如何不是一块未曾开垦的处女地。Chidamber等曾提出一套面向对象度量，其中包括一些度量规模的方法，他们都是很好地根据度量理论创立的[4]。Lorenz发布了一张11个“构思度量”的表，其中有些能很好适用于规模度量[16]。其他一些学者在收集软件开发工作不同的度量尺度时做出了贡献。Henderson-Sellers收集形成了一个这些方法的全部名单[2]。由于以前每种方法都是致力于面向对象软件的规模的一个度量尺度，这些方法没有一个能单独用作一个很好的规模预测器。Whitmire提出了3-D功能点[19]，这是一种扩展的功能点方法，度量软件项目的数据、控制和功能。然而3-D功能点采用的是传统的功能点思想处理遇到的问题，他可以度量所有3个尺度，但只能完成在类的水平。这就使得3-D功能点能作为一个完整的软件生产力分析的方法，但不可能用作工作量预测。
面向对象软件的度量尺度结构
传统度量方法应用于面向对象解决方案时的问题是只度量软件的一个尺度，即功能。没有度量对象与对象间通信的复杂性和通过继承的重用数量，传统功能性度量忽略了软件规模至关重要的这两个方面。功能（对象的行为）是你预测工作量时一个重要的信息，但只是考虑这个方面，在设计得比较好的面向对象方案中会明显证明是错误的。在功能之外，还有基于系统对象间通信数量的复杂水平。这种复杂性充分影响项目规模。对象间的通信增加，就需要更多的详细设计和对象测试，他们就是在增加更多的系统服务。面向对象规模的第三个尺度是通过继承的重用。部分优秀的面向对象分析员潜心识别对象（动作着），将行为足够相似的分成一个相同的类或一个相同的类族。类是通过行为和属性进行描述，实例化就有了具体的对象。一组有许多相似行为的对象常常设计为基类（或者父类），基类包含可以供派生类（或者子类）继承的一般方法，子类也可以添加新的方法和通过重载父类方法实现父类定义的方法中没有提供的功能。继承是面向对象软件系统一个强有力的特征，在某些软件项目，它有可能大大减少项目工作量。
度量所有的三维
已经确定传统的度量方法缺少准确估计软件规模的三维中的两维，下一步的就是确定一种能合并所有三维的度量方法或者度量方法集合。预测性对象点，本文的主题，综合了最近文献中出现的几种度量面向对象的软件的方法。他们是所有关于软件系统面向对象分析和设计的度量方法。这些方法度量项目面向的最重要方面～开发的类，类的方法和类的方法对系统其他部分的作用。他们也联合度量拟定类结构的广度和深度。包含在POPs计算的度量方法有：
顶层类数（NumberofTopLevelClassesTLC）
每类的加权平均方法数（AverageNumberofWeightedMethodsperClassWMC）
平均继承树深度（AverageDepthofInheritanceTreeDIT）
平均每基类的子类数（AverageNumberofChildrenperBaseClassNOC）
下面接着是描述上面的每一种度量并介绍他们在POPs度量方法中为什么重要。
顶层类数(TLC)
这个度量是计算类图中根部的类的多少，其他所有的类都是继承他们。因为POPs计算带有预测目的，所以能分析系统的顶层信息非常重要。顶层类数和NOC、DIT能提供估计面向对象系统广度和深度的计算基础。这就添加了通过继承重用的度量维到POPs计算。
每类的加权平均方法数(WMC)
这是每类的方法平均数，每个方法要通过根据方法的类别，方法影响的属性数和方法提供给系统的服务数确定的复杂性不同进行加权。这是POPs计算的核心。调查显示在决定面向对象度量方法对规模估计适合性方面有两个冲突的思想学派（记住，这个规模要联系工作量和生产力）一个是不同的对象总数（thetotalnumberofdistinctobjects）计算[10],[11]。另外一个用每对象类平均加权的方法数(WMC)[4],[12],[9],[16]。虽然对象数被称为一种工作量估计的好方法，但我偏好于WMC是由于以下几方面原因：
方法与行为相联系
早在分析时知道系统拟定的行为，它使得更加容易在软件生命周期早期阶段进行可信的规模估计。
WMC计算方法加强了计算过程的严密性。在POPs计算，每类的加权平均方法数体现了系统的功能和对象间通信。
平均继承树深度(DIT)
每个类要不被称为根类要不被称为派生类。那些不像根类那样，没有地方继承的类都是派生类。DIT对于一个类来说意味着它在继承树中的深度，也就是从根类到这个类的长度（层的数字）。平均DIT和TLC、NOC一起用来确定通过继承的重用度和整个系统的规模。
平均每基类的子类数(NOC)
每个类有0个或者更多的直接子孙（派生类）。NOC是对派生类的计算。在图2中，类A的NOC是3，它有三个子类。父类上的NOC用来确定通过继承的重用度和整个系统的规模。
POPs度量方法的形成
下一步工作就是收集数据。开始我们有超过20个项目的数据集。数据是从不同的软件开发领域如军用、金融和商业贸易的软件工具卖主那里收集来的，数据是规范化的，包含普通的应用类别和操作说明。虽然不是所有的数据都是我们想要的，但我们能对超过775个类和5900个方法进行详细研究。大部分软件是C++或者Smalltalk编写的。
有了收集到的一些数据和能覆盖所有三维的正确的度量主意，下一步任务就是确定一个能联合这些度量方法形成一个与工作量有意义的数量。在这个过程的第一步是对方法如何加权。挑战是如何提供一个方法分类的框架，这个框架能在分析软件方案时工作，且能提供足够好的非类粒度。
Booch建议将方法分成5类[1]：
构造器（Constructors）–实例化一个对象的方法。
·解析器（Destructors）–消灭一个对象的方法。
·修正器（Modifiers）–改变对象状态的方法。修正器内包含自己和其他类的一个或多个属性。
·读取器（Selectors）–访问对象状态但不改变状态。这种方法提供给公众读取加载在对象身上数据。
·叠加器（Iterators）–以定义好的顺序访问对象的所有部分。他们可以用来遍历一个对象集合中的每个成员，对每个成员执行同样的操作。
为了验证这种分类是否真实反映方法在复杂性上的不同和确定基于这些不同的加权系数，我们研究了数百个C++和Smalltalk方法。
对每种方法我们收集了有关类别和属性数的方面的信息。我们按类别组织了这些方法，给每个方法按花在它上面的工作量总和分配了一个系数。由于工作量是在类的层面跟踪的而不是在方法层次跟踪，我们根据提供者给的信息确定一个百分比，确定一个类的工作量能分配多少到一个特定的方法。如果缺少提供者给的可靠信息，我们用代码行来确定分配给方法的工作量。利用代码行并没有违反最初的设想，因为我们用代码行只是为了确定特定方法类别的加权系数。我们计算了每种类别方法的平均数，且将他们用作最初的加权系数。在分析过程中，我们确定构造器和解析器在复杂性方面没有明显的区别，所以我们将这两种方法类别合起来了。以这点为基础，我们确定了每种方法类别的平均加权系数。这些加权系数主要是基于功能。
下一步是怎么样辨别哪些方法高于平均值哪些低于平均值。通过回顾上面的数据，发现系统的响应数（方法预期响应的消息数）和被方法作用的属性数越高，方法就有高于平均数值的加权系数，相反地，这两个数据低，方法的加权系统也会低于平均值。重要的是要注意我们收集到的数据标本足够我们进行分析却不足以只通过对他们分析得出这样的结论。所以我们也应用了一些专家的知识。研究的结果引发了确定每类方法权重的开发过程，它包括分析方法功能的同时指出它基于对象间通信的低、平均或高的复杂性。表2显示了不同类别方法的复杂性，表3显示了计算规则（基于响应消息和影响属性数），它来确定方法所属类别。
一旦确定了常量的值，我们可以用这些数值计算每类的加权平均方法数(WMC)。
加权平均方法数(WMC)将会联合TLC、NOC、DIT进行计算。
我们对这些不同形态的数据进行了归约，综合形成下面形式一个方程式。在方程式中，
f1计算整个系统的规模，f2计算通过重用的影响。我们开始有了一个相当小规模的数据点集合，我们用jack-knifed方法进行数据分析。我们将拿出一小百分比数据进行查证确认，其他剩余的部分进行归约（按上面的方程式），接着对比衰退计算结果和经过提出查证确认情况。我们再三重复地做，用不同的例子不断地做，直到方程式的集合能得到最好的变更系数。我们用来做归约的工具是Jandel提供得SigmaPlot。
我们的数据显示了很好的相关性，变更系数在我们采用的例子中变化范围为5～19％内。我们知道研究到今天这些结果只是初步地给了一个数据总量。研究还要进一步进行，需要收集其他类型的软件和用其他开发语言开发的应用程序的数据。
POPs计算例证
理解了什么是POPs和它是怎么形成的，很明显下一步问题是它作为一个估计工具怎么样使用。一些POPs计算需要的信息可能是需求分析阶段没充分清楚的信息。然而，我们有可以采用的方法来合理估计计算POPs需要的参数。下面一个例子来自[17]。利用项目提供的信息和一个面向对象度量工具，我们将演示怎么样进行POPs计算。开发的软件是个OOCase工具。它是用Smalltalk开发的，有36个类和1040个方法。软件开发团队的生产力高于平均值，他们有大量的软件开发经验。
第一步是计算WMC。我们知道平均每类的方法是29（1040/36）。虽然我们不清楚这些方法的类别上的分布情况，我们可以用我们在研究过程中确定的百分比来计算：
构造器/解析器(20%)=6
读取器(30%)=9
修正器(45%)=13
叠加器(5%)=1
我们用图3来确定复杂度，我们用每类发送消息数（numberofmessagessent）和实例变量数，既然他们可利用。从这我们可以近似得到实例变量和发送消息。
通过计算发送消息和实例变量和把他们与复杂性分配表（表3）进行匹配，我们确定了方法的复杂度。图4显示了分析情况及最终结果的低、平均和高复杂方法数
图3用来确定复杂度的数据
接着我们用图5确定这个例子的平均NOC和DIT。从这我们计算得平均NOC是1.4,我们用子类的总数除以那些有子类的类（父类）的总数（30/21）。我们计算得平均DIT是1.6，顶层类是6（图中层次水平为0的类数）
22%低45%平均
图4例子的复杂性分配
最后我们用所有得到的输入进行一个POPs计算，如图6所示。虽然这个例子是采用的一个已经完成的项目，也可以用早在分析阶段的工作产品进行一个相类似的分析。当用例分析已经完成的时候，应该包含有用的动作者，他们的行为和初步的类结构，从这些可以近似地推出其他参数。
POPs展望
研究到今天，我们已经得到一个度量方法和计算过程，我们目前收集研究的数据，提供了面向对象度量和工作量之间的相互关系。但我们还有些问题需要克服。首先，无论如何我们研究的数据没有完全覆盖所有软件类型和现行的技术。我们需要收集另外的数据，并继续修正我们的最初结果。我们也需要填补早在分析时有的工作产品和POPs计算所需的工作产品之间差距。为了简化估计过程，下一步我们要开始研究用例图（或其他用例工作产品）和POPs的直接关系。最终，一旦项目完成，我们要能自动计算POPs，这非常重要。如果想对一个组织的现有度量方法的校准（改变），一个必须接受的最大的障碍是任何一种新的规模度量方法是否能自动计算。自动计算能使得pops很容易进入存在有历史数据的领域。
图6例子的POPs计算
参考文献
1.Booch,G.1994,ObjectOrientedAnalysiswithApplications-2ndEdition,enjamin/CummingsPublishingCo.Inc.,RedwoodCity,CA.
2.Henderson-Sellers,B.,1996,ObjectOrientedMetrics-MeasuresofComplexity,PrenticeHall,UpperSaddleRiver,NJ.
3.Albrecht,A&Gaffney,J.,1983,SoftwareFunction,SourceLinesofCode,andDevelopmentEffortPrediction:ASoftwareScienceValidation,IEEETransactionsonSoftwareEngineering,Vol.SE-9,No.6,pp639-648,November
4.Chidamber,S.R.&KemererC.F.,1994,AMetricsSuiteforObjectOrientedDesign,IEEETransactionsonSoftwareEngineering,Vol.20,No.6,pp476-493,June5.Churcher,N.I.&Shepperd,1995,M.J.,Commentson“AMetricSuiteforObjectOrientedDesign”,IEEETransactionsonSoftwareEngineering,Vol.21,No.3,pp.263-264,March
6.Banker,R.D,et.al.1992,AnEmpiricalTestofObject-basedOutputMeasurementMetricsinaComputerAidedSoftwareEngineering(CASE)Environment,JournalofManagementInformationSystems,Vol.8,No.3,pp.127-150,Winter.
7.Boehm,B.et.al.,1995,CostModelsforFutureSoftwareLifeCycleProcesses:COCOMO2.0,AnnalsofSoftwareEngineering,SpecialVolumeonSoftwareProcessandProductMeasurement.
8.Banker,R.D.et.al.,1994,AutomatingOutputSizeandReuseMetricsinaRepository-BasedComputerAidedSoftwareEngineering(CASE)Environment,IEEETransactionsonSoftwareEngineering,Vol.20,No.3,pp169-186,March.
9.Pittman,M.,1993,LessonsLearnedinManagingObject-OrientedDevelopment,IEEESoftware,January
10.Laranjeira,L.,1990,SoftwareSizeEstimationofObject-OrientedSystems,IEEETransactionsonSoftwareEngineering,Vol.16,No.5,pp510-522,May
11.Jenson,R.L.&Bartley,J.W.,1991,ParametricEstimationofProgrammingEffort:AnObject-OrientedModel,JournalofSystemsandSoftware,Vol.15,pp.107-114
12.LockheedMartin,AdvancedConceptCentertrainingmaterials,1994,ObjectOrientedSizeandCostEstimation.
13.Basili,V.,1980,Qualitativesoftwarecomplexitymodels:asummary,TutorialonModelsandMethodsforSoftwareManagementandEngineering,IEEEComputerSocietyPress,LosAlamos,CA.
14.Weyuker,E.,1988,Evaluatingsoftwarecomplexitymeasures,IEEETransactionsonSoftwareEngineering,Vol.14,No.9,September
15.McCabeT.J.,1976,Acomplexitymeasure,IEEETransactionsonSoftwareEngineering,Vol.No.4,April
16.Minkiewicz,A.F.,1997,‘ObjectiveMeasures’,SoftwareDevelopment,June1997,pp43-47.
17.Lorenz,M.1993,Object-OrientedSoftwareDevelopment:APracticalGuide,PrenticeHall,Englewood,NJ.p227.
18.Jacobson,I.,etal,1992,Object-OrientedSoftwareEngineering:AUseCaseDrivenApproach,Addison-Wesley,ReadingMA
19.Whitmire,Scott,1996,3DFunctionPoints:ApplicationsforObject-OrientedSoftware,ASM’96ConferenceProceedings,SanDiegoCA
