|
功能点分析(Function Point Analysis，FPA)是用于"需求文档"、"设计语言源代码"和"测试用例"的度量，是一种与程序设计语言无关，能够有效度量软件规模的方法。功能点(Function Point，FP)方法最初是由Albrecht于1979年提出来的，目的是想在软件开发的早期度量软件的规模。而后Albrecht又于1983年改进了功能点，使得功能点由5个功能要素和41个调整因子组成。为了推进软件功能规模度量的发展，国际功能点用户协会(International Function Point Users Group，IFPUG)于1948年出版了第一份规范的功能点分析计算实践指南，并子1994年发布了功能点计算实践手册(Counting Practice，Manual，CPM)4.0版本。CPM为FPA方法提供了一组从用户角度来度量软件功能规模的规则。
FPA方法可以使客户和开发人员使用同一种方法来表示软件规模，也可以在软件开发的早期度量软件的规模。由于软件的规模与开发软件的工作量、进度和成本关系紧密，早期估算软件功能规模有助于确定软件价格和提高策划过程中估算的能力。
本文首先介绍了功能点计算的步骤.并对半形式化模型进行了描述，然后以外部查询(External Query，EQ)为例，对其4条规则进行了形式化定义，最后提出了基于源代码的逆向工程方法来估算功能点。把FPA和源代码分析结合起来，就能够在软件开发的后期阶段更精确地度量软件的规模。
1 IFPUG FPA计算规则
功能规模是通过对用户功能需求(Function user Requirement，FUR)进行量化而得到的软件的大小。功能规模度量(Functional Size Measurement，FSM)是度量软件功能规模的过程。一个FSM方法就是由一组规则所定义的具体可执行的FSM。FPA就是一个 FSM方法。
FPA使用软件提供的功能度量作为规范值，它是基于软件信息领域的可计算的量及软件复杂性的评估而导出的。它将软件的功能归结为5个基本的功能要素:内部逻辑文件(Internal Logical File，ILF)、外部接口文件(External Interface File，EIF)、外部输人(External Input，EI)、外部输出(External Output，EO)和外部查询(External Query，EQ)。
这5个基本要素又可分为:数据功能(Data Function)和事务功能(Transactional Function)。事务功能包括外部输入(EI)、外部输出(EO)、外部查询(EQ);数据功能包括内部逻辑文件(ILF)和外部接口文件(EIF)。
为了能手动计算一个软件的规模，IFPUGCPM标准的作者列出了35个步骤。这些步骤可以划分为图1所示的7大步骤。计算时间和工作量主要花费在计算数据功能点、事务功能点和确定未调整的功能点这3大步骤上，尤其是识别数据和事务功能点的类型所花的代价比较高。
为了识别数据和事务功能点，要使用50个IFPUG规则，其中13个规则与数据功能类型有关，而其他37个规则与事务功能有关1。以识别EQ为例，其中一条规则是:导出的数据必须经过处理，而不是对来自一个或多个LIF和(或)IEF的信息直接进行检索、转换和信息编辑，即EQ不包含导出数据。CPM规则能以自然语言的形式描述，但必须进行形式化定义后才能自动执行。 （图片） 1.2 自动功能点计算
自动功能点计算涉及到 FPA方法的自动化。IFPUG把自动功能点计算定义为:基于应用软件功能的存储种类，系统在自动计算功能点的地方记录了该计算并且执行相应的计算。其中，存储种类包括:用户需求、数据库物理结构以及界面和报表布局。应用软件功能代表所有用户需求的一个子集，而这些用户需求则代表了用户的实践和过程。特别是，计算过程中所涉及的基本处理(Process)指的是对用户有意义的最小活动单位。相应的计算指的是根据CPM的一系列计算规则所进行的运算，也就是根据IFPUG4.0计算实践手册所获得的有效计算。一旦计算机存储介质上的用户功能需求(FUR)是可利用的，那么自动功能点计算就有可行性 。
近几年，对全自动化功能点计算的可行性问题的研究成为国内外很多学者关注的热点。虽然IFPUG已经定义了一些所谓的自动化工具，但实际上都不能实现全自动化。
2 IFPUG规则的形式化建模
2.1半形式化表示
事实证明，FPA计算的对象并不是由CPM定义的，数据和事务功能类型的识别活动基本上都依赖于系统边界(Boundary)和用户(User)观点这些基本概念。
图2描述了CPM中边界的概念以及位于边界内外的处理(P)、文件(f)和用户交互作用。其中:P作为计算的组成部分位于边界的中央，IFPUG把P描述为对用户有意义的最小活动单位;Flow为输入/输出数据流。这种半形式化的描述能够识别事务功能类型中有效的特征和信号。当试图自动识别一个事务功能类型时，这些信号就变得非常有用。（图片） 其中，Flow 1和Flow 2是必须存在的数据流，Flow 3通常是不存在的，Flow 4可以存在也可以不存在。Flow 1意味着位于边界内的处理(Process)接收来自于用户或边界外的另一个处理或文件(File)的数据;Flow 2意味着位于边界内的处理把数据发送给用户或边界外的另一个处理或文件;Flow 3的值为0，表明该处理不能向边界内的另一个文件写数据;而Flow 4为0或 1，则表明位于边界内的处理可能会读取位于边界内的另一个文件。
根据图2中的符号值，可以建立形式化模型:B表示CPM所使用的边界，1对应于B内实体的一个独立子集，E对应于该B外实体的一个独立子集。实体集是由处理P或文件f组成阁。实际上，E就是I在实体集内的补集，换句话来说，E就是边界外的实体的集合。当然，文件和处理可以通过CPM描述的具体实践手册来识别和计算。
2.2 从逻辑向物理转化的形式化扩充
对以上描述进行提炼，可以得到可计算的单元和物理文件。为了使 IFPUG规则能自动解释执行，这些计算单元和文件可以作为逆向工程技术和算法的输人。可计算单元是可区别的计算过程，这些过程存在于相应的名称、内部状态和对应的边界。具体的可计算单元的性质依赖于所使用的环境和程序设计语言。例如，可计算单元可以是模块、程序函数、对象或源代码等。
一个边界b可以定义为:b={x/(x∈P)V(x∈F)}。其中：P代表处理(Process)的集合，F表示文件(False)的集合。
定义函数(Function):is_in_b:I*B→{True，False}可以识别一个实体是否在一个特定的边界内。
假定C表示由可计算单元和用户接口组成的系统组件集合，则一个可执行边界可以定义为:ib={x/(x∈pwrset〔C))V(x∈PF)}。这里，pwrset(C)是组件的幂集,PF则表示物理文件的集合。
由于B是CPM所定义的边界，IB是可执行边界，则b_impl:B→IB就是从边界b到可执行边界动的一个映射。还可以定义另一个函数:is_in_ib:C*IB→{True，False}来识别组件是否在一个特定的可执行边界内。函数b_impl具体是由如下公式确定的:
其中:p_impl:P→pwrset(C)把一个过程和其组件的执行联系在一起。这些组件和物理文件与正在被计算的功能有关，而且很容易被识别并提供给自动执行工具。在设定了已知应用系统的边界后，其他的计算活动就由用户和计算者来完成。
边界把要度量的软件和软件以外的用户划分开，同时边界也确定了功能点计算的范围。CPM的第4章主要定义了边界，并给出了确定边界的规则和流程。边界的确定在整个功能点计算中显得尤为重要。
可计算单元的输人或输出操作可以定义为get和put两个基本操作。为了不失一般性，把以上定义的函数看成是复杂输人或输出操作的简单推理。对于一个给定的可计算单元，get返回的是影响单个变量的所有可区分的一组输人操作，这样就可以识别出输人的源组件;而put返回的是涉及单个变量的所有可区分的一组输出操作，这样使用标识符钻就可以识别出输出的对象。可以使用形式化方法来描述这两个操作:
get:C→C*ID
put:C→C*IDb_impl(b)
为了表示从逻辑到物理的转化关系(图 3)，假设:如果对于b_impl(b)，b→p_impl(p)是一个EQ，那么p是b的一个EQ。也就是说，处理p是已知边界b内的一个EQ，当且仅当执行P时所需组件也是相应执行边界内的一个 EQ。（图片） 3 评估IFPUG规则的逆向工程方法
要正确理解源代码分析过程中这些独立的IFPUG规则的评估点，必须理解功能点计算过程。FPA要求计算者在计算时遵循有序的步骤。计算过程首先要识别所有需要计算的数据项。
划分系统的步骤为:手动功能点计算者首先要接受培训和认证，然后从终端用户的角度确定计算的边界以完成系统功能的划分。当然这项工作是基于可用的系统文档、系统界面、数据库和报表布局的基础之上，因为只有这样才能识别由源代码确定的物理组件。
即使他们有可用的需求，但逆向工程方法处理的问题是:解决文档所描述的系统和执行过程中的实际系统之间的不一致性。因此，当需求确实可用时，逆向工程技术才会变得有价值。本文上面提出的等式为计算现有实际系统的功能点提供了一种方法。
一旦确定好边界，计算者就开始识别数据功能文件，然后识别事务功能类型。以EQ为例，假定数据功能类型和相关的物理文件都已经识别好，在计算与EQ有关的功能点数量之前必须根据相关规则识别出EQ。特别要处理的是使用逆向工程方法来自动处理一个特定的EQ是否符合这条规则。图4描述了从源代码出发评估EQ的逆向工程流程。当然，逆向工程方法还可以识别 EQ的参考文件类型(FTR)和数据元素类型(DET)。
在对源代码分析的过程中，必须识别出组成 P的可计算单元、P所要访问的用户接口以及P要访问的物理文件和数据元。然后才能根据 CFG中的这些系统组件，根据 CPM 规则识别出 EQ，继而计算出EQ的功能点数量。（图片） 4 结束语
本文首先对 EQ的 4个规则进行了形式化描述，从概念上证实了其可行性，并使用流分析技术对IFPUG规则进行评估。
一般而言，从源代码的角度进行自动功能点度量的逆向工程方法是非常有前景的。当然，目前有很多逆向工程技术可利用，而且也需要估算人为分析在整个功能点计算过程中所占的比例。本文已经对 7条EQ规则中的4条进行了形式化定义。下一步要进行的工作就是要解决 IFPUG所使用术语的精确性与源代码之间的关系。目前，一般从源代码中抽取一些信息作为某些等式的一部分输人，而另一部分输人则来自于人类的判断;而且现有的大多数支撑工具都包含有人类主观因素的干涉。因此，迫切需要估算一下:在自动处理IFPUG的CPM规则时到底需要多少人类交互作用的千预，尽可能避免一些人为因素造成的错误，才能保证IFPUG规则解释的精确性。
当然在度量过程中还可能存在一种偏差。当与随机错误比较时，这种偏差就是总的系统误差。这种保守的近似数据流分析可能会产生基于正确解决方法基础之上的系统偏差。
由于本文仅仅给出4条规则的形式化定义，本文所做的工作仅仅是在计算等式的概念定义阶段，对功能点计算的全自动化研究目前尚处于设想阶段，尚未开发成功，对于全自动化的实现，需要做更进一步的研究。
3/13/2008
|
