行之知识产权综合服务平台

技术领域

实施例一般涉及根据使用由需求文档和软件代码构成的本体模型的需求文档和 软件代码一致性检查。

背景技术

在系统开发过程中，需求文档提供关于软件必须为系统的成功运行提供的功能性 的必要信息。需求通常是以流畅的英语语言捕获，并且所得的需求文档遍布数百页。多个功 能需求可能具有一些重叠的功能性以及子功能性。因此，类似功能中的不一致可能导致软 件中的错误，从而导致或者产生故障。通常，主题专家SME检阅需求文档以识别不一致性和 正确性问题，并且将它们纠正以改进需求文档以及软件代码的一致性。此外，当在具有特定 实体（例如，车辆）的领域中观察到故障时，也可以将该故障的根本原因追溯到安装在车辆 中的模块中执行的其需求文档或软件。给定与需求相关的需求文档的长度和软件算法的数 量，手动地链接思维模型中的适当需求的任务是重要、耗时且容易出错的操作。

发明内容

实施例的优点在于识别需求文档之间以及需求与软件代码之间的不一致，使得能 够实现不同的子系统之间的故障可追溯性的。本发明还促进追溯通过车辆观察到的关于安 装在作为车辆组件的一部分的模块中的其需求文档或软件的故障。本文描述的实施例使用 从需求文档、软件代码以及从在用于识别不一致的领域中观察到故障时收集到的数据提取 的本体的比较。本文描述的实施例可以处理从各个异构源获得的数据的质量数量以及确定 需求文档水平和软件代码水平的根本原因，这通过最小化保修成本改进产品质量。

实施例预期一种在需求文档和软件代码之间应用一致性检查的方法。识别从数据 库获得的多个需求文档中的术语。处理器为每个术语分配一个词性标签。词性标签指示需 求文档中的每个术语的语法使用。处理器基于词性标签来将每个术语分类。分类识别每个 术语是零件术语、症状术语、动作术语、事件术语还是故障模式术语。处理器根据所分类的 术语来构建基于本体的一致性引擎。一致性检查通过在从两个上下文文档提取的本体之间 应用基于本体的一致性引擎来执行。识别上下文文档之间的不一致术语。校正具有不一致 术语的上下文文档中的至少一个。

本发明包括以下方案：

1.一种使用构建的本体模型在需求文档和软件代码之间执行一致性检查的方法，包 括以下步骤：

识别从数据库获得的多个需求文档中的术语；

由处理器为每个术语分配词性标签，词性标签指示需求文档中的每个术语的语法使 用；

由处理器基于词性标签来将每个术语分类，分类识别每个术语是零件术语、症状术语、 动作术语、事件术语还是故障模式术语；

由处理器根据分类的术语来构建基于本体的一致性引擎；

通过在从两个上下文文档提取的本体之间应用基于本体的一致性引擎来执行一致性 检查；

识别上下文文档之间的不一致术语；

校正具有不一致术语的上下文文档中的至少一个。

2.如方案1所述的方法，其进一步包括以下步骤：

响应于将词性标签分配给每个术语，识别每个术语是否是短语的一部分；以及

将所述短语分组为具有相同的术语数量的n元语法。

3.如方案2所述的方法，其进一步包括以下步骤：

基于POS标签来识别短语的开始和结束位置，用于确定短语的逐字长度。

4.如方案3所述的方法，其进一步包括以下步骤：根据逐字长度确定公共短语。

5.如方案3所述的方法，其进一步包括以下步骤：响应于确定两个相应短语包括 公共词性标签，估计用于确定相关分类的短语的字典式交互信息。

6.如方案3所述的方法，其中用于第一短语和第二短语的字典式交互信息由以下 公式确定：

。

7.如方案6所述的方法，其中将与第一短语相关的LMI概率和与第二短语相关的 LMI概率相比较，并且其中将与具有较高概率的相应LMI相关的分类分配给第一短语和第二 短语。

8.如方案7所述的方法，其中通过捕获其中指定特定短语的上下文使用朴素贝叶 斯网模型来确定上下文概率，其中使用LMI概率和朴素贝叶斯网模型来分配所述分类。

9.如方案1所述的方法，其中两个上下文文档之间的一致性检查包括一个第一需 求文档和一个第二需求文档。

10.如方案1所述的方法，其中两个上下文文档之间的一致性检查包括第一软件 代码和第二软件代码。

11.如方案1所述的方法，其中两个上下文文档之间的一致性检查包括需求文档 和软件代码。

12.如方案1所述的方法，其中两个上下文文档之间的一致性检查包括一个第一 需求文档和第二需求文档。

13.如方案1所述的方法，其中在第一软件代码与第二软件代码之间执行故障可 追溯性。

