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％内。我们知道研究到今天这些结果只是初步地给了一个数据总量。研究还要进一步进行，需要收集其他类型的软件和用其他开发语言开发的应用程序的数据。