CN101589380A - 基于上下文的代码分析 - Google Patents

Abstract

实施例提供与目标代码的分析检查有关的一组形式化的中间分析上下文。这样的中间分析上下文可包括但不限于，目标代码的开发阶段、目标代码的类型或状态、操纵目标代码的源、目标代码的用途或者其它开发或运行时要求。因此，实施例动态标识正在其下开发目标代码的当前分析上下文并且随后可基于规则可应用什么上下文的了解来执行规则。更具体地，分析规则可描述(例如通过元数据)规则可在其下运行的那些上下文条件。基于这样的描述和当前上下文，可以执行已经被配置为应用于这样的上下文条件的那些规则。

Description

基于上下文的代码分析

背景

大多数软件被开发为大量可重用的软件对象，它们各自被设计为执行一或多个任务。软件的实用性与功能以及运行该软件的计算系统，依赖于对被编译或解释以便处理器执行的源代码的正确编码。编码错误通常引起偏离软件的预期功能，并且有可能影响计算机系统的其它部分(例如，其它应用程序、数据库、操作系统等)。这样的编码错误不仅破坏用户有关软件的计算体验，而且还会在整个计算机系统中引起不希望的效果。因此，高质量软件的生产者花费大量的测试和分析努力来消除其软件中的错误。

然而，市场需求和编程者与设计者的创造性已经导致日益复杂但强大的软件。随着软件复杂性的增加，实现软件所需的源代码行数通常也增加。其直接结果是源代码中错误的可能性持续增加。因此，必须经常以各种方式(在发布之前和之后)多次测试和分析软件，以帮助保证软件按预期方式运行。

在一些分析环境中，测试者开发自动化规则或测试(在本文中可互换使用)，它们验证软件的一或多个部分的操作。例如，规则可自动化图形用户界面内输入域值的输入，以各种输入参数并在各种各样的条件下调用软件对象，收集产生的输出，并且确定测试是通过还是失败。测试者(无论是否为测试开发者)随后可执行测试实例，它提供正在测试的对象或目标代码通过还是失败(且由此对象是否按预期方式运行)的指示。

当前，测试开发者编写不同的规则用于不同级别的软件验证，即每一规则在确定对象或代码段通过还是失败时执行的分析量。用于测试软件的规则的验证级别依赖于无数因素而很大地变化。因此，通常在运行规则或测试实例所消耗的时间量与彻底测试软件的程度之间有一个折衷。具体地，生成与分析的输出越少，则进行测试所消耗的时间就变得越少。例如，测试开发者可编写用于仅测试软件的压力或负荷的规则。在此情形中，可忽略测试实例产生的输出，并且如果软件或系统没有崩溃，则认为对象或目标代码已经通过。尽管该分析形式允许快速测试软件，但不提供对由软件引起的所有效果的完整测定。因此，在确定每一规则所需的验证级别以适当地分析软件时，通常存在许多必需的商讨与考量。