14.如方案1所述的方法，其中产生关于第一软件代码和第二软件代码的本体的 实例，其中将相应本体实例相比较以用于识别第一软件代码与第二软件代码之间的不一 致。

15.如方案1所述的方法，其中在第一软件代码与需求文档之间执行故障可追溯 性。

16.如方案1所述的方法，其中通过发现第一组概念术语与第二组概念术语之间 的类似性来确定一致性检查，其中使用以下公式来确定类似性：

其中P(c)是看见概念c的实例的概率，以及

其中如果大于第一预定阈值，则确定第一和第二组概念彼此一致。

17.如方案15所述的方法，其中当使用词的多个继承时通过发现第一组概念术语 与第二组概念术语之间的类似性来确定一致性检查，其中使用以下公式来确定所述类似 性：

其中P(c)是看见概念c的实例的概率，

；以及

其中指示用于词w的可能意义组，

其中如果大于第二预定阈值，则确定第一和第二组概念彼此一致。

18.如方案16所述的方法，其中第一预定阈值大于第二预定阈值。

附图说明

图1是一般流程一致性检测需求技术的方框图。

图2是需求链接技术的整体方法的方框图。

图3是用于识别关键n元语法的流程图。

图4是使用关键N元语法的示例性POS标签过程。

图5是用于POS标签的示例性概率估计的流程图。

图6是用于将概率与上下文信息相关的流程图。

图7示出与试验数据合作使用的训练表的使用。

图8示出示例性的基于本体的不同子系统之间的一致性检查。

图9示出用于从软件开发本体的技术的流程图。

图10示出可以用来捕获Java代码（例如，软件）的关键组件的域特定本体的实例。

图11示出图10中所示的本体的实例。

具体实施方式

图1示出基于本体的一致性引擎的一般流程的方框图10。虽然本文描述的实施例 是基于车辆的系统，但是应理解，系统可以应用于各种其他系统，包括飞机或其他基于非汽 车的系统。基于本体的一致性引擎使用一个或多个处理器、存储器（诸如存储器存储设备、 数据库）以及用于输出来自一致性检查的结果的输出设备。此外，处理器或者另一个处理单 元可以执行具有不一致术语的上下文文档的自主校正。在方框11中，获得包括多个需求的 需求文档。从需求文档选择相应需求。需求是提供与零件、系统或软件的功能性和操作需求 有关的细节的关于零件、系统或软件的描述。

在方框12中，在需求中删除停止词。在执行数据的自然语言处理时，停止词在数据 中增加不必要的噪音。停止词由以下各项构成但不限于此：“一”、“一个”、“该”、“谁”、 “www”、“因为”和“变成”，这些被认为是非描述性的。停止词列表可以存储在存储器13中，诸 如服务器的存储器、数据库、比较数据库或者另一个相应的数据库或存储器。去除从存储器 13获得的停止词列表中所识别出的作为需求中提取的信息的一部分的停止词。维持是关键 术语的一部分的停止词，并且删除不是关键术语的一部分的仅各别停止词以维持文档的正 确意义。

在方框14中，将词性（POS）和n元语法构造应用于来自方框12的剩余提取的术语或 从其输出的短语，这在图2中详细示出。

在方框15中，确定数据中n元语法的位置，这在图3中详细示出。

在方框16中，识别关键术语的不同和公共POS标签（tag），这在图4和图5中详细示 出。

在方框17中，如果POS标签是公共的，则例程进行到方框18；否则，例程进行到方框 20。

在方框18中，估计字典式交互信息。

在方框19中，基于朴素贝叶斯网分类器估计上下文概率。

在方框20中，将术语分类为用于构建本体比较引擎的零件、症状、事件、故障模式 或动作术语中的一个。

在方框21中，产生并识别需求子系统。在方框22中，产生本体比较引擎并且将其用 来执行相应需求子系统之间的一致性检查。可以在两个或更多个需求文档之间、需求文档 与软件代码之间、不同子系统的软件代码之间应用一致性检查，并且用于检测软件代码之 间的故障可追溯性。

图2示出词性标注器，其中需求文档内的逐字数据被标注。如图2中所示，词性由相 应标识符来标注，其中诸如“are”、“see”、“24HR”、“purge”、“evap”、“selenoid”的短语被分 配下面的POS标签：“are/VBP”、“see/VB”、“24HR/JJ”、“purge/NNP”、“evap/NNP”以及 “selenoid/NNP”。

