基于潜在语义分析的软件构件采购自动化 - 理论电子笔记论文总结

理论计算机科学电子笔记189（2007）51-68www.elsevier.com/locate/entcs基于潜在语义分析的软件构件采购自动化Hans-Gerhard Gross1 Marco Lormans2软件技术代尔夫特理工Mekelweg 4，NL-2628 CDDelft荷兰周军3公安部第一研究所中国北京市首都体育馆南路1号，邮编：100044摘要组件采购的第一步是在现有组件的大型存储库中识别所需的组件功能。在最高的抽象层次上，组件需求和组件描述通常用自然语言编写。因此，我们可以将组件采购重新定义为文本分析问题，并根据所需组件功能的描述，应用潜在语义分析自动识别大型存储库中合适的现有组件。在这篇文章中，我们激励我们选择这种技术的特征识别，描述它如何可以应用于特征跟踪问题，并讨论了我们在一些案例研究中应用这种技术所取得的成果。保留字：软件构件、知识库、特征映射、文档分析。1介绍在一个软件组件可以被组装成一个新系统的一部分之前，它必须在市场上找到，它对目的的适合性必须根据功能和行为来确定，并且必须根据非功能性应用需求来选择。这些步骤被称为组件采购，它们在组件集成之前执行[24，30]。采购涉及两个1电子邮件：h.g. tudelft.nl2电子邮件：m. tudelft.nl3 电子邮件地址：zhoujun@fri.com.cn1571-0661 © 2007 Elsevier B. V.在CC BY-NC-ND许可下开放访问。doi：10.1016/j.entcs.2007.05.04752H.- G. Gross等人理论计算机科学电子笔记189（2007）51利益相关者、开发和提供组件的组件提供者以及需要组件以组装新应用的组件客户客户和提供者是两个角色，可以由同一工作组、同一组织或不同组织（第三方）的个人承担。在软件领域，客户通常会将其需求规格部分调整为现有组件，而组件提供商则会提供其现有组件的专用变体这需要进行调整，其动机是以下考虑：• 如果组件客户完全根据自己的需求设计应用程序，那么他们不太可能，或者至少很难找到与其预设规格完全对应的现有组件。• 当根据组件供应商的预定义规范完全从现有组件构建系统时，组件客户将失去与使用相同领域特定组件的竞争对手的区别。今天，市场差异主要是通过软件功能的独特“外观和感觉”来实现的• 纯粹的外包定制开发通常成本太高。采购涉及为特定目的确定候选组件，并评估需要进行的改造数量。在集成过程中，选择一个候选组件并将其集成到客户的框架中。换句话说，调整已经实施。最后，必须对集成进行定性评估，即通过测试或分析。只有按照[23]中所述的方法进行广泛的评估和测试后，才能确保工作组件的成功。图1中显示了与组件采购和集成相关的活动和工件（包括开发步骤）的概述。从图中可以看出，应用工程师必须经历一个完整的开发周期，包括需求工程和分析、设计和建模以及实现和测试，以确定候选组件是否可以集成到给定应用程序的特定环境中。如果图1中标识的双方将为所需和所提供的组件接口使用相同的规范样式，如果他们将为他们请求的和所提供的组件行为应用相同的语义，并且如果他们将在相同的抽象级别上进行通信，那么采购和集成将大大减轻。这通常不是现在的情况，将来也不太可能，因此两个利益相关者都回到了最小的共同点，即自然语言。它是记录软件需求的最重要的符号[7]，组件采购和集成的常见做法是工程师基于纯文本描述选择候选组件。本文将讨论图1中显示的第一个活动的挑战，即组件采购。采购涉及映射所需组件H.- G. Gross等人理论计算机科学电子笔记189（2007）5153组件客户谈判和沟通组件供应商发展阶段元器件采购所需组件特性比较和映射提供的组件功能分析需求工程客户映射和比对供应商提供设计建模组件集成适应建模实现客户适配器供应商测试测试Fig. 1.与组件采购和集成相关的活动和工件。特征到所提供的组件特征，并评估现有组件满足所述要求的程度。我们认为，组件采购可以自动化，至少部分地，在最高层次的抽象，以支持应用工程师在选择几个候选人，有可能匹配的规定要求了一个巨大的组件集合。这些候选组件可能适合于适应客户现有组件框架的给定上下文在第2节中，我们概述了现有的技术，如组件开发框架，组件模型和协调符号，解决组件识别，选择和适应的问题。这些技术主要面向较低的抽象层次。在第3节中，我们将组件采购问题重新表述为文档分析问题，并演示了如何应用潜在语义分析来自动识别组件库中以自然语言编写的需求。第4节概述并讨论了我们使用该技术进行的实验结果，第5节总结并结束了本文。2相关工作及面临的问题尽管在过去十年中组件技术取得了所有进展，即，部署环境和运行时平台（如CORBA、JavaBean、COM或.NET [44]），在更高抽象级别上的组件采购和集成，以及应用程序开发的早期阶段，仍然没有得到充分解决。为了推动54H.- G. Gross等人理论计算机科学电子笔记189（2007）51在可能的最高抽象级别上，在各种组件抽象、行为描述和非功能属性2.1集成层上的组件映射和协调基于组件的开发中的大多数进展都是在最低的抽象层、实现层或组件布线层上实现的，所有明显的组件平台和技术或组件模型都在[44]中描述。这些技术支持基于所谓的接口描述语言（IDL）的组件服务（自动）互连。基于构件的开发方法和形式化语言研究界已经提出了在实现之上的抽象层次多年来，已经提出了各种方法其中一些方法具有更正式的性质，如CL [26]，Koala[45]，Piccola [35]或抽象行为类型[2]。其他一些人则从更全局的角度看待组件集成，并将组合的概念嵌入到一个整体的、不那么正式的开发框架中。这些所谓的开发方法中最常见的是OMT [42]，Fusion [11]，ROOM [43]，HOOD [41]，OORAM[40]，Catalysis [18]，UML组件[9]，选择透视图[1]，FODA [29]，Rational统一过程（RUP）[27]，仅举最常见的名字。从这些方法中产生的许多概念很容易在组织内水平上或多或少成功地应用于工业中，例如，理性统一过程。然而，开发方法并不普遍适用于组织边界。由于它们的复杂性，它们通常深深地嵌入到整个组织环境中，因此它们的概念在客户和供应商之间不易转移。此外，它们受不同图形符号和特定工具的约束，不一定允许不同利益相关者之间轻松交换信息以文本形式。前面提到的正式组件组合和协调语言将组件组合属性的推理提升到更高的抽象级别，试图避免完整的实现周期。然而，它们似乎并没有进入工业界，仅仅是因为工业界害怕引入严格的规范化技术所带来的高额初始投资。考拉是一个例外，因为它是从工业背景中走出来的。尽管如此，Koala只为对象连接提供语法映射，而不考虑行为。模型驱动的软件开发社区建议为每个组件构建一些（UML）模型[5，8，38]，这些模型可以直接进行比较和调整。例如，KobrA方法提出了一种两阶段的方法来实现组件重用[4]，即创建一致性映射和导出语义映射。KobrA建议使用UML模型作为原生规范符号，并要求外部组件接口在UML中进行规范。外购H.- G. Gross等人理论计算机科学电子笔记189（2007）5155因此，组件必须用UML描述，以符合KobrA的原生表示（一致性映射）。然后，可以将所获取的外部组件的UML模型与集成组件框架的UML模型进行比较，并协商适应性。语义映射是UML模型的集合，它完全描述了必要的适配，它可以被视为适配器组件的规范。2.2采购层的组件特征映射在采购层面（如图1所示），自然语言是最重要的沟通符号[7，16]。由于这些要求明显缺乏形式，采购一级无法以任何方式得到工具的支持。一般来说，有两种正交或补充的方法来解决更高抽象级别上的特征映射问题，并使组件或系统描述更易于自动化处理。(i) 一种自下而上的方法，用于提高 实现级别上升到需求工程级别。这就是MDA社区目前的目标[8]，或者说是组件协调语言所提出的：在比实现级别更高的抽象级别上引入（半）形式化描述，以及合适的模型映射和转换机制。(ii) 一种自上而下的方法，在最高抽象级别的自然语言需求和规范中引入更多的结构和严格性这种方法的例子包括使用场景和模板[21，25，28，39]，或受控的自然语言，如Attempto Controlled English [19，20]。然而，在第一种方法中，它试图在更高的抽象层次上应用类似的形式化规范技术，这些技术用于频谱的低端，第二种方法承认自然语言是需求和分析层次上的主要符号，并引入了结构和严格性。这两种方法的目标都是实现所述目标和所提供的特性之间的映射，或者在更高的抽象级别上实现所需和所提供的组件属性之间的映射，例如，CORBA在编程语言级别上提供的映射[37]。更结构化的需求、严格性和形式化是使组件描述映射更易于自动处理和自动推理的关键因素在下文中，我们将以一个基于组件的嵌入式系统为例，说明在采购层面上组件需求和功能映射的挑战。图2显示了现有车辆报警终端的组件树，该终端可内置于由安全/安保服务运营的车辆中，如救护车、消防车、警车或装甲车。报警系统用于通过GPS和Galileo（未来）跟踪车辆的位置，通过无线电或GSM网络报告车辆的状态，如果车辆离开预定的地理区域或车辆出现问题，则发出警报，56H.- G. Gross等人理论计算机科学电子笔记189（2007）51设备数据处理<<系统>>报警终端呼叫处理轨道数据处理参数处理远程控制数据处理显示数据处理自检数据处理报警数据处理GSM控制器GPS控制器功率控制器手持式控制器输入/输出控制器存储器控制器显示控制器看门狗<<系统>>服务中心图二.以包含树为例的车辆报警终端组件的逻辑组织。该组织对应于图中的设计层。3 .第三章。在紧急情况下呼叫帮助，例如，武装抢劫装甲车。图2中显示的报警终端的每个组件是根据一组标准文本文档描述的。组件的文本规范是从系统级需求（如表1中所述的示例需求）中派生和分解的。当系统从零开始开发时，即，在开发第一个报警终端系统时，工程师根据架构和凝聚力考虑将其分解为组件。然而，在基于组件的应用程序开发中，重用是关键的驱动力，因此在报警终端的后续版本或变体中，工程师将根据组件库中的现有组件对系统进行分解图3展示了在基于组件的开发项目中必须执行的组合/分解维度和抽象/具体化维度系统开发从左上角开始，抽象的系统需求[23]。这些需求也代表了高水平的组成，因为它们描述了整个系统。在随后的步骤（设计）中，需求被转化为更具体的子系统或组件规范。这就是系统的架构和逻辑组件层次结构出现的地方[4]。最初，如果我们从头开始开发一切，我们会选择遵循一些分解规则的任意组件层次结构图3中的实施例具有定制开发。然而，由于我们的目标是提高重用程度，我们必须根据现有物理组件的约束来分解逻辑层次结构图3示出了具有现有部件的组装的图3中的实施例。这是一个迭代过程，H.- G. Gross等人理论计算机科学电子笔记189（2007）5157Req-ID描述R-CN-1在紧急情况下，司机按下紧急按钮时发出报警信号R-CN-1.1报警按钮应连续按下2s以上R-CN-1.2报警信号应包括报警类别、GPS位置、报警R-CN-1.3报警信号应通过GSM网络发送到服务中心R-CN-3对报警输入的反应时间应小于50 msR-SUB-4报警信号应加密R-REQ-6系统应持续发出报警信号，直到收到服务中心R-SYS-8如果预先设定了行驶路线，当汽车偏离其路线R-REQ-17系统应能够执行自检并将结果发送到服务中心R-R18系统应每隔50 ms检查一次主电源、GPS天线和紧急按钮，如果它们损坏，则R-REQ-22当多个报警输入同时R-SYS-31系统应配备备用电池R-REQ-31.1当主电源电压低于阈值时，系统应切换到备用电池R-SUB-31.2系统应在低电压R-REQ-38位置数据应至少每秒更新一次，并应存储R-SYS-39如果系统无法接收GPS数据，则应使用存储的最新数据集R-SYS-43系统应能够接收并处理来自服务中心的命令R-SYS-48系统应能够使用范围句柄进行电话呼叫R-SYS-49系统应通过RS485与手柄通信R-SYS-51系统待机时的消耗电流应小于10 mA R-SYS-55系统应始终运行（R-SYS-67系统应提供110紧急呼叫接口R-SYS-71系统应提供导航器R-SYS-72系统应提供车辆黑匣子记录表1车辆报警终端的系统级要求示例。• 从现有物理组件• 根据重用的组件重构逻辑层次结构，以及• 检查所有的需求是否已经被某些现有的实现所覆盖。从最后一项和图3中的说明可以明显看出，基于组件的开发在很大程度上是一个可追溯性问题[22]。应用工程师必须将需求与设计工件和实现中的特定功能联系起来。这确保了所有的需求都是通过一些物理组件实现的。因此，以下组合是可行的：• 一个需求与一个组件相关联• 一个需求与几个组件相关联• 一个组件实现多个需求。• 有些需求无法追溯到实现（特性将58H.- G. Gross等人理论计算机科学电子笔记189（2007）51组合物要求执行设计物理组件具体化逻辑组件抽象分解图三.高级系统需求、低级逻辑组件规范和存储库中现有物理组件之间的特性映射。需求必须在所有开发阶段都可以追溯到其相应的实现。从零开始执行可追溯性链接也可以双向建立，这对于嵌入式系统开发特别重要，以便评估组件功能在多大程度上无法追溯到需求。这告诉我们，重用组件提供的功能中有多少是我们的系统实际需要的，有多少是不需要的开销。在本节中，我们已经论证了组件采购在很大程度上是一个特性可追溯性问题。系统需求必须可以追溯到分解层次结构中的设计工件，以及它们的实际物理实现。[32，33]中描述的可追溯性与此处描述的所需和所提供组件规范的可追溯性之间的差异在于分析的文件类型。然而，在第一种情况下，所有开发文档都可以用于跟踪，即设计文档、源代码、测试用例和其他描述性工件，在第二种情况下，我们只处理组件描述。至于文本文档作为描述系统和组件属性的主要手段，因此，我们可以使用先进的文档分析技术进行自动跟踪和链接。如何做到这一点将在下一节中介绍。H.- G. Gross等人理论计算机科学电子笔记189（2007）51593将组件采购转化为文档分析问题文档分析或信息检索技术的基本方法查询由希望检索感兴趣的文档（例如，从互联网）根据查询的含义我们可以使用相同的术语来描述组件采购，因此，我们可以将之前描述的组件采购问题重新表述为文档分析问题或信息检索问题[36]，其可以通过典型的检索技术（例如潜在语义分析（LSA）[13]）来解决。3.1潜在语义分析LSA或潜在语义索引（LSI）是一种非常有效的全自动数学/统计技术，用于提取和推断文档中单词的预期上下文使用关系[31]。它利用术语与文档关联中的隐式高阶结构，以便基于查询中的术语（在我们的情况下，需要的组件描述）引导相关文档（在我们的情况下，在存储库中提供组件描述）的检测[13]。LSA基于一个术语-文档矩阵，该矩阵表示术语在现有文档中的出现次数。矩阵A的列对应于文档，行对应于词干化和规范化的项。单元格包含某个术语在文档中出现的次数。 通过奇异值分解（SVD）分析该矩阵A以导出潜在语义结构模型[13]，从而得到另外三个矩阵T，S和DT：A=T0S0DT0。T0和DT0有正交列，表示左和右奇异向量，S0是对角线，包含奇异值。如果奇异值（S0）根据大小排序，则可以保留第一个k-最大值，并保留剩余的k较小的设置为零，导致与较小矩阵的近似拟合减少[33]。 新算法A的预测结果仅近似于A 和R的一个简单等式： A=A=T SDT。 我将通过数据库数据库来重新生成所需的数据。矩阵的降维很重要，以便过滤掉采样误差和不重要的细节，同时保持基本的潜在语义结构不变[13]。 它可以被看作是压缩相同（或类似）的信息，是在一个更小的空间中的原始的条款由文件矩阵。从这个矩阵中获取相关系数，最终得出文档之间的相似性。高值[-1.. 1]表示高相关性，低值表示文档之间的低相关性。60H.- G. Gross等人理论计算机科学电子笔记189（2007）51构件库C1C2C3远程控制数据报警数据C4处理C5处理显示数据处理参数处理C9C8C7C6看门狗显示控制器功率跟踪呼叫数据C11加工处理C10C12控 制器GPS输入/输出控制器C14自检数据处理C15C13控 制器GSM控制器C16加密存储器控制器手机控制器文件要求R-R2 -3：报警反应更短...R-104：报警信号加密R-106：连续报警.R-CMP-8：检查报警标志...R-CMP-9：复合报警数据...按文件分列的条款矩阵Req.C1C2C3C4C5C6C7C8C9C10C11...报警13016200001000...Emerg5012501001000...GSM100000000000...方面网络10000001913990...反应108622102030...时间307318137450222...输入2917429818660327...加密100000000000.............................................见图4。 分析和绘图过程。3.2建立可追溯性链接的LSA在组件需求概念和现有组件规范概念之间建立语义链接的技术最初来自软件维护和再工程社区[14，15，33]。在这里，目标是在现有软件系统的各种开发文档之间建立可追溯性链接，以便使设计决策和模型转换更加明确。在基于组件的开发中，我们面临着同样的挑战。系统级或组件级需求中描述的语义概念必须追溯到组件存储库的相应概念。这可以在图4和图5所示的以下步骤中完成[31，32，33]。(i) 追溯模型的定义。在这里，我们必须决定我们希望跟踪开发项目的哪些工件，即一方面是系统或组件需求，另一方面是组件描述。组件描述可以包括文本描述、源代码，但也可以包括组件测试。这是关于选择在分析过程中使用的文档类型。(ii) LSA。属于一个组件的所有文档都被复制到一个单独的文本文件中，用于逐个组件的识别。用于组件识别的所有要求都被复制到一个文档中，代表搜索查询。所有文档都由LSA进行分析，生成一个逐项文档矩阵。列表示所有文档，行表示所有相关文档。H.- G. Gross等人理论计算机科学电子笔记189（2007）51610corrcoef（A）=FIG。 五、 SVD（T0，S0，DT0），Dim_s_i_n_educt_n（S0， k=3），M_i_x_e_t_n（A_i）和C_r_C_e_f（A_i）。0.14080.1106-0.77250.1213-0.52250.1365-0.2546-0.0000...0.10890.0763-0.50370.05930.4066-0.52260.53540.0000...0.00180.0005-0.02210.0021-0.09200.47670.5136-0.7071...0.1441-0.77830.00060.61090.0135-0.00210.0021-0.0000...T0=0.1236-0.0218-0.2822-0.06990.72860.4996-0.3454-0.0000...0.4840-0.4768-0.0381-0.7194-0.1173-0.06470.03920.0000...0.83550.38510.25970.2935-0.00680.0070-0.00100.0000...0.00180.0005-0.02210.0021-0.09200.47670.51360.7071..............................56.64360000 00 0...028.0933000 00 0...00 23.773900 00 0...00000 00 0...k= 3;S0=00000 00 0...00000 00 0...00000 00 0...00000 00 0..............................0.10190.0128-0.52500.0426-0.64820.45400.2928-0.0000...0.13270.12340.09830.1325-0.00870.0662-0.0163-0.1927...0.39090.2036-0.69460.10270.2003-0.4452-0.27160.0079...0.11230.0207-0.2033-0.04340.70690.51600.3667-0.0232...0.58590.09040.2642-0.2296-0.12070.0388-0.0280-0.6398...0.2354-0.10980.0216-0.35550.0404-0.32440.60600.1012...DJ=0.32750.12710.17350.0089-0.03040.1811-0.15770.2233...0.1710-0.51210.05960.5264-0.0358-0.27040.3333-0.0103...0.1731-0.3577-0.01960.30840.12640.3188-0.3391-0.0798...0.0229-0.24930.00020.27590.0173-0.02020.0329-0.2262...0.2617-0.5840-0.0379-0.4845-0.04160.0800-0.27910.3632...0.41530.33620.29170.3254-0.05930.06260.08840.5507..............................8.40334.224416.6394-2.63781.51744.3494-2.7037-2.5715...5.59352.781311.3469-1.77671.61872.3882-1.4810-1.7749...0.21730.10980.4169-0.0600-0.03910.1866-0.1130-0.0096...-2.0765-2.59576.42562.55215.1038-2.26442.750418.3839...A=3.第三章。25441.37998.3980-0.90593.1904-0.15230.23830.5306...1.3678-1.117216.33860.516017.4719-11.15657.998811.2646...3.84310.683919.4945-2.813432.0062-24.950415.3553-9.1094...0.21730.10980.4169-0.0600-0.03910.1866-0.1130-0.0096..............................请求C1C2C3C4C5C6请求1.00000.94290.6253-0.87980.03790.1089-0.1619...C10.94291.00000.3330-0.8551-0.22250.3317-0.3977...C20.62530.33301.0000-0.54920.6994-0.55090.5475...C3-0.8798-0.8551-0.54921.0000-0.26950.1881-0.1094...C40.0379-0.22250.6994-0.26951.0000-0.98160.9789...C50.10890.3317-0.55090.1881-0.98161.0000-0.9956...C6-0.1619-0.39770.5475-0.10940.9789-0.99561.0000...C7-0.6433-0.7199-0.22540.9139-0.19300.1883-0.0963...C80.66330.74120.2295-0.92120.1737-0.16460.0727...C90.58730.66030.2134-0.89010.2432-0.24990.1585...C100.56090.63200.2075-0.87750.2652-0.27710.1860...C11-0.5849-0.6577-0.21290.8890-0.24530.2525-0.1610..............................62H.- G. Gross等人理论计算机科学电子笔记189（2007）51在这些文件中确定的术语。一个文档包含查询（组件需求），所有其他文档包含来自存储库的组件规范。单元格表示每个文档中出现的术语（图4）。SVD生成三个新矩阵（图5，T0，S0，DT0）。(iii) 通过对SVD所记录的数据进行分析，矩阵（图5，A/CN.9/2004/L.10）。 这是一种将数据存储在RIX中的方法A，虽然在一个较小的子空间，从而过滤掉无关的信息。例如，最初，“警报”概念在文件“要求"中出现了13次，但LSA“估计”，8. 4033应该是根据所有其他文件中术语“警报”的上下文使用而调整的占用数。计算重构矩阵的相关系数一种新的数据存储方法，用于存储数据的简化方法：CorrCoef（A）在图5中。高的数字意味着来自组件需求文档的概念也包含在来自存储库的组件描述中。(iv) 可追溯性链接选择和识别合适的组件。这里的问题是哪些组件确实实现了需求，或者换句话说，我们在哪里划分感兴趣的组件和不相关的组件？有几种策略可以0的情况。7）、可变阈值（选择，例如，最佳20%相似度）。根据图5中显示的示例中的结果，我们的分析方法表明，组件C1似乎是最合适的候选者（概率为0. 9429），但是也可以考虑C8（具有较低的概率0. 6633）。4LSA实验与评价我们已经将LSA应用于许多不同规模和复杂性的跟踪问题重要的是要注意，对于评估，我们需要已知各种开发工件之间的联系的现有系统。换句话说，我们应该将LSA应用于我们已经知道所有工件之间的可追溯性链接（从需求到实现）的遗留系统，以便我们可以使用这些知识作为基准来评估LSA的性能，以找到（重建）这些链接。否则，正如我们在一个案例研究中所看到的那样，很难对结果进行评估。作为预处理工具，在我们应用LSA之前，我们使用Zeimpekis和Gallopou-los的TMGMatlab工具箱[46]。它配备了许多预处理功能，如停止词消除和词干，并生成逐文档矩阵。H.- G. Gross等人理论计算机科学电子笔记189（2007）51634.1PacMan案例研究我们应用LSA重建可追溯性链接的第一个案例研究之一是代尔夫特理工大学计算机科学学士课程中使用的PacMan游戏[32]。可用的文档包括10个需求文档，以用例描述的形式出现，19个描述游戏设计的文档（类层次结构）和17个带有测试描述的文档，以及Java实现。所有信息都是纯文本，包括Java代码。编程语言的关键词不带有任何语义意义，可以简单地通过将它们添加到停止词列表中来消除。然后由TMG过滤。或者，我们可以使用Doxygen [17]从源代码中生成文档，并将其用作源代码的替代品[33]。我们只是在分析中包含了所有可用的文档，从而产生了一个包含所有文档中约1200个相关术语的语料库。我们选择了所有相似性度量中最好的20%作为可追溯性链接。k值（矩阵缩减）在10%和20%之间变化，以评估选择对链路选择的影响。当k设置为20%时获得最佳结果。在这种情况下，LSA能够识别程序开发人员最初定义的17个可追溯性链接中的16个，尽管LSA发现了更多的链接（误报）。这是由于不同文档中描述的用例导致不同的实现正在处理类似的程序事件，例如，一种是在游戏暂停之后重新开始游戏，另一种是在游戏结束之后重新开始游戏。这两个需求描述了类似的概念，因此它们通过LSA联系在同样的，我们也发现了描述玩家移动和怪物移动的需求，或者关于玩家撞上怪物和怪物撞上玩家的描述。所有这些要求都描述了类似的概念，因此通过工具联系起来。LSA未识别的链接是PacMan GUI及其相应测试套件的描述。对GUI的需求文档和相应的测试文档的分析揭示了两个工件之间的概念不匹配。需求描述了GUI图形元素的布局和行为，而测试描述则是关于测试GUI的人应该看什么，应该点击哪些元素。因此，GUI的测试描述与大多数其他文档相链接，因为它们的概念出现在测试描述中。它们没有链接到GUI需求文档，因为那里描述的概念与测试描述中的概念不同，所以LSA没有链接它们。4.2Callisto案例研究我们在埃因霍温技术大学进行的另一个案例研究使用了一个名为Callisto的软件系统。它是一个软件工程工具，可用于指定组件接口。我们研究了三类文件，用户需求规范、设计文件和验收测试计划，并试图64H.- G. Gross等人理论计算机科学电子笔记189（2007）51把它们相互联系起来并加以实施。在包括源代码在内的实验中，我们最终获得了5500个相关术语。工具的参数设置为与PacMan病例相同的值。 LSA能够将63%的需求正确地跟踪到代码中，并将94%的需求准确地跟踪到测试规范中。将需求与代码联系起来会产生许多误报。因此，正确恢复链路的速率很低。需要注意的是，需求和测试描述通过唯一标识符有明确的链接。因此，可以很容易地将需求追溯到它们各自的测试文档，从而可以直接评估需求到测试追溯的结果。此外，我们发现LSA在建立需求和设计文档之间的联系方面比将测试套件与需求联系起来更困难。这可以归因于这样一个事实，即许多设计文档都包含以图片形式捕获许多基本概念的UML模型。这些模型没有包括在我们基于文本的分析中，因此那里描述的概念不会进入逐文档矩阵。因此，LSA只能考虑设计文件中包含的部分信息，导致链接更弱，因此值较低，为68%。4.3飞利浦案例研究与飞利浦应用技术公司合作，我们进行了一个案例研究，在这个案例中，我们试图将需求与DVD刻录机软件的一部分的组件描述和测试描述联系起来。最初的问题是，合同中商定的所有要求是否或在多大程度上在最终产品中得到实际执行，特别是在出现新的要求或变更请求这可以被看作是最现实的情况，在这种情况下，我们试图将功能描述映射到实际的组件描述，并评估组件对所需功能的此外，我们没有系统开发人员制作的明确的可追溯矩阵，因此很难从案例研究中进行最终评估并得出确切结论。然而，它提供了许多新的见解LSA的性能组件特征映射。存在对可用的不同抽象级别的要求，并且不清楚哪一个层次结构将是最合适的。为了分析，我们决定包括第一和第二最高抽象级别。较低层次的要求似乎包括太多细节，无法追溯到组件说明。在进行LSA之前，我们试图找到文件之间的明确联系，旨在提出一个手动生成的可追溯性矩阵。我们将文本文档转换为XML格式，并使用XPath表达式执行一些文本查询[10]。然而，我们既不能发现需求的唯一标识符，也不能发现任何其他文档中的需求标签（例如，作为评论）。LSA在这方面更有效。分析了20个工件，所有工件都以文本文档的形式工件的预处理导致在术语-文档矩阵中有2300H.- G. Gross等人理论计算机科学电子笔记189（2007）5165实验的一个值得注意的结果是，与LSA产生的需求和测试描述之间的相似性相比，需求和组件描述之间的概念预测相似性要高得多在另外两个案例研究中，情况正好相反。显然，组件描述与相应的需求有很好的联系，因为每个组件都配备了对其功能的一般高级描述而且，很明显，测试描述与需求的联系很差，因为测试是根据与高级需求不对应的组件的低级设计描述定义的。这种抽象上的不匹配使得一个定义良好的可跟踪性模型的重要性变得显而易见。在这种情况下，我们无法得出有关LSA性能的具体结果，因为我们缺乏该系统开发人员提供的明确链接。他们发现，在我们的分析中，确实有许多联系被正确地识别出来了，但对于其他许多联系，他们却不同意。4.4结果讨论通过使用所介绍的案例，我们深入了解了如何在典型的软件开发过程中将LSA应用于链接各种类型的可用文档。我们的主要目的是链接系统级需求或组件级需求，来自系统的分解层次结构，在一个存储库中的各个候选组件，通过使用潜在语义分析。然而，在实验中，我们使用了所有可用的文档，包括高层次和低层次的需求，中间设计文档以及测试描述和源代码。对于LSA，哪些文档属于哪种类型的工件并不重要。它只是试图猜测包括在基于这些文档中固有的底层语义结构的分析中的所有文档。我们的责任是将各种类型的文件归属于一个不同的实体，即，一个组成部分。这可以通过将所有相关信息复制到表示一个组件描述的单个文件中来完成。LSA将把它在其他文档中发现的与我们组件描述的概念相似的任何概念链接到该特定组件。因此，它在为每个组件提供的信息类型方面非常健壮，只要它以文本形式出现在Callisto案例研究中，我们有许多可用的UML图，显然包含了分析中没有考虑的基本概念。这导致这些文件中的概念联系不好。文字描述可能会导致更好的结果。图形符号越来越多地被用于工业中，因为人们可以更容易地掌握这些文件的要点。在未来，我们将不得不研究如何自动提取这些信息，并以文本形式提供。从需求中可以很好地跟踪测试用例，这很有趣。测试用例，特别是系统级测试和验收测试，通常是根据需求文档中的信息设计的他们在那里-66H.- G. Gross等人理论计算机科学电子笔记189（2007）51很有可能包含类似的概念。毕竟，它们代表了实现（测试的执行）和来自高层需求或设计文档的测试结果（oracle）之间的隐含联系。LSA可以使这种隐含的语义相似性显式化。因此，我们主张组件规范应该始终与它们各自的测试套件一起，根据[23，24]中描述的测试组件。我们还观察到，低级别的特定于实现的测试用例不能很好地追溯到高级别的需求。这有点令人惊讶，因为抽象是我们人类处理复杂实体的唯一最重要的技术，我们希望我们在更高的抽象层次上使用相同的语义概念，尽管我们在较低的层次上使用，只是摆脱了细节。显然，情况并非如此，我们必须更好地理解抽象的机制。5总结、结论和今后的工作在本文中，我们介绍了一种新的技术，通过应用潜在语义分析，自动将需求链接到组件规范文档能够将应用程序开发项目中的基本概念跟踪到存储库中的组件描述集合是自动化组件特征检测和分析的先决条件。到目前为止，我们只能在组件存储库中识别应用程序所需的基本概念，并且我们可以以术语-文档矩阵的形式创建到描述组件的文档的然而，链接是加权的（带有概率），这样我们就可以将合适的组件数量限制在少数，而存储库中可能有大量的组件。LSA帮助我们从大型存储库中识别出一些相关的组件。我们进行的实验在这方面很有希望。LSA不为组件采购的下一步提供支持，即对可能进行的调整进行评估目前我们还没有下一个问题的答案。在未来，我们计划使用不同类型的文档进行更多的案例研究这将是有趣的，看看如何更结构化的文档，如用例描述和其他模板[28，39]，这是越来越多地使用在行业中，一个完整的LSA。这样的结构会提高其性能还是会产生负面影响？这同样适用于更正式的文档，例如包含逻辑和公式的需求。我们已经看到了UML图如何抑制基于文本的LSA技术。对于形式表达式也是一样的吗？我们将来要研究的另一个问题是如何从工业中使用的图表中提取文本概念[8]。引用[1] P. Allen和F.霜企业系统的基于代理的开发：应用选择视角。剑桥大学出版社，1998年。H.- G. Gross等人理论计算机科学电子笔记189（2007）5167[2] F.阿巴布抽象行为类型：组件及其组成的基础模型。在F.S.de Boer等人，编者，计算机科学讲义，第2852卷，Springer，2003年。[3] Attempto项目尝试控制英语。http：//www.i fi.unizh.ch/juanto.[4] C.阿特金森和其他人。基于UML的产品线工程。 Addison-Wesley，2002年。[5] C.阿特金森和H.- G.恶心模型驱动，基于行为的开发。基于业务组件的软件工程. Franck Barbier（Ed.），Kluwer，2003年。[6] C.阿特金森角H.G.邦斯格罗斯角，澳-地Peper（Eds）.嵌入式系