为了允许各种各样的测试验证级别，已经开发了代码分析工具(例如静态代码分析工具)，它们为软件开发者提供在其代码中检查问题和矛盾的半自动化机制。更具体地，测试开发者用一组具有各种验证级别的规则来填充这些工具来分析软件源、目标或二进制代码，以便标识其正确性、完整性和/或质量。这些工具一般作为通过各种配置形式控制的整体操作来完成或执行对软件的分析。换言之，应用于代码的特定检查或规则由源控制表达式(诸如#pragma)、经由工具命令行选项或者通过在单独的控制文件中给出的设置来启用或禁用。尽管这允许测试者对在开发过程中的各级处要运行什么类型的规则进行某种程度的控制，但这样的方法仍存在若干缺点和限制。

例如，为了适当地测试代码，测试者(即静态代码分析工具的用户)需要对各种规则具有详尽的了解，包括但不限于在什么级和在什么条件下应当应用这些规则。然而，了解所有测试实例，通常超出了大多数代码开发者的专业知识(因为他们通常不是专业的测试开发者)。因此，测试者可能不能在适当的时间并在适当的条件下应用规则。而且，因为这些测试在实质上通常是静态的(即，它们通常由来自测试者的明确表示来执行)，所以在执行这些测试时存在各种时间效率低下的情况。例如，相同的检查可能反复运行，在过程中不适当的接合处可能引起问题(例如，在重复地忽略或推迟它们的地方)，和/或不能在开发过程的足够早的时间标识错误或故障(即，不言自明的是，标识或定位问题的时候离开工(check in)越远，则要解决它的成本就越高)。因此，典型代码分析工具的这些和其它有关缺点经常引起大量问题，诸如未完成的工作、用户和开发者受挫、性能问题、未标识的错误和故障、时间成本等等。

简要概述

通过本发明的示例实施例，克服了上面标识的当前代码分析工具的不足与缺点。例如，本文描述的实施例提供一种代码分析工具，它通过动态地跟踪在其下开发代码的分析上下文并且应用对应于当前上下文条件的规则(或其部分)来自动管理一组预定义规则的执行，以便平衡性能考量。注意到，提供本概述以便用简化形式介绍将在下面详细描述中进一步描述的一些概念。本概述不旨在标识要求保护主题的关键特征或基本特征，也不旨在用于帮助确定要求保护主题的范围。

一个示例实施例提供一种配置有代码分析工具的计算系统，该工具接收要基于一组预定义的规则对正确性、完整性和/或质量进行分析的目标代码。还从开发设备接收代码分析上下文信息，用于动态跟踪正在其中开发该目标代码的当前代码分析上下文。此外，接收对应于从该组预定义规则中选择的规则的上下文参数。注意，上下文参数按照代码分析上下文信息描述该规则的至少一部分的执行条件。之后，根据当前代码分析上下文评估规则上下文参数，用于动态确定该规则的至少一部分是否能针对正在分析的目标代码执行；因而，在开发过程中的适当阶段处应用该规则的至少一部分。

其它示例性实施例提供一种代码分析工具，它包括动态上下文跟踪模块，用于从开发设备接收用于确定正在其中开发目标代码的当前代码分析上下文的代码分析上下文信息。代码分析工具还包括规则管理模块，用于按照代码分析上下文信息评估当前代码分析上下文和指示规则的至少一部分的执行条件的上下文参数。基于评估，规则管理模块动态确定规则的至少一部分可以针对要对正确性、完整性和/或质量进行分析的目标代码来执行。另外，代码分析工具包括执行模块，用于针对正在分析的目标代码执行规则的至少一部分，使得规则的至少一部分在开发过程中的适当阶段得到应用。

本发明的其它特征和优点将在后面的描述中阐述，并且通过该描述其部分将是显然的，或者可通过实践本发明来领会。本发明的特征和优点可借助于所附权利要求书中具体指出的工具和组合来了解和获得。本发明的这些和其它特征通过下面的描述和所附权利要求书将变得更为显然，或者可通过实践如下文阐述的本发明来领会。

附图简述

为了描述可以获得本发明的上述及其它优点和特征的方式，将参考本发明在附图中例示的特定实施例来提供上面简述的本发明的更具体描述。可以理解这些附图只是描绘本发明的典型实施例并且因此不应视为对本发明范围的限定，将通过使用附图以额外的特殊性与细节来描述本发明，这些附图是：

图1例示按照示例实施例被配置为基于正在其下开发目标代码的上下文动态检查软件的代码分析工具；以及

图2例示按照示例实施例用于通过动态跟踪正在其下开发代码的分析上下文来管理规则的执行的方法的流程图。

详细说明

本发明延及用于基于正在其下开发代码的当前上下文动态管理规则在代码分析工具中的执行的方法、系统和计算机程序产品。本发明的实施例可包括包含各种计算机硬件或模块的专用或通用计算机，如下更详细地描述的。

本文提供的实施例形式化多个与目标代码的分析检查有关的中间分析上下文。因此，实施例动态标识正在其下开发目标代码的当前分析上下文，并且随后可基于规则可应用于什么样的上下文的了解来执行规则(或其部分)。这样的中间分析上下文可包括但不限于，目标代码的开发阶段、目标代码的类型或状态、操纵目标代码的源、目标代码的用途或者开发或运行时要求。注意，这样的中间分析上下文与软件开发过程除字面上的代码的开发之外的其它阶段有关。这些其它阶段可包括但不限于，构建和打包表示、部署测试以及在照字面意义执行——例如在各种机器和网络配置中执行时的运行时的代码的分析。当然，存在用于定义或形式化代码分析上下文的众多重叠或其它的关系。因此，本文定义的术语“代码分析上下文”应当宽泛地解释为包括任何数量的上面提到的并在后续实施例中更详细地定义的分析上下文、它们的组合和/或其分层关系。

注意，对当前的上下文条件的了解可由系统以各种方法来获得。例如，这样的上下文信息可通过与集成开发环境(IDE)的耦合来获得，集成开发环境通常传达项目类型和源语言，并且可能具有对编译器设置和/或构建风格等等的了解。可替换地，或者相结合地，这样的上下文信息可通过检查基于源的和编译器所提供的元数据和/或通过检查作为二进制代码的宿主的机器来获得。另外，用于提供代码分析信息的其它上下文源可包括诸如检查作为机器的宿主的较大网络系统之类。

不管如何确定当前的代码分析上下文条件，为了确定与这些条件有关的规则集，分析规则(或其它数据对象)可以描述(例如通过元数据)在其下规则(或其一部分)能运行的那些上下文条件(以及诸如规则优选或默认上下文等其它信息)。有关用于运行规则的上下文或所提供的其它信息(例如在元数据中提供)的这些决定可由规则开发者作出，但其它实施例还允许修改、噪声过滤和/或覆盖这些上下文条件。例如，一些实施例允许通过IDE内的明确表示和/或通过修改关联于分析运行的控制文件来修改或覆盖规则可在其下应用的上下文。因此，当开发者转到配置代码分析选项时，该开发者可具有覆盖关联于每一规则的一组上下文的选项。该信息随后可存储在包含由用户设置的其它代码分析选项的项目文件中。

不过，对于还未被覆盖的那些规则，在各个开发级期间，动态确定当前的上下文，并且基于提供的信息或元数据，执行已经配置为应用于这些上下文条件的那些规则。如可以看到的，这允许在各个开发级期间对代码的动态分析，使得可在开发过程中尽可能早地向代码开发者通知潜在问题。另外，测试开发者，通常具有有关规则的更专业知识，可以考虑和设置规则应当在其下应用的上下文。此外，随着条件改变或发展(例如，在其下开发目标代码的经形式化的上下文条件发生改变)，还可以修改各种元数据并保持最新，从而使这些规则能够扩展。

尽管下面参考附图更详细地描述对有利特征的更具体引用，但本发明范围内的实施例还包括用于携带或其上存储有计算机可执行指令或数据结构的计算机可读介质。这样的计算机可读介质可以是可由通用或专用计算机访问的任何可用介质。作为示例但非限制，这样的计算机可读介质可包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁存储设备，或者可用于携带或存储计算机可执行指令或数据结构形式的程序代码工具并且可由通用或专用计算机访问的任何其它介质。当信息通过网络或其它通信连接(硬连线的、无线或者硬连线或无线的组合)传送或提供至计算机时，计算机适当地将该连接视为计算机可读介质。因而，任何这样的连接适当地被称为计算机可读介质。上述的组合也应当包括在计算机可读介质的范围内。

计算机可执行指令包括例如使通用计算机、专用计算机或专用处理设备执行某一功能或某一组功能的指令和数据。尽管已经以专用于结构特征和/或方法动作的语言描述了本主题，但应理解，所附权利要求书中定义的主题不必限于上述特定特征或动作。相反，上述特定特征和动作是作为实现权利要求的示例形式而公开的。

如本文使用的，术语“模块”或“组件”可以指在计算系统上执行的软件对象或例程。在本文描述的不同组件、模块、引擎和服务可被实现为在计算系统上执行的对象或进程(例如作为独立的线程)。尽管在本文描述的系统和方法较佳地以软件来实现，但用硬件或软硬件组合的实现也是可能且被构想的。在本说明书中，“计算实体”可以是在本文之前定义的任何计算系统，或者是在计算系统上运行的任何模块或模块组合。

在本文描述的实施例提供一种代码分析工具，它考虑无数因素来动态管理规则的执行以便平衡性能考量。例如，本文的实施例考虑到，由一些规则生成的消息当在构建代码期间或之后检测到时进行修补的成本更高。因此，开发者可能想要尽可能早得到关于这些警告的通知，通常是在编辑代码的时候。另外，一些规则生成的消息对解决代码何时准备好用于诸如开工的各个开发级或者开发里程碑何时完成最感兴趣。作为一个示例，在里程碑未完成时执行检测无用代码的分析没有多大意义，因为代码可能在以后的开发过程中使用。而且，如前所述，一些规则的运行成本特别高。因此，开发者可能不想在每次增量构建或者甚至完全的重建时招致这样的分析成本。

要考虑的其它因素说明规则取决于其功能需要或多或少的二进制元数据来完成分析。这些规则可能需要仅在源代码中可用的信息，它们可在实际生成文件时编译掉。但是，其它规则需要被写到盘或将被写到盘的字面上的目标代码。另外一些实施例说明一些规则需要二进制代码出于在真正发布状态中的考量，这与开发者在客户箱(client box)上生成的构建不同。例如，开发者一般不创建完全签名的二进制代码，它们是由特定公司的实际安全密钥来签名的。

要顾及的另外一些因素考虑到一些规则依赖于与客户开发者系统明显不同的机器配置。例如，一些web应用程序分析可能只是在针对实际部署在web服务器上的代码执行时才是有关的。另外，一些规则需要有关二进制代码的执行上下文的特殊了解。例如，从未被本地化或者在非英语系统上运行的代码一般不需要针对全球化/本地化专用的问题进行检查。还考虑到，一些规则必须在特殊的上下文中运行，以便验证与较大的网络系统有关的问题。作为示例，针对为因特网的部署的web应用程序的安全检查可能需要在防火墙内联网外执行。

本文还构想一些规则行为按照与代码的生存期有关的环境而改变的事实。作为示例，可能需要之前已经向外界客户发布的二进制代码以维护高级别的后向兼容性。因此，不应当激发会激发要求破坏性改变来解决的违规的规则。另外，一些规则行为按照对执行行为的运行时预期而改变。作为示例，一些性能检查可能仅与频繁调用的性能敏感代码有关。不希望针对非频繁调用的代码或者必须蒙受压倒解决被标识问题的好处的执行成本的代码来运行这些规则。与上述有关，分析应当在其它环境中按照在分析目标代码中是否有可能进行修补而变化。作为示例，分析可能针对编译器发出的、不会受到改变用户代码的影响的代码模式进行。然而，编译器团队可能希望标识这些问题并且对生成分析目标的编译器作出改变。

在一些实施例中还构想的是，一些规则按照对目标二进制代码的预期重用(或者不重用)而改变行为。例如，可由任意第三方开发者消费的代码可能需要遵循某些标准以便提供一致性与可用性。对于一个实施不同编码标准的团队的完全内部项目，可能无视这些标准。另外，规则行为可能按照项目资源考量而改变。例如，对于具有受约束资源或者具有紧张时间期限的项目，分析可能需要被限制于具有重要纠正暗示的高度确定性结果。

当然，按照本文描述的用于基于开发过程中的各种上下文管理规则的执行的示例实施例，存在无数因素和考量可供考虑。事实上，如在下面将更详细地描述的，因为在其下开发代码的分析上下文不断地改变，本文描述的实施例允许如何管理和执行各种规则的可扩展性。因此，本文描述的用于确定规则(或其一部分)应当在什么上下文下执行的考量仅用于说明性的目的，并且除非明确要求否则不表示限制或者缩小本发明的范围。

无论如何，在考虑上述考量中的一些的情况下，图1例示基于正在其中开发代码的当前代码分析上下文来管理规则执行的代码分析工具100。如图1所示，为了开发，目标代码120可分布在无数开发设备105的一或多个之中，开发设备105包括IDE 110和能提供上下文的、诸如列为其它上下文源115的其它设备。例如，目标代码可以是IDE110中的源代码形式，或者可以是在机器或系统内运行的二进制代码。当然，本文还构想了其它形式的目标代码120。例如，如下面更详细地描述的，目标代码120还可处于设计阶段，即来自源代码的抽象概念。因此，本文描述的任何特定类型的目标代码120将依赖于适当的开发或运行时状态。

不管开发或运行时状态，本文的实施例提供能从如本文所述的各种开发设备105获得代码分析信息125的动态上下文跟踪模块130。如在下面将更详细地描述的，代码分析信息125包括有关当前正在其下分析和/或开发目标代码120的上下文的信息。注意，代码分析信息125且由此分析上下文信息可由代码分析工具100或者动态上下文跟踪模块130通过各种方法来获得。例如，动态上下文跟踪模块130可以耦合至IDE 110，后者可传达项目类型和源语言，并且还可能具有对编译器设置和构建风格等的了解。

代码分析125中的上下文信息也可以通过检查诸如基于源且编译器提供的元数据的其它上下文源115、通过检查作为二进制或目标代码120的宿主的机器和/或通过检查作为机器的宿主的较大网络系统来获得。当然，如会了解的，存在众多可由动态上下文跟踪模块130获得的上下文源115。事实上，代码分析工具100内的模块(例如，规则执行模块140)和/或甚至规则本身可提供代码分析信息125。因此，用于提供如本文所述的代码分析信息125的任何特定的设备、组件、模块、数据对象等仅用于说明性的目的，并且除非明确声明否则不表示限制或缩小本文的实施例范围。

还要注意，代码分析信息125可以通过任何众多周知的机制诸如请求-响应、推-拉、发布-提交(pub-sub)系统等等来动态获得。例如，一个实施例允许代码分析信息125使用事件通知系统来获得。例如，在上下文改变或影响目标代码120开发的其它事件发生时，通知(通常以代码分析信息125的形式)可以由动态上下文跟踪模块130发送或以其他方式接收。当然，存在用于获得代码分析信息125的众多方法。因此，对如何获得代码分析信息125的任何特定引用在本文中仅用于说明性的目的，并且除非明确声明否则不表示限制或缩小所述实施例的范围。

无论如何，如前所述，动态上下文跟踪模块130形式化多个与检查有关的分析上下文。因此，不管从哪里以及如何获得代码分析信息125，随后可使用信息125基于动态上下文跟踪模块130内定义(或以其他方式获得)的那些上下文来确定当前代码分析上下文135。注意，当前代码分析上下文135可按照诸如前面提到的众多考量来定义。例如，这样的分析上下文可按照目标代码120的开发阶段、目标代码120的状态、操纵目标代码120的源类型、目标代码120的用途和/或其它开发或运行时要求和考量来定义。

注意，上面定义的分析上下文可包括无论是否用各种分层术语来表达的众多属性或条件(例如，分析离编写代码有多远)。例如，按照开发的阶段定义的代码分析上下文可包括设计、构建、部署的各级，或者其它阶段或属性。另外，分析上下文可按照之前的阶段以及正在进行分析的当前阶段来定义。而且，每一开发阶段可进一步由其它子阶段来定义。例如，构建级可包括编辑阶段、用于增量构建的编译阶段或者开工之前(before a check in)子阶段的子级。作为另一个示例，分析上下文可按照其诸如源代码、目标代码、二进制代码或者抽象代码状态(它一般不提供对代码本身的完整描述)之类的状态或类型来定义。

还要注意，分析上下文(例如，在该情形中可以是当前代码分析上下文135)可进一步按照相互之间的分层关系来定义。例如，一个代码分析上下文可按照另一分析上下文的成功(或者不成功)完成来定义。而且，在分析上下文之间可以存在重叠属性，诸如按照针对无论是否准确对应于将向客户发布的二进制代码的构建环境定义的上下文的情形。当然，存在用于定义或形式化代码分析上下文的众多关系。因此，如前所述，术语“代码分析上下文”(例如，当前代码分析上下文135)应当宽泛地解释为包括在本文定义的任何数量的分析上下文、它们的组合和/或分层关系。

不管定义的形式化代码分析上下文如何，结合代码分析信息125使用该上下文列表来确定当前代码分析上下文135。因此，规则管理模块155可以使用当前代码分析上下文135来动态管理分析规则存储器170中规则175的执行。更具体地，为了规则管理模块155动态确定用于相对于当前代码分析上下文135执行的规则175的集合，每一分析规则175(或者其它数据对象)描述(例如通过元数据)规则可在其下运行的上下文参数180。通常，这样的上下文参数180将由规则开发者来定义；然而，实施例还构想了允许使用规则配置模块165来修改和/或添加上下文参数180。如将更详细地描述的，也可通过其它各种机制来覆盖这些规则。

无论如何，上下文参数180可包括诸如可以应用或者不可应用规则175的上下文之类的信息，和/或可具有确定优先级的上下文列表，例如，按照支持的、优选的、可选的、要求的或者任何其它周知的优先次序。作为一个更具体的示例，命名和装箱规则可标记为支持所有的分析阶段(即命名规则可适于在任何开发阶段执行)。然而，优选的执行阶段可以是后台时期。因此，这些检查应当在开发者正在编辑源的同时执行，但也可在其它阶段执行。

另外，上下文参数180可以包括按照诸如用于完成分析的运行时持续时间、输入所需的信息或者产生的输出等行为来定义规则的元数据。因此，这样的附加信息可由规则管理模块155使用来确定需要执行的适当规则150(和/或由动态上下文跟踪模块130使用来确定当前代码分析上下文135)。当然，上下文参数180可按照重叠属性、分层关系等以上面参考代码分析上下文描述的类似方式来定义。例如，在一个实施例中，规则的分析可在等于当前指定的阶段或者离当前指定阶段更远的任何阶段中发生。例如，被配置为在后台编译期间运行的规则也可在构建、或里程碑阶段期间运行。

注意，通常，一般具有有关规则的更专业知识的测试开发者可以考虑和设置规则应当在其下应用的上下文参数180。这些考量可包括但不限于以下各项(不必按照任何特定的顺序)。第一，在什么开发阶段由该规则生成的消息有意义？第二，控制应当多快返回给用户？例如，在编辑代码的同时进行的分析一般不应当影响编辑器可感知的性能。第三，需要多少元数据来完成检查？例如，针对对象设计图进行的分析可能不提供有关类型是否对于第三方开发者公开可见的信息。第四，对问题的可能修补是否构成破坏性改变？也就是说，修补该问题是否会打断所修改的应用编程接口(API)之前版本的消费者？如果是，则可能需要将该信息在开发过程中尽可能早得给予开发者。否则，如果标识了针对之前已经出厂的代码的破坏性性改变，则一种典型的解决方案是根本不向开发者显示该问题(假设分析已经被配置为保持高级别的后向兼容性)。换言之，如果该问题已经出厂并且因此修补不再安全(因为它可能引起打断之前版本的打断)，则可能必须或者需要对结果的过滤。第五，解决问题的成本如何？代码改变的程度是多少？分析要花多少时间？改变引起退化的可能性多大？与问题有关的源代码是否可进行修改？第六，有什么特殊的二进制代码、操作系统(OS)、机器和/或网络考量影响规则行为和/或检查是否应当运行？第七，有什么特殊的项目考量影响什么分析发生和/或应当向用户返回什么结果？

另外，如前所述，本文的实施例规定，上下文参数180是可修改的或者可配置的。因此，规则配置模块165可(由规则和/或代码开发者)使用来扩展或以其他方式限制规则可在哪些分析上下文下运行。可替换地，或者另外，通过配置设置/控制文件160可覆盖规则可在其下运行的上下文。例如，通过诸如IDE 110内明确的表示或者通过修改关联于分析运行的控制文件之类可覆盖规则。因此，一个实施例允许开发者访问配置代码分析选项，它可允许开发者覆盖关联于每一规则的上下文集合。随后可将该信息与其它信息存储在包含用户设置的其它代码分析选项的项目文件中。

与规则/上下文的配置有关，本文实施例还考虑一些配置表示可专用于检查；并且因此，本文提供了可耦合至较大的分析上下文的配置选项。例如，本文实施例允许规则以某种方式来调节(例如，范围在0-100％之间并且可以通过提供给用户的旋钮或其它调节控制机制来调整的噪声过滤设置)，这限制了用于审阅的输出、将输出限于高度确定性选项和/或限制了分析的时间。注意，该规则配置选项应当在系统中无缝地存在，并且在规则专用配置与较大系统所定义的上下文之间可以存在耦合(例如，在运行后台分析时，将噪声水平限于50％确定性或更高)。

其它实施例还允许将分析上下文可配置性映射至项目中的人员角色。更具体地，工作于软件开发项目的人员一般：(1)对在暗示分析上下文的特定接合处的代码作出贡献；具有各不相同的专业知识，该知识将使得他们对结果的敏感性或多或少；以及(3)对作出有关在何处分配(以及可能地，分配多少)资源的决策具有或多或少的权限。例如，开发者应当看到专用于针对开发者所应答的代码的此改变的结果。另一方面，可允许项目管理员回拨(dial back)结果以便限制专用于特定分析的开发者/测试循环。与之相比，负责标识和修补与二进制代码/产品完整性有关的问题(例如，所有二进制代码都存在？防病毒？没有损坏？等等)的构建管理员却既没有修补正确性问题的技术资格，也没有此能力。因此，本文实施例允许本文描述的分析上下文配置自动映射至团队中的各种角色以及代码开发和运行时过程中涉及的其它角色。

不管如何配置规则和/或分析上下文，基于在当前代码分析上下文135之间的分析、每一规则175内定义的上下文参数，和/或基于配置设置/控制文件160，规则管理模块155随后可选择一组规则150来执行。因此，规则执行模块140可以针对目标代码120应用该组规则150以产生结果145。如会了解的，这样的结果145将依赖于诸如分析上下文、正应用的规则及其它因素之类而很大地变化。例如，结果145可以立即被报告给编辑源代码的用户作为对诸如命名约定分析之类的智能感知文字(intellisense squigglies)，而其它规则150可根本不向用户产生反馈，如对于一些压力测试。可将其它结果140报告给文件和或以某种其它数据格式产生用于进一步分析。当然，存在可应用于本文描述的实施例的众多结果145，并且在任何描述的上下文下产生的任何特定结果仅用于说明性目的并且不表示限制或者缩小本文实施例的范围。

下面提供按照目标代码的开发阶段、目标代码的类型和/或状态、操纵目标代码的源、目标代码的用途或其它开发和/或运行时要求定义的中间分析上下文的一些示例。如上所述，以及在下面的描述中，这些中间分析上下文还可按照任何组合、重叠属性和/或分层关系来定义。而且，如前所述，上下文参数180、所定义的分析上下文(例如，当前代码分析上下文135)、配置设置/控制文件160以及规则本身是可扩展的，因此下面分析上下文和/或描述的规则的列表(以及本文描述的其它上下文或分析)不旨在是详尽的。

例如，规则175可按照在IDE 110中的编辑级期间进行的后台分析来描述，例如用于向开发者通知对源代码的改变。其它分析可在每一增量构建或完全构建的上下文中进行，如由上下文参数180所定义的。例如，在编译期间，可执行为后台和编译阶段定义的规则。这样的检查可与命名和装箱有关，并且通常具有极端的性能和/或表示标记通常应当立即解决的严重问题的高值正确性检查。

上下文参数180和/或当前代码分析上下文135可按照在开工之前阶段进行的分析来定义。例如，在开工之前，可进行卷起后台、编译以及进行阶段规则的分析。因此，专以开工阶段为目标的规则175通常是花较长时间来执行和/或标记通常不应当被注册到官方源库中的问题的高值规则175。

其它分析上下文可被定义或标记为按照里程碑阶段运行，它通常由明确的用户表示来执行。因此，专以里程碑阶段为目标的规则可以是运行成本极端昂贵的规则，它们要求高水平的审阅(即，它们比其它检查较易发生假阳性)，和/或它们构成因调度考量或因为工作更易于作为批处理来完成而被推迟的工作项目。

当然，如前所述，随着用于代码分析100的环境的改变，在其下运行规则175的分析上下文也会改变。例如，随着处理速度增加，可确定之前仅在里程碑阶段运行的规则可在之前的一些阶段中运行。然而，要注意的是，存在可以改变或影响分析上下文的众多因素，这就是为什么可以使用规则配置模块165来修改上下文参数180(以及用于创建当前代码分析上下文135的分析上下文的形式化表示)以便在需要时更新和调整系统。

其它分析上下文可包括在构建环境中针对可以或可以不精确对应于将发布给客户的内容的二进制代码而进行的分析。还可以存在针对部署在不必对应于顾客运行时环境的配置上的二进制代码而进行的分析。此外，如前所述，可以存在针对通常不提供对得到的代码的完整描述的抽象概念(诸如设计时分析)而进行的分析。其它分析上下文可由被发行至盘的源或目标代码来定义。其它分析上下文考虑或说明编译设置，诸如当前构建是否已经用优化来构建。针对二进制代码进行的其它分析可考虑特定代码用途或运行时用途，诸如在非英语系统上运行或者部署为web应用的一部分的那些用途。因此，例如将不会被本地化或者在非英语系统上运行的这类代码可能不需要针对全球化/本地化专用的问题进行分析或者为这类问题执行规则。另一分析上下文或上下文参数185可按照针对在或不在专门环境(诸如内联网服务器或者在防火墙的另一侧上)中部署的二进制代码而进行的分析来定义。这样的规则通常在特殊上下文中运行以便验证与较大的网络系统有关的问题。

其它代码分析可针对之前已经出厂或未出厂的代码而进行，或者针对可由第三方式提供或可不由第三方的代码而进行。例如，如果上下文被认为来自第三方，则需要按照上下文参数180定义地来运行病毒检查或规则。其它的分析可针对由外部或内部客户消费或不可由其消费的代码而进行，或者针对限制在私人团队或其它运行时环境中使用的代码而进行。分析上下文还可由针对可具有或可不具有对运行时特性诸如性能或安全性有严格要求的目标的分析来定义。在较少安全性有关的分析者随后对其编码之前要求高级安全许可(诸如写到任意盘位置的能力)组件将在部分信任的环境中运行。还有其它的分析上下文包括针对将部署在具有特定操作系统配置(诸如仅启用政府批准的加密服务的要求)的系统上的目标的分析。其它分析上下文可针对处于或不处于维护模式中的目标或者在受到严格的人员配备或最终期限考量的团队上开发的目标来定义。

注意，分析有可能针对各种结构(即目标代码120)发生，这些结构指源自源代码、二进制代码或与两者都不相关联的抽象概念(诸如分析类图、使用数据库表、确认数据库模式、验证存储过程、将命名/装箱约定应用于数据库专用的标识符和/或基于当前项目设备激发违规)的信息。而且，与当前上下文的聚集集合有关的规则集的配置通常动态进行。因此，结果通常在软件开发生命周期中的精确和适当的时刻返回给用户。如本文所述，正确结果或软件开发生命周期中的精确和适当的时刻将依赖诸如以下各项而变化：代码/abstractions(抽象概念)的当前条件；其当前或假设的机器、操作系统、网络和/或运行时间环境；对包括安全性、可靠性、后向兼容性以及字面上的性能的质量的各方面给定的项目要求；给定的项目生命周期、时间线和/或资源约束；给定的分析时间约束；给定的接收结果的人员理解和影响结果的能力；给定的由特定检查提供或由于上面未列举的任何原因(包括用户的纯粹的固执)而被覆盖的默认配置的任何特殊配置；等等。另外，因为分析上下文(例如，规则175，上下文参数180等)是可配置的、可扩展的、可插入的等等，本文描述的实施例定义开口的系统来描述多个与分析有关的中间上下文。

本发明还可按照包含功能步骤和/或非功能动作的方法来描述。下面是可在实践本发明时执行的步骤和/或动作的描述。通常，功能步骤按照完成的结果来描述本发明，然而非功能动作描述用于实现特定结果的更具体行为。尽管功能步骤和/或非功能动作可按特定顺序来描述和要求，但本发明不必受限于步骤和/或动作的任何特定的顺序或组合。另外，对步骤和/或动作的使用是对权利要求书的叙述——并且在下面图2的流程图的描述中——通常用于指示对这些术语的所期望的特定使用。

如前所述，图2例示本发明各个示例性实施例的流程图。下面图2的描述有时参考来自图1的相应元素。尽管可针对来自该图的特定元素进行参考，但这样的参考仅用于说明性目的并且除非明确声明否则不表示限制或者缩小所述实施例的范围。

图2示出方法200的流程图，它通过动态跟踪在其下开发代码的分析上下文并且应用一组预定义规则中对应于当前上下文条件的至少一部分，来管理这些规则的执行以便平衡性能考量。方法200包括动态确定一规则是否可以针对目标代码执行的步骤225。更明确地，步骤225包括接收205要进行分析的目标代码的动作。例如，代码分析工具100、规则管理模块155、规则执行模块140、开发设备105或者计算系统内的其它模块和组件可接收要基于预定义规则175对正确性、完整性和/或质量进行分析的目标代码120。

步骤225还包括接收210代码分析信息的动作。例如，动态上下文跟踪模块130可从各个开发设备105接收代码分析信息125用于动态跟踪正为其开发目标代码120的当前代码分析上下文135。注意，当前代码分析上下文135可按照目标代码开发阶段、目标代码类型或状态、操纵目标代码120的源、目标代码120的用途或者一或多个开发或运行时要求来定义。

在定义目标代码开发阶段的情形中，这样的阶段可包括设计、构建、部署或其它级。还要注意，构建阶段可包括诸如编辑阶段、用于构建的编译阶段、或者开工之前阶段等。因此，为这样级定义的规则可能是针对还未被编译到盘的目标代码120进行的后台分析。还要注意，构建级可包括里程碑阶段，该阶段由于按照分析持续时间、要求的输入、要求的输出、假阳性的高或频繁的发生、调度考量中的一个或多个执行规则的至少一部分所需的开销，或者因为执行更容易作为随其它规则的批处理的一部分来完成而要求特定的用户输入以执行规则的至少一部分。

还要注意，在当前代码分析上下文按照目标代码类型或状态来定义时，这样的类型或状态包括诸如源代码、目标代码、二进制代码或抽象代码状态等等。对于抽象代码状态，这样的状态可以是对不提供源代码的完整描述的目标代码的设计时分析。

步骤225还包括接收215对应于从一组预定义规则选择的规则的上下文参数的动作。例如，规则管理模块155可接收当前代码分析上下文135以及对应于从规则组175选择的一或多个规则的上下文参数180两者。注意，上下文参数按照至少代码分析上下文信息为规则的至少一部分定义执行条件(通过例如元数据)。而且，上下文参数180可按照用于完成分析的运行时持续时间、需要输入的信息和/或得到的输出中的一或多项包括有关规则行为的元数据。注意，要应用规则的什么部分(例如其结果的数量或类型)可以基于其它因素，诸如影响或改变规则行为的配置。如前所述，这样的配置可基于对于字面规则执行、噪声过滤或其它控制机制有意义的设置/控制信息。

还要注意，上下文参数180定义所支持的代码分析上下文的执行条件，它们按照优选的、可任选的、所要求的等中的一或多个来确定优先级。但是，通过一或多个配置设置和各种开发设备105、关联于代码分析工具100的控制文件和或通过允许上下文参数180可被配置能够覆盖这些执行条件。此外，注意上下文参数可被配置成允许扩展现有的上下文条件。

步骤225还包括根据当前代码分析上下文评估220规则上下文参数的动作。例如，规则管理模块155可评估规则上下文参数180和当前代码分析上下文135用于动态确定部分或全部规则150以便针对目标代码120执行。注意，可完成这样的评估以便在开发过程中的适当阶段处应用规则150。还要注意，根据当前代码分析上下文135对规则175上下文参数180的评估可考虑代码与分析上下文之间的分层关系、该组预定义规则175或两者。

本发明可在不脱离其精神或实质特征的情况下以其它具体形式体现。描述的实施例在任何方面被视为仅是说明性的而不是限制性的。因此，本发明的范围是由所附权利要求书而非上述描述来指示的。落在权利要求书的等价意义与范围之内的所有改变要包括在其范围内。

Claims (20)

1.在一个具有使用一组预定义规则检查软件的代码分析工具的计算机系统中，所述规则通常由通过配置设置控制的整体操作来执行，一种通过动态跟踪在其下开发代码的分析上下文并且应用所述规则中对应于当前上下文条件的至少一部分来管理所述一组预定义规则以便平衡性能考量的方法，所述方法包括：

接收要基于一组预定义规则对正确性、完整性或质量中的一或多项进行分析的目标代码；

从一或多个开发设备接收代码分析上下文信息用于动态跟踪正为其开发所述目标代码的当前代码分析上下文；

接收对应于从所述一组预定义规则中选择的规则的上下文参数，所述上下文参数按照所述代码分析上下文信息为所述规则的至少一部分描述执行条件；以及

根据所述当前代码分析上下文评估所述规则上下文参数，用于动态确定所述规则的所述至少一部分是否可以针对正在分析的所述目标代码来执行，以便在所述开发过程中的适当阶段处应用所述规则的所述至少一部分。

2.如权利要求1所述的方法，其特征在于，所述当前代码分析上下文是按照所述目标代码开发阶段、所述目标代码类型或状态、操纵所述目标代码的源、所述目标代码的用途或者一或多个开发或运行时要求中的一或多项来定义的。

3.如权利要求2所述的方法，其特征在于，所述目标代码开发阶段包括设计、构建或部署中的一或多级，以及其中所述代码类型或状态包括源代码、目标代码、二进制代码或抽象代码状态中的一或多项。

4.如权利要求3所述的方法，其特征在于，所述抽象状态是对不提供其完整描述的目标代码的设计时分析。

5.如权利要求3所述的方法，其特征在于，所述构建阶段包括针对还未编译至盘的所述目标代码进行的后台分析，并且包括编辑阶段、用于增量构建的编译阶段或者开工之前阶段中的一或多项。

6.如权利要求3所述的方法，其特征在于，所述构建阶段包括由于按照分析持续时间、要求的输入、要求的输出、假阳性的高发生率、调度考量的一或项执行所述规则的所述至少一部分所需的花费，或者因为执行最易于作为随其它规则的批处理的一部分来完成而要求特定用户输入以执行所述规则的所述至少一部分的里程碑阶段。

7.如权利要求1所述的方法，其特征在于，用于所述上下文参数的所述执行条件是由元数据定义的，以及其中所述元数据还按照完成分析的运行时持续时间、需要输入的信息或者得到的输出中的一或多项来定义所述规则的行为。

8.如权利要求1所述的方法，其特征在于，所述上下文参数定义所支持的代码分析上下文的执行条件，它们按照优选的、可任选选的或被要求的中的一或多项来确定优先级。

9.如权利要求8所述的方法，其特征在于，评估允许通过进一步评估所述一或多个开发设备中的配置设置、关联于所述代码分析工具的控制文件中的一或多项或者允许所述上下文参数可被配置来覆盖所述执行条件。

10.如权利要求1所述的方法，其特征在于，所述规则上下文参数是可配置的以允许扩展现有的上下文条件。

11.如权利要求1所述的方法，其特征在于，所述根据当前代码分析对规则上下文参数的评估考虑所述代码分析上下文之间的分层关系、所述一组预定义规则或者两者。

12.一种使用一组预定义的规则检查软件的代码分析工具，所述规则通常由通过配置设置控制的整体操作来执行，所述代码分析工具被配置为通过动态跟踪在其下开发代码的分析上下文并且应用所述规则中对应于当前上下文条件的至少一部分来管理所述一组预定义的规则的执行以便平衡性能考量，所述代码分析工具包括：

动态上下文跟踪模块，用于从一或多个开发设备接收用于确定正为其开发目标代码的当前代码分析上下文的代码分析上下文信息；规则管理模块，用于按照所述代码分析上下文信息评估所述当前代码分析上下文和指示规则的至少一部分的执行条件的上下文参数，其中基于所述评估，所述规则管理模块动态确定所述规则的至少一部分可以针对要对正确性、完整性或质量中的一或多项进行分析的目标代码执行；以及

执行模块，用于针对正在分析的所述目标代码执行所述规则的所述至少一部分，使得所述规则的所述至少一部分在所述开发过程中的适当阶段处得到应用。

13.在一个具有使用一组预定义规则检查软件的代码分析工具的计算系统中，所述规则通常由通过配置设置控制的整体操作来执行，一种用于实现通过动态跟踪在其下开发代码的分析上下文并且应用所述规则中对应于所述当前上下文条件的至少一部分来管理所述一组预定义规则的执行以便平衡性能考量的方法的计算机程序产品，所述计算机程序产品包括其上存储计算机可执行指令的一或多个计算机可读介质，当所述指令由所述计算系统的一或多个处理器执行时，使所述计算系统执行以下步骤：

接收要基于一组预定义规则对正确性、完整性或质量中的一或多项进行分析的目标代码；

从一或多个开发设备接收代码分析上下文信息用于动态跟踪正为其开发目标代码的当前代码分析上下文；

接收对应于从所述一组预定义规则中选择的规则的上下文参数，所述上下文参数按照所述代码分析上下文信息为所述规则的至少一部分描述执行条件；以及

根据所述当前代码分析上下文评估所述规则上下文参数，用于动态确定所述规则的所述至少一部分是否可以针对正在分析的所述目标代码来执行，以便在所述开发过程中的适当阶段处应用所述规则的所述至少一部分。

14.如权利要求13所述的方法，其特征在于，所述当前代码分析上下文是按照所述目标代码开发阶段、所述目标代码类型或状态、操纵所述目标代码的源、所述目标代码的用途或者一或多个开发或运行时要求中的一或多项来定义的。

15.如权利要求14所述的方法，其特征在于，所述目标代码开发阶段包括设计、构建或部署中的一或多级，以及其中所述代码类型或状态包括源代码、目标代码、二进制代码或抽象代码状态中的一或多项。

16.如权利要求15所述的方法，其特征在于，所述抽象状态是对不提供其完整描述的目标代码的设计时分析。

17.如权利要求15所述的方法，其特征在于，所述构建阶段包括针对尚未编译至盘的所述目标代码进行的后台分析，并且包括编辑阶段、用于增量构建的编译阶段或者开工之前阶段中的一或多项。

18.如权利要求13所述的方法，其特征在于，所述上下文参数使用元数据描述所述执行条件，以及其中所述元数据还按照完成分析的运行时持续时间、需要输入的信息或者得到的输出中的一或多项来描述所述规则的行为。

19.如权利要求13所述的方法，其特征在于，所述上下文参数是可配置的以允许扩展现有的上下文条件。

20.如权利要求13所述的方法，其特征在于，所述根据所述当前代码分析对所述规则上下文参数的评估考虑所述代码分析上下文之间的分层关系、所述一组预定义规则或两者。

Images