POPs度量方法的形成

下一步工作就是收集数据。开始我们有超过20个项目的数据集。数据是从不同的软件开发领域如军用、金融和商业贸易的软件工具卖主那里收集来的， 数据是规范化的，包含普通的应用类别和操作说明。虽然不是所有的数据都是我们想要的，但我们能对超过775个类和5900个方法进行详细研究。大部分软件是C++ 或者Smalltalk编写的。

有了收集到的一些数据和能覆盖所有三维的正确的度量主意，下一步任务就是确定一个能联合这些度量方法形成一个与工作量有意义的数量。在这个过程的第一步是对方法如何加权。挑战是如何提供一个方法分类的框架，这个框架能在分析软件方案时工作，且能提供足够好的非类粒度。
Booch 建议将方法分成5类[1] ：
构造器（Constructors） – 实例化一个对象的方法。
· 解析器（Destructors ）– 消灭一个对象的方法。
· 修正器（Modifiers） – 改变对象状态的方法。修正器内包含自己和其他类的一个或多个属性。
· 读取器（Selectors ）– 访问对象状态但不改变状态。这种方法提供给公众读取加载在对象身上数据。
· 叠加器（Iterators） – 以定义好的顺序访问对象的所有部分。他们可以用来遍历一个对象集合中的每个成员，对每个成员执行同样的操作。

为了验证这种分类是否真实反映方法在复杂性上的不同和确定基于这些不同的加权系数，我们研究了数百个C++ 和 Smalltalk方法。

对每种方法我们收集了有关类别和属性数的方面的信息。我们按类别组织了这些方法，给每个方法按花在它上面的工作量总和分配了一个系数。 由于工作量是在类的层面跟踪的而不是在方法层次跟踪，我们根据提供者给的信息确定一个百分比，确定一个类的工作量能分配多少到一个特定的方法。如果缺少提供者给的可靠信息，我们用代码行来确定分配给方法的工作量。利用代码行并没有违反最初的设想，因为我们用代码行只是为了确定特定方法类别的加权系数。 我们计算了每种类别方法的平均数，且将他们用作最初的加权系数。 在分析过程中，我们确定构造器和解析器在复杂性方面没有明显的区别，所以我们将这两种方法类别合起来了。 以这点为基础，我们确定了每种方法类别的平均加权系数。这些加权系数主要是基于功能。

方法类别	方法的复杂性	权重
构造器/ 解析器	低	1
	平均	4
	高	7
修正器	低	1
	平均	5
	高	10
读取器	低	12
	平均	16
	高	20
叠加器	低	3
	平均	9
	高	15
表2 不同类别和复杂性方法的加权系数

下一步是怎么样辨别哪些方法高于平均值哪些低于平均值。通过回顾上面的数据，发现系统的响应数（方法预期响应的消息数）和被方法作用的属性数越高，方法就有高于平均数值的加权系数，相反地，这两个数据低，方法的加权系统也会低于平均值。重要的是要注意我们收集到的数据标本足够我们进行分析却不足以只通过对他们分析得出这样的结论。 所以我们也应用了一些专家的知识。研究的结果引发了确定每类方法权重的开发过程，它包括分析方法功能的同时指出它基于对象间通信的低、平均或高的复杂性。 表2显示了不同类别方法的复杂性，表3显示了计算规则（基于响应消息和影响属性数），它来确定方法所属类别。

一旦确定了常量的值，我们可以用这些数值计算每类的加权平均方法数(WMC)。
加权平均方法数(WMC)将会联合TLC、NOC 、DIT进行计算。
我们对这些不同形态的数据进行了归约，综合形成下面形式一个方程式。在方程式中，

f1 计算整个系统的规模， f2计算通过重用的影响。我们开始有了一个相当小规模的数据点集合，我们用jack-knifed方法进行数据分析。我们将拿出一小百分比数据进行查证确认，其他剩余的部分进行归约（按上面的方程式），接着对比衰退计算结果和经过提出查证确认情况。我们再三重复地做，用不同的例子不断地做，直到方程式的集合能得到最好的变更系数。我们用来做归约的工具是Jandel提供得SigmaPlot。

我们的数据显示了很好的相关性，变更系数在我们采用的例子中变化范围为5～19％内。我们知道研究到今天这些结果只是初步地给了一个数据总量。研究还要进一步进行，需要收集其他类型的软件和用其他开发语言开发的应用程序的数据。

POPs 计算例证

理解了什么是POPs和它是怎么形成的，很明显下一步问题是它作为一个估计工具怎么样使用。一些POPs计算需要的信息可能是需求分析阶段没充分清楚的信息。然而，我们有可以采用的方法来合理估计计算POPs需要的参数。 下面一个例子来自[17]。利用项目提供的信息和一个面向对象度量工具，我们将演示怎么样进行POPs 计算。开发的软件是个OO Case 工具。它是用Smalltalk 开发的，有36个类和1040个方法。软件开发团队的生产力高于平均值，他们有大量的软件开发经验。

第一步是计算WMC。我们知道平均每类的方法是29（1040/36）。虽然我们不清楚这些方法的类别上的分布情况，我们可以用我们在研究过程中确定的百分比来计算：
构造器/解析器 (20%) = 6
读取器(30%) = 9
修正器 (45%) = 13
叠加器(5%) = 1

