[发明专利]建议的应用评估系统

说明书

相关申请的交叉引用

本申请要求2008年11月10日提交的美国专利申请序列号 12/268,168的优先权，其是2007年5月16日提交的美国专利申请序 列号11/804,030的部分继续申请，通过参考二者的全部内容而将其 并入在此。

技术领域

本公开内容涉及评估标识为实现期望的功能性的应用。具体地， 本公开涉及搜索、导航和可视化工具，其接受高层处理概念作为输 入，该输入驱动应用的多层搜索以验证应用的逻辑确实实现了期望 的功能性。

背景技术

软件专业人员广泛认识到：应用经常未能实现如应用描述和应 用的项目总结所描述的功能性。软件专业人员使用各种不足以胜任 的技术来减小用于验证应用实现了具体的功能性的时间、金钱和其 他成本。软件专业人员将API调用视为高层处理概念的抽象形式， 并且为验证应用实现了期望的功能性，仅搜索特定API调用的存在。 例如，API调用可以被识别和/或描述为实现下拉菜单功能性，尽管 底层逻辑实际上可能并不包括递送下拉菜单的功能性所必需的逻 辑。当前的逻辑评估技术和工具需要大量资源和用户经验以便精确 地验证应用实现了支持高层处理概念的功能需求。现代化的搜索引 擎并不能保证由搜索引擎所标识的应用的逻辑实际实现了如项目总 结以及应用的文档所描述的功能性。

软件专业人士认为：在高层处理概念(例如，反映在应用的描 述中的意图)和在应用逻辑中发现的低层实现细节(例如，API调用 和实际运行时行为)之间的失配是验证应用实现特定功能性的重要 技术挑战。在将应用放置到软件库的过程中，软件专业人士意图撰 写关于应用的有含义的描述。应用的描述和应用的实际行为之间的 失配代表了“词汇表问题”的一个例子，其声明没有单个单词或短 语能够最佳地描述编程概念。

在软件开发的螺旋模型中，客户向开发团队描述高层处理概念， 并且客户和开发团队一起识别支持高层处理概念的需求。此外，开 发团队基于需求来开发原型，并且开发团队向客户演示原型以接收 反馈。原型试图接近于新应用的期望的高层处理概念(例如，特征 和能力)，这是客户期望开发团队构建的。来自客户的反馈通常导 致原型和原始需求的改变，如客户反复地精炼他们的行为。如果客 户对需求做出了大量改变，开发团队通常将丢弃该原型并且构建新 的原型，则将重复另一轮精炼反复。重复地构建原型而不重用现有 的应用逻辑使组织在浪费的项目资源和时间方面开销很大。部署应 用而没有充分地评估和验证应用的逻辑实现了期望的功能性将进一 步令软件开发复杂。

开发团队发现评估和验证应用的逻辑接近于高层处理概念以及 软件逻辑资源需求的任务是密集的。在应用部署的环境中，软件开 发专业人士认为此类应用逻辑是高度相关应用逻辑(HRAL)。许多 应用库(例如，开源库和由客户内部所维护的源控制管理系统)包 含成千上万不同的现有应用(例如，潜在的高度相关应用(HRA))。 不幸的是，开发人员发现验证应用的逻辑是很困难的，这要归因于 在搜索应用、评估和验证应用的逻辑实现了特定的功能性中所涉及 的时间和花销。

开发人员为了将软件系统从开发的一个阶段转移到另一个阶段 而必须支出的智力努力量可以被认为是“认知距离”。例如，使用 当前的搜索工具，开发人员为了验证应用实现了期望的功能性而支 出显著的智力努力。许多开发人员使用搜索引擎，该搜索引擎识别 作为搜索查询的一部分输入的关键字和在应用中找到的词之间的精 确匹配。应用可以包括描述、应用逻辑注释、程序变量名和应用的 变量类型。此类搜索引擎实际上增加了验证应用的难度，这要归因 于包含在应用中的糟糕的信息质量，以及无法减小验证应用的逻辑 实现了期望的功能性所需的认知距离以及其他因素。另外，许多应 用包括对应用的不完整的、误导的和不准确的描述。因此，即使关 键字与应用描述中找到的词匹配，也不能确保搜索引擎将识别实际 实现了期望功能性的应用逻辑(例如，高度相关应用逻辑(HARL))。

有效的软件评估技术减小了系统的初始概念(例如，明确并隐 含地描述了应用的特征和能力的高层处理概念)、验证分立的需求 和应用的产品实现之间的认知距离。不幸的是，当前的应用评估工 具缺少减小涉及验证应用逻辑以识别HARL的认知距离的能力。