使用POS标注模块来将标签应用于术语。可以在PennTreebankProject (http://www.ling.upenn.edu/courses/Fall_2007/ling001/penn_treebank_pos.html) 中找到这些标签的实例，所述实例包括但不限于此。标签可以包括但不限于CC（并列连词）、 CD（基数）、JJ（形容词）、JJR（形容词比较级）、NN（名词、单个或块）、NNS（名词复数）、NNP（适 当的名词单数）、NNPS（适当的名词复数）、RB（副词）、RBR（副词比较级）、RBS（副词最高级）、 VB（动词、基本形式）、VBD（动词过去式）、VBD（动词，现在分词）、VBN（动词，过去分词）、VBP （动词，非第三人称单数现在式）、VBZ（动词，第三人称单数现在式）。应理解，本文的POS标签 是示例性的，并且可以使用不同的POS标识符。

识别与所提取的短语相关的N元语法(n-gram)。术语“语法（gram）”指代作为整体 的短语的（一个或多个）术语并且“n”指代与短语相关的术语的数量。

图3是n元语法表的示例性图示。从每个需求文档，构建以下类型的n元语法：包括 具有单个词的短语的一元语法（例如，电池、变速器）；包括具有两个词的短语的二元语法 （例如，电池没电）；包括具有三个词的短语的三元语法（例如，主体控制模块、仪表板群集、 动力总成控制模块）；包括具有四个词的短语的四元语法（例如，主体控制模块不工作、变速 器控制模块组件）；以及包括具有五个词的短语的五元语法（例如，变速器控制模块组件故 障）。潜在地使用可能五个词长的n元语法的基本原理是因为在含有五个词的一些实例中的 短语（例如，燃料箱压力传感器模块）的关键性质。例如，关键术语的长度可以是五个词，这 些术语是零件的名称、症状、事件、动作和故障模式。

当所使用的技术不使用将会提供术语的起源或数据库以从每个需求文档识别关 键术语的任何域特定本体时（即，分类法），构建并使用n元语法。因此，可以使用自然语言处 理（NLP）方法，由此在技术的这个阶段构建的n元语法随后被标注有其词性以用于识别术语 的正确分类。

图4示出识别数据中的n元语法的位置的表。识别短语在每个其POS标签的开始和 结束位置以用于确定其逐字长度。如以下所展示，在相应n元语法的每一侧上设置三个词的 词窗。词窗是变量，其应基于文档的性质来决定。

XXXXT₁XX[T₂xx^StartIndex{Phrase_i}^EndindexT₃XT₄]XXX

左边的上下文信息=(Phrase_iT₂)

右边的上下文信息=((Phrase_iT₃),(Phrase_i,T₄))

与词窗中的n元语法一起出现的术语被收集作为上下文信息。这有助于识别公共短语 和关键短语。

图5示出识别与短语相关的公共和不同的POS标签的表。通过分析分配给第一子系 统的POS来识别公共POS标签，其中POS被分配给第二子系统。POS标签的分组帮助识别子系 统之间公共的那些相应POS标签。图6示出图形逻辑交叉，也称为分段之间的连接。如图6中 所示，可以区别开在两个子系统之间具有公共POS标签的那些相应短语。

如果发现与不同子系统相关的POS标签是公共的，则应用字典式交互信息（LMI）概 率技术。LMI概率技术帮助确定POS标签应被拣选到的分类。例如，以下短语“不应被启动 （shallnotbeactivated）”与症状和故障模式短语“MDRBVBVBN”一起出现。确定用于 潜在分类的以下短语的LMI概率：

确定以及

。

使用以下公式来确定用于每个相应短语的LIM：

在确定相应概率时，进行一起观察的的概率与在数据中独立地观察的 的概率的比较，其中。因此，具有较高LMI概率的相应 标签或被分配给用于各别短语的分类。

此外，可以使用基于朴素贝叶斯网模型的上下文概率，该模型捕获其中指定特定 短术语的上下文。朴素贝叶斯网模型预测分类成员概率。使用以下步骤来确定上下文概率：

步骤1：

在训练数据中使得T为具有特定标签的标注的n元语法的组，

类别、(和给定T组，我们估计T是否属于具有最大后验概率的特定类 别，即，

，等

步骤2：

与当前标注的术语一起出现的术语为根据朴素贝叶斯网模型的上下文‘c’提供具有独 立于对应于先前术语的标签的当前标签的术语。

步骤3：

如下计算最大似然估计：

。

在确定用于公共POS标签的LMI和上下文概率之后，术语或短语被分类在其相应收 集器（例如，类别）中。分类后的收集器可以用于需求文档之间、软件代码之间或者需求文档 与软件代码之间的一致性检查。此外，可以将分类后的收集器输入到可以与试验数据一起 使用的训练表中。

图7示出与试验数据合作的训练表的使用。在方框30中，将试验数据输入到引擎 中。在方框31中，识别试验数据中的N元语法，并且从试验数据识别出关键n元语法。

在方框33中，与训练表32合作使用来自方框31的关键n元语法以用于匹配试验数 据中的n元语法模式。在方框34中，将所得匹配分类到其相应的收集器中。

在方框35中，主题专家（SME）分析所分类的收集器以用于确定是否误分类任何术 语或短语。在方框36中，SME产生修订的收集器。

在方框37中，从相应分类的收集器构建本体。形成软件代码的相应本体可以从可 用于软件代码与需求文档之间的一致性检查的结果来构建。所示本体模型优于其他类型的 建模（诸如有限状态建模（FSM））的优点在于FSM主要用于过程流程建模而本体可以用于形 式化话语的域。也就是说，本体区分领域的类别级和实例级视图。因此，本体不需要应用域 的完整视图，而建模技术（诸如有限状态建模）需要应用域的完整信息。同样，可以在不改变 域级别类别而是仅通过捕获新应用特有的新实例来建模与特定域有关的应用的不同类别。

图8示出示例性的基于本体的不同子系统之间的一致性检查。将本体引擎38应用 于根概念和根概念。检查和的术语的一致性。应用以下步骤：

其中P(c)是看见概念c的实例的概率（在层级结构中P(c)是单调的）。

其中是包括二者的概念组。

在具有词的多个继承中，确定直接超类别的类似性的多于一个意义。

其中指示用于词w的可能意义组。

可以将所确定的类似性与预定类似性相比较以用于确定一致性。例如：

如果，

则确定和彼此一致。

如果，

则确定和彼此一致。

图9示出用于从软件开发本体的技术的流程图。

在方框40中，对于每个方法，获得方法名称。

在方框41中，进行确定是否正在使用外部方法。例如，如果一个方法在其执行内调 用另一个方法，则原始方法内另一个方法的调用称为外部方法。如果未使用外部方法，则例 程进行到方框43，否则，例程进行到方框42。

在步骤42中，获得外部方法的名称并且例程进行到步骤43。

在步骤43中，获得返回类型。本文中返回类型的概念指定方法在执行步骤之后正 在返回的输出。在步骤44中，识别回路和其范围。在步骤45中，识别“如果”参数和“获得”条 件参数。在步骤46中，识别输入变量和变量类型。步骤43-46可以同时地或顺序地执行。此 外，执行步骤43-46的次序不需要是本文中描述的次序。响应于收集信息和识别方法，例程 进行到步骤47。

在步骤47中，获得方法层级。

在步骤48中，识别类别名称。

在步骤49中，识别项目文件夹和数据包的计数数量。在此步骤中应用信息的提取， 因为文件夹通常含有特定需求特征的完整信息，且因此提取文件夹信息允许以一致的方式 获得与特定需求特征相关的有关信息。

在步骤50中，从软件代码检索参数，并且基于在步骤40-50中识别出的参数需求来 构建本体。

图10示出可以用来捕获Java代码（例如，软件）的关键组件的域特定本体的实例。 本体展示类别和本体中所包括的任两个类别之间的“具有一个”关系。原则上，本体指示 java代码可以具有“方法”并且该“方法”可以具有“名称”、“回路”、“输入参数”、“如果条件” 等等。

如果在第一java代码与第二java代码之间进行比较，则必须创建关于第一java代 码和第二java代码的本体的实例以比较两个java代码。

图11示出图10中所示的本体的实例。该实例是基于以下样本java代码来创建：

“类别”定义结构，并且该类别的实例定义类别内的目标。如图11中所示，java代码 “ExteriorLightSubsystemFeatureRequirement（外部灯子系统特征需求）”的特征具有调 用“checkLampActivation（检查灯启动）”的方法，并且此方法具有两个各别输入 “vehicleSpeed（车辆速度）”和“lampActivated（灯启动）”。此方法还具有由返回陈述 “lampActivated（灯启动）”指定的输出并且还具有含有相关运算符“>”的如果条件（if condition）。此如果条件具有基于如果条件的“真(true)”或“假(false)”值分配的结果分 配陈述。应理解，图10和11是域特定本体的实例和本体的所得实例，并且本文描述的该发明 并不限于本文所示的实例。

领域中的故障可以被链接到需求问题。追溯故障（诸如在需求或软件中捕获的参 数值）是识别和校正问题的技术。在大多数情况下需要追溯高达需求水平的问题，因为与先 进水平相比较的在需求水平，可以容易地分析任何校正或改变对系统的另一个零件的影 响。

通过独立地测试不同产品并且手动地映射不同产品的结果（例如，映射需求和软 件）来执行故障可追溯性。除了向后方向（诸如“系统水平”到“部件水平”到“需求水平”）之 外，如本文所描述的技术使得能够在向前方向上（诸如“需求水平”到“部件水平”到“系统水 平”）进行故障追溯。

虽然已经详细描述本发明的某些实施例，但是熟悉本发明所涉及领域的人员将认 识到用于实践如以下权利要求所定义的本发明的各种替代设计和实施例。