我们用图3来确定复杂度，我们用每类发送消息数（number of messages sent）和实例变量数，既然他们可利用。从这我们可以近似得到实例变量和发送消息。

通过计算发送消息和实例变量和把他们与复杂性分配表（表3）进行匹配，我们确定了方法的复杂度。图4显示了分析情况及最终结果的低、平均和高复杂方法数

图3 用来确定复杂度的数据

接着我们用图5确定这个例子的平均NOC和DIT。从这我们计算得平均NOC是1.4,我们用子类的总数除以那些有子类的类（父类）的总数（30/21）。我们计算得平均DIT是1.6，顶层类是6（图中层次水平为0的类数）

22% 低 45% 平均

图4 例子的复杂性分配

图5 类的层次信息

最后我们用所有得到的输入进行一个POPs计算，如图6所示。虽然这个例子是采用的一个已经完成的项目，也可以用早在分析阶段的工作产品进行一个相类似的分析。当用例分析已经完成的时候，应该包含有用的动作者，他们的行为和初步的类结构，从这些可以近似地推出其他参数。

POPs展望

研究到今天，我们已经得到一个度量方法和计算过程，我们目前收集研究的数据，提供了面向对象度量和工作量之间的相互关系。但我们还有些问题需要克服。首先，无论如何我们研究的数据没有完全覆盖所有软件类型和现行的技术。我们需要收集另外的数据，并继续修正我们的最初结果。我们也需要填补早在分析时有的工作产品和POPs计算所需的工作产品之间差距。为了简化估计过程，下一步我们要开始研究用例图（或其他用例工作产品）和POPs的直接关系。最终，一旦项目完成，我们要能自动计算POPs，这非常重要。如果想对一个组织的现有度量方法的校准（改变），一个必须接受的最大的障碍是任何一种新的规模度量方法是否能自动计算。自动计算能使得pops很容易进入存在有历史数据的领域。

图6 例子的POPs计算

参考文献
1.Booch, G. 1994, Object Oriented Analysis with Applications - 2nd Edition, enjamin/Cummings Publishing Co. Inc., Redwood City, CA.
2.Henderson-Sellers, B.,1996, Object Oriented Metrics -Measures of Complexity, Prentice Hall, Upper Saddle River, NJ.
3.Albrecht, A & Gaffney, J., 1983, Software Function, Source Lines of Code, and Development Effort Prediction: A Software Science Validation, IEEE Transactions on Software Engineering, Vol. SE-9, No. 6,pp 639-648, November
4.Chidamber, S. R. & Kemerer C. F., 1994, A Metrics Suite for Object Oriented Design, IEEE Transactions on Software Engineering, Vol. 20, No. 6, pp476-493, June 5.Churcher, N.I. & Shepperd, 1995, M. J., Comments on “A Metric Suite for Object Oriented Design”, IEEE Transactions on Software Engineering, Vol. 21, No. 3, pp. 263-264, March
6.Banker, R.D, et. al. 1992, An Empirical Test of Object-based Output Measurement Metrics in a Computer Aided Software Engineering (CASE) Environment, Journal of Management Information Systems, Vol. 8, No. 3, pp. 127-150, Winter.
7.Boehm, B. et. al.,1995,Cost Models for Future Software Life Cycle Processes : COCOMO 2.0, Annals of Software Engineering, Special Volume on Software Process and Product Measurement.
8.Banker, R. D. et. al., 1994, Automating Output Size and Reuse Metrics in a Repository-Based Computer Aided Software Engineering (CASE) Environment, IEEE Transactions on Software Engineering, Vol. 20, No. 3, pp169-186, March.
9.Pittman, M., 1993, Lessons Learned in Managing Object-Oriented Development, IEEE Software, January
10.Laranjeira, L., 1990, Software Size Estimation of Object-Oriented Systems, IEEE Transactions on Software Engineering, Vol. 16, No. 5, pp510 - 522, May
11.Jenson, R. L. & Bartley, J. W., 1991, Parametric Estimation of Programming Effort: An Object-Oriented Model, Journal of Systems and Software, Vol. 15, pp. 107-114
12.Lockheed Martin, Advanced Concept Center training materials, 1994, Object Oriented Size and Cost Estimation.
13.Basili, V., 1980, Qualitative software complexity models: a summary, Tutorial on Models and Methods for Software Management and Engineering, IEEE Computer Society Press, Los Alamos, CA.
14.Weyuker, E., 1988, Evaluating software complexity measures, IEEE Transactions on Software Engineering, Vol. 14, No. 9, September
15. McCabe T.J., 1976, A complexity measure, IEEE Transactions on Software Engineering, Vol. No. 4, April
16.Minkiewicz,A.F.,1997, ‘Objective Measures’, Software Development, June 1997, pp43-47.
17. Lorenz , M. 1993, Object-Oriented Software Development: A Practical Guide, Prentice Hall, Englewood, NJ. p227.
18. Jacobson, I., et al, 1992, Object-Oriented Software Engineering: A Use Case Driven Approach, Addison- Wesley, Reading MA
19. Whitmire, Scott, 1996, 3D Function Points: Applications for Object-Oriented Software, ASM ’96 Conference Proceedings, San Diego CA