专利名称：一种基于熵的构件可信度量方法
技术领域：
本发明涉及可信度量领域，特别是涉及一种基于熵的构件可信度量方法。
背景技术：
软件可信性概念，或者说“可信”这一概念，来源于可信计算，而随着“可信”需求从硬件到软件的扩展，业界对“可信”的理解也在不断延伸。TCG认为“如果系统的行为与结果总是预期和可控的，那么系统是可信的”，容错专家提出并倡导的强调可靠性、可用性的可信计算D印endable computing是指计算机提供的服务是可以论证其是可以信赖的，而且这种可信赖是可论证的；国内武汉大学张焕国等人提出可信就是可靠、可用和安全。构件技术是重要的软件复用手段，旨在提高软件生产效率和质量。但是构件的共享和复用建立在构件使用者信任构件能实现预期功能的基础上，由于构件本身层次多样 (有通用基本构件、领域共性构件、应用专用构件等)，涉及业务种类繁多，构件本身的可信性度量至今在业界没有成熟的方法和技术。但是这不代表在某一具体领域我们不能寻求到构件的可信性度量方法。由此看出，可信性并没有一个公认的通用的定义，我们认为可信软件是具有领域需求的可信属性的软件。对于构件来说，因为更具备领域特性，因此构件的可信性除了一些通用的可信属性，如可用性(Availability)，可靠性(Reliability)，安全性(Security), 实时性(Real Time)，可维护性(Maintainability)和可生存性(Survivability)外，还应扩展一些领域相关的属性。因此，目前需要本领域技术人员迫切解决的一个技术问题就是如何能够创新地提出一种有效的构件可信度量方法，用以度量构件的可信性，提高软件生产效率和质量。
发明内容
本发明所要解决的技术问题是提供一种有效的构件可信度量方法，用以度量构件的可信性，提高软件生产效率和质量；通过创建构件可信性度量框架，对构件的可信属性进行分析与度量，从而获得量化的构件可信性度量结果。为了解决上述问题，本发明公开了一种基于熵的构件可信度量方法，所述方法包括分解出构件的主要功能点；记录每个功能点在需求阶段、设计阶段、编码阶段、测试阶段的可信证据；根据记录的可信证据计算功能点中每个阶段的可信评估值Pi ；计算各个功能点的熵；计算构件的熵，判断构件可信性。优选的，所述构件的可信性作为构件投入使用的标准，构件不可信，重新修改构件开发过程，度量可信性。优选的，所述需求阶段的可信证据包括过程能力资质、计划工作量、实际工作量、计划进度、实际进度、需求人员能力、需求变更数、需求评审结论、评审缺陷密度、缺陷清除效率。优选的，所述设计阶段的可信证据包括计划工作量、实际工作量、计划进度、实际进度、设计人员能力、需求变更数、设计评审结论、评审缺陷密度、缺陷清除率。优选的，所述编码阶段的可信证据包括计划工作量、实际工作量、计划进度、实际进度、编码人员能力、需求变更数、单元测试强度、代码规模、代码可维护性。优选的，所述测试阶段的可信证据包括计划工作量、实际工作量、计划进度、实际进度、测试人员能力、测试工具支持、测试缺陷趋势。优选的，所述可信评估值Pi为该阶段偏离上一步制品的意图的程度。优选的，根据构件可信性度量方法画出可信性树。优选的，所述构件的熵与可信性为负相关的关系，构件的熵越大，可信性越低。优选的，所述构件的熵为各个功能点的熵的平均值。与现有技术相比，本发明具有以下优点本发明中，可信性的度量侧重于过程证据。因为构件可信质量内建于开发过程，测试只能事后检验且带有片面性。假设一个软件的过程证据得分很低，但是测试结果很好，根据二者在可信度量时的权重差异，总体可信性仍然会很低。所以通过过程证据，量化可信性指标，用信息熵作为可信性度量标准是非常恰当的。
图1是本发明一种基于熵的构件可信度量方法的可信度量流程图。图2是本发明一种基于熵的构件可信度量方法的可信度量框架。图3是本发明一种基于熵的构件可信度量方法的可信树。
具体实施例方式为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式
对本发明作进一步详细的说明。参照图1，示出了本发明的一种基于熵的构件可信度量方法的可信度量步骤，所述方法具体包括步骤SlOl，建立可信性度量框架；优选的，所述方法还包括通过过程证据度量可信性。更为优选的，通过测量偏离上一步制品的意图的程度度量各阶段的可信性。参照图2，示出了本发明的一种基于熵的构件可信度量方法的可信度量框架图。在实际应用中，构件开发过程中需要记录的可信证据包括过程证据和测试证据。 前者是开发过程中记录下的证据，后者是在测试环境中记录下的证据。只有二者都达到可信要求，才能确保构件的可信从而可以提交入库投入使用。在整个过程中，有四个重要环节需要提供可信证据需求阶段过程能力资质、计划工作量、实际工作量、计划进度、实际进度、需求人员能力、需求变更数、需求评审结论、评审缺陷密度、缺陷清除效率。设计阶段计划工作量、实际工作量、计划进度、实际进度、设计人员能力、需求变更数、设计评审结论、评审缺陷密度、缺陷清除率。编码阶段计划工作量、实际工作量、计划进度、实际进度、编码人员能力、需求变更数、单元测试强度、代码规模、代码可维护性。测试阶段计划工作量、实际工作量、计划进度、实际进度、测试人员能力、测试工具支持、测试缺陷趋势。在应用中，我们使用“debug管理”软件进行过程证据的记录，使用构件测试工具进行测试证据的记录，证据的记录严格遵守可信证据框架的模板。构件可信评估人员如何根据上述证据来量化各个阶段的可信性呢？因为软件开发是一个逐步演化的过程，每一步都力图实现上一步的意图但不可避免有所偏差，我们要用概率表示出每一步有多大程度的偏差。如需求分析阶段，需求分析人员与构件的客户是否进行了有效的沟通，消除了歧义，本阶段的需求分析说明书多大程度地反映了客户的意图；设计阶段系统分析人员是否完全领会了需求分析说明书，设计方案能否实现前者的功能；编码阶段程序员是否理解设计方案并有能力去实现该方案等。构件开发过程中每一步软件制品只能反映上一步制品的意图，我们也只能测量它偏离上一步制品的意图的程度。 因为构件可信质量内建于开发过程，测试只能事后检验且带有片面性。所以度量可信性时我们侧重过程证据。假设一个软件的过程证据得分很低，但是测试结果很好，根据二者在可信度量时的权重差异，总体可信性仍然会很低。步骤S102，确定可信性量化指标；一个系统由多种要素组成，每个要素都有一定的不确定性，所以系统整体的不确定性就是各要素不确定性的加权平均。优选的，用信息熵作为可信性度量标准。信息熵概念来源于申农的信息论，表征系统整体的混乱程度或不确定度。公式表示为Entropy =Σ pi log pi (1)它的值代表系统不确定性的平均信息量。通过深入研究信任的本质，我们发现用信息熵作为可信性度量标准是非常恰当的。根据可信的定义，如果系统的行为与结果总是预期和可控的，那么系统是可信的。 因此信任度就是客体的运行结果和主体的期望的吻合程度。因为构件乃至整个计算机系统相当于一个函数，确定的输入必定有确定的输出，所以按运行结果的期望的吻合程度，可以转化为对运行系统的了解程度。例如我完全信任你，实质代表我对你情况完全了解。我对你还有多大程度的不了解，决定我对你有多大程度的不信任。反之，主体对客体越了解，对其不确定性消除越多，就越信任客体。客体的运行结果和主体的期望就会越吻合。如若能用程序证明理论分析软件程序的源码，并证明它是正确的，则可信性为1，即对该软件完全了解自然也就完全信任；若一个软件内部结构和开发过程细节都不提供，黑盒测试结果也与标榜的有很大差别，则可信性为0，表示对该软件完全不了解，它下次运行结果我们完全不可预期和控制。其他类型的软件，依据过程和测试证据打分情况，可信性会介于二者之间。我们考察构件使用者对构件开发和测试过程的了解情况，并用概率表示不了解程度。对这些概率求其加权平均即是对整个构件的熵。熵与可信性是负相关的关系，即构件的熵越大，可信性越低。根据构件的熵我们可以对构件的可信性划分等级。步骤S103，度量构件可信性；
5
优选的，用信息熵作为可信性度量标准。更为优选的，根据可信性度量方法画出可信性树。如图3所示本发明所述的一种基于熵的构件可信度量方法的可信树。面向数据处理的构件一般是基于一个数据处理算法，过程性强，实现的功能点清晰明确。因此度量构件可信性时，我们分解出主要功能点(根据需要确定功能点的粒度)， 然后画出可信树。首先分析功能点1，在需求阶段，专家通过分析客户的需求以及可信性度量框架中记录的可信证据，给定该阶段的可信评估值Pi ；设计阶段根据该阶段记录的可信证据测量它偏离需求阶段的意图的程度，给定P2;编码阶段，程序员是否理解设计方案并有能力去实现该方案，根据编码阶段记录的可信证据计算出该阶段的可信评估值P3 ；测试阶段，对实现的构件从功能、性能、安全性等各个角度进行测试，根据记录的可信证据得出该阶段的可信评估值P4。在得出PI、P2、P3、P4之后，根据熵的计算公式⑴计算出功能点1的熵值。功能点2以及其余的功能点都按照功能点1的分析过程进行分析，然后计算出每个功能点的熵值。所有的功能点分析完之后，计算所有功能点的熵值的平均值，该值即为构件的熵。由于所有的构件可信性都用该方法计算，所以熵值可以相对地比较出各个构件的可信性高低。熵与可信性是负相关的关系，构件的熵值越大，可信性越低。经过对可信性的度量，如果得出构件是可信的，则该构件可以提交入库投入使用；如果构件是不可信的，则要分析是哪个阶段出现了问题，然后对其进行修改，使构件达到可信度要求。下面以某金融领域汇率取得构件的开发为例，介绍上述可信性度量方法的运用实例。在实际开发过程中，我们根据可信证据和开发记录依次分析每一阶段软件制品针对上一步的可信度。第一阶段客户需求陈述。客户需求是构件生命期的起始，它与客户真实意图的微小偏离将会在后续阶段放大。所以我们务必保证客户需求尽量明确，为此我们要求客户有书面需求陈述。该陈述也是可信证据的一部分。专家将对照该陈述和需求分析文档来给定 pi。第二阶段构件设计阶段。包括构件的接口设计、接口描述和类设计三部分(本文略过)。构件接口设计在面向数据处理的软件生产线平台中，构件与构件之间的调用主要通过XML进行数据交互，因此构件所提供的方法的输入和输出参数，不仅支持普通的 JAVA类型参数，同时都提供了 XML支持。构件接口描述主要包括两部分内容构件功能描述和构件接口调用描述。其中构件功能描述主要用于构件的检索及查看，构件接口调用描述主要用于构件与构件之间的自动组装。前者包括构件的类型、分类、功能描述、约束、可信度描述(测试用例)等，后者主要描述构件是如何被调用的，主要涉及到构件的类名、构件的方法名、构件的输入参数和输出参数等等。第三阶段代码实现根据设计进行代码实现，对完成的代码进行严格的版本管理。第四阶段测试对实现的构件从功能、性能、安全性等各个角度进行测试。因为我们每一步都有详细的证据和文档，所以评审专家能根据这些资料评估每一步软件制品相对上一步的偏离程度Pi，从而可以熵的计算公式(1)计算出信息熵当作可信度的度量。因为信息熵值没有绝对的含义。因此构件的过程证据信息应按统一的标准和工具记录和测定，在算出各构件的信息熵后我们可以根据需要划分构件的可信度等级了。本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。以上对本发明所提供的一种基于熵的构件可信度量方法进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想， 在具体实施方式
及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。
权利要求
1.一种基于熵的构件可信度量方法，其特征在于，所述方法包括 分解出构件的主要功能点；记录每个功能点在需求阶段、设计阶段、编码阶段、测试阶段的可信证据； 根据记录的可信证据计算功能点中每个阶段的可信评估值Pi ； 计算各个功能点的熵； 计算构件的熵，判断构件可信性。
2.根据权利要求1所述的方法，其特征在于，所述构件的可信性作为构件投入使用的标准，构件不可信，重新修改构件开发过程，度量可信性。
3.根据权利要求1所述的方法，其特征在于，所述需求阶段的可信证据包括过程能力资质、计划工作量、实际工作量、计划进度、实际进度、需求人员能力、需求变更数、需求评审结论、评审缺陷密度、缺陷清除效率。
4.根据权利要求1所述的方法，其特征在于，所述设计阶段的可信证据包括计划工作量、实际工作量、计划进度、实际进度、设计人员能力、需求变更数、设计评审结论、评审缺陷密度、缺陷清除率。
5.根据权利要求1所述的方法，其特征在于，所述编码阶段的可信证据包括计划工作量、实际工作量、计划进度、实际进度、编码人员能力、需求变更数、单元测试强度、代码规模、代码可维护性。
6.根据权利要求1所述的方法，其特征在于，所述测试阶段的可信证据包括计划工作量、实际工作量、计划进度、实际进度、测试人员能力、测试工具支持、测试缺陷趋势。
7.根据权利要求1所述的方法，其特征在于，所述可信评估值Pi为该阶段偏离上一步制品的意图的程度。
8.根据权利要求1所述的方法，其特征在于， 根据构件可信性度量方法画出可信性树。
9.根据权利要求1所述的方法，其特征在于，所述构件的熵与可信性为负相关的关系，构件的熵越大，可信性越低。
10.根据权利要求1所述的方法，其特征在于， 所述构件的熵为各个功能点的熵的平均值。
全文摘要
本发明提供了一种基于熵的构件可信度量方法，所述方法包括分解出构件的主要功能点；记录每个功能点在需求阶段、设计阶段、编码阶段、测试阶段的可信证据；根据记录的可信证据计算功能点中每个阶段的可信评估值Pi；计算各个功能点的熵；计算构件的熵，判断构件可信性。发明中可信性的度量侧重于过程证据，通过过程证据，量化可信性指标，用信息熵作为可信性度量标准，更有效地度量构件的可信性。
文档编号G06F11/36GK102279793SQ20111022389
公开日2011年12月14日 申请日期2011年8月5日 优先权日2011年8月5日
发明者吴海燕, 张新钰, 许斌, 贾宁, 郑莉 申请人:清华大学